プロジェクトや組織を良い感じにしたい2022春

  • 組織

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

プロジェクト制を導入した|柴田 和祈
9月からOKRを元に組織作りを行なっていたが、10月に大きな方針転換をし、OKRで定めた目標が完全に意味をなさなくなった。この3か月で人数も倍増し、人の管理も難しくなってきた。
https://www.mythinkings.net/project-system

プロジェクトの進め方は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をそのまま続ける。

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

マトリクス組織は難しい

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

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

柴田 和祈 Twitter GitHub
株式会社microCMS 共同創業者兼COO / デザイナー兼フロントエンドエンジニア / ex Yahoo / 2児の父 / 著書「React入門 React・Reduxの導入からサーバサイドレンダリングによるUXの向上まで 」

Recommended