案件ふりかえりそのに
またも清水川大明神先生様に「それブログで」って言われたので、もうすこしまとめてみた。まだまだである。
お客さんとプログラマー
プログラマー(SE?)の仕事はお客さんが持ってるもやもやとしたアイデアを最終的に動くプログラムというカタチに変換してあげることだ。
しかしプログラムは思ったとおりには動かず、書いたとおりに動くものなので、まず仕様に落としてやらないといけない。
で、これが大変辛い。開発の苦労の半分ぐらいは、いわゆるクソ仕様と呼ばれるものから発生する。
だれが決める?
弊社だとこれを大体実装者と同じ人間がやるので、実装負荷と仕様策定の負荷が重なってたいへん辛い。
さらに他にメンバーが居ると厄介で、実装負荷を持ってもらう代わりに仕様を余す所なく伝えるという作業まで発生するのでもう泣きそうになる。
ここで伝え漏れ、認識の齟齬があるとコレジャナイロボを作るハメになり、さらに苦行が続く。
仕様変更はぶちょう窓口へ
で今回の案件の話に戻ると、そこの負荷をほぼすべてぶちょうが一人で持ってくれたので非常に楽ができた。
仕様をまとめて文書化し、お客さんと調整しながら、実装者の僕らにtracチケットのカタチにまで落として割り振り、お客さんに出す前の確認までやってくれたので、あとはめいめいが落ちているチケットをちぎっては投げちぎっては投げすることに専念するだけでよかった。
もちろんおかしい仕様はあったが、それを報告して
「これはこうでないと矛盾してるので、こんなんでどうすか」「りょうかい、仕様書直して先方に伝えます」
みたいなやりとりをするだけで済むので、実装者としては大変有り難かった。
お客さんのアイデアではなく、実装すべき仕様とだけ対話していればいいのでものすごく楽。
マルチプレイヤー or 分業化
うちは要件ヒアリングから運用保守まで一人でやるようなことが多いので、わりとヒーヒーいうことが多い。
今回は完全分業だったが、十二分にスピードと(納期の短さに対する)品質は確保できていたと思う。
少なくとも、3人でお客さんとやりとりし、3人であれこれ言いながら仕様を0から決めて実装した場合よりは良い結果になったはずだ。
一つの役割に徹する
役割分担をきっちり決めて、与えられた単一のロールに全力を注ぐというやりかたはとても効率的。
もっと言うなら、どのロールもやれる人達が集まって、お互い動きやすいように配慮しつつ、各人がより得意とするロールを受け持つというのが最も効率が出せる戦い方ではなかろうか。
できるなら、こんな働き方をずっと続けたいものだ。
6/50