PERT図を書こう

主張すること

• PERT図を書かずに、ガントチャートもどきを作ってもプロジェクト管理に失敗する。

ガントチャートもどき

ガントチャートもどきの特徴

• 各作業間の依存性が明示されていない。

• どのような依存性の結果、最終目標につながっているのかが見えてこない。

• 最終目標までの作業の分析が、このガントチャートで適切に表示されているのかがわからない。

  • 欠落している作業の存在を見失う。

• 担当分のガントチャートもどきに従っていることによる正当性の主張

  • 「それは私の仕事じゃない。」、「私は提示した計画通り進めている。」

• 外部への製造委託、開発委託などのクリティカルなイベントとの関係が人によって不明確になる。

• 各作業の成果物が不明確

• 各作業の成果物の可否の判定基準が不明確

PERT図とは

5つのマイルストーン（10から50）と6つの作業（AからF）がある7カ月間のプロジェクトのPERT図
上記のWIKIから引用

PERT図を書こう

• ガントチャートよりもPERT 図の方がいい。
  　依存関係が明確になる。
• 組織としてのゴール
  　製品の設計完了、試作完了、動作試験完了、出荷　などのイベントが各タイミングのゴールとして存在する。
• 各人の作業は、そのゴールつながるものでなくてはならない。
  　そのなかで、メンバー間の作業の依存関係が明確になる。
• PERT図の◯（ノード）が他のノードとつながっていなければ、
  　途中の作業が抜けているため、つながっていない。
  　抜けている作業を足していこう。
• どの作業を優先させればよいのかが明確になる。
• どの作業とどの作業が無関係に並行して進められるのかが明確になる。
  　人を投入して結果を前倒しできるようになる。
• それぞれの作業の入力データ・出力データが明確になっていれば、外部への発注で社内のリソースを補える。
• チェックポイントとチェック内容を意識するようになる。

PERT図を書かない場合に生じること

• どのようにそれぞれの作業が最終目標に関係しているのかが見えない。
  • 知っているつもりの（わかっていてもらえているはずの）暗黙の依存性は、明示化しない限り伝わらない。
  • 作業の依存関係が、その分野以外の人（非エンジニア）にとっても分かる状況にならない。
• その作業の流れを組織として、妥当なものとして承認をしたかどうかが欠け落ちる。
• Aさんの作業とBさんの作業との依存関係が見えない。

不幸な状況に陥ったプロジェクト

• 自分たちのプロジェクトの勝利条件を明確にしていない。

  • すること、しないことの区別を明確にできていない。

• すでに露見している「不幸な状況の始まり」に対して対策を準備しない。

  • そのことに対する対策を行わなかったという判断ミス。

• 商利用を目的とした研究開発で、製品に利用するための判断基準を、開発者に提示しないという問題点

  • どういう条件を満たせば、産業的に意味が出て事業化をできるのかを示さない。
  • そういう条件のまま、大勢を投入しても、事業化できる技術は開発できない。
  • 多額の開発投資を行なったあとに、つまらない理由による開発の断念。

• 「目標設定じたい無理なんじゃね」

  • 目標設定じたいが、実現不可能な妄想をであるというプロジェクト
  • そういうプロジェクトに配属されてしまっても、どうしようもない。
  • 実現可能でかつ意味がある目標への修正を受け付けてもらえない。

• 「目標設定じたい無意味なんじゃね」

  • 今の技術では、実現不可能なこと、あるいは、とっくに別の技術で達成されている場合
  • 目標は、まだできていないことで、今後の開発期間の中で実現可能なことを目標に設定しないと意味がない。

• 関係者が適切に動機づけられていない。

  • 「その問題は、私の知ったことじゃない」とより大きな問題に対して関与することを避けてしまう。
  • 「そこに問題があっても、言われた通り実現すればいい。」と考える。
  • 「自分より前の工程で失敗してくれるなら、自分の作業が問題にならなくてラッキー」などいう不誠実な考え方。
  • 「給料さえちゃんと貰えればOK」
  • 「最悪、別の会社に転職するし」

• 担当者の失敗をたたいてしまう。

  • 適切な判断をするための情報が共有されなくしてしまう。
  • うまくいかなくて手助けを必要としている人が、手助けを求められない。

• 現在進行中の技術の進展を見誤る。

  • そのため、その技術を取り入れることが必要なのに、その技術を無視してしまうことで、今までのその分野での実績を無意味なものにしてしまう。

• そのタスクをこなせる人の重要性を理解しない。

  • そのタスクをこなせる人の重要性を理解しないので、見解の不一致などで、その人を簡単に捨ててしまう。

• なんでも自前で作りたがる。

  • 購入すれば十分のものを自前で作ることで、不十分な実装を持ち込んでしまう。

• 「このままじゃ失敗する」という直感を無視する

  • 「このままじゃ失敗する」という直感は多くの場合妥当です。
  • 必ず対策をとりましょう。

成功したプロジェクトの特徴

• なにが達成したら成功であるのかがはっきりさせてある。
  • すること・しないことの区別ができている。
  • することの範囲でも、優先順序が設定されている。
  • MUST(必須)とshould better（あったらのぞましい）の区別
• 開発期間の中で可能になることと、可能にならないこととの区別がついている。
  • 技術動向を理解しており、開発期間内に利用可能なこととそうでないことの区別がついている。
  • そのため同一の開発目標の設定でも、「３年前には無理だった」が十分に起こる。
• 成果物がどのように使われるのかを明確に理解できている。
  • 成果物を利用する側の利用シーンをスケッチできている。
  • そのため、その利用シーンで満たされる必要がある条件について明示できる。
• 関係者が動機づけられている。
• 力関係で支配しようとしない。
  • 自分の実現できないことを実現できる人に対する敬意を失わない。
• 信頼関係と論理的な説明によって協力を引き出す。
• そのために必要なことを分析してあり、それぞれの作業の依存関係は、知るべき人が知っている状況にある。
• どのようにしたら、プロジェクトが失敗してしまうのかを、担当者が知っている。
• 担当者が抱えている課題をチームの課題としてチームとして解決できる。
• 間違えた判断に対して誠実に向き合う。
  • 例：間違えた判断をして担当者への作業を増やしてしまったとき、非を認められる。

注意

上記は、すべて個人的な経験の範囲で気づいたことです。たくさんのことが抜け落ちています。