“MECE”の罠 - Webディレクターとして要件定義の際に心がけていること -
こんにちは。とらのあな通信販売のWebディレクター(兼Webマーケター)の長です。これまでの私の記事では、とらのあな通信販売でのMAツール活用や多言語対応など実際の取り組みについて紹介してきましたが、今回はWebディレクションにおいて要件定義の際に普段心がけていることを書いてみたいと思います。
この記事を読んでいるWebディレクターやエンジニアの方。少しでも「いいね」と感じたら、「いいね」ボタンを押して、虎の穴ラボの企業サイトにも寄ってみてください！
そもそも要件定義って？
普段Webディレクションや開発マネジメントをしている方であれば、知らないことはないと思いますので、この章は読み飛ばしていただいて大丈夫です。普段Webマーケティングを中心に仕事をしている人にとっては、もしかしたら聞き慣れないキーワードかもしれません。
ビジネスにおいて厳密な定義が決まっている訳ではないですし、会社やチームあるいは個々人によって意味していることが異なるとは思いますが、私自身は要件定義を次のように捉えています。
要件定義の意味(ざっくり)
①実現したいことに対して解像度を上げていくこと
②実際にそれを作る人が何を作ればいいのか明確に分かるようにすること
例えばバナー表示でいうと、「誰に表示するの？」「いつどういう条件で表示する？」「表示する場所は？」というように5W1Hに近い問いを繰り返しながら、細かく仕様を決めていくのが①。
①の内容を分かりやすく図示したり表にまとめて、それを読めばエンジニアやデザイナーが実装に取りかかれるような情報として整理するのが②です。
Webディレクターとして心がけていること
要件定義の簡単な説明は今回はここまでにして本題に入ります。
Webプロダクトは、当たり前ですが様々な職種の人が力を合わせて仕事をすることで成り立っています。だからこそディレクターが要件定義をするのですが、やはりどうしても認識のずれやミスリードは起こり得ますし、実装したはいいもののユーザーからの反響がなかったり、結局使われないといったことも起こり得ます。
それを少しでも防止するため、私が要件定義をする際に気をつけていることをいくつか紹介したいと思います。少しでも「いいね！」と感じたディレクターの方々はいいねを押してみてください！
1. とことんMECE(ミーシー)に考える
MECE(ミーシー)という言葉は、おそらく皆さん一度は(いや何度も)聞いたことがあると思います。「Mutually Exclusive and Collectively Exhaustive」の頭文字を取った4文字で(この記事を書いている時に元の英文を知りました…笑)、直訳すると「互いに重複せず、全体として漏れがない」という意味です。
つまり「とことん“漏れなくダブりなく”考える」ということになります。ロジカルシンキング関連や新人研修向けの書籍などにも必ず書いてある考え方で、おそらく一般的な思考方法かもしれません。
しかし、知っていることと使いこなせることは天と地の差があるのも事実。私はいまだに不完全な時もあります(むしろ不完全な時のほうが多いかもしれない)。そのため、要件定義の時に限らず、何かを検討する際には絶対に洗い出したパターンに抜け漏れがないかを意識するように心がけています。
例えば
・対応すべきページの種別
・ユーザーの取りうる画面遷移のパターン
・干渉や影響を受けるKPI
・実現のために解決しなければならない課題
などなど、あらゆる場面で役に立ちます。
そして実は、最も避けるべきなのは「漏れがあることに気づけない」ことです...！こればかりは事前の調査や確認を入念にしないとそもそも気づけなかったり、そもそも入社後間もない時期はプロダクト自体への理解度が高くないため発生しやすくなります。機能に詳しい開発者や他の先輩Webディレクターに抜け漏れがないかを確認するのが一番です。
2. 資料には主語、数字の定義、前提を必ず記載する
2つ目はどちらかと情報をまとめてエンジニア等へ共有、伝達する時に気をつけていることです。「主語」「数字の定義」「前提」が明確になるように気をつけています。
■主語をちゃんと書く
口頭でのコミュニケーションでは多くの場合、主語がなくても会話が成り立ちますが、文章や資料ではこれがないと認識齟齬やミスリードの原因になってしまう時があります。
例えば「上記について～～～」という記載があった場合、もしもその上部に複数の箇条書き項目があったら、どれに対するものなのかが第三者視点で分かりにくいケースがあります。
そのため私はよく、箇条書きにする場合は数字番号を付けて「上記●番について～～～」と書くようにしています。
■数字の定義が分かるように書く
こちらは要件定義というよりは実施後の効果検証や、事前の効果予測を立てる時に意識していることです。
分かりやすい例は「売上金額」や「利益」です。税別なのか税込みなのか、粗利なのか営業利益なのかで検討時の判断や評価が大きく左右される場合もあります。「売上(税別)」というような記載を心がけています。
同じように「CTR」「CVR」などのマーケティング用語も、できるかぎり「クリック率」「注文完了率」と記載します。
■前提を明記する
特に実施前の予測を立てる際や、実施後の検証を行う際に気をつけているのがもう1つあります。それが前提をちゃんと書くことです。
・前提として〇〇な条件を満たす人にしか表示しない
・試算の前提としてCVRをX%としている
といった感じです。あくまで経験則ですが、実際に、事前に前提を書いたり説明したりした場合とそうでない場合では、その後のやり取りや議論がスムーズに進むことが多いです。
3. なるべく表で整理する
次に、情報を整理する時はなるべく表でまとめるように心がけています。これは認識のずれやミスリードを防止するというよりは、読む側の人にとっての負荷を少なくするためです。
要件定義や他の様々な検討事項の多くは、基本的にはいくつかのパターンや項目ごとに、メリットやデメリット、懸念事項などを整理しながら最終的にどうするかを決める流れになるはずです。
例えば、以下のようなマークダウン形式での整理でも別に問題なく議論はできると思います。
● 検討事項A
- メリット：～～～
- デメリット：～～～
- 懸念：～～～～
- 補足事項：～～～～～
● 検討事項B
- メリット：～～～
- デメリット：～～～
- 懸念：～～～～
- 補足事項：～～～～～
● 検討事項C
- メリット：～～～
- デメリット：～～～
- 懸念：～～～～
- 補足事項：～～～～～
しかし、選択肢と比較する項目が多ければ多いほど視認性も下がり、全体を理解するための負荷が大きくなっていきます。
そのため、何かを比較する時はなるべく(時間がない時を除いて必ず)表にして整理するようにしています。読む側はもちろん、なにより自分自身が後で見返したり、参照したりする際にスムーズに再理解できるのが一番のメリットです！
4. ときにはMECEを壊して再思考する
最後の1つです。実はこれが、私が普段心がけていることの中で最も大きい内容です。
これまでの3つは、あくまで何か方向性が固まったり、やることが決まった後の段階のもので、ミスリードを防止したり仕様の解像度をもっと上げていくための心がけでした。
一方でこの「時にはMECEを壊して再思考する」のは、そもそもどのような方向性にすべきか、そもそも実施すべきかといった検討の1番最初の段階で必要になることが多いからです。
私が虎の穴ラボに入社する以前、当時の上司から言われたフレーズがあります。
「一度MECEに分解したら、それ以外の分け方を一切無視することになるからね。時には手段や切り口そのものをMECEに考えよう。」
個人的にとてつもない衝撃でした。
簡単な例ですが、売上をそれを構成する要素に分解してどの指標をKPIにするかを検討する場合、たとえば
年間売上 = 注文件数 × 注文単価
と2つに分けて、それ以降は
売上 = サイト訪問回数 × 注文率 × 平均注文商品数 × 平均商品価格
といった具合に細分化して因数分解できます。
一方、この時点で
年間売上 = 購入者数 × 客単価(年間LTV)
や
年間売上 = 新規顧客による売上 + 既存顧客による売上
などの別の切り口で分解、検討していくことを除外してしまう恐れがあります。
私自身はこれを“MECEの罠”と勝手に読んでいます笑。
抜け漏れないようにパターンを検討していきつつも、時には別の切り口や方向性そのものに対して抜け漏れなく考えていくことを心がけています。
もちろん、無限に時間をかけてもいられないのは当然ですので、どこかで折り合いをつける必要がありますが…。常に最善を探る姿勢を忘れないディレクターでいたいと思っています！
開発エンジニア募集中！
現在虎の穴ラボでは、とらのあな通信販売の開発エンジニアを募集中です！
いきなり応募するのはちょっと…という方は、ぜひカジュアル面談に一度お越しください。
それではまた！