PM-Controlの始まりは、AIともう少し丁寧に仕事をすること

PM-Controlを始めたのは、新しい「AI platform」を作りたかったからではありません。理由はもっと日常的なものでした。毎日、プロジェクト資料、Backlog、Google Sheets、ソースコード、会話を行き来しています。AIはそれぞれの作業を支援できますが、共通の進め方がないと、古いデータを使ったり、操作は正しくても文脈を間違えたりします。

最初は、よく使うscriptとpromptを少しずつ集めていました。しかし続けるうちに、足りないのは新しいtoolではないと気づきました。必要だったのは、正しい情報を取得し、範囲を理解し、進め方を決め、元のシステムに反映し、完了前に結果を確認するという安定した流れでした。

PM-Controlは、少しずつ五つの考え方を中心にまとまりました。

繰り返し大切になる五つのこと

一つ目は、データの持ち主を明確にすること です。WBS、issue、source code、確認済みの知識がどこに属するのかを先に決めます。ローカルのsnapshotは処理を便利にしますが、元のシステムを静かに置き換えるものではありません。

二つ目は、作業の近くにruleを置くこと です。各repositoryやfolderで、AIができること、確認が必要な場面、完了に必要な証拠を説明します。共通ruleはrootに、具体的なruleは対象fileの近くに置きます。

三つ目は、taskの種類ごとにworkflowを分けること です。code修正、管理データの更新、顧客向け文書の作成では、同じ手順を使いません。参照する情報、確認のタイミング、成功の確かめ方がそれぞれ違うからです。

四つ目は、持ち運べるプロジェクト情報 です。長く使う情報はMarkdownやYAMLで残し、人が読めて、version管理でき、別の環境でも使えるようにします。作り直せるindexや生成データは分けて管理します。

最後は、完了前に証拠を確認すること です。codeなら関連testやbuild、API更新なら反映先からの読み直し、文書なら正しい形式と言語でのpreviewです。「完了しました」という言葉には、確認できる結果を添えたいと考えています。

PM-Controlが目指していないこと

PM-Controlは、すべてをAIに決めてもらう仕組みではありません。作業範囲を決め、重要な変更を承認し、最終判断を持つのは人です。AIは検索、整理、繰り返し作業を担当し、workflowがその力を正しい方向へ案内します。

しばらく使って感じた一番の効果は、commandを数回減らせたことではありません。同じ背景を説明する回数が減り、以前のtaskを再開しやすくなり、変更した理由も追いやすくなりました。

そのとき初めて、AIが「すぐ答えを出すtool」ではなく、日々の仕事を一緒に進める相手に少し近づいたと感じました。