![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
どうしても追加人員の投入が行われる場合には、以下の3点に留意しなければなりません。 まず第一に、日頃から可能な限りチーム内の業務を標準化しておくことです。 第二に、チーム内の独自ルール・知識などは日頃からドキュメント化・マニュアル化を心がけることです。 第三は、助っ人には、とびきり優秀な人を選定することです。
つまり、典型的な「生存バイアス」だ。生き残った人は良い思い出として語るが、実は炎上プロジェクトで潰れてしまった人も多くいる。その人たちは発言しないため、炎上プロジェクトの経験が実態以上に良いものとして語られてしまっている
「今も昔も、なぜ失敗しないのか、と聞かれます。そのつど、普通のことをやっているだけです、と答えています」確かに説明をそのまま書くと、当たり前のことの列挙になってしまう。例えばプロジェクト現場の事実をつかむにはどうすればよいか、と問うと次の答えが返ってきた。「ひたすら歩くことです」
トラブルの解決法は、現場から現場へ、暗黙知のノウハウのように伝えられる。だが、今はリモートワークが中心だ。
数々の炎上プロジェクトを解決、ゴールに導いてきた著者が、プロジェクトのトラブルを解決(防止)する方法を事細かに伝授する。
本書では、なにを対象としたどのような規模のものであっても活用できるPMの基本スキルを丁寧に解説します。
2011年7月1日の開設以降、Developers.IOは毎日多くの投稿を重ね、昨年07月(満6年)にはついに累計投稿10000本を達成致しました。
| 確率（高） | 軽減 | 回避 |
| （低） | 受容 | 転嫁 |
| 確率×影響度 | （低） | 影響度（高） |
リスクの事前対策を施すのは当然のように思えるかもしれないが、実はそうではない。プロジェクトの期間別に見ると、3年以上でさえ実施率は47.3％と半数にも満たなかった。
プロジェクトの進捗を把握するために作成される図の一つで、費用と工程の消化度合いを表す折れ線グラフを予算と実績の両方について描画したもの。
作業責任マトリクス（TRM：Task Responsibility Matrix）
