こんにちは
システムチーム プログラマー / マネージャー のAです。
特例的に書いています。
今回は
制作者にとって大事な話をします。
強く伝えたいので、極端な言い回しや展開があります。
結論から話すと
週間の予定を達成するには…
１. 残作業を洗い出し、優先度を決めて対応 を繰り返す。
２. 残作業の洗い出しは、極限まで細かく。
３. 他人が関わる作業は、優先度を高く設定する。
の３つが大事だという話になります。
残作業を洗い出し、優先度を決めて対応 を繰り返す。
個人的に、タスクを遂行する行為は
・残作業を洗い出す
・優先度を決め、対応していく
の 繰り返し だと思っています。
対応に失敗したとしても、
また、残作業を洗い出して、優先度を決めて対応する。
とにかく、この２つを繰り返す。
残作業の洗い出し、優先度決め、は 全員やってると思うんですが
感覚的にやってしまっていたり、
繰り返し実施してないことが問題と見ています。
もう１度書きますが
残作業を洗い出し、優先度を決めて対応 を繰り返す。
残作業が時間内に収まる限り、１００％は達成出来ます。
その前提で、ノウハウを聞いてください。
残作業の洗い出しは、極限まで細かく。
全員、「残作業」としているものが粗い傾向にあります。
その粗さが、未達の大きな一因になっています。
例えばよく見るのが
「QC」のような残作業。これでは全然ダメです。粗すぎる。
良い例と悪い例を図解したので、必ず見てください。
細かさの違いがよく分かると思います。
感覚的に、「残作業多いな」と感じると思います。それで正解です。
週の初めに「大丈夫です」と言ったのに大丈夫じゃなかった、、というのは
残作業量を少なく誤認しているのが一因です。
本人的には
ホントに大丈夫だと思ってしまっていると思います。
残作業量を少なく洗い出してしまい、危機的な状況を察知できていない。
あと、まとめて、整理して書くのもダメです。
よくあるのがこんな悪例。
残作業をタスクごとに書き出すと、効果が半減します。
１つの枝の中に、全てのタスクの残作業を含める事が大事。
タスクの枝の中で優先度を書いてしまうと、
タスク間での残作業の優先度を比較できなくなる。
「◯◯タスクのQC依頼」と「■■タスクのテスト依頼」のどちらが優先なの？という感じ。
だから、
QC依頼だけで完了するタスクを放置して
他のタスクの実装に集中していた、、、のようなあり得ない進捗が発生します。
また、
うちのタスクを進める上では、
「クォリティチェック」「相談」や「報告」を
残作業として扱うことも重要です。
「作業」という言葉から「実装」を連想してはダメです。
実際には、承認依頼送信、相談、 QC、、これらすべて作業。
次に、優先度の決め方に関するノウハウです。
他人が関わる作業は、優先度を高くする。
全員の傾向としてありますが、
他人が関わる作業の優先度を、低く設定しすぎです。
他人が関わる作業、とは
お客さまへのご連絡、代表のクォリティチェック依頼、他チームへのヒアリング、、
等になります。
こちらも図解しました。
「実装」や「仕様作成」は、基本的に1人で行うもの ≒ いつでもできるもの。
だから、優先度が低くなります。これがポイントです。
他人には、自分では予想できない不確定要素があります。
だからこそ、やれるときにやっておくべき。優先度を高く設定しておくべき。
システムチームにありがちな
他人が関わる作業を放置して、自分の実装を優先する というのは
最悪の進め方の１つになります。
次が、最後のノウハウになります。
１度やって終わりではない。１日何度でも繰り返す。
自分の場合、残作業の洗い出しは１日１０回以上行っています。
上手く実装が進まない、
承認依頼が差し戻って、再度承認依頼が必要、
取るべき承認が漏れていたことに気付いた、、、
など、
タスクの状況はリアルタイムに変わります。
その度に、残作業量と優先度は変わっています。
だから、残作業の洗い出し と 優先度決めを繰り返すわけです。
しんどい話が続いてるような気がするんですが、、、
残作業を消化して完了扱いにするのは、少し快感ですし
その日の消化量を確認すると、若干の達成感を感じます。
その達成感を求めて、自分は継続出来ているのかな と思います。
—
もう一度まとめます。
週間の予定を達成するには…
１. 残作業を洗い出し、優先度を決めて対応 を繰り返す。
２. 残作業の洗い出しは、極限まで細かく。
３. 他人が関わる作業は、優先度を高く設定する。
の３つが大事。
徹底すれば、もっと達成率は上がるはずだと本気で思っています。
