Blog一覧

勘定系システムから脱皮してAI駆動型システムを創るには エージェンティック開発では、従来のSoR（System of Record）の世界を脱皮して、データレイクハウスをベースにエージェントがデータを駆使する企業システムを実現することが必要です。しかし長年SoRで経験を積んだPMは社内からデータをかき集めて蓄積し、ビジネスゴールを達成するといったことを経験したことがありません。データレイクハウスをどうやって構築したら良いか、また、そこで動くエージェントをどう評価したら良いかといった観点は彼らからすると全く新しい挑戦になります。 システム開発が直面する新しい挑戦へどのように取り組むべきか。これについてもGeminiの回答を聞いてみたいと思います。 ＜Gemini：データレイクハウスでAI駆動型システムを創る＞ SoR（記録のシステム）の厳格なトランザクション管理に最適化されてきた従来のPMにとって、データレイクハウスという「曖昧で広大な海」を前提としたエージェンティック開発への移行は、パラダイムシフトそのものです。 決定論的（100%正解がある）な

「中にはいる」エンジニアの本質 「中にはいる」にもキャリアステップに応じていろいろなアクティビティがあります。かつての勤務先では、新入社員を最初の一年間顧客プロジェクトにアサインせず、研修に専念させていました。研修のゴールは最低1万行のプログラムを自分で完成させることです。このプログラムは新入社員に対して「コーディング」に限定した範囲で「中にはいる」行動を体験させることを狙ったものです。 もちろんこれだけで「中にはいる」エンジニアが完成するわけではありません。 PMとして一人前になるには、コーディングを「中から」考えることができ、基盤技術（RDBMSや新しい言語など）について集中的にキャッチアップすることができ、開発プロジェクトの収支について「中から」当事者として考えることができ、顧客の利益・目標について顧客目線で考えることができ、プロジェクトマネージャーとしてプロジェクト運営をバランスよく進めることができるという任務をこなせる必要があります。そして、これを長い時間の経験の積み重ねで育成してきました。10人月のプロジェクトを担当させて、うまく行っ

エージェンティック開発で「中にはいる」を実践するには AIによるシステム開発（エージェンティック開発）が急速に進んでいます。私の友人は従来の人海戦術のやり方を根本的に改めて、エージェンティック開発をするスタートアップを設立しました。今後、エージェンティック開発が高度化していくことは明白です。エージェンティック開発では「中にはいる」ためにエンジニアが取り組んできたことをエージェントが代わりに引き受けてくれます。ただし「中にはいる」エンジニア文化は仕様書を読み込んだりソースコードを何万行も書いたりする苦行のことを指しているわけではありません。 ソースコードをAIが作成し、膨大な仕様書をAIが読み込んでくれるとしたら、「中にはいる」ためのやり方も変わることになります。エージェントを使って中にはいるにはどうすれば良いか、Geminiに質問してみます。 ＜Gemini：「中にはいる」エージェンティック開発＞ AIの高度化と普及は、「中にはいる」という行為の難易度を劇的に下げる一方で、その重要性を次元の異なるレベルへと引き上げます。 従来の「中にはいる」と

中にはいるエンジニアをどう見分けるか？ 大勢の部下全てと十分なコミュニケーションが取れる訳ではありません。ましてや「中にはいる」経験を自分でしてこなかった経営者からすると、部下が中にはいっているのかそれとも口先だけなのかを見分けることはとても難しい課題になります。大企業のトップが外形的議論にひきずられて判断を誤るのはそんな瞬間ではないでしょうか。 「中にはいる」エンジニアは外形的なことに関心が薄いことも多く、性格的にエキセントリックだったりすることもあります。システム開発の本質とは関係のない言動まで同じ土俵で評価され、システム開発の門外漢に言い負けてしまうのはよくある光景です。どうすれば口先エンジニアと本物を見分けることができるのか、これもGeminiに聞いてみることにします。 ＜Gemini：「中にはいる」エンジニアの見分け方＞ 経営トップから見て、この2者を見分けることは非常に困難です。なぜなら、皮肉なことに「外形的なエンジニア」の方が、経営層へのプレゼンテーションが上手く、物事をスムーズに進めているように見えがちだからです。...

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

