サウスポーなSEの独り言

　もう1ヶ月以上前のことなのですが「XP祭り関西2012」に参加してして、LTをしてきました。

＃スピーカー、スタッフの皆さん、楽しい時間をありがとうございました〜

◆自分のLT
　前回「XP祭り関西2011」に参加して、そこでもLTをしたので、せっかくなので「続きもん」みたいにやってみようと思いました。


　主題は「勉強会に参加したことが無い(主に社内の)人に対してやったこと」です。

◆スライドの補足
ここには同僚は来ていませんけどね
　スライド作った後で同僚が参加しているのに気づきましたが、せっかくの対比だったのでそのままにしておきました(苦笑)。

1：情報発信
　時々「誘っても全然来ないんですよ〜」て声を聞きます。
　やっぱり来ない人は来ないです。
　
　なので、まずは「広い層に対して(自分のリソースをあまり使わない方法で)アプローチ」しました。
　これが社内SNSにポストしたり、みんなでランチしている場で軽く話してみるなどです。

　そこで、興味を示した人によりリソースをかけて一本釣りに行きます。
＃リソースって聞こえは悪いかもしれませんが、多くの方に来て欲しいですが、自分の時間も有限ですので。

　それぞれ興味の持ち方、「後一歩踏み出すため」のハードルが違ったりします。
　「勉強会」は怖くなく、軽い気持ちで行けば良いのですが、行き慣れている人の感覚でもあるので、そこを無理に「大丈夫だって」て押してもうまく行かないことも多いと思います。

　気をつけているのはアジャイルサムライにもあった「誰もがこの働き方を気に入るわけじゃない」というフレーズです。
　(残念なことですが)誰もが自分のレベルアップに一生懸命でも無いですし、レベルアップの必要性は理解しても、その実現方法は勉強会に行くだけではないので。

2：自社で社外勉強会
　平日夜開催なら(社員の方が)「残業をちょっと早めに切り上げて参加して(覗いて)みようか？」と少しでも思ってくれれば…と。

3：巻き込む
　ベースは巻き込む側の得意なパターンで良いのですが、ただ、同じく意識していたのが、人によって参加するきっかけ、しない理由はそれぞれ(性格ももちろん影響します)ってことです。
　なので、それぞれによって「響く言葉」を選んでいたように思います。

次は経営層やマネージャ層
　こういう層の方々は売上や利益など目に見える「数字」を(時には短いスパンで)達成することをより強く求められています。

　その環境の中で直接の数字に(すぐには)貢献しそうにない場を理解してもらう、また積極的に参加してもらえるのはなかなか難しいなぁと思っています。

　まぁ(技術的な勉強会などには)参加しなくて良いので「こういう存在があって、そこに(やる気のある)エンジニアがたくさん来ている」というのは知ってくれたら嬉しいです。
＃もちろんビジネス的なセミナーや勉強会にはアンテナを張って参加して欲しいです。

　後日開催されたRxTstudyでは「勉強会初参加」の同僚も数人いましたし、細々と続いている(気がつくと30回を越えている)「社内読書会」にも若手の方が参加してくれています。
　(もちろん自分のアクションだけではないですが)少しでも貢献できているのであれば、嬉しいことです。

　GWの谷間に「マシュマロ・チャレンジ」を体験しました。

　ちょうど先日、NHKのスーパープレゼンテーションで放送されたのでご存知の方もいるのではないでしょうか？


◆「マシュマロ・チャレンジ」とは？
　「タイムボックス」や「チームビルディング」などについて色々な学びを得る事が出来るワークショップです。

　使うのは1チーム毎に以下のものです。

1：パスタ20本(もちろん茹でていない)
2：マシュマロ
3：マスキングテープと紐を90cmずつ

　ルールは制限時間内にこれらの道具を使いながら、パスタでタワーを立てその上にマシュマロを乗せ、高さを競うというものです。

　詳しくは以下のブログに色々書いています。
　ただし、ネタバレ(このワークショップの色々な狙いや気づき)も書かれているので「いずれ(自分で)それを体験してみたい」という人は見ない方が良いと思います。
「チームとタワーを創造せよ！マシュマロチャレンジでチームビルディング #sgt2011 #CSPO」
TED

