超基本だけど超重要！QCD調整で乗り切るプロジェクト管理

はじめに

株式会社アイスリーデザインでPM（プロジェクトマネージャー）を務めているSoLです。

前回「英語会議が苦手な人にまず試してほしい、グローバル開発チームにおけるコミュニケーション術」という記事で海外メンバーとのコミュニケーションについて紹介しました。

改めて軽く自己紹介します。これまでアイスリーデザインでは自社製品であるflamingo（※詳細はこちらを参照）の導入プロジェクト、アプリやWeb開発の継続開発案件など、様々な案件でPMロールを務めてきました。

今回は、私が過去にプロジェクトで直面した問題をベースに、PMとして注意したほうが良いと思うことを記載していきたいと思います。休憩時間に、気軽に読んでもらえると嬉しいです。

管理する範囲が広いPMという仕事

学生時代など、この業界に入る前からPMを志していた方はどれだけいるのでしょうか。それにはあなたがPMの業務内容を当時から理解していたことが前提になると思います。

PMはプロジェクトの進捗・コスト・品質、そして顧客の温度感やメンバーのモチベーション管理などすべてウォッチすることを求められる職種です。また、プロジェクト進行にあたっての検討材料はデザイナーやエンジニアなどプロジェクトメンバーから提供してもらいますが、最終的な判断を担うのはやはりPMです。PMはプロジェクトの「顔」を務めることになるため、問題発生時にプロジェクトやクライアントに対して全責任を持つことにもなります。

このように、PMの業務内容と責任はかなり広範囲に及ぶため、この業界に入るまではなかなかイメージがつきにくいと思います。

顧客折衝の難しさ：PMが直面する典型的な問題

　PM業務の中でも、私が一番難しいと思っているのは顧客折衝です。例えばPMとしてプロジェクトを進めている中で、こんな問題に出くわしたことはないでしょうか。

1. 開発フェーズ後半になって、予算はこれ以上出せないが、当初の納期までに追加仕様を実装してほしいと顧客から依頼された
2. ベンダーはレベルAの成果物を作る想定でプロジェクトを進めていたのに、実は顧客が期待していたレベルはA+の成果物（こちらの想定より搭載機能などが多い成果物）だったことが開発中盤で判明した

恐らく私に限らず、これらはPMを務めている多くの人が経験する、ありがちな問題かと思います。上記のような要望を出されたとき、相手の立場や意見を尊重したうえで、大切なお客様相手にどのように「できること/できないこと」「受け入れること/お断りすること」を伝えるか、PMはものすごく熟慮すると思います。

1．のケースも2．のケースもそれぞれ考えられる対応策が異なるため、今回は1. のケースについて記していこうと思います。

QCDの原則：プロジェクト調整の基本フレームワーク

システム開発において、QCDはプロジェクトを成功に導くための基本的な指標です。QCDとは「Quality（品質）」「Cost（コスト）」「Delivery（納期）」の頭文字を取ったもので、これらはプロジェクトを支える三本柱です。どれか1つを重視すれば、他の2つに影響が出ることが多く、プロジェクトの進行には慎重な調整が求められます。

たとえば、品質を高めようとすれば、テスト工程やレビューに時間とコストがかかります。一方で、納期を最優先にすると、検証不足や機能の削減といった品質面でのリスクが生じるかもしれません。コストを抑える場合も、スキルの高い人材や十分なリソースの確保が難しくなり、結果的に品質や納期に響く可能性があります。

このようにQCDの3要素は、互いに補完しながらも時に対立する関係にあります。だからこそ、プロジェクトの目的や優先順位を明確にし、関係者間で認識を揃えることが、現場での判断や調整をスムーズに進めるために不可欠だと言えます。

【予防策】WBSによる要件定義と対応期限の明確化

プロジェクトにおける対象スコープと対応内容は、基本的に要件定義フェーズで確定するものとなります。WaterFallモデル（以下、WFモデル）におけるプロジェクトの流れは以下の通りですが、要件定義フェーズで確定した要件をベースに設計、実装フェーズへと流し込んでいく形になります。すると当然、すでに設計・実装着手してしまってから要件変更が発生した場合は手戻りが発生します。

手戻りが発生しないよう、PMは要件を確定する期限を明確化し、それを顧客にも理解して頂きます。そのためにはプロジェクト始動時にWBSや全体スケジュールなど、要件定義までの必要タスクと期限が明記されたドキュメントの提示が必須となります。

