サビ始まりのエンジニアリング

音楽の構造はサブスクにより変わった

音楽の消費構造はサブスクによって変化した。

以前の音楽体験では、アルバムや楽曲全体の流れの中で、音楽的構造が配置されていた。

しかし、サブスク隆盛以降は状況が変わった。

大量の楽曲が並び、ユーザーはいつでも次の曲へ移動できる。

その結果、最初の数秒で「聴き続ける価値があるか」が判断されるようになった。

楽曲は、最も価値を感じてもらいたい部分を早く提示する方向へ変化した。

いわゆる「サビ始まり」である。

しかし、ここで重要なのは、

サビから始まることと、サビだけで曲が完成することは別である

ということだ。

サビ始まりの曲にも当然、曲全体を成立させる構造が存在する。

変化したのは価値を提示する順序であり、価値を成立させる構造そのものではない。

では、エンジニアリングはどうだろうか。

AI時代の「サビ始まり」

AIによって、ソフトウェア開発の景色は大きく変化している。

プロトタイプやMVPを作る速度は、以前とは比較にならないほど向上した。

画面を作る、APIを作る、データをつなぐ。

一連の操作ができるものを短時間で生成できる。
これは大きな価値である。

アイデアを形にするまでの距離は短くなり、仮説検証の速度は上がった。

しかし、ここで考えるべき問いがある。

その「動くもの」は、本当に完成品なのだろうか。

MVPは完成品ではない

MVPという言葉は、しばしば誤解される。
MVPは「完成品を小さくしたもの」ではない。
不確実性を減らすための検証物である。

MVPには、意図的に存在しないものがある。

• 拡張性
• 運用設計
• 障害対応
• セキュリティ設計
• 非機能要件
• 保守性

それは欠陥ではなく、目的に合わせた判断である。

問題は、MVPを作ることではなく、MVPが完成品として認識されることだ。

動くものが持つ強烈な説得力

人間は、存在しないリスクより、存在する成果物を評価する。

設計書に書かれた将来の問題よりも、目の前で動く画面の方が強い説得力を持つ。

これは合理性ではなく、人間の認知の性質である。

だからこそ、AI時代の問題は「作れること」ではない。

作れてしまったものが、実際以上の価値を持って評価されることである。

動く画面がある、操作できる、デモできる、価値が見える。

この事実は非常に強い。

すると、自然に次のような認識が生まれる。

「もう使えるのではないか」
「これで十分なのではないか」
「これだけ早く作れるなら、開発コストも下げられるのではないか」

これはステークホルダーの理解不足だけが原因ではない。

企業活動において、速度やコストを評価することは当然だ。

問題は、評価対象が「見える成果物」だけになってしまうことだ。

見えない価値は、不要なものではない

ソフトウェアには、動いている画面だけでは見えない価値が存在する。

象徴的なのが、PoCやMVPから本番運用へ移行する段階である。

技術検証の段階では、目的を達成するために必要最低限の実装で十分な場合がある。

データを取得できる、処理が実行できる、画面上で結果を確認できる。

それだけで、仮説検証としては成功である。

しかし、それを実際のサービスとして提供する場合、求められる条件は変わる。

• 障害が発生した場合に復旧できるか
• 想定外の入力に対して安全に動作するか
• データの整合性を維持できるか
• 適切な権限管理ができているか
• 将来的な変更に耐えられる構造になっているか

これらは、最初に動くものを作った段階では見えにくい。

しかし、プロダクトを継続的に利用するためには不可欠な要素である。

動くことは、必要条件である。

しかし、それだけでは十分条件ではない。

最も危険なのは、評価軸の短絡

AIによって開発速度が向上すること自体は問題ではない。

問題は、動くものが存在した瞬間に、そこに含まれていないものまで「不要だったもの」と評価されてしまうことだ。

本来、MVPに存在しないものは、価値がないものではない。

検証段階では必要なかっただけであり、
プロダクトとして成立させる段階では必要になる。

しかし、完成品として認識された瞬間、
それらは「追加作業」として扱われるようになる。

本来、

MVPを作る 
↓
価値を検証する
↓
不足しているものを判断する
↓
プロダクトとして成立させる

となるところを、

MVPを作る
↓
動いた
↓
完成した

としてしまえば、話は変わる。

そして、認識も変わる。
その影響はステークホルダーだけではない。
エンジニア自身にも起こりうる。

「この程度でよいのかもしれない」

という判断である。

完成とは何かを定義する

AIによって、成果物を作る速度は大きく向上した。
しかし、それによって「作ること」と「完成させること」の距離が縮まったわけではない。
むしろ、その間にある判断の重要性は増している。

その成果物は、何を満たしているのか。
何を満たしていないのか。
どの条件を満たせば、本番で成立するのか。

これを判断し、関係者と認識を合わせることが必要になる。

MVPを提示すること自体に問題はない。

問題は、MVPであることを説明せず、それが完成品であるかのように扱われることである。

動くものを作る能力だけではなく、動くものが何を意味するのかを定義する能力。

AI時代にエンジニアへ求められるのは、そこにある。

MVPを完成品として扱う開発フローの先にあるもの

評価軸は、やがて開発プロセスそのものを変える。

「まず動くものを作ればいい」
「足りない部分は後から考えればいい」

この考え方自体は、MVPという手法の中では間違っていない。

問題は、それが開発プロセス全体の前提になってしまうことである。

MVPを完成品として扱う文化が定着すると、開発における評価基準そのものが変わる。

早く動くものを出せる人間が評価される。

しかし、その速度は本来、不確実性を減らすための速度である。

それがいつの間にか、完成品を作る速度として扱われるようになる。

すると、設計や検証に必要な時間は、価値を生む工程ではなく、遅延要因として認識される。

ここで初めて、問題は個々の実装品質ではなく、開発文化そのものになる。

そうなると、エンジニアリングの対象そのものが変質する。

本来、ソフトウェア開発とは、現実の業務や利用者の中で長期間成立する仕組みを作ることである。

しかし、MVPを完成品として扱う文化では、「今動くものを作ること」が目的になる。

その結果、後から必要になる判断や設計は、追加コストとして扱われる。

しかし、それらは本来、削減できるコストではない。
プロダクトを成立させるために必要な工程である。

今、必要なこと

AIによって短時間で成果物を作れる時代だからこそ、何を作ったかだけではなく、何を作っていないのかを認識することが重要になる。

AI時代に必要なのは、成果物を作る能力だけではない。

目の前にある成果物が、何を満たしていて、何を満たしていないのか。
その差分を認識できることが重要になる。

なぜなら、これから増えるのは「作れない問題」ではなく、「作れてしまったものを誤って評価する問題」 だからだ。

人間は、AIが生み出した成果物を、そのまま受け入れるのではなく、現実の要求や制約に照らして評価しなければならない。

そこから、生成された成果物をプロダクトとして成立させるためのエンジニアリングが始まる。

サビを作ることと、曲を完成させることは違う

AIによって、サビを作る速度は上がった。
これは素晴らしい変化だ。

しかし、サビを作る速度と、プロダクトを成立させる速度は同じではない。

サビからエンジニアリングを始めることが問題なのではない。

問題は、
「サビを聴いただけで、その曲全体が完成していると思ってしまうこと」
である。

サビだけを聴いて判断し、満足する。
音楽を楽しむ文脈では、これは許される。

しかし、その構造はエンジニアリングでは許されないのだ。

エンジニア達の「完全に理解した」Talk #79 にて本記事のLTを行いました。