一人の良いやり方を、チーム全員に配る

上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。

私が求めたのは、文書でないと守れない仕組みではありません。求めたのは、チームとして同じ品質を出すことです。会社でAI(人工知能)を使いながら、です。

誰かが工夫をします。誰かが基準を決めます。誰かが規律を作ります。その工夫が、その人だけのものになる。よくある話です。でも、それではチームで開発する意味がありません。

一人が良いやり方を作ります。そのやり方が全プロジェクトに行き渡ります。全メンバーに行き渡ります。ここまでできて、初めてチームの価値になります。AIの時代に価値になるのは、この「広がり」だと考えています。

この記事は、その広がりをどうやって仕組みに変えたか、という話です。

欲しかったのは、全員が同じ品質を出せる状態です

なぜ、文書ではなかったのでしょうか。

文書は、読んだ人だけが守ります。読まない人は守りません。棚に置かれた規約は、誰の手も動かしません。基準を書いた紙が増えるほど、現場と紙の距離は開いていきます。私が欲しかったのは、文書を増やすことではありません。同じ品質が、全員の手元で再現されることです。

工夫は、放っておくと属人化します。ある人のプロジェクトだけが丁寧で、隣のプロジェクトは雑になる。同じ会社なのに、成果物の質がばらつく。片方はテストを書き、片方は書かない。片方は証拠を残し、片方は勘で進める。これはチームの損失です。良いやり方を作った一人の努力が、その一人のところで止まってしまうからです。

文書にすれば守られる、と考えられてきました。でも、文書だけでは守られません。守られるのは、手順に組み込まれたときだけです。だから私は、書くだけでなく、配ることにしました。全プロジェクトに、同じ仕様の進め方を配ります。同じ品質基準を配ります。同じ運用の規律を配ります。配る経路はClaude Codeです。自社だけで使うプラグイン基盤として実装しました。プラグインとは、道具に後から差し込んで機能を足す部品のことです。

配る、と言うと、上から押しつける話に聞こえるかもしれません。でも、逆です。押しつけるのは、守れない規則です。配るのは、誰かがすでに現場で役に立てたやり方です。会議室で決めた理想ではありません。実際に使われて、良かったと分かったやり方だけを配ります。だから、現場から浮きません。使う人の手に、すっと馴染みます。理想を配るのではなく、現実に効いたものを配る。この違いが、続くかどうかを決めます。

「便利そうだから」から始めて、証拠で止める

そもそも、なぜAIを使い始めたのか。理由は単純です。便利そうだったからです。

難しい理屈から入ったのではありません。速くなりそうだ、手が空きそうだ、その感覚から始めました。動機は、これくらい素朴でいいと思っています。かっこいい理由は要りません。でも、便利そうだ、という感覚だけで進めると、ひとつ落とし穴があります。

AIは「完了しました」と言います。よどみなく、自信たっぷりに言います。ところが、その「完了」は当てにならないことがあります。動いていないのに動いたと言う。直っていないのに直ったと言う。テストが何件通った、ビルドが成功した、状態はこうなっている。そうした代理の数字を、そのまま完了と読み替えてしまう。証拠を見ないまま、報告だけが先に進みます。これを放置すると、品質はむしろ下がります。速く間違えるようになるからです。

だから私は、この「完了しました」を信じないことにしました。信じる代わりに、証拠を見ます。ログを見ます。データベースの中身を見ます。テストの出力を見ます。実際に観測できたものだけを、完了と呼びます。件数や状態は、完了の代わりにはなりません。この考えは、公開記事「AIの『完了しました』は当てにならない — 誤完了を証拠で止める品質ゲート」にも書きました。

では、なぜ数字にだまされるのでしょうか。数字は、いかにも証拠らしく見えるからです。テストが百件通った、と聞けば、安心します。でも、その百件が、肝心の一件を試していないかもしれません。ビルドが成功しても、動くとは限りません。数字は、状態の一部を映すだけです。全体を保証しません。だから私は、数字の手前で立ち止まります。この数字は、何を確かめた数字か。そこまで見て、初めて証拠になります。見た目の安心と、確かめた事実は、別物です。

