ITProの記事が本質を捉えそこねてる。
これ、リンク貼られた資料じゃなくて、下のPDFを見た方がいい。
http://www2.city.kyoto.lg.jp/shikai/img/iinkai/soumushoubou/data/290703souki01.pdf
何があったのか。
超高速開発ツールでフルスクラッチで開発した場合に、スケジュールに間に合わない事態である事が発覚。
処理性能にも問題がある。
↓
マイグレーションでの開発を選択
↓
マイグレーションしたプログラムの単体テストをフルスクラッチレベルで求められる
↓
スケジュールのびのび、客が不信感持つ。
↓
イマココ
まあ、私も直接的には関係がないんだけど、某独立行政法人の所で、RFPの前提をまるっとひっくり返して（てかプロポーザルだったのに、何故か導入する基盤のパッケージからひっくり返された）お値段据え置きという事をされた事がある。
また、やたら検品に厳しく、というか、日付とかどうでもええやんけレベルの所を「品質」と言われたりするのも経験した事はある。
なので、どっちが「本当に落ち度があったのか」とかとは別に、「証拠資料を幾ら揃えるか」としか思わない。
ただ、ドキュメントベースのマネジメントと、プログラムベースのマネジメントでは、品質管理のやり方は極端に違うし、それが出るのが特にこの手のマイグレーションなのであり、システム作るのに疲れる上に、むしろフルスクラッチの方が期間も予算も認められやすいので楽なんだよね。
ついでながら、どうも純粋なコンバートではなく、新しく作ってしまったシステムに合わせこむように作ってるから、確かに単体テストは必要だし実の所移行調査期間から設計構築期間が短すぎるとは思う。
なお、多分作成請負なのでこんな無理矢理な変更とかもやってんだと思う。
どうすれば
もうね、作成請負の場合には、ドキュメントの体裁だとかモノの作り方だとかは、完全に「客には一切合わせない」という形で押し通す力が必要。
契約書にゴネゴネ書いてきたら、蹴りましょう。
官公庁の場合には、一般企業とは違って、ゴールが「システム完成」ではないんですよマジで。「ドキュメントが揃ってナンボ」なんで。どうせ肥やしにするだけなのだけどね。
あそこは、よく延期とか言うんですが、もう一般企業よりもタチの悪い形で押し込んでくるので官公庁はイヤですし、なので、一般企業にシステム導入するよりも滅茶苦茶利益載っけとかないとしんどいです。その手の追求の労力をシステム開発に使ってくれる金以上にぶち込んでくるので。もうね、
あと、仕様凍結は、もう絶対必須だと思った方がいいです。そういう区切りをつけましょう。どうしても「客はシステムに理解が薄くてもいい」という事になっているので、明確な宣言をしないと止まりません。
