🍊

DATA Saberトレーニングを2社合同でやった話

に公開
Tableau
DATA Saber
idea

はじめに

こんにちは。Rakutenでデータエンジニアをやっています。世の中には，DATA SaberプログラムというTableauを使った短期集中型データ人材育成プログラム(のようなものと周囲の人に説明したりしています)がありまして。

本来このプログラムでは，「学びたい人(Apprenticeと呼ばれます)」が「すでにそのプログラムを履修した人(師匠と呼ばれます)」に弟子入りする形，つまりマンツーマンで行なうのですが，それを，2社合同で，かつ，師匠十数人と弟子数十人の団体で一斉に行なったイベントの顛末を，ここでは紹介します。

自分はその全体のリード役として，担当のアサイン・名簿管理・進捗確認・対師匠グループおよび対弟子グループへの連絡，などを行ないました。

同様のイベントでいうと，DATA Saber Bridgeがたびたび開催されております。残念ながら自分はTrain the Trainerに参加できなかったのでイベントに参加はしておらず，そこで学べるような部分でつまずいているかもしれないなと思いますが，いい経験になったので，ここでは時系列順に，何をやったか，どういう反省点があったか，その記録を残そうと思います。

イベント概要

  • 開催時期: 2025年3月から6月にかけて
  • 参加者: トータル97名
    • Apprentice: 75名
    • 師匠: 22名(弟子を取らないサポート師匠を除くと19名)
  • 認定者数: 57名認定(認定率76%)
  • 連絡手段: Slack。補助としてTeams, Viber
  • 技術講義: Zoom。補助としてTeams
  • 資料共有: Box。

発端

今回自分がリードしたのは第2期。第1期は弊社のOnishiさんと御社のAnzaiさんとがTableau Conference2024にいったときの酒の席でやることが決まり，2024年7月〜9月で行ないました。それが好評で2回目もやろうということになり，それをなんやかんやあってリードすることになりました。

そのお二人のTwitter(現X)のアカウントを掲載しておきます。

https://x.com/AnzaiMariko

https://x.com/Smile_Mac_Smile

第1期にも師匠として参加していたのですが，そこでの課題として感じていたのが，資料共有のばらつき，参加者名簿(メールアドレスやステータスなど)の管理，だったので，リードするならそのあたりを改善したいと思いながら進めました。

スケジュール

Apprentice Apply前からいろいろ活動をしてきたので，時期を小分けにして，その時期にどういったことをやったか，ということを箇条書きの一段目に書き連ねています。理由や目的などは二段目以降です。

結局どのタイミングで何をやったのか，そして振り返って何をやるべきか，文字だけだとイメージがつきにくかったので，Tableauのガントチャートで表すことにしました。こちらも見ながら下記をご参照いただけますと幸いです。

saber_schedule_datawash

https://public.tableau.com/views/saber_schedule_datawash/DATASaberSchedule-dat-a-wash?:language=en-US&:sid=&:redirect=auth&:display_count=n&:origin=viz_share_link

Apprentice Apply前

総評

結局ここでもっと準備すべきだったなと反省。 90日始まると準備している余裕がないので，師匠陣の意識合わせ・弟子側のApplyに必要なものの準備・師匠と弟子の顔合わせ(連絡手段の構築)など，事前にきちんとやっておくのが吉でした。意識合わせ、というのは、たとえばどのレベルのコミュニティポイントを点数として承認するか、という部分などです。団体で行なうならほぼマストだと思います，承認基準がぶれると不公平感にも繋がるので。

