自己紹介 栁生 広樹 (Hiroki Yagyu. ) 職業：プログラマ 年齢: 0x1A (0001 1010)2

趣味：個人でソーシャルゲーム作成、 銀細工、minecraft 趣味と仕事がごっちゃになっている人種です。 たまに minecraft の mod とかイジイジしてます。 プログラマと言いつつ、いろんな会社でプログラム以外の事を任されます。 それでは、宜しくお願い致します。

アジェンダ • Redmine とは • 利点と欠点 • 作業者、作業管理者それぞれの考え方、合わせ方 • 作業者且つ新人さんだよ、という方へ • PDCA サイクルと Redmine • Redmine 運用における KPT 法 • 最後に

徹底的に読ませますがご了承ください。 読み物としてどうぞ。 脱線や長文はわざとです。 その中から自分なりのヒントを見つけて、色々な見方をして頂けたらと思います。

個人用に作成した資料ですので どうぞお手柔らかに！

REDMINE (レッドマイン) とは

Redmineはwebベースのプロジェクト管理ソフトウェアです。タスク管理、進捗管理、情報共有が行えます。ソフトウェア開発やwebサイト制作などITプロジェクトでの利用に最も適していますが、それ以外の業務でも幅広く活用できます。 オープンソースソフトウェアですので、誰でも自由に利用できます。 http://redmine.jp より引用

REDMINE (レッドマイン) とは

• プロジェクト管理ソフトウェア

• プログラマにとっては開発初期からリリース後の対応までできるので便利

• これを使わない場合は Excel 様でじっくりコトコトプロジェクト管理

• 他にも Trac や Backlog といった方向性が似通った (ように見える) ものもある

• プログラマ以外でも、工数管理が発生するプロジェクトで利用されることがある

• 使い方のルールがないと、悪い評価を付けられがち

• 使い慣れた人からすると、「それは知らないからだ」「知らないことは罪だね」

少しでも皆さんの周りで Redmine の評価が上がるように これから悪あがきしてみます！

利点と欠点１

• チケット＝課題 １つ１つの課題が列挙できる • 課題や問題点をすべて覚えている必要がない (WEB 上でいつでも閲覧できる) • 設定すれば誰でも閲覧できる (もちろんプライベートなチケットも作れる) • カレンダーの表示や Wiki も機能として初めからついている • 内部は Ruby on Rails で動作しているからパッチやプラグインが書きやすい • データベースに直接クエリを発行すれば統計データも作れる • Redmine 上でファイル共有も可能 • チケット同士の関連性が細かく設定でき、状況を把握し易い • ユーザ登録さえしてしまえば、他社とのコミュニケーションも可能 • ガントチャートが分かり易くて便利 (ただし線形的に作業グラフが生成される) • メール通知機能が便利 (期日３日前にメールでお知らせ的な) • 個人の Redmine 上での活動は、活動履歴として閲覧が可能 • Git や svn, Hg, Bazzar に Mercurial といったソースコード管理システムと連携が可能 • プログラマ、エンジニアじゃなくても慣れれば分かり易い UI

まずは利点を列挙

これだけでも利点ばっかりだね！ これは使うしかない！

けれども一長一短。

もちろん欠点があります…。

利点と欠点２ 次は欠点を…

• 表計算できない (こういうことを言ってくる人がたまにいる…) • チャット機能がない (プラグインはある) • チケットを作るのが意外に面倒 (量や内容にもよる) • Redmine の運用上のルールが決まってないと、チケットを回すだけでもグダグダになりがち • 運用がグダグダになると、プロジェクト管理者の負担が劇的に増える • Redmine を立ち上げるのは楽。通常運用に耐えきる細かい設定をし始めると時間がかかる • 触れる項目が多すぎて初めて触る人には敷居が高く感じる (権限によって項目を減らす工夫が必要) • 実運用するにはトラッカーやロールなどの変更すべき点が多い • Redmine を使い始めると、様々な応用方法が思いつくようになるが、大抵下準備が大変になるだけ • Redmine の運用は全体の利用人数にもよるが、最初のうちは専用の管理者がいないと安心できない • 総じて、工数管理以外を Redmine に任せようとすると途端に設定項目が増える • 上記のことから最初の心理的障壁が大きく、プロジェクト管理者から利用の許諾を得にくい

“No Silver Bullet”(銀の弾丸などない) by Frederick Phillips Brooks, Jr. http://ja.wikipedia.org/wiki/フレデリック・ブルックス

9人の妊婦を集めても、1ヶ月で赤ちゃんを出産することはできない。 遅れているソフトウェアプロジェクトへの人員追加はプロジェクトをより遅延させるだけ、という事実を端的に表したもの。

実際に運用してみてこう思いました • 欠点らしい欠点は、改良するために工数を使えば乗り切れる (工数がある場合…)

• 知れば知るほど、どういった点で使うべきなのかが分かるようになってくる

• Redmine のもつ文化を理解することができれば、違和感がなくなる

• 運用方法をちゃんと決め、利用者が迷った時の指針を必ずどこかで示しておけばいい

