Life is beautiful

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

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

＞２〜４億円で作れる。会社としての粗利益率を５０％で計算しても１０億円で落札しておつりが来る計算だ。

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

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

＞優秀なエンジニアを１０人集めることが出来れば１〜２年程度で作れる（１００人いたら逆に難しくなる）

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

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

　訂正：　高級　→　高給

m.mさん

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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