プロジェクト管理について語る
自己紹介
はじめまして。ミルディアの廣瀬です。
新卒でITシステム開発の業界に入り、開発工程はいわゆる上流工程から運用・保守まで、開発領域は.NET界隈を主戦場としつつ、Webからネイティブアプリ、インフラ、サーバーなどその時々で必要とされる役割・業務を四苦八苦しながらこなすなんでも屋さんとして過ごしてきました。（フルスタックエンジニアと解釈するか、器用貧乏と解釈するかは難しいところです）
ミルディアに入社してからは主にマネジメント業務を中心に、みなさんに支えてもらいながら日々を過ごしております。
家庭では二児の父として子育てに奮闘しており、子供たちと同じ目線で趣味のスターウォーズのフィギュアを奪い合う毎日です。
（それはパパのおもちゃだから触っちゃダメ！と怒る日々・・・）
個人的にはコードをガリガリ書くエンジニアとしての活動も好きなのですが、せっかくなのでブログの場ではエンジニアとしての顔はそこそこに、マネジメント業務に従事する者の端くれとして、後進の若きマネージャー入門者や、マネジメントには普段あまり関わらない方を対象に、普段考えていることなどを発信できたらと思います。
今回のテーマ
さて、初回の記事なのでまずはプロジェクト管理とは何ぞや？について簡単に説明してみます。
今回はざっくりとした概要をスコープとして、それぞれ具体的なケースについては別の機会に記事にできたらと思います。
概要の理解を目的とするため、「厳密にはちょっと違うんだけどね」みたいな説明も含みますが、マネジメントの緒先輩方には暖かい目で見守っていただければ幸いです。
そもそもプロジェクトとは？
ITシステム開発の世界では何気なくよく使われる『プロジェクト』という言葉ですが、ちゃんと明確な定義があります。
『独自のプロダクト、サービス、所産を創造するために実施される有期的な業務』 こそがプロジェクトである、と定義されており、対となる概念として定常業務があります。
ポイントは『独自の～～を創造する』と『有期的な』の部分で、以下を満たす活動をプロジェクトと呼びます。
- 何かしらの成果物がある（体験など、形に残らないものも含む）
- 開始～終了までの期限がある
『○○システムの新規開発』、『国を南北に縦断する地下鉄を開通させる』、『20xx年度hogehoge高校3年B組 文化祭』等の例は有形・無形を問わず成果物があり、開始と終了が明確に定められているのでいずれもプロジェクト活動です。
一方で毎日・毎週・毎月行われる活動はプロジェクトとは呼べないので、例えば企業の経理業務だったり、稼働中のシステムの運用保守は厳密にはプロジェクト活動には含まれません。
（長期的な視点ではどんなシステムもいつかはEOLを迎えるし、『11月の締め作業』という括りだけで見たら開始～終了までの期限があるとも言えるのですが、一応定義としてはそうなっている位の理解で良いと思います）
プロジェクト管理とは？
さて、それを踏まえるとプロジェクト管理とは 『プロジェクトの成果物を、計画通りに完成させるために必要な活動のすべて』 と言えそうです。
プロジェクトが計画通りにできているか、については特に 品質(Quality)、予算(Cost)、納期(Delivery) という軸で評価することが多いです。頭文字を取って『QCD』なんてよく言うので、管理業務に興味があれば（なくても）覚えておくとよいです。
もちろん品質は高く、予算は少なく、納期も短いほうが良いとされていますが、一般的には品質と予算・納期はトレードオフの関係になりがちで、QCDのよいバランスでの着地を目指すことになります。
なぜプロジェクト管理が必要なのか？
なぜプロジェクト管理という活動が必要なのか。それはズバリ、プロジェクト活動というものはことごとく、放っておけばエントロピー増大の法則に従って品質は低くなり、予算は嵩み、納期は遅れるからです。（断言）品質は低くなり、予算は嵩み、納期は遅れるからです。（大事なことなので二度言いました）
プロジェクト活動の経験がそれなりにあれば、おそらくいずれかの項目が（あるいはその複数が）残念な結果に終わった思い出があるのではないでしょうか？
それもそのはずで、一般社団法人 日本情報システム・ユーザー協会が調査した『企業IT動向調査報告書2024』によれば、「プロジェクトの品質、予算、納期それぞれの項目が予定通りに完了した」と回答した割合はいずれの項目も多くはなく、日本のITシステム開発のプロジェクトがすべて大満足な結果に終わることは残念ながらあまり多くなさそうです。世の中には失敗するプロジェクトのほうが多いので、残念な思い出が残りやすいのも統計的には必然というわけです。（そうでないあなたはとても運がいいのか、とても優秀なのか、評価基準が甘いのか）
でもせっかく何かを成し遂げるなら、やっぱり少しでも満足できる結果を得られた方が嬉しいですよね？だから人はプロジェクトを管理しようとするのです。管理できなくても必死に管理しようと試みるのです。
具体的に何をすればいいの？
では、具体的に何をすればいいのでしょう？少しのことにも、先達はあらまほしき事なり。
今まで数々のプロジェクトを立ち上げて、時に成功させ、時に多くの失敗をしてきた先人たちの知恵を借りるのが一番です。そんな先人たちの知恵を集結させたガイドが世の中には存在します。
『PMBOK（Project Management Body Of Knowledge）』（ピンボックと発音）と呼ばれるプロジェクト管理における知識を体系的にまとめた書籍で、原本は英語ですが日本語をはじめ多くの言語に翻訳され、プロジェクト管理界隈のバイブルとして位置づけられています。
先人たちの知恵、と言いつつ世の中の時世に合わせて数年ごとに改訂を続けており、現在は2021年に発行された第7版が最新版となっています。
そのPMBOK 第6版によるとプロジェクトを管理するためには 49の管理項目があり、それらは5つのプロセス郡（立ち上げ、計画、実行、監視、終結） と呼ばれるプロジェクトのライフサイクルと、10の知識エリアと呼ばれる管理項目分類の掛け合わせで表現できるそうです。（なぜ最新版を参照しないのかは後述）
具体的な各項目とプロセス・知識エリアのマッピングは以下の表のとおりです。（表にしたら大変なことになったので画像にしておきます）
列ごとにプロセス郡、行ごとに知識エリアを示しており、それぞれ49の管理項目がどの掛け合わせに該当するかを表現しています。
本来ならここで用語の説明や、49項目の内容を更に具体的に一つ一つ説明するべきなのですが、それをしているとブログの一記事というレベルではなくなるので省きます。まぁ何となく字面で想像できると思うので、この記事では「あぁ、いろんな領域について、いろいろと気にしなきゃいけないんだなぁ・・・」と、大まかな雰囲気を掴めるところまでを目標としましょう。
49項目それぞれの字面を見るだけでもいろいろなことを気に掛ける必要があることだけは分かります。正直ゲンナリしますね。
見た通り管理すべきことはたくさんあるので、すべてをキッチリコントロールしようとすると、管理コストは青天井で溶けていくことになります。
ほとんどのプロジェクトでは、管理コストとして確保しているリソースにも限りがあり、そのほとんどが上記全てを完璧に管理しようとする工数には足りず、管理者は限られたリソースで何をどこまでコントロールすれば最良の着地点に辿り着けるかを取捨選択することになります。（それを考えるのが計画プロセスの各～～マネジメントの計画ですね）
「いやいや、うちはすべてをキッチリ管理してますよ」というプロジェクトがあるなら、そちらは絶対に失敗できないミッションクリティカルなプロジェクトなのでしょう。さぞかし日々胃が荒れる思いをなさっているかと存じます。逆に、「うちはそんなの全然管理してないぞ！？」というプロジェクトも冷静に振り返ると、実は意識していないだけで大なり小なり何かしらの項目を管理をしていると思います。
余談：PMBOK 第6版とPMBOK 第7版について
さて、プロジェクト管理の具体的な項目を挙げるために、先ほどPIMBOKの一つ古い版を参照しました。
何故かというと第6版と第7版で内容がガラリと変わっているからです。
ザックリと歴史を踏まえて解説すると、昔はしっかりとした計画を立てて、計画通りに遂行することと、顧客への価値提供がほぼ同義に考えられていました。
しかし、近年はプロジェクトを取り巻く環境の変化や、制約・前提条件などは常に変化し続け、立案段階の計画通りに進めることが必ずしも正解とは言えません。
また、プロジェクトの定義でもあった 『独自の～～を創造する』 の部分、この独自性が多種多様にわたり、必ずしも前例の画一的なプロセスを踏めばよいという訳ではなくなりました。
そこで、PIMBOKもプロセス主義のハウツーから、根本的な原理原則を示す行動指針へと大きく位置づけを変えて、内容も大幅に変更されました。
まぁアジャイルとかスクラムとかの考え方が産まれたのと経緯は一緒ですね。
違いをまとめると以下のような感じです。（別に細かいところは最初は覚えなくていいです）
| PMBOK 第6版 | 特徴 | PMBOK 第7版 |
|---|---|---|
| 成果物の提供 | 目指すゴール | 価値の提供 |
| 具体的なハウツー | 内容 | 指針となる原理・原則 |
| 5つのプロセス群(前項参照) | 体系分類 | 12の原理・原則 |
| 10の知識エリア(前項参照) | 対象 | 8つのパフォーマンス・ドメイン(行動領域) |
第7版では不確実性を広くカバーするために記述内容の具体性は失われたため、実際に個別の具体的なコントロール手法を知りたいときは第6版を参照するほうが良い場合もあります。
そんな事情もあって、PIMBOKを参照する際は必ずしも最新の版だけ抑えておけばよいという訳ではなく、知りたいことに合わせて参照する版も意識する必要があるのです。
第8版ではどうなるのか分かりませんがおそらくは第7版の方針を踏襲するので、しばらくは第6版と最新版を用途に合わせて照らし合わせることになるのかなぁ、と思っています。（とても大変ですね。。。）
プロジェクトマネジメント資格：PMP®︎取得のススメ
もしも興味があれば、PMP（Project Management Professional）という国際資格の取得を目指してみるとよいかもしれません。
先述のPMBOKを取りまとめているPMI（Project Management Insitute）という団体が認定している資格です。
PMI日本支部の説明によれば
PMP® 試験は、受験者のプロジェクトマネジメントに関する経験、教育、知識を測り、プロフェッショナルとしての確認を目的として実施されます。
専門知識を有していることを証明するために、米国PMI本部が資格認定を行うものであり、法的な資格、免許ではありません。
PMP® 資格は、プロジェクトマネジメントに関する資格のデファクト・スタンダードとして広く認知されており、プロジェクトマネジメント・スキルの評価基準として、IT・建設をはじめとする多くの業界から注目されています。
一般社団法人 PMI日本支部 PMP®資格について より引用
だそうです。
特に業務独占資格ではないのですが、問われる内容もPMBOKの範囲から出題されることが多く、普遍的にプロジェクト管理について体系的な知識を身に着けていることの証明にはなります。
3年毎に更新も必要で、取得はもちろん維持をするのもそこそこ大変ではありますが、資格取得自体というよりも資格取得過程のお勉強は、必ず力になるかと思います。
終わりに
気が付いたら結構な長文になってしまいました。これでもだいぶはしょったつもりだったのですが、早速なんでも詰め込もうとする自分の文章の癖が全開になっています。
初心者向けの記事のはずなのに妙なプレッシャーをかけることになっていないか心配です。
とはいえ具体的にPIMBOKなどを読み解いていけば、書かれている内容は意外と体感で分かっていることを改めて言語化しているだけだったりするのでビビらなくても大丈夫です。
苦労が多そうにも見えますが、その分だけ物事がうまく進んだときの達成感もまた大きく、関係者が喜んでくれる姿を眺めるのもよいものです。
この記事をきっかけにプロジェクト管理の世界に少しでも興味を持ってもらえれば幸いです。
最後に某研修で印象的だった言葉を引用して締めたいと思います。
「理解は容易。習得は困難。チェスのルールと一緒。」