公共的なシステム開発のあり方と特許庁システム問題

異論はたくさんあると思うし、答えは一つではないと思うので、私見です。

そんなにバグが無い状態をめざさなきゃいけなくて、それが実現できるんだというなら、ロジックをハードウェアにでも焼き込んでしまえばいい。ロジックをソフトウェアで書くのは、変更に対応するためだ。

ソフトウェア開発にとって最大の阻害要因は納期 - 狐の王国

でもね、目指さなきゃならんと思うんですよ、場合によっては。全システム金額計算とセキュリティーの塊である銀行の基幹系システムをやっている身としては、１００％バグのないシステムを作るのは無理だけど、１００％バグのないシステムを目指すのは義務だと思っている。結果として、バグによって起きる障害は少ないし、起きた結果として預金が消えてなくなって痕跡も残らない、ということもない。
それだけ厳しいことをやっている理由の一つには、不正を看過しない、という要素も含まれている。もっとも、昨今の銀行システム部門の実装技術力の無さやベンダー丸投げ風潮を見ると、不正を仕込む余地は昔よりある、と言いたくなるが。

できる、と、目指す、は違う。

特許庁のシステムにそれが必要だったかというと、そうではないだろうけれどもね。

もう一つ。ロジックをソフトウェアで書くのは、変更に対応するためだ。変更とはバグ修正のことではない。

だから「設計を先に終らせる」なんてことは通常あり得ないし、ウォーターフォール開発はそもそもが間違っているし、人月計算はコスト計算にしか使えないのである。

ソフトウェア開発にとって最大の阻害要因は納期 - 狐の王国

ウォーターフォール開発が全く後戻りも利かず、設計変更もできない手法である、と勘違いしている向きが結構あると思うんだけど、それは間違っている。設計変更に対する手戻り工数が大きい、というだけである。だけ、というのが時として重大なこともあるんだけど。大体、データ設計（DBの論理設計）が先に終わってない「業務」システムなんてコードが書けない。まあ今どき「プログラム仕様書」を完璧に書かないと先に進めない、なんてウォーターフォールがあったらやだけど。

こうしたことを考えていくと、いわゆる「納期」というものがソフトウェア開発の最大の阻害要因であることがわかる。もちろん締め切りなしにはスケジュールも決まらないだろうが、それはマイルストーン、この日までにここまで実装するといった目標であるべきだし、それを過ぎても開発が止まることはないのだ。

ソフトウェア開発にとって最大の阻害要因は納期 - 狐の王国

目標で飯が食えるかどうか。そこが大事だと思う。期間×投入人員がコストである以上、単に長くやるだけではオーバーヘッド工数がものすごいし、かと言って短期に人を詰め込んでも意味が無いわけで、それこそ適正な開発工数と期間を世界中で様々な手法を駆使して適正化しようと試みられている。もっとも、その指標を使って工数を積んだら「そりゃこんだけかければなんとかなるよな」という数字が出るのが常なんだけど。
なので、求めるべきは「納期なし」ではなく、適正なスケジュール。どういった形でシステムを作るか決まっていないのに納期が決まっているのはおかしい、というのであればわかる。でも大きな政府系案件は、はじめにRFIがあって、そこで提示された形にそって発注規模、納期を決めて入札にかけるわけです。そこには（ちょっとずるい話かもしれないけど）同種のシステムをやっていれば当然そのノウハウでその程度でできるよね、という暗黙の期待（そりゃRFIを求められたベンダーは「うちがやったら」このくらい、で考えるからね）が込められていて、それゆえに、新規に仕事を取りに行くのには結構なリスクが有るんですよ。

※これは仕事柄政府系案件をウォッチしていると案外まともな印象の案件が多いよ、というだけで、今まで不正がなかったとか独占がなかったとかいう話ではない。不正も不当な独占も今までたくさんあっただろう。

特許庁システムがうまく行かなかったのは、今まで出てきた情報からすると入札案件そのものに問題があるとは到底言えない。技術点が低く、予定価格を６割も下回る金額での入札をなぜ弾けなかったのか。あるいは、なぜ、そんな状態で東芝ソリューションという看板を背負った会社が入札することになったのか、というところにフォーカスすべき「事件」なのだと思っている。