事例から⾒たプロジェクトマネジメント 〜プロジェクト振り返り事例のご紹介 2016年03月26日 JISTA九州支部 陣 宏充

Contents 1 １．プロジェクトとは ２．プロジェクト管理者 ３．プロジェクトの成功 ４．成功するかもしれないプロジェクト ５．失敗プロジェクトの事例 ６．プロジェクト振り返り （⾃分で推進した事例） ７．まとめ

１．プロジェクトとは 2 ＜プロジェクトの定義＞ ー 大規模システムの構築から、小さな組み込みプログラムまで幅広い 案件︖タスク︖プロジェクト︖ ・プログラム規模 ・期間 ・費用 ・要員数などで呼び分けている場合もある。 ー プロジェクトマネジメント協会︓「独⾃の成果物、またはサービスを創 出するための期限ある活動」 定義︓製品やサービスなどを作り出すために、 定義︓製品やサービスなどを作り出すために、 期間が定められている業務かつ、リーダと複 数の担当者で構成されている

２．プロジェクト管理者 3 ＜プロジェクトマネージャという呼び方＞ ー 日本の多くの企業では職位によって呼び方が変わる（外資系では職位にかかわらず、 役割として定着している）。 ・主任/係⻑︓チームリーダ／サブリーダ ・課⻑︓プロジェクトリーダ（実際はプロジェクト責任者） ・部⻑︓プロジェクトマネージャの上司（予算等を管理） ー プロジェクトマネージャとは、プロジェクト全体の指揮管理を⾏う責任者 ー プロジェクトマネージャは、組織において新しい成果物を⽣み出すために⽴ち上げ られたプロジェクトについて、計画の⽴案、資材や要員などの調達、進⾏方法の確⽴や 納期、品質、進捗状況の管理までを包括的に監督し、プロジェクトを円滑に推進させる 役割を果たす。 定義︓プロジェクトを実際に動かし、日々の 管理を実施している責任者︕

３．プロジェクトの成功 4 ＜プロジェクトを成功に導くことがプロジェクトマネージャの役目＞ １．期限内に ２．決められた予算⾦額内で ３．期待レベルの品質・技術成果の元で プロジェクトマネジメントが重要︕ プロジェクトマネジメントの方法は様々 〇名人がKKDに裏付けられた⼿腕で実施。⇒しかしその人がいなくなった ら・・ 〇PMBOKやCMMIなどを利用する。⇒多くの企業が取り組んでいる︕ ４．割り当てたリソースを有効活用して ５．顧客が満⾜する状態で完了する 成功の為に

４．成功するかもしれないプロジェクト 5 Aさんはいわゆる「達人」︓ ・要件定義から設計、テストまで、すべてを高い水準 でこなすスーパーエンジニア（最近の言い方だとフル スタックエンジニア） ・プロジェクトメンバからの信頼は厚く ・問題が発⽣しても、人並み外れた対応で遅れを取り 戻してしまう Aさんの⼒が及ぶ範囲でプロジェクトは成功す る・・でも、Aさんがいつまでもいるとは・・ ◎属人的な要素に頼らないマネジメント が必要︕

５．失敗プロジェクトの事例 6 １．仕様が確定しない ２．プロジェクトマネージャが作業 を担当している ３．プロジェクトの状況が正しく 把握できていない

■仕様が確定しない 7 ・要件があいまいなまま作業が進められている︕ × 担当者個人の判断で作業している ・要件の抜け・漏れが発⽣する ・無用な仕様が入り込む × 下流⼯程になって要件変更が多発する ・納期遅延 × 仕様変更の受入条件があいまい ・要件の確定期日が決められていない ・要件変更の受入れが個人任せ ・要否回答に時間がかかり、結局、 既成事実化し、仕様変更せざるをえなくなる ■仕様があいまい 仕様決定のプロセスに問題がありませんか︖ ５．失敗プロジェクトの事例（１）

8 ５．失敗プロジェクトの事例（１） 事例︓仕様が確定しない ・要求が曖昧なため機能しようが決められない ・機能仕様の設計⼯程がずれこむ ・このような上流⼯程の遅れから下流⼯程がひっ迫 ◆上流⼯程でQCDを作りこむはずが・・ 不⼗分な機能仕様 設計作業が混乱 ソフト製作工程の圧迫 設計途中で仕様を 確認したり、調整したり ここからは漏れのないソフ ト製作はできないし、過不 ⾜のないテストもできない テストケース不⾜ テスト工数の圧迫 テスト⼯数を圧迫 曖昧 曖昧 曖昧 タイムリミット で出荷したが・ 品質(悪)

