「コードの9割をAIが書く」playgroundの仕様駆動開発 〜“AIが働きやすい職場”のつくり方〜

AI駆動開発への関心が高まっている昨今、「AIツールを導入して生産性が向上しました」といった技術発信を目にすることが増えました。しかし、AI駆動開発を組織としての継続性ある成果につなげている事例はまだ多くないのが現実です。一体何をすれば成果と呼べるのか。どのような状態を目指せばよいのか。そこを知りたいエンジニアは多いのではないでしょうか。

この問いに対して、playground株式会社は明確な答えを持っています。スポーツ・エンタメ業界のDXを推進するスタートアップである同社は、全社的なAI駆動開発への切り替えによって「コードの9割をAIが生成」「Figmaからコードへの変換精度90%」「AIでテストカバレッジ95%」を達成しています。

代表の伊藤 圭史さんは2年前、同社を「AIネイティブな会社にゼロから作り直す」と宣言。社内ドキュメントから開発プロセスまで全社を挙げて再整備・再構築を進めたことで、これらの成果を実現してきたといいます。

AI駆動開発で成果を出すには何が必要か。その答えを、代表の伊藤さんと同社エンジニアの舟口さん、塚原さんに聞きました。

AI駆動開発の成果を分けるのはツールではなく「職場環境」

――まず、playgroundの事業について教えてください

伊藤：playgroundは、「夢を与える仕事を、夢の職業にする」をミッションに掲げ、スポーツ・エンタメ業界のDXに取り組んでいる会社です。

主力サービスは、プレイガイドで販売されたチケットを電子的に発券する電子チケット発券サービス「MOALA Ticket」です。チケットぴあをはじめ、ほぼ全プレイガイドで採用されているのでイベントファンのなかでは定番としてご認識いただけているかな、と思っています。

――順調に事業を伸ばしてきたplaygroundですが、2年前に「AI ネイティブな会社にゼロから作り直す」と宣言されたそうですね。その背景を教えてください

伊藤：ChatGPTが登場したとき、AIを前提にゼロベースで会社をつくり直す必要があると思いました。いま、“DXを推進している”大企業と“デジタル前提でつくった”スタートアップでは業務の進め方や生産性がまるで違うように、AIは「取り組む」「導入する」というレベルの向き合い方ではダメだと。

――具体的には何から取り組んだのですか

伊藤：全社的に行った最初の取り組みは、ドキュメントをAIが読みやすい形に整えることでした。社内の環境、知識、プロセスをAIが活用しやすい形に再構築する。その第一歩がドキュメントの整備だったんです。

当時出ていたAIツールはまだ実験的なものが多く、導入しても明日にはまるで別のものに変わってしまうような状況でした。すぐに陳腐化するものに注力しても意味がないし、優秀なツールが出てきたら導入すればいいだけです。一方で、いくら優れたツールを導入しても、社内知識だけは外部から調達できません。社内知識の整備度合いがAIが活躍できる会社か否かの一番の違いになると考えました。

――まず環境を整えることが重要だと考えたのですね

伊藤：はい。AIの性能はすでにビジネスで利用するには充分すぎる水準に達していると実感しています。そう思えていないとしたら足りないのは「AIが活躍できる職場環境」です。

環境が整っていれば、現在のAIでも十分にスーパーエース級の優秀な働き手として機能します。だから私たちは「AIが働きやすい職場をつくる」というテーマで、社内知識の整備とAIへの指示精度の向上に集中してきました。

――「AIが活躍できる職場環境」とは具体的にはどのようなものですか

伊藤：ドキュメントは「読み手ファースト」から「AIファースト」へ。人が読みやすい資料ではなく、AIが読みやすいことが最優先です。よくある「クライアントが読みやすいようにデザインを整えよう」といった配慮はすべて捨てました。

もちろん議事録はすべて社内知識をInputしたAIにお願いしています。さらにレベルを上げて立ち話も録音し、社内のコミュニケーションはすべてAIが把握している状態を目指しています。

スライド作成ツールの使用も原則禁止とし、すべてMarkdownで記述しています。プレゼン資料は、Markdownで書いた内容をMarpで変換して作成。Marpで表現できないデザインは諦める方針としました。

加えて、社内ドキュメント管理ツールはAIには読みづらいことがわかったので、GitHubに移行しました。開発ドキュメントは体系立てて整理し、すべてGitHubに格納しています。

――伊藤さんのAI ネイティブ宣言を聞いたとき、社内の反応はいかがでしたか

舟口：衝撃を受けましたね。伊藤さんは個人としてもすごくスキルの高い人です。その伊藤さんが、「今まで自分がこだわってきたやり方や品質を全部捨てます」と宣言した。AIネイティブな会社では必要のないスキルだからと。それを聞いて、全力でついていくしかないと思いました。同じ衝撃を受けたメンバーは社内に何人もいたと思います。

塚原：伊藤さんの作業スピードの速さとドキュメント品質の高さは尋常じゃないですから。芸術の域に達していますね。その伊藤さんがそれを捨てると言うのだから、納得しかありませんでした。

「仕様書が完璧じゃないと次に進まない」AIに任せるための覚悟