Apply3週前〜2週前

  • Apprentice参加者にはWaiting Listに名前を記載してもらい，全体Kickoffまでに意思を確認していきました。
    • 目的;完走率を高めるため。時間が取られるプログラムですがその覚悟はありますか？みたいな。
  • 参加いただく師匠が集まったあと，いくつかのサポートポジションを作成して，分業制にしました。
    • 理由;師匠とApprentice合わせて100名ほどの規模になりそうで，1人ではイベント運営をしきれないと思ったので。
    • 具体例;ポジションは下記のとおり
      • 「技術講義の構成を考えるチーム(講義チーム)」に師匠22名中3名。
      • 「コミュニティポイントの取り方をはじめにレクチャーするチーム(コミュニティポイントチーム)」に師匠22名中3名。
      • そのほか，Apprenticeを弟子に取らないサポート師匠3名。
  • イベント開催に関する広報をもっとやるべきだったと反省。
    • 理由: 参加表明を締め切ったあとから参加したいという人が来てくれたことだったり，Slack/Boxへの招待が一部できていなかったりで，余分なコミュニケーションが増えてしまったため。
    • ただし，参加師匠の人数に対して多いApprenticeの人数を募集するのも考え物(今回ひとりの師匠あたり4,5人のApprenticeをみるようにしました)。広報は行なうが，参加してもらう人数規模は慎重に決めたいですね。とくに弟子を初めて受け持つという師匠がいるなら尚のこと。
    • 余談ですが、飲み会の場とか社内のメールとか，思わぬ形でこの活動を知ってくれて， 経営層へのプレゼン資料にTableauが使用されるようになったりしました。 なので，ここの広報でいろんな部門に情報を投げておくのは偶発的な成果につながるなと思いました。

Apply2週前〜1週前

  • 師匠1に対して弟子2-5名の組とし，それを3-4組ずつにして1チームとする，チーム制にしました。
    • 目的;2社合同で行なうので，師匠と弟子のマッチングは参加者が所属する組織がなるべくバランスよく，なるべく会社をまたいだ組み合わせになるようにしました。メリットとしては横のつながりができたこと，デメリットとしては連絡が滞るケースがたびたびあったこと，です。
      • DATA Saber Bridgeでも同様のケースが発生していると聞くので，この組み合わせのしかたは人を選んだほうがよいかもしれないです。(割り振りに時間はかかるが)
    • 反省点;半強制的に師匠を割り振ったので，師匠とApprenticeの間の関係性が希薄なまま始まってしまったなと思いました。のちに講義への参加率が低減していったのも，プログラムは運営サイドでやってもらうものだという意識を芽生えさせたためかもと思っています。まだ目の行き届く数の会社間でやっているので，Apprenticeに師匠を選んでもらって弟子入りするパターンも次回は試すべきかもしれません。
  • オンライン上で参加者リストを作成し，氏名やTwitterアカウントなどをすべて一元的に管理するようにしました。
    • 理由;あとからApprenticeのTwitterアカウントとか会社用アドレスを失念するリスクを避けるため。
    • 感想;これはやってよかった(と思いたい)。このファイルを見れば連絡先やTwitterアカウントをすぐ辿れるため。また漢字の読みとか案外すぐ忘れてしまうので、備忘録も兼ねられる一元化がおすすめです。

Apply直前

  • 全体Kickoffミーティングと懇親会の場所を決めました。
    • 反省点;正直もっと早くてよかったです。1か月前とかでもいい。
  • この時期にもっと事前準備に時間を割くべきであったと反省。
    • 理由;90日のプログラム始まってもTwitterが運用できていないとかSlackチャンネルに入れていないなど，問題が山積していたため。

Apprentice Apply後

総評

全体Kickoffミーティングをオフラインの会議室(プラスオンライン)で行ないました。またここで師匠と弟子のマッチングを発表しましたが，上にも書いたとおり事前に行なうべきだったと反省。

