顧客が自分で開発するとはどういう意味か
リトマスは EC データ分析ソリューションと受託開発を手がける約 60 名規模の会社です。Howwhy AI ポッドキャストに出演した金雄振（キム・ウンジン）代表が『パートナープラットフォーム』というものを紹介しましたが、ここで『顧客が自分で開発する』という言葉の実体が見えてきます。
パートナープラットフォームでは、顧客が自分のサービス画面上で直したい要素（ボタン、文言、レイアウト）をクリックして選び、コメントを残します。『この部分をこう変えてほしい』と書けば、そのコメントがすぐに『チケット』になります。チケットとは一つの作業単位で、開発依頼書一枚と考えればよいものです。
チケットが生まれると、エージェントが取りかかります。エージェントとは、人の代わりにコードを読み、直し、デプロイまで行う AI プログラムです。リトマスでは CRH という名前のエージェントが依頼を確認し、コードを修正し、作業を『完了』状態に切り替えます。顧客の側から見れば、開発者に口頭で頼む必要なく、画面上でクリックとコメントをするだけで開発が回っていく。実質的に顧客が自分で開発する構造です。
なぜ PM 関門が必要か——自助開発ではなく対話のツール
ただしここには安全装置があります。初期段階ではチケットが来るたびエージェントがすぐ実行してもよいのですが、プロジェクトが中期・後期に入ると PM（プロジェクトマネージャー）が関門を守ります。関門とは、通過の可否を人が決める関所です。
PM はチケットを見て三つのうち一つを選びます。すぐ反映するか、レビューのうえ反映するか（PR でプレビュー）、いっそ止めて待機させるか。PR は Pull Request の略で、コード変更をすぐ適用せず『こう変えるつもりですが、よいですか』とまず見せるプレビューの手順です。リトマスはチケットをすぐマージせず、ブランチを切り替えて PR を出す形で関門をかけます。
なぜ止める必要があるのか。顧客が望むからといって、すべてが正しいわけではないからです。近ごろの受託プロジェクトは同じ金額でも一年前より複雑さが三倍以上になり、技術的には実装できても方針や事業目的と合わない依頼がよく出ます。それをふるいにかけ、切り落とし、調整するのは依然として人の仕事です。だからこのプラットフォームは 100% の自助開発ツールというより、顧客と開発会社が同じ画面を見ながら対話するツールに近いのです。
RFP を 100% は作らないという選択
この構造を見て、私（SH Consulting）は自分のやり方に確信を得ました。RFP は Request For Proposal の略で、顧客が『こういうものを作ってほしい』とまとめた提案依頼書であり要件定義書です。ふつう受託開発会社は RFP に書かれたことを 100% 実装し、完成品として引き渡します。
私はあえてそうしません。核となる 80% を作って単独で回るようにし、残る 20% は顧客が自分で仕上げられるよう残します。すべて作ってあげると、顧客はささいな修正一つでも毎回開発会社を呼ばねばならず、その依存が時間とコストとして積み上がるからです。
ここでいう 80% とは『単独で回る骨組み』までを指します。残りの 20%（細かな文言、画面の微調整、新項目の追加など）は、顧客が自分で手を入れられる領域として残します。完成品を渡すのではなく、顧客が引き継いで育てられる、生きたシステムを渡すのです。
なぜ AX 教育が仕上げを肩代わりするのか
残る 20% を顧客が自分でやるには、やり方を知る必要があります。そこで AX 教育を併せて提供します。AX は AI Transformation の略で、組織や個人の働き方を AI 中心に作り替えることです。ここでは『顧客が AI ツールで自分のサービスを自ら直し、保守する方法』を身につけることを指します。
具体的には、顧客が Claude Code や Codex のような AI コーディングツールで画面を直し、文言を変え、簡単な機能を付ける流れを手に馴染ませます。リトマスが顧客にパートナープラットフォーム（クリック → コメント → チケット）を手渡したのと同じ原理です。開発者に口頭で頼む代わりに、顧客が自分で手を入れる経路を開くのです。
効果は依存から自立への転換です。すべて作ってあげると顧客は毎回私を呼びますが、自分で作る術を覚えれば自分の手で回します。保守コストが下がり、顧客は自分のサービスの主になります。すると開発会社は『完成品の納入業者』ではなく、『顧客を自立させる教育・設計のパートナー』になります。
AI 時代、コンサルタントの価値はどこへ移るのか
AI がコードをどんどんうまく書くにつれ、開発そのものはありふれた能力になっていきます。顧客も AI で直接開発できる時代です。すると開発会社が売るものは、『コードを書く労働』から別のものへ移らねばなりません。
移る先は二つです。一つは判断です。何を反映し何を止めるか、どの依頼が事業目的に合い、どれがリスクかを決めるゲートキーパーの役割です。もう一つは教育です。顧客が自分でできるようにすることです。どちらも AI が代われない、人と領域理解が要る領域です。
リトマスの代表は、セールス・PM・開発者の区別が消え、すべて『コンサルタント』という一つの職群に統合されていくと見ていました。私も同じ方向を見ています。実行は AI と顧客に渡し、人は判断・関門・教育へと上がります。あなたの仕事でも『実行』と『判断』を切り分けてみてください。実行は自動化するか委ねて、判断する位置に自分を残すこと——それが AI 時代の生存設計です。