下手な要件休むに似たり

一般的にシステム開発を行う場合、要件定義が重要というのはよく言われることだ。なぜならどんなシステムを作るかの大枠を要件定義で決めるからだ。ここがある程度の方向性を持ってまとまっていないと、その後の設計以降にも多大な影響が出てしまうので、あまりに間違っていると最悪作り直しになったり、まるで融通の利かないシステムや、一見動いているけどもちょっと変更するとすぐあちこちが壊れるシステムなどが出来上がってしまう。
 
しかし、だからといってあまりにこだわりすぎると開発自体が進んでいかなくなるので、ある程度の見切りは重要だ。業務用のシステムならある程度のパターンがあるので割ときっちりと要件定義を進めていける事も多い(それでも完璧、というのは見たことがない)が、新しい物や実験的な物を作る場合は要件定義にこだわりすぎると、だいたいつまらないものが出来るか、そもそも完成しない事も多い。
 
社内で新しい物や実験的な物を作る時に「みんなで考えて」というセリフが出た場合は特に要注意だ。これが「多数からアイデアを求める」という意味ならまぁ悪くは無いが、たいていの場合は「みんなの合意を得て」「計画的に」「予算を見ながら」という過剰な縛りがかかるので、何も決まらずプロジェクトも進まず空中分解したり、出来たとしてもどこかで見たような物になってしまう。
 
こういう場合はある程度の欲しい物の大枠だけをざっと要件として決めてしまい、その後は実際にプロトタイプをある程度作ってそれを評価してその結果をフィードバックしてまた修正をして、というサイクルを回していくのが良い。大体において人は(特に管理職層は)動いている物を見ないと話が進まないし、逆に動いている物をみる事で要件に対して色々悪い部分も良い部分も見えてくるものだ。
 
もちろんだらだらとやり続ける訳にはいかないので、ある程度期間を決めておいてその期間内で進行してくのが良い。いわゆるアジャイル開発のノリだ。これである程度動くプロトタイプを作り、それを要件としてきちんとした製品版の作成に取りかかるのが最善であろう。
 
こういう事を言うといきなり作り始める輩がいるので注意が必要だ。どんな適当な旅をするにもある程度の向かう方向を決めるように、開発するにもある程度の目的地は必要なのだから。もし作り始めたあとにまるで違う方向を向いていることが分かれば、それは良いフィードバックになるので逆を向いてさっさとやり直せば良い。
 
一番悪いのは要件ばかりこねくり回して何も進まないことだ。ペーパーウェアは売り物にならないし(たまに無理矢理売っているのも見かけるが、買った人には災難と言うしか無い)机上ばかりでは何も進んで逝かないのだから。