IPA「ユーザのための要件定義ガイド」を読むA001

昨年(2021年)11月にIPA(情報処理推進機構)から「ユーザのための要件定義ガイド」第2版(以下:本ガイド)が出ました。500ページの大著で書いて下さったメンバーの皆様にはお礼を申し上げたいと思います。「要件定義を成功に導く128の勘どころ」とあります。

 

最初のパラグラフ「はじめに」の中で、「本ガイドはタイトルにあるように『ユーザのための』要件定義ガイドである」・・・と書いてあります。しかし、ちょっと残念なのは中身を読んでいると、読者である「ユーザ」のペルソナがはっきりしないのです。本文中に【システム化要求の仕様化】と言う節があるのですが次のような表現が出てきたりします。「システム部門やベンダーが作成したドキュメントを業務部門が分からない、レビューできない」・・・です。やっぱり、システム部門やベンダーが要件定義をしている(少なくともドキュメント作成は)のが前提になっていて、私の考えるユーザ、つまり業務部門中心に要件定義作業が行われることが前提になっていないのでは・・・と思ったりしています。しかし、システム開発の失敗の原因は以前から「要件定義絡みが半分以上」と言われているように要件定義にユーザの積極的関与は今後の日本企業におけるデジタル・トランスフォーメーションにおいても重要な課題であることには異論はないので、このガイドをベースに私の考える「ユーザの手による要件定義」の在り方について考察して行きたいと思います。

 

上で「ペルソナ」がはっきりしない・・・と書きましたが、本ガイドの13ページに想定読者が示されてはいます。

しかし、これだけ想定する読者が多いと焦点がぼやけるのは仕方ありませんね。

 

 

本ガイドの23ページに「システム開発の失敗の原因」についてJUASのデータが示されており半分以上を要件定義の問題が占めていると言われています。

ちょっとデータは古いのですが、現在もほとんど変わっていないと推察しています。

 

さて、図1を見るとTOP3の原因がそれぞれ、第1位「要件仕様の決定遅れ」、第2位「要件分析作業不十分」、第3位「開発規模の増大」となっています。第3位は開発が進むにつれて要求が膨れ上がったのだと思います。

私が注目するのは、比率は低いのですが「システム化目的不適当」で、謂わば「超上流工程」です。と言うのは、RFPの不備や要件定義の不備もここに真の原因があったのではないと考えられるからです。

 

【ユーザ企業とベンダ企業の関係】

私は30数年前に大手都市銀行で第3次オンライン開発に携わりました。立場はユーザの企画で、外為事務の再構築と新システムの要件定義(及びテスト)でした。

ビジネスプロセス・リエンジニアリング(以下、BPR)は1993年にマイケル・ハマーとジェームス・チャンピーによって紹介されましたが、1980年代に行われた上記銀行の第3次オンライン開発における外為部門の開発はビジネスプロセスの全面見直しと新機能の追加、システムの全面刷新を行うハマーとチャンピーに先立って行われたBPRでした。

 

当時、開発スケジュールはご多分に漏れず、時間と予算との闘いでもありましたが、私もベンダのプログラマを10人程度預けられ期日までに要件定義、開発そしてテストを終わらせる責任を負っていました。直接プログラマと直接要件についてのやり取りをしていましたから、今、思い出すとアジャイル開発でスクラムの原型をやっていたんだな・・・と思います。(今のアジャイルと違うのは①開発言語がPL1でリリース後の修正は困難②全プログラムのリリースが同一日だったこと。)このプロジェクトでは、ユーザである我々とベンダの関係は明白でした。要件定義(ほぼ仕様書に近いもの)をユーザが書き、プログラマはそれをコードに落とし、テストケースもユーザが策定して共同でテストをする・・・で、QCD責任はユーザが負っていました。

私たちの時代、このシステムが出来るまでの外為業務はシステム化が遅れ我々は手作業で業務をしていましたから業務プロセスは手に染みついていました。そのお陰で、上のような開発も出来たのだと思います。しかし、その後、業務プロセスの多くの部分がシステム内にソフトウェアの形態で蓄積され、ユーザはシステムの操作にしか触れず、基本となる業務プロセスから縁遠くなってしまい、ユーザが自力で機能要件を書くことが出来なくなってしまいました。そして、システムの運用や機能修正に携わっていたベンダの技術者に頼るようになってしまった上、要件定義はユーザの業務ではないような風潮に陥ってしまっています。

本ガイドでも要件定義は発注者であるユーザの責任で行われるべきと主張されていますし、経済産業省の「情報システム・モデル取引・契約書(2007.4)」でも要件定義は「準委任契約」ですべきと求められていることが紹介されています。

 

 

以降、どうやったら機能要件定義をユーザの手で行えるようになれるかを本ガイドを読みながら綴って行きたいと思います。