「便利なのは分かっている」の先へ進むために
社内のエンジニアリング環境をより良くしたい、あるいは業務の在り方をアップデートしたい。そう考えたとき、今やAIという選択肢を外すことはできません。
2023年ごろからGitHub Copilotの名前は社内でも頻繁に耳にするようになり、一部では活用も始まっていました。しかし、改めて確認してみると、正式な導入までの道筋が、具体的には見えていなかったのです。
私はエンジニアの利用者として「便利なのは分かっている。全社で、誰もが安心して、公式な武器として使える状態にしたい」という強い思いがありました。
この思いを実現するために数カ月にわたるPoC導入プロジェクトの幕開けとなりました。
組織の力を味方につける：推進ユニットの伴走とPoCフレームワークの活用
今回私が推進したGitHub Copilotの導入は、決して私一人の力で成し遂げたものではありません。技術的な検証はできても、それを全社的な施策へ落とし込むプロセスは、エンジニアの私一人では完遂できませんでした。そこに、他部署のメンバーが持つ専門性や知見によるバックアップがあったからこそ、プロジェクトを完遂することができました。
社内ナレッジを武器にする。「PoCフレームワーク」が生む再現性
そもそもPoCの概念と言葉が分かっても、本当に新しいツールを導入する際に、「何から手を付け、どう評価すべきか」という悩みがありました。ここで大きな助けとなったのが、今期から取り入れられた「社内ツール導入PoC支援フレームワーク」でした。
このフレームワークには、過去の成功事例に基づく「計画書フォーマット」や「結果報告書」の型が定義されています。ゼロからPoC計画や書類を作るのではなく、フレームワークに含めたPoC設計の観点を活用することで、検証の抜け漏れを防ぎ、スピーディーに実証プロセスへ移行することができます。この「型」があることで、確実に終えるPoCの推進ができました。
社内のフレームワークを利用することで、PoCが高い再現性を持ってプロジェクトを推進できる。これこそが自社の多職種と連携できるケーパビリティでもあります。
多様なメンバーとの壁打ちで得た、一段上の視座
今回のPoCを通じて最も刺激的だったのは、多様な職能のメンバーとのアイデアをぶつけ、フィードバックをもらう『壁打ち』」にあります。エンジニアとしての「このツールは便利！必要である！！」という視点に対し、彼らは「案件全体の採算性にどう寄与するか」「クライアントへの提供価値はどう変わるか」「今自社が抱えている問題の解決が可能か」といった多角的な問いを投げかけてくれます。この対話を通じて、私は単なるツール導入の推進者というポジションから、ビジネス全体を最適化する視点へと視座を高めることができました。この部署を越えた共創こそがこの取り組みの中核だったのではないかと感じています。
PoCの全容：半年間で私たちが向き合ったもの
近年よく耳にする「PoC」と聞くと、単に「ツールを使ってみて、良かったかどうかを判断する期間」と思われがちです。しかし、組織として導入を進める上では、それ以上にビジネスとしての妥当性と安全な運用ルール、育成プログラムを確立するプロセスこそが重要でした。
1. 計画フェーズ：期待値を「言葉」にする
まず最初に取り組んだのは、PoC計画書の立ち上げです。正直なところ、書き始めは「使えば良さがわかるのに、なぜこんなに細かく書かなければならないのか」という、エンジニア的な、現場寄りの葛藤もありました。現場利用者の「感覚的に良い」というものをビジネス的に説得力のある言葉に翻訳し、意思決定者に伝えることが何より必要だったのです。
しかし、ここで「何をもって成功とするか」を定義したことが、後に大きな意味を持ちます。単に「便利になった」という感想を集めるだけではなく、会社として投資する価値があることを証明するために、「定量的な効率化の指標」と「定性的な満足度」の二軸で、誰が見ても納得できる評価基準を策定しました。
普段このような資料を作ることが少ないため、社内の協力メンバーには大きく助けられながら作ったことを鮮明に覚えています。
2. 環境整備フェーズ：見えないリスクを可視化する
AIを導入する上で避けてとおれないのが、セキュリティーや著作権のリスク管理です。テストユーザーが安心して利用できるよう、暫定的な利用ガイドラインを作成する。初学者が使うときのリスク想定や対応方針の組み立てといった基本事項の確認プロセスを経て、私の視点は少しずつ「一利用者の希望」から「推進者の責任」へと変化していきます。
また、博報堂アイ・スタジオは毎年一定数の新卒メンバーを迎えます。彼らがGitHub Copilotを使うとなった際に育成の妨げにならないか？トレーナーはどういう位置付けでツールを使うのか？などコミュニケーションレベルから導入とその向き合い方を探っていきました。
3. テスト期間（2ヶ月）：現場の熱量と「肌感覚」の収集
実際に現場のメンバー数名にテストユーザーとして、日々の業務でGitHub Copilotをフル活用してもらいました。 この期間中、私は推進者としてメンバーのフィードバックを注視していました。驚いたのは、テストユーザー社員の非常に協力的な姿勢です。「こんなプロンプトで効率が上がった」「この作業がこれだけ短縮された」といったポジティブな声が、日を追うごとに積み上がっていきました。
現場の「もっと使いこなしたい」という熱量に触れるたび、このプロジェクトを絶対に成功させなければならないという責任をさらに強く感じることができました。
4. 評価・報告フェーズ：感覚を「経営の言語」に変える
2カ月のテスト期間終了後、収集したアンケート結果やログをもとに報告書を作成します。ここで導き出されたのが、「実装業務とテクニカルディレクター（以降、TD）業務で約10％以上の業務効率化」という結果です。 単なる時短ではなく、定型作業の削減によってクリエイティブな思考に割ける時間が増えたという事実を、数字とコメントの両面から裏付けていきました。
また同時に効率化によって生み出された時間を次の技術習得に投資できるという確かな手応えをつかんだ瞬間であります。
現場で見えた「10%以上の効率化」の正体：具体的な活用シーン
今回のPoCで導き出された「10%以上の業務効率化」という数字。それは単なる時間の短縮ではなく、現場のストレスが解消され、よりクリエイティブな判断に時間を使えるようになった結果でもあります。具体的にどのようなシーンで効果を発揮したのか、ここでは3つのエピソードを紹介しましょう。
TDも納得のサジェスト精度。LP制作のスピードが劇的に向上
LP制作において、フロントエンドの実装はスピードと正確さが求められます。GitHub CopilotはHTML/CSSの構造や、JavaScriptによるインタラクティブな動き（スライダーやフォームバリデーションなど）の文脈を驚くほど正確に理解しました。「次はこのコードを書きたいはず」というサジェストが絶妙なタイミングで提示されるため、タイピング量は激減。
こだわりが強いクリエイティブメンバーとのディスカッションでも「相談しながらパフォーマンス改善や細かな演出のブラッシュアップに集中できる」と高い評価を得ました。
引き継ぎ資料の作成がわずか30分。ドキュメント作成のパラダイムシフト
TDの業務において、案件の完了時や担当変更時の「引き継ぎ資料作成」は避けて通れない、かつ非常に重いタスクです。複雑なCMSのカスタマイズ箇所や独自のロジックを説明するために、これまではコードを読み解きながら数時間をかけてドキュメントをまとめていました。これがCopilot Chat（※3）を活用することで劇的に変わりました。実装コードを読み込ませた状態で「ディレクトリの構造と主要なロジックをREADME形式で要約して」と指示するだけで、精度の高い叩き台が数秒で生成されます。中身の最終確認と微調整を含めても、以前は半日かかっていた作業がわずか30分程度で終了。情報の鮮度を保ったまま、スピーディーに後任へパスを回せる環境が整いました。
※3 GitHub Copilotのサービスに含まれるチャット機能。作業中のプログラムに対してチャットでの確認や提案などをうけ、作業進行やブラッシュアップなどが可能になる。
補完から共創へ。チャット機能がもたらした新しい開発体験
導入前、多くのメンバーはGitHub Copilotを「コードを自動で補完してくれる便利な予測変換」程度に捉えていました。しかし、PoCを通じて真に価値を発揮したのは、AIと対話できるチャット機能でした。例えば、ヘッドレスCMSの複雑なカスタムフィールドの設計や、条件分岐が入り組んだロジックを組む際、一人で悩むのではなくAIと壁打ちをします。「この要件を実装する場合、より拡張性が高く保守しやすいパターンはあるか？」という要件に対し、実装メンバーだけでは思いつかなかったベストプラクティスが提示されることもあります。単なる「作業の代行」ではなく、エンジニアの思考を加速させる「並走者」としての存在感。これこそが、数字以上のインパクトをもたらした大きな要因だと感じられました。
AIと歩むこれからの組織
AIの進化速度を考えれば、調べている間に次のサービスが出てくることが常にあります。ひとつずつ考えるべき内容を詰めている中でそういった技術進化の波に触れ、焦る気持ちもとてもありました。
しかし、今となって思うこととして、急進的な導入は、時に組織に「拒絶反応」を引き起こします。今回、あえて時間をかけてPoCというステップを踏み、ドキュメントの確認一つひとつにAIの視点を取り入れながら議論を尽くしたことで、「なぜ今、この会社にAIが必要なのか」を組織全体が納得した状態でスタートを切れたのです。
「10％以上の効率化」という数字は、あくまでひとつの指標に過ぎません。それ以上に、現場のメンバーが「新しい技術で私たちの働き方を変えられるんだ」という手応えを感じ、経営層が「リスクを管理しながら挑戦を後押しする」という成功体験を得たこと。この両輪が揃ったことこそが、真の成果だと確信しています。
振り返って
GitHub Copilotの導入は、「AIの業務利用」への最初の1つ目に過ぎません。
AIは日々進化し、私たちの仕事の定義を塗り替え続けています。これからの推進者に求められるのは、最新技術を追いかける情熱だけでなく、それをいかに組織の文脈に載せて、共通の価値へと昇華させるかという「翻訳の力」なのかもしれません。
今回のプロジェクトを通じて得たこの視点を武器に、私はこれからも、次なる「変化」を積み重ねていきたいと思っています。
