microCMSではプロジェクト制を採用している。
目標を達成するために職種横断で3ヶ月単位で発足する形を取っている。

プロジェクトの進め方はOKRをベースにしており、

• 月：チェックイン
• 火〜金：朝会
• 金：Win Session

という会議体で進めてきた。

タスクはTrelloやNotionを用いてプロジェクト単位で管理するという形を取っていた。

タスクの優先度付けが難しい

タスクの種類が多岐に渡っており、バックログの総数は300を超えていた。

• 経営層がやりたいこと
• ユーザーからの要望
• Enterpriseからの要望
• 緊急のバグ

などが混ざり合っており、優先度付けが難しい問題があった。

プロダクトオーナー、あるいはプロダクトマネージャーといった役職が不在で、実質的にはCEOまたはCOOが担っていた。

タスクのスコアリングフレームワークを導入した

優先度付けのフレームワークはたくさんある。
参考：プロダクトマネジメントの優先順位付けフレームワークの究極ガイド

microCMSではRICEを少し拡張したSRICE（自作）というフレームワークを導入した。
SRICEは下記の頭文字を取ったものだ。

• Sales（売上）
• Reach（リーチ数）
• Impact（影響度）
• Confidence（確度）
• Effort（労力）

Salesを加えた理由としては、RICEだけでは顧客の中での優先度が定義されていなかったためだ。
簡単に言うと、上位プランのユーザー要望ほど優先するという概念だ。

また、Confidenceはその施策にどれだけ自信（確度）があるかという指標で、これは定量的に何人以上のユーザーから要望があるのかという観点でスコアリングしている。

ちなみに経営層がやりたいことはImpact、緊急のバグはConfidenceに高く反映される仕組みになっている。

スコアリングの計算式は次の形とした。
各評価指標を掛け合わせて最終的にEffortで割ることで、コスパの高い施策が分かる。

Score = (Sales × Reach × Impact × Confidence) / Effort

スコアリングのために当初はProductboardというサービスの導入を検討していたが、各指標の掛け算ができなかったため、泣く泣く諦めた。
代わりにairfocusというサービスを導入した。



上記のようにタスクのスコアリングを簡単に行うことができ、カンバン形式やロードマップ形式での表示も可能だ。

スクラムを導入した

プロジェクトの進め方を正式なフレームワークに乗せた方がうまく回りそうだよね、ということでスクラムを導入することにした。
元々アジャイルっぽい開発はされており、リリースもかなり頻繁に行なっていたので、移行もしやすいのではないかと思っている。

とはいえ、社内にスクラム詳しいメンバーがほとんどいなかったため、下記の書籍を読んで認識を合わせた。

こちらの本はマンガで図解もされていて、かなり分かりやすかったのでオススメ。

スクラム導入の狙い

プロジェクトマネージャー負担の軽減

今まではプロジェクトマネージャーが朝会の進行、Backlog管理・プロジェクトの進捗管理をすべて行なっていた。
スクラムを導入することでこれらの負担をプロダクトオーナー、スクラムマスター、開発チームで分散できると考えた。

人数が増えても耐えられる体制作り

プロダクトオーナーが不在のままでは、開発メンバーが増えていった際のBacklog管理がかなり厳しくなると想定していた。
人数の増加に応じてスクラムチームを増設できるようにすればスケールしやすいのではないか。

プロジェクト推進自体の改善

プロジェクト単位でKPTによる振り返りを行ってはいたが、プロジェクトによって実施するかどうかもバラバラだったり、あまり体系化できていなかった。
スクラムを導入することでスプリント単位でPDCAを回していけると考えた。

新しい会議体

スクラムイベントは次の形で進める。

• 月：スプリント計画
• 月〜金：デイリースクラム
• 金：スプリントレビュー（Win Session）、スプリント振り返り

今まで月曜に行っていたチェックイン（目標チェック）は一旦なくし、SlackやNotionによる非同期連携とすることにした。
現状行なっているWin Sessionはスプリントレビューと近しいと感じたので、Win Sessionをそのまま続ける。

これらとは別に職域別の朝会・定例は職域ごとに設定する。

マトリクス組織は難しい

日々の仕事において、プロジェクトがメインの人もいれば、職域側がメインの人もいる。
それぞれ均等にリソースを配分する人もいるし、複数プロジェクト、複数職域に関わっている人もいる。

ここに関しては完全にメンバーによってバラバラなので、各個人のリソース配分比率だけ経営サイドで決めておく形としてみる。
おそらくその辺りのことが良い感じに書かれているであろう、チームトポロジーも読んでみる。