ソフトウェア開発で1本10万円のワインを造る方法：山浦恒央の“くみこみ”な話（6）

スーパー・プログラマの生産性は平均的プログラマの10倍もスゴいってホント!? ブルックスの法則をひもとき、その「真実」と「誤解」に迫る

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠IT MONOist]

　今回も前回「ソフトウェア開発やプロジェクト管理が進歩しない理由」に引き続き、ソフトウェア開発の永遠の古典“ブルックスの法則”を取り上げ、この法則が組み込み系ソフトウェア開発にも当てはまるのかどうかを、いろいろな角度から内容を検証していきたいと思います。

	関連リンク：
⇒	人月の神話 狼人間を撃つ銀の弾はない

法則1：プログラマ個人の生産性の差は10倍ある

　これは、ブルックスの法則の中でトップ3に入るほどの有名な法則です。ただし、非常に誤解が多い法則の1つでもあります。

　この法則を「なるほどスーパー・プログラマの生産性は平均的プログラマの10倍もスゴいのか」と解釈してしまうかもしれません。しかし、この“10倍”の差は「最優秀プログラマ」と「最悪プログラマ」を比べた結果です。実際、平均的プログラマと最優秀プログラマとを比較すると、2倍程度の差しか（2倍も!?）ありません。トム・デマルコ氏やハーラン・ミルズ氏の研究でも、この数値（最良 vs. 最悪の差は10倍、最良 vs. 平均は2倍）が裏付けられています。

　一方、これを給料の面で見てみると、最優秀プログラマの給料は多くても最悪や平均の20〜30％プラス程度だといわれています。このブルックスの法則からは、「要するにいいヤツを引っ張ってこられれば、高品質ソフトウェアを安く、早く開発できるのだ」であり、「なんのかんのいっても、最後は人かい……」と悲観的な気分にならざるを得ません。アメリカの高名な研究者、バリー・ベーム氏も「ソフトウェア開発では人的要素が圧倒的に重要」と述べています。

　3割余計に給料を支払えば、2人分働く（うまくすれば10人分！）プログラマを雇えるなら、誰でもそうするでしょうが、そんな優秀な人材はごく少数です。ですから、ソフトウェア工学の研究者たちは平均的なプログラマを対象に、「安い・うまい・早い」ソフトウェアを開発する方法論やツール、「開発レシピ本」を編み出そうと日々頑張っているのです（40年前から、あまり進化していませんが……）。

法則1の変形（1）：組織としての生産性の差も10倍ある

　これまた、非常に有名な法則です。トム・デマルコ氏の有名な「プログラミング・コンテスト」でも、会社による生産性の違いは11.1倍あったそうです。

　この法則を見て、「個人の生産性が10倍違うのなら、組織としての生産性も10倍違うのは当たり前だろう」と軽く読み流してしまいそうですが、個人と会社では性格がまったく違うことに注意してください。トップ・クラスのソフトウェア開発会社でも、その大部分は平均的なプログラマで、スーパー・プログラマはごく少数しかいません。生産性の高い会社は、そんな平均的な技術者を組織して「安い・うまい・早い」ソフトウェアを作る開発プロセス（というより、企業文化）を確立させているのです。

　この企業文化は決して特別なものではありません。「毎回同じ作り方をする」「機能や設計内容をきちんと文書化する」「バグは次の工程まで持ち込まない」など、ごく当たり前のことをサボらず強い意思で進められるかどうかです。これができるかできないかにより、高品質プログラムを早く安く開発できるプロ集団と、何カ月も遅れた揚げ句バグだらけのソフトウェアしか出せない会社に分かれるのです。

　ワインの世界に「ガレージ・ワイン」という1本数万円もする微量生産の高級ワインがあるのをご存じでしょうか。「金はないが、いいワインを造りたい」という熱い思いと夢を持った若い生産者が、ガレージのような狭い場所で貧弱な設備を使い、手作り感覚で作った高品質ワインのことです。「そんな生産者（通称、ガラジスト）は、きっと超一流シャトーに弟子入りして、特別な醸造技術を学んだに違いない！」と思うでしょう。しかし、実際には平凡なフツーの生産者の元で1、2年程度しか修業を積んでいません。

　では、どうして彼らは最高品質のワインを造ることができるのでしょうか？

　答えは超簡単で、「当たり前のことを当たり前に実施している」だけです。星の出ている早朝から畑へ出掛け、月が昇るまでブドウ樹の手入れをする。病気や発育不全の葉や実を丁寧に取り除き、除草剤に頼らず手で雑草をむしる。収穫もマシン・ハーベストではなく、完熟した果実を選んで手摘みし、ゆっくり発酵させる……。要は、「一生懸命に勉強すれば成績が上がる」をワイン造りで実行しているだけにすぎません。

　ソフトウェア開発もまったく同じです。時間がないときや、発注側から「何でもいいから早くプログラムを出してくれ」とせっつかれたときでも、途中の開発プロセスを省略せず、ソフトウェアをきちんと作る雰囲気、文化、歴史が社内にあるかどうか？ これがプロ意識を持った優秀な企業と、出荷日がくれば品質や機能漏れに関係なくリリースしてしまういいかげんな会社の分かれ目になります。

