第4章 4.1 ← 4.0 チームと関係者
権限がない立場で、それでもチームを動かす
プロジェクトを任されたとき、多くの人が最初に気づくのは自分には何の権限もないということです。評価もできない、命令もできない、予算も動かせない。それでも進めなければなりません。この記事は、そのための具体的な道具の話です。
この記事の要点
- 権限がないことは、動かせないことと同じではありません。使える道具が違うだけです。
- 共通しているのは、判断材料をこちらで用意して、決める人に渡すという形です。
- 「どうしますか」ではなく「AかBか」で持っていくと、決まる確率が跳ね上がります。
- 間に落ちる仕事は、担当が「チーム」になっている仕事です。必ず名前を入れてください。
- 最初の悪い報告への反応が、そのあと数か月の情報の流れを決めます。
持っていないものと、代わりに使えるもの
権限の話は、抽象的に語ると身も蓋もありません。具体的に、何が持てなくて、代わりに何が使えるのかを並べます。
「どうしますか」を捨てて、「AかBか」にする
4つの中で、いちばん効果が大きくて、いちばんすぐ使えるのがこれです。
判断を仰ぐとき、「どうしましょうか」と持っていくと、決まりません。決める側は状況を把握していないので、まず説明を求め、そのうち「持ち帰って検討する」になります。二週間が過ぎます。
かわりに、選択肢を2つにして、それぞれの結果を添えて持っていきます。
A案:連携方式を簡易なものに変える。開発が2週間短縮できるが、月次の手作業が1件残る。
B案:当初方式のまま進める。手作業はなくなるが、リリースが3月末から4月中旬になる。
この形なら、その場で決まることが多くあります。決める人が必要としているのは情報ではなく、選べる形になったものだからです。そして日本の組織では、この2択を稟議書に載せるとそのまま通ることも多い。決裁者が説明を書かなくて済むからです。
依頼は、理由と期限を書いて渡す
他部署や協力会社に何かをお願いするとき、口頭だけで済ませると高い確率で滞ります。相手にとっては数ある依頼のひとつで、優先度が分からないからです。
効くのは、次の3つを書いて渡すことです。
- 何をしてほしいのか。具体的な成果物の形で。「確認をお願いします」ではなく「この5項目について、はい/いいえで回答をお願いします」。
- いつまでに必要か。そして、なぜその日付なのか。「3月5日までにいただけると、移行テストに間に合います」。
- 遅れると何が起きるか。脅しではなく事実として。「遅れると、テスト期間が1週間短くなります」。
この形にすると、相手は自分の中で優先度をつけられます。命令ではないからこそ、判断材料が要るのです。そして書いてあると、相手の上長にも回せます。口頭の依頼は回せません。
協力会社への依頼には、契約上の注意があります
請負契約の相手に対して、業務の進め方や作業時間を細かく直接指示すると、契約の実態と合わなくなる場合があります。実務上は、「何を、いつまでに」を伝え、「どうやるか」は相手の管理者に委ねるのが基本形です。困ったら自社の調達や法務に確認してください。この線引きは、こちらを守るためのものでもあります。
間に落ちる仕事を、なくす
チームがうまく動いていない現場の症状は、たいてい同じです。誰の担当でもない仕事が、放置されている。
これはメンバーの怠慢ではありません。9.2でも扱いますが、4人が見えている仕事は、4人それぞれから見ると「他の3人がやるかもしれない仕事」です。待つコストは見えず、やるコストは見えます。合理的に判断すると、全員が待ちます。
対処はひとつだけです。すべての項目に、ひとりの名前を入れる。その人が作業をする人とは限りません。「その件について聞かれる人」であれば十分です。名前が入っていると、その人だけが落ち着かなくなります。それでいいのです。
そして会議の終わりには、必ず誰が・何を・いつまでにを口に出してください。3つとも埋まらない項目は、まだ議論が終わっていません。その場で気づくほうが、二週間後に気づくよりずっと安く済みます。
最初の悪い報告に、どう反応するか
4.0でも触れましたが、ここは繰り返す価値があります。チームの情報の流れは、最初の悪い報告への反応でほぼ決まります。
三日の遅れが報告されたとき、「なんで遅れたの」と聞くと、返ってくるのは説明です。そして次からは報告が来ません。「何があれば動きますか」と聞くと、返ってくるのは解決策です。そして次からも報告が来ます。
これは優しさの話ではなく、情報を集める技術の話です。責める権限を使うと、その場では気が済みますが、以後の情報が止まります。権限がない立場では、情報だけが武器です。それを自分で止めるのは、いちばんもったいない選択です。
評価できないからこそ、上長に届ける
メンバーを評価できないことは弱点に見えますが、使いようがあります。評価権を持たない人からの称賛は、持つ人からの称賛より信頼されます。お世辞である理由がないからです。
実務的には、その人の上長に一言送るだけで十分です。「移行の設計、田中さんに助けられました。あの指摘がなければ本番で止まっていました」。CCに本人を入れておく。これは3分で終わり、しかもかなり長く効きます。
兼任のメンバーにとって、プロジェクトの仕事は本業の評価に直接は乗りません。上長に見えていなければ、頑張るほど損になります。その構造を少し崩すだけで、次に無理を頼めるようになります。
ABではこう見えます
AB Projectsでは、タスクの担当者がひとりに定まる形になっています。「チーム担当」が作れないので、間に落ちる仕事が構造的に減ります。割り当てが特定の人に偏っていれば、それも一目で分かります。
依頼を書いて渡す部分は、タスクの説明欄とコメントで完結します。理由と期限が書かれた依頼が記録として残るので、相手の上長にもそのまま共有できますし、あとで「言った・言わない」になりません。
このページで使った言葉
- 上長
- 承認や評価の権限を持つ、その人の上位者です。プロジェクトを進める人とは別であることがほとんどです。くわしく →
- 協力会社
- 元請けから作業を請け負う会社です。契約の形によっては、作業の進め方を直接指示できません。くわしく →
- 稟議・決裁
- やるかどうかを組織として決める仕組みです。2択にして持っていくと、そのまま通ることが多くなります。くわしく →
- 報連相
- 報告・連絡・相談の略です。確定前に動かせる「相談」を促せるかどうかが、情報の流れを決めます。くわしく →
- 兼任
- 本業を持ったまま別の役割も担うことです。プロジェクトの働きが本業の評価に乗りにくい、という問題が伴います。くわしく →
- エスカレーション
- 自分の権限で決められないことを、決められる人に上げることです。2択の形で上げると通りやすくなります。くわしく →
あわせて読みたい
4.2 関係者との付き合い方
登場が遅い人ほど高くつく、という構造の話。
4.3 伝え方の設計
誰に、何を、どの頻度で伝えるかを先に決める。
9.2 実務のコツ
手間の割に効く習慣を、費用対効果で並べたもの。