What's Underneath by Yoshinao Takisaka

ソフトウェアを完成させる力 ― Pain-Driven Software Development

AI で何でも作れる時代に、それでも完成しないものについて

Claude Codeの出力がCLI上に流れ、手元の環境で次々とファイルが生成されていく。 僕にとって初めてのmacOSアプリ開発だった。 未知の領域に踏み込んでいるにもかかわらず、大きなつまずきもない。 わずか数時間で、プロトタイプが形になった。

作ったのは、会議の発話をリアルタイムで可視化し、構造化するアプリだ。 名前は「CONTXXXT」とした。 コンサルタントの技能の一つに、議論を整理して導くファシリテーションがある。 これをソフトウェアの力で自動化できないか、と考えたのだ。 会議の音声がリアルタイムでテキスト化され、フローチャートやツリーマップのように画面上で構造化されていく。 いわば、リアルタイムのグラフィックレコーディング化（グラフィックレコーダーのAI化）を狙ったものだった。

技術スタックは、音声認識に WhisperKit と Apple Speech、発話の構造化に Gemini の 3 段階 LLM パイプライン(realtime / mid / final)、グラフ描画は WKWebView 上の ReactFlow。Swift と TypeScript の組み合わせで動く macOS ネイティブアプリだ。

技術的には、驚くほどスムーズにMVP（Minimum Viable Product）まで到達した。 マイクに向かって話しかけると、画面の中に次々とノードが生まれ、意味で接続された線で結ばれ、構造化されていく。

動画は Substack 版で →

CONTXXXT の会議モード ― 発話がリアルタイムでノードとして構造化されていく

自分の発言が即座に図解される様子は、作っている本人から見ても魔法のようだった。 これは結構便利かもしれない。 そんな高揚感を胸に、同僚や友人数名と一緒に実際の会議で試用してみた。

そこで、根本的な問題に気づいた。

画面上に構造化された発話が常に見えていると、そこに注意が奪われてしまう。 次々と枝分かれしていくグラフを、みんなが目で追ってしまう。 「あ、今こんな風に図になった」と気になってしまい、肝心の議論の中身が頭に入ってこない。 本来なら相手の顔を見て、声のトーンを感じ取りながら進めるべき対話が、画面上の図形の変化に吸い込まれていく。 議論をスムーズにするはずのツールが、むしろ対話を邪魔していた。

そこで、ふと気づくのだった。 グラフィックレコーディングというものは、会議中ずっと見続けるものではない。 議論が終わった後の最終成果物として、全体像を俯瞰できることに価値があるものだったのだ。 リアルタイムで可視化し続けることには、注意の分散という根本的なトレードオフが存在した。これでは本末転倒だ。

技術的には作れた。 会議を傍観するユーザーとして見ている分には、面白い。 しかし、議論をスムーズにするためのツールとして使うユーザーにとっては、邪魔になってしまう。 「便利そう」が生み出すベネフィットは小さすぎる。そこにはユーザーのPainがなかった。 これ以上進めても仕方がないと判断し、僕は開発を止めた。

「動くもの」と「なくてはならないもの」の間には、溝がある。 AIで動くものを作れるようになっても、その溝は埋まらない。 どれほど高度な技術を使って、どれほど素早く形にできたとしても、それが本当に人の役に立つかどうか、Painを解消できるかどうか、まったく別の話なのだと思い知らされた。

もうひとつのプロジェクト、その結末

同じ時期、同じようにClaude Codeを使って自作し、こちらは最後までやりきったプロジェクトがある。 Superwhisper や AquaVoice のような、音声をテキスト化するツールのクローンだ。 名前は「HyperWhisper」 とした。 マイクから拾った音声を文字に起こし、任意の整形を施してクリップボードにコピーし、ペーストで貼り付ける。 ただそれだけの、シンプルなmacOSアプリだ。

技術スタックは、WhisperKit による on-device 文字起こしと、Gemini Flash による軽量な整形(箇条書き化・要約・話し言葉から書き言葉への変換など)。CONTXXXT と同じく Swift で書かれているが、こちらは UI を最小に削ぎ落としている。

