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

えっらそうに大規模開発を語るような立場じゃないんだけど、何かと話題のこのへんの記事を読んでいろいろと日ごろ思うところがふつふつとわいてきたので……。

特許庁システムのことはそれなりに話題で、日本についてから何度も話にあがってきている。まあ不祥事だのなんだのって話もあるがそれはおいとくとしても、設計段階で60人体制ってだけでも多すぎるのに、増員で1300人体制とか……。設計を穴掘りかなにかと勘違いしてるとしか思えない対策でそりゃまあ破綻するよなあと。

それからね、中嶋さんの記事のコメント欄に書き込まれてた、よく言われる大規模開発でのこのへんの話。

SIerが開発を行う場合、この10万ステップにひとつもバグがない状態を目指さざるを得ません。
Life is beautiful: 特許庁のシステム開発が破綻した本当の理由--コメント欄より--

この時点でソフトウェア開発としては大間違い、と断言しちゃおうかねここは。

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

なぜ変更があるのか。それはソフトウェアには完成が無いからである。ソフトウェアは作ったら育てるもので、ある程度育てたら今度は新しく生み直さなければならない。そういう性質のものだからである。

つまるところ「完璧な状態にして納品」とかいうのはソフトウェアにはあり得ない。それは不備があるという話でもバグは無くならないという話でもなく、そもそもの性質の話なのだ。

なぜソフトウェアに完成が無いのか。それは人間が思うほど賢くないからである。

目の前に無いものを想像しながら、完璧な状態など作れるわけが無い。それほど人間は賢くない。ソフトウェアは図面すらないほど実体が無いぶん、実際に動作するものを見て判断せざるを得なくなるのだ。「これは違うんじゃないか?」と思っても使ってみればそれが正解だったりもする。もちろんその逆もある。やってみたら無理筋でした、とかね。

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

ゆえにソフトウェア開発は小さく生んで大きく育てる。まずは動くものを作ってから。いわゆるアジャイル開発と呼ばれる手法で作ることになる。

もちろんこうしたことが実現できないのは発注側にも問題がある。そもそも発注する側が完璧な要求仕様を出せるわけがなく、それは規模が大きくなればなるほど無謀という言葉を超えて行く。下手をすれば実装側が要求仕様を推測して実装するはめになったりする。そりゃあどんな天才プログラマーだって破綻する。

本当にちゃんとしたシステムが欲しいなら、組織内にシステム部門をおいて内製するしかない。組織のことは組織にしかわからないし、要求される内容は刻々と変わるのである。常々改変を繰り返し、ときおり刷新する。そうしたサイクルが求められるのだ。そうでなければ外部のパッケージを買ってきて業務をそれに合わせ込んだほうがいい。

であるから、情報システム開発は公共事業には向かないのだ。やるのであれば、オープンソース開発にしてパッチや機能追加ごとに賞金を出すような仕組みにでもしたほうがいいのではないか。たいした乗数効果は見込めないかもしれないが。

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

こうしたソフトウェアの特性を理解して発注できるクライアントであって欲しい。政府機関、官公庁に一市民としてそれを求めるのは、そう間違ってる話ではないと思うのだが。