◆やってみた
　進行は原田(@haradakiro)さんにお願いしました。
　そしてメンバーは「スクラム道場関西版」(仮)の11人。
＃「スクラム道場関西版」についてはまた今度書きます。

　比較的こういうのに慣れている、そして、やっていくメンバーだったので、ゴールとして「体験することで、自分達が進行できるようにする」というのもありました。

　3チームに分かれて開始しました。
　私のチームは全員が仮にも(ペーパーでも・笑)「認定スクラムマスター」でした。

　そして1回戦は3チームともタワーを建てることができました。
　↓こんな感じです。


　しかし、2回戦は(少なくとも自分は)完全にこのワークショップの狙いにハマって、見事に失敗しました(記録ナシ)。

◆気づいたこと
・ちょっとした状況でこんな簡単に視野が狭くなるのかってこと。
・視野が狭くなったら、チームがこんな簡単に機能しなくのかってこと。
・「なぜうまく行ったのか？そしてそれは再現可能なのか？」を共有するのが難しいってこと。
・小さくても良いから、ゴールに近い部品から作ることが大事ってこと。
・時間はあるだけ使ってしまう(その使い方が有効かどうかに関係なく)ってこと。
　
　ある程度、どんな狙いがあるのか理解していたにも関わらず、他にも色々気づいたことがあり、興味深かったです。
　そして自分達のシステム開発でも同じような状況に良くなっているということも改めて感じました。

　「ちょっとやってみたい」「体験してみたい」という方がいれば、声をかけてくれると嬉しいです。

「RxTstudy」の第4回で(スタッフ/発表者として)参加してきました。

＃「RxTstudy」のこれまでの内容はこちらのサイトをご覧ください。

　今回は[雑多]RxTstudy第4回に向けてで書いたように「タスク管理」と「グループディスカッション」が特徴でした。

＃参加していただいた、お話していただいた、準備/後片付けを手伝っていただいた皆さん、ありがとうございました！


◆スピーカーのみなさんの話を聴いていて思ったこと
　「自分のタスク管理」的なお話だったのですが、それぞれ今のやり方に行くまでの試行錯誤したことが伝わって面白かったです。
　「なぜうまく行かなかったのか？」をちゃんと分析して、次に活かして自分なりのタスク管理スタイルになっているような感じでした。

　新妻あっちさんの話にあったように「本に○○と書いている」と言っても、書き手と本人のコンテキストや性格をちゃんと分析しないと、テクニックや考え方を有効に使えない･･･と改めてて思いました。

◆自分のお話


　今回言いたかったのは「自分の調子と相談」でした。

　仕事内容にもよりますが「どうしても乗らない時間帯/日」というのはあります。
　その状態でタスクをこなしても良い質のアウトプットにならず、結果的に手戻りなどで余計な時間がかかってしまうこともあります。
　なので･･･
1：「調子の良い時間を長くするか？」･･･「調子の良い状態へ持って行く方法を知っている」
2：「調子の良い時間にいかに最大限のアウトプットを出せるか？」･･･「準備をちゃんとしておく」
　…が大事だと思っています。

◆グループディスカッション
　(2回目はスタッフ業のため参加しませんでしたが)1回目は「デジタル×チーム」の枠に参加しました。
　みなさん「Redmine」を使っていたようです。

　それぞれの悩み･･･「どうやってみんなに使ってもらえるか？」とか「レビューをどう回すか？」など･･･に対して「自分はこうしているよ〜」という話が少しはできたので良かったかなぁと。

　自分なりに印象に残って考えてみたいと思ったことは…
「チームで使ってその効果は出ているが、マネージャクラスへの報告資料的なサマリ情報も一緒に出したい」
　…ということでした。
＃今のところの考えでは「マネージャ用には別のツール(ベースの情報はRedmineで良いけど)を使った方が受けが良いと思う」という感じですが。

◆その他
　「社外勉強会に行ったことが無い」同僚が3人ほど来てくれたのが嬉しかったです。


