プロジェクトマネージメント

#プロジェクトマネージメントとは
※一部Wikiより引用　Wiki

• プロジェクトを成功裏に完了させることを目指して行われる活動のことである。
  これにはプロジェクトを構成する各活動の計画立案、日程表の作成、および進捗管理が含まれる。
• システム開発を成功させるためには、プロジェクトを適切に管理することが求められる。

#プロジェクトとは？

• 明確に定義された目標がある
• 必ず開始時点と終了時点がある
• 永続的でない一時的な組織
• プロジェクトマネージャ（リーダー）と複数のメンバーから構成される
• 目的達成のための予算が与えられる（人的資源、物的資源、コスト等の制約がある）
• いくつかの工程から成り立つ
• 予期できない事態が発生することがある
• 後工程ほど変更・修正の困難度が増す
• 独自のサービスやプロダクツ（成果物）を生み出す

#プロジェクトにおけるフェーズ

##立ち上げ
新しいプロジェクトやプロジェクト・フェイズを開始するために実行されるプロセスから構成される。キックオフミーティングなどを行い、顔合わせをする。

• 「スコープ」を決める・・・「スコープ」とは、プロダクトやサービスの最終形のこと。
• 立ち上げ時にスコープを決め、そのスコープに沿って計画を進める。
• プロジェクト計画書を作成し、プロジェクト全体の目的や意識を共有する。
  立ち上げ時にはこの「スコープマネジメント」が非常に大切。

##計画
プロジェクトをどのように遂行していくかを計画するプロセスから構成される。
計画プロセス群には、プロジェクトをどのように進めていくかだけでなく、どのようにプロジェクトをマネジメントしていくかといった、プロジェクトマネージャの指針になるような活動も含まれる。

###「WBS」を作成
「計画」フェーズで重要なことは、WBS（Work Breakdown Structure）を作成してスケジュールとコスト計画を立てる。

• 機能一覧や立ち上げフェーズの「スコープ」を基に、WBSを作成。
• WBSの各アクティビティに対してリソース配分
• 当初リソースで足りなければ、パートナーや協力会社からリソースの協力を得る。

こうした「リソース計画」は「計画」フェーズで非常に大切な要素の一つ。

#監視コントロール
時にはトラブルが発生したり、計画とは異なる方向へ進んでしまったりすることもある。
監視コントロールの各プロセスは、プロジェクトの状況を監視し、プロジェクト計画とのギャップをチェック。
また、プロジェクト計画とのギャップが大きくなった場合は、是正処置を行い、プロジェクトの軌道修正を行うこともある。

##予期せぬ事態に遭遇

• ビジネス要因で、当初予定のスコープに変更がある
• 利用を予定していた外部サービスの仕様に一部問題があり、別のサービスへの変更を余儀なくされる
• メンバーのモチベーションから来る生産性の低下により、進捗が遅れる
• 優先順位の変更により、当初より早くリソースの調整が必要となる
• 当初見積額に大幅な変更がある

この変更を監視し、対応する仕組みを持つことが、このフェーズでは最重要となる。

• 「変更管理」をコントロールする委員会の設置
• 変更管理の「チケット」を管理する仕組み
• 「見える化」し、調整を迅速に進めていくことが必要。
• システムの一部分が再計画を余儀なくされる場合もあり、全体のコスト・進捗状況・品質を見ながらプロジェクトを推進していく。

#実行
プロジェクトの計画書に従って、プロジェクト作業を実際に推進していくプロセスから構成される。
##チームで戦う
「計画」フェーズで定義したWBSに沿って、プロジェクトを推進。

• ここで一番大切なのは**「チームのマネジメント」**。
• フルスタックと呼べるようなメンバーはごく一部に限られているので、チームでの推進が非常に大切。
• **「チームで戦えるか」**を重視する。

#終結
プロジェクトやプロジェクト・フェイズを公式に終了するためのプロセスから構成される。
正式に納品・検収の手順を経て、プロジェクトが「終結」。

最後もリクエスタとミーティングを行い、KPTを用いて「ふりかえり」ミーティングを実施するとよい。
お互いの良かったところ、悪かったところを「マインドマップ」など使って「見える化」し、後に続く「保守」や機能改修時に使ったりなど。

#各フェーズで必要なアウトプット

フェーズ	大切な事	アウトプット
立ち上げ	・関係者と親睦を深めること ・プロダクト・プログラムのスコープを決めること	・プロジェクト計画書 ・スコープ定義書
計画	・WBSを作成し、コスト・スケジュールの計画を立てること ・リソースの計画を立てること	・WBS ・リスク一覧 ・リソース計画書
実行	チームのマネジメントを心掛けること	成果物（ソースコード・テスト計画書など）
監視・コントロール	・変更を監視し、対応する仕組みを持ち実践すること	・変更管理表（変更の履歴が分かるもの） ・WBS更新版 ・リスク一覧更新版 ・リソース計画書更新版
終結	・ふりかえりをする	・次回につなげる

#最後に
私は今まで、規模の小さな案件で、立ち上げ～終結までは、経験してきました。
現在は、わりと規模の大きなものに携わっているので、全体的なPMはできませんが、主には「実行」「監視・コントロール」の部分を担っていると思います。
「予期せぬ変更」という部分で、変更を監視し、対応する仕組みを持つここに注力してはいますが、いまだにどういう対応が望ましく、どう仕組み化できるのだろうか、という部分に試行錯誤しています。
私が一番重きを置いていることは「プロジェクトを終わらせること」。
しかし、どんなやり方でも終わらせることはできると思いますが、人の管理・進行の管理・チームのマネジメントに努め、携わるすべての人が「良いものができた（達成感）。楽しく終えれた。」と思えるようなものを作っていきたいと思います。