この春からチームを異動した。
2022年の入社以来、約4年間ずっと担当していたシステムから離れることになった。前チームでは新規システムの構築も自分が主導したため、システムの仕様やドメイン知識については誰よりも深く理解しており、「無双に近い状態」で業務をこなしていた。そのため、当時の個人的な課題は「後任の育成」や「他チームとの連携による総合力の最大化」といったフェーズへとシフトしていた。
そんな中、今回の異動により、別チームでまったく新しいシステムを担当することになった。ちなみに異動の理由は会社都合であり、自分から希望したわけではない（ただ、事前のヒアリングで「興味がある分野だ」と答えてはいた）。
新しい環境になったことで、システムへの理解度はゼロになり、メンバーも変わったため積み上げてきた信頼も一度リセット。まさに「ゼロからの再出発」となった（ただし、転職と比べればリセット率は低いが）。
現在、新たな環境で絶賛奮闘中であるが、自分なりの「キャッチアップのノウハウ」をいくつか書き残しておこうと思う。
リセットされるものと残るもの
このような異動や転職においては、完全にリセットされてしまうものと、環境が変わっても手元に残るものがある。
リセットされるもの①：システム知識
まず、完全にリセットされてしまうのが「システム知識」である。
前述の通り、以前のシステムはほぼ完全に掌握していたため、あらゆる業務を短時間で処理できた。問い合わせ対応ひとつとっても、大半のパターンは経験済みのため調べるまでもなく回答できたし、その場で分からなくても「どこをどう調べれば答えに辿り着くか」の型が見えていた。機能追加にしても、要求仕様を聞いた時点で実装方法が脳内に浮かび、「これなら1週間あれば対応できるな」といった見積もりが即座に可能だった（もちろん、ときには頭を悩ませるパターンもあったが）。
しかし、環境が変わればこれが全く通用しなくなる。
問い合わせを受けても、そもそも「何を聞かれているのか」が分からない状態からのスタートになる。まずは有識者に質問の意図を尋ね、調査の方針を示してもらう。そこから自力で調査を進めるわけだが、コードの意図が掴めなかったり、歴史的経緯が理解できなかったりと、いくつものハードルにぶつかる。どうにか「おそらくこうだろう」という自分なりの結論に辿り着いた後、再び有識者に「こう判断したのですが、認識は合っていますか？」と確認を取り、ようやく回答に至る。
ここで心苦しいのは、有識者に確認を取っている時点で、相手にも同じ調査（ただし自分より遥かに効率的ではあるが）を強いてしまっている点だ。この段階では、チームの業務負荷軽減に貢献できているとは言い難い。
機能追加も同様である。そもそもの既存機能を知ることから始めなければならない。ソースコードを読み解いて設計思想を理解し、「ここに新機能を組み込もう」と目星をつける。しかし、そのままでは綺麗にはめ込めず、事前リファクタリングが必要なことに後から気がつく。当初出した見積もりを修正させてもらうか、それが許容されなければ死ぬ気でカバーすることになる。
リセットされるもの②：信頼貯金
そして、もうひとつリセットされてしまうのが「信頼貯金」である。これも地味に痛い。
以前のチームでは、日々の業務を通じてコツコツと積み上げてきた信頼があった。「彼なら上手くやってくれるだろう」という周囲の安心感があれば、多くのプロセスをショートカットでき、あらゆる業務のスピードが上がる。
例えば、何か新しい提案をしてプレゼンをするとき、資料の完成度がそれほど高くなく、説明が多少たどたどしくても、「ああ、そういうことがやりたいのね」と意図を汲み取ってもらいやすい（ただ、これは単なる信頼だけでなく、お互いの思考の癖――『この人はここを気にするよね』など――を理解しているからでもある）。結果として、「いいんじゃない、やってみたら？」とスムーズにGoサインが出やすい。
しかし、信頼貯金がない状態では、同じプレゼンをしても「説明のたどたどしさ」がそのまま「本人の未熟さ」として受け取られてしまう。その結果、意見を通すまでに多くの時間を要することになる。
ただ、どちらかというとこれは「信頼がないから余計に時間がかかる」というよりは、「本来ならそれだけステップを踏むべき物事が、信頼貯金があることである程度ショートカットできていた」と捉えるべきなのだろうとは思う。
残るもの：経験から得た「判断基準」
では、すべてが失われるのかというと、決してそんなことはない。やはり「経験」は確実に残る。
その対象は多岐にわたる。プロジェクトが上手く回っていたときの成功体験も、泥沼化して苦労した経験も、チームが変わり扱うシステムが変わったところで消えはしない。それらはすべて、新しい環境で物事を進めるための強力なベース（判断基準）になる。
例えば、新しいチームで業務を進める中で、何かしらの「やりにくさ」や「辛さ」を感じたとする。
過去の経験という比較対象があるからこそ、その違和感を放置せず、客観的に分析することが可能になる。「以前の環境ではこのプロセスで苦労しなかった。では、当時と今とでは何が違うのか？」と問いを立てられるのだ。
- 当時の手法を、そのまま今の現場に適用できるか？
- それとも、現在のチーム固有の事情があり、そのままでは適用できないのか？
こうした分析を走らせたとき、全く同じ形とはいかないまでも、過去の知見の多くは今の現場にも応用が利く。つまり、新しいシステムを前にして知識はゼロであっても、「課題の解決策をはじめから知っている」というケースがあったりする。
ただし、注意する点があり、
いくら過去の経験から導き出した「正論」であっても、新参者がそれを立て続けにぶち上げるだけでは、既存のチームメンバーには受け入れられない。事情を知らずにただ正論を振りかざしても、反発を招くだけになる。
だからこそ、手法の導入は少しずつ、慎重に行わなければならない。
まずは現在のチームの対話に耳を傾け、現在のやり方に至った過去の歴史や経緯をしっかりとヒアリングする。その上で、メンバーの心情に寄り添いながら、全員で新しい方向へ向かえるように関係性を調整していく。
リセットされてしまったものを取り戻す
システム知識のキャッチアップ
では、リセットされた「システム知識」をどのように最速で取り戻していくか。現在進行形で実践しているアプローチを整理する。
1. 待たずに、自分から動いて疑問を解消する
最低限のオンボーディング（受け入れ研修やドキュメント読み込み）が終わったら、あとは自分で疑問点を見つけて能動的に聞きに行く。
「忙しいメンバーの時間を奪うのは申し訳ない」という心理的ハードルは誰しも感じるものだ。しかし、自分が投げかけた質問をきっかけに、既存メンバーの間でも「実はそこ、曖昧だったんだよね」と再確認の場になることも少なくない（そう自分に言い聞かせるだけで、ずいぶんと質問しやすくなる）。
逆の立場で考えれば、自分が知っている領域を他人に説明するのは、案外悪い気がしないものである。だからこそ遠慮しすぎず、ただし時間を割いて対応してくれる相手への感謝の気持ちだけは、とにかく全力で伝えるようにしている。
2. AIを壁打ち相手にする
有識者の時間を無限に奪うわけにはいかないため、ドキュメントの読み込みやコードの壁打ちには積極的にAIを活用する。
まずはシステム全体のアーキテクチャやドメインの全体像をAIと共に掴み、大枠のロードマップを頭に叩き込む。その上で、実際の業務（タスク）をこなしながら、周辺の細かい仕様をディテールへと落とし込んでいく。
当然、新しい知識はすぐに忘れるし、ときには誤解したまま覚えてしまうこともある。しばらくの間は、自分の理解をこまめに有識者と答え合わせし、知識の解像度と精度を一歩ずつ上げていくプロセスが不可欠だ。
3. 「アラート周り」をハブにして理解を深める
新環境でのドメイン理解を効率化するハックとして、「アラート（エラー通知）周り」をキーにしてシステムを紐解くアプローチは非常に有効だと感じている。
アラートが設定されている場所＝「過去に問題が起きた場所」であり、「運用上の急所」である場合が多い。
問題が発生しやすいクリティカルな部分から優先的にコードや仕様を理解していくことで、メリハリのある、かつ実戦に即したキャッチアップが可能になる。
信頼を再度獲得する
信頼とは一朝一夕では得られない。
小さな約束や期待を裏切らずコツコツと積み重ねたり、皆が苦しんでいる時に一緒に苦しんだり、皆が喜んでいる時に一緒に喜んだりして、いつの間にか得られているものである。
しかし、システム知識がゼロの最初期においては、信頼の基盤となる技術的貢献がそもそも難しい。
そのため、まずは誰にでもできる「雑務」や「オペレーション」から自分の役割を見つけてしていく。
例えば、会議のファシリテーターを買って出る、ミーティングの場をセッティングする、議事録を率先して引き受ける、といったことだ。自分はまだ技術的な貢献は難しくても、こういった雑務を引き受けることによって、ドメイン知識を持つ有識者たちが彼らにしかできないコア業務に集中できるようになる。これこそが、初期段階においては立派なチーム貢献（価値）となる。
また、このアプローチはチームのためだけでなく、「自分の精神衛生を守る」という意味でも極めて有効である。
最初期はどうしてもチームメンバーに負担をかけてしまう。それは仕方のない過程だと割り切りつつも、貢献のない状態がある程度続くと、どうしても自分の存在価値に疑問を感じるようになり、大きなストレスを抱え込んでしまう。
どんなに小さなことでも「自分が役に立てる場所」を見つけることで、自分で自分を認められるようになり、しっかりと今やるべきことにフォーカスできるようになる。
ミドルエイジ特有の「高い期待値」という壁に対応する
基本的にはここまで述立ててきたアプローチを徹底すればよいのだが、ある程度の年齢やグレード（レイヤー）に達している場合、それだけでは足りない。なぜなら、周囲からの初期期待値が高いからだ。
マネジメント層からはもちろん、現場のメンバーからも「それなりの給与をもらっているのだから、さぞ有能なのだろう」という無言のプレッシャー（期待の目）を背負うことになる。
とはいえ、どれほど経験があろうとも、新しい環境に放り込まれた直後は「何も分からない」からのスタートである事実に変わりはない。ここに、自己の現実と周囲の期待との強烈なギャップが生じ、苦しむことになる。
もちろん周囲も鬼ではないため、最初の1ヶ月ほどはオンボーディング期間として温かく見守ってくれる。
しかし、2ヶ月、3ヶ月と経ってもなお「まだ色々と教わっている最中でして……」というスタンスのままだと、次第に厳しい目で見られ始める。
現実問題として、その短期間で大規模なシステムのすべてを把握することは不可能に近い。だが、ミドルエイジたるもの、その限られた「分かる範囲」の中で、何かしらそれなりの成果（プレゼンス）を示していく必要がある。
では、知識ゼロの状態から最速で成果を出すにはどうすればよいか。
その突破口として有効なのが、「ドメイン知識（深いシステム知識）がなくても手を出せる業務改善」である。
システムそのもののリファクタリングや機能改善には、膨大かつ詳細な知識が必要となるため、初期段階では手が出せない。しかし、チームが日々行っている「業務プロセス」や「定型業務」の非効率さについては、システムの中身を深く知らなくとも、これまでの他社経験や汎用的なスキルだけで違和感に気づき、より良いやり方を見出せることが多い。
（こうした業務改善の余地が残っているのは「達成難易度が極めて高いから」というわけでもなく、往々にして、改善のために周囲を巻き込む「パワー」や「時間」を割く余裕が、日々の運用に追われて捻出されていないだけなケースが多かったりする）
チームから仕様を教えてもらう一方で、自分からはこうした業務プロセスの負債を回収していく。この「ギブ＆テイク」を成立させることで、周囲の期待に応えてバリューを示しつつ、本当のシステム知識をじっくり身につけるための「猶予期間（打席に立ち続ける権利）」を自ら勝ち取るのだ。
ただし、この業務改善を推進する際にも、やり方には細心の注意を払わなければならない。
ここでも「積み上がっている信頼貯金の量」が成否を分ける。まだ信頼が十分にない状態で「ここ、非効率なので変えましょう」と正論を指摘しても、既存メンバーからは感情的に受け入れられにくい。
また、一見非効率に見えるプロセスも、自分がまだ知らない「過去の痛烈な失敗」や「外せない大人の事情」があってその形に落ち着いている可能性も十分にある。
だからこそ、ここでも自分の意見を強行するのではなく、まずは全員の意見や歴史的な事情をしっかりとヒアリングして理解する。その上で、「このアプローチに変えれば、皆の負担がこれだけ減る」というメリットを丁寧に共有し、合意形成をしながら進めるのが、ミドルエイジに求められる成熟した進め方である。
キャッチアップ時に襲われる「不安」とどう向き合うか
新しい環境での立ち上げ期、特にミドルレイヤー以上の人間を最も苦しめるのは、技術的な難しさそのものよりも、内面から湧き上がる「自分はもらっている年収分の価値を、いま出せているだろうか？」という強い不安（焦燥感）である。
結論から言えば、最初期に一時的なビハインドを負ってしまうのは仕方のないことだ。扱うシステムは決して簡単ではなく、相応の複雑さや歴史があるのだから、すぐにトップスピードで走れるわけがない。
また、これまでのキャリアで培ってきた汎用的なスキルやマインドなど、「経験から滲み出る価値」も確実に提供できているはずである。しかし、厄介なのは「その価値が、評価者や周囲にまで表面化（可視化）するにはどうしても時間がかかる」という点だ。
自分の中では価値を出している実感が（たとえ雑務や業務改善であっても）あったとしても、特に自分と少し距離のあるマネジメント層や他チームから見たときに、それが正しく見えているかどうか別問題である。
だからこそ、中盤以降は「自分の価値を、分かりやすくパッケージにして外に見せていく工夫」が必要になってくる。
「自分がチームに加わったことで、何がどう良くなったのか」
これを独りよがりな自慢ではなく、客観的な事実やチームの生産性向上という形（パッケージ）にして、意識的にアピールしていく。例えば、先述した業務改善の成果をドキュメント化して共有したり、仕組みとして定着した実績を定例会で報告する、といった行動だ。
最後は、自分を信じる力に尽きる。
焦って一発逆転の大技を狙うのではなく、チーム内で「少しずつ、難易度の高い仕事」へとステップバイステップで挑戦を続けてしていくこと。その打席を愚直に踏み続けていれば、いずれ必ず周囲のドメイン理解に追いつき、活躍できる日がやってくる。