ー つながり(ユーザ接点)を競うビッグテック ー 今日の情報インフラにとって欠かせないものとして、ソフトウェアとサービスの話をしました。次にお話しするのは利用者とのつながり（ユーザ接点）ということです。サービスもソフトウェアも目的を達するための大事な手段です。サービスやソフトウェアを駆使して情報インフラが互いに競い合うのは、ユーザをどうつなぎとめるかということです。その成否が決まるバトルフィールドがユーザ接点です。 江戸時代の天守閣然り、日本では大事なものほど奥に置かれています。昭和の時代に日本企業が築き上げた情報インフラでも大事なもの、例えばデータベースやバッチプログラム、ストレージなどはデータセンターの奥に設置されており、ユーザ・顧客の目にふれるようなものではありません。昭和の情報インフラを築き上げた日本の情報産業も日本の伝統的なものづくり文化をしっかり引き継いできました。重厚長大な情報システムを作り上げることが目的の大規模システム構築の常識では、大事なものが利用者から最も遠いところに置かれているのがあたりまえでした。利用者は間違えるし、人に

ー インフラを「サービス」へ進化させたExodus ー 1990年代半ばから2000年代初頭にかけての「ドットコム・バブル」期は、インターネットが学術的ネットワークからグローバルな商業インフラへと変貌を遂げた時代でした。この爆発的な成長期において、物理的なインターネット基盤であるデータセンタ（Internet Data Center: IDC）の先駆者として君臨したのが、Exodus Communications（以下、Exodus）です。1994年に創業したExodusは90年代の終盤には世界のトップウェブサイトの40%をホスティングする巨大企業へと急成長を遂げ、ピークの2000年には約320億ドルの時価総額を記録しました。 当時は、自社オフィス内のサーバールームでウェブサーバーを管理・運用することが一般的でした。しかしeコマースの台頭とトラフィックの指数関数的な増加によって、オフィス内部での運用管理はネットワーク帯域幅、安定した電源供給、そして高度なセキュリティの観点から非効率かつハイリスクなものとなっていました。Exodusは「ミッションク

ソフトウェアを情報インフラの主役に押し上げた「APIマンデート」 社会インフラとしての情報システムも、ダムや高速道路と同様、始まりはハードウェアを主役とするものでした。コンピュータの巨人、IBMの時代についてはそのうち触れることにして、ここではソフトウェアが決定的にハードウェアを支配することになったターニングポイントについて語りたいと思います。 Windows95が一世を風靡した1995年を経て、インターネットバブルの時代がやってきます。ソフトウェアの役割は大きなものになっていましたが、それでもコンピュータ業界の主役はIBM、HP、Sun Microsystemsといったハードウェアメーカでした。日本でも富士通、NEC、日立製作所が不動の地位を獲得していました。ところがこの頃、ソフトウェアの生産性に革命を起こした出来事がアメリカで生まれます。「APIエコノミー」と呼ばれる新たなアーキテクチャはコンピュータ言語の進化ではありません。このアーキテクチャは当時、インターネットで書籍を販売していたAmazonで生まれました。 Amazonのインターネット

ー 過去に学ぶ、情報インフラの変革 ー インフラと聞いて、何を思い浮かべるでしょうか。道路や水道、通信網といった物理的な基盤を想像する人が多いかもしれません。一方、IT業界に身を置く私たちにとって、情報システムはインフラそのものだと言えます。かつてのメインフレームコンピュータで「構築」された企業の中核となる情報システムは「基幹系システム」と呼ばれました。ことさら「構築」とか「開発」といった言葉が使われるのも橋や道路と同じような公共インフラの建設を意識してのものではなかったかと思います。東京デジタルアイディアーズと私たちは長いこと情報システムによるインフラとともに過ごしてきました。インフラは企業にとって最も重要な戦略と表裏一体の関係にあります。企業戦略の成否を分けるのはインフラだといって過言ではないと思います。ここではインフラについて東京デジタルアイディアーズからいくつかの観点で語ってみることにいたします。 このブログでは情報システムの進化とともにインフラの役割がどのように変化していったかについて語りたいと思います。情報システムが社会インフラとな

生成AIの競争軸は大規模言語モデル（LLM: Large Language Model）の「回答精度」を競うフェーズから、実務を完結させる「自律型AI（Agentic AI）」の性能を競うフェーズへと劇的に移行しました。アメリカの巨大テック企業はいずれもAgentic AIの大胆な活用をソフトウェア開発に活かしており、生産性の爆発的な改善に関する報告が相次いでいます。またその結果、エンジニアの大量解雇や「SaaSの死」と呼ばれるIT企業の株価暴落へとつながっています。 一方、日本ではどうでしょうか。IT企業の株価低迷の影響こそあったものの、Claude Codeでソフトウェア開発の生産性が爆上がりしたという話はまだあまり耳にしません。逆に開発現場の話を聞いてみると例によってできない理由が次々と発覚しているようなのです。 意識高い系のエンジニアたちと議論してわかった日本企業ITの壁はいつか来た道を想い出させます。かつてのPC革命もインターネット革命も日本企業では同じ壁にぶちあたってしまいました。本レポートでは日本企業において生成AIによるソフトウェ