こんにちは、人事・技術・経営推進本部の技術戦略ディビジョンでマネージャーをしています、天津です。
お仕事としてはシニアインフラエンジニア・SREなことをしています。
今回は、我々の部署が直近で取り組んでいる「越境改善」の実践と、その中で見出した7つのアプローチについて紹介します。
はじめに
我々の部署、技術戦略ディビジョンは、主に自社の様々なサービスを横断し、非機能領域の改善を担当しています。 具体的には、セキュリティ強化、運用負荷の軽減、IaCやCI/CDといったDevOpsの推進、そして技術的負債の解消などです。
（部署の紹介記事はこちら）
ここ数年、我々は自社サービスの全体的なセキュリティ対策に注力してきましたが、その一方で個別のサービスに直接踏み込んだ貢献が少なくなっていたという背景がありました。
そんな中、我々は改めて他部署が主管する自社サービス群に「越境」し改善を進めることを始めています。
本記事では、我々がそのようなシステムの改善で直面した困難と、それを乗り越えるために見出した 物語（ストーリー） 、そして 7つの具体的な実践的アプローチ（ノウハウ） を合わせて紹介します。
我々の前に立ちはだかった「3つの壁」
今回、我々が主に取り組んでいるのは、社内でも特に歴史の長い広告関連サービス群でした。
これらは長年の運用の中で技術的負債が蓄積し、OSやライブラリのEOL対応、そしてコスト削減が必要な状況となっていました。
これらの改善に取り組んだ我々には「3つの壁」が立ちはだかっていました。
仕様の壁
まず直面したのは、システムの全体像把握が難しいという現実でした。
全体を俯瞰したドキュメントが存在しないことも多く、各サーバの役割や通信経路が不明瞭。 サーバは手動で構築されたものについての手順書はメモレベルのものしか残っていない状況もありました。
また、Ansibleコードは存在するものの、現実の環境との乖離（drift）が大きく、何が正しいのか分からない状態でした。
また、システムの個別の仕様やビジネスロジックに関するドキュメントも多くは残っておらず、アプリケーションの挙動を理解するためには、実際に動いているものを調査する必要がありました。
文化の壁
次にぶつかったのは、部署間の「文化の違い」でした。
改善対象のサービスを主管する部署（以下、アドテク部署）は、我々のような改善活動だけでなく、日々の運用や新規開発も行っています。 そのため、我々がレビューをお願いしても、なかなかレスポンスが得られないことがありました。
また、当初我々はアドテク部署が持つ開発ガイドラインの存在を把握しておらず、良かれと思って進めた実装が、彼らの作法と異なり手戻りになることも。部署が違えば、仕事の進め方や暗黙のルールも違う。その現実を改めて感じさせられました。
技術・知識の壁
そして最も根深いのが、我々自身の知識不足でした。
我々はアドテクに関するドメイン知識が浅く、ビジネスロジックや専門用語への理解が追い付いていない状況もありました。
また、彼らが使用するScalaやGoといった技術スタックにも不慣れで、適切な改善提案ができない場面もありました。
この知識不足は、見積もり精度にも直結します。アプリケーションの仕様が分からず、調査と手戻りを繰り返すうちに、当初の見積もりを大幅に超過することもありました。
チーム内では「これは思ったより根が深いぞ…」という焦りが募るばかりでした。
3つの壁を乗り越えるための「7つの実践的アプローチ」
これらの壁を前に、我々が見出した、7つの実践的アプローチをご紹介します。
Part 1: 「仕様の壁」を壊すアプローチ
アプローチ1： AIと現物調査のハイブリッドで全体像を掴む
われわれはまず、システムの全体像を把握することから始めました。 しかし、ドキュメントが整備されていない状況でもあったため限界がありました。
古いOSを使用している状況もあり、例えばAWS Systems Manager のインベントリ情報といったものも活用しづらい状況でした。
そのような状況でのアプローチとして、動いている現物を見る手法を選択し、まずサーバー上で基本的なコマンドで状況を把握することから始めました。
psとnetstat、lsofで、動いているプロセスと通信先を特定する。crontabで、定時実行される隠れたジョブを見つけ出す。- 監視ツールの設定から、システムの「正常な状態」を推測する。
- アプリケーションやミドルウェアのログを追い、実際の挙動やエラーを把握する。
また、AWSなどのクラウドリソースも確認し、実際に動いているモノを把握しました。
そして、ソースコードの読解にはAIの力を借りました。GitHub Copilotのコード解説をフル活用し、処理の流れを掴むことで、調査時間を大幅に短縮できました。
アプローチ2： "分からなさ"を図に描いて整理・共有する
調査で分かった情報は、スプレッドシートにまとめた上で図に落とし込みました。
サーバー構成、ネットワーク経路、データの流れ…。図に描くことで、自分たちの頭が整理されるだけでなく、チームやアドテク部署のメンバーと議論する際の「共通言語」が生まれます。
これらをまとめることで認識のズレによる手戻りを防ぐことができました。
アプローチ3： 最も詳しい人を巻き込む
最終的に頼りになるのは、やはり「人」です。我々は、アドテク部署の担当者や、時にはビジネス担当の方にもヒアリングを実施しました。
「このシステムは何のためにあるのか」「なぜこの仕様なのか」。対話を通じて、システムの目的や背景にあるビジネス要件への理解を深めていきました。
また、システム上で使われる固有名詞、使われているキーワードが分からないこともしばしばありました。
これもヒアリングや対話を通じて意味を理解し、最終的には我々が相手の言葉で説明できるようになっていきました。
Part 2: 「文化の壁」を溶かすアプローチ
アプローチ4： 期待値を最初にすり合わせる
当初の我々は、自分たちのペースで開発を進め、レビューを依頼しては「待ち」の状態になる、ということを繰り返していました。
「待ち」の状態では並列での別作業を進めることもありましたがコンテキストスイッチングによる影響もあり、あまり効率的ではありません。
また、アドテク部署の担当者にとって、我々の依頼がこちらが考える以上の負荷になってしまうケースもあったと思います。
この反省から、我々は相手の文化を尊重し、仕事の進め方を最初にすり合わせるようにしました。
アドテク部署の担当者からのアドバイスもあり、定期的な相談の時間を設けるなど期待値をすり合わせることで、コミュニケーションは改善しました。
アプローチ5： "オーバーコミュニケーション"を実践する
Slackでのこまめな報告・相談も意識しました。考えていること、試していること、困っていること…。
少し過剰なくらいにテキスト化して共有することで、透明性を高め、認識のズレを未然に防ぐことができます。
例えば、 実装過程で行っていることをリアルタイムでSlackに「〇〇の調査・実装」といった形でスレッドにログを記載するようにしていました。
アドテク部署の担当者が時間が空いたときに見てくださり、困っている時は早い段階でサポートを受けることができ、認識のズレも防ぐことができました。
このような「オーバーコミュニケーション」は、最初は面倒に感じるかもしれませんが、後々の手戻りを防ぐために非常に効果的でした。
Part 3: 「技術・知識の壁」を越えるアプローチ
アプローチ6： AIを自分専用の学習・開発パートナーにする
未知の技術スタックの学習にも、AIは強力なパートナーでした。
EOL対応の調査では、NotebookLMに公式ドキュメントを読み込ませ、非互換の情報を対話形式で効率的にリストアップしつつ、非互換対応を進めました。
Go言語のコーディングでは下記のような GitHub Copilot のカスタム指示への取り込みにより生成されるコードの質を高めることを実践しています。
- アドテク部署でのガイドラインを Markdown 化し取り込み
- 「Effective Go」を gemini で Markdown に要約し取り込み
また、MCPサーバを活用し、最新の情報での開発も行うようにしています。
以下は Terraform MCPサーバを Copilot Agent で活用した例です。
AI Agent は往々にして古い情報を元にすることが多いのですが、こういった手法で最新の情報を参照してくれ、キャッチアップもできるため非常に役立っています。
（プロンプトではディレクトリ名をtypoしていましたがそこも対応してくれています、Copilot賢い。）
こういったAIの活用により、我々は新しい技術スタックへの理解を深め、開発速度や質を向上させるようにしています。
ただ、未経験の分野ではAIの回答の真偽を見極めることが難しい場合もあり、この部分は今後の課題と感じています。
アプローチ7： 小さな検証を積み重ね、引き出しを増やす
いきなり本番環境の大きな改善に挑むのではなく、まずは小さな検証を繰り返すことを徹底しました。
新しいライブラリの動作確認、リアーキテクチャの概念実証（PoC）…。
この地道な積み重ねが技術的な知見となり、提案の選択肢を増やし見積もりの精度を高めてくれます。
また、その結果をドキュメント化し知見として残すことも重要です。チームや開発組織全体のナレッジとして活かすことができます。
以下はそういったドキュメントの一例です。
「越境」した結果と今後
我々はこれらのアプローチを駆使し、他部署のシステム改善に取り組んできました。 もちろん、最初は壁にぶつかることも多く、思うように進まないこともありました。
そのような中でも、これらのアプローチを続けた結果、下記のような成果を挙げることができています。越境先の部署からは感謝の声もいただき、自分たちの取り組みが少しずつではありますが、他部署のシステム改善に寄与できている実感を得ています。
- MySQL EOL対応による脆弱性の解消・コスト削減
- サーバOS EOL対応による脆弱性の解消とそれに伴う改善実施による運用負荷の軽減
- Terraform 未導入プロジェクトへの導入による IaC 化の推進、CI/CD の整備
- Terraform のバージョンアップおよび drift 対応・ drift チェック追加による IaC の運用負荷軽減・品質向上
この取り組みは今後も続けていきます。引き続き今回のアプローチ・AI技術の活用を推し進めて越境改善をレベルアップしていきたいと考えています。
おわりに
他部署のシステムに改めて深く踏み込むことは、我々にとって大きな一歩でした。
この「越境」を通じて得た経験と知識は我々自身の成長に繋がり、そして何より会社のサービスに貢献できたという確かな手応えとなっています。
他部署との連携には、困難がつきものです。しかし、その厚い壁の向こうには、システムと組織をより良くする大きなチャンスが眠っています。
この記事で紹介した7つのアプローチが、同じように奮闘する皆さんの「はじめの一歩」に、少しでも繋がれば幸いです。
Appendix: 他部署システム改善「越境」チェックシート
この記事でご紹介した7つのアプローチを、明日からの業務で活用できるチェックシートにまとめました。他部署や初めて触るシステム改善に挑む際、ぜひご活用ください。
□ Part 1: 「仕様の壁」を壊すためのチェックリスト
アプローチ1: 現物とAIで全体像を掴む
- [ ]
psやnetstat、lsof、tcpdumpなどのコマンドでサーバ上のプロセスや通信を調査したか？ - [ ]
crontabや監視ツールの設定から、定時実行ジョブやシステムの期待状態を把握したか？ - [ ] 上記以外の定点で観測できないシステムの状態は把握できているか？(例：プロキシサーバの通信元)
- [ ] アプリケーションログを読み、実際の挙動やエラーの傾向を掴んだか？
- [ ] AI（Copilotなど）を活用して、不明なソースコードの読解を効率化したか？
- [ ]
アプローチ2: "分からなさ"を図で整理・共有する
- [ ] 調査で判明したシステム構成やデータフローを、図として可視化したか？
- [ ] 作成した図を、チームや他部署との認識合わせの「共通言語」として活用したか？
アプローチ3: 関係者を巻き込み、対話で理解を深める
- [ ] システムの仕様について、最も詳しい技術担当者にヒアリングの時間をもらったか？
- [ ] 技術的な背景だけでなく、ビジネス担当者にもシステムの目的や要件を確認したか？
□ Part 2: 「文化の壁」を溶かすためのチェックリスト
アプローチ4: 期待値を最初にすり合わせる
- [ ] 相手チームの開発ガイドラインや文化（レビュー作法など）を事前に確認したか？
- [ ] 仕事の進め方（PRの粒度、レビューのタイミング等）について、作業開始前に合意形成したか？
- [ ] 定期的に相談・進捗共有を行うミーティングを設定したか？
アプローチ5: "オーバーコミュニケーション"を実践する
- [ ] 考えていること、試していること、困っていることをチャットツール等で積極的に発信したか？
- [ ] 議論の透明性を高め、認識のズレを未然に防ぐ工夫をしたか？
□ Part 3: 「技術・知識の壁」を越えるためのチェックリスト
アプローチ6: AIを学習・開発パートナーにする
- [ ] 未知の技術やライブラリについて、AIに質問・要約させて効率的に学習したか？ (例: NotebookLMに公式ドキュメントを読ませる)
- [ ] チームのコーディング規約や設計思想をAIのカスタム指示に設定し、生成コードの質を高めたか？
- [ ] MCPサーバなど、AIを活用した開発環境の整備を検討したか？
アプローチ7: 小さな検証を積み重ねる
- [ ] 新しい技術やアーキテクチャを導入する前に、小規模な検証（PoC）でリスクや効果を測定したか？
- [ ] 検証で得た知見をチームの資産としてドキュメント化し、知見を蓄積したか？
