プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ
随分前だが7月初めにPFP関西WS#19が開かれた。
ワークショップの内容は「ファシグラ」。
【1】ファシグラはファシリテーショングラフィックの略語で、議論の見える化を目的として、A4用紙又は模造紙へプロッキーを使って議論を描いていく手法。
ワークショップでは西河さんの解説がとても分かりやすく、実際に描きながら試すことができた。
議論の内容を議事録にまとめたり、内容をまとめて更に議論を深彫りしていくのは難しい。
議論が白熱すると、あらぬ方向へ議論が行って本来の問題解決につながらなかったりする。
アイデアを出しながら企画を組み立てようにも、アイデアがなかなか出ない雰囲気だったり、アイデアが散発的でつながりが見えにくかったりする。
そんな時にファシグラはすごく有用だ。
僕が改めてファシグラの威力を感じたのは、えと~さんが実際にファシグラを使っている場面を見た時だ。
ミーティングで到達すべきゴールは既にメンバー全員で共有しているが、ゴールにたどり着くまでにどんな議論が必要なのか、見えない状況だった。
そんな時、大量のA4用紙を元に、プロッキーで議論からラフな概念イメージやフローを描いていく。
一人の頭にあるアイデアを紙に書くことで、全員がそのアイデアを共有できるだけでなく、刺激を受けて、更にそのアイデアを補強したり膨らませることができる。
えと~さんも言っていたが、ファシグラをやると、自然に「問題 vs 私たち」という構造になる。
つまり、問題がファシグラで描いた紙に書かれていくから、メンバー全員がその紙を見ながら、問題点を探るので、同じベクトルへメンバー全員が自然に向くようになる。
更にファシグラの利点は、ファシグラで描いた紙を組み合わせると、紙芝居になることだ。
例えば、10枚描いたファシグラのA4用紙をあるストーリーの元に並べれば、自然にプレゼン資料になりうる。
つまり、ミーティングの終わりに、一つのプレゼン資料が出来上がるため、それをPoerPointへデジタル化すればいいだけになる。
【2】ファシグラだけでなく、タスクかんばんなどプロジェクトファシリテーションのツールは非常に面白い。
だが、最近思うのは、プロジェクトファシリテーションはIT企業の中間管理職研修で使われる内容と一致するような気がする。
実際、IT企業の中間管理職研修では、チームビルディングを主体としたワークショップ形式が主流だ。
理由は、実際の開発現場では、現場リーダーの必須技術の一つが、寄せ集めの開発者たちをすぐにチームとして機能させることだからだ。
最近のソフトウェア開発は、プロジェクト単位にメンバーを集めて、短い期間で開発していく。
しかもそのメンバーは自社とは限らず、他の会社の見知らぬ開発者と組んでいる時が殆どだろう。
その初対面のメンバーとすぐに信頼関係を築き、チーム内の役割のバランスをすぐに作るというチームビルディングの技術が重要になって来る。
特に、最近のWebシステム開発はメンバーの出入りが激しいため、チームビルディングを上手に機能させないと、チームが機能しないだけでなく、開発プロセスの品質が下がり、最終的にはシステムの品質にも響く。
このファシリテーションの技術は、リーダー特有の資質や経験に依存するものと従来は考えられていたが、最近は、意識的に育成できる技術の一つと捕らえる傾向にある。
そのファシリテーションの技術をIT業界に特化させたものが、プロジェクトファシリテーションと言えると思う。
数年前からアジャイル開発からプロジェクトファシリテーションへトレンドが移りつつある理由は、プロジェクトファシリテーションのマーケットが発見されたからだと思う。
そのマーケットこそが、IT企業の中間管理職、つまり現場リーダーなのだと思う。
だから、開発チームを統率し、システム開発というプロジェクトをやり遂げる役割でなければ、プロジェクトファシリテーションの発想は響きにくいかもしれない。
逆に言えば、チームビルディングが必要な人には、喉から手が出るほど、アイデア豊富な技術が揃っているため、非常に面白いと思う。
【3】アジャイル開発を実践しているチームならば、リリース計画やイテレーション計画を作る時や、イテレーションの開始・実行中・終了後にプロジェクトファシリテーションのプラクティスを使うと、効果的だと思う。
少なくとも、朝会やふりかえりは、アジャイル開発とすごく相性がいい。
もちろん、チケット駆動開発とも相性はよい。
例えば、タスクかんばんは、チケット駆動開発では作業ステータス毎のチケット一覧でデジタル化できる。
バーンダウンチャートは、チケット駆動開発ならば、イテレーション単位の残チケットの集計結果でデジタル化できる。
チケット駆動開発は、プロジェクトファシリテーションをデジタル化するツールと捉え直すこともできるだろう。
そのアイデアも考えてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある(2020.12.11)
「Redmine」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
- PMO観点でRedmineの使い方とは何か(2020.12.20)
- 若手プロジェクトリーダー向けのRedmine教育資料の構想(2020.12.24)
「ソフトウェア工学」カテゴリの記事
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
- なぜなぜ分析、FMEA、FTAの違い(2020.06.09)
「プロジェクトファシリテーション」カテゴリの記事
- みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない(2021.01.14)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 「チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ」の感想(2020.08.14)
- オンライン勉強会のノウハウのリンク(2020.05.17)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
コメント