「もっとすごく」しても届かない ── Friction思考でプロダクトの存在意義を再定義した話

自分のプロダクトを、機能追加で良くしようとしていた時期がありました。

「もっと自動化できれば」「もっとカバー範囲を広げれば」──そうすれば使ってもらえるはず。そう信じて燃料を足し続けていた。でも、あるとき気づいたんです。燃料の問題じゃなかった、と。

この記事では、ロレン・ノードグレンの『「変化を嫌う人」を動かす』（原題: The Human Element）を読んだことをきっかけに、自分のプロダクト「DevLoop Runner」の方向性を根本から見直した思考プロセスを書きます。

結論を先に言うと、「自動化ツール」から「AIと協働できるエンジニアを育てる環境」へ再定義しました。ただ、そこに至るまでにはかなりの葛藤がありました。

「燃料」と「摩擦」── 人が動かない本当の理由

『「変化を嫌う人」を動かす』の核心はシンプルです。

人を動かそうとするとき、多くの人は「魅力（Fuel）」を足そうとする。もっと良い提案を、もっと論理的な説明を、もっと大きなメリットを。でも実際に人が動かない最大の理由は、魅力不足ではなく**抵抗（Friction）**だ──という主張です。

本の中では、変化を拒む心理的抵抗が4つに整理されています。

• 惰性（Inertia）: 今のやり方を変える面倒さ
• 努力（Effort）: 理解・学習・実行にかかる負担
• 感情（Emotion）: 不安、損失回避、アイデンティティの揺らぎ
• リアクタンス（Reactance）: 「押し付けられている」と感じたときの反発

読んでいて、グサッときました。自分のプロダクトでまさにやっていたことだったからです。

DevLoop Runner の Friction を分解する

DevLoop Runner（devloop-runner.app）は、GitHub Issue を起点にAIと協働して設計・実装・PR・ドキュメント生成までを進める環境です。技術的にはかなり作り込んできた自覚がある。思想もある。実装力もある。コンテンツも書ける。

正直に言うと、燃料は十分だったんです。

じゃあなぜ広がらないのか。Friction の視点で自分のプロダクトを見つめ直してみました。

graph TD
    A["DevLoop Runner が広がらない理由"] --> B["① 誰も知らない（惰性）"]
    A --> C["② 必要性の弱さ"]
    A --> D["③ 心理的不安"]
    B --> B1["知らないものは試さない<br>試さないものは評価しない"]
    C --> C1["あったら便利、でも今すぐ必要？<br>→ 多くのチームが「うーん…」"]
    D --> D1["GitHub クレデンシャルの不安<br>LLM APIキーの管理"]

自分の中での優先順位はこうでした。

単にまだ誰も知らない > 必要性の弱さ > 心理的不安

「知らない」は一見マーケティング課題に見えますが、ノードグレン的に言えばこれも惰性の一種です。知らないものを試さない。試さないものは評価しない。評価しないものは必要性を感じない。「知らない」は、行動しない理由として十分に強い摩擦なんです。

そして一番戦略的に重要だったのは「必要性の弱さ」でした。DevLoop Runnerは「あったら便利」「面白い」。でも「今すぐ必要か」と聞かれると、多くのチームは首をかしげる。

ここでやりがちなのが「もっとすごい機能を作ろう」。でもそれは燃料を足す行為で、摩擦は減らない。

最初に浮かんだターゲット像と、その葛藤

Friction を分解していく中で、最初に浮かんだターゲット像がありました。

エンジニアを時間労働で酷使している組織。そこで働くエンジニアは少しでも楽をしたいと思っている。DevLoop Runner をこっそり使って、これまで8時間拘束されていたところから実質の拘束時間を減らす。浮いた時間で勉強したり、別のやりたいことができるようになる。報酬は同じだけど時間が増えるから、実質時給が上がるのと同じ──。

正直に言うと、これはかなりリアルな仮説でした。実際にそういうニーズは存在すると思います。

でも、ここで立ち止まりました。

この方向には構造的な問題がある。「会社にバレずにこっそり使う」というツールは、組織の承認を取れない。予算がつかない。導入が広がらない。推薦してもらえない。つまり、スケールしない。

それ以上に引っかかったのは、プロダクトの物語が歪むことでした。

生産性向上と搾取構造の間で

ここからは少し踏み込んだ話をします。

エンジニアの生産性向上ツールには、構造的なジレンマがあります。生産性を上げたとしても、それによって生まれた余剰に対して追加のタスクが割り振られて、給料は上がらない。多くの企業で実際に起きていることだと思います。

エンジニア自身が生産性を高めつつ、自由な時間を取り戻せる。そういう広め方にならないのであれば、このツールを提供しないほうがマシなんじゃないか。わりと本気でそう考えていました。

でも、冷静に考えると、このツールを出さなかったとしても搾取構造が改善するわけではない。むしろ、効率化は経営主導で導入されるだけです。

ここで自分の中で整理がつきました。

問題はツールではなく、組織の配分ルールにある。 ツール自体は中立で、構造が歪んでいると良いツールも歪んだ使われ方をする。だったら、「誰のためのツールとして設計するか」が重要になる。

「自動化ツール」から「能力拡張の環境」へ

葛藤を経て見えてきたのは、こういう構図でした。

