サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

Redmine 改善 旧館より 開発プロセス

チームへのRedmineの効果

投稿日:2011年12月24日 更新日:


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全般でも同じことが言えますが)のこういう側面に着目してみても、使うことによるメリットは大きいと思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

-Redmine, 改善, 旧館より, 開発プロセス

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

新しいチームリーダーのことを社内SNSで知った

12月頭に全社横断的に(主に開発工程の)生産性向上をミッションとする部門に異動になりました。 で、「まずは顔合わせを…」ということになりました。 新しいチームで一緒になるチームリーダー(上司)は分かっ …

テーブル設計の指針(備忘録)

最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。 サロゲートキーとナチュラルキー 主キーの設定時に大きく2つの設 …

Professionalと思う3つの振る舞い

DevLOVE Advent Calendar 2012 “Professional”に投稿しました。 「自分にとってのProfessional」とは? 私が考えているProfessionalの定義は …

「Q&Aビンゴ」アクティビティ

(時期を逃した感がありますが)、新しくできたグループなど、あまり知らない人同士が集まった宴会で使えるアクティビティです。 「Q&Aビンゴ」 ビンゴの数字を(「くじ」ではなく)「質問に該当する人 …

我慢することの難しさ

もうずいぶん前の感じがしますが…2009年1月に納品したプロジェクトで、私が感じたことの1つに「自分には我慢が足りないなぁ」があります。 そのエントリにも書いていましたが、PJメンバーにいた新人と若手 …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。