―― コードの9割をAIが生成しているとのことですが、具体的にはどのような開発フローなのでしょうか

舟口：コードの9割をAIが書いていると言うと驚かれることがあるんですが、AIに自由に全部書かせているわけではありません。

まず前提として、私たちの開発は「仕様駆動」で進めています。機能要件だけでなく、詳細設計まで仕様書に落とし込み、その段階で議論を尽くします。だから、仕様書が間違っていることはほぼない状態から開発がスタートするんです。

その仕様書をAIに渡して、社内で定めた規約に沿ってコードを生成させています。さらにその規約をAIに読ませてレビューまで行わせる。私たちはコード自体には手を入れません。唯一手を入れるのは、レビューの段階で実際どうなっているかを確認するところだけです。

――規約というのは、どのようなものを指すのでしょうか

舟口：DDD（ドメイン駆動設計）の原則に沿った設計思想、コーディング規約、レビュー規約などですね。弊社のエンジニアの設計思想や、昔からあるエンジニアリングの原則をふんだんに盛り込んでいます。

GitHub上でAIによるレビューが自動的に行われて、もし規約の方針と違っていたら、私たちは規約のほうに手を加えます。先ほども言ったようにコードには手を入れません。これをひたすら繰り返すことで、AIが再帰的にレビューと修正を繰り返していく状態を実現しています。

――従来の開発と比べて、仕様駆動開発の最大の違いは何でしょうか

伊藤：「正しいもの」を明確に定義することが仕様駆動の要諦だと思っています。

従来の開発では、「正しいもの」が何なのか決まっていない状態で、ハイコンテクスト、つまりお互いの暗黙の理解や想像力を頼りに進めることが多かった。その結果、「伝わっていたと思っていたことが実は伝わっていなかった」というズレが生じて、それが全部バグや手戻りにつながっていたんです。

これまでの仕様書は「概ね正しい」という存在でした。でも仕様駆動では、「完全に正しい」存在でなければ次に進まない。この基準に変えたことで、社内のコミュニケーションの質も、AIの活躍度合いも、まったく違うレベルになりました。

―― 仕様書について、かなり厳格な運用をしているのですね

伊藤：仕様書がパーフェクトじゃないと次に進まないという覚悟を、とても大事にしています。

AIはハイコンテクストが通用しないため、曖昧な指示では思うような成果物を出してくれません。そもそも、人間への指示においても仕様書が正しくなくてもOKとされていたこと自体が、本来おかしかったのではないかとすら思っています。

この前提に立つと、仕様書を書くという仕事の価値が格段に上がります。5年後、10年後にプロダクトがどう発展していくかを考え抜いた上で、どういう仕様にするべきかを書ききる。それがPdMの仕事ですし、チームとしても仕様書を徹底的に議論して、本当に正しい存在に仕上げることを重視しています。

舟口：仕様書をしっかり書くようになったことで、エンジニアが上流工程に関わる機会が格段に増えました。 従来のアジャイルな進め方ではなく、ウォーターフォールに近いレベルで仕様を詰めていく。エンジニアとPdM、ビジネス側のメンバーが一緒になって、仕様について徹底的に議論するようになりましたね。

――実際に手戻りが減った実感はありますか

舟口：はい。直近入社してくれた人も「全然手戻りないですね」と驚いてくれましたが、びっくりするぐらい減っています。

仕様書を書く中で、プロダクトをつくるPdMが具体的な情景を想像するところまで詰めなきゃいけなくなりました。そこまで詰めるからこそ、手戻りが起きないんですね。

――仕様書が詳細になると一度に大きな単位で開発を進められそうですが、プルリクエスト（以下、プルリク）の粒度はどうなりましたか

舟口：仕様書がしっかり書いてあるなら、プルリクの粒度は大きくてもいいのではないか。そう思われるかもしれませんが、私はそうではないと思っています。

社内ではプルリクは20ファイルを超えないレベルまで小さくしています。理由は2つあって、1つはプルリクが大きいと人間のレビューが遅くなるから。もう1つは、弊社の事業ではたった一行のミスが命取りになりうるからです。 最終承認者の目をすり抜けないようにするためにも、小さめに小さめに、というのはすごく意識しています。

また、仕様駆動に加えてテスト駆動開発（TDD）も実践しています。テストの設計や生成もAIに任せることで、「仕様書は正しいけど実装が間違っている」という事態を防いでいます。

AI以前からの土台が「Figma→コード変換90%」を実現

―― 「Figmaからコードへの変換精度90%」という成果についても、どのような仕組みで実現しているのかを教えてください

舟口：FigmaにはFigma Connectという、デザインコンポーネントとコードを紐づける仕組みがあります。これを社内のコンポーネントライブラリと接続しているんです。

具体的には、社内コンポーネントの情報をMCPサーバーで提供し、Figma Connectがそれを読み込む。AIツールがこのMCPを呼び出すことで、Figmaに描いたデザインがそのままコードになって出てくる。これをかなりの精度で実現できています。

それぞれのツールを「点」で使っている事例はよく見かけますが、これを一連の流れで「線」としてつなげている会社はあまりない印象です。この一気通貫の連携が、高い精度を実現しているポイントだと思っています。