• Redmine で「めんどくさい」と思った作業には、実は小ワザがある

• 一人でも Redmine に詳しい人がいれば、周囲への布教が可能

つまり…

作業者、作業管理者それぞれの考え方、合わせ方１ • Redmine の粒度のオススメは１チケット２～１６時間ぐらい

• それ以上に小さい粒度のタスクは纏めて、“時間を記録”などでつぶやく感じでログとして残すぐらいが良い • １６時間を超えるタスクはどこかで分割できないか疑ってみる • １チケット１時間以下の作業は絶対にチケット化しない

• これ以下の粒度はチケット更新の手間と作業量が比例しなくなって、Redmine の恩恵を受けにくくなる • １～２人での利用は想定していない。あくまで多人数開発が基本 • チケットをプライベートなメモ書き代わりにしない

• メモ書きなら付箋アプリで。共有できるような内容なら別 • チケットのステータスの意味をよく理解する

• 上長、作業者共に、ステータスの定義をしっかりとすり合わせること • 残すという文化を理解する。 間違ったことは将来間違わない為の資産になる

• Redmine はチケットを削除すると DB 上のデータごと消えるため、復旧は Redmine のログから行うしかなくなる • 運用上、チケットを削除する権限を一般ユーザから剥奪すると Redmine 管理者的には安心

• チケットを確認する意識や習慣は大事。 朝出勤したらまず Redmine を見て自分のタスクを確認すること • 書類は素直に Word や Excel で管理する。そのプロジェクト自体を Redmine に移譲するのは良い • チケット、フォーラム、Wiki だけでホウレンソウを済ませない。口頭での意思伝達は何よりも重要 • チケットにはクローズ要件を書いておくと「永遠の90%」を避けやすくなる

• 子チケットが増え続ける場合は、そもそもそのチケットが子である必要性を疑う事 • 書類の作成場所、ファイルの添付場所をしっかりと決めておく

• 作成した書類の紛失は工数を無駄にしたのと同じ。 同様に、探すのも無駄

長いですね、ごめんなさい

作業者、作業管理者それぞれの考え方、合わせ方２

• スケジュールは作業のチケット化に要する時間も含めて算出すること (見積期間に含めてしまう事もあるけれど…) • Redmine は PDCA を伴わないプロダクトに用いるには工夫が必要になるため注意

• トラッカー、ロールを専用に用意する必要があったり、チケットすら使わない場合がある為 • 期日は明確にしてチケットに登録すること。 見積もり段階で作業者と膝詰談義しておくと吉

• 開発者・製作者にとって「あ、それ伸びても大丈夫だから」という言葉はモチベーション低下の要因でしかない事を知る • Redmine が楽だからといって管理を疎かにしない。 上司は部下の活動やタスクに常に気を配ること • 自分に割り当てられたチケットは、誰よりも早く気付いてリアクションを取ること

• 心掛けの問題。 上長の反応が悪いと全体的に Redmine の利用頻度が下がるという現象を確認 • 残チケットを確認。 最終ログイン時間や活動履歴、更にチケット一覧から担当者と未完了ステータスで絞り込むといい • チケットの担当者と注訳を更新した場合には、その人に向けてメールが送られることを理解しておく

• 決してメールから目を背けてはいけない。それが3日後の期日を告知するメールだったとしても！ • 次の間違いを無くすには、今回の間違いを分析して残せばいい。 Redmine の残す文化を利用する • スタートボタンから、スタートアップフォルダを選び、Redmine のショートカットを入れておくと明日の朝から幸せになれる • 部下の活動履歴は毎日チェックする。 そして自分のプロジェクトのガントチャートを見て先の対策を考えること • 生産とは何か、Redmine を使いこなすには何が最善か。常に頭の片隅に置いておくこと • 部下から報告が上がってこなくても、担当タスクの予定工数や期日をチェックして危険を感じ取ること

• 時として部下のアラートは事態が深刻化してから上がってくるもの

特に管理職 (プロデューサ、ディレクタ他) の方は以下の点に注意

長いですね、ごめんなさい２

作業者、作業管理者それぞれの考え方、合わせ方３

• スケジュールに疑問を持ったら、Redmine の画面を見せながら上長に相談すること。そこに論理的な証拠がある • 工数欄はプロジェクト着手の前、そうでなくとも可能な限り以前から見積もりをするつもりで入力しておくこと

• それがスケジュール交渉の第一歩になる • Redmine 上では残せる記録全てを残しておくつもりで更新する

• 上司はあなただけのタスクを管理しているわけではないから、当然忘れることもある • 言った言わないの水掛け論は愚か者のすること。証拠はチケットで残しておけば誰も文句はいえない

• 日々の日報に追われているのなら、活動履歴を日報代わりにできないか相談してみるのもあり • Redmine の利用方法が決まっているなら一度立ち止まり、その利用方法が適切かどうかよく考えてみる

• 最初から完璧な利用方法などないし、規模や案件によって運用方法は変わるべきだと考える • チケットの更新し忘れは自分の作業を棒に振りかねないことを心掛ける