　第5回も夏頃に開催予定です(これから相談ですが)。
　決まったらRxTstudyのアカウントで、つぶやきますので、是非参加してください！

＃「スタッフしても良いよ！」「スピーカー/LTしたい！」「ブログ書いたよ」とか感想のつぶやきは、ハッシュタグ#RxTstudyをつけてもらえると嬉しいです。

先日社内勉強会で「バーンダウンチャート」について説明する機会がありました。

説明資料として@ryuzeeさんの「[Agile]バーンダウンチャート虎の巻(資料公開)」を使わせてもらいました。(@ryuzeeさん、ありがとうございました！)

　で、その資料で自分なりに疑問に思ったことで@ryuzeeさんとやり取りした内容を(誰かの役に立てば･･･と)まとめておきます。(重ね重ね、ありがとうございました！)


◆質問1：バーンダウンと自己組織化の関連
※スライド11枚目：「バーンダウンから分かること」
　「チームが自己組織化されていて〜」は具体的にどのようなことでしょうか？
　バーンダウンの進み方と「自己組織化」の紐付けがイメージできませんでした。

【@ryuzeeさんのお話】
　チームがスプリントを主体的に行なっているかどうかが分かります。
　他人からの指示を欲してしまうチームは、一般的には問題が発生してもすぐ対応しないので、スコープ調整が行われず完了しないスプリントになったりスコープ調整が後半になったり、そもそも経験から学ばずに、毎回似たようなバーンダウンを描いたりします。

◆質問2：理想線の引き方について
　(スプリントの)見積総時間とスプリント終了日を結んだ場合、チームの1日辺りの理想時間と乖離する※こともあると思います。
　この場合は「詰め込みすぎ」なので「スコープを見直す」アクションにつながる･･･と思っていますが、この理解にコメントあればお願いします。
※例：3人チーム(1人の開発時間は6時間/日)の場合、18時間/日のパワーです。一方、理想線の傾き(1日の時間)は24時間とした場合、毎日6時間のオーバータスクになってしまいます。

【@ryuzeeさんのお話】
　その理解であってます。
　ただし、チームにはキャパシティというのがあります。
　これはチームメンバーの稼働可能時間の合計値ですが、それは一般的には就業時間の6割程度です。

　したがってスプリント計画第二部が終わって計画ができた時点で、まずチームの総キャパシティの中に合計タスク時間数が収まっているかは確認すべきポイントです。
　既にこれを超えているようであればPOと議論して順位の一番低いストーリーから順に外します。
　またチームがタスク出しになれていない場合は、2割くらいの追加タスクが出るのが普通なので、これも見込んだほうがよいです。

　結果として、理想線のスタート地点はキャパシティの下側になければいけません。

◆質問3：残時間の傾きが大きくなった場合の原因
※スライド21枚目：早期学習パターン
　残時間が44→26のように(スコープの調整等がなく)ガクッと下がった場合、以下のことが考えられます。

A：チームがレベルアップして当初見積より早くそのタスクが終わった
B：チームが残業した

　前者であれば良いのですが、後者であればそれは持続可能でないと思います。
　そういう場合に「最終コミット時間」を別にプロットすることで「原因を明らかにする」のが良いと思っています。
　この理解にコメントあればお願いします。

【@ryuzeeさんのお話】
　本当は最終コミット時間プロットしなくたって振り返りで分かりますけどね。
　本質的な原因を明らかにしなければいけないのはその通りです。
　往々にして成果達成に対する強いプレッシャーがかかってたりします。

◆質問 4：複数スプリント間での比較
※スライド35枚目：複数スプリント間で分析する
　スプリントで作る機能の難易度の違いを考慮する良いアイデアはあるでしょうか？
　「フリカエリ」でチームでディスカッションして明らかにするのが1つの方法と思っています。

【@ryuzeeさんのお話】
　難易度の違いはストーリーポイントと、ばらしたタスクに明確に現れるはずだと思います。
　そのためにチームで見積るので。
　それが着手してみて初めて難易度がわかるようであれば、そのバックログ項目はまだReadyではないです。


