人に何を任せ、自分は何を担うか。見ることだけは手放さない

私は、高度なことだけをしたいのではありません。プロジェクトを推進させたいのです。そのために必要な取り組みがコピー用紙の補充なら、率先してやります。コピー用紙の補充を軽く見ているのではありません。誰かがやらないと進まないことの、いちばん分かりやすい例として挙げています。

ただし、プロジェクトは基本的に複数名で進めます。一人なら「必要なことは全部やる」で済みますが、複数名ではそうはいきません。人に何をやっていただき、自分は何を担うべきか。その境界をどこに引くか。これを自分の言葉で整理しておきたくなりました。

コピー用紙の補充は、「なんでもやる」という意思表示です。それがプロジェクトの推進に寄与しているかは、別の問題です。プロジェクトには、自分で手を動かす側と、人がやった仕事を確認して次を決める側があります。確認して決める側に立つほうが推進に寄与するなら、あるいは顧客がそれを期待しているなら、私は確認して決める側に立ちます。つまり「なんでもやる」は姿勢の話で、「何を担うか」は判断の話です。この記事が扱うのは後者です。

私が実際に判断した一件を、任せる前、任せている間、任せたものが思うように進まなかったとき、終わった後の順に追います。それぞれの場面で、自分が何を見て決めているかを書きます。

任せる前

ある現場で、HA クラスタを構築することになりました。HA クラスタとは、サーバを二台一組にして、片方が壊れてももう片方で動き続ける仕組みです。私が入ったのは詳細設計の段階で、詳細設計から構築までを人に任せる予定でした。インプットとして利用できるのは、製品マニュアルと、現行システムを構築したときのログです。

任せるかは「できるか」で決める

任せるかは、相手にできる見込みがあるかで決めます。ここで言う「できる」とは、品質を担保できることです。品質とは良し悪しではなく、基準との差です。以下、この差を差分と呼びます。基準とは正しい形のことで、この一件では製品マニュアルと現行構築時のログから分かる形がそれでした。成果物を基準と見比べて、差が期限内に埋まる見込みがあるなら任せます。

品質を差で捉えるのは、私だけの言い方ではありません。JIS X 25010（ソフトウェア製品の品質モデル）は、品質を「明示的ニーズ及び暗黙のニーズを満足させる度合い」と定義しています。JIS Q 9000（品質マネジメントの用語）は「要求事項を満たす程度」です。比べる相手は違いますが、どちらも良さの絶対値ではなく、満たす度合いです。

基準が無いときは、基準を作るところから

基準が無い仕事もあります。そのときは、あらゆるインプットを元に基準を導き出して、顧客と握るところから始めます。製品マニュアル、現行構築時のログ、顧客との会話、似た案件の記録。そこから「これを満たせば良い」という形を作り、顧客と合意します。

基準を作る仕事も、可能であれば任せたいものです。任せるかどうかは構築と同じで、その人にできるかで決めます。ただし、そこで見るのは技術ではありません。

任せる相手は、技術より姿勢で選ぶ

任せる相手を見るとき、私は技術より姿勢を見ます。姿勢は必要条件です。能力は、必要最低限あるか、至る可能性があるかのどちらかで足ります。

姿勢は、次の四つで見ています。

• 成果物：初回のレビューで、内容が五割以上できているか
• 報連相：相手が欲しいタイミングで、適切な量が来ているか
• 質問：自分の想定を持って聞いているか。方向性が間違っていないか
• 期限：期限を気にした焦りがあるか

四つ目の焦りは、良い兆候として見ています。その仕事を自分のものとして引き受けている、いわゆるオーナーシップが垣間見えるからです。

能力について見ているのは、次の二つだけです。顧客を怒らせないこと。基準を導き出すまでのプロセスを間違えても、即座に修正できること。

なぜ技術より姿勢なのか。基準は一律ではなく、顧客の環境によって異なり、そのときの状況によっても変わるからです。いまの基準と完全に一致する経験を持つ人はまれです。一致する人がいればそのまま任せればよいのですが、次の案件に切り替わったとき、そこで終わってしまいます。姿勢のある人に任せると、その人にもチームにも、成功したインプットが残ります。成功したインプットとは、案件をこなす中で「この基準でうまくいった」と分かった材料のことです。それが増えるほど、次の案件で基準を導き出すのが容易になります。

