講師として関わるすべての方へ。
この講座の目的、設計意図、守るべきルールのすべてをまとめています。
元々ツール4つに振り回されていた原体験から生まれた講座。
「止まっている人の背中を押す場所」としての4つの信念。
Larkは手段。経営者の「思考」が変わらなければ何も変わらない。操作方法の前に「なぜこの仕組みが必要か」を必ず伝える。
「あの人がいないと回らない」は仕組みの欠陥。誰かが休んでも辞めてもビジネスが回る状態を作る。それをLarkで実現する。
みんな頑張っている。でもツールがバラバラだと努力が成果に繋がらない。頑張りがちゃんと報われる仕組みを一緒に作る。
業務効率化はゴールではなくスタート。「仕組みができた後、あなたは何をしたいですか？」を常に問いかける。
各レベルは「何を教えるか」ではなく「受講生の視座をどこまで引き上げるか」で設計されている。
1人で使う全体機能をマスターし、自社の業務システムを構築する。「自分の仕事の構造が見えた」がゴール。
「自分の業務を効率化する人」から「相手の組織の課題を解決する人」へ。組織向け機能を習得し、模擬案件で実践力を仕上げる。
構築力をビジネスに変える。営業導線・提案・契約・定着支援のスキルを身につけ、実案件の受注と継続サポートができる状態を作る。
Larkの中だけでは解決できない課題に挑む。外部システム連携、API、AI統合で高単価の技術案件を獲得できるエキスパートを目指す。
各回のテーマ・ゴール・成果物は共通。教え方のスタイルは講師の経験を活かしてください。
基礎完成 & 組織向け機能の習得
設計力 & 提案力の強化
模擬案件で実践力を仕上げ
押し売りは信頼を壊す。講師が売り込むのではなく、受講者が自分の手を動かした結果として「次の壁」に自然と気づく構造を作る。
| 場面 | 受講者の心の声 |
|---|---|
| 知人に「うちにもやってよ」と言われた | 「相手の会社は従業員がいる。承認とか権限ってどうするの？」 |
| 他の受講生の複雑な設計を見た | 「もっと複雑な要件にはどう対応する？」 |
| 「自動化をもっとやりたい」と思った | 「条件分岐とか承認連動はどうやるの？」 |
| 場面 | 受講者の心の声 |
|---|---|
| 模擬納品プレゼンが終わった | 「本当のクライアントをどうやって見つける？」 |
| 「価格はいくらにする？」と聞かれた | 「いくらで売ればいいか全然分からない」 |
| 構築した環境の「その後」を考えた | 「使われなくなったら？定着させるには？」 |
| 場面 | 受講者の心の声 |
|---|---|
| 「kintoneのデータと連携して」と言われた | 「データの同期...Larkの中だけじゃ無理じゃない？」 |
| 「LINE問い合わせをBaseに自動登録したい」 | 「Webhookって聞いたことはあるけど...」 |
| 「AIで自動分類してBaseに振り分けたい」 | 「MCPとかAPIとか触ったことがない」 |
異なる講師が各レベルを担当する中で、内容の重複・矛盾・先取りを防ぐルール。
各レベルには「視座」がある。その視座に合わない内容を教えると、受講者が混乱し、次のレベルの価値が薄れる。
前のレベルで教えた内容を「前提」として使うのはOK。同じ深さで教え直すのはNG。受講者の時間を無駄にしない。
次のレベルの内容を「存在をほのめかす」のはOK。「教える」のはNG。壁の設計が崩れる。
講師の仕事は「機能の説明」ではなく、受講生の視座をそのレベルに合った高さまで引き上げること。
「どう操作するか」の前に「なぜそうするのか」「誰のためにやるのか」を伝える。受講生が「Larkの使い方を覚えた」ではなく「自分の仕事の構造が見えた」と思える状態を目指す。
講義で知識を渡すだけでは足りない。修了発表会で「自分の手で作り切った」という実感を持って立てる状態を目指す。発表会は講座の根幹。
カリキュラムの構造が生み出す気づきであり、講師が「次のコースも買ってください」と言うものではない。受講生自身が「もっと先に行きたい」と思う状態を作る。
ITリテラシーゼロからBase構築できるようになった事例がいくつもある。どんなスタート地点でも「変えたい」と思って来ている人。その努力を認め、伴走する。
共通カリキュラムの骨格は守る。しかし「どう伝えるか」は講師自身の経験が活きる部分。リアルなエピソードこそが受講生の心を動かす。
全講師が共通で使用するフォーマット。独自テンプレートの追加はOKだが、共通フォーマットの省略・差し替えはNG。
現状の業務を棚卸しし、課題とゴールを整理するためのフォーマット。受講初回で使用。
クライアントの業務課題を構造的に引き出す。As-Is / To-Be / 組織の制約 / 優先順位合意まで。
ヒアリング結果をクライアントとの合意文書に構造化。スコープ・業務フロー・テーブル設計を含む。
テーブルの各フィールドを実装レベルで定義。型・必須・入力方法・用途を明確化。
Phase 1（MVP）→ Phase 2（拡張）→ Phase 3（最適化）の段階的導入計画。
クライアントのスタッフが見て操作できるレベルの引き渡し文書。FAQ・拡張案を含む。
講師が記入。5段階評価 + 修了認定（合格 / 条件付き合格 / 再提出）。基準を統一しフィードバックを返す。
ミスを責めるためではなく、事前に知っておくことで事故を防ぐためのリスト。
「これを教えていいか？」と迷ったとき、この順序で確認してください。