【アレスグッド アドベントカレンダー Day6】入社2週目でチケット管理&プロジェクト管理を破壊＋再構築させてもらった

“師走”という言葉に相応しい日々を過ごしております、花です。名字です。
これまではITベンチャーでPdM兼UIUXデザイナーとクリエイティブディレクターをやってきて、11月から週半分ほどallesgoodにUIUXデザイナーとして携わらせてもらっています。

そう、先月入ったばかりだというのに、気がついたらアドベントカレンダーに名前を連ねていたんですよね。
というわけで、入社早々再構築したチケット&プロジェクト管理について、備忘の意を込めて書いていく。

必要なもの：Notion, 30分, お気持ち

こんな人に向けて

誰に宛てて書いているか明確にしないと書きにくい、というアドバイスをもとに…

• 少人数って規模じゃなくなってきたな…ってプロダクト開発現場のPdMへ

• Notionでのチケット&プロジェクト管理に興味ある人へ

• 記憶力の悪さに定評のある未来の自分へ

各々管理していたチケットたち 〜課題のはなし〜

allesgoodのプロダクトチームでは課題ごとにプロジェクトを立て、その中で施策を回しています。
そして当初、各プロジェクトでそれぞれNotionにページを作り、その中のDBでチケット管理をしていました。

課題としては

• チケットをプロジェクト横断したり移動したりしにくい

• 複数プロジェクトを兼務していると、自分のタスクをまとめて確認したり優先度やスケジュールをチェックしにくく、見落としが発生するリスクがある

• 各ステップをスケジュール管理のためにページにしているため、空ページが多く存在する

• チケットのフォーマットが決まっていないので、情報網羅がされていないチケットが生まれてしまう

すでに忘れかけているけどこんな感じ。
それぞれ自走力のある少人数チームだったからこそ、スピード優先して管理体制を整えることが後回しになっても、これまで大きな問題はありませんでした。PdMも一人で属人的な面も大きかったように思いますね。

単純にベストではないとは思うがいい管理方法がわからない、という状態だったかな。

数年後に入社した人を想像 〜目標方針のはなし〜

前述した課題があった中でどんな状態を目指して、管理DBを構築したのかを書いていく。
実際チームによってベストな状態は違うと思いますよね。
なので、「ここは同じでいけそうだな」「このポイントは自チームに合わせて変えるといいな」を考える参考にしてください。

まずは管理体制の必要条件

• プロジェクト単位, イテレーション(スプリント)単位で確認ができること

• 施策実施において必要な情報が漏れないこと

• 仕様策定, デザイン, 実装のそれぞれのスケジュールが紐づいていること

• 担当者, 優先度が見れること

• 親子関係のチケット管理ができること

• メンバー全員が自由にチケットを作成・変更できること

追加で目指した状態

• 各プロジェクト自体の状態や情報が一覧化できること

• 各プロジェクトおよびチケットを後々振り返りやすいこと

• 齟齬の発生を防いだり他の場所にある情報と連携しやすくすること（ID管理）

• 各メンバーが自分が担当の施策をまとめて確認できること

• 各チケットのリリース予定がわかること

• 一目で現在のステータスがわかること

• 今後のメンテナンスコストが低いこと

NotionDBというのは便利でして、というかどんどん進化しておりまして、大抵のことはデフォルトの機能でできるんですよね。実質、私は何もしていないと言ってもいい。

あとは管理仕様決めの”お気持ち”ですが、「3年後入社した人が、自分がいなくても必要な情報を見つけて活用できる」を目指しています。
これは私がドキュメント作成・管理でも常々言っているのですが、数年後に入社した人を想像する、UXデザインってことですね。

一元管理してViewで出し分け 〜解決策のはなし〜

今はこんな管理にしているよ、を紹介していきます。

まずDBは3つ。プロジェクト管理、チケット管理、スプリント管理。それをリレーションで繋いでいます。

• プロジェクト管理

ここにはプロジェクトを一覧化。
会社によってはObjective単位かもしれないし、プロダクト単位かもしれないし、単純にプロジェクトって呼んでいる大きい方針があるかもしれないですが、それを置いていきます。
今回は、ターム, PM, そこに紐づくタスク, タスク数をプロパティとして、そのプロジェクトのDesign Docなどの詳細はページ内に記載してもらっています。

• チケット管理

とにかく全てのタスクチケットをここに。
リレーションでプロジェクトとスプリント(Iteration)を紐づけています。
Notionの機能で簡単にスプリントが作れるようになったの、本当嬉しいですよね〜（DBのメニュー>カスタマイズからTasksをAdd、その後に現れるSprintsをAddするとできるよ）
各ステップの期日もそれぞれプロパティにしています。

また、これまで関連情報は紐づいているものの型がなかったため、施策に必要な情報のうち何が揃っていて何が揃っていないのか、が一目でわかるようにテンプレートを設定。
プロパティも重要な情報が見やすいよう少し工夫を入れています。

• スプリント管理

Notionの機能でベースを作成したら、スプリント期間を設定してリリース日を入れておくと、各チケットのリリース日をここから参照できて便利ですね。
ついでに、一緒に作成されるSprintBoardにMineのViewを追加して、インラインに展開しておくのがおすすめです。

これらをProject/Sprint単位で、DB参照して出し分け。
それぞれで過去に作っていたプロジェクトページにも展開が可能になっています。

〜作り方〜

説明より触って学べ、という気持ちでテンプレを置いていきますね。いいのか？いいよな？
▶︎ テンプレート

〜ご利用者さまの声〜

チームメンバーがこの前の振り返りで言及してくれたものを載せておきます。嬉しいですね。やった甲斐がありますね。

構築して終わり、にはしない強い意志

さて、大事なのはここからかな。

諸行無常。
どういう状態がベストなのかは、どうしても変わってきます。そもそも今回構築した体制がその時点でベストだと思ってません。
運用していく中でこれから出てくる課題をちょっとずつ改善したり、より良い方法がないか、みんなのコストが増えていないか、定期的にチェックしたり吸い上げることが一番重要ですよね。
みんなが気が付いたことを言い合える、コミュニケーション体制と低コストなメンテナンスを継続していきたい。（今回メンテナンスコストを重視、優先した部分もあります）

それにしても、入社3日目くらいの人間の管理提案を「なるほど！いいね、お願いしたい！」なんて快く受け入れて任せてくれたり、できたらできたで「使いやすい！いいね！」とコメントをくれる方々がすごい。
経緯も知らない相手にあれこれ指摘されたらなかなか受け入れ難いと思うんですよ、人間なので。すごいなって。最近そんなことばかり話しています。
どんだけ心理的安全性が高いんだって話なんですよね。
今日はこれが言いたかっただけなので、他はすべて忘れてOKです。

意外と長くなってしまった。

まだしばらく”師走”を感じ続けそうですが…
良いお年を。