こんにちは、ログラスの飯田(@ysk_118)です。
ここ数年、AIによってコードを書く速度はずいぶん上がりました。一方で、「品質向上に対してどのようにアプローチしていくのか」という問いも、多くの現場で同時に立ち上がっているように思います。
AIによる開発現場の進化の渦中において、エンジニアリングマネージャーはどう変化すべきなのか？品質にとどまらずさまざまな観点でアップデートが求められていると感じていますが、まずは直近で取り組んだ品質KPIの可視化についてお話しします。
ソフトウェアの品質は、外部品質・内部品質・プロセス品質・利用時の品質などに整理できます。本記事が扱うのはこのうち外部品質、なかでもインシデントに関する品質です。「AIが書いたコードの品質をどう担保するか」という内部品質ではなく、その手前にある「インシデントに関する外部品質をどう見えるようにするか」という出発点の話をします。内部品質については、今後の記事で触れられればと思っています。
AIは品質の課題を生む側面があると同時に、マネージャーが品質と向き合う「やり方」そのものを変えてくれる側面もある、ということをお伝えできればと思います。
「見えているのに、手を出せない」という状態
マネージャーがメンバーとKPIに関する会話をするとき、こんなやり取りになりがちです。「この数字は何を表していますか」「内訳はどうなっていますか」「これだけだと判断できないので、この観点も足してもらえますか」「比較できる指標も欲しいです」。一つひとつは自然な問いかけですが、これを重ねていくと、それだけでメンバーの時間をかなり奪ってしまいます。
これは、立っている場所（視座）が違うと、どの粒度の情報で話すかを合わせるのが難しい、という問題だと考えています。経営と経営企画や事業部のあいだであれば、その擦り合わせ自体が仕事の一部かもしれません。ですが、開発組織のマネージャーとエンジニアの関係では、少し事情が違います。エンジニアには、KPI集計の微調整よりも、実際の開発推進に一層集中してほしいと考えています。
品質を測る指標として定めたKPI（以降、品質KPIと記載）そのものも、正直に言えば、上手く扱えているとは言えない状態でした。複数の場所に散らばった基準、NotionDBやスプレッドシートでの手集計。手を入れるコストが高く、課題が見えていてもKPIマネジメントのPDCAを回すことが難しいと感じていました。結果として、マネージャーである自分は、抽象的な議論にとどまりがちでした。
まず「何を測るか」を引き直す
取り組みの最初にやったのは、指標を増やすことではなく、「何を問うのか」を整理し直すことでした。
プロダクトの品質を取り巻くステークホルダーは多様です。もちろん最終的にはお客様が利用する際の品質が重要ですが、社内でもセールスやカスタマーサクセスなどお客様のフロントに立つ部門や、経営からも重要イシューとして認識されています。プロダクト組織のマネージャーはこうしたステークホルダーの間に立ち、品質に対して「良いのか悪いのか？」「課題があるならばどう解決していくのか？」といった説明責任を果たす立場にあります。
品質についてステークホルダーが気にするのは、「速く直せているか」だけではありません。「予防できているか」さらに言えば「過去発生した問題を繰り返していないか」も、同じくらい大切です。まずは、この直近の関心を二つの問いに分けて捉え直し、KPIに落とし込みました。
そのうえで、測り方そのものを見直しました。指標は増やすほど議論が発散しますが、まず状況として自分たちがフォーカスしたいものを絞り、経過を見ていく中で計測の課題も見えてきました。指標の測り方のアップデートの例としては、代表値を平均値から中央値に変えるということをしました。障害には、ごく稀に対応が長引くケースが混じります。平均値だと、そうした少数の大きな値に全体が引っ張られ、「実際のところ、たいていはどれくらいか」が見えにくくなってしまいます。中央値で読むようにしたことで、日々の実態に近い数字を見られるようになりました。
何を測るかを決めるのは、裏を返せば「何に関心を持つべきか」を決めることでもあります。ここは、マネージャーが引き受けるべき部分だと考えています。そして、こうして絞り込んだ問いを、次は実際に動く形にしていきます。
「見たいもの」を、動く形にしてみる
ログラスでは不具合や障害が発生した際に、インシデントコマンダー（障害対応の統括役）が中心となり、Slackでの対応チャンネル、Notionでの障害起票、これらの体制構築や対応の推進基盤としてWaroomを利用しながら進めるという形式をとっています。
上記で紹介した品質KPIの一次データには、NotionDBを使用しています。
従来はNotionDBの内容をNotionのダッシュボードの機能を使い、集計をしていました。
しかし、経営目線でのKPIマネジメントを推進しようとすると、スプレッドシートでの分析の表現を高頻度でブラッシュアップする必要があったり、分析したい軸も議論のたびにアップデートされていきます。
NotionDBはこういった分析用途の集計に特化したものではないため、データをCSVでエクスポートして手元で加工する必要がありました。
ただ、その方法は自分の手元でしか回らず、属人的で、他の人に引き継ぐのが難しいという弱点がありました。
今回はAIを使うことで、再現可能な集計の仕組みを、自分の手で組むことができました。仕組みは、おおまかに三つの段階でできています。
- 記録の欠けを補う段階（FILL）。NotionDBは手動更新のため、インシデントの日時や発生経路といったプロパティの欠損について、元データ（WaroomやSlack）から必要なメタデータのみを安全に補正します（※個人情報・顧客機密情報はマスク・除外した上で処理）。
- 記録の品質を検査する段階（CHECK）。必須項目の抜けや、後から分析に使えるだけの情報が書かれているか、データソース間で食い違いがないかを、機械的にチェックします。
- 集計する段階（AGGREGATE）。整ったデータをローカルのDuckDBに取り込み、KPIを中央値ベースで集計します。
上記はClaude Codeのskillにして運用していますが、KPIの定義はSQLに固定してあるので、同じデータからは、誰が回しても同じ数字が出ます。AIの確率的な挙動に対して、データソースの一元化・精緻化と、集計ロジックの固定によって再現性を持たせる形にしています。
運用としては、補完・検査・集計を週次で回して暫定的に状況を共有し、アクションを実行しながら月次で数字を確定させレポーティングを行う、というサイクルにしています。
大事なのは、これは「マネージャーが実装をやってみた」という話ではない、という点です。細かい指示を重ねてメンバーと視座を合わせにいく代わりに、自分の関心を動く形にして手渡す。そうすることで、擦り合わせのコストを減らし本質的な議論に集中できるようにする、ということがポイントだと考えています。
自分で触ったからこそ、見えたこと
正直なところ、自分でKPIマネジメントに踏み込んで実感を持てた点もいくつかありました。
一つは、直近のインシデントが「速く直せるようになったが、まだ根本対処には改善余地がある」ということです。可視化を推進した結果改善意識が高まり、AIによる仕組み化などが進み復旧スピードは改善した一方で、再発の防止には課題が残っている。この非対称は、数字を作る側に回ってみて、改めて輪郭がはっきりしました。私はインシデントコマンダーの当事者としても「どうすれば早く解消できるか」を考えて取り組んできましたが、再発防止や水平展開の踏み込みの重要性が数字で誰でも理解できる状態になったことが前進です。現在はインシデントコマンダーとQAでより重要なアクションを確実に実行するためのプロセスのアップデートを進めています。
もう一つは、ある検知系の指標の改善については、それが対応力の向上だけでなく、データの整備によって集計の精度が向上した、という側面もあります。母集団の線引きや、KPIの定義自体を精緻化する、そしてそのKPIの意図通りにNotionDB側のプロパティが正しく設定されているかまで確認できなければ正しい分析と正しいアクションになりません。
手を動かすことの意味は、実装そのものにあるのではなく、意思決定の精度を上げるところにあるのだと思います。
現場に手渡す、そして現場が良くしていく
この仕組みは、もともと自分の作業リポジトリで、属人的に動かしていたものでした。それをチームのリポジトリに移し、定義をコードに固定し、機微なデータを分離することで、他の人が引き継いでも同じ結果を再現できる状態に整えていきました。
そして実際に、この仕組みはQAのメンバーに引き継ぎました。今では、私が運用していた頃よりも、継続的に改善を進めてくれています。これは、とてもありがたいことだと感じています。
ここで一つ補足すると、これはチーム全体でAI活用を推進する土壌があるからこそ成り立っている話でもあります。マネージャーがプロトタイプを提示し、現場がそれを運用・改善していくサイクルを回せるのは、組織的な前提があってこそだと感じています。
渡したのは、完成品の仕様書ではありません。あくまで、目線を合わせるための土台です。引き継いだあとも、「ある指標が良くなったら、次はどこを見るか」「次に測りたい指標は、もう取れる状態にあるのか」「取れないなら、業務をどう変えれば取れるようになるのか」といった対話は続いていきます。この対話こそが、本当に価値のある部分だと思っています。
だからマネージャーの役割は、完成品を作って渡し切ることでも、細かく指示し続けることでもなく、経営の関心を形にしたうえで、改善には現場を巻き込んでいくことなのだと考えるようになりました。トップダウンの問いと、ボトムアップの改善を、つないでいく。それが、自分なりに見えてきた一つのあり方です。
AI時代のエンジニアリングマネージャーとして
今回の取り組みを通して、人とAIの役割分担が、少し整理できたように思います。
AIに任せられるのは、集計や、報告のたたき台づくりや、データの整形といった部分です。一方で、何を問いとして立てるか、数字が示す構造をどう解釈するか、どこまでを対象とするかといった判断は、人が引き受けるところだと感じています。今回の仕組みでも、数字や差分やドラフトを用意するのはAIの役割で、目標の確定や打ち手、ステータスの確定といった判断は人が行う、という形にしています。
こうして振り返ると、AIがあることで、マネージャーは抽象的な意思決定と、具体的な手触りのあいだを、以前より行き来しやすくなったのだと思います。これまでは時間の制約から具体に降りづらかったところに、降りていって、また抽象に戻ってくる。この往復ができるようになったことが、「経営の関心を形にして、現場を巻き込む」という経営と現場をつなぐという役割を、以前より現実的なものにしてくれました。
もし今、「関心はあるけれど、まだ手をつけられていない」という状態にいるとしたら、最初の一歩は、自分が見たいものを一つだけ、動く形にしてみることかもしれません。
次回に向けて
今回は、品質のなかでも「可視化」という出発点の話に絞りました。生産性が上がった先で品質がどう問われ、積み重なった無理がどう技術負債になっていくのか。そのあたりは、今後の記事で続けて書いていければと思います。
最後までお読みいただき、ありがとうございました。
Discussion