こんばんは。本日はSWプロジェクトにおけるツールの活用を考える会 第五回勉強会にお越しいただきありがとうございます。今日は「開発ツール管理者の羅針盤」というタイトルで、Redmineを中心としたツールの活用についてお話させていただこうと思います。それでは、よろしくお願いいたします。
自己紹介
まず自己紹介させていただくと、私はとあるサービス会社でアジャイルコーチをしています。別部署の開発チームに自分のチームごと入り、ツールやチームビルディングのようなテクニックを使って、開発を成功させるという仕事です。
環境の道のり
まずは環境について。品川Redmineというコミュニティで発表させていただいた資料「数千人が利用する楽天Redmineの過去と未来」をベースに簡単に紹介させて頂きます。
Redmineは私が入社した時には、ほとんど使われていませんでした。やがて徐々に人気が高まり、1年ぐらいの間で1000人のユーザが使うようになりました。1000人というのは、当時のエンジニア人数のうち、70〜80％ぐらいの割合です。
なぜこうなったか？正直に言うと私にもわかりません。ただ、「Redmineがエンジニアに求められていた素晴らしいツールだった」ことを除いて考えると、3つのポイントがあったのではないかと考えています。
1つ目は本体の進化です。
RedmineはRailsを使ったアプリケーションなのですが、バージョンアップがとても簡単に行えます。幸いなことに、当時のRedmine開発者は非常に頻繁に開発を行なっていました。それに便乗して、こちらもどんどんバージョンアップを続けました。
Redmineのバージョンアップによって、様々な機能が使えるようになりました。特に印象的だったのは、確か0.9.xのときに、プロジェクトを作成する権限をユーザに付与できるようになったことです。これにより、ユーザは誰かに申請して作ってもらうのではなく、自分でプロジェクトを立ち上げることができます。
ツール管理者としては、何かしらを管理しなければならない気持ちが生まれますが、そうではなく、ユーザが選択できる状態にするのが有効ではないかと考えることができます。
2つ目はプラグインによる拡張です。
主に自部署のMTGで状況確認を簡単にできるような、ダッシュボードとなるプラグインをたくさん作りました。写真のプラグインは「史上最高のチームプラグイン」と言うのですが、チーム内で問題になっていた「誰が何をしているかわからない」という問題を解決するために作りました。
また、チケット駆動開発で有名なあきぴーさんがブログに書かれていたRedmineへScrumのアイデアを注入のアイデアに刺激され、当時なかったRedmineのバージョンごとのバーンダウンチャートを作ったり、Kanbanやバックログといったプラグインを導入しました。
3つ目はプロモーション作戦です。
私の会社では月に1回、開発部全体に情報共有するMTGがあるのですが、それを活用して機能の紹介やプラグインの紹介をしました。わずか数分の共有なのですが、Redmineに対する認識は増えたと思います。
しかし、使って欲しくても、なかなか使ってもらえないことはよくあります。経験上、いいものは2年後流行りだすという経験をしてきました。Jenkinsがまさにそうで、当時は一部にしか使われなかったものが、現在ではたくさんの人が活用しています。
そう考えると推進とかは余計なお世話なのかもしれません。それに、使ってもらえたとしても、それを有効活用してもらわなければ意味がありません。つまり、ユーザ数が増えても喜んではいられないのです。
結果的に、プロモーションなどは最低限がんばり、あまりがんばりすぎないようになりました（会場やや笑）。がんばりすぎなかったのが逆に興味を引いたのかもしれません。
使い方の道のり
次に使い方について経験をお話させて頂きます。使い方については、大阪で開催されたRxTstudyというコミュニティの勉強会で発表させていただいた「チームにRedmineを適用せよ！」をベースにお話させて頂きます。
2009年から2010年ごろの話になるのですが、当時、私を含め3名で開発を行う機会がありました。そこにRedmineを導入し、タスクを完全にRedmineで管理する開発をしました。
そしてパーキングロットチャートプラグインで状態と成果を見える化し、当時問題になっていた「成果がなかなか見えない」という悩みを解決しました。特に成果については、イテレーティブな開発をしていたせいか、どんどん結果が積み上がっていくのを実感しました。
さらに、業務の一部である「問い合わせ対応」にRedmineを導入しました。私が所属する部署が、開発を横串で支える部署であった影響で、様々な部署からの問い合わせが毎日たくさん届き、その運用に追われるという問題を抱えていたのです。
まずは、「どう申請したらいいかわからない」問題を解決するために問い合わせのパターンによって定型化をしました。できるかぎり申請者の負担を減らすためです。そして運用を改善しました。大きくわけるとポイントは2つです。
1つ目は、Redmineを通して依頼をしてもらうことです。メッセンジャーなどで「ちょっといいですか？」と聞かれるたびに、「次回からはRedmineに登録をお願いします」と伝えつづけました。個人に問い合わせが集中するのを防いだり、だれでも同じ運用ができるようにするためです。
2つ目は、運用を午前中にまとめてやるです。何かがあるたびに毎回対応していると、やらなければならない作業がどんどん遅れてしまいます。そこでできるだけ午前中にまとめて対応を行い、午後に来た依頼は翌日の午前中にまわすようにしました。
結果的に、数日かかっていた作業のほとんどが1日以内で終わるようになりました。もちろん、これ以外にも作業の選択や集中、運用の見直し、やらないことを定義・・・といろいろ施策を繰り返し行いました。
当時Redmineで取っていたデータが上の写真です。これは、当時の問い合わせ作業をカテゴリにわけて時間集計した結果です。メンバーにお願いして細かく対応した時間をつけてもらっていました。
月ごとの時間（コスト）をみると、平均100時間近くが使われていることがわかります。ひどい時は160時間近くも。当時は5人ぐらいのチームだったので、約1人月が運用で消える場合があるということです。これでは成果がなかなかでないのもわかります。
最終的にこの計測は面倒くさいので、件数だけ測定するようになりました。正確な時間がわかっても役に立たず「100時間かかってる！」ぐらいの測定で十分だからです。件数で測定しても、やはり重い運用は見えてきます。
そこで、当時1番重かったSubversionの運用をツールを作り自動化しました。運用内容はユーザやリポジトリの作成という定形作業だったのですが、アカウントの重複チェックや使いたいリポジトリの選択など、フォームに情報を入れてもらうだけで、こちらはボタンひとつで作業を完成させる仕組みを作ったのです。
現在は5分で運用が終わるようになりました。きちんとした計測はしていないのですが、感覚としてチームの90％以上を開発に向けることができています。
私は開発生産性を単純に開発時間と考えています。開発時間を増やすことで、すばらしいプログラムが大量に生産されるわけではないでしょう。しかし、すばらしいプログラムを書けるプログラマが育つ環境にはなるのではないでしょうか？
ちょっとだけ寄り道になりますが、こんなデータも最近取れました。
あるチームの支援を行う前と後のソースコミット数をグラフ化してみたのです。ちょっとわかりにくいかもしれませんが、支援を行う前は一部のメンバーが集中してコミット行い、他のメンバーのコミット数は安定していません。
しかし、支援を始め、開発に時間を使えるように改善を続けた結果、メンバー全員のコミット数が安定し、きれいな層になっていきました。つまり、できるエンジニアががんばる環境から、全員が開発に参加する環境に変わったと考えることができます。
ここまでがこれまでの発表を総括した内容になります。
では、最後にツール管理者としての道のりをお話させて頂きます。
（後半に続く・・・。後半と資料は明日公開予定です）
旅と子育てとアジャイルコーチのブログ「世界」 