手段の話が先行すると視野が狭くなり、お客さまが本当に実現したいことからかえって遠ざかることもあります。たとえば 「ユーザが入力したデータを保持する」という目的を実現するにはいくつもの手段がありますが、「SQL Server にデータを保管する」という手段に限定してしまうと、ほかの手段を検討する機会を失うことになります。 (p.56)
つい実装よりのことを考えてしまうのですが、そこはぐっとこらえるようにしています。なんだったら、DB に格納する、というコンセプト自体を疑えるようにしたいです。だから、要件は明確にしつつも、レイヤーの高いところで話をしないといけない。オブジェクト指向分析っていうのは、本来そういうためのものじゃないかなぁと思っています。オブジェクトが最終的なクラスになる必要はないですが、分析段階で認識出来る抽象的な「モノ」があると何かと便利です。
特に重要なのは業務フローです。システムの提供する機能だ けではなく、手作業やほかのシステムも含めた「お客さまの業務そのもの」を表現します。(p.59)
要件定義の結果、最終的には「システムは何をすればいいの？」ってことが分かればいいのだけれど、その途中で、外部で何が起こっているか、すくなくともシステムから何が知覚できるのかは書いておかないとシステムは作れないと思います。顧客の立場では逆もしかり。業務フローもちゃんとまとめておくというのは共感です。
それから丸投げ対策なんかも書かれていました。丸投げの発生はしょうがないと考えています。これまでシステムのことを考えもしなかった人たちが、システムを新たに使ったり発注したりするでしょう。そのときに、丸投げすんなって言ってもいいけど、逆にそういうセグメントをターゲットにすることだってできると思います。クリステンセン「イノベーションへの解」にならうなら、最も供給が不足するところに利益が集まるわけです。
さてさて、別な話とみせかけて、スケジュールの話も。
要件定義フェーズで怖いのは「いつになっても終わらないこ と」です。このままでは時間切れで開発に突入してしまいます。 お客さまに進捗を示すことは重要です。ヒアリングも回数を重ねると堂々巡りになることがあります。前回の課題を継続検討していたり、「そもそも論」に立ち戻っていたりしてはスケジ ュールどおりの完了は見込めません。(p.56)
仮に仕様変更があることを前提にした開発であったとしても、前提条件としての仕様は明確にしておいたほうがいいですね。自戒も込めて。でないと、変更が発生したときに、どのくらいの規模での変更があるかさえわからなくなります。規模に影響する要件定義はできるだけ早く決めていくようにしよう、と改めて思いましたとさ。
