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

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

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

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

関連記事

自分の仕事を説明できますか?

#ソース元は「ビジネスマンの不死身力:お盆休みは知人に仕事のことを話そう」です。 IT業界における「システムエンジニア」「プログラマー」「プロジェクトリーダー」「プロジェクトマネージャー」の仕事って、 …

Todoリストの更新タイミング

仕事関係のタスクを記録しているTodoリストがあります。 このTodoリストを更新するタイミングについて、(自分にとって)より効率良く仕事ができた方法を書いてみます。 Todoリストの更新タイミングを …

速効!SEのためのコミュニケーション実践塾[読書感想]

速効!SEのためのコミュニケーション実践塾 (日経ITプロフェッショナルBOOKS) 著者:田中 淳子 私が定期購読している雑誌「日経SYSTEMS」の前身である「日経ITプロフェッショナル」の初期に …

あるプロジェクトで工夫したこと

(QCD的に)成功したあるプロジェクトで工夫したことを備忘録のために書いておきます。 そのプロジェクトの特徴は以下の通りです。 【納期】サービスインの時期は確定しており、それまで約3.5ヶ月。 【要素 …

社内読書会をやってみて

年末年始の小休止中&次の書籍を検討中ですが、社内で行っている「アジャイルサムライ読書会」のことです。 この社内読書会をやり始めたきっかけ やりはじめた経緯は(当時、同じ会社だった)@mah-labさん …

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