支える側の技術 ~チームを安定させる守りの思考~

はじめに

この記事は、mediba Advent Calendar 2025 の13日目の記事です。

mediba でバックエンドエンジニアをしている堀です。

エンジニアのキャリアでは、前に立つリーダーや実装を担うメンバーが注目されがちですが、その間でチームを支える役割もあります。

私は今、リーダーの推進力と現場の実装の間に立ち、プロダクトが安定して進むよう“守りの技術”を意識して働いています。

この記事では、なぜ自分がこの立ち位置にいるのか、そしてどんな視点で設計・実装・コードレビューなどを行っているかをまとめました。

支える側とはどういう役割か

支える側の役割を一言で表すと、
チームの摩擦や詰まりを減らし、誰もが迷わず前に進める状態をつくること です。

リーダーが意思決定に集中できるように、必要な情報を揃え、ノイズを取り除く。
メンバーが安心して実装できるように、仕様の曖昧さやリスクを先回りして解消する。
そしてプロダクトを安定して進めるために、負債や運用面の危険を拾い上げ、事故を未然に防ぐ。

いずれも派手な仕事ではありませんが、
こうした支えがあることで、チームの進行速度や心理的な安定感は大きく変わります。

プロジェクト開発で最初にやること

プロジェクトを進める際、私が最初に取り組むのは 土台づくり です。

• ドキュメントの置き場所を決める
• 議事録や設計書のテンプレートを用意する
• スケジュールやタスク管理の枠組みを整える
• ブランチ運用ルールを決める

いわゆる「形から入るタイプ」かもしれませんが、
最初に型を整えておくことで、コミュニケーションが取りやすくなり、齟齬による事故を減らし、迷いなく進める環境を作れます。

地味な作業ではありますが大事なポイントですし、個人的には嫌いじゃない工程です。
プロジェクトごとに最適な形は異なるので、あくまで土台として用意し、
メンバー構成や状況に合わせて柔軟に変えていくようにしています。

設計で意識していること

私のチームでは、基本的にモブワークで設計を行っています。
そのため、一人の考えに偏らず、メンバーの意見を自然に取り入れることを意識しています。

私自身は心配性なところがあり、些細な疑問やレアケースまで考えがちです。
対応不要という判断になったとしても、一度考え、理由を持って判断するプロセスは大切だと思っていますし、後から何か起きた際の素早い対応にもつながります。

また、シーケンスや処理パターン、SQL の流れといった判断の根拠は、必ずドキュメントとして残すようにしています。
見返したときに余計な考察をしなくても理解できる状態 をつくることを意識しており、
その結果、実装やコードレビューの際に迷いが生まれにくくなります。

実装で意識していること

実装では、書く時間より 読み返す時間をしっかり取る ようにしています。

AIがコード生成を加速させるようになった今、
“書いた後に自分でどう検証し、事故を防ぐか” がますます重要だと感じています。

• インプットやデータの考えうるパターンで動作確認する
• 自己レビューで仕様どおりか丁寧にチェックする
• PR を出した後も、一度落ち着いて読み直してみる

ローカルでは問題なく見えても、PR として冷静に読むと意外と凡ミスが見つかることがあります。

また、実装に不安がある場合は「なぜそう書いたのか」「何を懸念しているのか」を言語化し、
その観点ごとにレビューをお願いするようにしています。
曖昧なまま進めないことで、将来のバグの芽を潰し、レビューの精度もチームとしての理解もより深まります。

コードレビューで意識していること

コードレビューでは、フロントエンド・バックエンド・インフラなど、複数の領域を見ることがあります。

正直、すべての分野で深い知識を持っているわけではありません。
だからこそ、要件や設計とのズレがないか、意図しない挙動につながるパターンがないか という視点を中心に確認しています。

また、よくお願いしているのは、
API の実行ログや terraform plan の差分結果など、実際に動かしたときの出力を PR に貼ってもらうことです。
これはメンバーを信頼していないからではなく、
“動作結果を複数人で確認できる” という安心感を得るためです。
私自身も同じ理由でログを貼るようにしています。

指摘をする際は、否定的な言い方にならないよう意識しています。
コードレビューはプロダクト品質だけでなく、チームの空気を作る行為 でもあると思っています。
最後はちゃんとみんなで、ヨシ👍（Approve） しましょう。

なぜ「守りの思考」を持つようになったのか

正直に言うと、最初からこういった働き方を意識していたわけではありません。
様々なチームで業務を行ってきた中で、周囲には推進力の高い方や、圧倒的な技術力を持つ方々がたくさんいました。

その中で私はチーム全体を俯瞰し、足りていない部分を補い
プロダクトの安全性や安定性を高めることで価値を発揮してきました。
振り返ると、そうした経験の積み重ねが、自然と “守りの思考” につながっていったのだと感じています。

そして余談ですが——
私は小中学生の頃、野球では守備が比較的得意で、内外野どこでも守れるよう鍛えられていました。
本質的なスタイルは、あまり変わっていないのかもしれません（笑）

今の立場は、スキルだけで得られたものではない

支える立場を任せてもらえるようになったのは、スキルが特別に高かったからではありません。

• 運が良かった
• 周りに支えてもらえた
• 実績を積む機会があった
• 過去のチームでの経験で学んだことを続けてきただけ

その積み重ねのおかげで「チームにいれば安心」と言ってもらえるようになりました。

支える技術は1人では完結せず、チームの存在があって初めて形になるものです。
だからこそ、私は周囲へのリスペクトを忘れないことを大事にしています。

最後に

最後まで読んでいただきありがとうございます。

地味ではありますが、支える技術もまたプロダクトの品質やチームの健全性に確実に影響します。
今後も周囲へのリスペクトを忘れず、自分の技術と姿勢を磨いていきたいと思います。

当たり前に実践されていることも多いかもしれませんが、
この記事が少しでも参考やヒントになれば幸いです。