意思決定の落とし穴から学ぶ エンジニアリングマネージャーの教訓 ～発表後の落穂拾い🍂
本記事は READYFOR Advent Calendar 2024 の9日目の記事です。
先週金曜、Qiita Nightに登壇したので、新しく記事を書く余力がなかったため、その落穂拾い的に Note に残しておきたいと思います。
登壇のきっかけ
過去の投稿記事をきっかけに、Qiitaの方からお声掛けいただき、Qiita Night 登壇の機会をいただきました。今年は特に、様々なアウトプットを通じて新しい機会や繋がりが増えたように感じます。改めてアウトプットの大切さを実感する良い経験となりました。感謝！！
テーマ選定の背景
このテーマを選んだ背景には、主に3つの理由があります。
これまでの記事では成功体験の共有が中心でしたが、その裏側にはうまくいかなかった事例も数多くあります。そういった失敗体験も振り返りながら、共有できるナレッジにしたいと考えたこと。
エンジニアリングの分野ではあまり取り上げられない、少しニッチな切り口の方が新鮮さがあると感じたこと。また、一般的なエンジニアリング書籍とは異なる分野の知見を取り入れることで、新たな視点が得られるのではと考えたこと。
「意思決定の教科書」がきっかけです。特に第一章「The Hidden Traps in Decision Making（意思決定をゆがめる心理的な落とし穴）」は、豊富な意思決定研究の知見が含まれており、これをエンジニアリングの文脈で言語化できないかと考えていたこと。
なお、この内容はハーバードビジネスレビューでも公開されていますので、関心を持たれた方はぜひご覧ください。
意思決定の教科書 📚
今回は第一章「The Hidden Traps in Decision Making（意思決定をゆがめる心理的な落とし穴）」のみを取り上げていますが、他の章も意思決定に関する様々な知見が詰まっていてオススメな書籍です。ただ、これだけ意思決定のメカニズムが研究され、解明されているにも関わらず、今なお同じような判断の罠に陥りがちだということ。また、「知っていても避けられない」と言う漠然とした切なさも同時に痛感しますが……。
第１章「意思決定をゆがめる心理的な落とし穴」
第２章「意思決定の行動経済学」
第３章「ニアミス：隠された災いの種」
第４章「対話が組織の実行力を高める」
第５章「プロセス重視の意思決定マネジメント」
第６章「意思決定のRAPIDモデル」
第７章「道徳化ほどおのれの偏見にきづかない」
第８章「意思決定プロセスのカイゼン」
第９章「脳科学が解明する意思決定リスク」
第１０章「戦略立案と意思決定の断絶」
意思決定の落とし穴から学ぶ
ここでは発表資料の内容と被ります。「意思決定の落とし穴」を振り返る上で、なるべく特定の事案に絞らずに、一段抽象化した汎用的に用いられるような表現を心掛けしました。登壇内容としては、より生々しく具体的に書いた方が良かったのかもしれないですが、いざ失敗事例を書いてみようとすると、本来意図しない方向に捉えられそうな気もして、意外を難しいなと感じました。
教訓その１) ３回以上繰り返し発生する作業は仕組み化する
『積み上がり続ける「とりあえず手動で対応しよか」』
現状維持バイアスの罠：“選択肢が多いほど、人は現状維持の方向に傾くと言う事実が証明されている”
日常的なオペレーションにおいて、発生頻度が低い作業は、エンジニアが手動でコマンドを実行して対応することが多い。
➡︎ 手動対応は徐々に積み重なり、結果として本来注力すべき開発業務を圧迫する。
“ 複数の選択肢が提示された場合、現状維持を選択しがちである “
システムの機能要件を定義する際は、運用に必要な機能も漏れなく考慮する。特に、定常的なオペレーション作業は機能として実装することを検討する。
作業が3回以上発生することが予測される場合は、仕組み化を検討する。その上で、自動化や他チームへの移譲など、最適な方法を選択する。
「トイルの削減」に計画的に工数を確保できる仕組みを整える。
教訓その２） リファクタリングを起点に考えない。
『終わりが見えない大規模リファクタリング』
サンクスコストの罠：“意味も持たなくなってしまったような意思決定を何とか正当化しようとして、本来選ぶべきではない選択肢を選ぶ”
技術的負債の解消を目指し、コア機能のリファクタリングに着手。しかし、プロダクト要件との乖離が徐々に生まれ、技術的な懸念も浮上。進むも退くも辛い状況に...
➡︎ これまで進めてきたリファクタリングを全戻しする。
リファクタリングは、プロダクトの方向性と整合性を取りながら進める。現行システムと目指すべき姿の両方を明確に定義し、適切な範囲で実施する。
ドメインエキスパートの知見は重要だが、それだけでは十分ではない。システムの技術的な制約や実装上の課題も含めて、ドメインを包括的に理解する。
リファクタリングは、あくまでもシステム改善の手段の一つである。プロダクトの目標達成における位置づけを明確にし、その効果と影響を慎重に評価する。
教訓その３） 新しい技術やツールの導入は運用面もしっかり考慮する
『導入担当者と同時に消えゆくシステム』
確証バイアスの罠：“その時点で抱いた直観や観点を裏付けるような情報しかあなたは受け入れず、反対意見などには耳を貸さない”
注目を集めていた新しい言語とフレームワークを一部機能に導入。しかし、主導していたエンジニアがチームを去った後、残されたチームは改修や運用保守への対応に苦心することになる。
➡︎ 既存の言語スタックへ書き換えられる。
新しい技術に関心を持ち探求することは大切。ただし、その興味が確証バイアスとなり、本来必要な検討事項を見落とさないよう注意する。
新しい技術へのチャレンジは重要だが、本番環境への導入では運用面の検討が不可欠。特にエンドユーザーへの影響が想定される機能は慎重に判断する。
教訓その４) いかなるシステムにおいて最も重要な機能は信頼性である
『レイテンシ改善を後回しにした矢先、襲いかかる大量アクセス』
フレーミングの罠：“問題の理解の仕方次第で、取るべき選択肢が大きく変わってくる”
新機能の開発を優先する中で、レイテンシや可用性といったシステムの信頼性指標の可視化や改善への取り組みが後回しとなる。
➡︎ 想定外の大量アクセスにより鳴り響く、嬉しい悲鳴とインフラの悲鳴
ビジネス指標の改善だけを追いかけるのではなく、エンドユーザーへの価値提供を多角的に捉え、信頼性も含めた総合的な課題設定を心がける。
新機能の企画段階から、非機能要件も価値提供の重要な要素として位置付ける。機能開発と信頼性は、トレードオフではなく両輪として捉える。
新機能か信頼性かという二項対立の思考ではなく、両者の価値を意識する。
教訓その５) 過去経験や他社事例に囚われず、事実ベースの思考を心掛ける
『会社の規模や実態に馴染まない、プラクティスの導入』
アンカリングの罠：“人は一番最初に得た情報にどうしてもこだわってしまう”
過去の成功体験や他社事例という「最初の情報」に縛られすぎると、現状に最適な判断を見失う可能性がある。事実に基づく分析と建設的な議論を通じて、より良い選択肢を探る。
一見同じような課題に見えても、実際の状況は大きく異なることがある。過去の経験は参考程度に留め、現状分析を丁寧に行おう。
技術プラクティスは進化し続けている。過去の常識に固執せず、現代における有効性を見極め、導入の判断を行う。
他社の成功事例に引きづられることなく、自社の規模や実態に即した判断を心がける。
教訓その６) 見積もりは当てない、解き明かす
『やっぱり足りない、工数の見積もり』
見積もりと予測にまつわる三つの罠：“「自信過剰の罠」「安全第一主義の罠」「偏った記憶の罠」
見積もりは、予測して終わらせず、完璧さを追い求めるでもなく。チームの特性や傾向を科学的に捉え、継続的な改善を重ねていくプロセスを考える。
「自信過剰の罠」：過去の経験や実績に基づく過信が、安易な見積もりを生む。「似たような機能を作った経験がある」「このチームなら簡単」という思い込みには注意。
「安全第一主義の罠」：必要以上のバッファは、チームのモチベーションとフロー状態を妨げ、プロジェクト全体の推進力を失わせる場合もある。過度に慎重な見積もりが、かえってプロジェクトの効率を下げていないか意識する。
「偏った記憶の罠」：印象的な成功や失敗の経験が、現在の判断に過度な影響を与える。過去の特定の出来事に引きずられず、現状に即した判断を心がける。
最善の防衛策
意思決定をするのはマネージャーだけではない。
意思決定というとマネージャーの仕事と思われがちですが、実際には従業員一人ひとりの日々の判断の積み重ねにより、組織は形作られています。エンジニアリングの文脈では「開発の質とスピード」という表現は馴染み深いと思いますが、それと同等以上に意思決定の「質とスピード」は重要です。一人ひとりが主体的に考え、その判断を高め合えるチームづくりが、組織にとって大切であると思います。
終わりに
今回の登壇を通じて、意思決定の「罠」は誰もが陥る可能性があるということを改めて実感しました。だからこそ、チームで認識を共有し、お互いにフォローし合える関係性が大切なんだと思います。この記事が皆さんのチームでの意思決定の参考になれば嬉しいです。
明日はREADYFOR Advent Calendar 2024の１０日目、 @takaheraw さんによる記事です。お楽しみに〜！