Redmine Advent Calendar jp 2011の25日目になります。
＃余談。本場のAdvent Calendarは「24日まで」を窓を開けていくことでクリスマスを祝うそうです。一方、【技術系】Advent Calendarは「25日」まで書くことが多いようです。
というわけでトリなわけですが、相応しい壮大な話ではなく「チームへのRedmineの効果」について書いてみます。
普段よく言っている「Redmineの効果」
先日、社内で「Redmineを活用したタスク管理改善セミナー」というのをしました。
Redmineの簡単な紹介から始まり、事例紹介を交えてそこから得た自分なりのメリットやTips、考え方をお話しました。
後半は参加者の方と「こんなことで困っていませんか？」などのディスカッションをしました。
その中で「Redmineを使った効果はどういうものがありますか？」と質問がありました。
私はたいがい「Redmineは【見える化】【トレーサビリティ】【開発リズム】を強化してくれるツールです」と「ツールを入れることが大事ではなく、そのプロセスやマインドを変えていくことが大事」の2つを合わせて答えています。
最近はそこに「教育に伴うチーム力向上の効果もあるかも？」と思い始めました。
教育効果があると思ったシーン
あるチームは、割とエンジニアとしての経験年数が少ない人が多かったのですが以下のような変化が出てきていました。
- 1：チケットの書き方が(良いレベルで)揃ってきた
- 2：(チケットに書く)設計やそれまでの経緯を共有することができて、設計の技術が上がってきた
- 3：コードレビューの結果を共有することができて、実装のレベルが上がってきた
1：チケットの書き方が揃ってきた
親チケットに要求をプロダクトオーナーが中心となって書いています。
その要求に対し「どう作るか？」と言った子チケットは担当するメンバーがそれぞれ自分で考えるような開発プロセスで回っています。
最初の頃はそのチケットの粒度が大きすぎたり、内容が抽象的過ぎることもありました。
また、粒度が大きすぎることも原因の1つとなって見積もり(予定工数)の精度が低いこともありました。
そんな状況からイテレーションを繰り返していくうちに、他のチケットの良い粒度を参考にしたり、自分が書いた粒度が大きいチケットを苦労しながら片付け、それをふりかえることで、分かりやすいチケットの書き方がチームの中で浸透していったように思います。
ここで言う「分かりやすい」とは自分以外にも「チームが見ても分かりやすい」ということです。
「チームが見ても分かりやすい」ということはチケットの引き渡しをやりやすいということにもなります。
2：設計の技術が上がってきた
1はチケットの書き方の粒度のお話ですが、こちらはチケットに書く内容の話です。
チケットに「この設計はどういう考えで、この結論、仕様に至ったか」を書くことがあります。
特に複雑な要求や仕様の場合「A案、B案、C案と考えたけど○○な理由でB案で行く」という風に議論の過程も書くこともあります。
ちなみに「設計書」と呼ばれるドキュメントには「どういう設計になっているか？」は書かれていますが、「なぜこれになったか？」はあまり書かれていないと思います。
それ故に次にその機能を修正する際に余計なリソースがかかっているように思います。
そういうチケットを担当することで、設計の仕方や思考の経緯を学ぶことで設計の技術を上がってきたように思います。
3：実装のレベルが上がってきた
コードレビューはRedmine Code Review プラグインを使っています。
それまでのやり方(コードをプリントアウトして行ったり、レビュー指摘内容はExcelに書く)に比べると、効率が良くなっていますし、指摘内容の共有をしやすくなっています。
もちろんレビュー指摘もそのままチケットに登録されるので「どのように対応したか？」まで共有しやすくなっています。
そのため若手や新しく入った方が、過去にどのようなレビュー指摘があったかを見ることでそのようなコードは書かないようになってきました。
またそうなることで、コードレビューアの負担も軽くなり、より有効に時間を使うことができます。
チーム構成やその入れ替わりの頻度などによっては、Redmine(ITS全般でも同じことが言えますが)のこういう側面に着目してみても、使うことによるメリットは大きいと思います。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
コメント