Ad Network

あわせて読みたい

  • あわせて読みたい

« 今週の週刊 Life is Beautiful:1月8日号 | Main | CloudReaders アップデートのお知らせ »

特許庁のシステム開発が破綻した本当の理由

特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には(1)コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、(2)霞ヶ関から流れて来るお金にたかる IT ゼネコン、(3)そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。

破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。

そもそも破格だと言われた99億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれば、優秀なエンジニアを10人集めることが出来れば1〜2年程度で作れる(100人いたら逆に難しくなる)。一人当たりの人件費を(健康保険・福利厚生・オフィススペースなども含めて)2000万円として計算しても、2〜4億円で作れる。会社としての粗利益率を50%で計算しても10億円で落札しておつりが来る計算だ。コードの書けない上流の「自称エンジニア」が上位設計をして、実際のコーディングを下請けに任せるようなことをしているから人も育たないし、コストも高くつくのだ。

参考までに、週刊朝日の記事サンデー毎日の記事特許庁情報システムに関する調査委員会による「調査報告書」、へのリンクを張っておく(下の図はサンデー毎日の記事からの引用)。

Toshiba

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c4f9853ef017d3f8a96ad970c

Listed below are links to weblogs that reference 特許庁のシステム開発が破綻した本当の理由:

Comments

tkr

いつも拝読しております。大手電機メーカーでシステム開発をしている20代の者です。

SIerへの批判、官僚・ゼネコン・政治家が絡んだ腐敗した構造への批判、ごもっともであると感じています。そのうえでですが、この件を含む、以前からの中島さんのSIerの開発体制やあり方についての批判のうち一部に、最近は疑問を感じるようになりました。ポール・グレアムの「ハッカーと画家」に書かているような開発手法は理想的だと思いますし、ウォーターフォール型の開発には僕も嫌気がさしていますが、SIerの現状をふまえると、そういった開発手法にも一定の合理性があるようにも思えるのです。

>2〜4億円で作れる。会社としての粗利益率を50%で計算しても10億円で落札しておつりが来る計算だ。

ステップ数で計算することに意味があるとは僕も思っていませんが、仮にこのシステムが10万ステップだとしましょう。SIerが開発を行う場合、この10万ステップにひとつもバグがない状態を目指さざるを得ません。このシステムが仮に20年稼働するとして、20年間のうちにシステム障害が起こる可能性を0%にすることは不可能ですが、0.00…%の先にいくつゼロが続くのかが重要な意味をもちます。ですので「すべての起こりうる場合をテストする」ようなテストが必要となるわけですが、すごいハッカーが10人いても、そのようなテストを1年や2年の開発期間中に行うのは難しいと思います。

また、使用するミドルウェアのバグで障害が発生することも考えられます。例えばオラクルDBを使用し、オラクルDBのバグでシステムが落ちた場合、「DBのバグだから文句はオラクルに言え」では済みません。DBの品質に責任を持つためには、例えば、MySQLをテストして細かなバグにはパッチを当てるとか、DBも自社開発するとか、そういったコストも必要になるのではないでしょうか。DBに限らずWebサーバやハードウェアなど、あらゆる面でそういうコストが発生します。そういった観点をふまえると、テスト済みの古いJava実行環境を使用するのが現実的で、最新のプログラミング言語が使用できないため、さらなるコストがかかるわけですが、「絶対に落ちないように作る」ためにはそういったコストも必要なものだと思います。4億円で開発するというのは難しいのではないでしょうか。

>優秀なエンジニアを10人集めることが出来れば1〜2年程度で作れる(100人いたら逆に難しくなる)

あくまでも弊社の場合は、ということですが、製品の技術面に最終的な責任を持っている責任者の方々は、そこらのハッカーよりも遥かにスキルが高いように思えます(年齢で言うと、中島さんとほぼ同年代の方々です)。OSや言語処理系などは自作できるでしょうし、単に自作できる人よりも遥かに詳しいように思えます。その人たちが5人集まれば確かに1年もかからずに作ることができると思います。ですが、それでは若手が育たないので、小分けして若手にも仕事を割り振り、責任者が仕様書をレビューすることで質を担保しています。より優秀な学生を採用すれば、より少ない人数での開発が可能だとは思いますが、それにも限界があるように思えます。

なにかご意見などありましたら教えて下さい。

Ponta

