電力広域的運営推進機関(広域機関)は2017年6月に、ある報告書をまとめた。全国の電力網の司令塔ともいうべき「広域機関システム」の開発トラブルを総括したものだ。

 広域機関は外部の専門家による第三者評価委員会を設置して、報告書を作成。プロジェクトの実態をつまびらかにした。そこには、システム開発を発注した広域機関と、受注した日立製作所の混乱の様子が記されていた。電力小売り全面自由化のスタート時に混乱の火種となった同システムの開発は、希にみる“凄惨”なプロジェクトだった。

 システム開発にトラブルは付きものだ。プロジェクトの実態と、広域機関の対策を他山の石としたい。

関係者35人、計70時間のインタビューで実態を明らかに

 広域機関システムは、電力の安定供給を担う中核システムである。全国の小売電気事業者と発電事業者が作成した計画を取りまとめ、一般送配電事業者が需要家に電気を送り届ける司令塔、すなわち広域機関の日々の基幹業務に用いる。

 このシステムの規模が、公募で開発案件を勝ち取った日立製作所の想定をはるかに超え、10倍近くに膨れ上がった。見込みの甘さと、システム仕様の変更が多発したことが規模膨張の要因である。本来であれば仕様変更に伴い修正するシステムの仕様書や、改定するプログラムの設計書も、プロジェクトの途中から変更内容が反映されず放置された。

 広域機関は、「間に合う」「何とかする」という日立からの報告を信じ切り、稼働見送りの決断が2016年4月の全面自由化のスタート直前までズルズルとずれ込んだ。さらに広域機関内では、業務ルールを定める部門とシステム開発を担当する部門の意思疎通がうまくいかず、システム品質の低下を招きかねないリスクがなおざりにされた。

 このように広域機関システムを巡るトラブルの原因は1つではなく、プロジェクトの随所に散在した。裏を返せば、システム開発プロジェクトを成功に導くうえで参考になる材料が、それだけ多い。

 混乱を招いた当事者の責任を改めて問うことは簡単だが、数多の落ち度を指摘するだけでは生産的とは言い難い。広域機関や日立の肩を持つつもりはないが、広域機関システムの開発プロジェクトを俯瞰して両者の失敗を予断なしに見つめ直し、疑似体験として取り込む。そうすることが、自社で開発・運用するシステムの品質向上につながるはずだ。

 そこで今回からシステム開発編とプロジェクト体制編の2回に分けて、第三者評価委員会で浮かび上がった当該プロジェクトの実態をみていく。第1回はシステム開発編として、プロジェクト進行中に灯った「発注の赤信号」と「受注の赤信号」、「設計・開発の赤信号」という3つの視点でプロジェクトを検証する。

 なお、広域機関は広域機関システムのトラブルや開発遅延を受け、システム監査の専門家などで構成する第三者評価委員会を2016年10月に設置。広域機関と日立に残っている関連資料を網羅的に集めるのと併せて、双方の関係者合計35人へ各2時間の個別インタビューを実施し、広域機関システムの開発に影響を及ぼすことになった事実を洗い出した。

発注の赤信号:日立提案のリスクを認識しつつ採用

 まずは、広域機関システムの開発会社が日立に決まるまでの事実を整理しておこう。

 広域機関の前身である広域的運営推進機関設立準備組合が、広域機関システムの開発会社を選定するために公募を開始したのは2014年4月1日。同月25日に全195ページにおよぶRFP(提案依頼書)を発行すると共に、それまでに提案意思を示していたITベンダー6社を対象に説明会を開催し、期限である6月27日までに2社から提案を受けた。

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

 この連系線等利用計画管理こそ、全面自由化までに開発を完遂できず、2016年4月のスタート時から業界の混乱を招いた機能だ。大手電力会社のエリアをまたぐ電力の受け渡しを管理するもので、例えば、東北電力エリアの発電所で発電した電気を東京電力エリアで販売する時などに使う。全国規模で電力小売りの競争を活性化させるには不可欠な機能だ。しかし、広域機関は予定していた6種類の計画管理機能のうち4種類の稼働を、自由化直前の2016年3月末になって見送った。

 広域機関は他社の提案とかけ離れた日立の提案内容の実現可能性を確認するため、同社に見積もりの根拠を求めた。しかし、低価格を覆すだけの疑義を抱く悪材料を見出せず、2014年8月末に日立の落札が決まった。

 黄色に点灯した信号を目視しながら交差点を通過したイメージだが、実際はこの過程で赤信号がはっきりと灯っていた。それを広域機関は黄色と判断した。

 一般に、発注者が提示したRFP(提案依頼書)の記載内容があいまいな場合、ITベンダーの提案内容もいい加減になりがちだ。それでも、開発にかかる工数や陣容をできるだけ正確に見積もり、予算超過や工期遅延のリスクを最小限に食い止めるべく、ITベンダーはRFPに基づいて可能な限り具体的に開発するシステムのイメージを描く。その点、日立が提出した提案書には広域機関が発行したRFPのコピーが多く含まれている印象があり、詳細についての記載がない部分もあった。

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

 そもそも広域機関の担当者は、大手電力で電力の需要監視や供給力制御を担う中央給電指令所のシステム開発実績がある日立のブランドを信じていた。このことが、日立の提案内容に含まれる流用率などの見誤りリスクの過小評価につながった可能性は否定できない。

