開発プロセス談義メモ
http://d.hatena.ne.jp/m_pixy/20050614#1118721506
でもだからといって、「開発プロセスの標準化」ということを簡単にあきらめてしまっていいのか？と思っています。
別に諦めているわけではなく，良いものがあれば採用します．しかし現時点で存在しないし，近い将来においても実現する可能性が全くない．よくてせいぜい実験段階で，少なくとも現場レベルで見れば実用性は0です．
高校までなら問題にはほぼ必ず答がありました．しかし世の中の問題には，答が存在しない問題*1や，答があるはずなのだが現実的な時間で解決するのが不可能な問題*2，答があるかないか現時点では不明な問題*3などがあります．時として「答がないことを証明すること」が極めて重要な場合もあります．*4開発プロセスに関しても，実現不可能であるという証明こそ無いものの，答があるという保証さえもありません．
http://d.hatena.ne.jp/taichitaichi/20050614#1118747337
ある一部分が、「チャレンジングで、ヒューリスティックな」事はよくあるよ。つまり２：８の法則って訳。それを、何を勘違いしたか、２割の難しい部分だけを見て、開発プロセスはダメだって言ってないかい？と。っつうかさ、２割の難しい部分に捕らわれて、余計な所で頑張ってるんじゃねぇの？と思う訳ですよ。
8割の簡単な部分くらいなら，ご大層な「開発プロセス」などなくてもやっていけるんですよ．(銀の弾丸的な)「開発プロセス」が本当に欲しいのは，その「チャレンジングでヒューリスティックな残り2割」の部分を，効率よく，それこそ誰にでも簡単に実現できることだったりする．しかも80:20ルールからすると，この2割こそが工数の8割を占める問題の本質部分になる．
「工数の2割を占める8割の簡単な部分」を簡単にできるのは当たり前だし，その効果も限られている．「工数の8割を占める残り2割の難しい部分」では開発プロセスでは役に立たない．そして「開発プロセス」に求められているのは，この「工数の8割を占める残り2割の難しい部分」を簡単に効率良く誰にでも開発可能にすることだけなのだな．
そしてその2割の部分に悩んでいる人に対して，
只、そんな現場を知らずに、まるで全能神であるかのように舞い降りるコンサルなんて、僕は信用しないよ。「御社に足りないのは、開発プロセスです。開発プロセスが、ROIを劇的に上げ、うんちゃらかんちゃら…」開発プロセスの部分は、時と場合によって、ツールだったり新しいテクノロジだったりするんだけどさ。そういう時、僕が考えるのは、悪いのは開発プロセスじゃなくて、そういう事言ってる連中じゃないかな。と。*3
という悪魔の囁きがある．これには同意．
そして、そんな連中が寄って来やすい状況を作ってしまった自分達じゃないかな…と。
さてどうだろう．どれだけ生産性を上げ，どれだけ品質が高められたとしても，経営者がそういう悪魔の囁きに耳を貸せば全ては終わりな気がする．
何しろ成功している人ほど残り2割を負担する率が高く，だからこそその仕事は非定型的で見た目には何をやっているかわからない，「属人的」で「経験」や「直感」に頼る開発をしているのだから．
ソフトウエア開発は「設計フェーズ」だからそれは当然なのだが，「製造フェーズ」だと思っている経営者(や時として他産業の生産フェーズの品質管理担当者)にとっては，それは非効率的で前時代的な，「非科学的」な開発体制に思えるだろう．そして悪魔との契約書にサインする．
そう言えばこんな本もあった．
http://java.ameblo.jp/entry-f3a424f53a5b44e1b64bc5f700b3e665.html
開発プロセスで、品質が向上すると言うけれど、プロセスは、品質を一定させる為のモノ。
コレも疑問．それこそコンサルタントが「開発プロセスは品質が一定することが唯一のメリットです．」とは言わんでしょう．その手の解説でも「品質を一定にする」を売りにしていることはまずない．
それに実際には開発プロセスを入れると生産性が低下することが多い．品質に関しても一定に押さえられるかもしれないが，悪い部分を底上げするのではなく良いものを切り捨てることで実現される．一定品質，且つ最低品質を保証してくれる開発手法に何の意味があろう．
ソフトウェアが、常に全く違うモノを作っているってのも、違うと思うナ。他と全く同じモノを作ってる部分だってあるんじゃないかねぇ。
一般に技術力が低い人ほど，同じものを作り直す比率が高くなる．*5あとはコスト面とのトレードオフ．しかし基本的に全く同じと分かっているものを作り直すことは通常はありえない．
一見ほとんど同じに見えるが細部が少しずつ微妙に全部異なるために，カスタマイズするよりは作り直した方が早いということならばありうる．だがこの場合は開発プロセスを標準化するよりは，顧客要求を標準化した方が絶対に効率がいいし，品質も高くなる．
*1:「ケーニヒスベルクの橋」がそうか．ケーニヒスベルクの橋は比較的単純だから既に答が分かっている．
*2:NP完全とかNP困難がそれですね．地震予知や精度の高い天気予報なども同様．
*3:既に証明されたが，4色問題やフェルマーの最終定理が長い間そうだったはず．
*4:不確定性原理などは「答がない」パターンだな．暗号についても（少なくとも既知の解読技術を使って）現実的な時間内に解読できないことが証明できなければならない．
*5:ちなみに一般論として，いわゆるスクリプト言語には，最初作るときは早いが作り直す比率が高くなるものが多い(全部ではない．)のに対し，Javaのような言語ではスクリプト言語に比べて作り直しの比率を下げる効果がある．ただしこれもそういう設計/コーディングができればの話なので，素人が書くとそのメリットは完全に台無しになる．UMLモデリングを使えば，スクリプト言語による使い捨てコーディングよりも輪をかけて酷くなる．これはほとんど技術の問題で，開発プロセスとやらでは改善できない．
