このnoteはpmconf主催のプロダクトマネージャー Advent Calendar 2023の14日目の記事です。

こんにちは、株式会社エルボーズでPMを担当している小笠原です！
この記事では「プロジェクトマネージャーが社内の業務改善のために業務システムを構築した」話をしたいと思います。

弊社は企業の新規事業の開発支援をメイン事業としています。開発メンバーの特徴は全員がフルリモートであり、メンバーの80％以上（要確認）が業務委託・フリーランスです。社内では「“誰と、どこで、何をするか”を、もっと自由に。」のミッションの元、稼働時間に制限を設けず柔軟な働き方を尊重しています。
しかし、『「フルリモート×非同期」のコミュニケーションはめちゃくちゃ大事だよね！』と思っていながらも上手く回っていない実情もありました。

いくつか要因があるのですが、その中でも経験豊富なメンバーが多く在籍するからこそ、開発の手法が様々で合ったり、プロジェクトの進め方が担当PMに依存しているため管理方法バラバラになっていたりと、全員の“当たり前”が違っていたことがありました。

また参画してからすぐにプロジェクトがスタートするため、「ひとまず自分のやりやすい方法で！」と言った具合に各自が自己流のやり方で進めてしまい、再現性がなかったりナレッジが溜まりにくい状態も影響していました。

こういった課題を解決するため2022年7月に社内で開発Opsチーム（※）が結成されました。メンバーはPMの小笠原とフリーランスエンジニアの久保田さん（株式会社Antiphase）を中心に動き出しました。
※仮名称で結成したチームです、こう言う時なんて名前にしたら良いんでしょうね（笑）

開発Opsチーム

最初の課題

前述の通り、それまでは柔軟な働き方で参画いただいてた個人に依存し過ぎたため、自己流の管理方法で再現性が低く、統一されたフォーマットがなかったため、引き継ぎやキャッチアップにも時間がかかっていました。何よりも組織としてのナレッジが蓄積されにくい状態でした。

そこでまず社内で各ポジション毎にに何「を期待しているのか？ 何をサポートして欲しいのか？役割は何か？」の“目線合わせ”のワークショップを開催しました。

そこから明確化されたことはバックグラウンドの違うフリーランスの集まりだからこそ“常識“が違う、しかし戸惑いがありつつもプロジェクトを動かしながら“どうにかなっちゃってる状態”が続いていたことでした。

この表面化しづらい課題を解決するために、実際にプロジェクト管理をするPMを対象にスターターキットを用意し、プロジェクトの序盤をサポートする計画がスタートしました。

PMの「プロジェクト管理＝体験設計」と捉え、クライアントや開発メンバーにプロジェクト完遂するまでの体験を提供するものと定義つけました。そして開発Opsは新規参画したPMも迷わずプロジェクトを進行できるスターターキットや環境整備をするところから始めました。

プロジェクトキット（プロトタイプ時代）

少し話を過去に遡ると、これまで社内では様々な管理ツールを試しました。が、うまく合致するものが見つかりませんでした。

リッチ過ぎていたり、そもそも業務フローが決まっていない中でのツール導入は放置しがちになっていました。そんな中でコスト面や社内整備をする上でカスタマイズ性があり、かつノーコードで業務管理が作れるNotionに弊社は賭けることにしました。

このような背景から開発OpsはNotionを基盤としたプロダクト開発のスターターキットの作成に移りました。

商談から開発まで、すべての情報を集約する

まずプロダクト開発の情報管理を統一するためにドキュメントのプラットフォームとなるNotionのテンプレートを作成しました。このテンプレートを社内では「プロジェクトキット」と呼び、プロダクト開発の情報一元化を目的にLbose社内で全体で運用することを決めました。

「（プロジェクト名）_ドキュメント一覧（下記img参照）」はプロジェクトキットのコアとなるデータベースです。それぞれの性質の違うドキュメントの棚を用意し、収めるドキュメントの場所を統一しました。

プロジェクトキットは成約前の商談段階からセールスチームが使い始めます。これまでPMはクライアント情報を口頭ベースやセールスの提案資料の共有されいてました。しかしそれでは理解度や解像度が低くいため、クライアントの肌感や希望、そしてこちらがどんな提案したかなどを「相談メモ」ページに残すことにしました。

契約後はプロジェクトの概要を記述する「プロジェクトサマリー」ページを用意することで、「誰が・いつ・どのタイミングでアサインされても同じ情報をキャッチアップできる」環境を用意しました。その他、要件定義書や仕様書、デザインや設計書など、実開発に関わる全てのドキュメントを保管する場所を「開発ドキュメント」ページと決め、ドキュメントが散らばらないようにしました。これによりどの案件でも同じフォーマットでドキュメント管理ができるようになりました。

こうしてプロジェクトキットの必要最小限の価値となる「ドキュメントのプラットフォーム」が出来たため、どの開発でも迷うことなく資料を見つける環境が整いました。

評価軸と仮説検証〜正しい対象はエンジニアだった？〜

プロジェクトキット（以後、PJ KIT）の初期の構築時にはUXリサーチャーの草野さん（株式会社メルペイ）にアドバイザーとして入っていただき、UXリサーチャーの観点から課題の整理と検証の方法をご教示いただきました。その中で「評価軸」というものがありましたのでご紹介します。

