人月の神話

  • 341人登録
  • 3.76評価
    • (15)
    • (31)
    • (21)
    • (4)
    • (1)
  • 29レビュー
制作 : 滝沢 徹  牧野 祐子  富澤 昇 
  • ピアソン桐原 (2010年12月14日発売)
  • Amazon.co.jp ・本 (352ページ)
  • / ISBN・EAN: 9784864010054

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
デール カーネギ...
フレデリック・P...
濱野 純(Jun...
有効な右矢印 無効な右矢印

人月の神話の感想・レビュー・書評

  • 36年前に上梓された本とは思えない。
    それぐらい含蓄のある名著。
    逆に言うと、この36年間、ソフトウェアエンジニアリングの世界は何をやっていたんだという軽い絶望感を味わえる本。

    本文中にもあったと思うけど、ソフトウェア開発ってのは大規模になればなるほどステークホルダーとして多くの人間が関係し、人と人とのトランザクションが発生する。
    そういった意味で、エンジニアリングとはいうものの、多分に社会科学的な要素を含むんだろうな。
    コンピュータサイエンスみたいな自然科学寄りの分野の進歩と比較しても仕方ないのかも。

    だからこそ、ソフトウェア開発に携わる人間としては、ソフトウェアエンジニアリングの技術的側面だけでなく、心理学であったり社会学であったりマーケティングであったり組織論であったりEQであったりリーダーシップであったり、そういったもやっとしたウェットな領域もカバーしないといけないんだなと。
    これからの道筋が少し見えた気がします。

  • 一部現代にも通用するが全体として小難しい

    ITの分野で時々名前をきく本。興味があったので借りて読んでみた。
    1980年代付近に書かれた本で,ソフトウェア開発に関する問題について書かれている。よくきくのは2章の人月に関する話と16章の銀の弾丸の話。

    ソフトウェア開発に置いては,人と月は交換可能ではない。新しく人を投入しても教育やコミュニケーションのコストあるので,むしろ効率が悪くなるという話。
    昔に書かれたので,内容は全体的に古臭い。そして,学者が書いたのか,翻訳が悪いのか長くて堅苦しくてわかりにくくて読みにくい。たしかにソフトウェア開発に関する問題としては今でも通用するところがあるかもしれない。
    しかし,単純に読みにくいし過大評価されすぎだと思う。

  • 数年の積読を経て、ついに、今こそ読まれる日が来た。ということで読んだ。(後半は結構飛ばした)

    "コストは実際に人数と月数の積に比例する。が、進捗はそうではない。…人と月が交換可能になるのは、多くの作業者の間でコミュニケーション(意思疎通)を図らなくても、仕事が分担できる場合だけである。"

  • 内容は古いがコミュニケーションの重要性が参考になった。

  • 情報が古く内容が入ってこない

  • 古い本なので例えが古すぎる + 実際に大規模なガチ開発をしたことがないので、理解しづらいところも割とあった。
    前半は僕にとってわかりやすく、特に
    ・人月がなぜ人と月の等価交換ではないか
    ・デザインやらコンセプトは一人ないしは少数で固めるべき
    ・セカンドシステム症候群
    などはなるほどな、という感じだった。

  • 僕らITの人は「人月」と「単価」で見積もります。5人で3ヶ月の仕事は15人月。じゃあ、15人投入すれば1ヶ月でその仕事は終わるのか?って話。無理です。「人」と「月」は交換可能ではないから。

    全体の方針はプロジェクトの最初に優秀な人間が少人数で決める。このことで全体の整合性や一貫性が根付くのである。そーだー。

    全体をサマリーしている18章だけでも読む価値あります。

    2.6 コスト計算をもとにして組み立てられた見積もり技術は、労力と進捗とを混同している。人月は間違った危険な神話である。というのも人月とは「人」と「月」が相互に交換可能だということを意味しているからだ。

    3.7 外科手術チーム編成のチーフプログラマは、コミュニケーション負荷を徹底的に削減することで、少人数の頭脳による製品の完全性、および多くのサポートスタッフによる総生産性の工場を得る方法を提起できる。

    15.14 プログラムを修正する人が使用する文書では、単にそのプログラムがどうなっているのかを示すのではなく、なぜそうなっているのかを伝えることが重要だ。目的こそ理解の鍵になる。高水準言語の構文であっても目的を伝えはしないのだから。

  • プロなら古典ぐらい読もう!
    7章 The boss と The technical director は別の talent が必要、とある。これを一緒にしていいのは小規模プロジェクトだけ(`´)

  • 学生のうちに読んだけど、正直あまりピンと来なかった。プロジェクト管理の必要に迫られてからよめばもっと身になったかも。

  • 40年近く前に書かれているため、技術的には古く参考となる部分は多くない。しかし、考え等は今でも十分に通用するどころか非常に示唆にとんでおり参考となる部分が多い。

  • ソフトウェアプロジェクトがなぜ難しいのか、それは本質的に複雑で難しいものを解決する手段だから。
    銀の弾はないものの、理解しておくべきことは幾つもある。例えば、
    •人と月は相互に変換不可能
    •アーキテクチャはごく少人数で決めるべき
    •遅延したプロジェクトに要員を追加するとさらに遅れる

    こういうことを現場では感覚的に理解してる人は少なからずいそうだか、現場を知らない人は理解してなさそう。そういう人にこそ読んでいて欲しいと思う

  • [読んだ理由]==================
    「100人のプロが選んだソフトウェア開発の名著」にあった。工数に関する一般的な考え方が知りたかったので。「100人の~」からの引用:ブルックスの法則として知られる「遅れつつ有るソフトウェア開発プロジェクトにおいては、人の増員はかえって遅れをひどくするばかりである」というのがあります。これは延べ人数という概念からは相反します。しかし実情は、増員は後期を殆ど短縮しないということが知られています。

    [読んだ後の感想]==============
    思っていたより当たり前の内容が、思っていたより平易な文章で書かれていた印象。なので思っていたよりは読みやすい。特に印象的だったのは下記。
    ・遅れているプロジェクトへの要員追加は、更に遅らせるだけ。それは追加要員の教育やコミュニケーション、タスクの細分化?断片化?、システムテストの増加を招くため。
    ・コンセプトの完全性・統合が重要。その為にはデザイナーは1人or少数であるべき。
    ・アーキテクチャとインプリメンテーションとは切り離すべき。
    ・大規模ソフトは「構築」から「育成」の時代へ。
    ・偉大なマネージャと同等以上に、偉大なデザイナーは重要。

    18章にそれまでの各章のまとめがあるので、まずそこから読んで、興味出た章だけ読んでみるのも良いかも。


    [備忘録]======================

    ■第一章:タールの沼


    ■第二章:人月の神話
    得意先の希望する納期に合わせた間違ったスケジューリングは、他のどのエンジニアリング分野よりも、ソフトウェアエンジニアリングで頻繁に行われている。定量分析てき手法に由来しない、データの裏付けも殆ど無い、主としてマネージャーの感だけの保証による見積もりを、力強く、もっともらしく、又仕事を危険にさらしてまでその妥当性を主張することは、極めて難しい。

    必要不可欠なソフト受けあプロジェクトが予定より遅れていたら、どうするだろうか。当然、要員を増やすことだろう。しかし、仕事を変更せずに、要員の追加により元々の期日内で完成させようとすることは破滅的である。新しく追加された要員は、如何に優秀で、どれほど迅速に補充されようと、経験ある人からその仕事に関する教育・訓練を受けなければならない。(3名追加する場合)これに一ヶ月かかるとすると、三人月は元の見積もりにはなかった仕事に費やされてることに成る。しかも仕事は本来3つに分けられていた所を5つに分け直さなければならず、既に完了している仕事で無駄になるものも出てくる上、システムテストをより長くしなければならない。

    遅れているソフトウェアプロジェクトへの要員追加は、更に遅らせるだけだ。


    ■第三章:外科手術チーム
    経験を積んだプログラマグループの実績を測定した。其のグループの中だけでも、最高と最低の実績比率は生産性にして平均10:1、プログラム開発のスピードと量とではなんと5:1であった。要するに、年間2万ドルのプログラマが年間1万ドルのプログラマの10倍も生産性が高いということである。

    効率性とコンセプトの完全性の観点から見れば、デザインと政策は少数精鋭で行いたい。だが、大規模なシステムでは、製品をタイムリーに発表できるように、できるだけ大量の要員を投入する方法が望ましい。この2つのニーズはどのようにして折り合いを付けることができるのだろうか。


    ■第四章:貴族政治、民主主義、そしてシステムデザイン
    アーキテクチャは、インプリメンテーションとは注意深く区別される必要がある。
    「アーキテクチャは何が起こるかを語るのに対し、インプリメンテーションは如何にして起こせるかを語るのだ」
    アーキテクチャの労力をインプリメンテーションから切り離すことは、非常に大規模なプロジェクトでコンセプトの完全性を得るとても強力な方法である。


    ■第五章:セカンドシステム症候群


    ■第六章:命令を伝える
    アーキテクトは、自分が記述した機能のインプリメンテーション方法の一つぐらいはいつでも示せるようでなければいけないが、インプリメンテーションそのものを指示しようとしてはならない。

    インプリメンテーションが進むに連れて、仕様書が如何に的確であるとしても、アーキテクチャの解釈に関する数え切れない疑問が出てくる。
    勝手に推察して先に進むのではなく、理非をわきまえている担当アーキテクトに電話して疑問を正すようにさせることは必要不可欠なことだ。
    こういう時、アーキテクト側で電話の記録を残す仕組みを考えておくと良い。其の中にすべての質問と答を記録する。毎週、アーキテクトの記録を纏めて転載し、利用者と実現者に配る。この仕組はごく非公式のものだが、スピーディでしかも判りやすいものである。


    ■第七章:バベルの塔は、なぜ失敗に終わったか


    ■第八章:予告宣言する


    ■第九章:五ポンド袋に詰め込んだ十ポンド


    ■第十章:文書の前提
    マネージャーの仕事は、計画を作成してそれを実現することだ。だが、文書化された計画のみが明確で伝達可能だ。
    マネージャーの基本的な仕事は、全員を同じ方向へ進ませることなのだから、主要な日課は、意思決定ではなくてコミュニケーションを図ることなのだ。文書があれば、その負担が大いに軽減される。


    ■第十一章:一つは捨石にするつもりで
    大抵のプロジェクトでは、最初に完成したシステムはほとんど使いものにならない。遅すぎたり、大きすぎたり、使いにくかったりする。酷いものになると、この3つ全てが当てはまっていることもある。
    管理上の問題とは、パイロットシステムを作成して、それを廃棄するかどうかと言うことではない。当然そうすべきなのだ。

    システムプログラムの作成は、エントロピーを減らす過程だから、本来準安定なものである。他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行なっても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。


    ■第十二章:切れ味の良い道具


    ■第十三章:全体と部分
    最も有害で捉えにくいバグは、それぞれのコンポーネントを書く人々の間に存在する前提の不整合から発生するシステムのバグだ。
    製品に対するコンセプトの完全性こそが、製品を使いやすくするばかりでなく、構築を容易にしてバグから逃れやすくもするのである。


    ■第十四章:破局を生み出すこと
    人は、プロジェクトのスケジュールが破滅的に遅れていると訊くと、大変な不幸が続け様に起こったに違いないと想像する。しかし大抵の場合、そういう破滅的状況は竜巻のような突発的なものではなく、シロアリのようにじわじわ忍び寄ってくるものが原因である。スケジュールは、情け容赦なくではなく、ごくわずかずつ遅れてきたのだ。

    マイルストーンの決定に関し、関係する規則は1つだけだ。それは、マイルストーンを具体的かつ明確で測定可能なイベントとして、ナイフの歯のような鋭さを持って定義しなければならないということである。
    マイルストーンを鋭利な刃のように曖昧な所をなくすことは、上司が確かめられるようにすることより重要だ。人は、マイルストーンが自分も欺けないくらいえいろだと思えば、マイルストーンの進捗をごまかそうとはめったにしない。しかしマイルストーンがファジーなら、上司はしばしば報告を提出した本人とは異なる意味に解釈してしまう。悪い知らせを喜んで伝えようとするものなどもいないわけで、ごまかそうと言うつもりはなくても表現を和らげてしまいがちだ。


    ■第十五章:もう一つの顔
    実際の所、フローチャートを書くことは、騒がれているほどには、実践されていない。プログラムを書き始める前に詳細なフローチャートを決まって書く熟練プログラマにお目にかかったことがない。


    ■第十六章:銀の弾などない 本質と偶有
    ソフトウェア製作者が顧客のために行う最も重要な仕事は、製品の要件を繰り返し抽出し、洗練していくことだ。実際の所、顧客自身何を希望しているのかわかっていないものだ。カレラは通常、どんな質問に答えなくてはならないかを理解しておらず、指定しなければならない問題の詳細さについて考えたことなど殆ど無い。

    ソフトウェアを構築ではなく、育成する:建築に例えることはもう有用さを失ってしまった。再び代えても良い時期である。
    どのソフトウェアシステムも漸増的開発によって育成されるべきだ。つまり、そのシステムがたとえ適当なダミーサブプログラムのセットを呼び出すこと以外役立つことは何もしないとしても、先ず動くように作られるべきである。それから少しずつシステムを肉付けしていく。

    私達にできる最も重要な努力は、偉大なデザイナーを育てる方法を開発することだと思っている。
    ソフトウェアが医者なら、この挑戦を無視できないだろう。優秀なマネージャーは、数は少ないとしても、優秀なデザイナーよりは多いはずだ。偉大なデザイナーと偉大なマネージャーは、どちらも非常に稀な存在である。大抵の会社は、管理面で有望な人材を見つけて育成することには相当の時間を費やしている。だが、偉大なデザイナーの発見と育成について、同様の努力を費やしている会社を私は知らない。製品の卓越した努力は本質的に彼らに依存するのだが。


    ■第十七章:「銀の弾などない」再発射


    ■第十八章:「人月の神話」の命題 真か偽か


    ■第十九章:「人月の神話」から二十年を経て

  • 「人」と「月」は交換可能ではない。要員が増えることによるロスを考えると確かにそうなんだけど、スケジュール作成の際にはつい見逃してしまう(敢えて見ないふりをしている?)事柄。ここは交換可能でないことを啓蒙していくことから始めないといけないか。■全体的にはちょっと時代が旧いこともあって、いまいちピンとこなかった。デマルコの方が面白いかな。

  • システム開発の現場では、1人1人の動きとチームワークが成否を左右する。改めて、すごい開発ツールやマネジメント手法ではなく、人の育成や人同士の関係性が重要であることに気づかされた。

  • 人と月が交換可能なのは多くの作業者の間で意思疎通を図らなくても、仕事が分担できる場合だけ、どう頑張ってもシステムプログラム開発には当てはまらない。
    スケジュールの目安
    計画1/3
    コーディング1/6
    単体結合1/4
    システムテスト1/4

  • 数十年前に書かれたものだが現在でも名が上がるほどの本,
    ということで一回読んでみた.
    システムの開発に関して,開発を遅らせる原因やチームを作る難しさについて記してある.現在の自分の立場ではあまりイメージできないところではあるが将来そのような職に就くことがあればもう一度この本を理解したいと思う.ソフトウェア開発以外でも当てはまる事は多いと思う.

  • 1975年(なんと僕の生まれる前)に出版されたソフトウェア開発の古典。
    時間がなければ、16章以降から読めば良い。

    ソフトウェア構築の作業を「本質的作業」「偶有的作業」に分け、ソフトウェア構築の困難さはその「本質的」な部分が複雑が故であるという。
    ソフトウェア開発には銀の弾はないが
    ①購入できるものを構築しない
    ②プロトタイプの作成
    ③機能を追加しながら、システムを育成させる開発手法
    ④システムデザイナーの発掘、育成
    を説く。

    上記4点は2012年にしても成し遂げられておらず、現在でも十分に有効な提言だと考える。
    ①共通化、標準化がないことにより、度重なる同一機能の作成
    ②③相変わらずのフォーターフォールによる開発。もはや時代遅れ・・
    ④プロマネ至上主義、上流工程こそが価値があるといった考え、システムデザインを描ける人材の軽視、育成不足

  • 遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ。これぞ至言。チーム開発の難しさが痛いほど分かる本。もちろん真に理解するには経験が必要なのだろうけど理論を知れただけでも勉強になった。もし自分がプロジェクトを管理する立場になったら再読しよう。

  • 大規模ソフトウェア開発に関する古典とも言える書。かなり古い言葉も出てくるが、本質的な状況は変わっていない気がする。銀の弾はないということか。

  • 要するに、プロジェクト遂行とは大規模並列計算と同じなのだと。
    分割可能なタスクは並列演算、ベクトル演算可能。
    アムダールの法則に従えば、並列化率を上げれば、作業効率は上がる。
    基本的に分業できる部分は分業したほうがいい。
    しかし、実際の並列計算において意外にコストがかかるのは、個々のノードの演算ではなくて、ノード間の通信時間、オーバーヘッド。
    大規模演算を行うために並列数を増やせば、通信コストは増す。
    まして人間ではコンピュータ以上に通信のコストは高い。
    通信のプロトコルが正確とは限らないから、エラーが出まくりの、オーバヘッドが膨大なのである。
    したがって、安易に並列数を増やすより、各々のノードの実行効率を上げるほうが効果的。
    SIerやエンジニアリング業者の個人の仕事量が多いのは、そのためである。
    仕事が多いことが腑に落ちた。
    そして、一人で大量のタスクをこなせる高機能CPUが必要となる。
    「偉大な旋盤工は、平均的な旋盤工の数倍の給料を支払う価値があります。しかし、ソフトウェアコードの偉大な書き手は平均的な書き手の一万倍の価値があるのです。」
    というゲイツの言葉が思い出される。
    どうしても並列数を増やしたければ、プログラミング(組織を作る)の際にノード間の通信量をなるべく少なくするように、アルゴリズムを組む必要がある。
    そうすれば実行速度の低下も抑えられる。
    プロジェクトマネージャーの機能の一つが並列コンピューティングのプログラマ。
    少ないCPU間の通信で同じ演算結果を得られるように工夫しなければならない。

    あと、インターフェースとかオペレータとかの役割もあるのだろう。

    オペレーションも命令系統が機能するような組織を編成するべし。
    いくつかの案が提案されていた。

    また、プロジェクトの成果物のコンセプトを一貫したものにするためには、コンセプトの決定権を集約しなけらばならない。
    コンセプトを決める人は一人。
    設計者はコンセプトは触らない。
    いかにコンセプトを実現するかという部分に裁量を持ち、自己主張せねばならない。

  • ・遅延したプロジェクトに人員を追加しても、さらに遅延するだけである。
    ・人と月が交換可能なのは、多くの作業者の間でコミュニケーションを図らなくても仕事分担が出来る作業のみ。
    ・相互コミュニケーションが必要な作業は人が増えるとむしろ作業コストがあがる。
    ・プログラムを作ることは以下五種類の喜びを与えてくれる。
     -物を作る喜び
     -他の人に役立つ物を作る喜び
     -パズルのような組み合わさって作動する部品でできたものを作る喜び
     -つねに学ぶ、という繰り返しがない作業の喜び
     -実在して動き働くもので仕事ができる喜び
    ・優秀なプログラマの生産性は出来の良くないプログラマの10倍違う。
    ・少数精鋭チームが最高である。
    ・コンセプトの一貫性、完全性が重要。
    ・コミュニケーションの重要性。
    ・働きやすい環境にすることにコストをかける。

  • 全てではないが、「あ、これ、あるある!」の連続。しかし、この本が書かれたのは1975年のこと。当時こうやって指摘されていたソフトウェア開発の問題点が現代にも生き残っているというのは残念な話。

全29件中 1 - 25件を表示

人月の神話を本棚に「読み終わった」で登録しているひと

ツイートする