ソフトウェア開発やプロジェクト管理が進歩しない理由：山浦恒央の“くみこみ”な話（5）

　前回のコラムでは、IBMのフレデリック・ブルックスが1975年に書いた『ソフトウェア開発の神話（第2版から「人月の神話」）』を取り上げました。そして、ブルックスが同書を執筆するに至った背景や、同書の中で述べられている有名な“ブルックスの法則”を紹介しました。

　ソフトウェア開発の課題や法則について書かれたこの本が「怪物本」と呼ばれるのは、30年以上前というソフトウェア史上から見ると“石器時代”ともいうべき大昔に出版されたにもかかわらず、いまでも快調に売れ続けているからです。裏を返せば、ソフトウェアの開発技術や、プロジェクト管理が30年前からほとんど進歩していない証拠でもあります。もちろん、組み込み系ソフトウェアの開発技術も同様です。

　「ソフトウェア開発やプロジェクト管理がなぜ、こんなに難しいのか？」「なぜ、進歩しないのか？」。ブルックスは、次の4つの理由を挙げています。

1. プログラムは、規模が非常に大きい
2. ソフトウェアは、目に見えない
3. プログラムは、簡単に変更できる
4. 制約となる自然界の法則がなく、自由に作れる

　この4つをじっくりと考えてみると、組み込みソフトウェア開発が抱える根本的な課題も見えてきます。これらの理由も、ある意味ブルックスの法則といえます。

（1）プログラムは、規模が非常に大きい

　ブルックスが真っ先に挙げている理由が「大きさ」です。なんでもいいから1人が乗れる舟を造れといわれたら、材木を適当に買ってきてロープで縛るだけで完成です。流体力学も船舶工学も必要ありません。しかし、1000人乗りの大型客船を建造するとなると話はまったく違ってきます。世界最高峰の技術力、設計のセンス、製造実績が不可欠です。直径10センチの竹トンボは10分で作れますが、直径100メートルのローターを持ったヘリコプターは製造不可能でしょう……。

　また、日本の古典文学ファンであればご存じだと思いますが、今年は『源氏物語』の千年紀に当たるといわれ、テレビや雑誌では、瀬戸内寂聴、田辺聖子、大和和紀らを登場させて、いろいろな特集を組んでいます。世界初の長編恋愛小説といわれる源氏物語は、400字詰め原稿用紙に換算すると、およそ2000枚もの大作です。1行が20文字とすると、4万行になります。最近の携帯電話は、不必要、かつ、複雑怪奇な機能を雑多に詰め込んでいるため、かまぼこ板ほどの本体に1000万行を超えるプログラムを組み込んでいます。源氏物語の250倍のすさまじい量です。小説では、ページ数が2倍になると、ストーリーの複雑さは4倍になるといわれていますので、携帯電話には、源氏物語の6万2500倍も入り組んだストーリーが詰まっていることになります。

　どんな分野でも、量が大きくなると、作り方は急激に難しくなります。フレンチのシェフによると、一番厳しいのが大規模な結婚式のように同じ食事を同じタイミングで大量に出すことだそうです。いかに厨房が大きくても、200人分の肉を一度に焼くスペースもガス・レンジもフライパンもありません。この不可能を可能にするのが超一流シェフの腕だそうです。5000人年を投入したOS/360のプロジェクト・マネージャーだったフレデリック・ブルックスは、シェフとして大成したかもしれませんね。

（2）ソフトウェアは、目に見えない

　当たり前ですが、プログラムは目に見えません。手でも触れられませんし、大きさや重さを感じることもできません。

　ソフトウェアが目に見えないことによる弊害の一つが、“開発の難しさや複雑さを実感できないこと”にあります。100億円掛けて建築した高層ビルは、手で触れることができ、目で見えるため、100億円の威力を目の当たりにできます。その圧倒的な光景を見れば、作るのはさぞ大変だったろうと容易に推察できますし、完成した建造物を見れば、発注側も満足するでしょう。しかし、100億円の開発費を注ぎ込んだプログラムをCD-ROMに入れて、発注側の社長に「納入いたします」と手渡してもありがたがってもらえません……。

