コミュニティで得た価値観を「現場」に持ち込んでみた
はじめに
本エントリは「DevLOVE Advent Calendar 2013 「現場」」の34日目の記事です。
昨日の「新井 剛」さんからバトンを受けとりました。あらゆる場所を現場に、そこで最高の好奇心を
自分の現場は、自分がいる場所なんだ
というところが印象に残っています。とても素晴らしい記事でした。
自己紹介
大阪でBtoBの自社プロダクト開発をしていますkazinoupといいます。今年の２月から京アジャ、DevLOVE関西を中心にコミュニティの勉強会などに参加するようになって色々なことを学びました。それを「現場」で実践しようと取り組んだことについて今回は書いてみようと思います。
私は「笑顔のある職場」を目指して現場改善をする為に、いくつかのプロジェクトの支援やスキルアップの取り組みを行うようになっていました。これまでは技術的な支援が中心でしたが、コミュニティでアジャイルやスクラムというものがあると知り、徐々にプロセス改善にも取り組もうと動き出したそんなとき、あるチームが炎上したため、火消し役としてそのチームに入っていくことになりました。今回は約２ヶ月間その「現場」での取り組みを振り返ってみたいと思います。 かなり長くなってしまいましたが、よろしければ最後までご覧ください。
今回の現場の様子
プロジェクト全体が完全なウォーターフォール開発
社員１名（A子）、協力会社４名の５名のチーム ※プロジェクト全体は数十人規模
- A子は開発経験も少なく、協力会社の方と仕事をするのも初めてで混乱している
- 仕様を決める設計者は別にいて、随時新しい仕様が伝えられて機能拡張をしている
- 期限が近づいても完了の目処がたたない
- 残タスク、課題などが把握できず何をすれば終わりかA子自身が見えない
ということで、この状況をなんとかするためにチームに合流することになりました。 ウォーターフォールの現場にいきなりアジャイルやスクラムを導入するのは組織的にも技術的にも課題は多くありますが、コミュニティで得た「価値観」は持ち込めるはず！と思って、今やれることをやってみました。
まず、私が感じたこのチームの主な問題が以下の３つでした。
チームの問題点
- チームになっていない
- 自分の担当分の事しか知らない
- 自分の作業が終われば帰っていき、特定のメンバーだけが残業をしている
- 全体像が把握できておらず完了の基準があいまいでゴールが見えない
- どんな要求があって何ができればいいの？に対する明確な答えを持っていない
- 自分の担当が他のどこに影響するか分かっていない
- 仕様の確認は会話のみでズレが多く発生
- テストは？何すれば終わるの？などの基準もない
- 動作確認しないままタスクが「終わった」という人も・・・
- テストができずソースマージの間隔も長すぎる
- それぞれで開発を進めていて整合性がとれていない
- １週間から長い場合は２週間もマージがされずに開発をしていた
チームに入って取り組んだこと
これらの問題に対して以下のことを取り組みました。
チームのベクトルを揃える
まず最初にやったのは、チームとして５名のメンバーのベクトルを合わせることでした。 入って初日に、作業をすべてStopして以下のことについて話し合いをしました。
- プロジェクト全体の話や経緯、チームが担当するところが全体にどう影響しているかを再認識
- 理想的なチームとはどういったチームか？
- 理想的なチームになるために守るべきルールを決めよう！
- チームが目指すべき、達成すべきことは何か？
- チームが日々行っていることはなにか？
- チームのリズムを作ろう！
これらを話し合いは全員の意見を引き出しながらまとめて納得がいくように！というのを意識してやりました。PMやPLといった影響力のある人は参加せず、チームメンバーだけでやったことがよかった気がします。
結果として理想のチームを考えてまとまった、このチームの方針を以下に決めました。
- 全員野球
- 残業なし
- 品質重視
まず、全員野球は「仕様は全員が把握しておくべき」「変更点は全員が把握するべき」「特定の誰かしか知らないという状況をなくすべき」という理想の状況の意見を集約して決めた言葉です。 そして、残業をしないわけではないですが、極力しないためにどうするか？を考えて、残業なし＝悪 という雰囲気を、残業なし＝良 ということを考えたいという意見から決めました。 最後は共通部品を作るということで、品質重視でいきたい！というメンバーの意見が多く出てきたことから決まりました。
ここから、3でチームのルールを決めたのが以下となります。
- 元気に挨拶する！
- １人で残業しない！
- テストなしでチェックイン禁止！
挨拶は大事ですね。これを決めてから朝のMTGで全員が大きな声で挨拶するようになりましたが、チームがコミュニケーションを密にとるための最初の１歩だと思います。 テストモジュールはあとで詳しく書きます。
あと、１日、１週間でやることを出し合って、それをいつやるのがいいか？をチームで考えてきめました。やるべきことはなに？その目的は？じゃあ、いつやるのがいいか？といったことをチームで再認識できたことはよかったです。ここでチームにリズムができたことでスムーズに動き出したのは確かですね。 これらの話し合いで決めたことは、印刷しておいて常にチームのMTGの際には皆で確認しながら進めてもらうようにしました。
この取り組みで大変だったのは、PM層から「とりあえず２１時まで残業して進めてほしい」や、「なぜこのチームだけ止まっているのか？」、「やり方がぬるい」といった話を受け流すことでした。チームは問題を認識してるので協力的でしたが、PM層には理解できないところでなんどか衝突が起きました。どう進めようとしているか！求めている要求レベルは上げている！とりあえずは任せてほしい！というのを伝えてなんとか進めていました。PM層も話が分からない人たちではないので、最終的にはすべて任せてもらえたのでありがたかったです。
現状の見える化と完了の定義を決める
チームで一番の問題だったのが、何をもってこのチームの作業が完了するかが誰もわかっていないことでした。仕様が別で設計するメンバーがいるので、日々増えていく要求を対応していたり、設計者との認識のズレなども多く後で修正が発生することが多くありました。また、残タスク、追加対応、課題、仕様検討などがごちゃ混ぜになった表があるだけで、全体像を見れている人もいません。進捗管理もタスクが日々変わっていくためガントチャートのメンテナンスばかりで、チームメンバーが現状をきちんと把握することが困難な状況でした。そこで、取り組んだのが以下となります。
- 機能を32項目に分類し、この32項目が実装できれば完了という枠を作成
項目が「完了」となる基準とステップを定めて塗りつぶしの表を作成 ※ガントチャートは廃止
月曜日に項目の仕様洗い出しを設計者に確認させてもらう時間を確保
- 金曜日に月曜日で確認した仕様を動くものとしてレビューしてズレを修正していく
- 5回のサイクル（5週間）で32項目を終わらせる目標を立てて、１週間の完了の線をチームで引く
- 項目に担当者は作らず、朝会で塗りつぶしの表を見て、チームで目標の線を終わらせるタスクを決める
これによって既に実装済みのものも含めて、すべての項目について設計者への仕様確認と動くものでのレビューを毎週繰り返すというサイクルができたのでズレが減りました。何をもって完了にするか！をチームで話し合って基準を作ったのでズレも少ないですし、やることが明確になったことでメンバーもモチベーションを上げているようでした。そしてなにより、進捗の遅れ・進み、課題を全員が常に共有し、チームとして達成すべきラインがあることで、自分だけのタスクではなくチームとしてどう動くべきか？をメンバーが考えるようになっていく様子は私には衝撃を感じるほどでした。
とはいえ、最初は個人のタスクしか見れず、誰かだけが残業したり、チームとしての達成のラインを超えられないということが続きました。ここで「全員野球」というキーワードを何度も使って話しましたし、「周りからは自己組織化されたチームになるのは無理だと思われているが、そんなことはないはずですよね？私は皆さんを信じます。」ということも伝えました。そして、ようやく４、５週ほど進んだあたりで、自ら積極的にチームのために他の人のタスクをとっていったり、色々な提案が生まれてきた気がします。ここでラスト２週間でしたが、やはりチームになるまでは時間かかりますね。 このあたりのオーバーヘッドも考えて組織作りはするべきだと改めて実感しました。
テスト用のモジュール作成して毎日チェックインと動作レビューを実施
技術的な面でも大きな問題がありました。それが、同じチームで開発しているにも関わらず、１週間〜２週間マージがされずに各自のローカルで開発を進めていて、マージした段階で問題が起きるということでした。
ソース管理はTFSで行っているのですが、チェックインすることは特定の人以外ルールとして禁止されていました。このチームの場合、プロジェクト全体のリーダーのところに依頼を投げていましたが、多忙であるためどうしても遅れがでてしまいます。
また、作成しているものがUI部品ということもあり、その部品を使う画面がないと動作確認ができないということで、タスクが終わったとしても実際にそれを動かしての確認ができるのがもっと後という状況になっていました。Unitテストなどの自動化の経験もないですし、私も教えられるほどの力はありません。
そこで、チーム専用のテストモジュールを作り、そこに全機能のテストができるようにしました。私が入ってから最初のMTGしたあと１週間ずっとこのテストモジュールを作っていたので、「なぜこのチームだけ立ち止まっているんだ」という事も言われましたし、「早く課題をつぶしていってくれ」という依頼もありましたがこれだけはやらせてくださいとお願いして作りました。
これによって、チーム全員が実装▶︎テスト▶︎チェックインを毎日できるようになったので作業効率と、品質が劇的に上がりましたし、使い方の説明資料もなくして全てソースと動くモジュールを用意したことで、部品を使う開発者とのやり取りも簡素化されました。 動作確認もほとんどできていなかったA子も、後半は先にテスト画面を作ってから実装するなど、テストファーストの開発が出来るようになっていたのは嬉しかったです。
ただ、ここにも反省点はかなりあります。まず、サンプルという意識が強かったのか、ファイル名がめちゃくちゃだったり、テスト画面の作りが実際の開発にはまったく準拠していなくて、逆に混乱をまねいてしまったり・・・テストモジュールであっても動くものである以上、もう少し意識を高くして作成できていたらかなり違っていたのにな〜と思いますし、チームからもそういう声が上がってきていました。
日々のプチ振り返と、週１の振り返り
あとは、私からチームへのお願いとして、毎日のプチ振り返り（夕方にその日の作業の確認とともに５〜１０分程度で実施）と、１週間に１度のKPT（だいたい３０分くらい）をしてもらい、常に改善の意識を持つようにしてもらいました。ここにはあまり力を入れれなかったので、もっとうまいやり方があったんだろうな〜と思いつつ、それでもいくつか素晴らしい意見があがってきて効率が上がったのと、メンバーからの提案が少し増えた感じがしました。
結果
これらの取り組みの結果、他のチームよりも残業も少なく、かなりボリュームのある開発もスケジュールを調整しつつ、最終日に定時帰りができた事はよかったと思います。 その後も色々と問題もでてきて、もっと改善できた事は山ほどあるのですが、それでもコミュニティで得た「価値観」は少しは現場に持ち込めたのではないかと思います。
まとめ
いかがでしたでしょうか。アジャイル、スクラムなどのコミュニティで得た価値観は多いに今回の「現場」に役立ったことは間違いありません。 今後もコミュニティへの参加やブログなどの発信もやっていきたいと思っています。
次はchris4403さんにバトンタッチです。楽しみですね。 よろしくお願いします～。
