システム開発というもの

システム開発の仕事に就いて20年弱。
大規模とされるプロジェクトにもいくつか関わってきた。
その多くは会員管理、課金管理といったバックエンドシステムのリニューアルだった。


すんなり進むことはほとんどない、というか全くない。
いくつか要因があるけど、そのひとつが必要なだけ、十分なだけ、要件定義ができないことだと思う。
そのシステムで何をどう実現したいのか、要件を定義する。
おおまかなところは誰でもできる。難しくはない。
しかしちょっと突っ込んだ特殊処理や例外処理みたいなものはなかなか網羅できない。
現行システムを構築したときの担当がもはや誰もいないとか、ドキュメントも残っていないとか。
要件定義のフェーズが終わって、設計や開発、テストと工程が進んでから
あれが漏れていた、これが検討できていなかったとなり、
顧客と仕様変更だ(お金がもらえる)、仕様バグだ(お金がもらえない)ともめることになる。
そういうのをずっと見てきた。


今参画しているプロジェクトもそう。
「これまで聞いてなかった話」がいくらでも出てくる。
開発する側からすれば「なんで言ってくれなかったんだ」だし、
顧客の側からすれば「なんで聞いてくれなかったんだ」となる。
(もちろんそのノウハウは書籍化されて手軽に学べるというものではない)
優先順位の高いよく使う機能がないがしろにされる一方で
一年に一度使われるかどうかの機能が突然「発見」されて、
なんで設計されていないんだと右往左往する。日々そんなことの繰り返し。
結局のところ21世紀もその5分の1が過ぎつつある今も
要件定義をロジカルに網羅性高く進めることはできず、
それまでの経験を元に場当たり的に行ったヒアリングが元になっているのである。
別の視点から言えば、早い話、
開発ベンダーがその業界のその業務に詳しい、ということはないし、
まれに詳しいとしてもその会社独自の業務に詳しいということはない。
そこに追いつくだけで往々にして要件定義は終わってしまう。


見つかるたびに、さあ、どうしようとなる。
追加に次ぐ追加で、やるとなっても当初想定よりも作業量が増えてスケジュールがきつくなる。
やらないというとき、現場では「ほんとはやった方がいいシステムになるのに」というものもあるだろう。
やるけどその分他の開発を落とすとなってその調整に疲弊するというのが一番よくある話だ。
どう転んでも、上位のプロマネ層から末端のプログラマー層までモチベーションを維持するのが大変で。
今構築しているシステムの全体像も見えにくくなっている。
いったい何人が把握しているだろう?
今のプロジェクトでもノベではなく実数として100人以上の開発体制になっているが、
自分のタスクの意味や目的が分かっていて、
本当に役に立つことをしている人はパレートの法則の通り20%ぐらいだろう。


暴論、と分かってて言う。
いっそのこと「システムを一切つくらない」というのも手だと思う。
WEBサイト構築といった人目に触れるものではなく、あくまでバックエンドという前提で。
紙と電卓とボールペンと電話でしばらく業務をこなす。
その100人でひたすら人海戦術
おのずとリーダーシップを取る人が現れて、業務をなんとかギリギリ回していく。
これを数週間続けると、「本当に必要な機能」が何かがわかってくる。
一年に一回の例外処理なんてなくてもいい。
その見極めがついた時点で、手作業で行った業務を元に機能を作っていく。
どんなデータが必要なのか。誰に何をいつ、伝えるのか。何をダブルチェックするのか。
何がリアルタイムに処理する必要がって、何が通常業務終了後、夜間まとめて集計でもいいのか。


その気になればできると思うんですよ。
今から10数年前、とある業界の大手のシステムを再構築したとき、
いつまでたっても完成しない。
もういい、となってサービスインして、その後何が起こったかというと、
空いている要員は顧客のオフィスに徹夜で詰めて
様々な計算を自分で行ってそれを隣の人が検算してレポートを作っての繰り返し。
ブラックホールのように人を飲み込んでいった。
それが2〜3ヶ月続いただろうか。
(なぜそうなったのかの理由は別のところにあるが)


先日後輩と話していたら「YAGNIの法則」というのがあるという。
http://qiita.com/sesame525/items/fb2cfb23d0d7ef593014
など。
「You Aren't Going to Need it.」の略で、
結局それは必要にならないだろう、と。
今必要な機能のみを開発するべきであって、
将来的に必要「かも」みたいな機能は今開発してもしょうがない。
そのときにはあれこれ条件が変わっていて役に立たないかもしれない。
全くその通りだと思う。


システムに詳しい人ほど、異常系の異常系ばかり考えてそれが実現できるかどうかの検討に時間を割く。
それができるエンジニアほど、それが実現できたシステムほど素晴らしいとされる。
そんな時期があった。
3年に1度の特殊な申し込みであってもきちんと自動処理できて、
終わったときには担当者にメール通知もされますよと。
それを自動化するためのコストと開発するコストは見合ってますか? 今はそんなふうに評価される。
そういう特殊な申し込みを拾う仕組みだけ用意してあとは手作業でよくはないか?
そもそも以前に、なんでそんな3年に1度の特殊な申込の受け口を残しているのか、
まずはその見直しをするべきではないか?


そうは分かっていても、いざその場に立つと視界が狭くなるのが人間というものであって。
今もまたそんな検討が繰り返され、やればやるほどいろんなものを見落として取りこぼし、
あとからこんなものがあったと発見され、問題視される。
システムをつくるのも使うのも人間、というのは永遠に変わらない。