本記事の概要
プロダクトのリリース直前、ステークホルダー（役員や営業部門など）から「この機能も初期リリースに追加してほしい」と急な要望が入る局面は、よく聞くところです。私も例に漏れず当初の要求仕様で開発を進めてきたにもかかわらず経験があります。
よほど重要であるか、大きく見落としておりシステムの根幹を揺るがす機能でない限り無理をして入れ込むことはしたくありません。
安易に引き受けてしまえば、設計思想は崩壊し、開発チームは疲弊して納期遅延ひいては重大な不具合を引き起こします。一方で、単に「無理です」と突っぱねるだけでは組織的な信頼を失ってしまいます。
今回は、プロダクトの軸をブレさせずに、ステークホルダーと建設的なトレードオフの合意を形成するために私が実践してきたことを下記項目に分けて記載しています。
- 原則NG
- 代替案の提示
- どうしても！の時
「HWとSWが密結合するIoTシステム」の開発に基づいています。
このシステムは、センサーが取得した生データ（物理量）をバックエンド等で高度に加工・分析し、ユーザーに意味のあるデータとしてWebUI（Next.js）上の時系列グラフに可視化・制御する構造を持っています。
1人目のSWエンジニア兼PMとして、この不確実性の高い開発をコントロールした知恵を共有しています。
原則：設計思想とバッティングする急な要件は初期に入れない
まず基本的には「急に上がってきた要望は、これまでの設計思想やアーキテクチャと相反するリスクが高い」という考えから急な要件追追加はNGとしていました。
不確定要素を直前で混ぜ込むことは、システム全体の品質低下に直結します。そのため、基本スタンスとしては「初期リリースへの追加は見送る」を第一選択肢とします。
また、そのような要望を引き受けてしまうと「次もできる」と思われてしまいますし、チームメンバーからは信頼感が薄れます。そのような状態では健全なプロジェクト運営は難しくなり、リリース後の保守や、他プロジェクトで同じメンバーとチームとなった場合に良い関係を保てなくなってしまいます。
代替案の提示：初期リリース直後の「緊急アップデート対応」
とは言え、単に断るのではそれもまたPMとしての職務に反しますので、ビジネス側の要望に寄り添う代替スケジュールを提示します。
「初期リリースは予定通りのスコープで確実に完了させる。ただし、リリース準備と並行して希望機能の開発を進め、リリース後すぐに緊急アップデート扱いで追加実装・提供を目指す」というステップを提案します。これにより、本番運用の安定性を担保しつつ、ビジネス側のスピード感にも応えることができます。
リリース直後は一般的に不具合が出やすい時期として捉えられています。多くのプロジェクトがリリース直後はまだ開発メンバーを残し不測の事態に備えた体制をとっているのではないでしょうか。
その体制が維持されている期間がチャンスだと思ってそこでやりきるスケジュールを考案します。
最悪のケースへの備え：一部機能見振りと「疎結合実装」
どうしても初期リリースに組み込むことがビジネス上譲れない場合の最終手段として、明確な「トレードオフ」を理解してもらい対応を行います。
要件を追加する代わりに、アジャイル開発であれば既存機能の中から優先度の低い「一部機能のリリース見送り」を合意形成します。
ウォーターフォールであれば設計した機能をすべて実装し終え総合試験などを行っているタイミングかもしれません、そうであれば試験の簡略化で対応工数を捻出するように働きかけます。
さらに、開発側のリスクを最小化するため、「既存システムへの影響が最も少ない疎結合な機能」として設計・実装することを条件とします。
このような提示は、ステークホルダーに正しくリスクを理解してもらい、自分ひいてはチームメンバーを守ることにつながります。
そのような思惑が通用しない場合もありますが…
振り返り
成果
PMの役割は、すべての要望をそのまま受け入れる「便利屋」になることではありません。
システムの設計思想と開発チームの体力を守りつつ、ビジネス側の目的を別のアプローチ（緊急リリースやトレードオフ）で達成すること。対立ではなく「同じゴールを目指すパートナー」として合意をつくる交渉力こそが、プロジェクトの推進力になります。
ただ、どんなに説明しても理解が得られない場合があり飲み込まなければいけない場面もあります。私がチームメンバーとして参画していたプロジェクトでかなり強い顧客がいて毎回PMがボロボロになって買ってくることがありました。
その時はPMがしっかり顧客を納得させようとする姿勢と努力を見せていたので私は不信感を持つようなことはありませんでしたが、他の方はどうだったかわかりません。
そのようなPMのもとで働けていたため私もそうありたいと今頑張れているのかもしれません。
振り返り
- 頭でっかちな回答にならない程度に成果物の正当性と機能追加のリスクを伝える
- 相手の話と目的をよく理解して利益を損なわない判断を行う
- 機能追加は実装担当者と慎重に行いリスクの対応も視野に入れる