予想を裏切らない

機能仕様がぼちぼち出てきている。

なにがなんだか、一番訳が分かってない僕が目次を考え、書かなきゃいけない内容を指示して書かせていたのだが、目次に不備があるとか、自分の考えではこう書くべきだとか、というような意見は全く出てこなかった。

しまいにゃ、どういった内容を書いたらいいのか、僕に聞いてくるし。

君達は、今までここで作業していて、いままで機能仕様を作るときには何を考えてどうやって作っていたの？とこっちが聞きたい。

僕に聞かれたところで、君達には僕のイメージ通りのものを作成できるだけの力はないのだから、君達のやり方で、精一杯のものを見せてくれよ。


そしたら出てきたよ。


予想通りのものが。

書けといわれたから、何も考えずに書いてみました的な、その仕様書は何？

で、何をレビューしてもらいたいわけ？

つうか、何が言いたいのかさっぱり謎なんだけど。

ダメダメプロジェクトの典型だなこりゃ。


機能仕様を書き始める前に、僕が持っている機能仕様のイメージは伝えたのだが、抽象的過ぎるだの、グルーピングのレベルがわからないだんと、理解できないことについていろいろ言い訳を並べていたくせに、自分たちのやりかたでやった結果がこれかい。

大したもんだ。

ソフトウェアには静的側面と動的側面があり、その両面から記述してやらないと、ソフトウェアの構造を説明することはできないんだけどね。

そういう基本的な知識も、全く持ち合わせていないらしい。

この先も、何となく詳細設計して、製造して、製造が進むたびに機能設計・詳細設計の各フェーズでボロが見つかり、製造がどんどん押していくと。

そして、製造が押したおかげで、スケジュールが圧迫され、単体テストの時間が取れなくなると。

適当に単体テストして、結合・総合テストで適当に思いつくパターンのみをテストして、結合・総合テストが全て通ってしまえば、それでテストOKにしてしまうと。

実際には、単体テストをすっ飛ばして、結合・総合テストのみではテスト網羅度が著しく低く、とてもとても品質を担保できるといったレベルのテストにはなっていない。

でも、見た目上、もうテスト項目が思いつかないから、テストはやり尽くしたということで、リリースしてしまうと。

客先では、これまでと同じように、運用に入ってちょっと動かすといたるところでバグが出て使い物にならなくなると。

一応、こうなることが今から予想されているので、オボッチャマ達には、十分単体テストをするように指示するつもり。

だけど、製品として製造するコードの規模とテストプログラムのコードの規模が同等以上になるようにテストプログラムを作って隅々までテストしろと指示したところで、オボッチャマ達は頑なに抵抗するんだろうな。

自分たちの作業が著しく遅いのを棚に上げて、「理想としてはそうかもしれないが現実的でない」とか、なんとかいって。

現実的でないもなにも、僕が作業するときは常にそうやって作業してきているんだけどね。

あぁ、この先も僕の予想を裏切らない事態が続くんだろうなぁ