こんにちは。スタメンでエンジニアリングマネージャーをしている @temoki です。
前回、プロジェクトマネジメント入門以前という記事でプロジェクトマネジメントとは何なのか？について次のようにまとめました。
プロジェクトとは 独自の目標を達成するために、決まった期間の中で、集団で活動すること です。 プロジェクトというのはとても困難であることが多いと思いますが、これを なんとか対処して 目標を達成することに導くのがプロジェクトマネジメントなのです。
今回は、プロジェクトをなんとかするための方法について、特に重要なポイントについてお伝えしたいと思います。
なんとかする領域
前回お伝えした PMBOK では、プロジェクトでなんとかする対象を10個の知識領域（エリア）として定義しています。 そしてこれらは以下に列挙するとおり、プロジェクトの ゴール に関するエリアと プロセス に関するエリアの二つに分類されます。
- ゴールに関する３つのエリア
- Quality / 品質（成果物の品質）
- Cost / 原価（材料費、人件費、などなど）
- Time(Delivery) / 納期、スケジュール
- プロセスに関する７つのエリア
- Scope / スコープ（なにをやるのか）
- Human Resource / 要員（どのメンバーでやるのか）
- Communication / コミュニケーション（定例会、座席、ツール）
- Risk / リスク（目標の達成を阻害しうるものと、その予防）
- Procurement / 調達（必要なヒト・モノ・カネを外部から調達）
- Stakeholders / ステークホルダー（プロジェクトに関わるすべての人）
- Integration / 統合（↑のエリアすべてを統合してみないとね）
たくさんありますが、プロジェクトを成功に導くために（プロジェクトの大小に関わらず）あらかじめ考えておく必要があることばかりです。 今回はこの中でも私が最も重要だと考える、プロジェクトのゴールに関する３つのエリアに絞って考えていきたいと思います。
プロジェクトのゴール
プロジェクトのゴールを考えるにあたって、まずは仕事での日常的なシーンを例に挙げてみたいと思います。
仕事上でのとあるシーン
ある日のこと...
- 🙋♂️「この書類、スタメンの👨💼さんに送っておいて！」
- 🙆♀️「わかりました！」
後日...
- 🙎♂️「こないだお願いした書類の件で👨💼さんに怒られちゃったよ！」
- 🙎♀️「え？わたしちゃんとその日の夕方には送りましたよ？」
- 🙎♀️「ちゃんと丁寧な送付状も添えましたし。」
- 💁♀️「それと、これ送った時のレターパックの領収書です。経費精算お願いします。」
- 🤦♂️「なんと...」
さて、🙎♀️さんはちゃんと対応したように見えますが何がいけなかったんでしょうか？
問題は認識のずれ
どうやら🙎♀️と🙎♂️との間で次のような認識のずれがあったことが問題のようです。
| 🙎♀️の対応 | 🙎♂️の期待 | |
|---|---|---|
| 送るもの | 書類の原本 | 書類のコピー |
| 送る手段 | レターパック | FAX |
| 受けとる日 | ２日後 | 当日 |
| 費用 | ¥520 | ¥0 |
この中で👨💼を怒らせてしまった理由は、その書類を 必要な日に受け取れなかった ことです。
プロジェクトのゴールに関するエリアとして Quality・Cost・Time(Delivery)の３つがあることを先程お伝えしました。 これは主に製造業において昔から重要とされているエリアで、いわゆる QCD と呼ばれるものです。
この QCD の観点でふりかえってみると、🙎♀️は Quality を最優先した対応であったと言えます。 もし書類がとても重要なもので、確実に原本を👨💼に届けなければならない状況だったとしたら、🙎♀️の対応は100点です。 しかし、実際には👨💼が最も優先していたのは Delivery であり、🙎♀️の対応ではそれが満たされなかったために、🙎♂️は👨💼に怒られることになってしまいました。
ゴールのすり合わせ
今回の問題がなぜ起きたかを一言で言うと、ゴールのすり合わせが足りなかったということです。
依頼者である🙎♂️が「今日中に欲しいらしいからFAXで送って！」と一言添えていれば問題は起きなかったでしょう。
そして依頼を受ける🙎♀️からも「いつまでに届けばよいですか？」と不明点を確認しておくことでも防げたと思います。
ここでお伝えしたいのは、依頼する側、される側のどちらかが一方的に悪いということはあまりないということです。
ソフトウェア開発プロジェクトにおける裁判
少し重い話になりますが、ソフトウェア開発プロジェクトにおいて発注元と発注先の間で裁判が行われることがあります。 訴訟に至る主な原因は、プロジェクトの遅延、完成したものの品質、費用のふくらみなど、QCD というゴールのズレが原因です。 裁判における論点は、発注元と発注先のどちらに問題があったか、となります。
ソフトウェア開発の 発注先 はソフトウェア開発のプロとみなされるため、ソフトウェア開発のプロジェクトマネジメント義務を全うしているかどうかがチェックされます。
そして 発注元 は発注するソフトウェアで解決するユーザー業務に関するプロとみなされるため、発注先への必要な情報提供や要件定義への参加など、ソフトウェア開発への協力義務を果たしているかどうかが問われます。
つまり、プロジェクトに関わる人すべてが協力しないとプロジェクトの成功は難しいということですね。
プロジェクトのゴール設定
私は プロジェクトの成功はゴール設定が最も重要である と考えています。 プロジェクト開始時に設定したゴールが誤っていると、その後のプロセスをいくらうまくやっても間違ったゴールに向かってしまうからです。
プロジェクトが始まる時、誰もがまずは理想的なゴールを想像します。
- Quality : 高い
- Cost : 安い
- Delivery : 早い
これが理想的なQCDです。しかし、このようなゴールがソフトウェア開発の中で成り立つことはまずありません（旨い、安い、早いの成り立つ牛丼は偉大です）。 なぜなら、予算が決まっている、リリース日ををプレスリリースしてしまっている、などプロジェクトには必ず QCD のどこかに制約があるからです。
プロジェクトごとにどのような制約があるかを抽出し、その中で最良バランスの QCD でゴール設定することが重要です。
ソフトウェア開発プロジェクトでのゴール設定
ソフトウェア開発プロジェクトにおける QCD を具体的にすると次のようになります。
- Quality / ソフトウェアの品質（＝バグが少ない、だけではないのでまた別の機会に）
- Cost / インフラ費用、人件費（＝工数）
- Delivery / 納期、リリース日
ソフトウェアのエンジニアであれば、これらのどれかを優先すると、別のものが犠牲になるというのは感覚としてわかると思います。 ですのでプロジェクトの制約に応じて最も優先すべきものを設定しましょう。例えばこんな感じですね。
- 医療現場で利用される投薬管理システムの開発 👉 Quality
- 運用中のシステムで発生した影響度の大きい障害の対応 👉 Delivery
- コロナで収益の減ってしまった観光施設のPRウェブサイトの改修 👉 Cost
もちろんこんなにわかりやすい状況はないので、依頼者としっかりすり合わせてゴールを設定し、ステークホルダー間で合意をとってからプロジェクトを開始しましょう（これはステークホルダーマネジメントというエリアの話に関連しますね）。
まとめ
プロジェクトマネジメントにおいて最も重要なのは QCD というゴール設定にあります。 そしてプロジェクト固有の制約の中で、そのプロジェクトの独自の目標を達成するための最良バランスの QCD を設定することが、プロジェクト成功への必要条件です、というのが今回の記事のまとめです。
今回の内容を実践するのはプロジェクトマネージャーだけではありません。 例であげた日常的な仕事のシーンのように、小さなタスクであってもゴール設定はとても重要です。
大きなプロジェクトでもそれは小さなタスクの集合です。 プロジェクトに関わるメンバー全員が、それぞれのタスクが最良のゴールとなるように意識して行動できるかどうかが、プロジェクトの進捗に大きな影響を与えることになります。 これから実施する予定のタスクについて改めてゴールのすり合わせをしてから着手してみてください。 それがプロジェクトマネジメントの最も効果的な入門となるはずです。
最後になりますが、スタメンでは自社プロダクトの開発プロジェクトを一緒になんとかしてくれる仲間を募集しています。興味を持ってくれた方は、ぜひ下記の採用サイトをご覧ください。