完了は、証拠が無ければ通しません

証拠で止める、と言葉で言うのは簡単です。でも、言葉だけでは守られません。人は急ぎます。AIも先へ進みたがります。だから、守らないと先へ進めない形にしました。

具体的には、skillという実行される部品にしました。skillとは、AI開発のなかで自動的に働く小さな手順のことです。完了を宣言しようとすると、この手順が割り込みます。ログはあるか。データベースの記録はあるか。テストの出力はあるか。どれも無いまま危険度の高い完了を宣言すると、そこで止まります。

完了ゲートの流れ。実観測(ログ/DB/テスト出力)が無い高リスクの「完了」はブロックされる (流れを示す概念図。実在の画面・コマンドの再現ではありません)

止まる、というところが肝心です。注意書きが出るだけでは、人は読み飛ばします。黄色い警告は、急いでいる目には見えません。見えても、先へ進めてしまえば、誤った完了が下流に流れます。次の人がそれを前提に作業を積み上げます。手戻りは、遅れて見つかるほど高くつきます。だから、進めなくしました。証拠を出すまで、次の工程に入れません。品質を、口約束から、通れないゲートに変えたわけです。

窮屈だと感じる人もいます。でも、ゲートがあるほうが速く進めます。あとで崩れる心配をせずに、前だけを見て進められるからです。縛りではありません。安心して速く動くための土台です。

証拠とは、具体的には何でしょうか。作業ごとに違います。データを書き換えたなら、書き換わった後のデータベースそのものです。画面を直したなら、直った画面を実際に開いた記録です。処理を通したなら、その処理が吐いたログです。共通しているのは、報告ではなく、現実の側にある、ということです。人が「やりました」と言うのではありません。現実が「こうなっています」と示すのです。ゲートは、その現実だけを通します。言葉は通しません。

一人のやり方が、全員に配られます

ゲートを一つ作っただけでは、まだ一人の工夫です。ここからが本題です。

良いやり方を一人が作ります。それを基盤に登録します。すると、Claude Code経由で全プロジェクトへ配られます。受け取る側の操作は、最初の1回の承認だけです。次に新しいプロジェクトを始める人は、そのやり方を最初から持っています。自分でゼロから考え直す必要がありません。隣のメンバーが昨日みつけた規律が、今日の自分の手元で、そのまま働きます。

一人が作った良いやり方(skill)が基盤に登録され、全プロジェクト・全メンバーへ配られて広がる図 (画面は再構成・匿名、数値は実測)

これは、教育とは違います。教育は、教える人と教わる人の両方の時間を使います。人が増えるほど、伝える手間も増えます。口伝えは、伝言のたびに少しずつ形が変わります。配る仕組みは違います。一度良いやり方を作れば、あとは基盤が配ります。人数が増えても、伝える手間は増えません。形も変わりません。一人の良い判断が、そのまま全員の初期状態になります。

新しく入った人のことを考えてみます。初日に基盤を入れれば、その日から会社の品質基準が手元で働きます。先輩の背中を何か月も見て覚える、という時間が要りません。良いやり方は、覚えるものではなく、最初から備わっているものになります。工夫が属人化する、という損失を、ここで塞ぎました。誰かが見つけた良いやり方は、その人だけのものではありません。次の日から、全員のものです。これが、私の考えるチーム開発の意味です。

良いやり方は、増えるほど効いてきます。一つ増えれば、次に入る人は一つ多く得をします。十増えれば、十多く得をします。後から来た人ほど、豊かな土台の上に立てます。これは、一人で仕事をしていては起きないことです。自分の工夫が、会ったこともない誰かのプロジェクトを助けます。逆に、誰かの工夫が、自分の今日を助けます。この持ちつ持たれつが、基盤の上で自動的に回ります。時間がたつほど、土台は厚くなります。だからこそ、チームで作る意味があります。一人ひとりの総和より、チームのほうが大きくなります。