任せている間

任せたあとも、私が手放さないものが二つあります。

一つは、成果物を相手が見ていない側から見ることです。完璧に物事をすべてこなせる人はいません。作る人は、動くかどうかを見ます。私は、リリース後と運用保守の側から、壊れたらどうなるかを見ます。レビューの観点はテストと同じで、単体、結合、総合、運用の順に見ていきます。

もう一つは、状況を把握し続けることです。任せても、状況把握は任せる側の最低限のラインです。先ほどの四つの観察点は、任せる前だけでなく、任せている間も見続けます。この考えは、松下幸之助の「任せて任せず」や、Andy Grove の「フォローのない委譲は放棄である」と同じです。

見るだけで済ませるか、自分で作るかの境目は、期限に間に合うかどうかです。HA クラスタの一件では、上がってきた成果物を、製品マニュアルと現行構築時のログと見比べていました。差分は多く、期限は迫っていました。

任せたものが基準に届かなかったとき

差分が期限内に埋まりそうにないとき、私は次の五つを上から順に検討します。上の段で成立すれば、そこで止めます。成立しなければ、次の段に下ります。

一段目：任せ続ける

差分が小さいか、相手が自分で減らせるなら、そのまま任せ続けます。

二段目：差し戻して手直しさせる

差し戻しが成り立つのは、一度指摘すれば次は直っているときです。目的とインプットを理解しているか。示した方針に沿っているか。誤りに規則性があるか。前回指摘したことが取り込まれているか。指摘を素直に受け入れて直す姿勢があるか。これらが揃っていれば、差分は往復のたびに減ります。逆に、初期の品質が悪すぎると、いくら工数と期間を積んでも、品質を満たさないままで終わることが多いです。

フィードバックの研究でも、同じことが言われています。フィードバックが最も効くのは誤った理解を正すときで、理解そのものが無いときには効かないとされています。

三段目：手順を作って渡す

差し戻しでは減らなくても、判断を手順に固定できるなら、仕事は「実行」に変わります。手順を作ればあとはやるだけなので、要点と注意点を押さえていればいいだけです。ただし、最初に手順を作る人には、手順を作るための手順書がありません。だから最初の一つは、自分で作ることになります。

四段目：全部巻き取る

手順にできない仕事があります。一歩ごとに判断が要る仕事です。これは自分で全部やります。

五段目：条件付きでギブアップする

巻き取っても自分ひとりでは期限内に終わらないときは、期間を調整します。ただし限界が来てからではなく、「いつまでに〇〇ができなければ調整が必要です」と先に打診しておきます。怒鳴られても失望されても、ギブアップして期間を調整し、一から相手にやってもらうのもありです。

段の境目と、順番の理由

一段目と二段目の境目は、相手が自分で減らせるかです。二段目と三段目の境目は、指摘すれば減るかです。三段目と四段目の境目は、判断を手順に固定できるかです。四段目と五段目の境目は、自分ひとりで期限内に終わるかです。

上から順に検討するのは、段を下るほど戻れなくなるからです。一段目と二段目では、仕事は相手のものです。三段目と四段目に下りると、自分が作った部分が残ります。

「人を増やす」という手は、ここにありません。それが効くのは、考えることが終わっていて、あとはやるだけのタイミングだけだからです。それ以外の場面では、教えることで時間が潰れます。

最初から自分でやる、という選択もあります。それは任せる前に四段目を選ぶことです。判断が毎回要る仕事で、姿勢のある相手がいないとき、それだけです。

HA クラスタの一件では

一段目は成り立ちませんでした。差分が多かったからです。二段目も成り立ちませんでした。インプットが違い、間違いが不規則で、差し戻しても差分が減らなかったからです。三段目で止まりました。一台目を自分で作り、その過程で手順を整備できたので、「これなら人に渡せる」と二台目を渡しました。二台をまとめるクラスタの主要な設定は、ほとんど自分でやりました。

最初から手順を書いて渡すことはできませんでした。一台目を自分の手で作らないと、手順は書けなかったからです。時間に余裕があったとしても、二台目は渡していました。「自分がやった方が早い」とは別の判断です。

終わった後

