いろんな人からオススメだよと紹介された「正しいものを正しくつくる」をようやく読み終えました。ちょっと文章が硬いので咀嚼するのに苦労してしまい、読むのに２ヶ月ぐらいかかりました。

ただ、非常に面白い１冊でした。この本が５年前に出ていたら、前職のロックオンを辞めなかっただろうなと思うくらい、いろんな気付きを得ました。

もともと出身がエンジニア畑で、プロダクトマネジメントやソフトウェア開発に関する書籍は結構読みます。ここ数年を振り返っても、この本は間違いなくソフトウェア開発の書籍としてNo.１ではないでしょうか。

ただ、FMCG系を中心とする様々なメーカーの方々と「ものが売れないんだけどどうしたら良い？」と相談を受ける経験に照らすと、この内容を『ものづくり全体』に当てはめるには少し物足りなかったです。

今回のnoteは、自分なりにも「正しいものを正しくつくる」とはどういうことなのか考えたいと思います。

システム開発で苦労した個人的経験談

前職でシステムを作っていた約10年間、プログラマ、リーダー、プロジェクトマネージャ、企画など様々な職業を経験しました。中でも一番長かったのは、要求定義担当でした。

主に営業、サポートの「お客さんはこれが欲しいと言っている」「この機能があるとお客さんは喜んでくれる」という意見を集約し、掛かる工数や開発難易度を計算するのが役目でした。精査を終えると、担当役員に「この機能は工数がこれくらい、難易度がこれくらい」と報告して、何を作るのか意思決定を仰いでいました。

当時この役割が求められたのは、営業、サポートの「この機能が欲しい」を開発の言葉に落とし込む必要があったからです。人数も少ないベンチャー企業だったので、そういう「翻訳者」が居た方がスムーズにプロジェクトが立ち上がるという判断がなされていました。

以下のように１本のプロジェクトを２〜３ヶ月、３名（10〜15人月が目安）で遂行するので、事前に１人で「先行プロジェクト立ち上げ」を行い、スコープを定義し、影響範囲を調査し、リスクを精査する「支援者」のような役割も担っていました。

「言っている機能は分かるけど、どう実装して良いか分からん」

みたいなリクエストもままあったので、クリエイティブチームの力を借りてまずモックを作成した機会も１度や２度ではありません。というかモックで動いている感じを見せないと後から「やっぱり違う」と揉めるので、なるたけ作るようにしました。

あとはお客さんにモックを提示して「こういうのどうですか？」と聞いて回っていたはず。やっぱ改修後のイメージがあると便利なんですよね。

ちなみに現在は、こうした役割を担うのが個人ではなく部署になったと聞いています。

さて、この「座組み」で苦労した点があります。翻訳でも調査でもありません。何を作るかは１番揉めるんですが、苦労したとは感じていません。

「声の大きい人の意見が通る」と陰口を言われていたのも知っています。各部門の声を均等に聞きましたが、売上に繋がらないと意味が無いので、結果的には「平等じゃない」と感じた人もいたでしょう。

「売上につなげる」とはどういうことか。サブスクリプションモデルの性質上、重要なのは①解約されない、②新規獲得につながる、③ランクアップする、この３点でした。すなわちマイナスを防ぐのと、プラスを積み増す、この観点が売上増だという認識を持っていました。

それよりも苦労したのは「欲しいと言われた機能を苦労して開発したのに全く使われない問題」を、どうすれば解消できるかでした。

邪悪なウォーターフォール、救世主のアジャイル

「欲しいと言われた機能を苦労して開発したのに全く使われない問題」を、どうすれば解消できるか。私が着目したのはアジャイルでした。

当時、プロジェクトの進行方法はウォーターフォールを採用していました。前工程と後工程をしっかり橋渡しすれば、これほど堅牢なモデルはないのですが、大きく４つの問題点を感じていました。

①時間がかかる問題。着手からリリースまで２〜３ヶ月ですが、「こういう機能が欲しい」とお客さんが声をあげた時点から遡れば、およそ半年はかかっています。デジタルマーケティング業界で「半年待ってください」は厳しいなぁ…と考えていました。

②手戻りが多い問題。特にUIについては一家言を持つ人が多く、あの人に見せたら手戻り、違う人に見せても手戻り、足元はフラフラでした。なんで堅牢なはずのウォーターフォールでこんなことに！？と考えていました。

③コードだけ書きたいエンジニア問題。設計フェーズだからドキュメント書こ？テストフェーズだからテストしよ？と言っても聞かない人がいました。いっそフェーズに捉われず、書きながら考えてテストすれば良いか…と考えていました。

