失敗からの脱却｜崩壊の瀬戸際に立ったチームを再起させるプロダクトWikiの作り方
🎄SaaS Design Advent Calendar 2023の6日目の記事です！🎄
本記事では、社内一大プロジェクトであるプロジェクトの挫折を経験した開発チームが再起を果たすまでに取り組んだ施策としての「プロダクトWikiの構築」にフォーカスを当ててお話を紹介します。
「プロダクト統合」プロジェクトの大失敗
プロジェクトの背景
2022年2月に中途入社をした際に、複数の製品間での機能やデザインの調和を目指し、２つのプロダクトを統合するという社内一大プロジェクトの渦中にジョインしました。プロジェクトメンバーは、社内の精鋭たちをとりあえず集めました状態のチーム構成でした。
同じプロダクトを作るはずのチームが機能していない
プロダクト仕様やチームカルチャーが散逸している中でのスタートだったので、異なる製品ラインを管理するチーム同士の摩擦、不透明なコミュニケーション、そして期待するアウトプットのミスマッチが徐々にメンバー間のパフォーマンスに悪影響を及ぼしていました。
幾度の遅延を繰り返しリリースまで漕ぎ着けたが、もはやチーム崩壊の寸前
当初のスケジュールは、2021年12月〜2022年6月に統合を完了する予定でしたが、実際に統合プロジェクトを終えたのはそこからさらに半年以上遅延をし、2023年2月に完了しました。
統合プロジェクトの間は、新機能の開発などにもアプローチすることはできず、最終的には期待を大幅に下回る結果に終わりました。
開発チームの士気は底を打ち、分離の傾向が強まる中、チームを再起させるための施策をデザイナーが主体となって打つ必要性があると感じていました。
チーム負債返済に向けて、振り返り会の企画・実行をデザイナー主導で行った。
良い組織が良い仕事をするのではなく、良い仕事が良い組織を作る。
まずチームの中に文化を根付かせるために、私が大事にしているマインドセットがあります。
それは「良い組織が良い仕事をするのではなく、良い仕事が良い組織を作る」ということです。
最高のプロダクトは最高のチームから生まれると考えており、プロダクトデザインと同様にチームデザインにも重きを置いて日々活動しています。
「仕事でミスが起こった時にはその人が悪いのではなく、ミスが起こる仕組みが悪い」という風にチームとして課題意識を向けることを、チームのマインドセットとして根付かせることをまず最初に行うべきだと考えました。
つまり「人のせい」を「仕組みのせい」に変換していき、その仕組みを改善していくという行為を積み重ねいくことが、それによって循環が生まれていき、良い組織にすることができます。
例えば、「ここのリリースフローを改善したいから、自動化したほうがよさそう」「サービス提供の水準が機能ごとで違うので企画検討フェーズから新しい仕組みを入れていこう」など「仕組みのせい」にすることで、プロダクトを磨く上での仕事が生まれ、循環が生まれ、良い組織に近づけることができるというイメージです。
このマインドセットを意識させながら、チーム振り返り会を企画・実行しました。
振り返り会をどう実施したか
やり方としてシンプルで事前ワークと当日ワークのような形式でおこなました。
個人としてのKeep&Motto&Tryは事前に洗い出して、振り返り当日に共有
チームとしてのTryはテーマに添いながら全員で議論しながら導き出す
チームとしてのTryで挙げられたもの中から、「実行するTry」を決める
まず振り返りを通じて、様々な問題点を明らかにすることができました。
そしてそれらの課題は主に３点に帰結します。
チーム内での情報共有の不十分さや不便さ
目標としている成果物への解釈の齟齬から生まれる要件仕様の手違い
チーム全体としての仕様認識率の低さとボラティリティ
チーム力を高めて、プロダクトの課題を解決するチャレンジができるようにするために、散逸したドキュメントやナレッジを集積・共有できるようにNotionを用いてドキュメントプラットフォーム「プロダクトWiki」の作成をデザイナー主導で2023年3月から進めてきました。
プロダクトWikiの作り方
1. アウトプットとアウトカムを定義する
モノを作る立場だと、どうしても「何を作るか」といったアウトプットで考えがちです。ドキュメントプラットフォーム「プロダクトWiki」を作成すること自体が目的にならないように、デザイナーが注目しなければいけないのはアウトプットではなく「アウトカム」です。
アウトプット（Output＝成果物）
プロジェクトに関わる知識と情報を一元化し、すべてのチームメンバーがアクセスできるドキュメントプラットフォームの構築
アウトカム（Outcome＝成果物がもたらす本質的な価値や変化）
ドキュメント文化を根付かせることで「仕様の脱属人化によるQCD水準の向上」が起きること
QCDとは、Quality（品質）、Cost（コスト）、Delivery（納期）の頭文字を並べたものです。ここでは以下の意味合いを指します。
Quality(品質)：プロダクトのUIUX品質
Cost(コスト)：プロダクトを提供するためにかかるリソースコスト
Delivery(価値提供までの時間)：プロダクトのリリーススピード
「品質が高い」「コストが低い」「スピードが早い」の３つの条件を高いレベルでバランス良く満たすことで、プロダクト自体に高い競争力を生み出していくこと
2. まずページ設計を決めたらスクラップ＆ビルドを繰り返す
目指すべきアウトカムが定義した後に作るべきドキュメントが何かが明確になってきます。私が中途入社した時点では、ドキュメント管理について体系だった取り組みを行なっておらず、個々間での仕様書の作成や要件の擦り合わせなどのやりとりを行なっていた状況であったため、
新機能・改善・不具合の開発の仕様検討を行なう際に、プロダクトWikiを中心として開発を進行していくようなイメージを作っていけるように、Wikiには、PRD（要求・要件定義書）概要・詳細設計書、デザイン仕様書、テスト仕様書に関するプロダクト情報をまず集積することから始めて、PMを巻き込みながら、プロトタイピングしながら改良していきます。
ページのざっくり主構成として以下の通りです。
ガイド
プロダクトの使い方や機能説明が記載されたページです。ユーザーがプロダクトを使う上で必要な情報がまとめられています。
機能ごとのPRD資料
プロダクトの各機能に関する情報がまとめられたページです。機能の仕様やユーザーストーリーなどが記載されています。
種別ごとの資料
開発に必要な各種ドキュメントがまとめられたページです。設計書やテスト仕様書などが記載されています。
開発資料
プロダクトの開発に必要な情報が記載されたページです。コードの設計や仕様など、開発者が必要な情報がまとめられています。
システム構成資料
プロダクトのシステム構成に関する情報が記載されたページです。インフラの設計や構成、ネットワーク図などがまとめられています。
Dev運用資料
プロダクトの運用に必要な情報が記載されたページです。運用マニュアルや障害対応など、運用担当者が必要な情報がまとめられています。
企画設計資料
新しい機能や改善案など、今後のプロダクトの開発に必要な情報がまとめられたページです。
リリースノート
最新のリリース情報を記載したページです。バグの修正や新機能の追加など、プロダクトのアップデート情報が掲載されます。
3. チーム文化として浸透させるために、施策を継続的に実施する
組織には慣性があるため、プロダクトWikiを作っただけではチーム文化として中々浸透しません。そこでチーム施策として展開していきます。これまで実施した中でやってよかった施策を２つ紹介します。
おすすめ施策１：プロダクトバックログのNotion移行
これまでBacklogを開発チームとして利用している中で、Notion移行は、スイッチングコストや機能面でも意思決定が難航しましたが、ドキュメントツールとタスク管理ツールを同じことにするメリットが大きいと判断し、Notionに徐々に移行していきました。
今まではタスク管理ツールにドキュメントにリンクを貼ったりPRにアイテムのリンクとドキュメントのリンクの二つを載せていたりしましたが、一つに集約していることでオーバーヘッドがかなり減ったと思います。
やってよかった施策２：仕様度理解テスト
プロダクトWikiの仕様書や逆引きの活用頻度を上げることができつつ、チーム内のドメイン理解度や仕様理解度を可視化することができ、チームとしての健康状態を測定できます。ドメイン知識を深めることはゲームルールの理解に繋がりますので、勝ちやすい(負けにくい)プロダクト開発にも繋がってくると考えています。
プロダクトWikiを導入した結果として
プロダクトPRD・仕様の網羅率は2023年3月からスタートし、わずか9ヶ月で85%を達成しており、プロダクトWikiを中心に、チーム課題を多く解決できるようになりました。
開発メンバー体制として14人の中で行っているのですが、2023年の開発アイテムリリース数をざっと数えてみたら、160アイテムを軽く超えていました。前年比YoY183%です🤯。
持続可能なパフォーマンスをチーム全体で出力できるようになっている証拠なのかなと思っています。もはやチーム再起を果たすどころか会社内で開発部のチーム連携を称賛するような声を多く耳にする機会が増えてきました。
改めてプログラムWikiを導入することによって、以下のような状況に導くことができていると実感しています。
情報の可視化や共有によるチーム内コミュニケーションの改善
ドキュメント体制の整備によるチーム全体の仕様認識率の向上
新規メンバーの追加による引継ぎの容易化
過去の問題点や改善点の共有による開発プロセスの改善
チームメンバー同士の協調性やコラボレーションの向上
プロジェクト進行中の情報共有によるチーム全体の認識統一
知識の蓄積によるCSニーズの把握やサポートの強化
最後に：良い組織や良い文化は、良いプロダクトにつながる
偉大なプロダクトは、偉大なチームから生まれる
この言葉はGoodPatchのカルチャーとして広く知られ、プロダクト開発に深く関わる者ならば一度は耳にしたことがあるかと思います。
BtoBのSaaSは、まさに最高のプロダクト体験が市場を制覇するというシンプルなルールであり、そしてそれは組織的な協力と連携に支えられた最高のチームから生み出されます。
このような環境において、デザイナーはもはやビジュアルやUIの専門家にとどまらず、チームの協力を促進し、事業を推進する核となる存在としての役割を担う時が来ています。
プロダクト開発を成功に導くためには、時として組織構造や人間関係のデザインこそが近道となるかもしれません。
今回「プロダクトWiki ✕ チーム再起」を観点で色々つらつら書きました。同じような悩みを抱えつつ挑戦をしているデザイナーやデザインリーダーの皆さんのお役に立てばと思います。
【PR】イベントやります
デザイナー忘年会にLT登壇します。
イベントでは、株式会社root、株式会社RightTouchを含む3人のデザインリーダーが事業成長のために日々取り組んでいることを共有します。ぜひご興味あればご参加ください！
この記事が気に入ったらサポートをしてみませんか？