こんにちは。ネオシステムの高橋です。
今回は業務を最適化についてまとめました。
業務フロー図の作成方法の続きとなります。
併せて参考にしてみてください。
目次
- 最適なフローとは何か
- 業務改善方法
- コストの算出
- ビジネス価値の定義
- 業務の価値に対する評価
- プロジェクト計画の作成
- プロジェクトの目標を定義する
- プロジェクトのスコープを定義する
- 優先順位を定める
- プロジェクトチームメンバーを特定する
- プロジェクトのタスクと担当者を設定する
- プロジェクトのスケジュールを定義する
- リスクを特定する
最適なフローとは何か
業務フロー図の作成が完了したら、次は最適なフローとは何かを考えます。
以下の方法で業務の最適化を検討してください。
- この業務で達成したい目標は何か
- 何かをより効率的に、より安価に、より高品質にできないか
- KPIからうまく機能しているところ、改善すべきところはどこか
- 上層部から、より高いレベルで評価してもらうことで各ステップの透明性を上げられないか
- 顧客視点からフローを検討し、全体的な満足度を向上させる方法を検討できないか
(目標の例)
- 環境保護意識の徹底よりペーパーレス化を実現する
- コンプライアンスチェックを徹底する
- 業務フローの1サイクルに費やしている時間を削減する
- データの二重管理など、ムダの多い作業を廃止する
業務改善方法
業務目標が決まったらそれを達成するための方法について考えましょう。
- 各タスクの改善方法を探る
- 不要なタスクの削除
- タスクの順序を変更
- タスクの組み合わせの変更
- タスクを同時に実行
- タスク改善のほかに
- 必要な人数を削減
- 次の人への通知方法を変更
- 自動化できる側面はあるのか
- 自動入力処理の追加
- データに基づく意思決定の自動化
- 実行されるアクションの自動化
- 人間の注意力に代わるAI
コストの算出
まずは現状のコストを計算してみましょう。
- 現在のプロセスに費やした時間を特定し、それを実行する人のコストを掛ける
- 開始から終了まで1回実行するコストを決定し、1年間にプロセスを実行する回数を掛ける
- ソフトウェアライセンス、紙、送料など、その他の費用を追加する
(コスト算出と課題の例)
作業実施者で話し合いコストを算出したところ、以下のボトルネックが明らかになりました。
- 外部システムからデータを出力する作業は時間がかかっている。作業内容は単純であるがこの作業を省くことはできないだろうか？
- 工事の実施情報の登録は毎日やらなければならない作業である。もっと簡単にデータを登録できないだろうか？それとも不必要な項目を用意してしまっていないだろうか？
ビジネス価値の定義
問題を解決することのビジネス価値の定義によると、ビジネス価値は4つのカテゴリのいずれかに分類されます。
-
収益(Revenue)
- 新しいビジネスラインやこれまで提供されていなかったサービスなどで他の方法では実現できない収益をもたらす
-
効率(Efficiency)
- 効率化を図ることでコスト削減に効果をもたらす、プロセスの高速化を実現できる
-
ボリューム(Volume)
- 同じユーザーがより多くのトランザクションを処理できるようにすることでコストを回避し、さらなるリソースコストの発生を抑制する
-
その他(other)
- 組織が「必須」の要件に準拠するのに役立ち、財務上のペナルティを回避できる場合がある
対象の業務がどのカテゴリに分類されるか明確になったら達成ポイントを定義しましょう。
-
収益(Revenue)
A. サービスの価格を定める
B. 測定期間を決定する(月間、年間など)
C. サービスを購入する顧客の数を決定する
D. 収益 = A* B * C -
効率(Efficiency)
A. 対象業務を実施する人数を決定する
B. 業務に要する時間を決定する
C. 業務改革を実施した後の人数を予測する
D. 業務に要する時間を予測する
E. 節約された時間 = B - D -
ボリューム(Volume)
A. 一定時間における一人あたりのトランザクション量を測定する
B. 業務改革後の一定時間における一人あたりのトランザクション量を測定する
C. 時間内に処理する必要のあるトランザクション量を決定する
D. コスト回避 = C / A - C / B -
その他(other)
- 回避できるペナルティを決定する
算出した結果、得られるビジネス価値が業務改革のためのアプリ開発時間やソフトウェアライセンスの月額費用よりも大きい場合は、プロセスを自動化することが理にかなっています。
一方で、業務改革で得られるビジネス価値が、何もしないことのコストと比較して有利にならない場合は、本当に解決する必要のある問題なのか、正しい解決策なのかどうかを考え直す必要があります。
業務の価値に対する評価
特定したビジネス価値の進捗状況を評価するときはSMART基準で考えてみましょう。
-
Specific(具体性)
- 何を、どこで、どのように、が明確であるか
- あいまいな言葉を含んでいないか
-
Measurable (計量性)
- 数値化できているか
- 開始と終了が明確か
- 「開始」は現在の状況であり「終了」は目標値を意味しているか
-
Assignable (割当設定)
- 目標を個人やグループに割り当てられるか
- 目標達成が可能であるか
-
Realistic (実現可能性)
- 測定されているものは実現可能であるか
- 実現可能な目標は挑戦的であるか
- 時間内に達成可能か
-
Time-based (時間ベース)
- 期限が明確であるか
- 時間内に達成可能か
基準を特定するときは「ビジネス価値の実現に役立つのか」を常に考慮しておきましょう。
(道路補修工事の場合の目標例)
- 工事受注者が報告書を作成する時間を15分未満にする
- 工事受注者の報告書の記入漏れを10%未満に抑える
- 工事管理者は事故報告の確認を2日以内に実施する
- アプリを導入してから1ヶ月以内に、全ての工事受注者がアプリで情報登録できるようになる。
プロジェクト計画の作成
業務の最適解を導き出せたら、次はその目標を達成するために計画を立てます。
プロジェクトの目標を定義する
プロジェクト計画を立てることで、適切なリソース (時間、人員、資金) を確保できたり、作成したアプリの品質を確保したりすることができます。
プロジェクトチームや個人が明確な目標を持つことは、プロジェクトチームのメンバーが同じ目標を共有するにあたって重要です。
目標を書き留めておくことで、作ろうとしているアプリに何を求めているのかを明確にすることができます。 また、何を作成すべきか、どの機能を優先させるかということに集中することができます。
上のセクションではプロジェクトのビジネス目標を作成しました。ここで追加する目標の例を紹介します。
- アプリの機能性
- アプリのユーザビリティ
- 仕事の満足度の向上
(道路補修工事の場合のプロジェクト目標例)
- リリース1
- アプリを導入してから1ヶ月以内に、全ての工事受注者がアプリで情報登録できるようになる。
- リリース2
- 工事受注者の報告書の記入漏れを15%未満に抑える
- 工事受注者が報告書を作成する時間を15分未満にする
- 工事管理者は事故報告の確認を3日以内に実施する
プロジェクトのスコープを定義する
プロジェクトの達成度がわかるように、プロジェクトの範囲を確認しておきましょう。プロジェクトの範囲の内か外 (次のバージョンで対応すべきもの) かを明確にロードマップにしておきましょう。
スコープを定義するには以下の制約を考慮する必要があります。
- 時間
- プロジェクトの目標を達成する期限
- 人
- プロジェクトに携わる人数
- 予算
- 費やした時間を計上する必要がある場合や、専門家を雇う必要がある場合は予算を設定する
- 実現可能性
- 組織が求めている変化の大きさによっては制約を受ける場合がある
(道路補修工事の場合のスコープ例)
- リリース1
- モバイルアプリを使った補修情報登録機能
- 事故報告の承認機能
- リリース2
- 外部システム連携
- モバイル端末の残課題対応によるユーザビリティの向上
優先順位を定める
以下のルールに沿って順位付けすることで定量的な判断が可能となります。
- 各機能について、以下の項目を評価する
- 必要な機能か
- 実装の難易度
- 業務への影響度
最初は、重要でないと思われるリクエストであってもすべての要求を確実に記録することがポイントです。最初のバージョンが完了した後、アプリの新しいバージョンで作業を開始するときに改善のためのバックログを作成するのに役立ちます。
- 優先象限グラフに沿って優先度を決定する
影響度の大きいものが優先度が高くなる傾向にあります。
優先度が決まったら、アプリユーザと共有し理由を説明しましょう。
プロジェクトチームメンバーを特定する
アプリの設計、作成、テストに携わっている人は、プロジェクトチームの一員とみなされます。
業務フロー図に登場している人物はプロジェクトチームの一員です。そのほかに専門的知識があるソフトウェア開発者などを追加する必要があるかもしれません。
プロジェクトのタスクと担当者を設定する
計画、設計、作成、テスト、導入と改良の5つのフェーズに基づいて、各フェーズで実行する必要があるタスクを一覧表示します。各タスクの責任者を完了目標日と共に割り当てます。
プロジェクトのスケジュールを定義する
アジャイル開発では、迅速に開発できることがメリットとして挙げられます。ただし、アプリの完了までにかかる時間には様々な要因が影響します。
- アプリ作成者の経験レベル
- 既存のアプリをベースに設計・実装するかどうか
- 作成するアプリの数 (例:報告書作成者用のアプリと承認者用のアプリの2つなど)
- アプリに必要な機能数と複雑性
- 接続するデータソースの種類と数、データへのアクセスにあたって他のチームとの連携が必要かどうか
- プロジェクト参加者の稼働状況
これらが明確になると、スケジュールの見積もり精度が改良されます。
リスクを特定する
最後にリスク分析をしておきましょう。
プロジェクトにリスクをもたらす危険性があるものや、アプリによって作成されるリスクの種類を特定しておき、そのリスクの対処方法を予め用意しておきましょう。
リスクの種類
- リソースのリスク
- アプリの開発者がいなくなる
- アプリの作成資金が不足する
- ビジネスリスク
- ビジネスが頻繁に変化したときにアプリの作成方法に影響を与える
- 外部リスク
- プロジェクトチームが管理する範囲外の要因に依存する
- たとえばアプリを外部システムと統合する場合、外部システムが原因で動作が変わるなど
- セキュリティリスク
- 機密情報が漏えいする
リスクレベルの評価
- 深刻なリスク
- 会社全体に悪影響を及ぼすリスク
- 重大なリスク
- このプロジェクトや部門に悪影響を及ぼす可能性があり、継続する前に解決する必要があるリスク
- 軽微なリスク
- プロジェクトに影響を与える可能性があるが、プロジェクトの続行を停止しないリスク
- 個人レベルでのみ悪影響を与えるリスク
プロジェクト計画作成完了！
これでプロジェクト計画の作成が完了しました。
プロジェクト計画が曖昧であったり、メンバ全員に周知できていなかったりすると次以降のフェーズに大きく影響が出てきてしまうので、最初は慎重に計画を立てましょう！
開発するアプリの概要をメンバと共有するには、ユースケース図を使うことをお勧めします。
こちらの記事ではユースケース図の作成方法についてまとめていますので、こちらも併せてご活用ください。