個人開発でTobiishiというスクラム支援サービスを開発しローンチしました。この記事ではプロダクト開発観点から、どういうことを考えてプロダクトを構築したかなどをご紹介します。
作ろうと思ったきっかけ
スクラムでPBI管理とスクラムイベントの管理ができるいいツールがあるといいなあ……と思い色々なツールを調べたところ、
- 各種イシュートラッカー
- PBI管理は、まあできる
- 自由度の高いツールだとフィールドや状態を足しすぎちゃって罠にハマるみたいな未来は見える
- スクラムイベントの管理はできない、しづらい
- (イシュートラッカーなので当たり前だが)
- 頑張ってWiki機能などを使えばイケる・・・か?
- PBI管理は、まあできる
- Notion
- 色々設定すれば良さそう
- チームにあった形で適応もできる
- Notion職人と優れたスクラムマスターと金払いのいい雇用主が必要
細かい設定をせずに使える、スクラムイベント管理とPBI管理ができるツールを作ろう
→ できた!
プロダクト開発にあたって事前に勉強したこと
開発にあたって、行き当たりばったりではローンチまで辿り着けないのでは、という思いもあり、開発前にちょっとだけ勉強しました。
- プロダクトマネジメントのすべて を読みました
- 個人開発ということもあり特に Part I/II が参考になりました
- 特にプロダクトの4階層 Core/Why/What/How という考え方について
- この記事でも次のセクションで4階層に沿って紹介しています
実際に考えたこと
4階層を意識しながら、リーンキャンバス、ペルソナ(、、、の代わりに状況・課題・動機・行動)、North Star Metricを考えました。この辺りはAIと壁打ちしながら進めました。
それらを擦り合わせながら考えた、現時点での4階層を紹介します。
Core: 中心的価値
スクラムガイドに沿ったイベント運営を支援するサービスを提供します。チーム全体が価値に向かって動けるようにすることがサービスの目標です。
Why: なぜやるのか
- スクラムを導入したいが、経験のあるスクラムマスターがいないチームでは、スクラムガイドに沿った運営のハードルが高いと感じています。
- どうしてもツール(GitHub Issue, JIRA, Notion, Redmine, Linear, etc)をどう使うかに意識が入ってしまいがちであると感じています
- ただそれらのツールはスクラムのために作られているわけではないので、最適ではないと感じていました
- スクラムのためのツールがあれば、状況が改善するのではないかと仮説を立てました
- スクラムを運営していても、いつの間にかスクラムイベントやスクラム自体が形骸化してしまうことがあります
- フィーチャーファクトリー化してしまったり、ゴールや合意の形骸化、振り返りの形骸化、リファインメントの不在など、長く運営しているチームでも問題が発生していることを観測したことがありました
- しかもそれらはメトリクスからは検知しにくいことから顕在化しにくく、ただモヤっとしながら開発を続けていることがありました
What: なにをするか
- スクラムガイドの本質(透明性・検査・適応)を実践に落とし込んだツール
- スクラムイベントごとのページ
- 改善履歴の記録機能
- プロダクトゴール/スプリントゴールの設定・可視化機能
- DoDの設定・可視化機能
- PBIの管理機能
How: どうやるか
Webアプリとして実装し、以下のような点をUIや機能に埋め込んでいきました。
- チームで大事なことを定着させるUI設計
- ゴールやDoDを常に視界に入れることにこだわりました。
- サイドバーへの常時固定
- プロダクトゴールとスプリントゴールを、どの画面にいても左側に表示。
- 「なぜやるか」の強制可視化
- タスクをこなすだけの「フィーチャーファクトリー」化を防ぐため、常に目的を意識させる配置にしました。
- 統合的に日常遣いするツールとして、ストレスを感じにくいミニマルな操作感
- エンジニアやPMが日常的に使うツールとして、入力のストレスを徹底的に排除しました。
- Markdownエディタ
- イベントの各種投稿やPBIの詳細を素早く記述できることと、昨今のAIとの親和性が高いMarkdownを採用しています
- あえて機能を絞る
- 高機能なイシュートラッカーを使った時に、入力項目を増やしすぎて管理コストが高くなってしまう、みたいな問題に対抗するために、ログインしてすぐにスクラムの本質に向き合えるよう最小限の機能にしています。
終わりに
以前、優秀なスクラムマスターと話した時に、「スクラムを実践する上でツールが何かは、あまり重要ではありません!ホワイトボードとポストイットでもうまくできます!」という主張をされました。(アジャイルソフトウェア開発宣言の一つ目でもありますね。)
私も基本的にそれに5000%同意しています。
環境や条件が整っていれば、ツールは瑣末な問題なのかもしれません。
とはいえ、走り始めたばかりのチームなど、ツールがその形を支えてくれれば、チームがもっと「プロダクトの価値」そのものに集中できるような場面もあると信じています。
「今のスクラム、なんだか形骸化してるな」「もっとゴールを意識した開発がしたいな」と感じている方は、ぜひ一度、次回のスプリントで試していただけると嬉しいです。
(個人開発なので皆さんのシェア・フィードバックだけが存在の拠り所となっております。少しでも良いと思ったらシェアを、気づいた点があればフィードバックをいただけるととても助かります。なにとぞなにとぞ、、、)
