「社内要件を取りまとめする際、どっちの仕様にしようか決定打が無く社内会議でシーンとなる」「〜かも知れない…という概念論の話になり、議論が平行線のまま終りが見えない」「その結果、スケジュールが遅延しかける」
社内のWEB制作部署にいて、要件定義をすると必ず出てくるアルアル体験ですよね。
今日はこういった事例に 上手く対応する方法を解説していきます。
目次（押すとジャンプできます）
Web制作の要件定義に必要な視点3つ【答えはデータ、仮説、経緯です】
- データを見る：社内には意思決定に資する情報がたくさん
- 仮説を建てる：仕様決めに困ったら仮説を立てよう
- 経緯の記録：その仕様にした経緯をきちんと記録しよう
ざっとこんな感じです。
この3点が企業のWeb担当者がおさえておくべき三種の神器です。
①はできている人も多いかもしれませんが、②、③まで完璧にやっている人・チームは少ないのではと思います。
さっそく、深ぼって解説していきましょう。
データを集め、データで判断する
- 社内の注文数などの「顧客データ」
- コールセンターへの問い合わせなどの「受電データ」
- GoogleAnalytics/Googleサーチコンソールなどの「Webアクセスデータ」
社内には物事を判断するために活動できる宝のようなデータが転がっています。
しかし、これを社内で有効活用でできている会社は少ないです。
なぜなら、Web制作を担うデジタル部署、問い合わせ対応を担うコールセンター部門など縦割りになっているからです。
fa-check具体例として、「他部署とのつながりが少ないからデータが有るかどうか全くわからない」と感じる方も多いと思います。
実は数年前に大手企業に勤めていた私も同じ感覚でした。
しかし、同期や同僚を辿って「仕様を決めるためのINPUTにしたいのでデータがほしい。」と言い続けると半年ぐらいで自然に自分のところにデータが集まるようになりました。
データがあると要件定義で仕様を決める際の判断軸・理由ができるので物事をスムーズに決めれるようになります。
*ちなみにGoogleAnalyticsと・Googleサーチコンソールはデジタル部署として必須なツールです。
おでんで言うところの大根と卵のような存在です。ぜひ、自部署でこのデータを持っているかを確認し、毎朝見るルーティンを作りましょう。
仮説を立てる
- 自分の立てた仮説を突き通す大胆さが大事
- 魔法の言葉「データを元に検証しましょう」
次に、データの有り無しに関わらず、仮説を置くように意識しましょう。
仮説を噛み砕いて言うと「〜であるはず。なぜなら〜だからである」です。
文字で見ると当たり前のことのように見えるのですが、実はこれができている人は多くないです。
例えば、画面上の注文ボタンの色を決める際、「まぁ、とりあえず赤色で良いんじゃね？」という感じで理由なく仕様が決まっていることがよくあります。
これだとプロジェクトや案件自体は進んでいるように見えるのですが、プロジェクトリリース（完了）後に辛い思いをします。
なぜなら、リリース後の効果検証・改善ができないからです。
fa-checkよくある悩みとして「データがないので、要件を決めかねている。どうしたら良いのでしょうか？」という相談をよく受けます。
その答えは、あなたの仮説を全面に出して「コレで行きたい！」と自信を持って言いましょう。
この思いっきりの姿勢が企業での要件定義には必要です。
なぜなら、人は一般的に決めることを避ける傾向にあるからです。
ただ、「あなたの意見の根拠を教えてくれって聞かれたら…」という不安は残ると思います。
そのシチュエーションであれば、「データを探したが、有力なものが見つからなかった。なので、まずはこの仮説でリリースし、その後データで効果検証、改善へとつなげたい」と魔法の言葉を相手に伝えれば問題ありません。この前向きな姿勢に、否定してくる人はいないと思います。
何事も否定するのは簡単ですが、前向きにどうやろうって考える方が楽しいですよね。
検討経緯を確実に残す
要件定義書や設計書には必ず検討経緯を残しましょう！
「後でこの仕様の結果を検証しましょう」とプロジェクトの中で会話する機会があるかと思います。しかし、大体これらコメントはリリース後に忘れ去られます。
なぜなら、会社には異動が付き物だからです。
fa-checkこんな経験あるのではないでしょうか？
今の稼働しているWEBサイトの構成が今どきじゃないのはなぜか？この表現にしているのはなぜか？前任担当者が作ったものだから分からない。。
これらは全て検討経緯が残っていないので起きる課題です。
こういったことを避けるために、要件定義や設計書には検討経緯を必ず残すようにしましょう。
これらドキュメントは基本的に結果を書かれる傾向にあります。
例えば「注文ボタンは赤色の角丸ボタンとする。」みたいな感じです。
この表記の欄外で構わないので「【検討経緯】赤色とグレーで協議有り。グレーは視認性が悪くお客様にボタン押下されない可能性があるので赤色を選択。リリース後にABテストで検証」
と書かれていたら、どうでしょうか？
リリース後の改善活動（PDCA）が断然に回しやすいですよね。
ぜひ、検討経緯を要件定義書や設計書に残すようにしましょう。
さて、ココからが当サイトのコンセプトである手を動かす時間です。
次のアクション：仮説を出す練習をしよう
- （電車に乗っている人）次の駅で小学生が乗ってくる人数は何人だろう
- （家でくつろいでいる人）今、目の前にありテレビの電源をONにしたとき、何チャンネルが選択されているでしょうか？
- ③（それ以外の人）今日、家に帰って時計を見たら何時何分だろう。
仮説って苦しい言葉なので、ちょっと面倒くさく感じますよね。
実は私もこの言葉を聞いたとき、苦手でした笑
しかし、これをプライベートで少しずつ練習すると上達が速いのです。
具体的には上記質問に対する答えと理由を考えてみてください。
そして、できればメモ帳などで書き出してください。
①の回答例です。
→10人だと思う。なぜなら、15:30は小学生の下校タイミングの始まりである。ただし、ピーク時よりかは少ないはず。
みたいな感じでOKです。そして、その結果を次の駅で確認しましょう。
合っていれば自分の仮説立てが成功、間違っていれば「何が間違った要因だろうか」と考えてみましょう。
まずは、こんな感じでプライベートの中で仮説・検証のコツを掴んでいきましょう。
最後に少しだけ余談：価値観を共有
知識とスキルは違います。
知識は「知っている状態」、つまりこのブログを読み進んでくださった今のあなたの状態です。
そして、スキル「自分の手が動かせる状態」になるには、実際に手を動かしてみるしか方法がありません。
車の運転（特に車庫入れ）も学科だけではできないですよね。教習所を卒業した後に自分の手で何回もこなすことで上手くなったかと思います。
それと同じです。
これは私自身の経験から言えることですが、スキルが身につくと社内のWEB担当として制作会社や社内調整がめちゃくちゃしやすくなります。
「このアイデアって実現できるかどうか」の感覚が分かるからです。
fa-checkこのブログを読んで下さっているあなたは、知識だけで終わらずにスキルまで技術力を上げていきましょう。
おしまいっ！
