レッドハットは、世界をリードするオープンソース・ソリューション・プロバイダー。アメリカに本社を構え、40カ国以上でRed Hat Enterprise Linux、ハイブリッドクラウド・インフラストラクチャ、ミドルウェア、アジャイル・インテグレーション、クラウドネイティブ・アプリケーション開発、運用管理および自動化などのソリューションを提供しています。

レッドハットコンサルティングサービスは、Red Hat製品に関する深い専門知識と、ベストプラクティスを提供しています。お客様が直面する複雑な技術課題を解決し、ROI（投資対効果）の最大化とリスクの最小化を実現するために、戦略策定から設計・運用まで一貫して伴走し、支援します。

今回登場するのは、Agile Development Coach（アジャイル デベロップメント コーチ）として活躍するKazutaka.Sさん。「AI駆動開発」「ソフトウェアエンジニアリング」「アジャイル」を武器にお客様の変革支援に挑む彼に、日々の業務やRed Hatの温かいカルチャーまで、詳しく話を伺いました。

＜プロフィール＞
Kazutaka.S
Agile Development Coach

国内大手ITベンダーでの公共インフラSE、大手通信キャリアでのアジャイル普及推進、さらにグローバル飲料メーカーでの内製化エンジニアを経験し、Red Hatへ入社。

Red Hat入社後は、Agile Development Coachとしてお客様の開発組織に入り込み、開発アジリティやビジネスアジリティの向上に向けて伴走する役割を担っている。

趣味は海外旅行、けん玉、キャンプ、サウナなど。
過去10年間で19カ国訪問し、1年でパリに3回も訪問したことがあるほどの海外旅行好き。社内では「Red Hatサウナ部」を立ち上げ、泊まりでの遠征や有志でのキャンプなど、休日も仲間とアクティブに過ごしている。

── 最初に、Red Hatへ入社した理由を教えてください。
きっかけはリクルーターの方からのお声がけでした。

もともと私は、個人としての成果以上に「チームが継続的に価値を生み出せる状態をつくること」に強い関心があったんです。前職の事業会社での内製開発時代、良いプロダクトを作るには技術力だけでなく、学習する文化や開発プロセス、現場のプラクティスが極めて重要だと実感しました。その経験から、組織やチームの変化を支援する仕事に興味を持つようになりました。

── そんなタイミングで「Agile Development Coach」の打診があったのですね。
はい。ただ、実は当時、Red Hatにそのような役割があること自体を知らなかったんです（笑）。

でも詳しく話を聞いていくうちに、単にアジャイルの考え方を伝えるだけのコンサルティングではなく、エンタープライズのお客様の現場に深く入り込み、伴走しながらアジリティ向上にコミットする役割だと知りました。まさに、自分がこれまで関心を持ってきた「機能するチームや組織をつくること」と非常に近い仕事だと感じました。

── 数ある企業の中でも、なぜRed Hatだったのでしょうか？
Red Hatが世界最大のOSSプロバイダーであり、ソフトウェアエンジニアリングに対する圧倒的な知見と実践力を持っている点に強く惹かれたからです。

どれだけ組織やプロセスを綺麗に整えても、実際の開発現場で価値をデリバリーする力がなければ、最終的な成果（アウトカム）には繋がりません。その点、Red Hatなら「チーム・組織の変化」と「エンジニアリングの実践」の両面から、お客様に本質的な変化を起こすことができる。ここに他にはない大きな面白さを感じました。

また、これまでのキャリアを通じて一貫して大切にしてきた「ソフトウェア開発を通じてユーザーに価値を提供する」という信念ともマッチしたため入社を決めました。

単なる技術導入ではなく、お客様が実現したい「アウトカム（成果）」につなげる

── Agile Development Coachの役割と業務内容について教えてください。
業務内容は多岐にわたりますが、一言で言うと、お客様の開発組織に入り込み、開発アジリティやビジネスアジリティの向上に向けて伴走する役割です。

ただ、大事なのは単に技術的プラクティスを導入することではなく、お客様が実現したい「アウトカム（成果）」につながる取り組みにすること。そのため、まずはお客様が目指している姿や課題認識を丁寧にすり合わせるコミュニケーションを非常に重視しています。その上で、KPIツリーを設計したり、Value Stream Mappingを通じてボトルネックを可視化したりしながら、目指すアウトカムと現場で実行する打ち手をつなげていきます。

