🐈⬛
自社におけるCursorとの協働力の現在地の整理
概要
皆様、寒い中お疲れ様です！
みかん食べたくなりますね。
業務の種々をaiを活用することがスタンダートになったソフトウェア開発の現在、
生成aiとの協働力が鍵を握ると考えております。
なので202512初め時点での以下を記載させていただきました！
- 当社における協働力の現在地
- どのように協働力を上げていくか
経緯
- 「時間の価値を最大化する。」企業
- というのもあり生成aiツールの利用推進は全社的
- 実際に業務に組み込んでいる
その中で今回は、businessにして長らく経っている
cursorとの協働力にフォーカスしようと思いました。
前提
協働 とは:
同じ目的のために、対等の立場で協力して共に働くこと
「生成aiとの協働力」と表現したのは、
-
生成aiと対等の立場という関係性の中で、同じ目的のために協力して働く力
が重要と考えているためでございます。 -
生成aiを道具として扱うのではこれまでと変わらない
-
※ 考えるに至った記事
当社における協働力の現在地
意外といっぱいあった。
深ぼるのは別記事にしたい。
(諦めるの早い)
レベル感は以下を参考にする。
- ビジネス要求・目標設定等長期戦略編
- level3: 要求の叩きがgptsにて共通言語化された上で共有される。
- okr分解の目標設定案はgemini等にて壁打ち・レビューしてもらう
- ※(cursorと関係ないのでまたの機会に)
- システム要件定義編
- level4: 要件定義CursorRulesを用いて要件定義書を作成させたものをレビューする。
- 0次レビューとしてgithub actionsにて要件定義レビューCursorRulesによるaiレビューを実行する。
- 実装編
- level3: 要件定義の内容を元に実装はさせているが、要件定義の際よりCursorRulesの恩恵を受けてはいない。
- ※ただ後述するがここは任せ過ぎるのもとは考えている。
- 0次レビューとしてgithub actionsにて実装レビューCursorRulesによるaiレビューを実行する。
- 検証編
- level3: 生成aiとの壁打ちは日常的。
- 単体テストに関しては先生コードを記載したCursorRulesを元に記載させる方針。
- 結合テスト以降がまだまだ協働力を高めたいと感じるところ。
- 保守運用編
- level3: 簡単な修正prをCursor Background Agentに実行させる取り組みが進行中。
- ただ全社的な取り組みになっていない。
- 運用監視編
- level2: 運用監視ドキュメント等は生成aiを用いて作成を効率化。
- それらドキュメントに対してCursorと対話しているのが現在地。
- slackのエラーに対して自動起動して解決案を提示だったり、調査するまではまだ。
- 障害対応編
- level2: 障害対応中はわからんかった時のコード調査の際にCursorを利用する。
- 障害対応がAIだからこそ可能な状態になっているかと言われたら否。
- 再発防止編
- level2: ポストモーテムを中心とした再発防止議論の準備等が部分最適。
- タスク管理編
- level4: バイブコーディングを元に作成したslackショートカット+バイブコーディングを元に作成したタスク大量生産pythonコードを実行させるCursorRulesがタスク生産の肝となっている。
- 後は作られたタスクの調整と意思決定案をCursorにやらせることができればAIだからこそ可能な状態になっていると言える。
こうみたら、
最初に以下のように書いてあるのに、
現在地はまだまだだと自覚させていただきました。
生成aiツールの利用推進は全社的
なので次はどう協働力を上げていくのかを考える。
どのように協働力を上げていくか
目下、Cursorを活用しているかつ、level4に達成していない
実装・検証・保守運用・運用監視・障害対応・再発防止をlevel4に上げるアプローチを取りたい。
- 実装編
- level3→4へ: 目安1年
- 現状の生成aiのレベルではステップバイステップで人のレビューを挟んだ方が効率的と考えている。現状はこちら。
- 要件定義フェーズで作成したmdを元にaskモードもしくはplanモード
- 自分の記載したいコード方針と一致しているかをレビュー
- →方針が問題なければ実装をさせる(実装→レビュー→実装→...を繰り返す)
- →要件定義書の検証項目を満たすような単体テストコードが通るまで実施させる
- スケルトン・単体テストケースをコメントアウトでもう要件定義時に作成しとくとかがステップとして丸いかも。
- 1年としたのは半年は行かずとも、生成aiの精度がさらに上がりもはや自律的に実装させたほうがレビュー時間やコード品質も高い なんて時代が1年後には来ないとも言い切れないのでその時にはlevel4, 5になっているため。
- 検証編：目安3ヶ月
- level3→4: 単体テストは自然言語の要件の精度を上げる作業になると思う。
- レビューも不要とかではないと思う。とりあえず通るテストコードになっているかは確認する必要あり。
- 動作確認がローカルでできる環境をどれだけ作れるかもポイントだと思う。
- ガードレールとしてクラウド環境を触らせるのはできても開発環境くらいなため、精度はローカルでどれだけ検証できているかによるため。
- また、過去の検証項目をデータ化し、CursorRulesに検証項目自体を1から作成させるプロセスの構築が必要。(成果物(検証項目)をaiと作成するからスタートではなく、aiが作成した成果物をレビューからスタートに変えたい)
- なのでlevel4にするには、aiが効果を発揮するための検証環境・過去データをaiと協力しながら整備する作業。
- level3→4: 単体テストは自然言語の要件の精度を上げる作業になると思う。
- 保守運用編：目安3ヶ月
- level3→4: こちらは文化醸成→知見共有・エンハンスメント→組織全体への習慣化 がポイントと考えている。
- まず一部でやり始めている取り組みを全員でやってみる文化醸成
- 文化ができていくことによる知見の共有・アプローチのエンハンス
- この一連のプロセスが習慣化することで定型的だったり、修正範囲が狭い箇所は生成aiに実施させるのが習慣化すれば良いと考えている。
- ゴールとしてはローカル検証済みのaiレビューチェック済みのopen-prが出ている状態がゴールか
- 優先度：medium~lowに積んでいる保守運用タスク
- パッケージ管理等を自動通知・タスク作成する仕組みと連動させることによる更新タスク
- etc
- 運用監視編：目安3ヶ月
- level2→4: 当社はドキュメントはある状態なのでこれを生成aiによる調査が前提にシフトチェンジ
- あくまでローカルおよびgithubコードへ潜り込む想定
- ゴールラインはCursorRulesによって調査させたエラー対応予想がslackに流れてきたアラートを元にエビデンス付きで出力される状態
- 障害対応編：目安2~3年
- level2→4: かなりセンシティブな内容であるため、正直運用監視のような調査以外はあまり思い浮かばない。
- aiが旗振り役を実施して調査・影響範囲整理・文言作成等・解決案作成を実施して人は最終承認だけ。が理想だろうがかなりの精度がなければガードレールを緩和させる判断ができないため。
- aiタイムライン整理と旗振り補助とかはあってもいいかも(level3くらい？)
- 再発防止編：目安3ヶ月
- level2→4: まず、これまで実施してきたポストモーテム過去データをデータ化
- CursorRulesによって過去データも考慮した上でのポストモーテムをdraftで自動作成
- 人間はaiを一メンバーとして叩き台のもとに議論を進める
- ※もちろんこれまで主催いただいている方も相談に使っているだろうが、このアプローチを型化する
これから
- 整理してみるとまだ「協働力」が部分最適な箇所が多い。
- 協働力：生成aiと対等の立場という関係性の中で、同じ目的のために協力して働く力 と定義
- 前提を変えれていない箇所が多いと感じた。
- 現状であまりaiと協働できていないがアプローチ可能な開発プロセス工程から着手する
- 当社では検証・保守運用かと考えている
- プロセスごとの深堀は別記事にて。
参考資料
Discussion