Notionを活用して 『フルリモート × 副業メンバー』 でゼロからプロダクトを開発した方法
起業1年目 25歳
プロダクト開発未経験
リモートマネジメント未経験
役員＆正社員にエンジニアは0名
こんな私が、Notionを活用して フルリモート × 副業メンバー でプロダクトを開発した話です。
プロダクトの構想が始まったのは、2020年の11月からです。12月からデザイン・2021年1月〜5月中旬に実装、クローズドβ版を5月下旬に提供開始しました。
そして改善を積み重ねて、オープンβ版として本日PRさせていただいた次第です。
企業とYouTuberをつなぐマッチングプラットフォーム「Talema.」オープンβ版をリリースします！
— Hironobu Yamamoto (@nobu_llllllllll) November 4, 2021
企業とインフルエンサーにとって価値あるプラットフォームを構築していきます！https://t.co/mSeFbXtsVa pic.twitter.com/uXWk0mpKVp
私は何も成し遂げてないですし、現在プロダクトはPMFに向けての試行錯誤のフェーズです。なので、このnoteは決して「価値がある情報」と言えるかはわかりません。ただ、同様の状況でプロダクト開発に挑戦したいという方の参考になったらいいなと思い、今回記事を書きました。
また「フルリモート × 副業メンバー」ですと、通話やミーティングなどの同期接続の機会を頻繁に作れないので、ドキュメント中心の開発文化にすることを徹底しました。それが結果的に、デザイナー・エンジニアに非常に好評でした。なので、リモート環境でドキュメントを中心とした開発の仕組みづくりを企画・実行している方にも、参考になれば幸いです。
開発メンバーの声
・必要な情報が「検索」でヒットするので便利
・ドキュメントでコミュニケーションする「意識と行動」が徹底される
・「テンプレート」に一貫性があり、ムダな労力を使わないので楽
・ドキュメントが豊富になるため、新規メンバーの「参加ハードル」が低い
・「Slackと連携」して業務に溶け込ませることができている
・全ての議事録が確認できるなど、とにかく「情報が集約」されている
もしも、少しでも参考になれば「スキ」をつけていただけると非常に嬉しいです。初noteなので「スキ」の重みというか感覚がわかっておりませんが、、、どうかビギナーズラックをお願いします！笑
では早速、現時点での『結論』をご覧ください。10ヶ月の開発期間を経て確立した、Notionを活用したプロダクト開発の方法です。
結論｜Notionを活用したプロダクト開発
まず、プロジェクトのトップページは上記のようになっています。
今回取り上げるのは「プロダクト開発＞開発実行」に記載されている、以下のブロックです。業務開始時に、メンバーは以下の番号に沿って業務を実行します。
■ 開発実行
『 1️⃣ 質問』
『 2️⃣ 緊急タスク・バグ』
『 3️⃣ プロダクトバックログ』
『 4️⃣ 非緊急タスク・バグ』
数字の番号は「実行優先度」を意味します。これによって、プロジェクトの管理が劇的に簡単になりました。
上記のページ内には、実行するべきことがドキュメント化されているため、開発はドキュメントべースで進行できます。それと同時に、優先度を示しているため、意思決定の時間を最小化することができ、メンバーは迷うことなく、やるべきことに集中できます。
□ ■ □ ■ □ ■ □ ■ □ ■
前提として、開発手法はスクラムを採用しています。
スクラムでは、機能や要求、要望、修正などプロダクトに必要なものを抽出し、順番に並べ替えたプロダクトバックログと呼ばれるリストを作成します。
それぞれの項目はプロダクトバックログ上で一意な順番を持ち、順番が上位のものから開発します。そのため上位の項目ほど内容が具体的で詳細なものになります。
プロダクトバックログは、一度作って順番に並べ替えたら完成ではありません。絶えず要求が変わったり、新たな要求が追加されたりします。また作る順番も状況に合わせて変わります。したがってプロダクトバックログは、プロダクトを作っている間はずっと更新を続け、常に最新に保たなければいけません。
□ ■ □ ■ □ ■ □ ■ □ ■
数字の番号が「実行優先度」とはどういうことかというと、業務を開始する際に『 1️⃣ 質問』『 2️⃣ 緊急タスク・バグ』『 3️⃣ プロダクトバックログ』『 4️⃣ 非緊急タスク・バグ』の順番で実行しましょうということです。
なぜ、上記のような優先度になったかを説明します。
タイトルにある通り、私たちのチームは、プロダクトの設計から現在までリモートで開発をしました。そして、本業がある副業メンバーが開発をしています。
そのため「フルリモート×副業メンバー」では、頻繁にミーティングや相談の時間を確保できないことに気づいたからです。本業タイムには、もちろん業務があり、副業メンバーは 平日の夜や休日しか業務時間が取れません。それに加えて、メンバーにもそれぞれの予定があります。
よって、頻繁なミーティングは難しいと判断して、週1回の定例ミーティングを開催していました。しかし、最初はミーティングが相談や問題解決の機会になりがちで、開発スピードが遅くなっていました。
「ミーティングで話せばいいや〜」とメンバーの1人でも思ってしまうと、ミーティングは週に1回しか開催されないため、相談までのタイムロスが発生してしまいます。
そこで導入したのが『 1️⃣ 質問』という場所です。
1️⃣ 質問
『 1️⃣ 質問』は、バックログの開発実行中に発生した質問を、チケットで管理する場所です。 作成したチケットをもとにコミュニケーションを取り、解決した結果をチケットに記載します。ミーティングに頼らず、常に困りごとは最速で助け合おうということです。
まずは、テンプレートから「質問チケット」を作成します。
チケット作成後は、Slackでチケットの確認依頼・進捗の連絡などをします。
チームとして最大のパフォーマンスを生み出すために、『 1️⃣ 質問』は何よりも優先度を高くしています。そして、定例MTG内で質問や相談をすることを推奨せず、ドキュメントでの質問回答・問題解決にこだわっています。
質問をドキュメントにすることで、新規メンバーが過去の質問を検索して同様の問題を解決するケースがあり、複利として効くという良さがあります。メンバーからも、Notionは検索フィルターが豊富で、困ったときに検索すれば解決策が見つかり、体系的に情報がキャッチできると好評でした。
Notionの「Quick Find」を活用した検索
Notionの「データベース」を活用した検索
2️⃣ 緊急タスク・バグ
次に『 2️⃣ 緊急タスク・バグ』は、緊急で対応が必要なタスク・バグを管理する場所です。ユーザーのために最優先しなければならないと判断されたものなので、バックログよりも優先度を高くしています。
まずは、テンプレートから「緊急タスク」を作成します。「バグ・課題・要望」各ケースに応じて、アイコンとテンプレート文章が入力されます。
利用場面としては、重大なバグ・仕様漏れ・ボトルネックを解決できる簡易施策などが『 2️⃣ 緊急タスク・バグ』に該当します。
プロダクトは、ユーザーがいるからこそ成立します。なので、ユーザー視点で『 3️⃣ プロダクトバックログ』よりも早急に対応する必要があると判断されたチケットは、『 2️⃣ 緊急タスク・バグ』で管理されます。
つまり、メンバーは業務開始の際に、『 1️⃣ 質問』『 2️⃣ 緊急タスク・バグ』のチケット所持をしていないか？を確認して、なければ『 3️⃣ プロダクトバックログ』に着手するという流れになっています。
3️⃣ プロダクトバックログ
『 3️⃣ プロダクトバックログ』は、開発の中心となる場所です。バックログを起点に、プロダクト開発を進めます。チームメンバーは担当するバックログからタスクを分解します。分解したタスクを実行して、バックログを完了に導きます。
バックログはカンバンで管理していて、左から右にフェーズを進行させて、完了を目指します。
ステータスについて
バックログ：プロダクトチームが実現したいことを考える
デザイン中：デザイナーがUI・UXをデザインをする
仕様検討中：プロダクトチームが仕様を検討する
開発未着手：エンジニアチームの開発を待機する
開発実行中：エンジニアチームが開発する
完了：バックログが実現している
時系列でいうと「開発実行中」が現在なので、左に進むほどプロダクトが実現したい未来 になるというわけです。そのため、デザイナー・エンジニアは、次回のバックログが何かを事前にインプットすることもできますし、プロダクトチームの構想を理解しやすくなります。
「バックログ」をテンプレート作成すると、以下の内容が自動で生成されます。
ポイントは、なぜやるのか？（Why）です。これを記載することで、デザイナー・エンジニアがユーザストーリーをイメージしやすくなります。
プロダクトチームとしても、テンプレートに従って言語化をすることで、開発優先順位をつけやすくなり、勢いで不要な機能を開発することを防げます。
バックログは「ユーザに提供（リリース）する機能」を単位に作成しています。そのため、全てのバックログがユーザー目線のドキュメントで統一されています。
私たちは、機能アイデアが思いついたら、まずはこのバックログを作成します。
では、次にこのバックログにどのような順番で実行するのか？つまり、優先順位をどう決めるのかという問題です。バックログが山のように積み上がっていくだけでは意味がありません。
そこで、優先順位に関してもNotionを活用しています。
具体的には、バックログ作成時にプロパティ項目を入力すると「優先順位」が自動で調整され、バックログが並び替えされるようにしています。
実際のバックログを見ていただくとイメージしやすいかと思います。
画像の赤枠が「優先順位」に関係するプロパティ項目になります。
※ 各項目の意味は後ほど説明しますので、ここでは構造を見てください
プロパティごとに、バックログ全体の並び替えルールを設定しています。
さらにプロパティ内にも優先順位があります。つまり、まずは「狩野モデル」というプロパティの優先順位で並び替えされます。「狩野モデル」が同じ値だった場合は、次に「ボトルネック」という優先順位で並び替えされます。「狩野モデル」も「ボトルネック」も同じ値だった場合は・・・と繰り返されるわけです。
このルールをもとに、作成したバックログが並び替えられ、上位にあるバックログほど優先度が高いという設計を実現できます。
『 3️⃣ プロダクトバックログ』の優先順位には、以下の5つのプロパティが影響しています。
① 狩野モデル
② ボトルネック
③ 影響度（Moat）
④ キャッシュ価値
⑤ 影響がある顧客
特に優先順位に影響を与える「① 狩野モデル・② ボトルネック・③ 影響度（Moat）」について説明します。
□ ■ □ ■ □ ■ □ ■ □ ■
① 狩野モデル
プロダクト開発はやりたいことが山積みに出てきます。特にプロダクトオーナーである自分はアイデアが思いつく度に、実装をお願いしたくなってしまいます。
そんな衝動を抑えて、顧客視点に立たせてくれるプロパティが『狩野モデル』です。笑
「狩野モデル」は、品質管理の専門家である東京理科大学名誉教授・狩野紀昭氏によって提唱された、顧客満足度と品質の関係を表したモデルです。「Kano Model」として、海外でも広く知られています。顧客満足度を左右する品質の要素を5つに分類し、それぞれ優先順位をつけるのが狩野モデルの特徴です。
「狩野モデル」の優先度（上から優先度が高い順）
当たり前：顧客にとって「あって当たり前」の品質要素
一元的：満たされていれば顧客はより満足するが、満たされていなければ顧客が不満に思う品質要素
魅力的：満たされていれば顧客が満足し、満たされていなくても顧客が不満に思わない品質要素
無関心：満たされていてもいなくても、顧客の満足度に影響がない品質要素
逆行：満たされていると顧客が不満に思い、満たされていないと顧客が満足する品質要素
簡潔に「狩野モデル」をまとめると、まずは顧客が不満に感じる課題を解決して、その後に付加価値となる魅力的な機能を開発していきましょう ということです。
（参考記事がわかりやすく解説してくれていますので、興味がある人は是非一度読んでみてください）
プロダクトを開発してPMFを目指していると、顧客解像度が上がっていく中で「これが実現すれば！！！」みたいなアイデアが思いつくことがあると思います。
そんなときに、狩野モデルを入力するときに「この機能はあったら嬉しいけど、顧客の不満ではないよな…」と冷静になり、優先順位が下がります。（バックログは奥深くに眠ります。笑）
↓ 眠りについている「109個」のバッグログたち…
とは言っても、奥深くに眠ったバックログも定期的に見直すことで、事業進捗や顧客解像度によって優先順位が変わることがありますし、何よりアイデアメモを具体的かつ冷静に残せるので気に入ってます。
② ボトルネック
狩野モデルだけでは、「当たり前」「 一元的」「魅力的」の3種類に分類されることが多く、さらにそこからの優先順位付けが必要になります。例えば「一元的」のバックログが10個あるとき、何から開発するの？ということです。
そこで、現在採用しているプロパティは「ボトルネック」です。「ボトルネック」は「目的を達成する際に障害や問題となること」と定義しています。つまり、シードの私たちにとっては「PMFを達成するために障害や問題となること」に該当し、それを A・B・C のレベルで分類 します。
PMF前のプロダクトの問題・仮説は変化するので、週次レベルでこの項目を見直して、いま最重要課題に向き合えているのかを整理しています。
工数が少ないバックログはリソース調整しやすいので、取り掛かりたくなりますが、ボトルネックがあることで何となくの開発を防げます。
③ 影響度（Moat）
ボトルネックプロパティを入力しても、優先順位が同位になるバックログは「影響度（Moat）」プロパティで判断します。「影響度（Moat）」は「複利となり、長期的な優位性を築けること」と定義しており、それを A・B・C のレベルで分類 します。
Moat について、以下記事の内容を参考にしています。
Moat(モート)とは事業という城が外敵(競合)から攻められたときに、事業を守り続けてくれる"堀"、つまり競合優位性や企業の強みのことです。長く続く事業を作ろうとする際には、このMoatがあることが必須になります。
狩野モデルの「当たり前」に属するバックログは、Moatに該当しないものもありますが、ほとんどのバックログには、何のMoatを築いているのかを言語化しています。
記事で紹介されている10個のMoatを、プロダクトにとっての重要度で A・B・C のレベルに分類しています。何のMoatを築いているのかを言語化したら、それに該当するレベルを選択するという流れです。
これを実施することで、なぜやるのか？（Why）という深堀りを、ユーザー視点だけでなく、プロダクトの長期的な優位性という側面からも考えることができます。
□ ■ □ ■ □ ■ □ ■ □ ■
上記の手順で「優先順位」を決めて、並び替えはNotionに任せるという運用をしています。
プロパティを追加・変更・削除するときもNotion上で簡単に実行できますし、並び替えもそれに応じて自動で切り替えることができるので、状況が変化してもムダが発生することなく、優先順位付けが行えます。
その分、バックログを作成するコストは増しますが、開発の上流を大切にすることで、結果的に課題にフォーカスした開発ができ、悩むことや不安になることは少なくなりました。
「優先順位」は、色々な記事や本を参考にしましたが、多くのケースが苦戦していたり、方法が多岐に渡っていたので、これだ！という情報はありませんでした。なので、常にベストを考え抜いて、現在進行形で調整しています。
以上が「優先順位」についての説明です。
ここまでで「プロパティ」と「なぜやるのか？（Why）」の入力が完了します。
「なにをやるのか？（What）」「どうやってやるのか？（How）」はデザイナー・エンジニアを巻き込んで進行していきます。
ステータス「バックログ」「デザイン中」「仕様検討中」を進行しながら、チームでバックログを完成させていくイメージです。
そうして「なぜやるのか？（Why）」「なにをやるのか？（What）」「どうやってやるのか？（How）」が記載された状態で、バックログは「開発未着手」に移動します。
これで副業メンバーのエンジニアが、万全な状態でバックログを開発することができます。
まだまだ、バックログについて話したいことはあるのですが、、、
もう1つ「おすすめのプロパティ」を紹介します。
それは 関連する「質問」 というプロパティです。
これは、冒頭で紹介した『 1️⃣ 質問』で作成したチケットで、バックログに紐づくチケットが入力されています。
チケットを作成するときに、プロパティにある「関連するバックログ」を入力することで、『 3️⃣ プロダクトバックログ』のバックログにも自動で入力されるという仕組みです。
これは「リレーション」というNotionの機能です。「リレーション」を利用することで、データベース間で情報を連携できるようになります。
ちなみに 関連する「質問」 の内容をクリックすると、以下のように画面が展開します。
これでチケット名をクリックすると、以下のように質問の内容を確認することができます。
「リレーション」の活用により、バックログに関連する質問が集約されます。ドキュメントベースでの質問を徹底すると、バックログ完了までの経緯が透明化され、特に本業との切り替えが必要な副業メンバーにとっては、見返して、キャッチアップする際にも楽になります。
以上が、開発の中心となる『 3️⃣ プロダクトバックログ』の紹介です。
4️⃣ 非緊急タスク・バグ
『 4️⃣ 非緊急タスク・バグ』は、プロジェクトで早急に対応は必要がなく、余裕があるときに取り掛かるタスク・バグを管理する場所です。
『 4️⃣ 非緊急タスク・バグ』は『 2️⃣ 緊急タスク・バグ』と同じデータベースです。同じデータベースを「緊急」「非緊急」のタグで分けて、それぞれのフィルターを適用して表示しています。
以下のように、チケットのプロパティから「緊急」「非緊急」を選択すると、自動で『 2️⃣ 緊急タスク・バグ』or『 4️⃣ 非緊急タスク・バグ』に分類されます。
よって、『 3️⃣ プロダクトバックログ』を境界線として、対応が必要なタイミングで『 2️⃣ 緊急タスク・バグ』 に移動することができます。なので『 4️⃣ 非緊急タスク・バグ』は記録が目的であり、早急に対応する必要がないものです。
これにより、バグやタスクの抜け漏れを防げますし「非緊急タスクを作成して一旦放置で、プロダクトバックログに集中しよう！」というようなコミュニケーションができます。
長くなりましたが、以上が Notionを活用したプロダクト開発 です。
以下の「実行優先度」で業務を実行
1️⃣ 質問
2️⃣ 緊急タスク・バグ
3️⃣ プロダクトバックログ
4️⃣ 非緊急タスク・バグ
以下を「週1回のミーティング」で実行（業務は非同期で実行）
・プロダクバックログのリリース確認
・プロジェクト改善のアイデア出し＆議論
・次週までのプロダクバックログのゴール設定
Notion × Slack の活用方法
連絡は「Slack」問題解決は「Notion」と棲み分けをしていますが、組み合わせた活用方法を紹介します。
① ワークフローで「実行優先度」を徹底する
副業メンバーには、業務開始と終了時に「勤怠」と「ワークフロー」を入力してもらっています。
こうすることで「実行優先度」を必然的に確認できますし、チケット・バックログ単位で業務内容を入力するので、誰が・何に取り組んでいるのか、ひと目でわかります。
現在の副業メンバーとの契約は分単位の時給制なので、質問を回答するために数分のみ出勤することも気軽に可能です。
② チケット所持者に自動でメンション通知を送信
NotionのAPIを活用して『1️⃣ 質問』『2️⃣ 緊急タスク・バグ』のチケット所持者に、Slackで定期的にメンション通知しています。自動で通達されるので、『3️⃣ プロダクトバックログ』の作業に入る前に、自分が担当しているチケットがあれば、抜け漏れが減ります。
記憶に頼ってしまうと、忘れることや抜け漏れをすることは必ず発生すると思います。いかにやるべきことを明確にして、情報を探す時間を最小化するかということを意識して設計しています。
Notion × Figma の活用方法
Notionは、Figmaの画面を埋め込むことができます。これを活用して、仕様書もNotionで作成しています。
Figmaの画面リンクをコピー&ペーストして「Embed Figma」を選択すると
簡単にFigmaの画面を、Notionに埋め込むことができます。画面の拡大・縮小・移動が可能で、Figmaの該当ページに遷移することもできます。最大のメリットは、Figma上でのデザイン変更が、埋め込んだFigmaにもリアルタイムで反映されることです。
シード期のプロダクトは特に可変性が高いので、FIX版というものが存在せず、常に変化すると思っています。なので、画像データを貼り付ける方法だと、デザインの変更が必要になったときに、関連する全ての画面仕様に変更を加えなければいけません。
Figmaを埋め込むまでは、この更新作業というのが本当に億劫でした。。ただ、最低限の仕様書がないとエンジニアが開発する貴重な時間が、認識の齟齬などにより、無駄になってしまう可能性も高くなります。それに、画面仕様にミスが複数回あると、エンジニアもやる気が削がれますし、ミスを防ぐための情報収集に時間を過度に費やすかもしれません。
なので、Figmaを埋め込んだ仕様書を作成して、Notionのバックログに情報は全て集約するという活用をしています。
仕様書については、最低限必要な情報は何か？を常に意識して、項目などを調整しています。運用しながら改善して、現在は上記のような内容となっています。
とにかく全体を通して言えることは、利用ツールを絞り込み、プロダクトに関する全てのワークフローを「Notion」「Slack」「Figma」で実行できることを目指しています。
Notionの活用方法については、以上で終了です。わかりにくい箇所などは追記していくので、もし質問などがありましたら気軽にTwitterでリプライ・DMしてください！
プロセス｜最初はNotionはおろかSlackさえ使っていなかった…
ここからは、プロダクト構想から現在に至るまでのプロセスを紹介します。どのように現在のNotion活用方法に至ったのか、興味のある方はぜひ最後まで読んでください。
いま思えば恐ろしいことに、最初はNotionはおろかSlackさえ導入されていない開発環境でした。（起業してから、受託制作でクライアントとはChatworkで連絡を取っていたので、まとめた方が楽だなと思い、Chatworkグループで連絡をお願いしていました。。）
メンバーの意見を聞いたり情報収集をしていく中で、現在の形式に至りました。その変容の一部を紹介します。
仲間を探す
まず、私はデザインもエンジニアリングもできません。圧倒的な無力を実感して、知り合いにできる人はいないか？と考えました。
まずは、高校が同級生の友人エンジニアに連絡しました。僕は知識がなかったのですが、彼はソフトウェアエンジニアではなく、組み込みソフトウェアエンジニアでした。なので、実務経験はあるが自社プロダクトの開発経験はありません。
ただ、彼なら大丈夫だろういう信頼があったので、副業での参画を依頼したところ、快く承諾してくれました。役割はPMですが、何でも屋という感じですね。笑
結果的に、彼と試行錯誤してNotion活用法を創ります。スクラム・狩野モデルなどを導入したのは彼ですし、常に課題を何かしらの方法で解決に導いてくれる心強い存在となっています。
（そんな彼を誘い続けて、今月11月から転職して 当社のCTOに就任してくれることになりました。これで役員・正社員のエンジニアは0名ではありません！）
次に、デザイナーを探しました。知り合いにいなかったため、紹介してもらいました。プロダクトに共感してもらえたこと、話していてフィーリングが合ったので、すぐに依頼をしました。UI・UXは、このデザイナーの方がほぼ全て監修してくれています。スピード・品質ともに高いです。センスが合うためなのか、大きな修正事項を依頼したことはなく、とても重要な役割を担ってくれています。
プロダクト開発において、初期エンジニアの重要性は、書籍・記事などで散見されていますが、初期デザイナーの重要性は、ユーザー視点からすると、同等もしくはそれ以上のインパクトがあると思っています。
また、Notionを紹介してくれたのもデザイナーの方です。自身のタスク・プロジェクトをNotionで管理しているのを見させてもらい、こんなツールがあるのかと衝撃を受けました。
次に、実装メンバーとなるサーバーサイドエンジニアは友人の友人に依頼しました。サーバーサイドの設計は、全てお任せしました。当時は何もわからなかったのですが、Kotlin + Spring Boot というモダンな構築をしてくれたことやプロダクトの長期的な構想を考慮した設計をしてくれたことには、感謝しかありません。※ 自社プロダクトの開発経験はなし
最後に、実装メンバーとなるフロントエンドエンジニアです。複数の方を紹介してもらったのですが、なかなか条件に合う人がおらず、困りました、、
当社に出資いただいている East Ventures・金子さん に相談したところ「Offers」というエンジニアのマッチングプラットフォームがおすすめだと紹介いただきました。
すぐに「Offers」の6ヶ月プランを契約して、1週間ほどでフロントエンドエンジニアの方を採用することができました。プロダクトに共感してもらえたこと・年齢が近いこと・事業ドメインにも強く興味があることが決め手になり、依頼しました。その方の得意な技術である Vue.js & Nuxt.js で、爆速で開発してもらいました。 ※ 自社プロダクトの開発経験はなし
その後も「Offers」で複数名の副業エンジニアを採用するのですが、優秀な人と出会うことができ 『フルリモート × 副業メンバー』という環境は「Offers」があったから実現できたといって過言ではありません。
スクラムを知る
メンバーには、週1回のZoomミーティングで課題に対しての進捗を報告してもらい、新しい課題を設定して期限を切る、という流れでプロジェクトを進行していました。
しかし、フルリモートなので課題に対する進捗が見える化できず、週1回のミーティングでしか把握できていませんでした。なので、スケジュールが予測しにくいことや、遅延したときに何が原因になっているのかわかりにくいという問題が発生しました。当時は、Slack利用していなかったので、気軽な相談もしにくい状況だったと思います。
かといって、細かく詳細まで進捗報告をしてもらうようなマイクロマネジメントをすると、スピード感が遅くなりますし、本質的な解決策ではないなと思い、もやもやしていました。
これを高校友人エンジニア（現CTO）に相談すると、スクラムという開発方法を教えてくれました。おすすめの本を数冊読み、衝撃を受けました。
問題を早期発見して全力で即時に対応するという考え方は、『1️⃣ 質問』『2️⃣ 緊急タスク・バグ』が『3️⃣ プロダクトバックログ』よりも優先されるというNotionの活用方法につながっています。
私たちが実行している「Notionを活用したプロダクト開発」は、上記の本の影響をかなり受けています。そして、スクラムの思想は「プロダクト開発」だけでなく、「タスク管理」や「案件管理」などさまざまなシーンで転用しています。
Notion × スクラム × 〇〇
ここでデザイナーの方が利用していた「Notion」というツールを思い出します。Notionは、カンバン形式での管理ができること・気軽かつ直感的に使えることから、チームでスクラムを浸透させるには相性が抜群でした。
このときは『1️⃣ 質問』『2️⃣ 緊急タスク・バグ』『4️⃣ 非緊急タスク・バグ』のような利用方法は構想していませんし、Notionの検索・フィルター機能が、ここまで豊富だったことも知りませんでした。
とりあえず操作しながら覚えていき、これできないのかな？という課題も手探りで解決していき、現在の運用方法に変化していきました。そのため、最初はシンプルなカンバン形式のスクラムでした。
実際に活用する中で「優先順位」という壁にぶつかり、本文で紹介したように「狩野モデル」というプロパティをスクラムに導入して解決することになりますが、自動で「優先順位」が整理される以外にも良かった点が沢山ありました。
まず「優先順位」をプロパティとして見える化することで、チーム全体のプロダクトへの解像度が上がりました。例えば「『当たり前』と『一元的』のここまで終わらせて〇〇までのリリースを目指す！などのコミュニケーションができるようになり、共通言語として浸透できる点もよかったです。
開発以外の業務でも「それって『魅力的』じゃないかな？『一元的』の〇〇からやろう！」というような話し合いが自然にでき、意思決定がスムーズに納得感ある形で行えます。
企業文化をSlackのスタンプで浸透させるように、これからはNotionのプロパティで企業文化が浸透するなんてことがあるかもしれません。Notion × スクラム × 企業独自のプロパティ のバックログデータベースは、企業やプロダクトのプロセスが詰まった資産になると思っています。
シンプルなルールで運用する
その後も、週1回はプロジェクト改善のミーティングを開催して、副業メンバーが働きやすい環境で、最速でアウトプットができるように、Notionの仕組みやルールを変化させてきました。
一貫しているのは「Slack × Notion × Figma」で全てを解決させるシンプルな仕組みです。GoogleDriveやスプレッドシートも本当に必要かを考え直し、現在は一切使用せず運用しています。
また、Notionはテンプレートのカスタマイズが詳細まで行えるので、プロダクトバックログや議事録を、作成者が別の人でも決まった形式になるので差異が出にくいです。そのため、メンバーのキャッチアップも慣れてくると楽になります。
ワンクリックで上記のような議事録が生成できます。テンプレート内に『1️⃣ 質問』『2️⃣ 緊急タスク・バグ』のページリンクを記載できるので、この議事録の画面を共有しながらミーティングを実施して、議題になったらページに遷移することも簡単にできます。
リンクだけでなく、データベースもテンプレートに埋め込めるので、上手く活用すればかなりの単純作業を削減できます。
このようにドキュメントは徹底的に工夫してNotionにしています。もちろん、この議事録の文章も「検索」で表示されるので、形骸化されることなく資産性を持つドキュメントになります。
ツールは、シンプルな目的で利用し、横断を最小化する！
・Slack：コミュニケーション
・Notion：ドキュメント
・Figma：デザイン
思考｜コスト体質は組織優位性となる
その前に: コスト優位戦略の前にもっとも大切なこと
コスト優位性を考えるまずその前に、自分の会社のコスト体質を見直してください。スタートアップなのに大手企業よりも高いオフィス賃料を払い、採用費用をエージェントに払い、無駄な広告をうち、高いコスト体質となってしまった企業が散見されてきました。
いくらコスト優位がつくれたとしても、そのコスト体質だと利益率で大手に敵いませんし、コスト優位性でとても大切な組織の経営実行力がない、と暗に示している事になります。
上記の記事を初めて読んだときは、あまり現実味がありませんでした。コスト体質を見直すというと、費用を削減するようなイメージのままで、ムダなものにお金を使わないのは当然だよなーぐらいの感覚でした。笑
しかし、実際に起業して人を雇うことでわかったのですが、何者でもないスタートアップのシード起業家にとって、コストは「死を意識してしまうような本能的な痛み」があると思っています。仮に手元に数億円・数十億円があったら、同じ痛みを感じ、同じアクションをしたのでしょうか？制約があるからこそ、フルリモート × 副業メンバーのリソースを活用するという工夫を重ねて、現在の方法に最速で至ったのだと思います。
つまり、限られたリソースで成果を最大化しないといけないスタートアップは、徹底したコスト体質を必然的に形成しやすいと思っています。それがメンバーの1人1人に染み込み、時間を重ねることで、組織は複利的に二次関数的に成長するのだと信じています。
それが、プロダクト・テクノロジーの裏に隠れた「スタートアップの組織優位性」であり、この形成をスキップしてはいけないと個人的に思っています。そして、Notionの活用が「コスト体質の改善につながる」のであれば、Notionを愛用している私たちにとっては嬉しいことです。笑
結論はそれらのひょっとして必要かもと思ったのが全部要らなかったんだ。ホントに必要なら後から追加すればいいんだし。追加はカンタンで誰でもできる。
でも削ること、減らすこと、これが難しいしこれができないと成功にはたどり着かないんだ。
制約があるからこそ、本質的な課題に集中できる
リソースがないからこそ、本質的な課題に集中できる
余計な選択肢がないからこそ、本質的な課題に集中できる
スタートアップは、何者でもない挑戦者であるからこそ、価値提供にまっすぐ向き合える、向き合わざるを得ないのだと思ってます！こんなにシンプルでフラットで楽しいことはあるのでしょうか。
NotionでToDo・CRMも管理
現在では、メンバー各個人のToDo・セールスのCRMもNotionで管理します。『3️⃣ プロダクトバックログ』を転用しており「狩野モデル」は ToDo・CRMでも活躍しています。
「ToDo」もスクラム形式で管理しています。「CRM」はリレーション機能を活用して、情報のつながりを表示できるようにしています。
こちらにも独自の工夫があるので、もし今回の記事で反応やニーズがありましたら、紹介させていただこうかと思います。
あくまで、Notionはツールであり、実行することが一番重要だと思いますが、スピード・生産性を向上させる施策として、Notionはまだまだ活用できそうです。
最後に
ここまでお読みいただきありがとうございました。
プロダクトに関わるに先輩のみなさまは、今回のnoteより沢山の事例やノウハウ・壁を超えた経験を持っているかと思います。
みなさんのNotion活用法も、ぜひ教えてください！各企業とのコラボレーションがNotionで進むようになる未来を願っています。
ご感想・フィードバック・ディスカッションなど Twitter でお待ちしております。
もし弊社サービスに興味を持っていただけたら、是非とも下記から連絡してください！
この記事が気に入ったらサポートをしてみませんか？