「顧客が本当に必要だったもの」の事前調査と設計
抽象度
顧客が求めているものをストレートに実現して解決するものとそうでないものがある。 また、多数のユーザーを抱えている場合、数少ないユーザーの意見だけを聞いて実装すると他の多数のユーザーからは実は求めていないものとして扱われることもある。 解決するための銀の弾丸はなく、すべてのユーザーを満足させるための方法もない。 だからといってビジネスをやっているため、顧客の求めている具体的なものからインサイトを抽出する必要がある。
その上で、考えうるインサイトからモノを形作る上で抽象化のアンチパターンを知っておく必要がある。 少なくともそのアンチパターンを踏まない方法が第一歩になる。
| アンチパターンの例 | なぜ |
|---|---|
| カタチから入る | 成果物のカタチに囚われ思考が別方向を向いてしまう。 |
| 世の中のプラクティスを調べていない | 他がなぜこれをやらなかったのか、を様々な思考で考えていない。負債化しやすい。 |
| 高コスト | かけたコストに対して引き返せない状況になり、関係者が引き返したくなくなる。 |
| 野望の塊 | 「あれもこれも」と考えている時点で脱線してしまっている。1 つのことに対して 1 つのアプローチをまず考える。 |
| 救えるのは一握り | 成果物を使う顧客はほんの一握りしかいない！これは調査不足。 |
| 完璧主義 | コストが高くなりがちで、顧客に刺さらなかった場合に戻しが効かない |
| 意地を張る | 個人的思想でサービスを運営しだすとチームメンバーがげんなりする。 |
| アルファ、ベータリリースをしない | 自分が抱えている顧客の市場調査をしない。 |
ではどうしたらよいか？
| アンチパターンではない方法 | なぜ |
|---|---|
| 要素分解する | 「必要なもの」を直接ではなく、足りていないものをあぶり出す。布石を打つ |
| 要素単位で小さく作る | 要素単位で意味をなさなくても、集積体で成果物を作るようにする。廃棄しやすく組み合わせやすい |
| どんどんリリースできる環境を作る | リリースしてからしかわからないことのほうが多い。どんどんリリースする。 |
| 実装例を探す | 思いつくほとんどのものはすでに 99.9%世の中にある。探し出して近道しよう。 |
スケーラビリティ
スケーラブルなものとして扱えるのは次のもの。
- インフラシステム
- UI設計
- 実装設計
- サービス設計
インフラシステムはかなり進歩しており、ここでは議論しない。 UI/実装/サービスのスケーラビリティについて焦点を当てて議論したい。
新機能を設計するとき、顧客が目にするのはUIの部分であり、そこからサービスを受けることになる。 機能の作成が初期の頃は比較的見通しがよくうまく新機能を追加することはできる。 しかし、ある程度サービスが成長したときに新機能を追加すると、局所的になってしまうことがある。 この局所的な対応がもたらす以下のような負の恩恵がある。
- ユーザー/実装者双方からから見て統一感のない設計になる
- ユーザーに対する学習コストが増える
- 局所的な実装・保守をするコストが追加される
- リメイクするときの作業障害になる
- あらゆる対称性が悪い
新機能を提供するときにあらゆる角度から見て必要は移植性が富んだ方法を選ぶと良い。 技術的にもサービス的に新陳代謝の激しい時代になっているため、機動力と移植性の高いもの必要になっている。 そのため尖った提供方法をするのではなく、今後を見据えた提供方法を考えることが望ましい。
UI/UX
昨今のソフトウェア開発において、機能とUIは独立したものではなく、お互いに連携しあって提供されることが多い。 そのため、機能が先か、UIが先かでいえば両方同時になることがあり、デザインと実装方法が切り離せなくなっている。 技術的に作業場所が切り分けられたとしても、サービス視点から見れば切り離せるものではなくなっており、 設計は常に両方の都合のよう状態に落とし込むことが求められる。 新規にUIを作る場合、まずは既存のUIパーツで実現できないかを考えよう。 すでにあるものは実装コストが安い上に動作保証がついているため導入がしやすい。 サービスの提供方法を逆に既存のデザインや実装方法に合わせることも考える必要がある。 両者の歩み寄りによりどうしても新規に実装する必要がある場合はスケーラビリティを意識して設計をする。
まとめ
サービスの開発と運用はマラソンではあるが、実装からリリースまでは時に短距離走側面を要する。 両立させるためには設計がスケール可能な状態になっていること。そして移植性が高い状態にあることが必要となってくる。