• チケットの更新は時間と共に履歴が残る。 チケットの更新がないと仕事をしていないように見える。 • Redmine を利用する上で改善できそうな事柄があったら、すぐに提案ベースでも Redmine 管理者へ報告すること

• 実際の Redmine 管理者が利用者でない場合、改善したほうが良いか判断がつかない場合が多い • 現場の人間しかわからない「使いやすさ」の感覚は、管理者にとって非常に重要

• ３か月後、そのチケットを見たときに流れが追えるような書き方を心掛ける事

• でも、汚いチケットは汚いし、臭いチケットはいつまでたっても臭い。綺麗なモノも時間が経てば色褪せていく • 貴方がプログラマなら No Ticket, No Commit! と言う言葉通り、チケットのないコミットは禁止 (VCS上の話)

• TiDD を導入する場合の話. でも Redmine があるなら実行してみる価値あり

特に部下 の方は以下の点に注意

長いですね、ごめんなさい３

作業者で新人さんだよ、という方へ これは Redmine の云々に限らず…

これまでのことを律儀に守ったからと言って、自分の上長がスケジュール、タスク、クオリティ等で

納得してくれるかどうかは別の話。

上長はクライアントや色々な所で頭を下げて仕事を円滑に進めようとしてくれている。（はず)

その為どうしても引くに引けない事情があることも多く、部下から小言を言われるとサンドイッチになる場合がある。

何が言いたいのかと言うと…

お察しください

おっと脱線！

PDCAサイクルとRedmine PDCAとは…

Plan … 計画

Do … 実行

Check … 評価、テスト、Checkback Act … 改善

PDCAと反復型開発手法 PDCA サイクルでありがちなのは、PDC までやってるのに 最後のＡである分析・評価をせず、次の設計を行ってしまうこと。

Redmine ではバージョンという機能が存在するため 1周(イテレーション)を 1 バージョンとして区切ってもいいかもしれない (Unity アプリや ソーシャルゲームなどの短期開発の場合)

これでは欠点の分析ができず、 次のイテレーションに移っても同じ過ちを繰り返してしまう！

Redmine 運用に KPT 法を導入する

KTP (けぷと) とは… • Keep…このまま続けること、維持

• Try…次回やってみたい事、挑戦

• Probrem…やめるべき点、問題点

PDCA サイクルの Check と Act に適用することができる改善手法 普通はソフトウェアの改善や製品開発のライフサイクルで用いられる

１つの案件が終わるたびに Redmine について 利用者の立場から KPT に基づいた振り返りをしてくれると

Redmine の管理者としては非常に助かる！ #本音を言えば、運用の正解なんてないから、KPT みたいな振り返りによって軌道修正するしかないんじゃないかな…

Redmine は初期設定のままだと設定が煩雑で何を見たらいいのかわからない。 でもその設定は変えられるのだから、まずは変えてみる。 そして利用者は「分かりづらい」「面倒くさい」と発言するべきだ。 積極的に発言していかないと、変えられるものも変えられない。

KPTの応用 KPTIRK(ケプターク) 採用のススメ 参考：http://blogs.itmedia.co.jp/hiranabe/2005/10/kpt2_3a79.html

Keep このまま続けること

Try 次回やってみたいこと

Probrem 問題点

Knowledge Keep の結晶化。Keepの中には、ナレッジとして抽象化できるものがある。ナレッジの表現形式としては、「名前付け」がまず必要。

Issue Problem の本質化。問題を見つめ、

本質的「課題」としたもの。「５回のなぜ」などで到達できるもの。

Risk リスクに感じること。これは、問題予備軍、future problem と考えられる。

Redmine の木

Redmine の使用感を KPTIRK によって改善していき より作業に集中できる環境を目指しましょう。 結局はRedmine を利用することが目的ではなく、利用したその先、 手持ちの案件を完遂しきることが目的です。 Redmine は木のようなものです。 根を張るまで少し時間が掛かるかもしれませんが しっかり根を張ってくれれば地盤を固め、 草木の屋根を提供し、風雨を防いでくれます。 ゆっくりと育てて行きましょう。

REDMINE 小技紹介１ チケット右クリックで 直接チケットを更新できる！ （この場合は担当者を変更）

チケット一覧が煩雑な時に…

Redmineのバージョンは 2.3.2 stable 2013-08-07 現在

REDMINE 小技紹介２

Redmineのバージョンは 2.3.2 stable 2013-08-07 現在

日付を○日前から YYYY-MM-dd に変更してくれる

チケットのダイジェストをメールで送ってくれる (要 cron 登録)

Redmine 標準のリマインダの内容を見やすくしてくれる

Github にあるリポジトリと Redmine を連携できる

Redmine の権限などの情報をまとめて表示してくれる

メンテナンス画面を実装してくれる

フォーラムを Q&A 形式に使いやすくしてくれる

ユーザのプロフィール上に担当チケットを表示してくれる

ウォッチャーをグループで登録できるようにしてくれる

プラグインの作成者様に多謝！

ここまで読んでいただき有難うございました。