KDOC 670: 機能は使えるようにするだけでなく普及させるところまで設計する
この文書のステータス
- 作成
- 2026-10-17 貴島
- レビュー
- 2026-10-17 貴島
概要
機能の目的は、使えるようにすることではなく、使われることである。だから機能を作るときは、普及させる仕組みまで設計するとよい。機能を作っても普及せず、使われないまま終わるのはよくある失敗である。
たとえば管理画面に2段階認証機能を追加した場合を考える。目的は設定して使ってもらうことである。普及させる仕組みは、測る・気づかせる・教えるの3つに分けられる。
- 測る
- どれくらい設定されたかを、メトリクスとして計測する
- 管理者が設定状態を一覧で確認できるようにする
- 気づかせる
- ユーザ自身が設定状態を確認できるようにする。設定していないときはアラートを出す
- 定期的に未設定者をリマインドして移行をうながす
- 教える
- 使用方法のチュートリアルを整備する。たとえば設定した直後にログアウトさせ、2段階認証でのログインを一度体験させる
- 読みやすいヘルプドキュメントを整備する。どこまでが任意なのかを書くとすっきりする
関連
抽象。
- 機能の目的は使えるようになることでなく使われることなので、測る・気づかせる・教える仕組みまで設計する
関連。
- 前提: KDOC 169: 『ユーザーストーリーマッピング』。欲しいのはソフトウェアではなく、それを使って得られる成果だという。このメモはそれを、機能を作るときの設計に当てはめたもの
- 類推: KDOC 191: 仕様を検証するツールも提供するとよい。作ったもの単体では目的を果たせず、守らせたり使わせたりする手段を一緒に用意する点で共通する
- 類似: KDOC 610: オブザーバリティを醸成する第一歩。道具を入れただけでは使われず、見る頻度や担当を決めて定着させる点で共通する
- 補足: リリースした新機能や改善の多くに価値がないという調査結果が意味すること - mtx2s’s blog。機能の64%はほとんど使われない