全てを「MUST」にするな 譲れない要件を目的と手段に解きほぐす：「直感」と「論理」を使い分ける実践デザイン論（3）（1/3 ページ）
新しい価値を持つ製品開発では、要件定義の段階で議論が停滞しがちだ。本連載では、83Designが実践する「直感」と「論理」を使い分けるデザイン手法を紹介する。第3回は、部署ごとに示される「MUST」を問い直し、目的と手段に解きほぐして、要件の衝突を乗り越える方法を取り上げる。
どの部署の言い分も正しい。それでも、全部は満たせない。
妥協点を探しているうちに、誰にも刺さらない製品が出来上がる。
コンセプトが固まり、具体的な仕様に落とし込む段階に入ると、プロジェクトマネジャー（PM）は必ずこの板挟みに立たされます。営業からは「あの機能もこの機能も絶対に入れろ」と言われ、開発からは「それではサイズに収まらない」と言われる。時間切れが迫る中でやりがちなのが、全部署の言い分を70点ずつ採用して丸く収めるという着地です。
しかし、そうして出来上がるのは、エッジのない全部盛りの製品です。連載第1回で、量産間際になって「設計が成立しない」「コストが合わない」と判明する大規模な手戻りに触れましたが、要件の妥協は、その手戻りを引き起こす最も静かな原因でもあります。その場では誰も反対しないので、問題として残りません。だからこそ、後戻りできない工程を過ぎるまで気付けないのです。
今回は、要件が真正面からぶつかったときに、妥協ではない着地点へ抜けるための考え方をお話しします。
1．現場の一例と、なぜ全てが「MUST」になるのか
最初に、私たち83Design（ハチサンデザイン）が実際に経験した状況を紹介します。
工場や作業現場に据え置かれる業務用機器の開発プロジェクトでのことでした。その機器はネットワークにつながっておらず、日々入れ替わる協力会社の作業員が、スマートフォンから一時的に操作できるようにしたい、という内容です。卓上には、3つの要件が並びました。
- 体験：
作業員に専用アプリをインストールさせない（使うたびに人が違うため） - コスト：
この機能に割ける開発予算は限られている - 技術：
主要なスマートフォンの2つのOSに対応する必要がある
この3つの要件は、どう考えても同時には満たせそうにありませんでした。
なぜ、こうなるのでしょうか。各部署は、意地悪をしているわけではありません。それぞれの守備範囲の中で、「言われた範囲での最適解」を持ってきているのです。ですから卓上に並ぶのは目的ではなく、既に手段まで降りきった結論になります。「軽さが必要だ」ではなく「100g以下にする」や、「使い始めやすくしたい」ではなく「アプリを入れさせない」といった形で提示されるわけです。
手段同士を突き合わせれば、ぶつかるのは当たり前です。しかし、ぶつかっているのは手段であって、目的ではありません。
もう1点、押さえておきたいことがあります。MUSTとして提示される要件の中には、検証済みの事実ではなく、各部署がそれぞれ立てた仮説にすぎないものもあります。それを動かせない事実として受け取ってしまうと、選択肢が一気に狭まります。
2．問い直し（1）：それは本当にMUSTか
目的を問う前に、まず要件そのものの根拠を確認します。次の4つの問いでふるいにかけてみてください。
- それは会社として決めたことか、担当者1人の意見か
- いつの情報か（市場や技術の前提が、その後変わっていないか）
- 何を根拠にしているか（検証結果か、経験則か）
- 外したら、誰がどう困るか（誰も答えられないなら、それはMUSTではありません）
特に、プロジェクトの途中で追加される要件ほど、ここに引っ掛かりやすい傾向があります。ですからこの問い直しだけは、新しい要件が出るたびに毎回通しましょう。
とはいえ、要件が増えるたびに全部を並べ直していては、現場が持ちません。ここで効いてくるのが要件の持ち方です。要件を縦1列のリストで持つと、全てが同じ重さのMUSTに見えてしまいます。そうではなく、それぞれに「課題」「打ち手」「制約」といった札を付けて、目的の下に手段がぶら下がる形で持っておく――。こうしておけば、新しい要件が来たときにやることは「今あるどの目的の下に入るか」を見るだけで済みます。どこにも入らないものや、既存の前提を変えるものだけを問い直せばよく、2周目以降は一からやり直さず、増えた分だけを足していけます。
Copyright © ITmedia, Inc. All Rights Reserved.