graph LR
    subgraph "❌ 時間短縮ツール"
        A1["効率化"] --> A2["コスト削減文脈"]
        A2 --> A3["経営にとっての余剰労働力"]
        A3 --> A4["タスク増 → 搾取リスク"]
    end

    subgraph "✅ 能力拡張の環境"
        B1["思考拡張"] --> B2["AI協働スキルの獲得"]
        B2 --> B3["市場価値の向上"]
        B3 --> B4["交渉力↑ → 選択肢↑"]
    end

「時間を浮かせるツール」と「能力を拡張する環境」。中身は似ていても、思想がまったく違います。

時間短縮を売ると、経営にとっては「余剰労働力」になる。でも能力拡張を売ると、個人の市場価値そのものが上がる。交渉力が高まる。会社に依存しない力が育つ。

主導権とは、会社に勝つことではなく、会社に依存しないこと。

この整理がついた瞬間、プロダクトのコンセプトが一気に変わりました。

DevLoop Runner は自動化エンジンではない。AIと協働できるエンジニアを育てる環境だ、と。

なぜ「協働プロセスが見える」ことが大事なのか

ここでもう一つの分岐がありました。

プロダクトとしては、「AIが全部やってくれるブラックボックス」のほうが売れやすいかもしれない。でも、思考プロセスが見えない装置では、使っている人の能力は伸びません。

DevLoop Runner で目指しているのは、こういうフローです。

1. Issue を入力する（人間）
2. AIが設計案を提示する（AI）
3. 設計の妥当性を判断・修正する（人間）
4. AIが実装する（AI）
5. レビューと改善に集中する（人間）
6. PRとドキュメントが生成される（AI）

人間は不要にならない。人間の役割は「実装」から「判断」に進化する。

そしてそのプロセスが可視化されているからこそ、使っている人は「AIに任せる力」「Issue を構造化する力」「レビュー観点を明確にする力」を身につけていける。

正直に言うと、ブラックボックスのほうが楽だし、短期的には売れると思います。でも、それは自分の思想と矛盾する。エンジニアの主導権を拡張するツールが、エンジニアの思考を奪ってどうするんだ、と。

独自のポジションが見えた瞬間

他の類似サービスと比較してみると、多くは「コード生成効率」「PR自動化」「工数削減」「コスト削減」を売っている。

自分が今見つけた軸は「AIと協働できるエンジニアを育てる」。これはレイヤーが違う。

しかも、自分のバックグラウンドと一貫している。内省（ORIMD）の研究、キャリアコンサルタント資格、エンジニアの主導権というテーマ。全部が一本の線になる。

コンセプトは同じかもしれないけど、なぜそれをやるのかの文脈が違う。その文脈の厚みが、独自のポジションになる──そう感じました。

ランディングページのリブランディング

コンセプトが定まったので、ランディングページも全面的に書き換えました。

ヒーローコピーはこうなりました。

AI時代、エンジニアの役割は変わる。
DevLoop Runnerは、その変化を実践する環境です。

最初は「あなたはAIに仕事を奪われますか？ それとも、AIを使いこなす側になりますか？」という問い型のコピーを置いていました。でも、これは煽りのニュアンスがある。恐怖で動かすのは自分の思想と合わない。

静かに、でも深く届く言葉を選びました。

ランディングページ全体で意識したのは、以下の点です。

• 「時間が半分になる」とは言わない。「思考の重心が変わる」と表現する
• 避ける言葉: 爆速、劇的削減、革命、圧倒的効率化
• ストーリー中心で腹落ちさせる（Before/After を1人のエンジニアの1日として描写）
• 「効率化は副作用。本質は、思考の進化。」を伝える

正直、まだブラッシュアップの途中です。抽象的なコンセプトなので、わかりやすさは引き続き磨いていく必要がある。でも、方向性としてはもうブレない確信があります。

振り返り: Fuel ではなく Friction を見る

今回の一連の思考で一番大きかった学びは、燃料を足し続けても、摩擦が減らなければ届かないということです。

機能を増やす。性能を上げる。カバー範囲を広げる。それは全部 Fuel（燃料）の話。でもプロダクトが広がらない本当の理由は、多くの場合 Friction（摩擦）の側にある。

そして摩擦を分解していくと、技術的な問題よりも先に「そもそもこのプロダクトは何のために存在するのか」という問いにたどり着いた。自分にとっては、それが一番大きな収穫でした。

DevLoop Runner はまだ少数に届いている段階です。でも、「AIと協働できるエンジニアを育てる環境」という軸が定まったことで、ここからの判断は格段にシンプルになると思っています。

燃料を足すか、摩擦を溶かすか。どちらか一方ではなく、両輪で考える必要がある。ただ、自分はこれまで燃料を足すことばかりに意識が向いていたので、摩擦を溶かす視点を持てたことが大きかったと思っています。

参考書籍

今回の思考の起点になった書籍です。「なぜ良い提案が受け入れられないのか」を4つの摩擦で分解するフレームワークは、プロダクト開発に限らず幅広く応用できます。

[📦 商品リンク: moshimo-card-mIsWy]

プロダクトの方向性を技術と組織の両面から考えたい方に。意思決定・戦略・リーダーシップの実践的な視点が得られます。

[📦 商品リンク: moshimo-card-TxhLL]

AIエージェントとの協働に興味がある方に。DevLoop Runnerが目指す「AIと協働できるエンジニア」の技術的な基盤を理解するのに役立ちます。

[📦 商品リンク: moshimo-card-tpujl]