FIXER Tech Blog - Learning

FIXER cloud.config Tech Blog

プロジェクトの「成功」って何？【PMBOKを読み解く #2】

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「プロジェクトの成功って何？【PMBOKを読み解く #2】」を再編集したものです。

はじめに

　前回の記事では、プロジェクトとは何なのか、について理解をしました。

　そこでは、プロジェクトは「新しい何かを作り出す業務のうち、開始と終了が明確になっているもの」という整理をしました。

　プロジェクトの成功（失敗）やそこに至るまでの条件はどの様になっているのか気になって、朝も起きれない皆さんの為に「PMBOKを読み解く#2」ではプロジェクトの制約、成功/失敗について理解をしていきます！（強引）

プロジェクトの目的と目標

　皆さんがプロジェクトを始めるぞ！ってなったとき、意味もなくがむしゃらに頑張るぞ〜なんてことはないですよね。

　何か意味があって始めるはずです。何のためにプロジェクトを始めるのかの“何の”のことを「目的」と呼びます。

　目的を明文化することで、プロジェクトがどこに向かうのかをハッキリとさせることができ、迷子になることも減りそうですね。

　ここでひとつ例え話をしましょう。友人数人で名古屋城を見に行くという旅行の計画をたてることをプロジェクトに見立ててみます。

Let's go 名古屋

　名古屋へ旅行へ行こう！ と言っても友人それぞれ目的は異なります。

　食べるのが好きなAさんなら、名古屋飯を堪能したいでしょうし、歴史が好きな人なBさんは名古屋城は外せないでしょう。

　同じ事柄を成す場合でも目的は認識を合わせない（明文化しない）限りこの様にばらついてしまうものです。

　では、仮に目的を名古屋城観光と決めたとしましょう。これでもう旅行の計画はバッチリです！な訳はないですね。

　このままでは、いつ行くのか、どのように行くのかなど色々と決まっていないことがあります。

　何時の新幹線に乗るのか、いつどのホテルにチェックインするのかなど具体的に計画を立てますよね？ これが「目標」です。（図1参照）

　目標をクリアしていくと、最終的には目的が達成されるわけです。

図1.名古屋旅程

名古屋飯は何処へ

　きっちり計画を立てて名古屋城観光旅行は成功を収めることができそうです！

　何か一人不満げな表情を浮かべている人がいますね... 食べるの大好きAさんです。

　Aさんが満足できていないこの旅行は成功といえるのでしょうか？

　例えば、旅程の昼食やチェックイン後のフリータイムに名古屋飯満喫計画を入れることでAさんの要望も叶えることができそうです。

　Aさんも満足できる名古屋旅行ができればこの旅行は成功と言っても皆さん違和感ないのではないでしょうか？

プロジェクトの目的と目標のまとめ

　ずっと旅行の話をしていましたが、元の話を思い出しましょう。プロジェクトの目的と目標でしたね。

　プロジェクトも旅行と同様、プロジェクトの関係者（関係者については別記事で詳しく解説します）が満足することが出来たか否かというのが大きな判断材料になります。

　それをはっきりとさせるためにも、何を目的として、そのためにどの様な目標をクリアしなければいけないのかということを事前に（旅程を立てるように）定めておく必要があります。

僕が考えた最強の旅行にしよう！

　よし！ それなら誰しもが満足するような最高の旅行を計画しよう！ とあなたは計画を練り直すことにしました。（という設定でお願いします）

新幹線はグリーン車で広々快適な旅路を。歴史好きのBさんのために名古屋城だけでなく、名古屋の白鳥古墳や様々な史跡をめぐろう！Aさんのために3食名古屋飯満喫プランも盛り込もう！ホテルは最高級の部屋を用意しよう！…

　確かにこんな旅行に“連れて行ってもらえる”ならいいかもしれませんが、お金はどうするの？ とか時間が足りないとか、流石に名古屋飯3食はお腹いっぱい… みたいなことになりますよね。

　要するに様々な制約があるということです！それではプロジェクトの制約について考えていきましょう！（今回は導入が強引な回です）

代表的な制約

