**********************************************************************
セッションS2-c チュートリアル１
テーマ：プロジェクトファシリテーション 〜実践と変化〜
講師：懸田 剛 氏（チェンジビジョン）
日時：2007/8/31 8:50〜10:30
参加人数：27名（終了時）
**********************************************************************

・アジェンダ
  ○自己紹介
  ○プロジェクトファシリテーションの概要
  ○実践例
  ○まとめ

・今回のゴール
  講師の会社（チェンジビジョン）におけるファシリテーション実践例を紹介し，
気づきを受講者の皆さんに届ける．そして，受講者が自分の企業に帰ったとき，
プロジェクトファシリテーションを実践させたくなるようにする．
  『ファシリテーションとは何か？』については，前日の基調講演にて平鍋氏が詳細に
解説したため，本講演では簡単に触れるのみとする．

・自己紹介
  （株）チェンジビジョンに所属。チェンジビジョンは、UMLを用いたシステム設計
ツール“JUDE”と見える化ツール“TRICHORD”というソフトウェアの開発している。
講師はTRICHORDの開発リーダーを経験．
  幾つかのコミュニティに属しており，平鍋氏とは“日本XPユーザーグループ”という
コミュニティで知り合った．

・プロジェクトファシリテーションの概要
  価値，原則，実践によって，プロジェクト形態におけるファシリテーションの体系化
とそれを実践したもの．
  日本人は“価値”などの体系化を苦手としており，今までに上手く明文化してまと
まった事例が無かった．

・プロジェクトファシリテーションの目的
  プロジェクトの成功と個々人の成功を結びつけること．
  プロジェクトの質と個々人の人生の質を結びつけること．
  エンジニアがそのプロジェクトに参加したことで，質の高い時間・人生を送れたと
実感させられるか？ → 現状では，プロジェクトのために個人が犠牲になっている
（キーワードとして，QOL：Quality Of Life）

・プロジェクトファシリテーションの価値
  コミュニケーション：コミュニケーションの価値を重視し，成果が個人の能力の総和
を超えられるように
  行動リスクがあっても実行できるように，行動に価値を持たせる
  気づき：漫画のような，頭の上の電球がパッと光るにはどうすればいいのか？
  信頼関係：お互いに信頼して，モノが言える関係を築きあげる
  笑顔：プロジェクトを如何に楽しんで進めるか

・価値とは？
  行動を起こすときの指針となるもの
  チームで価値を共有することが必要

・プロジェクトと価値観
  価値観を共有し，それをベースとしておくことで，プロジェクトの進行がスムーズに
なる．
  価値観は個人それぞれであっていいが，ひとつのゴールに向かうには価値観を収束し
ていきたい

・価値と実践との関係
  価値観は行動がなければ何にもならない
  行動とは，すなわち実践すること

・PFの原則
  見える化：Seeing is Understanding．見ないと行動は始められない．
  リズム：プロジェクトの進行には，メリハリが必要．（一気に走り続けられない）
  名前付け：概念に対して名前を付け，名前でコミュニケーションしたほうが意思疎通
がスムーズになる．
    ＜例＞あるデッドラインに間に合いそうになく，残業するすること 
          → 界王拳（カイオウケン）
          （ドラゴンボールに由来．ある一定の期間だけ力が数倍になる，
            でも力の持続はできない）
  問題vs.私たち：問題を個人のせいにしない．お前のあれが駄目なんだ！ではなくて，
チームとして一緒に問題解決策を考えていく．
  カイゼン：継続的に，少しずつ良くなるようにしていく．

・原則とは？
  実践のためのルール．
  価値と実践を結び付けるもの．
  原則は不変でなければならない（実践は変わってもよい）

・実践の紹介
  以下，懸田氏がTRICHORDプロジェクトにおいて行ったプロジェクトファシリテーション
の実践例をみていく．

・プロジェクトの歴史
  2006年1月から開発を開始．最初のリリースは同年4月．
  当初は5人のメンバで開発を行っていたが，何度かメンバの変更／入れ換えがあった
（オリジナルメンバーは懸田氏ともう１人だけ）

・TRICHORD開発での実践
  主に，“ふりかえり”／“見える化”／“リズム”／“チーム作業”のPFを行った．
  本講演では，時間の都合で前者２つの実践例を紹介していく．

・実践（１）ふりかえり
  PFの中核になるじっせんであり，経験上から一番重要なものといえるだろう．
  目的：カイゼンにつなげるネタとする
        今から見て過去はどうだったか？未来にどう行動するか？
  PFでは漢字の“振り返り”ではなく，あえてひらがなで名前付けしている．
      漢字だと硬いイメージがあり，重いタスクにみえるため．

・ふりかえりの手法
  KPTとタイムライン
  KPT：Keep,Proplem,Try．短期間でのふりかえりに有効．
  タイムライン：時系列に沿ったふりかえり．長期間で有効．

・「ふりかえり」ではないもの
  反省会：駄目だったことの列挙．
          良かったことをふりかえることが重要．
  問題と自分たちを向き合わせることが必要（問題vs.私たち）．

・イテレーションふりかえり
  １週を単位時間としてKPTを行う．
  TRICHORDでは，金曜の10:30〜12:30に充てていた．

・イテレーションふりかえりの流れ
  1.前回のTryが今回にできたか
  2.今週のKPTを参加者全員でホワイトボードにざっと列挙する．
  3.内容を確認，一望する．
  4.左下に記述されたProblemを深堀りしていく．Tryを見つける．
  5.来週のTryの記述．Tryに対する担当を決める．
  6.写真撮影，BlogへのUP
  ※司会は毎週変えている → 個人によって進め方に個性があり，進め方が変化する
    面白さが出る．
  ※ホワイトボードの左上にKeep，左下にProblem，右半分にTryを記入していく．