④ウォータフォール邪悪だと思われている問題。これは③に紐付きますが、コードだけ書きたい人ほどウォータフォールを「ダサい」「時代遅れ」だと邪険に扱っていました。ウォータフォールを止めれば上手くいくと考えている人たちがいました。

これら４つを打破できるのではと考えて（④の声に苛立ってアジャイル導入したらやるんだな？という思惑もあり）、機を見ては「アジャイル風に進行しませんか？」と提案していました。（宇野さんに）

「正しいものを正しくつくる」では、アジャイル開発を以下のように定義しています。

アジャイル開発が何なのかをごく簡単な言葉でまとめると、「早く（ただし少しだけ）形を作る」活動だと言える。反復期間（イテレーションまたはスプリント）ごとに、自分たちが何を作ればよいのかを整理し、チームと関係者で合意する。

まずは軽く作って、反響を見て、進むか止めるかすれば良いと考えました。しかし結果的には提案は採択されませんでした。

当たり前です。問題の本質は「複数ある候補の中で何をつくるか」という選択だからです。私たちはどうやら選択を間違えているか、そもそも選択の内容自体が間違えているのです。

アジャイルを導入したら、漏れなく「欲しいと言われた機能を苦労して開発したのに全く使われない問題」も解消したか？　いや、しないでしょう。

アジャイルを導入しようものなら、永久に「止める」という選択を取り続けて、何もリリースされなかったでしょう。だったらまだ何か出して、プレス打って、代理店に足繁く通った方がマシかもしれません。

つまり、私たちの立てた仮説はだいたい間違っていた。仮説の土台となる欲しい機能は、幾つかは本当に欲しいものがあったにしろ、実はそこまで…なものもあった。それが問題の本質だったと今にして思うのです。

とは言え、プロダクト自体は順調にグロースし続け、インターネット広告市場の拡大に連動して、売上も拡大し続けていたので傍目には成功していたように見えたはず。

なぜ仮説をだいたい間違っていたのか？

「正しいものを正しくつくる」の中で、このような一文があります。

　置かれている状況や環境を把握し、最も分の良さそうな選択をすることが、私たちにできることだ。想定しているユーザーはどんな思考や行動をとっているのかを踏まえて、機能を検討する。ユーザーの観点だけではない。ビジネスの観点として、費用対効果を想定して実現手段や機能の作る順番を決めなければならない。その状況、環境において考えられる複数の選択肢のうち、最も確からしいものを選び出す必要がある。
　こうした選択肢の整理が「仮説を立てる」という行為であり、何が確からしいのか見立てるために実験することを「検証」と呼ぶ。仮説は答えではなく、実体としては問いである。「こういう課題があるのではないか？　その課題はこうしたソリューションで解決できるのではないか？」という問いだ。いずれの仮説も間違えている場合はある。検証活動も必ず正解を見つけられる行為ではない。それでも、何の状況把握にも務めず、適当に機能を片っ端から作っていくわけには当然いかない。

おっしゃる通りなのです。頷き過ぎて、首がもげます。

しかし「仮説を立てて」プロジェクト開発を進めたのに、なぜか的を外した回数の方が圧倒的に多かった。なぜでしょうか？

理由は単純で、立てた仮説の精度が悪かったのです。「それじゃない仮説」ばかり検証していたのです。もっと言えば、お客様の本質的な不満、プロダクトでは充たされない心を拾いきれなかったのです。

そもそも、どのようにして仮説を作るでしょうか。

市場に出て、今どのような流れにあるのかを把握したり、先ほど引用したように「想定しているユーザーはどんな思考や行動をとっているのか」を知るためにお客様や非消費者の声を聞いて何を考えているか何が不満なのか拾ったり、様々な考えを集約して仮説を作ります。

しかしお客様や非消費者の意見は①市場が成熟していて、②ブランドはどれもだいたい一緒で、③それらで消費者が充たされている場合において、あまり真に受けてはいけないという鉄則があります。

本当はどれでも良いのに、無理やり不満を考える。選ばない理由、買わない理由を考える。競合を選ぶ理由を考える。本当は「なんとなく」なのに、無理やり言語化する。

消費者は無自覚にウソをつきます。いや、ウソというか、結果として「本当はそうじゃないよね？」という言葉を口にします。

そうして出てきた表層的な意見を真に受けて仮説を考えても、全く意味がないのです。だから仮説の精度が悪くなってしまう。

仮説と一口で言いますが、ざっくり２種類のフェーズあります。立てた仮説を検証するフェーズと、そもそも仮説を探索するフェーズです。仮説探索して見つけた仮説を検証する。これは鉄則の流れです。そして私たちの落ち度は、仮説探索を明らかにサボった点にあります。

