如何なる開発手法、プログラム言語を用いても、日本の全てのソフトウェアプロジェクトは必ず技術的負債になる
「日本の全てのソフトウェアプロジェクトは必ず技術的負債になる」というタイトルですが、 次の条件を満す場合に限ります。
「プロジェクトに関わるソフトウェアエンジニアの大半が技術に無関心」
動機
このネタは、次の記事を読んで個人的に思うことがあったのをきっかけに 書いています。
- オブジェクト指向プログラミング – 1兆ドル規模の大失敗
- 大企業の技術系インターンシップに参加した
- ソフト開発で世界と闘った及川卓也氏が見た、日本の弱点と可能性
上記の記事は各自に読んでもらうとして、 それぞれの記事の内容をものすごく大雑把にまとめると
- 「OOP はダメだから、関数型プログラミングを使え」
- 「日本を代表する大企業に実情に失望した」
- 「日本の企業はソフトウェア開発を理解していない」
になると思います。
プログラミング言語は道具にすぎない
上記ブログで「OOP はダメだから、関数型プログラミングを使え」と書かれています。 私は、OOP が万能だなんて思ってませんし、 上記ブログで指摘されている側面があることも理解しています。
ですが、オブジェクト指向プログラミングにしろ関数型プログラミングにしろ、 万能ではないという意味ではどちらも同じです。
プログラム言語は道具です。 いかなる道具であっても、 その道具を安全に運用できるかどうかは、最終的には使う人に依存することになります。
例えば、古典的なプログラミング言語の代表格に C 言語がありますが、 ご存知の通り C 言語には GC もないですし、 NULL 安全でもありません。 そのような高度な「安全」機能を持たない C 言語は、Linux Kernel の開発言語です。 C 言語によって Linux Kernel を開発しているという事実は、 高度な「安全」機能が搭載されていないプログラミング言語であっても、 使用する人次第で大規模プロジェクトでも問題なく運用できるという一つの実証と言えます。
逆に、C 言語よりも高度な「安全」機能を搭載しているプログラミング言語を使用した プロジェクトが技術的負債の塊になり運用困難になった、 という例はいくらでも身近にあると思います。 もし身近に無いとしても、ネットで検索すれば多数ヒットします。
だからと言って、 C 言語の様に使用する人への依存が高過ぎる言語と、 Rust のように先進的な安全機能搭載言語のどちらを使っても大差はない、 というつもりはありません。 私が言いたいのは、「より安全」と言われる技術を使っても、 それを使用する人への依存性が無くなることはない、ということです。
自動運転に例えると、 プログラム言語自体が提供する「安全」は高々レベル 3 のサポートにすぎません。
レベル 3 の自動運転には、ドライバーの運転技術が必須であるように、 現存するどのようなプログラム言語であっても、 ソフトウェアエンジニアの能力が欠かせません。
「ソフトウェアエンジニアの大半が技術に無関心」であることの問題
なぜ「プロジェクトに関わるソフトウェアエンジニアの大半が技術に無関心」だとダメなのか？
これは単純に、そのようなプロジェクトではどのように「安全」な環境であっても、 その「安全」がレベル 5 の自動運転のように「完全」でない限り、 「不具合をエンジニア自ら作り込んでしまう」からです。
前述している通り、プログラミング言語はあくまでも道具であって、 その道具を安全に運用できるかどうかは、最終的には使う人に依存することになります。 そしてプログラミング言語を使う人はソフトウェアエンジニアであり、 ソフトウェアエンジニアの能力は、多くの場合、技術への関心度に比例します。
特に統計を取った訳ではなく、裏付け資料がある訳でもないですが、 個人的な経験上、技術への関心度が高いソフトウェアエンジニアほど能力が高く、 技術への関心度が低いソフトウェアエンジニアほど能力が低い傾向にあります。
つまり、 「プロジェクトに関わるソフトウェアエンジニアの大半が技術に無関心」であるということは、 ソフトウェアエンジニアの大半の能力が低いということと、ほぼ同義になります。
「技術への関心度が低いソフトウェアエンジニアほど能力が低い傾向にある」という持論の 根拠となるエピソードを一つ挙げておきます。
あるソフトウェアエンジニアＡがモジュールの設計をしていました。
そのモジュールは、他モジュールとの依存が高いことが問題になっていたので、 「DI(Dependency injection)の手法を取り入れたら もっとスッキリした設計になる可能性があるので検討してみてはどうですか？」 と、そのソフトウェアエンジニアＡに話をすると、 「そういう難しいことは逆に不具合につながるのでやりたくない」と 言われて一蹴されました。 DI を検討した結果、従来通りの方法を採用する方が良いという結論になったのであれば 納得できますが、なんとなく難しそうというイメージだけで拒否していました。 そして、そのモジュールは依存が高いまま実装されました。
DI のことを理解していれば、それが難しいと考える人はほとんどいないでしょうし、 テストがしやすいことから、むしろ不具合も低減できる可能性があり、 DI を取り入れることで不具合に繋がることを心配する人はいないでしょう。
このように、技術への関心度が低いと、 自分が知らない技術を積極的に取り入れるようなことをせず、 自分が使える技術だけで解決しようとします。 これによって、よりスマートに実現できる方法が他にあるにもかかわらず、 潜在的な問題を含む古い方法によってモジュールが作られていき、 それが積み重なってプロジェクト全体の品質が下っていきます。 そしてそれは時間が経過するほど、手をつけられない技術的負債になります。
一言で表現すれば、技術への関心度が低いエンジニアは「技術的負債製造機」です。
例え TEST FIRST の開発プロセスであっても、それは防げないでしょう。 ならぜなら、 テストというのは作成した成果物が仕様通りに出来ていることを確認するものであって、 仕様そのものに不具合があった場合は、その不具合を検知することは出来ないからです。 仕様を作るのはソフトウェアエンジニアです。 能力の低いソフトウェアエンジニアほど、穴の多い仕様を作る傾向にあります。
能力の低いソフトウェアエンジニアには仕様を作らせず、 能力の高いソフトウェアエンジニアだけで仕様を作れば良い、という考えもあると思います。
確かに、能力の高い人の比率が高い場合はそういう運用が可能かもしれません。 しかし、ここでは大半が能力が低いことを前提にしているので、 そのような運用は難しいです。
また、例え仕様に問題がなくても、 実際にコード化した時に不具合が埋め込まれることは良くあります。 そして、テストで検出されることもなくリリースされ、市場で時限爆弾のように爆発する、 お決まりのパターンです。もはや伝統芸能の域です。
なぜ日本で問題なのか？
ここまでの話を納得していただけたとして、次の疑問が浮ぶかもしれません。
「プロジェクトに関わるソフトウェアエンジニアの大半が技術に無関心」が 技術的負債を生み出す原因ならば、日本でなくても同じことが言えるのではないか？
それは確かにそうです。 しかし、日本の場合、終身雇用 & 転職しずらい社会環境によって、 一度雇ったソフトウェアエンジニアが技術に無関心だったとしても、 そのソフトウェアエンジニアを他の優秀なソフトウェアエンジニアに入れ替える、 ということが非常に困難なため、このような状況になり易いです。
さらに、日本ではソフトウェア開発をゼネコン方式で開発するという文化があり、 一つのプロジェクトを社内の優秀なソフトウェアエンジニアだけで開発する、 というのは非常に稀なケースであり、 一部(あるいは全部)のモジュールをアウトソーシングするケースが多くあります。
これによって、プロジェクトの品質コントロールをより困難にしています。
また、日本では全ての社員の待遇に差を付けず、 等しくすることを善しとする文化があるようで、 ソフトウェアエンジニアの能力に応じた待遇にする、というようなことを滅多にしません。 一方で、マネジメント能力に関しては、 能力に応じた待遇にするキャリアパスが古くから存在するため、 自分ではコードを一切書かないで一日中パワーポイントやエクセルの資料をせっせと作成している ソフトウェアエンジニア(？)が多く存在します。 そして、マネジメント能力以外のソフトウェアエンジニアの能力が評価対象ではないため、 自然と「プロジェクトに関わるソフトウェアエンジニアの大半が技術に無関心」と いう状況になる傾向にあります。 いわゆる Japanese Traditional Big Company では、 特にこの傾向が顕著なのではないでしょうか？
最初に紹介したブログの著者が「日本を代表する大企業に実情に失望した」原因は、 このような背景があるためだと思います。
また、このような背景を作り出しているのは、 Yahoo の記事にある「日本の企業はソフトウェア開発を理解していない」ためだと思います。
以上のように、日本のソフトウェア開発プロジェクトには 技術的負債を生み出す環境が整っているため、 いかなる開発手法、プログラム言語を用いても技術的負債化を防ぐことは出来ません。
それなのに、この状況を改善する為と称して、新しいプロジェクト進捗管理手法を導入する、 という斜め上な施策が実施されることがあります。
どういう論理で考えると、「新しいプロジェクト進捗管理手法を導入すること」と、 「プロジェクトの技術的負債化を防ぐこと」が繋がるのでしょうかね？
最後に
私は LuneScript という言語を開発しています。 「プログラム言語は単なる道具でしかない」というのは、 ある意味自己否定しているようにも思われるかもしれません。
ですが、プログラム言語自体で提供できる安全機能は まだまだ残っていると思っているので、 ソフトウェアエンジニアの助けになるような安全機能を提供できるように 今後も開発を続けていきたいと考えています。
以上。