エンジニア28年選手「今が一番面白い」　—AI Nativeな組織に賭けた話

はじめまして。2026年にブリングアウトに入社した、松木 宏人です。
エンジニアとして、Amazonやマネーフォワードにいました。アクセンチュアにいたこともあれば、8人のスタートアップにCTOとして参画したこともありました。
そして今年、AI Nativeな開発カルチャーを持つスタートアップに飛び込んでみたら、大変だけど面白い。28年のエンジニア人生、今が一番面白いかもしれない。
ということで、AI Nativeな開発カルチャーを持つチームに入るとどうなるかを、AIを前提とした組織に挑戦したい方向けに書いてみようと思います。

「仕組みをつくる」という問いとの出会い

エンジニアとして28年やってきて、キャリアを通じて追いかけてきた問いがあります。

「スケールする仕組みを作るとは、どういうことか。」

特定のチームや機能を改善するだけじゃなく、会社全体に効いてくるような仕組みを設計して、動かして、定着させる。それが自分のやりたいことだ、と気づいたのはAmazonにいた頃でした。
最初の2年はIntegration Managerとして、約100社の出品者をAmazonのプラットフォームに繋ぐ仕事。その後はSoftware Development Engineerとして、LINE連携システム、家電リサイクルサービス、SP-APIの開発者向けWebサイトのリプレースなど、10件以上のプロジェクトに携わりました。
そのなかで、繰り返し体感した言葉があります。

一人ひとりは本気でいい仕事をしようとしている。でも仕組みがなければ、その善意は個人の中で完結して終わる。この実感が、自分の中でずっと問いになり続けました。
そう感じるようになったのは、Amazonでの経験があったからだと思っています。Amazonは、世界中から多様なバックグラウンドを持つ人が集まる環境です。文化も言語も仕事のスタイルも違う。だからこそ、「この人がいるから大丈夫」という属人的な状態は、組織の弱点になる。人に依存しない仕組みを作り、それを標準化して回す——そのことの重要性を、Amazonという環境が教えてくれました。

仕組みが「回った」経験

その後、AIスタートアップでCTOとして8人のチームをリードし、ゼロからサービスをローンチしました。
AWSは環境・サービスごとに適切に分離し、20以上のアカウントで構成されるマルチアカウント基盤を設計。インフラはすべてCDK(IaC)で構築・管理し、30を超えるCI/CDパイプラインを整備しました。エンジニアがソースコードをマージすれば、各ステージでBuild・Unit Test・Integration Test・E2Eテストが自動実行され、そのまま本番環境へデプロイされる — 人の判断や手作業を一切挟まない、完全自動化の仕組みです。

その結果、本番デプロイは1日10回以上という高頻度リリースを実現。これだけの規模とスピードでもIaC化されているため、管理・運用コストは最小限に抑えられています。
こうした仕組みは単なる効率化の話ではなく、開発者の心理的安全性を確保するためにこそ不可欠だと実感しました。テストと自動化が信頼できる土台としてあるからこそ、エンジニアは躊躇なくマージし、恐れずに変更を加えられる。結果としてリリース頻度が上がり、開発効率も最大化される —「人に依存しない仕組みを作る」という思想を、組織とプロダクションの両面で体現した実践でした。
小さなチームだからこそ、仕組みを作るとすぐに使われる。使われると結果が出る。結果が出ると次の仕組みを作りたくなる — その循環を、初めてちゃんと回せた時期でした。

ボトムアップ組織の壁

その後、MoneyForwardにStaff Software Engineerとして入社しました。CTO Office所属で、開発者生産性の測定基盤を構築する仕事です。DX Core4のPoCをリードし、GitやJiraなど複数ツールのデータを統合してリアルタイムで可視化する環境を作りました。技術的には、やれた。

でも、その先に自分なりの壁がありました。

