最近はAIのおかげで、とりあえず動くものを作ってユーザーに見せる、というやり方がかなり手軽になりました。それ自体はいいことだと思っています。ただ、見ていてずっと引っかかっていることがあります。

自分は受託開発のPMとして、クライアントから直接請けるプライム案件を70件ほど回してきました。目的と課題を整理して、現場の業務をヒアリングし、業務フローに起こす。そこから必要な機能を精査して、やるもの、やらないもの、やるけど今じゃないものに振り分け、クライアントと合意する。合意したものをエンジニアやデザイナーと形にして、納品まで持っていく。何を作るかを決めるところから納品までが、自分の仕事です。

その立場から見ていて引っかかるのは、作るのが速くなったことそのものではなく、決めないままでも作れてしまうようになったことです。しかも、決めなかったところは空欄のままにはなりません。誰も決めていないのに、もう決まった状態で動き出してしまう。これがなぜまずいのか、ではどうすればいいのかを、順を追って書いていきます。

UXの5段階モデル

話の土台として、Jesse James Garrettの『The Elements of User Experience』（邦訳『ウェブ戦略としての「ユーザーエクスペリエンス」』）に出てくるモデルを使います。ウェブのUXの本ですが、業務システムを考えるときにもそのまま使えます。知っている人も多いと思うので、ざっくりだけ。

プロダクトは5つの層が積み重なってできている、という考え方です。

※画像はグッドパッチさんから拝借してます。

下から順に、戦略（何のために作るのか、何をもって成功とするか）、要件（そのためにどんな機能が必要か）、構造（それをどう組み立てるか）、骨格（画面のどこに何を置くか）、表層（見た目）の5つです。工程で言えば、下の層ほど上流で決めるものです。下が決まらないと上は決めようがない、というのも教科書どおりの話です。

構造だけ、少し補足しておきます。この記事でいちばん大事になる層なので。Garrettの言う構造は、情報の整理の仕方と、操作したときのシステムの振る舞いの設計のことです。これを業務システムに当てはめると、中心になるのはデータの持ち方だ、というのが自分の読み替えです。この記事で構造と言ったら、どんな項目を、どう関連づけて、どう残すか、のことだと思ってください。

影響が大きい層ほど、失敗は見えない

「下の層ほど影響が大きい」とはよく言われます。自分はその影響の大きさを、二つの問いで見ています。失敗したときに気づけるか。気づいたあとで取り戻せるか。

上の層から順に並べると、こうなります。

層	気づけるか	取り戻せるか
表層・骨格	○ 使った人が教えてくれる。toCなら離脱率に出る	○ その画面か周りを直せば済む
構造	× ほぼ気づけない	× 過去のデータは戻らない
要件	△ 半々	△ 声が上がった分は足せる
戦略	× 失敗と認識すらされない	× 気づかないまま続く

気づけるかどうかを分けているのは、使った人が声を上げてくれるかどうかです。表層や骨格の失敗は、使っているその場で本人が困るので、すぐ声になります。構造や戦略の失敗は、画面を使っている人が困らないので、声になりません。

要件が半々なのも同じ理屈です。使う人に必要な機能なら、足りなければすぐ声が上がる。声にならないのは、後から数字を見る人や、データを受け取る別の部署が必要とするものです。こっちはたいていデータの持ち方の話なので、見えにくさは構造と変わりません。

構造の失敗が見えないというのは、例えばこういうことです。この記事では、このあとずっとこの例を使います。

対応が回らなくなってきたサポート窓口に、問い合わせ管理のシステムを入れるとします。対応状況は「未対応・対応中・完了」のステータス1項目で持たせました。ステータスは変わるたびに上書きされるので、残るのは今の状態だけ。画面上は何も困らないし、誰からも文句は出ません。

ところが半年後、マネージャーから「一度完了にしたのに、また戻ってくる問い合わせが多い気がする。どれくらいあるか出してほしい」と言われる。

これでは出せません。今から履歴を取り始めても、過去半年分はもう戻ってこない。気づけないうえに、取り戻せないんです。

この失敗は、半年間ずっとそこにありました。でも、誰にも見えていなかった。困るのは画面を使う人ではなく、あとから数字を見る人なので、それまで誰も声を上げません。存在しないデータは、欠けていることにすら気づけないんですよね。