重要なのは、タスクが分かった段階で最初に期限を顧客に伝えておくことです。もちろん、要件定義を進める中で期限までに確定できない要件が出てくるなど、予定通りに完了しないケースもあるでしょうが、その場合にはスコープや機能ごとに期限を設定し直すなど、追加の細かい調整と管理を徹底しなければなりません。そしてこれも、想定通りに進められないことが明らかになった段階で、すぐに期限を切ることが重要になります。

※要件追加や仕様変更に比較的強いとされるアジャイル開発の場合でも、スプリント内で同様のケースが発生する可能性はあると思います。ただし、溢れたスコープを次のスプリントに回す選択肢があることが、WFモデルと異なる点になります。

【対応策】QCD原則を活用した顧客折衝

とはいえ、要件定義の期限後に、顧客から仕様変更をどうしてもと懇願されるケースも少なくないでしょう。基本的には、先述のように予め期限を切っている場合ベンダーが要望をお断りする権利自体はあると思います。しかしながら、その顧客が今後もお付き合いを継続したい大切なパートナーであるなど、無碍に頼みを断りたくない場合もあるでしょう。

このような状況に陥ったときに思い出してほしいのが、先程触れたQCDの原則です。「Quality（品質）」「Cost（コスト）」「Delivery（納期）」の3要素は常に依存関係にあり、何か一つを優先させる場合には、他の何かの優先度を下げる必要があります。

例えば、当初の想定にない追加機能を実装しQを優先する場合は、相応のC（追加費用）の調整とD（開発期間）の延長を許容頂く必要があります。反対に、追加費用を出せないのでC（≒予算）を優先する場合は、Q（追加機能の実装）を諦める必要があります。追加要件の対応方針について顧客と協議する際は、このQCDの原則を念頭に交渉するべきと考えています。

条件設計が顧客との関係維持のカギ

顧客心理としては、なるべく低予算で時間をかけず想定通り（もしくは想定以上）のアウトプットをベンダーに期待するのは当然のことです。しかしながら、現実はそうはいきません。ベンダーは、QCDのすべてを優先させるのは不可能であることを顧客にご理解いただき、何らかの条件付きで追加機能の実装を受け入れるのが望ましいかと思います（多くの場合は期間延長や追加費用が条件になると思います）。

十分な予算や期間をもらえずに、ただベンダーが身を削って顧客の要望に応えるというのは、ビジネス上の対等な関係性を壊してしまい、上下関係を生み出すことになります。

また、できないことをできると約束したり、上手くいく保証もないのに「頑張ります」と無条件に顧客の要望を全て飲み、結果的に「無理でした」とベンダーが泣き寝入りするのも無責任な行為です。「何事もタダではやらない」「できる保証がないことは約束しない」という前提を忘れずに妥当な交渉をすることが、顧客に対し責任を持つことにも、ベンダーが身を守ることにも繋がります。

何かを得るには、それなりの代償が必要というのが大原則になります。もちろん、顧客が最初からQCDの原則について十分理解されているケースも多いとは思いますが、いざプロジェクトの渦中にいると会社としての思いを優先してしまい、ついつい無理を押し切ろうする欲が出てしまうものです。しかし、それを冷静に正すことがベンダーの役割だと考えています。

最後に

色々書きましたが、PMの果たす責務というのは「言うは易し」で、いざこれらのことを抜かりなく実行するとその難しさに気づくはずです。多くのPMは並行して複数プロジェクトを見ているでしょうし、そんな中でプロジェクトの状況変化を敏感に察知して事前に対策を打つのは本当に毎日気が抜けません。

交渉にしても、理屈的にやるべきことは分かっていても問題はそれをどのように伝えるかですし、これは各PMのキャラによってもやり方は変わってくると思います。相手の空気も読まなければいけません。こればかりは教科書なんて存在しないので、各自が実践の中で自分に合った伝え方やコミュニケーション方法を探っていくしかないでしょう。最初はたくさん失敗もすると思いますが、死ぬわけではないので色々挑戦してみてください（会社に甚大な損害をもたらさない範囲で笑）。

また、プロジェクト中、PMは孤独感を抱えがちですが、全部一人でなんとかしなければと思い込んでしまうのも禁物です。困ったときは、しっかり自分の考えを持ったうえで上司や周りに相談しましょう。一生懸命考えて助けを求めれば、誰かは助けてくれます。全部投げ出したくなっても、最後まで逃げないことが重要です。

この記事が参考になりましたら嬉しいです。お読みいただきありがとうございました。