第3回RxTstudyで「Redmineをチームに適用せよ！」を発表させていただきました。機会をくださった@yohhatuさんをはじめ、大阪の皆さまありがとうございます。すごく楽しかったです。
ちょっと前に、shinagawa.redmineでシステムやプラグインの歴史を共有させていただいたのですが、RxTstudyでは、その歴史の中で、チームはどのようにRedmineを使っていったかというテーマでお話させていただきました。
資料の一部には、海外からのアクセス対応としてなれない英語を使っている部分があります。ご了承下さい。資料はSlideShareとSpeakerDeckで公開しています。
チームにRedmineを適用せよ！
前職では、とあるプロジェクトでTrac導入したりしたりしていました。2008年に今の会社に転職しました。
私が入社してはじめての場所はメンバーが3名ぐらいで、社内のミドルウェア標準化などの作業を担当していました。とくにタスクが管理されていたわけではなく、MTGがたくさんあったりして、私にとってあまり気持ちよく働けるような場所ではなかったです。
現場改善として、Redmineを空いているサーバに入れ、チーム導入を試みたりしたのですが、全然受け入れられることはありませんでした。かといって、仕事の効率が上がることもなく、仕事がうまくいくこともなく、全体的に閉塞感があったように思います。
やっぱりそういう現場は会社で長く続きません。最終的には、チームは解散。私は、パートナーとして来ていただいている二人のエンジニアと組み、チームの立て直しを行うようになります。とっかかりとして、社内でよく使われる似たような処理をまとめた「Java社内ライブラリ」の開発を選びました。
開発手法はXPを選択。人数が少ないので、楽できる部分を増やすためにツールをがんがん試しました。結構な数のツールを試しながら、使うもの以外はCloseしていき、Redmine、ReviewBoard、Wiki、CI・・・ぐらいが生き残りました。
タスクのトラッキングをしたかったので、チームにお願いしてタスク管理はいきなりRedmineを使いました。はじめはメンバーも慣れていないので、週に1回1つの画面を見ながら、自分が中心にタスクを作り、作業を確認しながらCloseするペアRedmineをしました。
慣れてくると徐々にまかせるようにしていき、最終的には朝礼での状況共有、スプリントの終わりにCloseされてないものを個別に確認という形になってきました。
合わせてRedmineのプラグインを自分で作り、見える化することで「どういう状況なのか」をチームに共有しました。Mgrへの報告も楽になり、やることが明確になり、集中して開発する時間が増えました。
メンバーも徐々に増えていったのですが、朝礼によって、メンバー間の調整を促すことで、メンバー間コミュニケーションが蜜になってきます。週に1回のマンツーマンペアRedmineを通して、Redmineの利用方法を伝えたり私とメンバー間のコミュニケーションも増やしました。
仕事の成果は小さなものが多かったのですが、ちょっとずつ前に進んでいる感が生まれました。何よりもチームの雰囲気がよくなり、周りと比べても元気なチームになってきました。
2010年は社内のRedmineユーザが1000人を超えた年です。チームも安定してきた時期で、引き続きRedmineやプラグインを活用して改善を続けていました。マンツーマンペアRedmineは徐々に減り、朝礼で十分になってきました。
それなりに順調にタスク管理ができていたのですが、なかなか仕事が終わらなかったり、長期的な作業チケットどうどうするか迷ったりするようになりました。
仕事が終わらない問題については、Redmineのバージョンを付箋のように並べ表示しただけのパーキングロットチャートプラグインが効果的でした。
「○○をやります！」のようにバージョンに「達成すること」を記入して、「やること」をより明確に見えるようにしました。長い時間のかかる作業についてはバージョンをわけて対応したり、1つめのバージョンでここまで。2つめのバージョンでここまで・・・とロードマップになるように分割しました。
「達成すること」は「リリースする何かしら」として、中途半端なものがリリースされないように注意しました。一つ一つのバージョンを完結する作業としてやっていくと、半年位で上の写真のようにたくさんのDoneした作業が積み上がって見えます。
そして、私のチームは問い合わせが多い部署でして、ものすごく開発を圧迫していました。もともとデジエというツールを使って管理していたのですが、トラッキングに強いRedmineに変更しました。対応時間を入力することで作業コストの分析ができるようにしました。
チームの指標としてはベロシティを使い、「Redmineでアジャイルチームのスピードやパワーを見える化する」のように安定性をチェックするようにしました。
その結果、チーム状況の見える化から、成果の見える化につながりました。コストがかかる部分を分析し、改善ポイントを見つけ対応することができるようになりました。
また、過去のよくあるやり取りをFAQや手順にまとめることで、問い合わせや対応コストを減らすことも出来ました。効果的にRedmineを使うことで、Redmineはさらにチームに浸透していきました。
チームに力がついてきたので、昨年は現場支援として現場のチームと組んでプロジェクトを担当しました。メンバーでタスクボードを使ってタスク管理を行ったため、Redmineは使わなくなりました。
Redmineを使うことも考えましたが、異なるチームが混合で働くこともあり「一緒にやってる感」をだすためにタスクボードにしました。「それぞれのPCでRedmineを見る」と「一つのタスクボードを見る」はやっぱり違うんですよね。
結果的にRedmineを使わなくてもうまくタスク管理できたのですが、ふりかえってみると、今回のプロジェクトに関してはRedmineを適用する部分が少なかった気がしています。
設計のディスカッションなどはホワイトボードに書いたものを写真にしたり、その写真やその他の情報はWikiに整理しました。ソースに関してはコミットログやコメントに情報を残しています。
タスクボードに貼ると「ログが残らない」と思ってしまいますが、残したいものを残すようにしていると、特に困ることがありませんでした。
当時、チームでよく話題になったのがタスクのサイズ問題でした。いろいろやってみたところ、スプリント（イテレーション）のサイズにあわせて考えるようになりました。
例えば、スプリントが1週間なら、付箋には1〜2日のサイズでタスクを書き、最大で1週間のサイズにするようにします。これによって、スプリントで誰もが1回はDoneすることになり「やっている感」「進んでいる感」がでます。1〜2日サイズとすることで毎日の朝礼で1人が1つのチケットをDone！する形にしたかったのです。
1日以下の小さいタスクは付箋を使わないようにしました。これを付箋にすると朝礼が長くなってしまいます。
最近では、改めてタスク管理を考えるようにしています。
上の図はJeff Patton氏のCSPO研修で出てきた絵なのですが、Feature単位でタスクを考え、それをリリース、イテレーション、開発タスクへと分割し、開発タスクがDoneすることで、有効なパーツ（ソフトウェア部品のようなもの？）ができあがり、パーツがあつまって最小サイズのソフトウェアができあがり、それを継続的にリリースしていきます。
この考え方が個人的にわかりやすく、チームの評判も良かったので、今では上の図をベースにスプリント計画でユーザーストーリーマッピングを使い、ストーリーをタスクに分割する作業をチームでやっています。チームでタスクの大きさや呼び方をそろえ（ストーリーとタスクの2つを使っている）、ミニマムサイズのリリースを意識したタスク管理を行うようにしています。
このやり方を気に入っている理由は、動くものを効率的に小さくリリースすることで、より価値のあるソフトウェアを作っていく…という点を体験したかったからです。いいところや難しいところを経験するにはちょうどいい開発だったので。
ソフトウェアの価値を意識すると、おのずとユーザの要件をタスクに落としこむ部分に注意するようになりました。過去に参加した勉強会やカンファレンス資料からヒントを得て、「要件」を「きっかけ」としてとらえ、ユーザーとの会話から要求を見つけていくやり方を探求しています。
最近、「ユーザーエクスペリエンスのためのストーリーテリング」という本を、UX TOKYOさんから献本いただいたのですが、その中に登場するスプリングボードストーリーがとても面白く、ストーリー作りのときに実験でこの技を使っています。
例えば、「リリースを自動化したい」という要求が私にはあったのですが、「1日10回リリースできるようにして欲しい」という言い方に変えてチームに伝えました。
小さなニュアンスの違いでしかありませんが、単純に作業を自動化するのではなく、1日10回のリリースに耐え切れるプロセスを考えたり、実現に向けてアーキテクチャやプログラムをリファクタリングしたり、思った以上にいろいろ考えて対応してくれたのです。
詳細は「ユーザーエクスペリエンスのためのストーリーテリング」をぜひ読んでいただきたいのですが、ストーリーの中にある隠れた部分を、想像力や技術的アイデアで解決していく印象があり、チームでのディスカッションを聞いているととても創造的なやりとりになるので、今後もいろいろ試してみようと思っています。
そろそろまとめです。
Redmineをチームに適用し、プラグイン開発やアジャイルプラクティスなどを試してきましたが、Redmineを自分色に染めるだけではなく、Redmineのようなツールに合わせてプロセスを考えるのもひとつの手です。カスタマイズしすぎると、いつのまにか便利が不便になってしまうかもしれません。
また、こういうツールはツールを「使うこと」が先行してしまい、「使う目的」を見失うことが多いので、使い方と考え方はセットで利用者に伝えていく必要があります。
そして、なによりも、「使わない」という選択を頭に入れておくべきです。コンテキストが変化したときに「従来のやり方」が最善であるとは限りません。思い切って違うやり方を導入することを考え、より柔軟に変化に対応していくほうが、私のチームにはマッチしていました。
今後は、私のコンテキストだと「大人数」があるため、JIRAやTFSのような開発プロセス全体をカバーする統合的なツールをベースに、自社のプロセスにマッチしたツール導入を考えていこうと思います。ただ、Redmineはなくなるわけではなく、私のチームのように問い合わせ管理、バグ管理といったRedmineを適用しやすい仕事で残っていくかもしれません。
私のチームはツールからプロセスを考えるようになり、アナログなツールや会話の活用へと変化してきました。これが成熟すると、またツール導入を考えるかもしれませんね。
どのツールがいいか？どう使えばいいか？という質問をよく頂くのですが、「そもそもなんのために使うのか？」を考える必要があります。そこがブレるとツールを最大限に生かせないからです。ツールはツールでしかありませんが、うまく使うことによってとても大きな恩恵を得ることができます。ツールの進化により、恩恵はより大きくなってきたので、うまく使うにこしたことはないはず。
どう使うかは人間の考える事です。そして、自分以外が使うツールの場合は、使う相手のことも考える必要があります。いくら道具であっても「相手に対する思いやり」って重要です。
*
長くなってしまいましたが、shinagawa.redmineでの発表と、RxTstudyでの発表で私のRedmineナレッジや経験全てだと思っています。現場改善に取り組まれている方のお役に立てれば幸いです。また、こういった事例発表がどんどん共有されればいいなぁなんて思っています。
ありがとうございました。
*
旅と子育てとアジャイルコーチのブログ「世界」 