　制約と言っても色々あるじゃんか！ っていうのが第一印象かと思います。そもそも、マネジメントとかそもそも要素を洗い出して体系立てられるのかよっていうのが僕の第一印象でした…

　でも良くある話とか、一般的にはっていう観点では十分に可能だというのが僕の今の考え方で、あくまでもベースラインとして理解をして、現場で自分でアレンジを効かせるっていうのが必要なんだろうと思っています。

　そんな前提で見てもらえるといいかなと。

　では早速、QCDって皆さんご存知でしょうか。結構有名だと思っているのですがどうでしょう？

　Qが品質（Quality）、Cがコスト（Cost）、Dがスケジュール（Delivery）です。

　端的に、どれくらい作り込むの？ どれくらいお金をかけれるの？いつまでに必要なの？ってところだと思います。

　それではひとつずつ見ていきましょう。

品質（Quality）

　プロジェクトの成果物（成果物については別の記事で紹介します）がどれくらい要求を満たしているかという度合いのことです。

　Aさんの名古屋飯を楽しみたい！ という要求をどれくらい満たせたかと今回は読み変えてみましょう。

　Aさんはどこか一ヵ所行ってみたいお店があったのか、それともひつまぶしをお店にはこだわらず食べてみたい、なのかなどです。

コスト（Cost）

　プロジェクトにかけられる費用のことです。

　Bさんはまだ学生でバイトをしながら貯めたお金で今回の旅行に行きます。とすると最高級のホテル！なんてことは言えませんよね。

　このプロジェクトにどれくらいのお金使うことができるのか、投資した時に得られる価値（価値についても別記事で解説します）が見合っているのかという観点で評価します。

スケジュール（Delivery）

　いつまでに成果物を収めるのか、価値を生み出すのかということです。

　例えば、Bさんが桜を名古屋城でみたいと要求しているのに7月に旅行を計画しては桜は見れませんよね。

　一方で、4月の上旬じゃないといけないのか？といわれるとそんな事はなくある程度の幅が許容されています。これがスケジュールによる制約です。

QCDの優先順位付け

　QCDそれぞれに譲れるものと譲れないものがあります。

　そのため何を最優先にプロジェクトを進めていくのかという優先順位をそれぞれにつけます。

　例えば以下のような要求の時はコストを最優先に品質、スケジュールの順で優先順位をつける場合以下のように整理ができるのではないでしょうか？（図2. 表1参照）

図2.旅行要求

表1. 優先度のマトリクス

品質	コスト	スケジュール
	1
2		3

・コスト（5万円）を越えるとBさんが来れなくなってしまうので最優先
・品質はその中でできるベストエフォートで、桜が満開の時期に行くとホテルが高くてコストオーバーだけど少し早めにいけば予算内みたいな
・スケジュールは桜の咲いている期間で自由なので一番下の優先度
　・最悪咲いてない可能性もあるくらい→コストが最優先なので、ホテルの安い時期とか諸々調整した結果そうなる可能性も

まとめ

　プロジェクトの成功／失敗の基準は、QCDなどプロジェクトの制約条件を満たした上で、プロジェクトの関係者が納得できる価値が得られたかで判断ができそうですね。

　プロジェクトを体系的に理解することの利点は、プロジェクト単体を成功させることもあるのですが、一定のフレームでマネジメントをすることで、成功や失敗の経験を次に活かすことができるということです。

　そのため、成功しても失敗してもプロジェクト終了後には振り返りを行い次に活かす準備をするということも重要です。

塚本有希／FIXER
（つかもと　ゆうき）
2020年度入社のエンジニアだったものです。
fintech系の部署で開発をしたり、WebRTCで会議システムの基盤を構築したり、Azureのコグニティブサービスを使ってチャットボットのプラットフォームを作ったりカラフルな開発経験を積ませてもらいました。
その後別の案件でPMO業務に従事して、現在ではプロジェクト監理室というところで社内で横断的にプロジェクトの支援業務をしています。

■関連サイト

• cloud.config Tech Blogのエントリー
• cloud.config Tech Blog
• FIXER