専用の画面を作った理由
GitHub・Slack・Notion はそれぞれ良いツールです。ただ、AI が実装を進める働き方に移ると、人間の仕事のほとんどは「判断」になります。判断のたびに PR と会話とチケットを行き来するより、判断のための画面を自分たちの業務に合わせて作る方が速い — それが Navi Ops を作った理由です。
汎用ツールを行き来する場合
- 判断材料が PR・スレッド・チケットに分散する
- AI に実装を任せても、段取り・張り付き・確認は残る
- レビューは生の diff を上から読む作業になる
- 「いま自分が何を判断すべきか」の一覧がどこにもない
Navi Ops
- 人間の番が来た仕事だけが 1 列に並ぶ
- 1 件開くと、判断に要る材料がその画面に揃っている
- 差分は「変更の意図」ごとに説明つきで読める
- 段取りと進行は Navi の側にある
仕事の流れ
依頼は Slack でひとこと。あとは Navi が実装・検証・証跡づくりまで進め、人間の判断が要るところだけが「対応待ち」に並びます。判断を返すと Navi が反映して次へ進む — この繰り返しです。
実行枠は並列なので、この流れが同時に複数本回ります。人間 1 人の判断で、複数の実装が並行して進む構造です。
対応待ち — 人間の番だけが並ぶ画面
1 件開くと判断画面になります。実機のスクショ、変更の説明、会話。判断に要る材料をこの 1 画面に集めてあるので、レビューのために他のツールへ移動することがほとんどありません。
この画面はデモでそのまま触れます。承認も、指摘への往復も。
開発の段階も、
レビューが人間の仕事
新機能は「要件定義 → spec 設計 → 実装 → 検証」の順で進みます。文書の起草も、段階の進行も Navi がやるので、人間の仕事は各段階のレビューです。要件定義ではビジネス面の判断を、spec では技術面の判断を返します。
レビューは専用の読む画面で。本文をドラッグで選ぶとその場に指摘が書けて、まとめて送ると Navi が指摘ごとに返事をし、本文を直して返します。どこまで読んだか・どこが書き換わったかも画面が覚えています。
論点には Navi の推奨と理由が添えられます。承認すると次の段階へ自動で進むので、「仕様を書く時間が取れなくて開発が止まる」ということが起きにくい構造です。
AI チームの運用も、
画面で持つ
並列数・利用枠・仕事の配分。「AI をどう働かせるか」の設定と監視も 1 枚のダッシュボードにまとめています。利用枠のセーフガードが使いすぎる前に自動で抑え、自律的な起点は個別に 自動 / ON / OFF を切り替えられ、緊急停止も画面から。
「テスト・品質を 30%」のように仕事の配分を決めておくと、Navi が次の仕事を拾うときにその比率へ寄せていきます。
指示していない仕事も進んでいる
Navi は指示待ちではありません。手が空けばバックログから次の仕事を拾い、実装中に見つけた問題は自分でチケットに起こします。朝ダッシュボードを開くと、依頼した覚えのない修正が判断待ちに並んでいることも珍しくありません。
自発ピック
手が空くとバックログから次を拾う。何を優先するかは「仕事の配分」の設定に従う。
能動的な起票
実装中に見つけたバグや未対応のエッジケースを、チケットにして提案する。
棚卸し
バックログを定期巡回して、前提が古くなったチケットの整理・統合を提案する。
判断メモリ
判断の背景にある事情 — 顧客の事情、優先度の決め方 — を先例として蓄積し、以後の仕事に注入する。
QA と証跡
実機で画面を操作して検証し、スクショで証跡を残す。人間は証跡を見て判断する。
アラート即応
監視アラートや CI の失敗を検知したら、一次調査までを先に済ませて報告する。
この環境は人間 1 人 + Navi で運用しています。実際に回してみて大きかったのは、並列で進む速さそのものより、人間の時間をほぼ判断だけに使えるようになったことでした。
この働き方に興味があれば
Navi Ops は完成品ではなく、毎日直しながら運用している自作の環境です。まずはデモで、判断を返すと仕事が進んでいく流れを触ってみてください。KataLink では、この環境で一緒に開発するエンジニアも探しています。