チーム開発の意思決定、どうすればスムーズにできる？

こんにちは、EventHubの井上です。昨年の12月から約1年ほどプロジェクトマネジメント※をやらせていただいてます。仕様の調整やテーブル設計などチームでの決め事をリードしなければならない場面が多かったのですが、なかなか苦労しました。

ちょっとした会議を進行するのも緊張しますし、何より会議の設計や進め方が未熟なために、議論が平行線になり、30分の予定が1時間経っても何も決まらない・・・なんてこともありました。

試行錯誤の日々でしたが、つい最近、上司から「会議の進め方が改善されてますね」とフィードバックをいただくことができました。

この記事では、周囲の方からのアドバイスや自身の経験を元に、チーム開発でスムーズに意思決定するためのtipsを5つご紹介します。

1つの事例として参考になる点があれば嬉しいです。

※ EventHubにはプロジェクトマネージャーという役職はなく、開発チーム内の任意のメンバーがその役割を担う体制になっています。

tips1: 提案ありきで受け手の負担を減らす

会議においてダメな方法は、「参加者に丸投げすること」です。自分の中でも整理できていないままダラダラと話して参加者の時間を消費し、結果、何も決まらなかったりします。

ではどのようにすると良いかというと、「提案とセットで相談すること」です。

例えばあなたが会議の参加者だとして、AさんとBさんがそれぞれ相談事を持ってきたとします。

Aさん:「〜〜なことで困ってまして、〜〜も調査したんですけどよく分からなくて、どうすればいいでしょうか？」

Bさん:「〜〜を解決したいと思ってます。原因は〜〜で、現状は〜〜なので、それを元にA~C案を持ってきました。〜〜な理由で、B案が良いと考えています。B案で進めていいでしょうか？」

どちらが答えやすいかは明白です。Aさんの相談には以下のような疑問が浮かび、参加者は何を答えればいいか頭を悩ませてしまいます。

そもそも何を解決したいんだろう？
何をどこまで調査したの？
なんとなくこうするのがいい気がするけど、他にも良いやり方がありそうだな・・・。

一方で、Bさんの相談に対しては、それほど負担なく回答することができます。参加者は提案をベースに考えられるので、他の観点やより良い意見も出やすくなります。

提案をどう作るか

提案を準備するためのプロセスですが、自分はおおむね以下で進めています。

実現したいこと・目的を明確化する
現状どうなっているか調査し、整理する
確認すべきこと（= 論点）を洗い出す
その中で重要な論点を絞る
その論点について、複数案を用意して、自分なりの結論（= 提案）を決める

こう書くと難しく聞こえてしまいますが、要は、「相談する前にちゃんと調査して自分なりにどうすべきか考える」ということです。

以前の自分は次のような失敗をしていました。

論点を絞らずに議論を進めてしまう。
- 参加者は何を聞きたいのか、何を話せばいいかよく分からない。
  - 結果、何も決まらない。

ではどうすべきか。次のポイントを押さえると、決まりやすい会議になります。

1回の会議で扱う論点は1つにする。
その論点について複数案を用意し、その中で1つ推奨案を提示する。

また、認識合わせや意思決定が必要な場面では、ドキュメント化して整理すると進めやすくなります。例えば、こんなフォーマットが役立ちます。

【背景】
- なぜこの議題が必要か？
- どのユーザー・どの機能に影響するか？

【現状と課題】
- 何が問題か？
- どの部分が曖昧か？

【論点】
- 今回決めたいことは何か？
- 仕様/実装/運用/UXのどれか？

【選択肢】
- 案A：
- 案B：
- ゼロ案（やらない選択肢）：

【判断基準】
- 工数、UX、リスク、将来の変更コストなど

【推奨案】
- 私の提案はA案です（理由：●●）

【意思決定方式】
- 非同期でコメント募集（期限：●月●日●時）
- or 同期MTG実施（参加者：最小限●名）

【ログ】
- 決まったこと／決まらなかったことを残す

tips2: 論点を整理し、適切な人に相談する

何か困りごとがあった時に、相談相手を間違えてしまうことがあります。例えば、実装の制約についての困りごとをPdMやデザイナーに相談しても、「それは開発チーム内で決めてください」と返ってくるでしょう。一方で、どのような要件・仕様にすべきかを開発チームだけで決めてしまうのはよくないはずです。

なぜ相談相手を間違えてしまうのかというと、何を確認したいのか、自分の中で論点が整理できていないからです。tips1で紹介したようなプロセスで論点を整理しておけば、このようなミスコミュニケーションは防げるはずです。

自分の失敗例として、PdMに仕様のことを聞いたつもりが、実装観点の話が混ざってしまっており、「仕様観点か実装観点どちらの話ですか？」と聞き返されてしまったことがありました。これをきっかけに、論点を整理した上で、誰に何を聞くべきか意識してコミュニケーションをとるようになりました。

tips3: 図を活用する

提案書を作る時に、題材が複雑だと文章だけではうまく伝わらない場合があります。最近あった事例は、バッチ処理を行うタイミングをいつにするかの仕様を決める際、「現在時刻が〇〇で、設定時刻が〇〇の時、XX時に発火する」等と文章でまとめてみましたが、うまく伝わりませんでした。