9 ５．失敗プロジェクトの事例（１） 事例︓仕様が確定しない ・要求が曖昧なため機能しようが決められない ・機能仕様の設計⼯程がずれこむ ・このような上流⼯程の遅れから下流⼯程がひっ迫 ◆上流⼯程でQCDを作りこむはずが・・ 不⼗分な機能仕様 設計作業が混乱 ソフト製作工程の圧迫 設計途中で仕様を 確認したり、調整したり ここからは漏れのないソフ ト製作はできないし、過不 ⾜のないテストもできない テストケース不⾜ テスト工数の圧迫 テスト⼯数を圧迫 曖昧 曖昧 曖昧 タイムリミット で出荷したが・ 品質(悪) 問題あり︕ 曖昧の元

10 ５．失敗プロジェクトの事例（１） 機能仕様 (開発側) ◎曖昧を取り除き要求と仕様を適切に決定するには ■仕様書（成果物）の表記を変える 追加や変更要求を明らかにでき る仕様書（成果物） 相互理解 相互理解 相互理解 要求仕様 (要求側) 気づき 気づき MECE ・必要な要求が⾒える ・仕様が⾒える 要求側と開発側とが互いに理解できる資料

11 ５．失敗プロジェクトの事例（１） ◎追加や要求変更を明らかにできる仕様書を作るために ◎要求を引き出すコミュニケーション ◎要求の可視化 ◎要求の管理 仕様決定プロセスが重要 上位組織主導で改善 ◎上位組織はプロジェクトマ ネージャの能⼒も含めて戦略 実⾏に必要な組織能⼒を⾒極 め、不⾜している部分を常に 改善する必要がある。

５．失敗プロジェクトの事例 12 １．仕様が確定しない ２．プロジェクトマネージャが作業 を担当している ３．プロジェクトの状況が正しく 把握できていない

■プロジェクトマネージャが作業を担当している 13 ・腕に覚えがあり、担当業務に⼿を出す ・ マネージャがチームを率いるという意識を持って作業分担や業務の割 り当てをしていない × レビューに参加できなくなる ・プロジェクトメンバーの作業が止まる × 情報が流れてこなくなる ・プロジェクト混乱 × 進捗などの管理が疎かになる ・プロジェクト状況が分からなくなる ５．失敗プロジェクトの事例（２） ・他のプロジェクトを兼任 ・ 人材不⾜が解消できない中での組織作り ⇒担当分が忙しくなるにつれ辛くなる・・

14 ５．失敗プロジェクトの事例（２） 事例︓PM/PLがプログラミング 問題部分を修正 メンバーがテスト 実施 ⾃ら単独で実装を始める 仕様で問題が 発生 責任を取って自分 で問題部分を実装 ＆修正 ⼿持ち作業が多すぎてダウン

15 ５．失敗プロジェクトの事例（２） 事例︓PM/PLがプログラミング 問題部分を修正 メンバーがテスト 実施 ⾃ら単独で実装を始める 仕様で問題が 発生 責任を取って自分 で問題部分を実装 ＆修正 ⼿持ち作業が多すぎてダウン プロジェクト内 混乱（内部崩壊）

16 ５．失敗プロジェクトの事例（２） 事例︓PM/PLが担当プロジェクトの他に別案件をもたされる 案件A 案件Bの担当 依頼 案件Aのみ管理 案件A 小案件 B 案件Aの他に小案件Bを兼任 （人材不⾜︖コスト最適化︖） 案件A 案件Bでトラブル発⽣ 案件A 小案件 B 案件A 小案件 B 案件Bを優先して作業 案件Aが野放し状態・・ 混乱 案件Aが混乱

17 ５．失敗プロジェクトの事例（２） 事例︓PM/PLが担当プロジェクトの他に別案件をもたされる 案件A 案件Bの担当 依頼 案件Aのみ管理 案件A 小案件 B 案件Aの他に小案件Bを兼任 （人材不⾜︖コスト最適化︖） 案件A 案件Bでトラブル発⽣ 案件A 小案件 B 案件A 小案件 B 案件Bを優先して作業 案件Aが野放し状態・・ 混乱 案件Aが混乱 上位組織の問題