戦略の失敗は、もっと見えません。失敗として認識すらされないからです。

営業日報のシステムを作り直して、入力が3分で終わるようになったとします。現場は喜んで、入力率も上がった。でも、日報で何を知りたいのかは決めていなかった。失注の理由を残す項目がなく、半年分の日報は営業会議で一度も使われない。それでも、使われているし評判もいいので、誰も失敗だとは思いません。現場の声だけを聞けば、むしろ成功です。何をもって成功とするかが決まっていないと、戦略が間違っていても、そのことにすら気づけないんです。

影響が大きい層ほど、失敗が見えない。自分が下の層からきっちり決めるべきだと思っている一番の理由はこれです。

誤解のないように言っておくと、表層がどうでもいいという話ではありません。toCなら表層の出来で数字が大きく変わるのは当然です。ただ、声で直せる層と、声では直せない層がある。声で直せない層は、声を待たずに自分で決めておくしかない。どの層が大事かではなく、どの層から決めるかという、順番の話です。

モックは「表層の先出し」じゃない

じゃあ、下の層を全部決め切ってからでないと作れないのかというと、そういうわけでもありません。決めるのは仮でいい。ここでモックの話になります。

「とりあえずモックで見せよう」と言うと、表層だけ先に作って確認しているように聞こえます。でも実際に画面を1枚描こうとすると、どんな項目があって、それぞれがどう関連していて、どの順番で入力されるのかを決めないと描けないんですよね。

つまり、モックを作った時点で、構造はもう仮で決まっているんです。モックで確かめているのは見た目じゃなくて構造のほう。省いているのは層じゃなくて、実装です。

問い合わせ管理のモックを現場の人に触ってもらうと、「この項目、うちは2種類あるんですけど」とか「担当者って1件に1人とは限らないですよ」みたいな話が出てくることがあります。ヒアリングでは出てこなかった話です。本人にとっては当たり前すぎて、聞かれても思い浮かばない。こういう話が出たら、構造に戻って直す。

なので自分は、モックを、順番を飛ばすための道具ではなく、構造の答え合わせを早くするための道具だと捉えています。

ただ、モックを過信するのも危ないです。画面に出ないものは、描いても決まりません。さっきのステータスの履歴はどの画面にも出てこないので、モックを触ってもらっても、たぶん誰も気づかない。モックが見えるようにしてくれるのは、見えない失敗のうち、画面に顔を出す分だけです。画面に出ない分をどう決めるかは、このあと書きます。

AIに作らせると、構造は「決まってしまう」

AIを使えば、要件も構造も決め切らないまま、動くものを作ってユーザーに見せられます。いわゆるバイブコーディングです。速いに越したことはないので、これ自体は悪いとは思っていません。

ただ、モックとは決定的に違うところがあります。

	モック	AIで作ったもの
構造を決めるのは	自分（仮で）	AIが埋める（人は誰も決めていない）
そのまま使えるか	使えない	使えてしまう
データ	溜まらない	残していないものは、使い始めた日から失われ続ける

まず、構造を誰が決めているか。自分で画面を描くなら、少なくとも画面に出る項目は、自分で決めるしかありません。ところがAIに「問い合わせ管理を作って」と頼むと、項目もデータの持ち方も、もっともらしく埋めてくれます。ステータスを1項目で上書きする作りになっていても、画面上は何も困らないので、誰も違和感を持たない。「履歴は残さない」という判断は誰もしていないのに、それはもう実装されています。

次に、表の下の2行です。モックはそのままでは使えないので、確かめ終わったら捨てるだけです。構造が間違っていても、データの面で失うものはありません。ところがAIで作ったものは、そのまま使えてしまう。使い始めればその日から業務のデータが入り始め、残す作りになっていないものは、その日から失われていきます。最初の表で構造の失敗を「取り戻せない」としたのは、過去のデータが戻らないからでした。AIで作ったものでは、その取り戻せない期間が、使い始めた初日から延び続けます。

作って、見せて、直す一周は格段に速くなりました。声が届く画面はどんどん良くなる。その裏で、声が届かない下の層は、誰も決めていないまま積み上がっていく。見えない失敗が、作った瞬間に生まれているわけです。

