背景
生成 AI が台頭し、各界隈各組織各チームとも利活用に動いていると思います。私も個人的に、業務的に、また趣味のコミュニティ的にあらゆる場面でそうしていますし、そうするムーブに関与しています。
一方で、本番適用やその先の効果発生にまでは及びにくいとの現状があります。この手のニュースや研究はすでに山ほどありますし、皆様の体感とも一致していると思います。
生成 AI への期待と、現実に落とし込みきれない実態とのギャップ——これをどうやって埋めていけばいいか、考えるようになりました。
そうして私が至ったのは 変革（Transformation） の考え方です。個人レベルでは良い感触を得ていて、次はその先にも適用していきたい。
本記事について
自身の備忘も兼ねて、この「変革」の考え方を整理します。
※本記事は筆者個人の見解であり、所属組織を代表するものではありません。
変革とは「そのあり方に合わせに行くこと」だと思う
一番わかりやすいのは DX——デジタル・トランスフォーメーションです。これは私たちそのものを、たとえば組織のあり方やビジネスモデルを デジタルありきに シフトすることを指します。
- ❌️「物理的に出社して、会議室に集まって、紙の資料を配って一人ずつ喋るやり方」をデジタルでどうやるか
- ⭕️ビジネスチャット（TeamsやSlack）、ウェブ会議（Zoom）、クラウドストレージ（GoogleドライブやBox）、コラボレーションノート（Notion）といったデジタルな手段を前提とした上で、どうやるか
今でこそ、後者の⭕️が当たり前だとわかりますが、後者がまだ普及してない頃に後者のあり方にシフトするのは容易ではありません。発想の飛躍が必要であり、それが 手段やあり方から考える ことだと私は思いました。この場合、ビジネスチャットやウェブ会議やクラウドストレージやノートといった手段とあり方を理解し、その前提で、では私たちはどう合わせられるだろうか、を考えることになります。そうするからこそ、これらの便宜を享受できる。
DX については、すでにレポートが溢れています。必要なのは、「合わせに行く」ためにたっぷり考えたり練習したりすることと、何よりこれら手段を使えるよう投資することです。このあたりの権限を握るのは経営層であるため、事実上、経営層が投資できるかどうか次第となっています。私はマッキンゼーのレポートが一番わかりやすいと思います。
一方で、この手の情報の中には、DX を謳いつつも❌️のアプローチをしているものも多いように見受けられます。❌️は現状に歩み寄っているので一見すると良さそうですし、たいていのビジネスではむしろ鉄板ですが、変革ではない。変革がしたいのなら、⭕️のアプローチが必要だと思います。今現在、生成 AI という新しい波が来ていて、日々そう痛感します。
(余談) DX に限らず、First や Native 等の言葉で表現されることもあります。Mobile-first、Cloud-native、AI で言えば AI-native や AI-first と言ったりもします。いずれも「そのあり方ありき」が本質ですが、この概念そのものを捉える言葉が無い。次で定義します。
Transformant（変革に即した）
ここで便宜上、一つ言葉をつくりたいです。
形容詞として Transformant（変革に即した） をつくりたい。
本記事では、変革とは「そのあり方に私たちが合わせに行くこと」と捉えます。これを一言で言いたいのです。Transformation（変革）の本質なので、この言葉をもじる必要がありますが、既存の Transformative、Transformational 等では上手く捉えられません……というわけで、造語してみました。造語である点はご了承ください。
本題：生成 AI も Transformant にやりたい
前提が揃ったので本題に入ります。
私が言いたいことは一つで、生成 AI も Transformant にやりたい（やるべきではないか）、です。
例: Agentic Engineering
例として Agentic Engineering な製品を挙げます。
-
Agentic Engineering:
- 元は vibe coding を提唱した Karpathy がその翌年にポストしたもの
- 「99% をAIにつくらせる」潮流を指している
- 技術の発展に伴い、生成 AI は Vibe 的な使い捨てではなく、商業レベルもつくれる（可能性がある）ようになってきた
- 特に開発工数を大幅に減らすアプローチとして、開発や SI を AI エージェントに完遂させる「丸投げ」式も模索されている
- 丸投げ式の製品やサービスを謳う例も見られます
そうでなくとも個人レベルでは、ちょっとしたアプリくらいなら 1 枚のテキストを与えるだけで、使えるアプリが一発でできちゃう、くらいまではできてしまいます。この「1枚のテキスト」のつくりこみはまだ専門的で、誰にでもできることではありませんが、技術的には Agentic Engineering は現実的に使えるところまで来ている（ように思われる）。だからこそ夢の丸投げ、夢の全自動が射程に入っていると考えられます。
丸投げ君をつくるとして
仮に「丸投げ君」と名付けましょう。あなたは丸投げ君の開発担当です。自社の次世代製品、次世代ビジネスとして期待のプロジェクトです。頑張って丸投げ君を形にしましょう——。
このとき、おそらく普通の発想だと、以下のように考えるはずです。
- 顧客の要求のとおりにつくらせるには、どうすればいいだろう？
しかし、Transformant に考えるなら、別の考え方になります。
- 生成 AI は具体的にどこまでできるのだろう？どこまでできて、どこからは筋が悪いのだろう？
- それを把握した上で、それを生かせるレベルのモノを提示してビジネスにできないか？
Transformant なアプローチ
単純な例として、SI ではドキュメントも成果物であり、慣習的に Excel や Word など Office 文書でつくることが要求されます。じゃあ生成 AI でこれらをつくればいいか、という話です。従来の発想だと「そうです」「つくる以外の選択肢はなくない？」となるでしょう。
一方、Transformant に考えると、たとえば次のようにできます。
- 生成 AI でリッチテキストな Office 文書をつくるのは難しい
- 特に文書には細かい装飾や形式が複雑に反映されており、それらを人間が見て納得するレベルで再現するのは難しい
- 生成 AI はプレーンテキスト、特に Markdown を扱うのは得意だ
- SI におけるドキュメントは情報の列挙であり、抽象化すると「情報のリスト」から成るとも言える
- だとするならば Markdown でリストを多用する形で構造化したドキュメントをつくればいいのではないか
- これなら比較的つくりやすい: 早くつくれるし、再現性も保ちやすい
- これをもって成果物である、と合意できれば、これで済むようにならないか？
- もう少しリッチな見た目がほしいなら、Markdown から他文書に変換すればいい（Markdown という原典を抱える構造を維持する）
「人間向けの Office 文書を AI でつくる」という困難を回避できるのです。しかし、Markdown という異なるあり方を提示しており、まさに Transformant です。
※私たち現場層が納得するのは比較的かんたんですが、意思決定層や顧客に納得してもらうのは難しいかもしれません。また要件その他制約によっては変更が難しいこともあります。余談ですが、こういう「現実の難しさ」があるからこそ、いわゆる FDE（Forward Deployed Engineer）が盛り上がっているのだと思います。
ともあれ、ここまでできたら、丸投げ君のプロトタイプくらいはできそうですね。丸投げ君として SI をターゲットにして、さらにその成果物の一種であるドキュメントに目をつけるというわけです。
これなら「99% を AI にまかせてつくる」はできそうですよね。おそらく最初に顧客やステークホルダーと会話して情報を集めて（書いて）、それから AI に解釈させてドキュメントの形式で整理し直してもらって、Markdown として吐かせる——のようになるでしょう。実際、オープンソースのフレームワークとしても、このような流れを汲むもの（特に初期段階でインタビュー的・対話的に情報を引き出させる UI/UX）は多数あります。
Transformant にやるためには何が必要か
上記は単純な例でしたが、現実はもっともっと複雑です。それでも、私は Transformant にやっていくことが変革への道だと考えます。もっとも常に変革を求めるべきか、という問いはノーですが、それでも変革的にアプローチした方が上手くいく、あるいは飛躍できるケースも多いのではないかと信じています。
では、チームとして、組織として Transformant にやっていくにはどうしたらいいのでしょうか。
まずは 個人レベルでの練習と定着 だと思います。同じく Karpathy の例ですが、LLM Wiki という「LLM に Wiki を書かせる」考え方もあって、これもまさに Transformant です。従来の、個人で日記やドキュメントや知識グラフを整備していた体験とはだいぶ異なります。個人で生成 AI を Transformant に捉える例として使いやすいと思いました。
あとは DX と同様、投資することです。
- 生成 AI をガッツリ使えるよう投資する
- 個人的には、社員全員 or 社内コミュニティ参加者なら誰でも社外秘（のうち機密性が高くないもの全般）込みで Claude Code や Codex CLI などの AI コーディングツールが使えるレベルが欲しいと思います
- Transformant に考えるための時間をたっぷりつくる
- 個人的には「遊ぶ」という表現が好きです。登大遊さんの記事がわかりやすく、調べるとたくさん出てきます
- たっぷり遊んで考えたこと・学んだことを持ち込んで議論する
- やり方は様々ですが、モブワークやもくもく会のように集まって会話ベースで行うものもあれば、Wiki などに情報を書いて育てていくものもあります。SF プロトタイピングのように空想の力を借りて当事者意識を養う取り組みもあります
- また私たちエンジニアや会社員とは異なるあり方（たとえばアカデミックな研究室での日頃のコミュニケーション様式）や、ティール組織などの新しい組織パラダイムも取り入れられる気がしています
- さらに言うまでもなく AI エージェントとの協業の仕方も色々あるはず
いきなり全社レベルでやるのは難しいですが、部門レベル、チームレベルならやりようはあるでしょう。いずれにせよ、権限を担う（その組織単位の）トップ次第となります。ということは事実上、トップにどれだけ訴求できるか、ということになるのでしょうか。
そして、その後、たっぷり遊んで持ち込むという体験の設計も一層求められそうです。こちらについては、チーム改めギルドという形で別途記事をお出ししたいです。お楽しみに！
おわりに
私にも確たる解はありません。あるなら聞きたいくらい。しかしながら、Transformant の考え方は重要かつ現時点で「伝えるための言葉がない」と思っていたため、今回記事にしてみました。