アカウント、ダッシュボード、通知、レポートを機能一覧に並べても、利用者がなぜ製品に戻ってくるのかは説明できません。最初のニーズから有用な結果まで業務を追うことで、範囲は明確になります。小規模な施設管理チーム向けの共有サービス依頼管理ツールを、SaaSの例として考えます。最初の目的は、各依頼の担当者と現在の状態をチーム内で見えるようにすることです。この目的が、初回リリースに実用的な境界を与えます。
このページの内容
最初の利用者と得られる結果を定義する
最初の対象者を、その人の業務から説明します。例の管理ツールでは、調整担当者が今はメッセージから依頼を集め、同僚に進捗を尋ね、手作業で報告しているとします。有用な結果は、十分な背景情報、担当者、見えるステータスを持つ依頼です。誰が情報を入力し、誰が対応し、誰が結果を確認する必要があるかを特定します。そうすることで、調整担当者のニーズと技術担当者の画面を分けて考えられ、あらゆる顧客を最初の対象にしてしまうことを避けられます。
- どのような出来事が製品を開くきっかけになりますか。
- 一回の有意義な利用で、何を完了する必要がありますか。
- どの情報が、作業を続けるための再訪につながりますか。
最初の利用の流れを描き、境界を決める
例では、調整担当者がワークスペースを作成し、同僚を招待し、依頼を登録して割り当てます。同僚は依頼を開いて状態を更新し、結果を記録し、調整担当者は後からその結果を見つけられます。これが最初の一連の利用の流れです。誤った割り当てや、誤って完了にした依頼への対応も決めます。高度なレポート、自動振り分け、公開の業者マーケットプレイスは、この例のリリースには含めなくてもよいでしょう。後の議論で既存の約束として扱われないよう、見送りを文書化してください。
- 含めるもの：ワークスペースへのアクセス、依頼内容、割り当て、状態、基本的な履歴。
- 含めるもの：ワークフローを使い続けるために必要な訂正機能。
- 見送るもの：最初の利用の流れで確認された不足を解消する場合を除く、追加のワークフロー。
製品運用に必要な作業も範囲に含める
アカウントの管理責任、招待、アクセス権の削除、各役割が参照・変更できる情報を定めます。複数の顧客が利用するなら、ワークスペース間の境界を定義し、確認してください。サポート担当者が合意したアクセスルールの範囲で報告された問題を調査できるようにします。復旧確認と重要なレコードの管理責任も計画します。サブスクリプションを含めるなら、採用する課金状態とアクセス状態を説明し、後回しにするなら初回リリースのアクセス管理方法を記録します。これらは画面と並ぶ製品上の判断であり、公開時まで放置すべき細部ではありません。
- アクセスできなくなった利用者を誰が支援しますか。
- 誰が依頼を訂正したり、再開したりできますか。
- チームはどのように更新を公開し、障害に対応しますか。
初回リリースから何を学ぶかを決める
仮説と、それをチームがどう確認するかを書き出します。例の管理ツールでは、調整担当者は外部の助けを借りずに依頼を登録・割り当てできるでしょうか。同僚は何をするべきか理解できますか。調整担当者は後から利用できる結果を見つけられますか。全体の流れを観察し、支援が必要な箇所を記録します。合意したワークフローの不具合と、新しい製品方針への要望を分けてください。自動振り分けは高度に聞こえるからではなく、最初の対象者にとって割り当て作業が重要な問題だと根拠で分かった時点で再検討します。