初心者に届けたい！僕が考えるプロジェクトマネジメント
「プロジェクトマネジメントについて教えてください！」
現在、所属しているベンチャーで、広報担当の社員から不意にこんな相談を受けました。
私自身、前職は大手SIerのシステムエンジニアとして、システム開発を専門に小〜大規模の様々なプロジェクトに携わってきましたが、
システム以外の人からプロジェクトマネジメントについて相談を受けるのは今回が初めてでした。
プロジェクトマネジメントで検索すると、上位にシステム開発、情報処理試験などのワードが上がってきますが、必ずしもIT業界に限った話ではないでな、というのが率直な感想です。
プロジェクトが存在するところには、
必ず「プロジェクトマネジメント」が存在する。
上記の通り、プロジェクトが存在するところには、必ず「プロジェクトマネジメント」が存在するので、
「誰でも何処でも通用するようなプロジェクトマネジメント」について、何となく私なりの解釈で整理してみましたので、IT業界に限らずプロジェクトに携わっている方はぜひ参考にしてもらえればと思います。
プロジェクトマネジメントとは？
いきなり難しい用語を出してしまいますが、プロジェクトマネジメントについてのノウハウや手法を体系的にまとめたもので「PMBOK（Project Management Body of Knowledge）」という知識体系がありますが、その中でアメリカの非営利団体PMI（Project Management Institute）がプロジェクトを以下のように謳ってます。
プロジェクトとは、
独自の製品、サービス、所産を創造するために実施される
有期性の業務である。
単純にこれだけでは、何のことを言っているのか、理解が難しいと思いますが、私なりのわかりやすい言葉で言い換えると以下だと思ってます。
プロジェクトとは、
ある目的に対して、限られた期限で、取り組む、
今までにない活動
少し要約すると、目的（≒ゴール）はある程度明確だと思います。
例えば、すごく単純に結婚式というプロジェクトの文脈でいうと、「結婚式を無事に成功させること」が目的になります。そして、契約の段階で結婚式の日程について確定すると思います。そこまでの限られた期限で準備が必要になります。また、結婚式というプロジェクトは多くの人は初めての経験になると思います。例えば、炊事、洗濯、風呂掃除などの家事は定常的な作業にあたるのでプロジェクトという呼び方はしません。
上記のような目的や期限は明確なのですが、そこにたどり着くためのプロセスが確立されていない活動をプロジェクトと呼びます。
プロジェクトマネージャーとは？
上記で説明した、新規性があり、スケジュールや予算など色々な制約事項が課せられた中でプロジェクトを計画・推進・調整することに責任が持つのが、プロジェクトマネージャーです。
プロジェクトを進めるにあたって
プロジェクトの種類については、大小様々あると思います。
例えば、私自身が長年経験しているシステム開発の領域においては、はじめにお客様からフワッとしたやりたい事とサービスインの時期について要望が来ます。それを踏まえ、要件定義工程である程度仕様を詰めて、プロジェクト計画書を作成します。そして、出来上がったプロジェクト計画書の中身を上長に承認をもらった上で、キックオフでプロジェクトに関係する人全員に展開し、プロジェクトがスタートします。
経験のある作業や定常的な作業の場合、大きく想定とズレる事はないですが、プロジェクトの規模や難易度でプロジェクト進行中にプロジェクト計画書を変更することは往々にしてあります。その場合は、変更した内容を上長に承認をもらった上で改めてメンバーに展開します。
上記のようなプロジェクトもありますが、そう言ったものばかりでなく、結婚式や社員旅行、強いては飲み会もプロジェクトの一種だと思います。
どんなプロジェクトを進めるとしても、はじめに計画をする事は大事なプロセスの一つであると思いますが、計画の中に含める要素は内容に応じて取捨選択する形が良いと思います。
以下では、プロジェクト計画を作る上での必要となる要素について記載をしたいと思います。
Why（背景・目的）についての共通認識を持つ
プロジェクトを進める上で一番大事なことは、プロジェクトの背景・目的を押さえておくことです。
背景
今回のプロジェクトを進める上での周囲を取り巻く環境がどうなっているのか、です。
例えば、銀行のATMのシステムに顔認証など新しい機能を追加するとなった場合に、他社のATMの機能はどうなっているのか、また、もう少し広い範囲でいうと、金融業界でセキュリティ対する意識がどう変わってきているのか、などです。
目的
こちらは、今回のプロジェクトで達成したいこと（プロジェクトのゴール）になります。ここはステークホルダー全員で認識を合わせておくべき重要な事項ですが、端的な言葉で全員の認識を一致させることが難しい場合は、スコープを定義してください。
成功基準
ただ目的を決めるだけでなく、目的（ゴール）を達成したことを証明する成功指標を設けておくことも重要です。
例えば、「社員旅行を成功させる」と言う目的があった場合に、社員旅行の成功と言うことに対して、プロジェクトに携わるメンバーの解釈が異なることが往々にしてあります。「社員旅行を成功させる」＝「終わった後の社員アンケートで満足度が7点以上（10点満点中）を達成する」など明確な指標を設ければ、プロジェクト進行の中に社員が満足することにメンバー全員が注力できることになります。
スコープの定義
目的のところでも話しましたが、複数のメンバーでプロジェクトを進める場合は、プロジェクトのスコープを定めておくことが重要です。
スコープの定義というのは、今回のプロジェクトでの対応範囲か否かを定義するということです。
例えば、社員旅行の場合、以下みたいな形でまとめておくと後で混乱せずに済みます。
〜社員旅行のスコープ定義〜
スコープ内の成果物／作業
・ツアー旅行会社の手配
・当日集合までの交通手段の手配
・しおりの作成
・社員アンケートの作成
・２次会のコンテンツ検討
スコープ外の成果物／作業
・当日の１次会の料理
・帰りの交通手段（各自事由とする）
などなど
また、プロジェクトを進めておく上での前提事項や、制約事項があれば合わせて定義しておくことをオススメします。
What（タスク、優先度）の洗い出し
プロジェクトの目的が決まったら、目的を達成するためにやるべき事（タスク）を洗い出すことが必要になります。
プロジェクト計画書上は、そこまで細かい粒度で洗い出す必要はないです。要素としては網羅的に洗い出す必要があります。
例えば、あるWebサービスを開発するときに、画面のデザイン、フロント、サーバー、データベースの構築、その他、非機能面をどう担保するか、などは要素として、少なからず上がってくると思います。
この粒度で落とし込めれば、デザイナー、フロントエンジニア、サーバーサイドエンジニア（データーベースエンジニア）、インフラエンジニアなどのステークホルダーが必要な事が明らかになるため、さらに細かくタスクを洗い出すのは各メンバーに依頼してWBS（Work Breakdown Structure）を作成します。
一通りタスクを洗い出したら、各タスクの優先度付けをする必要があります。
タスクの洗い出しと優先度付けまで完了したら、次は各々のタスクについて概算で所要時間を見積もります。王道のやり方としては、過去の同様のプロジェクトを探し、該当のタスクにどの程度時間を要したのかで見積もりを出すやり方があります。ただし、今回の対応が初めての場合は、担当のメンバーにさらっと所要時間の想定を聞いてみることをオススメします。
Who（担当）の割り振り
タスクの洗い出し、優先度付け、所要時間の見積もりまで完了したら、各タスクに担当をアサインしてください。
ステークホルダーマネジメント
各ステークホルダーについても可視化しておくしておくことをオススメします。ここでいうステークホルダーは社内に限らず、社外も含めてです。各ステークホルダーがどんな思惑でプロジェクトに臨んでいるのかも明記しておくとコミュニケーションを取るときに相手の思惑に沿った提案ができます。
面白いスライドシェアがありましたので以下に載せておきます。
When（スケジュール）の策定
タスクの洗い出し、優先度付け、所要時間の見積もり、担当のアサインまで完了したら、各々の要素をガチャガチャ組み替えてリリースまでの段取りを検討し、スケジュールを策定します。
出来上がったスケジュールをセルフチェックするに当たって必要なポイントは以下です。
実現可能なスケジュールとなっているか
スケジュール策定当初からガッツ目標となっていないか、バッファは取られているか、など意識してください。
クリティカルパスを見極める。
この作業が遅れたら全体のスケジュールに影響するラインを把握しておく必要があります。そして、そのタスクをリスクとして捉え、リスクが顕在化した時の対策をどうするのかをプロジェクト計画に記載しておくと、実際に怒った時に慌てずに対応できます。
リソース配分が上手くできているか。
見落としがちですが、スケジュールを組んだ時に同じ期間に同じ人のタスクがいくつも重なってしまう事があります。この部分は
全てのスケジュールに対して根拠を説明できるか
プロットしたスケジュール全てに対して、この工数をした根拠、このタイミングに配置した根拠を説明できるようにする事。
How（どう管理していくか）の決定
プロジェクトが進行している間にどのような管理をしていくか、明示する必要があります。
進捗管理
どのように進捗管理をするのか（例えば、開発者内ではWBSを活用してやります、など）を明記します。また、どんな会議体で進捗管理するのか、についても明記しておく必要があります。
会議体では、
顧客進捗定例
期間：週1回（月曜日：16:00~17:00）
アジェンダ：WBSに沿って進捗報告、障害発生状況、課題確認など
といった形で社内の進捗報告、顧客への進捗報告をどのように行うのか記載します。
課題管理
課題をどのように管理していくか（内部用、顧客提示用とブックを分けて管理する、など）、どんなフォーマットで管理していくのかを明記します。
簡単なフォーマットについて、シェアします。
プロジェクトマネージャーに求められるもの
スキル
業種問わず、どのプロジェクトでも求められるポータブルスキルがコミュニケーション能力です。
コミュニケーションスキルというのは、話すことが上手い、交渉力がある、営業スキル、ということを言っているのではありません。
ミーティングや問題発生時に相手の話を正確にかつ迅速に理解する力、および自分が伝えたい内容を適切に相手に伝えることができる能力のことを指してます。
また、プロジェクト計画書で言うと、プロジェクトに関わるメンバー全員とコンセンサス（合意）を取らなければなりません。
そんなことから、適切なメンバーに適切な順序で根回しをする段取り力も求められるスキルの一つと感じてます。
マインド
プロジェクトマネージャーに求められる資質は完全に私の経験からなるものですが、簡単な一言で言ってしまうと以下の通りです。
当事者意識を持つことは必要だが、ある意味で開き直りが大事。
この言葉をもう少し細かく噛み砕いて言語化すると、以下みたいな言葉が出てきます。
・自分が全て責任持ってやろうとは思わない。
・想定通りいかないことは当たり前と思った方が良い。
・関係者とのコミュニケーションは密に行うことを心がける。
・困ったらなんでも相談できる相手を作る。
まとめ
プロジェクトマネジメントについて、思いついたことをバーっと書かせてもらいましたが、要約して一枚のスライドまとめると以下になります。
まだまだ書き足りない部分も沢山あるので以降も更新をしていこうと思います。
「こういったことも知りたい」などありましたら、遠慮なく私のアカウントにご意見ください！
参考文献
各々のレベルに応じて参考となる文献を紹介します。
初級
中級
上級
この記事が気に入ったらサポートをしてみませんか？