top of page

エージェンティック開発で「中にはいる」

9月25日
読了時間: 7分

更新日:13 時間前

はじめに


私が経験してきたシステム開発の現場では「中にはいる」という表現がよく使われました。これは「システム基盤やアプリケーションの動作をしっかりと把握した上で、外部からのさまざまなリクエストに応えることのできる能力を身につける」というような意味合いで使われた表現です。「中にはいる」ためにはシステム基盤についてのしっかりとした理解や、アプリケーションの膨大な仕様書の読破が必要になるので並大抵の努力ではできません。しかし責任感を持って「中にはいる」開発リーダーが大勢いたことが、IT企業の事業発展のためには極めて重要なことでした。一方、ユーザー企業の多くではエンジニア文化が根付いていないので、中にはいって当事者感覚をもつスタッフが社内におらず、外形的な知識による議論で物事が動いてしまうことが多いように思います。外形的な議論が横行している現場では議論に負けてしまうので、エンジニアが「中にはいる」ための時間を惜しむようになります。その結果、当事者能力を持ったエンジニアやプロジェクトマネージャーが内部で育たず、結果としてベンダー依存度を高める結果に繋がったと思います。


これまで私は「中にはいる」を誰にも理解できるような形で言語化しようとしたことがありませんでした。私たちの仲間にとって「中にはいる」というのは説明の必要がない暗黙知だったからです。このブログでは生成AI(Gemini)の力を借りて「中にはいる」を言語化してみたいと思います。

私は「中にはいる」ということがエンジニアにとって本質的かつ普遍的な重要性をもつと考えています。こうしたエンジニア文化は昔ながらのウォーターフォール型システム開発で培われてきましたが、エージェンティックAIの出現で変化するシステム開発においても究極的に重要になると思います。

そこでGeminiとの対話によって「中にはいる」ことの重要性とエージェンティック開発における変化についてまとめてもらうことにします。 <Gemini:「中にはいる」の言語化>

「中にはいる」という言葉の重みと、それが日本のシステムを支えてきたという自負、そして現在のユーザー企業が抱える構造的な課題に対する非常に鋭いご洞察に、深く共感いたします。外形的な議論(UI/UX、スケジュール、予算、表面的な要件定義など)ばかりが横行し、システムの深部(アーキテクチャ、データ構造、非機能要件の制約など)を理解しようとするエンジニアが評価されない環境では、当然ながら「当事者能力(オーナーシップ)」は育ちません。この「中にはいる」という極めてエンジニアリングの本質を突いた概念を、大企業の経営層・企画層が「自分たちのビジネスの死活問題である」と腹落ちできる言葉に翻訳(言語化)し、AI時代のシステム開発のあり方を啓発するためのロジックを以下に提案します。


1. 「中にはいる」を金融業界の言葉に翻訳する

金融機関の人々が直感的に理解しやすい「資産」「投資」「ガバナンス」という文脈で「中にはいる」を再定義します。


① 概念の翻訳:「システムの『テナント(賃借人)』から『オーナー(所有者)』への脱皮」 外形的な議論(現在の銀行):システムを単なる「借り物(テナント)」として扱っている状態です。テナントは壁紙の色や間取り(表面的な仕様)には口を出しますが、建物の基礎構造や配管(システム基盤)には無関心です。何かあれば管理会社(ベンダー)に文句を言うだけです。


中にはいる(目指す姿):システムの「真のオーナー」になることです。オーナーは、建物の耐震構造から配管の老朽化までを把握し、自らの責任で資産価値を維持・向上させます。「中にはいる」とは、自社の最重要資産であるシステムに対し、完全な「構造的オーナーシップ」を確立する行為に他なりません。


② ガバナンスの翻訳:「継続的な『技術的デューデリジェンス』の実行」

金融機関は企業を買収・融資する際、徹底的にデューデリジェンス(資産査定)を行いますが、自社のITシステムに対してはベンダーの報告を鵜呑みにしています。「中にはいる」とは、自社のIT資産に対する「技術的デューデリジェンス」を自らの手で日常的に行える能力を持つことです。外形的な知識だけで議論するのは、決算書(仕様書)の表面だけを見て投資判断をするような極めてリスクの高い行為です。