　トップ・クラスのソフトウェア開発会社の「平均的プログラマ」は、そんな社内風土に鍛え上げられて、生産性の高い「優秀なプログラマ」となり、1本10万円のワインを造ることができるのです。

法則1の変形（2）：生産性の高いプログラマは偏在する

　これは、優秀なプログラマは業界全体に満遍なくランダムにばらまかれているのではなく、一部の組織に偏って存在するという法則で、『ピープルウエア』で有名なトム・デマルコ氏の考察によるものです。デマルコ氏の有名な「プログラミング・コンテスト」でも“プログラマの偏在”が実証されています。

	関連リンク：
⇒	ピープルウエア 第2版 - ヤル気こそプロジェクト成功の鍵

　ソフトウェア業界には、「80％・20％ルール」という経験則があります。例えば、「80％のバグは、20％のモジュールに集中している」で、バグがあるモジュールは、たたけばたたくほどバグが見つかります。そんな「パンドラの箱」的モジュールをどう扱うか？ “バグが枯れるまでデバッグを続ける”のか、“もともとの構造や設計が悪いためバグだらけになったと考え、そんな低品質モジュールをだましだまし使うより、思い切って捨ててしまい、一から作り直す”のかは、プロジェクト・マネージャが悩むところでしょう。どちらにせよ“バグは偏在”します。

　また、ソフトウェアの機能量とモジュール数も「80％・20％ルール」に従うようです。システムの80％の機能は、20％のモジュールに支援されているというもので、組み込み系ソフトウェア開発に従事している方であれば誰しも感じていることでしょう。装飾的な機能、不必要なデバイスを制御する機能、エラー・ケースのエラー・ケースのエラー・ケースみたいな100万年に1回しか発生しない状況でもきちんと対処する“老婆心”モジュールなどを捨てることで、20％のモジュールで80％の基本機能を支援できることがあります。プロジェクトが遅延しているとき、まずはこの20％だけを作って切り抜けることも選択肢として考慮すべきでしょう。このように“機能も偏在”します。

　さらに、優秀なプログラマにも「80％・20％ルール」が当てはまるようです。生産性の高いプログラマの80％は、20％の（業界トップ・クラスの）会社に偏って存在している気がしてなりません。逆に、ソフトウェア開発企業としてプロ意識の極めて高い会社が、生産性の高いプログラマを作るのかもしれませんが、どちらにせよ、トム・デマルコ氏の考察どおり“優秀なプログラマは偏在”します。

法則1の変形（3）：最も生産性の高いプロジェクトは少数精鋭チームである

　この法則は、OS/360という人類最初で最後の超巨大プロジェクトをマネジメントしたフレデリック・ブルックス氏の「信念」でもあります。ただし、これも、非常に誤解を招きやすい法則の1つです。

　プロジェクトの人員が多くなると、プロジェクト運営が急激に複雑怪奇になります。機能を分割し、大人数で作業を分担すると、コミュニケーションの経路が増えるため、オーバーヘッドが爆発的に増加し、伝達ミスも増えて大混乱を起こす要因となります。毎食後、何十種類もの薬を飲むのと同じで、薬相互の副作用が心配です。

　大規模プロジェクトの大混乱で痛い目に遭ったブルックス氏は、「なるべく少人数でソフトウェアを開発する方がよい」といっています。極端な例は、「1人のプロジェクト」でしょう。1人なら、コミュニケーションのミス、オーバーヘッド、混乱はあり得ません。病的なまでにきちんと文書を作る必要もありません。この方法であれば、高品質のソフトウェアを効率よく、しかも安価に開発できる可能性が非常に高いといえます。しかし、この方法でネックとなるのが“開発期間”です。

　例えば、携帯電話向けのソフトウェアは年々大きくなる一方であり、100万ステップを超えるものも少なくありません。これをたった1人で担当して、10年で作ることができたとすると生産性は通常の10倍以上にもなり、生産性自体は超人的です。しかし、ボーナス商戦を逃すと販売台数が激減する携帯電話を10年もかけて悠長に開発する余裕はありません。ここに、ブルックス方式の「少数精鋭プロジェクト」のジレンマがあります。

　このブルックスの法則は、少数精鋭プロジェクトは生産性が高いといっているだけであり、早く開発できるという意味ではありません。特に、開発期間の短さが何よりも優先される組み込み系ソフトウェア開発では、「少数精鋭の生産性の高さ」が必ずしも「プロジェクトの開発期間の短さ」に結び付かないのがつらいところです。とはいえ、例えば「少数精鋭の生産性×期間」から作業総量を割り出し、それに適合した開発作業を割り振るなど、逆のアプローチを取ることで「小さなプロジェクト」の特性を生かす方法はありそうです。

　さて、次回も引き続き「ブルックスの法則」が組み込み系ソフトウェア開発にも当てはまるのかどうかを検証していきます。ご期待ください！ （次回に続く）

【 筆者紹介 】

山浦 恒央（やまうら つねお）
東海大学 大学院 組込み技術研究科 助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。