ゆとりの法則 － 誰も書かなかったプロジェクト管理の誤解 [プログラミング]
経営コンサルタントの著者が書いた組織に「ゆとり」が必要かつ有用な理由。
知的労働者の労働は、工場労働者よりも「考える」比重が大きく、他の労働者に仕事を引き継いだり、分割したりするのは難しい。
知的労働者（とくに管理者）の効率をあげようとして、無駄な時間を探しだし、仕事時間を100％稼働時間にしようとするのは無理な話である。
短期的には効率の数字はあがるかもしれないが、実際にはパフォーマンスが落ちるし、なにより「やらされている」感じを労働者に与え「やる気」をそいでしまう。知的労働者は給与よりもやりがいを重視する傾向があるので、結果として優秀な人材が流出してその損害ははかりしれないことになる。つまり人件費を1円けずっても失うものがおおければ1円の利益にならない。
人的資本の損失計算例
人的資本＝代わりの人材がふつうの速さで仕事ができきるまでの期間×（給与＋間接コスト）×50％
人的資本の損＝人的資本の平均損失額×離職率
短期的なストレスが仕事の生産性をあげることは確かにあるが、常にあると生産性は低下する。
なぜなら、人間は時間的なプレッシャーをいくらかけられても、速くは考えられないから。
もともと知的労働者は無駄な仕事や、重要でない仕事はあとまわしにしているので、できるのは夜遅くまで働くことくらい。
ほとんどの知的労働者の給与は時間ではないので、長時間労働をすると生産性はあがったようにみえるが、実は生活の質がおちた労働者は仕事に手をぬきながらやっているふりをするか、転職を考えるようになるのだ。
効率を重視してアシスタントや事務の仕事を減らすことは、知的労働者がコピー取りをするということで、最終的は生産性をさげることになる。
開発者5人のチームより、開発者4人と事務アシスタント1人のチームのほうがコストは安い。
効果より効率重視で恐怖が支配する企業では、管理職は常に怒っていて、スケジュールは誰も守れると思えないほど強気であり、みなうまくいかないときの責任を押し付け合い、ときには責任をとらないですむように訴訟まで起こす。
納期を守るためにやるべきことはすべてやったようにみせるために、うまくいかないのを承知で人員を投入したりする。
これではよい製品などできるわけがない。
管理者の仕事は管理していると思われないように管理すること。その仕事は目に見える成果（製作物）がないので、無駄とおもわれがちだが、実は違う。忙しくしている管理者は管理以外の仕事＝やるべきことでない仕事をやっていると思って間違いない。多くの管理者が仕事をしていないと思われる恐怖から目に見える仕事をやってしまい、本来の仕事ができていない。
まちがった管理の第1法則
うまくいかないことがあったら、もっとやれ
まちがった管理の第2法則
自分自身のユーティリティ・プレーヤーになれ（自分でコピーをとれ）
規格はありがたいものだが、知的労働ではあまり役に立たない、うまくやっている社員は手順は人と同じだが他の人より他人とのつながりがゆたかであった。
手順や目標管理は知的労働には重要でない。必要なのは現場レベルに権限移譲をすることである。
危険は伴うがモチベーションは確実にあがる。
品質管理は、他はすべて同じで、ある部分だけ改善すれば、全体のパフォーマンスがあがるという考えなので間違っている。他がすべて同じなどという状況はビジネスにはない。
過剰なストレスのある企業は効率をおいかける。効果は考えられていないので、進む方向があっているかだれにもわからない。
またリスクをとることを回避するので、繰り返し意味のない選択をすることになる。
変化のないところには成長はない。
それなのに現状にこだわりながら当然のように成長を期待している組織によく会う。
現状維持から成長はない。
変化するためにはビジョンが必要。
変化が成功するためには変わらないものは何か、組織の存在意義はなにか（ピーター・ドラッガーがいうところの文化）を明確に理解している必要がある。それは変化してはならないものだから。
リーダーシップとは自分の課題に他の人たちを参加させる能力。
リーダーとして意味のある行動をとれば、人々は長期的な利益を高めるため、短期的な痛みをある程度受け入れる。
方向性を明示するだけではポーズだけである。短期的に痛みがあることを率直にみとめ、あとはフォローアップして、本当のリーダーシップである。
リーダーシップは組織図の下から上に昇ったり、空白を横切ったりする。だれでも能力をもっているのであり、使う責務がある。
活気ある企業は、フォロワーシップはない。結果として人に従うことはあっても、本質的にはリーダーシップは全員の任務であり、交替で担うものになっている。
変化には「安全」が必要である。
人間は仕事でアイディティティの一部を支えている、変化に対する抵抗は慣れ親しんだものを捨てることに対する恐怖である。しかし恐怖が変化を必ずさまたげるのではない。健全な恐怖は学習につきものである。それよりも、変化による失敗を嘲笑する行為は絶対にゆるしてはならない。苦労をうけいれ失敗をしたひとは貴重な教訓を残した尊敬すべき人である。この文化を確立しなければならない。
リーダーが信頼を得るには、信頼に足ることを示さなければならないが、新しいリーダーにはそれができない。
だから、親が用いる方法＝いつも信頼に足ることが示されるより少し前に信頼を与えるを行う。
権限移譲である。リスクを避けるタイプの人にはできないことである。
変化を起こすとしたら、業績がよく余裕があるときである。
傾きかけてから付け焼刃にやっても「ゆとり」がないので効果は薄い。
組織の変化＝再生がおこるのは中間管理職の層からであり、この層が管理に十分時間をとれる「ゆとり」をもつことが組織を柔軟に持続的に発展させることになる。
管理者の仕事は習得が必要な技術なのに、ほとんどの管理者は他の管理者に学ぶこともできず、通り一遍の研修だけで実践に投入され、熟練管理者と同じレベルのパフォーマンスをもとめられる。これでは無理がある。
学習とは、新しい仕事をベテランよりゆっくりすることに他ならないのに、急げというメッセージが学習を不可能にしている。
知的組織には「健全な」競争など存在しない。内部の競争はすべて破壊的である。
私たちの仕事は一人の人間が孤立した状態でこなせるようなものではなく、チームで行うべきものである。
ゆとりのない組織は権威主義的になりがち、
効率をもとめると意思決定は分散できない（権限委譲できない）
これは大量の仕事を片付けるにはよい方法だが、再生と学習を促進する方法としては悲惨。
再生ができる人に権限もゆとりもない。
変化は管理できない。
業績→報酬ではないし、がんばって失敗している人と、変化しようとしない人の区別がつかない。
そして知的労働者の管理は変化の管理に近い。
これまでの計画（ソフトウェアの工程）は、最初からリスク管理をしていない、すべてがうまくいったときの過程でつくられている。
つまり、15回連続でブラックジャックに勝つといっているようなもの。
そんな不可能な計画は役にたたないばかりか害になる。
リスクをとるということは、余分なコストや遅れの可能性が生じるということ。
妥当なリスクをとって、スケジュールに余裕を持たせることは良い結果をもたらすことを、
縦軸に完成する確率、横軸に完成日をいれたグラフで説明。
リスク管理をすることで不確定性を数量化して明示できる。
不確定を許さない企業文化であっても、管理者がこのようなグラフをもっていることは重要。ただし企業全体でやるより効果は薄い。
著者の経験として5％の不確定要素をいれることを許容している企業があるが、ほとんど予測に成功しないのでみながウソをついているという。
しかし、ウソとわかっていても意欲的な管理者は評判がよい。しかしこの管理者はリスク管理とは正反対。企業には「できない」管理者が必要だ。この人は失敗に結びつくことが予想されるあらゆる可能性を報告する。
リスク管理の基本
全体リスクと部分リスクがある。
肝心なのは部分リスクを管理すること。
リスクを管理するとは
１ リスクを一つずつリストアップし数える
２ 新しいリスクを発見するプロセスを継続する
３ 各リスクが与えると予想される影響と、その確率を数量化する
４ リスクが現われ始めたことをなるべく早く知らせる変化の指標を設定する。
５ 万一、各リスクが現実のものとなりはじめた場合の対応計画を事前にたてておく
である。
また部分リスクの影響が重なった場合、全体的な成功にどのような不確定がおこるかモデル化する。
リスク管理は動的で時間経過とともに更新していく必要がある。
リスク制御
リスクが実現したら
影響を受け入れ、コストを支払い、そのまま先に進む。
そのために予算とスケジュールに柔軟性を持っておくことが重要。そうでなければそのための予算とスケジュールを得る為に余計な仕事をすることになる。
リスク0％の予算やスケジュールより、最初からリスク管理をした予算とスケジュールを持つ方が結局よい結果になる。
リスクの軽減
リスクが発生したときの計画をもっておく。
事前準備をしておく（火災訓練のようなもの）
知的労働者に「急げ」ということはリスク管理と矛盾する。
リスク管理は「急げ」＝危険速度よりは遅い速度（事前の講習など）になるので、完成は遅くなる。
確実に遅くなることを嫌い、危険速度での計画を立てたがる管理者が多い。
この結果の結果とコストを表で説明。
結局リスク管理のコストを払った方が、危険速度で失敗したときのコストより小さいと説明。
また危険速度で成功しても、それは来年のもうけを先に手に入れたようなもので、知的労働者の転職など、結局は企業にとって損失になるという。
現代は変化の時代であり、リスクをとることは必要なことである。
それなのにいたるところでリスクが回避されているのが不思議である。
リスクのない計画はやめるべきだ。そうでなければ生き残れない。
変化の激しい時代に変化のない時代の管理方法を適用しても、21世紀のビジネスにはついていけない。
変化のない時代の管理方法＝開発「工場」の構築、「仕事量」の「測定」、プロセス、品質管理、効率、投下資本利益率、無駄の管理、コスト削減
リスク管理のチェックリストがのっていて、あなたの会社で最もリスクが大きい部分を選んでチェックしてみて、ほとんどチェックできなかったらリスク管理できず、リスク回避している可能性があるといっていた。
効率がまったく重要でないといっているのではない。ほとんど重要ではないといっている。
効率で1ポイント稼げるとしたら、わずかなゆとりと、発想、工夫、リスクの受け入れ、人間関係の理解によって3ポイント稼げる可能性があるのだ。
知的労働者の労働は、工場労働者よりも「考える」比重が大きく、他の労働者に仕事を引き継いだり、分割したりするのは難しい。
知的労働者（とくに管理者）の効率をあげようとして、無駄な時間を探しだし、仕事時間を100％稼働時間にしようとするのは無理な話である。
短期的には効率の数字はあがるかもしれないが、実際にはパフォーマンスが落ちるし、なにより「やらされている」感じを労働者に与え「やる気」をそいでしまう。知的労働者は給与よりもやりがいを重視する傾向があるので、結果として優秀な人材が流出してその損害ははかりしれないことになる。つまり人件費を1円けずっても失うものがおおければ1円の利益にならない。
人的資本の損失計算例
人的資本＝代わりの人材がふつうの速さで仕事ができきるまでの期間×（給与＋間接コスト）×50％
人的資本の損＝人的資本の平均損失額×離職率
短期的なストレスが仕事の生産性をあげることは確かにあるが、常にあると生産性は低下する。
なぜなら、人間は時間的なプレッシャーをいくらかけられても、速くは考えられないから。
もともと知的労働者は無駄な仕事や、重要でない仕事はあとまわしにしているので、できるのは夜遅くまで働くことくらい。
ほとんどの知的労働者の給与は時間ではないので、長時間労働をすると生産性はあがったようにみえるが、実は生活の質がおちた労働者は仕事に手をぬきながらやっているふりをするか、転職を考えるようになるのだ。
効率を重視してアシスタントや事務の仕事を減らすことは、知的労働者がコピー取りをするということで、最終的は生産性をさげることになる。
開発者5人のチームより、開発者4人と事務アシスタント1人のチームのほうがコストは安い。
効果より効率重視で恐怖が支配する企業では、管理職は常に怒っていて、スケジュールは誰も守れると思えないほど強気であり、みなうまくいかないときの責任を押し付け合い、ときには責任をとらないですむように訴訟まで起こす。
納期を守るためにやるべきことはすべてやったようにみせるために、うまくいかないのを承知で人員を投入したりする。
これではよい製品などできるわけがない。
管理者の仕事は管理していると思われないように管理すること。その仕事は目に見える成果（製作物）がないので、無駄とおもわれがちだが、実は違う。忙しくしている管理者は管理以外の仕事＝やるべきことでない仕事をやっていると思って間違いない。多くの管理者が仕事をしていないと思われる恐怖から目に見える仕事をやってしまい、本来の仕事ができていない。
まちがった管理の第1法則
うまくいかないことがあったら、もっとやれ
まちがった管理の第2法則
自分自身のユーティリティ・プレーヤーになれ（自分でコピーをとれ）
規格はありがたいものだが、知的労働ではあまり役に立たない、うまくやっている社員は手順は人と同じだが他の人より他人とのつながりがゆたかであった。
手順や目標管理は知的労働には重要でない。必要なのは現場レベルに権限移譲をすることである。
危険は伴うがモチベーションは確実にあがる。
品質管理は、他はすべて同じで、ある部分だけ改善すれば、全体のパフォーマンスがあがるという考えなので間違っている。他がすべて同じなどという状況はビジネスにはない。
過剰なストレスのある企業は効率をおいかける。効果は考えられていないので、進む方向があっているかだれにもわからない。
またリスクをとることを回避するので、繰り返し意味のない選択をすることになる。
変化のないところには成長はない。
それなのに現状にこだわりながら当然のように成長を期待している組織によく会う。
現状維持から成長はない。
変化するためにはビジョンが必要。
変化が成功するためには変わらないものは何か、組織の存在意義はなにか（ピーター・ドラッガーがいうところの文化）を明確に理解している必要がある。それは変化してはならないものだから。
リーダーシップとは自分の課題に他の人たちを参加させる能力。
リーダーとして意味のある行動をとれば、人々は長期的な利益を高めるため、短期的な痛みをある程度受け入れる。
方向性を明示するだけではポーズだけである。短期的に痛みがあることを率直にみとめ、あとはフォローアップして、本当のリーダーシップである。
リーダーシップは組織図の下から上に昇ったり、空白を横切ったりする。だれでも能力をもっているのであり、使う責務がある。
活気ある企業は、フォロワーシップはない。結果として人に従うことはあっても、本質的にはリーダーシップは全員の任務であり、交替で担うものになっている。
変化には「安全」が必要である。
人間は仕事でアイディティティの一部を支えている、変化に対する抵抗は慣れ親しんだものを捨てることに対する恐怖である。しかし恐怖が変化を必ずさまたげるのではない。健全な恐怖は学習につきものである。それよりも、変化による失敗を嘲笑する行為は絶対にゆるしてはならない。苦労をうけいれ失敗をしたひとは貴重な教訓を残した尊敬すべき人である。この文化を確立しなければならない。
リーダーが信頼を得るには、信頼に足ることを示さなければならないが、新しいリーダーにはそれができない。
だから、親が用いる方法＝いつも信頼に足ることが示されるより少し前に信頼を与えるを行う。
権限移譲である。リスクを避けるタイプの人にはできないことである。
変化を起こすとしたら、業績がよく余裕があるときである。
傾きかけてから付け焼刃にやっても「ゆとり」がないので効果は薄い。
組織の変化＝再生がおこるのは中間管理職の層からであり、この層が管理に十分時間をとれる「ゆとり」をもつことが組織を柔軟に持続的に発展させることになる。
管理者の仕事は習得が必要な技術なのに、ほとんどの管理者は他の管理者に学ぶこともできず、通り一遍の研修だけで実践に投入され、熟練管理者と同じレベルのパフォーマンスをもとめられる。これでは無理がある。
学習とは、新しい仕事をベテランよりゆっくりすることに他ならないのに、急げというメッセージが学習を不可能にしている。
知的組織には「健全な」競争など存在しない。内部の競争はすべて破壊的である。
私たちの仕事は一人の人間が孤立した状態でこなせるようなものではなく、チームで行うべきものである。
ゆとりのない組織は権威主義的になりがち、
効率をもとめると意思決定は分散できない（権限委譲できない）
これは大量の仕事を片付けるにはよい方法だが、再生と学習を促進する方法としては悲惨。
再生ができる人に権限もゆとりもない。
変化は管理できない。
業績→報酬ではないし、がんばって失敗している人と、変化しようとしない人の区別がつかない。
そして知的労働者の管理は変化の管理に近い。
これまでの計画（ソフトウェアの工程）は、最初からリスク管理をしていない、すべてがうまくいったときの過程でつくられている。
つまり、15回連続でブラックジャックに勝つといっているようなもの。
そんな不可能な計画は役にたたないばかりか害になる。
リスクをとるということは、余分なコストや遅れの可能性が生じるということ。
妥当なリスクをとって、スケジュールに余裕を持たせることは良い結果をもたらすことを、
縦軸に完成する確率、横軸に完成日をいれたグラフで説明。
リスク管理をすることで不確定性を数量化して明示できる。
不確定を許さない企業文化であっても、管理者がこのようなグラフをもっていることは重要。ただし企業全体でやるより効果は薄い。
著者の経験として5％の不確定要素をいれることを許容している企業があるが、ほとんど予測に成功しないのでみながウソをついているという。
しかし、ウソとわかっていても意欲的な管理者は評判がよい。しかしこの管理者はリスク管理とは正反対。企業には「できない」管理者が必要だ。この人は失敗に結びつくことが予想されるあらゆる可能性を報告する。
リスク管理の基本
全体リスクと部分リスクがある。
肝心なのは部分リスクを管理すること。
リスクを管理するとは
１ リスクを一つずつリストアップし数える
２ 新しいリスクを発見するプロセスを継続する
３ 各リスクが与えると予想される影響と、その確率を数量化する
４ リスクが現われ始めたことをなるべく早く知らせる変化の指標を設定する。
５ 万一、各リスクが現実のものとなりはじめた場合の対応計画を事前にたてておく
である。
また部分リスクの影響が重なった場合、全体的な成功にどのような不確定がおこるかモデル化する。
リスク管理は動的で時間経過とともに更新していく必要がある。
リスク制御
リスクが実現したら
影響を受け入れ、コストを支払い、そのまま先に進む。
そのために予算とスケジュールに柔軟性を持っておくことが重要。そうでなければそのための予算とスケジュールを得る為に余計な仕事をすることになる。
リスク0％の予算やスケジュールより、最初からリスク管理をした予算とスケジュールを持つ方が結局よい結果になる。
リスクの軽減
リスクが発生したときの計画をもっておく。
事前準備をしておく（火災訓練のようなもの）
知的労働者に「急げ」ということはリスク管理と矛盾する。
リスク管理は「急げ」＝危険速度よりは遅い速度（事前の講習など）になるので、完成は遅くなる。
確実に遅くなることを嫌い、危険速度での計画を立てたがる管理者が多い。
この結果の結果とコストを表で説明。
結局リスク管理のコストを払った方が、危険速度で失敗したときのコストより小さいと説明。
また危険速度で成功しても、それは来年のもうけを先に手に入れたようなもので、知的労働者の転職など、結局は企業にとって損失になるという。
現代は変化の時代であり、リスクをとることは必要なことである。
それなのにいたるところでリスクが回避されているのが不思議である。
リスクのない計画はやめるべきだ。そうでなければ生き残れない。
変化の激しい時代に変化のない時代の管理方法を適用しても、21世紀のビジネスにはついていけない。
変化のない時代の管理方法＝開発「工場」の構築、「仕事量」の「測定」、プロセス、品質管理、効率、投下資本利益率、無駄の管理、コスト削減
リスク管理のチェックリストがのっていて、あなたの会社で最もリスクが大きい部分を選んでチェックしてみて、ほとんどチェックできなかったらリスク管理できず、リスク回避している可能性があるといっていた。
効率がまったく重要でないといっているのではない。ほとんど重要ではないといっている。
効率で1ポイント稼げるとしたら、わずかなゆとりと、発想、工夫、リスクの受け入れ、人間関係の理解によって3ポイント稼げる可能性があるのだ。
- 作者: トム・デマルコ
- 出版社/メーカー: 日経BP社
- 発売日: 2001/11/26
- メディア: 単行本
タグ：トム・デマルコ
人月の神話―狼人間を撃つ銀の弾はない [プログラミング]
著者はIBMのシステム/360の開発マネージャーをしたひとで、最初の版は1975年に出版された。
ソフトウエア開発について述べた本がほとんどないなかで大きな反響を呼び、この版は20周年記念の増補版
なぜソフトウェア開発（特に大規模なもの）は予算も工期も予定通り進まないのか？
それは人と月が交換可能だという神話による。人を増やせば、その分その人の教育、これまでの情報の伝達が必要で、コミュニケーションの手間がかかることになる。だから生産性はかえって低下するのだ。しかもプログラマの生産性は調査によると10倍の差があるという。これをすべて均一な能力があると見積もるのも無理がある。
ソフトウェア開発で大切なのはアーキテクトの一貫性である、デザインと実現はわけるべきである。そして外科手術のようにチームで役割分担して仕事をすべきである。そして最初からアーキテクトの一貫性をつらぬく仕掛け(プログラム手引書など）をもつべきである。
絶対的に有効な処方箋はないにしても、役割を分担すること、手引書、打ち合わせ、電話などのコミュニケーションをとることで被害をもっとも小さくすることができるはずだ。
第1章 タールの沼
大規模開発チームが長い期間かけてつくりあげたものより、二人のプログラマがガレージでつくったものの方が優れているという意見がある。しかし、大規模開発チームはなくなってはいない。その理由は作り出されるものの違いである。
プログラム自体をつくりだすのは短くても、それをプログラミング製品にするには、一般化、テストメンテナンスとその3倍の時間がかかり、プログラミングシステム（システム統合のインターフェース）にするには3倍の時間がかかる。この両方を兼ね備えたプログラミングシステム製品となると、プログラムの実に6倍の手間がかかるのだ。
プログラミングは創作意欲を満たす楽しい作業であるが、呪文を一句たりともまちがえてはいけない魔法であり、大規模になると他人のプログラムに依存することが必要になり、そのための時間がとられていくようになる。そしてデバックは果てしなく続くしらみの卵探しである。そうしてやっと作り上げたものは時代にあわなくなっていたりするのだ。
第2章 人月の神話
プログラマはみな楽観主義者である。「今度こそきっとうまくいく」「バグはこれが最後」と思っている。それを前提にスケジュールをたててしまう。しかし私たちのアイデアの不完全さや不整合性は実現段階になってはじめてわかるのだ。すべての仕事がうまくいく確率はゼロに近い。
仕事の単位「人月」はあやまり、仕事の大きさを測る単位としての人月は疑うべき危険な神話。人と月は交換できない。
人と月が交換できるのは作業者の間でコミュニケーション（意思疎通）を図らなくても仕事が分担できる場合である。コミュニケーションを図ることで増える負担は教育・訓練と相互コミュニケーションからなる。負担の増加分は要因にあわせて増えるので、要員をふやしてもスケジュールは短くならない。
楽観主義者たちはバグの数を実際より少なくみつもって間違ったスケジューリングをしてしまう。著者の目安、1/3計画、1/6コーディング、1/4単体テストおよび初期テスト、1/4システムテスト。特にシステムテストには十分時間をかけるべきである。
見積りの精度をあげるには、生産性やバグの発生率の数量化、見積り基準の開発をすること。
遅れているソフトウェアプロジェクトへの要因追加はさらに遅らせるだけの例。
第3章 外科手術チーム
少数精鋭チームが、何百人もの二流プログラマを抱えたプロジェクトより望ましいという意見がある。その通りではあるが、大きなシステムをつくるときには少数精鋭チーム（通常10人以下）では時間がかかりすぎる。確かに効率性とコンセプトの完全性は小数精鋭チームがよいが、時間がかかりすぎればタイムリーに製品をだせなくなる。
ハーラン。ミルズは大規模な仕事の各セグメントに外科手術チームのように編成されたチームでとりくむことを提唱している。デザインと構造は少ない人数で考えだし、実際の作業開発には人をたくさん投入する。
外科手術チームをモデルに考えたプログラミングチームの役割分担
執刀医・・・チーフプログラマ、プログラムをデザインしコーディングしテストしてドキュメントを書く。プログラムのバージョン管理のほか、文書管理にもアクセスできる。才能と10年以上の経験がある。
福執刀医・・・執刀医の分身で、どの仕事もこなせるがまだ経験の浅いもの。
管理者・・・執刀医はボスであるが、人事や昇給設備には手がまわらないので、そこを補う。
編集者・・・執刀医の文書作成をたすける
二人の秘書・・・管理者と編集者につける
プログラム事務係・・・チームの技術記録全般のメンテナンスをうけもつ。これによりプログラムコードが個人のものではなく、全体のものであるという認識ができ、プログラミングを個人の技術から集団の技術に変えることができる。
ツール製作者・・・用途の限られたユーティリティやカタログ化されたプロシージャやマクロライブラリを作成する。
テスト担当者・・・制作中と終わってからの全体をテストするためのテストケースを用意する、テスト環境を整える。
言語エキスパート・・・プログラミング言語の複雑さを習得することに喜びを覚える人をこれにあてる。言語を巧妙に効率よく使うための助言を求める。一人の言語エキスパートが2-3人の執刀医をサポートする。
こうすることで、システムそのものは一心同体の二人が考えだしたものになる。
また、主従関係がはっきりしているので、判断をめぐって相違がでない。役割が特化されているのでコミュニケーションが簡素化される。
大規模開発チーム（5千人年）にこのコンセプトをとりいれるには、各部分でのコンセプトの完全性が根本的にかいぜんされてデザイナーの数が1/7になれば成功である。調整には独自のテクニックがいるが、トップダウンでシステムアーキテクトがデザインされることが肝要である。
第4章 貴族政治、民主政治、そしてシステムデザイン
コンセプトの完全性ことはシステムデザインにおいてもっとも重要な考慮点。
機能と簡潔さの比率がシステムデザインの究極の試金石。どちらかだけではいけない。
大規模プロジェクトではアーキテクチャとインプリメンテーションを切り離すことはコンセプトの完全性を得る強力な方法。
システムのアーキテクチャとは、ユーザーインターフェースについての完全かつ詳細な仕様書である。コンピュータにとってはプログラミングマニュアルであり、コンパイラにとっては言語マニュアルである。
「アーキテクチャは何が起こるかを語るのにインプリメンテーションはいかにして起こせるかを語るのだ」
アーキテクトだけがアーキテクチャについてよいアイデアをもっているわけではない。しかしコンセプトと合わないものはすぐれた機能やアイデアでも除外することがいい。コンセプトの完全性をもとめるなら、だれかがコンセプトをコントロールしなければならない。
アーキテクチャの外部規定はインプリメンテーションの創造性を拘束するのではなく、むしろ高める効果があることをみてきた。
アーキテクトが決定するまでインプリメンテーション担当はすることがない。だからといってインプリメンテーショングループに仕様書作成をまかせてはいけない。仕様書ができるまでは、システムの機能の大雑把な概要をもとに、システム構成の理解や、モジュール境界、テーブル構造、工程の細分化、アルゴリズム、ツールデザインなどの仕事があるし、アーキテクトとのコミュニケーションも必要だ。
実現段階でも、プログラミング技法の選定や、機械の習得など多くのすべきことはある。
経験上、統合されたシステムの方がより早く調和し、テスト時間が短くなることが実証されている。
第5章 セカンドシステム症候群
アーキテクトの創作意欲に弾みを与えるのはアーキテクトと実現者の間で交わされる徹底的で注意深く、さらに相手の立場を考慮したコミュニケーションである。
見積りが高くなりすぎる場合、アーキテクトはデザインを切り詰めるか、インプリメンテーションを安く抑えるかを選ぶ、後者を選ぶなら感情的対立を避ける為に穏やかに非公式に、インプリメンテーション側に創意工夫および創造の責任があることを常に忘れないようにすること。相手の提案をうけいれるようにすること。通常実現者はアーキテクトを変更するという提案で対抗してくる、それが正しいこともよくある
最初の仕事は自生して、余計な機能やアイデアはいれないでいられるが、二度目はこの時制がきかなくなってしまうことがよくある。また時の流れとともにシステムの基本的前提が変化して技術自体がすでに時代遅れの考え方になっているのに、それを改良しようとする間違いもよくある。
これらを踏まえた十分な自己鍛錬がアーキテクトには必要である。
第6章 命令を伝える
マネージャがアーキテクトの決定内容を全員にしらせ、コンセプトを維持するために、仕様書とマニュアルは必要なツール。つくるときには一人かせいぜい二人で一貫性が必要。制限事項(規定されていないもの）を定義する。
定義を周知徹底させるため、パラメータもしくは強要ストレージの宣言をデザインしてきめてコンパイルする方法がある
ミーティングは2階層で、第一階層はアーキテクト全員とハードソフトの実現者の代表と市場規格車を加えた週に半日の会議。ここで蓄積された予測されなかった問題や、抗議や不満を解決するための年1回の全体会議が2週間。本当は半年がよかったとおもうそうだ。
システム/360のアーキテクトは複数のインプリメンテーションの同時開発が行われ、仕様書を徹底させるうえで抜群の働きをした。
インプリメンテーションが進むといかに仕様書が的確でも解釈の疑問が出てくる、ここで困惑した実現者に推察して先にすすまれると困るので、アーキテクトに電話させるのは大切なこと、そしてそれを記録する。
仕様書に即して機械とプログラムをチェックし、重箱の隅をつつく製品テストグループは製品マネージャにとって最良の友。最終的には顧客が独立した監査役である。
第7章 バベルの塔はなぜ失敗におわったか
どんな崇高な目的や機材があってもコミュニケーションとそれから生まれる組織がなければプロジェクトは失敗に終わる。
チームの相互のコミュニケーションをとる方法
・非公式な方法による電話サービス
・定期的ミーティング
・手引書
プロジェクト手引書は、プロジェクトで作成される文書はプロジェクト手引書の構成に従わなくてはならない。構成が先にあることで良質なマニュアルが生まれる。情報を伝達し、すべの必要な人に伝わるようにするために手引書は必要。OS/360では先に手引書をつくり書くプログラマが全資料を読まなくてはいけなくした、またタイムリーな更新をおこなった。手引書が厚くなったのでマイクロフィッシュに切り替えたという。方法はともかく今でも手引書は必要とされている。
コミュニケーションは人数が増えるにしたがって必要になる。不要にするには作業の分割と機能の専門化しかない。
プロジェクト開発組織には制作主任＝マネージャと技術主任＝アーキテクトが必要。
小規模なら両方を一人できるが、二人いる場合はその関係がどのようであれば成功するか述べていた。
第8章 予告宣言する
独立した小さいプログラム開発のデータはプログラミングシステム製品にはあてはまらない。
ICLのチャールズ・ポートマンの調査ではプログラマは機械の故障やミーティング、事務、病気などで時間の半分しかプログラミング・デバッグにあてられていなかった。一人あたりの作業時間数がまちがっていたのである。
いろんな大規模プロジェクトにおける生産性のデータ。作業そのものの複雑さと難しさで生産性の違いがある。適切な高水準言語を使うと生産性はあがる可能性がある。
第9章 5ポンド袋に詰め込んだ10ポンド
プログラムが占めるスペースは主要なコスト。システムデザイナはそれが何をしてくれるものなのか考えて常駐させるか決定し、プログラマはなるべくコストを抑えるテクニックを考えるべき。
常駐スペースだけでなく、全体サイズの割り当ても行う。そうしないと実行スピードが(ハードウェアアクセスによって）おそくなる。モジュールのすべきことを明確にし、サイズを指定せよ。
メモリとスピードはトレードオフである。うまく対処できるようにプログラミングテクニックの習得を十分にさせ、なるべく短期間で学び共有する必要がある。またコンポーネントを汲みたてなければならないということを認識させよ。
職人技をこえたところにアイデアがあり、簡潔で余分なところがなくて
スピードの速いプログラムが生まれるのは戦略的突破である。これは新しいアルゴリズムである場合もあるが、むしろデータやテーブル表現のやり直しの場合が多い。
第10章 文書の前提
ソフトウェアプロジェクトで文書が実際どのように機能するのか理解し、役立てる。
コンピュータ製品のための文書の例
大学の学部のための文書の例
ソフトウェアプロジェクトのための文書の例
マネージャの仕事は計画を作成してそれを実現することだが、文書化された計画の実が明確で伝達可能だ。
何を・いつ・いくら・どこで・だれがという文書が構成されるはずだ。そしてその重要性がわかれば、マネージャーは文書作成を面倒な仕事でなく、使いやすい道具として対処できる。
第11章 一つは捨て石にするつもりで
化学工業では研究所でうまくいく工程でも工場では一足飛びに実施できないことがわかっていた。プログラミングシステム製作も同じである。最高のプランニングでさえも一回で成功するほどには計算されつくされていない。
不変なものは変化そのものだけだ。だｋら変化に備えるシステム計画＝変更の量子化、組織計画＝IBMの二重昇進機構が必要なのだ。
プログラムは配布されたあとも変化する＝プログラムメンテナンスがあるのが普通。
MITのベティ・キャンベルの研究ではインストール後の経過月数と1か月のバグ発見数は、一時おちたあと、再び上昇するそうだ。これはごく小さな欠陥がなにか局所的エラーに見えるが、実際にはシステム全体の問題であることが多いからである。修正の際に以前のシステムテストをすべて実施することはできないので、副作用が発生するのだ。
M・レーマンとL/ベラディの大規模オペレーティングシステムのリリース研究によると、リリース番号とともにモジュールの総数は線形に増加するが、影響をうけるモジュールは指数的に増加するとわかった。修正は創造を破壊する。常に最初が最高の状態であるのだ。プログラムメンテナンスはどんなに器用におこなっても、エントロピー増大なのだ。
第12章 切れ味のいい道具
熟練した機械工は長年にわたり収集し、大切にしまって守ってきた7つ道具をもっている。
熟練したプログラマも同じように、自分用に役に立つユーティリティをもっているものだ、これをチームで使えるように専門のツール製作者をおこう。
マネージャーが方針をたてて計画するのはソフトツールだけでなく、コンピュータ設備、オペレーティングシステム、言語、ユーティリティ、デバック支援、テストケース生成、文書作成用テキスト処理システムである。
ひとつひとつ解説していた。
もっとも重要なのは高水準言語と対話型プログラミングといってた。
第13章 全体と部分
どのようにしてきちんと動くプログラムを作るのか？どのようにプログラムをテストするのか、テスト済みにコンポーネントプログラム一式を統合し信頼できるシステムにする方法は？
・バグを取り除くデザインにする。
コンポーネント間の前提の不整合、コードが出来上がる前に仕様書をテストする、トップダウンデザイン、構造化プログラミング
・コンポーネントのデバッグ
デバッグ方法の変遷、機械上でのデバッグ、メモリダンプ、スナップショット（選択ダンプや選択トレース）、対話型デバック、テストケース
・システムデバッグ もっとも予想外に困難なもの
デバッグ済みコンポーネントを使う、十分な足場固めをする（すべてのプログラムとデータ、あるいはダミーコンポーネントとミニチュアファイル、補助プログラムによる分析やテストケース生成）、変更の統制方法をもつ、一回に追加するコンポーネントは一つにする、更新を量子化する
第14章 破局を生み出すこと
たいていの遅れは日ごとに発生し蓄積し、気づくことも予防することも取り戻すことも困難になる。
スケジュールにマイルストーンを置く、これは具体的で明確で測定可能なイベントでなければらなない。
どうせ他の部分もおくれているんだからは、使ってはいけない口実
上司は行動をとるための情報と状況を理解するための情報を区別して、行動にはたちいらないよう自制すべき。ミーティングは状況検討のためか、問題対策のために開くのかはっきり区別する。
こうしたプランをコントロールするグループをもつことはとこても有効である。
第15章 もう一つの顔
書き上げられたプログラムは人間から機械へのメッセージであるか、人間の利用者に語りかける顔をもつ。
プログラムを使用するために必要な文書を解説。
プログラムを信用するために必要な文書(正常に実行されているか）
プログラムを修正するための文書、フローチャートは過大評価されている。
ソースに文書を組み込む自己文書プログラムを推奨していた。ソースコードが増大するが、その価値はある。
第16章 銀の弾などない ソフトウェアエンジニアリングの本質と偶有的事項
すべてのソフトウェアの構築には本質的作業として抽象的なソフトウェア実態を構成する複雑な概念構造体を作り上げることと、偶有的作業としてそうした抽象的実在をプログラミング言語で表現し、それをメモリスペースとスピードの制約内で機械言語に写像することが含まれている。
過去のソフトウェアの生産性における大きな収穫のほとんどは、偶有的作業をはなはだ困難にする人為的障害を除去すること（きびしいハードウェアの制約、扱いにくいプログラミング言語、機械使用時間の不足など）で得られた。これからは本質的な部分について議論すべき。
狼人間を倒す銀の弾のように、ハードウェアのコストを下げるのと同じように、ソフトウェアのコストも劇的に下げてくれる特効薬を私たちはもとめるが、10年間は（1986年から）ありそうもない。しかし王道はなくても道はある。
ハードウェアの発達があまりに速いために、ソフトウェアはまったく進歩していなくみえるということもある。
ソフトウェア構築において困難な部分は、この概念構造体の仕様書作成とデザイン・テストにあって、表現することやその表現に忠実化をテストすることではない。構文上の誤りはコンセプトの誤りに比べると大したことはない。
ソフトウェアの基本的要素に含まれる固有の性質は、複雑性（どの二つの部分をとっても似ることがない、そしてソフトが大きくなると複雑性が非線形的に増す、そして技術も管理も信頼性がなくなる）、同調性（物理のように統一原理はなく、最後に登場したもの、従わせやすいとみなされるものに従う）、可変性（常に変更という圧力にさらされていて、そして制作されたものより容易に変更できるのでさせられる）、不可視性（視覚化できない、そのため一人の人間のデザインプロセスを妨げるだけでなく、コミュニケーションの妨害になる）
過去にもっとも成果のあったソフトウェアテクノロジーの三段階の発展、いずれも偶有的困難で本質的ではない。高水準言語、タイムシェアリング、統一されたプログラミング環境
銀の弾になる可能性があるものとして最も発展をとてげている技術
・Adaとその他の高水準言語の進歩。Adaの哲学（デザインとモジュール化概念）は言語以上に進んでいるが、機能が豊富すぎるし、言語である以上は銀の弾にはならないであろう
・オブジェクト指向・・・デザインの本質を表現するのに向いているが、デザインの複雑性は本質的で、それを変えることはできないので銀の弾になりえない
・人工知能・・・問題ごとに技術が異なるので期待できないと思う
・エキスパートシステム・・・一般化した推論とルールベースを持つプログラム、ただしつくるのにエキスパートがいる
・「自動」プログラミング・・・整ったケース（ソートや微分方程式）ならできても、通常はそうではない
・ビジュアルプログラミング・・・フローチャートから製作するのだが、フローチャートはソフトウェア構造を抽象化するにしては貧弱、現在のピクセルで表示される画像はソフトウェア構成図の詳細を表示するには範囲と解像度の両方で貧弱。そしてソフトウェアの視覚化は難しい。
・プログラム検証・・・膨大な労力を投入して実現やコストを行う前にデザインを修正しようという考え、これを行ってもプログラムが仕様書とあっていることを立証するだけで、完全で一貫した仕様書を作る役にはたたない
・環境とツール・・・階層型ファイルシステム、統一ファイルフォーマット、一般化されたツールは役にたっている。やがては統合データベースシステムが役にたつ。しかし本来の性質からあまり役にたちそうもない
・ワークステーション・・・プログラムや文書作成には十分。コンパイルはまだ早くなるだろうが、プログラマの思考時間は短くはならない
コンセプトの本質への有望な戦略
・購入対自主製作・・・製作のコストを購入者全員で負担するから安い。スプレッドシートと簡易データベースとう劇的なツールにより、多くの企業にとってソフトウェア生産性をあげる最強にして唯一の戦略は、コンピュータ初心者の知的労働者にPCとすぐれた汎用ワープロ、描画プログラム、ファイル管理プログラム、スプレッドシートを与えることであり、科学者なら数学や統計の汎用パッケージと若干の単純なプログラミング能力があればいいということになる。
ソフトウェア構築のもっとも困難な部分は、何を構築するのか的確に決定すること。そして顧客自身も自分の欲しいものがわかっておらず、しかも自分が要件を指定した製品を数バージョン使ってみなければ、正しい要件を指定することは不可能。だからソフトウェア問題に対する技術的な努力でもっとも有望で、偶有的事項でなく本質を攻略するものは、対話しながら要件を指定していく方法の一部としてシステムのプロトタイピングを迅速に行うアプローチの仕方とツールを開発すること。
ソフトウェアを建築にたとえ、構築するといったのは強力なメタファーだったが、今日では構築する概念が複雑すぎて前もって正確に指定することができず、欠陥なしに構築できないので、アプローチを変えるべき。複雑な生命をモデルに脳のようにソフトウェアを育てる＝漸増敵開発と考えてみる。この方法はトップダウンのデザインを伴うので後戻りが容易で、初期のプロトタイプがそのまま使え、追加された機能や新しく加えたものが、すでにあるものから生物の器官のように育っていく。しかもすでに稼働中のシステムは「やる気」を跳ね上げる効果がある。著者の演習で証明されているそうな。
ソフトウェア技法の改善はまず人間の問題に集中する。すぐれた練習法は教えることが可能。しかし、優れたデザインと偉大なデザインとの差は、偉大なデザイナーかどうかで決まる。ソフトウェア構築は創造的プロセスであり、こつこつ仕事をする人＝優秀なデザインができるひとを、偉大なデザイナーにすることはできない。だから偉大なデザイナーを開発する努力をソフトウェア会社や団体はするべきだ。
第17章 「銀の弾などない」再発射
銀の弾などないの論文にはたくさんの反論がきた。主に自分は銀の弾を開発したというものだ。著者は自腹で購入した利用者が正真正銘、これを使ったらソフトウェアの生産性が10倍改善された」といったら銀の弾が発射されたとみなすと書いていた。
偶有的は偶発発生したとか災難ではなく、副次的とか付随の意味でつかっている。ソフトウェア開発ではインプリメンテーションのことである。
作業の偶有的または表現的部分は全体の半分以下に減っているというのが著者の主張。
ソフトウェアの難しさは概念構造体をつくる部分=本質にあるといっているのあって、再利用可能で互換性のあるコンポーネントで改善できるのは偶有的部分である。
ソフトウェア構造体における概念上の複雑性の大半は、アプリケーションそのものの自由さがもたらす複雑性からきている。ソフトウェア構造体における複雑性の大半は、外部世界への同調性によるものというよりは、むしろデータ構造やアルゴリズム、それに接続性などといったインプリメンテーション自体によるものだ。以前に作ったものを再利用したり、他の人が構築したものをつかうことで複雑性の全階層に直面しなくて済む。また階層化したモジュールやオブジェクトをもつ、漸増性は必要な複雑性であると述べている。
あまりに悲観的という意見もあるが、1986年当時に進行中のさまざまな改革が十分に開発利用された場合、それらを結び付けて生産性における大規模な改善が達成できると予想している、王道はないが道はある。ソフトウェアの本質そのものが銀の弾など見つからないようにさせていると書いたつもりだ。
1986年当時の銀の弾候補を個別に論じて却下したのは、どれも決定的秘薬であるとはいえなかったからだ。
ハレルは「銀の弾などない」が1952年にかかれたと仮定して思考実験をした＝背理法。でもそれは使えない。規模もちぐので。ハレルの主張するモデル化技法「バニラフレームワーク」は銀の弾候補である。またソフトウェアの概念構造体の多くが本来はまったく位相的であり、関係は空間的、図形的に自然に写せるといっている。著者の主張はソフトウェア構造は三次元空間に埋め込まれているのではないから、概念的デザインから図式への一つの自然な写像を得ることはできないということであって、まったくできないということではない。
ジョーンズは生産性より品質に焦点をあてるべきで、生産性は後からついてくると主張。系統だった品質管理の欠如はスケジュールの破たん殿相関関係があるというデータを提供している。
生産性を示す値は今きちんと定義されたものはない。しかしパッケージを購入することが生産性をあげることは証明されたと思っている。
オブジェクト指向の成長が遅かったのは程度のあまり高くない抽象化をおこなっていたからと主張する人がいる。事前のコストが高くつくのだ。
ソフトウェア構築の本質を攻略する最良の方法は全然構築しないこと。または再利用。継承して再利用というのはオブジェクト指向技法のもっとも大きな魅力。しかし、やってみると意外とてこずることもある。再利用はいま企業ではほとんどされていない。もっとも統計もあまりとられていないのだが。
思考レベルが高くなれば、取り扱わなければならない初歩的試行要素も多くなる。だからプログラミング言語は機械言語より複雑で自然言語はもっと複雑なのだ。再利用にはプログラミング語彙の大きさも関係してる。言語の習得法帆運い関する研究と知見が必要。
解決策についての要点は変わっていない。複雑性がわれわれのとりくんでいる仕事である、制約しているものである。登場しそうもない解決策＝銀の弾を待っているのではなくて、可能性のある漸増的な改善をすすめていくべきだ。
第18章 「人月の神話」の命題－真か偽か
1975年の提言のうち、データと経験によって支持されたもの、反証されたもの、時代遅れになったものを判断できるように、各章の真髄を並べたもの。
第19章 「人月の神話」から二十年を経て
人月の神話の息がながいのは、ソフトウェア開発という分じゃが正常に適切に進歩していないからだという意見がある。ハードウェアの生産性が二十年で千倍になっているので余計にそうみえるのだろう。しかしハードの方が異常なのだ。またソフトウェアについてではなく、チームでモノを作る方法について書かれているからだともいわれるが、当たっていると思う。
書いたときも正しく、現在も相変わらず正しいことについて考える。
・中心になる主張 コンセプトの完全性とアーキテクト
大規模プロジェクトで利用者という一人の頭脳から見たコンセプトの統一性をとるためにプロジェクト管理をするには、小規模プロジェクトとは異なる周到かつ大胆な管理行動が必要。アーキテクトは一人にする。アーキテクチャはインプリメンテーションと実現から分離する。アーキテクトの再帰利用（大きな製品は一人ですべてのアーキテクチャをこなせないので、サブシステムにわけて主任アーキテクトを置く）、コンセプトの完全性こそ、製品の品質にとって中心的なものであるという主張は、現在もより確信をもっていることである。
・セカンドシステム症候群－多機能主義と度数推測
汎用ツールをデザインする方が、特別な目的のツールをデザインするより難しい。多様な利用者のさまざまなニーズに重みづけをしないといけないので。市場が要求していると多機能主義に陥るにつれ使いやすさは消える。利用者群を定義すること、度数を推測するべきである。あいまいなままでいるより、明白に間違っているとわかる方がずっとまし。
・WIMPインターフェースの勝利
WIMP・・・ウィンドウ、アイコン、メニュー、ポインティングインターフェース、はコンセプトの完全性をもったユーザインターフェースの最高の例。メニューの使い勝手(コマンド＝動詞と名詞を指定する方法）を例に利用者の力と使いやすさのバランスをとるのもアーキテクトの直面する問題を述べていた。著者は1世代でWIMPは歴史的遺物になり、音声が動詞を表現する適切な方法になるといっている。
・捨て石にするつもりで構築してはならない－ウォーターフォールモデルは間違いだ
一つは捨て石にするつもりでは間違いであると考えるようになった。インプリメンテーションでアーキテクトはの修正がわかったら上流にもどることが必要、漸増的モデルの方が勝っている。どの段階でも実働システムがあり、それが「やる気」を引き出す。利用者による早期テストも行えるのだ。ソフトウェア製品を関連製品のファミリーとしてデザインするのはデービット・パルナスの考えで、変更されることがないと見込まれるデザイン部分の根元付近を基本製品においている。マイクロソフトは「毎晩構築」アプローチを使っている。
・情報隠ぺいに関して、パルナスは正しく私は誤っていた
モジュールコードは適切に定義されたインターフェースを使って隠ぺいすべきだというパルナスの主張を否定したが、今ではソフトウェアデザインのレベル上げる唯一の方法と確信している。パルナスの定義はオブジェクト指向プログラミングの知的先祖で、抽象データ型、継承、再利用のためにデザインされテスト済みのモジュールライブラリまたはクラスのアイデアである。
・人月はどの程度神話的なものか－べーむのモデルとデータ
バリー・ベームが63種類のソフトウェアプロジェクトについて行ったものによると、要員と月数の間のトレードオフは線形どころではなく、人月は生産性の尺度としては実に神話的だとするものであった。そしてコスト曲線についていくつかの発見をした。要員追加についての、細かい研究によると、どのようにどんな要員を追加するかについて有益な知見も得られている。やみくもな要因追加がプロジェクトを破たんさせるのはいうまでもない。
・人間がすべて（そう、だいたいのところは）
ピープルウェアは大きな収穫。技術的というより社会的。プロジェクトの移動をチームの融合の観点から注意を払っている。
・力を断念する力
創造性は個人から発するもので工程や組織から発生ｓるものではない。だから創造性を伸ばす組織と工程を感がることが必要だ。権限委譲である。
・最近あった最大の予想外の事件は何か？－何百万台ものコンピュータの普及
マイクロコンピュータ革命がコンピュータの利用方法を変えた。シューマッハの主張がかないつつある。マイクロコンピュータ革命がソフトウェアの構築方法を変えた。ネットワークの利用で変更やテストが楽におこなえるようになった。
・まったく新しいソフトウェア産業－パッケージソフトウェア
古典的ソフトウェア産業は分裂し、アプリケーションユーザーは細分化している、一方で機能豊富なソフトウェアパッケージが一人のプラグラマの一日のコストより少ない値段で購入できるようになった。OSの世界は小数に収れんした。
・購入して構築する－パッケージソフトをコンポーネントとして
これは概念構造体を作り上げることの本質を攻略するものだから急速に成長していくだろう。パッケージ利用者は、そのままの利用者、メタプログラマ、外部機能作成者、一つあるいは複数のアプリケーションをより大きなシステムのコンポーネントとして使用するメタプログラマに分類される。アプリケーション群のなかで相互作用をコントロールするスクリプト言語があると実に効果的。
・ソフトウェアエンジニアリングの現状と将来
化学工学とソフトウェアエンジニアリングの展開には類似点がある。パルナスはソフトウェアは電気工学のように数学的基礎をもったエンジニアリングとして展開できないといっている。ソフトウェアエンジニアリングは、経営工学同様、人間の行動の複雑性によって永久的に混乱させられるものなのかもしれない。ただし、絶望的なわけではなく、未熟なだけだと思う。当分はタールの沼であるであろう。しかし展開させていくことはできる。
エピローグ 五十年間の不思議 興奮 それに喜び
著者が13歳のときハーバード・マークIの記事を読んで、知識を大きなハイパーテキストのおりものとして構成し、既存の道に従いながら新しい連想の先鞭をつけるような機械を利用者に与えるという提案に興奮した。その後コンピュータの道をすすみつづけたが、この分野は爆発的に進歩してきている、すべてを把握することは難しくなり、周辺分野をすてているくらいだ。コンピュータ関連分野は進歩のスピードをゆるめず、終わりも見えない。これからますます楽しみだ。
ソフトウエア開発について述べた本がほとんどないなかで大きな反響を呼び、この版は20周年記念の増補版
なぜソフトウェア開発（特に大規模なもの）は予算も工期も予定通り進まないのか？
それは人と月が交換可能だという神話による。人を増やせば、その分その人の教育、これまでの情報の伝達が必要で、コミュニケーションの手間がかかることになる。だから生産性はかえって低下するのだ。しかもプログラマの生産性は調査によると10倍の差があるという。これをすべて均一な能力があると見積もるのも無理がある。
ソフトウェア開発で大切なのはアーキテクトの一貫性である、デザインと実現はわけるべきである。そして外科手術のようにチームで役割分担して仕事をすべきである。そして最初からアーキテクトの一貫性をつらぬく仕掛け(プログラム手引書など）をもつべきである。
絶対的に有効な処方箋はないにしても、役割を分担すること、手引書、打ち合わせ、電話などのコミュニケーションをとることで被害をもっとも小さくすることができるはずだ。
第1章 タールの沼
大規模開発チームが長い期間かけてつくりあげたものより、二人のプログラマがガレージでつくったものの方が優れているという意見がある。しかし、大規模開発チームはなくなってはいない。その理由は作り出されるものの違いである。
プログラム自体をつくりだすのは短くても、それをプログラミング製品にするには、一般化、テストメンテナンスとその3倍の時間がかかり、プログラミングシステム（システム統合のインターフェース）にするには3倍の時間がかかる。この両方を兼ね備えたプログラミングシステム製品となると、プログラムの実に6倍の手間がかかるのだ。
プログラミングは創作意欲を満たす楽しい作業であるが、呪文を一句たりともまちがえてはいけない魔法であり、大規模になると他人のプログラムに依存することが必要になり、そのための時間がとられていくようになる。そしてデバックは果てしなく続くしらみの卵探しである。そうしてやっと作り上げたものは時代にあわなくなっていたりするのだ。
第2章 人月の神話
プログラマはみな楽観主義者である。「今度こそきっとうまくいく」「バグはこれが最後」と思っている。それを前提にスケジュールをたててしまう。しかし私たちのアイデアの不完全さや不整合性は実現段階になってはじめてわかるのだ。すべての仕事がうまくいく確率はゼロに近い。
仕事の単位「人月」はあやまり、仕事の大きさを測る単位としての人月は疑うべき危険な神話。人と月は交換できない。
人と月が交換できるのは作業者の間でコミュニケーション（意思疎通）を図らなくても仕事が分担できる場合である。コミュニケーションを図ることで増える負担は教育・訓練と相互コミュニケーションからなる。負担の増加分は要因にあわせて増えるので、要員をふやしてもスケジュールは短くならない。
楽観主義者たちはバグの数を実際より少なくみつもって間違ったスケジューリングをしてしまう。著者の目安、1/3計画、1/6コーディング、1/4単体テストおよび初期テスト、1/4システムテスト。特にシステムテストには十分時間をかけるべきである。
見積りの精度をあげるには、生産性やバグの発生率の数量化、見積り基準の開発をすること。
遅れているソフトウェアプロジェクトへの要因追加はさらに遅らせるだけの例。
第3章 外科手術チーム
少数精鋭チームが、何百人もの二流プログラマを抱えたプロジェクトより望ましいという意見がある。その通りではあるが、大きなシステムをつくるときには少数精鋭チーム（通常10人以下）では時間がかかりすぎる。確かに効率性とコンセプトの完全性は小数精鋭チームがよいが、時間がかかりすぎればタイムリーに製品をだせなくなる。
ハーラン。ミルズは大規模な仕事の各セグメントに外科手術チームのように編成されたチームでとりくむことを提唱している。デザインと構造は少ない人数で考えだし、実際の作業開発には人をたくさん投入する。
外科手術チームをモデルに考えたプログラミングチームの役割分担
執刀医・・・チーフプログラマ、プログラムをデザインしコーディングしテストしてドキュメントを書く。プログラムのバージョン管理のほか、文書管理にもアクセスできる。才能と10年以上の経験がある。
福執刀医・・・執刀医の分身で、どの仕事もこなせるがまだ経験の浅いもの。
管理者・・・執刀医はボスであるが、人事や昇給設備には手がまわらないので、そこを補う。
編集者・・・執刀医の文書作成をたすける
二人の秘書・・・管理者と編集者につける
プログラム事務係・・・チームの技術記録全般のメンテナンスをうけもつ。これによりプログラムコードが個人のものではなく、全体のものであるという認識ができ、プログラミングを個人の技術から集団の技術に変えることができる。
ツール製作者・・・用途の限られたユーティリティやカタログ化されたプロシージャやマクロライブラリを作成する。
テスト担当者・・・制作中と終わってからの全体をテストするためのテストケースを用意する、テスト環境を整える。
言語エキスパート・・・プログラミング言語の複雑さを習得することに喜びを覚える人をこれにあてる。言語を巧妙に効率よく使うための助言を求める。一人の言語エキスパートが2-3人の執刀医をサポートする。
こうすることで、システムそのものは一心同体の二人が考えだしたものになる。
また、主従関係がはっきりしているので、判断をめぐって相違がでない。役割が特化されているのでコミュニケーションが簡素化される。
大規模開発チーム（5千人年）にこのコンセプトをとりいれるには、各部分でのコンセプトの完全性が根本的にかいぜんされてデザイナーの数が1/7になれば成功である。調整には独自のテクニックがいるが、トップダウンでシステムアーキテクトがデザインされることが肝要である。
第4章 貴族政治、民主政治、そしてシステムデザイン
コンセプトの完全性ことはシステムデザインにおいてもっとも重要な考慮点。
機能と簡潔さの比率がシステムデザインの究極の試金石。どちらかだけではいけない。
大規模プロジェクトではアーキテクチャとインプリメンテーションを切り離すことはコンセプトの完全性を得る強力な方法。
システムのアーキテクチャとは、ユーザーインターフェースについての完全かつ詳細な仕様書である。コンピュータにとってはプログラミングマニュアルであり、コンパイラにとっては言語マニュアルである。
「アーキテクチャは何が起こるかを語るのにインプリメンテーションはいかにして起こせるかを語るのだ」
アーキテクトだけがアーキテクチャについてよいアイデアをもっているわけではない。しかしコンセプトと合わないものはすぐれた機能やアイデアでも除外することがいい。コンセプトの完全性をもとめるなら、だれかがコンセプトをコントロールしなければならない。
アーキテクチャの外部規定はインプリメンテーションの創造性を拘束するのではなく、むしろ高める効果があることをみてきた。
アーキテクトが決定するまでインプリメンテーション担当はすることがない。だからといってインプリメンテーショングループに仕様書作成をまかせてはいけない。仕様書ができるまでは、システムの機能の大雑把な概要をもとに、システム構成の理解や、モジュール境界、テーブル構造、工程の細分化、アルゴリズム、ツールデザインなどの仕事があるし、アーキテクトとのコミュニケーションも必要だ。
実現段階でも、プログラミング技法の選定や、機械の習得など多くのすべきことはある。
経験上、統合されたシステムの方がより早く調和し、テスト時間が短くなることが実証されている。
第5章 セカンドシステム症候群
アーキテクトの創作意欲に弾みを与えるのはアーキテクトと実現者の間で交わされる徹底的で注意深く、さらに相手の立場を考慮したコミュニケーションである。
見積りが高くなりすぎる場合、アーキテクトはデザインを切り詰めるか、インプリメンテーションを安く抑えるかを選ぶ、後者を選ぶなら感情的対立を避ける為に穏やかに非公式に、インプリメンテーション側に創意工夫および創造の責任があることを常に忘れないようにすること。相手の提案をうけいれるようにすること。通常実現者はアーキテクトを変更するという提案で対抗してくる、それが正しいこともよくある
最初の仕事は自生して、余計な機能やアイデアはいれないでいられるが、二度目はこの時制がきかなくなってしまうことがよくある。また時の流れとともにシステムの基本的前提が変化して技術自体がすでに時代遅れの考え方になっているのに、それを改良しようとする間違いもよくある。
これらを踏まえた十分な自己鍛錬がアーキテクトには必要である。
第6章 命令を伝える
マネージャがアーキテクトの決定内容を全員にしらせ、コンセプトを維持するために、仕様書とマニュアルは必要なツール。つくるときには一人かせいぜい二人で一貫性が必要。制限事項(規定されていないもの）を定義する。
定義を周知徹底させるため、パラメータもしくは強要ストレージの宣言をデザインしてきめてコンパイルする方法がある
ミーティングは2階層で、第一階層はアーキテクト全員とハードソフトの実現者の代表と市場規格車を加えた週に半日の会議。ここで蓄積された予測されなかった問題や、抗議や不満を解決するための年1回の全体会議が2週間。本当は半年がよかったとおもうそうだ。
システム/360のアーキテクトは複数のインプリメンテーションの同時開発が行われ、仕様書を徹底させるうえで抜群の働きをした。
インプリメンテーションが進むといかに仕様書が的確でも解釈の疑問が出てくる、ここで困惑した実現者に推察して先にすすまれると困るので、アーキテクトに電話させるのは大切なこと、そしてそれを記録する。
仕様書に即して機械とプログラムをチェックし、重箱の隅をつつく製品テストグループは製品マネージャにとって最良の友。最終的には顧客が独立した監査役である。
第7章 バベルの塔はなぜ失敗におわったか
どんな崇高な目的や機材があってもコミュニケーションとそれから生まれる組織がなければプロジェクトは失敗に終わる。
チームの相互のコミュニケーションをとる方法
・非公式な方法による電話サービス
・定期的ミーティング
・手引書
プロジェクト手引書は、プロジェクトで作成される文書はプロジェクト手引書の構成に従わなくてはならない。構成が先にあることで良質なマニュアルが生まれる。情報を伝達し、すべの必要な人に伝わるようにするために手引書は必要。OS/360では先に手引書をつくり書くプログラマが全資料を読まなくてはいけなくした、またタイムリーな更新をおこなった。手引書が厚くなったのでマイクロフィッシュに切り替えたという。方法はともかく今でも手引書は必要とされている。
コミュニケーションは人数が増えるにしたがって必要になる。不要にするには作業の分割と機能の専門化しかない。
プロジェクト開発組織には制作主任＝マネージャと技術主任＝アーキテクトが必要。
小規模なら両方を一人できるが、二人いる場合はその関係がどのようであれば成功するか述べていた。
第8章 予告宣言する
独立した小さいプログラム開発のデータはプログラミングシステム製品にはあてはまらない。
ICLのチャールズ・ポートマンの調査ではプログラマは機械の故障やミーティング、事務、病気などで時間の半分しかプログラミング・デバッグにあてられていなかった。一人あたりの作業時間数がまちがっていたのである。
いろんな大規模プロジェクトにおける生産性のデータ。作業そのものの複雑さと難しさで生産性の違いがある。適切な高水準言語を使うと生産性はあがる可能性がある。
第9章 5ポンド袋に詰め込んだ10ポンド
プログラムが占めるスペースは主要なコスト。システムデザイナはそれが何をしてくれるものなのか考えて常駐させるか決定し、プログラマはなるべくコストを抑えるテクニックを考えるべき。
常駐スペースだけでなく、全体サイズの割り当ても行う。そうしないと実行スピードが(ハードウェアアクセスによって）おそくなる。モジュールのすべきことを明確にし、サイズを指定せよ。
メモリとスピードはトレードオフである。うまく対処できるようにプログラミングテクニックの習得を十分にさせ、なるべく短期間で学び共有する必要がある。またコンポーネントを汲みたてなければならないということを認識させよ。
職人技をこえたところにアイデアがあり、簡潔で余分なところがなくて
スピードの速いプログラムが生まれるのは戦略的突破である。これは新しいアルゴリズムである場合もあるが、むしろデータやテーブル表現のやり直しの場合が多い。
第10章 文書の前提
ソフトウェアプロジェクトで文書が実際どのように機能するのか理解し、役立てる。
コンピュータ製品のための文書の例
大学の学部のための文書の例
ソフトウェアプロジェクトのための文書の例
マネージャの仕事は計画を作成してそれを実現することだが、文書化された計画の実が明確で伝達可能だ。
何を・いつ・いくら・どこで・だれがという文書が構成されるはずだ。そしてその重要性がわかれば、マネージャーは文書作成を面倒な仕事でなく、使いやすい道具として対処できる。
第11章 一つは捨て石にするつもりで
化学工業では研究所でうまくいく工程でも工場では一足飛びに実施できないことがわかっていた。プログラミングシステム製作も同じである。最高のプランニングでさえも一回で成功するほどには計算されつくされていない。
不変なものは変化そのものだけだ。だｋら変化に備えるシステム計画＝変更の量子化、組織計画＝IBMの二重昇進機構が必要なのだ。
プログラムは配布されたあとも変化する＝プログラムメンテナンスがあるのが普通。
MITのベティ・キャンベルの研究ではインストール後の経過月数と1か月のバグ発見数は、一時おちたあと、再び上昇するそうだ。これはごく小さな欠陥がなにか局所的エラーに見えるが、実際にはシステム全体の問題であることが多いからである。修正の際に以前のシステムテストをすべて実施することはできないので、副作用が発生するのだ。
M・レーマンとL/ベラディの大規模オペレーティングシステムのリリース研究によると、リリース番号とともにモジュールの総数は線形に増加するが、影響をうけるモジュールは指数的に増加するとわかった。修正は創造を破壊する。常に最初が最高の状態であるのだ。プログラムメンテナンスはどんなに器用におこなっても、エントロピー増大なのだ。
第12章 切れ味のいい道具
熟練した機械工は長年にわたり収集し、大切にしまって守ってきた7つ道具をもっている。
熟練したプログラマも同じように、自分用に役に立つユーティリティをもっているものだ、これをチームで使えるように専門のツール製作者をおこう。
マネージャーが方針をたてて計画するのはソフトツールだけでなく、コンピュータ設備、オペレーティングシステム、言語、ユーティリティ、デバック支援、テストケース生成、文書作成用テキスト処理システムである。
ひとつひとつ解説していた。
もっとも重要なのは高水準言語と対話型プログラミングといってた。
第13章 全体と部分
どのようにしてきちんと動くプログラムを作るのか？どのようにプログラムをテストするのか、テスト済みにコンポーネントプログラム一式を統合し信頼できるシステムにする方法は？
・バグを取り除くデザインにする。
コンポーネント間の前提の不整合、コードが出来上がる前に仕様書をテストする、トップダウンデザイン、構造化プログラミング
・コンポーネントのデバッグ
デバッグ方法の変遷、機械上でのデバッグ、メモリダンプ、スナップショット（選択ダンプや選択トレース）、対話型デバック、テストケース
・システムデバッグ もっとも予想外に困難なもの
デバッグ済みコンポーネントを使う、十分な足場固めをする（すべてのプログラムとデータ、あるいはダミーコンポーネントとミニチュアファイル、補助プログラムによる分析やテストケース生成）、変更の統制方法をもつ、一回に追加するコンポーネントは一つにする、更新を量子化する
第14章 破局を生み出すこと
たいていの遅れは日ごとに発生し蓄積し、気づくことも予防することも取り戻すことも困難になる。
スケジュールにマイルストーンを置く、これは具体的で明確で測定可能なイベントでなければらなない。
どうせ他の部分もおくれているんだからは、使ってはいけない口実
上司は行動をとるための情報と状況を理解するための情報を区別して、行動にはたちいらないよう自制すべき。ミーティングは状況検討のためか、問題対策のために開くのかはっきり区別する。
こうしたプランをコントロールするグループをもつことはとこても有効である。
第15章 もう一つの顔
書き上げられたプログラムは人間から機械へのメッセージであるか、人間の利用者に語りかける顔をもつ。
プログラムを使用するために必要な文書を解説。
プログラムを信用するために必要な文書(正常に実行されているか）
プログラムを修正するための文書、フローチャートは過大評価されている。
ソースに文書を組み込む自己文書プログラムを推奨していた。ソースコードが増大するが、その価値はある。
第16章 銀の弾などない ソフトウェアエンジニアリングの本質と偶有的事項
すべてのソフトウェアの構築には本質的作業として抽象的なソフトウェア実態を構成する複雑な概念構造体を作り上げることと、偶有的作業としてそうした抽象的実在をプログラミング言語で表現し、それをメモリスペースとスピードの制約内で機械言語に写像することが含まれている。
過去のソフトウェアの生産性における大きな収穫のほとんどは、偶有的作業をはなはだ困難にする人為的障害を除去すること（きびしいハードウェアの制約、扱いにくいプログラミング言語、機械使用時間の不足など）で得られた。これからは本質的な部分について議論すべき。
狼人間を倒す銀の弾のように、ハードウェアのコストを下げるのと同じように、ソフトウェアのコストも劇的に下げてくれる特効薬を私たちはもとめるが、10年間は（1986年から）ありそうもない。しかし王道はなくても道はある。
ハードウェアの発達があまりに速いために、ソフトウェアはまったく進歩していなくみえるということもある。
ソフトウェア構築において困難な部分は、この概念構造体の仕様書作成とデザイン・テストにあって、表現することやその表現に忠実化をテストすることではない。構文上の誤りはコンセプトの誤りに比べると大したことはない。
ソフトウェアの基本的要素に含まれる固有の性質は、複雑性（どの二つの部分をとっても似ることがない、そしてソフトが大きくなると複雑性が非線形的に増す、そして技術も管理も信頼性がなくなる）、同調性（物理のように統一原理はなく、最後に登場したもの、従わせやすいとみなされるものに従う）、可変性（常に変更という圧力にさらされていて、そして制作されたものより容易に変更できるのでさせられる）、不可視性（視覚化できない、そのため一人の人間のデザインプロセスを妨げるだけでなく、コミュニケーションの妨害になる）
過去にもっとも成果のあったソフトウェアテクノロジーの三段階の発展、いずれも偶有的困難で本質的ではない。高水準言語、タイムシェアリング、統一されたプログラミング環境
銀の弾になる可能性があるものとして最も発展をとてげている技術
・Adaとその他の高水準言語の進歩。Adaの哲学（デザインとモジュール化概念）は言語以上に進んでいるが、機能が豊富すぎるし、言語である以上は銀の弾にはならないであろう
・オブジェクト指向・・・デザインの本質を表現するのに向いているが、デザインの複雑性は本質的で、それを変えることはできないので銀の弾になりえない
・人工知能・・・問題ごとに技術が異なるので期待できないと思う
・エキスパートシステム・・・一般化した推論とルールベースを持つプログラム、ただしつくるのにエキスパートがいる
・「自動」プログラミング・・・整ったケース（ソートや微分方程式）ならできても、通常はそうではない
・ビジュアルプログラミング・・・フローチャートから製作するのだが、フローチャートはソフトウェア構造を抽象化するにしては貧弱、現在のピクセルで表示される画像はソフトウェア構成図の詳細を表示するには範囲と解像度の両方で貧弱。そしてソフトウェアの視覚化は難しい。
・プログラム検証・・・膨大な労力を投入して実現やコストを行う前にデザインを修正しようという考え、これを行ってもプログラムが仕様書とあっていることを立証するだけで、完全で一貫した仕様書を作る役にはたたない
・環境とツール・・・階層型ファイルシステム、統一ファイルフォーマット、一般化されたツールは役にたっている。やがては統合データベースシステムが役にたつ。しかし本来の性質からあまり役にたちそうもない
・ワークステーション・・・プログラムや文書作成には十分。コンパイルはまだ早くなるだろうが、プログラマの思考時間は短くはならない
コンセプトの本質への有望な戦略
・購入対自主製作・・・製作のコストを購入者全員で負担するから安い。スプレッドシートと簡易データベースとう劇的なツールにより、多くの企業にとってソフトウェア生産性をあげる最強にして唯一の戦略は、コンピュータ初心者の知的労働者にPCとすぐれた汎用ワープロ、描画プログラム、ファイル管理プログラム、スプレッドシートを与えることであり、科学者なら数学や統計の汎用パッケージと若干の単純なプログラミング能力があればいいということになる。
ソフトウェア構築のもっとも困難な部分は、何を構築するのか的確に決定すること。そして顧客自身も自分の欲しいものがわかっておらず、しかも自分が要件を指定した製品を数バージョン使ってみなければ、正しい要件を指定することは不可能。だからソフトウェア問題に対する技術的な努力でもっとも有望で、偶有的事項でなく本質を攻略するものは、対話しながら要件を指定していく方法の一部としてシステムのプロトタイピングを迅速に行うアプローチの仕方とツールを開発すること。
ソフトウェアを建築にたとえ、構築するといったのは強力なメタファーだったが、今日では構築する概念が複雑すぎて前もって正確に指定することができず、欠陥なしに構築できないので、アプローチを変えるべき。複雑な生命をモデルに脳のようにソフトウェアを育てる＝漸増敵開発と考えてみる。この方法はトップダウンのデザインを伴うので後戻りが容易で、初期のプロトタイプがそのまま使え、追加された機能や新しく加えたものが、すでにあるものから生物の器官のように育っていく。しかもすでに稼働中のシステムは「やる気」を跳ね上げる効果がある。著者の演習で証明されているそうな。
ソフトウェア技法の改善はまず人間の問題に集中する。すぐれた練習法は教えることが可能。しかし、優れたデザインと偉大なデザインとの差は、偉大なデザイナーかどうかで決まる。ソフトウェア構築は創造的プロセスであり、こつこつ仕事をする人＝優秀なデザインができるひとを、偉大なデザイナーにすることはできない。だから偉大なデザイナーを開発する努力をソフトウェア会社や団体はするべきだ。
第17章 「銀の弾などない」再発射
銀の弾などないの論文にはたくさんの反論がきた。主に自分は銀の弾を開発したというものだ。著者は自腹で購入した利用者が正真正銘、これを使ったらソフトウェアの生産性が10倍改善された」といったら銀の弾が発射されたとみなすと書いていた。
偶有的は偶発発生したとか災難ではなく、副次的とか付随の意味でつかっている。ソフトウェア開発ではインプリメンテーションのことである。
作業の偶有的または表現的部分は全体の半分以下に減っているというのが著者の主張。
ソフトウェアの難しさは概念構造体をつくる部分=本質にあるといっているのあって、再利用可能で互換性のあるコンポーネントで改善できるのは偶有的部分である。
ソフトウェア構造体における概念上の複雑性の大半は、アプリケーションそのものの自由さがもたらす複雑性からきている。ソフトウェア構造体における複雑性の大半は、外部世界への同調性によるものというよりは、むしろデータ構造やアルゴリズム、それに接続性などといったインプリメンテーション自体によるものだ。以前に作ったものを再利用したり、他の人が構築したものをつかうことで複雑性の全階層に直面しなくて済む。また階層化したモジュールやオブジェクトをもつ、漸増性は必要な複雑性であると述べている。
あまりに悲観的という意見もあるが、1986年当時に進行中のさまざまな改革が十分に開発利用された場合、それらを結び付けて生産性における大規模な改善が達成できると予想している、王道はないが道はある。ソフトウェアの本質そのものが銀の弾など見つからないようにさせていると書いたつもりだ。
1986年当時の銀の弾候補を個別に論じて却下したのは、どれも決定的秘薬であるとはいえなかったからだ。
ハレルは「銀の弾などない」が1952年にかかれたと仮定して思考実験をした＝背理法。でもそれは使えない。規模もちぐので。ハレルの主張するモデル化技法「バニラフレームワーク」は銀の弾候補である。またソフトウェアの概念構造体の多くが本来はまったく位相的であり、関係は空間的、図形的に自然に写せるといっている。著者の主張はソフトウェア構造は三次元空間に埋め込まれているのではないから、概念的デザインから図式への一つの自然な写像を得ることはできないということであって、まったくできないということではない。
ジョーンズは生産性より品質に焦点をあてるべきで、生産性は後からついてくると主張。系統だった品質管理の欠如はスケジュールの破たん殿相関関係があるというデータを提供している。
生産性を示す値は今きちんと定義されたものはない。しかしパッケージを購入することが生産性をあげることは証明されたと思っている。
オブジェクト指向の成長が遅かったのは程度のあまり高くない抽象化をおこなっていたからと主張する人がいる。事前のコストが高くつくのだ。
ソフトウェア構築の本質を攻略する最良の方法は全然構築しないこと。または再利用。継承して再利用というのはオブジェクト指向技法のもっとも大きな魅力。しかし、やってみると意外とてこずることもある。再利用はいま企業ではほとんどされていない。もっとも統計もあまりとられていないのだが。
思考レベルが高くなれば、取り扱わなければならない初歩的試行要素も多くなる。だからプログラミング言語は機械言語より複雑で自然言語はもっと複雑なのだ。再利用にはプログラミング語彙の大きさも関係してる。言語の習得法帆運い関する研究と知見が必要。
解決策についての要点は変わっていない。複雑性がわれわれのとりくんでいる仕事である、制約しているものである。登場しそうもない解決策＝銀の弾を待っているのではなくて、可能性のある漸増的な改善をすすめていくべきだ。
第18章 「人月の神話」の命題－真か偽か
1975年の提言のうち、データと経験によって支持されたもの、反証されたもの、時代遅れになったものを判断できるように、各章の真髄を並べたもの。
第19章 「人月の神話」から二十年を経て
人月の神話の息がながいのは、ソフトウェア開発という分じゃが正常に適切に進歩していないからだという意見がある。ハードウェアの生産性が二十年で千倍になっているので余計にそうみえるのだろう。しかしハードの方が異常なのだ。またソフトウェアについてではなく、チームでモノを作る方法について書かれているからだともいわれるが、当たっていると思う。
書いたときも正しく、現在も相変わらず正しいことについて考える。
・中心になる主張 コンセプトの完全性とアーキテクト
大規模プロジェクトで利用者という一人の頭脳から見たコンセプトの統一性をとるためにプロジェクト管理をするには、小規模プロジェクトとは異なる周到かつ大胆な管理行動が必要。アーキテクトは一人にする。アーキテクチャはインプリメンテーションと実現から分離する。アーキテクトの再帰利用（大きな製品は一人ですべてのアーキテクチャをこなせないので、サブシステムにわけて主任アーキテクトを置く）、コンセプトの完全性こそ、製品の品質にとって中心的なものであるという主張は、現在もより確信をもっていることである。
・セカンドシステム症候群－多機能主義と度数推測
汎用ツールをデザインする方が、特別な目的のツールをデザインするより難しい。多様な利用者のさまざまなニーズに重みづけをしないといけないので。市場が要求していると多機能主義に陥るにつれ使いやすさは消える。利用者群を定義すること、度数を推測するべきである。あいまいなままでいるより、明白に間違っているとわかる方がずっとまし。
・WIMPインターフェースの勝利
WIMP・・・ウィンドウ、アイコン、メニュー、ポインティングインターフェース、はコンセプトの完全性をもったユーザインターフェースの最高の例。メニューの使い勝手(コマンド＝動詞と名詞を指定する方法）を例に利用者の力と使いやすさのバランスをとるのもアーキテクトの直面する問題を述べていた。著者は1世代でWIMPは歴史的遺物になり、音声が動詞を表現する適切な方法になるといっている。
・捨て石にするつもりで構築してはならない－ウォーターフォールモデルは間違いだ
一つは捨て石にするつもりでは間違いであると考えるようになった。インプリメンテーションでアーキテクトはの修正がわかったら上流にもどることが必要、漸増的モデルの方が勝っている。どの段階でも実働システムがあり、それが「やる気」を引き出す。利用者による早期テストも行えるのだ。ソフトウェア製品を関連製品のファミリーとしてデザインするのはデービット・パルナスの考えで、変更されることがないと見込まれるデザイン部分の根元付近を基本製品においている。マイクロソフトは「毎晩構築」アプローチを使っている。
・情報隠ぺいに関して、パルナスは正しく私は誤っていた
モジュールコードは適切に定義されたインターフェースを使って隠ぺいすべきだというパルナスの主張を否定したが、今ではソフトウェアデザインのレベル上げる唯一の方法と確信している。パルナスの定義はオブジェクト指向プログラミングの知的先祖で、抽象データ型、継承、再利用のためにデザインされテスト済みのモジュールライブラリまたはクラスのアイデアである。
・人月はどの程度神話的なものか－べーむのモデルとデータ
バリー・ベームが63種類のソフトウェアプロジェクトについて行ったものによると、要員と月数の間のトレードオフは線形どころではなく、人月は生産性の尺度としては実に神話的だとするものであった。そしてコスト曲線についていくつかの発見をした。要員追加についての、細かい研究によると、どのようにどんな要員を追加するかについて有益な知見も得られている。やみくもな要因追加がプロジェクトを破たんさせるのはいうまでもない。
・人間がすべて（そう、だいたいのところは）
ピープルウェアは大きな収穫。技術的というより社会的。プロジェクトの移動をチームの融合の観点から注意を払っている。
・力を断念する力
創造性は個人から発するもので工程や組織から発生ｓるものではない。だから創造性を伸ばす組織と工程を感がることが必要だ。権限委譲である。
・最近あった最大の予想外の事件は何か？－何百万台ものコンピュータの普及
マイクロコンピュータ革命がコンピュータの利用方法を変えた。シューマッハの主張がかないつつある。マイクロコンピュータ革命がソフトウェアの構築方法を変えた。ネットワークの利用で変更やテストが楽におこなえるようになった。
・まったく新しいソフトウェア産業－パッケージソフトウェア
古典的ソフトウェア産業は分裂し、アプリケーションユーザーは細分化している、一方で機能豊富なソフトウェアパッケージが一人のプラグラマの一日のコストより少ない値段で購入できるようになった。OSの世界は小数に収れんした。
・購入して構築する－パッケージソフトをコンポーネントとして
これは概念構造体を作り上げることの本質を攻略するものだから急速に成長していくだろう。パッケージ利用者は、そのままの利用者、メタプログラマ、外部機能作成者、一つあるいは複数のアプリケーションをより大きなシステムのコンポーネントとして使用するメタプログラマに分類される。アプリケーション群のなかで相互作用をコントロールするスクリプト言語があると実に効果的。
・ソフトウェアエンジニアリングの現状と将来
化学工学とソフトウェアエンジニアリングの展開には類似点がある。パルナスはソフトウェアは電気工学のように数学的基礎をもったエンジニアリングとして展開できないといっている。ソフトウェアエンジニアリングは、経営工学同様、人間の行動の複雑性によって永久的に混乱させられるものなのかもしれない。ただし、絶望的なわけではなく、未熟なだけだと思う。当分はタールの沼であるであろう。しかし展開させていくことはできる。
エピローグ 五十年間の不思議 興奮 それに喜び
著者が13歳のときハーバード・マークIの記事を読んで、知識を大きなハイパーテキストのおりものとして構成し、既存の道に従いながら新しい連想の先鞭をつけるような機械を利用者に与えるという提案に興奮した。その後コンピュータの道をすすみつづけたが、この分野は爆発的に進歩してきている、すべてを把握することは難しくなり、周辺分野をすてているくらいだ。コンピュータ関連分野は進歩のスピードをゆるめず、終わりも見えない。これからますます楽しみだ。
人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)
- 作者: フレデリック・P,Jr. ブルックス
- 出版社/メーカー: アジソンウェスレイパブリッシャーズジャパン
- 発売日: 1996/02
- メディア: 単行本
IT業界を楽しく生き抜くための「つまみぐい勉強法」 [プログラミング]
IT業界に入ったばかりの人を対象に書かれた学習方法の紹介の本。
目的は仕事か終わってからもつい勉強してしむような「楽しく学び続ける人」をつくること。
2010年6月出版
第1章 つまみぐい勉強法とは何か？
つまみぐい勉強法の価値
小さいゴールに全力投球し続けることなく、自分が楽しそうだなと思うものを次々「つまみぐい」することで高いモチベーションを維持する。
合わないとおもったらやめる、罪悪感を持つ必要はない。すきなことを継続して学ぶのが目的なのだから。
3法則
・えいやで、すぐ始める
ジャンルは興味と仕事で使いそう、あるいは一緒に勉強する人がいる、教えてくれる人がいるなどで決めよう
やり方は、本、勉強会、ウェブサイトなど、できそうなものをえらんではじめる
・他の勉強へすばやくスイッチする
ただし、継続できるものをみつけて続けることは必要。プログラミングを学んでちょっとしたものが作れるようになったら、次はライブラリやツールの使い方を覚えるとか、GUIの作成方法を覚えて他の人が使ってもらえるツールをつくるなどいろんな方法が考えられる。
一回の勉強のサイクルは人それぞれ、1-2週間や2-3か月などいろんな人がいる。一度勉強した対象に戻るのもオススメ。著者は3か月で対象は３つでスパイラルでやるそうな。
・対象は変わっても、勉強自体は続ける
学生とちがって枠がきまっていて、その範囲をすべて覚えればよいという減点法ではなく、社会人の勉強は加点法。引出しを増やすことで、仕事の幅も広がる。独力でなく他の人との協力で良質なアウトプットをだすことが大事。
勉強することで正解が拡がって、自分のゴールをみつけやすくなる。
勉強が浮かくいかなる理由
やり方があわない。
人の前で発表するのが好き？ 資格をとる？ ソフトウェアを作って公開？いろんあ方法がある、対象は変えず、やり方を変えてみる
状況が変わった
無理せず楽しく継続できるものを選ぼう
戦力的撤退もあり
ゲームと同じでいきなりラスボスは無理。達せ出来なそうなら一旦撤退して別の場所でレベルアップして再挑戦すればいい。
「合わないことが分かった」と考えよう
勉強がうまくいかなくても自分のせいと悩む必要はない。行動している限り経験は蓄積され、成長している。あんしんして振り出しに戻ろう。
終着点は自分で決めよう
得意技をみつける
・つまみぐいしただけなのに、思った以上に効果がある
・自分で普通と思っているのに、他の人から評価が高い
・実施していて楽しい
これらは得意技をさがすキーワード
最初から目標がきまってきなくても、歩き出そう。
つまみぐいで歩いているうちに、得意技がみえてきて、社会で生かす方法もみえてくる
第2章 守りの勉強法
自分の勉強をする前準備として、目の前の仕事改善するためのヒントを紹介
新しい仕事が与えられた瞬間が勉強のスタート
システム開発には、「作る対象の技術」＝金融や製造、「作る技術」＝開発環境やプログラミング、ネットワークの二つがある。だから作る対象の言葉をしること、プロジェクトのイメージを理解することが必要。次は担当範囲を把握、大きな目標のなかのどこに貢献するのかみえるとモチベーションも高くなる。
調べ方を学ぶ
先輩に聞くはリーサルウエポン＝最終兵器
独りで調べる方法
・先輩からきいた本やサイト、ただし一度全体を見通して検索用地図を頭にもっていないと必要なものを端から端までさがすことになる
・ソーシャルブックマーク
ウェブサービスの一つで「はてなブックマーク」など。日本や世界のユーザーが価値があると判断したページから検索できる。知識を生み出す人をウォッチし続けると質の高い情報を得ることができる。
・通常の検索エンジン エラーコードなどはそのままいれてみる
・大きな問題は課題を小さく分解して調べてみよう、目の前の事象に引きずられて本質にたどりつけないことがある
問題解決のステップ例
１ どういう問題があったのか？
２ どうやって問題個所を特定したのか？
３ どうやって修正方法を決定したのか？
質問の仕方を工夫しよう
質問する前に今の状況を整理
１ 具体的にどんな作業をしたか
２ その結果どういう状態になったのか
３ 本来どういう状態になりたかったのか
４ そもそも何をしたかったのか？
伝えるときには４→３→１→２の順。
一番大切なのは１で、この段階で自分で問題解決の糸口をつかむこともある
情報の質について考えてみよう
一次情報か二次情報か
一次情報・・・開発元や開発者の情報や翻訳、ソースコードやシステム現物
二次情報・・・一次情報を見た人がそれを咀嚼してわかりやすく伝えたもの、ブログなど
事実か？判断か？
事実・・だれが受け取っても同じ情報。
判断・・・人の感想
情報か？経験か？
実際に他見することによって得られる情報は貴重。情報は実践、経験して価値がある。
最終的なアウトプットから学ぶ
ソフトウェア開発なら
ソースコードを見る前に、周囲をみわたす、ドキュメントが何でかかれているか、どういう開発環境課、ソースコード管理は？テストは？バグ管理は？
ソースコードから、コメントのかきかたやルール、名前の付け方、関数やメソッド、クラスの行数、ライブラリやフレームワークの実践的使い方などがわかる。
改善できる箇所があるか？ プロジェクトに浸かっている間はきがつけないことがあるメモしておいて、効率のよい開発に役立てよう
つまみぐいで仕事の引出しを増やす
新人はいろんな仕事が振られるが、仕事もつまみ食い。
メモのかきかた、整理の仕方などの細かい作業スキルやビジネスマナーなどの向上に役立つことも。
他の人と作業するうえでの仕事の仕方、人との関わり方について力をつける。
中堅になったらある程度得意技を選ぼう。また足りない部分がわかっていれば伸ばしていける
仕事の枠は自分で決める。組織でなければできない仕事ができるので会社。
GTDを基にした心の渋滞の解消法
紙にやらなければならないことを書き出して、手をつけられそうな簡単なことから実行。重要度が高い仕事は簡単な仕事に分解してみる。
第3章 攻めの勉強法
仕事と関係なく自分で積極的に行う勉強
勉強時間をつくる
まず時間別にやっていることを書き出し、削減できるものなどを分析して勉強時間の枠を用意する。
あとのアンケートでは、早朝、深夜の勉強をしているひとが多く、通勤時間が次に多かった。
次は自分に合ったやり方を選ぶ。電車なら小さい本を広げたりポッドキャストをきくくらいならできるなど、制約や自分の好みで計画を立てよう。ストレスなく続けられるのが一番。
本は最強の時短勉強メディア
選び方は、何度も書店にいってみるのが一番の近道。あとは先輩友人の紹介やブログの書評、読みこなすとだんだん必要かどうか判断できるようになる。
ジュンク堂書店のコンピュータ書籍の入荷情報をしらせるTwitterもある。再入荷情報をみると売れている本がわかる。
ただし、読める速度以上では消化でいないし、レベルがあるので、だめなら他を読んでからあたろう。
本の選び方戦略
古典は基本
そのうえで横軸に
よりよい習慣⇔新しい分野
縦軸に 品質のよい設計⇔実装の低レベルとみて、どの部分の知識がほしいのかで本を選ぶ
勉強会アンケートでは月の書籍代は平均3000円
IT以外では「デザインパターン」や「７つの習慣」「ザ・ゴール」などもよく読まれていた。
ソースコードから学ぶ
良いソースコードに触れて読まない限り、善いコードはかけるようにならない。
オープンソース化されていて、読めるコードは大量にあるので、人のソースコードを読んで、盗めるところはどんどん盗もう。
そのソースコードが何のためのものか？意識して読もう
コードの読み方の例
使い方のわからない関数の名前で検索して、どう使われているか調べる
フレームワークや既成のツールをおいかけて、ユーザの操作やデータの流れと処理を追う。
アプリケーションを起動時からおいかけ、モジュール分割、パッケージのまとめ方などの構築方法を知る
拡張性をもったプログラムの拡張機能の周辺をみて、分離方法、拡張可能な仕組みをどのように実現しているか調べる
エラーメッセージや画面上の表示メッセージで検索し、それが生成されている場所から読んでいく
最初に手を付けるソースコードは自分が使っているプログラミング言語に付属している標準ライブラリやフレームワークがおすすめ
新しい言語なら今まで使っていたものと同じ機能を実装してるライブラリを見るとプログラミング言語の特徴がつかみやすい。
オープンソースから学ぶ
ただしライセンスに注意。改変可能か、再配布可能か
学んだことはブログなどでアププット
利点
自分の知識をまとめる ただし、ある程度丁寧に書かないと後でみてわからない、分野別に書き溜めるのもいい
人の役に立つ情報の発信 自分の観測している情報を定期的に発信したりする、修正や最新情報に注意
ネットワークの構築 ブログならRSSなどで読んでもらえる
自分を伝えるツールになる 蓄積されることで、履歴書などよりITスキルを伝えられるようになる。知り合った人が読んでくれる。
ブログを使った学習の強化
メモを整理
ストーリーを整理・・・読者が読みたい理由は自分のメリットになる内容か
ブログにまとめる・・・手間はかかるが成果として蓄積されるし、読み手を意識すれば構成を考えるようになる
あなたが読みたいと思ったブログなどをマネしてみよう
最低限、下書きで1度、最終画面で2回は確認しよう
翻訳で学ぶ
翻訳のメリットは一次情報を細かいところまで知ることができる
翻訳で大切なのは日本語力、海外でも理系の人はあまり文章はうまくない。文章を通じて書いた人が言いたかった気持ちを訳す
翻訳はちょっとずつ。あるいは、チームで
恐れずに公開。著者も学生時代の翻訳があって今読むとひどい訳だが、それは自分が成長した証し。公開にあたっては原文の著者に了解をとる
翻訳で学んだ知識をアウトプットすることで、成長できる、人に教えたくなる。一度詳しい知識を身に着けると関連情報がでてきたときの情報収集も早くなる
マインドマップの解説
第4章 勉強法座談会
つまみぐい勉強法を効率よく行う手段として勉強会の紹介
勉強会歴10年以上の先輩との座談会
勉強会は社会人の勉強法として役にたつ。IT業界では安いし
昔は会社で教わったが、今は会社に余裕がない。すごい人に必ず会えるとも限らない。
長く続く勉強会では性質が変わることがある。流行によってなくなることも
主催する側が力むと続かない、自分が楽しいからやる。
初心者も提供する側になろうという心構えがほしい。
モチベーションが続くのは楽しいから。
ベテランの人の方が「できない」といえなくて難しい。でもその人のメリットを生かすと伸びだす。
いろんな分野をつまみぐいしていると「つながった」と思うときがある。
場を提供することで起きる化学変化がおもしろい。
IT業界は新しいモノがよくでるけど、名前が違うだけで理論派そんなに変わらないものも多い
会社はほっておくと保守的になる、先進的なことを追いかけないと競争に負けてしまう。チャレンジしないと。
ライトニングトークスがすごい発明
勘違い、若さとバカさは前に進む原動力
勉強会メリット
一緒に学んでいく仲間ができて、日常に変化が生まれる
知識の幅がひろくなり、世の中の情勢がわかる
自分のスキルがどの程度のものかわかり、自身につながる。高い目標もみつかる
勉強会の中心メンバになればマネジメントスキルが身につく
自分のブランドがつくれて、本や雑誌の執筆の機会が得られることがある
第5章 勉強会に行こう
勉強会１０のメリット
ファミリーを作る・・・人脈がひろがる、助け合える仲間が増える、知り合いでも付き合いが深まる。
日常に変化を与える・・ルーチンワークと違うのでやる気スイッチが刺激される
方向性をただす・・・仲間の中で一番スキルの高い人に近づける、調べる方向にアドバイスがもらえる、自分の持つ技術を客観的に見直せる
リーダーシップを伸ばす・・マネジメントにかかわることで成長
世の中の流れを知る・・独りではあらゆる情報にアクセスできない、よく知っている人の選別してくれた情報は貴重
初心者レベルからロケットスタートする・・不要かどうかの判断はベテランが確実、軽快にスタートできる、初心者向けワークショップなども利用しよう。ただし教わったらブログにまとめたりフィードバックして感謝の気持ちを持つ・
ストレスへの耐性をつける・・・実力がついたと実感し、認めてくれる人が増えるので、会社の評価以外の価値をもつことでストレス耐性ができる。
高い目標を発見する・・・まわりとひっぱりあって高い目標を発見できる
自分のブランドを確立する・・知識はアウトプットされないと気が付かれない。勉強会で知名度があがると頼られる。
出版デビューのチャンスをつかむ・・・参加者には出版関係の人もいる
勉強会の探し方
コミュニティを探す・・・SNSやメーリングリスト
人を探す・・・ブログの勉強会レポートなど
勉強会情報を探す・・・ATND、こくちーずなど
一度参加したら仲間からの口コミも聞ける
輪を広げるためのコツ
事前にあいさつ、コミュニティで積極的に発言（ただし、明日までの仕事なんです、助けて下さいは不快に思う人がいるのでやめましょう）、勉強会用名刺をつくる。マインドマップで興味ある分野を書いたり、会った日を書き込んだりできる、内容もバージョンアップして、配りなおすくらいでいい。社内とわけて、連絡先も別にするとよい。
キャンセルの連絡は必ず
わからないことは主催者にきこう、主催者も初めて来る人がどんな人か知りたい
当日は積極的にメモをとり、ブログにも書こう。懇親会は出れらたら出よう。
勉強会の落とし穴
高揚感のみで、一人する勉強を怠ると知識と人脈が増えるだけで、スキルアップできない。自分がネタを仕入れる時間、じっくり勉強する時間も大切に。
お客さん気分で参加するのは損
時間が減るのは覚悟
自分が上という意識を捨てる。相手のよいところを探す。年齢によらず教えを乞う
ハンドルネームをころころ変えない
プチプチ時間管理術
日時が明確でそこまでにやらないといけないことをまずいれて、他は空いた領域にいれていく。この後からいれたものは後回しにできる予定(緩衝材のようなもの）なので、緊急なこと、重要度があがったことがあれば後ろにずらす。プチプチは緩衝材のこと。
定期開催の勉強会なら、参加していることをみなに周知しておくと、「○○の日」と理解してくれたりする。
勉強会開催方法
「学びたいもの」「メンバー」をある程度きめる
考えておきたいこと
目的・・勉強会を通じて何をしたいのか？
機会・・参加者にとってどんな体験があるのか？
前提・・参加者の前提となる知識にはどのようなものがあるか？
メンバーを集めて30分でもいいから話してみよう。
設計図
他に参加する人はいるか
どんなタイプの勉強会にするか
どこで実施するのか
いつ・どのくらいの周期で実施するか
開催
教える人とマネジメントは分けたほうがいい
リマインダーメール（忘れている人がいるので）
振り返り
次回予告
振り返りツールとしてKPT紹介
KEEP＝よかったこと、PROGULEM＝問題点、TRY＝次回、将来挑戦したい
勉強会に参加した人たちがよく「離陸した感じがする」という。
自分でも学べるが、いったん勉強会を体験すると入ってくる情報の流れと速度が変わる。
第6章 勉強会を思考タイプ別に攻略
全員がうまくいく勉強法はない。エマジェネティックスをもとにした4つの考え方紹介。
第7章 家庭を持っている人の勉強時間の作り方
家族第一
週末は連続してでかけないなど家族に配慮
配偶者がでかけたいときには進んで留守番する
予定をつたえ、どんなことを学んだかなどを話す。
懇親会や書籍代はキツイ、でも勉強が必要なことを理解してもらい折り合いをつけている。
子どもに親が勉強を続けているのを見せるのはメリット
独身のうちの方が勉強もラク。是非始めよう。
目的は仕事か終わってからもつい勉強してしむような「楽しく学び続ける人」をつくること。
2010年6月出版
第1章 つまみぐい勉強法とは何か？
つまみぐい勉強法の価値
小さいゴールに全力投球し続けることなく、自分が楽しそうだなと思うものを次々「つまみぐい」することで高いモチベーションを維持する。
合わないとおもったらやめる、罪悪感を持つ必要はない。すきなことを継続して学ぶのが目的なのだから。
3法則
・えいやで、すぐ始める
ジャンルは興味と仕事で使いそう、あるいは一緒に勉強する人がいる、教えてくれる人がいるなどで決めよう
やり方は、本、勉強会、ウェブサイトなど、できそうなものをえらんではじめる
・他の勉強へすばやくスイッチする
ただし、継続できるものをみつけて続けることは必要。プログラミングを学んでちょっとしたものが作れるようになったら、次はライブラリやツールの使い方を覚えるとか、GUIの作成方法を覚えて他の人が使ってもらえるツールをつくるなどいろんな方法が考えられる。
一回の勉強のサイクルは人それぞれ、1-2週間や2-3か月などいろんな人がいる。一度勉強した対象に戻るのもオススメ。著者は3か月で対象は３つでスパイラルでやるそうな。
・対象は変わっても、勉強自体は続ける
学生とちがって枠がきまっていて、その範囲をすべて覚えればよいという減点法ではなく、社会人の勉強は加点法。引出しを増やすことで、仕事の幅も広がる。独力でなく他の人との協力で良質なアウトプットをだすことが大事。
勉強することで正解が拡がって、自分のゴールをみつけやすくなる。
勉強が浮かくいかなる理由
やり方があわない。
人の前で発表するのが好き？ 資格をとる？ ソフトウェアを作って公開？いろんあ方法がある、対象は変えず、やり方を変えてみる
状況が変わった
無理せず楽しく継続できるものを選ぼう
戦力的撤退もあり
ゲームと同じでいきなりラスボスは無理。達せ出来なそうなら一旦撤退して別の場所でレベルアップして再挑戦すればいい。
「合わないことが分かった」と考えよう
勉強がうまくいかなくても自分のせいと悩む必要はない。行動している限り経験は蓄積され、成長している。あんしんして振り出しに戻ろう。
終着点は自分で決めよう
得意技をみつける
・つまみぐいしただけなのに、思った以上に効果がある
・自分で普通と思っているのに、他の人から評価が高い
・実施していて楽しい
これらは得意技をさがすキーワード
最初から目標がきまってきなくても、歩き出そう。
つまみぐいで歩いているうちに、得意技がみえてきて、社会で生かす方法もみえてくる
第2章 守りの勉強法
自分の勉強をする前準備として、目の前の仕事改善するためのヒントを紹介
新しい仕事が与えられた瞬間が勉強のスタート
システム開発には、「作る対象の技術」＝金融や製造、「作る技術」＝開発環境やプログラミング、ネットワークの二つがある。だから作る対象の言葉をしること、プロジェクトのイメージを理解することが必要。次は担当範囲を把握、大きな目標のなかのどこに貢献するのかみえるとモチベーションも高くなる。
調べ方を学ぶ
先輩に聞くはリーサルウエポン＝最終兵器
独りで調べる方法
・先輩からきいた本やサイト、ただし一度全体を見通して検索用地図を頭にもっていないと必要なものを端から端までさがすことになる
・ソーシャルブックマーク
ウェブサービスの一つで「はてなブックマーク」など。日本や世界のユーザーが価値があると判断したページから検索できる。知識を生み出す人をウォッチし続けると質の高い情報を得ることができる。
・通常の検索エンジン エラーコードなどはそのままいれてみる
・大きな問題は課題を小さく分解して調べてみよう、目の前の事象に引きずられて本質にたどりつけないことがある
問題解決のステップ例
１ どういう問題があったのか？
２ どうやって問題個所を特定したのか？
３ どうやって修正方法を決定したのか？
質問の仕方を工夫しよう
質問する前に今の状況を整理
１ 具体的にどんな作業をしたか
２ その結果どういう状態になったのか
３ 本来どういう状態になりたかったのか
４ そもそも何をしたかったのか？
伝えるときには４→３→１→２の順。
一番大切なのは１で、この段階で自分で問題解決の糸口をつかむこともある
情報の質について考えてみよう
一次情報か二次情報か
一次情報・・・開発元や開発者の情報や翻訳、ソースコードやシステム現物
二次情報・・・一次情報を見た人がそれを咀嚼してわかりやすく伝えたもの、ブログなど
事実か？判断か？
事実・・だれが受け取っても同じ情報。
判断・・・人の感想
情報か？経験か？
実際に他見することによって得られる情報は貴重。情報は実践、経験して価値がある。
最終的なアウトプットから学ぶ
ソフトウェア開発なら
ソースコードを見る前に、周囲をみわたす、ドキュメントが何でかかれているか、どういう開発環境課、ソースコード管理は？テストは？バグ管理は？
ソースコードから、コメントのかきかたやルール、名前の付け方、関数やメソッド、クラスの行数、ライブラリやフレームワークの実践的使い方などがわかる。
改善できる箇所があるか？ プロジェクトに浸かっている間はきがつけないことがあるメモしておいて、効率のよい開発に役立てよう
つまみぐいで仕事の引出しを増やす
新人はいろんな仕事が振られるが、仕事もつまみ食い。
メモのかきかた、整理の仕方などの細かい作業スキルやビジネスマナーなどの向上に役立つことも。
他の人と作業するうえでの仕事の仕方、人との関わり方について力をつける。
中堅になったらある程度得意技を選ぼう。また足りない部分がわかっていれば伸ばしていける
仕事の枠は自分で決める。組織でなければできない仕事ができるので会社。
GTDを基にした心の渋滞の解消法
紙にやらなければならないことを書き出して、手をつけられそうな簡単なことから実行。重要度が高い仕事は簡単な仕事に分解してみる。
第3章 攻めの勉強法
仕事と関係なく自分で積極的に行う勉強
勉強時間をつくる
まず時間別にやっていることを書き出し、削減できるものなどを分析して勉強時間の枠を用意する。
あとのアンケートでは、早朝、深夜の勉強をしているひとが多く、通勤時間が次に多かった。
次は自分に合ったやり方を選ぶ。電車なら小さい本を広げたりポッドキャストをきくくらいならできるなど、制約や自分の好みで計画を立てよう。ストレスなく続けられるのが一番。
本は最強の時短勉強メディア
選び方は、何度も書店にいってみるのが一番の近道。あとは先輩友人の紹介やブログの書評、読みこなすとだんだん必要かどうか判断できるようになる。
ジュンク堂書店のコンピュータ書籍の入荷情報をしらせるTwitterもある。再入荷情報をみると売れている本がわかる。
ただし、読める速度以上では消化でいないし、レベルがあるので、だめなら他を読んでからあたろう。
本の選び方戦略
古典は基本
そのうえで横軸に
よりよい習慣⇔新しい分野
縦軸に 品質のよい設計⇔実装の低レベルとみて、どの部分の知識がほしいのかで本を選ぶ
勉強会アンケートでは月の書籍代は平均3000円
IT以外では「デザインパターン」や「７つの習慣」「ザ・ゴール」などもよく読まれていた。
ソースコードから学ぶ
良いソースコードに触れて読まない限り、善いコードはかけるようにならない。
オープンソース化されていて、読めるコードは大量にあるので、人のソースコードを読んで、盗めるところはどんどん盗もう。
そのソースコードが何のためのものか？意識して読もう
コードの読み方の例
使い方のわからない関数の名前で検索して、どう使われているか調べる
フレームワークや既成のツールをおいかけて、ユーザの操作やデータの流れと処理を追う。
アプリケーションを起動時からおいかけ、モジュール分割、パッケージのまとめ方などの構築方法を知る
拡張性をもったプログラムの拡張機能の周辺をみて、分離方法、拡張可能な仕組みをどのように実現しているか調べる
エラーメッセージや画面上の表示メッセージで検索し、それが生成されている場所から読んでいく
最初に手を付けるソースコードは自分が使っているプログラミング言語に付属している標準ライブラリやフレームワークがおすすめ
新しい言語なら今まで使っていたものと同じ機能を実装してるライブラリを見るとプログラミング言語の特徴がつかみやすい。
オープンソースから学ぶ
ただしライセンスに注意。改変可能か、再配布可能か
学んだことはブログなどでアププット
利点
自分の知識をまとめる ただし、ある程度丁寧に書かないと後でみてわからない、分野別に書き溜めるのもいい
人の役に立つ情報の発信 自分の観測している情報を定期的に発信したりする、修正や最新情報に注意
ネットワークの構築 ブログならRSSなどで読んでもらえる
自分を伝えるツールになる 蓄積されることで、履歴書などよりITスキルを伝えられるようになる。知り合った人が読んでくれる。
ブログを使った学習の強化
メモを整理
ストーリーを整理・・・読者が読みたい理由は自分のメリットになる内容か
ブログにまとめる・・・手間はかかるが成果として蓄積されるし、読み手を意識すれば構成を考えるようになる
あなたが読みたいと思ったブログなどをマネしてみよう
最低限、下書きで1度、最終画面で2回は確認しよう
翻訳で学ぶ
翻訳のメリットは一次情報を細かいところまで知ることができる
翻訳で大切なのは日本語力、海外でも理系の人はあまり文章はうまくない。文章を通じて書いた人が言いたかった気持ちを訳す
翻訳はちょっとずつ。あるいは、チームで
恐れずに公開。著者も学生時代の翻訳があって今読むとひどい訳だが、それは自分が成長した証し。公開にあたっては原文の著者に了解をとる
翻訳で学んだ知識をアウトプットすることで、成長できる、人に教えたくなる。一度詳しい知識を身に着けると関連情報がでてきたときの情報収集も早くなる
マインドマップの解説
第4章 勉強法座談会
つまみぐい勉強法を効率よく行う手段として勉強会の紹介
勉強会歴10年以上の先輩との座談会
勉強会は社会人の勉強法として役にたつ。IT業界では安いし
昔は会社で教わったが、今は会社に余裕がない。すごい人に必ず会えるとも限らない。
長く続く勉強会では性質が変わることがある。流行によってなくなることも
主催する側が力むと続かない、自分が楽しいからやる。
初心者も提供する側になろうという心構えがほしい。
モチベーションが続くのは楽しいから。
ベテランの人の方が「できない」といえなくて難しい。でもその人のメリットを生かすと伸びだす。
いろんな分野をつまみぐいしていると「つながった」と思うときがある。
場を提供することで起きる化学変化がおもしろい。
IT業界は新しいモノがよくでるけど、名前が違うだけで理論派そんなに変わらないものも多い
会社はほっておくと保守的になる、先進的なことを追いかけないと競争に負けてしまう。チャレンジしないと。
ライトニングトークスがすごい発明
勘違い、若さとバカさは前に進む原動力
勉強会メリット
一緒に学んでいく仲間ができて、日常に変化が生まれる
知識の幅がひろくなり、世の中の情勢がわかる
自分のスキルがどの程度のものかわかり、自身につながる。高い目標もみつかる
勉強会の中心メンバになればマネジメントスキルが身につく
自分のブランドがつくれて、本や雑誌の執筆の機会が得られることがある
第5章 勉強会に行こう
勉強会１０のメリット
ファミリーを作る・・・人脈がひろがる、助け合える仲間が増える、知り合いでも付き合いが深まる。
日常に変化を与える・・ルーチンワークと違うのでやる気スイッチが刺激される
方向性をただす・・・仲間の中で一番スキルの高い人に近づける、調べる方向にアドバイスがもらえる、自分の持つ技術を客観的に見直せる
リーダーシップを伸ばす・・マネジメントにかかわることで成長
世の中の流れを知る・・独りではあらゆる情報にアクセスできない、よく知っている人の選別してくれた情報は貴重
初心者レベルからロケットスタートする・・不要かどうかの判断はベテランが確実、軽快にスタートできる、初心者向けワークショップなども利用しよう。ただし教わったらブログにまとめたりフィードバックして感謝の気持ちを持つ・
ストレスへの耐性をつける・・・実力がついたと実感し、認めてくれる人が増えるので、会社の評価以外の価値をもつことでストレス耐性ができる。
高い目標を発見する・・・まわりとひっぱりあって高い目標を発見できる
自分のブランドを確立する・・知識はアウトプットされないと気が付かれない。勉強会で知名度があがると頼られる。
出版デビューのチャンスをつかむ・・・参加者には出版関係の人もいる
勉強会の探し方
コミュニティを探す・・・SNSやメーリングリスト
人を探す・・・ブログの勉強会レポートなど
勉強会情報を探す・・・ATND、こくちーずなど
一度参加したら仲間からの口コミも聞ける
輪を広げるためのコツ
事前にあいさつ、コミュニティで積極的に発言（ただし、明日までの仕事なんです、助けて下さいは不快に思う人がいるのでやめましょう）、勉強会用名刺をつくる。マインドマップで興味ある分野を書いたり、会った日を書き込んだりできる、内容もバージョンアップして、配りなおすくらいでいい。社内とわけて、連絡先も別にするとよい。
キャンセルの連絡は必ず
わからないことは主催者にきこう、主催者も初めて来る人がどんな人か知りたい
当日は積極的にメモをとり、ブログにも書こう。懇親会は出れらたら出よう。
勉強会の落とし穴
高揚感のみで、一人する勉強を怠ると知識と人脈が増えるだけで、スキルアップできない。自分がネタを仕入れる時間、じっくり勉強する時間も大切に。
お客さん気分で参加するのは損
時間が減るのは覚悟
自分が上という意識を捨てる。相手のよいところを探す。年齢によらず教えを乞う
ハンドルネームをころころ変えない
プチプチ時間管理術
日時が明確でそこまでにやらないといけないことをまずいれて、他は空いた領域にいれていく。この後からいれたものは後回しにできる予定(緩衝材のようなもの）なので、緊急なこと、重要度があがったことがあれば後ろにずらす。プチプチは緩衝材のこと。
定期開催の勉強会なら、参加していることをみなに周知しておくと、「○○の日」と理解してくれたりする。
勉強会開催方法
「学びたいもの」「メンバー」をある程度きめる
考えておきたいこと
目的・・勉強会を通じて何をしたいのか？
機会・・参加者にとってどんな体験があるのか？
前提・・参加者の前提となる知識にはどのようなものがあるか？
メンバーを集めて30分でもいいから話してみよう。
設計図
他に参加する人はいるか
どんなタイプの勉強会にするか
どこで実施するのか
いつ・どのくらいの周期で実施するか
開催
教える人とマネジメントは分けたほうがいい
リマインダーメール（忘れている人がいるので）
振り返り
次回予告
振り返りツールとしてKPT紹介
KEEP＝よかったこと、PROGULEM＝問題点、TRY＝次回、将来挑戦したい
勉強会に参加した人たちがよく「離陸した感じがする」という。
自分でも学べるが、いったん勉強会を体験すると入ってくる情報の流れと速度が変わる。
第6章 勉強会を思考タイプ別に攻略
全員がうまくいく勉強法はない。エマジェネティックスをもとにした4つの考え方紹介。
第7章 家庭を持っている人の勉強時間の作り方
家族第一
週末は連続してでかけないなど家族に配慮
配偶者がでかけたいときには進んで留守番する
予定をつたえ、どんなことを学んだかなどを話す。
懇親会や書籍代はキツイ、でも勉強が必要なことを理解してもらい折り合いをつけている。
子どもに親が勉強を続けているのを見せるのはメリット
独身のうちの方が勉強もラク。是非始めよう。
IT業界を楽しく生き抜くための「つまみぐい勉強法」 (技評SE選書)
- 作者: 奥 乃美
- 出版社/メーカー: 技術評論社
- 発売日: 2010/05/07
- メディア: 単行本（ソフトカバー）
