技術選定の基準は「今の現場にフィットするか」「これからの担い手に広がるか」
すべてを標準化するのは現実的ではないため、松尾氏のチームはゴールデンパスが担保する範囲の分界点を決めることにした。背景にあったのは、閉域環境が払い出されてからアプリがネットワーク疎通するまでに、長いケースでは1カ月ほどかかっていたという課題だ。
さまざまな申請が疎通確認のボトルネックになっていたため、ゴールデンパスは疎通確認がスムーズに完了するところまでを担保する範囲とし、案件固有の要件を踏まえた最小限のアプリテンプレートを配布する形にした。
IaCツールの選定では、現場の経験と標準として選んだ技術スタックの間にギャップがあった。チームが選定したのはAWS CDKだ。CDKはTypeScriptで記述できるため静的型付けにより人もAIも安全にインフラを定義でき、よく使う構成をクラスとして抽象化して再利用可能な部品にできる。標準構成をバージョン管理しながら各案件に展開しやすい点も評価した。
一方で、当時の現場エンジニアにはTerraform経験者の方が多かった。松尾氏は、技術選定においては技術そのものの優劣よりも、導入先との親和性と将来的な広がりを重視すべきだと考えた。Wiz Base自体の構築・運用にもCDKが使われており、その上で動くアプリもCDKであれば運用とガバナンスを揃えやすい。
加えて、社内では2021年からCloudFormationの研修、2024年からはCDKの研修が実施されており、多くの社員エンジニアにすでにCDKの素地があったことも選定理由に加わった。「技術の優劣ではなく、今の現場にフィットするか、これからの担い手に広がっていくかで選んだ」と松尾氏は選定の軸を説明する。
「自分たちで作る標準」から「現場と一緒に育てる標準」へ
標準として選んだ技術を現場に届く形にする段階でも、摩擦は残っていた。Terraform経験者にとっては、CloudFormation特有の挙動、とりわけデプロイ失敗時にロールバックによって長時間実行になりやすい点が開発体験を損ねていた。
松尾氏は現場エンジニアとの直接対話でこうしたつまずきを拾い上げ、いきなり大規模な展開を求めるのではなく、まずはサンプルアプリで小さくデプロイを成功させることから始めるよう案内した。IaCの構想の違いやCDKのTipsをドキュメント化し、共有会も開催している。「方針を決めただけでは使われない。移行の節目に伴走することで、初めて現場に届く」というのが、この過程で得た学びだった。
少人数でゴールデンパスを拡げ続けるのには限界があるため、松尾氏のチームは現場の内製開発を担うパートナー2社を拡張に巻き込んだ。A社にはアプリテンプレートの拡張を、B社にはガードレールの整備を依頼し、ゴールデンパスは「自分たちで作る標準」から「現場と一緒に育てる標準」へと変わっていく。
もっとも、すべての物事が思うように進むわけではない。パートナーは現場の案件開発と兼務のため拡張に割ける時間が限られ、松尾氏らもゴールデンパスの価値を関係者に十分に伝えきれていなかったことで、現場の案件が優先され拡張の優先度が下がることが繰り返された。開発上のトラブル対応もあり、計画は後ろ倒しになっていく。
そこで松尾氏らは、動くものを見せて議論する文化を活かし、部内向けデモンストレーションの予約を入れることで優先度を引き上げた。パートナーとは進め方やスコープをあらためて一緒に見直し、並走する体制を作り直している。ガードレール設計では、現場で何がNGになりやすいかという肌感覚を持つメンバーの参画によって、みずほ銀行のチェックリストに基づく議論が一気にスムーズになった。
