今年の４月〜８月頭にかけてやった案件のお客さんの担当者のことを、惜しまれながら退社されたDさんがおっしゃられたコトがあります。
このお客さんは情報システム部におられる方でしたが、基本的なSQLも怪しくましてやWebアプリなんて何も知らない方でした。また結構直情的な方で、打ち合わせに行く度にいらっしゃると「今度はいつ吠えるのか」をネタにした事もありました。
そんな困ったお客さんでしたが、彼はこちらの設計書を見る度にパターンの記述を要求しました。「処理概要とかちょーだりぃからモデルケースを用意汁！」が十八番でありました。
ウチのメンバーはその姿勢に辟易していたんですが、*1システム開発に関わるのならパターンマニアで在ることは基本的に正しいと思います。
何故ならば、仕様はパターンの集合体だからです。
パターンとはシステムでやりたい事と同意です。そもそもパターンの定義が違う事が一番よろしくないことであり、そのお客さんは自分がわかる範囲ならば煮え湯を飲まされてなるものかと言うポリシーがきっとあるんだろうなと、今思います。お互いにとって不幸だし。
仕様がパターンの集合体であり、尚且つある共通点を持ちうるから「デザインパターン」というベストプラクティスがあるんじゃないかと。
要件定義などの上流工程では大まかな幹だけ決めて後から枝葉付ければええやろ、っていうアプローチが良く取られますが動かないシステムが生まれる典型な負けパターンがコレなんだね。
木を見て森を見ず、そして森を見て畑を焼き払うようになりませんよう。
*1:基本設計レベルでパターンばっか出してくれって言われても全然仕様決まらないよっていう愚痴