　目に見えないことで困るもう一つの弊害は、“ソフトウェア・システムの全体像を簡単にはとらえられないこと”です。目で確かめながら作ることができません。プログラム構造も見えないため、プロジェクトで開発中のソフトウェアが、シンプルで整然とした構造をしているのか、スパゲッティのように乱れた構成になっているのかは、ドキュメントから推察するしかありません。この歯がゆさは、目隠しをして、手袋を3重に着けて、陶器の傷を探し出すようなものでしょう。

　目で見た美しさや簡潔さは、設計の良しあしを判断するうえで非常に重要な要素なのですが、ソフトウェアの場合はそんな判定ができません。目に見えないことは、ものすごく大きなハンディなのです。

（3）プログラムは、簡単に変更できる

　物理的な製品、特に、建築や土木関係の開発では、後で変更がないよう、細心の注意を払って作るのが普通です。例えば、建造物の耐震強度計算を間違えると、途中で作り直しとなり、巨額の解体費が掛かります。そんな事態にならないよう、着工時には何重にもチェックし、いろいろな方法で検証し、最終的な判断を下します。

　一方、ソフトウェアでは、変更はものすごく簡単でコストも時間もかかりません。完全に削除をする場合でも、数秒あれば可能です。このため、特に注意せずに自分がよいと思えば、軽い気持ちで簡単に実行できてしまいます。つまり、簡単に変更や削除できるが故に、大きな失敗をする可能性を秘めている「もろ刃の剣」といえます。

（4）制約となる自然界の法則がなく、自由に作れる

　「ニュートンの法則」「オームの法則」「ボイル・シャルルの法則」など、中学の理科や、高校の物理の授業では、「将来、なんの役に立つんだろう？」と思いながらも、いろいろな自然界の法則を勉強しました。500人をマッハ0.7で運ぶジャンボジェット機は、「ベルヌーイの法則」と「重力の法則」との差で空に浮き、見えない飛行物体、スティルス爆撃機は、レーダーが放つ電磁波の直進性を逆手に取っています。

　最先端の科学技術を駆使して作ったモノは、必ず、重力・磁力・電流などいろいろな自然界の法則に束縛されていますが、ただ1つの例外がソフトウェアです。ソフトウェアが動作するハードウェアは、あらゆる法則でがんじがらめになっていますが、ソフトウェアは四則演算など数学の定理に従うだけ。信じられないほど自由度が高いのです。

　法則に縛られず、自由に作れるのは、とてもよいことではないのかと考える人もいるでしょう。束縛が厳しくなるほど、開発側の考え方が同じになり、画一的な作り方になります。逆に、完全に自由に作ってよいとなると、決まった作り方や、設計上の定石が存在しないことになります。「どんな方法でも構いませんので、『悲しみ』を表してください」といわれた場合、絵画で表現したり、小説に書いたり、写真を撮ったり、音楽で表したり、芝居に仕立てたりといろいろな方法を取ることでしょう。これは、文字通り芸術の世界です。「開発プロセス」は存在しません。逆に、「自分が経験した『悲しい話』を400字で書いてください」と“縛り”を付けると、非常に書きやすくなります。

　このように、「自由過ぎるのは不自由」なのです。あらゆる法則からガチガチに縛られているハードウェアが革命的な進歩を遂げ、完全に自由なソフトウェアは、生産性が30年前から向上せず、生産技術にも大きな変化がないのは、これが大きな原因です。

　さて次回のコラムでは、今回紹介したソフトウェアの4つのハンディキャップを考慮しながら、さらに「ブルックスの法則」について紹介していきます。ご期待ください！ （次回に続く）