人が達成する必要のあることとして記述すると、アイデアは開発しやすくなります。技術の一覧や機能満載の画面ではなく、仕事から考えましょう。
1. 作業をどこで行うかを選ぶ
提供内容を見つけ、理解し、問い合わせることが必要なら、分かりやすいウェブサイトが最初の製品として適しているかもしれません。スマートフォンで繰り返し作業し、特に安定した接続がない環境なら、モバイルアプリを詳しく検討する価値があります。
既存の道具間で情報を繰り返し移すことが主な問題なら、システム連携や自動化がより直接的な答えになるかもしれません。実際の障害を、管理可能な運用費で解消する出発点が最適です。
2. 完結する一連の操作を説明する
「接続なしで完了した作業を記録する」は、観察できる必要性を説明します。「高度なダッシュボードをつくる」では、実際の作業が分かりません。誰が、何をし、どの情報を使い、どんな結果を見る必要があるかを示します。
初回リリースは、役立つ一連の作業を最初から最後まで完結できるべきです。補助機能は少なくても、成功、失敗、修正が必要な場合にどうなるかを説明する必要があります。
3. 運用にかかる費用を含める
ソフトウェアには、更新、サポート、所有責任への継続的な取り組みも伴います。アプリには配布と端末対応が必要です。システム連携は、外部システムの権限、制限、動作に依存します。サイトには内容の保守と明確な連絡先が必要です。
誰がアカウントと基盤を所有するかを決めます。技術を選ぶ前に、バックアップ、復旧、保守の責任を範囲に含めます。これにより、公開は容易でも運用が難しい製品を避けやすくなります。
4. 判断に役立つ概要を書く
現在の手順と関係者を説明します。個人情報を除いた例を含めます。時間を失う箇所、情報を重複入力する箇所、誤りの代償が大きい箇所を示します。
- 利用者： 誰が、どのような場面で製品を必要としますか？
- 不可欠な成果： 初版で、どの作業全体を支援する必要がありますか？
- 既存システム： どの道具や情報源が関係しますか？
- 制約： 端末、言語、アクセシビリティ、予算、時期。
- 受け入れ： 合意した動作が機能することを、どう実証しますか？
- 所有責任： 誰が範囲を判断し、成果を保守できますか？
5. 意図的な変更の余地を残す
新しいことを学ぶのも製品開発の一部です。優先事項が変わったら、影響を記録し、範囲、時間、費用を明示的に判断します。新しい案をすべて現在のリリースに加えると、中心の操作が未完成になりかねません。
焦点の定まった製品は、何が役立ち、どこで人が困り、次に何を改善すべきかを話し合う、より良い土台になります。