HOW WE RELEASE

書く速さは変わった。リリースゲートは、変えていない。

AIエージェントが書く量が増えても、変更が本番に届くまでの順路は同じです。ブランチを切り、人がレビューし、自動テストを通り、検証環境で確かめ、最後に人が切り替える。エージェントが何体増えても、この順路は短くなりません。短くできないようにしてあります。

品質の担保について相談する 順路を見る

THE ROUTE

変更が本番に届くまで

どの持ち場の変更も、例外なく同じ順路を通ります。急いでいても、順番は飛ばせません。

  1. 01
    ブランチを切る

    ひとつの目的に、ひとつのブランチ。長い仕事ほど、他の作業と混ぜません。

  2. 02
    小さく出す

    人がレビューしきれる大きさに切って出します。大きな一回より、小さな変更を何度も。

  3. 03
    人がレビューして、マージする

    読んだ人がいない変更は入りません。設計と規約に合っているかを見るのはここです。

  4. 04
    自動テストがゲートになる

    リリース時にテストが走り、通らなければリリースされません。これはCIの仕組みで、AIの判断ではありません。

  5. 05
    検証環境で確かめる

    本番と同じ形で動かし、実際に触って確かめます。画面で見て初めてわかることが残っているからです。

  6. 06
    人が本番に切り替える

    確かめたうえで、人が切り替えます。最後のボタンは人が押します。

WHY

なぜ、ゲートを減らさないのか

つくる速さが上がると、確かめる側が追いつかなくなります。だからゲートは減らさず、人が見る場所のほうを絞っています。

書く速さと、出す速さは別

エージェントが増えても、ゲートの数は変えません。速くなったのは、ゲートの手前だけです。

繰り返しは、機械の仕事

同じ確認を何度も繰り返すのはテストに任せます。人のレビューは「動くか」ではなく「正しいか」に使います。

小さく出せば、小さく戻せる

変更が小さいほど、問題が起きたときに戻す範囲も小さくなります。

出したあとに、測る

リリースした内容とKPIの動きを毎週突き合わせます。効かなかったものは残しません。

WHERE WORK COMES FROM

直すものは、どこから来るか

思いつきで決めないために、入り口を決めています。ここに集まったものから、次にやることを選びます。

この順路を動かしているチームを見る
  • 利用者からの機能リクエスト

    使っている人が、欲しいと言ったもの。

  • KPIの動き

    管理画面チームが毎週見ている数字。動かなかったものも含めて。

  • ログ分析で見つかった不具合

    毎週エラーを洗い出し、増えた異常を問い合わせより先に見つけます。

  • CSに届いた声

    問い合わせの裏にある、直すべきもの。

WHAT IS NOT HERE

ここに書いていないこと

環境の構成、デプロイの方式、テストの具体的な中身は公開していません。守るべきものだからです。仕組みの形はこのページに書いたとおりで、それ以上の詳細が必要な場合は、お取引の中でお伝えします。

案件の進め方（8つの工程）を見る

LET'S TALK

この進め方のまま、御社の開発もお受けしています。

つくる前に品質の担保を知っておきたい、という相談は歓迎です。今の開発体制に合わせて、どこから関われるかを一緒に考えます。

相談する