作業完了の妥協はダメエンジニアを増殖させる

座席の都合、席に戻るときにメンバの横を通ることになるのだが、ときどきメンバに声を掛けて雑談をすることあるのです。大体、声をかけるときは、何かしら気になることがあって立ち寄っているわけです。

あるメンバの仕事の仕方というか、アプローチが気になっているんですね。もう、ずっと。何が気になっているかというと、仕事の終わらせ方です。

終わらせ方と言っても、定時になってスッと帰るとか、机の周りの片付けとかではありません。

作業の完了のさせ方、です。そうですねぇ、アジャイル開発風に表現すると

作業の完了と言っているけどDoneの定義に照らしても完了と言えるのか

とい感じですかね。

完了の定義

作業の完了とは何か。それを決めずに作業を始めてしまい、レビューを受けて何度もリジェクトされ、不貞腐れるケースを見たことがあります。

あー、作業の完了を理解しないでやっているからだよ、と思うわけです。別に作業の完了基準はアジャイル開発が広く普及してから広まった考え方ではありません。

ウォーターフォール型のシステム開発でも、工程毎の成果物の作業プロセスや品質管理の品質要求などでこれらを満たさないと当該工程をexitできない、とするやり方は昔からあるので。

形式が強くなるとexitさせることが目的となって何のための完了条件だかわからなくなっているケースもあるようですけどね。詳しくは知りませんなー。

話を戻して、結局は、何を満たせば作業を終わり、と宣言して良いか、その基準が完了の定義です。

それは手続きかもしれないし、定量的な測定結果かもしれないし、審議結果かもしれない。

どれも全部、基準なんですよ。基準。

基準を理解して作業をしていない、基準を設けずに作業を始めてしまうことは、その成果物を修正する必要がある場合に、作った本人はあとあと困るんですよ。

何が困るかと言うと、まず、完了と言える根拠がない。

この基準を満たしているから完了だ、と言えないわけです。

なぜか。

自分で決めたから。

でも、それは受け入れられません。チームで作業をしていればチームの作業の完了の定義があり、それを全員で守らなくてはメンバ毎にバラバラな作業品質の成果物ばかりになります。

それでプロジェクトは上手く行くかと言えば答えは決まっていますよね。

もちろん、自分の作業だから自分で決めるという人も出てくるだろうけれど、それは自分がスポンサになる作業だけ言えることです。

スポンサから対価をもらって作業をしている（内製でも同じですよ）のだから、スポンサの利益（＝契約があるなら契約を満たせばいい）になっていないと。

自分の基準で作業を完了だと言ってしまうメンバは、自分がそこで終わりにしたい何かしらの理由があり、それは大体、本人が本来ある基準に満たしていないことをわかって自己判断しているケースばかりです。

つまり、ウイークポイントはわかってやっているんですね。

だから、そこを突っ込むと不機嫌になるんですよ。痛いところを突く、というやつです。

シンプルです。ときどき書いていますが、作業プロセスを決めて着手する前にアウトプットイメージを作業をする人に説明させて、完了基準を合意してからやらせればいいです。

ただ、作業をやっていると本人は忘れているので、何度でも基準に満たない作業はリジェクトし続けてください。

プロジェクトの推進で影響が大きいようだったら、入れ替えとしたいところですがマネージャの立場だと、覚えるまでリジェクトをする他ないですね。