プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ
随分前だが7月初めにPFP関西WS#19が開かれた。
ワークショップの内容は「ファシグラ」。
【1】ファシグラはファシリテーショングラフィックの略語で、議論の見える化を目的として、A4用紙又は模造紙へプロッキーを使って議論を描いていく手法。
ワークショップでは西河さんの解説がとても分かりやすく、実際に描きながら試すことができた。
議論の内容を議事録にまとめたり、内容をまとめて更に議論を深彫りしていくのは難しい。
議論が白熱すると、あらぬ方向へ議論が行って本来の問題解決につながらなかったりする。
アイデアを出しながら企画を組み立てようにも、アイデアがなかなか出ない雰囲気だったり、アイデアが散発的でつながりが見えにくかったりする。
そんな時にファシグラはすごく有用だ。
僕が改めてファシグラの威力を感じたのは、えと~さんが実際にファシグラを使っている場面を見た時だ。
ミーティングで到達すべきゴールは既にメンバー全員で共有しているが、ゴールにたどり着くまでにどんな議論が必要なのか、見えない状況だった。
そんな時、大量のA4用紙を元に、プロッキーで議論からラフな概念イメージやフローを描いていく。
一人の頭にあるアイデアを紙に書くことで、全員がそのアイデアを共有できるだけでなく、刺激を受けて、更にそのアイデアを補強したり膨らませることができる。
えと~さんも言っていたが、ファシグラをやると、自然に「問題 vs 私たち」という構造になる。
つまり、問題がファシグラで描いた紙に書かれていくから、メンバー全員がその紙を見ながら、問題点を探るので、同じベクトルへメンバー全員が自然に向くようになる。
更にファシグラの利点は、ファシグラで描いた紙を組み合わせると、紙芝居になることだ。
例えば、10枚描いたファシグラのA4用紙をあるストーリーの元に並べれば、自然にプレゼン資料になりうる。
つまり、ミーティングの終わりに、一つのプレゼン資料が出来上がるため、それをPoerPointへデジタル化すればいいだけになる。
【2】ファシグラだけでなく、タスクかんばんなどプロジェクトファシリテーションのツールは非常に面白い。
だが、最近思うのは、プロジェクトファシリテーションはIT企業の中間管理職研修で使われる内容と一致するような気がする。
実際、IT企業の中間管理職研修では、チームビルディングを主体としたワークショップ形式が主流だ。
理由は、実際の開発現場では、現場リーダーの必須技術の一つが、寄せ集めの開発者たちをすぐにチームとして機能させることだからだ。
最近のソフトウェア開発は、プロジェクト単位にメンバーを集めて、短い期間で開発していく。
しかもそのメンバーは自社とは限らず、他の会社の見知らぬ開発者と組んでいる時が殆どだろう。
その初対面のメンバーとすぐに信頼関係を築き、チーム内の役割のバランスをすぐに作るというチームビルディングの技術が重要になって来る。
特に、最近のWebシステム開発はメンバーの出入りが激しいため、チームビルディングを上手に機能させないと、チームが機能しないだけでなく、開発プロセスの品質が下がり、最終的にはシステムの品質にも響く。
このファシリテーションの技術は、リーダー特有の資質や経験に依存するものと従来は考えられていたが、最近は、意識的に育成できる技術の一つと捕らえる傾向にある。
そのファシリテーションの技術をIT業界に特化させたものが、プロジェクトファシリテーションと言えると思う。
数年前からアジャイル開発からプロジェクトファシリテーションへトレンドが移りつつある理由は、プロジェクトファシリテーションのマーケットが発見されたからだと思う。
そのマーケットこそが、IT企業の中間管理職、つまり現場リーダーなのだと思う。
だから、開発チームを統率し、システム開発というプロジェクトをやり遂げる役割でなければ、プロジェクトファシリテーションの発想は響きにくいかもしれない。
逆に言えば、チームビルディングが必要な人には、喉から手が出るほど、アイデア豊富な技術が揃っているため、非常に面白いと思う。
【3】アジャイル開発を実践しているチームならば、リリース計画やイテレーション計画を作る時や、イテレーションの開始・実行中・終了後にプロジェクトファシリテーションのプラクティスを使うと、効果的だと思う。
少なくとも、朝会やふりかえりは、アジャイル開発とすごく相性がいい。
もちろん、チケット駆動開発とも相性はよい。
例えば、タスクかんばんは、チケット駆動開発では作業ステータス毎のチケット一覧でデジタル化できる。
バーンダウンチャートは、チケット駆動開発ならば、イテレーション単位の残チケットの集計結果でデジタル化できる。
チケット駆動開発は、プロジェクトファシリテーションをデジタル化するツールと捉え直すこともできるだろう。
そのアイデアも考えてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
「Redmine」カテゴリの記事
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
「ソフトウェア工学」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
「プロジェクトファシリテーション」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 「世界を動かすプロジェクトマネジメントの教科書」の概念図(2022.01.16)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- 昭和の管理者の承認処理は判子押印、令和の管理者の承認処理はいいねボタンを押すこと(2021.12.31)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
「チケット駆動開発」カテゴリの記事
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
コメント