―― なぜplaygroundではそれが実現できたのでしょうか

舟口：AI時代が来る前から、特にフロントエンドは先進的なところを追い続けようというスタイルでやってきました。コンポーネントライブラリも昔からつくり続けていて、みんなが使い回せるように整備していたんです。

そこにFigmaがFigma Connectを提供してくれた。弊社のコンポーネントライブラリはすでに綺麗に整備されていたので、それを接続するだけで連携できる状態でした。準備ができていたところに必要なピースが揃って「じゃあ、いけるじゃん」という話になったんです。

ちなみに開発チームでは、週次で「AI実装分科会」をやっていて、それぞれがキャッチアップしてきた新技術に関する情報を共有しています。良さそうなツールがあればすぐに試して、効果が出れば採用する。Figma Connectもその流れで導入が決まりました。

塚原：AIにそのツールを使わせた場合と、使わせない場合で、それぞれコードを書かせてみる。出てきたアウトプットの品質を比較して、良ければ採用する。この検証サイクルを頻繁に回していますよね。

伊藤：このような業務の仕組み化が行われてきた背景には「戦術遵守」というplaygroundのバリューがあります。

たとえ個人技で突破できるスター選手が入っても、チーム戦術を優先させる。それがうちの方針です。コーディング規約、コンポーネント定義、デザインシステムなどなど、一番いいやり方を事前にみんなでしっかり決めて、その戦術のうえで、個々人がクリエイティビティを発揮したときにチーム力が最大化するという思想を大切にしてきました。

その土台があったからこそ、Figma ConnectやAIツールが加わった時に、組み合わせるだけで正しいものが出てくる状態になったんです。

―― AI時代になって、ライブラリ選定に対する考え方は変わりましたか

舟口：playgroundでは、ソースコードがGitHub上でどれだけ使われているかをライブラリ選定の基準のひとつにしています。出てくるコードのレベルがそれで変わると感じていて、マイナーな言語やライブラリではなく、メジャーなものを使っていこうという方針です。

伊藤：AIが精通しているか、をライブラリ選定基準の一つに加えよう、という考え方ですね。

エース級の社員が入社してきて「自分はこのライブラリに精通しています」と言ったら、「じゃあそれを使おう」となることがあります。同じように、AIが得意とするライブラリを優先的に選定するようになりました。

「コードを書く」から「設計する」へ。AI時代のエンジニアの価値

―― 長年コードを書いてきたエンジニアとして、AI駆動開発への移行を率直にどう感じていますか

舟口：正直に言うと、コードを書く機会が減っていくのは少しだけ寂しいですね。コードを書いてきた量には自信があるので。

ただ、その感情にはあまり意味がないなと、この会社にいて実感しています。コードを書くことではなく、プロダクトを作ることにフォーカスできるようになり、手戻りの少ない環境で「これをやりたい」「そのためにはどうすればいいか」という本質的な議論に集中できる。プロダクト開発という観点では、むしろポジティブな気分です。

塚原：私としては、AI駆動開発になってコミュニケーションの負担が減ったなと感じています。

ウォーターフォール的な進め方は理屈上正しいけれど、人が成果物に対して厳しくレビューすると、心理的な負担が大きくなりがちでした。でも相手がAIになったことで、遠慮なく指摘しても淡々とやってくれる。その変化は大きいですね。

―― コードを書くことが減ったぶん、エンジニアは何にフォーカスすべきだと考えますか

舟口：コードやアーキテクチャの一貫性を保ち続けること。これがAI時代のエンジニアに最も求められることだと思っています。

コードを書くことではなく、設計や保守性を保ち続けることにエンジニアの価値がある。AIが書いたコードが、全体のアーキテクチャと整合しているか。一貫性が崩れていないか。そこに目を光らせる方向にフォーカスしていくことになるのではないでしょうか。

―― 他にも、エンジニアの業務で変化を感じている部分はありますか

舟口：エンジニアの負荷がかなり減りました。

従来の開発では、上流工程で詰め切れなかった仕様の曖昧さを、エンジニアが実装段階で補完することが多かったんです。いわゆる“できるエンジニア”は「エスパー能力が高い」と言われることがありますが、あれは超能力でも何でもなくて、「今後の要件を考えるとこう実装しておくべきだ」を論理的に導き出しているだけなんですよね。

仕様駆動開発では、PdM側が仕様を詰め切ってから開発に渡してくれます。だからエンジニアは補完作業から解放されて、本質的なプロダクトの議論に集中できるようになりました。

―― エンジニアの働き方が大きく変わっている中で、AI駆動開発の環境で働くことは、キャリアにとってどのような意味があるとお考えですか

伊藤：紙からデジタルへの転換期にいち早くデジタル環境で働いていた人が、10年後に高い市場価値を持ちました。

AIへの転換期であるいま、この時期にAI前提の開発プロセスを実践した経験は、10年後、AIが当たり前になった時代において歴然とした差になるはずです。

playgroundは、その「10年後の当たり前」を今実践している会社です。この環境に身を置くキャリア価値は非常に高いと考えています。