redmine-tokyo-14

redmine.tokyo 14 登壇「なじむ Redmine」のスライドです。内容は Slideshare に公開しているものと同一となります。2022 現在はスライドを Speaker Deck で一元管理しているため、こちらへも公開することにしました。

Transcript

1. なじむ Redmine Redmine を組織へ 「なじませる」ための施策と課題 @akabekobeko redmine.tokyo 14 - 2018/5/26 1
2. 自己紹介 プログラマー。Web 、モバイル、デスクトップまで なんでもやります。 Redmine への関わりとしては minimal at2 というテ ーマを開発しています。 ブログ アカベコマイリ Twitter アカベコ(@akabekobeko) GitHub akabekobeko (akabeko) 2
3. 今回のお話 以前ブログに書いた Redmine 運用シリーズ記事 Redmine 運用について 1/3 – はじめに Redmine 運用について 2/3 – 運用ルールと諸設定 Redmine 運用について 3/3 – 普及の施策と課題 から普及の施策と課題を要約した内容となります。 どのように組織へ Redmine を導入してなじませる か。そのための施策と課題についてお話します。 3
4. Overview Redmine 導入事例 現状分析 業務管理の Redmine 化 Redmine をなじませる 既存の仕組みを尊重する 活況を演出する マメなサポート 課題 4
5. Redmine 導入事例 5
6. Redmine 導入事例 私の Redmine 導入 & 運用経験は足掛け 8 年、2 社。 1 社目はソフトハウス。過去に Trac の利用経験もあ るため Redmine への移行もスムーズでした。 2 社目 ( 現職) は印刷・出版系の企業。 ソフトハウスほどの IT リテラシーはありませんが社 をあげて業務改善に乗り出しており、私が移籍する前 に Redmine を実験導入していました。 ここでは主に 2 社目の話をします。 6
7. 現状分析 1/2 Redmine を実験導入してみたものの本格採用には至 らない。では業務をどのように管理しているのか？ まずは 2 ヶ月ほど自分の部署に限定して様子を見てみ ることにしました。その結果、 業務は主に上長の手による Excel シートで管理 1 ～ 2 週間ごとの定例で進捗と問題を共有 定例の内容を Excel シートに反映 のような感じになっていました。 7
8. 現状分析 2/2 上長へのインタビューや定例で気になった点。 1. Excel シート運用にかなり時間を割いている 2. 同じ議論が回をまたいで繰り返される 3. ほとんどのメンバーに関係のない議論が多い 4. 進捗管理は作業の着手と終了のみで中間がない 5. 議事録をとらない Redmine なら 1 ～ 4 をチケット、5 は Wiki で対策で きそう。 8
9. 業務管理の Redmine 化 1/4 というわけで業務管理を Redmien 化。さきほどの課 題をひとつひとつ対策してゆきます。 1. Excel シート運用にかなり時間を割いている Redmine へ移行にともない Excel シート廃止 シート管理していた要素と Redmine の対応づけ 作業、担当者、進捗、期限あたりがあれば OK Redmine チケットですべて置き換えられそう 9
10. 業務管理の Redmine 化 2/4 2. 同じ議論が回をまたいで繰り返される 3. ほとんどのメンバーに関係のない議論が多い 課題と議論は主にチケットで運用 参加者は必要最小になる 他者へ共有したければウォッチャーを追加 議論が自動的にテキストとして記録 いつでもどこでも読める 10
11. 業務管理の Redmine 化 3/4 4. 進捗管理は作業の着手と終了のみで中間がない チケットのステータス、進捗率、期限を利用 担当者が更新するので上長は管理から開放 いつでもどこでも更新・確認できる 進捗率を出しにくければ 0 ～ 100% 更新も許可 注記へ現状を文章として書くことも進捗とする 進捗管理の目的は「現状」を把握すること 11
12. 業務管理の Redmine 化 4/4 5. 議事録をとらない 議事録ドリブンを提案 定例の前に Redmine Wiki へ議題を書く Wiki を読んでから参加 議題はチケットへのリンクとして記述 定例では Wiki をエディタ編集 & プレビュー 議題のみの Wiki を定例の場で埋める感じ 必ず議事録がとれて読み返せる 12
13. Redmine をなじませる 13
14. 既存の仕組みを尊重する 1/4 なんらかのシステムやツールを採用する動機として以 下があります。 1. 新しい課題を解決している 2. 既存の課題をよりよく解決 1 ならば賛同を集めやすそうです。 しかし 2 はどうでしょう。これは既存の仕組みや価 値観を否定することになりがちです。 素直に受け入れられるでしょうか？ 14
15. 既存の仕組みを尊重する 2/4 Redmine 導入事例にあげた組織は Excel シートで業 務を管理していました。これは 複数人の同時編集が難しい 履歴が取りにくい セル管理の破綻しやすさ などの問題があります。Web ベースの TDD/BTS に比 べるとメリットはほとんどないように見えます。 それでも紙の帳票よりずっとマシで、例え紙でも管理 されているだけで価値があります。 15
16. 既存の仕組みを尊重する 3/4 業務が管理されているなら方法は非効率でも現状が可 視化されています。 そして管理したいことは大抵、ヒト、コト、モノのよ うな典型があります。 よって表現が異なっても概念は一緒なことが多く、加 工すれば別の仕組みへ移行できるものです。 事例であげた Excel シートも大半の項目は Redmine チケットに対応づけ可能でした。 16
17. 既存の仕組みを尊重する 4/4 以上を踏まえ 既存の仕組みや管理者を尊重 します。よくぞ管理してくれていました、と。そして Redmine 導入や移行に際しては あなたの管理してきた情報は価値あるもので、それを より便利なツールに移行するだけ という点を強調。これは事実でもありますし、あえて 明示的に強く伝えることで雰囲気もよくなります。 17
18. 活況を演出する Redmine を導入しても使われなければ意味がありま せん。 そして使われるとしても、それが自発的でなければす ぐに廃れるでしょう。ではどのように動機づけする か。 ひとつの施策として活況の演出を提案します。 18
19. 活況を演出する 多くのユーザーに利用されて勢いのある状態を活況と 定義します。 この状態になれば黙っていてもユーザーは維持され、 増えます。 レストランに例えると、流行っている店は流行ってい ること自体が客を呼び込みます。 Redmine の場合、みんなに使われているから使うと なるでしょう。 19
20. 活況を演出する みんなに使われているように見せるため、Redmine 導入 & 推進者が積極的にコンテンツを増やしましょ う。 Redmine の主なコンテンツは Wiki チケット です。これらを増やしてゆきます。 20
21. 活況を演出する チケットよりも先に Wiki ページの構築をオススメし ます。理由は以下。 文章を書くだけなので心理的に楽 覚える規則がすくない Markdown/textile もさほど難しくない 開発知識なしに Web ページ作成を体験できる 環境面はすべて Redmien が面倒みてくれる Web ページ、便利なのはわかるけど難しそう... というハードルを解決 21
22. 活況を演出する Wiki ページに書くものとしては 1. 資料 2. 業務メモ 3. 議事録 4. 日報 あたりがよいでしょう。定期もの ( 例えば議事録) が あれば前回のを見本に書いてみてくださいという感じ で Redmine 経験の機会をつくりやすいです。 22
23. 活況を演出する Wiki ページが自発的に書かれるようになったらチケ ットの普及に挑戦してみましょう。 先に Redmine 導入 & 推進者がチケットで業務や雑務 を管理して、それを見本とします。 といっても Wiki に比べると心理的なハードルはかな り高いはず。 私が見聞きした範囲だとなにをチケットにすればよい かわからないという意見が多かったですね。 23
24. 活況を演出する なにをチケットにすればよいかわからない理由として は 1. チケット = 業務の可視化、に抵抗感がある 2. 業務を小さく分解するのに慣れていない 3. Redmine に関する理解の不足 という感じ。 3 は時間と経験が解決してくれるとして、1 と 2 は心 理的なハードルと概念の教育が絡むので解決するのは けっこう難しい。 24
25. 活況を演出する 対策として必ず短期で終了する雑務のチケット化はオ ススメです。例えば 備品購入 掃除 など。長くても 1 日かからず、効果を目視しやすいも のがよいでしょう。 目的と期間がはっきりしているためチケットにする抵 抗感はかなり小さいはず。 25
26. 活況を演出する このような感じで Wiki やチケット運用を体験しても らう人数を増やしてゆくと 演出されていた活況が本物 になります。Redmine 以外にもチャットワークや Slack なども組み合わせると更によいです。 Wiki やチケットを更新したらチャットでお知らせし ます。Redmine にもメール通知機能はありますが、 チャットなら同時・多数・即時に通知できるため活況 感を強調できます。 26
27. マメなサポート Redmine に関する 疑問 トラブル 要望 はマメに対応しましょう。こうした問題は Redmine と組織のギャップにあたります。ギャップは放置する と忌避感を生みます。 解決すれば逆に親近感を得られるでしょう。サポート がマメ = 迅速ならば活況の演出にもなります。 27
28. マメなサポート サポートの方法としては チャット Redmine Wiki Redmine チケット あたりが考えられます。コストや記録の観点から非同 期なテキスト ベースの仕組みで対応することをオス スメします。 対面は最後の手段です。 28
29. マメなサポート 近年は業務でチャット サービスが普及しています。 代表的なものだと Slack ChatWork など。このようなサービスを利用しているなら Redmine 専用のチャット ルームを用意します。 ここにはユーザー全員を招待して、Redmine に関す る議論ならなんでも投稿できるようにします。 29
30. マメなサポート チャットや対面などで Redmine に関する質疑応答や 知見がたまってきたら Wiki に FAQ などの形で記録し ましょう。 テキスト ベースな仕組みで固めているならコピペで 運用できます。 より高度に効率化するならチャットと Redmine を連 携させてこの辺を自動化するのもよいですね。 例えば Redmine ルームの書き込みを REST API で Wiki ページ化するなど。 30
31. マメなサポート チャット以外の対話方法として Redmine チケットも オススメ。 チャット代替となるだけでなく、チケットに親しむ機 会としても有用です。例えば プロジェクト作成依頼 リポジトリー作成依頼 といった Redmine 運用に関わるものはそれ自体をチ ケットで管理します。 31
32. 課題 32
33. 課題 ここまでの内容をみると大成功しているように見えま すが、 Redmine のなじまない人、部署がある タスクや工数管理に別サービスが利用されている といった課題もあります。 これは教育や不足している機能のプラグイン補完など による対応を検討していますが、道のりは長い... 33
34. 課題 最近、日本の Redmine 界隈で話題？になった記事 Redmine の直近の課題～競合ツールGitlab に対抗で きるか: プログラマの思索 ↑ で挙げられている内容は Redmine 運用していて強く 実感させられる課題です。 私的には環境面の運用が厳しい。インストール、更 新、プラグインやテーマの配布と互換性など。 34
35. ご静聴、 ありがとうございました！！ 35