プロジェクトの情報の流れ方を整理した
まあ、サービス開発でなくともいろんな人がプロジェクトに関わります。受託だとむしろこの辺は最初にガッチガチに決められてしまう分楽なのかもしれませんが、社内だと「とっ捕まえて話しゃいいんだから」となって少し雑になっていた気がします。
ただ、ポジションによって、結果を求めるまでのタイムスパンであったり、求められる判断をするための情報であったりが違うので、情報の見せ方をコントロールしないと伝わらないな、と思って関わる人が少ないうちに整理しました。
とりあえずこんな感じ
汚い絵ですみません。最近、図で描き起こしてみると理解が早いことに気づいたので。
この流れは、以下二つの仮説に基づいています。
- あまりにすべての情報が一元的にありすぎると、ノイズが多くなってきて正しい判断ができないのではないか？
- 情報のフォーカスは現在被っている帽子によって変わるのではないか？
なので、それぞれのポジションのために適切に情報をフィルタリングしてあげよう、という前提での設計です。で、この帽子のかぶり換えをツールの境界線で促してあげよう、と。
もちろん手作業は辛いんですけど、なるべくトラッキングについては減らすようにしてます。なるべく普段やっている行動が紐付いて、やることのスコープを限定したいですよね。特にGithubをせっかく使ってるんで、DeveloperのやることはGithubを使うフローに寄せるようにしています。まあ、FeatureからIssueへの分割はそれこそが設計行為ですし、課題定義からストーリーマップとリリースプランの策定も要求を見つける行為ですから、ここまで機械的にしようとは思っていません。今はいいんだけど、人増えてきたときにどこまで大変になるかは読めていません。
少し具体的にトラッキングの話をすると、FeatureからIssueへの分割(つまり設計時)に、IssueにはFeatureに紐づくラベルを貼るようにしています。一つ一つのFeatureにはリンクをアタッチできるので、ラベルでフィルタリングしたIssueリストのURLをFeatureに紐付けてFeatureの進捗管理をします。FeatureMapの側はそれを元にステータス管理(ここは手動)。Mapのリンクはredmineに貼り付けてますので、リリースタスクの進捗は適宜確認してください、という感じです。人が少ないところは人力で頑張っております。
で、FeatureとIssueにはそれぞれ完了基準を作りました。これをどこで宣言しようか迷い中。
この後
毎週状況のサマリくらいはビジネスオーナー向けに発信しようかと。リリースレビューまで諸々うまく回せるようになるといいなあ。
