こんにちは。グッドパッチのサービスデザイナーのぬまです。

グッドパッチのデザイナーは、クライアントワークとは別に「組織貢献活動」という社内プロジェクトを日々進めています。ざっくり言うと、組織が持続的に成長していくための”投資活動”のようなものです。

サービスデザイナーのチームでは今期、各々が「AI×UXデザイン」の領域を深く理解した上で、チームとして知見が組織として蓄積・再現可能になることを目指しています。属人的ではなく、チームとして一貫した品質を出せることがポイントです。

この活動には、現在15人程度のメンバーが関わっています。そのため、チームや個々人の活動が見えづらい構造を作ってしまうと、組織の生産性にも影響すると思っていました。そこで、活動当初からGithubとClaudeCodeでの運用を中心とした仕組みづくりを実現したいと考えていました。

個人個人が生成AIを活用するだけでは頭打ち　組織の生産性を高めるために必要なこと

皆さんはGitHubのアカウントをお持ちですか？　私は2026年1月に初めてアカウントを登録しました。エンジニアではないため、それまでGitHubとは無縁だと思っていたからです。正直、ページを開いても英語だらけで、構造もよく分からず、抵抗感がありました。

今はチームメンバーと一緒に、組織運営をGitHub中心でやり取りするようにしています。議事録も進捗も、日々の試行錯誤も、すべてGitHubに集約しています。

サービスデザイナーに限らず、グッドパッチでは今、日々の業務やプロジェクトにどのように生成AIを取り入れるかを皆で試行錯誤しています。一般的にAI活用の話では「成果物をどれだけ効率的に・質の高いものを作るか」ということに焦点が当てられます。確かにClaude Codeなどを使えば作業は早くなり、アウトプットは短時間で出てきます。しかし、それは個人レベルに閉じた話になりやすいです。

私は、生産性の高い個人が多くいても、生産性の高い組織は生まれないと思っています。

例えば、以前の私であれば、Claude Codeに作ってもらったMarkdownやHTMLをzipにまとめてSlackで送っていました。ただ、受け取った相手はそこからアウトプットの品質を上げることはなかなかできません。

理由はシンプルです。私の手元には、プロジェクトの背景やこれまでの議論といった”コンテキスト”が日々積み上がっています。一方、ファイルを受け取った相手にはそれがありません。切り取ったmdファイルを1枚送っても、そこに張り付いていたはずの”コンテキスト”までは引き継がれず、受け取り側のアウトプットのスピードや品質は伸び悩みがちです。

チームとして動くとき、この問題は何とかならないかと以前から感じていました。生成AIを使って作るスピードが上がっても、コンテキストの「共有・接続」がボトルネックになってしまいます。

だからこそ、GitHubを土台にして、議事録・検討プロセス・アウトプットのような日々のコンテキストを、全員でつなぎ続けるための仕組みを少しずつ組み上げてきました。

メンバーの多くは、GitHubをほとんど触ったことのないデザイナーたちです。ここからは、GitHub初心者のデザイナーたちがどのように使い、2カ月が経過した現在、どのような変化が起きたかをお伝えします。

運用は可能な限りシンプルに　チームを支えるフォルダ構成を検討する

GitHubというと、ブランチを切ったりマージしたりといった運用のイメージが先に立ち、それ自体にハードルを感じる人は少なくないと思います。

リテラシーがバラバラなチーム全員で使うなら、運用方法はシンプルな方が望ましいです。そこでフォルダ構成だけで、チームの動きを支える形を考えました。

メンバー一人ひとりに「自由な場所」を用意する

フォルダ構成で最初に決めたのは、メンバーが自由に使える場所を作ることです。今回は「members/名前/」というフォルダをメンバーごとに用意しました。書きかけのメモも、思いつきの図も、ドラフトも何でも置けます。こうしないとメンバーが全く使ってくれないと思ったからです。

ただ、そのままだとClaudeが個人の散らかった作業ファイルまで読み込んでしまいます。そこで、claude.ignoreというファイルを置いて、members/の中身は基本的にAIのコンテキストとして読み込ませない構成にしました。

組織貢献活動は、5つのチームに分かれているのですが（AIda ~~チームがそれに当たります）、それぞれに同じ型のフォルダを用意し、最終的に下記のような構成になりました。

├── team-pm/             # AIda PMチーム
│   ├── members/         # 個人の自由スペース
│   ├── meeting-notes/   # 議事録
│   ├── docs/            # 正式なアウトプット
│   └── sprints/         # スプリント振り返り
├── team-ui/             # AIda UIチーム
├── team-trial/          # AIda Trialチーム
├── team-knowledge/      # AIda Knowledgeチーム
├── cross-numano-team/   # AIda Crossチーム
└── shared/              # チーム横断の共通ドキュメント

members/は個人の場所、meeting-notes/ docs/ sprints/は共有の場、と用途を分けています。同じ型を全チームでそろえたことで、誰がどこを見れば良いかが分かるようになりました。