　バーンダウンチャートを始めることは割と簡単にできます(おそらくガントチャートと並行してもできるはずです)。

　実際にやってみるとガントチャートだけでは見えなかった(チームやプロジェクトの)色々なことが見えて来ます(逆に何も見えなかったらそれはそれで無茶苦茶素晴らしいチームか、何か隠しているかです)。
　それを改善のきっかけにしていくこともできます。

　社外勉強会やコミュニティ活動がマルチタスクだったり、これから活動するよ！ってなものもあり、整理したく書いてみます。


◆RxTstudy
　「Redmine」と「タスク管理」の勉強会です。
　少し前まではこの活動にパワーを使っていました。
　
　次回が第4回で、2、3ヶ月に1回のペースで開催しています。
　ありがたいことに「今度、話したい！」という声もちょくちょくあります。

◆(仮名)スクラム道場関西版
　「仮名」とあるようにこれから動き出すもので、どんな名前になるのか分かりません。

　「関西、大阪近郊でAgile(またはScrum)にフォーカスしたこぢんまりとした勉強会(ディスカッションがメイン？)」のような形で･･･

1：アジャイルを実践している/しようとしている人の「よりうまく行くためにはどうしたら良いか？」という相談をしたり。
2：アジャイルな開発でより価値を届けたいけど「うまくチームが機能していない」という問題を一緒に考えたり。
3：ユーザ企業で「アジャイルな開発でより価値を得たいけどどうしたら良いか分からない」という問題を一緒に考えたり。

･･･などをテーマにできたらと思っています。
　
　発端は･･･
「関西ではスクラムマスター同士の情報交換できる場所とかあまりないなぁ」
　…と思ったからでした。
　スクラムマスター同士が顔を合わすと、(コンテキストはそれぞれ違いますが)似たような悩みを持っていて、ディスカッションすることでその悩みの突破口が見つかることがあります。
　そういうシーンをもっと多くできると嬉しいのでは？と思ったわけです。

　「興味ある！」という方がいたらTwitterなりFacebookなりで声をかけてくれると嬉しいです。

◆DevLOVE関西
　DevLOVEを関西で開催するって内容です。
　今度で3回目です。

　過去2回に参加した方から時々･･･
「DevLOVE関西ってまたしないんすかね？」
「今度あったら行きたい」
　…と声をかけられていました。
　
　ということで、「この人の話を聴きたい！」という方もたくさんいるので、せっかくなので進めていくことにしました。
　@papandaさんを初めとしたDevLOVEな方々も手伝ってもらえるでしょうし。
　これも「関わってみたい！」という方がいたらTwitterなりFacebookなりで声かけてください〜

＃他にも社内読書会や(大阪)Jenkins勉強会などがありますがメイン処はこんな感じです。
　
　(もちろん本業も大事ですが)こういうコミュニティ活動から得られたモノはすごくたくさんあり、大きいものです。
　私にとっては本業をがんばる源泉の1つでもあります。

　ここ1年ほどいくつかの勉強会に参加して、時にはスタッフだったり、スピーカーをさせてもらったりした中で「仕事と勉強会の源泉の関係」について感じたことです。


「今日の勉強会でエネルギーをもらったので、明日からまた現場で頑張れます！」
　…という声を時々聞きます。
　
　(スタッフだったりすると)そういう声は嬉しいのですが、一方で…
【うまく行っていないのに変化しようとしない現場やデスマの現場でエネルギーが切れる(心が折れる)】→【勉強会でエネルギーを補給】→【また日々のしんどい現場で…】→【エネルギー切れたら勉強会へ】
　…という(改善ではない)ループにハマっている感じがする時もあります。

　「(しんどい)仕事をやり切るために勉強会へ参加する」みたいな。
＃もちろんこういう方は少ないよ！ってのであれば嬉しいことですが…

　一方、自分はどうだろうか？と考えてみました。
　「勉強会で話したいために仕事で(改善も含めて)楽しんでガンバル」
　↑が自分のスタイルかなぁと。
＃ベースは「オレの話を聞け！」なのかもしれませんが(笑)。

