ウクライナ情勢
Bildagentur Zoonar GmbH/Shutterstock
誰かから指示された｢やらされ仕事｣より、｢裁量ある仕事｣のほうがやる気は出るもの。しかもそれで結果を出せれば成長につながり、何より楽しい。では、裁量ある仕事を任されるためには何が必要でしょうか？ 答えは｢自分で考え、生産性高く成果を出すスキル｣です。
このスキルを｢自律思考｣と呼ぶのは、リクルートグループに29年間勤務し、独立後はさまざまな企業に対して業績向上支援を行っている中尾隆一郎さん。連載｢『自律思考』を鍛える｣では、生産性高く成果を出すスキルを身につけるためのエッセンスを中尾さんに解説していただきます。
前回までは、プロジェクトマネジメントの準備フェーズで押さえておきたいポイントについて解説していただきました。今回は、プロジェクトの成否を握る｢実行｣フェーズでのポイントについて考えていきます。
前回までで、適切なメンバーへのタスクの割り振りなどの準備が整いました。ここからは｢実行と修正｣のフェーズが始まります。
下図は、この連載でも何度か登場した｢G-POP（ジーポップ）｣のフローチャートです。
G-POPとは、ハイパフォーマー（仕事ができる人）の仕事の仕方と多数のビジネス書籍のエッセンスを私が独自にまとめた方法論で、プロジェクトマネジメントにも広く応用できます。｢実行と修正｣のフェーズは、このG-POPでいうところの｢O（On）｣に当たります。
- G（Goal）：ゴール
- P（Pre）：事前準備
- O（On）：実行
- P（Post）：振り返り
例えば、半期6カ月で完遂したいミッションがあるとします。理想的には、｢ゴール（Goal）｣の設定と｢事前準備（Pre）｣は当該期間が始まる前の期中、遅くとも期初の1〜2週間以内には確定させたいところです。
そして期末の1〜2週間でG-POPの後ろのP、｢振り返り（Post）｣を行います。
ということは、残りの約5カ月は｢実行と修正（On）｣ということになります。ここの巧拙がいかにゴール達成の可能性を大きく左右するかがお分かりいただけるでしょう。
そこで以降では、｢実行と修正｣をうまく遂行するためのポイントを4つご紹介します。
1. 目標達成の進捗を定期的に確認
ゴールを達成するためには、ゴールに関連するタスクをこなさなければいけません。｢何を当たり前のことを｣と思うかもしれませんが、実際にはこれを忘れている人が少なくないものです。
顧客のLTV（Life Time Value）を高めることが本来の目標のはずなのに、気がつけば新規顧客獲得のためのプロモーション準備に追われていた……なんてことはありませんか？ 目の前にタスクが積まれるとそれをこなすことについ必死になってしまいますが、本当にゴール達成に関連するタスクをこなさないかぎり、あなたがいくら頑張っても本来到達したいゴールへはたどり着けません。
約40年前の1983年に和訳された『1分間マネジャー』という名著があります。この本の中で、マネジャーが目標設定後にやるべきこととして次の3つが挙げられています。
- 部下の目標を何回でも読み直す。だが、どの目標も読むのに1分とかからない（本書では、目標は1分間で読めるように書くことを勧めています）。
- 1日のうち、ときどき、1分使って部下の目標達成度合いを調べる。
- そして、部下の行動が目標と合致しているかどうかを調べてみる。
つまりマネジャーにとって重要な仕事は、メンバーの目標の内容、達成度合い、そしてメンバーが目標へと近づく行動をしているかをチェックすることだということです。『1分間マネジャー』の中でわざわざこう書かれているということは、それをしないマネジャーがいかに多いかの証左でもあります。
あなたは定期的に目標を確認していますか？ それだけでなく、自分が日々目標に関連する行動をしているかどうか確認していますか？
進捗確認の方法としてお勧めしたいのが、下図のようなG-POPフォーマットを活用して毎週1回振り返りを行うグループコーチングです（連載第4回参照）。1週間ごとに実行・修正を繰り返すことで、知らず知らずのうちに習慣化することができます。
繰り返しになりますが、ゴールに関連するタスクをしなければゴールにたどり着くことはできません。あなたも自身のゴールを目に付くところに置いて、定期的に確認することをお勧めします。
2. アジャイルで仕事を進める
システム開発の方法のひとつに｢アジャイル開発｣というものがあります。
｢アジャイル開発｣とはその名の通り、アジャイル（俊敏）に開発する方法のこと。｢仕様や設計の変更は当然ある｣という前提に立ち、2週間程度のイテレーション（反復）開発ごとに｢実装→テスト→実装→テスト……｣を繰り返し、徐々に開発を進めていく手法です。
この考え方は、システム開発以外のビジネスパーソンの仕事にも応用できます。
アジャイル開発の最大のメリットは、不具合が発覚しても手戻り工数を最小限に抑えることができる点。また、仕様変更や追加にも柔軟に対応できます。
未来が見通しにくく、変化することが前提で試行錯誤が必要な現在では、組織もこの｢アジャイル｣が求められていることが増えてきているのです。
｢アジャイル開発｣のやり方は次のとおりです。
2週間程度のイテレーションの期間中、現場は自ら判断し開発を進めます。毎朝15分程度、6人前後のチームでスタンドアップ形式でミーティングを行い、状況確認やその日の計画などを共有します。これにより、チームメンバーが今どんなことで困っているかが分かり、支援も可能になるのです。
日次のミーティングの他に、2週間に1度｢ショーウインドウ｣と呼ばれるミーティングも行います。プロジェクトオーナー（発注者、あるいは上司）に開発物を見せ、全員で次の2週間の開発の優先順位を確認するのです。つまりショーウインドウとは、2週間ごとに実行・修正を繰り返す手法といえます。
3. ｢KPT会議｣に一工夫でより効果的に
アジャイル開発では、チーム内で｢KPT（ケプト）｣と呼ばれる会議を行うことがあります。これも有効な方法なのでぜひ覚えてください。
KPTは、Keep（継続）、Problem（問題解決）、Try（挑戦）の頭文字を取ったもの。KPT会議では、2週間（もしくは1週間）ごとに現在やっているタスクを棚卸しして整理するのです。KPTそれぞれの意味合いは次のとおりです。
- Keep（継続）：今のまま継続実施するもの
- Problem（問題解決）：問題が起きているので解決すべきもの
- Try（挑戦）：新たに挑戦すべきもの
実際にKPT会議を実施してみると、案件の対応方法が次々に決まっていくので気持ちがいいものです。気持ちよさに加えて、｢問題解決｣と｢挑戦｣ができることもポイント。実行・修正を具体的に行うにはうってつけの方法なのです。
ただし、一般的なKPT会議には1つ問題があります。Keepは継続実施なのでよいとして、Problem（問題解決）とTry（挑戦）では新たな仕事が増えることになります。
当たり前ですが、人の労働時間には限界があります。KPTをただ続けていくだけだと仕事が増えていき、最終的には破綻してしまいます。これではせっかくの良い方法がもったいない。どうすればよいのでしょう？
そこで｢KPTS（ケプツ）会議｣の登場です。KPTSは、KPTに｢Stop（やめる）｣を加えた私の造語です。KPTに加えて、やめることを決めようということです。
企業の中には、この｢やめること｣だけに絞って｢掃除｣と称している組織もあります。KPTS会議の発想もこれと同様です。定期的に｢掃除｣をすることで、よくよく考えたらこれは不要だと思う業務を整理していきましょう。
こうしてKPTS会議を定期的に行うことで、知らず知らずのうちに｢On（実行・修正）｣の能力が高まっていきます。
4. ｢悪い兆し｣をいち早く察知する
ロバート・キーガンの『なぜ弱さを見せあえる組織が強いのか』を読んだことはありますか？ 400ページを超える大著ですが、プロジェクトマネジメントのスキルを高めるうえでは非常に示唆に富む一冊です。
私は同書の手法を、リクルート時代のスーモカウンター、リクルートテクノロジーズ、リクルートワークス研究所などで活用してきましたが、どこでも効果を発揮しました。その後、多くの経営者にも紹介したところ、ほぼすべての組織で機能した効果検証付きの方法です。
キーガンが著書で示した方法とは、毎週｢悪い兆し（Bad Sign）｣と｢良い兆し（Good Sign）｣を集めるというものです。
マネジメントする側にとって本来一番知りたい情報、知るべき情報とは、要点でも顧客からの褒め言葉でもなく、｢悪い兆し｣です。現場にいる者でなければ気づかない｢悪い兆し｣こそ、いち早くマネジメントに届けてほしいと願うものです。
ただし、マネジメント側は｢悪い兆し｣が欲しいわけですが、それだけをコミュニケーションするとチームに元気が出なくなります。そこで｢良い兆し｣もテーマに入れて、バランスを取るのが1つのコツです。
｢悪い兆し｣に話を戻しましょう。例えば、いつもアポイントが取れていた重要顧客のアポイントが2週間取れない。これは典型的な悪い兆しです。｢新入社員が月曜日に2回遅刻をしてきた｣｢メンバーが『何のために働いているのだろう』とボヤいていた｣などもそう。
こうしたことを｢兆し｣の時点で知ることができれば、とれる対策はいくらでも考えられます。上司や人事が動くこともできるでしょう。しかし｢兆し｣が見えているのに何もせず手をこまねいていると、取れる選択肢がどんどん狭まってしまいます。
他社のサービスに乗り換えようと考えている顧客に、われわれのサービスが改善されることを事前にお伝えできれば乗り換えを止められるかもしれません。しかし、ひとたび乗り換えを決めた後でその決定をひっくり返すのは大きな手間がかかります。
同じく従業員が会社を辞めようと考えている段階であれば、まだ慰留は可能かもしれません。しかし、辞めると決めてからではひっくり返す難易度は一気に上がってしまいます。
｢悪い兆し｣を現場から上げてもらうコツは2つあります。
1つは、｢悪い兆し｣として現場から上がってきたことに対して、マネジメントは絶対に怒らないというルールにすること。マネジメントにしてみれば、もちろん腹が立つこともあるでしょう。｢そんな些細なことは自分で解決してくれ｣と言いたくなることもあります。しかしそこはぐっと我慢して、｢悪い兆しを伝えてくれてありがとう｣と感謝を伝えるのです。
もう1つは、マネジメントのもとへは｢悪い兆し｣として報告されていないにもかかわらず、メンバーが急に辞めると言い出した、大口の取引先が急に他社に乗り換えるなど、悪いことが起きた場合の対応です。
この場合に考えられるのは、リーダーが兆しに気づいていないか、気づいていても報告しなかったかのどちらかです。つまり、｢経営→リーダー→現場メンバー｣向きのパイプ、あるいは｢現場メンバー→リーダー→経営｣向きのパイプのどこかに｢詰まり｣があるということです。
この場合は、｢詰まり｣を掃除して取り除き、今後は兆しの段階で報告が上がってくるように善後策を考える必要があります。
なお、悪い兆しが上に報告されないもうひとつの可能性として、現場やリーダーの怠慢、あるいは｢こんなのは大したことじゃない｣という勘違いが考えられます。これも見つけ次第、きちんと正さなければなりません。
｢悪い兆し｣を把握することは、組織の変化にいち早く気づくことにつながります。悪い兆しをベースに実行・修正の計画を立てることで、まさかの事態を回避することができるのです。
さて、今回は｢実行｣のフェーズで気をつけたいポイントについてお話ししてきました。次回は、リモートワークだからこそ重要な自律自転したOn（実行）についてお話ししたいと思います。
※本連載の第13回は、11月13日（金）を予定しています。
（連載ロゴデザイン・星野美緒、編集・常盤亜由子）
中尾隆一郎：中尾マネジメント研究所代表取締役社長。1989年大阪大学大学院工学研究科修了。リクルート入社。リクルート住まいカンパニー執行役員（事業開発担当）、リクルートテクノロジーズ社長、リクルートワークス研究所副所長などを経て、2019年より現職。株式会社｢旅工房｣社外取締役、株式会社｢LIFULL｣社外取締役も兼任。
