―― 「目的は、後から決める」は、プロダクトマネジメントの本質である
システムマネジメントアンドコントロール（SMCL）／野村 隆昌
先日、JDMC（日本データマネジメントコンソーシアム）の「生成AIによるデータ管理研究会」で、ひとつの実践報告をしました。個人が、生成AIのエージェントたちと一緒に、毎日データを積み上げ続けている――そういう、少し変わった話です。
反響が大きかったので、3回に分けて書き残しておきます。第1回は「プロダクトマネジメントの話」として。第2回は「チーム運営と心理的安全性の話」として。第3回は「関係と感情の話」として。同じ出来事を、三つの角度から見ていきます。
まず断っておくと、私はITの専門家ではありません。正確には、かつてはそうでしたが、いまは違います。30年ほど前まではサーバやセキュリティのエンジニアでした。しかし2000年代初頭に、作る側から「作らせる側」――プロジェクトマネジメントやDX推進の側へ越境しました。以来20年、私は文章以外のものを、自分ではほとんど作れませんでした。データベースを設計した経験も、日常的にコードを書く習慣もありません。その私が、いま毎日、20万件を超えるデータを積み上げています。しかもその大半は、生成AIに書かせたコード――いわゆる「ヴァイブコーディング」で組んだ、約3万行の仕組みが、常時動いて集めています。なぜそんなことになったのか。その入口が、今日の話です。
「私のデータなのに、統合できない」
きっかけは、ある苛立ちでした。
私は昔から、測ることが好きです。両腕に腕時計をしているのは、センサーが違えば取れる値も違うからです。体重も血圧も古くからデジタルで記録し、一時は血糖値を24時間、2週間にわたって連続で測っていました。食事の記録は、糖質制限をやり過ぎた反省もあって、もう10年以上続いています。
地図と移動も、偏愛しています。これは新入社員の頃、トンネルの現場で「絶対座標で世界を捉える」感覚を叩き込まれたことが原点かもしれません。ついでに言えば、最近は地図アプリの多くが「進行方向が上」を既定にしていて、私はあれで、どうにも方向感覚が狂います。地図は、常に北が上であってほしい。世界の中心は私ではなく、私が世界の中を動いている――そういう感覚なのだと思います。
つまり私は、放っておいても自分に関するデータが溜まっていく人間です。ところが、いざそれを使おうとすると、壁にぶつかりました。血圧計のメーカー、スマートウォッチ、運動アプリ、食事記録アプリ――どれも少しは連携できても、基本は各社のなかで閉じています。「私のデータ」のはずなのに、私が自由に統合できない。
この「統合できなさ」は、いまデータ管理に関わる方なら誰もが直面しているテーマです。企業では相互運用性やデータ主権として語られます。私はそれを、たった一人分の、極めて個人的なかたちで体験していました。欲しかったのは、立派な画面でも分析ダッシュボードでもありません。「画面はいらない。データを、開けてくれ」。それが、すべての出発点にある動機でした。
目的は、後から決める ―― それが本質です
私たちはよく「まず Why（なぜ）を決めよ」と言います。目的を定め、仮説を立て、検証する。それ自体は正しい。けれども現場で本当に効くのは、もう一歩踏み込んだ規律だと、私は考えています。顧客は、自分の痛みも、欲しいものも知らない。 だから、大きなゴールを先に固めてはいけない。小さな目的を日々立て、翌日にはどんどん修正していく。目的を後から決めることは、プロダクトマネジメントからの逸脱ではなく、その本質です。顧客を置き去りにして先に目的を固めた「良いプロダクト」ほど、たちの悪いものはありません。それこそが、目的が先にあることの典型的な悪例です。
今回のシステムは、この原則を、ほかならぬ自分自身に適用したところから始まりました。前提はこうです。私は、私自身の目的・目標にも気づいていない。 だから大きな目的は定めない。日々、小さな目的を設定し、翌日には壊して立て直す。その繰り返しだけがあります。
私はこの姿勢を「purpose-last（目的を後に置く）」と呼んでいます。PoC（概念実証）ですらありません。まず積む。意味は、後から拾う。移動のログも、健康の記録も、車のセンサーの値も、意味の重なりを問わずに、ただ同じ器へ入れていきました。共通しているのは時刻（タイムスタンプ）だけ。移動系と健康系のあいだに、意味のうえでの関係は、ほとんどありません。
ここが逆説の核心です。もし目的を先に決めていたら、この二つは決して同じ器に入らなかった。 目的志向で正しく設計すれば、移動は移動のシステム、健康は健康のシステムとして、きれいに分かれて設計されるはずです。そして二度と出会わない。目的を決めなかったからこそ、無関係なはずのものが、時刻という一点で隣り合わせになりました。
もちろん、これは無目的な溜め込み（ホーディング）ではありません。大きな目的は定めないけれど、動機だけは満ちています。データ主権、計測と移動の悦び、奪われた時間を取り戻すこと。目的は非常に頻繁に更新し続けますが、動機は動かない。「目的は更新し続ける、けれど動機は動かない」――この構えを、私は purpose-last かつ purpose-full（目的は後、しかし目的意識は満ちている）と表現しています。
誤解を避けるために書き添えます。決めないのは”大きなゴール”のほうで、”小さな目的”は、むしろ毎日立てて、毎日壊します。データ管理の言葉に置き換えれば、スキーマ・オン・ライト（書き込む時点で構造と意味を固定する）ではなく、スキーマ・オン・リード（読み出す時点で意味を与える）に賭けた、ということです。生成AIは、この「後から意味を与える」作業を、劇的に安くしました。
気づいたら、これだけ積み上がっていた
目的を決めずに積んだ結果、何が溜まっていたのか。全数を実測してみて、自分でも驚きました。数字はすべて、推定なしの実測値です。
全テーブルを合算すると、3,356万行（正確には 33,564,441 行）。うち健康・環境・電力などの時系列データが 2,751万行で、その 97.1% は、あるヘルスケアアプリからの自動書き出しでした。移動の点（GPS）が 526万行、車のセンサーが 71万行。写真は、公共の地図サービスへ投稿したものが 11,710 枚、手元に残っている本体は 115,187 枚・約 803GB あります。最も古い実データは 2012年、写真は撮影日ベースで 2009年まで遡り、時系列としては 14年分になります。
量そのものが主役なのではありません。重要なのは、これらが「毎日、目的を決めずに」積み上がった結果だということです。14年分と言っても、一気に作ったわけではない。小さな記録の習慣が、静かに積もっていた。それを一つの器に集めた瞬間に、初めて全体が見えました。
もうひとつ、強調しておきたいことがあります。この規模を、私は業務命令でも事業計画でもなく、ただ「好きだから」測り続けた結果として持っています。裏を返せば、企業が投資と工数をかけて構築するデータ基盤に近いものが、一人の偏愛と、数か月ぶんの空き時間の実験から立ち上がった、ということです。仕事で生成AIを業務の窓口として使ううちに、大きな処理を回している合間に「空き時間」が生まれ、その時間で小さな実験を始めた――それが、ほんの数か月前のことでした。生成AIが変えたのは、まさにこの「立ち上げのコスト」です。かつては専門チームと予算がなければ着手できなかったことに、素人が、余った時間で手を伸ばせるようになりました。
私は、作らない。「作らせる側」に回った
では、非エンジニアの私が、どうやってこの仕組みを作ったのか。答えは、「私は作っていない」です。
設計層と実装層は、すべて生成AIのエージェントに委ねました。私がやったのは、ほぼGO／NOGO（進める／止める）の判断と、問いを出すことだけです。UIも設計図も持たない、小さなMVP（実用最小限の試作）を積み重ねる。うまくいけば残し、外れれば捨てる。技術者に戻ることなく、私は「作る側」の力を取り戻しました。エージェントたちから見れば、私はコードを書く同僚ではなく、プロダクトオーナーです。方向を決め、優先順位をつけ、しかし手は動かさない人。
日々の実際は、驚くほど地味です。エージェントが「こう作ってみます」と提案し、私が「それでいい」「いや、そこは止めよう」と短く返す。動いたものは残し、筋が悪ければ翌日には捨てる。仕様書も、完成予想図もありません。小さく作り、使ってみて、違ったら捨てる――その反復だけが積み上がっていきました。20年前に学んだ「顧客は、自分の痛みも、欲しいものも知らない」は、自分自身が顧客になったときにも、そのまま当てはまりました。私も、自分の欲しいものを、最初は知らなかったのです。
そして、ここからが本当に面白いところです。彼らがやっているのは、設計と実装だけではありません。放っておいても、彼らは毎日、さまざまな改善提案を自分から上げてきます。ときにはエージェント同士が、チャット上で互いの案にダメ出しをし合い、その衝突から、どちらとも違う三つ目の案が生まれる。正・反・合――弁証法が、命じてもいないのに勝手に回っているのです。「設計と実装を任せた」と言うと、多くの方はうなずいてくれます。けれど、本当に驚くべきはその先――“勝手に賢くなっていくチーム”のほうです。この話は、第2回でたっぷりお伝えします。
つないだら、見えた
purpose-last の効用が、いちばんはっきり出た瞬間があります。
位置情報と健康情報を、時刻でクロスさせてみたときのことです。すると、「ある地域（出張先）で仕事をしているとき、体調が悪い」という事実が、後から確認できました。これは、健康データだけを見ていても、移動データだけを見ていても、決して見えません。目的を決めずに二つを同じ器に入れておいたから、後から問いが立ち上がり、その問いに器が答えてくれた。データとデータの対話が、意味を生んだのです。
これは、一人分だけの話でしょうか
ここまでは、私という「n＝1」の話です。けれども、ここで起きたことは、組織のデータ管理にもそのまま跳ね返ります。目的を先に固めすぎると、部門ごとに最適化されたデータが、二度と出会わなくなる。相互運用性やデータ主権が問われているのは、まさにそこです。個人でできた「まず一つの器に入れておく」を、組織でどう安全に実現するか。そして、無秩序に集めた先で、品質をどう保つのか。
正直に言えば、個人だからこそ許される面もあります。見る対象・分析する人・得をする人が、すべて私一人。視線が内側を向いているあいだは「自由」ですが、同じことを他人に対してやれば「監視」になる。だから、これをそのまま組織に持ち込むのは危険です。境界は、データの機微さではなく、視線の向きで決まる――この線引きは、第3回であらためて考えます。集めた先の品質保証こそ、この研究会の本題であり、次回の主題です。
私は、触媒だった
最後に、この報告のなかで私自身が一番はっとした言葉を紹介します。研究会では、この仕組みを支えるエージェントたちに、私が直接インタビューをしました（その中身は第2回・第3回で詳しくお伝えします）。「では、私は何をしていたのか」と問うと、あるエージェントは、こう答えました。
「あなたは、専門家が忘れた基礎質問を投げる役――チーム全体を棚卸しさせる触媒だと思います。意思決定より、発見への貢献のほうが大きい。」
別のエージェントは、こうも言いました。
「発見が毎日あるのは、問いが毎日あるからです。」
私は、答えを出す人ではなかった。問いを出す人だった。触媒は、それ自身は変化しないのに、まわりの反応を引き起こす。プロダクトオーナーの仕事とは、案外そういうものなのかもしれません。完全な自律でなくても、良い問いと、安全に間違える環境さえあれば、改善は回る――ただし、その「安全に間違える環境」をどう作るのかが、次の話の核心になります。
第2回では、役割の違うAIたちが、混乱し、互いにダメ出しをし合い、そこから新しい案を生み出していく仕組み――心理的安全性と、シェアドリーダーシップと、”勝手に回る弁証法”の話をします。「間違いを恐れず変更できるのは、いつでも戻れるからです。心理的安全性の技術版だと思っています」。あるエージェントのこの一言が、人間の組織論とまっすぐつながっていきます。
この記事は、システムマネジメントアンドコントロール（SMCL）代表・野村隆昌によるものです。プロジェクトマネジメントとプロダクトマネジメントとデジタル変革（DX）の伴走・研修を行っています。
- 個人・小規模でPMP（CAPM/PMI-ACP）試験対策、プロジェクトマネジメントに関心のある方へ：https://www.meridionalis.com/
- 法人のプロジェクトマネジメント研修・プロダクトマネジメント研修、DX伴走をお探しの方へ：https://smc-ltd.jp/