エンジニアもプロジェクトマネージャもタスクを終わらせられないのはタスクでマスターベーションしているからだよ

「進捗どうですか？」
「ダメです！！」

ダメですって「！！」を2つもつけるほど元気ならいいんですが。いや、良くないか。去年も今年もいくつもプロジェクトに何かと関わっていると進捗が終わらないタスクをあちらこちらで見かけます。で、いいのか？と言えばよくないです。はい。じゃなんででで？なんですかねって聞かれますよね。

タスクが何時までも終わらないのはエンジニアが終わらせないからだし、プロジェクトマネージャが終わらせさせないからに決まっているじゃないですか。

まぁ、そういうことですよね。正直いいんですよ、ワタシのプロジェクトでなければ。終わらないタスクを放置していたり、見過ごしていたり、将又、無視していたりしていてもワタシは痛くも痒くもないのですから。まぁ、それでも縁あってというか仕事で関わるので内心「(しょうがねぇなぁ。)」なんて思わないこともないですがここ最近はワタシが先鋒を切ってダメ出しをしなくても周りが艦砲射撃をするようになったので、後ろからゆっくりと、

「これはdue dateを過ぎているようだけれど、後続工程に影響しないのかな。」

なんて紳士を気取れる配役になってきたので割と穏やかです。そんなこんなでいくつもプロジェクトにかかわるエンジニアさんやプロジェクトマネージャさんたちの終わらないタスクに対するふるまいを見ていると「そんな対応していては終わらんよなぁ。」と気づきをくれるのでそのパターンをいくつか。

エンジニアがタスクを終われないのはエンジニアが終わらそうとしないから
エンジニアがタスクを終わらせられないのは、端的に言えば「終わらそうとしない」からです。これしかない。プロジェクトでは様々な事象で見えてくるけれど、本質の、真因はコレです。そして、事象として見えるパターンは2つに分類することができます。

気が済むまで作ってる
タスクを頼まれたとき、イメージアップもそこそこに作り始めてしまうんです。1つ目の間違いは、タスクは目的があってそれを満たせたら完了なのですよ。いいですか、エンジニアさんの自己満足で終わるものではありません。タスクを終わっていいのはそのタスクのコレが出来たら終わっていいよ、というcriteriaなのですよ。

criteria前にいくら満足したりこれでいいやと思っても終わりにはできないですよね。だって、受けれてもらえないもの。また、criteriaを超えて続けて作り込みしてもそれじゃオーバースペックか蛇足にしかならないですよね。端的に言えば、余計なもの、使われないごみを生産しているようなものです。

終わりのイメージアップもしないで作ってから仕様を聞きに来るまず手を付けちゃう。何と言うか脊髄反射？パブロフの犬？そんな感じです。目の前にタスクを置くだけで「パクっ！」て食べちゃう。それはそれでタスクをお願いする方は楽なんですよ。だって、依頼時にタスクの仕様を詰めなくていいんですから。そして、実体が出来てから「あーだこーだ。」とか「それちょっと違うんだよねぇ。」と言えばいいんですから。

このパターンどこかで見たり経験したことがありませんかね？そう、要件を決めずにつくらせてダメだしされるプロジェクトそのものですよね。そのパターンだとスケジュールもコストもオーバーランするしか想像できないですよね？

ね。そういうことなんですよ。タスクの仕様を確認しないで手を付けるということは。もし、エンジニアが「効率的にやりたい！」と微塵でも思っているならタスクの仕様を決めてから手を付けるように仕事のやり方を変えた方がいいです。

じゃあ、プロジェクトマネージャは？

タスクのcriteriaを決めない
何ができればそのタスクが終わりにしていいのか決めていないでタスクをアサインしちゃうプロジェクトマネージャが多いこと多いこと。

あのですねぇ、ウォーターフォールでやっているなら作るモノ、deliverableを決めて、それを構成するための部品を作る作業に展開したものがWBSなんですからね。いいですか。それなのに、ウォーターフォールを採用しているのにWBS、タスクのアウトプットの仕様を決めないでエンジニアに仕事をアサインするということは、仕様決めないで丸投げしているだけなんですよ。それ、顧客にされたら文句言うでしょ？なんで、プロジェクトマネージャはエンジニアに同じことしてるんですかね？まったくもってわかりません。

完了予定日で終わらないことを放置する
エンジニアのタレント性により、いつもまでもタスクをホールドする人がいます。これは一定量の割合でプロジェクトチームに存在するので存在すること自体は理解するしか方法がないです。

が、しかし、それを理解するにしても許容する、受けれいるわけにはいかないのです。だから、そうしたタレント性を持つエンジニアなのかどうかチームの立ち上げ時の早いうちにタレント性を識別する必要があります。その上で、人それぞれの対応をすることがポイントなのです。

で、どうするかと言えば、期限を切って、終わらさせるのです。そのためにはタスクのアサイン時に仕様を決めて、共通の理解を得ることが1つ目です。そして、期日までどこまでできているかトレースするのです。その上で、期日にはそこまででいいかどうかcriteriaで判断するのです。そうしてエンジニアのタレント性を見極めてそのエンジニアに渡すタスクのサイズを調整するんです。みんなと同じサイズのタスクで何回かアサインしても期日に終わらないのであればタスクのサイズを半分にして期間も半分にしてアサインするなど、兎に角、期日に終わらせる成功体験をさせることです。

それは、エンジニアの判断でスケジュールを伸ばさせない、と言うことです。それは、意思を持って終わらさせる、と言うことです。