クルーレスポンシブオンボーディングサイトメーカー
팀
팀제이커브
カテゴリー
Empty
背景
チームジェイカーブに新しいクルーが合流するたびに、オンボーディングは毎回即興的だった。決まった手続きなしに担当者の記憶に依存し、抜ける項目が生じたり、同じ内容を繰り返し説明することが多かった。
この問題を解決するために、オンボーディングプロセスを体系化することにした。最初はSKILL.mdという業務設計書の形で接近したが、作成してみると方向が変わった。
完成した結果の例
ドキュメントからWebアプリへ - ピボットまで
初めて：SKILL.md（業務設計書）
クロードと対話しながらオンボーディングに必要なすべての項目を整理し始めた。合流前の行政処理からアカウントセッティング、グラウンドルール、クルー諸島、業務環境、固定スケジュール、HR、業務コンテキストまで8つのPhaseで構造化した。
まとめながら各項目ごとに[自動] / [人]分類も一緒にした。 「これは文書リンク一つで解決可能で、これは必ず誰かが直接やらなければならない」という区分だった。
SKILL.mdでまとめられた結果はかなり良かった。ところで、一つの質問が残った。
「このマークダウン文書をどのように活用すれば、組織レベルで書くことができるのか？」
コンバージョンポイント：「体験型オンボーディング」というキーワード
クロードに活用案を尋ねたとき、二つの選択肢が出た。
1.
ノッションベース- 素早く作成できますが、動的機能（進行率、段階的ロックなど）は不可能
2.
Webアプリベース- インタラクティブな体験型オンボーディングが可能
ノーションページにチェックボックスを一覧表示することと、段階的に直接完了しながら進行率が積み重なるWebアプリはオンボーディング経験自体が異なる。後者を選んだ。
この時点でSKILL.mdはWebアプリのコンテンツベースの文書に役割が変わった。文書が捨てられたのではなく、役割が進化したわけだ。
製作プロセス
ステップ1：コンテンツを完成させる（SKILL.md）
クロードが一つずつ質問を投げ、答えを受けてスキル文書を埋めていく方法で進行した。
•
スラックチャンネルリストと用途（All-unit、client、mkt-osmu-rawなど10個+）
•
ノーションメインページリンク4本（メインハブ、週刊誌、AI Native Lab、ワークショップDB）
•
休暇/勤務規則、毎日の会議出席規則
•
クルー情報管理シートの位置
•
パブリックアカウント（Tool/info/agent）ロールの説明
ステップ2：企画書でピボット
SKILL.mdが完成するとすぐにWebアプリ企画に切り替えた。クロードOpus 4.6に計画を立てた。
設計の中心は次の通りであった。
•
3段階画面構造：ウェルカム画面（名前+クルータイプ選択） - >オンボードダッシュボード（8フェーズ） - >完了画面
•
左サイドバー：Phase 1～8進行状況を一目で
•
リアルタイムプログレス：アイテムをチェックするたびにパーセントを更新
•
インタラクティブ要素：メールの自動作成、カレンダーの招待、Notionリンクのリンク、アコーディオンのメモ/詳細
ステップ3：実装（Sonnet 4.6）
実際のコーディングはSonnet 4.6に任せられました。 Opusが織り上げた計画に基づいてReact SPAを作成しました。
主な機能実装プロセス
メール自動作成機能が最も多く繰り返された。
•
最初はWindow.location.hrefでmailtoを実行しましたが、iframe内で実行されて画面自体が飛ぶバグが発生しました
•
Window.open(..., '_blank')で修正して解決する
•
•
50以上の韓国の姓氏テーブルを内蔵し、姓+名初星の組み合わせでメールアドレスを推論
コーヒーチャットスケジューリングは、日付/時間を選択すると全体クルー10人にGoogleカレンダー招待が発送される仕組みにした。
Notion Profile Guideは、 faces.notion.comへのアクセス - >フェイス制作 - >ダウンロード - >担当者共有の4段階プロセスをモーダルに案内するように構成した。
修正の繰り返し
一度に完成したわけではなかった。主な修正履歴を見ると：
1.
WelcomeScreenのCSSが抜けて入力背景が白にレンダリングされる問題
2.
下ボタンが切り取られて見えないレイアウトオーバーフロー
3.
メールボタンをクリックすると白い画面（Iframe mailto問題）
4.
Phase別詳細調整（クルー情報最新化からメールボタンを削除、メールシグネチャを担当者案内要請に変更など）
5.
クルータイプ(CORE/HUB)による日々の会議ルール分岐処理
この過程でスクリーンショットを撮って見せて問題を説明すると、クロードが原因を把握して修正するように進めた。
結果：ホンウェルカム
最終配布されたサイト： Jcurve-onboarding.vercel.app
構成の概要
区分 | 内容 |
技術スタック | React(SPA)、Vercel 配布 |
デザイン | ダークモード、ミント/シアンアクセント |
総フェーズ | ステップ8 |
総チェックリスト項目 | 36個 |
インタラクティブ要素 | メールの自動作成、カレンダーの招待、Notion リンク、アコーディオン、プログレスバー |
8つのフェーズ
フェーズ | 名前 | アイテム数 |
1 | 合流前（担当者アクション） | 5 |
2 | アカウント設定（参加初日） | 4 |
3 | グラウンドルール | 5 |
4 | クルー諸島の把握 | 2 |
5 | 業務環境設定 | 8 |
6 | 固定スケジュール | 4 |
7 | HRガイド | 2 |
8 | 仕事の文脈 | 6 |
制作方法の回顧
Opusによるプラン、Sonnetによる実装
今回のプロジェクトで試みた方式は、 AIモデル間の役割分担だった。
•
Opus 4.6 : 全体構造設計、フェーズ分類、機能計画、コンテンツの整理
•
Sonnet 4.6 : 実際のReactコードの実装、バグ修正、UIの調整
Opusは「何をすべきか」をよく整理し、Sonnetは「どうするか」を素早く実行した。計画と実施を分離したことは効率的でした。
SKILL.mdから始まったのが鍵
最初からウェブアプリを作ろうとしたら、コンテンツが粗末だった可能性が高い。マークダウン文書で全体の内容を慎重に整理した後、Webアプリに切り替えたため、各項目の説明、リンク、担当者情報が抜け落ちた。
文書->計画->実装の順序が結果的に正しいと見なすことができます。最初はスキルを作らなければならないという考えだったが、事実上企画案を作ることになったわけだ。
人の手が少ない
このプロジェクトの元の目標は、「オンボーディングで人の手が少なくなる」ことでした。完全自動化ではないが、新しいクルーがリンク一つを受けて自ら進行できる仕組みが作られた。担当者にメールを送らなければならない項目もボタンひとつで解決され、どのチャンネルに入るべきか、どのノッションページを確認すべきかも各段階ですぐに案内される。
今後改善できること
•
進行状況の保存：現在はリフレッシュすると初期化されます。ブラウザストレージまたはDB連携が必要
•
管理者ダッシュボード：誰がどこまで完了したかを一目で確認する
•
スラック通知：オンボード完了時にチャンネルに自動通知
•
クルータイプ別分岐強化：CORE/HUB/FREE別に見える項目を異なる構成
「AI Native百科事典」を購読する
サイトを購読すると、新しい投稿などの最新のアップデートを通知やメールで最初に受け取ることができます。
Slashpageに参加して「AI Native百科事典」を購読してください！
Slashpageに参加して「AI Native百科事典」を購読してください！
