事業会社におけるプロジェクトマ ネジメントの基礎 2022/9

この資料とは ● 対象 ○ プロジェクトマネジメント経験が少ない人 ● 書かれていること ○ 事業会社におけるプロジェクトマネジメントの概要について記載 ● 資料読後のゴール ○ プロジェクトマネジメントの根底にある概念を理解する ○ プロジェクトマネジメントとして行われる活動の大枠を理解する

免責事項 ● 実践的な内容にフォーカスしているため、一般的なベストプラクティスからは外れている部分がある ● 事業会社（特に、内製でソフトウェアを構築している会社）に合わせた内容のため、クライアントワークにお けるプロジェクトマネジメントとは考え方が異なる

目次 1. プロジェクトとプロジェクトマネジメント 2. 事業会社におけるプロジェクトマネジメントの基本方針 3. プロジェクトマネジメントの活動内容

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

プロジェクトとは？ ● PMBOK（Project Management Body Of Knowledge）の定義 ○ 「独自のプロダクト、サービス、所産を創造するために実施される有期性の業務」 ● ポイント ○ 独自性 ■ 日々のルーチンワークではなく、何らかの独自性を持つ ○ 有期性 ■ プロジェクトには明確な始まりと終わりがある ■ スケジュールだけでなく、資金ショートや目標の達成なども含まれる ● ざっくりいえば、何らかのゴールを持ったルーチンワーク以外のもの、、、くらいの意味

なぜプロジェクトにするの？ ● 人間の特性を生かしてゴールを達成するための人類の知恵 ○ 期限の力を利用することで物事を前に進めやすくする ● プロジェクトの「型」を利用することで、未知の内容に対しての対応力を高める ○ 独自性のある業務に対して型を当てはめることが出来る ○ 型があることで、未知の領域にも一定の指針を持つことが出来る

プロジェクトマネジメントとは？ ● プロジェクトを何とかすること、くらいの意味でしかない ○ プロジェクトを成功裏に完了させるための一連の行動、、という雑な定義がある ○ 成功させるために行う行動全て、くらいと捉えて良い ● この言葉自体には大きな意味はない（という筆者の認識）

事業会社におけるプロジェクトマネジメ ントの基本方針

Q. プロジェクトを何とかするために はどうしたら良いか？

A. 正しい方向に手を動かすしかない ● 手を動かさない限りプロジェクトは前に進まない ○ ミーティングだけしていてもプロジェクトは完了しない ● 間違った方向に手を動かしても前には進まない ○ 正しい方向に進まなければゴールに近づかない 手を動かさないとプロジェクトは前に進まないという当然の事象に向き合い続ける。 つまり、正しく手を動かしやすい状況をどう作るかがプロジェクトマネジメントのキモ。

プロジェクトマネジメントの基本 ● タスク実施時間の最大化 ○ 手を動かす時間を最大化することで、プロジェクトはより早く前に進む ● 無駄なタスクの排除 ○ 正しいタスクだけを見極めることはできないが、無駄なタスクは初手から省くことが出来る チームのタスク実施時間をいかに増やし、その上で無駄なタスクに時間を使わないようにするかがプロジェクトマ ネジメントの基本となる。 プロジェクトマネジメントのどの活動もこの二つに紐づく。

● アラインメントを揃えるための 戦略/計画策定 ○ チームの目線を揃えることで、無駄なタスクを最小化する ● チームを前に進めるための 狭義のマネジメント（タスク管理等） ○ 手を動かす時間を最大化させる 事業会社のプロジェクトマネジメントは、戦略策定と日々の狭義のマネジメントの二つの活動から構成される。双 方の活動があることを認識し、二つともを効果的に行う必要がある。 事業会社のプロジェクトマネジメントの２つの活動

プロジェクトマネジメントの活動内容

全体の流れ 戦略 ・目的の明確化 ・リソース把握 ・仮説立案 ・実行可能な基本 方針 実行準備 ・チーム設計 ・コミュニケーション 設計 ・インセプション デッキ 実行 ・PRD/仕様 ・タスク管理 ・リスク管理 ・課題管理 振り返り ・結果確認 ・振り返り ・次の施策の検討

● 戦略とは、目的を達成するための筋道（仮説）を立てること ○ 目的がないところには戦略は存在し得ない 戦略を立てるための前段として、目的の明確化が必須。 （参考） 目的の明確化のフレームワークとしては、 SMAC「Specific（具体的）」「Measurable（測定可能）」「Achievable（達成可能）」「Consistent（一貫性 がある）」やSMART「Specific（具体的）」「Measurable（測定可能）」「Achievable（達成可能）」「Related（経営目標に関連）」「 Time-bound（時間 制約）」などがある。 戦略 - 目的の明確化

● 正しくリソースを把握しなければ正しい戦略は立てられない ● リソースは下記の観点で整理できる ○ 既存のリソースを使う ○ 新しくリソースを獲得する ○ 既存のリソースを増やす /成長させる 既存のリソースが少ない場合、リソース獲得やリソース増加についても考慮した上で戦略を立てる必要がある。 戦略 - リソース把握

● リソースを利用して目的を達成するための筋道を作ること ● あくまでも仮説であり、変わる可能性は常にある ○ プロジェクトを前に進めた結果、仮説が変わることは何ら問題がない ○ 戦略はあくまでも仮説であることを理解し、より良い仮説を探し続ける必要がある ○ 仮説が変わった場合は、メンバーがその変更を正しく認識できるようにする 戦略 - 仮説立案

