プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ
随分前だが7月初めにPFP関西WS#19が開かれた。
ワークショップの内容は「ファシグラ」。
【1】ファシグラはファシリテーショングラフィックの略語で、議論の見える化を目的として、A4用紙又は模造紙へプロッキーを使って議論を描いていく手法。
ワークショップでは西河さんの解説がとても分かりやすく、実際に描きながら試すことができた。
議論の内容を議事録にまとめたり、内容をまとめて更に議論を深彫りしていくのは難しい。
議論が白熱すると、あらぬ方向へ議論が行って本来の問題解決につながらなかったりする。
アイデアを出しながら企画を組み立てようにも、アイデアがなかなか出ない雰囲気だったり、アイデアが散発的でつながりが見えにくかったりする。
そんな時にファシグラはすごく有用だ。
僕が改めてファシグラの威力を感じたのは、えと~さんが実際にファシグラを使っている場面を見た時だ。
ミーティングで到達すべきゴールは既にメンバー全員で共有しているが、ゴールにたどり着くまでにどんな議論が必要なのか、見えない状況だった。
そんな時、大量のA4用紙を元に、プロッキーで議論からラフな概念イメージやフローを描いていく。
一人の頭にあるアイデアを紙に書くことで、全員がそのアイデアを共有できるだけでなく、刺激を受けて、更にそのアイデアを補強したり膨らませることができる。
えと~さんも言っていたが、ファシグラをやると、自然に「問題 vs 私たち」という構造になる。
つまり、問題がファシグラで描いた紙に書かれていくから、メンバー全員がその紙を見ながら、問題点を探るので、同じベクトルへメンバー全員が自然に向くようになる。
更にファシグラの利点は、ファシグラで描いた紙を組み合わせると、紙芝居になることだ。
例えば、10枚描いたファシグラのA4用紙をあるストーリーの元に並べれば、自然にプレゼン資料になりうる。
つまり、ミーティングの終わりに、一つのプレゼン資料が出来上がるため、それをPoerPointへデジタル化すればいいだけになる。
【2】ファシグラだけでなく、タスクかんばんなどプロジェクトファシリテーションのツールは非常に面白い。
だが、最近思うのは、プロジェクトファシリテーションはIT企業の中間管理職研修で使われる内容と一致するような気がする。
実際、IT企業の中間管理職研修では、チームビルディングを主体としたワークショップ形式が主流だ。
理由は、実際の開発現場では、現場リーダーの必須技術の一つが、寄せ集めの開発者たちをすぐにチームとして機能させることだからだ。
最近のソフトウェア開発は、プロジェクト単位にメンバーを集めて、短い期間で開発していく。
しかもそのメンバーは自社とは限らず、他の会社の見知らぬ開発者と組んでいる時が殆どだろう。
その初対面のメンバーとすぐに信頼関係を築き、チーム内の役割のバランスをすぐに作るというチームビルディングの技術が重要になって来る。
特に、最近のWebシステム開発はメンバーの出入りが激しいため、チームビルディングを上手に機能させないと、チームが機能しないだけでなく、開発プロセスの品質が下がり、最終的にはシステムの品質にも響く。
このファシリテーションの技術は、リーダー特有の資質や経験に依存するものと従来は考えられていたが、最近は、意識的に育成できる技術の一つと捕らえる傾向にある。
そのファシリテーションの技術をIT業界に特化させたものが、プロジェクトファシリテーションと言えると思う。
数年前からアジャイル開発からプロジェクトファシリテーションへトレンドが移りつつある理由は、プロジェクトファシリテーションのマーケットが発見されたからだと思う。
そのマーケットこそが、IT企業の中間管理職、つまり現場リーダーなのだと思う。
だから、開発チームを統率し、システム開発というプロジェクトをやり遂げる役割でなければ、プロジェクトファシリテーションの発想は響きにくいかもしれない。
逆に言えば、チームビルディングが必要な人には、喉から手が出るほど、アイデア豊富な技術が揃っているため、非常に面白いと思う。
【3】アジャイル開発を実践しているチームならば、リリース計画やイテレーション計画を作る時や、イテレーションの開始・実行中・終了後にプロジェクトファシリテーションのプラクティスを使うと、効果的だと思う。
少なくとも、朝会やふりかえりは、アジャイル開発とすごく相性がいい。
もちろん、チケット駆動開発とも相性はよい。
例えば、タスクかんばんは、チケット駆動開発では作業ステータス毎のチケット一覧でデジタル化できる。
バーンダウンチャートは、チケット駆動開発ならば、イテレーション単位の残チケットの集計結果でデジタル化できる。
チケット駆動開発は、プロジェクトファシリテーションをデジタル化するツールと捉え直すこともできるだろう。
そのアイデアも考えてみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 掃き溜めの鶴を活かすマネジメント、それは強みSと環境Oを組み合わせたクロスSWOT分析と同じだ(2026.10.01)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
- Redmine利用成熟度モデルによる運用戦略(2026.07.12)
「Redmine」カテゴリの記事
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
「ソフトウェア工学」カテゴリの記事
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- AI時代のソフトウェア開発者とはアーキテクトの役割として再定義される(2026.08.30)
- AI時代の「コードと人間の関係」を問い直す—デブサミ関西2026で考えた、アーキテクチャの未来とコミュニティの価値 #devsumi(2026.08.22)
- 人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる(2026.08.16)
「プロジェクトファシリテーション」カテゴリの記事
- ふりかえり手法にジョハリの窓を使って自己開示と他者フィードバックを得る(2026.09.27)
- 組織変革の鍵を「聞く」体験から探る(2026.06.14)
- PM理論で読み解く日本人リーダーの弱点(2026.05.12)
- astahでPJ管理もプロセス設計もアイデア発想も全て表現したい(2025.10.25)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「チケット駆動開発」カテゴリの記事
- Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア(2026.09.21)
- 第23回Redmine大阪の感想~AIの暴走はチケット駆動で制御する!AI時代に人間が担うべき真の役割は何なのか? #redmineosaka(2026.09.06)
- 人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる(2026.08.16)
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)


コメント