ITエンジニアへの5分間キャリア・コンサルティングやってます!

第738回 前提構造理論(OST)のススメ17・補足6 ケーススタディ

»

 こんにちは、キャリアコンサルタント高橋です。

 OSTのススメも17回めですね。今回はOSTが実際のどのようなシーンで活用できるのか、ケーススタディとして簡単にご紹介したいと思います。

■ケーススタディの内容

 このケーススタディはOSTを実践するために作成したリファレンスマニュアルから持ってきています。OSTを実際に活用するシーンというのは、介入部にあたるのですが、それぞれC介入、A介入、R介入について個人、組織のケースについてご紹介しています。

 それぞれの介入については、以下のコラムをご参照ください。

 C介入...第730回 前提構造理論(OST)のススメ9・介入部2 C介入(CUP)
 A介入...第731回 前提構造理論(OST)のススメ10・介入部3 A介入(TVD)
 R介入...第732回 前提構造理論(OST)のススメ11・介入部4 R介入(REP)

■ C介入(CUP)のケース

①個人のケース
困っている状態:
仕事でミスをするたびにひどく落ち込み、新しいプロジェクトや少し難易度の高い仕事への挑戦を無意識に避けてしまう

CUPによる解決への流れ
StepA:C3の特定
介入者の問いかけにより、「今回のミスの原因(Cause)は、すべて自分の能力不足だ」と思い込んでいる前提を、評価を交えずに客観的な事実として書き出します

StepB:一点特定
本人の判断を最も狭めている「原因(Cause)の捉え方」を、今回アップデートするターゲットとして一つだけ選びます

StepC:一点更新
「能力不足」という枠組みの横に、「今回は初めての環境だった」「情報が足りていなかった」など、能力以外の可能性(環境要因や経験要因)をそっと並べてみます。無理にポジティブにするのではなく、「別の見方もあり得る」という余地を作ります

StepD:再選択
新しい選択肢が見えたことで、本人は無理なく「今回は経験の条件が合わなかっただけだから、次は少し準備期間をもらって試そう」と、自分自身で新しい結論を選び直すことができます

②組織のケース
困っている状態:
営業と開発が会議の度に対立し、意見がまとまらずに決裂してしまう

CUPによる解決への流れ:
StepA:C3の特定
会議での発言を振り返り、両部門が「自分たちの部署の利益や都合」という狭い範囲(Context)だけで状況を見て意思決定していることを確認し、言語化します

StepB:一点特定
組織の判断を対立させている最大のバグである「狭い視野(Context)」を、今回のアップデート対象に決定します

StepC:一点更新
「営業 vs 開発」という対立構造の枠を外し、判断の視野に「顧客視点」という共通の範囲を仮置きし、今までの前提が唯一ではないことを可視化します。「この件は、顧客にとってはどちらが良いか?」という問いを立てます

StepD:再選択
「顧客視点」という新しい前提が追加されたことで、部門の意地を張り合うのではなく、「顧客に価値を届けるためにはどうすべきか」という共通の基準で、組織としての新しい結論を導き出します

■A介入(TVD)のケース

①個人のケース
困っている状態:
本来やるべき重要なタスクがあるのに、目の前のメール返信や雑務など、次々とやってくる緊急の対応ばかりに追われて一日が終わってしまう

TVDによる解決への流れ:
StepA:ASの可視化
現在抱えているタスクを全て書き出し、「価値があるか(ON/OFF)」「今すぐやらなきゃいけないか(ON/OFF)」を判定して、行動ポジションマップ上に並べます

StepB:偏りの一点特定
重要タスクが「いつかやればいい(時間依存性がOFF)」となっているため、次々とやってくる雑務に押し退けられているという偏りを見つけます

StepC:一点再設計
重要タスクの「時間依存性」の前提条件を再設計するため、「毎週〇曜日の朝一番に、進捗を上司に10分だけ報告する」といった公式な締め切り(仕組み)をカレンダーに設定します

StepD:再配置
締め切りという圧力が生まれたことで、気合や根性に頼らなくても、重要タスクが雑務よりも「自然と前に出る」ようになり、スケジュールの優先順位が新しく組み替わります

②組織のケース
困っている状態:
トラブル対応が常に最優先され、組織の未来を作るための「予防活動」や「長期施策」に全く時間が使われない

TVDによる解決への流れ:
StepA:ASの可視化
組織の活動を洗い出し、予防活動が「組織としての価値は高いが、時間的な焦りが全くない」状態に置かれていることを確認します

StepB:偏りの一点特定
予防活動に「今すぐやらなきゃ」という時間的圧力がかかっていないという構造上のバグを特定します

StepC:一点再設計
予防活動を後回しにできない仕組みを作ります。例えば、「システムに特定のアラートが出たら、自動的に担当者の予定がブロックされ、〇時間以内に予防チェックを行うルール」を組み込みます

StepD:再配置
現場に「もっと予防活動を頑張れ!」と号令をかけなくても、仕組みによって予防型行動が自動的に優先タスクとして割り当てられ、組織の活動が自然と再配置されます

■R介入(REP)のケース

①個人のケース
困っている状態:
仕事でミスが起きると、ひどく落ち込むか、環境のせいだと言い訳をして終わってしまい、後日また同じようなミスを繰り返してしまう

REPによる解決への流れ:
StepA:結果の事柄化
起きたミスから「自分がダメだ」「あいつが悪い」といった感情や言い訳を全て排除し、「〇月〇日に、この手順でエラーが起きた」という純粋な事実(事柄)だけを書き出します

StepB:一点抽出
その事実の中から、「ここのルールを変えれば次回は防げる」というアップデートの材料を一つだけ選び出します

StepC:OA点検
せっかくの発見が「今回は運が悪かっただけだ」などの言い訳に流されて消えてしまわないよう、回収ルートにバグがないかを点検します

StepD:次Cへの引き渡し
抽出した前提ルールのバグを、次回似たような仕事をする時の「新しい判断のルールづくり(CUP)」に直接結びつけて、失敗を確実な学びに変えます

②組織のケース
困っている状態:
会議が売上などの数字報告だけで終わり、未達の場合は「誰の責任か」という犯人探しになってしまう

REPによる解決への流れ:
StepA:結果の事柄化
数字の未達に対して、評価したり誰かを責めたりすることを会議のルールで禁止し、「いつ、どれくらい未達だったか」という起きた事実のみを確定させます

StepB:一点抽出
未達という結果から、組織のやり方やルールを変えるためのヒントを一つだけ抽出します

StepC:OA点検
結果が「営業の頑張り不足」といった精神論で処理され、個人の人事評価のマイナスとして消費されてしまわないよう、客観的に点検します

StepD:次Cへの引き渡し
「なぜその数字になったのか」という組織の前提ルールのバグを、次回の経営会議での具体的な議題(組織CUPのアップデートテーマ)として引き渡し、会議を「犯人探し」から「OSを更新する場」へと変えます

■介入のコツ

 このようにOSTを活用することで個人、組織を問わず様々なシーンでの問題に対処できるようになります。

 ただし、介入には明確なルールが存在しています。

相手(または自分)の考えや行動を、無理やり直接変えようとしないこと
前提条件にアプローチすることで、自然にアップデートされる条件を整えること

これが、すべてのプログラムに共通するアプローチです。このようにOSTでは起こっている出来事を変えようとするのではなく、その元になっている前提構造にアプローチをすることで自然と問題を解決するようにしていこうというモノです。

 こうすることで場当たり的な対応ではなく、本質的に問題や課題を解決するような仕組みになっています。

Comment(0)

コメント

コメントを投稿する