  |
もし本気で言ってるのなら、品質なんて担保できるわけがないのだ。
あのドキュメント群が、どのようにしてこの世に産まれ出たのか、顧客（エンドユーザーではない）も開発チームも知っているはずだ。
決して詳細設計ではなく、「プログラミングを一切知らないエンドユーザーが見て解る」機能について説明しただけのドキュメントなのだ。
そして更に、上っ面の機能ではなく内部仕様までこと細かく記述した「詳細設計書は作成しない」ことになったのだ。
それを顧客⇔開発チーム双方合意したうえで書かれたモノである。
すなわち今あるドキュメントは、たとえば「○○画面には△△が入力でき、決定ボタンでホストシステムに登録されます。」ということが書かれているだけで、決して「入力された△△を５byteと３byteと８byteの位置で分割し、□□と連結したものを送信用XMLのほにゃららタグにセットしてからホストに送信する。」といったことは書かれていないのだ。
なぜなら、システマティックな知識を持たないエンドユーザーが読んでもわからないからだ。
エンドユーザーは、仕組みはどうあれ、思った通りに入力したデータがホストシステムに登録できることだけを望んでいるのだ。
ところが、だ。
なぜか今は、その上っ面の機能だけが書かれたドキュメントだけに基づいてシステム要件が検討されていると言うのだ。
無理に決まっている。
上っ面の機能ですら必ずしもすべて書いてあるわけではないのだ。
誰がどう見ても数字しか入力しない入力欄には、誤って英字や全角文字を入れてしまうことが無いようチェックしたりしているのだが、「そんなの当たり前でしょ？」的なレベルのことは省略されていることも多々ある。
そしてその「それは書かなくて良いんじゃん？」には明確な基準は無く、レビュアーの感覚、さじ加減次第で省略されるのだ。
経緯は絶対に知っているはずだ。
絶対ということは絶対にない！と言うのなら、ドキュメント作成時から上流工程に携わっている人間でも知らない可能性が無いこともないのだろう。
だが、本気で「知らない」と言うのであれば、恐らくその人間はポンコツの極みである。
そのような経緯があるにも関わらず、今になって「ドキュメントに書かれていないこと」を見つけると、「ドキュメント不備だ」「きちんと書かれていないから正しい要件調整ができないじゃあないか」「不具合なのだからすぐ直せ」だとか……もうね、アホかと、バカかと。
期限と費用を重視して、詳細設計書を省略したんじゃねえのかよ？
であれば、追加開発時に改めて現状把握のためにソースコードの解析を伴う調査が必要になるに決まってるじゃねえかよ。
でもその工数を開発チームに与えることはしない。
未定義部分は末端の担当者に「ユーザーに質問してみて」と、体の良い形で実のところ調整作業自体を丸投げする。
遅れや障害でも発生しようものなら「なぜだ？！」の追及の手は緩めず「対策を考えろ」とか、根本原因の大部分を上流が占めていることを認めようとは決してしない。
それで「このプロジェクトはウォーターフォールだから」とか、どの口？
もうね、アホかと、バカかと。
12