90日でのプログラム中にここは守りたい・気をつけたいという点を書き連ねます。そのあと，それぞれの時期に行なったことを書いていきます。

  • 師匠陣MTGはやるべき。
    • 理由;トレーニングを団体で行なう際は弟子側のメリットが大きいとおもったが，じつは師匠側もお互いに良い意見が聞けたり発信できるのでメリットがある。具体的には，担当する弟子からの(とくにコミュニティポイントに関する)質問の返し方を相談できる。細かい認定方法のずれ(イベント開催とDocter開催の違い，分析案件の報告先MGRなど)もすり合わせられる。
    • 後述しますが，会社間をまたいだ師匠と弟子のコミュニケーションは滞りがち。とくに普段使わないチャットツールを使っているのなら尚更。なので師匠同士ぐらいは密に連携しましょう。
  • 団体でトレーニングをやる意味をよく考えるべき。また活かすべき。
    • チーム制をどう活かすか，横同士ののつながりをどう強くしていくか。これを解決するのが日々のコミュニケーションだと思います。まずは手始めに，直近の活動状況を承認してあげることができたら(見ているよという暗示も兼ねられるので)いい。普段の話題にもなるし
    • データを提供して，Vizを作り合って共有する「もくもく会」は良いイベントであった。
      • 理由;居合わせた師匠が共有されたVizに対してフィードバックを行なうと，そのアドバイスが形式知として参加者に行き渡る。使用してもらうデータも複数準備すると良い。Apprenticeが興味のあるデータを触ろうと自主選択するのが大事
  • コミュニケーションは滅多に自発的に起こらない。なので最初は積極的にこちらから動きましょう。
    • これが運用でカバーというか，ツールや仕組みで低コストにできたら素晴らしい。本プログラムでは改善しないといけないポイントとなった。
      • Teamsチャンネルなどを作っても最初はコミュニケーションは動かない。実態は，実際に手を動かしてコミュニティポイントを取ろうとしたところや講義が難しくなってくるところから。
  • Apprenticeへ行動規範を示すのは言わずもがな。しかし師匠側も行動規範を持とう。
    • まずApprentice側の行動規範について。
      • 強く言えば問題行動が見られた。具体的には，コミュニティポイント申請時に師匠に申告しない，サンプルスーパーストアだけで6つViz投稿してパブリックポイントを申請する，太古のForumに・かつAIで出力されたような没個性な言葉で回答する，など。
      • 師匠もいち人間で，Apprenticeの活動をレビューするのに時間がかかることを理解する。またリスペクトをもつ。
    • そして師匠側の行動規範について。
      • 情報連携は密に行なうこと。
        • 5-6週間経った頃，師匠陣MTGも集まりが悪かった。MTGに参加できないのはしかたないが，そのぶん別の場で情報共有は行なうべき。Apprenticeの動きをちゃんと追えていますか，とか。
        • Apprenticeの状況，とくに全体講義への参加もOrdeal提出もしていないApprenticeが10%ほどいて，彼ら彼女らの状況を見失いがち。実は連絡がつかなくて…という状況であったと後から分かったこともあった。情報が共有されないと取れる対策も取れない。
      • 師匠側の立ち位置を揃えること。
        • たとえばApprenticeから拙いVizを提出されたときに，どういうフィードバックを送ってやれるか。3つのVizをまとめて出すというのが横行するが，そういうときどうApprenticeに是正させるか。クオリティに満たない活動を申請される土岐，きちんとはじいてあげる必要がある。
        • 師事した師匠のせいでDATA Saberになれませんでした，という状況は避けたい。
    • このあたりの行動規範は本プログラムの第3期をやることがあれば，そのタイミングで作ろうと思うので，その際に記事にでもしてみようかな。
  • 師匠陣とApprentice陣が必ず全員集まる場を月1回は準備するべき。
    • 情報共有のためはもちろん，Apprentice自身に「Saberトレーニングに参加している」という自覚をもってもらうため。
    • 情報共有はたとえば，「最終試験受験の流れ」「コミュニティポイント申請時のグッドマナーとバッドマナー」「師匠vsApprenticeのコミュニケーションのグッドマナーとバッドマナー」「技術共有」など。
    • 「Saberトレーニングに参加している」という自覚については，たとえば毎週Ordealに関する講義を開催していても，自分で動画をみるから参加しなくていいと思っているApprenticeが少なからずいて，そういった人たちにとっては団体でやる意義を見失いかねないため，必須参加のイベントを設ける必要があるのかなと思ったことがきっかけです。

