第１０回 広域機関システムの開発に関する第三者評価委員会 議事録

日時：平成２９年３月２９日（水）１６：００～１７：０５
場所：電力広域的運営推進機関 ＡＢ会議室
出席者：
中村 英夫 委員長（日本大学 特任教授）
大谷 禎男 委員（弁護士 元東京高等裁判所部総括判事）
喜入 博 委員（KPMG コンサルティング株式会社 顧問）
配布資料：
・議事次第
・
（資料１）評価委員会報告書
・（資料２）広域機関システムの開発に関する第三者評価委員会からの報告
議題１：第三者評価委員会の報告
第三者評価委員会から、広域機関理事長・理事に対して、資料２を基に、報告を行った。
＜主な質疑＞＜広域機関 理事長＞
半年間にわたる委員会でのご審議に感謝したい。報告書のご提言を踏まえて、広域機関として今後どのような対応をとるべきか真摯に検討していきたい。今回のシステム開発の遅延に関して、開発が納期に間に合わないならば、期限を延期すればいいわけであるが、その判断を行うこと自体が難しかった。これまでに経験した中では、期限に間に合わないなら、通常は、委託先である開発会社から「間に合わない」と申し出があったが、今回は、広域機関からの問合せに対して、開発会社は、「大丈夫、間に合わせます」と回答するばかりで、運用開始直前まで、期限を延ばしてほしいとは言ってこなかった。間際になって、「できない」では、こちらとしてもアクションがとれない。こういった経緯自体が想定外であった。以前、建設業関係の委員会の仕事に従事したことがあるが、建設業の場合は、間に合わないなら、間に合わないと言ってくる業界であった。こういうケースはシステム開発の業界では普通の事なのか。
また、こういう場合にはどう対処すべきなのか、ご意見頂けるとありがたい。
＜評価委員会 委員長＞
委員により意見が違うこともあるかと思うが、私としては、通常であるならば、もう少し早い段階で開発会社から納期の延期や開発範囲の縮小について相談があってしかるべきと思うが、今回はそれがなかった。なぜ、そのような相談がなかったのか、それは、日本で最初に開発するシステムであるがゆえに、開発会社に本システムの開発規模や難易度を正しく理解し、適切な判断や指示のできる人材がいなかったからだと思う。一方で、広域機関には、今までの経験上、理解・判断のできる人材がいたと思うが、それを口にすると、開発会社からみて仕様の変更となるために、うまく機能しなかったのだと思う。開発会社にそのような人材がいれば、もう少し事態は変わっていたのではないか。

1