── 「現場で実行する打ち手」とは、具体的にどのようなアプローチになるのでしょうか？
例えばプロダクト開発のリードタイム短縮が目的の場合、一連のバリューストリームから課題を特定します。仮にコード修正の影響範囲の広さに原因があれば、設計やコードの構造、リファクタリングにまで踏み込みます。実際、モノリシックなアプリケーションを論理的に分離する「モジュラーモノリス」に取り組んだりもしています。

その中で、私自身が現場に入り込み、テスト戦略の策定、自動テストの実装、プロダクションコードのリファクタリングなどを実際に手を動かして行っています。プロセスや組織面の支援だけでなく、ソフトウェアエンジニアリングの実践を通じて現場の変化を支援する。ここが、この役割の大きな特徴であり面白さだと思っています。

── プロセスの変革だけでなく、技術的な実践まで一貫してサポートされているのですね。
はい。ただ、自分だけができる状態では組織にスケールしないため、チームメンバーに対するティーチングやコーチング、ナレッジトランスファーも重要な業務です。お客様のチームが自分たちで改善を継続できる状態、つまり「自走化」を強く意識しています。

また別のお客様では、開発チームの現状をアセスメントし、To-Be（あるべき姿）とAs-Is（現状）のギャップを整理した上で、ステークホルダーと改善に向けた方向性を協議するような活動も行っています。

── 現場での「AI駆動開発」の実践にも取り組まれていると伺いました。
LLMは非常に強力ですが、あくまで確率モデルなので出力の妥当性を常に検証する必要があります。昨今のツールには一定の品質を担保する機構がありますが、最終的な業務要件やコード品質は自分たちで担保しなければなりません。そのため、自動テスト、静的解析、Lintといったガードレールを整備し、それらをCI上で継続的に検査できるようにすることや、開発現場で活用できるSkillsやAgentの作成に取り組んでいます。

AI駆動開発のベストプラクティスをどう現場に実装するかは、お客様の組織やシステムのコンテキストによって大きく異なります。だからこそ、仮説を立て、小さく実験し、学習しながら適応していくアジャイルな進め方が重要だと感じています。

── 組織の変革から最先端のAI実装まで、まさに「Red Hatだからこそできる支援」ですね。
そうですね。「AI駆動開発」「ソフトウェアエンジニアリング」「アジャイル」という3つの武器によって、お客様の開発組織がより速く、より安全に価値を届けられるように、自ら手を動かしながら伴走する。それが、このロールの最大の面白さであり強みだと感じています。

「うちでAIの先生になってほしい」── 難関のレガシーモダナイゼーションで高評価をいただいた理由

── これまで経験した印象的な出来事があれば教えてください。
メーカーのお客様における、基幹システムのレガシーモダナイゼーションPoC（概念実証）が非常に印象に残っています。

もともとは開発チームの生産性向上に向けたアセスメントとして参画したのですが、プロジェクトが一区切りついたタイミングでお客様から「AI駆動開発を活用して、さらに開発生産性を高めたい」とご相談をいただき、本格的な支援が始まりました。

── 基幹システムという「絶対に失敗できない領域」で、あえて未踏のAI駆動開発に挑むのは、かなりのリスクや難しさがあったのではないでしょうか。
そうですね。特に大切にしていたのは、単にAIを使って開発を速くすることではなく、基幹システムとして求められる「品質」を守りながら、いかに開発サイクルを短縮できるかという点です。お客様からも品質を非常に重視しているとお話があったため、私たちはAIの出力をそのまま信用するのではなく、出力の妥当性を継続的に検証できる仕組みづくりを重視しました。

── 具体的には、どのような手順で「品質の担保」と「AIの活用」を両立させたのでしょうか？
まず、既存のレガシーシステムをコンテナ化してローカル環境で動作確認できる状態にしました。その上でドメインの理解を進めながら、現行システムの振る舞いを保証するための仕様テストをE2Eのテスティングフレームワークで実装したんです。いわば、AIの出力を検査するためのハーネスを先に整備しました。

