そのためには、ツールを使用した可視化が効率的で且つ、生産性が高いため、業務プロセス改革を支援するケースにおいてその有効性を３つのフェーズに沿ってご紹介します。
① 企画フェーズ
－ 機能可視化
現状（As-Is）を明確にするために、現行業務と稼働しているシステムの概要を可視化し、あるべき姿（To-Be）として新システムの構築要件について、機能レベルまで期待する内容を洗い出し、それを基に大枠の概要を作成します。
その際、帳票などのアプトプットや、連携すべきデータの量や入手先、処理を行う計算ロジックの根拠など、質問記入票等を利用して確認し、機能要件を一覧にします。
現行業務プロセスの把握には、設計書なのどのドキュメントが残っていたとしても、現状のシステムの仕様に合って最新となっているかが重要なため、必要に応じて、現行の業務フローを作成しなおして、関係者が共通認識できるように可視化します。 そして、同じツールを使って、あるべき姿の業務フローも作成することで、改善点が明確になります。
－
要件定義
現状業務の内容と、問題点の把握、そして関係者からの新システムへの期待と要望の洗い出しができたところで、技術メンバーが中心となり、新業務機能記述書を作成します。
この際、可用性や、性能、拡張性、保守・運用を考慮した機能についての要件は、ユーザからは明確に要求が出てこず、システム部門が主体となって検討すべき項目が多くなります。特に、セキュリティポリシーに則っているかとか、
そして、技術担当任せにならず、経営層が主体的にビジネス構想やシステム化構想を創造する立場で参画していないと、大胆な業務改革や組織改革は断行できずデジタル時代に対応した新たなビジネスモデルの構築が実現できないため、このシステム再構築によって具体的な数値レベルで目標も明確化することが重要です。
－ RFP
RFP（Request for Proposal）は、SIerや、システムの開発側に対してシステム構築を依頼する際に、解決したい課題とあるべき姿をまとめ、実現したい業務の内容や、システムに必要な要件などを明記した書類となります。
実際には、外部の会社へ依頼しないケースでも、自社内での開発側の立場の関係者へ新システムへの期待と希望を不足なく伝えるためには、とても重要な情報となります。
具体的には、開発をする背景や、現状の課題、スケジュールや予算、ゴールや開発に必要な組織内のリソースや体制など、必要な情報が多く含まれております。
② 開発・テストフェーズ
開発・テストフェーズでは、業務プロセス改革の主旨を理解し、情報を共有しながら、複数名で共同作業を行う場面が多くなります。進捗状況の視える化や、関連するドキュメントやソースコードの最新を参照できる仕組みなど、プログラムのコーディング以外にも効率よく作業ができる環境が必要です。特に、実装に伴うテストでは、何をどのように検証するかによってアプリケーションの品質に影響するため、時間とリソースが必要になってきます。
－ 設計、機能詳細定義
開発側が中心となり、RFPに従い要件定義された内容をもとに、どのようにシステムに実装するのか具体的に明確にします。そのために、画面の動きや、アウトプットの内容、機能のアウトラインなどを定義する基本設計に加え、どのようなコーディングをするのかまで機能レベルで明確化する詳細設計まで行ないます。
従来のウォーターフォール型の開発手法では、基本設計、詳細設計、運用設計など、開発に着手する前にかなり詳細なレベルまで、システム全体にかかわるかなり木目細かい設計が必要でした。しかしながら、業務プロセス改革では、ユーザの要求に対して柔軟で、迅速に開発できることが求められるため、アジャイル開発のような手法を用いる場合は、あまり細かな仕様を決めすぎず、イテレーションごとにテストをして、仕様変更しやすい設計が望まれる傾向にあります。
－ 開発
システムの開発は、環境によって使用する言語や、支援するツールが違ってきますが、業務プロセス改革では、最新のIT技術を取り入れやすく、且つ迅速に開発できること、開発ノウハウが特定個人に依存せず、他の人にも理解できるものが求められます。
作成されるシステムは、セキュリティポリシーに適合するレベルで、巧妙なサイバー攻撃に耐えるような強靭なセキュリティが保てるシステム開発が望まれます。
開発内容によっては、RPAのソフトウェアロボットを使用して、AIやEAI/ETLツールなどを活用することで、プログラミング効率を圧倒的にあげる方法もあります。
また、クラウドサービスなど、すでにあるアプリケーションを上手く取り込んだり、ローコード開発やノーコード開発のツールの採用も、かなり有効です。
－ 実装
実装を行うために、現状（As-Is）をあるべき姿（To-Be）へ導くための改善施策として検討したシナリオを、最適なものになるよう仮説を立てシミュレーションによって繰り返し検証します。具体的には、リソースの量や使用時間などを仮定して複数種類の設定を行い、定量比較などできるだけ可視化できる形でシミュレーションします。
シミュレーションによって、現状の問題点・ボトルネックなどが定量的に把握でき、意図した方法で業務の流れを変えたときの効果も定量的に評価することが可能となります。これにより、効果的なプロセスの変更やリソースの再配置などの具体的な施策に着手することができ、企業の業務改善・改革を成功に導きます。
－ テスト
テスト検証には、開発したアプリケーションの可視化のために、
③ 運用フェーズ
変革を狙った業務プロセス改革において、
セキュリティインシデントに迅速に対応し、被害を最小限に抑えることができるシステム運用が不可欠です。理想は、経験が無い担当でも、誰でも運用できる業務システムであることです。
－ 仕様変更
運用フェーズに入ってからの、業務プロセスの仕様変更は必ずドキュメントを残す必要があります。作成
－ 影響分析
仕様変更や、障害対応など、アプリケーションの内容を変更する場合、アプリケーションのどの部分にどのような影響があるか、あるいはセキュリティ面でのリスクは無いかなど、構想上や関連性において影響分析できる仕組みが必要です。そのためには、
－ 改変履歴
開発された業務アプリケーションに変更が生じた場合、変更したプログラムの内容に合わせて、業務フローが常に最新のものにアップデートされているかが、障害時や変更時の影響分析などで重要となります。そのためには、アプリケーションを解析して出てくる情報が、毎日自動更新され、更新履歴が残るような仕組みが有効です。
改変履歴のログが信頼できないものであると、予期しないトラブルを起こしかねません。
