実務に必要なスキルや知識を、どう体系的に学ぶか。
ツールの活用法や機能は既存の教材で一通り学んでいたとしても、プロジェクト固有の構成やルール、エラーへの対処法などは、現場に入ってみるまで分からない、ということも少なくありません。
そうした包括的な「実務力」は、これまで現場のOJTや、経験者からの口伝えで補われてきました。しかし、OJTや口伝えだけでは、インプットできる量や幅にも限界があります。
リクルートと共創しながら、さまざまなデータプロダクトの開発を手がけるニジボックスは、この問いに、データ変換ツール「dbt」の研修を内製することで向き合いました。
カギとなったのは、徹底した現場目線。学んだことがすぐ実務に活かせるよう、研修の設計や、組み込む項目にこだわったと言います。
その背景に、一体どのような課題やニーズがあったのでしょうか。研修を設計した村上広樹さんと、レビュアーであり先行受講者でもある佐藤未来さんに聞きました。
村上 広樹（むらかみ・ひろき）
ニジボックス データエンジニアリング室 BIエンジニアリング2グループ
dbt研修の設計・作成、研修環境の構築をメインで担当する。
佐藤 未来（さとう・みらい）
ニジボックス データエンジニアリング室 BIエンジニアリング2グループ グループリーダー
さまざまなプロジェクトに参画しつつ、チームのタスク調整や組織体制づくりを担う。dbt研修では設計ミーティングに参加し、先行受講者としてフィードバックも行った。
※この記事は株式会社ニジボックスによるタイアップ広告です。
外部の教材はある中でも、内製にこだわった理由
── 村上さんは前回の記事で、dbtを活用したプロジェクトのエピソードを紹介しながら、dbtの知識を他のメンバーにも伝えていきたい、と話していました。あれから、ご自身が関わるプロジェクトでdbtを使う場面は増えていますか？
村上 増えていますね。もともとは試験的にテストや複雑な実装で使うツールだったのが、今は、全部ではないですけど、dbtを使って基本的に開発するようになってきています。
佐藤 量というより「触る範囲」が広がった感じがします。これまでは担当範囲を区切ることで対応できていましたが、コアな部分を触る機会が増えてきた印象です。
── もはや「dbtの使い方を知らないと仕事の手が止まってしまう」レベルにまでなってきていると。とはいえ、dbtについての教材は外部に多数存在する中、わざわざ研修を内製した理由は何だったのでしょうか？
村上 1つは、既存の教材は汎用的につくられているぶん、私たちの現場要件に照らすと過不足が生じ、組織としてのベースラインをそろえにくいこと。もう1つは、既存の教材はどうしてもインプット中心になっていて、実践重視のスタンスを打ち出しづらい＝実務で利活用しづらい側面があることです。
── なるほど。メンバー間で技術や知識レベルをそろえる、あとは実践性にフォーカスするということですね。たしかにこの辺りは、既存の教材がカバーしきれていない要素かもしれません。
村上 そうですね。特に実践性は強く意識していて、中でもプロジェクトの中では必ずと言っていいほど必要になるデバッグの項目を重視しました。ゼロからdbtの機能をインプットする教材では、トラブルシューティングに関する技術や知識が扱われないことも少なくありませんから。
── トラブルシューティングは体系的に学ぶのが難しく、経験者から口伝えで教わることが多い領域ですよね。そういう基準を設けたということは、やはり村上さんご自身も、困った経験があったのでしょうか？
村上 ありました。実務においては、エラーを修正していく力があらゆる局面で必要になりますが、私自身、以前はそこが全然追いつかなくて。
その経験から、エラーログや、コンパイルされたクエリのような中間生成物を見に行くところこそ手を動かして学んだほうがいい、と感じました。
だから、研修内容もベースは公式教材のチュートリアルなどを採用しつつ、実践形式の問題をハンズオンで解いて、レビューを受けるスタイルにしています。
「何を教えて、何を教えないか」をどう決めたか
── 研修の具体的な内容についても掘り下げたいのですが、まずはdbt認定試験のシラバスを参照しながら「どの項目を入れるか」を洗い出したそうですね。
村上 そうですね。シラバスを読むだけでなく、チュートリアルを受けたり、技術系の記事を見たりしながら洗い出しました。
── 先ほどデバッグを重視するというお話もありましたが、どのような観点で仕分けたのでしょうか？
村上 まず、初級はどの教材でも扱われている「最大公約数的」なものを網羅することを意識しました。
そのうえで、既存の教材では扱われないけど、実務で「これは必要だな」と思ったもの。たとえば、先ほどのトラブルシューティングに関する項目をはじめ、コマンドやコマンドの実行オプションなどを追加していく流れです。
初級のゴールは、既存のプロジェクトに入って基本的な作業をこなせて、なおかつ「困らない」こと。システム構築の初期で必要なコマンドは、既存プロジェクトに参画する段階では使わないので中級以上のレベルに回しました。
中級は基本項目を一通りおさえて新規プロジェクトの立ち上げまでをカバーできるレベル。開発の効率化に資する機能のうち、プロジェクトに与えるインパクトが特に大きかったり、すでに現場で使っていたり、今後現場で使う可能性が高かったりする項目を入れています。
そして上級は、dbtの認定資格が取れるレベルを想定しています。上級まで進んだ人が、そのままdbt公式の認定資格を取得する、といった流れも今後はつくっていきたいですね。
── 佐藤さんもdbt研修の設計に参加していたんですよね。
佐藤 はい。ただ、私の役割はどちらかというと、村上さんが中級として設定した項目を初級に振り分け直すといったものが中心でした。「これは現場で必要でしょ」と。
あとは先行受講者として、メンバーの顔を想像しながら「この文章の順番だと、中身が頭に入ってこないんじゃないか」「この通りにやるとエラーが起きる」といった、詰まりそうなポイントを的確にフィードバックする。
それだけでなく、各フェーズで出す提出物の定義が曖昧になっていないか、という運用面の改善も意識しました。
ちなみに研修の内容は私だけでなく、別の案件に入っているマネジャーや、担当領域が異なるグループリーダーなど、さまざまなメンバーの視点を入れながら内容をブラッシュアップしています。
── 「現場目線」が徹底されているわけですね。最後までどの級に配置するか迷った項目はありましたか？
村上 データモデリングのレイヤリングです。ディメンショナルモデリングをはじめとしたレイヤー戦略の話は抽象的になりやすいので、最初は中級に入れようとしていたんです。しかし既存のプロジェクトにおいては、レイヤー戦略に沿ってディレクトリ構成やファイルの置き場所が決まっているため初級に入れるという結論に達しました。
実務そのままを再現するという「割り切り」
── 初級から中級、中級から上級へ昇格するにあたっては、それぞれ実務でぶつかりやすい課題を解くフローが設定されていると伺いました。課題の数は初級で20〜30本、上級まで完成すれば100本程度で「100本ノック」形式になっているとか。
村上 入社時に「SQLノック」という実践形式の研修を受けたんです。問題を解くためには調べたり、手を動かしたりしなければならない、実務に直結するタイプの研修で。これを参考につくりました。
── 「実務でぶつかりやすい課題」というのは、たとえば？
村上 わざとSQLにエラーを仕込んだ上で、「コンパイル済みのSQLから原因を特定せよ」といった実践的なものが多いですね。
── 研修の「環境」にもこだわったと伺いました。
村上 実務で使っているデータウェアハウスと同じBigQueryの環境を実際に用意して、データを加工するところまでできるようにしています。
佐藤 受講者の立場でも、そうして自前のBigQueryの環境が用意されているところは非常に良いと感じました。
データの置き場も、アウトプットの置き場も明確で、かつ実際のプロジェクトと似たような環境が整えられている。実務ではツールもプラットフォームも運用ルールが決まっているので、研修もそれを踏襲して受けられます。また、成果物を提出してレビューを受けることは、プルリクエストを出してレビューをもらう通常の開発と同じスタイルです。本当の意味で実践形式になっているわけです。誰かが決めたというより、ニジボックスの既存の研修がそのスタイルなのを、本研修も自然と受け継いでいる感じです。
村上 だからこそ、今後は機能を「使い方」だけで教えるのではなく、「使いどころ」まで学べるよう研修の内容をブラッシュアップしたいですね。たとえば、大規模なデータや定期更新されるデータに用いられる機能も多く扱う中級以降では、それぞれの機能に合ったデータをセットで用意し、どの場面で使うのかまで一緒に身につけてもらうようにできればと。
── 佐藤さんは受講者側として、既存プロジェクトに新しく入る人は、dbtのどんなところにつまずきやすいと思いますか？
佐藤 1つは「コマンドの違いが分からないこと」です。手順書の通りに実行はできるけど、似たコマンドと何が違うのかよく分かっていない。
あとは、全体の流れです。どの順番でフローが動いているかを知らないと、どこに後続の影響を及ぼすかが分からない。dbtは便利であるがゆえに、何が起こっているか分からないケースも多いので、研修はそこが分かるようなつくりになっていると思いました。
── 既存の研修との違いや、今回のdbt研修を受講して感じた効果について教えてください。
佐藤 既存の研修って、1つの研修内でフォーマットがバラバラなことがあったりします。ある章ではUdemyを見なさい、違う章ではこのスライドを見なさい、みたいなのが多かったり（笑）。一方で今回のdbt研修は、環境構築の仕方から演習問題まで1箇所にまとまっていて、あちこち見に行く必要がありませんでした。
また私自身も、このdbt研修で体系的・実践的な知識を固められたので、メンバーからエラーの相談を受けたときもより良い説明やアドバイスができるようになっている気がします。
dbt未経験の中途入社の方でも、研修を受けたら、ある程度共通言語で会話できるようになると思います。この研修を受けるか受けないかで、現場への馴染みやすさが全然違ってきそうですし、「研修で体系的かつ実践的にdbtを学べた」ことがキャリアにも良い影響を及ぼすのではないでしょうか。
「みんなを同じレベルにする」のではない、ベースラインの哲学
── ここまで研修の設計プロセスや設計思想について伺ってきましたが、改めて、実務で活用できる研修を設計・運用するうえで、大切なことは何だと思いますか？
村上 受講者が「全体感」を得られるよう設計することでしょうか。そもそもdbtで何ができるのか、プロジェクトの全体構成はどうなっているのか。こうしたことを網羅して初めて、実務への利活用がイメージできるように思います。
佐藤 受講者にどうなっていてほしいかのゴールが定まっており、ゴールを目指すための「教科書的インプット」と「実務に近い環境で手を動かす実践」のバランスを最適化することが、設計のカギだと思います。
── OJTや勉強会ではなく研修という形式も重要なのでしょうか？
村上 そうですね。OJTは実践的な反面、目の前のタスクに閉じやすい。研修で全体像をそろえておくことで、OJTがより効果的な状態をつくれると思っています。
── 研修という形式であれば、当初の課題感だった「知識や技術のベースラインをそろえる」ことにも寄与しそうですよね。
村上 はい。ただ、このベースラインをそろえるとは決して「メンバー全員を等しく同じレベルにする」ということではありません。各領域に特化したデータエンジニアを育てる上で「最低限ここまでは全員できるようになっていてほしい」という目線を合わせる意図が強いんです。
私たちにとってdbtが実務で欠かせない技術になっている以上、「皆がここまでできるようにしよう」という明確な基準を設け、仕組みとして整えなければならない。そのために最も適していたのが研修というフォーマットだった、ということです。
株式会社ニジボックスではデータ領域に携わるエンジニアを募集中！
データエンジニアの成長を力強く支援する環境や仕組みが用意されています。興味がわいた方は👇気軽にクリック！
[タイアップ広告] 企画・制作：はてな
取材・文：青山祐輔
撮影：是枝右恭
