エンジニアから見たナレッジワークのプロダクトの作り方
ナレッジワーク SWE の味野（@minodisk）です。
以前、CTO の mayah よりナレッジワークの開発体制についてのお話ししました。今回は、どのように認識を共有しながらプロダクトを開発しているのかということを、エンジニア視点でお話しします。
プロダクトシェアデイで why を見いだす
ナレッジワークでは、週に一度プロダクトシェアデイというミーティングが開かれます。これは、セールスサイドとプロダクトサイドの接点となるミーティングで、ナレッジワークの開発体制で紹介した情報流通の仕組みの一部です。
このミーティングでは、セールスサイドからは顧客の声を、プロダクトサイドからは新しい機能の紹介をします。顧客の声には、プロダクトを使った際のリアルな喜びの声と、改善要望の声という両方の面があります。
私たちは喜びの声を Good と、改善要望の声を Opportunity と呼んでいます。
Good は、自分たちが機能を正しく作れたことを認識し、より一層ブラッシュアップするために何をすべきか再考するきっかけを与えてくれます。一方で Opportunity は、プロダクトの伸び代と捉ることで何を改善したらさらに喜んでいただけるのかを考えるきっかけを与えてくれます。
このように、ナレッジワークのエンジニアは顧客の声を認識した状態で機能について考えて設計をすることで、顧客のペインを解消するためにより良い方法を模索することができます。
私がナレッジワークに接してもっとも感動したのが、このセールスサイドとプロダクトサイドの双方向からの情報発信で認識を共有する仕組みです。
双方向性があることで、同じ社内で情報が断絶しがちな二つの組織に一体感が生まれます。また、Opportunity だけではなく Good を定期的に届けてもらえる環境でプロダクトを作ることができるのは、とても貴重な環境だと感じています。
プロダクトデイリーで what を議論する
次に、ナレッジワークでは毎日プロダクトデイリーというミーティングが開かれます。このミーティングには PO、PdM、PMM、デザイナー、エンジニアなどが参加します。参加者は、プロダクトシェアデイなどで発見した顧客のペインを解消するためのアイデアを持ち寄り、意見を出し合い、次に作るべきものの形を定義します。
ここでは、抽象的なものから UI のような具体的なものまで、プロダクトを取り巻くありとあらゆる課題について話し合われます。それぞれの参加者が課題に対して高い理解を持ち、質の高い議論が行われています。
このミーティングの前に、 PdM が Slack でアジェンダを共有します。エンジニアはこのアジェンダを確認し、自由にミーティングに参加することができます。
エンジニアは、この会を通して何を作るのかの選択肢を提案したり、テクニカルな観点からの意見を述べることができます。ナレッジワークのエンジニアはこのミーティングを通じて何のために何を作るのかの認識を揃えることで、作るものへの納得感を持って開発に取り組むことができています。
このミーティングで決定したことは、minispec というドキュメントに落とし込みます。minispec には、主に why と what を記載します。これを元にソフトウェアエンジニアがアプリケーション設計をしたり、QA エンジニアがテスト設計を行います。
why と what から how に繋げるために、認識を共有する仕組みがナレッジワークにはあります。
DesignDoc で how を模索する
エンジニアは、what が定義された minispec から DesignDoc に how を定義します。
DesignDoc にはアーキテクチャや、API インターフェースの定義や、 DB のテーブル定義や、場合によってはシーケンス図などを書き込みます。
DesignDoc に設計をする際に、まれに minispec のままではないがより良い方法を見つけることがあります。そのような場合には minispec にフィードバックを行い、minispec をアップデートします。
DesignDoc を書き起こした後は、フロントエンドエンジニア、バックエンドエンジニア、QA エンジニアなどがさまざまな視点からレビューを行います。ここで徹底的に曖昧な点を洗い出し、設計に合意をとります。
早期に認識の差異を埋めるコストを払うことで、作ってから誤りに気づき作り直すというコストを払うリスクを軽減しているのです。
私もそのうちの一人ですが、PR を出してからそもそも PR で実装した機能の意義についての議論が始まる不毛さを体験したエンジニアは少なくないのではないでしょうか。
このようなテンションの下がる開発体験を極力減らすために、ドキュメンテーションとコミュニケーションで認識を共有する仕組みが整っています。
まとめ
ナレッジワークで、どのように認識を共有しながらプロダクトを開発しているのかということを、エンジニア視点でお話しました。
私たちは、今回ご紹介した仕組みが最終系であるとは考えていません。開発組織をスケールしていくにあたっての課題も、いくつか見えてきつつあります。今後も仕組み自体をリファクタリングをし続け、形を変えつつ運用しようと考えています。
私たちが抱えている課題について相談に乗っていただける方や、ナレッジワークに興味がある方とカジュアルにお話ししたいです。
まずは話を聞いてみたいという方も大歓迎ですので、その場合は下記カジュアル面談フォームよりご応募ください！