なぜこちらは完走できたのか。 理由は明確だった。すでに市場で価値が定義されているサービスであり、自分一人で価値を発明する必要がなかったからだ。 世の中にはすでに似たようなツールがたくさんあり、多くの人がそれを使って便利さを感じているからだ。 つまり、「こういうものがあれば助かる」という仮説検証の段階を、丸ごと省くことができたのだ。

さらに大きかったのは、自分自身のPainも解決されたことだ。 僕自身が、日常的に音声をテキスト化するツールを使っているヘビーユーザーだった。 歩きながらアイデアをメモしたり、長い文章の草稿を声で吹き込んだりする。 その中で、既存のツールに対して感じていた小さな不満点があった。 使わない機能が多いとか、かゆいところに手が届かないとか、そういう日々のちょっとした引っかかりだ。 それらの不必要な機能を削ぎ落とし、自分好みに機能を追加していく。 コードを書き換えては自分で使い、使いながらまた直していく。 その自己改善ループが、とても綺麗に回った。

実装が進むにつれて、確かな達成感があった。 自分自身がユーザーであり、自分が満足するラインがはっきりと見えていたからだ。 「処理速度がもう少し早ければイライラしないのに」と思えば、そこを直す。 直ったものを自分で触ってみて、「うん、これなら心地よい」と納得する。 価値の定義が既存市場からの借り物であっても、完成の感触はたしかにそこにあった。

欲しい機能だけが、欲しい場所にある。しかも自分でつくった。イケア効果だ。 僕自身が「これでよい」と思える状態にたどり着いたとき、自然とキーボードから手を離すことができた。 それは、間違いなくひとつの「完成」の形だった。

Pain の所在

同じ作り手、同じ道具。一方は完成し、一方は止まった。 違いは「誰のPainか」が定まっていたかどうか、それだけだった。

この「痛み」で駆動されるソフトウェア開発を「 Pain-Driven Software Development 」と呼んでみることにする。 GainではなくPainを起点に置く設計と実装の流儀のことだ。仕様や機能要件の前に、まず痛みがある。 痛みがあるから、何を作るかが決まる。何を捨てるかも決まる。そして、どこで「完成」 と言えるかが決まる。 不便は発明の母である。

もちろん、はじめは好奇心ドリブンでもいい。手を動かしてみないと見えてこないものがある。 新しい技術や「こんなものが作れたら面白そう」という気持ちは、ものづくりの原動力となる。 だが、その先、完成まで持っていきたいのなら、好奇心は痛みに置き換わっていなければならない。 誰の何の痛みを引き受けたのか。それが定まらないまま 8 割で手が止まったプロジェクトを、僕はいくつもフォルダの中に眠らせている。

誰かの明確な痛み、つまり切実な課題を解決するために作るものは、完成に向かう。 ゴールがはっきりしているし、使う人の顔が見えるから、細部を詰めるモチベーションが続くのだ。 エッジケースの処理も、ドキュメントの整備も、「この人が困るから」「この人を助けたい」という理由があれば手が動く。 自分自身の痛みであっても同じだ。 毎日の不便を取り除きたいという切実さがあれば、最後の面倒な調整作業も乗り越えられる。

一方で、「技術的に面白そう」「こういうの作れたらクールだな」という動機で始めたプロジェクトは、8割くらいのところで手が止まってしまう。 コア部分が動いた瞬間に、満足感が来てしまう。 画面にグラフが描画された。音声がテキストになった。 その「動いた」という事実だけで、好奇心は満たされてしまう。 残りの2割、つまり予期せぬエラーのハンドリングや、使い勝手の微調整、セキュリティ対策、テスト、リリースに向けた地味な作業に向かうエネルギーが、急に枯れてしまう。

AI時代になり、コードを書いて「つくること」のコストは劇的に下がった。 思いついたアイデアを、その日のうちに形にできる。 しかし、「完成」のコストは変わっていない。むしろ、簡単に始められるぶんだけ、未完成のプロジェクトが量産されていく。 むしろ、簡単に始められるぶんだけ、未完成のプロジェクトが量産されていく。 Painのない場所に、完成は訪れない。誰かの痛みを想像し、それを引き受ける覚悟がなければ、最後の2割を走り切ることはできない。

厨房には、品質のしきい値があった

完成させることの難しさを考えるとき、僕はかつて料理人として厨房に立っていた頃の記憶を思い出す。

