The 10th Anniversary
日本中で新型コロナウイルス感染症が拡大する中、新幹線も空港もないド田舎陸の孤島ぶりが幸いして奇跡的な清浄さを保っていた山梨県の、ゴールデンウィーク明け頃からの感染者数急増に恐れ慄いている昨今、皆様は如何お過ごしでしょうか。
タイトルにもある通り、独立して今年で10年。
8年目, 9年目は面倒くさい特段書くこともなかったためアニバーサリー記事の執筆をサボってしまいましたが、さすがに10年の節目には何か書いておかないと、読む人がいるかどうかはともかく自分の意識が緩み切ってしまいそうなので、アップロード予定日の2週間前からポツポツと認 (したた) めている次第です。
肝心の仕事の方はどうかと言えば、この4月からとある大手企業のオフィスに入り、そちらの業務システムの改修に携わらせて頂いております。 使用する言語も VB.NET および、レガシーシステムを構成するVBScriptとこれまでに縁のなかったもので、BASIC を扱うのは PC-98 時代以来となる私は昔を懐かしみつつも、仕事の傍ら勉強に励んでおりました。 そうそう、For ループは Next で閉じるんだったねぇ......。 まぁ、私ほどのプログラマともなれば、使い始めて2ヵ月経った頃には完全に理解できてしまっていたわけですが。
【エンジニア用語解説】
- 「完全に理解した」
- 製品を利用をするためのチュートリアルを完了できたという意味。
- 「なにもわからない」
- 製品が本質的に抱える問題に直面するほど熟知が進んだという意味。
- 「チョットデキル」
- 同じ製品を自分でも1から作れるという意味。または開発者本人。
人手余りも人材不足
6年前のアニバーサリー記事において、「今後技術者余りが発生するだろう」という予測を示したところ、コメントにて nsdt 氏より「それでも頭数を揃える必要が生じるので供給は不足するのではないか」という指摘がありました。
こうした見方はプログラマやシステムエンジニアを含めた技術者や、実際の開発を担当する業者のレベルではある程度の危機感をもって共有されているものの、発注者の側にはなかなか広がらず、新聞などで時折報じられる所謂「動かないコンピュータ」問題の温床となっています。 空前の技術者不足と取り沙汰される「2015年問題」の只中にあっても、未だIT技術者は頭数幾らで取引され、その単価も上がる気配はなし。 エンジニアを雇用して技術を育てるという発想を持たないメーカが殆どという現在のIT業界が、今後確実に到来する「技術者余り」によってどうなるのかについて、明るい見通しはまったくありません。
nsdt 氏コメント
[2015/07/01 12:35] 人が減っていって機械に仕事させようとするほど、名目的技術者でさえ、足りなくなるのではないかな。
[2015/07/13 18:22] しかし、頭数をそろえる、という指示がどこからか出るのではないかな。意志に反して。そして、人の数自体が減っている。
これらの予想のどちらかが正しかったのかを現時点から振り返ると、少なくとも私の見聞きする範囲においては「両方とも当たっていた」というか、
という、禅の公案のような状況となっています。
例えば、先月防衛省が運用を開始したワクチン予約システムにSQLインジェクションができてしまうのではないか、といった問題が取り沙汰されたのは記憶に新しいところでしょう。
防衛省が5月17日に始めた、大規模接種センターの新型コロナワクチン接種予約システム。 Twitter では「架空の番号で予約できる」「接種期間外でも予約できる」など、仕様にさまざまな問題が指摘された。 その中には「SQLインジェクション」という手法を使い、システムが使っているデータベースに不正アクセスできてしまう可能性がある、という指摘もあった。
SQLインジェクションとは、システムが想定しない「SQL文」を何らかの方法で実行させ、利用しているデータベースを不正に操作する手法を指す。 SQL文は、データベースを操作するための命令文だ。
私自身の経験でも、改修業務で渡されたソースコード中に
という、何の対策もなされていないため任意のSQLを実行できてしまうというセキュリティ上の「穴」......と呼ぶにはあまりにも大きく、もはや「門」と呼びたくなるような欠陥を見たのは一度や二度のことではありません。 SQLインジェクション脆弱性は簡単に作り込まれてしまう一方で、攻撃に利用されたならばシステムが停止するだけではなく、機密・個人情報の流出などによって、運営企業の存続をも脅かす重大なセキュリティリスク。 先に引用したワクチン予約システムの記事において、解説者の徳丸浩氏は
急な話だったので、スピードを優先してシンプルなシステムを作ったとみられる。 そもそも現状は緊急事態なので開発に何カ月も掛けるのはナンセンス。 他人の情報が見えるといった話が出ている訳ではないので、確かに "イケてない" ところもあるが、国民の利益につながる判断をしたのでは
と、十分な工期を確保できなかった開発元の事情を斟酌されていますが、これはかなり無理のある擁護でしょう。 というのも、SQLインジェクション対策というのは、SQLを扱う (≒ データベースを使用する) のであれば、どんなシステムであっても最低限実施されるべき基本的かつ重要な作業だからです。 少なくとも新規に開発されるシステムでは「何カ月も掛ける」ような工程ではありえません。 緊急の開発だからSQLインジェクション対策を省略したというのは、飲食店のサービスで例えるならば、
というようなもので、「論外」と言えるレベルの申し開き。 WEBシステム開発に携わるプログラマであれば「手クセとして無意識のうちに行ってしまう」「やらないと不安で落ち着かなくなる」タイプの作業であり、その工程が脱落しても気付かない・気にしないというのであれば、プロフェッショナルとして金銭を対価とする仕事をしていいレベルに達していないと個人的には思っています。
しかし、今やそのレベルの労働者が業界構成の中心帯となっているのがこの業界の現実。 独立してから間もない頃は「こうした人材不足というのは地方特有の悩みであり、東京などの都市圏であれば十分なスキルを有するIT技術者が数多居て、その調達に困るようなことはないのだろう」と考えていました。 しかし、個人事業主である私が携わってきたような知名度のそれほど高くないシステムのみならず、「防衛省提供のワクチン予約システム」という政策レベルのシステムを開発する現場においても、SQLインジェクション対策程度のごく初歩的な知識・技術を持つIT労働者を確保できていないという現実を目の当たりにすると、それが根拠のない楽観であったことを思い知らされます。
私が直接間接に見聞きする範囲では、どの開発現場にもシステムエンジニアあるいはプログラマといった肩書を持つ「IT技術者」を頭数だけは十分に、個人的には「この規模のプロジェクトにこんなに必要か?」と思ってしまうほどに抱えています。 世の中には頭数を揃えてゴリ押しすればなんとかなる問題は数多くありますが、残念なことにソフトウェア開発はそのようなジャンルではありません。 手術を行える外科医がいなければ重傷者を救うことができず、トラックを運転できるドライバがいなければ大量の物資を遠方の都市へ輸送することができないように、十分なスキルを持たない人員、つまりは素人を何人集めたところで、まともに動くシステムは出来上がらないのです。
素人が席巻する開発現場
一昨年7月に発生した「セブン・ペイ事件」を皮切りに、厚生労働省提供の新型コロナウイルス接触確認アプリ、そして前節で挙げた防衛相提供のワクチン予約システムなど、大企業や政府組織の重要プロジェクトとして開発されたシステムが、その存在意義を根底から疑問視させるような深刻な不具合を露呈する事例が次々と報じられました。
セブン・ペイ側は、7月4日の緊急記者会見で「事前にセキュリティー審査を繰り返し、脆弱性は指摘されなかった」と説明していたが、この時点で「7iD」に2段階認証やパスワード変更の通知機能が導入されていないことなど、認証システムに問題があると指摘されており、記者から2段階認証に関する質問を受けた際にも、それに社長は答えられなかった。 また、経済産業省も一般社団法人キャッシュレス推進協議会が策定した『不正利用防止のためのガイドライン』が守られていなかったことを指摘した。
その後の調査で「7iD」が、外部IDでログインしている他人のアカウントにパスワードなしでログインして、なりすますことができたことが明らかになった。 OpenID Connect などの認証連携プロトコルで定めている、なりすましを防ぐためのチェック手順が実装されていなかったと推察されている。 また「7iD」にログインした後に認証システムから取得できるユーザーデータの設計にも問題があり、ハッシュ化されたパスワードを含む広範な個人データを取得できたという。
セブン&アイ・ホールディングスは8月1日、今回のトラブルの原因について「7payに関わるシステム上の認証レベルの問題」「7payの開発体制の問題」「7payにおけるシステムリスク管理体制の問題」とした上で、「現在の7payのサービススキームに基づきサービス提供を継続することは困難である」として、9月30日24時を以て7payのサービスを廃止すると発表した。
厚生労働省の調査チームによる報告書が16日公表され、不具合が見逃された原因について、去年6月に運用を始めた時点で動作確認のテストを行う環境が整備されず、10月に環境が整ってからも優先的な課題とせずにテストを実施していなかったなどと指摘しました。
その背景として、アプリの開発や運用に関する厚生労働省の職員の知識や経験が乏しく、専門的な判断ができる人材が不足していたうえ、頻発する別の不具合の対応や改修に追われ、適切に管理できない状態に陥っていたことなどを挙げています。
また、技術者などが意見を交わすサイトで、問題が発覚する前から不具合の可能性が指摘されていたことについては、サイト上の意見を管理するよう去年9月ごろに委託業者に依頼していたものの、業務の流れや分担があいまいで、具体的な対応が検討されていなかったと指摘しました。
中小あるいは零細組織とは異なり、これらの組織が重要システムの開発に、工期はともかく、十分な予算を充てられなかったというのは少々考えにくいところ。 故にこれらの事例からは、
という、単なる資金不足よりも一層深刻な経済および産業の衰退の兆候が見えています。
一体何がその衰退を招いたのかと考えるとき、直接の関係があるかは定かではありませんが、個人的には開発現場における「ガチ勢」、即ち、三度の飯よりプログラミングが好きという技術オタクの存在比の減少が気になっていました。 自分自身を含め、私の親兄弟や友人、あるいは所属する組合の技術者たちは概ね「好きなこと」を仕事にしているため、普段あまり意識することがなく、ともすれば忘れがちなのですが、
という現実があります。 苦痛・我慢と引き換えに金銭を得て、それを消費することで自らと家族の生活を支え、そして、そこにこそ楽しさや喜びを見出すのが、ある意味で「普通」ということ。 趣味をそのまま仕事にできている私などは、相当に例外的で幸運なケースだと言えるのかもしれません。
しかしそれでも、数学者になるのが数学大好き人間だけであるが如く、コンピュータプログラミングという、日常生活とはあまり接点のない知識・技術を習得し、特段華やかでもなく、精神的なストレスの多い職業をわざわざ選んで就くというのは、多かれ少なかれ、それが好きだからこそできること......だと思っていたのですが、それももはや昔の話。 ここ10年で就職した世代が生まれた頃から続き、彼らにとってはそれが世界の常態として認識されているであろう不況と、これまた途切れることなく続いている情報システムの需要の増加により、少なくない数の人々は例えそれが好きでも得意でなくとも、IT産業に従事して糊口をしのぐことを余儀なくされています。 となれば、
という、「職業 (としてのみの) プログラマ」が開発現場の大部分を占めるようになるのは必然の流れ。 それ自体は悪いことでも何でもない「普通」のことで、プライベートな時間でスキルの習得をしないからという理由で彼らを責めるのはお門違いです。
その一方で、職域における技量あるいは生産性について考えると、「好きこそものの上手なれ」の諺が示すようにプライベートな時間で知識・技術の習得をしているプログラマと、そうでないプログラマの間には歴然とした差が生じるのもまた事実。 同じ「実務経験5年」であっても、「プログラミング」という作業に頭を働かせ手を動かしてきた時間には、控えめに見積もっても1.4倍 (週5日に対して週7日)、実際にはおそらく2倍以上の開きがあるわけで、それらを「同質の労働力」と見なすのは現実との乖離著しい行いと言えるでしょう。
とあるシステムの開発業務において、ウェブサーバ上で稼働するメインのプログラムとは別に、バックエンドエンドで動作し、連携するサーバから定期的にデータ取得を取得してくるためのプログラムが必要となったことがありました。 ところが、私よりも実務歴の長い人員4～5人を含め、その場にいる誰にもソケットを使って直接TCPを叩くプログラムを書いた経験がないことが判明。 協議の結果、現場入りして間もない (1ヶ月も経っていない) 私が、本来割り当てられていた作業を一時中断してその作成を担当することになりました。 もう6年ほど前のことですが、今でも時折思い返しては「もし自分が入っていなかったら、彼らはどのように対処したのだろうか」と想像を巡らせています。
確かに、ウェブシステム開発の作業の大部分は「ブラウザから要求を受け取り」「データベースをゴニョゴニョして」「その結果をHTMLとして投げ返す」プログラムの作成です。 しかし、開発チームが「本当にそれしかできない人員」だけで占められるようになると、このような些細な追加タスクによって工程全体が大幅に遅延し、場合によってはプロジェクトそのものが頓挫することにもなりかねません。 そのようにして破綻したプロジェクトの噂は、私のごく狭小な情報網にも定期的に入ってきます。 観測範囲を日本全国にまで広げたならば、おそらくは累々たる屍の山が見えることでしょう。
末端労働者の重要性
これまでに仕事をさせて頂いた現場でも、上流工程の担当者や管理職、あるいは経営者の方から、
といった言葉を聞くことがしばしばありました。 そのうちの半数くらいは「だから君もいつまでも手を動かしてコードを書く低い仕事なんかしていないで、より高いポジションを目指したまえ」というような激励の意図を込めてのものだったようですが、プログラミングという職能に誇りを持っている自分としては、あまり愉快な心持ちで聞くことのできる言葉ではありません。
確かに、2ヶ月も勉強すればちょっとしたプログラムを書けるようにはなるでしょうし、派遣業やSESの広がりによってプログラマの供給は常時過多といった状況にあるようです。 しかしながら、前節まででも述べた通り、「プログラムが書ける」と「(まともに稼働する) システムを組み立てられる」の間には、「日本語で文章が書ける」と「日本語で小説 (あるいは論文) を書き上げられる」ほどの隔たりがあります。
さらに見過ごせないのは、上述のように他人の仕事を「誰でもできる」と評して憚らない人たちの背後には
という意識が透けて見えることです。 近年は官民問わず、大学のような教育機関ですら、学生を中心とした若年層にやたらと「起業」を促す傾向があるように思われます。 会社を起こして自らが理想とする製品作りやサービスの提供を目指すのであれば大いに奨励されるべきことかもしれませんが、「起業すること」そのもの (もっと言えば、その資産価値を高めて売却すること) が目的化しているケースが散見され、連続起業家などという肩書で活動する手合いが注目と称賛を集める昨今の状況は、産業振興にとってマイナスでしかないだろうと個人的には考えるところ。 会社員や公務員といった労働者として生きることを陰に陽に「つまらないもの」と見下し、その対極に位置付けられる「起業」ないし「経営」こそが「意味のある」あるいは「夢のある」生き方であるかのように語ることで若者を煽り立てる向きについては、
と感じています。 そして、当座の生活のため仕方なく働く人員のみで構成された会社の事業がどうなるかはこれまでに見てきた通り。 畑を耕し、牛を追い、鉄を打つ民の上にあって領主が領主たりえたように、あるいは、十分な数の兵卒が揃ってはじめて将校が将校としての役目を果たすことができるように、システムを設計し、サーバを建て、プログラムを書き、インフラを維持する労働者がいてこそ、IT企業はIT企業として存在できるのです。
現場の意欲と技術の向上という課題は一朝一夕に解決を図れるものではありませんが、個人的には、現場に2割ほどの「ガチ勢」を配置することができればで、スキルとマンパワーのバランスが取れ、そこそこに品質・能率の高いシステム開発が実現できるのではないかと考えています。 その程度のささやかな改善すらも、現状からは考えるだに困難なことではあるのですが......。
コメント