こちらは「コドモン Advent Calendar 2022」の2日目の記事です🎄🎅
こんにちは！コドモンプロダクト開発部の天川です。 本日、めでたく30歳の誕生日を迎えました🎂 30代は20代よりもさらに楽しく面白くしていきます！！
今日はPdMの業務の一つである仕様策定のために「仕様検討チェックリスト」を作成したお話です。
仕様検討で感じていた課題👻
観点の見落としでイマイチな機能になる
コドモンにはPdMが7名おり、機能群ごとに分けられたチームにそれぞれ1〜2名在籍しています。
以前はPdMは各々の知識や経験から課題・ユーザーストーリーを書き、CSやエンジニアへの共有を経て実装されていました。 そのため、仕様の質はPdM個人の力量に委ねられている部分が大きかったように感じます。
その中でも細心の注意を払っていたのは、検討事項が漏れてユーザーにとって不便だったり分かりづらい箇所が生まれてしまわないか、ということです。
私の担当機能群は6つほどの基本的機能ですが、これらの中ではUIや小さな機能(フォーム、画像アップロード etc.)が共通していることが多々あります。また、他機能との連携も多い箇所です。 UIや細かな挙動も含めて一貫した体験を提供するには、小さな改善でも予想以上の確認事項が生まれることもあります。
事前に確認していても、実装中にエンジニアやデザイナーが新しく検討事項を見つけてくれることもあり、内容によってはその間の実装がストップしてしまいます。より早くリスクを潰して検討を進めるために、必要な観点を早めに定義したいと思うようになりました。
また、仕様だけでなくコードの複雑化の問題も組み合わさり、チーム全員で確認していても適切なタイミングで問題を見つけることが難しい場面もありました。
新しいメンバーがどんどん増えるコドモンで、その時のメンバーが知っている範囲でユーザーストーリーや受け入れ条件の抜け漏れをチェックすることには限界を感じます。
過去の検討内容が情報として残らず施策に活かせない
古くからある問題のなかには仕様の検討に時間を要しているものもあり、私が引き継いで着手することがありました。
過去の会話に、自分の知らないユースケースや技術的課題がないか？ 検討したが却下した手段があれば、そこに問題が隠れていないか？
古いIssueだと、当時の検討内容がまったくわからない場合があり、その場合は新しく調べ直すことになります。検討に時間がかかるのも問題ですが、過去に社内で起きた問題を知らないうちに繰り返していたら怖いなぁという気持ちがありました。
仕様チェックリストを作った！💪
これらの課題を解決するために、社内共通で使える「仕様チェックリスト」を作成しました。
作成の流れ
普段からチェックしている項目を洗い出し
まずは仕様検討時に自分でチェックしている観点を洗い出してみました。 自分が課題感として感じていた、他機能との連携や一貫性の部分はこの時点で項目として挙げることができました。
必要な観点の追加
また、自分が過去に見落とした箇所を、どうしたら防げただろうか？という観点で項目を追加していきます。
Webアプリケーション外で発生する影響(メール、プッシュ通知)は見落としやすい上に他機能との共通部分も多く、後から発見すると問題になりやすい箇所です。 また、コドモンはユーザー権限の仕様がやや複雑なので、チェックリストの備考には具体的な観点をメモしています。
アプリケーションやドメインの特徴に合わせて特に気をつけるべき箇所がわかれば、今後新しく入社したPdMにとっても助けになりそうです。
さらに、今後チームで効果測定をしていくために、指標も仕様の一部としてチェックリストに含めました。 指標と仕様をセットで決めることで、計測に必要な改修も受け入れ条件に含めて工数感の会話ができます。
PdMチームでの共有とブラッシュアップ
ここで、PdMチームでリストを共有してコメントをもらいました。
社内運用チームへの影響など、自分が知らなかった影響の可能性がわかったのでリストに追加していきます。
修正後にリストを改めて共有して、お試し運用を開始しました。
実際の使い方と感じたメリット
使い方
リストをGoogle スプレッドシートのテンプレにして、Issueごとに1枚のリストを作成しています。 各Issueの概要にリストを貼りチェックした内容やメモを残しているので、後からそれぞれの観点についてどんな判断をしたかがわかるようにしています。
リストはあくまで観点の確認用なので、検討して決まったユーザーストーリーや受け入れ条件は、今まで通りIssueに記載しています。
メリット
仕様検討時の「何となく不安」が減った
今まではIssueにユーザーストーリーや受け入れ条件を書き出した後に、頭の中に浮かんだ観点を洗い出したり、過去のIssueを見ながら検討していたのですが、現在はこのチェックリストに記入して完結するようになりました。
必要な観点が可視化された状態になり、不安になる状態が減りました。
仕様決定までの流れがスムーズになった
チェック項目から事前に調べるべき内容がわかったことで、より多くの懸念点を確認してからチームメンバーに仕様を共有できるようになりました。
また、チームで議論が必要な際も、類似サービスのスクショや利用状態のデータなどより多くの情報を持って打ち合わせができるようになりました。
Issueの記載に必要な時間は増えましたが、打ち合わせ後に「これも追加で調べましょう」といった内容が減り、全体の流れはスムーズになったと感じます。
Issueが資産になる
最初の検討段階でIssueに多くの情報が集まるので、情報をIssueに集約させたいと自然に思うようになりました。 そのため、Slackに残してしまうこともあった会話ログも今はIssueのコメントに残すようにしています。 一度Miroにまとめていた情報を、改めてIssueに書きなおすこともありました。
以前よりも明らかにIssueの情報量が増えており、情報が分散していたときよりも過去の情報が追いやすいと感じます。
終わりに
「あったらいいな」で作り始めた仕様チェックリストでしたが、PdMチームの協力もあり、短い期間でメリットを感じながら仕事ができる状態になりました。
また、当初課題だった仕様の質やリスク管理だけでなく、Issueへの情報集約など予想外の部分でもよい効果がありました。
今後も各メンバーの気づきを足していくことで、チーム全体の仕事のしやすさや仕様の質の向上に貢献できたらと思います。
最後まで読んでいただきありがとうございました！
明日の担当は開発の採用広報担当のおかぱるさんです！✨
天川が書いた他の記事はこちら✏️
コドモンの開発チームのTwitterを始めました！ アドベントカレンダーの新着記事も毎日ツイートしていくので、ぜひフォローしてください😊
