P.ブルックス著「人月の神話」とソフトウェアビジネスの難しさ
私は丸14年間仕事の約半分は自社開発のパッケージソフト作りに、後の半分は大手企業からの特注ソフトウェア開発で飯を食ってきた。そして様々な修羅場もくぐってきたから、ソフトウェアビジネスについて物言いする資格はあるだろう(笑)...。
ブルックスの著書、「人月の神話〜狼人間を撃つ銀の弾はない」にからめて今回はソフトウェアビジネスの難しさをテーマに雑文を書いてみる。
フレデリック・P・ブルックス著「人月の神話〜狼人間を撃つ銀の弾はない」は1975年に出版された本だから、すでに30年以上も前の本である。そして私が手にしているものは発行20周年を記念して1996年に増訂出版された一冊だ。
本書(原題：「The Mythical Man-Month」)はコンピュータの開発、特にそのソフトウェア開発の生産性に関わるマネジメントの問題を扱った本である。ただし1975年といえば、コンピュータは大型汎用コンピュータを意味した。ブルックス自身、IBMのシステム/360の開発者として知られており、その開発の経験が本書を書くきっかけとなったという。したがって現在パソコン向けのソフトウェア開発の現状とは些かニュアンスが違うが、事ソフトウェアという "魔物" を扱う仕事としては傾聴に値する内容であることには間違いがない。
まあ、これからの話はプログラマや同業者の方々には文字通り釈迦に説法であるから、読み飛ばしていただきたいが、ソフトウェアを創るという仕事の内幕をご存じない方には面白いかも知れないし、一部はすべてのビジネスにも関わってくることだ...(笑)。
※フレデリック・P・ブルックス著「人月の神話〜狼人間を撃つ銀の弾はない」 (原著発行20周年記念増訂版)表紙
本書「人月の神話」について詳しく解説する余裕も能力も私にはないが、ソフトウェアを開発する立場からは現在にも通じる様々な問題を考えさせられる「古くて新しい一冊」だといえる。
ところで「人月」という言葉に馴染みがない人もいると思うので少し触れておきたい。「人月」は通常「ニンゲツ」と読み、ソフトウェア(とは限らないが)を開発実装するのに必要とする工数(一般的には見積額の算出などに利用する延べ時間)を人と時間との単純な掛け算で表現した単位である。例えば「3人が6ヶ月かかってソフトウェアを開発する場合」の工数は「18人月」となる。
この工数はそのまま見積の単位として見なされ、その開発企業の一人月の費用が100万円なら、前記の開発費用の基本総額は1,800万円となる計算だ。
しかしこの人月という考え方は、心ある人なら誰でも頭をかしげながら使っているのではないだろうか。
ブルックスは、開発コストは人月で算出されるが開発の進捗は人月にはそぐわず、疑うべき危険な神話であると言っている。
コストを人月で表すと言うことは、"人"と"月"とがお互いに交換できるというニュアンスを含んでいる。しかし実際には交換はできない。どういうことか...。
例えば前記のように「3人で6ヶ月かかるから18人月の仕事です」とクライアントに提示したとする。クライアントは「18ヶ月もかかるのでは間に合わないから18人を投入して1ヶ月で開発してくれ」と要求する(笑)。しかし、現実には出来得ない相談である。
そこに混乱が起きる。こうしたソフトウエア開発の管理の難しさから「女性がどれほどたくさん動員されたところで、子供１人が生まれてくるまでは十月十日かかることに変わりはないのと同じだ」とか「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」というブルックスの明言が生まれた。
そんなに不明瞭なら人月といった単位は使わなければ良いと考えるかも知れないが、当然クライアントはコスト算出のためには単位の定量化・標準化を求める。したがってある意味、ソフトウェア開発の天才であろうと今年入社した新人であろうと、１人は１人として数えるしか方法はなく、何ヶ月で開発が終わるかをコストに反映させるしか説得力のある単位が他にないのである(笑)。まあ、厳密にはより以上に緻密なコスト算出をしなければならないが、一般的に「人月」へのイメージはこんな感じなのだ。
さて、私の経営したMacintosh専門のソフトハウスは工数単価の高いことでも知られていた(笑)。
クライアントが他社と相見積をとるような場合があれば確実に2倍から3倍は高かったと思う。いや、私から言わせれば相見積の他社が異常であり、そのコストでは後先を考えずに仕事を取りたいがための安売りとしか考えられないのだが...。そして初めからそのコストではまともなものが作れるとは到底思えない。
ともかく１人月のコストは高かったが、自慢できることがひとつある。それは14年間のビジネスのなかで自社開発のケースは別として、クライアントからの特注開発依頼の納期を一度でも遅らせたことはない...。
さらっと書いたが、この事実はこの業界では希有なことだと断言できる(笑)。中には「ソフトウェア開発は遅れて当然」と考えている人もいるようだが、趣味ならともかくビジネスとしての契約あるいは約束を「当然」とか「慣例」のひと言で済ませてしまうそのことが、ソフトウェア産業への信頼性を薄くする原因に違いないと考える。
無論技術的にも他社が開発を失敗し、アップルに泣きつき、その駆け込み寺的に私の会社にコンタクトを取られた超大手企業もあったくらい、手前みそながら技術的にも優れた企業だった。
ともかく特注ソフトウェア開発はひと言でいえば「魔物」である。数多くの開発を手にしてきた経験から言えば最大の問題は「クライアントの多くは発注時に自身の欲しい"もの"を知らない」と常々感じている。どういうことか...。
もともとMacintosh用のソフトウェア開発のために、本格的な意味での仕様書などを書き上げた例はほとんどなく、開発の進捗そのものが仕様の確認となる場合が多かった。それでもクライアントは注文に当たり、当然のこと「このような機能を実装し、このような結果が得られるソフトウェアを開発して欲しい」と依頼してくる(注文書)。しかしそれらを実装して実際に動作するところをお見せすると、その大半は「ああ...なるほど、弊社が考えたことはこのことなのですね」と始めて本当の意味で、機能の目的や仕様の実際・実態を認識され、それが他へどのような影響を与えるものなのかを知ることになる。だから多くの場合に続いて「...それなら、こうした機能も可能ですか？」とくる(笑)。
...それでは見積の工数計算をやり直さなければならない。しかしクライアントはその事は頭にない(爆)。
だいたい仕様やその完成度について、開発側とクライアント側とはもともと温度差が違うものだから、その温度差をいかに埋めるかが重要であり、まかり間違っても口約束だけの仕事を受けるようなことがあってはならない。
私がどのような大手とも対等の基本契約書をやり取りする努力を怠らなかったのはそのためだ。
だいたい相手は工数だなんて便宜上のものであり、どうにでも収縮できるものだと思っているフシもあるのだ(笑)。
プログラムの開発の話ではないが、最近友人から聞いた話しで印象的な出来事があった。それは彼らがビデオ制作の受注を受け、何度もクライアント側のスタッフらと入念な打ち合わせをした結果、作品が完成し、それを納品するため相手先に出向いたという。クライアントのスタッフらは思った通りの出来に満足だったようだが、そこにこれまで一度も打ち合わせに出たこともない責任者と称するオヤジが登場し、一瞥しただけで「これではダメだな...やり直してもらえ」とスタッフにボソっと指示をしたという...嗚呼。
この種の場面を経験したことのないビジネスマンは幸せであるばかりでなく、失礼ながらまだ一人前ではないと思う(笑)。なぜならそれほどこの種の、それも理不尽なすれ違いが実際には多いものなのだ。
ともかくひと言でいえばソフトウェア開発という仕事は特殊な要素を多々含んでおり、単純に他のクリエイティブな労働と比較出来ないのである。
ここで詳細な部分には踏み込まないが、ブルックスはこうした問題を解決する意味で、管理者側の取るべき行動のうちもっとも重要なことは、「だれか１人を製品アーキテクト(architect)に任命することだ」と主張している。アーキテクトとは、この場合、設計者・考案者・構成者などと訳されるが、アーキテクトは開発関係者全員が共有すべき製品の心的モデルを形成することは勿論、利用者の代弁者でなければならない。
開発には機能・性能・サイズ・コスト・スケジュールといった様々な要因が複雑にからんでくるが、これらを十分に認識し、問題があれば傷の浅い内に軌道修正をとらなければならず、それらをコントロールするのもアーキテクトの役割に違いない。そして自身がユーザーの立場からもソフトウェアを評価できることが最も大切なことだと考える。
手前みそにはなるが、私の会社においてのアーキテクトは社長の私自身であった。現在でも私の大きな仕事のひとつはソフトウェア開発や新規事業立ち上げに際しての"アーキテクト"であると自負しており、名刺にもその旨を記してある。
というわけで、幸いにも優秀な開発陣やスタッフらの努力と共に私自身がアーキテクトの役割を果たし得たからこそ、納期を違えたこともなく、大きなトラブルを抱えることもなく14年間を過ごすことが出来た。
ただし、これは特注開発に関する状況であって自社開発のパッケージソフトウェアを生み出すプロセスとなれば話はかなり違ってくる。暴露話になるが(笑)、正直遅れに遅れたプロダクトもあったし、バグがなかなか取れずに苦労したプロダクトもあった。そうしたパッケージソフトの開発秘話についてはまた別途ご紹介してみたい。
さて、ブルックス著「人月の神話」はソフトウェア開発だけでなく、さまざまな業種における管理職のあり方をも考えさせられる名著だと思う。そこに展開されている理窟がすべて我々の日常を反映しているとは思わないが、もしまだお読みになっていない管理者がおられたら是非一読をお勧めしたい一冊である。
____________________________________________________________________________________
「人月の神話〜狼人間を撃つ銀の弾はない」
1996年2月15日 増訂版第1刷発行 (原著発行20周年記念増訂版)
著者：フレデリック・P・ブルックス
訳者：滝沢徹、牧野祐子、富澤昇
発行：アジソン・ウェスレイ・パブリッシャーズ・ジャパン（株）
発売：（株）星雲社
書籍コード：ISBN4-7952-9675-8 C3055
定価：本体2,816円+税
_____________________________________________________________________________________
ブルックスの著書、「人月の神話〜狼人間を撃つ銀の弾はない」にからめて今回はソフトウェアビジネスの難しさをテーマに雑文を書いてみる。
フレデリック・P・ブルックス著「人月の神話〜狼人間を撃つ銀の弾はない」は1975年に出版された本だから、すでに30年以上も前の本である。そして私が手にしているものは発行20周年を記念して1996年に増訂出版された一冊だ。
本書(原題：「The Mythical Man-Month」)はコンピュータの開発、特にそのソフトウェア開発の生産性に関わるマネジメントの問題を扱った本である。ただし1975年といえば、コンピュータは大型汎用コンピュータを意味した。ブルックス自身、IBMのシステム/360の開発者として知られており、その開発の経験が本書を書くきっかけとなったという。したがって現在パソコン向けのソフトウェア開発の現状とは些かニュアンスが違うが、事ソフトウェアという "魔物" を扱う仕事としては傾聴に値する内容であることには間違いがない。
まあ、これからの話はプログラマや同業者の方々には文字通り釈迦に説法であるから、読み飛ばしていただきたいが、ソフトウェアを創るという仕事の内幕をご存じない方には面白いかも知れないし、一部はすべてのビジネスにも関わってくることだ...(笑)。
※フレデリック・P・ブルックス著「人月の神話〜狼人間を撃つ銀の弾はない」 (原著発行20周年記念増訂版)表紙
本書「人月の神話」について詳しく解説する余裕も能力も私にはないが、ソフトウェアを開発する立場からは現在にも通じる様々な問題を考えさせられる「古くて新しい一冊」だといえる。
ところで「人月」という言葉に馴染みがない人もいると思うので少し触れておきたい。「人月」は通常「ニンゲツ」と読み、ソフトウェア(とは限らないが)を開発実装するのに必要とする工数(一般的には見積額の算出などに利用する延べ時間)を人と時間との単純な掛け算で表現した単位である。例えば「3人が6ヶ月かかってソフトウェアを開発する場合」の工数は「18人月」となる。
この工数はそのまま見積の単位として見なされ、その開発企業の一人月の費用が100万円なら、前記の開発費用の基本総額は1,800万円となる計算だ。
しかしこの人月という考え方は、心ある人なら誰でも頭をかしげながら使っているのではないだろうか。
ブルックスは、開発コストは人月で算出されるが開発の進捗は人月にはそぐわず、疑うべき危険な神話であると言っている。
コストを人月で表すと言うことは、"人"と"月"とがお互いに交換できるというニュアンスを含んでいる。しかし実際には交換はできない。どういうことか...。
例えば前記のように「3人で6ヶ月かかるから18人月の仕事です」とクライアントに提示したとする。クライアントは「18ヶ月もかかるのでは間に合わないから18人を投入して1ヶ月で開発してくれ」と要求する(笑)。しかし、現実には出来得ない相談である。
そこに混乱が起きる。こうしたソフトウエア開発の管理の難しさから「女性がどれほどたくさん動員されたところで、子供１人が生まれてくるまでは十月十日かかることに変わりはないのと同じだ」とか「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」というブルックスの明言が生まれた。
そんなに不明瞭なら人月といった単位は使わなければ良いと考えるかも知れないが、当然クライアントはコスト算出のためには単位の定量化・標準化を求める。したがってある意味、ソフトウェア開発の天才であろうと今年入社した新人であろうと、１人は１人として数えるしか方法はなく、何ヶ月で開発が終わるかをコストに反映させるしか説得力のある単位が他にないのである(笑)。まあ、厳密にはより以上に緻密なコスト算出をしなければならないが、一般的に「人月」へのイメージはこんな感じなのだ。
さて、私の経営したMacintosh専門のソフトハウスは工数単価の高いことでも知られていた(笑)。
クライアントが他社と相見積をとるような場合があれば確実に2倍から3倍は高かったと思う。いや、私から言わせれば相見積の他社が異常であり、そのコストでは後先を考えずに仕事を取りたいがための安売りとしか考えられないのだが...。そして初めからそのコストではまともなものが作れるとは到底思えない。
ともかく１人月のコストは高かったが、自慢できることがひとつある。それは14年間のビジネスのなかで自社開発のケースは別として、クライアントからの特注開発依頼の納期を一度でも遅らせたことはない...。
さらっと書いたが、この事実はこの業界では希有なことだと断言できる(笑)。中には「ソフトウェア開発は遅れて当然」と考えている人もいるようだが、趣味ならともかくビジネスとしての契約あるいは約束を「当然」とか「慣例」のひと言で済ませてしまうそのことが、ソフトウェア産業への信頼性を薄くする原因に違いないと考える。
無論技術的にも他社が開発を失敗し、アップルに泣きつき、その駆け込み寺的に私の会社にコンタクトを取られた超大手企業もあったくらい、手前みそながら技術的にも優れた企業だった。
ともかく特注ソフトウェア開発はひと言でいえば「魔物」である。数多くの開発を手にしてきた経験から言えば最大の問題は「クライアントの多くは発注時に自身の欲しい"もの"を知らない」と常々感じている。どういうことか...。
もともとMacintosh用のソフトウェア開発のために、本格的な意味での仕様書などを書き上げた例はほとんどなく、開発の進捗そのものが仕様の確認となる場合が多かった。それでもクライアントは注文に当たり、当然のこと「このような機能を実装し、このような結果が得られるソフトウェアを開発して欲しい」と依頼してくる(注文書)。しかしそれらを実装して実際に動作するところをお見せすると、その大半は「ああ...なるほど、弊社が考えたことはこのことなのですね」と始めて本当の意味で、機能の目的や仕様の実際・実態を認識され、それが他へどのような影響を与えるものなのかを知ることになる。だから多くの場合に続いて「...それなら、こうした機能も可能ですか？」とくる(笑)。
...それでは見積の工数計算をやり直さなければならない。しかしクライアントはその事は頭にない(爆)。
だいたい仕様やその完成度について、開発側とクライアント側とはもともと温度差が違うものだから、その温度差をいかに埋めるかが重要であり、まかり間違っても口約束だけの仕事を受けるようなことがあってはならない。
私がどのような大手とも対等の基本契約書をやり取りする努力を怠らなかったのはそのためだ。
だいたい相手は工数だなんて便宜上のものであり、どうにでも収縮できるものだと思っているフシもあるのだ(笑)。
プログラムの開発の話ではないが、最近友人から聞いた話しで印象的な出来事があった。それは彼らがビデオ制作の受注を受け、何度もクライアント側のスタッフらと入念な打ち合わせをした結果、作品が完成し、それを納品するため相手先に出向いたという。クライアントのスタッフらは思った通りの出来に満足だったようだが、そこにこれまで一度も打ち合わせに出たこともない責任者と称するオヤジが登場し、一瞥しただけで「これではダメだな...やり直してもらえ」とスタッフにボソっと指示をしたという...嗚呼。
この種の場面を経験したことのないビジネスマンは幸せであるばかりでなく、失礼ながらまだ一人前ではないと思う(笑)。なぜならそれほどこの種の、それも理不尽なすれ違いが実際には多いものなのだ。
ともかくひと言でいえばソフトウェア開発という仕事は特殊な要素を多々含んでおり、単純に他のクリエイティブな労働と比較出来ないのである。
ここで詳細な部分には踏み込まないが、ブルックスはこうした問題を解決する意味で、管理者側の取るべき行動のうちもっとも重要なことは、「だれか１人を製品アーキテクト(architect)に任命することだ」と主張している。アーキテクトとは、この場合、設計者・考案者・構成者などと訳されるが、アーキテクトは開発関係者全員が共有すべき製品の心的モデルを形成することは勿論、利用者の代弁者でなければならない。
開発には機能・性能・サイズ・コスト・スケジュールといった様々な要因が複雑にからんでくるが、これらを十分に認識し、問題があれば傷の浅い内に軌道修正をとらなければならず、それらをコントロールするのもアーキテクトの役割に違いない。そして自身がユーザーの立場からもソフトウェアを評価できることが最も大切なことだと考える。
手前みそにはなるが、私の会社においてのアーキテクトは社長の私自身であった。現在でも私の大きな仕事のひとつはソフトウェア開発や新規事業立ち上げに際しての"アーキテクト"であると自負しており、名刺にもその旨を記してある。
というわけで、幸いにも優秀な開発陣やスタッフらの努力と共に私自身がアーキテクトの役割を果たし得たからこそ、納期を違えたこともなく、大きなトラブルを抱えることもなく14年間を過ごすことが出来た。
ただし、これは特注開発に関する状況であって自社開発のパッケージソフトウェアを生み出すプロセスとなれば話はかなり違ってくる。暴露話になるが(笑)、正直遅れに遅れたプロダクトもあったし、バグがなかなか取れずに苦労したプロダクトもあった。そうしたパッケージソフトの開発秘話についてはまた別途ご紹介してみたい。
さて、ブルックス著「人月の神話」はソフトウェア開発だけでなく、さまざまな業種における管理職のあり方をも考えさせられる名著だと思う。そこに展開されている理窟がすべて我々の日常を反映しているとは思わないが、もしまだお読みになっていない管理者がおられたら是非一読をお勧めしたい一冊である。
____________________________________________________________________________________
「人月の神話〜狼人間を撃つ銀の弾はない」
1996年2月15日 増訂版第1刷発行 (原著発行20周年記念増訂版)
著者：フレデリック・P・ブルックス
訳者：滝沢徹、牧野祐子、富澤昇
発行：アジソン・ウェスレイ・パブリッシャーズ・ジャパン（株）
発売：（株）星雲社
書籍コード：ISBN4-7952-9675-8 C3055
定価：本体2,816円+税
_____________________________________________________________________________________
- 関連記事
-
- 右手の腱鞘炎の原因を検証する (2007/06/06)
- 多摩美術大学八王子キャンパスで特別講義を行った (2007/06/03)
- 何故CalculatorはMac OS 9までそのまま使われたのか？ (2007/05/21)
- 打ち合わせのため、多摩美術大学八王子キャンパスに出向く (2007/05/16)
- Apple本社から届いた株主総会案内と決算報告書を見て... (2007/05/06)
- P.ブルックス著「人月の神話」とソフトウェアビジネスの難しさ (2007/04/22)
- ジョブズの現実歪曲フィールド効果か？Apple商標権問題解決！ (2007/02/06)
- 「iPhone」にも酷評があるようだが...いつものことだ！ (2007/01/24)
- Apple iPhoneの素直な印象〜写真だけではその凄さは分からない！ (2007/01/11)
- 社名変更はAppleの経営戦略の大幅な変更を意味するか？！ (2007/01/10)
- デジタルアートに見る私とビル・ゲイツ氏の接点(ウソ〜笑) (2006/11/22)