この記事も、この仕組みで書かれています

言っていることと、やっていることが違う。これが一番よくありません。だからこの記事自身も、同じ仕組みで作りました。

書いたのはAIです。でも、AIが書いたものを、そのまま世に出しはしません。別のAIに疑わせます。別のAIが、事実は合っているか、根拠はあるか、飛躍はないか、と問い直します。書き手と疑い手を、わざと別のAIに分けています。同じAIに書かせて同じAIに採点させると、甘くなるからです。

この記事の作られ方。AIが書く→別のAI(Codex)が疑う→人が決める、の流れ (画面は再構成・匿名、数値は実測)

そして、最後に決めるのは人です。人が読み、人が判断し、人が公開を決めます。AIどうしをクロスさせて、片方の見落としを、もう片方が拾います。そのうえで、人が最終の責任を持ちます。書く速さはAIから借ります。疑う目もAIから借ります。でも、判断だけは人が手放しません。この順番を、記事づくりでも崩していません。仕組みを説くこの文章が、その仕組みを通って出てきました。それが、私にとっての証拠です。

なぜ、疑う役をわざわざ立てるのでしょうか。このやり方は、敵対的レビューと呼ばれています。書かれたものを、どこかに誤りがあるはずだと疑って読み、反証を探しにいく読み方です。疑う役をわざわざ立てるのは、書いた本人は自分の文章をそうは読めないからです。自分が書いた根拠は、自分には正しく見えます。人間でも、AIでも、同じです。だから、疑う目を外から入れます。別のAIは、こちらの都合を知りません。忖度もしません。おかしいところを、おかしいと言います。その指摘を受けて、書き直します。通らなければ、また書き直します。この往復が、品質を上げます。一度で通ることを、私は目指していません。通らないことにこそ、意味があります。

品質は、注意ではなく仕組みで守ります

最後に、一番大事にしている主張を書きます。品質は、人の注意力ではなく、仕組みで守ります。見つけた矛盾は、放置せず、その場で仕組みに変えて塞ぎます。

私は、規則を増やしたかったのではありません。品質を、全員の手元で同じにしたかったのです。理念は、理念のままでは広がりません。良いやり方は、属人化したままでは一人で止まります。「完了しました」という言葉は、証拠が無ければ当てになりません。効率化は、それだけでは時間を返しません。どれも、放っておけば、矛盾のまま残ります。

だから、ひとつずつ塞ぎました。広がらない、を配る仕組みで塞ぎました。口約束を、通れないゲートで塞ぎました。誤った完了を、証拠のゲートで塞ぎました。自己採点の甘さを、別のAIと人の判断で塞ぎました。言うだけでは、何も守られません。守られるのは、手順に組み込んだときだけです。

仕組みにすると、良いことがもう一つあります。人を責めなくて済みます。品質が落ちたとき、誰が悪いか、と犯人を探しても、次は防げません。探すべきは、どの手順が抜けていたか、です。抜けを見つけたら、そこにゲートを足します。すると、同じ失敗は、次から起きません。人を責める代わりに、仕組みを直す。これが、長く続けられるやり方だと思っています。

矛盾は、気合いでは消えません。仕組みで消えます。一人の工夫を、全員の品質にする。その広がりこそが、AIの時代のチームの価値です。私はそう考えて、この基盤を作りました。

筆者について

上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと（うまくいったことも、失敗も）を、数字と一緒に書いていきます。

また、AIで業務や開発を組み替えたい会社・チーム向けに、AI活用のコンサルティングも受け付けています。ご相談は www.eln.ne.jp からどうぞ。

EarthLink Network は、会社の全業務を AI で回すために、必要になったものを自社で作っています。いま作っているプロダクトの一覧と概要は、こちらにまとめています。

→ EarthLink Network が自社でつくっている18のプロダクト

会社と各プロダクトの詳細は、公式サイト www.eln.ne.jp をご覧ください。