開発したものがユーザに使われてると、エンジニア冥利につきますよね。
逆に開発したものが使われないと、寂しさや無駄な仕事への憤りを感じることもあるかもしれません。
では、「使われるものだけを作る」ために何かできることはあるのでしょうか？
僕のチームでは、立ち上げ期こそ大変な時期もありましたが、それを経て学んだ工夫について書きます。
「せっかく開発するんだから、多くの人に使ってもらえるものにしたい」と思っている方、是非読んでご意見をいただきたいです。
この記事はリンクアンドモチベーションアドベントカレンダー2021の19日目の記事です。
ソフトウェアの3分の2の機能は使われていない。なぜ？
よく引用されているアメリカでの調査結果よると、そう言われています。
自分自身がよく使うサービスでも、使っていない機能ってある気がしますよね。
この調査結果は、アメリカの調査機関であるスタンディッシュグループが発表したもので、様々なレポートでも引用されている非常に信頼性が高く、そして何よりショッキングな調査結果です。1
では、なぜこのようなことが起きてしまうのでしょうか。ざっと考えるだけでも、以下のような理由がありそうです。
- 解決する課題の設定に不備があるから
- 主観的に課題を設定してしまうから
- 開発物では、設定した課題を解決できないから
- 要件の不備
- 開発能力の不備
- 改善不足
- 開発物が、顧客に浸透しないから
- 認知不足
- タイミングが良くない
- 使いづらい（UI/UX）
他にも理由はあるかもしれませんが、僕はこのうち、「1-1. 主観的に課題を設定してしまうから」について考えてみました。
プロダクト開発における意思決定で、「ユーザーストーリーの優先順位づけに客観性を持たせることが重要だ」みたいなことはよく言われていますよね。過去の僕のチームの場合も、主観的に「解決する課題」を設定してしまっていたことがありました。
なんで主観的な課題設定じゃだめなの？
何となく、だめそう！って感じはあるのですが、改めて、なにがどのようによくないのでしょうか。
実は人間の認知・判断には常にバイアスが影響を与えます。情報を認識し課題を設定する際に、何らかの情報を過大評価してしまっている可能性があります。特に、以下の4パターンには注意した方が良さそうです。2
| No. | 名前 | 概要（意訳です） |
|---|---|---|
| 1 | 現状維持バイアス | 「これまでに置いた前提や過去の慣習」に関する情報を過大評価してしまうこと |
| 2 | 近視眼バイアス | 「直近・目先で起きた物事」に関する情報を過大評価してしまうこと |
| 3 | 参照点バイアス | 積み上げ思考的に、「自身の経験や勘」に基づく情報を過大評価してしまうこと |
| 4 | 同調性バイアス | 「周囲の人・集団の考え」に関する情報を過大評価してしまうこと（類似: 権限バイアス） |
バイアスを防ぐためには？
結論、バイアスを完全に排除することは難しいです。ただ、その前提の上で、「立ち止まるきっかけを作っておく」ことはできると思っています。
そのきっかけづくりに役に立つのが、データ活用です。
開発フローの中にあえて「不都合な事実をデータにつきつけてもらい、立ち止まるステップ」を埋め込むことで、立ち止まるきっかけを作ってみました。
ありがちな開発フロー
一例ですが、無意識のうちに以下のような開発フローになってしまうことはあるのではないでしょうか。
もちろん、上記のような開発フローにしたくないと考えている人が多いとは思うのですが、かなり意識的に開発を進めていかないと、いつの間にか特定の人物の主観で開発物が決まってしまっていることはあると思います。
バイアスに気づくための開発フロー
一方、意識的にバイアスに気づき、向き合うために、なにをすべきでしょうか。
僕のチームでは、以下のようにして各バイアスに気づくきっかけをつくることにしました。
関係部署へのヒアリング
想定ユーザが社内か社外かを問わず、開発チームが得ている情報は断片的である可能性が非常に高く、さらに近視眼バイアスが作用し「直近起きたことの方がインパクトが残り、優先度が上がりやすい」という傾向があります。
では、想定ユーザにインタビューをすれば全ての謎が解けるかというと、実は心理学的にはそうでもないです。3
そこで、想定ユーザやその周囲の人物なども巻き込みながら、イベントストーミングを実施しました。
【おすすめのインプット】
- ミニマムにはじめるイベントストーミング4
- もう少し学びたい人は合わせて
分析方針策定
イベントストーミングなどのヒアリングや、ビジネス上の課題整理を踏まえて、取り組む課題を設定できたとします。次は、その課題を解決するための仮説検証です。
ここで一気に開発物を考え始めると、どうしても過去の自身の体験などの思い込みに引っ張られてしまいます。
このステップは、問いや仮説ありきで進めた方が効果的です。理由は、探索的に検証を進めると、検証の完了基準を明確に定義できないためです。なので、
①問いまたは仮説
②検証方法（データを活用し定量的に検証する場合は、データの抽出・集計方法や、指標の取り方まで）
③検証結果に基づくネクストアクション
を事前に決めておきます。
【おすすめのインプット】
- 「仮説探索型分析」と「仮説検証型分析」：分析のアプローチは2つだけ
- もう少し学びたい人は合わせて
分析作業・結果評価
分析方針まで決まれば、あとは分析を進め、結果を評価し、事前に決めてある選択肢の中からネクストアクションを選び、実行します。
ここでのポイントは、以下2点です。
・分析作業：実行者はあえて仮説立案者ではない人で行うのも有効（Mustではないですが、よりバイアスを排除するという意味で）
・結果評価：最終的な評価の決定は、分析者のみで行うのではなく、仮説立案に携わった方を出来るだけ巻き込んだ形で判断を行います
開発フローへの埋め込み
そして、このきっかけを開発フローに埋め込みました。5
これまでだと、開発などの施策が実施されるまでの部分（事前検証部分）を、誰かに任せっきりにしてしまったりしていたことがありました。
当然、任された人は情報を処理して課題を設定し、開発物を企画していくのですが、その過程での情報処理にバイアスがかかってしまっても、なかなか1人ではうまく気づいて立ち止まることができません。
そこで、事前検証部分にバイアスへの対応策となるようなアウトプット物とミーティングを設定しました。
また、単独プレーではなく役割を設けたチームプレーにすることで、お互いのバイアスなどに気づきやすくなるようにしています。ざっくり以下のようなイメージです。
この進め方の実践を通して、僕のチームでは少しずつ「つくったものが使われない問題」は解決しつつあります。
最後に
これが当たり前のようにできているチームもあるかもしれませんが、
- バイアスの性質上、
- 普段は当たり前にできていても、「当たり前だ」と思ったときこそ意識したい（「自分はできてる」と思った時ほどバイアスに気づけなくなるので）
- 当たり前にはできていない場合、慣習を変えるのは最初は相当大変
- 世の中に「使われないサービス」や「無駄な開発タスク」じゃなく、「愛されるサービス」「意味ある開発タスク」が溢れてほしいな
と思い、この機会に是非多くの人と一緒に考えてみたいと思い今回投稿してみました。
僕自身はデータチームの立ち上げ期から携わっている身なのですが、正直最初の頃の見られ方としては
「ある日突然謎のチームが立ち上がり、得体の知れないものを作っている」
といった状態でした。
当然、開発したものがなかなか思い通りに使ってもらえないこともあり、苦労しましたが、今はここに書いたことを実践し、徐々にですが使われる・愛されるものを開発できるようになってきた実感があります。
ただ、もっと良くしていきたいと思っているので、他にもやっている工夫などがあれば是非コメントください！