研修管理の効率化について書かれた記事の多くは、「まずツールを入れましょう」から始まります。この記事は逆です。私たちには、すでに研修カリキュラムがありました。それを整理しようとして、失敗しました。その3日後に「もう自分たちで作ったほうが早い」と判断し、社内ツール「研修ハブ」の開発が始まっています。
この記事は、Web制作会社であるGrowGroup株式会社が、なぜ研修管理を自作することになったのか——その背景・課題・目的・現在地を、社内に残っている記録どおりに公開するものです。うまくいった話ばかりではありません。中核の機能は、コードは完成していますが、まだ動いていません。そして効果を数字では測っていません。そこも含めて書きます。そのうえで、始まりにあった2つの課題は、2つとも解けました——その中身も、最後に書きます。
目次
- 1 始まりは「7月1日に新入社員が入社する」という締切だった
- 2 あったのに機能しない——研修管理が壊れる2つの理由
- 3 何が壊れていたのか——新人が増えるたびに「列」が増える
- 4 Notionの上で整理を試みて、失敗した
- 5 もう一つの課題:「見て終わり/自己チェックで流せる」
- 6 何を達成したかったのか——「中身・進捗・人」を分ける
- 7 あえて、やらなかったこと
- 8 どう解いたか①:列をやめて、行と参照にする
- 9 どう解いたか②:AIは起案まで、公開は人
- 10 どう解いたか③:完了ボタンを押す人を変えた
- 11 どう解いたか④:独り立ちテストを記述式・部分点・ランク判定にした
- 12 今どうなっているか——2つの課題は、2つとも解けた
- 13 この話を、御社の業務に移すなら
- 14 よくある質問
- 15 まとめ:整理で直らないなら、それは構造の問題
始まりは「7月1日に新入社員が入社する」という締切だった
きっかけは、技術的な思いつきでも、流行りのAI活用でもありませんでした。2026年7月1日に新入社員が入社する——それだけです。動かせない日付があり、それまでに研修資料を、古い情報と新しい情報を織り込んで整えておく必要がありました。
この時点で私たちがやろうとしていたのは、ツール開発ではありません。手持ちの研修資料の棚卸しです。当社は当時、研修カリキュラムをNotionで管理していました。項目を並べたデータベースがあり、動画はDropboxにあり、実務の手順はワークフローDBやマニュアルDBに散っている。「新人が来るから、そこを最新に直そう」——ごく普通の判断でした。
ここは強調しておきたいところです。カリキュラムはゼロではありませんでした。もともとあったのです。研修管理の効率化に悩んでいる会社の多くも、たぶん同じ状況だと思います。資料が無いのではない。あるのに、機能していない。
そして棚卸しのために中身を開いた結果、直すべきなのは中身ではなく、構造のほうだったことが分かってきます。これが、この記事の本題です。
あったのに機能しない——研修管理が壊れる2つの理由
社内で改めて課題を整理したとき、答えは2つに集約されました。研修管理の効率化を考えるうえで、この2つはほぼすべての会社に当てはまると思っています。
- 研修者本人がどこまで進んだかの把握と、上司とのやりとりで煩雑になる。誰が何をどこまで終えたのかを知るために、毎回人に聞くか、表を手で読むことになる
- カリキュラムのマスター自体が更新されず、形骸化する。作った直後は正しい。しかし業務は日々変わり、教材だけが取り残される
この2つは、根っこでつながっています。進捗の管理が重いと、その表を触ること自体が面倒になり、結果として中身の更新も止まる。逆に中身が信用できなくなると、進捗を丁寧に追う意味も薄れていく。研修資料が「あるのに機能しない」状態は、こうして完成します。
何が壊れていたのか——新人が増えるたびに「列」が増える
抽象的な話にしないために、実際に見つかったものを挙げます。棚卸しの調査で発見された構造上の問題は、大きく3つでした。
| 見つかった問題 | 実際に何が起きていたか | なぜ整理では直らないのか |
|---|---|---|
| 人名別ステータス列の増殖 | 研修資料DBの本体に「受講ステータス_◯◯」「日付_◯◯」「メモ_◯◯」を人ごとに追加して進捗を管理していた。当時すでに14人分が横に並んでいた | 新人が1人入るたびに列が3本増える。表そのものが年々重くなる=設計の問題であり、掃除では減らない |
| 研修資料DBが2系統で並走 | 正マスター側と、別系統のDBが両方生きていた。しかも正マスター側が「演習(ハンズオン)層」を欠いている | どちらが新人の正カリキュラムか確定できない。片方を消すと、必要な演習が消える |
| 幽霊リレーション列8本 | 参照先のDBが削除済みで、列名だけが残り、開いても存在しないページを指す列が8本 | 過去に手で整理した痕跡そのもの。手作業の整理が、次の負債を生んでいた |
最初の1行が最大の要因です。進捗を「人ごとの列」で持つ設計は、人数が少ないうちは非常に手軽で、実際にしばらく機能します。スプレッドシートで新人管理をしている会社なら、ほぼ同じ構造のはずです。ところが人数が増えると、次のことが同時に起きます。
- 表が横に伸び続け、誰も全体を見られなくなる
- 退職者の列を消すべきか残すべきかが、毎回議論になる
- 「今、何人が何%まで進んでいるか」を出すのに、毎回手集計が要る
- 新しい研修項目を足すとき、全員分の列に整合を取る必要がある
- 進捗を聞く側も答える側も、表を見るより口頭で確認したほうが早くなる
最後の1行が、課題①「進捗の把握と上司とのやりとりで煩雑になる」の正体です。管理表が重くなると、人は表を捨てて口頭に戻ります。そして口頭に戻った瞬間、研修の進捗は、担当者の記憶の中にしか存在しなくなります。
さらに、中身の側にも実害が出ていました。記録に残っているものを挙げます。
- 研修資料に、すでに使っていない旧ツールの記述が残存していた。社内メモにも「研修資料に旧ツールが残ると致命的」と書かれています。使っていない道具の手順を、新人が真面目に覚えてしまう
- 新規作成用のテンプレートが、2年以上放置された古いDBを埋め込んでいた。そのまま使えば、新入社員に古いカリキュラムが自動的に割り当たる
- 中身が空に近い「薄いラッパー」ページが多数あった。「30分・自習・リンクのみ」といった、実質リンク集のページです
- 戦略設計の演習群が、計測ツールの世代交代前の内容のまま陳腐化していた
- 古いページに、IDとパスワードが平文で残っていた
- 実務フロー上の抜けがあった。問い合わせ受付からアポイントまで、公開作業、納品・検収、アフター保守——ここに対応する研修項目が存在していなかった
整理すると、教材が古いという「中身の問題」と、人が増えると重くなるという「構造の問題」が、同じ場所で同時に起きていた状態です。そして私たちは、まず中身の問題として片付けようとしました。
Notionの上で整理を試みて、失敗した
ここが、この話でいちばん大事な部分です。私たちはいきなり作り始めたのではありません。まず「今あるものを整理する」ほうを選び、そしてうまくいきませんでした。
やろうとしたことは明快でした。同じ内容のデータベースが複数系統に分かれていたので、本流に一本化して重複を消し、抜け漏れと更新漏れをなくす。それだけです。もっともらしい方針ですし、実際そう考える会社は多いはずです。
ところが、整理を進めるほど手応えが悪くなっていきました。本流に寄せていくほど、その本流自体への違和感が強くなる。まとめたはずの構造が、かえって雑多になっていく。最終的に、私たちは触ったものをすべて元の状態に戻しました。数時間かけた作業を、丸ごと巻き戻したわけです。
そしてその3日後、研修ツールを独自開発するという判断に至ります。根本的に解決しようと思ったら、そのほうが早い——という結論です。
この順番には意味があります。整理で直せる問題と、整理では直せない問題があるからです。ページの内容が古いのは整理で直せます。しかし、「新人が入るたびに構造が重くなる」設計そのものは、どれだけ丁寧に片付けても直りません。片付けても、次の新人が入った瞬間に元へ戻る。私たちはそれを、実際に手を動かして確かめたことになります。
もう一つ、判断を後押しした事情がありました。会社としてNotion自体を将来解約する方向性が出ていたことです。整理して延命しても、いずれ土台ごと無くなる。この2つが同時期に重なったことが、内製に踏み切った理由です。
研修管理の効率化を検討している方に、ここだけは持ち帰っていただきたいと思います。整理してみて、元に戻したくなったなら、それは中身ではなく構造の問題です。そして構造の問題は、ツールを新しいものに乗り換えるだけでも直りません。同じ構造を、新しい画面で作り直すことになるからです。
もう一つの課題:「見て終わり/自己チェックで流せる」
構造の話と並んで、研修そのものの効き目に関わる課題がありました。社内で「見て終わり/自己チェックで流せる」問題と呼んでいたものです。
旧方式では、完了判定が本人の自己チェックでした。研修項目を開き、読み、「受講済み」を自分でチェックする。中身が空に近いテンプレートも混ざっていましたから、極端に言えば、開いてチェックするだけで進捗が100%になる。悪意の話ではありません。誠実な人でも、そういう仕組みを渡されれば流せてしまいます。
そして進捗が100%になったとき、その100%は何も証明していない。上司の側は結局、実務で当たってみるまで実力が分からない。進捗の数字が信用できないから、人に聞くしかなくなる。ここでも、課題①に戻ってきます。
この時点で、私たちが直したかったものは2つに定まりました。人が増えても重くならない構造と、意味のある完了の定義です。
何を達成したかったのか——「中身・進捗・人」を分ける
研修ハブで達成したかったことは、機能一覧ではなく設計思想の側にあります。全体のゴールは「社員を登録し、職種に応じて研修を割り当て、受講し、進捗が見え、担当者とやり取りできる。そしてコンテンツの更新は自動検知→AI起案→人の承認で回す」というものでした。
そのために置いた設計の柱が、次の5つです。
| 設計の柱 | 内容 | 解こうとした課題 |
|---|---|---|
| ①「中身・進捗・人」を分離する | 変えるのは1点。進捗を「人ごとの列」から「受講記録の行」へ。新人が増えても、行を足すだけにする | 人が増えるたびに構造が重くなる |
| ②参照方式にする | 割り当ては教材の識別子だけを保持し、本文は常にマスタの公開版を表示する。マスタを直せば、割当済みの全研修者へ自動反映 | 古いカリキュラムが割り当たる/更新が追いつかない |
| ③正本はアプリ、Notion・Slackは「入力ソース」 | 変更を検知し、AIが影響を判定して改善案を起案。管理者が承認して初めて公開される | マスターが更新されず形骸化する |
| ④完了の定義を変える | 「自己チェック」から「成果物+確認者の確認」へ | 見て終わり/自己チェックで流せる |
| ⑤テストを記述式・部分点・ランク判定に | 独り立ちテストを選択式から記述式へ。AI採点は補助で、確定は必ず人 | 「知っている」と「できる」の区別がつかない |
この中で決定的なのは①です。「中身・進捗・人」を分ける——文にすると当たり前に見えますが、旧方式ではこの3つが1つの表に同居していました。教材の情報も、誰が受けたかも、進捗も、すべて同じデータベースの上に乗っている。だから人が増えると教材の表が太り、教材を直すと進捗の側も揺れる。分けていないから、片方を触るともう片方が壊れるという状態です。
③についても補足します。「Notionを解約したい」のに、なぜNotionやSlackを入力ソースとして残したのか。理由は単純で、カリキュラムは日々の業務の中で、NotionやSlackの会話として変わっていくからです。現場の変化はそこに現れる。それを人が手で教材へ書き写す運用は、続きません。だから「変化はNotionやSlackから拾う。ただし正本はアプリ側に置く」という形にしました。正本がどちらにあるかを決めることが、この設計の肝です。
あえて、やらなかったこと
設計思想は、やったことよりもやらなかったことに出ます。研修ハブで意図的に見送った判断を挙げます。
| やらなかったこと | 理由 |
|---|---|
| Notion構造のフラット1本化 | 研修資料は研修以外の場所からも参照されている。フラット1本化は共有を壊すのでNG。シンプル化とは作り替えることではなく、掃除すること——最初の失敗から得た結論 |
| メール通知 | やり取りはアプリ内のコメントで完結させる。通知チャネルを増やすと、確認場所が分散して結局どこも見られなくなる |
| 学習形態をカテゴリ軸にすること | 自習・講義・演習・実践は「分類」ではなく完了の押し方を決める属性。カテゴリにすると意味が変わる |
| Excel取込を必須経路にすること | 既存のExcelがある職種にしか適用できなくなる。アプリ内で作成・編集できることを優先した |
| Notion同期の恒久化 | 移行期のみと最初から決めた。同期を恒久機能にすると、Notionを外せなくなる |
| 退職者データの自動削除 | 自動で消す判断は、取り返しがつかない |
いちばん効いたのは1行目です。「整理=一本化」ではなく「整理=掃除」。私たちは一本化を試して失敗しているので、これは反省から出た方針です。研修管理を効率化しようとして手が止まっている会社は、たいてい「きれいな1本の構造」を作ろうとしています。構造をきれいにすることと、運用が軽くなることは、別の話です。
どう解いたか①:列をやめて、行と参照にする
ここからは実装の話ですが、すべて上の目的に紐づく範囲だけ書きます。
目的:人が増えても重くならないこと。そのために、進捗の持ち方を根本から変えました。
| 旧(Notion運用) | 新(研修ハブ) | |
|---|---|---|
| 進捗の持ち方 | 研修資料DBに人名別の列を追加 | 受講記録の行(1行=1人×1研修項目) |
| 新人が1人増えると | 列が3本増える(ステータス/日付/メモ) | 行が増えるだけ。構造は変わらない |
| 教材の実体 | ページごとに内容を持ち、コピーが分岐していく | 割当は識別子だけを保持し、本文はマスタの公開版を表示 |
| マスタを直すと | 手で各所に反映する必要がある | 割当済みの全研修者に自動反映 |
| 進捗の集計 | 手集計 | 行を数えるだけ |
これが「中身・進捗・人を分ける」の具体形です。教材のマスタ(中身)、受講記録(進捗)、社員(人)を別々に持ち、受講記録が中身と人を参照する。たったこれだけで、14人分の列という問題は消えます。次の新人が入っても、増えるのは行だけです。
そして参照方式には、もう一つの意味があります。教材をコピーして配った瞬間に、更新は永久に追いつかなくなる。コピーは、配った数だけ古くなっていくからです。割り当てが持つのは識別子だけ、本文は常にマスタから引く——この一点で、「古いカリキュラムが新人に割り当たる」という実害を構造的に潰しています。
どう解いたか②:AIは起案まで、公開は人
目的:マスターが更新されず形骸化するのを止めること。参照方式にすれば「マスタさえ直せば全員に届く」状態にはなります。しかし、そのマスタを誰が直すのかという問題は残ります。日々変わる業務を、人が手で教材に書き写す運用は現実的ではありません。形骸化は、更新の反映先ではなく、更新の起点で起きているからです。
そこで置いたのが、更新提案の仕組みです。設計はこうなっています。
- 変更を検知する。NotionやSlack側の変化を定期的に拾う
- 影響を判定する。その変更が、どの研修項目に効くのかをAIが判定する
- 改善案を生成する。教材本文の修正案をAIが書く
- 起案する。提案として積まれる。この時点では、まだ誰にも配られていない
- 管理者が承認して、初めて公開される。
肝は5です。AIに自動反映させず、人の承認を必ず挟む。速度だけを求めるなら、4と5の間を自動化したほうが速い。それでも挟んだのは、教材が「新人が疑わずに信じる文書」だからです。
私たちはすでに、古いカリキュラムがそのまま新人へ渡る事故を実際に見ています。誰の承認も経ていない「たぶん合っている文章」が自動で配られる状態は、その事故を、速度を上げて再現するだけです。AIの利点は「案を出すコストがほぼゼロになる」ことであって、「判断が要らなくなる」ことではありません。AIは起案まで、公開は人。この線は、どの機能でも崩していません。
どう解いたか③:完了ボタンを押す人を変えた
目的:「見て終わり/自己チェックで流せる」を塞ぐこと。研修ハブでは、完了の定義を「成果物+確認者の確認」に変えました。そのうえで、誰が完了ボタンを押すかを、学習形態で分けています。
| 学習形態 | 完了ボタンを押す人 | 考え方 |
|---|---|---|
| 自習 | 本人 | 読んだかどうかは本人にしか分からない。ここを他人が押す仕組みにしても、確認コストが増えるだけ |
| 講義 | 本人 | 同上。受けた事実は本人が押せば足りる |
| 演習 | 研修担当者(本人は押さない) | 成果物がある。成果物を見た人が押さないと、完了の意味がない |
| 実践 | 研修担当者(本人は押さない) | 同上。実務で通用したかどうかは、本人には判定できない |
全部を担当者確認にしなかったのがポイントです。全部を他人確認にすると、確認が滞留して研修そのものが止まります。逆に全部を自己チェックにすると、進捗が実力を意味しなくなる。成果物が出るものだけ他人が押す——という線の引き方にしました。
あわせて、研修者と研修担当者のやり取りはアプリ内のコメントで完結させています。完了を押す判断と、その理由のやり取りが同じ場所にある。これが、課題①「上司とのやりとりで煩雑になる」への答えです。進捗を聞くために人を探す必要がなくなり、確認の会話が記録として残る。そして完了の押し手が変わったことで、進捗の数字そのものが信用できるようになる——だから、そもそも聞きに行く必要が減る、という順序です。
もし御社の研修管理から1つだけ持ち帰るとしたら、これがいちばん安く効く変更だと思います。ツールを作らなくても、今のスプレッドシートのまま「この項目のチェックは本人以外が入れる」と決めるだけで、進捗の意味が変わります。
どう解いたか④:独り立ちテストを記述式・部分点・ランク判定にした
当社には以前から、新人が単独で案件を持てるかを見る「独り立ちテスト」があり、Excelで運用されていました。研修ハブに載せるにあたって、全問を実際に確認したうえで仕様を決め直しています。
- 形式は記述式。当初は選択式を検討しましたが、実データを見て改訂しました。選択式は「知っている」ことしか測れず、「見て終わり」問題をテストの側で再現してしまう
- 採点は0/1/1.5/2の部分点制。1.5点があるのは、実務の答えが白黒で割れないからです
- 「-」は免除=満点の母数から除外。したがって満点は動的(採点対象の設問数×2)。まだ経験していない領域を0点として数えるのは、評価ではなく事故です
- 合否はしきい値ではなくランク判定。S=即単独案件可/A/B=サブ担当/C。得点率の帯はテストごとに設定でき、運用しながら調整します
- AI採点は補助。回答例と照らして点数と根拠を提案するところまでで、確定は必ず人
ランク判定にしたのは、研修のゴールが「合格」ではなく「どう配置するか」だからです。合否だけを出しても、現場は動けません。S=すぐ単独で案件を持てる、B=まずサブ担当から——という形にして初めて、テスト結果が業務の判断につながります。
ここでも設計思想は同じです。AIは案を出す。人が決める。人の評価を機械に確定させない、という一点だけは、どの機能でも崩していません。
なお、テストはアプリ内で作成・編集・複製できるようにしました。現状Excelが存在するのはディレクター職の分だけで、他職種はこれからです。Excelが無い職種を、Excelを作るところから始めさせない——独自に作る以上、アプリケーションの中で完結させたい、という判断です。
今どうなっているか——2つの課題は、2つとも解けた
先に、いちばん大事なことを書きます。数字では測っていません。研修期間が何%短くなったのか、工数が何時間減ったのか——社内を検索しても、導入効果・振り返り・短縮といった記録は1件も出てきません。リポジトリにも、開発時の記録にもありません。「◯%短縮」と書けば読み物としては締まりますが、それは事実ではないので書けません。
そのうえで、変わったことが2つあります。そしてその2つは、この記事の前半で挙げた2つの課題と、そのまま1対1で対応しています。
| 始まりにあった課題 | いま起きていること |
|---|---|
| ①研修者本人がどこまで進んだかの把握と、上司とのやりとりで煩雑になる | 研修者の進捗が見える |
| ②カリキュラムのマスター自体が更新されず、形骸化する | マニュアルの更新が自動で行き渡る |
1つ目。進捗が見えます。以前は、誰がどこまで進んだのかを知るために、本人に聞くか、上司が表を開いて人名の列を横に探すかしかありませんでした。いまは、進捗が人ではなく行として持たれているので、開けば分かります。「進捗を確認する」という仕事そのものが、やりとりではなくなった——これが、煩雑さの正体が消えたということです。
2つ目。マニュアルの更新が、自動で行き渡ります。教材の中身はアプリ側の正本に1つだけ置かれ、各研修者はそれを参照しています。だから1か所直せば、全員の教材が同時に直ります。以前のように「人数分の場所に、同じ修正を手で書き写す」作業が発生しません。カリキュラムが形骸化していたいちばんの理由は、書き手の怠慢ではなく「直すコストが人数に比例して増えていく構造」でした。そこが構造ごと外れたので、直せるようになりました。
ただし、この2つ目は「全部が自動になった」という意味ではありません。どこまでが動いていて、どこからが宿題なのか。稼働状況を、そのまま書きます。
| 項目 | 現在の状態 |
|---|---|
| アプリ本体 | 本番稼働している |
| 実運用への組み込み | 組み込まれている。社内の研修モジュール群が、完了判定を研修ハブ前提で記述するよう更新済み |
| 新人受け入れ手順 | 正式化された |
| 機能開発 | 継続中 |
| 更新提案の仕組み(中核) | コードは完成しているが、未稼働 |
| Notionからの実データ移行 | 未実行 |
| Notion解約(最終ゴール) | 到達していない |
| 定量での効果測定 | 行っていない |
下から4行目が、この表でいちばん重いところです。中核と位置づけた更新提案の仕組みは、まだ動いていません。コードは書き上がっていますが、外部連携の認証情報が未設定で、日次の検知は回っていない。「直せば全員に行き渡る」ところまでは動いていて、「直すべき箇所を、機械が先に見つけて持ってくる」ところは、まだ動いていない——というのが正確な現在地です。つまり「教材を腐らせない仕組み」は、設計として存在し、実装として存在し、しかし稼働はしていない。そして、そもそもの動機だったNotion解約にも、実データの移行が未実行のため到達していません。ここは、はっきり未達です。
誤解を招かないよう、書けそうで書けないものも明示しておきます。
- 独り立ちテストの過去の実績値は、研修ハブの成果ではありません。あれは研修ハブ導入前のExcel運用時代のデータです。ツールの効果として引用したら、嘘になります
- レベル別の研修期間の目安も、実績値ではありません。要件の側に「推定・運用しながら調整」という断り書きを、自分たちで入れてあります
成果を数字で測っていないこと自体は、褒められた話ではありません。ただ、測っていないのに測ったふりをするより、測っていないと書くほうが、読む人の役に立つと考えました。定量化は、これからの宿題です。
そのうえで、動かせない事実があります。7月1日という締切には、間に合っています。新入社員は、人名別の列が14本並んだ表ではなく、研修ハブで受け入れられました。そして始まりにあった2つの課題——進捗が見えないことと、マスターが更新されないこと——は、2つとも解けています。数字はまだありませんが、解こうとした問題が実際に解けたかどうかは、数字がなくても分かります。研修ハブについて、現時点で確実に言えるのはそこまでです。
この話を、御社の業務に移すなら
研修ハブそのものは当社の社内ツールで、販売していません。移せるのは、ツールではなく判断のほうです。研修管理の効率化に取り組むなら、次の順番で考えることをおすすめします。
- まず、整理で直るのかを確かめる。私たちは確かめて、失敗しました。この失敗には価値があります。整理してみて元に戻したくなったなら、それは中身ではなく構造の問題です
- 「人が増えると重くなる場所」を探す。人名が列になっている表、人が増えるたびにシートが増えるファイル。そこが、いつか必ず限界に来る場所です
- 進捗を「人ごとの列」から「記録の行」へ移す。これは大がかりな開発なしでもできます。スプレッドシートでも、1行=1人×1項目の形にするだけで構造は変わります
- コピーを配らず、参照させる。教材を各人にコピーして配った瞬間、更新は永久に追いつきません
- 完了を押す人を決め直す。成果物が出るものは、本人以外が押す。これが最も安く効きます
- AIは起案までにする。教材・マニュアル・手順書のような「疑われずに信じられる文書」に、AIの出力を直接反映させないでください
- やらないことを先に決める。私たちが決めたうちで、いちばん効いたのは「フラット1本化しない=シンプル化は作り替えではなく掃除」でした
そして、この構造は研修に限りません。人ごとに列が増える表、マスタが更新されずに形骸化するドキュメント、本人の自己申告だけで進む承認——この3つは、研修以外の業務にもだいたい同じ形で埋まっています。案件管理、社内マニュアル、稟議、日報。研修管理を効率化しようとして見つかった構造は、そのまま他の業務にも移せます。
よくある質問
研修管理の効率化は、まずツール導入から始めるべきですか?
いいえ。まずは今の運用を整理してみることをおすすめします。それで直るなら、それがいちばん安い。私たちは整理を試して失敗し、そこで初めて「これは構造の問題だ」と確信できました。整理の失敗は、無駄ではなく判断材料です。整理せずに作り始めていたら、同じ構造を新しい画面で作り直していた可能性が高いと思います。
スプレッドシートやNotionのままでは、なぜダメなのでしょうか?
ツールの問題ではなく、使い方の問題です。私たちの場合、致命傷は「進捗を人ごとの列で持っていた」ことでした。新人が入るたびに列が3本増え、当時すでに14人分が横に並んでいた。この持ち方をやめれば、スプレッドシートのままでもかなり延命できます。1行=1人×1研修項目にするだけです。
研修カリキュラムはあるのに機能していません。何から見直せばよいですか?
私たちも同じ状態でした。カリキュラムはありました。機能していなかっただけです。原因はたいてい2つに絞れます。①進捗の把握と上司とのやり取りが煩雑で、表を触ること自体が面倒になっている。②マスターが更新されず形骸化している。この2つは連動します。管理が重い→触らない→中身が古くなる→信用されない→さらに使われない。まず、進捗の持ち方から見直してください。そこが軽くならないと、中身の更新も続きません。
研修の完了判定を本人に任せるのは、なぜ良くないのですか?
本人が不誠実だからではありません。誠実な人でも流せてしまうからです。「読んだと言えば進む」仕組みを渡せば、進捗は必ず100%になります。そしてその100%は、何も証明しません。私たちは成果物が出る研修(演習・実践)だけ、本人ではなく研修担当者が完了ボタンを押すようにしました。逆に、自習や講義まで他人確認にすると、確認待ちで研修が止まります。全部を他人確認にしないのが要点です。
教材の更新をAIに任せてしまってはいけませんか?
更新案を作らせるのは有効です。私たちもそう設計しました。ただし公開には人の承認を必ず挟んでください。教材は、新人が疑わずに信じる文書です。誰の承認も経ていない「たぶん合っている文章」が自動で配られる状態は、古いカリキュラムが自動で割り当たる事故を、速度を上げて再現するだけです。AIは起案まで、公開は人。この線引きが要ります。
研修ハブを導入して、どれくらい効率化しましたか?
数字では測っていません。短縮率や削減時間を記録した社内資料は1件もなく、数字を出すことができません。そのうえで、変わったことが2つあります。研修者の進捗が見えるようになったことと、マニュアルの更新が、直せば全員に自動で行き渡るようになったことです。これは、始まりにあった2つの課題(進捗の把握が煩雑/マスターが更新されず形骸化)と、そのまま1対1で対応しています。ほかに言えるのは、本番稼働している/実運用に組み込まれている/新人受け入れ手順が正式化された——ここまでです。なお、変更を自動で検知して更新案を起案する仕組みはコードは完成していますが未稼働で、Notionからの実データ移行も未実行、当初の目的だったNotion解約には到達していません。定量化も、これからの宿題です。
既存の研修資料は、どこまで捨てるべきですか?
捨てる前に、他から参照されていないかを確認してください。私たちは「重複を消して本流に一本化したい」と考えて着手しましたが、最終的に「フラット1本化は共有を壊すのでNG」という結論になりました。研修資料は、たいてい研修以外の場所からも読まれています。シンプル化とは、作り替えることではなく掃除すること——これが私たちの整理でした。なお、実際に消す価値があったものもあります。参照先が消えて開けなくなった幽霊のようなリレーション列や、IDとパスワードが平文で残っていた古いページなどです。
まとめ:整理で直らないなら、それは構造の問題
研修管理の効率化は、ツールを買うところからは始まりません。私たちの場合、7月1日に新入社員が入社するという締切があり、資料を棚卸ししたら構造が壊れていて、整理を試みて元に戻し、その3日後に「作ったほうが早い」と決めた——この順番でした。カリキュラムは最初からありました。無かったのは、それを腐らせない仕組みのほうです。その仕組みを自分たちで作った結果、進捗は見えるようになり、教材の更新は直せば全員へ自動で行き渡るようになりました。数字は測っていませんが、始めに挙げた2つの課題は、2つとも解けています。
設計として持ち帰れることは3つです。①進捗を「人ごとの列」から「受講記録の行」へ移すこと。②教材はコピーを配らず参照させること。③完了ボタンを押す人を、本人から確認者へ変えること。どれも、大がかりな開発なしでも今日から試せます。そしてAIは起案まで、決めるのは人——これは研修に限らず、社内文書をAIで回すときの共通の線引きだと考えています。
私たちは、こうした判断を自社の業務で一つずつ実際に試しています。整理して直るのか、作り直すべきなのか。どこまで自動化して、どこから人が決めるのか。教科書ではなく、自分たちの業務で通ってきた道です。Web制作会社でありながら自社の業務を自分たちでDXしてきたのは、同じ発想を、お客様の業務にそのまま持ち込むためです。
「育成が属人化している」「研修資料はあるのに誰も更新していない」「人が増えるたびに管理表が重くなる」「そもそも別の業務が同じように壊れている」——そうした課題があれば、ぜひ一度ご相談ください。現状をお聞きしたうえで、御社の業務に合わせた進め方を無料でご提案します。ご相談・お見積りはこちら






