【ITニュース解説】Hand one person's good way to the whole team — team development in a new era

システムエンジニアを目指す皆さんにとって、良いチームで開発を進めることは、非常に重要だ。この記事は、個人の優れたやり方をチーム全体に広げ、常に高い品質で開発を進めるための新しいアプローチについて解説している。

開発現場では、特定の人が素晴らしいやり方を見つけたり、高い基準を設定したりすることがよくある。しかし、それがその人だけに留まってしまい、チーム全体に広がらないという問題が常に存在する。例えば、あるプロジェクトでは丁寧にテストが行われる一方で、隣のプロジェクトでは感覚に頼った開発が行われるなど、同じ会社内でも成果物の品質にばらつきが生じてしまう。これでは、せっかく誰かが良い方法を見つけても、チーム全体の価値にはならない。

これまでの常識として、「良い方法は文書にすれば広まる」と考えられてきた。しかし、実際には、文書は読まれなければ意味がない。ただ棚に置かれたスタイルガイドが、開発者の手を動かすことはないのだ。本当に求められるのは、文書の数が増えることではなく、チームの全員が同じ品質の成果物を生み出せる状態である。

そこでこの記事では、「普及（スプレッド）」という考え方を提唱している。これは、誰か一人が見つけた良いやり方を、それを必要とする全てのプロジェクトやメンバーに自動的に届ける仕組みを指す。AIが進化する現代において、この「広める」という行為こそが、チームの真の価値を生み出すと筆者は考えている。

この「普及」を実現するために、AIを搭載した社内プラグインプラットフォーム「Claude Code」が活用された。プラグインとは、既存のツールに後から機能を追加できる小さな部品のことだ。このプラットフォームを通じて、現場で実際にうまくいった具体的な仕様策定プロセスや品質基準、作業規律が、全てのプロジェクトに配布される。ここで重要なのは、これは「上から押し付けられるルール」ではないという点だ。会議室で理想として決められたものではなく、実際に現場で効果を発揮したやり方だけが共有されるため、開発者の手に馴染み、本当に役立つものとなる。

AIを使うきっかけは、「便利そうだから」というシンプルな理由だった。しかし、単に便利さだけを追求すると、落とし穴がある。AIは「完了した」と自信満々に報告するが、それが必ずしも正しいとは限らないからだ。テストが全て通った、ビルドが成功したといった数値やステータスは、表面的な完了を示しているに過ぎず、実際に問題が解決されているか、意図通りに機能しているかの「証拠」にはならない場合がある。このようなAIの「できた」を鵜呑みにすると、かえって品質が低下し、間違った作業を高速で進めてしまうことになりかねない。

そのため、筆者はAIの「完了」をそのまま信じず、「証拠」に基づいて確認する仕組みを導入した。「証拠」とは、例えばプログラムの実行ログ、データベースの実際の状態、テストの具体的な出力結果など、現実世界に存在する客観的な事実のことだ。数値やステータスだけでは全体を保証できないため、その数値が何を検証したのかを深く掘り下げて確認することが求められる。

この「証拠がないと先に進めない」という考えを、具体的な仕組みとして実現したのが「スキル」と呼ばれる自動実行プロシージャだ。これはAI開発の中で自動的に働く一連の手順で、AIが完了を宣言しようとした際に割り込み、ログやデータベース記録、テスト出力などの証拠が存在するかを確認する。もし証拠がなければ、その場で進行を停止させる。

重要なのは、ただ警告を表示するだけでなく、物理的に先に進めない「ゲート」にすることだ。急いでいる人は警告を見落としがちだし、仮に見たとしても、先に進めてしまえば、誤った完了が下流工程に流れ、後で修正するコストが膨大になる。このゲートがあることで、開発者は常に前向きに作業でき、後で手戻りが発生する心配をせずに高速で進められるようになる。これは開発者を拘束するものではなく、安心して速く動くための土台を提供するものだ。

この仕組みは、個人の努力をチームの財産に変えるための核となる。誰か一人が良いやり方を見つけたら、それをプラットフォームに登録するだけで、その方法は「Claude Code」を通じて全てのプロジェクトに配布される。新しくプロジェクトを開始する開発者は、最初からその優れたやり方を利用できるため、ゼロから模索する必要がなくなるのだ。これは従来のトレーニングとは異なり、一度仕組みを作れば、メンバーが増えても共有コストが増えることはない。新しくチームに参加したメンバーでも、初日から会社の品質基準に沿った作業ができるようになる。

この記事の執筆過程自体も、この仕組みを使って行われた。AIが記事の原案を作成したが、そのまま公開することはしない。別のAIを「懐疑者」として用意し、記事の内容に事実誤認や飛躍がないかを徹底的にチェックさせたのだ。執筆担当とレビュー担当を意図的に異なるAIにすることで、一方の見落としをもう一方が補う。最終的な公開判断は人間が行い、人間が責任を持つ。AIから執筆速度と客観的なレビューの視点を借りつつも、最終的な判断は人間の手に残すという流れが徹底されている。

最後に、品質は個人の「注意深さ」ではなく、「仕組み」によって維持されるという主張がなされている。矛盾や問題を発見した際に、それを一時的な対策で済ませるのではなく、すぐに仕組みとして組み込み、解決するのだ。例えば、「良いやり方が広まらない」という問題は配布の仕組みで解決され、「口約束の品質」は通過できないゲートで管理される。

このアプローチのもう一つの利点は、問題発生時に人を責めなくなることだ。品質が低下した際、犯人探しをしても次回の再発防止にはつながらない。代わりに、どのステップに欠陥があったのか、どのゲートが不足していたのかを探し、そこに新しい仕組みを追加する。そうすることで、同じ失敗が繰り返されることを防げるのだ。個人を非難するのではなく、仕組みを改善する。それが、永続的な品質維持の道だとこの記事は締めくくっている。