ナレッジワークの開発体制
ナレッジワーク CTO の mayah です。
前回、CEO の麻野より、ナレッジワークが作ろうとしているプロダクトについてお話ししました。今回は、ナレッジワークの開発組織において大切にしている考え方と、開発プロセスについてお話しします。
ナレッジワークでは「正しいものを正しく作る」という思想のもと、
正しいものを定義するための、情報流通の仕組み
正しく作るための、アジャイル開発をうまく回す仕組み
に開発体制の特色があります。
話したいことはたくさんあるのですが、本日はこの２点に絞ってお伝えします。
プロダクト開発は総合力勝負
ナレッジワークでは、プロダクト開発は総合力の勝負であると位置付けています。
プロダクトを開発する側をプロダクトサイド、販売する側をセールスサイドと分けたとします。プロダクトサイドはプロダクトマネージャー (PdM)、デザイナー (Des)、ソフトウェアエンジニア (SWE)、QA などから構成されており、セールスサイドはプロダクトマーケティングマネージャー (PMM)、マーケティング (MKT)、セールス (Sales)、カスタマーサクセス (CS) などから構成されています。
さて、プロダクトを作る中心となるのはプロダクトサイドです。しかし、プロダクトサイドだけがいくら作りたいものを作っても良いプロダクトは生まれません。直接顧客の声を聞いているのはセールスサイドであり、顧客の問題理解が曖昧なままプロダクトを作っても本当の問題解決にはならないからです。
一方で、セールスサイドが売れると思われる機能をプロダクトサイドに作らせても良いプロダクトは生まれません。プロダクトの中身を本当に知っているのはプロダクトサイドであり、プロダクトの中身の理解が曖昧なままプロダクトを作らせても本当に問題を解決するプロダクトにはならないからです。
淀みなく情報が巡る体制を整えます
プロダクトは、正しい機能を見定めて正しく作り、それを正しく顧客に届けることで、価値が最大限に発揮されると考えています。
そのために必要なことは、情報が淀みなく両サイドを巡るような仕組みを作ることです。一般に、情報はプロダクトサイド内、セールスサイド内に閉じがちであるため、仕組みをきちんと作らなければこの情報はすぐに巡らなくなってしまうでしょう。
ナレッジワークでは、プロダクトサイドとセールスサイドの情報提供の仕組みとして、毎週開催されるプロダクトシェアデイと呼ばれる時間を設けています。この場では、プロダクトサイドからセールスサイドへ、またその逆の情報共有が行われます。
プロダクトサイドからセールスサイドへは、プロダクトの機能を正しく伝えるため、作った機能のデモをしています。作った機能は PdM のデモ担当者に説明され、わかりやすいデモが全セールスサイドメンバーの前で行われます。しばしば、開発が速すぎてセールスサイドの方々に良い意味で泣かれます。
逆に、セールスサイドからプロダクトサイドへは、PMM 中心に顧客からの生の喜びの声と要望をまとめて共有しています。喜びの声は自分達が作った機能がどのように使われているかを知ることができます。要望は PdM 中心に一度まとめ、優先順位のもとに開発スケジュールに組み込まれていきます。しばしば、大変熱のこもった喜びの声が届きプロダクトサイドは良い意味で泣いています。
また、日々の議論と意思決定の場として、プロダクトデイリー（45分）と呼ばれる場があり、実際の作る機能に関しての議論がプロダクトサイド・セールスサイド問わず活発に行われています。PdM 中心に仕様を minispec と呼んでいる形式にまとめ、日々３つほどの意思決定が迅速に行われていきます。
別件ですが、unofficial な情報共有の場としてバディ制と呼ばれる取り組みも実施されました。セールスサイドとプロダクトサイドのメンバーが1対1の組となり、プロダクトに対する困り事の共有や解決案の壁打ちを行うというものです。このような取り組みも必要に応じて unofficial に多数行われています。
これらの取り組みはこれまで非常にうまく行っています。この根本原因は情報が流れる仕組みを作ったことにありますが、仕組みがうまく生きるためにはセールスサイド・プロダクトサイドのお互いのリスペクトが欠かせません。これまで両サイドがお互いの要望を叶えてきた実績があり、両サイドが非常に良い関係が作れていると自負しています。
淀みなく開発が回る体制を作ります
さて、これまでセールスサイドとプロダクトサイドの体制についてお話ししてきましたが、Developers Blog ですので、開発体制に焦点をあててお話ししましょう。
ナレッジワークの開発は、一人一人の能力が高いことにもあるのですが、アジャイル開発をきちんと回すことに相応の労力を注いでいることに特徴があります。結果として開発スピードは非常に早く、スプリントで必須で作ると決めたものがスプリント内に作られなかったことがありません。
スプリントサイクルはパイプライン化されています
ナレッジワークのスプリントは、おおきく３つのフェーズに分けられます。要件定義・デザインフェーズ、実装フェーズ、QA・リリースフェーズです。
スプリントはパイプライン化され、３本のスプリントが同時に走っています。要件定義・デザインフェーズは PdM およびデザイナー中心、実装はエンジニア中心、QA・リリースフェーズは QA 中心と、中心職種がバラバラだからです。
ただし、中心以外の職種の方が意見を言う機会をさまざま確保しています。特に要件定義・デザインフェースはその後の実装フェーズ、QA・リリースに大きく関わってきます。ここで正しく意見を言うことは後工程での手戻りを大幅に減らせるため、非常に大事です。
要件定義・デザインフェースは誰でも関われます
要件定義・デザインフェースはプロダクトデイリーが意思決定の場になります。その会議体には開発および QA の責任者は常に、それ以外のメンバーも時間が許す限り参加しています。ここで問題があると実装・QA フェーズにまで響いてきますので、自分がよく知っている領域の話が行われるときは参加義務がない開発者もプロダクトデイリーによく参加しています。
この会議体では、はじめの方で述べたように minispec と呼ばれる仕様書（というより仕様案）をもとに議論が進んでいき、その議論の結果も minispec にまとめられていきます。プロダクトデイリーに参加していない人でも minispec を見れば「顧客のどの問題をどう解こうとしているのか」がまとまっているため、意思決定理由がわかりやすいものとなっています。
実装フェーズでもドキュメントベースで実装議論をしています
実装フェーズは実際に実装を行うのですが、このフェーズが始まる前に、minispec をベースに必要なタスクを起こしておき、開発の総量を見積もっておきます。
あらかじめ大きな設計が必要である場合は、minispec から設計が書かれた DesignDoc と呼ばれる内部設計資料を作っておきます。DesignDoc には、例えば API 定義や RDB のテーブル定義、アーキテクチャなどがまとまっており、ドキュメントベースで議論できるようにしています。日々のコードレビューでは大きな設計の誤りを見つけることは難しいため、あるいはそこで設計の誤りが見つかるようでは後戻りが大変であるため、大きな設計が必要な実装については DesignDoc を書くようにしています。正直言うと Google から文化を流用してきましたが、ナレッジワーク流に少しアレンジして使っています (Google では我々の minispec + DesignDoc で一つの設計文書を成しているように思います)。
これらは採用デックに少し形式が載っているので見てください。
QA・リリースフェーズ
QA・リリースフェーズでは、QA を行い、リリースをします。
QA はこれまで全て個々で行ってきたのですが、誤りが見つかるならば可能な限り早く見つかる方が良いことから、QA は実装フェーズ中からできたものを実施するような体制に切り替わりつつあります（シフトレフト）。これまでは QA 人員不足で難しかったのですが、QA 人員も採用が進んでおり、このような体制が取れるようになってきつつあり、改善してきています。
また、このフェーズでは、セールスサイドにプロダクトを説明するためのドキュメントも作っています。これが意外と時間がかかるのですが、作ったものを顧客に届けるまでが開発であるため、非常に大事であると考えています。ここで作られたドキュメントがプロダクトシェアデイで共有されていきます。
まとめ
ナレッジワークの開発において重要視している体制と考え方についてお話ししました。「正しいものを正しく作る」体制について、一通りお話ができたと思っています。
カジュアル面談でここまでの話をすると、しばしば、「本当にこんなにちゃんとスプリント回しているの？」と聞かれます。答えは常に「こんなにちゃんと回しています」です。もちろんこんなにちゃんと回すためにも、ここには書けない様々な工夫がありますし、ここに書いていないイベントもたくさんあります。採用デックにスプリントイベントをまとめたページを作っているのですが、こちらにも再掲しましょう。
単に開発をしているだけでなく、見積もりや振り返りもきちんとしていることもわかるでしょう。これらは全て未来に対する投資であり、スプリントで出てきた問題を早期退治するためには必要な時間であると考えています。このためにかなりの時間を割いていますが、「正しいものを正しく作る」ためには必要な時間であると考えています。
具体的に使っている開発技術や開発上の工夫なんかは、他メンバーよりまた日を改めてお話しすることにしましょう。
まずは話を聞いてみたいという方も大歓迎ですので、その場合は下記カジュアル面談フォームよりご応募ください！