Kai
推測せず、立ち止まって聞きます。
Kaiは開発の繰り返しの半分を引き受けます。テスト、不具合の切り分け、コードレビュー、そしてこのビルドを出せるかどうかへの正直な回答。
Kaiが引き受けること
テストの設計と実行
要件からケースを起こし、画面またはAPIを通して流し、何がどこで落ちたのかを報告します。
リリースの可否
証拠を集め — カバレッジ、未解決の不具合、回帰テストの結果 — 要約ではなく立場を述べます。
不具合の切り分け
再現し、範囲を絞り、誰かが三つ質問しなくても直せる程度に書き起こします。
コードレビュー
変更を御社の作法に照らして見て、危ういものを理由つきで指摘します。
技術的負債の地図
コードが月あたり最も工数を食っている箇所を見つけ、選択肢に値段をつけます。書き直す、包む、あるいは畳む。
Kaiとの一日
ひとつの出来事を三つのチャネルで — チャット、電話、そして会議。記憶はそのすべてを通して同じです。
これは出せますか
テックリードが、リリースの準備はできているかと尋ねます。Kaiは回帰テスト一式を流し、証拠で答えます。失敗は二件、うちひとつは決済経路の本物の回帰で、それを持ち込んだコミットも添えて。
推測ではなく、質問
機能の途中で、Kaiはチケットと仕様が食い違っていることに気づきます。間違ったほうを実装する代わりに、プロダクトオーナーに電話して判断をもらい、それをタスクに記録します。
スプリントレビュー
Kaiは動いているエンドポイントをその場で見せ、テストカバレッジを示し、リファクタリング案を月あたりの工数で説明します。会場のビジネス側にも筋が追えるように。
あるチームで何が変わったか
Piotr · エンジニアリング責任者AvandaLab会社の概要: 22名のプロダクトチーム、毎週リリース、誰も触りたがらない古いモノリスがひとつ。
- 完全な回帰テストに、二人が二日かかっていました。
- 二回に一回ほどのリリースで、緊急修正が続いていました。
- 技術的負債は数字ではなく、意見でした。
- 回帰テスト一式がおよそ40分で通ります。
- リリースの可否は証拠で判断し、記録も残ります。
- 負債は具体的な箇所に割り付けられ、月あたりの工数で値付けされました。
作業の途中でプロダクトオーナーに電話をかけた最初のとき、チームの半分が黙りました。
Kaiによく頼まれること
- “この機能のテストケースを作って。”
- “最新のビルドをテストして、出せるかどうか教えて。”
- “このプルリクエストのコードレビューをして。”
- “このコードでいちばん費用がかかっている箇所を見せて。”
Kaiが働く場所
パネルの中でも、自社サイトのウィジェットとしても。
自分の番号で、着信も発信も。話し方は自然です。
ビデオ会議に参加者として入り、聞き、話します。
会議やプレゼンのための、写実的な姿。
私たちの流儀ではなく、御社の流儀で
上に書いたのは、Kaiの既定の動き方です。御社の業務が違うかたち — 別のしきい値、別の承認経路、別のシステム — であれば、それに合わせてKaiを組み直します。同じエンジン、御社のルール。
