こんにちは、ブログ運営担当の遠藤です。 6/1（月）12:00～13:00 当社主催の勉強会「NRIネットコム TECH AND DESIGN STUDY #101」が開催されます!! 今回のTECH & DESIGN STUDYでは、当社エンジニアから「Google Cloud Next 26 ｰ Agentic Eraの幕開け ｰ」についてお話します。 【1テーマ目】Keynoteから考える、AIエージェント時代で何が変わるのか？ 2日間のKeynoteの概要・メッセージを整理しながら、Google Cloudの描くAIエージェント時代の開発と、それを組織で運用/活用するために必要となる仕…

こんにちは、ファインディのCTO室でスタッフエンジニアを担当している及川(@rojoudotcom)です。 4月14日(火)〜16日(木)にDevOpsDays Tokyo 2026が開催されました。本記事は、スポンサー登壇者として参加してきたレポートです。 DevOpsDaysは、世界各地で開催されるエンジニア向けの国際カンファレンスです。 開発（Dev）と運用（Ops）の連携、自動化、組織文化、最新の事例やプラクティスを発表しています。日本では DevOpsDays Tokyo として、年に1回開かれています。 本記事では、開発組織の成果を経営層にどう伝えたらいいのかを悩まれている方や、AIを導入したのに成果が見えないと感じる方に向けて書きました。3日間のイベント参加を通じて改めて確信した「可視化は組織が動き出すための前提条件である」というメッセージを、登壇・基調講演・現地での会話の3つの角度から振り返ります。 開発組織は、経営から「見えない」 成果を見やすい形で可視化すれば、見える投資に変わる 経営から「見えない」と言われた開発組織を、仕組み・文化・習慣の3層で診断 組織設計に意図を持つことで組織の活動が見える 成果を見る側に立って翻訳する 仕組みを作り、文化を育て、習慣を変えれば、見えない現場は見える投資に変わる 可視化がない改善は、AIに増幅されない 「可視化されてはじめて、人は動く」 おわりに 開発組織は、経営から「見えない」 DevOpsという言葉についてのおさらいですが、もともと「DevとOpsの壁を壊す」ことから始まりました。コンテナ、CI/CD、SREといった方法論が広まり、Dev-Ops間の景色が変わったと感じる方は多いと思います。 一方で、 Devと経営(Biz)の間の壁は依然として高いままではないでしょうか 。 開発部門が作るソフトウェアは形がなく、損益計算書には給与や販管費などの「費用」としてしか記録されません。経営層の関心は売上向上や費用削減にあるのに対して、開発の関心は製品開発におけるリリース頻度の向上やリードタイム削減にあります。お互いが重要だと思う指標が異なることが、すれ違いを生み続けていると考えています。 成果を見やすい形で可視化すれば、見える投資に変わる 今回の登壇では、ファインディ以前に在籍していた現場の事例を話しました。経営層から状況が見えないと言われていた開発組織を意図を持って再設計し、活動の良し悪しを計測したことで投資の判断ができる状態とした体験談です。 テーマは「Dev-Bizの壁をどう越えるか」。20分のスポンサーセッションで持ち時間は短かったものの、自分の問題意識を言語化する貴重な機会になりました。   経営から「見えない」と言われた開発組織を、仕組み・文化・習慣の3層で診断 私が過去に在籍していたある企業の開発部門の話です。配属された開発部門は発足から20年が経つ自社サービスを担当しており、内製化を進めていたところでした。歴代の担当者は退職済みで、ドキュメントもなく、現場の判断は開発担当者の属人的なナレッジに委ねられていました。 エンジニアリングマネージャとして組織の状況を把握するために現場関係者にヒアリングを始めると、様々なことが見えてきました。 まず、組織のサイロ化が進む仕組みが見えてきました。開発に関わるメンバーはプロジェクトの終了と共に解散するため組織ナレッジが溜まりにくいこと、そして新機能開発チーム（Dev）と運用改善チーム（Ops）は分断されており、特にOpsチームに届けられる改善要求は、その背景が不透明なまま改修が行われていました。 次に、受け身の文化が根付いていました。歴史的に要求は事業部が作成し、開発側は要求を待つ立場だったためです。さらに、上位下達の関係性から、開発側からの提案や意見を出しづらい状況でした。 最後に、経営層からすると、PLやBSの数字以上に開発の状況が見えない状態が続いていて、それ以上踏み込めない状況が習慣化されていました。リソースをどこに集中すべきか、開発予算は適正なのかの判断ができない状況でした。 組織設計に意図を持つことで組織の活動が見える 見えない状態は、組織の設計に「なぜそうしたか」の意図がないことが原因です。最初の取り組みとしてTeam Topologiesで組織体制を再設計しました。すると、顧客の要望がどこからきてどこに流れていくのか（バリューストリーム）を見えるようになり、それぞれの開発チームの責任範囲やチーム間の関係性も明確になりました。 組織の枠組みが整ったところで次はチームの中身（マインドセットや運用ルール）です。アジャイル開発のスクラムフレームワークを導入し、自己管理化を進めていきました。チーム自身が開発案件の優先度や実現方法を話し合うようになりました。さらに、システム的観点から事業部の要望に対する逆提案が生まれるようになりました。 そして、新体制が動き出してきたところでFindy Team+を導入し、開発チームのリードタイムやボトルネックを可視化し、定量的なデータを取り始めました。半年後にはリードタイムが従来比8割短縮、デプロイ頻度も3割増加し、経営層に対しても改善を数字で示せるようになりました。 成果を見る側に立って翻訳する Four Keysによる開発活動の成果や、新機能が完成したときに得られるであろう期待される売上やコスト削減効果は重要な数字ではありますが、経営層が理解するにはもう一歩踏み込む必要があります。 例えば開発生産性が向上したことで稼働可能な人月が増えたと同等の効果と捉えれば、管理会計の項目のどこに増減の影響が生まれるのか。あるいは、リリース回数が増えたことで事業計画がどの程度短縮できるのか。こうした情報は決算書にも書けるような話題で、経営層にとって必要な情報です。 このように、投資判断を行う経営層の立場に立ち、開発の活動を翻訳して伝えることで、ようやく開発部門に対する投資判断の議論ができるようになりました。 仕組みを作り、文化を育て、習慣を変えれば、見えない現場は見える投資に変わる 以上、目の前の問題の直接解決ではなく、問題を生み出す構造（仕組み・文化・習慣）に目を向けて根本解決を促すストーリーでした。 さらに詳しい内容はスライドをご覧いただけるとうれしいです。 見えない開発現場を、見える投資に変える — Speaker Deck 可視化がない改善は、AIに増幅されない 「可視化が大事」とは言われ続けてきました。それでも今このテーマで登壇しようと思ったのは、AI時代に入って、その重要性が以前にも増して大きくなっていると感じていたからです。そして、その直感はカンファレンスの基調講演で裏付けられました。 Google CloudでDORA（DevOps Research and Assessment）プログラムを率いるNathen Harvey氏によれば、 2025年の調査でAI採用率は90%に達した そうです（前年比＋14%）。 一方で、コード品質や個人の生産性は上がったものの、 ソフトウェアデリバリーの安定性は悪化していました 。Harvey氏はこの現象を踏まえて、AIの役割を「 増幅器（amplifier） 」と表現していました。 良いシステムには良い結果を、悪いシステムには悪い結果を増幅するもの という意味合いです。 この比喩がしっくり来たのは、増幅されるためにはまず「何が起きているか」が見えていなければならない、という当たり前の前提が浮かび上がるからです。 可視化されていないデータをAIに与えてもノイズを増幅するだけです。可視化されていない開発組織は、AIを入れても何が良くなったのか悪くなったのかすら判断できません。 AI採用は、可視化された土台の上ではじめて成果に結びつく 基調講演から受け取ったメッセージはそこに集約されていました。 そして、もう一つの基調講演でDevOpsムーブメントの礎を築いた一人であるAndrew Clay Shafer氏が残した「 行動を変えるまでは、何も学んでいない 」という一言も、同じことを別の角度から言っていると感じました。見えなければ学ぶことはできないですし、闇雲に行動することになります。それは学んでいないのと同じことです。 ここで触れた2つの基調講演のセッション情報は次のとおりです。 confengine.com confengine.com 「可視化されてはじめて、人は動く」 3日間で一番心に残ったのは、技術的な議論ではなく、夜の懇親会で交わした一つの会話でした。 懇親会で日本酒を参加者に勧めていたとき、たまたまDay1の基調講演スピーカーのNathen Harvey氏が近くにいました。興奮して握手を交わし自己紹介をすると、彼は「 ファインディのプロダクトを見せて欲しい 」とリクエストしてくれました。 その場でブース担当者を呼んで、開発生産性可視化のデモをしました。彼はそれを見終えた後、こう言いました。 可視化することで、ようやく人は動き出すんだよね。 自分の登壇で伝えたかったことも、基調講演で語られていたDORAの研究も、3日間で出会った人たちが共有していた問題意識も、この一文で言い表されていると感じました。 Four Keysのような生産性指標で 内側の現在地 を、DORAのような調査レポートで 外側の方向性 を捉え、両者のギャップを埋めていきます。 可視化はゴールではなく、組織が動き出すための出発点です。 Dev-Bizの壁を越えるにも、AIを増幅器として活かすにも、共通して まず見えていること が要ります。これが3日間を貫いていたメッセージでした。 翌日のスピーカーインタビューのアイスブレイクで「日本に来てどうですか？」と聞かれたHarvey氏が「 ファインディに会えたことが思い出になった 」と答えてくれたのは、嬉しいおまけでした。 おわりに 開発組織を率いるマネジメント層にとって、可視化は「あれば便利な機能」ではなく「動き出すための前提条件」だと、今回の3日間で改めて確信しました。当社は指標を計測するサービスを提供する側だからこそ、組織を歪ませない設計に責任があると、身が引き締まる思いです。 DevOpsDays Tokyoに参加することで、スピーカー同士、運営の方々、そして海外登壇者との繋がりをつくることができ、DevOps文化に貢献したい気持ちも高まりました。来年の開催も楽しみにしています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

はじめに クラウドエース DevSecOps 事業部の羽田です。 今回はGoogle Cloud Load Balancing について初心者でもざっくり理解できるように図解を交えながら紹介していきます。 今回はざっくり解説のため Cloud Load Balancing の種類の解説等はしません。 この記事でわかること Load Balancer が何かわかる Google Cloud の Cloud Load Balancing の特徴がわかる Cloud Load Balancing の具体的なユースケースがわかる この記事での最終目標は IT 初心者、Google C