要件定義でデスマ化を防ぐ。
一週間なんて、あっという間ですね。
もう、AL実践会から、一週間経過したんですから。
最近、また忙しくなってきて、なかなか辛い時期に
なっています。
システム開発は、どうしても、設計工程以降も
仕様の変更や、新しい要求が発生することがあります。
そして、製造が、逼迫していたりなんかすると、簡単に
思える仕様変更でも、死活問題になりますよね。
こうやって、改めて考えていると、二つのことがらに
思いが巡らされます。
- 要求の抽出と仕様化。
- ステークホルダー間のコミュニケーション。
ごく、当たり前のこと思われることですが、
やはり大切。
裏返すと、これらがデスマに至る要因として、
考えられます。
- 要件定義が適当、あるいは漏れまくり。
- コミュニケーション不足
というわけで、今回は前者の方について、改めて
考えて見ます。
要求、仕様、設計
まずは、言葉の定義。
課題と思っていることに対して、
こうやりたいというユーザのニーズ、これが要求。
その要求を満たすために、システムが備えるべき
こと、これが仕様。
その仕様を、如何にシステム上で表現・実装していくかを
検討するプロセス、これが設計。
要件定義では、要求と仕様を検討し、
基本設計は、そのアウトプットを受けて行う。
何故、要件定義が重要なのか。
世の中に、要求定義や要件定義と言った書籍が溢れていることを
鑑みても、誰もがこのことを重要だと思っていることが
分かる。しかし、実際には本のいうとおりには、
上手く行っていなかったりする。
それは、本に書かれていることが頓珍漢なのだ、
というよりは、実践者の問題が大きいと考える。
要求仕様を定義する者、要件定義者というのは、
中途半端な知識や経験では、その役割を果せないのだと思う。
生半可な適当な、要件定義は、非常に不幸なプロジェクトを
量産する。
仕事として携わる以上、その責任をそれぞれの
ポジションにおいて果さなければならない。
テスターは、テストに対する責任。
実装者は、実装の責任。
設計者は、設計の責任。
要件定義者は、要求仕様に対する責任
プロマネは、プロジェクトに対する責任。
上流以降の工程は裾野が広がる。
上流に行くほど、この責任と影響は大きい。
要件定義者に求められること。
ウォーターフォール開発だろうが、アジャイルだろうと、
要件定義の重要性は変わらない。
なぜならば、顧客が考える、ビジネス課題やサービスと言ったものが
工程を進むにつれ、その本質まで変容することは
ないはずだからだ。
例えば、在庫管理システムにおいて、実績集計の機能が漏れていた
というのは、要求レベルの問題。
実績集計の機能が、オンラインで見れないというのは、
仕様の問題。
実績集計を表示する画面で、ソートボタンが無いのは、
設計の問題。
要求や仕様のレベルの問題は、仕様変更ではなく、要件定義工程の
作業漏れというべきだと思う。
一方、枝葉末節で、変更が発生する可能性はある。
ユーザが思い浮かべるイメージと、実際のイメージが
異なる、あるいは、新しいイメージが浮かぶ。
しかし、それは設計レベルの話だ。
画面上、やっぱりソートボタンが欲しい、あるいは
エラーメッセージで、TOP画面へのリンクを張って欲しい、とかね。
もちろん、このレベルの変更でも、内容と発生のタイミングに
よってはインパクトが大きくなる。
だから、ここで、アジャイルな開発、イテレーティブな開発が
求められる。
変更は発生するものなのだという前提に立って開発を
するか、否かの違いである。
要求や仕様の漏れについては、如何にその漏れを要件定義時に、
防ぐかが重要となる。
この点、設計以降と立脚点が異なるはずだ。
このレベルで、変更が発生するのは、致し方ないという
考えは、ありえないと思っている。
当然、要件定義時には、スコープを策定する。
そのため、要求仕様レベルの発生・変更は、本来、開発には影響しない
はずだ。
しかし、システム開発に投資をする意味を揺るがすような要件が
発見されてしまうと、開発側はそれを飲まざるをえない
可能性が高い。
要件定義者の責任は重い。
だからこそ、要件定義にまつわる方法論が、求められている。
ＤＯＡや、ＯＯＡ、要求開発など、要件定義者にとって
強力な、拠り所が既に存在している。
方法論が全てはではない。他にも大切なことはある。
しかし、これらの方法論を、学ぶこともなく、いわば生身で、
顧客の口から発せられる言葉のみを拠り所にして、
要件定義を行おうとするのは、あまりにも危険すぎる。
