イベントレポート『プロジェクトファシリテーションのはじめ方～現場力を高める見える化手法～』

12月某日、弊社が開発現場改善コンサルティングを実施しているお客様にて、
社内コミュニティの立上げイベントを行いました。現場改善では、組織レベル
に自律的な改善サイクルを定着させる手段として、社内コミュニティを構築す
ることがよくあります。横展開やより推進していくためには、自分達で考え、
お互いの気づきを共有する場が有効だからです。今回は、その立上げイベント
の様子をセミナーレポートとしてお届けします。

<<お客様プロフィール>>
・お客様概要
　　メーカーのソフトウェア開発部門
・コンサルティング目的
　　ソフトウェア製品の品質向上
　　→チーム力(現場力)の向上
　　　→プロジェクトファシリテーションの導入
・コンサルティング対象
　　社内推進部署
・立上げイベント参加者
　　20数名

立上げイベントは、以下のように進められました。
・コミュニティ趣旨説明(お客様)
・講演(平鍋)
・ワークショップ(天野)
・PF事例紹介(お客様)
・気づきの共有(天野＆平鍋)

●開発プロセス/技術だけでは足りない、チーム力にフォーカスした強化施策を
コミュニティ趣旨説明では、推進部署のキーマンから、これまで開発プロセス
と技術にフォーカスした施策を行ってきたがそれだけではプロジェクトを成功
に導くには限界が来ていることが告げられました。プロジェクトが複雑化、巨
大化していく昨今では、人と人のコミュニケーションの精度が重要であり、コ
ミュニティを立ち上げることで現場にパワーが出るような仕組みを作りたい、
という意気込みが参加者に伝えられました。

●現場の見える化でコミュニケーションのバンド幅を広げよう
冒頭の趣旨説明を受けて、平鍋からプロジェクトファシリテーション(以降、PF)
の目的、基本的な活動の紹介を行いました。
最初に、「ソフトウェア開発において、始めるときに要求が固まっていること
は少ないのでは？」と参加者に問いかけました。やり始めてみてから気づく仕
様変更、外部環境によるターゲットの変化などは、当たり前のように発生しま
す。このような状況で仕事を進めていくには、今やっていることや困っている
ことを見えるようにすることが求められます。良い計画を立てても、現状が見
えなければ計画通りに進んでいるかどうかわからないし、そもそも変更を前提
にしておくことが重要である、と提言しました。その核となる仕組みが、プロ
ジェクトの見える化です。ではどのように見える化すればよいのか、それは、
チームにおいて野球のスコアボードのようなものを作る事である、と紹介しま
した。その心は、最新の正の情報が、一箇所に集約されていることにあります。
また、まずはアナログで始めることを勧めました。アナログの方が、見える化
された情報から感覚的に危機感を察知することができ、更には誰でも見たいと
きにすぐに見ることができるからです。感覚的に察知する方が、人間の本能に
働きかけやすく、解決行動が誘発されやすい。これに対し、サーバに最新の情
報をあげておいても、最新かどうかわからない上、見たいときにすぐに見れな
いことが多いと紹介しました。
具体的な例として、タスクボード・朝会・ふりかえりを紹介し、最後に、「コ
ミュニケーションのバンド幅を広げよう」と締めくくりました。

●ワークショップで、実践するきっかけを作ろう
ワークショップでは、天野から、実際にどのように現場で運用していけばよい
のかをタスクボードを例に実践的な演習を行いました。PFで紹介されている見
える化はどれも簡単に始められそうでいて、実際のところ実践するまでの一歩
が踏み出せないという状況がよく見られるため、その課題を解決するために、
ワークショップの中で現場ですべきことを一通り体験して、その気づきを現場
に持って帰って、始めやすくしたいという狙いがありました。
1チーム4名にわかれ、「イベントを開催する」というお題で、そのためのタス
クを洗い出し計画するということを行いました。その中でファシリテーション
技術、タスクの切り出し方、タスク見積もりの合意方法、タイムボックスの考
え方等、実践的なテクニックが紹介されました。
参加者からは、
　・チームが主体的に動くためのエッセンスがあった。やらされ感の軽減につながる。
　・文書化されない細かいズレをなくせそう、共通認識を作りやすい、作業漏れが減りそう。
　・属人化対策になりそう。
　・一緒にタスクを切り出すことで若手育成につながる。
等の声が寄せられました。
また、良いタスクの基準としてSMARTを紹介した。
　S　Specific　　イメージできるくらい具体的であること
　M　Meacurable　計測・見積もりができること
　A　Achievable　達成可能であること
　R　Relevant　　上位タスク(目的)に寄与すること
　T　Timeboxed 　締め切りを区切る事ができる
まずは、やり始めて気づきをキャッチしてやり方を変えていく柔軟性が重要で
ある、と締めくくりました。

●既にやり始めているところはある！
PF事例紹介では、お客様内でPFを実践しているプロジェクトの生の声が提供さ
れました。タスクボードを導入した例では、当初は一定の成果が見込まれたが
最終的には形骸化し、中止することになった事が紹介されました。その原因と
しては、ふりかえってみると何かしら続けることに無理があったのではないか
とので、何が無理なのかを考え、最低限知りたいことに絞って見える化を再度
やってみようと思う、と今後の進め方が紹介されました。

●今日の気づきを現場に持ち帰るために
気づきの共有では、事例を聞いて感じたことをテーブル毎に共有しました。ど
のテーブルでも、さまざまな意見が交換されました。(以下、一例)
　・みんながそれをやりたいと思っていない、なぜだろう？
　　→その解決策は、現場によっても違うし、人によっても違う
　　→管理している人のための物となっているのでは、やる人の嬉しさがあまりなかった
　　→目的の合意が必要だったが、目的の合意を先に作るのは結構難しい
　　　→概念的な話となるため、やってみて必要だから導入する、というサイクルが必要
　・定期的な報告が義務付けられているが、報告をあげても解決してくれない
　　→やっても意味がないので、やりたくなくなる
　・タスクを書くことが難しそう
　・タスクを移動していくのが面倒臭そう
　・会社が違うとやり方も違って、独自でやることが許されるのか？
その気づきを代表者が発表しました。(以下、一例)
　・やっぱり、担当者も管理者もみんなのために嬉しくないと駄目だな、と痛感した
　・タスクボードを導入している。タスクが徐々に右に動いていくのは気持ちがいい
　・作っている製品でユーザを嬉しくするためには、作っている人が嬉しくないとい
　　い製品が作れないのではないか、と思っている。

●見える化ツールは手段のひとつにすぎない
立上げイベントを終了して、参加者の中には、「今回の見える化ツールは手段
のひとつであって、自分達の現場をより良くするには、課題を見極めて、適し
た手段を編み出す必要がある」と本質的な議論がされていました。コンサルタ
ントとしては、「よく気づいてくれました」という感想を持ちました。立上げ
イベントの目標は達成され、非常に有意義な時間を提供できたと感じています。