tkr さんの言うほど優秀な技術者ならば、相当に高級を払う必要がありますよね。本文中では 1000万円ぐらいしか払わないつもりのようですが、それは無理では? その 5倍は必要でしょう。さらに、補佐をする人も必要でしょう。
 ざっと見て 10倍のコストならば、本文中の 10億円に対して 10倍の 100億円が妥当では? それでも、100億円できちんとしたものができるならば、安上がりですね。
 現実には、本質は、ITゼネコンの問題でしょう。

Ponta

 訂正: 高級 → 高給

m.m

tkrさん
>SIerが開発を行う場合、この10万ステップにひとつもバグがない状態を目指さざるを得ません。

すべての起こりうる場合をテスト出来ないのに、そういった目標を目指すことが誤り。
バグがあっても二〇年間、顕在しなければよいのだし。


>DBの品質に責任を持つためには、

テスト駆動開発手法ででテストしながら開発をしていきましょう。Webサーバーも同じようにテストすればよいし、ハードウェアはAmazonWebServiceなどの仮想環境を使いましょう。

そういった観点からすると使用するべきはテスト駆動開発に積極的に対応しているJavaEE6などの最新のフレームワーク。
最新の開発環境を使った開発プロジェクトなら、優秀なプログラマを集める困難も大きく減ります。
逆にEndOfLifeを過ぎたような古いJava実行環境に優秀なプログラマは近づかないでしょう。


>小分けして若手にも仕事を割り振り、責任者が仕様書をレビューすることで質を担保しています。

若手にはひとつのアプリを最初から最後まで作らせ、責任者はソースコードをレビューするべき。

バグが無いのを目指しながら、バグが存在するソースコードをレビューせずに仕様書をレビューするのは無意味でしょう。

それで育っているのはレビューの目を誤魔化す文章上のテクニックだけ上手くなったプログラマではない何かだと思われます。


Pontaさん
>その 5倍は必要でしょう。さらに、補佐をする人も必要でしょう。

最新のフレームワークの実装コストは大きく下がっていますから、そんなに優秀な人は必要ありません。
AWSなどの仮想環境とそのフレームワークを使いこなせれば充分ですから1年拘束1000万で充分です。

tkr

m.mさん

えっと、突っ込み所が多すぎて、どこから突っ込んでいいのか困ります。。

>そういった観点からすると使用するべきはテスト駆動開発に積極的に対応しているJavaEE6などの最新のフレームワーク。
>最新の開発環境を使った開発プロジェクトなら、優秀なプログラマを集める困難も大きく減ります。

優秀なプログラマが積極的にJavaを使う、という話は、ちょっと聞いたことがないですね。。
「最新のフレームワーク」の例としてJavaEE6を挙げるって(笑)

>テスト駆動開発手法ででテストしながら開発をしていきましょう。Webサーバーも同じようにテストすればよいし、ハードウェアはAmazonWebServiceなどの仮想環境を使いましょう。

えっと、AWSを使うとか言ってる時点でSIのことを全く分かってないですよね。。
官公庁のシステムですよ?「プライベート・クラウド」なんて言葉があること、存知ないのでしょうか。
また、そもそもの話ですが、AWS自体が落ちることはお考えになりませんでしたか?
結局、Amazonのデータセンタで稼働しているんですよ?

>テスト駆動開発手法ででテストしながら開発をしていきましょう。

TDD、BDDは従来よりも品質を高めるための手法ではありません。
アジャイル開発において品質を下げないための手法です。

>バグが無いのを目指しながら、バグが存在するソースコードをレビューせずに仕様書をレビューするのは無意味でしょう。
>それで育っているのはレビューの目を誤魔化す文章上のテクニックだけ上手くなったプログラマではない何かだと思われます。

仕様書は全体に影響するので総責任者が直接レビューし、コードレビューは現場のチーフが行なっています。
SIerの仕様書がどういうものか全くご存知ないようですね。。
プロトタイプを作ったり、部分的に実装して性能測定を行なったりしたうえで、
設計の肝となる部分の検討結果をまとめたものが仕様書です。
他社のことは分からないので、SIer全体の実情については僕には何とも言えませんが。

>バグがあっても二〇年間、顕在しなければよいのだし。

顕在化するバグとしないバグを本稼働の前に切り分けて、前者だけを全て潰す手法がある、とお考えなのでしょうか?
そんな手法があるんだったら教えて欲しいです。。

Ryuusei

