こんにちは!2020年1月18日に開催した,NaITE#35 Redmineうまくつかえてる?~つかえませんでした!にならないために~ のレポートをお届けします。
開催概要
記念すべき2020年の1回目,通算で35回目の勉強会は,以下の内容でした。
コンテンツ | 概要 | 発表者 |
オープニング | 開会のご挨拶,NaITEのご紹介 | NaITE |
Redmine ペルソナ
~ Redmine さんってどんな人?~ |
Redmine とはどういったものなのか。どのように付き合っていくべきか。Redmine を擬人化して(ペルソナ)考えてみることで,日常に引き寄せて考えてみます! | あさこ氏 |
ボウコバ流チケット駆動のお話
~トラブル管理編~ |
良いチームとして活動していくにはどうすればいいか?そのために Redmine をどう役立てるか?
ボウコバ氏の長年にわたるチーム運営に関する知見を,情熱的にご紹介!ええっ,そんなことまで!? |
ボウコバ氏 |
Q&A | Redmine に関する皆さんの疑問に,ボウコバ氏が答えます。 | ー |
オープニング
まずは NaITE より開会のご挨拶と,NaITEのご紹介を行いました。内容は slideshare に公開していますので,よろしければご覧ください。
NaITEとして,今年度も様々な活動を行っていきます。”長崎” とついてはいますが,長崎県の存在を知っているあなたなら,参加資格はございます!我々はいつでも仲間を募集中です!
発表1 Redmine ペルソナ ~ Redmine さんってどんな人?~
(写真を掲載予定)
NaITEメンバー あさこ氏による,Redmine との向き合い方についての発表です。
タイトルの通り,Redmine を擬人化する,ペルソナを考えてみることで,Redmine にはどういうふうに手をかけてあげるべきかを身近な例に引き寄せ,掘り下げて考えてみよう!という試みでした。
そう,Redmine とはまるで「手のかかる子供」のよう…放置していてはいけないのです。使う人自身が親になったつもりで,きちんと手をかけて「育てて」いくものなのです!そうすれば Redmine はきっとアナタに応えてくれることでしょう…
発表資料は slideshare に公開しています。お時間許す方は是非ご覧ください!
発表2 ボウコバ流チケット活用術 ~トラブル管理編~
(写真を掲載予定)
Redmine はツールでしかありません。導入してすぐに効果があらわれるようなものでもないし,また導入した効果というのはチームによって差が出てくるものです。それは,導入する目的や方針がきちんと浸透していないせいであったり,実際の業務フローと Redmine が提供する機能の間にあるズレを,きちんと調整できていないせいであったりします。
そのため,Redmine を導入するにあたっては,既存プロセスの単純化(削れるところはできるだけ削ったうえで,Redmine とフィッティングしていく)と,常に Redmine を更新,保守し続けるという2つのことが重要になってきます。
…と,ここまでが前置きです。
Redmine 運用がうまくいかない,というと上記のような話がが必ず出てきます。しかし,これらのことは表面的な話に過ぎないのです。本当は,導入しようとするチームメンバーがその方針にきちんと納得できていること,そしてチームメンバーが常にチームにとっての最善を考えて行動できていることこそが重要なのです。
すなわち。
1999年にハーバードビジネススクールのエイミー・C・エドモンドソン教授が提唱し,Google の Project Aristotle によって検証された,「心理的安全性」を軸とした「良い成果を生み出すチーム作り」が先にあり,十分に検討された運営方針と Redmine を相互にフィッティングしていく継続的な取り組みがあってこそ,チームとツールが噛み合い,成果へとつながっていくのです。
残念ながら発表の詳細については,事情によりご紹介することができません。しかし,レポートを書いている私,個人的には本当に目から鱗の話が多くありました。非常に有意義なお話でした(特にオフショアとの関係などは素晴らしいものでした)。公開できないのが非常に惜しい!もどかしい!!もしご興味を持ってくださった方がいらしたら,ぜひ NaITE の勉強会へ足を運んでみてくださいね!
Q&A
参加した皆様からの質問に対し,ボウコバ氏の考えを惜しげもなく披露していただきました。一部表現を変えていますが,概要をご紹介します。
Redmine に興味を示してくれない,使ってくれない人に対してどう働きかけるのが良いか?
まず,自分の思う Redmine の使い方と,相手の業務プロセスとがマッチしていない可能性がある。相手の事情をよく聞き,不満などをしっかり聞き出し,それを自分たちの改善の機会としても捉えて,「いっしょに」プロセスを作っていく。OJTのようなことをやっていく必要がある。そこまで踏み込んで,相手にも「使ってよかった」という成功体験を感じてもらって初めて使ってもらえるものだと思うべき。
WBS管理する上でExcelとの共存などどのように行っているか?
ボウコバ氏のところでは,上長の報告にも Redmine で出力した情報を直接使っている。収集したいデータがあるならばチケットにカスタムフィールドを追加するなどして,Redmine で集計が可能な仕組みづくりをしている。
チケットのウォッチャー設定ポリシーはあるか?
たしかに役職が上がるにつれて,ウォッチャー設定がかさみ,メール通知の嵐,というような状況はあり得ると考える。ただ,ボウコバ氏のチームでは特にポリシー設定はせず,メンバーの自主性に任せている。それによって,通知メールをトリガに作業する人もいれば,単に「マイページ」の担当チケットを順に処理する人もいる,というように,各個人のスタイルを尊重することができている。
複雑なチケットが多くあるときに,視覚的に状況を把握できるようにする方法はないか?
チケットに「要約」というフィールドを追加することを考えている。また,メンバーにはチケットをクローズするときに情報を整理し,何をどうしたのかがわかるような「概要」情報を追加してもらうように伝えている。また,チケットの粒度を小さく保ち,ひとつのチケットが大きくなりすぎないようにして,情報を把握しやすくするように努めている。
バグ情報のチケットはどのように管理しているか?
「チケットを小さく保つ」という方針とも関連するが,バグについては「タイトルには現象をそのまま記述」「内容には本来期待される正常な挙動と,実際に発生した挙動を記述」という方針で「調査」という名目のチケットを発行する。実際に調査を行った時点で「調査」チケットはクローズし,「対策」なり「仕様変更」といったチケットを新たに起票する。
要件管理を Redmine でやるにはどうしたらよいだろうか?
ボウコバ氏のチームでは,要求元となる社内の別部門が直接 Redmine に書き込むような仕組みを作った。もちろん,ただ「書いてくれ」といってもダメで,きちんとテンプレート文章も整備したし,最初のうちは文章の手直しもこちらでやっておくなどして,「Redmine を使うとスムーズに進む」という状態を作り出す努力を重ねた結果である。
おすすめプラグイン
IssueTemplate と ViewCustomize は最強
おわりに
開催レポートとしては以上です。NaITE の活動に,ご興味持っていただけたでしょうか。
次回勉強会などについては,決まり次第ご案内いたします。
報告者:松山 拓広(NaITE)