【Facilitation】解けない問題を解ける問題へ変換する
「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」の本で「解けない問題を解ける問題へ変換する」という挿話がある。
ファシリテーションを得意とするコンサルタントが、ある病院にやってくる。
そこでは、医師と事務のお偉方が「前年度よりも20%手術件数を増やす」という課題について議論していた。
しかし、その会議では、医師は忙しいのだ、医師の数が足りないという堂々巡りの議論ばかり。
そこへコンサルタントがひょっこり入ってきて、状況を聞いた後、現在の医師の人数から、手術可能な件数を計算させてみると、あら不思議、かなり余裕がある。
コンサルタントが「医師の時間の使い方を調べて手術に使える時間を20%増やす」へ問題を置き換えると、医師も事務方も途端に積極的な意見が出始めた。
この挿話では、解けない問題を解ける問題へ変換すると、人は自然に解決する方向へ動き出す、というエピソードで括られていた。
この話をシステム開発に置き換えて考えてみる。
【1】課題解決のフレームワークは、目的→課題→アクション
「プロジェクトを成功させる 現場リーダーの「技術」 」の本では、課題解決のフレームワークを「目的→課題→アクション」と言い切っていた。
実際、新規開発での要求の聞き出し、運用保守での課題管理では、このフレームワークが使える。
その時、チームのメンバーが実際に動けるレベルの課題まで落としているか、がポイントになる。
振り返ってみると、自分が所属するシステム開発のチームは、メンバーのスキルは高い。
だから、プロジェクトリーダーが課題をメンバーが作業できるレベルと範囲まで落とせば、少なくとも課題解決までもっていける。
むしろ、個々は小さくとも膨大な量の課題、手に負えないような幅広い課題を、いかに優先順位をつけて、スケジュール化していくか、というプロジェクトマネジメントの能力の方が問われている気がする。
【2】成熟した組織は、自身で問題を定義し、課題を解決する能力を持つ
組織の成熟度という話は、IT業界では、CMMIを連想させる。
CMMIでは下記の5段階が定義されている。
◆レベル1(初期段階)
場当たり的な状態で、決まったプロセスがない
◆レベル2(反復可能な段階)
初歩的管理は行われており、同じようなプロジェクトなら反復できるプロセスがある
◆レベル3(定義された段階)
組織的に定義された標準プロセスがある
◆レベル4(管理された段階)
プロセス・製品の精度、品質を管理し、定量的な分析が行われている状態
◆レベル5(最適化された段階)
プロセス分析からのフィードバックにより、改善が継続的に行われている
「同じような問題(プロジェクト)は解く(管理する)ことができる」レベルは、CMMIレベル2と言える。
「解けない問題を解ける問題へ変換する」を「初めてのプロジェクトでも標準プロセスでコントロールできる」と置き換えるなら、CMMIレベル3と言えるのではなかろうか?
CMMIレベル4は、プロセスの計測可能な指標を組織自身が回収できていること。
つまり、プロセス改善に役立つメトリックス、即ち、プロセスを客観的に評価する基準があることを示す。
このレベルにあると、開発ポートフォリオやROIなど、開発プロセスが上手く行っているか、投資対効果があるか、などを客観的に議論できる。
これらは、ソフトウェア工学の研究対象そのもの。
CMMIレベル5になると、組織自身が自己学習できる状態にあることを示す。
ファシリテーターは、組織やメンバーの問題解決プロセスを支援するが、プロセスのコンテンツにも関わり、学習プロセスにも参加させる役割も担う。
少なくとも、CMMIレベル3以上の組織は、既にプロセスフレームワークが存在する。
そのような組織は、おそらくファシリテーターの役割を担う人は自然にいるはず。
「解けない問題を解ける問題へ変換する」能力は、チーム自身が持っているだろう。
ファシリテーションのゴールは、チーム自身が継続して学習できること、そして、メンバーが自ら問題を解ける課題まで落として、解決していく方向へもっていくことだと言える。
「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」では、「小学生を集めて、いくらファシリテートしても、高校生の問題は解けない。でも解きたいのは高校生の問題」というフレーズがあった。
そんなケースでは、ファシリテーションによって学習する組織へ成長させることはできるのか?
「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」にはその回答らしきものは書かれていたが、曖昧で納得しがたい所があった。
【3】ファシリテーションは、問題解決や課題解決の能力を高める
「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」では、MBAホルダーである深山が、開発ポートフォリオや要素技術マッピングなどのビジネスフレームワークを、彼が所属する研究所のテーマの評価ではなく、研究者と思考を共有化する道具として使って、より良いテーマを企画するファシリテーターに変身していた。
つまり、論理的フレームワークを使って組織の思考プロセスを見える化し共有することで、組織内の意見交換が活発になる方向へ持っていく。
この時、ファシリテーションは、他社とのインタラクティブな関係を補強することに使われている。
「ファシリテーターはチームのプロセス管理者である」という意味は、組織の問題解決プロセスや学習プロセスを方向付ける人がファシリテーターであると言い直せる。
そんなことを考えると、ファシリテーションは会議術の一つだけでなく、チームを問題解決プロセスに巻き込む技術の一つと捉えた方が、その意図がよりはっきりするのではなかろうか?
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
コメント