最寄りで進行している案件について、作業に従事している会社の若手氏から「酷い状態ですが一体何がだめだったんでしょうか」という質問が挙がったので、説明したことをメモしておきます。
開始時点の状況がすでに赤い
受注した時点で顧客からは「予定を月単位で過ぎてるんですよね」という話があったらしいです。これは要するに、他の会社が敬遠した「真っ赤っか案件」を喜んで引き受けてきたということですね。
本来であればこの手の案件、状況でスタートの場合、当然遅れを取り戻すためにどこかで注力する必要があることから、費用を高めに請求したりするものですが。おそらく失注を恐れて通常価格で取っているのではないかとおもわれます。
当然、遅れているのだから下記のような努力が必要ですが、多分やっていません。
- 人員を投入して作業をガンガンすすめる
- ユーザーと日程を調整して後ろ倒ししてもらう
- 作る機能を減らしたりして作業量を減らすか機能を簡単なものに変える
結果的に、後ろの工程（設計、実装、テスト等）にしわ寄せが行きます。
設計者がミドルウェアを知らない
どうやらシステムで利用することが決まっていたミドルウェアの機能や制約事項について、要件定義者および設計者は全く知らない状態で作業を進めたそうです。
たとえば、データベースから情報を抜き出して表示する場合に「単位は自由に変えられるのか」「1,000円単位（50K円、のような）といった表記はできるのか」「人名を出す際に敬称やミドルネームなどにも対応しているのか」など、いろんな要望やツール側の制約があるとおもうので、それらを
- 存在する機能で実現する
- 存在しないので自作する
- 存在しないので利用を断念して代替方式を検討する
など、細かく判断しなければいけません。しかし、おそらくそれをやっていません。結果どうなるかというと、実装段階で「この設計に書かれていること、この仕組みではできませんよ？」となったりします。当然、設計に戻るため作業は遅延します。
データベースの設計が冗長すぎる
本件を担当した設計者が下記のようなデータベースのテーブル設計を行っています。
- 数値や文字のデータ桁数を多く持たせる …… 一律20桁、のように、3桁であることが判っていても多めに用意している。テストやメンテナンスで使わない余計な桁についても考慮する必要がでてきて無駄が生じる（全桁数値で埋めるテストをするのか、しないのか。1か0しか入らないのに999といった値も確認するのか、など）。
- 無駄にNull可の列が多い …… 業務上必須でもNull可であったりする列が多い。実装やテストでの場合分けが無駄に増える。
- 日付や数値であることが確定していても文字列として定義されている …… 日付であっても文字などで定義されていて、さらに上記のNull可でNullの可能性もある作りになっている。日付の書式違いや異常値の検知に実装工数やテスト工数が割かれる。また、数値はマイナス値が入ると1桁減ってしまうため、桁数に関するテストの考慮事項が増える。
- 外部キーは使っていないが、かといってテーブル間で同じ意味を持つ列なのに名前が違う …… キーとなる列が「受注番号」であっても、テーブルによっては「受注番号」だったり「案件番号」だったりして名前が不揃い。しかし外部キーの定義もないので第三者はこれが同一かどうか判断が付かない。
- 列名のルールが不揃い …… 数値に「Nm」のような数値であることをあらわす名称を付けていたり、付けていなかったり、付けていても実態はVarcharだったり。読み手が名称に惑わされて無駄が生じる。
この設計者は以前からこうしたやり方をやっており、以前にも一度「なんで桁数を全部大きめの15桁にするのですか？」と聞いたところ、「そのほうが設計が楽。型も文字列にした方が設計書がシンプルになる」と答えていて頭を抱えた記憶があります。
設計者が処理のSQLまでガッチリ書いてしまっている
これはどちらでも良いのですが、上記の「ミドルウェアの特性を知らない人」が具体的なSQL、それもフォーマットをツールで整えたら2,000行ぐらいになるSQLをバンバン書いてしまっているので、プログラム側の実装段階で不整合やミスマッチが発生して手戻りが出ます。
また、SQL自体も付け足し付け足しで書いているため、全体を通した最適化が行われておらず、無駄なテーブル参照や、3段構えのビュー（ビューからビューを呼んで、そのビューがビューを呼んでいる）、200列ぐらいのSelect対象全部にCase Whenでの場合分けが200個入っている、等々。なかなかな内容になっていることから、テストデータ作成や「これは何をしているのか」の把握が困難でトラブル発生時の対応も遅れます。
テーブル定義が最新化されていない/DB関連資料が無い
上記のような状況で、作業中に出た変更点や修正が資料に反映されていません。また、ビューやストアドプロシージャーなどの設計書が全く書いてなかったりするため、肝心のロジックがシステム稼働前から既にブラックボックス化されてしまっているという状況です。
実装/テスト工程に入ってもデータの詳細が詰められていない
基本的にマネージャークラスが顧客と交渉をしていません。従って、いつまでにコレがないと遅延がでる、ということについてキツい発言を出来ておらず、ユーザーから情報が出てこない、という理由でテスト工程になってもデータの構成が決まらない、といった状況が発生しています。
本来、遅延状況で受注した時点で少々強気に出たり「請け負う前提条件」として情報提供や協力の必須化は言っても良いと思うのですが。どういう力関係で契約しているのか……。
どうなるのか
とまぁ……まだカットオーバーしていないらしいのでどうなるのかは不明ですが。少なくとも長期の運用で「インフラ運用」「問合せや不具合の対応」に支障が出る要素が満載なので。非常に危なっかしい状態です。
というわけで、若手氏への回答を少し細かく書き直してみました。