冒頭で書いた「誰も決めていないのに、もう決まった状態で動き出してしまう」というのは、このことです。

画面に出ないものは、書いて決める

じゃあどうするか。自分は、決める工程を飛ばしている自覚を持つところからだと思っています。そのうえで、飛ばした層について「たぶんこうだろう」を書いておく。これを、ここでは仮説と呼びます。モックのところで「決めるのは仮でいい」と書いた、その仮の決定のことです。

仮説というと戦略の話に聞こえるかもしれませんが、ここで言う仮説は戦略だけではありません。戦略から要件、要件から構造へと続く、層と層のつながりのことです。

ここで思い出してほしいのが、半年後のマネージャーの「一度完了にしたのに、また戻ってくる問い合わせが多い気がする」という一言です。そもそも問い合わせ管理を入れたのは、対応が回らなくなってきたからでした。なぜ回らないのか。その答えの候補が、この一言です。つまりこれは、半年後に急に湧いた疑問ではなく、作る前に書けたはずの戦略の仮説でした。

作る前に書いていれば、こうつながります。

戦略の仮説をひとつ書いただけで、画面のどこにも出てこない変更履歴が、残すべきものとして決まります。モックを何度触ってもらっても誰も気づかず、AIに任せれば上書きで作られていた、あの履歴です。画面に出ないものは、描いても決まらない。書いて決めるしかないんです。

もちろん、作る前に書く仮説がこれと同じになるとは限りません。でも、何かしらの仮説を書けば、それを確かめるために何を残すかを、作る前に決めることになる。半年後に数字を出せなかったあの失敗は、仮説が外れていたからではなく、そもそも仮説が書かれていなかったから起きたものです。営業日報で失注理由の項目がなかったのも同じ構図で、日報で何を知りたいのかという戦略が書かれていなかったから、要件にも構造にも降りてこなかった。

書くのは、この図の3つの箱だけで十分です。何が問題だと思っていて、何で成功を測るのか。そのために何を出せるようにして、何を残すのか。仕様書のようなものは要りません。

ただし、作る前に書く。モックのところで、構造の答え合わせと書きました。答え合わせは、自分の答えを先に書いておかないとできません。頭の中にあるだけだと、答えを見たあとで「最初からこうなると思ってた」と、都合よく書き換わってしまいます。

作ったあとにも、やれることがあります。AIに作らせると、誰も決めていない決定が黙って実装される、と書きました。それなら、その決定をAIに言葉にしてもらえばいい。

自分はコードが読めないので、実装の中身はAIに説明してもらうことが多いんですが、AIに作らせたものなら、なおさらこれが効きます。「このアプリは、どんなデータを、どう持っていますか。ステータスを変えたとき、前の状態は残りますか」と普通の言葉で聞く。説明が完全に正しいとは限りませんが、画面からは分からなかった決定が言葉になって出てきます。それを、書いておいた構造の箱と突き合わせる。箱には「変更履歴を残す」と書いたのに、「ステータスは最新の値だけを持っています」という説明が返ってきたら、そこが外れています。コードが読めなくても、構造の答え合わせはできます。

仮説を書かずに作ると、ユーザーの声に振り回される

使い始めると、今度は現場から声が届きます。たとえば「完了を戻すたびに、理由を書かされるのが面倒」。理由の入力欄は、さっきの図の構造の箱から来たものです。でも、現場の人にとってはただの手間でしかありません。

もし、この欄がなぜあるのかがどこにも書かれていなかったら、直し方は一つです。声のとおり、理由の入力をなくす。現場は喜び、声は消えて、誰も困らない。そして、戻った理由はその日から残らなくなります。声は構造のことを教えてくれないのに、声のとおりに直すと、構造まで変わってしまう。声にならない失敗が、今度は声を聞いたせいで生まれるわけです。

仮説を書いてあれば、つながりを逆に辿れます。理由の入力は、要件の「戻った理由を出せる」のためにあって、それは戦略の仮説から来ている。だから、理由を残すこと自体は変えられない。変えていいのは、入力のさせ方です。自由記述をやめて、「回答が足りなかった」「別の問題が出た」「お客さん側の確認漏れ」くらいの選択式にする。手間は減って、理由も残ります。

