1ヶ月で達成できる行動目標を与え続ける
人を育てる際にすべきことを重要な順に並べると、次のようになる。
（１）素質（特にやる気）をもった人を育てること
（２）適切な難易度の挑戦機会を与えること
（３）手取り足取りなど、丁寧に指導する時間を設けること
ここでは（２）について話したい。
例えば、期限までにアウトプットを提出できないエンジニアがいるとする。
期限までに間に合わないことを再三指摘され、本人も気に病んでいるとする。
このエンジニアをどう指導するか。
こういうときにエンジニアによくいく指示として代表的なのは、
「期限までに出せ」とか
「スケジューリングをしろ」とか。
でも、これらは指示として不適切。
だって、言われてそれができるんなら、そもそも期限に間に合うようできたはずだから。
だから上司としては、部下がなぜ期限に間に合わないのかを、考える必要がある。
技術力の問題なのか、そもそも実現不可能な期限が与えられていたのか、
それともスケジューリングの問題だったのか。
スケジューリングの問題だとしたら、それはなぜか。
スケジューリングを組む習慣がそもそもないのか、
スケジューリングを組む習慣があってもダメなのか。
プロジェクトの初期にスケジュールを組む習慣があるとすれば、
資源配分や目標の修正など、突発事項が出てきたときには柔軟にスケジュールを変更できているのか。
・・・ このように分解していくと、次のように行動目標を置くことができる。
・１ヶ月目 期限が渡されたときに、1週間単位程度でマイルストーンを適切に置けるか
・２ヶ月目 開発人員体制が変更されたり開発上の技術的困難がみつかったりしたときに、
. マイルストーンを適切に変更し、期限への影響を判断できるか
・３ヶ月目 期限に遅れそうな場合、そのアラートを開発期間全体の３分の２の間に出せるか
・４ヶ月目 期限に遅れる開発者という印象を周りに与えずに済むか
実際、上記のものに近いものをフィリピン側の開発者に対して提示した。
彼は今までずっと「期限に間に合わせろ」というプレッシャーを受け続け悩んできた。
できないのは自分が悪いのではないか、才能がないせいなのではないか、
会社の評価の仕組みが間違っているのではと苦しんでいた。
だからこそ、今回のこの目標の話を聞いてほっとしていた。
何に対して自分が取り組むべきか明確になって、
そして自分がそれを達成できそうで、安心していた。
コミットメントの高い人にチャレンジングな状況を与えれば、
本人はスキルを伸ばそうと真剣になる。
このとき、簡単すぎるチャレンジでもダメだが、
半年や1年たたないと達成できないような難しいチャレンジもダメ。
当然、体をこわすような無理なチャレンジもダメ。
部下に仕事をデレゲーションするときは、
全部を任せきるのはぐっと我慢し、
部下が１ヶ月頑張れば達成できる範囲にデレゲーション内容を限定し、
残りは（暗黙の内に）自分がカバーするという意思決定が必要だ。
そして部下が１ヶ月の目標を達成したらそれをほめ、
任せる範囲を少し拡大して、さらなる１ヶ月目標を与える。
これを続けていくことで、常に適度にチャレンジングな状況を与え続けることができる。
僕自身が常にそうできるようになる必要があるのはもちろん、
ミドルマネジメントの人たちもそのようにできるよう、
トレーニングしていく必要があると考えている。
（１）素質（特にやる気）をもった人を育てること
（２）適切な難易度の挑戦機会を与えること
（３）手取り足取りなど、丁寧に指導する時間を設けること
ここでは（２）について話したい。
例えば、期限までにアウトプットを提出できないエンジニアがいるとする。
期限までに間に合わないことを再三指摘され、本人も気に病んでいるとする。
このエンジニアをどう指導するか。
こういうときにエンジニアによくいく指示として代表的なのは、
「期限までに出せ」とか
「スケジューリングをしろ」とか。
でも、これらは指示として不適切。
だって、言われてそれができるんなら、そもそも期限に間に合うようできたはずだから。
だから上司としては、部下がなぜ期限に間に合わないのかを、考える必要がある。
技術力の問題なのか、そもそも実現不可能な期限が与えられていたのか、
それともスケジューリングの問題だったのか。
スケジューリングの問題だとしたら、それはなぜか。
スケジューリングを組む習慣がそもそもないのか、
スケジューリングを組む習慣があってもダメなのか。
プロジェクトの初期にスケジュールを組む習慣があるとすれば、
資源配分や目標の修正など、突発事項が出てきたときには柔軟にスケジュールを変更できているのか。
・・・ このように分解していくと、次のように行動目標を置くことができる。
・１ヶ月目 期限が渡されたときに、1週間単位程度でマイルストーンを適切に置けるか
・２ヶ月目 開発人員体制が変更されたり開発上の技術的困難がみつかったりしたときに、
. マイルストーンを適切に変更し、期限への影響を判断できるか
・３ヶ月目 期限に遅れそうな場合、そのアラートを開発期間全体の３分の２の間に出せるか
・４ヶ月目 期限に遅れる開発者という印象を周りに与えずに済むか
実際、上記のものに近いものをフィリピン側の開発者に対して提示した。
彼は今までずっと「期限に間に合わせろ」というプレッシャーを受け続け悩んできた。
できないのは自分が悪いのではないか、才能がないせいなのではないか、
会社の評価の仕組みが間違っているのではと苦しんでいた。
だからこそ、今回のこの目標の話を聞いてほっとしていた。
何に対して自分が取り組むべきか明確になって、
そして自分がそれを達成できそうで、安心していた。
コミットメントの高い人にチャレンジングな状況を与えれば、
本人はスキルを伸ばそうと真剣になる。
このとき、簡単すぎるチャレンジでもダメだが、
半年や1年たたないと達成できないような難しいチャレンジもダメ。
当然、体をこわすような無理なチャレンジもダメ。
部下に仕事をデレゲーションするときは、
全部を任せきるのはぐっと我慢し、
部下が１ヶ月頑張れば達成できる範囲にデレゲーション内容を限定し、
残りは（暗黙の内に）自分がカバーするという意思決定が必要だ。
そして部下が１ヶ月の目標を達成したらそれをほめ、
任せる範囲を少し拡大して、さらなる１ヶ月目標を与える。
これを続けていくことで、常に適度にチャレンジングな状況を与え続けることができる。
僕自身が常にそうできるようになる必要があるのはもちろん、
ミドルマネジメントの人たちもそのようにできるよう、
トレーニングしていく必要があると考えている。