今よりもっと早く、質の高いプロダクト開発をめざして~Confluence＆Jiraでモダンな開発プロセスの構築~
この記事は MICIN Advent Calendar 2022 の17日目の記事です。
前回は小泉さんのopenapi-typescriptと型パズルで作るREST APIクライアントでした。
はじまして。MICINでProduct Managerをやっている酒井です。
本日は、私がMICINに入社してプロダクト開発を行う上で直面した社内の課題をどのように解決していったのかを書きたいと思います。今回の記事は、開発プロセスや環境をどう変化させたのかがテーマになります。
なお、「プロダクトの仮説検証」や「実際の開発をどう進めたのか」にご興味がある方はこちらを見てみてください。
入社後に感じたこと
入社直後に私が担当した業務は、オンライン診療curonやcuron お薬サポートといったcuronブランドのプロダクトと親和性の高い領域で新しい価値やマネタイズを生み出すこと、いわゆる0→1のフェーズの仮説検証を行うことでした。
そのためにも、オンライン診療curonを利用している患者さんや医療機関がどういう人たちなのか、curonが作られた背景や機能などのインプットから始めようとしました。しかしそこで立ちはだかったのは、情報が整理されていないということでした。
Figma上のデザインUIとKibelaという情報共有ツール上のエンジニア達が開発する上で必要だと思われた技術情報はかろうじて存在していましたが、これまでのcuronを積み上げている要求がまとめられているはずのPRDだけでなく、画面仕様やデータベース設計書などもどこにあるのかわからない状態で、そもそも書かれていないものもたくさんありました。
また、0→1の活動だけでなく、curon お薬サポートのプロダクトチームの中に入って1→10のような動きもしているのですが、私がチームに合流した時にはWrikeというタスク管理ツールを四苦八苦しながら使いつつ、アジャイルスクラム的に動いてはいるのですが、大量にたまったチケットをただたださばいている状態でした。
はい、そうなんです。プロダクト開発あるあるといえば、あるあるなんですが、
過去の背景がわからない
現在の仕様もわからない
今何をやるべきかも整理されていない
向かうべき方向もわからない
という状態に直面してしまい、「あぁ、これはとても大変なところに来てしまったな」というのが率直な感想でした。ちなみにいうと、プロダクトの検証や今の開発アイテムの優先度付けは早急に行う必要があったので、わからないことは人に聞きながらなんとか船を前に漕いでいきましたが、それだけだと船と共に私も海の藻屑になりそうでしたので、並行して船の構造や進むルートを根本的に見直すことを決意したのです。
まずはじめに課題や解決策とめざすべき方向性を整理
ということで、Product Managerらしく、課題からはいります。そして、背景を正しくとらえ、解決策に落とし込んでいきます。ちなみに、この背景というのが結構大切だと思っておりまして、社内のいろいろな方にヒヤリングしながら、整理していきました。
簡単にまとめると、ドキュメントの必要性がきちんと認識されておらず情報を残していく文化が醸成されていないことや目の前のものを如何にさばくかに特化しすぎた開発プロセスを作ってしまっていることが課題でした。この課題を解決するために、目的に合わせたドキュメンテーションと開発プロセスを再設計して事例を作りながら認知・浸透していく必要がありました。
ということで、解決策が何となく見えてきたので後は実践あるのみです。進めながら、解決策がうまくいかなかったら小さいピボットを繰り返します。
実際に実施したこと
ちなみに、こちらが私が実施したことをまとめたものになります。日々のプロダクトマネジメントの中でこの解決策を入れてながら進めていきました。解決策は何か一つを実施したらよいものではなく、一気通貫で地道に継続実施していくことで初めて社内に浸透していくと思っています。
上の図を少し簡単に書いておきますと、
ドキュメンテーションによるプロダクト開発のスピードと質を向上するため以下を行いました。
Kibelaだと、プロダクトの検証や開発ドキュメントを記載するのが厳しいので、Confluenceの導入を経営会議に起案しました。
自分たちのチームでのトライアル利用を経て、全社展開につなげました。
全社展開をする上で、プロダクト開発観点ではもちろんのこと、全社ナレッジマネジメントの観点で提案しています。全社展開する上で、Kibelaからの移行や運用ルールの整備なども行っています。
ドキュメンテーションだけではなく、MICINの開発プロセスもより良いものにしていくために、以下を行っています。
自チームは0→1のチームであったため、既存のツールであるWrikeではなくトライアル利用が承認されていたJiraで最初からプロセスを構築しました。また、フェーズに合わせてプロセスをウォーターフォールからスクラムに変化させたりしました。
また、既存のプロダクトチームの開発プロセスのルールの再整備を行い、WrikeからJiraへの移行しました。
また、こういう取り組みが他チームにも浸透していくように、他チームのメンバーとディスカッションしたり、エンジニアのLT会で発信したり社内認知の活動も並行して行いながら、相談を受けたら全面的にサポートを行っています。
いろいろやった結果どうだったのか？
Confluenceは全社wikiとして全社員から活用される基盤になってきています。全社ポータルとしても機能していますし、各事業部やプロダクトチームで様々な情報が記載されるようになっています。Kibelaについては、エンジニアにとってはMarkdown形式のとても軽いエディターで使いやすいという声もありましたが、Confluenceに移行したことで、表現力が格段に上がりましたし、Markdownでの記入やエクスポートもアドオンで対応可能です。Confluenceのエディターは重いという声も出ていましたが、Cloud版＆新エディターになってからかなり改善されており、重さも気にならなくなっています。
また、WrikeからJiraへの移行をきっかけに、目的やプロダクトの状況に応じてウォーターフォール・スクラムと変化させたり、スクラムにおいても各チケットの優先順位を成果や価値ベースで判断をしていくチームに変化が起きてきています。Jiraの各種ドキュメントはスクラム開発のナレッジがたくさん書いてあるので、Jiraを使い倒すとスクラムができるようになっていることが素晴らしいと感じています。
ツールはあくまでツールで、ツールに使われないことが大切ですが、課題に応じて選定することで、チームが変わるきっかけになりえます。今回の変化は私だけで進められたことではなく、ツールを使う側のひとり一人が自分の業務環境への課題を認識しながら、自ら変化させていった結果だと思っています。
最後に、参考までにツール選定時に比較したポイントをまとめておきたいとおもいます。
ツール選定時の判断ポイント
実際には、チームからの要求をヒヤリングした上でもう少し詳細な機能を比較した上で、コストや移行難易度も含めて判断しています。
ドキュメント管理ツール
様々なメンバーからの要求をききながら、「なぜこの機能が必要なのか」を確認しながら、様々な職種の方でも簡単に使えて、プロダクト開発に必要な表現力をもったConfluenceを最終的に選定しています。価格面も比較条件として入れており、Notionは複数スペース利用となると価格が少しネックとなりました。
タスク管理ツール
機能ベースで比較は困難なため、思想やUI/UXをポイントとしてあげています。
判断ポイントとしては、ドキュメントはConfluenceによせる形として、ソフトウェア開発のしやすさを優先とし、ビジネスタスクの管理も可能かという観点で選びました。
さいごに
私が入社して1年半が経ちますが、その間だけでもプロダクトやチームに様々な変化が起きました。それでも、MICINのプロダクトやチームはまだまだ未成熟な状態です。プロダクト開発というゴールがない道を歩き続ける限り、日々変化をし続ける必要があります。ぜひ、これから一緒にMICINを成長させていきませんか？
MICINではメンバーを大募集しています。
「とりあえず話を聞いてみたい」でも大歓迎ですので、お気軽にご応募ください！
MICIN採用ページ：https://recruit.micin.jp/