「電力自由化システム、大トラブルの真相」

http://business.nikkeibp.co.jp/atcl/report/16/022700115/080700031/

2014年4月の説明会で広域機関は、短工期である点や発注時点で制度が固まっていない点、制度設計と並行してシステム仕様を固める必要がある点、仕様の追加・変更が発生する可能性がある点をITベンダーに伝えている。

既にグダグダすぎるんだが.

日立の提案内容は工数と金額の両面で、他社の見積もりを大きく下回っていた。特に、「連系線等利用計画管理」関連の開発規模は、他社が提出した提案の約9分の1と極端に少なかった。

その点、日立が提出した提案書には広域機関が発行したRFPのコピーが多く含まれている印象があり、詳細についての記載がない部分もあった。

 だが広域機関は、「ミドルウエアの流用率を高めることで工数を数割程度削減する」、「2段階開発で短工期対応する」といった趣旨の日立の説明に納得。「開発流用率が当初予定まで達しない(開発の際に想定通りにミドルウエアを用いることができない)場合は、開発会社の責任においてその都度リソースを投入し、工程の厳守・品質の確保に努める」との回答も得られたことから、開発規模や流用率の見誤りリスクがあることを認識したうえで日立案の採用を決めた。

「開発会社の責任においてその都度リソースを投入し、工程の厳守・品質の確保に努める」って,「デスマーチだけど死ぬ気でなんとかするつもりです」ってだけだもんなあ.

しかし、開発するプログラムの量にして総量50万ステップ相当と見込んでいたシステムの規模は、桁違いの400万ステップほどに膨れ上がった。連系線等利用計画管理を含む広域機関システムの各種計画系機能において、上述した流用率の見誤りリスクが顕在化し、日立が用意したミドルウエアがほとんど使い物にならなかったのが主因の1つだ。計画系機能で新規開発するプログラムの量が増え、結果的に広域機関システム全体の開発に要する工数を大幅に読み違えた。

ところが、広域機関システムの開発プロジェクトでは、計画系機能の仕様変更の凍結時期が2カ月延期された。この段階で信号は黄色から赤色に変わろうとしており、その後、2015年秋にはクッキリと赤信号が灯った。

設立準備組合を経て広域機関が発足したのは2015年4月1日。大手電力からの出向者などが集まり、ようやく8月末から広域機関の業務フローの検討を始めた。

 システム開発において、業務フローの内容は極めて重要で、その決定いかんによってはすでに作ったシステム使用への手戻りが発生する。案の定、広域機関システムの開発プロジェクトでは検討結果を踏まえたシステム仕様の大掛かりな変更や追加が9月以降に多発し、仕様変更は最終的に2016年1月まで続いた。

ころが、広域機関システムのプロジェクトでは、2015年9月頃から計画系機能に関する仕様書や設計書の更新が滞った。全面自由化が刻々と迫る中で繰り返される仕様変更により、日立は仕様書の修正もままならない状況になった。

 システム仕様の追加や変更が発生すると、日立は技術者に口頭で内容を伝えたとされる。また、プログラムの開発工程が遅れていたことから、設計書の作成よりプログラム開発体制を強化し、システムの稼働時期を死守したいと考えた。

日立に対して「仕様書が書ける人材が欠けている」と何度も陣容強化を要請していた。だが、広域機関システムを理解して仕様書を作成できる技術者の養成に時間がかかり増員は困難、と日立は判断した。

http://b.hatena.ne.jp/entry/business.nikkeibp.co.jp/atcl/report/16/022700115/080700031/

  • id:kamei_rio (ある重要な機能について)ミドルウェア流用を前提に、他社提案の約9分の1で受注。実際は流用できず、50万ステップが何と400万ステップに / 書きっぷりから↑と判断したけど、仕様確定の遅れも含まれて400万なのかな?
  • id:ssig33 id:kamei_rio この記事からだとミドルウェアの流用失敗したのと、仕様変更がリリース直前まで続く糞発注元がいたのと、どっちがコード量増えた要因なのかわからない感じじゃないですか


たしかにどちらが原因かわからない.

しかし受注時には制度設計さえおわっておらず,仕様を固めるのはその後の予定という段階で、フレームワークが使えるかどうかの判断はできなかったはず.実際には仕様変更が入ってフレームワークが使えなくなるリスクは小さくはないし,一度そうなったら最後,開発規模が膨れあがって泥沼のデスマーチになるのは最初から承知の上だったのではないだろうか.