本記事はQiitaのデータに関する記事を書こう！イベント用の記事となります。
記事概要
最近社内でデータの民主化を促進するための評価制度が絡んだ非エンジニアの方向けのSQL試験の仕組みが入り、3か月程度経過したので導入されたものや経過などを記事にまとめておきます。
概要的にまとめておくと、
- 今まではデータやSQLなどに抵抗の無い方は普通に分析などでSQLなどを使われていました。
- しかし社内の多くの非エンジニアの方（ゲームプランナーの方など）はそこまで複雑な分析のSQLなどに慣れていない方が多い形になっていました（ライトなSQLなどは多くの方が書ける一方で）。
- そこでデータの民主化を一層推進するために社内のBIツール上にSQL試験を受けられるようにし、評価の一部でもその試験結果が参照されるようになりました。
- 「どういった意見が出るだろうか」「どのくらい受け入れられるだろうか」といった点が不安でしたが、結果としてはポジティブな意見を結構いただきつつもネガティブな意見は今の所来ておらず、且つ思っていたよりもぐぐっとSQLを触られる方が増える形となりました（思っていたよりも大分効果がありました）。
以降の節ではそれぞれ細かく触れていきます。
※以前この辺りのSQL試験に絡んだものは記事にしてOKと上長（役員の方）やSQL試験制度の推進を担当されていらっしゃった方から許可をいただいています。
※ゲーム業界の話なのでゲームプランナーさん達を主な対象とした記事となっていますが、他の業界では営業の方とかによるBIツール利用や分析文化の普及が中々進まない・・・といったようなケースで差し替えてお読みいただけますと幸いです。
※ポエム成分や他の会社などでは微妙な（合わない）ケースの話を色々と含みます。既にデータの民主化などが進んでいる会社様ではまったく役に立たない記事になります。苦手な方や賛同できない方など様々だと思いますのでそういった場合にはご容赦（もしくはブラウザバック）いただけますと幸いです（豆腐メンタルなのではてブコメントなどでの強めのマサカリなどもお控えいただけますと幸いです）。
ことのきっかけ
以前から弊社社内では分析をしたりデータを扱える方が限られているという問題がありました。
その辺りに抵抗が無い方がSQLやBIツール、Python、R、エクセルなどで分析や数字を追ったりしている一方で多くのプランナーさん達はあまり分析用にSQLなどに触らない・・・という状態です。
会社からも「SQLの勉強をして分析などがやれるようになるとプラスになるので本とかで勉強していきましょう！」といった形でアピールしても日々皆さん忙しく普段の仕事をさせているので中々しっかりとしたデータの民主化が進みません。
一方で分析や施策の実施、施策結果のデータチェックなどは現場の方の方がやりやすいケースが多くあります。施策実行は専任のデータアナリストの方よりも現場の方の方が色々と通すのがスムーズなこともありますし、プロジェクトごとのドメイン知識も現場の方の方がしっかりしています。出来れば多くの現場の方が自分達で施策を決めて、自分達でデータを追って、自分達で分析して次に繋げる・・・形が理想です（ドメイン知識が浅いと数字の違和感を見落としがちでミスもしやすいというのもあります）。
また、データ関係の専任のメンバーに頼る（データエンジニアに頻繁にデータ抽出や集計などを依頼するなどの）形だと依頼が集中したりといった問題もあり、専任のメンバーは社内でごく少人数の一方でそれ以外のプランナーの方達は大勢いらっしゃる・・・という状況を考えるとバランスが良いとは言えません。
できれば現場の皆さんが気軽にデータ分析などをできるように分析用のSQLなどを身に付け機動力を高くし、且つ専任メンバーの負担を減らすために必要になった場合のみ専任の方に依頼などを投げる・・・という形が理想です。
そのためには一部の人が「データの扱いにがっつり精通している」状態を推進するよりも「普段エンジニアリングやSQLなどにあまり馴染みの無い多くの人で、全社的にデータを扱うスキルの底上げを行う」形を推進したいという状態になっていました。
どのように推進するか
※私は評価制度には直接は携わっておらずシステム側の対応が主で、役員の方やデータ活用を推進されていらっしゃる方・人事の方の間で色々進んでいたようですが見聞きした点など触れておきます。
評価制度に関しては評価制度を整えていった方々の間で色々な事例や書籍などを参考にされていたとは思いますが、チャット上のやりとりなどを眺めていた感じ以下の書籍が参考本として目立っていました。「現場の方々が幅広く自分達分析できるようにする」「試験結果を評価制度を組み込む」辺りが今回のSQL試験と
「ワークマンは 商品を変えずに売り方を変えただけで なぜ2倍売れたのか」
また、試験は（あまり実装に時間をかけない形で）内製でなるべく楽ができるようにシステム化しています（手動での採点や受験状況の集計などはやりたくなく、問題データ設定やチェックなども楽をしたかったため。この辺は後の節で詳しく触れます）。
ただ研修を入れただけでは中々身に付かなかったり研修を受けて終わり・・・となってしまうため、以下のような点に留意して進められています。
- 評価制度に試験の合否状況が組み込まれたため、高い評価を得ていくにはSQL試験を合格することが必須となりました（もちろんSQL試験だけでなく他の試験や実際の成果など多くの点から評価されます。この辺はワークマンさんの本を参考にしています）。評価に絡まないと中々普段の仕事に忙殺されていると習得が進みにくい（人による）印象なので、全社的に底上げしたい場合にはやはり評価制度を絡ませるのが強く作用するという印象です（実際に大分効果が数字として出ています）。
- 競プロ的に「自身でSQLを書く」 → 「すぐにエラーや正解・不正解のフィードバックを得られる」という形にして、対象の方が大量に実際にSQLを書いて学んでいく・・・という形になっています。
また、「これを学んでも仕事に活きるのか・・・？」といった疑問が出てくると試験に抵抗感が出てくると思われたため、なるべく現場に近い形になるように以下の点が工夫されています。
- 社内の各ゲームプロジェクトでの横断のデータ基盤・横断のBIツール上で追加されました。これによって使われる技術やサービス・UIなどは実務に非常に近くなり、試験でUIに慣れればそのままBIツールも慣れ親しむことができるという形になっています。
- MySQL・PostgreSQL・BigQuery・Redshift・Athenaなど様々なDBがあるわけですが、SQLの書籍だとMySQL（or PostgreSQL）だけで実際の仕事ではAthenaになっていて方言やUDF、細かい挙動の違いなどが気になる・・・といったことがなく直接仕事で使うものがSQL試験で使われています。
- 実際のゲームプロジェクトのログなどを流用して試験用のDBを用意したりしています。そのため試験で触るログが実務からあまり乖離していません。
- 実際に普段現場でがっつり分析やデータを扱ったりなどされている方が推進担当となっており、試験問題などもその方が作成されています。現場に近い試験問題になっていると言えます。
なるべく自身で手を動かしていくことの重要性
コードの写経だったり、写経して慣れてきた後に自分で考えて手を動かして何か作ったりするとプログラミングが身に付きやすいのと同様、SQLなどに関しても自分で手を動かして書いて実行してみて、そしてすぐにフィードバックが得られると身に付きやすいと思っています。講習などをただ聞いているだけでは中々分析用のSQLなどは身に付かないという所感です。とにかく手を動かして何度も何度も書いたり修正したり実行したり・・・を繰り返していけると効果的かなと。
そういった意味ではSQL試験では自身でSQLを書いて実行しないといけないという点、実行してすぐにSQLエラーが見れたり正解・不正解のフィードバックが得られるというのは学習目的では中々良いのではと思われます。
試験では何度も再受験できるようになっている
前述の通りSQLを身に付けるためにとにかくたくさんSQLを自身で書いて実行してもらうのが大切・・・という点を踏まえ、SQL試験では「1度の受験で合格できなくともデメリットは無い」という形になっています（試験の問題は再受験時にランダムで出題されたりするので毎回問題が変わったりはします）。
実施期間中に何度でも再受験できますし少ない回数で合格できた方も多くの受験回数で合格できた方も評価面としては変わりありません。会社として大切なのは「多くの方が分析などでSQLを書けるようにする」という点であり、個人の受験回数は会社に取っては重要ではありません。
それよりもSQLに不慣れな方がたくさんSQLを書いて慣れるといったことの方が大切であり、それに即した評価制度になっています。
特に再受験などしてもデメリットも無いため、日々少しずつ細切れ時間などに受験して慣れて段々と合格に近づける・・・といった対応もできるようになっています。日々の業務で忙しい方も多いためこの辺も再受験でデメリットは発生しないという仕様は良かったのではと思っています。
試験とは別に事前に体系立てて学んでおくための練習問題も追加された
SQL試験とは別に試験と同じUI・ほぼ同じ挙動で事前に体系立てて学ぶためのSQLの練習問題も設けました。
こちらは試験とは別で答案例のSQLをユーザー操作によって見れるようになっています。また、解説記事などもある程度設けてあります。
BIツール上に試験や練習問題なども組まれたので勉強の際に自分でDB環境などを組まなくてもOKになった
分析のSQL本などはどうしても自前でDBとテーブルを用意したりインストールしたり、クラウドのアカウントを用意したりデータを入れたり・・・と最初の方に作業する必要があります。
一方で今回の対応で推進したかった方々はエンジニア以外且つSQLやエンジニアリングなどが不慣れな方々が対象であり、この辺の最初の作業がネックになりがちです（本などでの勉強を推奨しても中々進めていただくのが難しい）。
人によってはその辺はエンジニアでなくとも余裕・・・という方も結構いらっしゃるとは思いますがこの辺は人によります。
今回は横断で使われているBIツール上にSQL試験や練習問題などのUIや機能が追加となりました。普段SQLでの分析などをされていない方でもBI上のダッシュボードは確認されている方が多く、アカウントなどはそのまま使用できますしDBなどの準備も不要ですぐに勉強用として触り始めることができるようになりました。
横断のBIツール上で実際にプロジェクトのログデータを参照していく際にも非エンジニアの方がDBを構築しなければいけない・・・ということはなくすぐに触り始めることができるようになっていますので、構築などに苦戦して時間をかけたりするのは皆さんの負担増となるためこの辺は楽で良いかなと思います。
利用の推進のための定期的な試験合格状況の通知の実施
SQL試験は初級・中級・上級と各試験が設けられたのですが、2週間ごとなどにSQL試験などによるSQL実行回数や各試験の合格者数などをチャット上で（合格者の個人名などは出さない形で）許可をいただいて公開（通知）するようにしました。
ゲームでも他のユーザーのランキングなどの数字が見れた方がモチベ的に盛り上がる・・・といったことが多くあると思いますが、同様にSQL試験でも「こんなにたくさんの回数のSQLが実行されている」「他の人の多くが何だか合格していっている」ということが分かった方が興味を持っていただけたり触り始めたりしていただけそうな気がしていたため通知などをしています。「皆やっているっぽいので私もやろう」といったモチベも生まれるかなとも思っています。
社内の方向けなのでABテスト的に人によって通知を行う / 行わないといったことはできず通知による効果測定などはやれていませんが、利用ログや合格率などを見ていた感じ通知対応による効果はあったのでは・・・という雰囲気はあります（確実に効果があったと明言することはできませんが・・・）。
SQL実行時のエラーメッセージはなるべく日本語のものが表示されるようにしている
SQL試験に限った話ではなく横断のBI環境で以前から進めていたことなのですが、SQL実行時のエラーメッセージは英語の元のメッセージだけでなく日本語のメッセージも出すようにしました。
弊社の場合現場の各プロジェクトも横断のデータ基盤なども統一してAWSが使用されています（管理の煩雑さやデータの送信の手間やコスト、海外展開など色々な理由があると思いますが基本的にマルチクラウドは一部を除いて避ける形となっています。最近は中国にどのみちゲームがほぼ出せなくなってきているので海外展開はどこのクラウドもそんなに変わらない感じにはなってきている感じもありますが・・・）。
そうなってくるとログに対するSQLの実行はAWS内のAthenaやRedshiftなどになってくるわけですが、例えばAthenaだとエラーメッセージは英語のみです。内部で使われているPresto的にも日本語のサポートは今後も恐らくは無いだろう・・・という印象です。仮に日本語サポートが入ったとしても（特にAWSなどの機械翻訳によるドキュメントなどだと顕著ですが）日本語のメッセージが分かりづらいままかもしれません。
エンジニア以外の方にどんどん普及していって欲しい・・・という点を考えると、こういった時の英語の分かりづらいエラーメッセージはあまり良くありません。そのためSQL試験も含め横断基盤上のBIツールでは日本語のエラーメッセージが出るようにしてなるべく短時間でSQLの問題点を修正できるようにしています。
また、単純に日本語のメッセージを出すだけでなく、「SQLのどこが間違っているのかのハイライトを行う」「元の英語のメッセージではエラーの理由が分かりづらい場合は色々発生原因などの説明を丁寧に加える」「どうすれば解決するのか、どのようなSQLの調整が必要かなどの解決策の説明も加える」といったようにしています。
昔のCEDECでその辺の日本語のUI・メッセージは大切・・・といったこともセッションでお聞きしたような記憶がありますし（別の勉強会とかだったかもしれません）、実際に上級試験まで合格された一部の方に感想などを聞いて見たところやはり元々のエラーメッセージは分かりづらく解決に苦戦している時が結構あったので丁寧な日本語のメッセージが表示されるのはとても助かったといったご意見をいただいたのでUX的にも案外馬鹿にできません。
実装としてはユーザーのSQL実行によるエラーメッセージとSQL内容をログとして保存しておいて、もし日本語のエラーメッセージの正規表現によるマッチするマッピング設定があれば日本語のメッセージもBIツールのUI上に一緒に表示するようにしています。
最初から全てはカバーできないのでマッチする日本語のマッピング設定がなければデータ基盤担当に日次でチャットに飛んでくるようになっており、検知した時点でマメにマッピング設定を追加する・・・としてきました。
日々の積み重ねでじわりじわりとマッピング量が多くなり最近は大体の日でマッピングのカバレッジが100％付近で落ち着いています。
弊社では内製したものの、こういったサービスやプラットフォームなどがあっても（あった方が）良いかもしれない
弊社の場合上場しているので少人数のスタートアップやベンチャーなどよりかは人的リソースなどがあった点、社内の非エンジニアの方も大勢いらっしゃるので効果が大きい点、細かいUXなどまで追求していける点、既にBI上にUIや機能などをさくっと追加できるように整備されていた（実装に対して工数がかからない）点、私一人でシステムをあまり時間をかけずに作れそうだった点、ゲーム業界の傾向として1つのゲームでも開発数年・運用5年以上くらいになるケースは多く、且つそれらのプロジェクトの横断のデータ基盤・BIとなると基盤もかなり寿命が長くなってきているため（内製しても長いこと使われて元が取れるため）今回は内製となりました。
一方でこの辺は極力内製するべきではない・・・というのも正しいと思っていますし、そこにリソースを割くのであれば他の製品自体などに力を割くべきというのも正しいと思います（特に会社の人数が少なくどんどん製品のアップデートやリリースなどをする必要がある場合などは顕著に）。社内用のもので内製となるとどうしてもトラックナンバーが低くなりがちというデメリットもあります。
弊社でも内製すべきか？外部の研修などをやるくらいで済ませるべきか？といった議論が入り2名の方から内製すべきではないのでは？という意見をいただいたりもしています（これも正しい意見かと思います）。最終的には役員の方から内製の方向でのGoサインが出た点とこの辺のデータの民主化推進担当の方（現場でもディレクター的に上の立場でお仕事をされている方）の判断で内製する形に落ち着いています。
「ダッシュボード整備したけどろくに見られなくなってきた」とか「データ基盤（もしくはツールやBIなど）整備したけどデータの民主化が思ったように進まない」といったケースは世の中にぼちぼちあると思いますし且つ内製は大変なケースが多いと思いますので、このようなことを考えるとデータの民主化推進のためのサービス・プラットフォームがあっても良いのでは？とは少し思います。
前述までに触れた点を踏まえて以下のようなサービスとかだと良いかもと感じています。
- 評価制度などと絡ませやすいように管理者もしくは人事の方などによる合格情報の閲覧などができる。
- 業界ごとにログは様々なので業界ごとに合わせたログをベースとした試験にする。
- ※実務のログと乖離しすぎていて利用者から「これ実務に役立つのか？」と思わせないようにするため。
- 同様の理由で試験問題もなるべく業界ごとの実際の分析をベースとしたものにする。
- DBやテーブルの準備などはせずともすぐに使えるようにする。
- BigQueryやAthena、Redshift、MySQL、PostgreSQLなど選べるようにする。
- ※なるべく実務と近づける（試験で身に付けたものが実務に活かしやすい）形で実務で使うものと挙動や使える関数などがずれないようにするため。
- SQLの問題点やエラーメッセージなどは分かりやすい日本語などを設定してUXを良くしておく。
- 試験で使うもの（BigQueryやAthenaなど）での使えるキーワードや関数などの日本語の一覧資料などもあるとより良い。
- ※後の節で詳しく触れますが、追加してみたら社内で結構評判が良かったのと利用もぼちぼち多かったです。
本記事がdelikaさんのイベント用の記事ということもありdelikaさんのことも今回興味を持って紹介記事なども拝見していたのですが、以下のような方向性ということで将来データの民主化を推進するためにこの辺のものがdelikaさん上で整備が進んだりすると良いかもしれませんね（業界ごとのデータとかは集めるのはどうするのが良いのだろう？とかは難しい所が色々あるかもしれませんが・・・実際のデータそのまま触れるのがベストではありますが、その辺を整えるのが厳しい場合は実際のデータを参考に、学習用になるべく近い形のダミーデータを作るとかは良いかもしれませんね）。
DXの実現、AI開発を目的に外部データの需要が拡大しデータ活用におけるコストや人材不足が課題になってきております。
そのため「データの民主化」実現のための社会的インフラが必要になってきております。
...
delikaはデータ版「GitHub」を目指して開発されたデータ共有プラットフォームです。
データの収集や分析もオープンな場で行うことで、より効率良く新たな価値創出につながると考え開発されました。
もしくはData Engineering Studyとかの勉強会でお馴染みのtroccoさんとかにこの辺のデータの民主化推進のものが乗っても良い（役に立つ）のかもと少し思います（データ基盤整備後の次のステップとしてのデータの民主化として）。
実施してみた結果、思っていたよりもしっかり活用いただけて且つポジティブな意見などをいただいた
SQL試験機能の運用をスタートしてからまだ約3か月くらいではありますが、1日中BI上でSQLが流れ続けているといったような日も珍しくなくなってきましたし、リリース前のプロジェクトでかなり追われていて「SQL試験はまだ先で良いよ」となっているプロジェクトなどを除くと前半の試験は少なくとも7割くらいの人が合格されている方が出てきています（上級まで一通り合格された方も後回しでOKとなっているプロジェクトを除くと4割くらいの方は合格されているかなと）。
勿論世の中にはもっと遥かにデータ活用（民主化）が進んでいる会社も多々ありまだまだ道半ばではありますが試験運用前と比べると大分利用が伸びています（想定していたよりもぐっと伸びてくれました）。
上級試験まで合格されているされている方にヒアリングなどもある程度してみましたが、「大変勉強になった」「実務にかなり活かせそう」「とても使いやすい」「売れそう（社内だけで使うのがもったいない）」といったご意見をいただき、懸念していたネガティブな意見などは今の所私の方には来ていません（もしかしたら私が把握していないところで役員の方や人事の方へはネガティブな意見なども少しは出ているのかもしれませんが・・・）。
組んで実際に運用してみるまでは「内製ってどうなんだ・・・」という気持ちはありましたが結果を見てみれば（データの民主化の面で大分苦戦して色々試行錯誤していたというのもあり）対応して良かったなと現在は強く感じています。
少なくとも「外部研修導入してみたけどこれ効果あるの？」とはならずにしっかりと数字や感想として効果が出てきている印象です。
テーブル構造などの（メタデータの）資料の連携をしっかりとした
こちらもSQL試験のみの機能というわけではありませんが、ログなどのテーブルの構造資料や注意点、テーブルの統計値などのいわゆるデータ基盤におけるメタデータ関係とBIの連携をしっかりさせているのですが、こちらもSQL試験を消化された方に感想をお聞きしたところ大分好印象な意見をいただきました。
メタデータの資料はBIツール上で確認できる（追加のドキュメントサービスなどのアカウントを要求したりすることなく）ようにしたり、SQL編集中にリアルタイム気味に参照している各テーブルの概要の説明が同じ画面に表示されるようにしたりそのテーブルへの構造資料のページへのリンクを表示するようにしたり等しています（Sphinxを使っているのですがこの辺はコードと色々連携できたりがさくっとできてSphinx楽しいです）。
メタデータ自体が信頼できないと良くないのでずれないようにこの辺の資料出力・同期は自動化して実際のテーブルの内容とずれないようにするといった処理も加えてあります。SQL試験で言えば回答で必要な参照テーブルなどは資料へのリンクが自動で設定される・・・といったことをしてあります。
これらの資料が頻繁にアクセスされているのを実際に見ていると、この辺の資料をしっかりする＆アクセスしやすいようにする等のUX面は地味にエンジニア以外の方へのSQLの普及を進めるには大切なのでは・・・という感じがしています。
SQLキーワードや関数などの資料を整備した
MySQLなどと比べてログ分析などで主に使うAthenaなどで標準SQLから外れるものなどの差は結構あり、MySQLなどは普段から触っていて馴染みのある方でもAthenaなどは馴染みの無い方が大半で、そういった方から「その辺の差の把握が大変」という以前を利用者の方からいただきました。
また、AthenaはPrestoがベースになっていることからAthena + Prestoのドキュメントを読み込んでいく必要があります。AthenaはまだしもPrestoは基本的に英語のドキュメントとなります。エンジニアの私にとってもPrestoのドキュメントに目を通しただけでは理解が及ばず、色々動かして理解できる・・・という点も結構ありました（特に普段使わない関数など）。
その辺りを加味してAthenaで使えるキーワードと関数の説明と使い方例の一覧の資料を追加しています。追加してみたところ好印象のフィードバックを複数いただいたり実際の結構参照されている点を踏まえると結構効果があったのではという印象です。
それらの対応のためにまずは自身がAthenaなどで使えるキーワードや関数などを全体的に把握しておく必要があるため以前一通りQiitaにシリーズ記事としてまとめたりしています（この辺にまとめたものは少なくとも資料上に反映されるようになっています）。
例 :
また、普段からVS Codeなどで作業していると関数などに変数やマウスオーバーや呼び出しなどした際に詳細が表示される・・・という機能を活用されている方が多いと思いますが、それと同じようなことがBIツールのSQL編集画面上でされるようにしてあります（追加したSphinxでの資料とこの辺りの機能が同期されるようにしています）。
SQLの関数の引数などは（特に普段あまり使わない特殊な関数などは）よく内容を忘れたりするので、引数情報なども確認できて作って整備した私自身も普段のSQL操作などで助かっています。
標準SQLがベースになっているとしても発展的なSQLを書こうとするとBigQueryやRedshift、Athena、MySQL、PostgreSQL間などで色々差がある点、新しい機能もそれぞれでアップデートとして日々追加されていっている点、それらを調べるのをエンジニア以外の方に任せるというのも結構現場の方の負担となったり障壁となったりしますので（手間は結構かかりますが）整備しておくというのも良かったと思います。
ただしこの辺も自前で整備すると勉強にはなりますが大変なのでdelikaさんとかが各サービスごとにまとめられていらっしゃると楽なのではという所感が（以下略）
データ基盤・BIツール自体も利用ログを細かく取って継続的に改善をしていっている
今回のSQL試験機能もそうですが、社内のデータ基盤・BI上でも（社内利用とはいえ）通常のプロジェクトと同じように利用ログなどを細かくとったり実際に感想などをヒアリングして少しずつ改善していったりしています。
データ基盤は分析するための環境なので、そもそもそれ自体も「隗より始めよ」的に分析対象にして継続的に改善していってもいいのかなと思います。
弊社のケースですがデータ基盤のチームは社内の少人数で回している都合、裁量も多くいただいていますし機能を内製する際も色々試行錯誤することができます。
機能を内製する際にはUIデザインをしたりなるべくUXが良くなるように配慮したり（この辺は元デザインの学校出身だったり以前デザイナーやゲームのクライアントエンジニアでUIの操作感などはこだわっていたのでしっかりしたい）、フロントエンド・バックエンド・必要なクラウド関係と器用貧乏に自分でやっていく形となっているため、職種間の連携などもあまり気にせずに自分で判断して分析・実装・調整・ログ追加・・・とすることができます（もちろん専門の方々と比べると知識も技術も器用貧乏的になっていて足りていませんが）。
たとえば通常のプロジェクトではプランナーさんが出した案をプロデューサーなりディレクターの方がOKを出して、それをバックエンドの方とフロントエンドの方でログが保存されたりしてようやく分析・・・となるケースが多めですが、これがデータ基盤であれば自分の判断で追加が必要と思われるログの追加を決めてその日の内にフロントとバックエンドなどを調整してデプロイして分析も自分でやる・・・みたいなことが可能です。ある意味データ基盤・BIツール・データの民主化の推進などは改善施策が実行しやすいですし改善のしがいがあると言えるかもしれません（改善しないケースも多く難しい面も多々ありますが・・・）。
すんなりとデータの民主化が進む会社ではそこまで色々頑張らなくても良いかもしれませんが、弊社のようにデータの民主化に苦戦している場合には基盤やBI自体も色々ログを取って分析や調整・検証し続けるようにしてみても面白いかもしれません。
SQL試験用に組んだシステムの内容
最後に、以降の節では今回対応したSQL試験機能についていただいた要件（どんな機能を追加したのか）といったところを大雑把に記載しておきます。あまり面白い話でも無いと思いますので不要な方は読むのを割愛ください。
なお、対応は要件を決めたり試験問題を作成される方（データの民主化を推進されている方）1名とシステム側は私の1名の2人での対応とあります。
なるべくシステム側は既存の仕組みやクラウド・ライブラリの機能などを活用して工数を節約する形で進めたため、最初にいただいた一通りの要件を組むのにシステム側はテストコードを書いたりコードドキュメントを書いたりなど含め8人日くらいでした（その後は都度フィードバックをいただいて調整や機能追加などを対応する形にしています）。大分工数節約のための工夫などは頑張った感じがあります。
一通り動くようになるまでシステム側はそこまで工数はかかっていない（そこまで会社に対して負担になっていない）ので、内製するという判断面でもそこまで躊躇しなかったというのもあるかもしれません（作ってみてもしデータの民主化的に皆さんに刺さらなければ他の施策を考えれば良いかなと）。
※本記事で触れる内容は将来随時更新・調整されていきます。
試験用のDBの準備
まず試験用のデータですが、実際のログに近いものが良いものの実際のログを参照する形だと（そういったケースは少ないですが）ある日ログに対して修正が加わったりすると試験側も影響が出てしまうため新しく試験や研修用のDBを用意する形で、そちらへ試験で必要な期間の実際のログなどをコピーしたりして対応しています。
問題によっては実際のデータに似せて作ったダミーデータなども使用しています。
試験や練習問題の一覧表示画面
試験や練習問題の一覧画面に関してはシンプルに受けられるものの一覧や難易度ごとのフィルタリング、各試験の設問数や合格に必要な正解数、現在の自分の合否状況などを表示しています。
試験の受験・再受験
一覧画面で任意の試験を受験し始めると各設問で登録されている問題がランダムに出題されたり試験の残り時間のカウントがスタートするようにしてあります。練習問題側は特に残り時間などは設定されません。今の所基本的に試験の残り時間は2時間程度で設定されているようです。
時間内に必要とされる正解数を満たした場合その試験は合格となります。
前節までで触れた通り時間内で合格できなくとも特にデメリットは無く何度でも再受験することができます（問題はランダム出題なので毎回変わったりはします）。皆さん何度も何度も受験して合格となっています（基本的にストレートでは合格されている方は稀な感じの難易度となっています）。
また、自身で正解した問題の解答をメモしておいて、もし将来同じ問題に遭遇した場合はその解答を使用するのはOKという会社のルールとなっていました(ただし他の人と答えを共有するのはNG)。
SQL関係をネットで調べるのもOKとなっています（実務では基本的にネットのある環境で仕事をするのでそれに合わせた形となります）。
これはそもそもその自力で調べたり何度も何度もSQLを実行して答えまで辿り着いていれば元々会社がSQL試験制度の目的としていた「幅広い人にSQLやBIに慣れ親しんでもらう」「自分でSQLを書いてなるべく自分でデータ分析などができるようにする」という点はカバーできるためこのようになっています。試験自体を実務になるべく近づけるという点も試験中に検索などは行ってOKという点に絡んでいます。
再受験はできるので残り時間制御の機能は要るのか？という議論もありましたが残り時間表示がされていた方が集中して着手できる・・・といったような意見をいただいて残り時間を設ける形に試験はなっています。
練習問題の解答例の表示と解説へのリンク
練習問題に関しては解答例を自由に見ることができます。解答例には解説資料へのリンクなども表示されるようになっています。
これは学校の勉強の問題集などと似たような感じでしょうか。自分で最初解いてみて、解けなければ解答や解説などを見るといった使い方ができるようになっています。
回答入力画面
回答入力画面は通常のBIのSQL入力の画面をベースとしています（試験でUIなどに慣れてそのままプロジェクトのログに対してもSQLで分析などが出来るようにするためと工数削減のため）。
加えて問題文（抽出対象や必要な集計内容の指定）や参照が必要なテーブル（及びそのテーブルへの構造資料へのリンク）、SQL結果で必要なカラム名と型の表示、必要なORDER BYの指定などが記載されています。
入力内容の採点
入力したSQLをそのまま実行して採点を行うことができ、通常のSQLと同じようにSQL結果の表示をすることができます。もし問題文で提示されていた内容を満たしていたら正解判定、満たしていなければ不正解判定となります。
正解となる判定
事前に解答例として登録されていた結果と回答のSQL結果の内容が一致していれば正解判定となります。行の順番なども一致している必要があります。
Athenaの場合ORDER BYを指定しないとSQL実行の度に順番が変わってしまうのでその辺りのORDER BYの必要な指定は問題文のところに明記される形になっています。
カラムの順番などは問われません（解答例の設定とずれていても正解となります）。また、結果のカラム名の大文字小文字などもどちらでも受け付けるようにしてあります。もちろんSQL内容が解答例と異なっていても結果が一致していれば正解となります（SQL内容が異なっていても問題文で指定された必要な内容を満たせば正解となります）。
競プロとかに少し雰囲気が近いかもしれません（AtCoderなどはやったことがないのであまりその辺には本記事では触れません）。
採点結果の不正解位置やカラムの過不足などの表示
SQL実行後に不正解だった場合には、カラムの過不足が発生していればそれは実行結果の画面に表示するようにしています（そもそも必要なカラム情報は回答入力画面で明記されているため）。
また、不一致になっている行部分も赤く表示されるようになっています（不一致行部分で実際に必要な値自体は公開されません）。これは不一致部分がまったく公開されないとどこが間違っているのかが分かりづらく正解になるまで非常に時間がかかりすぎる・・・という意見を踏まえて不一致部分は公開する形にしています。
また、解答のデータの行数が多い場合不一致行を探すのが大変な時があります（結果が数万行くらいで、途中の一部の行だけ合っていない場合など）。そういった時のために不一致行のみを抽出する機能も設けてあります。
試験データ設定の管理画面
管理者（試験データなどを設定される方）向けのための機能となります。
主に試験の各データ、設問の各データ、問題の各データ設定の管理画面の3つ用意してあります。
設問のデータは試験のデータに紐づけ、問題のデータは設問のデータに紐づける形になっています。1つの設問に対して複数の問題データが指定できるようになっており、実際の受験時には各設問内に設定されている問題のリストからランダムに出題されるようになっています。
各データには問題文の設定や参照が必要なテーブルの指定や説明、ORDER BYの指定、解答例などを設定できます。設定ミスを防ぐために入力内容と解答例のSQLなど相互に複数の点でのチェックが保存時にされるようになっています。
解答例のSQLの自動実行と答案データの自動保存
入力した解答例のSQLは保存後自動実行され、結果は解答データとして保存されます。この保存されたデータを参照して試験時の入力されたSQL結果との比較が行われます。実行結果のデータを参照して解答で必要なカラム名や型情報などは自動で算出されるようになっています。
※微妙にORDER BYの指定が一部足りておらず実行の度に行の順番が変わってしまう・・・ということが発生していると解答で中々正解しないという問題が発生するため、複数回解答例のSQLが実行され結果が変動しないことなどがチェックされるようになっています。
日々の受験状況・合格状況・SQL実行状況などのチャットへの通知やデータのダウンロードなど
こちらも管理者の方向けに作った形になりますが、改善に役立てたりするために日々のSQL実行状況や合格状況の変動値などは管理者の方など一部の方のみが居るチャットへ日々通知されるようにしてあります（とりあえず今の所はダッシュボードを作るほどでもないかなと）。
また、評価用に受験状況などのデータがダウンロードできる形にしてあります（良くあるCSVダウンロード的に）。
終わりに
長々と書きましたが社内のデータ基盤の改善やデータ活用の促進はまだまだ身に半ばです。整備や環境・文化などは一日にしてならず・・・と腰を据えて今後も長期的に色々試したりしていこうと思います（やりたいこと・やった方がよいこと・改善できそうなところ・試してみたいことは無限にあります）。
今回のSQL試験機能の導入は改善の一環で大分効果が出てくれた感じで良かったですが、「良い取り組みだね！」「頑張ったじゃん」などと思われた方はこっそりLGTMとか押してくださると喜びます・・・！（マイノリティな感じの対応なのでほとんどの方には刺さらない記事だとは思っていますが、どなたか1人くらいには刺さると良いなと思っています）