「タスク遅れに対しての手札をふやす」ことが、マネージャーの立ち回りとして大事だという話
皆さん、「タスクが遅れている時」の対処法って、いくつくらいお持ちですか?
この記事で書きたいのは、大体以下のようなことです。
・昔、「タスク遅れ解決のための手札をどれだけ持っているかがマネージャーの価値」と教わりました
・タスク遅れは必ず発生するものですし、必ず対処しなくてはいけません
・タスク遅れの解決方法は色々ありますが、ざっくり分類すると「人的リソースでなんとかする」「調整でなんとかする」「プロセスをなんとかする」の三つになります
・ただし、タスク遅れに対してどんな手を打てるかは組織次第、状況次第で変わります
・「タスク遅れ解決のための手札」をなるべく増やすように、普段から立ち回りを意識するのが良いような気がします
よろしくお願いします。
さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。
前から何度か書いていますが、しんざきはシステム開発の会社で管理職をしています。元々の専門はDB屋で、特にPostgreSQLとかOracleとかMongoDBあたりで色々やってることが多いんですが、最近はマネジメントがメインです。
いきなり話がそれるんですが、先日のラスベガス、Oracle AI Worldでいきなり「Oracle Database 26ai」とかいうものが発表されたのはびっくりしましたよね。
あれ、中身見てるとどう見ても23aiのマイナーバージョンアップで、リブランディングよりも早いとこオンプレ版出してくれないかなと思うんですが……
で、最近後輩の子がマネージャーに昇格しまして、若干疲れている様子だったので飲みに誘ったところ、チーム内のタスク遅れについて相談されました。
その時話したことが、本人的には結構参考になったようなので、ちょっと記事にしてみようと思います。
新人マネージャーさんの悩み
彼の悩みは、簡単に言うと
「チームのタスクが遅れがち」
「それについて、マネージャーの自分が解決しないといけないのに、なかなか解決できず遅れが膨らんでいる」
というものでした。とてもまっとうな悩みだと思います。
昔、同じようなことは私自身にもあって、その時先輩マネージャーの人に教わったのが「タスク遅れの手札の増やし方」という話だったので、私もその話をしました。
まず前提として、それがどんなプロジェクトであろうと、「タスク遅れ」というものは絶対に、確実に発生します。これはどうしようもありません。
工期の見積もりというものは、あくまで「見積もり」でしかありません。完璧な見積もりをすれば完璧な工数が算出されるはずですが、言ってしまうと絵に描いた餅です。
プロジェクト遂行中に発生するトラブルはエスパーでないと予知できませんし、メンバーが人間である以上は体調崩すこともありますし、サボっちゃうこともあります。「このタスク難しすぎてわけわかんないんですけど」とか、「依存関係が複雑過ぎて手がつけられません」なんてことだってあるでしょう。
なので当然タスクごとにリスクを計ってマージンを作るわけなんですが、存在するマージンは基本的に全て食い潰されるものなので、大抵それ以上にタスクは遅れます。ここまではごく自然なことです。
問題は、
「タスク遅れに対して、マネージャーはどれだけ打てる手を持っているか」
ということでして、これは実のところ環境と状況と経験次第と言ってしまっていいです。
まず、「タスク遅れに対する手札の種別」の話をします。
タスク遅れに対する手札
もちろんタスク遅れに対処する方法は様々にあって、対処する人の立場でも、仕事の種類でも、組織のあり方によっても異なるんですが、すごくざっくりと分類してしまうと、
1.人的リソースでなんとかする
2.調整でなんとかする
3.プロセスをなんとかする
の、大きく三つくらいにカテゴライズできると思います。
もちろん、お互いに関連したり、複数のカテゴリーにまたがったりもします。
まず、「人的リソースでなんとかする」。これは分かりやすいですよね。
要は「やる人の手を増やしたり、費やす時間を増やすことでなんとかする」というものです。
端的に「残業時間を増やしてタスク対応をする」というのもここに含まれるし、
「対応メンバーを追加する」
「誰かに手伝ってもらう」
「出来る人を連れてきてもらう」
というのもこれでしょう。
もちろん、メンバーを一人から三人に増やしたからといって、即対応能力が三倍になるわけはない(場合によってはむしろ対応能力が下がったりする)んですが、ここでは一旦それは置いておきます。
一番分かりやすいが故に、マネージャーにとっては安易に頼ってしまいがちな方法でもあります。
端的に「頑張る」でしかない対処法もここに含まれており、マネージャーが「頑張る」しか手札をもっていない人である場合、時々悲劇が発生することもあります。
「人的リソース」以外の手札を何枚持っているか、というのは、マネージャーの有能さを示す一つの指標である、といってもいいでしょう。
次に「調整でなんとかする」。
ここにも様々な方策が含まれるんですが、分かりやすいのは
「他の担当チームやクライアントと相談してスケジュールを延ばしてもらう」とか、
「実装する機能のスコープを見直してタスク自体をスケールダウンする」とか、
「機能を簡易化してタスクの難易度を下げる」といった辺りは代表的なところでしょう。
「上にエスカレーションする」というのもこれに含まれるかも知れないですね。
一般的に、「人的リソースでなんとかする」よりは、この「調整でなんとかする」方が、マネージャーにとっての難易度は高い傾向があります。
組織によっても仕事の質によっても、ここでどれだけの選択肢がとれるかは変わってきます。
とはいえ、一般に「タスク遅れ」と言われた場合、この辺の選択肢がマネージャーに期待される部分は大きいでしょう。
三つ目、「プロセスをなんとかする」。
これにも色々あるんですが、分かりやすいところで言うと
「レビューや事務手続きで時間を食い過ぎているので、リスクをとったり簡略化したりでプロセスを改善する」であるとか、
「メールのやり取りで時間食ってるので拠点を移して対面で話せるようにする」
みたいな方策はここに当たると思います。
他にも、例えば開発手法を変更したり、ツールでテストを自動化したり、作業を分割して開発を並列化したり、なんて方法もあるでしょう。
クリティカルパスの見直しや、後工程を前倒しで始めることで全体としての遅れを吸収する、というのもよく使う手です。
まあ、炎上してる最中にそんなことできるかって方策もあり、むしろ遅れが顕在化してからより普段からの準備が重要って部分でもあります。
もちろん「プロセスをなんとかする」にも調整が必要になる場合は多いですが、一般的には、ここが一番難易度が高いケースが多いように思います。
マネージャーにとっては腕の見せ所でもあり、「プロセスの改善で工期遅れを取り戻しました」なんて言えたら超かっこいいですよね。
まあ、下手にプロセスをいじると逆効果で、実際にはメンバーが超頑張ってフォローしてくれていただけ、なんてケースもあったりするんですが……。
今の自分は、「タスク遅れ対応の手札」を何枚持っているか
ここまでで問題になってくるのは、「実際にタスク遅れをどう解決するか」以上に、
・マネージャーとしての自分は、タスク遅れの対応策を幾つ知っているか
・そのうち、現在の環境、現在のプロジェクトで、実際に取り得る対応策はどれか
・そのうち、もっとも効果的で、なるべくコストを低減できる対応策はどれか
ということを把握しているかどうか、ということです。
上でも書きましたが、タスク遅れの対応策は、環境によっても、仕事の種類によっても、選択できるものが変わってきます。
例えばクライアントとの関係次第では、スケジュールの調整なんてやりたくてもできないかも知れません。
品質は絶対厳守でテスト工数は絶対に減らせないかも知れませんし、有識者を連れてこようにも他チームも全部炎上しているかも知れません。
そんな中で、「頑張る」以外の手札をどれだけ用意できるか。
少なくとも、「調整で何とかする」「プロセスで何とかする」からも、それぞれ二枚、三枚の手札を選択できるだけの余地を確保できているか。
要は、常に「使い得る手札」を把握しておいて、できることならその枚数を増やせるように立ち回っておく、というのが、マネージャーとしては非常に重要、という話なんです。
例えば、常日頃から他チームといい関係を築いておいて、いざという時にはヘルプを求められるよう恩も売っておく、とか。
スコープの見直しの可能性やリスクについて、事前にクライアントと調整しておいて、いざという時は切り捨てても良い機能、品質の落とし所について確認しておく、とか。
もちろん、こういうリスク計画ってプロジェクトの立ち上げ時点で個別に考えておくべきテーマですが、一方「普段からの立ち回り」で事前準備が必要な部分でもあります。
「タスク遅れ」という分かりやすいピンチでどういう手札を持っているかは、マネージャーとしての一番の価値でもあって、この「手札を増やす努力」自体が、会社での自分の立ち位置を向上させていくための努力とほぼイコールになると言っても言い過ぎではないと思うんです。
まあ、冒頭書いた新人マネージャーさんの場合、今回彼が悩んでいたタスク遅れって環境由来の部分で、一つの開発環境内で全部解決しようとしていたから色々引っかかっていたわけで、
「あれ、それもう一つ環境作って、そのリソース使えば解決できるんじゃ。使ってないの融通できるよ」
というようなアドバイスを出したら解決に向かったわけですが、そういった「解決できそうな人に事前に渡りをつけておく」というのも、マネージャーとしての価値を高めるための一つの方法なのかも知れません。
タスク遅れの対処、大変ですよね。
皆さんが、できれば炎上などとは無縁に、平和なプロジェクトを進められることを祈念しつつ、この記事を締めたいと思います。」
今日書きたいことはそれくらいです。
***
【著者プロフィール】
著者名:しんざき
SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。
レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。
ブログ:不倒城
Photo:Olha Sobetska
