中小企業診断士２次試験チェック模試に参加。去年よりもだいぶましになった感じはしてきたが、まだ詰めが甘い。あと、事例IVの財務が問題になりそう。
毎週、名古屋に出張し、久しぶりにお客さんにヒアリング。まだ、要求定義段階なのだが、システムの本質は例外にあるのではと思い始めた。つまり、正常ケース、一般的なケースはあたりまえ。問題は、現場でおこるさまざまな例外ケース。これらにシステムが追随できるか、極端に面倒な操作を要求されないか、不整合が発生しないか、結果の把握にどのような影響が出て、それは許容できるものなのか。その繰り返しである。
一般的には細かいことであるため、無視されやすい。しかし、ここがうまく機能しないと、「実際には使えないシステム」になってしまう。開発工数もテストも、こういう例外的な事項がほとんどを占めることになる。
他のプログラム、例えば言語等もおなじではないだろうか。例えば、printfやifが動くのは当たり前。むしろ、一見普通じゃないプログラムが動くかどうか、それが実は問題だったりしないだろうか？そして、それが正しく動作できるかが使えるかどうかの分岐点になったりしないのだろうか？いわば、文法の隅をつつくような、一般的にはほとんど使用されないような細かいところであるにもかかわらず。
要求定義段階でどこまで細かくやるのは別として、次のことはできていてほしい。
- ユーザーから見てプログラムが要求される動作
- どのようにプログラムが動作するかは不要だが、正しいアウトプットが計算できるはずの、インプットは取得できる保証
つまり、インプットとアウトプットが明らかになっていて、それらが理屈として変換できるはずであれば、問題ない。ただ、細かな部分がとても大切で、そこをおろそかにすると、要求定義の意味をなさなくなってしまう。
