【お仕事ネタ】シバ丸印のこう書いたら楽じゃない？シリーズ第三弾：設計書の次は、小さく作ってみんなで見よう――頭の中の完成像ではなく、プロトタイプを囲んで議論する話――
これまでの記事では、要件定義書や基本設計書について、
後工程へ進める粒度で書くこと
外部連携では、異常系や責任分界まで具体化すること
などを書いてきました。
今回は、その先の話です。
設計書を書いた。
レビューもした。
認識合わせもした。
では、関係者全員が同じ完成形を頭の中に描いているか。
たぶん、そこまでは保証できません。
「検索画面を作る」
「申請内容を一覧表示する」
「利用者が迷わないようにする」
「必要な情報を分かりやすく配置する」
文章としては、どれも意味が通ります。
ただし、その文章を読んで想像する画面や操作は、人によって違います。
一覧表示と聞いて、表形式を想像する人もいる。
カード形式を想像する人もいる。
検索条件を画面上部に並べる人もいれば、折りたたむ人もいる。
申請ボタンを常に表示する人もいれば、入力完了後に初めて表示する人もいる。
同じ言葉を使っている。
会議でも特に反対意見は出なかった。
だから認識が合っている。
そう思いたくなります。
残念ながら、人間の脳内画面を同期する機能は、まだ標準搭載されていません。
そこで今回は、
言葉や図で整理したあと、早めに見えるものを作り、それをみんなで見ながら議論してみませんか。
という話をします。
設計書は必要。でも、設計書だけでは完成像は揃わない
先に書いておくと、これは「設計書なんていらない」という話ではありません。
要件、制約、業務ルール、責任分界、例外条件、非機能要件など、文章として残さなければならない情報は大量にあります。
設計書は必要です。
ただし、設計書の役割と、実際に見たり触ったりできるものの役割は少し違います。
設計書は、条件やルールを整理し、後から確認できる形で残すことに向いています。
一方、ワイヤーフレームやプロトタイプは、
人によって異なる解釈
操作したときの違和感
業務手順との食い違い
説明を受けなければ分からない箇所
文章では気づきにくい抜け
を表に出すことに向いています。
アジャイルソフトウェア開発宣言には、
包括的なドキュメントよりも、動くソフトウェアを
という有名な価値観があります。
これは、ドキュメントには価値がないという話ではありません。
宣言は、ドキュメントなどにも価値を認めたうえで、動くソフトウェアをより重視するという考え方です。
ドキュメントか、動くものか。
どちらか一方を捨てる話ではありません。
言葉で整理する。
見えるものへ置き換える。
見つかった論点を、また設計書へ戻す。
その往復を、早い段階から始めたいという話です。
見えるものを作ると、議論の内容が変わる
文章だけで議論していると、会話は抽象的になりがちです。
できるだけ使いやすくしましょう。
必要な情報を分かりやすく表示しましょう。
利用者が迷わないようにしましょう。
どれも反対しにくい、非常に立派な方針です。
ただし、具体的に何を変えるのかは、あまり分かりません。
ここで、簡単なワイヤーフレームを出してみます。
すると、議論が変わります。
この項目は、申請者には分からないのでは？
この順番で入力する必要がありますか？
承認者は、申請理由と金額を同時に見たいです。
差し戻された場合、どの画面へ戻るんですか？
スマートフォンから入力する人もいます。
このボタン名では、確定されるのか一時保存されるのか分かりません。
「使いやすくしましょう」が、
誰が、どの場面で、何を見て、何を判断し、次に何をするのか。
という話に変わります。
見えるものは、完成形を宣言するためのものではありません。
曖昧だった質問を、具体的な質問へ変えるための道具です。
何を確認したいかによって、作るものを変える
現場では、ワイヤーフレーム、モック、プロトタイプ、PoC、パイロット、MVPなど、さまざまな言葉が使われます。
これらの区分や呼び方は、組織や開発方法によって異なります。
そのため、名称だけを見て、
PoCだから、ここまで作るはずだ。
MVPだから、そのまま本番利用できるはずだ。
プロトタイプだから、作り捨てでよいはずだ。
と判断するのは危険です。
この記事では、ワイヤーフレームや画面モックを含む、確認のために作る試作品を広い意味で「プロトタイプ」と呼びます。
そのうえで、何が分からないのかによって、作るものを選びます。
画面配置や情報の見せ方が分からない
紙のスケッチやワイヤーフレームを使います。
この段階では、色や細かなデザインよりも、
必要な情報があるか
情報のまとまりが自然か
操作の順番が業務に合っているか
を確認します。
画面遷移や操作方法が分からない
クリックできるプロトタイプを使います。
実際にボタンを押し、次の画面へ移動できるようにすると、
次に何をすべきか分かるか
戻る場所は自然か
入力途中の状態をどう扱うか
エラー時に何が起きるか
を確認しやすくなります。
技術や方式が成立するか分からない
PoCを行います。
PoCはProof of Conceptの略で、一般に概念実証と呼ばれます。
たとえば、
必要な処理速度を出せるか
想定するデータを扱えるか
他のシステムと接続できるか
必要な精度を得られるか
技術上の制約は何か
などを確認します。
この場合、画面をきれいに作る必要はないかもしれません。
確認したいものが処理性能なら、最低限の入力と出力があれば足ります。
IPAの「DX実践手引書 ITシステム構築編」でも、何をProofするのかを明確にし、目的の曖昧なPoCを無駄に重ねないよう注意されています。
同手引書では、計画が十分であれば、必ずしもPoC自体を行う必要はないとも述べられています。
PoCを実施することが目的ではありません。
分からないことを確かめ、次の判断へ進むことが目的です。
業務全体が回るか分からない
一部を手作業で補いながら、業務の流れを試します。
利用者から見るとサービスとして動いていても、裏側では担当者が手作業で処理している場合があります。
すべてを実装する前に、
その業務自体に需要があるか
利用者が途中で迷わないか
運用担当者が処理できるか
想定外の問い合わせがどこで発生するか
を確認できます。
利用者へ本当に価値を提供できるか分からない
MVPを考えます。
MVPはMinimum Viable Productの略です。
この記事では、
実際の利用者へ最低限の価値を提供し、その利用結果から次の判断に必要な学びを得られる最小構成
として扱います。
大事なのは、単に機能が少ないことではありません。
価値を提供し、結果を確認し、次の改善につなげられるところまで、一つの流れが成立している必要があります。
ログイン画面だけ作れば、確かに機能は少ない。
しかし、利用者は目的を達成できません。
それは最小ではありますが、MVPというより、まだ入口です。
英国政府のサービスマニュアル「How the alpha phase works」でも、Alphaでは複数の解決策をプロトタイプとして試し、リスクの高い仮説へ焦点を当て、次の段階へ進むかを判断する考え方が示されています。
利用者の行程全体を最初から作るのではなく、特に難しい部分へ絞って検証する場合があることも説明されています。
最初から、きれいに作りすぎない
プロトタイプを作るとなると、つい見栄えをよくしたくなります。
色をそろえる。
余白を調整する。
アイコンを入れる。
アニメーションを付ける。
そして、気づけば数週間が過ぎる。
何を確認したかったのかは、少し遠くへ行っています。
プロトタイプの完成度は、確認したいことに合わせて決めます。
画面内の情報配置を確認したいなら、紙でも構いません。
操作の流れを確認したいなら、クリックできれば十分かもしれません。
処理性能を確認したいなら、画面は最低限で構いません。
きれいに作りすぎると、
関係者が完成間近だと誤解する
色や文字サイズの話ばかりになる
作ったものを捨てにくくなる
根本的な変更を提案しにくくなる
検証用の実装が、そのまま本番へ流用される
といった問題が起きます。
英国政府の「Making prototypes」でも、プロトタイプは紙のスケッチからコードで作るものまで、目的に合う形式を選ぶとしています。
また、コードで作ったプロトタイプは、本番と同じセキュリティや性能基準を満たすとは限らず、そのまま本番コードへコピーすべきではないと注意しています。
完成品らしく見えることと、完成品として使えることは別です。
見た目は新築。
配管はまだ仮設。
そういうことがあります。
作る前に「何を確認するものか」を決める
プロトタイプは、作ること自体が目的ではありません。
作り始める前に、最低限、次を決めておきます。
1. 何を確かめたいのか
利用者が、説明を受けなくても申請を完了できるか。
承認者が、必要な情報を一画面で比較できるか。
大量のデータを、許容時間内に処理できるか。
できるだけ、確認可能な問いにします。
2. 誰に見てもらうのか
開発担当者だけでなく、実際に利用する人、運用する人、問い合わせを受ける人なども候補になります。
毎回全員を集める必要はありません。
確認したい論点に応じて、見るべき立場を選びます。
3. どの場面を再現するのか
通常の申請だけを見るのか。
差し戻しも見るのか。
入力途中の保存も見るのか。
スマートフォン利用も見るのか。
確認する場面を決めます。
4. 今回は何を作らないのか
本番用の認証
詳細な権限制御
大量アクセスへの対応
すべてのエラー処理
最終的なデザイン
など、今回の検証対象外を明記します。
作らないものを書かないと、
ここは、まだできていないんですか？
と聞かれ続けます。
できていないのではなく、今回は作っていない。
この差は、先に説明しておきたいところです。
5. 結果を見て何を決めるのか
この案で詳細設計へ進む
別の画面構成を試す
対象利用者を見直す
技術方式を変更する
追加検証を行う
開発自体を見送る
プロトタイプを見たあと、何を判断するのかまで決めておきます。
「どうですか？」と聞くだけでは、感想会になる
プロトタイプを作り、関係者へ見せます。
そこで、
どうですか？
と聞く。
すると、
いいと思います。
分かりやすいです。
もう少し明るい色がよいです。
という感想が返ってきます。
感想も無意味ではありません。
ただし、それだけでは利用できるか分かりません。
実際に操作してもらいます。
たとえば社内申請サービスなら、
この申請を完了してください。
申請内容を修正してください。
申請結果を確認してください。
過去の申請を探してください。
という具体的な作業をしてもらいます。
そのとき、
どこを最初に見たか
どこで止まったか
何を押そうとしたか
どの言葉を誤解したか
説明なしで完了できたか
本来の業務手順と違う行動をしたか
を観察します。
操作後には、
次に何が起きると思いましたか？
どこまで処理が完了したと思いましたか？
必要な情報はどこにあると思いましたか？
などを確認します。
英国政府の「User research in alpha」や「Using moderated usability testing」でも、利用者に具体的な作業をしてもらい、理解できるか、作業を完了できるか、どこに使いにくさがあるかを観察する方法が示されています。
「好きですか」より、「使えましたか」。
少し冷たいようですが、こちらのほうが次の改善につながります。
MVPは「機能を何個まで削れるか」ではない
MVPを考えるとき、
最低限の機能だけ作りましょう。
という話になります。
すると、機能一覧から項目を削る会議が始まります。
検索は後回し。
履歴も後回し。
通知も後回し。
管理機能も後回し。
どんどん小さくなります。
最後には、何かを入力できる画面だけが残る。
確かに小さくはなりました。
ただし、利用者の目的が達成できなければ、価値の検証はできません。
MVPで考えたいのは、
利用者が目的を達成し、提供側も結果から学べる最小の一連の流れは何か。
です。
たとえば社内申請サービスなら、少なくとも、
申請者が必要事項を入力する
申請を提出する
承認者が内容を確認する
承認結果が申請者へ返る
という流れが必要です。
差し戻しなどの分岐まで最初から含めるかは、対象業務や今回確認したい仮説によって変わります。
最初から、すべての申請種別へ対応する必要もありません。
一種類の申請だけでも構いません。
高度な検索や分析機能は後回しにできます。
ただし、対象とする一つの業務について、利用者が目的を達成できる必要があります。
MVPは、品質の低い製品という意味でもありません。
機能範囲は限定しても、
入力内容が失われない
誤った相手へ情報が見えない
処理結果が分かる
最低限の安全性がある
利用者が目的を達成できる
といった、価値提供に必要な品質は残します。
「最低限」は、「雑でよい」の別名ではありません。
同じものを見ると、立場をまたいだ会話が起きる
プロトタイプは、デザイナーや開発者だけが見るものではありません。
確認したい論点に応じて、
業務担当者
実際の利用者
運用担当者
開発担当者
テスト担当者
セキュリティや法務などの専門担当者
意思決定者
にも参加してもらいます。
毎回フルメンバーを集める必要はありません。
ただし、開発側と一部の業務担当者だけで閉じず、後から影響を受ける立場を早めに混ぜる意味は大きいです。
立場が違えば、見る場所も違います。
同じものを囲むと、たとえば次のような会話が起きます。
その操作は便利ですが、承認後は修正できません。
その情報は表示できますが、現在のデータには入っていません。
通常時は動きますが、差し戻し後の再申請が定義されていません。
利用者には分かりやすいですが、運用担当者の手作業が増えます。
文章だけを個別に読んでいると、それぞれが自分の専門領域の中で解釈します。
同じものを見ることで、立場をまたいだ影響が表へ出ます。
プロトタイプは、単なる会議資料ではありません。
異なる立場の人が、同じ対象について話すための共通言語です。
よくある失敗
最後に、よくある失敗を整理します。
確認したい問いがない
何となく画面を作り、何となく見せる。
感想は集まりますが、採用するのか、修正するのか、何を判断すべきなのかが分かりません。
いつもの会議参加者にしか見せない
利用者の意見を代弁することはできます。
ただし、実際の利用者がどこで迷うかまでは、代弁できないことがあります。
PoCで動いたので、そのまま業務利用できると思う
技術的に処理できたことと、業務で継続的に使えることは別です。
利用者、運用、セキュリティ、例外処理、保守、費用など、別の確認が必要です。
MVPを機能削減大会にする
機能を減らしても、価値の一連の流れが成立しなければ、利用結果から学べません。
削る基準は、
なくても、対象とする利用者が目的を達成できるか。
です。
最初のプロトタイプが、そのまま確定仕様になる
一度画面が見えると、
もう、これでよいのでは。
となることがあります。
ただし、最初の案は、あくまで検証のための案です。
見せるときには、
何を確認するためのものか
どこが仮置きか
何が未実装か
何はまだ決まっていないか
を明示します。
プロトタイプは、変更するために作ったものです。
最初に作った案を守り始めたら、少し目的が入れ替わっています。
設計書とプロトタイプを往復する
プロトタイプを作れば、設計書が不要になるわけではありません。
プロトタイプを見て、新しい論点が出ます。
この項目は必須なのか。
差し戻し後は誰が修正するのか。
操作途中で離脱した場合、入力内容を保存するのか。
同じ申請を二重に送った場合、どう扱うのか。
通知が届かなかった場合、どこで状態を確認するのか。
この内容を、設計書や課題管理表へ戻します。
設計書を更新する。
プロトタイプも直す。
もう一度見てもらう。
また論点が出る。
少しずつ認識が揃います。
設計書からプロトタイプへ。
プロトタイプから設計書へ。
どちらか一方を完成させてから次へ進むのではなく、往復しながら精度を上げます。
この往復が早いほど、大きな勘違いを安いうちに見つけやすくなります。
まとめ
設計書を書くことは大切です。
文章で条件を整理する。
業務ルールを残す。
責任分界を明確にする。
例外を考える。
後工程で確認できる形にする。
ただし、設計書を精緻にすれば、関係者全員の頭の中まで同じになるわけではありません。
同じ言葉を使っていても、想像している画面や操作、業務の流れは違うことがあります。
だから、早めに見えるものを作ります。
画面配置を確認したいなら、ワイヤーフレームを作る。
操作を確認したいなら、クリックできるプロトタイプを作る。
技術的な成立性を確認したいなら、PoCを行う。
利用者へ価値を届けられるか確認したいなら、MVPを考える。
大事なのは、立派な試作品を作ることではありません。
何が分かっていないのか。
何を確かめたいのか。
結果を見て何を決めるのか。
を明確にすることです。
そして、作ったものを正解として守るのではなく、間違いを見つけるために使います。
プロトタイプは、完成品の予告編ではありません。
関係者の頭の中で上映されている、少しずつ違う映画を、一度同じスクリーンへ映してみるためのものです。
同じものを見ながら話せば、
何となく違う。
ではなく、
この操作では、実際の業務がここで止まる。
と言えるようになります。
設計書を書いた。
レビューもした。
次は、小さく作って、みんなで見てみる。
間違えるなら、まだ消しゴムで消せるうちに間違えておきたい。
コンクリートが固まってから玄関の位置を議論するよりは、たぶん楽です。
参考資料
本記事は、筆者の実務経験をもとに、プロトタイピング、PoC、MVPの使い分けを実務向けに整理したものです。
これらの用語や工程の区分は、組織や開発方法によって異なります。本記事内の整理は唯一の標準的定義を示すものではなく、「何を確認するために、何を作るのか」を考えやすくするための整理です。
IPA「DX実践手引書 ITシステム構築編 完成第1.1版」
https://www.ipa.go.jp/digital/dx/dx-tebikisyo.html
PDF：
https://www.ipa.go.jp/digital/dx/hjuojm000000gx4n-att/000094497.pdf
何をProofするのかを明確にし、目的の曖昧なPoCを避ける考え方、および計画が十分ならPoC自体が不要な場合もあるという整理の参考にしました。
UK Government Digital Service「How the alpha phase works」
https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works
複数の解決策をプロトタイプとして試し、リスクの高い仮説を検証する考え方の参考にしました。
UK Government Digital Service「Making prototypes」
https://www.gov.uk/service-manual/design/making-prototypes
目的に合わせてプロトタイプの精度を選ぶこと、および検証用コードと本番コードを区別する考え方の参考にしました。
UK Government Digital Service「User research in alpha」
https://www.gov.uk/service-manual/user-research/user-research-in-alpha
プロトタイプを利用したユーザー調査の考え方の参考にしました。
UK Government Digital Service「Using moderated usability testing」
https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing
利用者へ具体的な作業を依頼し、感想だけでなく行動を観察する方法の参考にしました。
アジャイルソフトウェア開発宣言
https://agilemanifesto.org/iso/ja/manifesto.html
ドキュメントの価値を否定せず、動くソフトウェアをより重視する考え方の参考にしました。
関連記事
第一弾
【お仕事ネタ】シバ丸印のこう書いたら楽じゃない？シリーズ第一弾：未来の自分と後工程の人に恨まれないための要件定義書の話
https://note.com/shibamaru_log/n/n72513c043027
設計書に項目があるかだけでなく、その粒度で後工程へ進めるかを考えた記事です。
第二弾
【お仕事ネタ】シバ丸印のこう書いたら楽じゃない？シリーズ第二弾：「外部連携する」と書いてある設計書が、なぜ後から燃えるのか
https://note.com/shibamaru_log/n/n43200bbeda02
外部連携について、正常系だけでなく、異常系、責任分界、再送、復旧までどう具体化するかを考えた記事です。
後記
シバ丸印は、だいたいこのくらいの温度感でやっております。
実はこの記事自体も、最初からこの形だったわけではありません。
一度書く。
読み直す。
他の視点から見てもらう。
重複しているところを削る。
曖昧なところを直す。
文章も、プロトタイプとあまり変わらないのかもしれません。
最初から正解を作ろうとするより、一度見える形へ出してみる。
違うところが見つかったら、まだ直せるうちに直す。
そんな感じで、今回もこねこねしております。