● 仮説に対しての行動の基本方針を立てる ● 行動の基本方針は「実行可能」でなければならない ○ 実行不可能な方針や仮説には意味がない ○ 「利用可能なリソース」で実行可能な方針にする必要がある 目的とリソースを明確にした上で仮説を立て、仮説を実現するための実行可能な基本方針を立て終わった段階 が戦略立案のゴールとなる。 戦略 - 実行可能な基本方針

● ソフトウェア開発における主なリソースは「人」 ● 人の集まりである「チーム」をどのように設計するかはタスク実施時間の最大化に直結 ロールとしての人という観点だけでなく、組織のスループット（単位時間あたりのアウトプット量）の最大化を視野 に入れながらチームを設計する。 実行準備 - チーム設計

● 主に会議体の設定や、ステークホルダーとの情報共有方法の設計を行う ● プロジェクトの生産性に直結する部分であり、慣例に沿うのではなく意識的に行う 「組織の目的は、必要となるコミュニケーションと調整作業の量を減らすこと」であり、コミュニケーション設計は重 要。会議体の設計だけでなく、議事録やドキュメント類の管理方法、日々のコミュニケーション方法等にも工夫の 余地は多々ある。 実行準備 - コミュニケーション設計

● プロジェクトの全体像（目的、背景、優先順位等々）を端的に伝えるためのドキュメント ● インセプションデッキは、チームメンバー全員で作成することが望ましい ○ アウトプット自体よりも、アウトプットを生み出す過程での意識統一に意味がある プロジェクトの全体像を言語化することで、それ自体がプロジェクトを進める上でのブレない指針となる。指針に 従った行動を取ることで、無駄なタスクの発生を未然に防ぐことができる。 （参考）テンプレート https://github.com/yosukeo/markdown-inception-deck/blob/master/markdown-inception-deck.md 実行準備 - インセプションデッキ

● プロジェクト内の施策/機能等の詳細について記載する資料 ○ PRD（Product Requirements Document）と呼ばれることも多いが、呼び方は仕様書でも何でも良い ● 振り返りを行いやすくするためにも、なんらかの PRDのようなものは必須 ○ PRDには振り返る時に比較可能な数値等のゴールを含めることが望ましい ● PRDに書かれる内容はプロジェクトやチームごとに異なる ○ 規模、理解力、バックボーンなどの差が内容の違いにつながる PRDはプロジェクトマネージャー（プロダクトマネージャー）が作成することが多いが、誰が作成しても問題はな い。また、施策や機能の規模感によっても内容は異なる。 PRDに何を書くべきかを考えるのもプロジェクトマネジ メント活動のひとつ。 実行 - PRD/仕様

● プロジェクトの複雑性の高さゆえにタスク管理が必要となる ● 複雑ゆえに、タスクを忘れてしまう ○ タスクを忘れても良いように、なんらかの一覧で管理する ○ 最低でも「なぜやるか」「なにをやるか」を記載する ● 複雑ゆえに、タスクの実行順序がスループットに直結する ○ 待ち時間を最小化するようにタスクを組むことで、チームのタスク実施時間の最大化につながる 実行 - タスク管理

● 後半のフェーズになるにつれ、問題の修正コストは高くなる ● 発生が想定される問題については事前に手段を講じることで、最小コストでの対応を目指す ○ 無駄なタスクの発生を抑えることがリスク管理の狙い ● リスクは発生確率と発生時の問題の大きさで整理することが多い ○ 発生確率が高く、発生時の問題も大きいものについては事前に対策することで不要なコストを防げる ○ リスクを認識した上でリスクを許容するのも一つの手段 実行 - リスク管理

● プロジェクトでは当初想定していなかった問題が発生することが常 ○ そのうちの「対応すべき問題」を「課題」として管理する ● 課題管理は大きく下記の3つを行う ○ 課題の一覧化 ○ 課題に対する対応方針の確定 ○ 課題のタスク化 プロジェクトには課題発生が付き物ということを理解し、タスクを考える段階で課題対応のためのバッファを設け ておくことが望ましい。また、リスク管理を正しく行っていれば、課題による追加タスクの発生を最小限に抑えるこ とができる。 実行 - 課題管理

● プロジェクト開始時の目的が達成できたか否かの確認を行う ○ この確認を行うためには、目的が「 Measurable（測定可能）」であることが望ましい ● 結果確認を行うことを前提に、結果確認のための仕掛けを作る必要がある ○ 数値計測の仕組み化などをプロジェクトのタスクに含めておくことが望ましい 振り返り - 結果確認

● 結果をチーム全体で振り返り、次回の施策に対しての学びを得る ○ 事業会社の場合、次のプロジェクトのための学びを得ることが重要 ● 振り返りの手法としては下記のようなものがある ○ KPT（A） ○ YWT ● 振り返りには慣れが必要 ○ 振り返りの技術を向上させることで、プロジェクトからの学びが最大化される ● 結果の振り返りだけでなく、プロセスの振り返りを行うのも効果的 ○ プロジェクトの進め方自体の振り返りなどを追加で行っても良い 振り返り - 振り返り（狭義）

● 振り返った内容をもとに次の施策の検討を行う 振り返り - 次の施策の検討

まとめ

● プロジェクトマネジメントの目的はこの二点に集約される ● これらの実現のためにも戦略立案と狭義のマネジメントの組み合わせが重要 ● プロジェクトマネジメントの細かい技術はチームによって異なるのが通常 ○ どのような人がいるかによって取るべきマネジメント方法が異なる ○ メンバーに合った手段を選択できるように引き出しを増やしていけると良い タスク実施時間の最大化と無駄なタスクの排除がキモ