“フルフレックス×フルリモート”でも品質を高めるために　Notionを活用したプロジェクト立上げの仕組み化

小笠原氏の自己紹介

小笠原智氏：それではよろしくお願いします。私からは「フルリモート×非同期でのプロジェクト立上げの仕組み化」について話したいと思います。

まずは自己紹介からスタートしていきたいと思います。（スライドを示して）私、小笠原は、経歴はWebデザイナーとしてガラケーサイトのデザインやコーディング、あとはWebサイトやアプリのグラフィックデザイン、WordPressの構築など、今と違ってデザイナーとエンジニアの境がちょっと曖昧なキャリアからスタートしました。

その後はWebディレクターとしてサイト制作に携わりました。その後はPMとしてキャリアを積んで、2022年6月に株式会社LboseにPMとしてジョインしました。ちょうど（入社して）1年になります。

稼働を少々セーブした週4勤務をしています。入社当時はクライアントさまの案件を担当していて、現在は社内改善プロジェクトや採用、あとはアサインなどを行う開発マネジメントチームに所属しています。よろしくお願いします。

株式会社Lboseの特徴

それでは今回の本題ですね。プロジェクト立上げの仕組み化について話したいと思います。イベントの始めにあった会社紹介と重複しますが、弊社の特徴を2点伝えたいと思います。

（スライドを示して）1点目はメンバー全員がフルリモートの組織であることです。オフィスは熊本県にあるんですが、必要最低限の機能しか持たず、一部のメンバー、主にバックオフィス（の方々）が使用しています。そのため、弊社ではSlackを“オフィス”と呼んでいます。

2点目が、社員も含めてメンバー全員がフルフレックス、つまり非同期となっていることです。フルリモートかつ非同期コミュニケーションの開発環境下において、開発するプロダクトの品質を高める施策が必須であると考えています。その中で、今回はイベントのテーマである「プロジェクトの立上げの仕組み化」に注目して話したいと思います。

プロジェクトのスタート時に重要視している3つのこと

（スライドを示して）まずはプロジェクトのスタート時に重要視しているところは何かから話したいと思います。もちろんたくさんあるのですが、今回は3点に絞りました。

1点目が初期情報の共有です。弊社はBizDevチームが商談に出席して契約につなげます。この時に商談時の情報ややり取り、プロジェクトの概要をBizDevから担当のPMに引き継ぎをするんですが、その時の情報や温度感を含めて伝えることを重要視しています。

2点目が、先ほど「フリーランスの集まり」とありましたが、多種多様なフリーランスが集まることから、メンバー間のコミュニケーションや役割分担、あとでお伝えするドキュメント文化を推奨しています。

3点目が、フルリモートかつ組織が非同期であることから、情報のプラットフォームの設置と、メンバーへの情報の共有のしやすさを重要視しています。

「プロジェクトキット」を活用したドキュメント文化づくり

こういったところからまず取り入れたのがNotionでのドキュメント管理です。けっこう利用されている方も多いかと思いますが、Notionは比較的自由度が高くて、ドキュメントやページを作成できるツールです。

このNotionを使って、先ほどお話しした初期情報の共有とドキュメント文化の構築、情報のプラットフォームの設置など、プロジェクトに関する情報を集約する環境を整えようというところから始めました。

（スライドを示して）社内ではNotionのこの部分を「プロジェクトキット」と呼んでいて、あらかじめ情報をカテゴライズして、開発プロジェクトに誰が・いつ・どのタイミングでアサインされても同じ情報をキャッチアップできるベースを構築することになっています。これをテンプレートとしてNotionに登録したものをプロジェクトキットと呼んでいます。

商談が発生したタイミングで、まずBizDevチームがこのプロジェクトキットを利用します。このテンプレートには、情報のカテゴライズとして大項目のプロジェクトサマリー、議事録などは必須で用意してあるんですけど、その中身は各プロジェクトメンバーに委ねています。これは案件の性質によって開発手法が異なるため、それらに対応する柔軟性を保つためにやっています。

現在はこのプロジェクトキットを社内で推奨して、ドキュメント文化を作っているというフェーズになります。

ちょっと脱線しますが、前回の弊社の副業イベントでプロジェクトキットを少し紹介したら、Notionアンバサダーの方も含めていろいろと反応をいただけたので、おもしろい仕組み（なの）かなと捉えています。

話を戻します。このプロジェクトキットを弊社内でも1つのプロダクトとして捉えて、社内アンケートやインタビューを行っています。

先ほどお伝えしたとおり、プロジェクトの性質によって手法が異なるので、平均して必須のドキュメントなどを、プロダクトの品質担保としてできることはないかを考えながらアップデートしています。（画面を示して）今見せているグラフでいうと、「アサインされる時に、用意されていなくて困ったドキュメントは何ですか？」みたいな、そういった当たり前なことも含めてアンケートをしています。

それらをUXリサーチとして抽出してプロジェクトキットに反映し、プロジェクトの立上げに活かします。

実際に社内でプロジェクトキットについてのインタビューを行ってみると、PMからは「どこにドキュメントを置くかを指定されているだけでも考える負担が減るよね」とか。エンジニアに関していうと「最近他のプロジェクトに行ったんだけど同じフォーマットになって見やすくなった」という声も上がっています。

なので、こういった共通フォーマットがあるだけでも環境改善になっているかなと考えていて、社内でもプロジェクト立上げ段階で一定の評価をもらえているかなと考えています。

そもそもなぜ仕組み化を進めているのか

ここまで弊社のプロジェクトの立上げの仕組み化についてお伝えしましたが、最後にそもそもなぜ仕組み化を進めているのかも伝えさせてください。

（スライドを示して）弊社の開発チームのポリシーに、（スライド）真ん中の「As One Team」があります。チームで高め合って、チームで補い合って、チームとして成果を出す。クライアントを含めて、One Teamであるというポリシーを掲げています。

冒頭にあったように、弊社はクライアントの隣に立って伴走するチームを提供しています。そのため、効率化できるところはどんどん仕組み化して、その分ヒトができるところの厚みを増やしていきたいと考えています。そこが何かというと「ユーザーにとってより良い価値」を作り出す（ことで、その）ための時間を作り出したいと考えています。そのために効率化できるところをどんどん仕組み化していきたいなと考えています。

事業のコンセプトが「明日から、あなたの開発チームに。」ということで、本日話した仕組み化も含めて、メンバーの規模やフェーズに寄り添って、日々アップデートを検討してより良いプロダクト開発をしていきたいなと思っています。

以上です。ご清聴ありがとうございました。