OSC2013名古屋で「Redmineの事例」を発表しました
2013/06/22 に開催された「オープンソースカンファレンス2013名古屋( https://www.ospn.jp/osc2013-nagoya/ )」にて、「Redmineでプロジェクトを【見える化】しよう！」というタイトルで発表をして来ました。
当日ご参加くださいました皆さま、ありがとうございました。
当初はあそこまで人が集まることになるとは思っていなかったので、非常に嬉しい気持ちでいっぱいでした。
スライドに補足をしつつ、当日の発表をふりかえってみたいと思います。
■話さなかった内容について
Redmineは、使い方によっては本当に色々と利用でき、僕も現場でさまざまな恩恵を受けています。
とは言え、便利な使い方すべてを網羅的に説明していては45分という時間に到底収まりきらなかったので、今回は以下の2点に絞り、発表させていただきました。
とは言え、上記2点だけでも結局時間いっぱいまで掛かってしまったので、ある程度絞り込んだ事は良かったと思います。
本当は、TiDD（チケット駆動開発） や VCS連携 と言った、開発者自身が色々と便利になる利用法について事例説明もしたかったのですが、そこら辺は詳細な解説本もいくつか出ている事もあり、今回は見送りました。
■会場への質問
会場内の方々に「実際に現場で何かしらのツールを利用しているか」という質問をしてみた所、以下のような状況でした。
・Redmine：半数近く
・Microsoft Project：少々
・Trac：少々
・TFS：少々
半数近くの方々が「Redmineを利用している」という反応だったので、少々驚きつつ一瞬その後の説明をどうしようか、と言う迷いが生まれました。と言うのも発表内容が「初心者向け」を意識していたので、Redmineの基本的な部分にそれなりの時間を割いている内容だったためです。
そのため「Redmineの基本」については予定よりも短めに説明し、その後の事例紹介の時間を多めに取ろう、という形で進行を考えなおしました。
■自身の進行管理について
要所要所に挟まれている上記のお姉さんの画像ですが、発表の進行管理用に意図的に挟んだスライドです。
当日は、デモに利用するRedmineを発表マシンの中に立てていました。
その中に専用のプロジェクトを作成し、Backlogsプラグインのタスクかんばんを用いて事前に単元ごとのタスクを作成しておき、上記のお姉さんのスライドが出る度にタスクかんばん上のチケットを1つずつ完了させていきました。
↓こんな感じ（これは最後のクロージングのタイミングでの状態ですね）
↓ちょっと拡大
一見するとけっこう無駄な事かもしれませんが、
- 実際にBacklogsのタスクかんばんをどんな感じで利用できるのかを説明する
- 本番でそれぞれの単元ごとにだいたい何分掛かったかを後から計測する
という2点において、非常に優秀な役割を果たしてくれたと思っています。
あと、途中に綺麗なお姉さんの写真が入る事で、会場の皆さんの気持ちも少しは和らいだのではないかな、と。
■国内事例の紹介
国内でRedmineを導入している事例として、楽天さまを紹介させていただきました。事前に楽天の藤原さん (@daipresents)にご相談させていただいたところ、問題ない旨を返答いただきましたので、引用させてもらっています。
藤原さん、ご快諾ありがとうございました。
■チケットのサンプルについて
サンプルとしてスライドに含めた上記のチケットですが、これは業務とは無関係なチケット内容になります。
実際に会場内でチケット作成のデモをした時には、以下のようなものを作成しました。
そこそこ笑いが取れて良かったです。
■表計算ソフトでのタスク管理
同時編集できない類の表計算ソフトでタスク管理すると、けっこう面倒な事になりますよね…という話でした。最近だとGoogleDocs等のオンラインスプレッドシートを利用すれば、同時編集とかは全然問題なくできますけども。
あ、ちなみに「1タスク＝1ファイル」は、僕自身が過去に出会った実話です。
■その他の便利機能について
機能がありすぎて全部は紹介できなかったのですが、このスライドの中ですと「マイルストーン（ロードマップ）」が非常に便利です。
これは、開発対象のソフトウェアのバージョン毎に、
- そのバージョンのリリース期日
- そのバージョンに対しての説明を書くWiki
- そのバージョンに含まれるチケット
をまとめる事ができる機能です。
更にはそのバージョンを複数作成して、未来の「ロードマップ」 を分かりやすく整理出来るようになるのが便利です。たとえば「既に運用が始まっており、定期的に新規バージョンのリリースをおこなう」ようなプロジェクトには非常にマッチすると思います。
■自社製品の宣伝
ぜひリリースされたら遊んでみてくださいね！
■Webサービス運用でのチケットワークフロー
この図で説明しているワークフローは、実際のチケットの遷移図とは異なり、少々簡略化しています。本当はもう少し複雑です。
会場でも説明したのですが、このチケット運用のボトルネックはやはり「プロダクトオーナーの承認が無いとチケットを先に進められない」部分にあり、そういった場合は例えば後述の「機能（扱う領域が異なる）単位でプロジェクト制を取り、承認権限を委譲する」ような方法を取る事で解消されたりします。
■Scrumへの適用
この写真に出てくるチームは、僕が社内で初めてスクラムマスターとして関わらせてもらったチームになります。
このチームは「Scrumに対する取り組みの歴史」だけで1時間の事例セッションが発表できるぐらいに様々なチャレンジをおこないました。この写真のように、バックログの管理にRedmineを活用したりもするのですが、それ以外にもオープンスペースを利用しての計画会議やふりかえり、ホワイトボードを利用したバーンダウンチャート等、うまくアナログとデジタルの良さを取り入れています。
最近は僕もこのチームから離れ気味なのですが、色々と「自分たちの開発プロセス」を日々カイゼンしており、今では下のスライドにあるような感じのオリジナルボードを運用していたりもします。「複数のバーンアップチャート運用」や「障害かんばん」等、「常に皆の目に届く場所にあって欲しい情報はアナログで見える化」を地で行っています。素晴らしいですね。
■社内での問い合わせ対応
例えば「利用する機能やその手順が固定化されているようなシステム」の運用であれば、ある程度「定型化されたマニュアル」が末永く有効になるものですが、
- PCの不具合（動作異常、ウィルス疑惑等）への対応
- 都度新しい種別の運用が発生するような作業
といった業務については、正直「定型化されたマニュアル」があまり役に立ちません。（もし作ったとしても、誰も見なくなり、その内に廃れてしまう）
そこでわざわざ抽象度を高めたマニュアルを作らずに「都度チケットに作業内容を記録する」事を可能な限り継続していく事に注力します。
すると、蓄積されていったチケットの数々がいつしか「過去の作業履歴データベース」になり、キーワードで検索するとだいたい過去にあった同じような作業がヒットするようになります。まったく同じ現象があった場合にはその通りに対応し、もし少し異なる事象であった場合には、他のチケットと相互に照らしあわせてより良い対処をする事で、厳密な運用マニュアルを作らなくても業務が進むようになる（はず）。これを「緩い手順書」としてスライド内で表記しています。
もしその中で「本当に定型化」出来る作業があった場合は、それを「マニュアル」として切り出せば良いわけです。
■「共同所有」という言葉
単なる語感の話かもしれませんが、僕は
- チームで発生するタスクや事象を【メンバー各自が自分ごととして認識】する
事に対して、「共有」ではなく「共同所有」という表現を好みます。
辞書で調べれば結局は同じ意味っぽいのですが、個人的に
- 共有
その情報・事象を関係者が認識している - 共同所有
その情報・事象を【自分ごと】として認識しており、何かあった際には自分も動かねばならない、という意識を持たせる
という勝手なイメージを持っています。
この感覚は「XP（eXtreme Programming）」というアジャイル手法の一種におけるプラクティスである【コードの共同所有】によって植え付けられました。
単に【何が書かれているかを知っている】意識と、【書かれている内容を知っており、もし何かあった場合には自分ごととして対処をしなければならない】意識とでは、実際に何かがあった場合の自主性に大きな差が出てきます。
そんな事を考えつつ、発表資料内では「共同所有」という表現を利用しています。
■コンピュータ・ソフトウェアを利用しない見える化
容易です。
思った瞬間から始められます。
例えば、僕がスクラムマスターとして関わったとあるチームでは、適当な壁が無かったので「社内のお知らせが掲載されているホワイトボード」の片隅を利用して「タスクかんばん」を作り運用を開始しようとしていたぐらいに、どこでも手軽に出来ます。（その後、専用のホワイトボードを入手しましたが）
とは言え、作るのは容易ですが、【継続して使っていく】事が非常に重要になってきます。ちょっとでも気を抜くと、すぐに廃れます。更新されなくなります。いつの間にか「見えない化」されてしまいます。
もしこれから「見える化」に着手しようとする方がいた場合、そこを一番注意して大切に育てていってください。
いきなりソフトウェアを導入するのは、正直オススメしません。「いつでも自分のPCで閲覧できる」事は非常に便利で生産性も高くなりそうですが、けっこう個人ごとの意識はバラバラな状態のまま使いはじめる事になってしまいます。
まずは自分たちの「見える化されたもの」を「共同所有」できている状態になりましょう。それさえ出来ていれば、「ソフトウェアを利用するかしないか」は、実はそんなに大きな問題ではなくなっていると思います。
見える化して「不便な事」が見えてきたら、後は「カイゼン」するだけです。
■Redmine Microblog について
初めてご本人に見せていただいた際に「非常に素晴らしい思想のあるツールだな」と感じました。今回の発表テーマが「コミュニケーション」でもあったので、引用させていただいております。
単純なTwitterライクなツールなのですが、「Redmineに人を集める」という目的においてはかなり有用に働くツールなのではないかと思っています。
実際に @dabits さんの職場でどのような形で運用されているかはご本人に聴いていただくのが一番良いのですが、実際に彼の職場では開発者以外の方も積極的に書き込みをするようになったとの事で、 上手く目的に対して機能しているのだろうなぁ、と感じさせられます。
■今でしょ！
単なる時事ネタ（ただし、妻に言わせると「化石級に古い」）です、はい。
会場内で叫んでくださった皆さま、本当にありがとうございます。
スベらなくて良かった…。
■オールインワンインストーラー「ALMinium」
実際にインストールしてみたら、非常に簡単に導入でき、かつ欲しいプラグインもたくさん入っていて、便利に使えました。
今回の発表もALMiniumがあったから非常に効率的に実施できました。
発表内での引用についてご快諾いただきました @mikoto20000 さん、ありがとうございました！！
■最後に
今回は、社内に数あるプロジェクトの「ほんの一部」を切り取って、事例を発表させていただきました。他にもまだまだ多数のプロジェクトがあり、それぞれのプロジェクトが日々「自分たちの仕事をより良いものにするために」努力・カイゼンを続けています。
弊社エイチームでは、そんな環境で一緒にお仕事をしてくださるようなエンジニアの方を随時募集しています。
「もの凄いスキル」を持っている必要はありません。
弊社代表が掲げている経営理念である
- 今から100年続く会社
- みんなで幸せになれる会社
に共感し、周囲のメンバーと共に成長を続けられる方であれば、大歓迎です。
もし興味ある方がいらっしゃいましたら、僕に直接ご相談いただくか、もしくは弊社にて隔週水曜日に開催されている「水9プロジェクト」へ足を運んでいただき、実際に現場の方のお話を聴いてみてください。
■最後に
今回の発表をおこなうにあたり、色々な方にお世話になりました。
登壇のお話をいただきましたjusの法林さん、発表資料にコンテンツを引用させていただいた皆さま、発表資料を作成するにあたりアドバイスをくださった各プロジェクトの皆さま、発表資料のレビュー会に参加してくださった社内メンバー、会社としてオープンソースカンファレンスにスポンサードしてくださった弊社社長および社長室のMさん、そして当日会場に足を運んでくださったすべての皆さまに感謝したいと思います。
本当にありがとうございました。
※また不足等を発見した際には追記するかもしれませんが、ひとまずこの段階で公開しようと思います。