受注の赤信号:業務フローが決まらない、特大リスクを読み誤った日立

 一方の日立は、広域機関システムの開発プロジェクトが明らかに抱えていた特大のリスクを完全に読み誤った。

 2014年4月の説明会で広域機関は、短工期である点や発注時点で制度が固まっていない点、制度設計と並行してシステム仕様を固める必要がある点、仕様の追加・変更が発生する可能性がある点をITベンダーに伝えている。日立は当然、短期決戦の難プロジェクトになるのは必至だと認識し、開発規模の膨張も折り込んでいたはずだ。

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

 2014年12月末の段階でシステム仕様の変更をいったん凍結する、との日立の求めがかなわなかった影響も無視できない。

 大規模なシステムの開発では、システムの稼働日やテストに必要な期間から逆算した一定のタイミングで、仕様の変更を打ち止めにすることが多い。五月雨で発生する仕様変更に伴う開発作業の手戻りなど、プロジェクト全体のスケジュール遅延につながるリスクを排除するためである。ところが、広域機関システムの開発プロジェクトでは、計画系機能の仕様変更の凍結時期が2カ月延期された。この段階で信号は黄色から赤色に変わろうとしており、その後、2015年秋にはクッキリと赤信号が灯った。

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

 システム開発において、業務フローが固まっていないということは、何も決まっていないに等しい。案の定、広域機関システムの開発プロジェクトでは検討結果を踏まえたシステム仕様の大掛かりな変更や追加が9月以降に多発し、仕様変更は最終的に2016年1月まで続いた。

凄惨を極めた開発プロジェクトは現在も続いている
「広域機関システム」の開発経緯

設計・開発の赤信号:度重なる仕様変更に、文書管理せず口頭で指示出し

 広域機関システムの開発プロジェクトでは、システム品質へ直接的に影響を与えかねない赤信号も灯っていた。ドキュメント管理の放置が、それだ。

 システム開発プロジェクトでは通常、システム仕様書に基づいてプログラムの設計書を作り、設計書に従って技術者がプログラムを開発する。そして、作成した個々のプログラムやシステム全体のテストでは、設計書あるいは仕様書のとおりにプログラムやシステムが正しく動作するかを確認する。

 テストの結果、想定したアウトプットや性能が得られない場合は、仕様書や設計書に基づいて不具合などを突き止めて改修したり、必要があれば仕様や設計を見直したりして可能な限り不具合が少ないシステムに仕上げる。つまり、正確な仕様書と設計書はシステム品質の重要な根拠の1つになる。

 システム稼働後の機能追加や改修を安全かつ効率よく進めるうえでも、現状を漏れなく反映した仕様書と設計書が欠かせない。機能追加の際にプログラム間で処理の整合性を確保するのはもちろん、改修内容が他のプログラムの動作に悪影響を及ぼさないようにするためだ。

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

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

 システム品質に関しては、早々に赤信号が点灯していたわけだ。この事実は、第三者評価委員会によるプロジェクト関係者へのインタビューで初めて明らかになった。

 もっとも、全体の進ちょく状況と課題を報告する月次の定例会議でほぼ毎回、日立から遅延報告が繰り返されたこともあり、広域機関は赤信号に気づいていた。その証拠に広域機関は2015年8月までに、日立に対して「仕様書が書ける人材が欠けている」と何度も陣容強化を要請していた。だが、広域機関システムを理解して仕様書を作成できる技術者の養成に時間がかかり増員は困難、と日立は判断した。

 仕様書も設計書も事実上、存在しない。人材もいない。広域機関システムの計画系機能を開発する日立の部隊は、もはや破たん状態だった。そう言っても過言ではない。

 現に、どの機能が完成しているのかを確認するため、広域機関の担当者が2016年2月に日立に乗り込んだところ、納得できる回答は得られずじまい。進ちょく状況を管理する案件管理表もなく、現況を把握できなかった。

 そのため広域機関の担当者は、日立からの委託でプログラムを開発するITベンダーの技術者に直に状況を確認。広域機関にとって再委託先となる技術者の情報を基に自ら資料を作成した。この段階で初めて、基本的な機能やインタフェースの開発が抜け落ちていることが判明したが、時すでに遅し。広域機関システムへの機能実装は、2016年3月末までに間に合わなかった。

 これだけ数々の赤信号が灯っていたのに、広域機関システムの開発プロジェクトは、どうして軌道修正できないままトラブルに向かって突き進んでしまったのか。次回はマネジメントや人材など体制の面からプロジェクトの課題をみていく。

栗原 雅(くりはら・もと)
1998年、日経BP社に入社。日経コンピュータや日本経済新聞の記者として国内外企業のIT活用事例やITベンダーの経営戦略、最新技術動向を取材。2006年に独立後、IT専門誌の立ち上げや企業のオウンドメディアのプロデュースを手掛ける。趣味はレスリング(ただし、観戦)。稲門レスリング倶楽部常任委員
公式Facebookページ&メルマガ、ご活用ください
日経エネルギーNextの更新情報やイベントなどの最新情報は、 公式Facebookページメルマガでご確認いただけます。ぜひご活用ください。