みんながハッピーになるために
PMに、将来について相談した。
会社がこんな調子だからね；
で、案の定、話が脱線しまくった。
その中で、いまのウチの開発状況は誰もハッピーじゃないよねって話になった。
PM「いまの関係者のうち、誰かが飛び抜けて儲けてるとか、そういう話のほうがまだマシ」
開発がうまくいかないばっかりに、元請のウチが不幸だし、開発してる外注も不幸だし、開発途中で外注に連れてこられた協力企業も不幸だし、なにより仕事を出したクライアントまでも不幸。
特にクライアントは、開発費前払いしてるのにシステムはいつまでたっても出来上がらないし、大手企業なので顧客や株主への説明とかプレス打ったりしなきゃなんなくて、かなり不幸だと思う。
これだから受託開発は嫌なんだ、とPMがこぼした。
PM「でもね、こないだウチがやったこの案件は、誰もがハッピーになったよ」
例のLLL frameworkを使ったwebアプリなんだけれども、受託開発な割に誰も不幸にならなかったという。
クライアントにもPMの会社にもプラスになり、みんなハッピーになれたそうな。
どうしてそうなったんだろう。
PM「バグ１個も出してないもん」
PMの持論だと、一番頑張らなければならないのは開発担当、主にプログラマなんだそうな。
営業とか、要件つめたりなどの人対人の場面では、相手がある以上、100％の力を出し切って動くのは難しいけれども、開発担当は対人ではなく対コンピュータの仕事なので対人フェーズにありがちな煩わしい部分はなく、それこそ自分の持っている力を100％出し切ることができるとのこと。
開発担当が頑張ってよりよい設計やよりバグの少ないプログラミングなどを心がけることで、絵に描いたようなデスマーチはある程度まで回避できるという話。
顧客とのトラブルや要件定義が不十分など開発着手以前の段階がぐだぐだになっていた場合でも、渡された仕様書に沿ったバグが少ないものを仕上げていれば開発者側は「仕様どおりに作ったよ」と言い切れるからそこまで不幸にはならないそうな。まぁ、要件定義したヤツ＆仕様書書いたヤツ出てこいよ、だわな……。
これが、いくら仕様がしっかりしてても設計ダメダメとか出来上がったブツがバグだらけという話になると、話が違ってくる。
えーと、つまりこうだ、客が「なんか甘くておいしそうもの作ってよ。のど渇くから、適当な飲み物もあるといいな」って言った（要件定義がｇｄｇｄ）けどあまりにもイミフなんで客が所望していると思われるケーキセットの絵（仕様書）を描いて見せたら「そんな感じかな？」ってそれっぽい返事がきた（客は仕様書にハンコをくれた）から、パティシエ（開発者）は絵とそっくりのメニュー（仕様に沿った納品物）を作って出した結果、客から「……なんか違くね？」って言われた（要望通りになってないとごねだす）場合はそもそも最初の注文内容がアレだよね？！って話になるじゃんね。
絵を見てそれとなくOK出したのは客のほうだし、パティシエは絵のとおりにセットを完成させたんだから、ってことで客を上手く説得（ここが営業のウデの見せ所だよね！）できればとりあえずできた分だけ代金もらったり（いったん請求できるようにする）や作り直し（プロジェクト仕切り直し……もちろんタダではやらないよｗ）って方向に持っていったりもできるかもしれない。
相手がよっぽど頭がイッた客でない限り、少なくとも「完全に店側が悪い」って話にはなりづらいと思うのね。
けど、客がちゃんと「イチゴショートケーキセットをください。ドリンクはホットのミルクティーで」と言って注文も通ってる（要件定義～仕様書まで OK）のに、できたケーキセットは散々……デコレーションがヨレヨレ（見た目がショボい）だったりスポンジがしぼんでる（機能がイマイチ）とかならまだしも肝心なイチゴが載ってない（仕様を満たしていない）とか、ドリンクがアイスコーヒーになってる（仕様と違ってる）とか、果てはケーキそのものが出来上がりません（開発が間に合わず一部機能が未実装）とかいう話になると、客が「なにやってんだ！」と怒り出すのは至極当然な話、みたいな。
システム開発ってのはさまざまな要因が重なって客の要望どおりのものが完成しないことが多々あるけれど、その中でも一番不幸なのが「開発者の技術不足」によるところのもの……つまり不具合なんだなって、ホント思う。
昨日も稼働中のシステムに不具合発生で緊急出動した身としては、こういうことが１件でも減らせればいいなと思う次第orz