エドテックのスタートアップで開発リードを務めるサンユンさんには、2四半期目に入っても解決しない悩みがあった。会社にAIが根づいて半年ほどたつと、カンバンボードの完了列のカードが目に見えて増えた。ところが、閉じたカードが過去最多だった四半期でも、追加した機能に見合うほどには、プロダクトは育たなかった。サンユンさんとこの会社は、私が経験したり聞いたりしたことを一か所に集めて作った人物と会社だ。
完了列を埋めたのは小さな機能だった。運営チームのある担当者は、以前はクラス別の課題提出状況を出してほしいというカードを開発チームに上げて、1週間待っていた。いまはデータを取り出すクエリをAIに任せ、クラス別の提出状況を表で見る小さな画面まで付けて、午後の半日で自分で作った。その担当者が閉じたカードは1四半期で30枚を超えた。営業チームは手作業で作っていたレポートをボタン1つで出すツールを作り、ほかのチームもそれぞれ不便に感じていた点を、同じように1つずつ解消していった。頼んだ人はすぐ使い、作った人は次のカードを取った。1つずつ見れば、どれもちゃんと動いていた。
ところが、重要なカードが1枚、そうしたツールに引っかかった。「学習レポート刷新」が先生の画面に載せる生徒数を決めようと、そのツールが使っている数字を集めてみると、どれも違っていた。同じ「生徒」をツールごとに違うやり方で数えていた。先生の画面にどの数字を載せるか決められないまま、そのカードは、小さなカードが閉じていく横で2四半期目に入っても同じ場所にあった。
#プロダクトにはずれを埋めてくれる人がいない
社内ではまだ持ちこたえられた。運営チームと営業チームのツールが少し食い違っても、使う人が目で合わせながら仕事をした。不便ではあったが、仕事は回った。
ユーザーの手に渡るプロダクトはそうではなかった。先生たちは会社の中の事情を知らず、どの画面で見ても同じプロダクトであることを期待していた。刷新が止まっているあいだに、開発チームが閉じた小さなカードが1枚、先生の画面にアクティブな生徒数を先に載せた。その数字は運営担当者のクラス画面から取ったものだったが、その日、ある先生が営業担当者から受け取ったレポートとなぜ違うのかと尋ねてきた。クラス画面はクラスに登録された生徒を数え、営業レポートは直近30日以内に課題を提出した生徒を数えていた。両チームともその数字を「アクティブな生徒」と呼んでいて、それぞれの仕事にとってはどちらも正しい数字だった。先生の画面にどちらを使うか、答えられる人がいなかった。
先生からの問い合わせ1件に答えるには、営業チームと運営チームがそれぞれの計算を出して突き合わせなければならなかった。1か所を合わせると別の場所がずれ、そのあいだ「学習レポート刷新」のような大きなカードは後ろへ押しやられ続けた。社員60人ほどの会社で、数字1つを合わせるのに2つのチームがかかりきりになった。2四半期前にはなかったことだった。
#1週間の待ち時間が偶然守っていたもの
当時は運営担当者が開発チームの返事を1週間ずつ待っていた時代で、生徒数を尋ねる依頼も開発チームという同じ窓口に入っていた。依頼を受けた数人は、前回のクエリを引っぱり出して手直しした。開発チームに新しく来た人も、クエリを書く前にそれを知っている同僚にまず聞いた。「生徒」をどう数えるかについて社内で合意したことはなかったが、同じ人たちが同じクエリを直して使っているあいだ、数字はおおむね1つのやり方で数えられていた。その1週間が守っていたのは、この偶然の一貫性だった。
ツールを作りはじめた人たちは、開発チームを通さずにAIからもっともらしい新しいクエリをすぐに受け取った。開発チームの中でも、同僚に聞くより先にAIに聞いた。依頼はもう同じ人たちを通らなくなり、その窓口が消えると、同じ数字に触れるカードが同時にそれぞれ「生徒」を数えはじめた。窓口が消えたまさにその四半期に、基準を決めるべきだった。そのときサンユンさんの目に見えていたのは、増えた完了カードだけだった。
#先に閉じた小さなカードが負債になる
「学習レポート刷新」は、最初は生徒を数える基準を1つ決めて画面を新しく作ればいい仕事だった。ところが基準を決めようとすると、数えている場所がすでにいくつもあり、どれか1つを共通基準に選ぶと、別の計算を使っていた画面やレポートも一緒に変えなければならなかった。「アクティブな生徒」をどう数えるかというその決定は、そうやって先送りされていた。そのあいだに営業チームは30日基準の数字で四半期目標を立て、運営チームはクラス画面を基準に学校に答えていた。どちらも最初は、それぞれの仕事を終わらせるために選んだ仮の基準だった。少しのあいだ使うつもりの間に合わせは、そうやって全員が寄りかかる基準になった。規模は小さくても、約束していない振る舞いにも誰かが寄りかかるというHyrum Wrightの法則が思い浮かぶ場面だ。
先生からの問い合わせがさらに数件入ったあと、サンユンさんは「学習レポート刷新」の見積もりを出し直した。2週間と見ていた仕事は2か月にふくらんでいた。そのあいだに生徒数を数える場所は7か所に増え、画面を1つ作ればよかった仕事が、その計算を探して合わせ、寄りかかっていた人たちに知らせる仕事になっていた。共通基準はまだ決めてもいないのに、各チームが先に選んだ基準はすでに変えにくくなっていた。エクストリームプログラミングを作ったケント・ベックは、コードが手をつけにくい状態になるまでに、以前は100人が10年働く必要があったと言った。AIを使えば1人でも1週間でそこまで行くと言った。この会社で手をつけにくくなったのはコードではなく、7か所に散らばった計算とその数字に合わせた業務で、そこまで行くのに2四半期で足りた。
小さなカードはまだ下されていない決定を推測で借りて使い、1枚閉じるたびに大きなカードに利子がついた。この負債は借りた人と返す人が違った。運営担当者はその日のうちに仕事が楽になり、営業チームは四半期目標を立てたが、費用は数か月後、大きなカードを手に取ったサンユンさんのところにまとめてやってきた。そのあいだに小さなツールが各チームの痛みを先に和らげ、大きなカードを押し通す理由も一緒に減っていった。痛み止めがよく効けば、病院には行かなくなる。
#数字ごとに持ち主を決めた
作業期間を2か月と見積もり直したサンユンさんは、まず代表のところへ行った。持っていったのは画面の設計案ではなく、1つの質問だった。「アクティブな生徒」が何人なのかを、会社で誰が決めるのかという質問だった。代表は開発チームではないのかと言い、サンユンさんは開発チームが決めたことはなく、前回のクエリを直して使っているうちにそう数えられていただけだと答えた。
そこで数字ごとに持ち主を決めた。先生の画面やほかのチームに出ていく数字12種類を書き出し、1つずつ誰が決めるかを代表がその場で割り当てた。「アクティブな生徒」と「完了」をはじめ、先生の画面に出ていく数字の大半は、その画面を担当するプランナー1人のところへ行った。サンユンさんはその場でその偏りを見たが、ほかに任せられる人がいなかった。持ち主が決めるまでは、その数字を外に出さないことにした。代表は全体会議でこの割り当てを伝えた。持ち主の仕事は基準を決めるところで終わり、クエリと画面は以前と同じように、頼んだ人がAIと作った。
プランナーは7か所を使うチームを1つずつ訪ね、その数字をどこに使っているのかを聞いた。直近30日以内に課題を提出した生徒は「アクティブな生徒」、クラスにいる生徒は「登録生徒」と決めるまでに3週間かかった。持ち主の返事を待たなければならなかったのは、その12種類を外に出すカードだけだった。持ち主を決めた四半期に運営担当者が閉じた30枚のうち、それに当たるのは4枚で、残りは以前と同じように半日で閉じた。各チームが7か所の計算をその2つの基準に合わせると、刷新がまた動きはじめた。それらの計算を共通のクエリ一式にまとめる仕事は、その次に回した。
チームの中だけで使うカードは、閉じる前に持ち主に1行残せばよかった。「営業チーム週次集計：ひとまず提出したら完了とみなす」のような行が、プランナーが受け持つ基準ごとに集まった。その行は、基準が変わるときに誰に知らせ、どのツールを一緒に直すかを書き留めておいたものだった。
次の四半期、プランナーは「完了」を先生が確認した課題と決めた。営業チームは週次集計が減ると反対し、プランナーは先生の画面に出ていく数字だから先生が確認したものだけを完了と数えるべきだと答えた。営業チームは反対を取り下げず、プランナーはそのまま決めた。基準が変わった日、プランナーは「完了」の下に集まった行を取り出した。行を残していた3枚は、そのチームが2日で新しい基準に合わせた。行を残していなかった1枚はそこになく、古い基準で数えていたそのカードを、2週間後にやっと運営チームが見つけ出した。
#持ち主が決めるまでは外に出さない
ケント・ベックは、機能と機能のあいだで立ち止まり、リファクタリングでコードを変える余地を取り戻せと言った。コードなら作った人が立ち止まればすむことだが、この会社では誰が立ち止まり、誰が決めるのかから決めなければならなかった。外に出すのを止めることで推測の負債を防ぎ、持ち主に残した1行で、あとから基準を変える余地を残した。カードを閉じる前に問う質問は4つにまとまった。
- このカードが閉じることで、顧客のどんな困りごとが減ったか。
- このカードは、まだ下されていない決定を推測で借りて使っていないか。
- このカードは少し使って捨てるものだったか、ほかのカードが寄りかかるものになったか。
- このカードが寄りかかる基準は誰が決め、全体は誰が見ているか。
持ち主を決めたことが答えだとは言いにくかった。チームの外に出ていく数字に限って、カードがどの基準に寄りかかっているかを見えるようにし、その基準を人が直接決めるようにしたことに近かった。12種類に含まれない数字が新たに出てくるたびに、その持ち主も決めなければならず、基準がプランナー1人に集まる問題は解けなかった。サンユンさんはもっといい方法をまだ探しているところだった。
ただ、数字が食い違ったときに聞ける場所はできた。機能を足してもプロダクトにはならず、カードがつながる流れを確かめて合わせるには別に時間がかかるということだけは、はっきりした。カードは誰でも閉じられる。だが、何のために閉じるのかは、誰かがつかんでいなければならない。
#参考資料
- DORA: User-centric focus: 機能をどれだけ作ったかよりユーザーにどんな価値が届いたかを見るべきだと述べ、AIは組織の強みと問題を同時に増幅すると説明している。
- Hyrum’s Law: Hyrum Wrightがまとめた法則で、ユーザーが十分に多ければ、約束にかかわらず観測可能なすべての振る舞いに誰かが依存するようになる。
- Kent Beck: Software Engineering in the Age of AI (Prodacity 2026): 手をつけにくいコードに至るまでに100人が10年かかっていたことがAIなら1人で1週間ですむと述べ、機能のあいだで立ち止まりリファクタリングでコードを変える余地を取り戻す仕事は仕様書にないので誰も求めない、と指摘している。