紆余曲折を経て、長らく付きっきりだったプロジェクトがまもなく終わる。プロジェクト中のいろいろな苦労は思い起こせば限りがないが、今は達成感が上回っている。システム切替も問題なく終わり、無事にリリース。しばらくは平和な時間が過ごせると思った頃に一本の連絡があった。
「ここの業務は3ヵ月前にやり方が変わっています！このままの仕様では業務が回りません！」
平和な時間は儚くも終わり、次のシステム改修が始まる！俺たちの戦いはこれからだ！システム部門の次回プロジェクトにご期待ください！！
そのシステム構築プロジェクトのゴールはどこ？
上の文章は面白おかしく書いていますが、「あるある」と思った方もいらっしゃるのではないでしょうか。
システム構築プロジェクトの場合、半年や1年以上かかるようなプロジェクトも少なくありません。さらに、昔ながらのウォーターフォールでプロジェクトを進めていると、要件定義はプロジェクトの序盤に実施されます。蓋を開けてみれば要件定義からリリースまでの期間が長すぎて、業務が変わってしまっていた。こんなことは決して珍しいことではないでしょう。
業務の変更を考慮したシステムにできていれば良いのですが、対象業務の専門家ではないシステムの設計担当者が「この業務はどこかが変わるかもしれない」と想像して設計するのは難しいのではないでしょうか。
では、どうすれば良かったのでしょうか？
システム構築で業務要件に適合していくには、それなりに時間がかかります。一方で、時間がかかれば社内外の環境が変化して、それに伴って業務も変化していかなければなりません。こうなると「アキレスと亀のパラドックス」のように、システムを構築している間に業務が変化していき、業務の変化にシステムは永遠に追いつけません。
しかし、これもひとつの真実ではないでしょうか？時間が経過すれば業務が変化していくことは当然です。システムもこの変化に適応するべく追いかけ続けなければなりません。つまり、システム構築プロジェクトにはリリースやフェーズ２のような小さなゴールはあっても、明確な最終ゴールはないのです。
人とシステムが業務の変化に適応し続けるために
このようにシステム構築には明確なゴールがないことがわかりました。
では、変化に適応し続けるためにはどうしたらよいのでしょうか？
分解して考えると、業務の実施方法を変化させ、場合によってはシステムに合わせていく必要があるでしょう。また、システム側も業務がより効率的になるように人が使いやすいように補っていく必要があるでしょう。このように、「業務を実施する人」と「システムを改修する人」が互いに寄り添って、業務の変更とシステムへの反映を継続的に繰り返す必要があります。
しかし、現場の業務部門が「システムを改修する人」として、システム部門のメンバーや社外のベンダーを抱え続けることは現実的ではないでしょう。
ならば、現場の業務部門が「業務を実施する人」と「システムを改修する人」のどちらの役割も果たせれば良いのではないでしょうか。
「基幹システムと連携する」のような大規模な改修は難しくても、管理項目の変更、業務プロセスのステップ追加などの簡単な改修を現場で実施できるシステムであることが重要です。
現場自体がシステムの改修をすることで次のようなメリットが考えられます。
- 現場が実施したいタイミングで、スピード感を持ってシステムの改修が行える
- 業務に詳しい人が改修するから、コミュニケーションロスや考慮漏れなどが起きにくい
- 外部に依頼しないから、お金や時間も節約できる
システム部門はもういらない？
現場でシステムの改修などができるようになったら、システム部門はやることがなくなってしまうのでしょうか？
もちろん、そんなことはありません。
高い専門性を持ち、中立的な立場のシステム部門だからこそできることがあります。
- 複数の部門が個別に利用しているシステムを統合して効率化する
- システム化されていない業務領域に対して、ユーザーが使いやすいツールを選定する
- 現場部門のパートナーとして、システムの視点から保守性などを考慮した設計となるようアドバイスする
- システム単体で実現が難しい業務の代替案を検討する
- システム間の連携方式を調整して、実現する
これからのシステムの作り方
「デジタルトランスフォーメーション（DX）」という言葉にも象徴されるように、業務プロセスや業務システムは、外部環境やビジネスモデルの変化にあわせて継続的に変化していくものです。
変化していくことを前提とした場合、「今、この瞬間の業務に最適なシステム」を時間をかけて作るべきではありません。
「とりあえずは8割くらいでシステム化して、PDCAサイクルを回しながら変化に対応して、最適化していく。」そんな柔軟なシステムを導入して、現場主導のDXを実現していきませんか。
