1. はじめに
独力＋AI活用で月商1億円を目指している。
最近、開発用PC、確認用端末、ChatGPT、Cursor、自動テスト、ドキュメントを組み合わせながら、かなり本格的に開発を進めている。
AIを使うと、実装スピードは確かに上がる。
アイデアを整理できる。
実装指示を作れる。
コードを書ける。
テストも作れる。
ドキュメントも整備できる。
ブログ記事まで書ける。
ただし、ここまで進めてきて強く感じることがある。
AIを使うほど、プロジェクトマネジメントの考え方が重要になる。
AIがいるから管理が不要になるわけではない。
むしろ逆である。
AIを複数使い、PCも複数台使い、ドキュメントも増え、試験も増えてくると、役割分担、進捗管理、課題管理、不具合管理、制限事項管理、Close条件がないとすぐに混乱する。
最近、そのあたりの整備がかなり進んできた。
2. AIは作業者になるが、管理者ではない
AIは強力な作業者である。
しかし、AIはプロジェクト全体の責任者ではない。
AIは言われたことをやる。
ただし、たまにズレる。
実装してほしいのにドキュメントを直す。
YES / NOで聞いているのに曖昧に返す。
修正済みと言いながら、確認条件が弱い。
前提が変わっているのに、そのまま進めようとする。
だから、人間側が管理しなければならない。
自分はPMPの資格を持っていることもあり、プロジェクトマネジメントの考え方はかなり意識している。
人間のチームでも、役割、責任、進捗、課題、リスク、完了条件が曖昧ならプロジェクトは崩れる。
AIを使う場合も同じである。
むしろ、AIは速く動く分、管理が弱いとズレも高速で積み上がる。
3. 役割分担がかなり整理されてきた
現状、開発体制はかなり整理されてきた。
ざっくり言うと、以下の役割分担である。
| 領域 | 役割 |
|---|---|
| 開発用PC | 実装、修正、ビルド、自動テスト、PR対応 |
| 確認用端末 | 実機UI確認、シナリオ試験、スクリーンショット、再確認 |
| ChatGPT | 方針整理、指示文作成、記事化、判断補助 |
| Cursor | 実装作業、修正、テスト追加、ドキュメント更新 |
| ドキュメント | 正本ルール、残課題、制限事項、試験結果、進捗記録 |
以前は、確認用端末にも実装をさせようとして、やや混乱した。
しかし今は、開発用PCを主戦場にし、確認用端末は常時並行開発ではなく、節目レビューや実機確認に寄せる形になっている。
これはかなり良い。
開発用PCは作る。
確認用端末は見る。
確認用端末がP0/P1を出す。
開発用PCが直す。
確認用端末が再確認する。
この流れが見えてきた。
4. 制限事項とブロッカー管理も整ってきた
最近かなり重要だと感じているのが、制限事項とブロッカー管理である。
試験をすると、いろいろな問題が出る。
ただし、それらを全部同じ扱いにすると混乱する。
本当に今すぐ直すべき不具合。
既に分かっている制限事項。
まだ未実装の範囲。
後回しにしている機能。
上流の問題が原因で確認できない下流工程。
これらを分けないと、同じ問題を何度も報告してしまう。
そこで、既知ブロッカーや制限事項を管理する台帳を整備した。
この台帳では、以下を整理する。
既知ブロッカー
制限事項
何が何にブロックされているか
再開条件
開発残課題との関係
後回し機能との関係
開発用PCが対応すべきか
確認用端末が再試験すべきか
これにより、確認用端末が同じ制限事項を毎回P0/P1として量産することを防げる。
また、上位ブロッカーが未解消なのに、下流工程を無理に何度も試験する無駄も減らせる。
これはかなりプロジェクト管理らしい整理になってきた。
5. 「Fixed」と「Confirmed」を分ける考え方
不具合管理で特に重要なのが、Close条件である。
開発用PCが直しただけでは、完了ではない。
開発側が修正した状態は、あくまで Fixed。
確認用端末が再確認して、実際に解消を確認した状態が Confirmed。
この考え方を明確にした。
これは非常に重要である。
開発側は「直した」と思っている。
でも、確認側で見ると直っていないことがある。
別の状態では再発することもある。
期待した改善と違うこともある。
だから、BOSPCが直しただけではClose相当にしない。
Surfaceが再確認してConfirmedになって初めてClose相当とする。
このルールが入ったことで、かなり品質管理らしくなってきた。
6. 重複指摘と無駄な再試験を防ぐ
確認用端末で試験を回すと、同じような指摘が何度も出る可能性がある。
たとえば、上流の問題が原因で後続画面に進めない場合、下流の確認項目が全部失敗する。
そのたびに新規P0を作っていたら、残課題が爆発する。
そこで、今は以下の考え方を入れている。
同一不具合を重複登録しない
上位ブロッカー配下の下流工程を無理に繰り返し試験しない
制限事項を毎回P0/P1として量産しない
上位ブロッカーが未Fixedなら、下流工程はBlocked byとして整理する
別原因の問題なら新しいIDを採番する
これは、AIを使った試験運用ではかなり大事である。
AIは指示すれば真面目に試験してくれる。
しかし、前提を管理しないと、同じ問題を大量に報告することがある。
だから、試験そのものだけでなく、試験結果の整理ルールが必要になる。
7. 完了報告もかなり整ってきた
開発用PC側の完了報告も、かなり整ってきた。
今は、単に「作業しました」ではなく、以下のような項目を求めるようにしている。
作業ブランチ
commit hash
push先
変更ファイル
実装内容
実行した確認
省略した確認と理由
初期公開への進捗率
正式公開への進捗率
前回比
根拠
残り所要時間
リスク・未確認事項
確認用端末で再確認すべき範囲
指摘IDごとの対応状況
これは地味だが、かなり重要である。
AIの作業報告は、放っておくと都合よく省略されることがある。
だから、報告項目を固定する。
プロジェクトマネジメントでは、報告の型が重要である。
型があれば、比較できる。
抜け漏れに気づける。
次の判断ができる。
8. 新規ドキュメントを増やしすぎない判断も重要
以前は、何か新しい問題があるたびに、新規ドキュメントを追加しようとしていた。
しかし、最近は少し考え方を変えている。
新規ドキュメントを増やしすぎると、管理対象が増える。
どれが正本か分からなくなる。
AIも迷う。
人間も読むのが大変になる。
今回確認したところ、2台PC運用、制限事項、ブロッカー、Close条件、完了報告ルールなどは、既存ドキュメントにかなり反映されていた。
つまり、新しいドキュメントを追加するより、既存ルールの微修正で十分な状態になっている。
これは良い傾向である。
プロジェクト管理では、ドキュメントを作ること自体が目的ではない。
目的は、プロジェクトを進めること。
混乱を減らすこと。
判断を速くすること。
品質を上げること。
そのためには、ドキュメントも増やしすぎず、正本に集約することが大事である。
9. まだ軽微な整合課題はある
もちろん、まだ完全ではない。
細かい整合課題はある。
たとえば、ある参照ファイルが実際に存在するか確認が必要なケース。
また、以前の指標が一部残っていて、現在の方針と少し表現が揺れているケース。
こうしたものは大きな問題ではない。
しかし、AIに作業させる場合は、こういう小さな揺れが誤解の原因になる。
だから、今後は大規模な追加ではなく、既存ルールの微修正で整えていけばよい。
特に、主指標と補助指標の整理はしておきたい。
今は、初期公開への進捗率と正式公開への進捗率を主指標にしている。
以前使っていた確認版の進捗率は、必要に応じた補助指標に寄せた方がきれいである。
こうした細かい整合が、AI運用では効いてくる。
10. AI開発でもPMBOK的な考え方が効く
今回あらためて感じたのは、AI開発でもPMBOK的な考え方がかなり効くということだ。
たとえば、
スコープ管理
スケジュール管理
品質管理
リスク管理
課題管理
変更管理
コミュニケーション管理
ステークホルダー管理
進捗報告
完了条件の定義
これらは、人間のプロジェクトだけでなく、AIを使った個人開発にもそのまま必要である。
むしろ、AIは高速で作業するため、管理の甘さがすぐに大きなズレになる。
AIに任せるだけではだめである。
AIを管理する必要がある。
その意味で、プロジェクトマネジメントの考え方は、AI活用の土台になる。
11. 現状はかなり良い形に近づいている
今の開発プロセスは、まだ完璧ではない。
しかし、かなり良い形に近づいていると思う。
開発用PCと確認用端末の役割が分かれてきた。
Surface報告があればP0/P1を優先し、なければ開発用PCは止まらず自走する。
既知ブロッカーと制限事項を台帳化した。
FixedとConfirmedを分けた。
重複指摘や無駄な再試験を防ぐルールも入ってきた。
完了報告にも進捗率、根拠、残り時間、リスクを含めるようになってきた。
これは、独力＋AI活用としてはかなり実用的なプロセスになってきている。
単にAIにお願いしているだけではない。
AIを作業者として使い、PCを役割分担し、ドキュメントでルールを固定し、報告で検収する。
これは、かなりプロジェクトマネジメントそのものだと思う。
12. 今回の結論
AIを使った開発では、プロジェクトマネジメントの考え方が非常に重要である。
AIがあるから管理が不要になるのではない。
AIがあるからこそ、管理が必要になる。
役割分担。
制限事項管理。
ブロッカー管理。
残課題管理。
後回し機能の切り分け。
FixedとConfirmedの違い。
再試験範囲の限定。
完了報告の型。
進捗率と根拠。
残り所要時間。
リスクと未確認事項。
これらを整えることで、AI開発はかなり安定する。
現状、かなり反映できてきている。
新規ドキュメントを増やす段階ではなく、既存ルールを微修正しながら運用を固める段階に入っていると思う。
独力＋AI活用で月商1億円を目指すには、アイデアや実装力だけでは足りない。
AIをどう管理するか。
複数端末をどう役割分担するか。
不具合をどう閉じるか。
試験結果をどう次の実装につなげるか。
そこまで含めて、プロジェクトである。
AI時代でも、結局プロジェクトマネジメントは強い。
むしろ、AI時代だからこそ、プロジェクトマネジメントがさらに重要になってきている。
0 件のコメント:
コメントを投稿