開発者20名未満のプロダクト開発チームの組織管理について
株式会社var CEOのfurusatoです。
本日は、弊社におけるプロダクト開発手法について共有します。
開発人数5-15名程度の小規模ベンチャーにおける、エンジニア以外のマーケターやデザイナーも含めた開発手法について何か学びになればと思います。
概要
- 少ないリソースを最大限に引き出すためには、戻し0の構成を心がけた
- なんでも屋さんがでてきましまうので、Roleによる区分を取り入れた
- コミュニケーションフローを可視化した
前提
-
開発人数5-15名のスタートアップ
-
なんでも屋さんがいる
- コーダー兼、デザイナー
- CTO、兼コーダー
- 自社開発 or 丸投げな受託開発など
-
フルリモート、フルフレックスを採用
内容
弊社は、フルリモート・フルフレックス制をとっています。また、会ったことがないスタッフの方が大半であるというgitlabのような働き方を採用しています。まずは、どうやってコミュニケーションを円滑に進めるかが課題でした。
はじめにやったこと
- slackとNotionの導入
- zoomの導入
- とりあえず色々と進めてみる
その結果、何が起きたか？
-
何がどこにかいてあるかわからなくなった
どの情報をslackで共有し、どの情報をNotionにまとめるのかの線引きが全くなされていませんでした。その結果、どの情報がクリティカルなものであり、どのコードがjust ideaになっているのかわからなくなってきました。
また、プロダクトに関わる人数が10名程度になり、誰が何をしているかを把握するのが非常に困難になりました。これは、スタートアップや小規模ベンチャーにありがちな、なんでも屋さん（コーダー兼、マーケター。デザイナー兼、コーダー）が生まれてしまうことに原因があると思っていまして、うまくRoleを分ける必要があると感じました。
-
コミュニケーションが円滑に進まない
「slackで、個人DMで連絡をとっては、全体に共有する。」といった運用をしていましたが、コミュニケーション効率が悪かったり、全体に共有し忘れるなど、そもそも何を共有したか忘れると言ったことが多々起きました。スタートアップでは、マルチタスクが当たり前ですから、5分前はデザインをしていて、今はコーディングしているといったことはよくあるかと思います。そんな中でとあるタスクを誰に相談するべきか、意思決定者は誰なのかも徐々にわからなくなりました。
-
機能追加の際に、出戻りが多い
次から次に、なんでも屋さんがなんでもするものですから、気づいたらUIがおかしくなっていたり、ここの仕様が矛盾していると言ったことがよく起きました。少ない資本力のベンチャーですから、出戻りほど機会損失になるものはないかと思っています。
試作
-
SlackとNotionの棲み分けを定義
まずは、SlackとNotionの棲み分けを定義しました。弊社では、次から次に経営陣がアイディアを出し、それがjust ideaなのか、戦術として有効なものなのかをマーケターと共に議論していました。そこで、just ideaな部分は全てslackでやりとりを行い、ある程度現実味があるもの（試作として行うもの）だけはnotionにまとめるという「棲み分け」を定義しました。Notionでは、現在進行中のタスクをわかりやすいように表記し、今何が行われていて、何が終了したのかを明確にすることにしました。
-
Roleという概念を作成
なんでも屋さんが生まれてしまう小規模ベンチャーにおいては、なんでも屋さんに対してRole(マーケター・デザイナー・フロントエンドエンジニア・バックエンドエンジニア)を定義しました。2つ以上のRoleを持つ人は、あたかも2人存在するように扱うようにしました。次に、このRoleに応じてフロー図（下図参照）を作りました。どの段階でどのようなコミュニケーションが行われるのかを明確に定義しました。そして、出戻りを防ぐために1つ目の図でいう③以降は、絶対に出戻りが出ないようにデザインカンプをとことん詰めることにしました。さらに、このフロー図を参考にして、slackチャンネルを分けました。例えば、弊社で運営するITスクールRareTECHに関わるプロダクトは、図のようにわけました。この時、番号をある程度このコミュニケーションの番号と一致させることで誰がどのチャンネルにいるべきか、誰はどのチャンネルにいるべきでないかを明確にしました。結果としては、slack運用でよくある、チャンネルが増えすぎて訳がわからなくなる現象も解消することができました。
この様に、Roleという概念を用いて言語化してまで区分を意識することに意味があると感じています。
-
個人DMは、原則禁止
弊社では、「心理的安全性」を取り入れていますが、それでもなお細かな質問が個人DMで行われいていることが多かったので、個人DMを禁止にしました。その結果、デメリットとしてすぐに情報が流れていってしまうことが起きましたが、全体像をCEO、CTOが理解できるようになり、結果としては成功でした。
-
ツールの統一
弊社では、UI系は全てfigma、アーキテクチャー設計はdraw.io、コード管理はgithubを利用すると定義しました。特にUI系は色々なツールがあり、色々な人が色々なツールを使ってくるとカオスになるため、このようにルールを定めました。慣れていない人もいるという声が聞こえてくるようですが、長い目で見るとこの運用のほうがいいかと思っています。
結果
以上により、戦術決定と実装に明確な境界ができ、なんでも屋さんの「なんでも」を言語化することができました。結果としては、それぞれの責任が明確になり、あらゆる試作が同時実行されている中でドキュメント管理は平易化し、試作のコンフリクトもかなり少なくなりました。
組織構造はビジネスのスケールに伴って随時変更していく必要があるとは思うのでこれが完璧なBest Practiceではありませんが、Better Practiceとして取り入れる価値はあるかと思います。
宣伝
弊社では、インフラ学習サイトEnvader（エンベーダー）とITスクール（RareTECH）を運営しています。また、企業研修やシステム開発なども行っていますので興味がある方はHPよりご連絡下さい。
Discussion