最初にやらかした話から始めます。
入社して2年目、はじめてPMO補助として顧客の定例打ち合わせに同席させてもらった頃のことです。開発が中盤に差し掛かった、いつもの週次MTGでした。
画面共有でモックを見せていたところ、クライアント側の担当者が「あ、そういえばなんですけど」と前置きして言ったんです。
「この機能、AじゃなくてBの形にしてもらえませんか。前回どっちって決めましたっけ？」
恥ずかしながら、頭が真っ白になりました。Aで合意してから2週間、コードもテストも全部A前提で書いてきたのに、と思いながら。
「その場で答えない」という選択
あの時に「その場で答えなかった」のは、正直に言うと「答えられなかった」という方が正確でした。仕様書をさっと開いて影響範囲をその場で言えるほど、まだ頭の中が整理されていなかったんです。
ただ、その後先輩に「その場で詰めなくて正解だった」と言われて、理由を聞いて少し救われた気がしました。先輩いわく「要件が変わる瞬間って、クライアント側でも整理がついてないことが多い。その場で合意してしまうと、2時間後に『やっぱりこっちの意味で言ってました』ってなりやすい」と。
クライアントの「Bで」という一言にも、背景があるんですよね。コンペで競合に何か言われたのか、社内で上から指摘が入ったのか、最初からBのつもりが伝わり損ねていたのか。その場ではまず「確認して折り返します」と言って、一度持ち帰ることにしました。
持ち帰ってから最初に書いた3項目
会社に戻って最初にやったのは、こんなメモを作ることです。
## 要件変更メモ（2026-MM-DD 打ち合わせ後）
### 1. 現在の要件（合意済み）
- 〇〇機能はAパターンで実装する
- 対象画面: ××ページ、△△ページ
### 2. 新要件（変更依頼内容）
- 〇〇機能をBパターンに変更
- 変更の根拠: 打ち合わせ中は不明（要確認）
### 3. 差分の影響
- バックエンド: 〇〇APIのレスポンス形式変更（工数+X時間）
- フロントエンド: 〇〇コンポーネントの設計変更（工数+Y時間）
- テスト: 既存テスト△件の書き直し
- スケジュール: 完了予定から約Z日後ろ倒し「差分の影響」を書き出すのが思ったより時間がかかりました。「ここを変えると、あそこも変わって、そっちが変わると…」という連鎖が見えてくる作業で、この時間を省いて先方に連絡していたら、見落としが出ていたと思います。
今思えば、頭が真っ白になったからこそ「持ち帰る」という選択ができたとも言えます。その場の空気に流されて「分かりました」と即答していたら、後からもっと大変なことになっていたはずです。
議事録に「なぜ変わったか」を残すことにした
要件変更メモを書きながら気づいたことがあって、それは「変更の理由」が空白のままだということでした。
その後のクライアントとの確認MTGで聞いてみたら、「競合他社のサービスを触ってみたらBパターンの方が直感的だった」という理由が出てきました。なるほど、それなら他にも影響を受けそうな画面がある、と次の論点まで引き出せたわけです。
それ以来、議事録には「何が変わったか」だけでなく「なぜ変わったか」を必ず残すルールを自分の中で作りました。
| 項目 | 変更前 | 変更後 | 変更理由 |
|---|---|---|---|
| 〇〇機能の形式 | Aパターン | Bパターン | 競合サービス調査の結果、Bの方がUXが優れていると判断 |
| △△画面のフロー | ステップ3 | ステップ2 | 上記理由から、同様の画面も見直し対象に |
ただ正直なところ、この表形式だと変更理由が複数絡み合うケース（「コスト削減のため」かつ「期限の前倒しのため」みたいな状況）では整理しきれないことがあります。改善の余地がある部分で、複雑な変更の場合は「背景」という自由記述欄を別途設けた方がいいかもしれません。
## 要件変更サマリ（2026-MM-DD）
### 変更内容
- 〇〇機能: AパターンからBパターンへ変更
### 変更理由
競合他社の△△サービス調査の結果、Bパターンの方がユーザー操作の直感性に優れているとクライアント判断。
（社内でのUXレビューが2026-MM-DD に実施済み。議事録PDF添付）
### 影響範囲
...要件変更を「前提」にしたスケジュール組み直し
この経験の後、スケジュールの立て方を少し変えました。
以前は「要件が固まった前提」でWBSを引いていたので、変更が入ると全体を作り直すことになっていました。先輩に教わってから実践しているのは、最初からバッファを「要件変更対応枠」として明示することです。
# スケジュール案
Week 1-2: 設計・コア機能実装
Week 3: 追加機能実装
Week 3後半: ★要件変更対応バッファ（0.5〜1日）
Week 4: テスト・QA・受入「バッファ」と書いてしまうと「使わなかった分どこ行ったの？」という話になりがちなので、「要件変更対応枠」と名前をつけると、クライアントにも「変更が0件なら前倒しで終わります」と説明しやすいです。これ、言葉を変えるだけで会話の質が変わるんですよね。
振り返って
あの打ち合わせで頭が真っ白になったのは恥ずかしかったし、今でも覚えています。でも今思えば、あそこで無理に答えなかったことは結果的にはよかった。
要件変更そのものは悪じゃない、と最近ようやく思えるようになってきました。「変わること」を前提に設計するのがPMO補助の仕事の一部だということを、この経験で学びました。
今後は「なぜ変わったか」の深掘りをもっと早く引き出せるようになりたいです。一回の変更で「次に変わりそうな要素」まで先読みして提案できたら、クライアントの信頼も変わってくる気がしています。
まだまだですが、もう少し先輩の動きを観察して盗んでいきたいと思っています。