概要
チームメンバーは5名以下のスモールチームですが、現在の体制となってから2年ほど経過し、取り巻く状況が変わってきたのでタスク管理方法をNotionのスプリントテンプレートをベースとした方法に変更しました
-> https://www.notion.so/ja-jp/help/sprints
2024年3月から以前の管理方法と並行稼働し、4月から本運用に入り、記述時点で2ヶ月ほど経過したので結果どうなったかや、至るまでの過程などを本記事で紹介できたらと思います
結果 ☺️
チームとして変化があった点
- スプリント期間を意識したタスク分解ができるようになった
- プロジェクト進行状況が把握しやすくなった
- プロジェクトに紐づく成果物の管理が容易になった
スプリントテンプレートを使った感想
- Goodポイント
- プロジェクトと関連づけたタスク管理できる点
- スプリント期間の柔軟性
- スプリントを自動完了できる点
- いまいちポイント
- 完了したプロジェクトを除外できない点
- 定期的なタスクの管理には向かない点(工夫が必要)
どんな形になったか 🎈
スクショでご紹介
ダッシュボード 📋
プロジェクト管理 📽️
タスクボード ✏️
スプリント管理にした動機 😎
課題感 💭
現在体制となった約2年前は、一定引き継ぎなどがあったものの情シスに関する業務全般の見通しがたっておらず
社内に落ちている玉と、ひたすらに投げられる依頼や申請を捌く用途で各々が何をしているかを記録できるカンバンボードを利用していました
業務を進めていく中でSaasの導入や大きな業務プロセスの改善などプロジェクトが発生していくるようになり、それを上記のカンバンボードに記載するようになりました
既存カンバンボードに乗っていたものは以下のとおりです
- 通常タスク (30分程度〜1日程度)
- 定期タスク (月初の棚卸しなど、特定時期に必ず実施すべきタスク)
- 申請事項 (承認ワークフロー経由で発生するタスク)
- 依頼事項 (問い合わせなどから情シスでのみ作業可能なタスク)
- プロジェクト
そうすると、1カードが表す粒度が30分で終わるものから数ヶ月かかるものまでバラバラになり、状況や進捗の確認が難しという課題が発生しました
またペンディングタスクや未着手タスクが積み上がりカンバンボード自体が肥大化してしまったという問題も発生していました
どう改善したかったのか 🤔
業務が複雑化・大型化してきたことで上記の課題が見つかり、以下のように改善したいと考えました！✋
- 1カードの粒度を揃えたい
- プロジェクトに紐づくタスクをリスト化し過去を振り替えれるようにしたい
- 日々の業務での発見された改善タスクなどをストックしたい
- カンバンボードをスリム化したい
5. 完全に手つかず、またはすぐに再開されないものを載せたくない
設計と実装
運用プラン
今のチーム体制と経験に合わせて以下のように日〜週〜月と運用していくよう定めました 🧑🎓
- カンバンボードは継続して利用する
- カンバンボードのライフサイクル=スプリント期間は1週間とする
- プロジェクトの管理は新規で形を作る
- 全体サマリを確認できるダッシュボードを作る
- 朝会は実施し、今日やることを会話する
- 週・月で振り返りを行い、次の期間に向けた業務内容を組み立てる(プランニング)
1. タスク用DBとカンバンボードの設計と実装
設計
こちらは集約し、種別毎に見るところをビューで分けられるよう以下のように設計を行いました
- タスクに該当するものを1つのDBに集約する
- PJに紐づくタスク
- 定期タスク
- 依頼タスク
- 申請タスク
- PJタスクと定期タスクはカンバンボードで閲覧できるようにする
7. 1カードはスプリント期間内に収まる内容に切り分けるルールにする
8. 必ず何かのPJに紐づくようにする
9. 表示されるカードは進行中スプリントに紐づくもののみにする - 依頼と申請はリストビューで閲覧できるようにする
実装
タスクDBでは、1カード(=1タスク)をスプリント期間内で実施可能なサイズに調整し運用できるようプロジェクト用のDBは別に用意しました(後述します)
カンバンボードは担当者毎にサブグループを設定し誰が何をしている、する予定であることが明確になるよう設定を行いました
申請や依頼事項については、元々ZapierでNotionにタスクを作る仕組みにしていたので、それを引き継いで使えるようにしたかったため、これ用のDBは作らずにタスクDBに集約することにしました
カンバンボードに表示することも検討しましたが、外部から起票する際に現在のスプリントに動的に紐づけることはできなかったため別立てのビューで管理するようにしました
2. プロジェクト管理の設計と実装
設計
プロジェクト管理では以下の点を満たすよう設計を行いました
- 各プロジェクトで何が予定され、実施中で、終わっているかの進捗管理ができること
- クローズしたプロジェクトでは何が実施されていたかの記録が残ること
- スプリント単位で何が実施されたのか記録が残ること
これは、現在のチームにおいての進捗が明確にわかり、一定期間(スプリント)で何をしていたかの説明コストをさげることを目的として設計しました
また、未来チームメンバーが入れ替わっても情報が残り、記憶以外の事実情報を参照できる状態を作ることも想定しました 🐲
プロジェクトの分類
タスクDBにはプロジェクトに紐づき作成するタスクから定期実施タスク、依頼や申請まで全て入ってくるため
プロジェクトの種類として大きく2つに分割しました
- 通常プロジェクト
- 定常プロジェクト
通常/定常の使い分けは以下のようにしました
- 通常プロジェクト
- ロードマップ等で実施するプロジェクトなど
- 主に自分たちでタスク切り分けを実施し、進めていくもの
- 定常プロジェクト
- 定期発生するタスクの親プロジェクト
- 例： 棚卸しのプロジェクト
- 依頼管理のプロジェクト
- 申請管理のプロジェクト
- 定期発生するタスクの親プロジェクト
スプリント紐づけ方針
また、各プロジェクトでスプリントへの紐づけ(プランニング対象)を行うかどうかはタスク発生時期がコントロールできるかの観点で決めました
- 通常プロジェクト
- 自分たちでタスクを生成していくため、スプリント紐づけをする
- 定常プロジェクト
- 定期発生の親プロジェクト
- 時期がわかるためスプリント紐づけをする
- 依頼管理のプロジェクト
- 不定期のためスプリント紐づけしない
- 申請管理のプロジェクト
- 不定期のためスプリント紐づけしない
- 定期発生の親プロジェクト
実装
- プロジェクトDBの作成
2. テーブル表示で行単位でプロジェクト表示
3. オーナーや期間などのプロパティ表示
4. 進捗率が分かるよう紐づくタスクのロールアップと、完了率をバーで表示 - 通常 / 定常の使い分け
6. ステータス定義に「定常」を作り、そのステータスが割り振られたものが定常プロジェクト
プロジェクト種別のようなプロパティ作成も検討しましたが、定常というステータスと捉えてステータスプロパティに組み込みました。
プロジェクトに紐づくタスクの確認は各プロジェクトを選択して表示することでわかるよう
プロジェクト用のテンプレートを用意して、どのプロジェクトでも同じ見え方になるようにしました
3. ダッシュボードの設計と実装
設計
ダッシュボードは手早く状況をキャッチできることを目的に以下のように設計しました
- プロジェクトは動き出しているものの進行状況(タスク消化率)が分かるようにする
- タスクは現在のスプリントと進捗が分かるようにする
- 依頼と申請はクローズされていないものだけ把握できるようにする
実装
- 最上部にはタスク、プロジェクト等の詳細ページ、DBへのリンクを配置
- 中段にプロジェクトとタスク状況を配置
3. 表示はリスト表示で担当と進行状況が出るようにしました - 下段には申請と依頼の進行状況を配置
5. こちらもリスト表示にしました
移行
棚卸し
- 塩漬けになっていたタスクで重複を消し込む
- 起票時からの状況変化でクローズ可能なものを確認し、クローズ
- テンプレートで不要なものを削除
データ移行
- 通常プロジェクト
- プロジェクトを作成し、TODOになっていたものをタスク化
- 状況に合わせたステータスを設定
- 定常プロジェクト
- 棚卸し系や月末月初の処理などに分類しプロジェクト化
- タスク
- 取り込み用のCSVを作成し一括取り込み
- プロジェクトの紐づけ
- 手作業辛かったポイント1, ただ一定のワードでまとまるようにして複数選択のプロパティ編集である程度効率的に紐づけ可能
テンプレート移行
- 開いてコピーして貼り付け*テンプレート数分実施
- ここが移行作業で一番つらかったポイント
- 定期実行の再設定
自動化処理の移行
- Notionオートメーションの移行
- Zapierでの起票の仕組みを移行
運用移行
- チームメンバーへの説明を実施
- 並行期間として1ヶ月をとり、基本は新しいものを使うよう依頼
3. 定期タスクなどのヌケモレはここで確認、定期系は人の方が意外と覚えていました - 朝会やふりかえり・プランニングで新しい仕組みと運用に慣らしていく
5. フィードバックを適宜もらい、改修する - チームメンバーと会話し旧カンバンボードはクローズ
終わりに
ここまで読んでいただきありがとうございました
構築自体は2,3日で実施することができました
構築と移行を行ってみて、意外とあっさりチームとしての移行が行えたので今のチーム状況にあっていたのだと思います (それだけチームとして成熟しているのかもしれません)
また、Notionでできることの幅広さも感じることができましたし、テンプレートで設定したアイコンでタスクが多い、依頼が多いみたいな情報を視覚でざっくりと把握できるっていうのはNotionでしかできない強みに感じました
(最近他のツール使っていないので、今どきどのツールでもできるのかもしれませんが 💦)
Notionにテンプレートの移行機能の強化だったり、APIでDBアイテム作るときにテンプレート指定できるようになる等、テンプレートをもっと有効に使える機能アップデート来てくれると嬉しいです
(あとスプリントテンプレートへの移行をもっと楽にできるようにしてほしいｗ)
Discussion