タスクデリバリー

タスクデリバリーは、部署をまたぐ請求書発行業務の進行状況を、工程単位で可視化する業務進行トラッキングアプリです。前工程の完了状況や次に取るべき行動が見えづらい状態を、担当・期限・状態・履歴が追える体験として整理しました。

部署をまたぐ定型業務では、自分の担当工程だけでなく、前後の工程がどこまで進んでいるかによって次の行動が変わります。進行状況が個別連絡や担当者の記憶に依存すると、確認・待機・手戻りが発生しやすく、業務全体の流れが見えにくくなると考えました。

当初は、課題を部署間の連絡漏れや通知不足と仮定していました。しかし総務担当者へのヒアリングを通じて、連絡手段そのものよりも、今どの工程で止まっているのか、次に誰が動くべきかを判断しづらいことが大きな負担になっていると分かりました。

そこで課題を「業務の現在地と判断材料が共有されていないこと」と再定義しました。

解くべき課題は、前工程の完了状況が見えず、次の担当者が作業開始を判断しづらいことです。

単に連絡を増やすのではなく、部署間で業務の現在地と判断材料を共有し、次の作業へ迷わず進める状態をつくることを目指しました。

解決策を通知やチャットの追加に広げると、初期MVPとしてはスコープが大きくなりすぎると考えました。

そこで、まずは請求書発行業務を4工程に分解し、担当・期限・状態・履歴・次アクションを工程単位で確認できる体験に絞りました。複雑な機能を増やすよりも、業務の現在地を共有することを優先しました。

中心オブジェクトを「業務タスク」とし、その中に複数の「工程」を持つ構造にしました。タスク全体では進行状況を把握し、工程単位では担当・期限・状態・コメント・履歴を確認できるようにしています。

これにより、一覧では優先度を判断し、詳細では次アクションの根拠を確認する役割に分けました。

一覧では、対応すべきタスクを判断しやすいように、進行状況・現在の担当・期限・アラートを優先して表示しました。

一方で詳細では、工程ごとの状態や履歴、コメントを集約し、なぜその状態なのか、次に何をすべきかを確認できる構成にしました。画面ごとに役割を分けることで、探す負担を減らすことを意識しています。

初期プロトタイプを総務担当者に操作してもらい、一覧画面・詳細画面・状態変更操作の分かりやすさを確認しました。

テストでは、履歴表示について「何が行われたか分かるので安心する」という反応があった一方で、一覧画面では「自分が対応すべき案件か分かりづらい」、確認操作では「毎回コメントを書くのが手間になりそう」という課題が見つかりました。

そこで、担当中の案件を判断しやすくするラベル表示、工程担当表記の見直し、コメント未入力時も定型文で履歴に残る設計へ改善する方針にしました。

一覧画面では、ログインユーザーが担当中の案件のみを小さなラベルで明示し、確認すべき案件を判断しやすくしました。

詳細画面では、工程カード内の表記を「担当」から「工程担当」に変更し、案件全体の担当ではなく、各工程ごとの対応者であることが分かるようにしました。あわせて詳細画面にも担当中ラベルを追加し、一覧から詳細まで一貫して担当状態を確認できるようにしています。

また、工程開始・完了・確認完了などの定型操作では、コメント未入力時も操作内容に応じた定型文を履歴に記録する設計にしました。一方で、修正依頼のように相手への具体的な伝達が必要な操作では、入力を促すエラーを表示する想定としています。

ユーザーテスト後の改善を反映したプロトタイプでは、一覧で担当中の案件を判断し、詳細で工程ごとの状態や履歴を確認し、モーダルで状態変更を行う流れを設計しました。

操作後はToastで結果を返し、確認待ち・未着手・作業中・完了といった状態変化が利用者に伝わるようにしています。画面遷移だけでなく、業務が前に進んだことが分かるフィードバックも設計対象にしました。

この制作を通じて、業務を単に一覧化するのではなく、利用者が今の状態を理解し、次に何を確認・判断すべきか分かる形に整理することの重要性を学びました。

特にユーザーテストでは、履歴表示が安心感につながる一方で、担当中の案件の見分けやコメント入力の負荷が実務利用時のつまずきになり得ることが分かりました。

今後は、権限・通知・例外対応・担当者変更などの運用条件も踏まえ、より実務に耐える業務プロダクトとして発展させたいです。