　自分にとって(会社での)仕事で改善を意識し続けてやっている源泉の1つに「(自分が経験して学んだ)アウトプットを話したい」というのがあります。

　もっと言うと、それを伝えた人からの(良い悪い関係なく)フィードバックを得て、もっと良いモノにしていきたいです(そして、それを共有したい)。

　さらにさらに言うと、自分と同じようなことに(不必要に)悩まず、はまらず、本来やりたいことにリソースを集中して、より良い仕事ができるようになれば…と思っています。

　そのためには、(当たり前ですが)上っ面をなぞるようなことでなく、自分が腹落ちしていることを言いたいわけです。
＃腹落ちしていなくて、自分が悩んでいてもっと意見を聞きたい場合は、正直に伝えるようにしています。

　(自分で腹落ちするために)漠然とするのでなく、工夫や改善を意識して、「何か伝えるエッセンスがないか？」ということも意識しながらやっているわけです(いつもってわけではないですが)。

　勉強会やセミナーなどでよく話されるスピーカーの皆さんの(話す)源泉ってどんなんだろうって気になります。

　AgileJapan2012でも少しだけお話したのでこちらでも宣伝です。

　「RxTstudy」(第4回)が2012年4月21日(土)にあります。
　参加受付はATNDで行なっています。

＃懇親会の出足が毎回いまいちなので、こちらもよろしくお願いします(笑)


◆今回の特徴1：「タスク管理」に焦点を当てたセッションが多い
　過去3回では(「R：Redmine」に関する話が多く)なかなか「T：Taskmanagement」である「タスク管理」になかなか焦点を当てることができませんでした。
＃これまでの過去3回の内容はRxTstudyの公式サイトにまとまっています。

　そこで今回は関西ライフハック研究会女子部の新妻あっちさんなど(あまりRedmine色が強くない方・笑)にお話していただきます。
　「IT業界じゃないから…」という方も参考になる話だと思います。

＃私も「個人のタスク管理」に焦点を当ててお話するつもりで、Redmineは出てきません。

　今更の余談ですが「RxTstudy」の「R」は「Redmine」で「T」は「Taskmanagement」を表しています。

◆今回の特徴2：グループディスカッション
　これまで「スピーカーが話す→それを聴く」という一方通行感がありました。
　また参加者のフィードバックにも「他の参加者と意見交換したい」という声もありました。
＃質疑応答や懇親会でディスカッションできた方もたくさんいるとは思いますが。

　というわけで、グループディスカッションを設けました。

※ATNDの文章より　

自分の自慢のタスク管理ツールをみんなに見せるもよし。
話すのが苦手な方は、今タスク管理について困っている事を相談するもよし。
タスク管理について、自由に話ができる場にしたいと思います。

　多くの方の話を聴いてインプットするのも良い事ですが、それにとどまらず(意見交換などを通じて)アウトプットをすることで、より良いものをRxTstudyで(自分も含めた参加者の方々が)得ることができれば…と(スタッフの1人として)思っています。


　まだ人数に余裕がありますので、興味がある方は軽い気持ちで覗いてみてはいかがでしょうか？

　「AgileJapan2012」に参加してきました。
＃色々準備をされていた(もちろん当日も)スタッフのみなさん、スピーカーのみなさん、ありがとうございました。

　去年は大阪はサテライトだったのですが、今年はメイン会場でした。
　各地からスピーカーが集まり、参加者の数もかなり多くとても熱い内容になりました。

＃それでも平日ということもありスーツな方の割合が多かったですが

　私はご縁があって2つのセッションでお話してきました。
　Agile セッション「チケット駆動開発の課題と展望」とChange セッション「現場に続くAgileの道を語ろう〜アジャイルサムライ読書会が変えてきたこと〜」です。

　今回は「チケット駆動開発の課題と展望」での話です。



　今回は(あえて)「Redmine話」や「チケット駆動開発」を意識しませんでした。
　「チケット駆動開発をどうやったらうまく行くんだろ？」と期待されていたものとは違ったものだったかもしれません。

