見えない業務を、
見える未来へ。

本連載について

本連載は、Amazon KDPにて刊行済みの拙著『PReP MODEL - 現実世界をデザインする -：PRePモデルによる業務レベル設計』の内容を、できるだけ噛み砕いてお伝えするものです。なお、第5回以降は有料記事とさせていただいております。

ここまで4回にわたって、要求定義の限界や、業務プロセスの記述方法に潜む見落としについて見てきました。実は、これらの問題の根っこをたどっていくと、ひとつの言葉に行き着きます。それは「システム」という言葉です。

「コンピュータシステム」「業務システム」「社会システム」——私たちは日常的にこの言葉を使いますが、あらためて「システムとは何か」と問われると、案外うまく答えられないのではないでしょうか。この言葉の輪郭があいまいなまま議論を進めてしまうことが、実は業務設計やシステム開発の混乱の一因になっています。今回は、少し遠回りに思えるかもしれませんが、「システムとは何か」を丁寧に問い直してみたいと思います。

前回、ソフトウェアに対する「要求」は、実は業務プロセスという上流の設計から流れ出てくるものであり、要求定義はすでに下流の工程だという話をしました。だとすれば、こう思われるかもしれません。「では、業務プロセスをきちんと図に描いて分析すれば、問題は解決するのではないか」と。

実際、多くの企業では業務フロー図やBPMN(Business Process Model and Notation)を使って業務プロセスを可視化する取り組みが行われてきました。DXプロジェクトの初期段階で、こうした業務フロー図を目にしたことがある方も多いはずです。

前回、IBMのSystem/360の開発を振り返りながら、優れた設計の現場では要求定義と設計そのものが分かちがたく結びついている、という話をしました。誰かから明確な要求を渡されて始まったわけではなく、「コンピュータとはどうあるべきか」という概念そのものを作り出す過程の中に、要求定義にあたる営みが溶け込んでいたのでした。

この話を聞いて、こう感じた方もいるかもしれません。「それはSystem/360のような、前例のない画期的な開発だからではないか。普通の業務システムの開発は、やはり要求定義から始まるのではないか」と。