会議が終わるたび、決まらなかったことだけが自分に戻ってきた
「いったん持ち帰りましょう」で終わったけど、明日、自分は何を作ればいいんだろう。
水曜14時、地域の植物園が使う会員アプリの定例会が終わろうとしていた。議題は、来園者へ配るクーポンの期限変更だった。
営業は「発行から7日間」と言い、運営担当は「7日目の閉園まで」と話す。さらに、期限前日の通知を何時に送るか、すでに発行済みのクーポンをどうするかも同じ会話へ入ってきた。画面共有されたチケットには「有効期限を7日へ変更」としか書かれていない。
業務委託で実装を担当するエンジニアは、発言ボタンへ指を置いた。発行時刻から168時間なのか、7日目の23時59分なのか。それだけでも実装は変わる。でも、会議の進行はPMの仕事に見えた。外から参加している自分が話を戻したら、細かい人、仕切りたがる人と思われるかもしれない。
結局、マイクを入れないまま会議は終わった。
翌朝、チケットには「金曜までに対応をお願いします」とだけ追記されていた。営業へ聞くと「利用者には丸7日使ってほしい」、運営担当へ聞くと「閉園時刻で切れる方が現場は分かりやすい」と返ってくる。どちらも間違いではない。だからこそ、エンジニアだけでは決められなかった。
締切は近いのに、コードを書き始められない。昨日、気づいていたのに黙った自分にも腹が立つ。いまさら聞けば「会議で言ってくれればよかったのに」と思われそうで、チャットの文面を何度も消した😓
これは、会議を回す技術が足りない話ではない。曖昧さに気づいた人と、決める権限を持つ人が別なのに、その間をつなぐ一言が置かれなかった話だ。
この記事では、いくつかの現場で起きやすい流れを一つの場面にまとめている。PMの代わりになる必要はない。実装者の立場から、決まっていないことを一つだけ見えるようにし、決める人へ返し、次の作業を残す方法を考える。
見えていたのに、口を挟めなかった
会議が止まりそうだと分かっていても、手を挙げられないことがある。話す内容がないからではない。自分の担当を越えたように見えるのが怖いからだ。
「誰かが決めるはず」で、全員が待ってしまう
営業は利用者の体験を見ている。運営担当は閉園後の問い合わせを心配している。PMは期限と関係者を見ている。エンジニアは、どの条件ならコードにできるかを見ている。
見ているものが違うと、同じ「7日間」でも意味がずれる。ただ、会議では全員が少しずつ相手の領域に遠慮する。「最後はPMがまとめるだろう」「運営が決める話だろう」「実装側から条件が出るだろう」。その結果、誰も反対していないのに、誰も決めていない状態が残る。
IPAが2026年4月に公開したデジタルスキル標準ver.2.0では、製品やサービスを前へ進める役割を一つの肩書きへ寄せず、ビジネスアーキテクト、ビジネスアナリスト、プロダクトマネージャーなどに分け直している。また、異なる関係者の連携や共創を促す「デザインマネジメント実践」も追加された。
これは、エンジニアもPM業務を引き受けるべきだ、という意味ではない。立場が違う人の情報をつなぐ動きは、誰か一人の性格や善意だけに任せるものではないと考える材料になる。
黙ると、曖昧さは実装者の手元で重くなる
会議中は、黙っていた方が波風を立てずに済むように感じる。でも、決まらなかった仕様は消えない。チケット、テストケース、問い合わせ対応のどこかで、もう一度こちらへ戻ってくる。
植物園の案件では、期限の数え方を決めないまま実装すれば、開園中に突然使えなくなるクーポンが出るかもしれない。通知時刻まで同時に決めようとすると、関係者が増えてさらに止まる。エンジニアは、全部を理解してから発言しようとしていた。その重さが、最初の一言を遠ざけていた。
必要なのは、完成した答えではない。「この一つが決まらないと、今日は実装を始められない」と伝えることだ。仕様の曖昧さを分ける方法は、仕様が曖昧なままでも前に進める人は、何を切り分けている？でも詳しく扱っている。
会議を仕切らなくても、一つだけ止められる
翌日の午後、エンジニアはPMへ短い再確認の時間をお願いした。会議全体を進行する準備はしなかった。画面へ出したのは、三行だけだった📝
今日決めたいこと: クーポンの期限を、発行時刻から168時間にするか、7日目の閉園時刻にするか
決める人: 植物園の運営責任者
決定後: エンジニアが金曜12時までに仕様とテスト条件を更新する
まず、「今日決めること」を一つにする
エンジニアは、最初にこう聞いた。
実装を始めるために、今日は期限の数え方だけ決める場でいいですか。通知時刻と発行済み分の扱いは、別の確認に分けたいです。
これなら「私が会議を仕切ります」と宣言しなくていい。自分の作業を始めるために、混ざっている話を分けているだけだ。PMも「今日は期限だけにしましょう」と返し、営業と運営担当の話が同じ問いへ向いた。
Scrum Guideは、Scrumの各イベントを、成果物を検査し、必要なら調整する正式な機会としている。また、そのためには状態が見える「透明性」が必要だと説明する。すべての会議をScrumへ当てはめる必要はないが、話した量より、何を見て、何を変える場なのかが見えているかを確かめる視点は使える。
意見を出す人と、最後に決める人を分ける
次に、エンジニアは「どちらが正しいですか」と全員へ投げなかった。
営業と運営の意見を聞いたうえで、最終的にはどなたのOKで実装へ進めますか。
AtlassianのDACIは、判断を進める人、最終承認者、意見を出す人、結果を知る人を分ける考え方だ。小さな会議で四つの役割名を導入しなくても、「意見を出す人」と「最後にOKを出す人」が同じとは限らない、と分かれば十分だ。
植物園では、営業が利用者への影響を伝え、運営責任者が「7日目の閉園時刻まで」と決めた。エンジニアはその判断材料を出したが、運営方針まで背負ってはいない。整理することと、決定することを分けると、前に出ても責任を抱え込みにくい。
担当者と期限まで残して、やっと次へ進める
決まった直後は、全員が同じ理解を持ったように感じる。けれど、翌日には言葉が少しずつ変わる。「7日後」「一週間」「次の閉園まで」が別々に使われると、また元へ戻ってしまう。
エンジニアは、チケットの先頭へ「発行日を1日目とし、7日目の閉園時刻まで有効」と追記し、運営責任者の確認日と、未決の通知時刻を誰がいつまでに確認するかを残した。会議録を完璧に書く必要はない。決定、理由、次の担当、期限が読めれば、翌朝の自分が迷わずに済む。
一度動いた人に、全部が集まる
再確認のあと、実装は進んだ。営業からも運営担当からも「整理してくれて助かりました」と言われた。少しうれしかったし、昨日までの気まずさもほどけた🙂
ところが、次の定例会の招待には「今後の進行もお願いします」と書かれていた。ここで、別の重さが出る。一度できたのだから断りにくい。役割を広げる機会かもしれない。期待に応えなければ、協力的ではないと思われるかもしれない。
小さく助けたことを、無期限の担当にしない
進行整理ができる人には、会議の設定、議事録、関係者への催促、優先順位の判断まで集まりやすい。どれも必要な仕事だ。ただし、実装の合間に善意で持ち続ければ、コードを書く時間だけが削られる。
エンジニアは、招待へこう返した。
実装に関わる論点の整理と、決定事項の記録までは対応できます。会議全体の進行と優先順位の最終判断は、PMにお願いしたいです。毎週の担当にする場合は、今の業務範囲と時間配分を一度合わせたいです。
目の前の協力を断ってはいない。一方で、どこからがPMや発注側の判断なのか、継続するなら何を見直したいのかを同時に伝えている。
役割が広がったのに評価へ残らないつらさは、会議も調整も増えた。それでも「実装担当ですよね」と言われたでも扱っている。会議を一度前へ出したことと、今後も進行担当を引き受けることは別の合意だ。
価値は「会議を回した」ではなく、動いた判断で残す
週報へ「会議をファシリテーションした」とだけ書くと、何が変わったのか伝わりにくい。エンジニアは、結果を次のように残した。
- 期限と通知の論点を分け、期限の数え方を運営責任者が決められる状態にした
- 決定をチケットへ反映し、実装とテストを金曜から開始した
- 未決の通知時刻は、営業が金曜15時までに確認することを残した
大げさに「プロジェクトを成功させた」と言う必要はない。誰のどの判断が止まり、自分が何を見えるようにし、そのあと誰の手が動いたか。そこまで書けば、気遣いではなく役割として話せる。
会議は、終わった後に手が動いて初めて終わる
Atlassianが2024年5月31日に公開した記事では、5,000人の知識労働者を対象にした調査で、54%が会議後に次の作業や担当者を明確に分からないことが多いと回答したと報告している。同社内104人を対象にした別の実験では、目的、背景、決めたいことを書いたページを使う会議は、通常の会議より目標を達成した割合が高かったという。
これは一社の調査と社内実験なので、すべての職場へ同じ数字が当てはまるわけではない。それでも、会議前に目的を書き、会議後に決定と理由を更新する考え方は、翌日の迷いを減らす実務として試しやすい。
植物園の案件では、金曜の朝、エンジニアはチケットを開いてすぐテストケースを書けた。通知時刻はまだ決まっていなかったが、それは別の担当と期限が付いた課題になっていた。全部が解決したわけではない。でも、全部を自分の頭に置かなくてよくなった。
会議中に曖昧さへ気づいても、毎回きれいに発言できるとは限らない。外部メンバーなら、なおさら一歩目は重い。そんな時は、会議を回そうとせず、次の一文だけでいい。
実装を始めるために、今日決めたいことを一つだけ確認してもいいですか。
声に出せなければ、会議チャットやチケットへ置いてもいい。危なさを指摘すること自体が怖い時は、「気づいていたなら、なぜ言わなかった？」あの会議で黙った自分がつらかったも次の一歩になる。
小さな進行整理は、全部を仕切ることではない。自分の手を止めている未決事項を一つ見つけ、決める人へ返し、次の担当と期限を残すことだ。 それなら、PMになりきらなくてもできるし、便利屋にならない線も引ける。
昨日の会議で黙った自分を責め続けなくていい。次の会議で、一つだけ問いを置く。翌朝、自分とチームの手が動けば、その一言には十分な価値がある。
