シンプルにする｜会議1ヶ月の大企業と、即日実行のAI開発体制の決定的な差

会議の設定に1週間。内容の承認に2週間。翌週に次の会議を設定。

これだけで1ヶ月が消える。

この1ヶ月の間に、市場は動き、競合は手を打ち、クライアントの状況も変わる。1ヶ月前の予測はもう当てにならない。それなのに、1ヶ月前の議論の続きから始める。

私はこの構図を前職で何度も経験し、消耗してきた。そして1つの結論に辿り着いた。「シンプルにする」——これが今の私の会社のスローガンだ。

意思決定スピードの差を数値で見る

同じ「Webアプリの改修」案件で、実際に経験した2つのケースを比較する。

大企業クライアントA社の場合

当社の場合

着手までの差は15倍。 これは極端な例ではない。大企業との協業では日常的に起こるスピード差だ。

もちろん、大企業のプロセスには理由がある。ガバナンス、コンプライアンス、リスク管理——すべて組織を守るために必要な仕組みだ。しかし、それを小規模な案件やスピードが求められる局面にそのまま適用すると、プロセスを守ることが目的化し、本来の「クライアントの課題を解決する」という目的が後回しになる。

「請けたら負ける」構図の正体

特にマレーシアで日系企業をサポートする中で、日本式のプロセスをそのまま海外に持ち込んでいるケースを数多く見てきた。

深刻な問題は、意思決定の責任が分散することだ。

「この方向で進めましょう」と言える人がいない。全員が合意を求め、全員がリスクを回避する。結果、決定が先送りになり、行動が遅れ、予測が外れ、成果が出ない。

これが**「請負」が「請けたら負ける」構図**だ。

請け負った仕事がクライアント側の遅延で進まない。しかし納期は変わらない。品質要求も変わらない。遅れた分だけ、しわ寄せが開発側に来る。

この構図を打破するために選んだのが、「シンプルにする」というアプローチだ。

シンプルにするための3つの判断基準

「シンプルにしたい」と思うだけでは何も変わらない。判断に迷うたびに立ち返る、3つの基準を設けている。

基準1：その工程は「成果」に直結するか

会議、資料作成、承認フロー——すべての工程を「クライアントの課題解決に直結するか」で判断する。直結しない工程は削る。

具体例： 以前は提案前に社内レビューを3段階踏んでいた。1人体制に変えてからは、AIでモックを作り、クライアントに直接見せて反応を取る。社内レビューの2週間が消え、クライアントからの具体的なフィードバックが初日に得られる。

基準2：判断に必要な情報は「3つ以内」に絞れるか

情報が多すぎると判断が遅れる。あらゆる意思決定で、判断材料を3つ以内に絞ることを徹底している。

具体例： 技術選定で10個のフレームワークを比較するのではなく、「実績」「学習コスト」「保守性」の3軸で3候補に絞り、1日で決定する。網羅的な比較表を作る時間は、実装を前に進める時間に充てたほうが良い。

基準3：失敗したとき「やり直し」にかかるコストは小さいか

シンプルな体制の最大の強みは軌道修正の速さだ。小さく始め、間違いに気づいたらすぐ方向転換する。

大企業が1ヶ月かけて合意形成した計画は、方向転換にも1ヶ月かかる。当社なら翌日には修正版を出せる。だから、完璧な計画を追求するより、まず動いて検証するほうが合理的になる。

提案プロセスを変えた具体例

この3つの基準を提案スタイルにも反映した。

Before：机上のディスカッション

1. クライアントのビジネスモデルをヒアリング
2. 要件を言語化してもらう
3. こちらで整理して提案書を作成
4. 次回ミーティングで提案
5. フィードバックを受けて修正
6. 繰り返し...

ステップ2でつまずく。 クライアントの多くは、自分が何を求めているかを正確に言語化できない。「なんとなくこういうイメージ」「もっといい感じに」——抽象的な表現が飛び交い、会議が進まない。

After：モックを先に見せる

1. 事前にAIでモックを3案作成（数時間）
2. 初回ミーティングで見せる
3. 「これは違う」「ここはこうしたい」と具体的なフィードバックをもらう
4. その場で修正するか、翌日までに反映
5. 実装着手

モックを見せた瞬間、クライアントの反応が変わる。

「ここの色を変えてほしい」「この機能はいらない」「ここにもう一つボタンがほしい」——率直な意見が多い。しかし、抽象的な議論で膠着するよりも、具体的な批判が出るほうが100倍前に進む。

