同時並行で作業をアサインしてもどっちも予定どおりに終わらないのだからアサインするのはいつも1つだけが良い理由

今、何度もチームメンバに伝えているのは、

「並行でタスクを抱えても同時に二つは処理できないんだから1つに集中して終えてしまいましょう。」

ということです。

当たり前ですね。だって、自分は一人しかいないんだから、今この瞬間に自分で処理できるのは一つだけなのですから。

集中してタスクに取り掛かる前に
今、貴方が仕掛中のタスクは着手前に何をアウトプットするか、タスクを受け持ったときにそのアウトプットイメージを具体的にイメージ出来たでしょうか。多分、不明瞭なところばかりで走りながら摺合せして……じゃないでしょうか。

コンセプト出しや概念設計をするならそれでもありだと思いますが、そうは言ってもそのタイミングだってWBSを切り出したときにはそのWBSでアウトプットするものを決めて、そのアウトプットが後続工程で必要なタイミングに渡せるようにアウトプットの中身を調整しながら作り上げていかなければなりません。一方、タスクが詳細設計や開発工程以降なら走りながら考え調整する余地は少ないものです。実現仕様に基づいて作るのですから。

集中してタスクを片付けるためにはインプットとアウトプットを押さえる
モノづくりの工程であればあるほど、より具体的に、より子細な情報が必要で、それは、作業を着手する前に必要なインプット情報です。同じようにアウトプットするものは、その出来具合が後続工程の要求するレベルで出来上がっていないといけないです。

担当するタスクに手を付ける前に、必要なインプット情報、モノづくりの工程を介してアウトプットする仕様を明らかにしてから着手することが必要です。

え？そんなこと出来ないって？それ、前の工程でやることやっていないだけでしょう？それを言ってはいけないって？そういうこともあるでしょうけれど、そんなことを放置しておいたら、その関連するタスク、いつまでたっても終わらないですよ。だって、決められないんでしょ。

でも、やっぱり前提を置いて作業をせざる得ないタスクも少なからずあるものです。できれば、その前提が変わることを考えれば回避したいですが、そうも言っていられないこともあるものです。その際は、やっぱり何が前提とか仮説とか明確にして、「この前提は仮説だから。」と言うことを明示的にしてタスクを集中して着手しましょう。のんびりやっていると、仕掛中に仮説がひっくり返ってしまうこともあるんですから。

集中してタスクを片付けるためには工数見積もりも理想日で見積もる
そのタスクは、インプットの情報とアウトプットの仕様を明示的に仕入れてから着手しないと、いつまでたってもインプットの情報を集めていたり、アウトプットの仕様を擦り合わせていたりすることになるので、着手する前に明示的に合意してからやりましょう、と書きましたがその上で作業に必要な日数を改めて見積もりましょう。だって、一番情報が揃っている状況で見積もった方が一番それなりに正しそうでしょう？それより情報が揃っていない状況下で見積もっても不確定要素があるのだから、それはそれなりでしかないんですよ。

一番それっぽく、つまり、他のタイミングよりは正確に見積もれるのだから、その見積もりは“理想日”で見積もりましょう。理想日とはそれに集中したら何時間又は日で終わるか、です。

理想日で見積もる＝集中して作業するです。注意しないといけないのは、その理想日をそのまま日程にしてはいけないです。丸2日＝16時間必要なら、今日明日にしてはいけないです。予定されている朝会とか1日で作業できる時間とかを考慮しなければいけません。

同じように、そのタスクの中のプロセスを明らかになっているか、合意されているかを確認しないといけません。レビューが必須なら、レビューの時間、その修正を反映する時間を織り込まなくてはいけません。その上で、理想日を見積もるのです。

1つだけタスクをアサインするメリット
1つだけしかアサインしないわけです。作業の見積もりも一番正確な情報でやるわけです。そして、段取りも明確なっているわけで。で、終わらないなんて言えないですよね。だから、結果的にタスクを終わらそうと集中するんです。それがタスクを担当するメンバにはタスクを終わらせたと達成感が得られるメリットで、プロジェクトマネージャには予定どおりにタスクが終わるというメリットがあるんです。

あと、集中して終わらそうとするので何か障害があれば、早めに相談してくれます。だって、終わらせたいんだもの。これも双方にとってメリットです。