　ただ「Redmineを入れてチケット駆動開発をしたいんですけど･･･」という相談をちょくちょく受けるのですが…
「どんな風なチームにしたいのですか？Redmineを入れてそれをどう実現したいのですか？」
　…と聞くと「本当にやりたいこと」が実はRedmineで無くてもできることがあったりして「Redmineやチケット駆動開発をやることが目的になっている」事例もけっこうあるなぁと感じていました。
　ですので、今回のスライドのお話にしました。

　いくつかスライドの補足です(当日話したこととかぶるかもしれませんが)。

◆「守」の話
　他のメンバーのチケットの書き方、分割・更新のやり方が自然に目に入る機会が多くなり、チームに広まって行くことがあります。
　フリカエリなどで「分かりやすいと思ったチケットはどれだったか？」などとテーマでディスカッションするとより効果的です。

　理想はツールを介せずに、ノウハウや技術の伝承ができるチーム(組織)です。
　しかしロケーションの違い、その風土が無いなどでも(諦めずに)このような方法でもレベルの底上げのチャレンジができるという話です。　

◆「破」の話
　「改善タスクを行うリソースをどう確保するか？」ですが、チーム全員が改善を好き(得意)ではないですし、そればかりだと本業(お客様へ価値をもたらすシステム)もおろそかになります。

　しかし、改善しないとちょっとしためんどうや不便さがチームのスピード、モチベーションを低下させ、パフォーマンスを奪っていきます。

　スクラムマスターはこういう改善がそれこそメインになりますし、改善が得意なメンバーがいれば(本業のタスクとのバランスで)改善タスクを取ってもらうのも1つの方法です。

　ポイントは(スクラムマスターやプロダクトオーナーを含めた)チームが「改善は必要なタスク」と意識することです。

◆「離」の話
　「これまでがこうだったから･･･」「○○を今まで使っているから…」という理由でチームのパフォーマンスを上げるチャンスを逃さないように･･･というのが言いたかったことです。
　確かにこれまではその方法がベストだったかもしれません。

　でも今ではチームのパフォーマンスも変わって、周囲の状況も変わっているはずです。

　その中で、これまでの方法も含めて「今のチームが一番パフォーマンスを発揮できるやり方」を考えて行く方が(短期的には多少遠回りでも)結果として良い価値を届けることができやすくなると思います。

　コンテキストもそれぞれですし「そんな簡単には･･･具体的にどうしたら･･･」という方もいると思います。
　そんな場合、愚痴を聞くだけかもしれませんが、(もしかすると)何かお力になれるかもしれませんので、お気軽に声をかけてください。


　ちなみに(各セッションも良かったのですが)自分にとって一番勉強になったのは講師控え室での色々な方とのディスカッションでした。
　正解が無い話題が多い中で「自分はこう思う」を話して、それに対してフィードバックを(ダイレクトに)もらえる時間というのは、スピーカーをするメリットでもあると思います。

[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」と「見える化」ともう1つ「フリカエリ」について考えることがありました。


　今のチーム(約2年)では原則、(Scrumの)イテレーション毎にフリカエリを行い、そこではKPT(Keep/Problem/Try)のフレームワークを使っています。

　やり方はほぼプロジェクトファシリテーション実践編 ふりかえりガイド(※リンク先はPDF)の通りです。

　以下は、今のチームでやっている工夫や気づいたことです。

◆W(分かったこと)を書き出す
　KPTに似たようなフレームワークで「YWT」というものがあります。
＃Y(やったこと)・W(わかったこと)・T(次にやること)というもので、弊社ではひょっとするとKPTよりこっちに慣れている方が多いような気も･･･。

　Keep・Problemといった事象やアクションから「感じた」何かがあると思います。
　それを「W(分かったこと)」として書き出します。

　分かっこと自体がTryなどの直接のアクションになることは少なくても、それをさらに深く考えることで別のTryに結びつくこともあります。

◆日常的に書き出す仕組み
　youRoomをコミュニケーションツールとして使っています。
　そこにイテレーション開始時に"あらかじめ"フリカエリ用のスレッドを立てておきます。
　そして、日常の開発などで…
「あっ！これはPかも」
「次はこんなこと(T)したいなぁ」
　…と思えば、すぐに書き込むようにしています。

　イテレーション終了時のフリカエリより先にPの内容によってはすぐに対応できます。
　早く対応した分だけ、チームのパフォーマンスが上がります。
＃なかなかチーム全員が開発に集中しているとPへの対応は後回しになりがちですが、そこはスクラムマスターがうまく動くことである程度はカバーできると思います。

◆Problemの深掘り
　これは最近やり始めたことです。

　Pに対してTを書き出しますが、中には･･･
「本当にそれでPは解決する？もう少し深く話した方がいいのでは？」
　･･･というものもあります。
　例えばPの原因が実は根深かったり、TがPの対処療法にしかなっていない等です。

　このような場合、(KPTが一通り終わった後)新しいホワイトボードにPを中心としたマインドマップを使って深掘りします。

　こうすることで「隠れていた本当のP」や「(Pに対する)より効果的なT」が見えてくることもあります。

＃(時間の関係で)全てのPを深堀りすることはできないことも多いので、チームが「これでできるのかな？」と半信半疑な雰囲気になっているPを取捨選択する必要があります。

◆ProblemのTry以外にも、チャレンジしたいTryを書く
　(Pとは関係なくても)「こんなことにチャレンジしたい！」という意味のTも書き出すようにしています。

　そしてそれがPJの方向性と合うのであれば、実際にその手を上げたメンバーを中心にして、次のイテレーションなどでやるようにします。

　(サインアップのように)「自分がやりたい！」と手を挙げることで、その質やコミット感が強くなるのが良い点です。

　Pに対するTは(改善ではあるものの)、(内容によっては)「できていないこと」にフォーカスが当たりがちです。
　ですので、前向きにやる…とのが難しいこともあります。

　それとバランスを取るように「チャレンジしたいT」を使ってみると良いと思います。

◆同じProblemが上がっていないかを見る
　同じチームで何度かフリカエリをやっていると…
「あれ、これって前も同じようなPが上がっていなかったっけ？」
　…というシーンが出てくることもあります。

　同じPが出ていると、ひどい場合には、チームの中に「どうせ変わらないし…」という負の感情やマンネリ感が出てしまい、あまり良い状態ではなくなります。

　そこで毎回フリカエリのKPTを(写真などで)残しておき、次のフリカエリでそれを眺めて、同じようなPが上がってないか？を見るようにしています。
　そのようなPがあるなら、その根本原因やTを工夫しないと、また同じ結果になってしまうのでチームで対応を考える…例えば、上に書いた「深堀り」の対象にするなど…必要があります。

◆気づき：暗黙知となったKは減っていく
　同じチームでフリカエリを行なっていると(PやTはそれなりに出ているのですが)Kは少なくなっていきました。
　チームの状態が悪くなったわけではなく、そのKがチームにとって当たり前になり「暗黙知」になったのです。
　そして「あえて書き出すまでもない当たり前のこと」になり、Kとして出ることがなくなったわけです。

　新しいメンバーが入って、そういう暗黙知を「K」として書き出すことで改めて、チームがその良さに気づくということがありました。


　このように、いくつか工夫はしていますが、最初に上げた「プロジェクトファシリテーション実践編 ふりかえりガイド」に書かれているほぼその通りです。

　大事なのは(リーダーなどを含めた)チーム全員が、そこに書かれている心持ちや姿勢を取ることができるか？ということです。
　その点では、(日常の)朝会に比べると少し難しいかもしれませんが、フリカエリをきっかけにチームが大きく変わることもあるのでチャンレジする価値はあります。

　[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」について考えることがあって、その後もチームで話すことがあったのでちょっと書いてみます。

　今のチームでも、もちろん朝会をやっています。
　そのやり方はほぼプロジェクトファシリテーション実践編 朝会ガイド(※リンク先はPDF)の通りです。
　
　以下は、(別のチームも含む)過去の朝会でやった工夫です。

◆司会者持ち回り
　最初はリズムを作るためにリーダーがやっていたのですが、リズムが出来てから、メンバーで司会者を持ち回りでするようにしました。

　背景として、若手メンバーに(チームの朝会とは言え)場を作って進めることを学んで欲しかった…がありました。

　やはり自分がそのロール…ここでは朝会の司会…を実際にやってみないと、考察や気づきには至らないこともあります。
　そして実際にやってみることで新しい適性に気づいたりして、レベルアップにもなりますので「いまいち、若手が積極的でない…」という場合にはやってみても良いかもしれません。

◆プチフリカエリ
　当時はなかなか頻繁な「フリカエリ」がなかなかできませんでした。
＃文化的なこともあるのかもしれませんが「PJが終わった後に一気にやる」というアンチパターンなのが多かったように思います(それでも「無し」よりはマシですが)

　とは言え、新人の方もいるチームで「頻繁なフリカエリとフィードバック」はきっと効果がある…と考えていました。

　そこで、「朝会の延長戦」的な感じで、毎週金曜日の朝会の後に「プチフリカエリ」と称してやりました。

　朝会と同じ場所ですので、チームの目の前には「今週にやったタスク」「次週にやるタスク」がタスクボード上に付箋としてあります。
＃弊社の標準的なタスクボードでは(カンバンとは違い)時系列で作られていることが多いのです。

　そのタスクボードをインプットにして、そこでKPTをサッと話しあうようにしました。
　対象期間は1週間ですので、15分程度ですぐに終わります。

　「フリカエリ」単独の場合…
「今回はちょっと忙しいからスキップしようか…」
　…になることもありますが、(フリカエリに比べて)朝会はスキップされることが少ないので、プチフリカエリを安定して行うことができました。

　改善する点としてはKPTを書き出していなかった(話すだけ)ので、ここは書いた方が良かったかも…と思いました。

◆退社時間の表明
　「今日は19時に帰ります！」と宣言します。

　こうすることで「今日やること」とのバランスが分かります。
　「今日やること」が残業そうな量なのに「定時で帰ります」と宣言していると、タスクが漏れていたり、勘違いしているのでは？と気づいたりします。

　また表明することで自分にも良い意味のプレッシャーがかかり(いつも以上に)集中できます。
＃「あれ？○○さん、19時過ぎたよ、帰らないの？(笑)」なんて声がかかって来ることもありました

　他のメンバーとのスケジュール調整ができるようになります。

　「19時に帰る」と表明したメンバーに仕様の相談、レビューなどをお願いしたいのでなら、18時半ではなく、15時とかにお願いする必要がある…で、あればタスクの順序を変えて…というようなことができます。
＃定時の予定を(PJ状況次第ではありますが)ちょっと気をつければ防げた的な予期せぬ割り込みタスクで影響を受けるのが好きでないので、このルールは助かりました。

◆夕会
　同僚が(朝会と)夕会をやっていたチームにいたこともあって、それについても考えてみました。

　予定通り行っていないことやハマっていることなどの心配事を夕会で言う(はき出す)ことができるので、退社後から朝会まであれこれ気にかけることが少なくなります。
＃特に週末などは効果が高そうです

　ちょっとやればクリアできそうなら夕会後、ペアプロなりで対応すれば、スッキリしてその日のタスクを終えることができます。

　また「本当に今日それが必要なのか？」「(残業が必要でも)他の人とペアでやったりすることで早くできないか？」とかを考えるインプットになり、結果的に不要な残業も少なくできます。

　ここで大事なのは、2交代制(でも人が変わらない)のPJのように「後半戦(長時間残業)」の開始の合図にしてはダメということです。

◆余談
　20人以上でA3のガントチャートで進捗を1つ1つ確認して、1時間以上やっている朝会(すでにそれは朝会ではないですが・笑)もあったりします。
　で、そこは指揮命令系統があるだけの集団でチームでは無いと思います。


　朝会はお金がかからないですし、特別な準備もそれほどは不要です。

　もちろんより効果を出そうとすれば、見える化された情報は必要になります。
　が、まずは集まって「リズムを作って」「隣の人が何やっているか知る」ようにしてみてはどうでしょうか？
　そうすると「もっとこういう情報が見えた方が朝会が効果的になるよね？」と改善していくと思います。