要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

要件を定義する者のブログを立ち上げた理由

仕事柄、色々なシステム開発プロジェクトに携わってきた。

 

大規模なシステム、中規模なシステム、小規模なシステム。

 

問題の発生しないプロジェクトはほとんどなかった。たいていのプロジェクトは納期遅れとなるか、納期は死守されるがスコープは極限まで落とされるというようなものであった。

 

問題のあるプロジェクトの中でも特にひどいのは、要件が定まっていないプロジェクトだ。システムを作りたい人たちが、要件をわかっていない。作りたいものがわからないから、作ってみる。作ってみたけど、思っていたのと違う。無駄の無限ループだ。

 

確かに、要件定義は難しい。なぜならば、これから作成するシステムというのは、まだ世の中にないものだ。世の中にないものを文章で定義するというのは、非常に難しい。想像で誰かの似顔絵を描くようなものだ。難しいしやり方もわからないから、誰もやりたがらない。発注側は、ベンダに任せようとする。ベンダ側は、発注側に任せようとする。時間だけが過ぎ、なんとなくプロジェクトは進む。結果、思っていたものと違うものが完成する。

 

プロジェクトは遅延すると、挽回が非常に困難である。昨日判明した遅れが、今日挽回できることはない。遅れはずっと続き、関係者すべてが不幸になる。筆者は、このような状況を何とかしたいと考えている。だからこそ、このブログを立ち上げたのだ。

 

こんなこと言ったらエンジニア失格かもしれないが、筆者は、素晴らしいシステムを世の中に出すということや、最新のテクノロジーを使いこなすということにあまり興味がない。エンジニアといっても、結局、ほとんどの人はサラリーマンなのだから、つまらないことや、やりたくないこともやる必要がある。筆者が目指すのは、みんなが最新のテクノロジーを駆使してイケイケの開発をする世界というよりは、途中経過は平凡でつまらないかもしれないが、各自が各工程でやるべきことをしっかりとやって、波風立たずプロジェクトが完了し、顧客に感謝されるという世界だ。

 

そういう世界を実現するためのキーとなる技術が要件定義と考えている。

 

本ブログでは、要件定義を軸として、エンジニアが不幸にならないような、役に立つ情報を発信していきたい。