さらに厄介なのは、私レベルが思いつきそうな仮説は、すでに他の誰かが思いつき、既に実装されてしまっているのです。差を無くすために実装する機会はあっても、差をつけるために実装する機会はほぼ無かったと思う。

どうすれば筋の良い仮説（他の会社が着目していない目新しい仮説）を発見できるか？

これは喫緊の課題だと思うのですが、本書ではガッツリとスルーされています。「仮説検証の前に行う状況調査」としてエスノグラフィーが取り上げられているぐらいです。正直、なぜエスノなのか理由付けもされておらず、取って付けた感は否めない。

以下、抜粋します。

　ただしこうした活動は仮説検証ではない。実際には、仮説を立てて参与観察に臨むこともあるが、状況を理解するためという目的であれば、それは検証ではなく調査だ。調査によって得られた情報にもとづき、次に最初の仮説を立てることになる。

これは思想の問題なのかもしれませんが、市谷さんは仮説を「検証」のみで捉えているようですが、私は仮説を「探す（探索）」「検証」で捉えています。

仮説はどこから生まれるのか？　「探す」を絶対におざなりにしてはいけないと思うのです。直ぐに見つかる仮説は、既に実装されている仮説なのですから。

これは市谷さんにどこかで会うタイミングがあればお聞きしたいのですが、仮説を検証のみとするか、探索を含めるか、それは定義の問題だとして、みんなが思いついていないような「鋭い仮説」をどうすれば思いつくのでしょうか。

もし調査から生まれるのであれば、そこを徹底して掘り下げ無いと、結局は「みんな思いつく当たり前仮説」しか生まれないのではないでしょうか。それでは結局、他社と同じサービスになりませんか？

みんなでワイワイと話をして仮説を何万本生み出そうが、既に実装されていたら何ら差別化、独自性は確立されません。仮説を検証するよりも、検証に耐えうる仮説をどうやって生み出すかが何倍も重要だと思うのです。

キリンビールの「本麒麟」がバカ売れしてから、仮説なんかさておいて、サントリーが後追い戦略で「金麦ゴールドラガー」を出すというケースもあります。しかし大半は、FMCG系を中心とする様々なメーカーの場合、シーンや情緒価値に起点して「こういう可能性は無い？」という仮説探索を大事にされています。

市谷さんは、消費者に振り回された経験が無いのだろうか…うーむ、と思いました。

ちなみに、どのようにして仮説の精度を上げていくのか。本書では仮説キャンバスというフレームワークを紹介しています。こちらは市谷さん自作だと考えられます。

課題は顕在課題、潜在課題の２つに分かれています。

対象者が既に自ら認識している課題、これを「顕在課題」と捉える。一方、対象者の多くが自分で認識できていない課題、こちらは「潜在課題」とする。顕在課題は明らかになっている課題なため、対象者が何らかの解決行動をとっている場合が多い。

この下りは「？」でした。本人が認識していない潜在課題を、どうやって本人でない私たちが言語化できるというのでしょう。そこがわかりませんでした。エスノでしょうか、デプスでしょうか。

おっしゃっていることは分かるのですが、それを見つける手段の提示が無い限り、キレイゴトではないだろうか、と私は悩んでいます。

WEBサービス、どれもだいたい良いんじゃない？

FMCG系メーカーの場合、同じブランドでも年に何回か新商品を出します。それでも「作り過ぎ」と言われている方です。

しかしWEBサービスの場合、人と金さえあれば、無尽蔵に何回でも新サービス、新機能をローンチできます。どんな差別化機能も、金にモノを言わせて同質化ができる時代です。

私の勤めるデコムでは、成熟市場が多い日本を「だいたい良いんじゃないですか時代」と定義しています。どのブランドも十分に成熟して完成度も高く、どれもだいたい良い。いよいよWEBサービスも、そうなりつつあるのでしょうか。

これは私の感覚でしかないのですが、「正しいもの」は、だいたい実装されているのではないでしょうか。

その結果、ECサイトはどれもだいたい同じ、ソーシャルゲームはどれもだいたい同じ、キュレーションメディアはどれもだいたい同じ、何とかPayはどれもだいたい同じ。

ブランド化に成功している日本発のWEBサービスって、どれぐらいあるんでしょう？

2007年からWEB系エンジニアとして仕事を始めたのですが、その当時はスマホ前夜でしたから、インターネット＝オタクかつ先端という感じでした。ネット自体が新しいものという扱いでした。

いつの間にか、そうじゃなくなっているんですよね。直ぐパクれる。直ぐ同質化される。そんな状況で、今までのような企画の建て方してたらダメなんだと感じています。