0週間〜2週間経過ごろ

  • Apprentice登録でまだつまずいてるひとがちらほらいて，そのフォローをやっていました。
    • 具体例;登録Twitterアカウントが間違っていたり，また作成したTwitterアカウントがさっそく凍結されたり規制くらったり。
    • 注意点;Saber HP上のダッシュボードではApprentice登録時から90日後が締め切りと表示されることです。 同スケジュールによる一斉受験で行なう場合，期日は一斉登録日から90日を死守することを今回は徹底しました。 それが，一斉登録日にちゃんと登録してくれた人からの不公平感を招かない方法なのかなと思いました。
  • Ord1-10に関する講義を進めていきました。
    • 体制;講義を担当する師匠(たち)と，スケジュールや中身のチェックなど管理を行なう講義チーム，という形でした。
      • 不測の事態に対応できるように，各講義を担当する師匠はメインとサブとしたいと思っています。 片方がトラブルに見舞われても，もう片方がバックアップで時間通りに講義できるためです。
        • 余談としてこれを思った経緯を書いておくのですが，講義担当者が講義直前になってZoomトラブルで講義に参加できないという事態が発生しました。対応としてカジュアルVizつくりまShowという基礎版Workout WednesdayでTableau技術を復習してもらう回にし，復旧後TeamsでMTGを開始しました。裏で対応方法を連絡しあう手段をもっておいて良かったと心から思いました。
    • 具体的な流れ;
      • 1週前の技術講義の数日前に，次週担当者にご都合がよいか，講義内容について疑問点ないかを確認する
      • 1週前の技術講義で次回講義の日程などをアナウンスする
      • 技術講義の2日前に，オンライン上に資料格納してもらって，講義チームで確認します。誤字脱字，技術的に間違っていないかの確認を行ない，講義担当者にフィードバックしました。
      • 1日前に講義内容のすり合わせ。毎週設定していたのは1時間ほどですが，時間が余ってしまうようならグループディスカッションを加えたりするようにしました。せっかく団体で研修を行うので，お互いの視点や考えを共有して，学習の質を高めることを目指しました。
    • 感想;各講義の1週間前に，その講義の担当者と講義チームとで連絡を取り合い，そもそも都合に変更ないか・講義の中で何を話す予定か，を聞いておくようにしたら，スムーズに進行できました。
    • 反省; 途中に実施したアンケートで，「技術講義がKT動画の範疇を逸していないため出る理由がよくわからない」というフィードバックを受けました。 たしかにこれは最もだと思ったので，当時の解決策として質問箱を開設しました。KT動画で提供できていない情報をなんとか提供できるようにしたいという意図です。途中から作ったので一桁しか集まりませんでしたが，最初から作っておけばもっと増えたのかもしれません。
  • プログラム内のある師匠が行なっていた，Ord提出に対する承認コメントがApprenticeのモチベーション管理にとてもよいなと思ったので，記録と出力を開始。
    • これについては別記事に詳述します。

3週間〜4週間経過ごろ

  • Apprentice全員に，1ヶ月経過アンケートを取ることにしました。
    • 理由;ちょうど技術講義が10個中5個終わって，日数としても1ヶ月が経過して，これまでの講義参加状況をZoomのReport機能をつかって出力すると，技術講義の参加率が二極化してきていたため
    • 結果;回答率自体が30%以下と低い結果に終わりました。改善のアイデアとしては，DATA Saberプログラム自体には含まれていないが一斉受験プログラム上では必須の条件にすることが考えられます。個人的には，Saberになる以上，Apprenticeたちには自主的に一斉受験プログラムに臨んでほしいという思いがあります。
    • 別記事に，ZoomのReport機能の使い方や，当時管理のために使っていたダッシュボードを掲載します。

5週間〜6週間経過ごろ

  • 最終試験の受験方法として，一斉受験枠と個別受験枠を設けることにして，日程を師匠内で確定させたのち，Apprenticeたちへ共有しました。
    • 理由;早々とSaberプログラムを終わらせたい人がいたので
    • 一斉受験枠は，業務時間内外のそれぞれから候補を出しました。時期はおよそラスト3週の各週それぞれ2,3枠ずつ。
    • 個別受験枠は，Ordealもコミュニティポイントも早く修了したApprenticeや，一斉受験枠での受験が難しいApprentice向けの枠。ここは従来通り師匠と弟子の1on1で決めてもらい，必要なら他師匠がサポートする形にしました。
  • 1.5ヶ月が経って折り返しになろうというタイミングで，OrdealをすべてPassしている人が10%ほど。うち，コミュニティポイントも取り終わっている人は20%ほど，つまり2,3%程度。
  • ちらほらApprenticeによるTwitter投稿が増え始めました。
    • 感想;やはり必要に駆られないと活用は難しいです。またTwitterでのApprentice同士の交流はとどのつまりほとんどなかったです。
    • 当時使っていたTwitterタグはこちらです。

