2018-06-25

あんものは、やった体にしただけのガラクタなのになぁ。

もし本気で言ってるのなら、品質なんて担保できるわけがないのだ。

あのドキュメント群が、どのようにしてこの世に産まれ出たのか、顧客エンドユーザーではない)も開発チームも知っているはずだ。

決して詳細設計ではなく、「プログラミングを一切知らないエンドユーザーが見て解る」機能について説明しただけのドキュメントなのだ

そして更に、上っ面の機能ではなく内部仕様までこと細かく記述した「詳細設計書は作成しない」ことになったのだ。

それを顧客⇔開発チーム双方合意したうえで書かれたモノである

すなわち今あるドキュメントは、たとえば「○○画面には△△が入力でき、決定ボタンホストシステム登録されます。」ということが書かれているだけで、決して「入力された△△を5byteと3byteと8byte位置で分割し、□□と連結したもの送信XMLほにゃららタグにセットしてからホスト送信する。」といったことは書かれていないのだ。

なぜなら、システマティック知識を持たないエンドユーザーが読んでもわからいからだ。

エンドユーザーは、仕組みはどうあれ、思った通りに入力したデータホストシステム登録できることだけを望んでいるのだ。

ところが、だ。

なぜか今は、その上っ面の機能けが書かれたドキュメントだけに基づいてシステム要件検討されていると言うのだ。

無理に決まっている。

上っ面の機能ですら必ずしもすべて書いてあるわけではないのだ。

誰がどう見ても数字しか入力しない入力欄には、誤って英字や全角文字を入れてしまうことが無いようチェックしたりしているのだが、「そんなの当たり前でしょ?」的なレベルのことは省略されていることも多々ある。

そしてその「それは書かなくて良いんじゃん?」には明確な基準は無く、レビュアー感覚、さじ加減次第で省略されるのだ。

経緯は絶対に知っているはずだ。

絶対ということは絶対にない!と言うのなら、ドキュメント作成から上流工程に携わっている人間でも知らない可能性が無いこともないのだろう。

だが、本気で「知らない」と言うのであれば、恐らくそ人間ポンコツの極みである

そのような経緯があるにも関わらず、今になって「ドキュメントに書かれていないこと」を見つけると、「ドキュメント不備だ」「きちんと書かれていないから正しい要件調整ができないじゃあないか」「不具合なのだからすぐ直せ」だとか……もうね、アホかと、バカかと。

期限と費用を重視して、詳細設計書を省略したんじゃねえのかよ?

であれば、追加開発時に改めて現状把握のためにソースコードの解析を伴う調査必要になるに決まってるじゃねえかよ。

でもその工数を開発チームに与えることはしない。

製造が始まっているのに不安定要件がある。

定義部分は末端の担当者に「ユーザー質問してみて」と、体の良い形で実のところ調整作業自体を丸投げする。

遅れや障害でも発生しようものなら「なぜだ?!」の追及の手は緩めず「対策を考えろ」とか、根本原因の大部分を上流が占めていることを認めようとは決してしない。

それで「このプロジェクトウォーターフォールから」とか、どの口?

もうね、アホかと、バカかと。

浄化しない排水を上流から流すせいで下流人間うんこまみれの水飲まされんだよ。

記事への反応(ブックマークコメント)

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん