このエントリは？
このエントリは達人出版会から出版された電子書籍【開発現場に伝えたい10のこと】で私が書いた内容を許可を得て転記したものです。
2014/01/14(火)にはDevLOVE関西で書き手が集まる【「開発現場に伝えたい10のこと」それぞれの後日談】を行います。
よろしければご参加ください。
では少し長いですが、お付き合いください。
最初に行う3つのプラクティスと継続していくコツの目次
前半はチームビルディングにフォーカスを当てて、私がチームに参加した際にまず最初に行うことが多い3つのプラクティスについて書きます。後半はそれらのプラクティスを導入し、継続していく時に気をつけている点を書きます。
前半：私がチームに参加したら最初に行う3つのこと
- 朝会
- ふりかえり
- タスクボード
後半：変化を起こそうとした時の心構え的なこと
- 「やり始める」のは簡単
- 「やり続ける」ことの難しさ
- 「効果を出しながらやり続ける」には……
最後に
前半：私がチームに参加したら最初に行う3つのこと
私が新しく開発チームに入った際に最初に何をするか？と聞かれるとまずは、次の3つです。それは”朝会”、”ふりかえり”、”タスクボード”です。
いずれもチームの状況を「見える化」して透明化をします。こうすることで、チームが自分達で工夫して少しずつでもレベルアップしていく状態になることが目的の1つです。もちろんレベルアップすることでユーザー、顧客へ届けるモノ、価値を期待以上にします。
透明化が十分でないチームでは、「誰がどのタスクを持っていますか？」という小さな話から、「今回のリリースの日はいつですか？」という大きめの話のいずれでも「知らない」とか、全然違う答えをそれぞれ持ってしまいます。しかも答えが違うことを分からないまま進んでいることもあります。これではチームがうまく回りませんし、レベルアップして良い成果を出すことは難しくなります。
一方、”朝会”、”ふりかえり”、”タスクボード”がチームに馴染んでいれば、”ふりかえり”で、「これまでと比較して何がうまくできなかったのか？」「これまでより何がうまくいったのか？」を検査することができます。検査によって様々な情報を得ることで、どう適応すれば良いか分かり、アクションをしやすくなります。そして、そのアクションは”タスクボード”や”朝会”によって「見える化」されていきます。
以降はこの3つのプラクティスについて詳しく書いていきます。
朝会
参考：プロジェクトファシリテーション 実践編 朝会ガイド(リンク先はPDF)
“ちょうかい”ではなく“あさかい”と読み、アジャイルな開発手法では、デイリー・スクラムやスタンドアップ・ミーティングと呼ばれることもあります。
特徴として以下が挙げられます。
1：朝行う
2：15分以内
3：チーム全員が参加し、発言する
4：昨日やったことの確認、今日やること、困っていることを簡潔に話す(長くなりそうなら別途設ける)
5：立ったまま行う
目的の1つは、メンバーが「お互い何をやったか？やっているか？困っていることはないか？」を共有し、必要であればチームが何らかのアクションを取る状態になることです。それを毎日同じ時間に同じやり方で行うことで、チームに一定のリズムを刻むことも大事なことです。詳しいやり方は上記の参考文献に掲載されています。
以下は、私が見かけたアンチパターンと私なりの解決方法です。
1：長時間ダラダラする
Scrumではデイリースタンドアップとして「15分」と定められています。それ以外のプロセスでも「短く」というのは共通しています。長くなると集中力が途切れ、しんどくなります。それぞれの状況を短い時間の中で把握できないということ自体が課題でもあります。
また、個別の課題にこだわりすぎて時間が長くなるパターンもあります。このような場合、朝会の進行役が「その話は後で個別にやりましょうか？誰と誰とができますか？」と提案するとうまく収まることが多いです。
2：誰も聞いていない
メンバーが話している時、他の人(ひどい時にはリーダーさえも)が誰も「我関せず……」という感じで聞いていないことがあります。関心事が「自分のタスク」に向かっていて、「チームとしてこのプロジェクトをどうするか？」ということに向かっていないのが原因の1つです。
このような場合、ペアでタスクに取り組むことで、お互いの状況を把握し、チームを意識しやすくします。またインセプションデッキを使って、「プロジェクトの目標を明確にし、チームとして成功させる」大事さを伝えたりします。
時には、メンバーがリーダーに向かって「のみ」話して「報告」になっていることもあります。朝会はリーダーとメンバー間のみの進捗確認や詰問の場ではありません。これが悪い方向に進んでいくとリーダーは「指示」を出し、メンバーは「指示待ち」の姿勢になってしまいます。さらには報告しているメンバー以外は他人に感心を持たなくなり、チームでなくなっていきます。
3.：見えるものがない
それぞれのタスクの量や状況が見える化されていない中での朝会もありました。WBSがファイルサーバーの奥底に眠ったままだったり、リーダーしかメンテしないとこのようなことが発生しやすくなります。まずはその日と前日の分だけでも、見える化するところから始めます。
あるチームでは、タスクボードではなくRedmineを使っていたので、スプリントでやるチケットの一覧を印刷して貼り出し、それを見ながら朝会をしていました。余談ですが、このチームが成熟してスピードが上がっていく中で、Redmineにアクセスして、チケットを操作することがボトルネックになったこともあり、最後にはRedmineを使わなくなり、タスクボードのみ使うようになっていきました。
また別のチームでは、大きいモニタの前に集まって、Redmineのチケット一覧を表示しながら朝会をやっていました。この方法は効率は良いのですが、朝会までに最新情報に更新しておく文化がないと、朝会でRedmineの操作役が他のメンバーのタスクまでいじることになり、自分のタスクを自分でマネージメントする(自分でいじる)感覚が薄くなってしまいます。
これらのアンチパターンに陥らないように、また、良い朝会をするために私が工夫してきたことです。
1：観察する
(リーダーやスクラムマスターは)できるだけ口を挟まずに場の雰囲気やメンバーそれぞれの話し方や表情などを観察します。そうすると徐々に「AさんとBさんは息があってそうだな」、「気にかかっていることがあるのかな？」とか「体調が悪そうだな？」ということが分かることもあります。
「昨日やったこと」を意識して聞いてみるのも時々行います。もし昨日やったことが当初の予定と大きく違っていることばかりであれば、(割り込みタスクが多いなどの)何か問題を抱えているかもしれません。
2：質問の形を工夫する
「課長」や「プロジェクトリーダー」のような肩書きは、その人の発言が命令になり「自分達で考える」ことを阻害してしまう場合もあります。
よく言われていることですが「You(あなた)」でなく「(止まっている)このタスクを片付けるのに、私達がやれそうなことはあるかな？」のように「We(私達)」を使った形で話すようにすると「(話している本人も含めた)チーム全員で考える」意識を持ち続けやすくなります。
3：その場で貼る
「貼っていないですがXというタスクをします。付箋は後で貼っておきます」という話が出たら、その場でさっと書いて貼るようにします。「後でする」というのは忘れてしまいがちですし、目に見えないタスクが多くなってくるとチームの透明性を徐々に奪っていきます。そのために朝会で使うタスクボードには付箋紙とペンを用意しておくとさっと書けるのでオススメです。
ふりかえり
参考：プロジェクトファシリテーション 実践編 ふりかえりガイド – オブジェクト倶楽部(リンク先はPDF)
次にふりかえりです。特徴は以下のようなものです。
1：チーム全体が、行動可能な改善策を探し、試す勇気を得ること
2：チーム全体が、これまでの行動を思い返し、新たな気づきを得ること
3：チーム全体が、やってみてうまくいった行動を、チームに定着させること
4：チーム全体が、メンバーの多様性を受け入れ、信頼関係を築くこと
ふりかえりでは「KPT」(Keep/Problem/Try：けぷと)というフレームワークを多く使うので、主にその「KPT」のことを書きます。ふりかえりの目的は、「自分達がうまくできていること、もっとうまくできそうなことはないか？」を共有して、さらに「もっとうまくできるために何をすれば良いのか？」というアクションを共有することがその1つです。
以下はそんなふりかえりでの経験談です。
1：KeepはGoodなことから導き出してみる
慣れていないとなかなかKeepが出てこなかったりします。その場合、些細なことでも良いので「良かったこと(Good)」という観点で出してもらうようにします。その良かったことを起点にして「なぜGoodと感じたのか？」→「これからもGoodと感じることができるにはどうすれば良いだろうか？」→「それはKeep(継続できる習慣)だろうか？」という流れで出てくることもあります。
なぜそのKeepが出てきたのか分からないと、偶発的なものになってしまい次に活かせないこともあります。その場合、「それは続けることができそうか？チームの習慣になりそうか？」と話し合います。
2：Problemは「それで何が困ったのか？」を意識する
「○○ができなかった」というProblemがあった時に、「それでチームは何が困ったんだろう？」と話し合うことがあります。
できなかったことは事象ですが、それで何が困ったか？を共有していないと、それに対する効果的なアクションであるTryを出せないこともあります。話し合った結果、その○○ができなかったことではチームの誰も困っておらず、○○という行為自体が不要なことであることが分かるかもしれません。
3：Tryは「それでPはなくなるか？」を意識する
1度に全てのProblemに対処するのが難しい場合もあります。その場合、ドットシールなどで投票して、どのProblemに対処していくかを決めた上で、Tryを出していきます。
一通りTryが出た後に「これらのTryができれば、次回のふりかえりではこのProblemはなくなっているだろうか？」と話し合うことがあります。その答えがNoなら、まだ何かTryが足りないかもしれませんし、もしかしたらProblemの深掘りが足りないのかもしれません。
4：観察する
何度かふりかえりをやっていると、Aさんはテストに関するKPTが良く出るなどのように誰がどの領域に強い関心事を持っているか？など色々なことが分かってきます。意外と自身では何に強い関心事を持っているかハッキリ分かっていないことがあるので、それを認識することでチームのレベルアップに繋がることもあります。
これまでのKPTを写真に残しておき、定期的に時系列に見て、KPTの割合、それぞれの内容などを話し合うこともあります。その時に過去のTryが次のKeep、Problemのどこに行っているのかトレースしてみるのが良いです。
またタイムラインという表現方法を使って、この半年や1年などでチームやプロジェクトにどのようなイベントがあったか？またどんな感情の変化があったか？などをプロットして、そこからチームの変化や成長を実感するということもします。
タスクボード
最後はタスクボードです。
参考：川口 恭伸(@kawaguti)さんの「Kanban and Scrum」
タスクボードの目的の1つは自分達がどのようなことをするのか、そして今それがどのような状態なのか？を分かるようにすることです。これには、見える化、透明性の維持、周囲へのコミットメントなどが関係しています。また付箋紙などを動かしていくので、Doneに溜まった付箋による達成感、開発のリズムというようなものを感じることもできます。
私はまずはシンプルにTodo、Doing、Doneの3レーンからスタートします。
Todoのレーンでは「Doneの定義」や「Readyであるか？(タスクを着手できるか？)」などをチームと一緒に話し合ったりします。このようなポイントを見逃してタスクをやり始めると、手戻りが発生し、貴重なリソースをムダに使ってしまいます。
DoingのレーンではWIP(work-in-progress＝作業途中)の数に気をつけます。これを意識しないとすぐにマルチタスクの状態になってしまいます。マルチタスクはタスクのスイッチングコストが多くなって効率が悪くなります。これもリソースのムダになってしまいます。私はWIPは多くても3までとしていて、チームができたてだったり、メンバーのタスクマネジメントの経験が浅い場合は、1にすることもあります。
開発プロジェクト以外にも、保守プロジェクトや問合せなどがタスクとして存在しているチームの場合、このWIPの制限によって「どういう優先順を付けると顧客やチームにとって良いのか？」と真剣に考えることになります。このことで自分達の生産量が向上したり、周囲との仕事の受け渡しや頼み方などにも改善が見られることもあります。
Doneのレーンでは、Doneに付箋を移動する時に「Doneの定義」に注意します。タスクを開始するとDoneの定義が修正することも時々あります。それが共有されていないといざDoneになった時に、その際に「あれ？そうだったの？」というすれ違いが発覚し、リソースをムダに使ってしまいます。
アンチパターンとしては、タスクボードの更新が全然されないことがあります。これは、タスクボードがチームから物理的に遠かったり、普段見えていなかったりすると発生します。
また、更新がされない状態はタスクの粒度が大きすぎる時にも発生します。最初はタスクの粒度が大き過ぎ、進捗が分かりづらいという状況になります。しばらくすると(チームが工夫することによって)タスクの粒度が細かくなっていきます。すると今度は細かすぎたりして、タスクを書き出す手間がメリットを上回ってしまう感覚を持ちます。その結果として「チームにとってちょうど良い感じ」のタスクの粒度が共通認識として出来上がる……というパターンとして経験したことがあります。
タスクの粒度は、チームの成熟度などのコンテキスト次第ですが、私の感覚では見積もりの最大時間が4時間程度を1枚の付箋紙(タスク)とするのが良いと思います。だいたい1日で1枚はDoneに持っていける粒度でもあり、精神的にもリズム的にも良い状態だと考えています。
タスクボードは時間が進んでいけば、そのチーム独自のタスクボードになっていくことが多いです。Readyレーンを用意してそのタスクをTodoレーンに移動できるか検討したり、Doing以外にWillDo(やる予定)レーンを作ったりしたこともあります。またタスクの付箋紙自体も追加されたことを分かるよう印をしたり、バグを付箋の色で一目で分かるようにしたり、Small/Medium/Largeの見積もりを色で分けるようにしたこともあります。
後半：変化を起こそうとした時の心構え的なこと
後半は、前半で書いたプラクティスなど新しいこと、ちょっとした変化を持ち込もうとする際に私が心がけていることなどを書いていきます。
「やり始める」のは簡単
「最初の一歩が難しいんだよ」という声もありますが、今回前半に書いたことは、いずれも1人でもできることであり、その効果を周囲に伝えることもしやすく、比較的始めやすいことです。
タスクボードは「Myタスクボード」を作り、自分のタスクをそこでマネジメントしていくようにします。
リーダーや同僚などに「今の進捗はどんな感じ？」や「後はどんなタスクが残っているの？」などと聞かれた時に、そのMyタスクボードを見ながら、サクサクと答えていくと興味を持ってもらえることもあります。このようなことが何度かあると「チームでタスクボードをやってみよう」という流れも起きやすくなります。私もMyタスクボードを出発点として、最終的にはチーム全員のタスクボードまで成長していったこともあります。
ふりかえりも1人で始めることができます。
私は(チームのふりかえりとは別に)、自身のふりかえりとして週単位で行っています。1人だと、Tryなどに対するモチベーションを保つのが(チームでやるのに比べると)一工夫必要だったりします。私は、リーダーや同僚との雑談で「こういうことを今週は自分なりにTryしてみようと思う」と宣言したりして、アクションをするようにしています。
「やり続ける」ことの難しさ
ダイエットでも経験がある方もいるでしょうが、やり始めてすぐに効果が出るわけではない……と、頭では分かっていても、数日して何も変わらないと「これでは効果が出ないのかな？」「前の方が良いのではないか？」というような考えがムクムクと頭をもたげてきて、「続ける」モチベーションが弱くなってしまうことがあります。
それまでのやり方とあまりに違うような方法をとっている場合、「前の方が(慣れていたし)良かったんじゃないか？」という声も聞こえてくることもあります。忙しくなってくると優先順位を落としたくなるのも分かります。が、このようなプラクティスは即効性のあるものではなく、じわじわ効いてきて、気がつくとチームに変化が起きていた……ということも多くあります。
一方で、それなりに続けていると今度は「マンネリ化」という課題が出てくることもあります。「なぜそれをしているのか？」という理由が消えてしまい惰性になり、「もっとうまくやる方法があるのでは？」という考えやアクションへの意識が弱くなり、すでに実状と合わなくなっているにも関わらず、「前からやっているから」という理由だけで続けてしまっている……という状態です。
このように「効果を出しながら、やり続けていく」ことは、言い訳の天才でもある人間にとってなかなか難しいことです。
「効果を出しながらやり続ける」には……
自分達はもっとうまくできるようになるという「信念」(のようなもの)、「交渉力」そして「ちょっとした幸運」が必要だと感じています。
1：「信念」
「自分達はもっと成長していき、うまくでき、それで良い結果を出すことができる」という「信念」が必要です。
すぐに効果が出なかったり、社外の成功事例が耳に入ったりすると「やり方が間違っているのか？」と思ったりすることもあります。しかし成功事例はあくまでそのコンテキストでの話に過ぎませんし、自分達が同じ状況、同じ能力を持っていない限り同じ結果にはなりません(おそらく持っていても同じ結果にはならないでしょうが……)。
すぐに成功事例に飛びついたりせず、自分達にあったやり方、エッセンスを抽出して、また「どこがうまく行っていないのか？」を冷静に客観視していく必要があります。
自分達のコンテキストは自分達が一番分かっているはずですので、ある程度は「信じる」気持ちが必要になります。もちろん自分達のやり方に(無条件に)固執することは成長を阻害する大きな要因ですので、バランス感覚も必要です。
2：「交渉力」
従来の管理手法との違いや(形骸化した)社内ルールとの衝突など外圧が発生することもあります。その外圧に負けてしまうと、新しい取り組みが定着し、効果が出るまで続けることができなくなるかもしれません。また鶏(＝チーム外)の大きな声などによって自分達のやり方が脅かされることもあります。
そのような戦いに負けないように、そもそもそういう戦いをしないで済むように”根回し”などと言われる交渉力も少しは必要になってきます。
様々なタイプの上司や組織風土があります。「やり方は問わないので、とにかく結果が出れば良い」から「やり方は問わないがプロセスも報告し、もちろん結果も」というタイプ、そして「やり方もプロセスも詳細な報告を……」という感じです。
マイクロ・マネジメントが良い結果を生むことが少ないことは知られていますが、「何か得体の知れないこと」をされるのは気持ち悪い、そして自分の管理責任を問われると感じる上司や組織風土もまだまだあります。それぞれのタイプごとの関心事などを考え、うまく伝えるたり、見せることで味方にする……少なくとも敵にならないことが大事です。
多くの場合、これら「確実な成果は約束できないけれど、今より少しうまくできるようになる可能性がある」アクションに対しNo！と頭から否定されるフィードバックはあまり返ってこないと思います。もしあるとすれば、うまく「なぜするのか？」という理由や「どこを目指そうとしているのか？」などのゴールが説明できていなかったりするかもしれません。このように話を聞く側の心理的不安を取り除くようなアクションをすることも必要かもしれません。
3：「ちょっとした幸運」
本当に入ったプロジェクトがデスマーチの場合、なかなかこれらをやり始めることすらできないかもしれません。しかし、本当のデスマーチになる前であれば、少なくともこれらをやり始めることはできます。
また(数少ない話だとは思いますが)このようなアクションを一切認めない上司や組織風土も存在するかもしれません。そういう本当に「ひどい状況」に当たらないというのも、これら続けていくために必要な「ちょっとした幸運」です。
最後に
3つのやること、そしてそれらを続けることの私なりの方法を書いてみました。もちろん3つのことは他にもあるでしょうし、続けるコツも他にもあるでしょう。ぜひ皆さんのそういうコツなどを教えて欲しいですし、話し合ってみたいです。
これらをやり始めて、続けていったとしても、世界を、組織を変えることはできないかもしれません。しかし、チームは、自分は確実に変わっていくことができます。
DevLOVE関西のような多くのコミュニティでは、このような課題をテーマとして扱うこともあります。実際にアクションして解決するのはそれぞれの現場でのことかもしれませんが、ぜひコミュニティと現場を循環していくことで、自分の課題が解決し、その解決したことが、別の現場で困っている別の誰かの課題へのヒントになるサイクルが回るようになることを願っています。
※アイキャッチ画像：http://www.flickr.com/photos/stevendepolo/3605321899/in/photostream/
の内容を応用しています。
