業務プロセス改革支援 3つのフェーズ

業務プロセスを見直し、改善し、変革を目指すシステム開発を行うには、業務フロー全体と開発するアプリケーションについて、誰もが同じ目線に立って状況が把握できるよう可視化することが重要です。
そのためには、ツールを使用した可視化が効率的で且つ、生産性が高いため、業務プロセス改革を支援するケースにおいてその有効性を3つのフェーズに沿ってご紹介します。


ツールを使用したBPR3つのフェーズ

① 企画フェーズ

 
業務プロセス改革を実践するための企画フェーズでは、その変革プロジェクトのステークフォルダーから情報収集した要求事項をまとめ、本来その業務で何を目的にアウトプットし、どのような成果を期待するのかを明確にする必要があります。 そのためには、業務の現場担当のみならず、経営層が期待する要件を洗い出し、現状(As-Is)の問題点とあるべき姿(To-Be)を明確にします。

- 機能可視化


現状(As-Is)を明確にするために、現行業務と稼働しているシステムの概要を可視化し、あるべき姿(To-Be)として新システムの構築要件について、機能レベルまで期待する内容を洗い出し、それを基に大枠の概要を作成します。
その際、帳票などのアプトプットや、連携すべきデータの量や入手先、処理を行う計算ロジックの根拠など、質問記入票等を利用して確認し、機能要件を一覧にします。
現行業務プロセスの把握には、設計書なのどのドキュメントが残っていたとしても、現状のシステムの仕様に合って最新となっているかが重要なため、必要に応じて、現行の業務フローを作成しなおして、関係者が共通認識できるように可視化します。 そして、同じツールを使って、あるべき姿の業務フローも作成することで、改善点が明確になります。

iGrafx FLOWCHARTER

- 要件定義


現状業務の内容と、問題点の把握、そして関係者からの新システムへの期待と要望の洗い出しができたところで、技術メンバーが中心となり、新業務機能記述書を作成します。
この際、可用性や、性能、拡張性、保守・運用を考慮した機能についての要件は、ユーザからは明確に要求が出てこず、システム部門が主体となって検討すべき項目が多くなります。特に、セキュリティポリシーに則っているかとか、BCP(事業継続計画)に基づいて、非機能要件を洗い出し、システムの運用を考慮した要件をまとめることが必要です。
そして、技術担当任せにならず、経営層が主体的にビジネス構想やシステム化構想を創造する立場で参画していないと、大胆な業務改革や組織改革は断行できずデジタル時代に対応した新たなビジネスモデルの構築が実現できないため、このシステム再構築によって具体的な数値レベルで目標も明確化することが重要です。

iGrafx PLATFORM

- RFP


RFP(Request for Proposal)は、SIerや、システムの開発側に対してシステム構築を依頼する際に、解決したい課題とあるべき姿をまとめ、実現したい業務の内容や、システムに必要な要件などを明記した書類となります。
実際には、外部の会社へ依頼しないケースでも、自社内での開発側の立場の関係者へ新システムへの期待と希望を不足なく伝えるためには、とても重要な情報となります。
具体的には、開発をする背景や、現状の課題、スケジュールや予算、ゴールや開発に必要な組織内のリソースや体制など、必要な情報が多く含まれております。

iGrafx FLOWCHARTER


② 開発・テストフェーズ

 
開発・テストフェーズでは、業務プロセス改革の主旨を理解し、情報を共有しながら、複数名で共同作業を行う場面が多くなります。進捗状況の視える化や、関連するドキュメントやソースコードの最新を参照できる仕組みなど、プログラムのコーディング以外にも効率よく作業ができる環境が必要です。
特に、実装に伴うテストでは、何をどのように検証するかによってアプリケーションの品質に影響するため、時間とリソースが必要になってきます。

- 設計、機能詳細定義


開発側が中心となり、RFPに従い要件定義された内容をもとに、どのようにシステムに実装するのか具体的に明確にします。そのために、画面の動きや、アウトプットの内容、機能のアウトラインなどを定義する基本設計に加え、どのようなコーディングをするのかまで機能レベルで明確化する詳細設計まで行ないます。
従来のウォーターフォール型の開発手法では、基本設計、詳細設計、運用設計など、開発に着手する前にかなり詳細なレベルまで、システム全体にかかわるかなり木目細かい設計が必要でした。しかしながら、業務プロセス改革では、ユーザの要求に対して柔軟で、迅速に開発できることが求められるため、アジャイル開発のような手法を用いる場合は、あまり細かな仕様を決めすぎず、イテレーションごとにテストをして、仕様変更しやすい設計が望まれる傾向にあります。