評価軸は「誰にとっての質かなのか」「ユーザーにとっての価値は何になるのか」を項目として明文化したものです。この軸を決めることでPJ KIT開発の方針が決まり進むべき道を目線合わせ出来ました。

また評価軸はPJ KITの作成後には、仮説検証の指針となります。PJ KITの価値として設定した評価がユーザー（=社内メンバー）にとって有益であったのか？その仮説を検証するために使います。もしこれでユーザーにとって価値のないものであればこの評価は見直す必要がありますが、それはユーザーにとってのコア価値を掴むチャンスにもなります。

PJ KITは社内施策ですが、小さく作りリリースして仮説するリーンスタートと同じ方法を採用しています。ユーザー価値を定義した上で最小限のプロダクトを検証し、中長期の拡張性も視野に入れてスタートしました。

使われないシステム

しかし、実際にプロトタイプをPMに見せたところ想像以上の抵抗がありました。特に経験年数の長いPMはこれまで自身がやっていた開発手法を全て変えられると思われてしまいました。後になって分かったですが、そもそもNotion自体を使ったことなく、知らないツールの上にプロジェクトキットが乗っかったため、初見での理解がとても難しいものでした。

またPJ KITを認知されることも難しかったです。全体定例やSlackで社内周知してもをしても『プロジェクトキットって何ですか？』など、社内施策であっても認知されにくいことに驚きを隠せませんでした。

こういった状況の中でも新規プロジェクトから導入したり、全社施策として何度も周知したりヒアリングを行いながら理解者を増やしていきました。

正しい対象はエンジニアだった？

検証を続けていくうちにある傾向が見えてきました。PMは要件定義やスケジュールなど、自身が作成するドキュメントの置き場所にはそこまでこだわりがなかったのです。むしろPM以上にドキュメントに敏感に反応を示したのがエンジニアでした。
「（PMが作成した）ドキュメントがどこにあるかわからない」
「仕様書がない」
「設計書がない」
etc.

『あれ？もしかしてプロジェクト参画時に困っていたのはPMではなく、エンジニアだったのでは？』という発見がありました。弊社はPMよりエンジニアの人数が圧倒的に多いです。またAPI設計書やDB設計書など、実開発に関するドキュメントはエンジニア（テックリード）が作成します。また実装のタスクやチケットはテックリードが起票します。つまり開発の中盤以降はPMよりエンジニアの方がPJ KITの更新をすることが多くなります。

そこでPJ KITの調整を入れました。まず「開発ドキュメント」ページに開発に最低限必要なドキュメントの項目名だけを明記したデーターベースを用意しました。これによりドキュメントの作成漏れを防ぐことにしました。

また実際にNotionでタスク管理をしているテックリードからヒアリングをし、現場に馴染みやすいタスク一覧のテンプレートを用意しました。そしてPJ KITはプロジェクト開始時は空白のままなので、どう使って良いか迷う声もありました。こうした意見には「PJ KIT サンプル版」を用意し出来る限り実開発に近い形で共有することにしました。

PJ KITの認知は社内全体にかけつつ、理解や運用はCTO室と連携を取りテックリードを中心にプッシュすることで実運用やPJ KITのアップデートを進めていくことにしました。これらが上手くワークした秘訣は小さく始めて検証していったことで柔軟に調整が出来たことだと思っています。

最後に

現在、開発Opsチームは解散しています。前述の通りPJ KITはメインターゲットをエンジニアに寄せたことでCTO室直下での管理・運用の方が効果的と判断したためです。共にPJ KIT開発をしていった久保田さんはCTO室に移り、私は開発マネジメントチームにいます。お互いのチームで上がった施策や仕組みをPJ KITに反映させるため、時々に擦り合わせながら検証とアップデートを繰り返しています。開発の中心にPJ KITを置くことで、各チームの社内施策がバラけないように社内横断で連携する効果もあるようです。

Notionはノーコードツールではありますが、エンジニアの久保田さんがいて本当に良かったと思っています。それはNotion内のデータベースの設計や拡張性を考慮する際にエンジニアの視点が欠かせないためです（これからNotionエンジニアのような職種も出てくるかもしれませんね）。PJ KITがエンジニア向けになったのも、もしかしたらNotionとエンジニアの親和性があるのかもしれません。

PJ KITリリース当初は全社施策とは言え、運用や認知の難しさを感じました。しかし、少しでも興味を示していただいたメンバーから巻き込んでいき、役員陣にもアナウンスをお願いしました。また参画時のオンボーディングでも重要性を刷り込んでいくことで社内認知を獲得しました。

つい最近ではプロトタイプで拒否反応を示していたPMが積極的にプロジェクトキット使ってくれるようになりました（心の中では涙涙です）。検証初期段階では分からないこともあります、協力者から巻き込み、徐々に周囲の理解者を増やすことで全社に広がったのだと思います。

今回は「プロジェクトマネージャーが社内の業務改善のためにPJ KIT（社内業務システム）を構築した」話について書きました。小さく始めて検証し成長させていく大切さを感じました。

最後までお読みいただきありがとうございました。