上司に仕事を丸投げされた時に大火傷しないよう心がけている5つのこと

社内外のパートナーから丸投げされるケースや、他社の社長さんからいきなり指令が下るケースも想定しています。本日知り合いの社長さんが、ブラックな開発会社から中間管理職を採用するのが良いね、といってましたが、たしかにそういった会社の管理職の方々は全員できそう。

任せていいかな?でプロジェクトの全責任は既に自分に移っている

部分的に手伝えばいいかな、とか、空いた時間で優先的にできる限り貢献すればいいかな、なんて思っていると痛い目にあいますよね。既存業務のスケジュールや目標やリソースの調整を率先してやらないと気づい頃にはすべての負債が自分の手元で爆発しています。爆発してからは誰も協力どころか近づいてくれないので序盤で全力を出すのが鉄則です。幸い任された初日から事業やプロジェクトや仕事が崩壊しているケースは比較的少なく、むしろ良い状態で回ってくることもあるので、経験不足があっても全力さえ出せればなんとかなる。

けど引き渡されるってことはいろいろ意味がある。それをまず紐解くのが大事なのかなと思います。

他のやつではなく自分に任せられている理由が必ずある、それを把握する

そもそも、誰にとっても良い仕事や事業であれば任されることはまずないです。自分に専門性があって、その専門性が求められているケースであればわかりやすいのですが、それは(ぼくは)殆どないです。任されているということは、その仕事の旨味が(その人にとって)なくなったか(続けても自分が成長できないと判断した、成長するつもりがない分野だった、など)、もっと旨い仕事が見つかったか、雲行きが怪しくなってきたか、ですよね。ただ、いずれの場合も自分に任される理由が一応あって、それをまずは把握することがモチベを底上げする要因にもなりますし、相手が求めている結果や動き方ができるようになるんじゃないかと思います。

たとえば、上司にとっては旨味がないけど自分にとっては旨味があると思われている場合は、欠点を補う機会や新たに知識を得る機会であり、上司が経験者であれば盗みやすく、そうでなければ上司と異なるスキルセットを得やすい、などのメリットがあります。また、これらから成長を期待して話をふってきています。僕の場合は(前職および、弊社を初めてからは)、そうでした。他社は知りません。そして押し付けがうまくいけばその上司は優先度の高い仕事を遂行できるようになります。次に評価される内容が把握でき、感謝されやすい状況を作ったとも言えますね。

さて、自主的にモチベをあげられることに成功したら、けっこう面倒くさい現実が待っているので、対処していきます。まずは最大のリスクはどこかを把握することから始めます。

”できれば”やっておいてね・やっておいたほうがいいよは絶対やらないと死ぬ

任せた側もいきなり任せて悪いなあという負い目があるからか、進め方など細かいところまで指定しないことが殆どです。そのためか、落とすと致命傷になるけど、致命傷になりえることがあるとわかってて依頼した思われたくないから、ふわっとした言い方でアドバイスをくれるものだと認識しています。

※任せたといって細かいところまで口出してくるやつはむしろ優しい。面倒くさいかもしれないけどちゃんとケアしている証拠です。

”できればこうなったらこの人に事前に連絡しておいたほうがいいよ。”といった納期を守らないとぶちきれる系の人を教えてくれたり、連絡しておくとよしなに協力してくれる人を教えてくれたり、”できればこの人と会うときは事前準備を怠らないほうがいいよ。”といったふうに下手なことをすると仕事がなくなるし、うまくいけば関係構築が一気にすすむ人を教えてくれたり、様々ですね。まあいろいろありますが、ふわっとした依頼こそリスクだとすぐに感知して対応しておくと、訳の分からない理由であとで怒られまくったり、なんでこうもすべてが上手くいかないんだろうと失敗が続いたりする状況を防げます。

すべてのメールをもらって過去のやりとりや登場人物の役割を徹底的に調べる

逃げ腰かつ丸投げ癖のある上司であってもメールを全部転送するところまでは迅速に対応してくれることが多いです。丁寧な説明を求めるよりも全部一気に読んで、わからない所を聞くほうがよっぽど自分の時間短縮になるし、その対応のほうが何故か上司の期限がいい。特に地雷や目標と思われるものは自分で大中小の粒度関係なくありったけ書き出してまとめて一点の曇がなくなるまで確認するのが良い。

また登場人物は全員把握しておくのが良いです。自社だけでなく、他社と組んでいるなら、他社のそれも全部把握します。開発者にとって”作り込み”が大事なのと一緒で、事業やプロジェクトといったではこの登場人物とのコミュニケーションがビジネスの作り込み部分に相当しますね。特に自分の立場や立ち位置から直接連絡できない人もいて、そいつらに連絡できるルートを確保することも大事です。切羽詰まった時に連絡網がなくてデッドロックとか洒落にならないわりによく発生するので注意します。

口頭のやりとりでログに残っていないことは諦めて足かせ分の労力を計画する

これ、毎回どうすればいいのか迷います。過去やりとりの矛盾点や謎仕様の原因やおかしなビジネスロジックの背景を聞きまわっていると大抵は断片的に闇に葬られている情報を拾い上げられます。だいたいは綺麗なロジックや問題の明確な理由ではなく、問題が問題のままフタをされちゃった結果だと知ります。フタが矛盾点、謎仕様、おかしいビジネスロジックそのものだった、といった状態ですね。

で、これを事前にすべて察知しておかないとやっぱり無駄なことに時間をかけたり大切なことをし忘れたりします。これは登場人物を全員把握して話しまくっておくと取りこぼせることも多いのですが、既に確定してから何度かピボットして決まった次項や方向性などは、特に再修正するのは難しい。しかも論理的にベターな案を理解してもらうことが難しいわけではなく、理解する行為や変更する行為そのもの自体がめんどくさくいなという空気がそこにある。ただ、メンドクサイは時間と労力をかければなんとかなるので、その時間を計画に織り込んでおくって考え方が正しいですね。

関連記事

40名:増床の費用対効果改善と社員満足度向上のための個別指導教室
35名:拡大と社員満足度向上を見据えた人事・採用担当の仕事と迎え入れ方
30名:拡大と収益率改善のための大量採用の実現と社内平均値の上げ方
25名:今後の開発体制強化を意図したウィングドア社株式取得
25名:引き受けられる案件難易度向上を実現するバーサタイルウェイ社株式取得
25名:今後の拡大を支える仕組みづくりを開始、まずは社員研修から
20名:拡大に応じて残す外注先とそうでないところの選定基準
20名:経営能力と資源確保のための第三者割当増資を実施
20名:拡大を決意し2015年度振り返り改善点を洗い出す

Ruby on RailsによるWEBシステム開発、Android/iPhoneアプリ開発、電子書籍配信のことならお任せください この記事を書いた人と働こう! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

渡辺 正毅

1984年生まれ、サンフランシスコ育ち。大学から憧れの日本に留学してそのまま移住。いい国ですよね。もっとよくしたい。好きになってくれる人を増やしたい。BPS代表。

渡辺 正毅の書いた記事

関連する記事

週刊Railsウォッチ

インフラ

Rubyスタイルガイドを読む

BigBinary記事より

ActiveSupport探訪シリーズ