測定基盤を作ることが目的だったわけじゃない。やりたかったのは、それを使って組織全体を変えることでした。計測できるようになった。では次に、その数字で全社標準の開発プロセスを動かせるか — ここで、詰まりました。
規模が大きく成熟した組織では、現場の自律性を重んじるカルチャーが根付いていることが多いです。各チームが自分たちの判断で動ける分、スピードが出るし、現場のリアルな課題に即した意思決定ができる。それ自体は組織の大きな強みです。ただ一方で、全社標準のような取り組みをトップダウンで推進するのが、構造的に難しくなることがある。歴史的にも、組織的にも、文化的にも。

「仕組みを作りたいのに、組織の構造がそれを阻んでいる」

この課題感はエンジニアなら一度は感じたことがあるんじゃないかと思っています。善意のある人たちが、善意のまま動いていて、でも全体としては変わらない。個人が頑張れば頑張るほど、組織の構造との摩擦が見えてくる。
Amazonで学んだはずの「good intentions don't work, mechanisms do（善意では、組織は動かない。仕組みを作らないと、何も変わらない。）」が、皮肉にも自分自身に刺さった時期でした。

転機 — AI Nativeという言葉との出会い

そのタイミングで、Amazon時代の元上司からメッセージが来ました。MoneyForwardでも一緒に働いていた、Teppanさんです。ブリングアウトに転職し、「興味ないか」と。

信頼している人が「いい」と思って動いている会社なら、まず話を聞く価値はある。カジュアル面談を受けるには、それだけで十分でした。

HPや動画、記事をひと通り確認して、最初に感じたのは「AI Nativeな会社だ」という印象でした。
ただ、最初はそのワードの意味を正確には掴めていませんでした。AIを使っているスタートアップは今や珍しくない。「AI Native」と「AIを使っている」は、何が違うのか。

実際に話し始めて、わかりました。
「AIを使っている」会社は、会議の議事録をAIで作る、コードレビューをAIに補助させるなど、既存の仕事の一部をAIに置き換えています。一方で、「AI Native」な会社は、仕事の設計からAIを前提にしています。何をどう蓄積するか、誰が何を判断するか——その構造ごとAIに合わせて作られている。

ブリングアウトでは、社内会議もクライアントとの会話も、全てAI-Readyな状態で構造化・蓄積されています。それをもとにAIが課題を見つけて改善案を出したり、メンバーを称賛する仕組みが実装されている。社内でユースケースを作って顧客に持っていくという動きも、自然に生まれています。

つまりAI Nativeとは、サービスの話だけじゃない。組織の動き方そのものがAIを前提に設計されているということです。 そしてこの設計のもとでは、「仕組みを作る、そして使われる」という循環が回ります。AIスタートアップのCTOを務めていた時に感じた手応えが、もっと大きなスケールで動いていったのです。

今が一番面白い、その理由

私のキャリアがスタートした1997年、AIが業務の意思決定を変えるという絵は描けませんでした。ただ、それから28年かけて積み上げてきたものが、今この瞬間、AI Nativeという文脈で全部繋がる感覚があります。

エンジニアとして「スケールする仕組みをつくる」という問いを持ち続けてきた人間にとって、AIが本当に使える道具になった今のタイミングは、正直、来すぎなくらいいいタイミングだと思っています。
10年前にこの選択はできなかった。技術環境が違うし、AIがここまで実用的じゃなかった。でも今なら、できる。

そして何より面白いのは、答えが決まっていないことです。今のフェーズだからこそ、現場やチームの状況に合わせて自由に設計できる。誰かが作った仕組みをただ使うのではなく、自分たちで作り、自分たちで回す。その試行錯誤ができる環境にいるのです。

もし同じような問いを持っているエンジニアがいたら、今がそのタイミングかもしれません。

ブリングアウトに興味を持ってくださった方へ

ブリングアウトはビジネス／開発側の採用を積極的に行っています。
まずはカジュアル面談からぜひお話ししてみませんか？