次にレガシーシステムをリバースエンジニアリングして仕様を整理し、AIに与えるインプット情報とハーネスが揃った段階で、仮説と検証を繰り返しながら少しずつモダナイゼーションを進めていきました。

── 事前の緻密な設計が功を奏したのですね。実際の成果はいかがでしたか？
手動で行う場合と比較して、開発のサイクルタイムを大幅に削減できました。現行システムの振る舞いをE2Eの受け入れテストで継続的に確認しながら進めたため、同一性をきっちり担保できましたし、認知的複雑度やCode Smell（コードの不吉な臭い）の指摘件数といった内部品質の指標も、元のシステムより大きく改善させることができました。

お客様からも非常に高く評価していただき、他のプロジェクトへもこの知見を展開しようという動きに繋がっています。何より、お客様の部長の方から「うちでAIの先生になってほしい」と声をかけていただけたのは、個人的にも本当に嬉しかったですね。

── 技術的な成果はもちろん、お客様との信頼関係も深く築けたプロジェクトだったのですね。
はい。お客様のメンバーと長時間にわたって議論を重ねたり、AI駆動開発のモブプログラミングを一緒に行ったりしながら、非常に良い関係性を築くことができました。PoCは一区切りしましたが、これから本格的なレガシーモダナイゼーションが始まっていくので、この最高のチームと一緒に、引き続きお客様の期待に応える成果を出していきたいと考えています。

── お客様との素晴らしい信頼関係ですね。今回のプロジェクトがこれほどワンチームとして大成功した背景には、何か理由があったのでしょうか？
実は、このプロジェクトに繋がる前日譚があります。以前、年に一度開催されるRed Hatの全社グローバルイベントに参加するためにラスベガスへ出張した際、私が現地で高熱を出して寝込んでしまったんです。海外ということもあって本当に心細かったのですが、その時に一緒に日本から出張したメンバーや現地のグローバルチームの方たちが、信じられないほど手厚くサポートしてくれました。

── 海外出張先での高熱は不安になりますよね……。
ありがたいことに日本のメンバーは動けない私のために体温計や薬、食べ物などの物資をわざわざ買ってホテルの部屋まで届けてくれたんです。そして現地のグローバルチームは「とにかく体調が第一だから、しっかり休んで！必要なら帰国便を後日に変更していいし、ホテルの滞在も延長して構わないから」と声をかけてくれました。

── それは心に染みますね。その経験が今回のプロジェクトにも生きたのでしょうか。
はい。前述のレガシーモダナイゼーション案件でラスベガスで私を助けてくれた日本のメンバーと一緒になったのですが、スタート時点で「絶大な信頼関係」がデプロイ済みでした（笑）。

プロジェクトが始まってからも、終始「阿吽の呼吸」で仕事ができる最強のチームになれました。私たちがそれだけ固い一枚岩だったからこそ、お客様のメンバーとも深い信頼関係を築くことができ、最終的に高い評価をいただくことができたのだと思っています。

大きな裁量をもって実践できる楽しさ、それこそがRed Hatの大きな魅力

── それでは次に、Red Hatで働く上での魅力や特徴があれば教えてください。
大きく2つあると感じています。

1つ目は、お客様の伴走者として、非常に近い立場で課題解決に関われることです。私たちのメインミッションは、お客様の現場に入り込み、対話を重ねながら「何が本質的な課題なのか」「どのような状態を目指すべきなのか」を一緒に考えて実践していくことです。

その中で、自分自身に大きな裁量があるのも特徴です。お客様の状況を見ながら、自分が正しいと思えるTo-Be（あるべき姿）を描き、具体的なアクションに落とし込んで実践していくことができます。簡単ではありませんが、密にコミュニケーションを取りながら改善を進め、その結果として現場の状態が良くなったり、チームの動き方が変わったりした時には大きなやりがいを感じますね。

── なるほど。では、2つ目の魅力についても教えてください。
2つ目は、社内にさまざまな領域のプロフェッショナルがいることです。

Red Hatには、OpenShiftやAnsibleといった自社製品に強いメンバーはもちろん、AI、アジャイル、プラットフォームエンジニアリングなど、多様な専門性を持ったコンサルタントが揃っています。そうしたメンバーと日常的にコミュニケーションを取りながら、お客様への価値提供を考えられるのは非常に面白い環境です。

