SIMPLE フレームワークの使用
学習の目的
この単元を完了すると、次のことができるようになります。
- 他者に説明責任を課す方法を特定する。
- 説明責任を維持するプロセスを使用する。
SIMPLE
S = Set Expectations (期待の設定)
信号がなければどうなると思いますか? 誰に優先通行権があるかを皆わきまえているので、何とかなるだろうと思いますか? 運転手が窓を開け、次に誰が進むかで怒鳴り合い、遊園地のバンパーカーを上回る数の衝突事故を起こすことでしょう。
職場でも同じです。期限や期待が明確でなければ、混乱や過誤が多発します。状況確認やプロジェクトのマイルストーンは、業務がチェックされないまま間違った方向に突き進んでいかないようにするための赤信号です。進路から何キロも逸脱した地点で、出発地よりも目的地から遠ざかっていることに気付いたときの落胆は計り知れません。
担当業務に対する期待を設定するときは、その形式と期待される結果をきわめて明確にしておきます。期限の直前に驚愕するようなことはしたくありません。明確にしておくというのは「では、来週木曜日の午後 5 時までに、最終案を Google ドキュメント経由で送信してもらうということでいいですね。問題が生じたときの対処法も確認しておきましょう。」といった言葉を意味します。
以下をクリックして、Kris や Ansar が、チームを前進させ続けるため、チームに日常レベルあるはキャリアレベルの期待をどのように設定しているのかをお聞きください。
大したことではないような気がするかもしれませんが、前もって同僚とこうしたを会話をしておけば、時間の節約になるほか、誤解を回避できます。そして、最終成果物の内容と受け取る時期および方法が明確になります。
I = Invite Commitment (コミットメントの取り付け)
明確で実行可能な期待を伝えたら、次は、業務遂行のタイムライン、コミットメント、計画について全員から承認を取り付けます。忘れられがちながら重要な点は、エスカレーションのタイムラインについても認識を一致させておくことです。なぜそう思ったのですか? SOS を発信すべきレベルの問題に対して同僚とあなたとの間に相違があると、助けを求めたられたときにはすでに手遅れである可能性があります。
タイタニック号のような惨事を防ぐために、以下の事項に合意しておきましょう。
|
取り決め事項 |
相手へのアプローチ |
|---|---|
| 状況確認日 |
週に 1 回は進捗を確認したいのですが、問題ありませんか? |
| 障害 |
どのような障害によって進行が妨げられる可能性があると思いますか? 予め対処するにはどうすればよいですか? |
| 連携性 |
他には誰がこのプロジェクトに関与していますか? 他の関与者と目標やタイムラインの認識を統一させるにはどうすればよいでしょうか? |
| 危険信号 |
どのような場合にタイムラインを戻る必要があると思いますか? |
| ゴールライン |
目標完了日はいつですか? |
上記の点に対する認識を統一しておけば、誤解が軽減し、両者が期限に余裕をもって対応して、質の高い仕事を仕上げることができます。ただし、期限を一方的に指定してはいけません。実行計画を取り決める前に期限をいつにするべきかチームの意見を聞くようにします。なぜそう思ったのですか? そうしたやり取りによって、業務の期間や難易度、重要度に対するあなたの考えとチームの考えとのが明らかになるからです。これが職場の掃海艇となります。チームが業務を開始する前に惨事の火種を見つけることができるのです。
素晴らしいですよね! スタート、コース、ゴールが定義されたところで、次の疑問は、進行状況を示すにはどうすればよいのかということです。これはいい質問です。必要に応じて、説明責任および委任パックの Inviting Commitment Exercise (コミットメントの取り付け演習) をダウンロードしてください。
M = Measure Progress (進行状況の測定)
「測定できるものは管理できる。」1500 年代の数学者 Georg Rheticus (コペルニクスの友人) が記したこの原則は、レポートの進行状況を評価する理由にも適用されます。当社では結果を報告する場合、進歩だけでなく、注意を要する点や成長機会も明示します。起業家であり実業界の大物でもある Bill Gates は、医療、技術、教育、ビジネスの分野で、数百万ドルに値する技術革新を実現できたのも測定に重きを置いていたからです。説得力がありますよね?
ビジネスごとに成功を測定する手法は異なります。重要業績評価指標 (KPI) を採用しているところもあれば、チームに進歩に対する説明責任を課す目的で目標と主要な結果 (OKR) を選択しているところもあります。Salesforce では、こうした手法をもう一段階引き上げています。
当社の手法は、従業員の Vision (ビジョン)、Value (価値)、Methods (メソッド)、Obstacle (障害)、Measures (測定) をまとめた V2MOM に着目し、認識の統一、大局的な思考、進歩の測定、各々の説明責任を推進しています。事業計画および目標設定のこうした活力的なプロセスによって、あなたの達成目標やその実践方法が、同僚やマネージャーのみならず社内の全員に示されます。この手法では、社内で出会った誰もが数回クリックするだけで、あなたの当年の最大のチャレンジ目標やビジョンを知ることできるため、説明責任と透明性の両方が増大します。
進行中のプロジェクトの状況やキャリア目標を評価する場合は、1 対 1 の面談も優れた方法です。実際、部下に説明責任を課すことによってエンゲージメントも高まります。
たとえば、年度の初め、部下にストレッチ目標を書き出すように指示するとします。月に 1 回部下の進歩を確認すれば、部下はあなたから気にかけてもらい、キャリア面での成長が測られていると実感します。これは、もう少しで手が届きそうなものに向かってジャンプしようとしている人に、梯子を差し出すようなものです。部下の成長を可能にし、促進し、容易にします。部下は業務を速やかに完遂できるだけでなく、完遂したことに満足感を抱きます。
部下から口うるさい管理主義者と思われることなく、その進歩を測定するにはどうすればいいかと思っているかもしれません。ここで登場するのがテクノロジーです。クラウドベースのソフトウェア、スプレッドシート、プロジェクト管理ソフトウェア、そしてダッシュボードスタイルの無数の追跡機能を駆使すれば、進歩レポートを作成するためにいちいち部下を煩わせることなく、各人の進歩を完全に掌握することができます。そして、Kris が次の動画で述べているとおり、最も優秀な従業員は説明責任の概念を言わずとも心得ています。
この様子を具体的に見てましょう。Ankar は営業チームのマネージャーです。中堅のアカウントエグゼクティブである John に、重要な案件の成立を任せることにしました。John は今回初めて単独で取引先を担当することになります。不安もありましたが、自力でやり遂げようと心に決めていました。Ankar も多忙を極めていたため、時間的な負担が 1 つ減ってホッとしていました。
週の終わりに Ankar が John と 1 対 1 のミーティングを行い、パイプラインの進行状況について報告を求めたところ、John は突然泣き出します。重要なクライアントにどのように切り込めばいいのかわからなかった John は、相手に連絡することもせず、また Ankar にも助けを求めずにいました。クライアントは顧客対応のひどさに憤慨し、取引を止めてしまいます。
Ankar は、John とこの重要な案件をどのようにサポートすればよかったのでしょうか? 案件の喪失につながった要因を調べてみましょう。
- 経験値 — John は単独でこのような案件に取り組んだことがなかったため、Ankar は、指示を与え、質問に答えることができるパートナーやアドバイザーを指定することができたはずです。
- 状況確認の頻度 — Ankar は、業務を割り当ててから状況を確認するまで丸 1 週間やり過ごすのではなく、John の行動をダッシュボードで監視することができたはずです。毎日状況をメールするか、送信メールを CC するよう指示することも考えられます。
- 報告 — Ankar は、John が自身の進行状況を測定し、取引の過程で必要となりうるアクションを検討するために、手段を設定することができたはずです。
丁度いいことに、Salesforce にはこのためのツールが用意されています。Ankar は進行状況を測定する手段がなかっため、五里霧中の John を放置してしまいました。前進するためには測定が大切であることがわかったところで、フィードバックによって測定の効果が一層高まることを見ていきましょう。
P = Provide Feedback (フィードバックの実施)
フィードバックは不当な非難を受けています。歯医者になかなか行く気がしないのと同様に、同僚間でのフィードバックも必要ではあるものの気まずいやりとりになると思われています。実際には、フィードバックの苦痛の原因は、その内容ではなく実施方法です。ここで、有益なフィードバックでも不適切なタイミングで行われれば有害になる様子を見てみましょう。
Toni の従業員である Keisha がレポートの期限に間に合わせることができず、Toni は新規のクライアントに未完成のレポートを提示するしかありませんでした。1 週間後、クライアントが自社から離れていったことを知った Toni は、Keisha のデスクのそばを通りかかったときに「Keisha、言わせてもらうけど、ここ最近のあなたの仕事振りはひどいわね。何があったのか知らないけれど、ちゃんとやってもらわないと困るのよ。」と言います。この突然のフィードバックは Keisha にとっては青天の霹靂でした。Keisha は社内での自身の将来に不安を募らせます。
不十分と思われる仕事の出来に Toni が憤るのはもっともですが、そのフィードバックは唐突で、実際の問題点に対処しておらず、その問題の結果どうなったのかも言及していません。まずいですね。
Salesforce では、Situation (状況)、Behavior (行動)、Impact (影響) を特定する SBI モデルに基づいて、フィードバックを適切なタイミングかつ建設的な方法で実施する文化を構築しています。「フィードバックの文化」モジュールに各要素が詳述されていますが、要約すると状況、具体的な詳細、影響の説明を示し、フィードバックの受け手が反応できるようにするということです。
もしも Toni が SBI モデルに従っていたならば、フィードバックは「Keisha、先週の火曜日に送ってくれたプレゼンテーションにはタイプミスや書式エラーがいくつもありました。書式が見づらかったために、クライアントが要点を把握できなかったのではないかと懸念しています。残念ながら、クライアントが当社と取引しないことにした理由の一端は、あのプレゼンテーションにあったと思われます。」というようなものになるでしょう。
会話が終わると、Keisha は自身の将来を悲観して落ち込むのではなく、何が起こったのかを客観的に理解し、どの点を改善するべきなのかを明確に把握できました。
これで、自身の考えをまとめて、チームに説明責任を課すようなフィードバックに変換する方法のフレームワークを身に付けることができました。けれども、従業員のスキルレベルや経験がばらばらな場合はどうでしょうか? また、規模や重要性が異なるプロジェクトにチームで対応している場合はどうでしょうか? チームにいつも同じように説明責任を課しますか?
ここで、厨房の場合を検討してみましょう。料理長の Jo はディナータイムの作業を助手に伝える際、スタッフの経験値、ディナーの重要性、予想される顧客数を基にアプローチを変えています。
厨房に何人も新人がいる場合は、実践的な指導を行い、積極的なフィードバックを頻繁に与えます。相手の包丁を取って、人参を厳密にどのくらいの大きさの角切りにし、ズッキーニをどの程度薄く切って欲しいのかを実際にやってみることもあります。
他方、経験豊富なチームメイトには作業の大半を任せ、Jo は一品ごとに品質を確認します。Jo は、この人たちの場合手を出し過ぎると気分を害することを心得ています。様子を見ながら励ましの言葉をかけ、建設的なフィードバックを与えます。それでも、このレベルの熟達者であれば、自分はサービスの他の部分に専念しても大丈夫であると確信しています。どちらのチームも同じように説明責任が課されますが、フィードバックの頻度が大きく異なります。
たとえば、レストランで国家の元首や要人が参列する 200 名規模の結婚式が催されるときであれば、料理長は通常の火曜日のディナータイムよりも高頻度でチームに状況確認を行うのではないでしょうか? これは間違いないですよね。
同様に、プロジェクトの結果が大勢の利害関係者に影響するときは高い頻度で状況確認することが、チームをサポートして成功させるために必要なレベルの説明責任であると考えられます。
Jo の場合と同様に、説明責任の向上につながるフィードバックを行うときは、次の点を考慮します。
| 経験 |
プロジェクトに携わる部下が新人または未経験者である場合は、極めて指導的なフィードバックを頻繁に与えます。 部下が経験者である場合は、レベルの高い提案やガイダンスが好まれます。 |
| プロジェクトの重要性 |
極めて重要な業務で注目度が高い場合は、頻繁なフィードバックが推奨されます。 優先度の低いプロジェクトでは、前回から次回の状況確認の間に部下がより多くのリスクを引き受けて、自身でプロジェクトを進行し、次の大きな目標に挑むモチベーションを高めるようにします。 |
| 頻度 |
日、週、数週、月に 1 回の定期的な状況確認を確立し、部下があなたからいつ助言が受けられるのかを認識できるようにします。 |
| スタイル |
部下は、直接編集、メール、対面のどの形式のフィードバックによく反応しますか? 相手の学習スタイルに応じたスタイルでフィードバックを実施すれば、好意的に受け止められ、理解される可能性が高くなります。 |
Ansar によると、チームのメンバーごとに個性やスタイルが異なるため、仕事上の最適な対応方法を見極めることは、マネージャーの最も困難かつ重要な役割の 1 つであるということです。
フィードバックが思いやりをもって率直にやりとりされれば、部下はその最初の試行が、あなたの助言を受けて最終成果物に磨き上げられると感じます。
L = Link to Consequences (帰結を示す)
最終成果物が話題に上がったところで、帰結についても説明しておきましょう。帰結というな何だか嫌な感じがしますが、仕事では自らの行為の影響を理解することが不可欠です (もちろん、実生活でもそうですが……)。
部下の Nancy が社内の四半期レビューの前夜に中途半端なプレゼンテーションを提出します。あなたは徹夜で手直しをしたため、午前 8 時の会議では頭が働きませんでした。自分の仕事の質がプレゼンテーションにどのように影響したのかを知らされなければ、Nancy は仕事への取り組みを改めることができません。
話し合うことは、失敗から学び改善させる最良の方法です。とは言っても、説明責任と帰結についてチームを咎めたところで、パフォーマンス向上のモチベーションは上がりません。社会人として、同僚やリーダーには敬意をもって誠実なコミュニケーションを図ることを求めます。相手を怒鳴りつければ、間違いなく従業員は最高の仕事を成し遂げる意欲を失います。
では、帰結についての話し方の例をいくつか見てみましょう。
|
適切な言い方 |
すべきではないこと |
|---|---|
| 「昨日提出してもらったプレゼンテーションについてちょっと話があります。最終版と思っていましたが、タイプミスや書式エラーがたくさんありました。 あなたの仕事はこのグループを代表するものです。あなたも私もチームを成功させたいと思っているはずです。次回は同じ認識で取り組めるように、今回のプレゼンテーションについてどのように考えていたのか聞かせてもらえますか?」 |
「あんな中途半端なクズを提出するなんて信じられません。徹夜してやり直さなければならず、翌朝のプレゼンテーション時はぐったりでした。次回はもっとちゃんとしたものを提出してください。」 |
| 「レポートを受け取りました。ありがとう。あのレポートについては昨日の朝に送ってもらうことを確認していました。そのため、タイムラインに対するあなたの考えについて話したいと思います。何かと用事が重なることは理解していますが、今後の進め方について話し合いましょう。」 |
「期限を過ぎていました。遅れることを知らせもしないなんて信じられません。」 |
従業員によるチームや会社への影響を強調すれば、担当業務の目的に対する認識が植え付けられます。自らの行為にどのようなマクロ的影響があるのかはなかなか認識できるものではありません。どのようにして公害が生じるかを考えてみるとよいでしょう。窓からペットボトルを 1 本投げ捨てたところで大事には至らないと思うかもしれませんが、大勢の人が同じように考えれば生態系が破壊されます。同僚の取り組みの影響を測定すれば、その業務、プロジェクト、目標のそれぞれがチームおよび会社の成功にどれだけ貢献するのかを確認できます。
E = Evaluate Effectiveness (効率性の評価)
評価の結果はどうでしたか? 部下にどのように説明責任を課すか、および部下に説明責任を課した場合に部下のパフォーマンスがどうなるかを考えれば、一貫性のある効率的な業務遂行プロセスを確立できます。あまり面白味のないことのように思えますが、これはチームの成長に向けた大きなステップです。
次回部下と 1 対 1 で話をする際は、説明責任が課されたときにどのように感じたかを尋ね、頻度やスタイルが機能したかどうかも確認します。率直かつ協力的な調子で臨めば、部下も安心してあなたにフィードバックを与えることができます。
相手への質問:
- 前回のプロジェクトでは (日、週、月に 1 回) 状況を確認していました。あなたにとってはどうでしたか?
- メールやメッセージでの現況報告やリマインダーや、直接話をすることで、どのくらいサポートされていると感じましたか?
- 経験豊富なチームメンバーと一緒に仕事をすることについて、どのように感じていましたか?
- プロジェクトの期限が近づいてきたときに、どのように感じたか聞かせてください。どのような点を変えれば、プロジェクトのタイムラインに従いやすくなると思いますか?
説明責任に対するあなたのアプローチをチームが理解すれば、チームは各自の努力をきちんと認めてくれる人がいると考え、各自および仕事に対して高い基準を掲げるようになります。この点を念頭に置いて、基準および期待を定めた後に説明責任を維持する方法を見ていきましょう。必要に応じて、説明責任および委任パックの SIMPLE in Action (SIMPLE の実践) をダウンロードしてください。
説明責任の維持
では、説明責任に対する期待を定めたら、お終いでしょうか? そういうわけにはいきません。次に、期待の設定と同じぐらい重要なこととして、順調な業務進行について考慮します。システムを設定する以前に、確立したシステムを維持する方法を認識しておく必要があります。
サッカーの試合途中で、足だけでなく手を使ってもよいと審判が言ったら、どうなると思いますか? 試合を進める審判の能力を選手が信頼しなくなるだけでなく、サッカーではなります。
同様に、説明責任の基準を変更すれば、部下があなたの言葉 (あるいはあなた自身) が本気かどうかわからなくなります。以下は、あなたが努力して確立した基準を維持する方法を示しています。
- Set expectations (期待の設定) — あなたが状況確認する時点、および過程の各段階であなたが求める内容を部下に知らせます。
- Check-in (状況確認) — 毎日のメールでも毎週の 1 対 1 のミーティングでも、業務を割り当てたときに合意したスタイルおよび形態を維持します。
- Assess (評価) — スケジュールおよび目標に沿っているか? 沿っている場合は、予定されている次回の状況確認時まで計画どおり進めます。沿っていない場合は、ステップ 4 に進みます。
- Swarm (協力体制) — 順調に進んでいない場合は、余裕のあるチームメイトに業務を振り分け、あなたの期待と現時点までの進行状況のギャップを縮めます。「人手が多ければ仕事は楽になる」ということわざを実践します。
- Analyze (分析) — 部下と協力して、コミュニケーションや期待にギャップが生じている箇所を掌握します。
- Move forward (前進) — 部下の仕事の帰結をグループへの影響や組織全体と結び付けます。部下に学んだ教訓を次の業務に活かし、認識を一致させるように指示します。
以上の頭文字を取って SCASAM と覚えましょう。これを実践することで、魔法のような成果を生み出します。説明責任の基準の説明としては若干大げさかもしれませんが、このプロセスを説明責任戦略の中核に据えれば、プロジェクトを順調に進めることができます。
説明責任の文化を構築することで、部下が互いに説明責任を果たすようになるでしょう。たとえば、財務マネージャーの Takeda が 6 人の部下と当四半期の結果に対する各自の貢献を発表するミーティングをしているとします。部下の Jon がデータを発表しているときに、チームメイトの Jorge が数か所の計算間違いを指摘します。
「普通」であれば、Jon は攻撃されたと感じて、このフィードバックを前向きに受け取らない可能性があります。一方で、Takeda が推進してきた、相互的な説明責任と信頼を育む環境であれば、チームは気兼ねなくフィードバックをやり取りできます。Jon は Jorge のフィードバックに感謝し、ミーティングの最後に次回のプレゼンテーションではこのような間違いはしないと約束しました。調査でも、最も影響力のあるチームは速やかに説明責任行動を取ることが示されてます。間違いの発見からその善処を明言するまでの時間が短いほど、より多くの成功を収めるようになります。
Jon と Takeda の次回の 1 対 1 のミーティングで、Jon は躊躇うことなく以前に犯した間違いと、その後どのように修正して以前のデータセットを改良したかについて話し合うことができます。会話は双方向であるため、Jon は自己認識と向上への意欲を示すことができます。Takeda の役割は、協力的な姿勢で傾聴することです。そして、これが説明責任の魔法なのです!
まとめ
同僚に説明責任を課すということは、同僚が明確で測定可能な目標に向かって取り組み、成果を挙げられるようにすることです。必ずしも容易なことではありませんが、チームの目標の拡大や複雑化に伴い、説明責任の強化が成功にとって極めて重要になってきます。
目標が拡大し複雑になれば、誰一人として単独で業務を成し遂げることはできません。チームの業務範囲や影響の拡大を望むのであれば、部下に責任を委任し、説明責任を課す必要があります。ということで、次の単元をあなたに委任して説明責任を課し、うまくいけば次のバッチを獲得できるようにするというのはどうでしょう?