＜評価委員会 委員＞
理事長のご指摘のとおり、延期の判断が難しい事情があったと思う。業務仕様が決まっていない段階で、並行して開発を進めざるを得なかったことで、開発会社としても、間に合うと思っていたことが、途中の仕様変更・追加で、先行きが見えなくなったものと思われる。
＜評価委員会 委員長＞
判断が可能なタイミングはあったと思う。開発会社が当初考えていた開発会社所有のソフトウェア資産の流用が、開発初期の段階で使えないことが分かった。それが分かった時に開発範囲の変更などの適切な対応を取らず、単に開発スタッフの増員で終わらせてしまったことが判断の間違いであった。
＜広域機関 理事＞
この度は、かなり踏み込んで要因分析・評価をして頂き感謝している。広域機関は、２年前に正式に発足したが、その前身（準備組合等）にまで遡り、事実経緯等を整理の上、このような形でしっかりまとめて頂いたことは、広域機関にとって貴重な資産になると思っている。今後、二度と同じようなことを起きないよう、再発防止策を図っていきたいが、報告書の内容について、いくつか質問させてほしい。
１年前にシステム開発遅延が顕在化し、その原因について自問自答した。報告書にあるマネジメントが不十分であったことについては反省し、その反省からこの１年間は、広域機関として、開発会社にスタッフも送りこんで、リスクマネジメントを実施した。まだまだマネジメント面でやれることはあるとは思っているが、一方で、これほどやっても、残念ながら、未だに工程が守られておらず、順調に来たとは言えない。広域機関の更なるマネジメントの強化も必要であるが、限界も感じている。そうなると、やはり人材の問題になってくると思う。当初は、要員不足が問題と考え、増員を図ったが、量ではなく、質の問題であった。そんな中で私が悩んでいるのは、どこまで発注者側が、開発会社の人材強化・育成に関与すべきかである。報告書の２３ページに、「開発会社の人材確保は広域機関の義務ではないが、開発会社に十分なスキル・経験を持つ人材が確保できない場合には、広域機関でその底上げを図る施策が必要となる」とあり、感覚としては同感であるが、実際にはどうすればよいのか。委員の皆様から、これまで様々なシステム開発事例をもとに、開発会社の人材の質の底上げについてぜひご助言いただきたい。
＜評価委員会 委員長＞
開発会社の開発工程に対する考え方が間違っていた。進捗が遅れているから、仕様書や設計書の文書化をやらずに、とにかくやれることをどんどん実施し、テスト時に発生した不具合を人海戦術で直していくやり方を採用した。一番やってはいけないやり方であって、後から修正項目がたくさん出てきて、文書化されていないから、何をどう修正すればいいのかわからなくなった。本来は、修正がある場合には、仕様書ベースできちんと直して、直したものがその他の開発に支障が生じないことを確認した上で、プログラミングに移らないといけない。広域機関は、ここで、もし大変であっても、「仕様書・設計書の文書化をきちんとやりなさい」と指示できていれば、開発会社は、間に合わない、できないと具体的な相談もできたと思う。それをやらずに「人海戦術で何とかやれます」との開発会社の説明を信じて、開発会社にきちんとした工程を踏ませることができなかった。たとえそのことで時間がかかっても、そこは譲れないと思う。そうした工程を踏ませた上で、どこを切るか等の相談をすればいい。ウォーターフォールモデルの基本であるが、絶対に手戻りが発生しないよう、各段階でレビューをして、手順を飛ばさないことが一番大事だ。今回のように、開発会社にノウハウを持った人がいない状況下では、一緒になって運用はこれこれしかじかと、常時現場で話しをしながら育てる策もあると判断する。以前に、鉄道制御の開発に何件か携わったが、開発会社に開発経験がなかったため、我々のエンジニアが一緒に行っ
2

て、常駐して開発会社ともの造りをする。もちろん、ソフトウェアは開発会社が作るが、どうあるべきか常に議論し、育てていくやり方をしたことがある。３年も経つと開発会社のスキルの向上が見られたが、最初はそのような策を打つ必要があるかと思う。それを建前論で、我々はこのような立場にあって、開発会社側はこうだと言うのではなく、システム成功のために、今我々が抱えている人材と開発会社の人材をどのように融合させて目的まで導くかを考えられるといい。
＜広域機関 理事＞
平成２８年４月の運用開始直前は、私自身も全面自由化のスタートに遅れがあってはならないとの思いから、工程優先が譲れないこともあり、「なんとか頑張ってくれ」と言ったこともあった。それで、開発会社も何とか頑張って遅れを取り戻そうとの思いになったかもしれない。ただ、運用開始後は、もう既に予定通りの運用は実質的に無理であったので、急がしても決していいことはないと考え、開発スケジュールに余裕を持たせ、手戻りを減らすため、「できないことは、はっきりできないと言ってほしい」と、開発会社に伝えたが、アウトプットは変わらなかった。そこが一番の疑問である。現在でも、広域機関のスタッフが工場に通い、コミュニケーションを密にしているが、それでもまだ仕様の齟齬が出ている。
＜広域機関 理事長＞
米国では、無理なことを頑張って挽回しようとはしないで、遅れは普通に出て、費用の追加でかかってくる。こういうことが、普通に起きるのであって、新しいシステムの開発にはそれが不可避なところがある。見極めが難しい。
＜評価委員会 委員長＞
米国と日本ではモノの作り方が違っていて、日本は職制（会社、下請け、孫請け）で流れていくことが多い。米国のプロジェクトマネジメントは職制ベースではなく、人ベースで、いろんなところから人を集めて、チームを編成し、タスクが終われば解散する。日本の場合は、プロジェクトは、会社ごとで参画することが多く、いったん仕事を依頼すると、進捗はわからず、相手の会社が大丈夫だと言えば信じるしかなく、判断する術がない。コミュニケーション不足を指摘しているが、中々表面化することなく、実際に、中身を見てみたら、発注者と開発会社で考えていることが全然違っていたことが、今回露呈した問題点であった。日本式が悪いわけではなく、それに合った見極め方、留意の仕方が必要であるということ。そこの対策の一つが、間接レビューを実施することだと思う。
＜広域機関 理事長＞
外部委託は、成功するか否か難しいところである。各電力会社が電力システム改革のために行っているシステム開発は広域機関システムとは異なるが、決して順調に進んでいるわけではない。
＜広域機関 理事＞
広域機関システムは、まったく新しいシステムであって、開発会社に経験や高い開発スキルがなく、広域機関にもわからないことが沢山あったために、こういった事態となった。広域機関が、要件定義書や設計書等を直接、間接にレビューするという提案は良い提案と認識しているが、これをやり続けることは大変な作業で、広域機関の人的リソースを相当に抱えなくてはならない。こういった取り組みを３年程度続ければ、開発会社のスキルも上がると聞いて少し安心するが、実際に、このような手法でシステム開発を行っている業界があるのか。発注者側と開発会社側の役割分担が進み、発注者側が開発会社のプロジェクト管理まで踏み込んでやるという手法は少なくなったと認識していたが。