声は、どこが痛いかは教えてくれても、どこが悪いかまでは教えてくれないんです。この例で痛いのは入力の手間で、悪いのは入力のさせ方でした。入力のさせ方は骨格や表層の話なので、声で直していい。理由を残すかどうかは構造の話なので、声では決められない。仮説を書いていなければ、この二つを分けられません。

分けられなければ、声が来るたびに、声の大きいところから、声のとおりに直していくしかない。そうすると、構造を決めているのは声になります。AIに任せれば構造はAIが決め、声に任せれば構造は声が決める。どちらも、自分では何も決めていません。それはユーザーの声を聞いているんじゃなくて、振り回されているだけです。

順番は変えない。一周を短くする

とはいえ、作ってみて初めて分かることがあるのも事実です。画面まで作ってみて、戦略の読みが甘かったと気づくこともある。上の層で分かったことで下の層を書き換えるのは、普通のことです。

5段階モデルのところで「下が決まらないと上は決めようがない」と書きましたが、これは一方通行の話ではありません。Garrett自身も、層の依存は両方向にあって、上の層での判断が下の層の見直しを迫ることもある、と書いています。そのうえで、下の層を完全に終えてから次へ進めとは言っていなくて、上の層の作業が下の層より先に終わらないように進めろ、という言い方をしています。

自分はこれを、手をつける順番ではなく、確定させる順番の話だと受け取っています。画面から描き始めてもいい。ただ、画面を確定させるのは、データの持ち方が確定してから。守るのはこの順番です。モックを「順番を飛ばすための道具ではない」と書いたのも、この意味です。

だから、やるべきは順番を崩すことじゃなくて、順番を守ったまま一周を短くすることだと思っています。ここまで書いてきたことをつなげると、自分の考える一周はこうなります。

問い合わせ管理で、この一周を最後まで回してみます。使い始めて3か月。履歴が残っているので、あのマネージャーの問いに、今度は答えられます。出してみると、完了から戻った問い合わせは全体の5%ほどしかありませんでした。戦略の仮説は外れていたわけです。対応が回らない原因は、別のところにある。戻るのは、仮説の図の一番左、戦略の箱です。たとえば「割り振りが一部の人に偏っているから」と書き直して、そこからもう一周します。

外れたと言えるのは、書いてあったからです。頭の中にあるだけなら、「戻りが一番の原因だとまでは思ってなかった」といつの間にか書き換わって、それで終わりだったはずです。そして、外れたと分かったのは、仮説が残せと言った履歴があったからです。仮説を書かずに作ったときは、半年経っても確かめることすらできませんでした。

当たったときも同じです。画面から作って、結果的にうまくいくこともあります。でも、なぜ当たったのか説明できなければ、次の案件で同じことはできません。極端に言えば、それは実力ではなく、作った人の趣味がたまたまユーザーに合っただけです。

仮説は、当たらなくていいんです。確かめられる形で先に書いてあれば、外れても、どこに戻ればいいかが分かる。この一周が短ければ、最初の仮説が多少粗くても、回数で詰めていけます。

受託では、この一周がどうしても長くなります。決めたことを書面にして発注側と合意し、変えるときは合意を取り直すからです。重たい仕組みですが、合意するには、何を作って何を作らないかを決めるしかありません。その重さが、決める場面を強制してくれていたとも言えます。

AIは一周を劇的に短くしてくれました。ただ、短くするときに、決める場面まで一緒に消さない。そこだけは守りたいと思っています。

おわりに

影響が大きい層ほど、失敗は見えない。だから下の層から決める。ただ、決めたことが合っているかは作ってみないと分からないので、モックで構造の答え合わせを早めにやる。画面に出ないものは、作る前に仮説として書いて決めておく。そのうえで、AIの説明とも、届いた声とも、残したデータとも、その仮説を突き合わせる。

作るのは、AIのおかげでずいぶん速くなりましたが、決めるのが速くなったわけではありません。しかも今は、決めないままでも動くものができてしまう。だからこそ、決める場面だけは、自分の手で残しておく。
それが大事なことかなって思ってます。