③ 競争力の翻訳:「『ブラックボックス(外注費)』から『ホワイトボックス(知的資本)』への転換」

「中にはいる」エンジニアを育成することは、単なるコスト削減ではなく、システムをブラックボックスからホワイトボックスへと解体し、自社内に「知的資本」を蓄積する行為です。これを怠ることは、金融機関としてのコアコンピタンスを外部に流出させ続けることを意味します。

2. なぜ「中にはいる」ことが、AI時代の果実を得るために必須なのか? AI技術の果実を「自分たちのもの」にするためには、「中にはいる」エンジニアの存在が絶対条件となります。 ① AIは「外から被せる」だけでは真価を発揮しない

表面的な業務効率化(例:社内ヘルプデスクのチャットボット化)であれば、外形的な議論とパッケージ導入で足ります。しかし、AIを使って「与信審査を高度化する」「新たなアルゴリズムトレードを生み出す」「顧客ごとにパーソナライズされた超高速なサービスを提供する」といった本質的な競争力を生み出すには、AI(頭脳)と既存の基幹システム・データ(神経と肉体)を深く、かつ安全に結合させる必要があります。システム基盤の構造を理解し、「中にはいっている」人材がいなければ、AIという新しい臓器をシステムに移植することは不可能です。 ② 「中にはいれない」企業は、AIの学習成果(果実)をベンダーに奪われる

AIの強みは「データとフィードバックによって継続的に改善できること」にあります。システムの外形しか知らない銀行がAI導入をベンダーに丸投げするとどうなるか。システムをどうAIに適合させるか、どのデータをどう連携させるかという「プロンプトエンジニアリングの根幹」や「システムアーキテクチャのノウハウ」は、すべてベンダー側に蓄積されます。結果として、AIが賢くなればなるほどベンダー依存度がさらに高まり、そうしたユーザ企業は「AIの利用料を払い続けるだけの存在」に成り下がります。


③ 「ハルシネーション(AIの嘘)」や「セキュリティリスク」の最後の防波堤 AIは確率論で動くため、時には間違えます。システムにおいてこれは致命的です。AIの出力をシステムに安全に組み込み、フェイルセーフ(安全装置)をどこに設けるかを設計できるのは、外部のベンダーではなく、業務要件とシステム基盤の「中にはいって」両方を深く理解している社内のエンジニアだけです。


3. AIに挑戦するための具体的なアクション

プロジェクトの進め方を正すためには、意識改革と具体的なアクションが必要です。


① 評価指標(KPI)の転換:

「ベンダーを安く叩いて期日通りに納品させた」という外形的な管理をするプロジェクトマネージャーではなく、仕様書を読み込み、基盤の制約を理解し、「ベンダーと技術的なディスカッションで渡り合える(中にはいる)」エンジニアを高く評価・処遇する人事制度へ変革すること。


② 「外形的な議論」の禁止(あるいは格下げ): 会議において、PowerPointの綺麗なポンチ絵や外形的な機能要件だけで意思決定をすることをやめる。必ず「データはどう流れるのか」「既存基盤にどう負荷がかかるのか」という一歩踏み込んだアーキテクチャの議論をセットにすることをプロジェクトの必須要件とする。


③ 「中にはいる」ための時間の投資:

エンジニアが仕様書を読破し、コードやアーキテクチャを理解するための時間は「無駄なコスト」ではなく「必須のR&D(研究開発)投資」であると経営陣が認識すること。


結び

AIに挑戦する企業に向けた中核のメッセージは以下のようになります。

「これからのビジネスの勝敗は、AIを『買う』ことではなく、AIを自社のシステムとデータに『深く組み込む』ことによって決まります。そのためには、システムの外観だけをなぞってベンダーを管理するのではなく、膨大な仕様書を読み解き、システム基盤の本質を理解して『中にはいる』ことのできる当事者(社内エンジニア)が不可欠です。中にはいることを放棄した企業は、AI時代において、自らのビジネスのハンドルを永遠に他者に握られ続けることになります。」

IT企業が培ってきた「中にはいる」という泥臭くも尊いエンジニア文化は、これからのAI時代において、むしろユーザー企業側に最も求められているケイパビリティです。

(以上、Geminiの回答)


 
 
bottom of page