そこで、Miroというツールで時系列を図表に起こしたところ、文章よりもずっと伝わりやすくなりました。自分自身も図に起こす過程で、見落としていたエッジケースに気づけたりと、思考の整理にもなると実感しました。

難点としては文章よりも手間と時間がかかるため、心理的に着手しづらいことです。正直に言うと、面倒なのでやりたくないと思ってしまいます。

面倒さを乗り越えるための心がけとして、以下を持つようにしています。

センスは不要。下手でも伝わればいい。
最初は面倒なのは当たり前。
皿洗いと同じでやり始めたら最後までやれる。

とは言え、文章よりも時間がかかることは事実なので、それほど複雑でない事柄は文章だけで十分だと思います。

生成AIで作る手間を省く

設計フェーズでよく使うER図、シーケンス図、状態遷移図などは、Mermaid記法で生成AI（Claude Code）に書かせ、Notion MCPでそのまま転記するような運用にすればそれほど手間をかけずに作成することができます。

また、近年はClaude CodeやCodexなどを使えば簡単なモックをすぐに作ることができるので、ローカル環境で動くものを作って共有すると、より共通認識を得やすくなると思います。

蛇足ですが、簡単なUIモックを作る時に、CursorのComposer 1に書かせてみると超高速で驚きました。公式によると、同等モデルの4倍の生成速度とのこと。一方で、より複雑なものを作る時は、Claude CodeやCodexの方が精度高くやってくれる印象です。

tips4: 期限を設定する

チーム開発で意思決定を行う上で、メンバー間の合意形成をすることが重要です。合意形成することでお互いに共通認識が持てますし、納得感のある状態で開発を進めることができます。

ただ、テーブル設計などではあるあるですが、それぞれ主義主張があるため、議論が紛糾し、なかなか決められないことがあります。また、設計書をSlackで共有したものの、誰もコメントしてくれない・・・なんてこともよくあります。

なぜこうなるのかというと、期限を決めていないからです。期限がないためにメンバーは以下のような心理になってしまいます。

まだ時間があるから、もう少し議論したい。
まだ時間があるから、あとでコメントしよう。

また、設計書をただ共有されただけだと、どうリアクションすればいいか分からず躊躇してしまうようなこともありえます。「どうコメントすればいいですか？」と聞いてもらうだけで解決しますが、起案者がそのあたりの案内をした方がスムーズに進むはずです。

以上を踏まえて、何かを提案するときは以下のように期限と決定方法を示します。

◯月◯日の◯時に結論を決めます。
（簡単な事柄の場合）SlackのこのレスにYes/Noスタンプで投票してください。
（複雑な事柄の場合）設計書に疑問点など事前にコメントいただき、30分の会議で決めましょう。

多数決で意見が割れてしまったりしても、期限に達したら、提案者がベストだと思う案を選択し、他のメンバーは Disagree & Commit（賛同しないがコミットする）の精神で、チームでその案を進めていくことが大事です。

tips5: ログを残す

同じ議論を繰り返さないようにする、という観点で議論のプロセスや決定事項のログを残すことが重要です。

できれば決定事項は一箇所のマスタ文書に反映し、複数箇所に分散しないようにすると、後で混乱が生じるのを防げます。要件については要件書に、設計については設計書に更新を加え、常に最新の状態に保ちます。

議論プロセス（議事録）を残すことにも価値があります。例えば、別の開発者が後から改修を加える際に、「なんでこの設計になったんだろう。こうした方がいい気もするけど、何かこうしなければならない理由があったのかな」と疑問に思う場面があると思います。開発中のチームが実装時に「そういえばなんでこうしたんだっけ」と議事録を遡ることもよくあります。

EventHubではGoogle Meetを使用していますが、意思決定する会議では、録画と「Geminiによる自動メモ作成」機能を使い、負担なく議事録を残すようにしています。自動メモの精度は素晴らしく、要点が的確にまとまっていて、生成AIの進化を実感します。

まとめ

以上、5つのtipsをご紹介しました。チーム開発の経験が豊富な方は、無意識レベルでやっていることがほとんどだったかもしれません。こうして書いてみるとどれも当たり前のことだと感じるのですが、情報量が多く、タスクが山積みな状況ではつい疎かにしてしまうことがあるなと思いました。

抜け漏れがないように、以下のようなチェックリストをNotionテンプレートなどに貼っておくといいかもしれません。よかったら活用してみてください。

意思決定チェックリスト

- [ ] 目的は明確か？
　（なぜ決める必要があるのか、背景・課題が書けている）

- [ ] 相談相手は適切か？ 
　（仕様→PdM／実装→開発／UX→デザイン etc）

- [ ] 論点は1つに絞れているか？
　（複数ある場合は順番に扱う or 別ミーティングに分ける）

- [ ] 選択肢（A案 / B案 / やらない案）は提示できているか？
　（推奨案と理由も示せているか）

- [ ] 図・モックなど、伝わる形に変換したか？
　（例：ER図 / シーケンス図 / 時系列表 / Before-After比較 / UIモック）

- [ ] 意思決定方法と期限は設定したか？
　（例：Slack投票・ドキュメントコメント・30min同期MTG）

- [ ] 決定後の次アクションが明確か？  
　（誰が何をいつやるか）

- [ ] 決めた内容を正しい場所に反映したか？ 
　（例：要件書 / 設計書 / JIRAチケット / コーディング規約）