■ 1. 背景と問題意識
- AI時代のデザイナーの不安:
- リサーチもドキュメント作成もAIが担う領域が広がり、既存の専門性やスキルだけで大丈夫かという問いが生じている
- 「自分にしかできないこと」を問い直される場面が増えている
- サービスデザイナーの実態:
- デザインの専門性を起点にしつつ、プロジェクト全体を俯瞰して動く役割を担ってきた
- クライアントの課題把握、関係者との合意形成、スケジュール管理や関係者調整にも積極的に関わっている
- すでに「デザインだけ」の枠を超えた動き方をしてきたと言える
- 属人化という課題:
- 幅広い業務への関わりは個人の経験やセンスに大きく依存していた
- 「どう進めるか」が属人的なノウハウとして蓄積される一方、メンバーが変わっても再現できる「型」は整っていなかった
- プロジェクトの発足:
- 属人化への課題意識と、AI時代に自分の領域をどう広げるかという問いが重なった
- サービスデザイナーの有志で、AIを使ってプロジェクト管理業務にも自信を持って関われる状態をつくる取り組みを開始
- 2026年4月に始まり約4カ月間の試行錯誤を経ている
■ 2. サービスデザイナーとプロジェクト管理
- サービスデザイナーの仕事:
- クライアントの課題を把握し、それを解決するための体験やサービスを設計すること
- ヒアリングの設計、ユーザーの理解、コンセプトのとりまとめが本来の主戦場
- 管理業務に関わる理由:
- デザインの方針を決めるというプロジェクトの上流部分を担っている
- 一連のユーザー体験を設計するため、プロダクト全てのステークホルダーと関わる必要がある
- 主に関わるプロジェクト管理業務:
- プロジェクトの目的、範囲、制約条件を整理したドキュメントの作成
- 「誰が何を決めるのか」という関係者の役割整理
- 新しい案件に入るときのクライアント業界の事前調査
- 定例会議の準備や議事録の管理
- 強みの意図的な活用:
- デザインの視点でユーザーや事業全体を見渡せるからこそ、プロジェクト管理でも質の高い判断ができる
- グッドパッチはこの強みを意図的に生かしている
■ 3. PM業務の整理と分解
- 出発点はPM業務の理解:
- 自分たちはプロジェクト管理のプロフェッショナルではないという前提に立った
- プロジェクト開始直後に社内のプロジェクトマネージャー職のメンバーへヒアリングを実施
- 参照したPMBOK:
- プロジェクト管理の国際標準となっているフレームワーク
- 業務を「立ち上げ」「計画」「実行」「監視・コントロール」「終結」の5段階に分けて整理している
- 業務の一覧化:
- PMBOKをベースに、サービスデザイナーが実際に担っているタスクを一覧化した
- AIが代替できる可能性があるタスクも併せて一覧化した
- 発見1: PM業務の多くを既に担当:
- スケジュール設計、関係者の整理、要件の取りまとめ、会議の設計はすべてPMBOKに定義されたPM業務
- サービスデザイナーが実質的なPMとして機能していることが、客観的なフレームワークによって可視化された
- 発見2: AIの得意領域は構造化とドキュメント生成:
- ヒアリング内容の整理、情報を一定のフォーマットにまとめること、抜け漏れのチェックはAIが得意とする
- クライアントとの合意形成や優先順位の判断は人がやるべき仕事
- 決定した基本方針:
- AIが作るのはドラフトと構造、判断するのは人
■ 4. 9つのAIスキルの整備
- Claude Codeのスキルという仕組み:
- グッドパッチはClaude Codeを活用した業務効率化に取り組んでいる
- スキルとは特定の業務をAIに任せるための専用設定
- 情報を収集、整理して出力する作業フローを定義すると、一言指示するだけでAIがその手順通りに動く
- プログラムを書く必要はなく、自然言語でやってほしいことと出力フォーマットを記述するだけで作れる
- 開発の進め方:
- チームメンバーで担当領域を分け、スキルの開発を並行して進めた
- 約3カ月で9種類のスキルを整備した
- スキル1: プロジェクト開始時の全体像整理:
- 「何のために、誰と、どこまでやるのか」を文書化することは重要だが、経験と時間を要する
- 担当者とAIが対話形式でやり取りし、目的、関係者、範囲、スケジュールの骨格を整理する
- 完成文書を一発で作るのではなく、何から考えるべきか、どの順番で整理するかという思考の流れの支援に絞っている
- スキル2: プロジェクト関係者の整理:
- 意思決定者や報告タイミングを整理しないまま進むと、後半でコミュニケーションのトラブルが起きやすい
- 関係者の構造を整理する経験はベテランでないと難しい
- 会話形式で登場人物の情報を入力すると、役割、責任、報告ルートの一覧表と組織の関係を視覚化した図を出力する
- 誰が何の意思決定に責任を持つかを整理するグッドパッチ独自のフォーマットを組み込み、実案件で試しながら精度を高めた
- スキル3: クライアント業界の素早いキャッチアップ:
- 新規案件で業界、市場、競合を理解するには半日から1日かかることがある
- マクロ環境、業界と市場の構造、法規制と制度、競合他社とポジション、ユーザーと顧客像、クライアント企業の組織と意思決定者の6つの切り口で自動整理する
- 情報の信頼度を「公式資料ベースの確かな情報」「複数ソース確認済みの参考情報」「要確認の情報」の3段階でラベリングする
- 開発過程での重要な気付き:
- 情報量が多ければ多いほど良いわけではない
- AIに渡す内部整理用の資料と、クライアントに見せるコミュニケーション用の資料では目的が違う
- 出力を分けて設計しないと、どちらにも使えないものができてしまう
- この気付きはスキルを作ってみなければ言語化できていなかった
- そのほかに整備したスキル:
- 先行事例、競合リサーチ: 他社の取り組みを調べて比較整理したいとき
- プロジェクトトラブル対応: 遅延、スコープ膨張、人手不足などへの対応策を複数案出したいとき
- 成果物の品質チェック: 作ったドキュメントの抜け漏れや論理的な矛盾を確認したいとき
- コミュニケーション計画: どの頻度で誰にどう報告するかを整理したいとき
- 定例会議のアジェンダ生成: 次回の会議の議題案を自動生成したいとき
- 要求事項の整理: ヒアリング内容を「要望→要求→要件」の段階に整理したいとき
■ 5. スキル連携によるワークフロー自動化
- 次のステップ:
- 個別のスキルがそろった段階で、それぞれをシームレスにつなげられないかを検討した
- 想定した場面:
- 新規案件の初回打ち合わせ前の準備フロー
- クライアントの業界と競合を調べ、内容を分かりやすくまとめ、正確性と抜け漏れをチェックする手順
- 人がやると半日以上かかることもある
- 自動化後の動作:
- 「○○社の業界調査をして」と入力する
- AIが公開情報をもとに6つの切り口で情報収集、整理を5〜15分で行う
- 別のAIが内容の整合性と抜け漏れを自動チェックする
- 問題がなければ打ち合わせに使える資料として完成する
- 問題があれば指摘内容をもとに自動修正し、再チェックする
- 担当者の実働時間:
- 質問への回答3分と最終確認5分程度を合わせて約10分
- 残りはAIが並行して作業する
- 磨き込みのサイクル:
- チーム内の他のサービスデザイナーに実際の案件で試験的に使ってもらった
- そのまま使えるクオリティに達しているものもあったが、改善の余地がある部分も見えた
- フィードバックを基に設計を見直して再度試すサイクルを繰り返した
- 特定の案件だけでなく幅広いプロジェクトで使えるワークフローへ磨き込んだ
■ 6. 意思決定の記録
- 記録を習慣化した理由:
- スキルを作る過程では多くの設計上の判断が発生する
- どちらのアプローチを選ぶか、どこまでAIに任せるかといった判断を後から追えるようにする必要がある
- 記録の形式:
- 意思決定一つひとつを「論点、背景、選択肢、結論、理由」の形式でドキュメントに残す
- ソフトウェア開発の現場でよく使われる手法だが、AIを使ったスキルづくりでも同様に有効だった
- 記録の効果:
- 新しいメンバーが「なぜこう設計したのか」を後から理解できる
- チームの学習の蓄積につながる
■ 7. うまくいったこと
- 最大の価値は「どう使うかの型」の提供:
- AIを使えば誰でも情報を集められる時代に、ただ情報を集めるスキルには差別化の余地がない
- 作ったスキルの価値は情報収集ではなく、現場で培ったプロジェクト管理のノウハウをテンプレートとして提供する点にあった
- ノウハウが型として使えることで、経験の少ないメンバーでも一定の品質でアウトプットを作れる
- 定例運営の変化:
- 議事録の自動生成とアジェンダを自動で作るスキルの組み合わせにより、会議の前後の準備作業が大幅に軽くなった
- 次の会議で何を話すかという議題案までAIが出すことで、準備時間が体感で半分以下になる
■ 8. 推進プロセスにおける気付きと工夫
- 方針の段階的な精緻化:
- 活動初期に「AIとは何をするものか」の定義をチーム内でていねいにすり合わせた
- 「定型作業を自動化するもの」と「自律的に計画から実行までやり切るもの」のどちらも有効な方向性だった
- そのため段階を分けて進める計画に切り分けた
- まず9つのスキル完成に集中し、次の段階でスキル同士をつなぐ自動化を考える2段階の計画とした
- 最初にゴールの認識をチームでそろえることが、後の開発をスムーズにする
- スキル連携時の前提の食い違い:
- 複数のスキルを連携させると、それぞれの設計上の前提が食い違うケースが出る
- 品質チェックのスキルが要求するフォーマットと、別のスキルが生成する文書のフォーマットが微妙に違うといった衝突が起きる
- 論点と解決策の候補を記録に残してチームで議論するプロセスを定着させ、問題の再発を防ぎやすくした
■ 9. 4カ月の活動から得た3つの学び
- 「何をAIに任せるか」を最初に整理する:
- AIを使う前に、この仕事のどこがAIに向いているかを考えることが大切
- プロジェクト管理のフレームワークと現場ヒアリングで業務を棚卸しし、AIが得意な構造化とドキュメント生成に絞って着手した
- この分解作業をせずにAIを使おうとすると、何を作ればいいか分からなくなる
- スキルの価値は「収集」より「型の提供」:
- AIで情報を集めること自体は誰でもできる時代
- 価値が生まれるのは、収集した情報をどのフォーマットで整理するかという型の部分
- 自分たちの現場で培ったノウハウを型に組み込むことで、汎用的なAIではなく自分たちの仕事に合ったスキルになる
- 試行錯誤の記録がチームの資産:
- AIを使ったスキルづくりは最初から完成形にはならない
- うまくいかなかったことや設計を変えた理由を残すことで、後から理解できる知識資産が蓄積される
- 記録の習慣こそが、個人の経験を組織の学びに変える鍵
■ 10. 結論
- デザインの専門性だけでは安泰と言いにくい時代:
- AIがリサーチもドキュメント作成も代わりにやってくれるようになっている
- グッドパッチの取り組み:
- サービスデザイナーが得意領域をデザインの外側にも広げていけるよう支援している
- AIを使い、その拡張を特別なスキルを持つ一部の人だけができることから、誰もが型として再現できることに変えていく
- 今回紹介したPM領域への染み出しは、その一部分に過ぎない