読者です 読者をやめる 読者になる 読者になる

myatsumoto blog

マツモティウスです

特許庁の情報システムについて - 技術検証委員会の議事録

特許庁の情報システムについて -
http://myatsumoto.hatenablog.com/entry/2012/01/26/082554
で仕様については一通り調べ、内部フローの複雑さが障壁になったのではないか、という結論に至った。id:Dryad さんから技術検証委員会の議事録の存在を教えて頂いたので詳しい推移を調べている。

特許庁情報システムに関する技術検証委員会 -
http://www.jpo.go.jp/cgi/link.cgi?url=/shiryou/toushin/kenkyukai/jyouhou_iinkai.htm

技術検証委員会による審議会が全6回行われている。
まず、この審議会以前に設計について様々な問題が指摘されている。

特許庁情報システムに関する調査委員会報告書ご指摘に関する状況について -
http://www.jpo.go.jp/shiryou/toushin/kenkyukai/pdf/jyouhou_iinkai01_haifu/haifu1_siryou3-1.pdf

この資料によると

  • システム上のエラー処理のみならず、業務上のエラーについても設計されていない。このためシステム保守が困難。
  • 特許庁業務システムに知見のあるSEが見ても、設計書の内容理解に時間を要した。
  • 機能的に冗長な設計となっており開発規模が膨大となる。このため後工程でテストが完了しても、稼働後の保守が行えない。
  • ハードウェア等の設計を行う際に、業務量の日内変動(ピーク時)が考慮されていないため、過小なハードウェア調達となり、性能不足に陥る懸念がある

など基本的に設計的な問題点が指摘されておりこの時点で3000件ほどの残件があった。おそらく相当冗長な設計になっていたのだと思われる。

2011年9月8日に行われた第一回の審議会はこれら問題を踏まえて対応が検討されている。
第1回議事要旨 -
http://www.jpo.go.jp/shiryou/toushin/kenkyukai/pdf/jyouhou_iinkai/giji1.pdf

最初の方に残件の理由が書かれている。

東芝ソリューション(株)からのヒアリング>
残件の発生原因として、共通したものはあるか

通常、プログラミングでは「クローンの弊害」とかよく言われていて、クローンは作るべきではないのだが、このプロジェクトでは、設計段階でクローンを非常にたくさん作ってしまい、明らかにクローンの弊害が出ている。つまり、既に検証された部分をコピーペーストしてクローンを作るのではなくて、品質が検証される前の段階でクローンをつくってしまっているので、元の設計箇所に問題があると当然そのクローンの分だけ修正対象箇所が増えていく。

未完成のコードをコピペして使ってたことが残件の主な原因だったと言っている。
コードをコピペして使っていると、コピペ元に変更があるとコピペ先も修正せねばならず手間が掛かる上にコピペが増えていくと修正箇所が把握できなくなっていく。なので、コードを共通化して使うのは初歩的な手法だが、これを見るにTSOLは動く処理ならコピペすることを良しとしていたようだ。
これならコード量が膨らむのも納得できる。

TSOL社の共通化していくという提案自体はよかったと思う。だが、それを特許庁の設計の具体的な工程の中で、どのように実現し、どのスケジュールに沿ってやっていくのかというところが、肝心のTSOLから出てこなかったということで、これではこの共通化が目測どおりにできるだろうという見地には立てなかった。

とあり、TSOLからは膨大化した設計に対し「共通化する」対応策を提案されたが、現実的なスケジュールなどが提示されなかったようである。

最後の討議では

今日の各者の話を聞いていると、アクセンチュアは、もう思いの上では止まっていました、という感じなので、印象としてもうほとんど破綻しているのかなという感じがする。

TSOLすら、このプロジェクトを少なくとも今のまま進めていく可能性があるとはおっしゃらなかったし、アクセンチュアも手戻りすることを前提とした議論だったと認識している

と第一回の時点でかなり諦めに入っていることが分かる。

一週間後に行われた第二回では既に責任追及の会議になっている。
第2回議事要旨 -
http://www.jpo.go.jp/shiryou/toushin/kenkyukai/pdf/jyouhou_iinkai/giji2.pdf

担務の変更をTSOLが申し出てきたということは一体どういうことを意味するのかということについて、TSOLが十分に考えて言ってきたのか分からない。すなわち、最初の契約のところで請け負ったはずのことと違う方向へ行ってしまうわけであるが、TSOLは、それは大きな問題であるという認識がないのか。

担務の変更をする、しないとかも含めて、平成29年1月までにシステムができるかどうか分からないという状態自体が問題と思っている。外部の意見からは、設計書の品質が悪くて入れない、UA業者としては入れない、ということだが、基幹的なものも含めて平成29年1月にできそうかどうかは、まず明確にした上で、できそうでないということであればどういう対応ができるのかを検討したい。

平成29年(2017年)の1月でもシステムができるかどうか分からない、という状態だった。
本来の稼働予定時期は平成26年なので計画段階で3年延期されている。

要するに、ちゃんとしたものを早く作りたいわけだが、今までの経過からすると、TSOLに任せてできるのかといったら、TSOLはアクセンチュアが言ったことが渡りに船で、私はもうここから先はできませんとこういったわけで、それで29年1月というのは、根拠は何かと言えば、その中身はよく分からない。

第三回では今後の対応について検討されており、第四回では途中段階のシステムの利用可能性について検討されている。第五回、第六回の審議会は詳細が記されていない。

第四回で

現在の段階で一番バーを高くしているのは開発規模だと思う。アーキテクチャーの難しさと規模というのは相関があり、ある程度難しいアーキテクチャーでも、ある程度の規模であれば実現可能性は高いが、規模が一定程度を超えると、極めて簡素なアーキテクチャーでも難しい状況が出てくることは、ままあるので、その規模をどう考えるかだと思う。規模の壁をそのまま置いておいていいのかというのが一つの議論ではないか。できないことではないと思うが、それなりの体制、それなりの期間、それなりの費用が必要だと思う。

とTSOL側(発言者が書かれていないので推測)から発言されており、基幹系大規模開発の障壁が垣間見えたように感じた。

あまり技術的な部分を詳しく見ることは出来なかったが、前回の記事も含めてまとめると

  • 検索などのアルゴリズム面での仕様はそこまで難しくなかった
  • 複雑な内部利用ケースに対し、設計が膨大化したのが障壁だった
  • コードが凄い量になった上に残件が多かったのは処理をコピペしてた所為
  • このような体制で基幹系の超大規模開発をしてしまったことが原因

という感じだろうか。

技術的な原因をまとめたが、
なぜ大手は下請けに回すのか、とか、なぜ大手だけが公共事業の仕事を貰えるのか
など別な視点からの疑問は色々ある。根本的には業界の腐敗の構造が引き起こしているのだと思われるが、その構造自体もなぜ出来たのか、という点は大いに興味がある。こういう組織の腐敗を調べるのは非常にタメになるので、今後も機会があれば調べたい。