こんにちは！社会人4年目のaa-cryingです。
現在は開発チームの小チームのリーダーとしてチーム内のプロジェクトマネジメントを行っています。
あらすじ
まず、私がプロジェクトマネジメント業務に携わるようになった経緯をご説明します。
昨年度11月より、新機能の上流工程に携わりました。
下流工程に入るタイミングでチームの再編があり、
3人チームのリーダーとして、新機能のプロジェクトリーダーに任命されプロジェクトマネジメント業務にあたることになりました。
急に任されたこともあり、そもそもプロジェクトマネジメントの知識が乏しかった私は、基本の基から学んでみることにしました。
プロジェクトマネジメントとは
プロジェクトマネジメントとは、その字の如く「プロジェクトをマネジメント（管理）すること」を意味します。
もう少し噛み砕くと、「計画、進捗、作業系統化、コスト、リソース（人、物）、時間、リスクといった制約条件を管理しながら、プロジェクト完了までチームを効率的にリードしていくこと」です。
現在はPMBOK（Project Management Body of Knowledge・プロジェクトマネジメント知識体系ガイド）」という、プロジェクトマネジメントの知識を体系的にまとめた参考書のようなものが定義されています。
PMBOKは「QCD」（品質・コスト・納期）の管理のため「立上げ」「計画」「遂行」「コンロール」「集結」の「５つのプロセス」を敷き、 その為に必要な知識を「10個の知識エリア」として分類しています。
PMBOK 10個の知識エリア
統合マネジメント
プロジェクト全体の方針を決めて、目標やプロセスを調整したり管理したりする分野です。
他の9つの知識エリアをその名の通り統合して、全体をマネジメントする位置づけとされています。
スコープマネジメント
スコープとはプロジェクトの範囲を意味し、プロジェクトを成功させるために必要な作成物とタスクを定義して、目標の達成する確率を高めるために行う分野です。その定義は必要に応じて常に見直されます。
ここを的確に定めることがプロジェクトの成否に大きく影響するため、10個の中でも最重要項目ともいわれています。
リスクマネジメント
プロジェクトを進めていく中で発生する可能性があるリスクを管理する分野です。
リスクはチャンスも包括することが多いため、避けてばかりいるのではなく上手くコントロールしながら管理・調整しなければなりません。
また、想定できるリスクを事前に予防することも重要です。
コミュニケーションマネジメント
ステークホルダー（利害関係者）とのスムーズなコミュニケーションを行うために管理する分野です。
プロジェクトマネジメントでは、相手にただ状況伝達するだけでなく、相手の理解を得ることができるレベルのコミュニケーションスキルが求められます。
ステークホルダーマネジメント
ステークホルダー（利害関係者）にとって必要な情報を収集し、保管・伝達を管理する分野です。
プロジェクトでは、社内・社外問わずさまざまなステークホルダーが存在します。
2012年に公表されたPMBOKガイド第5版により、「ステークホルダーマネジメント」は「コミュニケージョンマネジメント」から独立して新しく設定された知識エリアです。
スケジュールマネジメント
プロジェクト成功させるためのスケジュール管理や生産性を向上させるために時間の使い方を管理する分野です。
スケジュール管理を行うだけではなく、時間あたりの成果を高めるためのマネジメントでもあるのがポイントです。
なお、2017年にPMBOK第6版のリリースに伴い、「タイムマネジメント」から「スケジュールマネジメント」に名称が変わりました。
コストマネジメント
プロジェクトにかかる費用を適切に見積り・予算を設定して管理する分野です。
現実的な予算を設定することが重要であり、予算を超えないようにマネジメントを実施します。
品質マネジメント
プロジェクトのプロセスやプロジェクトの作成物における品質の管理を実施する分野です。
プロジェクトにおける品質とは、作成物がクライアントが求めているものと合致しており、使用するのに適していることを指します。
資源マネジメント
プロジェクトを成功させるために人材(リソース)だけでなく物的資源の調達および管理を実施して、プロジェクトを遂行できるチーム編成を行う分野です。
2017年のPMBOK第6版のリリースに伴い、「人的資源マネジメント」から「資源マネジメント」に名称と内容が変わりました。
調達マネジメント
調達マネジメントは、プロジェクトの業務を進めていく中で必要なサービスやプロダクトの調達を管理する分野です。
調達の多くは契約が必要ですが、契約のみが目的ではありません。
調達先の選定から、納品の進捗管理・検収まで調達に関する全ての管理を行います。
PMBOK 5つのプロセス
PMBOKでは、プロジェクトの開始から終了までの流れを
という5つのプロセスに分類して定義しています。
ここでは、それぞれのプロセスについて詳しく紹介します。
立ち上げプロセス
プロジェクトを発足する前に許可を得るプロセスのことです。
立ち上げプロセスの段階では、プロジェクトを始める際に必要な情報である目的・目標・予算・成果などを定義します。
また、プロジェクト憲章の作成やステークホルダーの特定も行います。
計画プロセス
プロジェクトを成功させるための作業計画を企画して実際に設計するプロセスです。
計画プロセスの中に、20の詳細なプロセスが定義されています。
計画プロセスの段階では、目標の定義や、プロジェクトを進める際の一連の行動の流れも規定します。
実行プロセス
企画・設計した計画に基づいて人材と資源の調達を行い、プロジェクトを実際に実行するプロセスです。
5つのプロセスの中で最もリソースを消費するプロセスであり、進捗状況次第では計画の練り直しや更新を行ってベースラインを再度設定する必要があります。
監視・コントロールプロセス
プロジェクトを進めていく中の作業で計画との差異が発生していないかについて継続的にチェックを行います。
差異が検出された場合は、その改正を実施します。
終結プロセス
規定のプロセスがきちんと完了していることを検証して、プロジェクトや工程を正式に完了させるプロセスです。
ただプロジェクトや工程を終了させるだけではなく、プロジェクトの中で獲得したノウハウを保管して、次のプロジェクトに役立たせることが大切とされています。
初めてのプロジェクトマネジメント
プロジェクトマネジメントの基本をおさらいしたところで、私の経験談についてお話させていただければと思います。
私が今回実施した内容はプロジェクトマネジメントと言っても下流工程のみのため、5つのプロセスの中で言うと「実行プロセス」以降になります。
知識エリアで言うと「スケジュールマネジメント」「コミュニケーションマネジメント(開発内)」「資源マネジメント(一部)」になりますね。
具体的な業務内容をあげると、以下の3つになります。
スケジュール・タスク管理(下流以降)
- スケジュールを策定し、チームメンバーにタスクを采配
- タスクの進捗をウォッチし、進捗が芳しくないようなら適宜フォローをし、原因を取り除く
- 原因について自チーム内での完結が難しい場合は上のリーダー層へ相談
リーダーへの報連相
- 日々の進捗を報告
- タスクや進捗に問題がある場合は整理した上で相談し、解決を図る。
チームマネジメント
- チームメンバーの開発歴や得意分野を考慮してタスクをアサイン
- 当然機能開発以外にもやることはあるため、それらについてもタスクのアサインや進捗の管理を行う
- 機能開発以外にもチームメンバーの困っていることや問題の解決
他チームの方やリーダーに助けられ、最終的にはスケジュールから何とか遅れずに開発完了できましたが、その中で失敗もありました。
フワっと概算で算出し、スケジュールを組んだ
一番にあげるならこれです。
スケジュールを立てる方法が分からず、過去の似たような箇所を改修している案件から概算でおおまかなスケジュールを組んでしまいました。
その後、いざ実装に入るタイミングで見積もりを見直したところ、見立ての2倍くらいの工数に跳ね上がりました。
当然リスケをすることに...
書籍を読んで得たエッセンス
スケジュールマネジメントには課題感が大きく、どうすれば良いか悩んでいました。
上長やリーダーの方の勧めもあって書籍を読んでみることに...
担当になったら知っておきたい「プロジェクトマネジメント」実践講座
読んでみた書籍はこちら。
選んだ理由はAmazonで検索して1番左上に出てきたのと、
担当になったばかりだったのでタイトルと自分の状況があってそうだなと思ったことです。
全部読んだわけではなく、課題に感じていたスケジュールや見積もりに関する箇所を中心に読んでみました。
以降は書籍に記載されていたエッセンスとそれに基づいた失敗の分析等をまとめています。
スケジュールの建て方
まず、書籍にて紹介されていたスケジュールの建て方を紹介します。
- WBSの構成要素・最終目標を書き出す
- 要素を出し終わったら各要素の成果物を書き出す
- 各要素の成果物を更に分割し、要素成果物(ワーク・パッケージ)を書き出す
- その要素成果物(ワーク・パッケージ)を生み出すための活動(アクティビティ)を書き出す
- 活動の順序付けを行う
- 順序付けを行ったアクティビティ一つ一つについて工数見積もりを行う
- アクティビティの単位で開始日と終了日を決める
- アクティビティ⇒ワーク・パッケージ⇒成果物⇒最終目標と工数を積み上げていき、全体の完了日を設定する
...と結構多く段階を踏む必要があるそうです。
ここで気づいたのが、
私達のチームでは、開発の工程を細かくタスクに分割した一覧としてRedmineのチケットテンプレートが存在すること。
基本的に機能開発の下流工程を開始する際は、そのテンプレートからチケットを登録しています。
100%達成すれば、基本的に開発工程が漏れなく完了できるというものです。
なんと、開発準備の段階で既にアクティビティまで分割と順序付けまで出来ていました。
先の機能開発でも使用はしていたのですが、WBSの構成要素について過去の案件からおおよそのスケジュールを定め、
それをもとにRedmineチケットの1つ1つの開始日・期限を設定していくという方法を取ってしまっていました。
上記書籍の手法の逆をやっていることになるので、そりゃあ見積もり精度に問題が出るわけですね。
まとめ
今回はプロジェクトマネジメントの基本の基としてPMBOKの「10個の知識エリア」「5つのプロセス」を紹介し、その上でスケジュールマネジメント(主にスケジュール策定)の手法について経験を交えながら少し掘り下げてみました。
本来なら書籍に記載の手法に則って策定したスケジュールに沿って進めて実際にどうだったかまで記載できれば良かったのですが、プロジェクトは現在進行中なので、プロジェクトが完了した際に振り返ってみて、また記事にしたいと思います。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
forms.gleイベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com