プロの規律として、誰かが食べる料理は中途半端な状態では絶対に出さない。 作るからには120%、200%喜んでほしいというのが、職人の性だ。 頭の中で考えたアイデアや、面白そうだと感じた味の仮説が、実際に作って試すと想像と全く違うことは多々ある。 食材の組み合わせが合わなかったり、火入れの加減が難しかったりする。 その差に気づき、修正していくのがプロの仕事だ。

それでも、現実の厨房では様々な制約が重なる。 満席の店内で、オーダーの伝票がずらりと並ぶ。 前菜を盛り付け、煮物焼物の具合を横目で睨みながら、オーブンの中のメインディッシュの焼き加減を見る。 あらゆるものを同時に、大量に作らなければならない。 時間、材料、注文の都合が複雑に絡み合い、どうしてもクオリティにムラが発生する。

たとえば、同じ料理を5皿同時に作るとする。 フライパンを振り、ソースを絡める。 うち4皿は完璧な仕上がりだが、1皿は火入れや盛り付けが今ひとつ納得いかない。 これを提供するか、しないか。

そこには、プライドのしきい値のようなものがある。どこを妥協点とするか。 それは、その日の状況や忙しさの中で結構揺らぐ。 待たせているお客様の顔が浮かぶ。 食材の残りも少ない。 今から作り直せば、全体の提供リズムが崩れてしまう。

忙しさにかまけて、あるいは材料や時間の都合から、クオリティを妥協してしまった経験がある。 その結果、「こんなもの出せるか」と、無言の圧力で店主に突き返される。皿を戻され、客にクレームをもらう。 料理人であれば誰しも経験があるはずだ。

完成とは、痛みが解消された瞬間のことだ

では、ソフトウェア開発における完成とは何なのだろうか。 それはきっと、誰かの痛みが解消されて、その人が満足に至った瞬間のことだ。

第三者のためのものなら、その人が満足するまで作る。 自分自身のためのものなら、自分が満足するところでやめる。 商業製品であれば、MVPとして市場に受け入れられ、料金を取っても問題がないクオリティまでは最低限引き上げる。 時間や予算、技術的な限界といった複合的な制約のもとで、完成のラインが決まるのだ。 誰の顔を見て料理を作っているのかがわかれば、どこまでソースを煮詰めるべきかが自然と決まるように。

好奇心だけで進んだプロジェクトは、いつまでも開発し続けられる。 とくにAIは、開発を加速させる一方で、次々と機能を追加するように誘惑してくる装置でもある。 「こんな機能も実装できますよ」「このライブラリを使えばもっとリッチになりますよ」と、コンテキスト次第でその誘惑は無限に広がる。 ターミナルに流れるAIの提案を見ていると、つい「じゃあ、それもやってみようか」と乗せられてしまう。 そうやって本質から離れた機能ばかりが膨らみ、いつまでたっても終わらない。

この誘惑を断ち切り、完成に向かうためには、想定した利用シーンにおいて早く実際に使ってみる体験をするしかない。

Claudeから「ここまでで動きます」とコードが返ってきた時、こうするといい。 MVPの段階で、自分で実際にテストし、体感で満足するかどうかを見極めるのだ。 キーボードを叩き、マウスを動かし、画面の反応を見る。 動作の軽快さ、情報の見やすさ、手触り。 画面の向こう側のAIがどれほど優秀でも、満足の所在を判断するのはユーザーである僕自身の体感でしかない。 AIはコードを書いてくれるが、「これで十分だ」という感覚は教えてくれないのだ。

満足する対象が明確に定まっており、その対象が満足するラインに到達したと判断できる状態であれば、それが完成だ。 自分の中にある「これでよし」という感覚、あるいは、目の前にいる誰かの「助かったよ」という言葉。 その手応えを得たとき、ソフトウェアはようやくひとつの区切りを迎える。

プロダクトの思想は、細部に宿る

完成の判定基準は、単なる機能の充足ではない。 そこには、つくり手の価値観や哲学が色濃く反映される。

たとえば、Webフォームの性別欄を一つ取るだけでもそうだ。 男性・女性のバイナリで書くか、その他などの複数選択にするか。 あるいは、自由記述にするか、そもそも性別を聞かないか。 これは単なる技術選択ではなく、どういう価値観を持った開発者であり、サービス提供者なのかの表現だ。 どういう価値観を持った開発者であり、サービス提供者なのかの表現だ。 思想や哲学が暗に表現され、標識化される。

