実装は終わった。それでも「誰が決めるのか」が分からず、仕事が止まった
実装は終わった。なのに、レビュー依頼の「送信」に指を置いたまま動けない。
金曜18時12分。地域の美術館で使う予約サイトの改修は、テストまで終わっていた。翌週に始まる企画展へ向けて、時間指定券を追加する仕事だ。
コードは動く。残っているのは、満席時に出す文言、公開する日時、問い合わせが来た時の案内だった。チケットには「来週公開」としか書かれていない。学芸担当は文言を運営へ聞いてほしいと言い、運営は公開日を責任者へ確認すると言う。責任者は別の打ち合わせ中で、チャットにもいない。
業務委託で実装を担当するエンジニアは、「最終的には誰が決めますか」と打ちかけた。でも、消した。
そこまで聞くのはPMの仕事かもしれない。外から入っている自分が仕切ったら、面倒な人に見えないだろうか。
早く帰りたい気持ちもあった。結局、「実装とテストは完了しました。ご確認をお願いします」とだけ送った。これなら角は立たない。少なくとも、その瞬間はそう思えた。
月曜の朝、コメントは三方向から返ってきた。文言は学芸担当の案へ戻す。公開日は一日早めたい。問い合わせ先はまだ決まっていない。修正そのものは小さいのに、誰の返事を待つかが分からず、作業は水曜まで止まった。
「金曜に気づいていたのに、なぜ聞かなかったんだろう」。画面を見ながら、自分ばかり責めた。実装に集中したかっただけなのに、黙ったことで余計に仕事を増やした気がした😓
ここで必要だったのは、いきなりPMになることではない。会議を増やすことでも、全員の予定を自分で集めることでもない。実装の途中で見えた未決事項を分け、決められる人へ返すことだった。
実装だけに戻りたいのに、曖昧さだけが手元へ残る
実装者は、仕様の穴に早く気づきやすい。エラー文言がない。公開時刻が決まっていない。運用担当が分からない。コードへ落とそうとした瞬間、曖昧な部分だけが急に具体的になるからだ。
ところが、気づいた後がしんどい。「見つけたなら、自分で答えも用意すべきでは」と考えてしまう。文言案まで作り、関係者へ連絡し、公開日も調整しないと質問してはいけない気がする。そこまで持てないなら、黙っていた方がいい。頭の中で二択になりやすい。
でも、その二択は少し乱暴だ。
Scrum Guideの現行公式版は、開発者の責任として、作業計画を作ること、完了の定義に沿って品質を保つこと、目標へ向けて日々計画を調整することを挙げている。一方で、プロダクトの価値を最大化し、バックログを管理する責任はProduct Ownerに置いている。
すべての現場がScrumではない。それでも、作る人が計画や品質に関わることと、価値や優先順位の最終判断まで一人で背負うことは別だ、と考える手がかりにはなる。
気づいた人が全部を決める必要はない。気づいたことを、決められる人へ渡せばいい。
最初の失敗は、答えまで持とうとしたことだった
美術館の案件で手が止まったのは、未決事項が多かったからだけではない。「質問するなら、正しい案まで出さなければ」と思ったからだ。
満席時の文言は、購入できない理由をどこまで説明するかで迷った。公開日は、アクセス集中の可能性まで考えると自分では決められない。問い合わせ先も、学芸担当と受付のどちらが持つか分からない。三つとも答えを作ろうとしたら、当然まとまらない。
ここで出せたのは、答えではなく次の三つだった。
- 文言: 満席時に利用者へ何を伝えるか
- 公開日時: いつから予約を受け付けるか
- 問い合わせ対応: 予約できない人を誰が案内するか
「まだいろいろ未確定です」では、相手も動きにくい。三つに分ければ、少なくとも誰へ聞くかを考えられる。未決事項を分けるだけでも、実装者が抱えていた重さをチームへ戻せる。
「分からない」を、技術への影響まで添えて出す
ただ「決めてください」と投げると、相手には急かされているように見えることがある。実装者が一歩だけ足せるのは、決まらないと何が止まるかだ。
たとえば、こう書く。
満席時の文言が未確定のため、画面確認を完了できない状態です。公開日時はリリース予約、問い合わせ先は案内リンクの設定に影響します。
これなら、相手を責めていない。実装上の事実を伝えている。決定の中身は持たず、決まらない時の影響だけを出す。作る人だから書ける一文だ。
以前、似た案件で「まだ決まっていません」だけを連投し、結局どれから決めるべきか伝わらなかったことがある。細かく報告したつもりでも、受け取る側には未処理の通知が増えただけだった。以来、未決事項と技術への影響を一組にして出すようにしている。
「で、誰が決めますか」が怖かった
未決事項を分けても、決定者を聞くところでまた指が止まる。
特に業務委託や外部メンバーは、「契約範囲を越えていると思われないか」「現場の体制へ口を出す人に見えないか」が気になる。質問した結果、「そこまで見てもらえるなら、調整もお願いします」と仕事が増える怖さもある。
だから、普段やり取りしている担当者へ全部返してしまう。担当者も決められず、「確認します」が増える。確認先が一つ増えるたびに、自分の作業予定だけが後ろへずれる。急かしたくないから黙り、待っている間も落ち着かない。かなり消耗する。
相談相手と、決める人を分けて聞く
聞き方は、大げさにしなくていい。
三点の相談窓口は運営担当で合っていますか。最終判断は、文言、公開日時、問い合わせ対応でそれぞれ誰にお願いすればよいでしょうか。
ここで聞いているのは、組織図ではない。今回の三点を誰が決められるかだけだ。担当者名がすぐ出なければ、「公開日時だけ先に責任者へ確認する」のように順番を決められる。
2026年4月に公開されたIPAのデジタルスキル標準ver.2.0は、ソフトウェアエンジニアとビジネスアーキテクトを別の類型に置き、後者の中でプロダクトマネージャーを定義している。現場の肩書きをそのまま当てはめる必要はないが、実装、価値判断、事業側の調整が同じ仕事ではないことは確認できる。
境界を知るために役割名を使うのであって、壁を作るためではない。実装者が未決事項を見つけても、最終判断まで自分の責任になるわけではない。 そう考えると、決める人を尋ねる怖さが少し小さくなる🧭
少し前へ出るほど、持たない範囲も書く
次の企画展でも、同じような未決事項が出た。今度は、エンジニアが三点を分けてチャットへ出した。すると、運営担当からこう返ってきた。
助かります。このまま関係者の取りまとめもお願いできますか？
うれしさより先に、胃が少し重くなった。質問したせいで、また仕事が増える。ここで断ったら協力的ではないと思われるかもしれない。反射的に「承知しました」と打ちかけた。
でも、一度止まった。今回できることと、決定を持つ人しかできないことを分けて返した。
未決事項の一覧と、実装へ影響する点はこちらで整理します。文言と公開日時の最終判断、関係部署の日程調整は館側で担当を決めていただけると進めやすいです。
冷たい断り方ではない。自分が持てる作業を先に示し、持てない理由を仕事の流れで説明している。相手も「では、公開日時は責任者、案内文は学芸担当」と割り振りやすくなった。
もしここを曖昧にすると、今回だけの手助けが次回から標準の担当になる。会議招集、催促、関係者への説明まで増えても、「自分から始めたことだから」と言い出しにくくなる。役割を広げたい気持ちがある人ほど、この流れに入りやすい。
一歩前へ出すのは論点であって、すべての責任ではない。 この線を文章に残しておくと、協力と抱え込みを分けやすい。
完了条件も、誰が何を終えたらよいかで書く
「実装完了」という言葉も、立場によって意味が違う。コードがマージされたら終わりなのか、テスト環境で館側が確認したら終わりなのか、本番公開まで含むのか。ここを合わせないと、こちらは終えたつもりでも、相手には途中に見える。
美術館の案件では、次のように置いた。
今回は、館側が文言と公開日時を確定し、こちらがテスト環境へ反映し、運営担当が表示を確認した時点を実装完了とします。本番公開は責任者の承認後に行います。
これで、誰の作業待ちかが見える。実装者だけが「まだ終わっていない」と抱え続けなくていい。完了条件は、自分を守る線でもあり、相手が安心して確認する順番でもある。
金曜18時12分に戻るなら、送るのは四行でいい
役割を広げるというと、資格や肩書きから考えたくなる。でも、最初の一歩はもっと小さい。金曜のレビュー依頼へ、次の四行を足すだけでもいい。
実装とテストは完了しています。残っている判断は、文言、公開日時、問い合わせ対応の三点です。
文言は画面確認、公開日時はリリース予約、問い合わせ先は案内リンクに影響します。
それぞれの最終判断を、誰にお願いすればよいか確認したいです。
実装完了を「テスト環境で運営担当が確認するまで」としてよいかも、あわせてお願いします。
次の企画展では、この四行を出した日のうちに担当が決まった。月曜に文言が確定し、火曜にテスト環境を確認、水曜の予定どおり公開できた。劇的な成功ではない。会議を仕切ったわけでもない。ただ、誰の返事を待っているのか分からない時間が減った。
そして週報には、「関係者へ確認した」ではなく、こう残した。
- 三つの未決事項と実装への影響を整理した
- 最終判断者を分け、確認待ちの往復を減らした
- 実装完了と本番公開の条件を分けた
PMIの2025年版Pulse of the Professionは、事業や価値への理解が、プロジェクト人材を目の前の問題へ対処する役割から、価値を生む役割へ進めると整理している。実装者がいきなり経営の判断を持つ、という話ではない。自分の作業が誰の判断を待ち、利用者や公開予定へどう影響するかを説明できることから始まる。
こうして残せば、「少し整理しただけ」で消えない。更新面談や役割相談でも、コード以外に何を前へ進めたかを話せる。役割をさらに広げたい時は、会議が終わるたび、決まらなかったことだけが自分に戻ってきたや、会議も調整も増えた。それでも「実装担当ですよね」と言われたもつながる。
今すぐPMを名乗らなくていい。全部の調整を引き受けなくてもいい。今日の実装で見えた未決事項を一つ分けて、技術への影響を一行添え、決める人へ返す。役割は、肩書きを先に変えるより、仕事が止まる場所を一つ減らした記録から広がっていく。
金曜の自分を責め続ける代わりに、次のレビュー依頼へ四行を足す。まずはそこからで十分だ✍️