18 ５．失敗プロジェクトの事例（２） プロジェクトマネージャ(プロジェクトリーダー)の役割 ■体制作りと責任分担 チームを率いているという⾃覚 PMの采配 ・プロジェクト体制を整備し、個々の役割・責任分担明確化 ・重要な事項に関しては、リーダーに、さらにリーダーから プロジェクトマネージャに迅速に報告が伝わる仕掛けを作る。 ・メンバーの希望を確認し、できるだけやりたい仕事につかせ る。モチベーションや⽣産性、品質が高まる場合が多い。 ・適材適所にメンバー、リーダーを配置する。 ⼀方、組織としてやるべきことは何︖

19 ５．失敗プロジェクトの事例（２） 組織の役割 ・上位組織は、プロジェクトマネージャの能⼒を含めて戦略実 ⾏に必要な組織能⼒を⾒極め、不⾜している部分を常に改善し ていく必要がある。（プロセス改善やプロジェクトマネージャ 不⾜解消など） ・開発期間や予算が厳しく制限、技術は専門化/高度化 ＜困難な条件で⼒を発揮できる 技術者の確保は難しい＞ 最適な組織体制を決める「組織デザイン」が重要 ・情報共有やリソース（人・モノ・カネ） 上位組織 運用する人を育成 プロジェクトの特性に応じた組織作り 運用する人を育成

５．失敗プロジェクトの事例 20 １．仕様が確定しない ２．プロジェクトマネージャが作業 を担当している ３．プロジェクトの状況が正しく 把握できていない

■プロジェクトの状況が正しく把握できていない 21 ・メンバーからの報告内容が曖昧 ５．失敗プロジェクトの事例（３） × 個人毎に報告の粒度や数値の意味が異なる 「できている」「進捗度５０％」の意味が個人で異なる 「進捗を回復できる」の根拠など × 課題がどれだけ残っているかわからない 「概ね順調」「小さい問題はあるが大丈夫」 協⼒会社任せや鵜呑み × 不測の問題が起きてから慌てる 事後対策に時間がかかる ・リスクの把握を怠った × リスクと課題とを同じ表に載せている リスクを未来、課題は現在、ごちゃまぜに管理・・

22 ５．失敗プロジェクトの事例（３） PMの仕事は報告の曖昧さとの闘い 「メンバーが報告しなかった」責任はPMに帰する 「メンバーが報告しなかった」責任はPMに帰する コミュニケーション管理はプロジェクト管理の基盤 × あうんの呼吸 ⇒相⼿に察してもらう文化は通用しない。 PMは、様々な報告から出来る限り曖昧さを排除し、正確 な状況を把握するように努めなければならない。 PMは、報告者に対して積極的に質問や指導を⾏わなけれ ばならない。 ⇒報告者が曖昧さを排除した報告ができるような報告ルー ルを定めたり、報告書フォーマットを用意することが重要。 PM

23 ５．失敗プロジェクトの事例（３） 予兆（危険の察知） 危険を察知できる仕掛けやフレームワーク 進捗の⾒える化 ・会議が予定通り開催できない。 ⇒直前の日程変更、先送り ・報告資料に定量的データが無い。 ⇒日ごろからデータを把握していない、進捗遅延回復の 根拠が示されてない。 ・状況報告資料を徹夜で作成。 ⇒⽭盾する報告、実態との乖離 ・協⼒会社の作業状況の未把握。 ⇒丸投げ 敏感

24 ６．プロジェクト振り返り（推進事例）（１） プロジェクト完了報告書（振り返り⽤） [概要][結果][各メンバーの 所⾒][得られた成果][問題 点][今後の対策]と各項目に 分けて、反省会を実施。 参画したメンバー全員が意 ⾒を出し合うことで改善点 等の情報共有化が可能︕

25 ６．プロジェクト振り返り（推進事例）（２） 振り返りKPT（Keep/Problem/Try） Keep(今後持続してやる点) Problem（問題点） Try（今後への改善点） ◎改善点等の情報共有が可能 ◎⾒える化

26 ７．まとめ ◆失敗しないための留意点 １．仕様書（成果物）の表記変更と仕様変更プロセス ２．不⾜部分を改善する組織のサポート ３．危険察知と進捗の⾒える化 ４．プロジェクト反省会（振り返り会）を実施し 小さな失敗を教訓に大きな失敗を未然に防ぎ、 小さな成功を教訓に大きな成功を︕

★ご参考「原理原則17か条」 27 格言 ※出典︓IPA 「超上流から攻めるIT化の原理原則17か条」