ファイルにはフロントマターを付ける

また、共有の場に置くMarkdownには、必ず先頭にフロントマターを付けるようにしています。

---
id: CT-mtg-2026-04-17-AIda_Cross定例
title: "AIda_Cross定例"
depends_on: []
affects: []
version: 1.0
last_updated: 2026-04-17
status: done
---

AIが「どのチームの、何の文書か」を一目で掴め、last_updatedで鮮度が分かるのでファイル名に_v2_finalのような印を付けなくて済むようにするためです。

最初の一歩が大切　GitHubの利用ハードルを極限まで下げるには

仕組みを整えるだけでは、利用する瞬間のハードルは下がりません。とにかく使い始めてもらうために、まずはメンバーに以下の2つだけをお願いすることにしました。

• GitHubのアカウントを作ってほしい
• GitHub Desktopというアプリを入れてほしい

そして、運用を1カ所に集めてコンテキストを残したいこと、定例での報告の負担を減らしたいこと、コンテキストを溜めておくと社外発信もしやすくなることなど、背景もていねいに伝えるようにしました。

ちなみに、ターミナルが絡むとハードルを感じてしまう方は多いです。コマンド1つで先に進めないなど、「GitHubはやっぱり難しい」という印象を持たれてしまいます。GitHub Desktopを使っていただいたのはそれが理由です。

運用ルールはシンプルに保つ

フォルダ構成についてもそうでしたが、編集についても運用ルールはできるだけ削ぎ落としました。mainで直接作業して良いことにし、その代わり、作業場所だけは決めました。members/名前/の中に、その日の日付フォルダを作って、その中では何をやっても自由にすることにしました。このルールにしておくと、基本的にコンフリクトは起きません。

議事録を自動で溜め、コンテキストとして利用可能にする

その後は議事録をコンテキストとして使える状態を実現したく、自動でGithubに溜めるためのワークフローを組みました。

リポジトリを1つで運用しているので、会議名にチームのキーワードを入れておくと、その文字列をフックに振り分け先のフォルダが決まります。仕組みとしては、まずGAS（Google Apps Script）がGoogle Meetから自動生成された議事録をGitHubのリポジトリに連携し、その上がった内容をGitHub Actionsが読み取って、会議名のキーワードに応じて各チームのフォルダへ振り分ける、という流れです。これを毎日定期実行しています。

GitHubに集約された議事録やコミット状況を有効活用したく、morning-briefingというスキルとscheduleを組み合わせて、私宛てに毎日Slackで届くようにしました。

中身は未完了のToDo（自分と全員の分）、前日の5チームの議事録ハイライト、そして直近3日間のGitコミットを個人別に集計したものです。これによって、私は自分が出席できなかった会議の決定事項も、誰が今何に取り組んでいるかも、朝の数分で全体像がつかめるようになりました。

生成AI時代、Githubはエンジニアだけでなく、全てのホワイトカラーに必須のツールになる

そして、チームでのGithub運用を始めて2カ月が経ち、まだ途中段階ですが、メンバーがGitHubを使うことに慣れてきました。日々のコミット状況や、各個人のコミット状況を見ていると、それなりに使う習慣ができつつあると感じています。

もちろん、個人によって「使っている／使っていない」のグラデーションはあります。それでも、情報を1カ所に集約したり共有したりするときに、「GitHubからローカルにpullして内容を確認してください」と言えるようになりました。

かつて、Slackで手作業で添付ファイルやzipファイルを送っていたことが、もうなくなりました。それ自体がコンテキストとして、そのまま全員に共有できる状態になったのは、非常に良かったと感じています。

例えば、毎月の報告会もやり方が変わりました。あらかじめフォーマットを決めておけば、そのフォーマットに沿って、過去のコンテキスト、特に直近1カ月の活動内容を基に、どんな活動をしてきたのか、AIが叩き台を作ってくれるようになりました。各チームのメンバーが報告やその準備にかける時間も、以前より減ったと思います。

これまでGitHubを食わず嫌いしていましたが、議事録や個々の成果物がGithubで共有できる状態になると、時間をかけて積み上げたものが、やっと組織としての生産性向上につながっているなという感覚になってきました。今回の試みを通じて、Githubの活用はエンジニアだけでなく、もはやホワイトカラーの人でも必須のツールだと感じています。

コンテキストが溜まり、より質の高いアウトプットが生まれていること。これは自分にとっても、チームとして成果を上げる上でも、非常に良いと感じています。とはいえ、まだ土台ができて慣れ始めたばかりです。本来あるべき、もっと良い運用の形があると信じて、引き続き挑戦していきたいと思っています。

ここまで読んでいただき、ありがとうございました。

AI時代に、自分の領域を積極的に広げていきたい方。そして、AI時代のデザイナーの価値を一緒に考えていきたい方。私はそんな人たちと一緒に働きたいと思っています。少しでも興味を持ってくれた方、お気軽にカジュアル面談からいかがでしょうか。お待ちしています。