知らないことで損をする会社を、なくしたい。エンジニアにも、発注者にも、まっすぐ価値が届く世界をつくりたい。
ベンダーに発注してもいい。大事なのは、その中身を理解し、言いなりにならず、自社が手綱を握っていること。「自分たちで判断し、使いこなしている状態」——それを、“自社開発”と呼んでいます。

代表取締役。リクルートで営業を経験後、起業(失敗)を経て日本マイクロソフト・NTTデータへ。発注者・ベンダー・自社開発、すべての立場で開発現場に入り、この20年、同じ光景を見続けてきた。2019年に独立、2022年法人化。Red Hatでアジャイル開発の標準化を支援。いまは1人+AIで、10以上のプロダクトを開発・運用している。
ビルを建てるのと同じ。完成・引き渡しが“ゴール”。それ以降は、関係ない。
使われて初めて、改善が始まる。納品はゴールではなく、出発点。
ここに、根本的な利益相反がある。発注者は“より良くしたい”、ベンダーは“早く納めて終わりたい”。
金額と納期を固定する「請負」では、ウォーターフォールしか選べない。
最初にすべてを決め、上流から下流へ一方通行。後戻りできない。——でも、現実はそう動かない。
5年前にコロナを、20年前にiPhoneを予測できましたか? 最初に完璧な要件定義など、誰にもできない。
こんな機能が欲しい、このボタンは押しにくいから場所を変えたい。フィードバックなしに、良いものは作れない。
実装中に設計ミスに気づいても、納期と入金を守るため報告されない。セブンペイの炎上は、その典型。
そのコア技術、他社に丸投げで、いいんですか?
請負を何層もの下請けに丸投げするたび、中間マージンが抜かれる。実際に手を動かすチームへ届く頃には、ごくわずかです。
各層が約20%ずつ“中抜き”。4層通るだけで発注額の半分以上がマージンに消え、実際に作るチームへ届くのは4割ほど。
請負は納期と金額を固定する。だから変更を受け入れられず、ウォーターフォールになる。アジャイルは、その逆です。
最初に全部決める。変更できない。
納品が、ゴール。
短く作って、使って、直す。
変化を前提に、フィードバックで良くする。
一流のPO・スクラムマスター・エンジニア、そしてアジャイルへの理解。これらを揃えるのは、簡単じゃない。
自走するチームには、権限委譲が要る。が、日本の組織で“現場に任せる”判断は、なかなか下りない。
ラボ型・SESで始めても、人材と契約の壁にぶつかる。丸投げでは、結局いいものは作れない。
借りられないなら自前で持つしかない。けれど現実は、受注時点で“高コスト”と“依存”が同時に上がるのが普通だった。
現在は1人+AIの前提で、まずは価値ある対話だけを増やす設計にしています(※実運用)。
受ける窓口(Contact)を整えるだけでなく、送る窓口(Reach)を“価値ある提案”に限定する。不要営業・誤送信・迷惑メッセージは拒否し、reCAPTCHA等の検知制御を前提に、AIは先に草案を作成・下書きして、最終回答は人が決める体制に変えています。
AIに足りないのは、御社の「文脈」と「ノーと言う判断」。その判断力を残したまま、AIが答えられる問い合わせのみを先行処理します。
私が目指すのは、AIと人が役割を分担する前提を社内外で透明化し、最初は人の判断が必要な意思決定を必ず残すことです。
Reach/Contactは対立しない。Reachは必要な場面だけの提案、Contactは必要な問いへの受けの場面だけに絞り、相互に引きずりあう不毛なやり取りを減らします。
AIが一次応答の草案を作成し、ヒューマンが確認できる状態で返すため、窓口の生産性が上がる。一方で“人間が取るべき対話”は優先され、意味のある会話に時間を戻せます。
現在は電話・メール・フォームの受け口を一本化し、将来はSNS/有効媒体へ接続を拡張する設計です。AIは現状、一次案作成と分類が得意。最終承認・微妙な交渉は“今”の運用ルールに従って人が判断します。
御社の外部接点(電話・フォーム・メール・SNS)を、必要なときだけ価値ある提案で開く設計にできるか。AI Front Officeという名前で“できること・できないこと”を明示し、拒否できる対話と安全制御を守る状態から始めましょう。