・イテレーションふりかえり
  TRICHORDプロジェクトの進行途中で作成された何枚かのKPTをみていく．
  随時，ポインタで指して注釈を加えながら．
  プロジェクトの進行状況，問題点（サーバなど），来客記録，個人的な話題，
  ただの落書きetc.が記載されている．

・イテレーションふりかえりで気をつけていること
  個人攻撃はしないこと．あくまで“問題vs.私たち”である．
  目的はなにかを意識して記述する．

・気づき[1] チームのフェーズの存在
  成長 -> 苦悩 -> 安定 -> 変化のループがフェーズとして存在する．
  どこかに長く居てもいけなないし，短くていいものでもない．

・気づき[2] 同意する
  KPTの表に正の字で同意を表明する．
  共感の意思表示でもある．

・気づき[3] 改善の種類
  Problemを改善するためには，今の枠組みの中で対応できるのか，枠組み自体を
  変える必要があるのか → ふりかえりによってどちらが良いか見えてくる．

・気づき[4] ルールや気持ちだけでは続かない
  行動するには理由・動機付け，さらには仕組み作りが重要になる．

・気づき[5] チームとして問題に対峙する
  問題の発生は個人が悪いわけではない．個人が問題を発生させる要因となった
  システムの問題とみなす．（問題vs.私たち）

・気づき[6] すべてを振り返る
  どんなに軽いネタでも書く．（この日のお昼はおいしかった，この宴会は楽しかったなど）
  生産効率には繋がらないのだが，同じ時間をすごした思い出になり，チームの結束力
  向上に繋がるのではと感じている．

・もしもふりかえりをしなかったら・・・
  簡単に言えば，酒の席での愚痴が多くなり，周りに広がり，チームの雰囲気へと
  伝播していく

・気づきの重要点
  大きな視点での効果がある．イテレーションごとでは見えない問題に気づくことが増えた．
  ステークホルダーが全員参加し，全員で気づきを共有する．
  細部は覚えられない → ニコニコカレンダーの利用（詳細は後述）

・ふりかえりの今後の野望
  すぐに使えるようにしたい．短時間で効果的に行えるようにしたい．

・実践（２）−数々の見える化
  見える化の目的：まず見えるようにする．誰にも見えるように話題を共有する．

・チームの作業の見える化（かんばん）
  作業のTodo／Doing／Doneの状態をはっきりさせる．助け合いの指標とし，
  どこがネックになっているのかを見えるようにする．
  TRICHORDでは，１週間でかんばんを貼り出していた．
  現場によって、Pendingのような他の作業状態ももあるのではと感じている．

・かんばんの変遷
  1.壁に１枚の紙として貼り出していた
  2.PCを用いて，デュアルディスプレイでかんばんを表示させた．
  3.『○○までにこの部分を実装しなければいけない』などの計画を表示できるようにした．

・アナログとデジタルの比較
  アナログの最大のメリットは壁に貼りだしていつでも誰でも見れる．
  逆に，物理的空間をとり，再利用できない．
  デジタルは場所もとらないし，再利用も簡単．
  逆に，最大のデメリットは常に見ることはできない．

・問題、課題の見える化（Inbox）
  デジタルだけで運用するだけでなく，気づいたらいつでも付箋に書いて壁に貼って
  良いこととした．
  それを毎朝確認．問題の共有がスムーズに．

・ふりかえりとの違い
  ふりかえりは単位時間での問題の列挙．
  Inboxは現時点で存在する問題の列挙．すぐに共有したい事柄を書く．
  どちらもチームでの共有に価値を置いている．

・なぜソフトウェアだけで運用しないか？
  メールでのやり取りは時間の無駄．読んでいないと言い訳されるかもしれない．
  最大の理由は，今、ここに、全員いるから．

・Inboxの気づき
  共有は第一歩に過ぎず，それを行動に起こさなければ意味が無い．
  いかに対処するかを考えないと，壁がモリゾー状態（付箋が大量に貼られて貯まる
  一方）に陥る．

・気分の見える化  ニコニコカレンダー
  毎日，その日の気分を３段階の顔のアイコンで表し，一言日記を添える．

・ニコカレの気づき
  自分の気持ちを正直に書く場が提供できている．素直にBadが出ているのがうれしい．
  Blogを毎日続けるのは大変だが，１行で良い気楽さで続きやすい．
  チーム内のコミュニケーションとしても役立つ．

・ニコカレの導入〜段階的改善
  個人の性格に依存して個別にフォローアップする判断材料とする．
  ふりかえりとの相乗効果を狙えないか考えている．

・PFの実践を通じてのまとめ
  価値観に基づく行動を実践できれば、さらなるひろがりが生まれる．
  チーム内、組織内、顧客との関係でPFを持続していきたい．


○質疑応答

＜質問者１＞
KPTについて，全部の要素（Keep／Problem／Try）を同じとみなして見ていないと思うが，
管理者（プロジェクトリーダ）から見るときにどういう粒度でそれぞれの要素を見るか？
どの記述に着眼するかの見るコツは？

＜回答＞
落書きレベルの抽象的なものは，ふりかえりの場では気にしない．
表層的な記述は，記述者にもう少し問いかけてみる．何かが上手くいかないのなら，
なぜ上手くいっていないのか，仕組みに問題があるのか，どのような仕組みなら解決
できるのかを考えるような呼び水となればと思っている．
要素ごとの粒度はそれほど意識していない．


＜質問者２＞
KPTのうち，Problemが重要であり，目が行きがちな印象を持ったが．

＜回答＞
Problemそのものというよりも，そのProblemがTry／Actionに繋がっていくのかが重要
となる．
繋がらないのであれば，何故繋がらないのかを考えることも重要．