【機能設計】どのように構築するのか
なぜ「機能設計」が独立して必要なのか
業務改善の議論では、「効果は整理できた」「運用の方向性も合意できた」ところで、こうした会話が始まることがよくあります。
- じゃあ、どんなツールを使う？
- フォームを作ればいい？
- システム化するならどこまで？
ここでいきなりツールや画面の話に入ってしまうと、効果設計・運用設計で決めたことが、実装段階で崩れていくことが起こりがちです。そこで必要になるのが、「何を実現するために、どんな機能が必要なのか」を整理する 機能設計 です。
機能設計は効果設計や運用設計を技術やツールに翻訳するための中間工程と位置づけると分かりやすいでしょう。
機能設計は「業務を分解する」ことから始める
機能設計に入ると、つい「どんな機能が必要か」「どんなツールを使うか」といった話から始めてしまいがちです。しかし、効果設計や運用設計で整理した内容と齟齬なく構築を進めるためには、まず業務そのものを分解することが重要になります。
このときに有効なのが、要件定義フェーズで作成した現行業務（As-Is）の業務フローです。
業務フローは、単に現状を説明する資料ではなく、機能設計の出発点として活用できます。
ポイントは、業務フローをそのまま「機能」に置き換えないことです。業務フローには、
- 人の判断
- 口頭やメールでのやり取り
- 記録されていない暗黙の作業
などが混在しています。機能設計では、これらを一度立ち止まって、「どのような行為が行われているのか」「その行為は「管理・記録・可視化」が必要か」という観点で分解していきます。
例えば、納期確認の問い合わせフローであれば、
- 問い合わせ内容を把握する
- 対応対象として認識する
- 担当者を決める
- 社内に確認する
- 回答内容を確定する
- 顧客へ回答する
- 対応状況を後から確認できるようにする
といった 行為の単位 に分けて考えます。
このように業務を分解することで、「どこを仕組みで支えるべきか」「どこまでを機能として持たせるべきか」が明確になります。
機能設計は、新しい仕組みを考える工程ではありません。要件定義で整理した業務フローを、もう一段深く読み解く工程であり、この整理ができていれば、次の「効果設計から導かれる機能」「運用設計から導かれる制約」へ、無理なくつながっていきます。
効果設計から導かれる「必要な機能」
効果設計で整理した効果を思い出してみましょう。
- 対応漏れを防ぎたい
- 回答までの時間を短くしたい
- 管理者が状況を把握したい
- 後から傾向を分析したい
これらの効果は、そのまま機能要件に置き換えられます。
| 期待する効果 | 機能要件 |
|---|---|
| 対応漏れを防ぎたい | 問い合わせを必ず一覧化できる機能 |
| 回答までの時間を短くしたい | 未対応・滞留が分かる機能 |
| 管理者が状況を把握したい | ステータス別に見える機能 |
| 後から傾向を分析したい | データとして蓄積される機能 |
重要なのは、「便利そうだから」ではなく「効果を出すために必要だから」という理由で機能を定義することです。
運用設計から導かれる「機能の制約」
一方で、運用設計で整理した内容によって、機能に対する制約条件が課されることになります。
| 運用方針 | 機能の制約 |
|---|---|
| 担当者の入力負担を増やさない | 入力項目は最小限であること |
| 管理者が毎日手作業で整理しなくてよい | 操作が複雑でないこと |
| 例外があっても業務が止まらない | 一部入力漏れがあっても致命的にならないこと |
この視点が抜けると、「理屈上は正しいが、誰も使わない仕組み」が出来上がります。
機能を「役割」で整理する
ここまで整理した内容を踏まえると、 必要な機能は大きく次の役割に分けられます。
| No | 機能 | 役割 |
|---|---|---|
| 1 | 受付・起票の機能 | 問い合わせを案件として登録する |
| 2 | 管理・一覧の機能 | 状況・担当・進捗を一覧で把握する |
| 3 | 記録・履歴の機能 | 回答内容や判断根拠を残す |
| 4 | 共有・通知の機能 | 関係者に状況を伝える |
| 5 | 振り返り・分析の機能 | 件数や傾向を確認する |
このように「役割」で整理すると、特定のツールに依存せず、構築イメージを描くことができます。
Google Workspace での実装イメージ（例）
ここで初めて、Google Workspace を使った場合の実装イメージを簡単に確認しておきます。
| No | 機能 | GoogleWorkspaceでの実装イメージ |
|---|---|---|
| 1 | 受付・起票の機能 | GoogleフォームやGmailを起点に案件化する |
| 2 | 管理・一覧の機能 | Googleスプレッドシートで案件一覧を管理 |
| 3 | 記録・履歴の機能 | 回答内容は行に蓄積、関連資料はGoogleドライブへ |
| 4 | 共有・通知の機能 | GmailやGooglChatで状況を共有 |
| 5 | 振り返り・分析の機能 | Googleスプレッドシートで集計・フィルタで確認 |
重要なのは、「Workspaceだからこうする」ではなく、「この機能が必要だから、Workspaceのこの要素を使う」という順序を守ることです。
機能設計で「やりすぎない」ための判断軸
機能設計でよくある失敗は、「できるからやる」という判断です。
- 自動化しすぎる
- 例外処理を作り込みすぎる
- 最初から完成形を目指す
これらは一見すると高度な設計に見えますが、運用負荷・保守負荷を一気に高めます。
機能設計では「運用が回るか」「誰でも直せるか」を常に基準に判断することが重要です。
機能設計のポイント
機能設計では、効果設計・運用設計で決めたことを、機能として実装可能な形に翻訳することです。
- 効果を出すために必要な機能か
- 運用を阻害しない機能か
- 将来の拡張を邪魔しないか
この3点を押さえた機能設計ができれば、構築はもはや難しい工程ではなくなります。
[次回]いよいよ構築へ
ここまで問い合わせ対応の改善に向けた設計をお話してきました。
次の記事では、いよいよ設計に基づいた構築について説明していきます。引き続きお付き合いください。
