突然ですが、皆さんは「人月の神話(第一版では“ソフトウェア開発の神話”)」という書籍をご存知でしょうか？
これは今から41年前の1975年、フレデリック・ブルックスという著者により発刊された“ソフトウェア工学とソフトウェア開発管理”について書かれたものです。
この書籍は41年も経過した現在でも、多くのソフトウェアエンジニアやプログラマに愛されています。
時代を超えてここまで売れている技術書は類を見ず、しばしば「怪物本」と例えられることもあります。
そしてこの書籍が未だに売れている理由の一つは、41年経過した現在においても“ソフトウェア工学とソフトウェア開発管理”の本質があまり変化していないからです。
ビッグデータ、IoT、クラウドといったキーワードが「アツイ！」と言われている現代ではテクノロジーが飛躍的に進歩したと言われています。
しかし実際に進歩したのはハードウェアの性能や技術であり、ソフトウェア開発管理に関しては未だ“時間が止まったまま”なのです。
今回はこのフレデリック・ブルックス著である「人月の神話」をもとに、ソフトウェア開発管理について話を進めたいと思います。
フレデリック・ブルックスという人物について
フレデリック・ブルックスの生い立ちはさておき、彼がソフトウェアエンジニアとして著名である理由は今回の題材である「人月の神話」だけではありません。
実は、世界初のメインフレーム向け商用オペレーティングシステムとなったIBM OS/360。この大規模な開発のプロジェクトマネージャーを任されていたのが、他ならぬフレデリック・ブルックスその人です。
「人月の神話」は当時の開発経験から得た失敗などに基づき執筆されており、「ブルックスの法則」と呼ばれる法則を生み出しています。
また、「銀の弾などない」という論文も非常に有名です。
“銀で作られた銃弾は狼人間や悪魔を倒す”という西洋の信仰にちなんで、「ソフトウェアエンジニアの生産性を劇的に向上させるものはない」という皮肉なの言葉でもあります。
ベテランエンジニアが開発管理に苦悩する若手エンジニアに向かって「銀の弾などないんだよ」というセリフを吐くシーンを今でもしばしば見かけることができます。
ソフトウェア開発管理が難しい4つの理由
「人月の神話」では、「ソフトウェア開発管理がなぜ難しいのか？」というテーマに対し、4つの理由を提示しています。
1.プログラムは規模が膨大
「1人分の料理を作れ」と言われれば、食材を適当に切り煮るなり焼くなりして、ちょっと味付けをすれば簡単にでき上がります。
しかし「1,000人分の料理を作れ」と言われたら話はまったく別です。
1,000人分の料理を作るためには、それに伴った人員も設備も必要です。1人では到底不可能でしょう。
これに加えて「全ての料理を同時に出せ」と言われたら、その大変さが何倍にも膨れ上がります。
単純に作るだけでなく、食品の鮮度を保つため効率的かつ短時間で作ることができるロジックを組み立てなければなりません。
また、そもそも1,000人分の料理を同時に作れるような調理器具は存在しません。
この料理の例のように、プログラムとは基本的に超大規模であり、それが故に開発管理を複雑にしている部分が多く存在します。
ちなみにフレデリック・ブルックスがプロジェクトマネージャーを務めたIBM OS/360の開発は、5,000人年という人類史上類を見ない規模でした。
2.プログラムは変更が簡単
日曜の昼下がりに父親がDIYでキャビネットを作っていました。
しかし、「いざ完成！」というときになって設計が間違っていたことに気づき、採寸ミスで所定の場所に入らない。
なんてことにならないためにも、設計段階から十分に注意を払って進めていくのが基本かと思います。
なぜなら、「ものづくり」における設計のミスはかなり致命的であり、後戻りしてやり直すということが基本的にはできないからです。
一方プログラムは非常に簡単に変更がききます。
作り上げたプログラムを削除するのもクリック一つ。数秒あればまるで始めからなかったかのように消えてしまいます。
このようにプログラムは変更の自由度が非常に高いため、慎重な設計ができてないケースも多いのです。
故にトラブルが発生しやすく、開発管理に遅延を招きます。
3.プログラムは可視化できない
ソフトウェアプログラムとは論理的なものであり、建築物などと違って目に見えるモノではありません。
住宅を建築するのであれば、外観や内部構造を確認しつつ造っていくことができます。
しかしプログラムは可視化することができないため、外観はもとより内部がどんな構造をしているかを確認しながら作り上げていくことができず、ドキュメントから構造を推察するしかないのです。
プログラムも一種の「ものづくり」なので、可視化できないということは大きなハンディキャップでもあります。
4.プログラムには制約がない
自然界には必ず何かしらの“法則”が存在します。
例えば物理的な話をするのなら、原材料の体積量を超えるモノを作り出すことはできません。
1万本分の木材からは、木材1万本分の建築物しかできないということです。
これは一種の“制約”でもあるのですが、プログラムにはこの“制約”と呼べるものが存在しません。
これが非常に厄介なものであり、数十年間ソフトウェア開発管理が進化していない最大の原因でもあります。
例えば複数人に対し「何でもいいのでモノを作ってください」と言えば、1人は椅子を作ったり1人は機械を作ったりなど、様々なプロセスで様々なモノを作るでしょう。
これはいわゆる“制約”がないという無秩序な状態なので、「作り方」や「作るモノ」が常にバラバラです。
これをビジネスに置きかえるならば、明らかに非効率的ですね。
そこで「この設計図通りにテーブルを作ってください」と言ってみてはどうでしょう。
「作り方」と「作るモノ」も指定されたという“制約”はありますが、とたんに秩序が生まれます。
これなら高い生産性を維持しつつ、技術を発展させていくことできますね。
このようにプログラムには“制約”がないが故に、ソフトウェア開発管理は進化が難しい領域なのです。
遅延回復のために人員を投下すると、さらに遅れる
ここで有名な「ブルックスの法則」の一つを紹介します。
もしもソフトウェア開発管理で遅延が発生していたら、皆さんは遅れを取り戻すためにどんな対策を取りますか？
おそらくほとんどの方が「新たに人員を投下して工数を削減する」と考えると思います。
しかし「ブルックスの法則」では考え方がまったくの逆であり、新たに人員を投下するとさらに遅延が発生すると示しているのです。
この原因として、以下の3つが挙げられます。
- 人員の再配置
- 新要員の教育
- コミュニケーションパスの増加
新たに人員を投下すると、まずは人員を再配置しなければなりません。
次に新要員の教育を行わなければならないので、これもタイムロスの原因となります。
そして人員が増えれば増えるほど、コミュニケーションパスは増加します。
例えば人員が3人しか存在しない場合ならコミュニケーションパスは3本で済みます。
しかし10人なら、[10×(10-1)÷2＝45]で15倍ものコミュニケーションパスが生まれるのです。
このように、一見効果的な人員増加も実はさらなる遅延を招く原因だったのです。
ちなみに遅延を回復するためにフレデリック・ブルックスは「スケジュールを立て直す」「開発規模を縮小する」といった方法を提示しています。
ソフトウェア開発管理の“質”を高めるためには
これまでのことを踏まえて「本当にソフトウェア開発管理に銀の弾はないのか？」、「ソフトウェア開発管理の“質”を高める方法はないのか？」について考えます。
まず、近年話題になっている“超高速開発ツール”ですが、これはソフトウェアエンジニアの利便性を高めても「銀の弾にはなり得ない」という見解が多くあります。
しかし言い換えるならば「まだ完全な銀の弾ではない」といのが正しい気がします。
なぜなら、超高速開発ツールの活用により「開発期間が従来の1/10まで削減した」や「プログラムの属人化を防止することで業務効率が劇的に上がった」といった事例が実際にあるからです。
そしてこの超高速開発ツールは常に進化し続けており、インテリジェント・モデルが提供する大規模バッチシステム「ODIP(オーディップ)」もその一つとなります。
「ODIP」では10人月分の作業を数分で完了するという実績があり、ソフトウェア開発管理における様々な課題を解決するための革新的ソリューションです。
超高速開発ツールの登場と進化により41年間変化のなかったソフトウェア開発管理が今、変化の時を迎えていると言ってもいいでしょう。
まとめ
いかがでしょうか？まだ「人月の神話」を読んだことがない方にとっては「ブルックスの法則」が目から鱗ですよね。
また、人によっては実際の現場において肌で感じているという方もいらっしゃると思います。
「人月の神話」は現在も変わらないソフトウェア開発管理の概念などを俯瞰して紹介しているので、機会があれば一読してみてはいかがでしょうか。
また、最後に紹介した超高速開発ツールとはプログラムの自動生成やGUIベースの操作によってソフトウェア開発を行うためのものです。
「導入すればどんな企業でも開発期間を削減できる」といものではないので、この点をしっかりと認識して頂きたいと思います。
しかし、先に紹介した導入効果を実感している企業が存在するのは事実であり、大切なのは「超高速開発ツールで如何に開発期間削減やコスト削減に繋げるか？」という点です。
超高速開発ツールに関する基本情報や、導入のポイントなどはこちらで解説しているので是非参考にしてみてください。