tkrさんにだけ反応します。書かれてらっしゃる事は間違ってないと思います。
ちょっと長く生きてる立場で一言だけ聴いて欲しいのですが…。
元記事にミスリードされている気もしますがコストそのものの話ではなくて、
コストに見合ったシステムかどうか、費用対効果の話を先に考えてみて下さい。
というのがお願いです。
後は駄文。
本当にミッションクリティカルな制御系システムで有ればそもそもOracleは使えません。
が、人命に関わるとか、10msのディレイで10億吹っ飛ぶとかで無ければOracle使いますよね。
要は適材適所で費用対効果を見極めつつ使うべき物をえばいい話で、
テストや信頼性も同じじゃ無いかと。

日本は色々社会的に話題になるようなシステムトラブルを多々経験して、
監督官庁からの指導の下、必要以上の信頼性を求められてる気がします。
信頼性上げるのは飽和曲線なのである程度以降はなかなか信頼性上がらないんですよね。

ひとつ意地の悪い質問をしますが、tkrさんの所ではSI後、不備0でシステム運用されていますか?

m.m


>優秀なプログラマが積極的にJavaを使う、という話は、ちょっと聞いたことがないですね。

あなたが優秀なプログラマでないことは客観的な説明を行わずに「聞いたことがない」という主観を理由にすることからよく分かります。

>官公庁のシステムですよ?「プライベート・クラウド」なんて言葉があること、存知ないのでしょうか。

AWSは本番環境と全く同じ開発環境を作るのにも使えますし、各国政府機関もAWSを使用するようになっています。


>結局、Amazonのデータセンタで稼働しているんですよ?

AWSは「プライベート・クラウド」と名前を変えたデータセンターとは違うのですよ。
AWSは世界各地にリージョンを持っていますから、分散させておけばよいだけ。
その分散もブラウザから指示するだけです。

AWSについて勉強した方がよろしいかと。


>TDD、BDDは従来よりも品質を高めるための手法ではありません。

いいえ。品質を高める方法です。


>仕様書は全体に影響するので総責任者が直接レビューし、コードレビューは現場のチーフが行なっています。

レビューは品質を保証しません。
TDDやBDDは無数のテストケースにより一定の品質が客観的に保証されます。


>設計の肝となる部分の検討結果をまとめたものが仕様書です。

その仕様書の正しさを保証する手段は存在しません。
だから、コードの作製と品質確保を中心とするアジャイル開発が広まったのです。
WEBの新しい規格などで、仕様と共に参照実装が公開されるのは仕様の正しさを実証し保証できるのは実装されたコードだけだからです。

仕様書の作製も、そのレビューも無駄なコストでしかありません。
無駄なコストを積み上げて、大規模開発には人手と金がかかると主張するのは詐欺そのものです。


>そんな手法があるんだったら教えて欲しいです。

それがテスト駆動開発手法です。

Kazuno_QMA

そもそもAWSは東京リージョンであっても米国法の適用範囲なので、官公庁や医療のシステムだと各種ガイドラインに準拠できなくなりますね。はなから使わせてもらえないかと。

とはいえ、もっと効率よくシステムの構築は行えることはSIerの中にいても感じるので、どこかで一つでも実績が生まれれば一気に変わっていく気はします。
結局は前例主義なだけなので。

m.m

>そもそもAWSは東京リージョンであっても米国法の適用範囲なので、官公庁や医療のシステムだと各種ガイドラインに準拠できなくなりますね。はなから使わせてもらえないかと。

AWSと交渉して日本の法律の適用範囲にしてもらうとよいですよ。

日本の法律の適用範囲に置いて起きたデータやシステムだけを自社内なり官公庁のデータセンターに置いて、その他の汎用的なだけをAWSから調達してもいいし。

Jhnsmth235

JavaEE6とかwww
岐阜のド田舎じゃJavaが最新なのかよw

Macchaka

本稿とはずれていきますが、TDDの品質については違うかなと思いました。

深夜のテストTL
ttp://togetter.com/li/5878

本稿に関しては、官公庁の仕事をやりたがる「優秀なエンジニア10人」とやらがいて、**現場が尊重されれば**、確かにできるんでしょうね。

m.m

Jhnsmth235さん の知識が古いままなだけです。
JavaEE6は最新のフレームワーク。2013年春にはそれをバージョンアップしたJavaEE7が公開されます。
Javaも2013年にはラムダ構文などを取り込んだJava8が2013年夏に公開されます。
どちらもearlyバージョンを試すことができますので、どうぞ。

Macchaka さん
>TDDの品質

TDDのテストケースで定義された範囲での品質を、テストケースの実行により保証できるのが大きい利点だと思っています。

Post a comment

This weblog only allows comments from registered users. To comment, please Sign In.