「結局、何が言いたいの？」と言わせない。中堅エンジニアが研修で掴んだ『思考の武器』
みなさん、こんにちは。shormaでエンジニアをしているバグとねこげまみれ🐈です。
最近「自分、今のままでいいんだっけ？」とふと立ち止まる瞬間はありませんか？ 中堅エンジニアという立場になると、コードを書く技術だけでなく、「チームをどう動かすか」「複雑な問題をどう整理するか」といった、一段上のレイヤーでの課題が増えてきますよね。
先日、そんなモヤモヤを解消するためのヒントが詰まった研修「中堅社員、あなたの役割と仕事はこれだ！」に参加してきました。そこで手に入れた、現場で即戦力になる最強の「2つの武器」を、エンジニアならではの視点で詳しく共有します！
■ 武器1：迷子にならない「問題の8段構造」
「バグが出た！」「納期が危ない！」という時、いきなりソースコードを書き換えたり、力技でカバーしようとして、結局事態を悪化させた経験はありませんか？
研修で学んだ「問題の8段構造」は、解決策（HOW）に飛びつく前に、冷静に状況を紐解くためのフレームワークです。
【具体例：パフォーマンス劣化問題で考える】
例えば、「APIのレスポンスが遅い」という問題が発生したシーンを想像してみてください。
- ステップ1：あるべき姿の明確化
- 本来は「レスポンス200ms以内」であるべき。
- ステップ2：現状の把握
- 今は「平均800ms、ピーク時1.5s」かかっている。
- ステップ3：問題の特定（ギャップの確認）
- 「600ms以上の遅延」が解決すべき問題。
- ステップ4：問題の分解（どこで起きているか？）
- フロント、API、DB？切り分けた結果、「特定のDBクエリ」に時間がかかっていることが判明。
- ステップ5：原因の深掘り（真因の追求）
- なぜ遅い？→インデックスが効いていない。なぜ？→先日のリリースで追加した条件が考慮漏れだった。
- ステップ6：対策案の立案
- インデックスの追加、およびコードレビュー項目の更新。
- ステップ7：対策の実行
- ステップ8：効果の確認と標準化
Point! いきなり「サーバーのスペックを上げよう！」と解決策に走るのではなく、「どこが（Where）」「なぜ（Why）」を順に追いかけることで、手戻りのない確実な改修が可能になります。
■ 武器2：説得力が爆上がりする「ピラミッドストラクチャ」
上司への提案や会議の報告で、「で、結局何が言いたいの？」と言われてしまったことはないでしょうか（私は何度もあります…）。情報の伝え方を構造化する技術、それが「ピラミッドストラクチャ」です。
視覚イメージ：論理の三角形
情報を整理する際は、以下のような三角形の構造を意識します。
なぜこれがエンジニアに効くのか？
私たちはついつい「実装の苦労話」や「細かい技術仕様」から話し始めてしまいがちです。しかし、意思決定をする立場の人（上司や顧客）がまず知りたいのは「結論」と「納得感のある根拠」です。
- 結論を先に言う（頂点）
- 根拠を3つに絞る（土台）
- 各根拠に具体的な数値を添える（詳細）
この順番を守るだけで、話の筋道がピシッと通り、相手の納得感が格段に変わります。
■ これからの自分にご期待ください
日々のデバッグや設計はもちろん、自分のキャリアを考える上でも、この2つの思考法は「一生モノの武器」になると確信しました。
まずは明日からの提案資料を、この「ピラミッド型」で整理して、上司に「お、今日の説明はわかりやすいな」と言わせるのが裏目標です（笑）。
一歩レベルアップした（予定の）姿で業務に励みますので、ぜひ見守ってください！
執筆：バグとねこげまみれ🐈
