「プロジェクト」という言葉は、仕事をしていると当たり前のように使う。
「このプロジェクトでは――」
「プロジェクトメンバーとして――」
「プロジェクトを成功させるために――」
自分自身も、これまで何度も使ってきた。
でも改めて考えてみると、
そもそも、プロジェクトとは何なのだろう。
意外とうまく説明できない。
期限が決まっている仕事なのか。
複数人で進める仕事なのか。
大きな仕事のことなのか。
プロジェクトマネジメントについて改めて勉強する中で、峯本展夫氏の『プロジェクトマネジャーになる』を読み、この「プロジェクトとは何か」について一度整理してみたいと思った。
今の自分なりの理解では、
プロジェクトとは、実現したい未来に向かって、限られた期間の中で独自の成果を生み出し、それを価値につなげていく活動
なのだと思う。
今回は、この考え方を少し掘り下げてみたい。
プロジェクトには終わりがある
まず、プロジェクトについて調べていくと出てくるのが「有期性」という言葉だ。
PMIでは、プロジェクトを、独自のプロダクト、サービス、成果を生み出すための一時的な取り組みとしている。
ここで出てくるのが、
有期性
独自性
という2つの特徴になる。
「一時的」と聞くと少し分かりにくいが、要するに始まりと終わりがあるということだ。
例えば、毎月同じ帳票を作る仕事がある。
これは基本的には繰り返し行われる業務になる。
一方で、
「現在Excelで行っている集計業務を自動化するシステムを6カ月で作る」
となると、少し意味が変わってくる。
システムを作り始める時点があり、完成すれば一区切りになる。
そして、今まで存在しなかった新しい仕組みを作る。
こちらはプロジェクトとして考えやすい。
つまり、
仕事が大きいからプロジェクトになるわけではない。
ここは自分の中でも少し認識が変わったところだった。
一人で行う小さな取り組みであっても、
「こういう状態を実現したい」
というゴールがあり、期間を区切って新しい成果を作るのであれば、それもプロジェクトになり得る。
「独自性」とは何だろう
もう一つの特徴が「独自性」だ。
最初にこの言葉を見たとき、
「完全に新しいものを作らなければ、プロジェクトとは言えないのだろうか」
と思った。
ただ、そういう意味ではない。
例えば、ある会社で何度も同じような業務システムを構築していたとしても、
利用する会社が違う。
ユーザーが違う。
要求が違う。
予算が違う。
納期が違う。
関係者も違う。
まったく同じ条件になることは、ほとんどない。
だからこそ、プロジェクトは一つひとつ違う。
過去の経験やテンプレートを使うことはできる。
それでも、
今回のプロジェクトには、今回のプロジェクトなりの判断が必要になる。
このあたりは、ソフトウェア開発をしているとかなり実感するところだ。
似たようなシステムを作っていたとしても、前回うまくいった進め方をそのまま持ってくれば、今回もうまくいくとは限らない。
プロジェクトマネジメントに「これをやれば必ず成功する」という正解がない理由の一つなのだと思う。
では、成果物を作ればプロジェクトは終わりなのか
ここまで考えると、プロジェクトとは、
「一定の期間の中で、独自の成果を生み出す活動」
と言えそうだ。
では、システム開発プロジェクトであれば、
システムを完成させれば、それで成功なのだろうか。
例えば、半年かけて業務システムを開発したとする。
予定した日にリリースできた。
予算も守った。
要求されていた機能も実装した。
一見すると、問題なく成功したプロジェクトに見える。
ところが実際に使い始めると、
「以前より入力項目が増えてしまった」
「使いにくい」
「結局Excelで作業している」
という状態だったとする。
システム自体は完成している。
それでも、
「このプロジェクトは成功した」
と言われると、少し違和感がある。
なぜだろう、と考えると、
システムを作ること自体が、本来の目的ではなかったから
なのだと思う。
成果物の向こう側に目的がある
業務システムを作るのであれば、その前に何か理由があったはずだ。
業務を効率化したい。
入力ミスを減らしたい。
人手を減らしたい。
利用者の負担を軽くしたい。
情報を一元管理したい。
システムは、こうした状態を実現するための手段にすぎない。
ところがプロジェクトが始まると、
「画面をいつまでに作るか」
「この機能は完成したか」
「スケジュールから何日遅れているか」
といった話が中心になっていく。
もちろん、これらを管理することは必要だ。
ただ、そのことばかり見ていると、
そもそも何のためにこのシステムを作っているのか
ということが抜け落ちてしまう。
これは自分自身も気を付けなければならないところだと思う。
目の前のタスクを追いかけていると、そのタスクを完了させることが目的になってしまう。
でも、本来はその先に目的がある。
そこで「価値」という考え方が出てくる
ここで重要になってくるのが「価値」だ。
価値という言葉は少し抽象的だ。
ただ、
プロジェクトを行ったことで、誰かにとって意味のある変化が生まれたか
と考えると、自分には少し分かりやすい。
例えば、
「毎月10時間かかっていた作業が1時間になった」
というのは、比較的分かりやすい価値だ。
一方で、
「入力ミスを心配しなくてもよくなった」
「作業が分かりやすくなった」
「問い合わせ対応に時間を使えるようになった」
といった変化もある。
こちらは数値では表しにくいかもしれない。
それでも、利用する人にとっては大きな価値になる。
ここで面白いのは、
価値は、人によって違う
ということだ。
誰にとっての価値なのか
同じプロジェクトであっても、立場が違えば見え方も変わる。
経営者であれば、
「コストを削減できたか」
というところを見るかもしれない。
現場の利用者であれば、
「仕事が楽になったか」
を気にするかもしれない。
開発する側であれば、
「無理のないスケジュールで品質を確保できたか」
を重要だと考えるかもしれない。
つまり、
一つのプロジェクトでも、関係者によって期待しているものが違う。
ここで出てくるのが、ステークホルダーだ。
プロジェクトに影響を与えたり、プロジェクトから影響を受けたりする人や組織をステークホルダーと呼ぶ。
発注者。
利用者。
開発者。
プロジェクトマネジャー。
経営者。
取引先。
プロジェクトによっては、さらに多くの人が関わってくる。
そう考えると、
「プロジェクトが成功したか」
という問いも、思っていたより単純ではない。
QCDを守れば成功なのか
プロジェクトでは、QCDという言葉もよく使う。
- Quality：品質
- Cost：コスト
- Delivery：納期
品質を守る。
予算を守る。
納期を守る。
どれも当然重要だ。
自分もプロジェクトを管理するときには、必ず意識する。
ただ、
QCDをすべて守れば、必ず価値のあるプロジェクトになるのだろうか。
先ほどの例のように、
予定通り。
予算通り。
仕様通り。
それでも、誰にも使われないシステムができることはある。
逆に、途中で計画を変更したことで当初よりコストが増えたとしても、その判断によって利用者にとって大きな価値が生まれることもある。
もちろん、
「価値さえあれば予算超過してもいい」
という話ではない。
QCDは重要だ。
ただ、
QCDはプロジェクトを管理するうえで重要な指標ではあるが、プロジェクトの目的そのものではない
ということなのだと思う。
プロジェクトでは認識をそろえる必要がある
ここまで考えてくると、
プロジェクトの最初に、
「何を作るか」
だけを決めるのでは足りない。
このプロジェクトで、どんな状態を実現したいのか。
誰に、どんな価値を届けたいのか。
何をもって成功と考えるのか。
こういったことを、関係者の間で共有しておく必要がある。
そして、さらに難しいのは、
その認識がプロジェクトの途中で変わることだ。
市場が変わる。
技術が変わる。
会社の方針が変わる。
利用者から新しい要望が出る。
予算が変わる。
プロジェクト開始時には正しかった判断が、半年後にも正しいとは限らない。
だからプロジェクトでは、
最初に計画を立てて、あとはその通り進めれば終わり、
とはならないのだと思う。
プロジェクトマネジャーは何を管理しているのか
プロジェクトマネジャーというと、
進捗を管理する人。
スケジュールを管理する人。
会議を開く人。
課題管理表を更新する人。
そんなイメージもあると思う。
実際、それらも仕事だ。
ただ、『プロジェクトマネジャーになる』を読みながら考えていると、
それだけではかなり狭い捉え方なのではないかと思うようになった。
プロジェクトでは、常に何らかの判断が発生する。
この要求を受け入れるのか。
納期を優先するのか、品質を優先するのか。
予定していた方法を続けるのか。
計画を変更するのか。
誰に相談するのか。
どこで決断するのか。
そして時には、
「そもそも、このプロジェクトを続けるべきなのか」
という判断もあるかもしれない。
こういった場面で、
プロジェクトの目的。
ステークホルダーの期待。
現在の状況。
制約。
リスク。
それらを見ながら意思決定していく。
それがプロジェクトマネジメントの重要な部分なのだと思う。
改めて、プロジェクトとは何だろう
最初の問いに戻る。
プロジェクトとは何なのだろう。
一般的な定義として考えるなら、
一定の期間の中で、独自の成果を生み出すための活動
ということになる。
そこに今回、自分が考えたことを加えるなら、
現在とは違う「こうありたい」という状態に向かって、人と協力しながら意思決定を重ね、価値を生み出していく活動
なのだと思う。
期間がある。
実現したいものがある。
そこに関わる人がいる。
そして、その先に何らかの価値がある。
こう考えると、
プロジェクトマネジメントは、単純なスケジュール管理ではなさそうだ。
むしろ、
「何のためにこのプロジェクトをやっているのか」を見失わず、その時々で必要な判断を続けること
なのかもしれない。
今回、改めて「プロジェクトとは何か」を考えてみたことで、これまで自分が経験してきたプロジェクトも少し違った見方ができるようになった気がする。
次は、
「では、プロジェクトの成功とは何なのか」
というところを、もう少し掘り下げてみたい。
参考
本記事を書くにあたり、峯本展夫氏の『プロジェクトマネジャーになる』を参考にした。
書籍の内容をそのまま解説するのではなく、これまでのソフトウェア開発やプロジェクトでの経験と照らし合わせながら、自分なりに考えたことを整理している。
また、プロジェクトの基本的な定義については、PMI（Project Management Institute）の考え方を参考にした。
