日経BP総研の谷島氏の記事は、多くの業界関係者に一石を投じたと思います。
ややもすると発散しがちなテーマなので、今回、私はこれを「これまでの要件定義のあり方 = クラシック」と、「今求められている要件定義 = モダン」という切り口で自分の考え方をまとめてみました。
モダンな要件定義のあり方とは
クラシックとモダンというように分けた理由は、要件定義の目的が変わってきているのではないか、と捉えたためです。
「クラシック（これまで）」の要件定義は、「今の (AsIs)」業務フローを整理し、そこから「本来あるべき (ToBe) 」業務フローとの差を可視化します。ただ、このアプローチは AsIs のヒアリングがどうしても現行システムの使い勝手の不満という点で語られることが多く、結果として UI の改善程度の要件洗い出しで終わってしまうという傾向がありました。
要件定義はシステム化の出発点であるため、それが現状の改善程度の内容というのはいかがなものか、という主張には一理あると思います。
また、このアプローチは IT 化を省力化、自動化、という世界観で捉えやすく、どこまでいっても改善の延長でしかない、という側面もあります。
ではモダンな要件定義とはどういうものか。この点について業界全体でコンセンサスがとられているわけではありません。谷島氏の続報記事でも、さまざまな論点があることがわかります。
目下の社会的課題は DX つまりトランスフォーメーションを視野に入れるべき、というものです。これは現行の延長ではなく、誰もみたことがない、未来の業務をデザインするということです。もちろん、これは容易なことではありません。
このアプローチに対して、とっかかりとなる足場をどこに置くか、という点で多くの識者が持論を展開しています。私が注目しているのは、次のようなものです。
- 業務フローではなく、データモデルを足場に置く。自分たちが持っているデータ、および、今は持っていないが、こういうデータが必要という観点で洗い出す。もちろん単に項目を見つけるだけではなく、データ間の関連性まで含めて「（データ）モデリング」である。データモデルを出発点に、未来の業務をデザインする。
- テクノロジを足場に置く。クラウド、モバイル、AI などが手の届く範囲で使えるという前提に立つことで、未来の業務デザインを、これらのテクノロジを活用することを前提に組み立てる。
いずれもクラシックな方式からみると異質でしょう。しかし DX を、自社業務を大胆に変革（トランスフォーム）するという視点にたてば、むしろ現行業務の改善ネタしかあがってこない要件定義を変える時期になったのではないでしょうか。
現場主導で、モダンな要件定義をやってみる
先に「現場にヒアリングすると、現行業務の不満点が噴出し、結果として改善ばかりの要件になる」傾向があると書きました。では、現場主導で未来の業務をデザインすることはできないのでしょうか。
私は適切なアドバイザーが側につくことで、できるのではないかと考える派です。注意点として、アドバイザーはあくまで伴走者であり、メインは現場です。コンサルタントという肩書きの方に、我が社のあるべき姿を提示してもらう、というアプローチの真逆と受け止めてください。しかしそれこそが回り道でも最終的に関係者の腑に落ちやすく、それが成功の鍵ではないか、と思うのです。
テクノロジの進歩から目をそらさず、かつ、データモデルを核に捉えるという思考体系を武器にして、現場主導でモダンな要件定義に積極的に関わっていくこと。現実にはなかなかみない光景ですが、私にとっては一つの理想的な姿です。
ローコード開発との関係
ローコード開発ツールとの関連でいえば、概念としての業務デザインを具現化するために、ローコード開発ツールを手元に置くことは必要不可欠です。ローコード開発ツールの利点は、すぐに動くものをつくることができることでしょう。
そしてこれまでの私の経験から、目の前で動作するアプリケーションになってはじめて、要件自体の不備や改善点に気づくものです。
クラシックな要件定義は、「最初の段階で完璧な要件定義をしないとシステムは完成しない」という方針が多かったようにも思います。要件定義、というキーワードを反射的に忌避する方は、これがトラウマになっているかもしれません。
モダンな要件定義は、もっと自由で、創造的で、変更が容易なものであるべきです。ローコード開発ツールはそのアプローチを積極的に支えることでしょう。
