入社半年で気づいた「2つの人力の限界」
株式会社アクセルラボでPdMを担当している藤丸です。
弊社のプロダクトはB2B2C構造で、不動産管理会社・物件オーナー・入居者・デバイスメーカー・施工業者など、複数のステークホルダーが一つの機能に関わります。IoTデバイスの制約も重なるので、要件の複雑さは構造的に跳ね上がります。
関わる人が多ければ、そのぶん会議や調整の場が増え、決まりごとも増えます。しかも決まった内容が残る場所はバラバラで、あるものは会議の議事録に、あるものは Slack のスレッドに、あるものは 1on1 のメモに散らばっていく。情報の量と散らばり方が、記憶と手作業で管理できる範囲を超えていくのです。
入社して半年ほど経ったころ、私はこれを「人力の限界」として2つに整理しました。
① 決まった経緯が消える
「なぜこの仕様になったか」が議事録のどこかに埋もれて後から追えない。半年前の自分が合意した内容を、今の自分が追えないことがある。
② タスクが様々な場所で発生し散らばる
関わる案件が増えるほど、アクションアイテムが議事録・Slack・1on1に分散して、自分の手元にある仕事の全体像が見えなくなる。「あの件どうなったっけ」を探す時間が積み重なる。
これは多くのPdMの現場でありがちなことだと思いますが、仕組みがないと構造的に起きがちです。
まず正直に言っておくと、この記事で紹介するのはチームの標準ではなく、私ひとりで検証・運用している仕組みの話です。「こうすればうまくいく」ではなく、「こういう構造的問題に気づいて、こう対処してみた」という一つの記録として読んでください。
この記事では、この ①「決まった経緯が消える」 と ②「 タスクが様々な場所で発生し散らばる」 を解決するために作った、会議録から仕様書更新・タスク可視化まで自動でつなぐドキュメントパイプラインの話をします。
パイプラインの発想
解決策として考えたのは、散らばった入口を一つの議事録形式に合流させて、記録を自動で育てるパイプラインです。 会議が終わったら議事録が自動で取得され、Slack での決定もコマンド一つで同じ形式に取り込まれる。
構造化された議事録は仕様書に反映され、アクションアイテムも統一フォーマットで記録される。この「記録」の流れをほぼ自動にします。記録さえ揃えば、タスクの集約はあとからいつでもできます（後述）。 メインの入口は Google Meet の会議です。Gemini が自動で文字起こしドキュメントを生成します。これを Claude Code が取得して構造化し、仕様書を更新し、git commit します。翌朝には Slack DM で処理結果が届いています。 会議の外で決まったことも取りこぼしません。
Slack での合意や判断は、/slack-to-minutes でスレッドごと同じ議事録形式に取り込めます。最近は URL を一件ずつではなく、会話をまとめてサーベイして一括更新する使い方が中心です。入口はバラバラでも、合流地点は一つ——これが、課題②「タスクが様々な場所で発生し散らばる」に対する基本方針です。
なお、この仕組みは社内で承認されたツールと環境を利用し、社内のデータ取り扱いルールおよびアクセス権限に基づいて運用しています。
処理の流れ：「集める→残す→知らせる」の3ステップ
パイプラインを動かすのは、毎平日 20時 に自動起動する議事録収集コマンド（/daily-mtg-sync）です。なぜ 20時 かというと、Gemini の文字起こしは会議終了から 15〜30 分後に出来上がるので、19時台に終わる会議でも 20時 にはだいたい揃っているからです。
やっていることは、大きく「集める→残す→知らせる」の3ステップです。
補足：AIが勝手に仕様を書き換えるわけではありません。 「残す」のステップで仕様書に反映されるのは、あくまでその会議で決まった内容です。更新は差分（diff）として git に残り、CHANGELOG に「どの議事録のどの決定が根拠か」が記録されます。
コミットは"AIの判断"ではなく、MTGで決めたことをそのまま履歴に刻む操作だと考えると分かりやすいと思います。人はあとから差分を見て確認・修正できます。
この「残す」のステップが、①「決まった経緯が消える」への手当てになっています。会議で決まったことが仕様書の差分と CHANGELOG として残るので、ステークホルダーの多いこのプロダクトでも、「なぜこの仕様になったか」を後から履歴で追えます。
散らばったタスクを一箇所に集めるコマンドを作った
①に目処がついたら、次は②「タスクが様々な場所で発生し散らばる」です。
ここまでは「記録」を自動化する話でした。記録が統一フォーマットで揃うようになると、次は集約です。蓄積された議事録・1on1ファイルを横断で走査し、自分の未完了タスクを案件名つきのテーブルで一覧化する（期日順）——それが未完了タスク一覧コマンド（/my-tasks）です。
「あの件どうなったっけ」が、コマンド一発で解消できる。 地味ですが、これが一番日常的に使っています。
導入前と、いま
導入前の私は、「あれはなぜそう決まったんだっけ」を探して議事録を掘り返し、「あの件どうなったっけ」を探す時間を積み重ねていました。冒頭に挙げた2つの課題は、いまこう変わっています。
「使いながら育てている」状態ですが、①「決まった経緯が消える」と②「タスクが様々な場所で発生し散らばる」 の構造的な問題に対して、自分なりの回答を持てた手応えがあります。
コードを書かなくてもパイプラインを設計できます。Markdown でコマンドとエージェントのプロンプトを書いて Git で管理し、会議→仕様→タスクの流れを自動化できます。 PdM にとって新しい選択肢だと思っていますし、まだ試していないことのほうが多いです。
現在は完全自動ではなく「ほぼ自動、崩れたら手動」くらいの温度感が実態で、この仕組みは、運用しながら少しずつ育てている最中です。
おそらく同じ課題を持っているPdMの皆様は世の中にたくさんいらっしゃると思います。本記事がそんな皆様の一助になれば幸いです。
📩 お問い合わせ・採用情報
本ブログを読んでいただきありがとうございます。 もし内容にご興味を持っていただけましたら、以下よりお気軽にお問い合わせ・ご応募ください。
スマートホームの導入をご検討中の企業様へ：
アクセルラボへご興味を持たれたみなさまへ：
アクセルラボでは採用を強化しています。 私たちの技術やビジョンに共感し、スマートホームの未来を共に創っていきたい方のご応募をお待ちしています。 👉株式会社アクセルラボ 採用サイト - ACCEL LAB RECRUIT-
