チームやプロダクトの話をしていると、いつも「決める」ことが中心に回ってくる、と感じます。プロダクトそのもの方向性、仕様を決める、優先順位を決める、やるかやらないかを決める。リーダーやPdMに求められるのも、だいたいそのあたりです。
リーダー層に求められるのは、正しさとスピードの両方
意思決定の重要性は、特にリーダー層に強く求められる、と自分は捉えています。
いまの時代は、少しのスピード感がないと出遅れになる場面もあります。決めるのが遅いと、後発になり、市場で売れなくなる可能性もある。ただ、早ければいいわけではない。きちんと見極めて、正しい意思決定をすることもセットで必要です。
中途半端な決め方を続けるより、決めきれない状態が長く続くと、チームにはきつい。士気やモチベーションが下がる。やるかやらないかが曖昧なままだと、誰も前に進めない。
求められるのは、正しい意思決定に加えて、スピード感です。やるか、やらないか。をはっきり宣言すること。リーダーだけでなく、チームとしての意思決定も、強く、かつ謙虚に出てくることが大事です。
チーム全体で揃える「やる／やらない」と、メンバー各自の意思
特に大事なのは、チームにとっての意思決定だと感じています。
チームの1人でも意思が見えなければ、そこが起点になり、物事やプロダクトの穴につながる。雑なたとえですが、腐ったみかんが段ボールに入っていたら、ほかのみかんにも影響する。いずれ箱全体の状態が悪くなる。チームも同じで、小さな曖昧さや不満が放置されると、士気や品質に波及していく、と捉えています。
だからシンプルに、メンバーそれぞれが自分の意思を明確に伝えることが重要です。「だれが言ったから」「上から言われたから」という外部の言い訳に寄せるのではなく、自分はやるのか、やらないのか、なぜそう考えるのかを言葉にする。それだけで、チームの空気は変わっていく、という経験があります。
意思決定はトップダウンだけの話ではない。全員が同じ方向を向くための、地味ながら一番効く仕事のひとつです。
PdMは、顧客の文脈でチームを牽引する
プロダクトをマネジメントする立場の人には、チームの士気が下がらないように、意思決定のスピードと「やる／やらない」の意思を明確に示す必要がある、とメモしていました。それに加えて、チーム全体の認識合わせを促す役割も大きいです。
エンジニアが好き勝手に作って、自己満足で終わるプロダクトは、顧客の要望や文脈を把握していないときに起きやすいです。可能であれば、PdMが顧客や事業の視点を持ってチームを牽引する。それがないと、なかなかうまく回らない、というのは、経験則として共感できます。
証拠にもとづく意思決定（EBM）のような枠組みも、ここで効く場面があります。「なんとなく」や「一番偉い人の意見」だけで進むと、チームは動いても学びが残りにくい。顧客価値や成果指標と結びつけた決め方が、士気を上げる方向に働く、という感覚です。
AI時代は、決める回数が増えた
『AIエージェント 人類と協働する機械』を読んだとき、プログラマーの仕事が実装から意思決定へシフトした、という整理に強く同意しました。AIがコードを出すほど、人間は要件の明確化、設計判断、品質評価、長期的な技術選択に時間を使う。
その一方で、「意思決定の高密度化」と「AI疲れ」も実感しています。出力が増えるほど、採用・修正・却下の判断も増えます。アウトプットは早くなったのに、決める密度だけが上がって疲れる。これがAI疲れの正体のひとつだと、本の例えは腑に落ちました。
takorattaさんの「完全情報ゲームと非完全情報ゲーム」の整理も、近いところがあります。ルールが閉じた領域ではAIが実装を代行します。ルールが変わり相手の手札が見えない領域では、人間が候補から採用を決め、倫理や境界線を引きます。AIは候補を量産し、人間は決める。という分担です。
決めるだけでは、言葉が出なくなる
AIで効率化し、提示された案を選び続けている。これは自分にも当てはまる。ただ、それだけを続けると言葉は出なくなる。そんな感覚がある。
書かないと覚えない。発しないと言葉が出なくなる。定期的に脳のストレッチが必要だ、とメモしたのは、そのためです。決めることと、考えて言語化することは、別の筋肉だと感じています。
AIにおいて、脳に残りにくいのは、自分の引き出しから出したものではないからだ、と思う。それは理解できる。ただ、引き出しを探すよりAIのほうが早い。情報が多い、という意味で、意思決定の材料が必要以上に増えている、という感覚もある。
意思決定のスピードを上げる話と、考える余白を守る話は、矛盾しているように見えます。でも両方必要です。早く決めきる場面もあれば、波平さんのように書類を見つめて考える時間が価値になる場面もあります。AIが「手が止まっている＝非生産」と見えやすい今だからこそ、見えない仕事の時間を意図的に残す。という話も大事です。
ブログを書く、アウトプットする、は自分にとってそのストレッチのひとつです。決めたことを残す。なぜそう決めたかを後から読める形にする。ADRや意思決定ログをGitに残す、というのも同じ系統だと感じています。
スピードを出すために。まだ答えは見つかっていないが、できるアクション
ここまで、意思決定の重要性やチームでの揃え方は書けた。一方で、「意思決定のスピードを出すために、具体的に何をすればよいか」の答えは、自分にはまだ見いだせていない。
もっとシンプルに決められる仕組み化も大切だと感じている。過度な資料はAppendixに寄せ、いちばん伝えたいことだけを前面に出す削ぎ落としが、AIを活用した意思決定のスピードを止めないための仕組みではないか、と持っている。材料が増えるほど、決める前に読む量だけが膨らみ、速さの恩恵が相殺されやすい。
早く決めろと言われても、事情が単純ではない。情報が足りない。権限がない。トレードオフが重い。そういう場面では、言葉を濁して様子を見るほうが楽に感じることもある。ただ、それが続くとチームが止まったままになる。問題の重要性は分かっているのに、手応えとなるアクションのリストが揃っていない。だからこそ、これから試すことをこの記事に残しておく。
いま大事にしているのは、次の1つです。
難しい意思決定や判断が難しいとき、言葉を濁さず、「自分では決められない」と明確に伝える。
「検討します」「一度持ち帰ります」だけで終わらせず、決めきれない理由と、誰の判断が必要かまで言葉にする。それ自体がチームの前進になる。決めないまま宙ぶらりにするより、エスカレーション先を示したほうが速い。
例外もあります。上位層で、自分が決めなければならない案件はその限りではない。役割として最終判断を持っているなら、濁す理由にはならない。逆に、現場のメンバーとして権限の外にある判断を、なんとなく引き受けて宙吊りにするほうが、スピードを落とす原因になりやすい。
このルールは、スピードの全貌ではない。EBMで証拠を揃える、チームでやる／やらないを揃える、といった話とセットで試していく必要がある。ただ、自分が今日から実行できるアクションとしては、いちばん具体的で、チームの士気にもつながると感じている。
スピードの正解を見つけるまでの暫定策、という位置づけです。読み返したときに、ほかのアクションが増えていたら追記したい。
まとめ
意思決定について、いまの自分の整理は次のとおりです。
- リーダー・PdMには、正しさとスピード、そして「やる／やらない」の明確さが求められる
- チーム全体で認識を揃え、メンバー各自が自分の意思を言葉にすることが、士気と品質につながる
- 意思の見えないメンバーがいると、プロダクトやチームの穴の起点になりうる
- 決めきれない状態が続くと、チームの士気やモチベーションが下がりやすい
- 顧客や事業の文脈を持った牽引と、EBMのような証拠に基づく決め方が効く
- AI時代は決める回数が増え、AI疲れも起きうる。人間の役割は候補からの採用と境界線の設定
- 決めるだけでは足りない。書く・考える・言語化する時間も意図的に確保する
- AIの出力は引き出し由来ではないと脳に残りにくく、意思決定の材料は必要以上に増えやすい
- 本筋をシンプルにし、過度な資料はAppendixに寄せる削ぎ落としが、AI時代の決断スピードを止めない仕組みになりうる
- スピードの全貌はまだ整理しきれていない。いま実行できるアクションは、決められないときに言葉を濁さず伝えること
- 自分が決めるべき案件を除き、「自分では決められない」と明示してエスカレーションする
メモをブログにした、という位置づけの下書きです。読み返したときにアクションが増えていたら、また手を入れます。