You meet Redmine.
- Redmine とは？
- さあ、はじめよう
- 何も始まらない
- 初めてのチケット
- 何がうれしいのか？
- 担当を変える
- 初めての終了
- 問題が発生した
- 今後こそ終了
- 問題がまた発生
- やりたいことが増えたら
- チケットが増えたらカテゴライズ
- 目標が見えたらマイルストーン
- コードと連携しよう
- 次はコードレビュー
- プロジェクトの中心がコードになる
- 責任が人ではなくコードへと
- 優先順位をつけて
- 過去の振り返り、それは検索
- メンバーの追加と権限
--
プロジェクト管理ツールである。
では、プロジェクト管理、とは何か？ 言葉を足すなら、プロジェクトの状態管理であろう。
プロジェクトの現在の状態が一望でき、特定の期日までにある状態まで進めていくこと。 その繰り返しが可能な状態であることをプロジェクトが管理できていると言えるであろう。
多くのプロジェクトでは、この状態管理ができていないため、 プロジェクト管理が強く望まれている背景がある。
これを望む人にとって Redmine は最良の選択肢の一つである。
これから開始するプロジェクトはもちろん、 現在進行中のプロジェクトでも構わない、 Redmine 上でプロジェクトを作成すれば、 そのプロジェクトの管理が Redmine 上で可能になる。
例えば、ここで伝えたい Redmine に関しての執筆をプロジェクトとして立ち上げてみようではないか。 プロジェクト名は「Writing about Redmine」とでもしておこう。
素晴らしい第一歩だ。
良い気づきだ。 これだけでは何も始まらないことに気づいただろう。
Redmine は人間の代わりにプロジェクトを管理してくれるツールではない。 あくまでサポートしてくれる存在である。
どうやって Redmine に対してプロジェクトを管理してほしいか、 一つ一つ教えてあげる必要がある。
そのプロジェクトで何をやらなくちゃいけないかリストアップするのがまずはとっかかりとなるだろう。
例えば、「Hello, Redmine」の場合、以下のようなタスクが考えられる。
- チケットに関する話の執筆
- ステータスに関する話の執筆
- コードとの連携に関する話の執筆
- 優先順位に関する話の執筆
- 検索に関する話の執筆
- メンバーと権限に関する話の執筆
- ブログとして公開する
このような感じでプロジェクトをブレイクダウンしていく。 ポイントは終了条件が明確になるように分解すること。
この終了条件を明確にするのは、 思った以上に難しいはずだ。
今はそれほど気にしなくても良い。 追って、これが明確でないと破綻していく過程を示し強く意識付けたいと思う。
Redmine におけるチケットはタスク実行券とでも言おうか。 このチケットを持っていると仕事ができます。 そんなチケットだ。
前章でリストアップしたものを登録していく作業だ。
一つのチケットで何をすべきか、 どこまでできたら完了か、そういったことを詳細に記しておき、 それにどれくらいかかりそうか、 別のチケットとの兼ね合いも考慮し、いつから開始していつ終わりそうか、 そういった情報を追加していく。
この内容は後から変更できるし、変更の履歴は見ることもできるので、 まずは一通り作ってしまおう。
これでチケットの一覧がタスクリストに、 プロジェクトの完了に必要な項目が一望できる準備が整った。
このチケット一覧ができて瞬間は喜びを感じただろう。 初めてのことは常に喜びが湧いてくると思っている。
しかし、冷静に眺めると、 Redmine を使わない時と何が違うかわからないだろう。 そう、この時点では何も違いがない。 むしろ、 Redmine を経由した分、余計な手間がかかっており無駄だ。
ここでステータスというものに注目してもらいたい。
これは、新規 -> 進行中 -> 解決 -> 終了といった状態管理ができる。
これによって、どのチケットがどの状態かわかるようになるのだ。
少し話がそれるが担当という概念についてから 担当とは、一個人を指すのではなく、役割にひもづく抽象的な概念である。 複数の役割を担う人がいれば、それは別々の担当になると考える。
これをベースに一人でプロジェクトを進めるには、 担当を二人分用意する。 作業を担当する自分と作業が完了したことを確認する自分だ。
作業中は、作業アカウントでログインし、チケットを解決まで進める。 確認作業に入る場合は、確認アカウントでログインし、問題なければ、チケットを終了する。
さあ、ここでチケットを解決まで進めた時に、 担当を確認アカウントにすることで彼に通知メールが届く（自分自身だが） Slack と連携してそちらへ飛ばすことも可能だ（自分自身だが）
このようにして非同期でチケットの状態変化を 然るべき担当へつないでいく仕組みが用意されている。
チケットを終了すると、チケット一覧から表示されなくなる。 やるべきことが一つ終わったことがわかる。 大変に喜ばしいことだ。 両手を挙げて喜んでいい。
さて、プロジェクトのタスクが終わりました。 うん、問題ないね。 だけで進むなら苦労する人は少ないだろう。
終了したはずの内容がやっぱここ直してと そういうのが頻発するのが常であろう。
Redmine ではそれを歓迎する。
「Hello, Redmine」でもある章で誤字が見つかった。 こいつをフィードバックしたい。 ステータスからフィードバックを選び、然るべき担当へ差戻す。 これだけで良い。 担当へはフィードバックの通知が飛び、 然るべき優先度で対応を行い、解決させる。 こういったフローもサポートしている。
再びチケットを終了し、チケット一覧から表示されなくなった。 やるべきことが今度こそ終わった。 また喜んで良い。
喜びスパイラルを短いサイクルでガンガン発生させることが肝要だ。
なぜか？
喜びほど人のモチベーションを上げるものはないと考えるからだ。
さて、少し嫌気が指すだろう。 強靭な精神を持っている人は、また喜べるチャンスが来たと、 この瞬間にモチベーションが上がって好循環を産み出していることでしょう。
いずれにせよ、問題は必ず収束し、そして発散する。 つまり、当初の問題はなくなりつつあるが、それ故に別の問題に気が付いたという状況が生まれうる。 これはプロジェクトにとって歓迎すべき状態だ。
そして冷静にその問題を分析してみよう。 収束へ向かう問題であれば、以前の繰り返しをすべきだ。 しかし、発散した問題であれば、別件として新しくチケットを切るべきだ。
なぜか？
別の問題だからだ。 これほどシンプルなことを往々にしてプロジェクト管理では混合し、 人々を疲弊させていくのだ。
このデスマーチへの予兆を必ず断ち切ろう。
問題、とは少し違って、 対応している内容に対して追加の要望が出てくることがある。 これもまずはプロジェクトにとって歓迎すべき状態だ。 やりたいことが見えてきたのだから。
ただし、プロジェクトの管理として、1つのチケットへ要望を追加していくと ステータスが意味をなさなくなる。
なぜか？
前回同様、別の要求だからだ。 これらを別々に管理しないでチケットが肥大化すると、 何が完了して何が対応中なのか追えなくなる。
もちろん、チケットの詳細を追えば可能ではあるが、 そんなことをするくらいならチケットを使う分、非効率とも言える。
ちょっとしたことに一々チケットとして追加していくと、 チケットが増えて却ってわかりづらくなるだろう。 そんな時、人はカテゴライズしていく。
Redmine にもカテゴライズの機能は標準で用意されているのでこれを活用しよう。
カテゴリごとにフィルタ表示すればぐっと見やすくなる。 チケットが増えて見づらくなるからチケットを追加しないという選択肢はないということを知っておこう。
通常マイルストーンがあって、それに合わせて目標を立てる。
便宜上、先にチケットを作成して、それがどの期日までにできそうか、あるいはやりたいか、 それぞれのマイルストーンを作成し、紐付けをしていく。
Redmine にはリポジトリと連携する機能が標準で用意されているのでこれを活用しよう。 コミットとチケットを関連付けることもできるので、 どの変更がどのチケットに由来するものかわかるようにしておこう。
後でチケットにフィードバックが発生した場合、 バグが発生した場合のトレースが容易になる。
これは現状プラグインの導入が必要となっている。 コミットした内容について行単位でチケット化できる。 何か気になる点をレビューして明文化しておくことで、問題の顕在化、共有をし、 品質の改善につながると考えている。
コードレビューのサイクルが生まれるとプロジェクトの中心はコードになる。
属人性がなくなり、コード自体が責任を担い、そのコードをチームで育てていく。
やりたいこともリストアップでき、 コードも共有でき、 レビューにより品質も高め、 すべて順調に行きそうだが、 マイルストーンにやりたいことが入りきらない。
これはもう仕方ない。 その時、やりたいことに対して優先順位をつけて対応していく。
びっくりするくらい単純なことだが、 ここまでに整えた状態だからこそ、 各情報に説得力があり、 どれをやり、どれをやらないか、という選択が可能になるものと思っている。
目グレップではない。
過去やった件について、ど忘れしていたり、あるいは完全に記憶にないことがある。 素晴らしい状態だ。常に未来で頭がいっぱいであれば理想とすべき状態だと考える。
しかし、どうしても思い出さなければならない。 そんな時は検索する。 そうすれば Redmine が答えてくる。 そのためにも日々のチケットの更新が適切な言葉で綴られていることが必須条件となる。
新規メンバーの追加はどの対応をしてもらうかによって適切な権限を設定しよう。 Redmine ではロールという区分けで権限の雛形が用意されている。 基本的には、必要最小限としたい。 余計な操作や情報は誤操作や情報収集を散漫にさせるだけなので。