はじめに：レガシー環境を前に、立ちすくまないために「このシステム、誰がどう作ったのか分からない」「仕様書はない。でも、止めることも変えることもできない」そんな状況に直面したことのある情シスや現場マネージャーの方も多いのではないでしょうか。私もまさに、他社が作ったレガシーシステムの引き継ぎを担当する中で、何度もその壁にぶつかってきました。私はエンジニアではありません。コードを書くことはできません。ですが、内製化を進めるための“環境づくり”や“会話の土台づくり”には、私のようなディレクターだからこそ担える役割があると感じています。この記事では、現場で属人化と向き合いながら取り組んできた「非エンジニアの内製化支援」について、実体験を交えてお話ししたいと思います。レガシー環境を変えずに、変えられたこと私が担当した案件の多くは、すでに稼働している業務システムの保守・運用が中心でした。コードは複雑化し、担当エンジニアも退職済み。ドキュメントはあっても現状と乖離している──そんな状況からのスタートです。ですが、いきなりコードに手を加えなくても、以下のような変化を起こすことは可能でした。業務フローや役割分担の「暗黙知」を、図やドキュメントにして“見える化”SlackやNotionを活用し、質問やナレッジの蓄積を仕組み化開発者と利用者の間に立ち、「なぜそうしているか」「なぜ困っているか」を翻訳属人的な対応が発生しそうな場面で、意図を確認しながら巻き取りを提案結果として、「特定の人しかできない」が減り、「誰でもできる」に近づいていく。それが、内製化の第一歩だったと感じています。ディレクターは“翻訳者”であり、“土台づくり”の設計者私自身は技術者ではありませんが、エンジニアと会話し、理解し、仕様や制約を整理することはできます。また、非エンジニアのクライアント側メンバーとも会話し、「何に困っているか」「なぜ手が出せないのか」を丁寧に言語化することもできます。この両者をつなぐこと。つまり、現場の“翻訳者”として機能することが、ディレクターとしての最大の価値だと考えています。そして、ドキュメントやナレッジの共有環境整備は、その翻訳結果を“現場に残す”仕組みづくりです。これが属人化を防ぎ、再現性ある運用体制につながっていくのです。技術がわからなくても、内製化は支援できる「内製化」と聞くと、どうしても“技術者の話”と捉えられがちです。でも実際には、「エンジニアが働きやすい環境を整えること」「チームが属人化しないように整理すること」も、大きな内製化支援の一部です。「分かる人にしかできない」を減らす「質問しやすい空気」をつくる「自分のやっていることを言語化してもらう」場を用意するこうした小さな土台づくりの積み重ねが、結果として、組織に再現性をもたらし、外注ではなくチーム内で解決できる力につながるのだと思います。おわりに：コードを書かなくても、できることはある私は、コードを書かない立場で現場に関わってきました。ですが、その分、エンジニアとは違う視点で「気づくこと」「できること」があると信じています。もしあなたが、レガシー環境に悩み、属人化に頭を抱えているなら、まずは“翻訳”から始めてみてください。今いる人、今ある環境のままでも、きっと変えられることがあります。