一台目は、あとで問題が起きたとき、作った自分が対応することになります。二台目を渡しても、その分は相手に移りません。これが、三段目に下りた代償です。

理想は、期間内で手直しをして、すべて相手自身にやってもらうことでした。時間のためでも、育成のためでもありません。結局、何か問題があったときに自分で対応しないといけなくなるからです。

これは構築に限りません。新しいものを試す仕事も同じです。試すのは楽しいのですが、導入となるとテストや運用まで付き合うことになり、試した分だけ自分の工数が減っていきます。

成功したインプットが残るのは、一段目と二段目

成功したインプットが相手に残るのは、一段目と二段目です。相手が自分で差分を減らしたときだけ、「この基準でうまくいった」が相手のものになります。三段目に下りると、相手は手順を実行しただけです。手順を渡すと、相手はそこで止まります。明確な指示を出すことでリーダーになったつもりでいると、メンバーが自分で考えられなくなります。

期限に押されると、段は下に落ちます。落ちるほど、成功したインプットは減ります。五段目の条件付きギブアップは、それを守るための手です。期間を調整して、一段目や二段目に戻すのです。

七年前、私は X に、期間を延ばすのは一番使わない手だと書いていました。信用を失いやすく、誰もやらないからです。今は、五段目として先に握っておく手だと考えています。振り返ると、私は五段目を使わずに、期限に押されて三段目や四段目に落ちてきたことが多かったです。

確かめていないことと、この記事の外側

確かめていないことが一つあります。基準を作る仕事を、姿勢で選んだ相手に任せることです。構築を任せた経験は多いのですが、基準を作るところから任せた経験は少ないです。姿勢で選んで任せたと言えるかは、まだ確かめられていません。相手の能力が足りないと感じて、任せる勇気が出なかったこともあります。

この記事は、自分と任せる相手の一対一の話です。その外側に二つあります。

一つは体制です。品質の問題なのか、人の問題なのか、体制の問題なのか。見落としがちなのは体制で、座組みを間違えていると、頑張っても暖簾に腕押しになります。

もう一つは、この判断がどう広がるかです。与えられたタスクを手戻りなく完遂すると、過去実績の信用から次のタスクの信頼を得ます。貯めた信頼で、自分で面倒を見られる範囲のメンバーを預かります。面倒を見られない人数になれば、サブリーダーを立てて、自分は課題と進捗の管理で全体を見る側に回ります。ここは別の話なので、この記事では触れるだけにします。

出典

• 本人の経験則（2026-09-12〜13 の壁打ちで言語化）と、本人の過去の X 投稿（2019〜2026 年）
• JIS X 25010:2013（ISO/IEC 25010:2011）システム及びソフトウェア製品の品質要求及び評価（SQuaRE）― システム及びソフトウェア品質モデル。3.1 と 4.3.13 の品質の定義。ISO/IEC 25010:2011 の公式プレビュー https://cdn.standards.iteh.ai/samples/35733/2ca18b477b7845a5b8cae39d6de0c098/ISO-IEC-25010-2011.pdf
• JIS Q 9000:2015（ISO 9000:2015）品質マネジメントシステム ― 基本及び用語。3.6.2 品質の定義（ISO 9000 は 2026 年に第 5 版となり、同じ定義が 3.5.2 に移っている）
• 松下幸之助「任せて任せず」 松下幸之助.com（PHP 研究所） https://konosuke-matsushita.com/keywords/hr-development/no3.php
• Andrew S. Grove, High Output Management, Random House, 1983, p.60 "delegation without follow-through is abdication"
• John Hattie and Helen Timperley, "The Power of Feedback," Review of Educational Research 77(1), 2007, pp.81–112. https://doi.org/10.3102/003465430298487
• Stuart E. Dreyfus, "The Five-Stage Model of Adult Skill Acquisition," Bulletin of Science, Technology & Society 24(3), 2004, pp.177–181. https://doi.org/10.1177/0270467604264992 （手順は初心者段階の指導法であり、それ以上に進むには自分で判断する経験が要る、の裏付け）

関連

• 課題管理_課題管理とはなにか（未公開）
• 仕事の進め方_SES現場で教わるなら相手が手を打てる時点で聞く
• 仕事の進め方_打ち合わせの出口は誰が何をいつまでにの一文