モックは「言語化の壁」を壊すツールだ。AIとの協業で数時間で3案を作れる今、この方法のコストは劇的に下がっている。

料金体系もシンプルに

提案だけでなく、料金体系もシンプルにした。

以前は項目が50行を超える積み上げ式の見積書を作っていた。クライアントは読み解くだけで疲弊する。

今は、やることと金額をシンプルに提示する。 クライアントが知りたいのは「いくらで何ができるか」だ。工数の内訳ではない。

シンプルな体制が生み出す具体的な成果

「シンプルにする」は理念ではなく、測定可能な成果を生む方法論だ。

成果1：案件の回転速度が3倍になった

提案から着手までの期間が平均30日から10日に短縮。同じ期間で扱える案件数が増え、1人で5案件を同時進行できる体制が実現した。

成果2：クライアント満足度が向上した

「提案が速い」「修正対応が速い」——スピードそのものがクライアントからの信頼になっている。特にマレーシアでは、目的が明確な企業が多い。「マレーシアで成功して実績を作る」という目標に対して、速く動ける外注先は重宝される。

成果3：軌道修正コストが下がった

小さく始めて速く回すから、方向転換のダメージが小さい。3ヶ月かけた計画が白紙に戻るリスクより、1週間で作ったモックを捨てるほうが遥かに低コストだ。シンプルだから、失敗しても次の一手がすぐ打てる。

5つの実践ルール

1. 会議は30分以内

1時間の会議を設定しない。30分で終わらないなら、準備が足りない。 事前にモックや資料を共有し、会議では確認と決定だけを行う。ディスカッションの場ではなく、意思決定の場にする。

2. 提案は3案以内

選択肢が多すぎると判断を遅らせる。それぞれの方向性が異なる3案を提示し、クライアントは「選ぶ」だけでいい状態を作る。

3. 決定は即日

ミーティングで議論した内容は、その日のうちに方向性を決める。「持ち帰って検討します」を極力なくすために、意思決定者がミーティングに出ることを事前に依頼している。

4. AIで実行速度を補う

シンプルにするだけでは足りない。速さも必要だ。AIとの協業で、モック3案を数時間で作成し、設計書を1日で仕上げる。この実行速度があるからこそ、シンプルな提案プロセスが成り立つ。AI社員の実稼働データはこちらで公開している。

5. やらないことを決める

最も重要かつ最も難しいルール。

• やらない会議
• やらない資料
• やらない承認フロー
• やらない根回し

「やること」を決めるのは簡単だ。「やらないこと」を決めるのが、シンプルにする本質。

シンプルにすることの限界と注意点

ただし、シンプルにすることが常に正解とは限らない。

シンプルが合わないケース：

• 規制産業（金融、医療等）では承認プロセスの省略が法的リスクになる
• 大規模プロジェクト（数十人規模）では合意形成プロセスが品質を担保する
• セキュリティ要件が厳しい案件では、チェック工程の削減が重大なインシデントに繋がる

シンプルさの代償：

• 属人化しやすい。1人で判断するため、判断基準の共有・ドキュメント化は意識的に行う必要がある
• 「速く動く」ことが目的化すると、品質を犠牲にしがちだ。スピードと品質のバランスは常に意識する

シンプルにする戦略は、小〜中規模案件で、意思決定者との距離が近い場合に最も威力を発揮する。自分の体制がどの領域に適しているかを見極めることが重要だ。

まとめ：シンプルだから、速く、正確に

会議設定に1週間、承認に2週間——この世界は変わらないかもしれない。

しかし、自分の戦い方は変えられる。

シンプルにする。判断基準を3つに絞る。モックで「言語化の壁」を壊す。AIで実行速度を上げる。小さく始めて、間違いに気づいたらすぐ方向転換する。

シンプルだから軌道修正が速い。軌道修正が速いから、結果として成功率が上がる。

完璧な計画を追い求めて動けなくなるよりも、70点の仮説で動き出し、現実のフィードバックで100点に近づける。それが、私が選んだ戦い方だ。

AI社員との協業でスピードがどう変わったかは1人社長がAIチーム4名を組むまでをご覧ください。提案スタイルの具体例は売上が先、システムは後で解説しています。

AI活用やシンプルな開発体制についてのご相談はお問い合わせからお気軽にどうぞ。