iGrafx FLOWCHARTERiGrafx PLATFORM


- 開発


システムの開発は、環境によって使用する言語や、支援するツールが違ってきますが、業務プロセス改革では、最新のIT技術を取り入れやすく、且つ迅速に開発できること、開発ノウハウが特定個人に依存せず、他の人にも理解できるものが求められます。
作成されるシステムは、セキュリティポリシーに適合するレベルで、巧妙なサイバー攻撃に耐えるような強靭なセキュリティが保てるシステム開発が望まれます。
開発内容によっては、RPAのソフトウェアロボットを使用して、AIやEAI/ETLツールなどを活用することで、プログラミング効率を圧倒的にあげる方法もあります。
また、クラウドサービスなど、すでにあるアプリケーションを上手く取り込んだり、ローコード開発やノーコード開発のツールの採用も、かなり有効です。

ROBOWARE

- 実装


実装を行うために、現状(As-Is)をあるべき姿(To-Be)へ導くための改善施策として検討したシナリオを、最適なものになるよう仮説を立てシミュレーションによって繰り返し検証します。具体的には、リソースの量や使用時間などを仮定して複数種類の設定を行い、定量比較などできるだけ可視化できる形でシミュレーションします。
シミュレーションによって、現状の問題点・ボトルネックなどが定量的に把握でき、意図した方法で業務の流れを変えたときの効果も定量的に評価することが可能となります。これにより、効果的なプロセスの変更やリソースの再配置などの具体的な施策に着手することができ、企業の業務改善・改革を成功に導きます。

iGrafx BPRiGrafx PROCESS


- テスト


テスト検証には、開発したアプリケーションの可視化のために、ソースコードを様々な角度から解析できるツールがあると非常に効率的です。 また、アジャイル開発などでは、実装前に失敗するテストコードを書き、次にテストが成功するコードによってロジックを追加していき、テストがパスしたらリファクタリングを行って、実装が完了するまでそれを繰り返すテスト駆動開発(TDD)などの開発手法も有効です。

ChangeMiner

③ 運用フェーズ

 

変革を狙った業務プロセス改革において、保守・運用によって、陳腐化せず、俗人化したシステムになってしまわない仕組みを作ることが大切です。業務のフローチャートが更新されていないとか、最新のプログラムのソースはどれかわからないということが無いように運用しなければなりません。
セキュリティインシデントに迅速に対応し、被害を最小限に抑えることができるシステム運用が不可欠です。理想は、経験が無い担当でも、誰でも運用できる業務システムであることです。

- 仕様変更


運用フェーズに入ってからの、業務プロセスの仕様変更は必ずドキュメントを残す必要があります。作成フローチャートから、各種ドキュメント資料とリンクして管理できていないと、レガシーシステムの二の舞となり、システムがブラックボックス化してしまうリスクが残ります。関連するドキュメントも連動して、変更管理できるような仕組みにしておくことが得策です。

iGrafx FLOWCHARTER

- 影響分析


仕様変更や、障害対応など、アプリケーションの内容を変更する場合、アプリケーションのどの部分にどのような影響があるか、あるいはセキュリティ面でのリスクは無いかなど、構想上や関連性において影響分析できる仕組みが必要です。そのためには、CRUD (Create, Read, Update, Delete) マトリックスなどの分かり易い情報を提供して、構造分析、関連分析、フロー分析、品質診断、脆弱性診断などができるツールが役立ちます。

iGrafx FLOWCHARTERChangeMiner

- 改変履歴


開発された業務アプリケーションに変更が生じた場合、変更したプログラムの内容に合わせて、業務フローが常に最新のものにアップデートされているかが、障害時や変更時の影響分析などで重要となります。そのためには、アプリケーションを解析して出てくる情報が、毎日自動更新され、更新履歴が残るような仕組みが有効です。 
改変履歴のログが信頼できないものであると、予期しないトラブルを起こしかねません。

ChangeMineriGrafx FLOWCHARTER