https://x.com/hashtag/DATASabeRAdventure?src=hashtag_click&f=live

7週間〜8週間経過ごろ

  • 卒業式の会議室予約のためにある程度の日程を決めました。具体的にはプログラム終了から2週間先の平日あたり。

9週間〜90日経過まで

  • 最終試験や口頭試問が立て続くこの時期の注意点が2点あります。これらに対する釘刺しを，全員必須参加のMTGで共有したいなと振り返って思いました。
    • 参加者全員が，Apprenticeから師匠への連絡，そして師匠からApprenticeへの連絡が時折遅くなることに敏感になってくる ことです。通常業務を行なっている以上，連絡が1日つかないことは往々にしてあることだと思いますが，期限が迫ってその余裕がなくなり，リスペクトの欠けた発言が出ている場面をいくつも見かけました。
    • Ord提出やコミュニティポイント申請の終盤の駆け込みが多くなってくること です。それに応じて， コミュニティの活性化につながらないような活動を申請してくることが増えます 。Saberに合格することでなく，コミュニティに求められる活動を心がけるようApprenticeに伝え，師匠側もきちんとスクリーニングするようにしましょう。
      • 具体的には，Community Forumへの投稿を粗雑なもので済ましたり，Tableau Publicへの投稿をサンプルスーパーストアですべて済ましたり，というものが見られました。

結局何が言いたかったかをAIにまとめてもらった

＞ 筆者が伝えたいことは以下の通りです。

  • 事前準備の徹底: Apprentice開始前の準備（師匠陣との意識合わせ、Apprenticeの準備、顔合わせ）と広報活動は、90日間のプログラムを円滑に進める上で極めて重要。
  • 運営体制の構築: 大規模なプログラムでは分業制が必須。師匠とApprenticeのマッチングは慎重に行い、関係性構築に配慮すべき。参加者情報の一元管理も重要。
  • 師匠陣の連携強化: 師匠陣MTGを定期的に開催し、情報共有、承認基準のすり合わせ、相互サポートを行うことで、師匠自身のメリットも大きく、プログラム全体の質が向上する。
  • 団体トレーニングの意義活用: チーム制や「もくもく会」などを通じて横のつながりを強化し、フィードバックによる学習効果を高めるべき。
  • 積極的なコミュニケーション: コミュニケーションは自発的に起こりにくいため、運営側から積極的に働きかけ、促進する仕組みが必要。
  • 行動規範の明確化: Apprenticeだけでなく、師匠側も行動規範を持ち、相互のリスペクトを基盤とした活動を促すべき。質の低い活動は適切に是正する必要がある。
  • 定期的な全体集会の実施: 月1回程度の全体集会は、情報共有とApprenticeの「参加意識」を維持するために不可欠。
  • プログラム中の柔軟な対応: 講義内容へのフィードバックを受けて改善したり、不測の事態に備えて担当者を複数配置するなど、柔軟な運用体制が求められる。
  • 終盤の駆け込み対応: プログラム終盤に発生しがちな、連絡遅延や質の低い申請への対応策を事前に講じ、参加者全員に注意喚起を行うべき。

だそうです。

おわりに

終わってみてもう少し準備に時間を増やせばよかったなとか，Slack承認やApprentice ApplyでのFAQなどを充実させればよかった，とは思うものの，方向修正をうまくやりつつ，人にも動いてもらって支えてもらいつつ終えられたと思いました。あらためて参加者みなさんに感謝を申し上げたいと思います。有難うございました。

また，自分の言葉が読んでくださるあなたにどこか刺さっていたら，喜ばしい限りです。

余談

現在，弊社Rakutenではモバイルの社員紹介キャンペーンを実施しております。
下記リンクから，Rakuten会員でログインいただくと，回線変更で最大14,000ポイントがもらえるので，ご興味ある方はぜひアクセスしてみてください！

https://r10.to/hNCoik

Discussion