僕自身にも、似たような経験がある。 僕はWeb開発者として、アクセシビリティに非常に強い関心を持っていた。 理由は単純で、身の回りに障害を持つ友人や知人がこれまで多くいたからだ。

会社や仕事で求められずとも、アクセシビリティをどこまで実装してデリバリーするかを強く意識して取り組んだ時期があった。 スクリーンリーダーでの読み上げ順序を調整し、色のコントラストを確認し、キーボードだけで全ての操作ができるようにコードを書き直す。 アクセシビリティは、業界によっては意識されにくい。 クライアントからの要望にも含まれていないことが多い。 だが、自分自身の美学や哲学として、どこまで対応するか、どのレイヤーでどこまでやり切るかという完了基準を自分で決める。 自分自身の物差しを持って、哲学的に、思想として実装していく。

誰も求めていないのに、なぜそれをやるのか。 それは、自分の中の友人や知人の顔が、Painの所在を定めているからだ。 「あの人がこのサイトを使おうとしたとき、ここでつまずくかもしれない」 そんな具体的な誰かの顔が浮かぶからこそ、手を抜くことができない。

Painが外部から与えられているとき、たとえば顧客からの要望や、上司からの指示、あるいは法令による義務であるときは、完成の判定が借り物で済む。 チェックリストを満たせば、それで終わりだ。 だが、Painを自分で発見して引き受けたとき、完成の判定もまた自分の中の思想で立てなければならないのだ。 どこまでやれば十分なのか。どこで妥協するのか。 そしてその選択は、サービスの細部、性別欄に、アクセシビリティ対応の深さに、つくり手の標識として残る。 コードの一行一行に、僕たちが何を見て、何を大切にしているかが刻み込まれていくのだ。

つくり手の哲学は、思想として残る

AI時代になり、僕たちは本当に何でも作れるようになった。 思いついたアイデアを、数時間で形にできる。 魔法のような道具を手に入れたからこそ、何を引き受け、何を諦めるかが哲学になるのだ。

プロダクトやサービスは、「誰かの痛み」を解消するためのものだ。 誰のために作っているのか。誰の痛みを和らげたいのか。その人の顔を思い浮かべながら、自分が「これなら出せる」と頷けるかどうか。

痛みや苦しみ、不便さを感じないAIに、本当の意味でのプロダクト・サービス開発ができるのだろうか。 設計に、実装に、そこに思想や哲学を吹き込む人間が、必要なのではないだろうか。 ソフトウェアには、思想がこもる。哲学が宿る。

あなたが今手がけているプロダクトや機能は、どんな人のどんな痛みを出発点にしていますか？

AIのおかげで、思ったことはすぐ形にできる時代になりました。 そのぶん「誰のどんな課題や違和感に敏感でいたいか」「自分の手をどこまで届かせたいか」が、一つひとつのプロダクトに自然とにじみ出る気がしています。

このブログでは、AI時代のものづくりに欠かせない人間の役割について、現場で感じたことを等身大で綴っています。 もし興味があれば、よければ下のボタンから購読をよろしくお願いします。

最後まで読んでいただき、ありがとうございます。

あなたが完成させたかったのに、8割のところで手が止まってしまったプロダクトや機能は何ですか。 もしよければ、コメント欄で教えてください。

この記事に何か感じるものがあったら、いいねやシェアをしていただけると嬉しいです。

背景にある考え方

本論で深く展開できなかった、しかし議論の地下水脈になっている概念や思想、参照したツールを、入口として置いておきたい。

本文で言及したツール・参照点:

本文では深掘りしなかったが、本論を支えている概念:

※ 本原稿は、著者である私(瀧坂義尚)の実体験を、AI によるインタビュー取材で深掘りし、AI との協働で構成・執筆した上で公開しています。Powered by Gemini and Claude.

※ 本文中の動画は、著者が開発した CONTXXXT アプリの実際の動作を撮影したものです。

推奨タグ: #AI #LLM #ソフトウェア開発 #プロダクトマネジメント #エンジニアリング #DX #AX #ものづくり

Substack 版