Notionで非エンジニアも巻き込んでスクラムしたら一体感が生まれた話
はじめに
こんにちは、PharmaX株式会社のエンジニアの尾崎(@FooOzaki)です。
この度、PharmaXでアドベントカレンダーを実施することになり本記事は節目の10日目の記事になります！
今回はセルフメディケーション事業部でプロダクト管理の仕組みをNotionで改善した話を紹介しようと思います！
・エンジニアと非エンジニア間で溝を感じたり、同じ目線でプロダクトに向かいきれていない感覚がある
・エンジニア以外のメンバーに開発状況がうまく伝わりきらない
もしこの悩みに共感できたり心当たりある人には何を課題に感じ、どう改善したのかという部分にはヒントが転がっているのではと思いますので、ぜひ読んでみてください！
Notionはツール・手段の1つでしかありませんので、馴染みのない人にも伝わるように書いたつもりです！
ちなみに事業部のnotionページはアクセス性抜群で今日もいい感じです！
背景
セルフメディケーション事業部はエンジニア数名に対して非エンジニアが20名近く所属しており、特に薬剤師さんが10名以上所属しているのが特徴です。
一言でユーザ体験を向上する！
といっても「患者さんとの日々のチャット相談の応対品質向上」、「取り扱い商品力向上」「ロジスティクス体験の向上」「同梱物・メッセージカードなどのクリエイティブ改善」などなど方法は多岐にわたり、プロダクトグロースの要素もかなり広範囲に渡ります。
チームも「ペイシェントサクセスチーム」「ロジスティクスチーム」「マーケティングチーム」など専門分野ごとに分かれています。
今回の記事テーマにもつながるところなのですが、
複数チームの状況やインサイトを吸い上げながら、どの要素に注力してプロダクト開発を進めていくのかが難しいところです。
また、ソフトウェアだけで完結する部分は少なく、オペレーションとセットでの価値提供となるため開発チーム（エンジニアチーム）と各チームの連携も非常に重要だと常々感じています。
ソフトウェア開発はスクラムで進めていますが、参考までにスクラムの流れはこんな感じです。（今回はどちらかというとツール面の話にはなるので細かい説明は省きますが、参考までに）
ツール面の課題感
前述の通り、スクラムプロセスにおいても非エンジニアチームとの連携、プロダクトバックログの優先度づけ（どの部分に注力するのか）が重要です。
各チームのリーダ陣がスクラムイベントに参加し、プロダクトマネジャー(PdM)がスクラム開発上のプロダクトオーナーとして施作を取りまとめる形でスクラムを進めています。
プロセス面の改善はこれまでも事業部全体で取り組んできており、スクラムイベントにはない独自の各チーム間連携、課題抽出のための会議体設計など、色々工夫をしています。
とはいえ、チーム間での情報伝達面で、ツールの課題、特にプロダクトバックログ管理上の課題をチームとして感じていました。
チーム間でツール分散が課題に
改善前のツール状況はざっくりと以下の形で、チーム間でツール分散していました。
・スクラム開発の管理ツール、スクラム開発におけるプロダクトバックログはJiraで管理
・ドキュメント管理ツールは全社的にNotionを使用
・開発外の施作管理、課題管理はNotionやスプレッドシートなど各部門でやりやすい形で管理
PdM・エンジニアチームの悩み
・各チーム内で開発が絡まない施作はどんどん自律的に進めてくれており各チームは素晴らしいのだが、ソフトウェアやプロダクト全体として最適化するところにいま一歩踏み切れていない感覚。全員が同じ目線間でプロダクトに迎い切れていない感覚
・各チーム個別ツールを閲覧し、会議体を通じてヒアリングした上でJiraでプロダクトバックログ化する必要があり辛い…
各チームの悩み
・プロダクト状況を見るためだけにJiraにアクセスしないといけないのはしんどいし、メンバーへプロダクト状況が行き届いていない
・いつ機能がリリースされるのか、既知の不具合で報告するべきなのか、など同じようなコミュニケーションが複数回いろんな場所で行われている
・精度の高い施作やプロダクト状況を踏まえた提案がし切れない。提案した施作や要望がちゃんと届いているのか不安
・オペレーションメンバーがソフトウェア開発状況を把握し切れていないケースがある。開発施作リリースとオペレーション連携がうまく取れず、結果的に患者さんに届ける価値が最大化していない
Notionに全てをまとめる試み
過去に各チームの施作・タスク管理をJiraに全てを寄せる案も検討はしたのですが、以下の理由でハードルが高く諦めました。
・個別チームのタスク管理をJiraに移行するのは機能過多になり過ぎ
・非エンジニアにとっては設定画面が複雑で扱いが難しい
それを踏まえて全社ドキュメント管理ツールとして利用しているNotionであれば全員が慣れ親しんだツールですし、新しいツール課金コストも発生しないため、Notionで全部やっちゃおうプロジェクトが発足しました。
Notionについて
既にご存知の方も多いと思うのですが、Notionの製品ページURLも貼っておきます。
Notionにはデータベースという概念があり、任意の行列データベースを作ることができます。
行列データで表現できるものは表現できてしまうので結論、最強です！
そして1行のrowデータはドキュメントとしても機能するので中にドキュメンテーションも自由に書くことができます。
また、データベースのデータはビューとして見える化することができ、フォーマットも結構いろいろあります。
カンバン的なこともできますし、カレンダー形式で日付カラムを参照したロードマップを引くこともできます。
最終どうなったかの画像ととも見てもらった方が早いのでポイントと共に解説していきます。
プロダクトバックログ
プロダクトバックログを1行とし、持たせたいプロパティをカラムで定義しています
ドキュメント機能も備えており、
テンプレートも作れるので統一したフォーマット管理が可能です
全てのチームの取り組む施作をバックログに一元管理することにしました
よくありがちな
・非エンジニアチームからの開発やプロダクト状況がわからないという声
・エンジニアサイドからの各チームの状況がわからないという声
は普段見るツールを統一して横並びで見えたら改善するんじゃね？
というツール視点での発想です。
事業部レベル・他部門に共有・報告するまでもない小さいものはプロダクトバックログ化していませんが、導入にあたってはガチガチにやるとめちゃくちゃ難易度が高いのとROIも悪いと思います。
ポイントは部門間・プロダクト全体レベルで共有すべき施作が統一的にプロダクトバックログで共有できていることです！
※タスク管理・開発管理の粒度だと粒度が細かすぎると思うのでその辺りの工夫は後述します。
最初は非エンジニアは大変だったり管理対象が増えたりして反発もあるかもしれないですが、プロダクト開発に携わる人なら全体状況を見えるありがたさは言わずもがなだと思います。
Notion限らず是非色んな人を巻き込んで取り組んでみるのはオススメです！
併せてプロダクトのグロースファクター（成長レバー）に紐づける形で施作を起こすルールを適用しました
成長ファクターごとに取り組んでいる施作が見えるようになっています
前段として事業部合宿を通じて事業の成長ファクターを定義し、プロダクトの方向性と何にアプローチするのかという目線感を全体で揃えていました。
やはり全員の目線感を揃えるには明確な指針・指標が必要ですし、指標があったとて同じ基準で物事が判断できなければ意味がありません。
そういう意味で「1ツール」「同一フォーマット」「同一基準」で管理する重要性はかなりあります。
問題になりがちなプロダクトバックログの優先度問題も同じファクター間で比較可能になるので優先度も非常につけやすくなりました。
また、スプリントレビューや各進捗報告も統一の基準ができて質が非常に高くなりました。
開発含む施作かどうかをラベリングし、開発プロセスにも組み込みやすくしました
だいたい複数概念のバックログやイシューを１元管理した時に問題になるのはバックログ・イシュー多すぎて管理し切れねーよ問題です。
ということで運用やチーム体系に合わせてフィルタできるようにラベル、フィルター、ビューを定義しました。
これまでJiraで管理していた開発施作一覧も「開発」ラベルでフィルターをしたビューを作ることで実現できました。
notionのラベル機能は非常に便利で異なるラベル概念も簡単にselect型カラムとして追加でできます。
これって開発いる？開発大変なの？みたいな質問ってよく起きがちですが、同じフォーマットの施作ベースで言語化されたものを基に議論できてラベリングできるので効率も非常に良いです。
タスク管理
プロダクトバックログとリレーションし、その下に各チームのタスクが紐づく構造です
各チームのタスク管理データベースを作成し、プロダクトバックログとリレーションしました
NotionはDB同士のリレーションを組むことができます。
各チームの好きなカラムを用意したタスク管理用データベースを作り、先ほど作ったプロダクトバックログとリレーションで紐づけることができます。
開発であればGitHubのPRを紐付けるプロパティを用意したり、開発プロセスに併せてタスクステータス管理項目を用意しました。
ちなみにGitHub連携は今年に入って強化されてPRにnotionリンクを貼っておくとシンクができます。
また、プロダクトバックログにするまでもないチーム内のタスク管理も自由にできます。
プロダクトバックログにリレーションしないタスクとして同一のタスク管理データベースに起票すればOKです。
これでプロダクトバックログを起点にタスク管理できる体制が整いました。
スプリント管理とベロシティ計測
スプリント管理用のデータベースを準備
Jiraからの移行でスプリント管理面は懸念でしたが、データベースの構造次第で結構柔軟にできそうな実感を得ています。
先ほどと同様に新しいデータベースでスプリントの管理データベースを定義しました。
前述の開発のタスク、プロダクトバックログとリレーションすることでスプリント管理することが可能です。
集計関数などもnotionはカラムで定義可能で、リレーション先での集計も可能です。（とはいえリレーション先まで参照した複雑な条件式は組めないのでデータベースで非正規化的に持って運用したりなどは一定必要そうです。）
スプリントに紐づくバックログのストーリーポイントを集計すればベロシティが算出可能です。
Notionで物足りないこと
専用のタスク管理ツールやアジャイル開発ツールに比べてまだまだ小回りが効かない部分は正直あります。
その分有り余る汎用性と操作性があるので今回のように非エンジニア部門連携を主眼においたツール選定としては超おすすめです！
記事が長すぎてTipsや具体的な設定まで書き切れないのでなかなかイメージがつかないかもしれませんが、実際に本運用に載せる前にやりたい要件を洗い出して試運用してみることをお勧めします！
開発の指標計測
notionは集計関数を組んだりは一定できますが、異なるDBリレーションを跨いだ集計などは弱く結構DBのデータの持たせ方にコツが必要です。
ベロシティ計測ぐらいであれば良いですが、細かい数値を出そうとするとDB設計やカラムの運用に工夫が今後必要そうです。
あとはグラフ化も別ツール使わないと難しかったりします。
この辺りはアジャイル開発に特化したJiraなどのツールに優位性はあるかもしれません。
Notion頑張って！！！（切実）
ボード管理やレーン管理
基本的なカンバンボードとして一定のことはできますが、例えば数日間滞留しているタスクをピックアップしたり、スクラムマスターがやりたくなる細かいロジックに基づいたボード管理までは結構難しかったりします。
スクリプトを書けば一定できたりしますが日付の自動入力とかはあまり小回りは効かない印象です。
この辺もAsana、Jiraなどのタスク管理機能の強いツールには劣る部分はあります。
Notion頑張って！！！（切実）
最後に
偉そうに色々書きましたが、今回ご紹介したことは私一人で実現したことではありません。
特にPdMの方がNotion大臣として、「これってNotionでできるかなー？（私）」「余裕でできますよ！っていうかやっときました！（notion大臣）」の阿吽の呼吸で爆速整備してくれたおかげです。
導入したツールが使われない問題をよく聞きますが、個人的には浸透のポイントはツールを徹底的に使いこなすエバンジェリスト的存在と運用設計だと思っています。
改めてnotion大臣と運用に協力してくださった事業部メンバー全員に感謝です！
細かいHowについてはあまり記事には書き切れなかったので気になる方はお気軽にtwitterへ連絡ください。情報交換しましょう！
PharmaXアドベントカレンダー2022では、2022年12月25日まで技術的な話から組織の話まで幅広い記事が公開される予定です。
引き続き、ぜひよろしくお願いいたします！
PharmaXでは定期的にテックイベントをオンラインで開催しています！
2023年1月は、金融業界・花き業界・薬局業界という異なる業界でDX推進をリードするスタートアップ企業3社が集まり、それぞれのオペレーションを担っているドメインエキスパートとプロダクト開発チームがどのように連携しながらプロダクトや開発組織を作っているのかについてディスカッションします。
ぜひお気軽にご参加ください。
この記事が気に入ったらサポートをしてみませんか？