要件定義はシステム開発プロジェクトで最も重要な難所です。

パッケージを使えばスクラッチ開発より短納期・低コストで開発可能ですが、パッケージソフトが既存の業務プロセスと完全にフィットすることはまずありません。また、これまでの経緯や担当者の考え方によって、事業部間でも同じ業務プロセスにバラツキが生じるため、パッケージにフィットする、しないが異なってきます。

こうした現状を踏まえてパッケージを導入するため、システム導入プロジェクトのスタートは、たいていの場合ベンダーSE(システムエンジニア)が行う業務分析になります。業務分析の結果に基づき、現場と調整しながらパッケージの導入方針やカスタマイズの方向性を決定するのです。

ただ、ここで言う業務分析の実態は、システム導入に関する現場への要望伺いです。業務プロセスを抜本的に見直したり、ビジネスモデルの視点から業務プロセスを再構築することはスコープ外です。

SEによる業務分析の結果として、すべてのステークホルダーの意見を充足させるために、システムのカスタマイズ範囲は肥大化、要件はどんどん複雑化していくことになるのです。ましてやDXの文脈になると、現場でのパイロットを繰り返しながらアジャイルで進むケースも多く、当初の想定からどんどん要件が膨らんでしまいます。

＜参考＞日経XTECH「開発費を膨らませるカスタマイズ、パッケージ導入トラブルを防ぐ3カ条」

このような状況はたいへん多く見られるケースですが、こうしたプロジェクト進め方の中で抜け落ちている発想が、BPRです。

「業務プロセスは感情の塊」と以前の記事（【BPR For DX】Vol.1「対話から共感と発想を生み、DXにつなげる」)でもお伝えしたとおり、単なる業務手順ではないのです。仕事に対する想い、こだわり、プライド、人間関係などウェットな要素が複数に絡み合っているのが業務プロセスです。

そのような業務プロセスを、システム開発の要件定義で解きほぐし、整理していくハードルが高いことは、プロジェクト経験者の方は特にご理解いただけることでしょう。論理的な業務整理や導入システムと業務との整合性の確保といった従来SEに求められる役割に加え、現場従業員との信頼関係を構築した上で、本音を引き出し、そして導入に向けた現場の納得感を高める、ウェットなコミュニケーションが求められるのです。

それをクリアできる百戦錬磨のスーパーSEも存在しますが、その数が圧倒的に少ないこともまた事実です。通常のプロジェクトで、SEのヒアリングに過度な期待をかけた要件定義は、プロジェクト炎上リスクの一つと言えるでしょう。

現場にとって納得感のあるBPRを着実に行うことができれば、要件定義も本来はシンプルに完了するはずです。

しかし、BPRなしにシステム導入の要件定義を行うために、現場の納得感が引き出せず、御用聞きに陥り、カスタマイズによってシステムが複雑化してしまうのです。

当社が推奨しているワークショップ形式のBPRは、とにかく従業員同士の対話を重視します。現場を動かす共感、チームワークを最重要視し、要件定義につなげます。また、部門を超えた対話を重視することで、業務の幅を超えた顧客価値の創造に繋げる場づくりを行っています。

プロジェクトにおける要件定義成功のポイントは、ベンダーへの丸投げスタイルから脱却し、従業員同士の自律的な問題解決能力への信頼、そして過去のやり方にこだわらない創造的な発想や実験的な解決を促す環境づくりであると言えるでしょう。