3

＜評価委員会 委員長＞
各製造工程が正しいプロセスを踏んで実施されているかどうかを、第三者に判断してもらうことが重要である。安全性が要求され、社会的影響の大きいシステム開発では、第三者認証という形で、義務付けられているほどである。第三者認証機関が、依頼人の業務の内容をよく理解しているわけではなく、プロセスの良し悪しを判断してくれる。広域機関は、全ての直接レビューを実施せねばならないというわけではない。自動車の世界では、ISO26262 規格というものがあり、モノつくりの過程を重要なものとそうでないものに分類し、生産工程の標準化を進めている。
＜広域機関 理事＞
先ほども他の理事から言及があったが、現在のリスクマネジメント会議は、相当に細かく丁寧に、各製造工程をモニタリングし、広域機関のスタッフが開発会社の工場まで出かけて作業の進捗を管理しているのにも関わらず、うまくいっていない。ここまでやってもうまくいかないと、今後どういう取り組みをすればいいのか大いに不安である。
＜評価委員会 委員＞
今の話は、委員会から提言したことについては、広域機関もよくわかっていて、実行に移しているにもかかわらず、うまくいっていないということか。
＜広域機関 理事＞
委員会による問題点の指摘は、自分が立てた仮説を裏付けるものと考えている。ただし、そのとおりに実行できているわけではなく、更なるブラッシュアップが必要と認識している。ポイントとしては、ここが問題だと考え、問題解決を徹底的にやってきて、その結果が段々見えてきて、次にどういうアクションをすればよいのかと考えていたところである。
＜評価委員会 委員＞
最初に事の顛末を聞いて、開発会社の態度、行動には正直呆れた。開発会社は、もともとが、楽天的な組織で、何とかなるとのセンスでずっとやって来たのではないかと思った。信賞必罰体制を徹底して、双方がきっちりと責任をとるべきところは、とらせる必要がある。
＜評価委員会 委員長＞
開発会社は、開発会社なりに適切な工程管理に取り組もうとしている訳で、双方で役割分担して、一緒に工夫しながらやると効果があると考える。広域機関だけが一所懸命やって危機意識を持っても致し方ない。
＜広域機関 理事長＞
半年間にわたり、非常に細かく調査していただき、大変有意義なご提言を頂いたと認識している。今回のご提言を、どう生かしていくかは、これから我々が悩むところでもあるが、何とか、いい形にしていきたいと思っているので、これからもご助言いただきたい。
議題２：第８回及び第９回委員会の議事録確認について・事務局より第８回及び第９回委員会の議事録の説明を行った。
・原案のとおり承認された。
4

以上

5