── 社内のプロフェッショナル同士でコラボレーションが生まれることもあるのでしょうか？
はい、まさに最近、AI駆動開発のチームとPlatform Engineeringのチームの間で新たなコラボレーションが生まれようとしています。AIだけ、アジャイルだけ、プラットフォームだけではなく、それぞれの専門性を組み合わせることで、より多角的にお客様の開発アジリティ向上に貢献できる。この掛け算の強さは、Red Hatならではのユニークな魅力だと思います。

── 一方で、プロフェッショナルが集まる環境だからこそ、大変な一面もありそうですね。
確かに、お客様からは常に高いプロフェッショナル性を期待されます。ソフトウェアエンジニアリングの知見はもちろん、AIをはじめとする最新の技術トレンド、アジャイルやDevOpsの実践知識など、常に学び続ける必要がありますね。

ただ、裏を返せばそこも大きな魅力なんです。日々自己研鑽を重ねて自分の専門性を高めながら、お客様の変化に本気で貢献したい。そう考える人にとっては、これ以上なくエキサイティングで面白い環境だと思います。

能動的に動く「自走力」を持った「いい人」を求めている理由とは？

── Agile Development Coachにはどのようなスキルや人物像が求められていると思いますか？
ここも大きく2つあると思っています。

1つ目は「自走力」です。Red Hatでは非常に大きな裁量を持って働くことができるため、自分で課題を見つけ、お客様や社内のメンバーと対話しながら自ら行動に移せる力が求められます。

指示されたことをこなすというよりは、「今どこに課題があり、何から着手すべきか」を能動的に考えて動くことが大切です。これまでに自組織やプロジェクト、あるいはお客様先を問わず、能動的に動いた経験がある方は間違いなくカルチャーフィットしやすいと思います。

── では、2つ目は何でしょうか？
2つ目は、ズバリ「いい人」であることです（笑）。
もう少し具体的に言うと、素直さ、傾聴力、そしてお客様へのリスペクトを持っていることです。

── 「いい人」という言葉の背景には、深い意味が込められているのですね。
はい。私たちの理想は、お客様とRed Hatが一枚岩となり、組織の境界を越えてワンチームで課題解決に向かっていくことです。そのためには、お客様のミッションや目指している姿に自ら飛び込んでいく素直さや、表面化していない悩みやインサイトを引き出す傾聴力が欠かせません。

そして何より大切なのが、お客様へのリスペクトです。外から入る立場として、既存の文化や仕組みを頭ごなしに否定してしまうと、ハレーションが生まれてしまいます。たとえ改善すべき点があったとしても、その背景にはお客様の中で長く受け継がれてきた事情や文脈があるはずです。そこを尊重しながら、前向きにより良い状態へ変えていく姿勢が必要です。

── 相手への敬意と、自走力のバランスが大切なのだと。
そうですね。専門性を持ちながらも、相手に敬意を払い、素直に学び、周囲と協働しながら自ら前に進める人。そういう意味で、最終的には「いい人」であることがすごく大事だと感じています。

卓越したテクニカルスキルはあるに越したことはありませんが、それは後からいくらでも習得できます。それよりもソフトスキルが大事なのではないでしょうか。

テクニカルスキルは私の趣味である「けん玉の技」と似ていて、繰り返し練習すれば難しい技でも必ず習得することができます（笑）。実際に手を動かすことが何より大切ですし、Red Hatにはそれを全力でサポートする環境やプロフェッショナルが揃っています。

── 最後に、読者に向けてのメッセージをお願いします。
ここまで読んでいただきありがとうございました。Red Hatには、外資系らしい自由さがありつつも、社内では「Red Hatサウナ部」を立ち上げてメンバーと長野へ遠征したりキャンプに行ったりと、プライベートでもちょうどいい熱量（サウナだけに）の心地よい関係を楽しんでいます。強制や同調圧力は一切ありません（笑）

自分の専門性を高めながら、お客様に深く寄り添い、変化を起こしていきたい方。もし少しでも興味を持っていただけたら、お気軽にお声掛けいただければと思います！サウナ好きな方も、けん玉に挑戦したい方も大歓迎です（笑）。素敵な仲間と一緒に働けるのを、楽しみにしています！