7.3. 歴史的背景
要件定義の不備による問題をどのように処理するか、という観点でシステム開発の方法論やトレンドが変化してきたという歴史がある。まずは、要件定義にまつわる方法論の変化について整理する。要件定義に関わるシステム開発のアプローチは図7-1のように変遷してきた。
要件定義工学的アプローチ
「キチンとやればキチンとできる」
方法論が大きく変化しない勘定系のシステムや法律の縛りがあるような業種、古くからの慣習が固まっているような場面では十分通用する方法論だが、すべてのものごとが明確に仕様化できる「はず」だという、現在ではほぼ幻想となっている考え方である。
誤りや漏れをなくせ、当然の前提や例外ケースを確実に伝達せよ、開発者に行間を読ませるような要件定義書は書くな、という掛け声は消えない。しかし、要件は常にどこかがあいまいなままで、完成したシステムと理想とのギャップが生まれている。
要件定義を完璧に近づける努力は続けられているが、その理想は遠いものである。また、あいまいさを極限まで排除しようとすると、一般人に理解しにくい形になってしまう。なぜならば、あいまいさを極限まで排除することを追求していくと、最終的にはZ言語のような形式的仕様言語（Formal Specification Language）や、RSL（Requirements Statement Language）のような数学的な整理に陥ることとなる。これらは、あいまい性こそ排除されるが、その代わり自然言語が持つ柔軟性が存在しない。さらに、少なくとも日本ではコミュニケーションが成立することのない世界である。
プロトタイピング
「ユーザは自分の作りたいものがわかっていない」
システム開発のうえで、要件定義におけるシステム屋とユーザとのギャップは決して小さいものではない。どれだけ綿密かつ入念に要件定義を行ったとしても、なかなかこのギャップを埋めることができない。なぜならば、システム屋とユーザの考え方に根本的な違いがあるからである。この根本的な違いをどのように扱うかが、より完璧な要件定義を行う鍵であることは間違いないだろう。
システム屋は、そのシステム要件の全体を包含し、詳細に落としていくという考え方をする。また、システムを分析する段階では、現状の問題点を抽出するという、現状否定的な思考が働いている。
その一方で、ユーザは現状の業務フローをひとつひとつ拾い起こしながら業務の全体を組み立てていく。日常的に疑問を感じず行っている業務であるため（あるいは、そうせざるを得ないことを納得しているため）、現状肯定的な思考が働いている。この思考の違いが生むギャップは決して小さなものではない。
思考の違いが生み出すギャップを避けるための方法論のひとつがプロトタイプの開発である。プロトタイプは発注側が開発側に情報伝達をする手段として有効である。
プロトタイプ開発には、以下のような特徴がある。
- 詳細から全体へと至る。
- 試行錯誤あり、作ったところまで動かしてみるアプローチである
- あくまで意識するのは正常系のパスだけ
ユーザにとっては、個々の画面イメージを見ながら全体を考えるほうが業務の理解が容易である
紙芝居程度の画面イメージを流して全体を俯瞰できることで、自分が求めているものをほかの人間に伝えることができるのである。
プロトタイプ開発は、そのプロトタイプを拡張しながらスパイラル型の開発をするのか、それともユーザが要求を視覚化するためだけに利用する使い捨て（モックアップ）なのかをあらかじめ考慮に入れたうえで、プロジェクト全体に周知する必要がある。これを明確にしておかないと、後々の開発で、「もうできているはずだ。これだけの変更なのに、どうしてそんなに時間がかかるんだ」というもめごとのタネになるのは有名な話である。
このほかにも、プロトタイプの開発には、さまざまな弱点がある。詳細な画面を見せても、顧客のイメージは一度には固まらない。詳細であるがゆえに、ひとつの画面を何度も何度も修正することになり、実際の開発に進むのがかえって遅くなる場合がある。
また、プロトタイピングは場面ごとに部分最適を積み重ねていくので、会社全体に対する全体最適にはなり得ないことが多いという問題もある。本来は全体を包含しながら詳細を考えるシステム屋も、プロトタイプ開発を行っているときには、ユーザからの要望を満足させるために、ひとつひとつの画面機能に視点が陥りがちである。システム全体を視野に入れながらのプロトタイプ開発は、なかなか難しい。
さらに、プロトタイプは欲しいシステムへのイメージを作るためにあるが、そのイメージが完璧にはならないという本質がある。システムに本番データが登録された状態で利用して、ようやくギャップに気がつくようなことが非常に多いのである。このようなギャップを埋めるのがBPRである。
パッケージの活用
「ビジネスをシステムに合わせろ」
あらゆる業務に対応する「ベストソリューション」としてシステムを導入してきたのが、ビジネスパッケージの世界である。「業務のあるべき姿はすでにシステムが実現していますから、システムに合致した業務プロセスに変更してください」という考え方である。
「業務プロセスを最適化し、それに合わせたシステムを構築する」という考え方はシステム開発の「あるべき姿」である。人材の流動性が高いうえに、組織の改編への抵抗感が少ない米国では、的確なソリューションであった。しかし、人材の流動性が少ない日本では、既得権益や仕事への慣れなどから、従来の業務プロセスを変えることへの抵抗感は非常に強い。結果として、「ウチの会社なりのやり方がある」というユーザからの反対が大きくなる。
この抵抗感を緩和したのが、パッケージベンダのコンサルタントによるコンサルティングサービスとカスタマイズである。
しかし、そのパッケージの本質から離れたカスタマイズに多くの工数をかけることになると、システム化の効果は必然的に少なくなる。さらに、パッケージが想定していない深い階層に至るまでの強引なカスタマイズを行った場合、極端な性能低下や予期しない障害が発生するケースもある。
多くの工数をかけてカスタマイズしたシステムは、パッケージのバージョンアップ適用時にも、また同じように多くのカスタマイズ工数が必要となるというコスト面の問題もある。
スクラップ＆ビルド
「その場しのぎ、ビジネスは勝利者こそが偉い」
どの企業もベストソリューションとしてビジネスパッケージを採用した場合、そのシステムによる効果までもが各社一様となる。つまり、ビジネスパッケージでは競争優位に立てないという限界がある。
システムの要件と仕様のギャップをなくすことは不可能である。さらに、ビジネスの変化に即応していくためのシステムの改修は頻繁に発生する。このような状況の中では、もはや完璧主義を捨て、ビジネスの実情にマッチするシステムを効率的に開発せざるを得ない。システムの開発スピードがビジネスの勝敗を左右することになる。
そこで、SOAのようなアプローチにより、過去の資産をうまく組み合わせシステム化していくことが主流となりつつある。既存のシステムは、開発終了後も障害対応や機能拡張に多額の出費が必要になる。システム開発のスピードアップとコスト削減のために、多数のコンパクトなシステムを作り捨てするという発想が生まれた。
永続的なデータを主体として、「ビジネスロジックはニーズに合わせて頻繁に変わっていくもの」という考えのもとで開発していく。とにかくコストをかけずに迅速にシステム化を行い、ユーザが運用しながら、ギャップを埋めるための改善活動を行う方法論である。
どれだけ要件定義を綿密にしても、そのギャップは常に発生するという観点で考えた場合、素早くシステム化し、利用しながらギャップを埋めていく方法は、コストや効率の面で効果がある。ただし、あまりにもギャップが大きい場合には「使いものにならない」ことになるため、「要件定義が不要」ならないことは、十分に注意しておきたい。
7.3. 歴史的背景 ハッピィ・エンジニアリング関連ページ
- 7.1. 要件定義の重要性
- ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
- 7.2. 要件定義プロセスにおける課題
- ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
- 7.4. 相互誤解
- ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
- 7.5. 要件定義プロセス
- ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
- 7.6. 要件定義の未来像
- ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。