自動化の果てに残る手作業:要件定義
ITの発展に伴って、さまざまな作業の自動化が進んでいる。どんな複雑精妙な作業であってもいったん手順化してしまえば、コンピューターは飽くことなくそれを繰り返してくれる。また、主題に関する膨大なデータがあれば、人工知能(AI)が主題に沿った応用を自動生成できるようになった。
そんな自動化全盛の時代に、システム開発者の手にはどんな作業が残るのだろう。単純な設計作業、あるいはパターン化されたプログラムのコーディングやユニットテストは、本記事のテーマであるローコード開発技術をはじめとするさまざまな工夫によって自動化されてゆく。その果てに残る手作業は何か。
それは、業務プロセスやデータベース(DB)構造を含めた「システムのあるべき姿」を定義する作業、すなわち「要件定義」である。これは、システム刷新やデジタルトランスフォーメーション(DX)を実現するための最初の一歩であり、要(かなめ)でもある。自動化はおろか、経験を積んだ技術者にさえ簡単にこなせる作業ではない。AIを適用しようにも、教師データの様式化も収集も困難であるためほとんどお手上げである。
一般的なシステム開発の手順
要件定義の困難の本質は、業務担当者と技術者の相互理解の難しさにある。それは自然言語、あるいは業務フローやデータモデルといった図面言語を用いてなされる。しかし、自然言語を用いたコミュニケーションは想像以上に難しい。語り手と聞き手、あるいは書き手と読み手の間での解釈の違いが避けられない。求められる業務知識や専門用語も多岐にわたる。図面を用いても、表記法や書き手による出来の違いが著しい。そのため、要件定義を担える要員の育成は簡単ではない。人材は慢性的に不足している。
オブジェクト指向分析の発展と新たな問題
こうした課題への対応策として2000年初頭から、オブジェクト指向分析という要件定義手法が注目されてきた。この手法では業務担当者と技術者が相互理解できる世界共通の表記法「UML(Unified Modeling Language)」の利用が推奨された。これを用いてユーザーとシステムの振る舞いを整理しながら、ソフトウェアのあり方や動きが定義される。この手法によって、それまで曖昧だった要件定義過程の体系化が進んだ。
UMLを用いたシステムの要件と設計の表記イメージ
JavaやC#といったオブジェクト指向言語の発展を追い風として、オブジェクト指向分析を支援するためのさまざまなツールや方法論が生み出された(最近注目を集めるドメイン駆動設計はその一種である)。これらの手段を活用すれば、業務担当者の頭の中にある要望を引き出すことで正しい要件定義を実現できると技術者は期待した。開発組織の管理者も、UMLを教えることで要件定義を担える技術者を育成できると期待した。
しかし業務システム開発において、オブジェクト指向系の分析手法がデファクトスタンダードとなり、この手法を使用して要件定義を担える技術者が増えたかというと、そうではなかった。業務担当者の頭の中にあると考えられていた「業務システムのあるべき姿」が、どこにも存在していないことが明らかになったためである。業務用語を誠実に抽出してクラスやメソッドとして構成しても、それが「あるべき姿」としてまとまる保証は最初からなかったということだ。
なぜ業務担当者の頭の中に「あるべき姿」が存在しないのか。その原因としては、テクノロジーの発展に伴う情報の民主化、新しい雇用形態の登場による働き方の多様化、デジタルビジネスの急速な拡大等の環境の変化が挙げられる。結果的に、業務システムに求められる要件の不確実性が、数十年前と比べて急激に増大した。システム設計のプロでもない業務担当者が「業務システムのあるべき姿」をイメージできていると期待することがそもそも無理だったのかもしれない。
こうして要件定義は、「ユーザーの頭の中にある何かを引き出して整える作業」から、「事業の新しいあり方をユーザーとともに創案する作業」に変化した。なんのことはない。「創造性」を発揮しないままでは要件定義を担えないという点では、30年前と何も変わっていない。むしろ、作業手順を精緻化することで創造性の問題から目をそらし続けてきたのが、システム設計技法の発展史だったといえないだろうか。