こんにちは。倉内です。
プロジェクトマネジャー（以下、PM）は、資格が必須というわけではない*1ため、極端な話「明日から君がこのプロジェクトのPMだ！」ということもありえます。
もちろん普通はチームリーダーやプロジェクトリーダー（以下、PL）を経ての任命が多いと思いますが、PMはその名の通りプロジェクトを管理し、システムの納品もしくはリリースまで確実に進行しなければならない重要な役割です。一朝一夕で完ぺきにできるものではなく、経験を積むことでうまくこなせるようになる部分もあります。
ただ、プロジェクト計画の立て方、見積もり、ステークホルダとの関係構築…など、PMとして知っておくとよい基礎知識はあります。
今回はそれらの内容をこれからPMになる、もしくは新米PMの方にお伝えしていきたいと思います。
そもそもPMの役割ってなんだろう？
「プロジェクトをマネジメントする」と言ってもよく分からないので、もう少し役割について具体的に見ておきましょう。なお、今回は受託開発のプロジェクトを想定して書いている部分が多いですが、自社開発でも通ずる部分はあると思います。
PMのおもな役割は、プロジェクト立ち上げ時は計画立案や見積もり、受注後は顧客との要件調整、プロジェクトのスケジュールや人員調整、予算管理などです。
中でも成果物を期日までにお客さまへ納品する、もしくは決められた日にサービスをリリースすることがもっとも重要な使命となります。
特に規模が大きい案件ではPMのマネジメント力がプロジェクトの成否を左右しますし、単にチームメンバーとのコミュニケーション能力だけでなく顧客との交渉力まで問われます。
また、プロジェクトの予算、スケジュール、システムの品質管理はもちろん、ステークホルダのマネジメントも欠かせません。
ステークホルダは「利害関係者」を意味し、顧客（システム利用者、決済権のある人物、経営層）や協力会社のメンバーだけでなく、自社のプロジェクトメンバーや関連する他部署などを含めた関係者すべてを指します。
（参考サイト）【第15章】ステークホルダーマネジメントを意識しよう：ステークホルダマネジメントとは
（補足）「PMBOK」を知っておこう
プロジェクトマネジメントについて語るとき、「PMBOK」というものが必ず出てきます。「PMBOK」とは、「プロジェクトマネジメント知識体系ガイド」のことで、ソフトウェア開発のプロジェクト管理において必要な知識体系が得られます。
PMBOKでは、プロジェクトマネジャーに求められる能力として「プロジェクトマネジメントの技術」「戦略的及びビジネスのマネジメント」「リーダーシップ」の3つを挙げています。（出典：日経クロステック）
完全に内容を把握するのは大変ですが、ざっくりとでも理解しておくとPMに必要な体系立った知識が得られます。
まずはプロジェクト全体の流れを知る
新卒入社直後にPMになることはおそらくないので、経験年数は多少前後しても皆さんはこれまでエンジニアとしてプロジェクトに従事していた経験がある状態だと思います。
ただ、大企業の場合は、いち社員が担当するのは全体工程のほんの一部であることも多く、全体の流れは見えにくいですよね。
開発工程以降だけでなく、要件定義や基本設計といった上流工程の経験がある人でも、それ以前、つまり営業と一緒に提案活動をおこなったり、顧客から出されたRFPから提案書・企画書を作成して、見積もりをして受注に至るという過程をしっかり理解していない場合もあります。
プロジェクトの内容や規模、契約内容によって異なる点はありますが、基本的にはプロジェクト全体の流れは以下の図のとおりと思ってください。
RFP（Request for Proposal）とは
RFPというのは、顧客から提示される((顧客がシステム開発案件に慣れていない場合などは、RFP作成だけを切り出してシステム会社に委託することもあります。）「提案依頼書」のことです。
発注側の企業がシステム開発会社（SIerやベンダー）に対して、現在抱えているシステムに関する課題、それを解決するためにシステムに必要な機能などを示す書類です。
以下の記事の内容は発注側に向けて書かれていますが、RFPについて分かりやすくまとめてあるのでよければ参考にしてみてください。
RFPとは？提案依頼書の基本を解説｜株式会社NTTデータビジネスシステムズ
システム開発会社はRFPを受けて、提案書を作成します。提案書には一般的には以下のような項目を記載します。
- あいさつ（自社の紹介）
- 提案の目的
- システム全体構成図
- システムの基本方針および方式
- 機能一覧
- スケジュール
- 体制図および作業場所
- 作業一覧と主担当（責任の所在）
- 成果物（うち納品物）
- お見積り
- 会議体（顧客とのコミュニケーション）
- 本番環境移行計画書
- 保守範囲（瑕疵担保責任）
- 懸念事項
など
この項目以外にも必要なものもあれば、不要なものもあります。
提案書は決まった形式というものがないので、自社の過去の事例などを参考にするのがよいでしょう。
システム開発の見積もりをする
見積もりというとお金のことだと思いがちですが、システム開発においては「このプロジェクトを完遂するために必要な工数とそれにともなった予算」を算出することだと考えてください。
もう少し噛み砕くと、「要求された機能を実現してシステムの納期を守るためには、どんなスキルを持った人が何人必要で、各工程に必要な期間はどのくらいで、それらを達成するには費用がいくらかかるか」という感じですね。保守・運用も作業範囲であれば、それらも考慮します。（保守費用は開発費用とは分けて、別途見積もることもあります）
よく「工数を見積もる」という単語を聞くと思いますが、これは「何人月かかるか？」つまり「何人いたら何カ月かかるか？」を算出することを意味しています。
システム開発が難しいのは、たとえば新人とベテランがともに「1人」いたとしても機能実装にかかる時間や品質にはおそらくかなりの差が出るところです。ベテランばかり集めてプロジェクトチームを組めればいいですが、現実はそういうわけにもいかないので工数を見積もる際は気をつけましょう。
開発規模を見積もる3つの手法
システム開発の規模を見積もる方法として、係数モデル見積もり（パラメトリック見積もり）をよく使います。
見積もりは経験値が高いほど精度が上がりますが、新米PMのうちからある程度の精度を持って見積もりをするために、ここでは信頼性の高い手法である「係数モデル見積もり」を紹介します。
係数モデル見積もりでは、おもに以下の3つのモデルが使われます。
- ファンクションポイント法
- COCOMOモデル、COCOMOⅡデモル
- Putnamモデル
この中では、情報処理技術者試験でもよく出題されるファンクションポイント法が比較的馴染みがあるかもしれません。
（参考サイト）FP法の計測手順 | 日経クロステック（xTECH）
見積もり対象となる項目
これもプロジェクトの内容や規模によって異なりますが、基本的には以下のような項目を見積もり対象とするとよいでしょう。
- 要件定義費用
- 設計費用（機能・非機能・画面）
- 管理費用
- 開発費用
- 初期導入費用
- 導入教育費用
- ハード購入費用
- 交通費
- 保守・運用費用
また、顧客には提示しないものの内部的に発生するものなども考慮が必要です。たとえば、営業費用、品質管理費、販売管理費、調達費、プロジェクトリスク費…などです。
これらは直接費・間接費に分けられます。忘れているものがあると原価管理が正しくできないためしっかり理解しておきましょう。詳細は以下の参考サイトもごらんください。
（参考サイト）第1回【ＩＴプロジェクトにおける原価管理とは】：プロジェクト原価管理連載シリーズ
必ずというわけではありませんが、大規模なプロジェクトであるほど提案書提出時点での見積もりは概算で、そのあと要件定義で機能要件・非機能要件がはっきりしてから再度見積もりをすることが多いです。
というのもRFPの情報だけでは不確定要素が多く、また要件定義段階で初めて明らかになる顧客要望や認識のズレなどがあるからです。
そのため契約としては要件定義とそれ以降の工程と2つに分けて結ぶこともあります。
できる限り精度の高い見積もりをするためには、要件定義でしっかり顧客と認識を合わせ、システムで実現しなければならないことを漏れなく明らかにする必要があります。（それが非常に難しいのですが…）
また、工数を勘で見積もったり、まったくバッファがない見積もりをすると失敗する可能性が高くなるため避けましょう。
ちなみに要件定義については、以下の記事で詳しく説明しているのでよければごらんください。
プロジェクト計画を立て、進行管理をする
ここまで見積もりにフォーカスしてお話ししてきましたが、今度は計画を立てるところと、進行管理についてお伝えします。
計画立案：
- プロジェクト計画書の作成
- WBSの作成
- ガントチャートの作成
進行管理：
- スケジュール管理
- 資源マネジメント（人、お金）
- 品質管理
- リスクマネジメント
以降でもう少し詳しく説明します。
プロジェクト計画書
プロジェクトを成功に導くため、プロジェクト計画書には以下のような内容を記載します。
- プロジェクト概要
- プロジェクトの目的とゴール
- スコープ
- スケジュール（作業開始、納期の明示）
- 費用
- 体制
- 品質
- コミュニケーション
- リスクと対策
具体的には、自社の過去のプロジェクトを参考にするとよいとおもいますが、以下のサイトも参考にしてみてください。
WBSとガントチャート
WBS（Work Breakdown Structure）は、プロジェクトに必要な作業を細かく分解することで、特に規模の大きなプロジェクトで見えにくい作業の全体像を把握し、適切な管理をするために利用します。
一方、ガントチャートは進捗管理のためのスケジュール表で、全体の状況を把握するのに長けています。縦軸に作業内容、横軸に作業開始日・作業完了日を記載して、進捗を管理します。日々の進捗が目で見て分かりやすいので、多くのプロジェクトで使われています。
WBSとガントチャートは役割が異なるため、併用することでより効果が発揮できます。
以下のサイトでは具体的な例も掲載されているため、まだ一度も作ったことや見たことがないという方はぜひ参照してみてください。
（参考サイト）WBSとガントチャートとは？違いや関係性を解説 - タスク・プロジェクト管理ツールJooto (ジョートー)
PMには技術的スキルが必要か
ここまでおもに見積もり、プロジェクト計画、そして進行管理の3つについてお伝えしてきました。
いずれもPMにとっては非常に重要な仕事で、どれかひとつでも欠けていたらプロジェクトはうまくいかないでしょう。
特にプロジェクト規模が大きくなればなるほど、それらの管理工数は大きくなり、PM自身がコードを書いたり手を動かすことはなくなります。管理だけで手いっぱいでとても実作業まで手が回らないからです。
しかし、だからといって技術的スキルがなくてもいいかというとそこは少し違うかなと思います。
スキルがまったくないとそもそも見積もりや要件定義の精度が著しく下がります。上流工程に不備が多いと、あとの工程にしわ寄せが来て、プロジェクト炎上の原因となります。
そしてリスクマネジメントという観点でもスキルがないと対応できない（対応策を考えられない）ことが多く、結局はスケジュールの見直しを迫られたり、赤字プロジェクトとなったりマイナスな面が大きくなります。
ただ、技術的なスキルについては、仕事で機会がないとなかなか身につけるのが難しいですよね。
最近はpaizaラーニングのように、オンラインで手軽にプログラミングを学習できるサービスも充実していますので利用してみてください。
paizaラーニングでは、ブラウザさえあれば、すぐにプログラミングの基礎が動画で学べるレッスンを多数公開しております。
まとめ
これからPMになる人、PMになったばかりの人が知っておくとよいプロジェクトマネジメントの基礎知識についてお伝えしてきました。
詳細までは紹介できなかった部分もあるので、ご自身でも調べたり職場の先輩PMに話を聞いたりして力をつけていきましょう。
エンジニア経験が十分にある人でも、PMとなるとはじめのうちはうまくいかず悩むこともありますが、基本的なことをしっかり押さえて経験を積めばだんだんとコツが分かるようになってきます。
大規模なプロジェクトのPMは責任も大きく大変な仕事ですが、その分プロジェクトを成功させたときの達成感は他では味わえないものです。
paiza転職では、開発系エンジニア職だけでなく、PMやコンサルタントに近い業務内容の募集までさまざまな求人票を掲載しています。
paiza転職について詳しくはこちら
paizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
*1:企業によっては、一定規模以上のPMに従事するためにPMP資格や情報処理技術者試験の「プロジェクトマネージャ試験」の取得が必要な場合もあります。
