<p>こんにちは、クラッソーネでアプリケーションエンジニアをしている<a href="https://twitter.com/saiid_kk" target="_blank" rel="nofollow noopener noreferrer">菅野</a>です。<br />
もう年末なので今年をふりかえってみると、世界最高の古楽アンサンブルグループである<a href="http://www.allegromusic.co.jp/Artists.html" target="_blank" rel="nofollow noopener noreferrer">タリススコラーズの東京公演</a>が今年はスキップされてしまったことが地味に残念でした。隔年で毎回行っていたのですが、ここまでコロナウィルスの影響が続くとは思いもよりませんでした。2023には無事開催されることを願ってます。</p>
<p>今回は全社的なデータの利活用の推進を目的に、知識ゼロから学んでいく初心者向けのSQL勉強会をやり始めた話について紹介していきたいと思います。</p>
<h2 id="%E5%BD%93%E6%99%82%E3%81%AE%E7%8A%B6%E6%B3%81%E3%83%BB%E8%83%8C%E6%99%AF"><a class="header-anchor-link" href="#%E5%BD%93%E6%99%82%E3%81%AE%E7%8A%B6%E6%B3%81%E3%83%BB%E8%83%8C%E6%99%AF" aria-hidden="true"></a> 当時の状況・背景</h2>
<p>弊社では、私がジョインする前から全社的にOSSの<a href="https://www.metabase.com/" target="_blank" rel="nofollow noopener noreferrer">Metabase</a>がBIツールとして活用されていて、開発部門以外でもある程度SQLを使いこなせる方が存在している状態でした。<br />
(事業の本格的なデジタルシフトが直近2~3年程度であることを考えると、この点は非常に素晴らしいことだと入社時に感じていました)</p>
<p>とはいえSQLを利用して自在にデータを参照できるメンバーは全体からすると非常に限定的で、その限られた方々に各部署からの取得依頼が集中しているという状況になっていました。</p>
<p>また私が直近関わっている新規事業の立ち上げ、新規プロダクトの開発に関しては、セールスやCS部門をはじめいわゆる「プロダクトの開発」自体が初めてという方も多く、サービスを開発・改善していくというゴールに向かって諸々のコンテクストを揃えていく必要に駆られていました。</p>
<h2 id="sql%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%A8%E3%81%84%E3%81%86%E5%8F%96%E3%82%8A%E7%B5%84%E3%81%BF%E3%81%AE%E4%BC%81%E7%94%BB"><a class="header-anchor-link" href="#sql%E5%8B%89%E5%BC%B7%E4%BC%9A%E3%81%A8%E3%81%84%E3%81%86%E5%8F%96%E3%82%8A%E7%B5%84%E3%81%BF%E3%81%AE%E4%BC%81%E7%94%BB" aria-hidden="true"></a> SQL勉強会という取り組みの企画</h2>
<p>そんな状況の中、ひとりでも多くの方がデータに対する解像度を高めて、かつ実際に業務活用していけるように、知識ゼロからSQLを学んでいける場としてこの勉強会をスタートさせました。</p>
<p>業務片手間の個人プロジェクトではありますが、以下その企図と経過を含めてあらましを記述していきます。</p>
<h3 id="%E7%9B%AE%E7%9A%84"><a class="header-anchor-link" href="#%E7%9B%AE%E7%9A%84" aria-hidden="true"></a> 目的</h3>
<p>当初から以下の3点を明確にゴールとして定めていました。</p>
<h4 id="1.-%E3%82%BB%E3%83%BC%E3%83%AB%E3%82%B9%E3%82%84%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%83%BC%E3%82%B5%E3%82%AF%E3%82%BB%E3%82%B9%E3%81%AE%E4%BA%BA%E3%82%82%E3%80%81%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AA%E5%86%85%E5%AE%B9%E3%81%A7%E3%81%82%E3%82%8C%E3%81%B0%E5%88%86%E6%9E%90%E3%82%AF%E3%82%A8%E3%83%AA%E3%82%92%E8%87%AA%E5%BC%81%E3%81%A7%E3%81%8D%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%AA%E3%82%8B"><a class="header-anchor-link" href="#1.-%E3%82%BB%E3%83%BC%E3%83%AB%E3%82%B9%E3%82%84%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%83%BC%E3%82%B5%E3%82%AF%E3%82%BB%E3%82%B9%E3%81%AE%E4%BA%BA%E3%82%82%E3%80%81%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%81%AA%E5%86%85%E5%AE%B9%E3%81%A7%E3%81%82%E3%82%8C%E3%81%B0%E5%88%86%E6%9E%90%E3%82%AF%E3%82%A8%E3%83%AA%E3%82%92%E8%87%AA%E5%BC%81%E3%81%A7%E3%81%8D%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%AA%E3%82%8B" aria-hidden="true"></a> 1. セールスやカスタマーサクセスの人も、シンプルな内容であれば分析クエリを自弁できるようになる</h4>
<p>こちらが第一義的な目的で、クエリ依頼の偏在が解消されるとともに、<br />
全社の視点で見てもSQLを多少なりとも扱えるクルーが増えることはデータリテラシーの底上げに寄与しそうです。</p>
<p>またこのゴールを念頭に、SQLの細かい構文やデータベースの仕組みなどにはあまり言及せず、あくまでデータの利用者として「大掴みにデータ・SQLを概観できる」という点を重視することにしています。</p>
<h4 id="2.-%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%81%AE%E3%82%B3%E3%82%A2%E3%81%A8%E3%81%AA%E3%82%8B%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E6%A7%8B%E9%80%A0%E3%82%84%E3%82%AB%E3%83%A9%E3%83%A0%E5%AE%9A%E7%BE%A9%E3%81%AA%E3%81%A9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%80%81%E5%85%A8%E4%BD%93%E3%81%AB%E5%A4%A7%E6%9E%A0%E3%81%AE%E5%86%85%E5%AE%B9%E3%81%8C%E5%85%B1%E6%9C%89%E3%81%95%E3%82%8C%E3%82%8B"><a class="header-anchor-link" href="#2.-%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%81%AE%E3%82%B3%E3%82%A2%E3%81%A8%E3%81%AA%E3%82%8B%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E6%A7%8B%E9%80%A0%E3%82%84%E3%82%AB%E3%83%A9%E3%83%A0%E5%AE%9A%E7%BE%A9%E3%81%AA%E3%81%A9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%80%81%E5%85%A8%E4%BD%93%E3%81%AB%E5%A4%A7%E6%9E%A0%E3%81%AE%E5%86%85%E5%AE%B9%E3%81%8C%E5%85%B1%E6%9C%89%E3%81%95%E3%82%8C%E3%82%8B" aria-hidden="true"></a> 2. プロダクトのコアとなるテーブル構造やカラム定義などについて、全体に大枠の内容が共有される</h4>
<p>こちらは統合的なDWHがまだ存在しないことに起因するのですが、<br />
分析のためにはアプリケーション都合のデータ構造やその背景などにある程度知悉する必要がありました。<br />
(特にプロダクトが<a href="https://www.slideshare.net/kawasima/ss-40471672" target="_blank" rel="nofollow noopener noreferrer">イミュータブルなデータモデル</a>を基本方針に設計されているため、その点は重点的なインプットが必要となりそうです。)</p>
<h4 id="3.-%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E9%96%8B%E7%99%BA%E3%81%8C%E8%A1%8C%E3%81%88%E3%81%AA%E3%81%84%E3%80%81%E3%81%BE%E3%81%9F%E3%82%AD%E3%83%A3%E3%83%83%E3%83%81%E3%82%A2%E3%83%83%E3%83%97%E3%81%8C%E5%BF%85%E8%A6%81%E3%81%AA%E9%96%8B%E7%99%BA%E3%83%A1%E3%83%B3%E3%83%90%E3%83%BC%E3%81%AB%E3%80%81%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E9%96%8B%E7%99%BA%E3%81%AB%E5%8F%96%E3%82%8A%E7%B5%84%E3%82%80%E3%81%9F%E3%82%81%E3%81%AE%E6%89%8B%E3%81%8C%E3%81%8B%E3%82%8A%E3%82%92%E4%B8%8E%E3%81%88%E3%82%8B"><a class="header-anchor-link" href="#3.-%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E9%96%8B%E7%99%BA%E3%81%8C%E8%A1%8C%E3%81%88%E3%81%AA%E3%81%84%E3%80%81%E3%81%BE%E3%81%9F%E3%82%AD%E3%83%A3%E3%83%83%E3%83%81%E3%82%A2%E3%83%83%E3%83%97%E3%81%8C%E5%BF%85%E8%A6%81%E3%81%AA%E9%96%8B%E7%99%BA%E3%83%A1%E3%83%B3%E3%83%90%E3%83%BC%E3%81%AB%E3%80%81%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E9%96%8B%E7%99%BA%E3%81%AB%E5%8F%96%E3%82%8A%E7%B5%84%E3%82%80%E3%81%9F%E3%82%81%E3%81%AE%E6%89%8B%E3%81%8C%E3%81%8B%E3%82%8A%E3%82%92%E4%B8%8E%E3%81%88%E3%82%8B" aria-hidden="true"></a> 3. バックエンド開発が行えない、またキャッチアップが必要な開発メンバーに、バックエンド開発に取り組むための手がかりを与える</h4>
<p>こちらは開発チームに閉じたゴールですが、フロントエンドエンジニアやマークアップ出身の方など、<br />
様々なバックボーンをもつメンバーで開発を進める中、バックエンド開発のコンセプト、コンテクストを理解してもらうための手がかりになることを裏の目的のひとつとして据えています。</p>
<p>特に私たちの開発チームは開発体制の分業を一切しておらず、いわゆるフルサイクルな感じで各自がやれることを増やして手を広げていく姿勢を文化として良しとしています。</p>
<p>個人的には<a href="https://www.freee.co.jp/" target="_blank" rel="nofollow noopener noreferrer">freeeさん</a>の開発文化のひとつ、 <em>「何でもやれる、何でもやる」</em> のステートメントに非常に感銘を受けており、我々のチームにとってこの取り組みがその一助となればという感じでがんばってます。</p>
<p>参考) <a href="https://developers.freee.co.jp/entry/anyone-who-has-never-made-a-mistake-has-never-tried-anything-new_" target="_blank" rel="nofollow noopener noreferrer">失敗して攻め続けるために - freeeのエンジニアが障害対応で実践していること | freee Developers Blog</a></p>
<h3 id="%E3%82%AB%E3%83%AA%E3%82%AD%E3%83%A5%E3%83%A9%E3%83%A0"><a class="header-anchor-link" href="#%E3%82%AB%E3%83%AA%E3%82%AD%E3%83%A5%E3%83%A9%E3%83%A0" aria-hidden="true"></a> カリキュラム</h3>
<p>基本的に全4回くらいででそれっぽいことができるように、という意図でカリキュラムを組みました。<br />
各回1時間という時間設定で、座学とワークショップを組み合わせていい感じに学んでもらうことを目指しています。</p>
<p>この記事を執筆している2021/12時点で第2回まで実施していて、全工程の半分程度を消化しているかな、というところになります。<br />
実施済みの回は実際に利用した資料をアップしているので、その内容から雰囲気を掴んでいただければ幸いです。</p>
<table>
<thead>
<tr>
<th style="text-align:center">Vol.</th>
<th style="text-align:center">ゴール</th>
<th style="text-align:center">座学 / WS<br />の割合</th>
<th style="text-align:center">資料</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:center">第1回</td>
<td style="text-align:center">select文の基本がわかる</td>
<td style="text-align:center">5 / 5</td>
<td style="text-align:center"><a href="https://speakerdeck.com/saiidalhalawi/di-1hui-sqlmian-qiang-hui-she-wai-gong-kai-yong" target="_blank" rel="nofollow noopener noreferrer">第1回 SQL勉強会 (社外公開用)</a></td>
</tr>
<tr>
<td style="text-align:center">第2回</td>
<td style="text-align:center">結合と集計の基礎がわかる</td>
<td style="text-align:center">8 / 2</td>
<td style="text-align:center"><a href="https://speakerdeck.com/saiidalhalawi/di-2hui-sqlmian-qiang-hui-she-wai-gong-kai-yong" target="_blank" rel="nofollow noopener noreferrer">第2回 SQL勉強会 (社外公開用)</a></td>
</tr>
<tr>
<td style="text-align:center">第3回</td>
<td style="text-align:center">結合と集計をある程度使いこなせる</td>
<td style="text-align:center">3 / 7</td>
<td style="text-align:center">-</td>
</tr>
<tr>
<td style="text-align:center">第4回</td>
<td style="text-align:center">データ構造の見方、追い方の理解 / <br />ゼロベースでの問い合わせ</td>
<td style="text-align:center">4 / 6</td>
<td style="text-align:center">-</td>
</tr>
</tbody>
</table>
<h2 id="%E9%81%8B%E5%96%B6%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6"><a class="header-anchor-link" href="#%E9%81%8B%E5%96%B6%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> 運営について</h2>
<p>なにぶん私個人が業務の片手間で行うことなので、開催は不定期な感じでやってます。<br />
想定受講者は字義通り知識ゼロ、「SQL is 何？」レベルの方を想定していましたが、実際には開発チームからも数名参加したりなど、様々なレベルの方に参加いただきました。</p>
<p>運営上の課題や拙いポイントなどがいくつもありながらも、途中からGoogleフォームでアンケートをとるようになったりなど、いろいろ試行錯誤しながら継続しています。</p>
<p>内容についてもSQLやデータベースの知識ゼロのクルーに対して説明することについて、当初かなり不安ではあったのですが、<br />
参加された方が色々と質問してくれたりして、理解度を確かめながら進めていくことができているかな、と感じています。</p>
<p>また、社内とはいえ勉強会を主催・運営するのはたぶん初めての経験だったので、日々新規プロダクトのビルドに追われる中で業務としてもいい気分転換になっている気がします。</p>
<h2 id="%E7%8F%BE%E6%99%82%E7%82%B9%E3%81%A7%E3%81%AE%E3%81%B5%E3%82%8A%E3%81%8B%E3%81%88%E3%82%8A"><a class="header-anchor-link" href="#%E7%8F%BE%E6%99%82%E7%82%B9%E3%81%A7%E3%81%AE%E3%81%B5%E3%82%8A%E3%81%8B%E3%81%88%E3%82%8A" aria-hidden="true"></a> 現時点でのふりかえり</h2>
<p>まだまだ道半ばの取り組みではありますが、ここまでを簡単にふりかえって本エントリを締め括りたいと思います。<br />
他社さんでも同じような取り組みをされているところ、またこれから始めようとされているところも多くあるかと思うので、何かの参考になれば幸いです。</p>
<h3 id="%E3%82%88%E3%81%8B%E3%81%A3%E3%81%9F%E7%82%B9"><a class="header-anchor-link" href="#%E3%82%88%E3%81%8B%E3%81%A3%E3%81%9F%E7%82%B9" aria-hidden="true"></a> よかった点</h3>
<ul>
<li>
<p>SQL、データベースへの理解ではなく、あくまでゴールをBIツールの利用に置いたこと</p>
<ul>
<li>正味1時間程度の限られた時間での開催になるため、目的の割り切りとその事前共有は正解だったかなと感じています</li>
</ul>
</li>
<li>
<p>データベースやテーブルの説明にSpreadsheetのアナロジーを用いたこと</p>
<ul>
<li>あくまで講師視点での感想になりますが、日頃利用しているSpreadsheetとの対比をベースに説明することで、色々理解が捗っていたのではないかと感じました</li>
</ul>
</li>
<li>
<p>各回で質問が出ていた</p>
<ul>
<li>質問は出れば出るだけ受講者の現時点での理解度を推し量るための指標として活用できるため、一方通行なコミュニケーションにならずにホッとしています
<ul>
<li>とはいえ今後もより多くの質問をしてもらうための仕掛けや工夫が必要だと感じています</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3 id="%E8%AA%B2%E9%A1%8C%E7%82%B9-%2F-%E6%94%B9%E5%96%84%E7%82%B9"><a class="header-anchor-link" href="#%E8%AA%B2%E9%A1%8C%E7%82%B9-%2F-%E6%94%B9%E5%96%84%E7%82%B9" aria-hidden="true"></a> 課題点 / 改善点</h3>
<ul>
<li>
<p>ワークショップの設計が稚拙</p>
<ul>
<li>ワークショップについては事前に用意したサンプルクエリに対して口頭での指示通りに手を加えてもらう、という方法で進めていたのですが、もう少し工夫があってもよかったと感じます。
<ul>
<li>たとえば設問や解法などを明示的、説明的に事前に言語化しておけば、当日の段取りだけではなく、参加できなかったクルーへのフォローや事後的な復習にも活用してもらえたかもしれません。</li>
</ul>
</li>
</ul>
</li>
<li>
<p>録画・録音必須！</p>
<ul>
<li>実際に始めるまでまったくアタマにありませんでしたが、当日の様子を録画ないし録音することは必須だと感じています。
<ul>
<li>同期的な参加が難しいクルーへのフォールバック措置</li>
<li>自身の事後的なふりかえりへの活用
<ul>
<li>録音を客観的に聴いてみると、説明のスピードと受講者の理解とでいかに足並みが揃っていないか、またひとつひとつの説明がいかに無用なフィラー表現で満ちているか、などなど、当日は気にも留めなかった課題点をありありと見せつけられます</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<h2 id="we-are-hiring!%E7%9A%84%E3%81%AA"><a class="header-anchor-link" href="#we-are-hiring!%E7%9A%84%E3%81%AA" aria-hidden="true"></a> We Are Hiring!的な</h2>
<p>最後に、クラッソーネではエンジニアを積極採用中です！<br />
少しでも興味を持っていただけたらぜひお気軽にご連絡ください。</p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__b7747ed59ad4d" src="https://embed.zenn.studio/card#zenn-embedded__b7747ed59ad4d" data-content="https%3A%2F%2Fwww.crassone.co.jp%2Frecruit%2Fengineer%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.crassone.co.jp/recruit/engineer/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.crassone.co.jp/recruit/engineer/</a></p>



こんにちは、クラッソーネでアプリケーションエンジニアをしている菅野です。
もう年末なので今年をふりかえってみると、世界最高の古楽アンサンブルグループであるタリススコラーズの東京公演が今年はスキップされてしまったことが地味に残念でした。隔年で毎回行っていたのですが、ここまでコロナウィルスの影響が続くとは思いもよりませんでした。2023には無事開催されることを願ってます。

今回は全社的なデータの利活用の推進を目的に、知識ゼロから学んでいく初心者向けのSQL勉強会をやり始めた話について紹介していきたいと思います。

当時の状況・背景

弊社では、私がジョインする前から全社的にOSSのMetabaseがBIツールとして活用されていて、開発部門以外でもある程度SQLを使いこなせる方が存在している状態でした。
(事業の本格的なデジタルシフトが直近2~3年程度であることを考えると、この点は非常に素晴らしいことだと入社時に感じていました)

とはいえSQLを利用して自在にデータを参照できるメンバーは全体からすると非常に限定的で、その限られた方々に各部署からの取得依頼が集中しているという状況になっていました。

また私が直近関わっている新規事業の立ち上げ、新規プロダクトの開発に関しては、セールスやCS部門をはじめいわゆる「プロダクトの開発」自体が初めてという方も多く、サービスを開発・改善していくというゴールに向かって諸々のコンテクストを揃えていく必要に駆られていました。

SQL勉強会という取り組みの企画

そんな状況の中、ひとりでも多くの方がデータに対する解像度を高めて、かつ実際に業務活用していけるように、知識ゼロからSQLを学んでいける場としてこの勉強会をスタートさせました。

業務片手間の個人プロジェクトではありますが、以下その企図と経過を含めてあらましを記述していきます。

目的

当初から以下の3点を明確にゴールとして定めていました。

1. セールスやカスタマーサクセスの人も、シンプルな内容であれば分析クエリを自弁できるようになる

こちらが第一義的な目的で、クエリ依頼の偏在が解消されるとともに、
全社の視点で見てもSQLを多少なりとも扱えるクルーが増えることはデータリテラシーの底上げに寄与しそうです。

またこのゴールを念頭に、SQLの細かい構文やデータベースの仕組みなどにはあまり言及せず、あくまでデータの利用者として「大掴みにデータ・SQLを概観できる」という点を重視することにしています。

2. プロダクトのコアとなるテーブル構造やカラム定義などについて、全体に大枠の内容が共有される

こちらは統合的なDWHがまだ存在しないことに起因するのですが、
分析のためにはアプリケーション都合のデータ構造やその背景などにある程度知悉する必要がありました。
(特にプロダクトがイミュータブルなデータモデルを基本方針に設計されているため、その点は重点的なインプットが必要となりそうです。)

3. バックエンド開発が行えない、またキャッチアップが必要な開発メンバーに、バックエンド開発に取り組むための手がかりを与える

こちらは開発チームに閉じたゴールですが、フロントエンドエンジニアやマークアップ出身の方など、
様々なバックボーンをもつメンバーで開発を進める中、バックエンド開発のコンセプト、コンテクストを理解してもらうための手がかりになることを裏の目的のひとつとして据えています。

特に私たちの開発チームは開発体制の分業を一切しておらず、いわゆるフルサイクルな感じで各自がやれることを増やして手を広げていく姿勢を文化として良しとしています。

個人的にはfreeeさんの開発文化のひとつ、 「何でもやれる、何でもやる」 のステートメントに非常に感銘を受けており、我々のチームにとってこの取り組みがその一助となればという感じでがんばってます。

参考) 失敗して攻め続けるために - freeeのエンジニアが障害対応で実践していること | freee Developers Blog

カリキュラム

基本的に全4回くらいででそれっぽいことができるように、という意図でカリキュラムを組みました。
各回1時間という時間設定で、座学とワークショップを組み合わせていい感じに学んでもらうことを目指しています。

この記事を執筆している2021/12時点で第2回まで実施していて、全工程の半分程度を消化しているかな、というところになります。
実施済みの回は実際に利用した資料をアップしているので、その内容から雰囲気を掴んでいただければ幸いです。

| Vol. | ゴール | 座学 / WSの割合 | 資料 |
| :---: | :---: | :---: | :---: |
| 第1回 | select文の基本がわかる | 5 / 5 | 第1回 SQL勉強会 (社外公開用) |
| 第2回 | 結合と集計の基礎がわかる | 8 / 2 | 第2回 SQL勉強会 (社外公開用) |
| 第3回 | 結合と集計をある程度使いこなせる | 3 / 7 | - |
| 第4回 | データ構造の見方、追い方の理解 / ゼロベースでの問い合わせ | 4 / 6 | - |

運営について

なにぶん私個人が業務の片手間で行うことなので、開催は不定期な感じでやってます。
想定受講者は字義通り知識ゼロ、「SQL is 何？」レベルの方を想定していましたが、実際には開発チームからも数名参加したりなど、様々なレベルの方に参加いただきました。

運営上の課題や拙いポイントなどがいくつもありながらも、途中からGoogleフォームでアンケートをとるようになったりなど、いろいろ試行錯誤しながら継続しています。

内容についてもSQLやデータベースの知識ゼロのクルーに対して説明することについて、当初かなり不安ではあったのですが、
参加された方が色々と質問してくれたりして、理解度を確かめながら進めていくことができているかな、と感じています。

また、社内とはいえ勉強会を主催・運営するのはたぶん初めての経験だったので、日々新規プロダクトのビルドに追われる中で業務としてもいい気分転換になっている気がします。

現時点でのふりかえり

まだまだ道半ばの取り組みではありますが、ここまでを簡単にふりかえって本エントリを締め括りたいと思います。
他社さんでも同じような取り組みをされているところ、またこれから始めようとされているところも多くあるかと思うので、何かの参考になれば幸いです。

よかった点

SQL、データベースへの理解ではなく、あくまでゴールをBIツールの利用に置いたこと
  正味1時間程度の限られた時間での開催になるため、目的の割り切りとその事前共有は正解だったかなと感じています

データベースやテーブルの説明にSpreadsheetのアナロジーを用いたこと
  あくまで講師視点での感想になりますが、日頃利用しているSpreadsheetとの対比をベースに説明することで、色々理解が捗っていたのではないかと感じました

各回で質問が出ていた
  質問は出れば出るだけ受講者の現時点での理解度を推し量るための指標として活用できるため、一方通行なコミュニケーションにならずにホッとしています
    とはいえ今後もより多くの質問をしてもらうための仕掛けや工夫が必要だと感じています

課題点 / 改善点

ワークショップの設計が稚拙
  ワークショップについては事前に用意したサンプルクエリに対して口頭での指示通りに手を加えてもらう、という方法で進めていたのですが、もう少し工夫があってもよかったと感じます。
    たとえば設問や解法などを明示的、説明的に事前に言語化しておけば、当日の段取りだけではなく、参加できなかったクルーへのフォローや事後的な復習にも活用してもらえたかもしれません。

録画・録音必須！
  実際に始めるまでまったくアタマにありませんでしたが、当日の様子を録画ないし録音することは必須だと感じています。
    同期的な参加が難しいクルーへのフォールバック措置
    自身の事後的なふりかえりへの活用
      録音を客観的に聴いてみると、説明のスピードと受講者の理解とでいかに足並みが揃っていないか、またひとつひとつの説明がいかに無用なフィラー表現で満ちているか、などなど、当日は気にも留めなかった課題点をありありと見せつけられます

We Are Hiring!的な

最後に、クラッソーネではエンジニアを積極採用中です！
少しでも興味を持っていただけたらぜひお気軽にご連絡ください。

https://www.crassone.co.jp/recruit/engineer/


社内で初心者向けSQL勉強会を始めてみた話


こんにちは、クラッソーネでアプリケーションエンジニアをしている菅野です。
10月からワールドトリガー3期のアニメも始まったので充実した生活を送れそうな予感がしてます。

さて、弊社もご多分にもれず多くのやりたいことに対してエンジニアのトリオンリソースが全然追いついていない比較的小さな規模の組織です。
今回はそんな状況の中オペレーション変更を伴う短期的な仮説検証に早期に対応したという話題で、とある事情から開発なしでアドホックに新規施策のログ蓄積とモニタリングを実現した事例について具体的な手法を交えて紹介していきたいと思います。

前提条件(当時の状況)

まず前提としてざっと以下のような状況になってます。割とあるあるなんじゃないでしょうか。

会社: アーリーステージのスタートアップ
プロダクト: ユーザーからの申し込みで始まるマッチングサービス
注力領域: GMVを高めるための要因分析と仮説検証
希望リードタイム: なる早(！)
想定リードタイム: 不明
  開発チームはスクラムでPBI(タスク)をさばいているため、他タスクの内容・状況によっては依頼したところで相対的に提供時期が遅くなる可能性があった
データ基盤: なし
  BIツールは全社的に導入しており、参照データはアプリケーションDBのレプリカとなっている
私: 別事業の別プロダクトにて専任開発者
  対象プロダクトは「自分の庭先」ではないため、知識・コンテクストの面で当然十分にキャッチアップできていない、かつ本件にかかる対応にリソースを割きづらい状態

具体的にやりたい施策

電話によるユーザーサポートで得られた新設ヒアリング項目をBIツール上でモニタリングして仮説検証を行いたい。

つまり素直に要件を検討するとコアとなる申込の周辺データとしてイベントテーブルの新設とそのCRUD操作が必要な依頼であり、かつ短期的な仮説検証に対する開発要求です。
したがって役目を果たしたら他の箇所へ影響を残さないように削除できるようにしておく必要もありそうです。

先述の状況を踏まえるとこの開発自体のROIはキャッチアップコストも含めてあまり高いものにはならなそうですね。

さて、どうやって実現させていくのがいいでしょうか。

実際にやったこと

今回のケース、結論から言うとサポート用の申込備考欄に所定のCSVフォーマットでテキスト行を入力してもらい、BIツールにてSQLを駆使して擬似的なイベントレコードの形に整形の上で抽出する、というなんとも泥臭くてプリミティブな対応を取ることにしました。

決してベストな対処ではないものの、データボリュームや概算の見積りなどもろもろ踏まえて現実的な落としどころ判断した、という感じです。

※ ただし実際のところ「運用でカバー」の極致みたいな危うい対応になるので、十分な開発リソースを準備できたり、適切なDWHが構築済みの場合はこんなことせずに素直に進めていくのがいいでしょう。間違いなく中長期で安定運用していける施策ではないと思います。

1. フォーマットを決める

まずはオペレーションチームに入力したい内容についてのヒアリングを行い、入力データのフォーマットについて関係者で検討していきます。

そして検討の結果、以下のルールのもとでヒアリング内容を申込の備考欄に対して入力していく運用に決まりました。

新設項目の入力開始は特定日から実施する
新設項目は備考欄に行ごとに入力していく
新設項目は備考欄先頭行から入力していく
新設項目は種類に応じて各行以下のフォーマットで入力する(当然ながら中身は実際のデータとは異なりますが、形はこのままです)
    固定PREFIX, イベント種別1, イベント内容1, イベント内容2, イベント内容3, イベント内容4, 登録日
    固定PREFIX, イベント種別2, イベント内容1, イベント内容2,登録日

参照したいイベントの区分は複数種類あるため イベント種別 の「列」を用意してます。
また、それぞれで指標となる項目数が異なることにも留意が必要です。

2. 取り決めに従い運用

上述のルールに従いまずは1週間ほど運用してもらいます。

3. 結果を見る

さて、いよいよ蓄積されてきたデータをBIツール上で抽出してみます。
試行錯誤の末、なんやかんやあって以下のような問い合わせ内容に落ち着きました。
(ちなみにRDBMSはMySQL 8系です)

with newentryevents as (
    select
        e.id as entry_id,
        substringindex(e.memo, “\n”, 1) as newentry_event
    from
        entries e
    where
        e.memo like ‘%固定PREFIX,%’
        and e.created_at > ‘2021-01-01’
        and substring_index(e.memo, “\n”, 1) like ‘固定PREFIX%’
    union all
    select
        e.id as entry_id,
        substringindex(substringindex(e.memo, “\n”, 2), “\n”, -1) as newentryevent
    from
        entries e
    where
        e.memo like ‘%固定PREFIX,%’
        and e.created_at > ‘2021-01-01’
        and substringindex(substringindex(e.memo, “\n”, 2), “\n”, -1) like ‘固定PREFIX%’
    union all
    select
        e.id as entry_id,
        substringindex(substringindex(e.memo, “\n”, 3), “\n”, -1) as newentryevent
    from
        entries e
    where
        e.memo like ‘%固定PREFIX,%’
        and e.created_at > ‘2021-01-01’
        and substringindex(substringindex(e.memo, “\n”, 3), “\n”, -1) like ‘固定PREFIX%’
    union all
    select
        e.id as entry_id,
        substringindex(substringindex(e.memo, “\n”, 4), “\n”, -1) as newentryevent
    from
        entries e
    where
        e.memo like ‘%固定PREFIX,%’
        and e.created_at > ‘2021-01-01’
        and substringindex(substringindex(e.memo, “\n”, 4), “\n”, -1) like ‘固定PREFIX%’
    union all
    select
        e.id as entry_id,
        substringindex(substringindex(e.memo, “\n”, 5), “\n”, -1) as newentryevent
    from
        entries e
    where
        e.memo like ‘%固定PREFIX,%’
        and e.created_at > ‘2021-01-01’
        and substringindex(substringindex(e.memo, “\n”, 5), “\n”, -1) like ‘固定PREFIX%’
    union all
    select
        e.id as entry_id,
        substringindex(substringindex(e.memo, “\n”, 6), “\n”, -1) as newentryevent
    from
        entries e
    where
        e.memo like ‘%固定PREFIX,%’
        and e.created_at > ‘2021-01-01’
        and substringindex(substringindex(e.memo, “\n”, 6), “\n”, -1) like ‘固定PREFIX%’
)

select
    newentryevents.entry_id as ‘申込ID’,
    substringindex(newentryevents.newentry_event, “,”, 1) as ‘取得イベント‘,
    substringindex(substringindex(newentryevents.newentryevent, “,”, 2), “,”, -1) as ‘イベント区分‘,
    substringindex(substringindex(newentryevents.newentryevent, “,”, 3), “,”, -1) as ‘イベント内容1’,
    substringindex(substringindex(newentryevents.newentryevent, “,”, 4), “,”, -1) as ‘イベント内容2’,
    substringindex(substringindex(newentryevents.newentryevent, “,”, 5), “,”, -1) as ‘イベント内容3’,
    substringindex(substringindex(newentryevents.newentryevent, “,”, 6), “,”, -1) as ‘イベント内容4’,
    substringindex(substringindex(newentryevents.newentryevent, “,”, 7), “,”, -1) as ‘発生日‘,
    concat('https://dummy.crassone.co.jp/ops/', newentryevents.entry_id) as ‘管理画面URL’
from newentryevents
where newentryevents.newentryevent like ‘固定PREFIX,イベント種別1%’
union distinct
select
    newentryevents.entry_id as ‘申込ID’,
    substringindex(newentryevents.newentry_event, “,”, 1) as ‘取得イベント‘,
    substringindex(substringindex(newentryevents.newentryevent, “,”, 2), “,”, -1) as ‘イベント区分‘,
    substringindex(substringindex(newentryevents.newentryevent, “,”, 3), “,”, -1) as ‘イベント内容1’,
    substringindex(substringindex(newentryevents.newentryevent, “,”, 4), “,”, -1) as ‘イベント内容2’,
    null as ‘イベント内容3’,
    null as ‘イベント内容4’,
    substringindex(substringindex(newentryevents.newentryevent, “,”, 5), “,”, -1) as ‘発生日’,
    concat('https://dummy.crassone.co.jp/ops/', newentryevents.entry_id) as ‘管理画面URL’
from newentryevents
where newentryevents.newentryevent like ‘固定PREFIX,イベント種別2%’
order by 申込ID

いきなりヤバそうなクエリが出てきました。一体なにをしているのでしょうか？

解説

まず、このSQLは大きくイベントの事前整形処理とそのCSVの分解処理に大別されます。 newentryevents を形成する with 句と地のselect文ですね。
それぞれ以下のような処理になってます。

1. 事前整形

まずは with 句の中身です。
備考欄(entries.memo)という申込データに付随するtextカラムから1行ずつ合致するCSV行を抽出していきます。
1行ずつというところがキモで、それぞれ union 句で接続された select 文は以下のことを行ってます。

select
    e.id as entry_id, /* 申込IDを抽出 */
    substringindex(e.memo, “\n”, 1) as newentry_event /* 備考欄1行目のみを抽出 */
from
    entries e
where
    e.memo like ‘%固定PREFIX,%’ /* 特定の文字列を含む備考欄を対象 */
    and e.created_at > ‘2021-01-01’ /* 施策の開始日以降を対象 */
    and substring_index(e.memo, “\n”, 1) like ‘固定PREFIX%’ /* 備考欄1行目に特定文字列を含むレコードを対象 */

ひとつひとつの select 文では備考欄の特定行目のみを抽出しており、それをカバレッジ十分と思われる数だけ「ガッチャンコ」してる感じです。

substring_index 関数がネストしていますが、これは最初の関数の呼び出しで指定の行目以前の文字列をすべて取得し、続く呼び出しでさらにそのうち最後の行内容のみを取得する、という構造になっています。

存在するレコード状態とクエリ取得結果は以下のような対応になっています。

| 申込ID | 備考 |
| ---: | :--- |
| 1 | 固定PREFIX,イベント種別1,ああああ,いいいい,うううう,ええええ,2021-01-01固定PREFIX,イベント種別2,かかかか,きききき,2021-01-03あのイーハトーヴォのすきとおった風、夏でも底に冷たさをもつ青いそら、うつくしい森で飾られたモリーオ市、郊外のぎらぎらひかる草の波。 |
| 2 | 固定PREFIX,イベント種別1,ささささ,しししし,すすすす,せせせせ,2021-01-02山路を登りながら、こう考えた。智に働けば角が立つ。情に棹させば流される。意地を通せば窮屈だ。 |

| entryid | newentry_event |
| ---: | :--- |
| 1 | 固定PREFIX,イベント種別1,ああああ,いいいい,うううう,ええええ,2021-01-01 |
| 1 | 固定PREFIX,イベント種別2,かかかか,きききき,2021-01-03 |
| 2 | 固定PREFIX,イベント種別1,ささささ,しししし,すすすす,せせせせ,2021-01-02 |

ご覧の通り、これで text 型のカラムから対象となるCSV文字列行を集めて擬似的な表として抽出できたことになります。

2. CSVの列分解

ここまでくると後は簡単で、 イベント種別 ごとにCSV文字列を分解して合体させればよい訳なので特に内容は大丈夫でしょう。

この段階で抽出結果は以下の通りとなり、備考欄のそれぞれのCSV行が構造化された擬似的な表として抽出できたことになります。

| 申込ID | 固定PREFIX | イベント種別 | イベント内容1 | イベント内容2 | イベント内容3 | イベント内容4 | 発生日 |
| ---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| 1 | 固定PREFIX | イベント種別1 | ああああ | いいいい | うううう | ええええ | 2021-01-01 |
| 1 | 固定PREFIX | イベント種別2 | かかかか | きききき | | | 2021-01-03 |
| 2 | 固定PREFIX | イベント種別1 | ささささ | しししし | すすすす | せせせせ | 2021-01-02 |

あとはBIツール上でそのまま集計するなり、ダウンロードしてスプレッドシートで活用してもらうなり好きにしてもらいましょう。

そしてここまで本当に「開発なし」

以上見てきた通り、かなり乱暴な手法でありましたがアプリケーションに手を入れることなく業務上の新しい施策とそのモニタリングを実現することができました。

実現のために開発者としてかけた労力と言えば、最初の要件・ルール策定の部分と最後のクエリ構築の部分(ここはやや苦労した汗)のみであり、せいぜい半日程度だったと思います。

やりたいことは一応実現できたので良しとしますが、登場したクエリ内容についてはもっとスマートな解法があるかもしれません。

今回紹介した事例はコンテクストありきのかなり特殊なものではありますが、特にビジネスも小規模で割けるリソースも限定的な組織などでは、ひょっとすると条件付きで参考にして頂ける点もあるかと思い紹介させてもらいました。

We Are Hiring!的な

クラッソーネではエンジニアを積極採用中です！
インフラにも詳しくなりたいバックエンドエンジニア、デザインも語れるフロントエンドエンジニアなど、領域を広げて活躍したいと思っていらっしゃる皆さん、興味を持っていただけたらお気軽にご連絡ください。

https://www.crassone.co.jp/recruit/engineer/


開発なしで別プロダクトの新規施策を実現したという特殊な話

<p>こんにちは、クラッソーネでエンジニアをしている菅野です。<br />
ここ数日Kindleにて『鬼滅の刃』を一気読みしたので、これで世間の話題にもなんとかついていける気がしてます(遅)</p>
<p>私はここ数ヶ月ほど新規プロダクトの開発に関わっているのですが、<br />
まっさらな開発プロジェクトということもあり、概ねゼロベースの技術選定を行なっていました。</p>
<p>その過程で <em>ADR</em> という手法を用いて技術的な意思決定に関するドキュメントを残す取り組みを行なってきたので、本エントリでは弊社での事例を紹介できればと思います。</p>
<h2 id="adr-is-%E4%BD%95%EF%BC%9F"><a class="header-anchor-link" href="#adr-is-%E4%BD%95%EF%BC%9F" aria-hidden="true"></a> ADR is 何？</h2>
<p><code>Architectural Decision Records</code> の略で、アーキテクチャ上の意思決定についてその背景や・経緯も含めて書き記して言語化しておこうというドキュメントとその手法を指します。</p>
<p>現時点でADR自体には明確にこれという形式・フォーマットが規定されているわけではないようですが、中でも <em>Lightweight Architecture Decision Records</em> というタイプが過去に<a href="https://www.thoughtworks.com/de/radar/techniques/lightweight-architecture-decision-records" target="_blank" rel="nofollow noopener noreferrer">Technology Raderで <em>Adopted</em> になっていて</a>、一定の権威付けがされているようです。</p>
<h3 id="lightweight-architecture-decision-records%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6"><a class="header-anchor-link" href="#lightweight-architecture-decision-records%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6" aria-hidden="true"></a> Lightweight Architecture Decision Recordsについて</h3>
<p>以下の5つの項目で構成される軽量なADRフォーマットで、わたしたちのチームでもこちらを採用しています。</p>
<ul>
<li>title (タイトル)</li>
<li>status (ステータス)</li>
<li>context (コンテクスト)</li>
<li>decision (決定)</li>
<li>consequences (結果)</li>
</ul>
<h3 id="%E5%8F%82%E8%80%83"><a class="header-anchor-link" href="#%E5%8F%82%E8%80%83" aria-hidden="true"></a> 参考</h3>
<ul>
<li>
<p><a href="https://adr.github.io/" target="_blank" rel="nofollow noopener noreferrer">Architectural Decision Records | adr.github.io</a></p>
</li>
<li>
<p><a href="https://www.thoughtworks.com/de/radar/techniques/lightweight-architecture-decision-records" target="_blank" rel="nofollow noopener noreferrer">Lightweight Architecture Decision Records | Technology Radar | ThoughtWorks</a></p>
</li>
<li>
<p><a href="https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-michael-nygard/index.md" target="_blank" rel="nofollow noopener noreferrer">Decision record template by Michael Nygard | Github</a></p>
</li>
</ul>
<h2 id="%E5%BC%8A%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%A7%E3%81%AE%E4%BA%8B%E4%BE%8B"><a class="header-anchor-link" href="#%E5%BC%8A%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%A7%E3%81%AE%E4%BA%8B%E4%BE%8B" aria-hidden="true"></a> 弊プロジェクトでの事例</h2>
<p>さて、ここからは実際に試してみた経過を事例としてお伝えしていきたいと思います。</p>
<h3 id="%E4%BD%8D%E7%BD%AE%E4%BB%98%E3%81%91%E3%81%A8%E3%81%9D%E3%81%AE%E7%8B%99%E3%81%84"><a class="header-anchor-link" href="#%E4%BD%8D%E7%BD%AE%E4%BB%98%E3%81%91%E3%81%A8%E3%81%9D%E3%81%AE%E7%8B%99%E3%81%84" aria-hidden="true"></a> 位置付けとその狙い</h3>
<p>まず、当社におけるADRの運用ですが、「アーキテクチャ上の」要素に限らず、プロジェクトに関わるあらゆる技術的な意思決定や利用ツールの選定を対象としました。<br />
そのためリポジトリ内ではなく、全社で管理しているドキュメント管理サービスにADRを配置することにしています。この点は原義からすると多少離れたものになっているかもしれません。</p>
<p>また発足当初は2~3名の規模ではじまったチームでしたが、新規プロダクトということで <strong>大きな機能要件も不明瞭で、かつ短期的にも人員の入れ替わりや増減が予想されたため</strong> 、以下のことを主な狙いとして取り組むことにしました。</p>
<ol>
<li>
<p>精緻な内容を目指さす、とにかくカジュアルにドキュメントを残していく</p>
<ul>
<li>ただしコンテクストを極力ダンプしていくことは大切</li>
</ul>
</li>
<li>
<p>あとからチーム全体でふりかえりを行うことで、情報共有と今後の改善に活かす</p>
<ul>
<li>後述しますがこの点はかなり重要だったと思います</li>
</ul>
</li>
</ol>
<h3 id="%E9%81%8B%E7%94%A8"><a class="header-anchor-link" href="#%E9%81%8B%E7%94%A8" aria-hidden="true"></a> 運用</h3>
<p>以上のことを念頭に折に触れてLightweight ADRの形式でドキュメントを残していました。</p>
<p>特に執筆の基準や固定化した運用ルールは定めずにカジュアルな運用を目指しました。<br />
コードレビューの中でレビュアーが指摘事項として執筆を依頼することもあれば、書いたADRに対してコンテクストを詳細にしてくれといったプチレビューが入ることもあった気がします。</p>
<p>その結果「rubocopでの <a href="https://techracho.bpsinc.jp/hachi8833/2019_11_05/82601#2-2" target="_blank" rel="nofollow noopener noreferrer"><code>accepts_nested_attributes_for</code> の利用是非</a>」といった細かいものから「デザインツールの選定」に至るまで、大小様々なエントリが作られていきました。</p>
<h4 id="job%E3%82%A2%E3%83%80%E3%83%97%E3%82%BF%E3%82%92%E9%81%B8%E5%AE%9A%E3%81%97%E3%81%9F%E9%9A%9B%E3%81%AE%E3%82%A8%E3%83%B3%E3%83%88%E3%83%AA%E4%BE%8B"><a class="header-anchor-link" href="#job%E3%82%A2%E3%83%80%E3%83%97%E3%82%BF%E3%82%92%E9%81%B8%E5%AE%9A%E3%81%97%E3%81%9F%E9%9A%9B%E3%81%AE%E3%82%A8%E3%83%B3%E3%83%88%E3%83%AA%E4%BE%8B" aria-hidden="true"></a> Jobアダプタを選定した際のエントリ例</h4>
<p><img src="/images/posts/introduce-adr-documentation/our-adr-example.png" alt="Jobアダプタを選定した例" /></p>
<h3 id="%E3%81%B5%E3%82%8A%E3%81%8B%E3%81%88%E3%82%8A%E3%81%AE%E5%AE%9F%E6%96%BD"><a class="header-anchor-link" href="#%E3%81%B5%E3%82%8A%E3%81%8B%E3%81%88%E3%82%8A%E3%81%AE%E5%AE%9F%E6%96%BD" aria-hidden="true"></a> ふりかえりの実施</h3>
<p>さて、チーム発足から3~4ヶ月程度が経過して、プロジェクトもマイルストーンとなるタイミングを迎えました。<br />
そこでこれまで書き溜めていたADRの数々について、チーム全体で集まって同期的なふりかえりを実施しました。</p>
<p>先述の通りLADRには「結果」の項目があり、その意思決定がチームやプロダクトに何をもたらしたのかをみんなで話し合って「良かった点」「課題点」を思い思いに記載していきます。</p>
<p>案の定チームの顔ぶれも発足当初から大きく変わっていたため、当時の背景を振り返りつつ、その中で「チームとしての思考/判断」に言及しながらひとつひとつ良し悪しをディスカッションしていきます。<br />
この作業は非常に楽しくもあり、また情報共有・文脈共有の観点からも有益でもあったと感じています。</p>
<p>ただし「結果」と言いながら、実際のところその内容も <strong>特定時点でのスナップショットでしかない</strong> ので、「ログ欠損」を抑制するため今後も必要に応じて継続的なふりかえりを行っていく必要性はありそうです。</p>
<h3 id="%E3%81%BE%E3%81%A8%E3%82%81"><a class="header-anchor-link" href="#%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> まとめ</h3>
<p>以上みてきた通り、このエントリではADRという手法を新規開発プロジェクトで小さく導入してきた事例を紹介してきました。<br />
その中で個人的に感じた利点と反省点を最後に記しておきたいと思います。</p>
<h4 id="%E5%88%A9%E7%82%B9"><a class="header-anchor-link" href="#%E5%88%A9%E7%82%B9" aria-hidden="true"></a> 利点</h4>
<ol>
<li>乱暴に言ってしまえば意思決定というイベントの <strong>ただのログ</strong> であるため、一度書いてしまえば完全にメンテナンスフリーであること
<ul>
<li>マニュアルや仕様書など、一定のメンテナンスコストを要するものに比べるとこの利点は大きいと感じます</li>
</ul>
</li>
<li>LADRに関して、導入・定着のハードルがかなり低い
<ul>
<li>簡素ながらもツボを押さえた形式のため、日ごろからドキュメントを書く習慣のあるチームであればすぐに定着できるのではないかと思います</li>
</ul>
</li>
<li>途中参入のメンバーにもチームやプロダクトの連続的な背景を共有しやすいこと
<ul>
<li>通常の技術ドキュメントが現時点での「What」や「How」を記述するものだとしたら、過去のコンテクストや「Why」を可視化するドキュメント群はそれらを補完するものとして非常に有力だと感じます</li>
</ul>
</li>
</ol>
<h4 id="%E5%8F%8D%E7%9C%81%E7%82%B9"><a class="header-anchor-link" href="#%E5%8F%8D%E7%9C%81%E7%82%B9" aria-hidden="true"></a> 反省点</h4>
<ol>
<li>フォーマットを間違えて運用していた
<ul>
<li><strong><code>status</code> の項を完全に無視して運用してしまっていました。</strong> これは恥ずかしい。</li>
<li>とはいえカジュアル運用という意味ではさほど難を感じなかった(ゆえに発見が遅れた側面も...)</li>
</ul>
</li>
<li>ふりかえり時期はあらかじめ個別に想定しておけるとよかったかもしれない
<ul>
<li>どれくらいで結果が見えてきそうかは個別の決定内容によって異なるはずなので、大枠のふりかえりの時期も起票時点で決めておけるとより良く運用できそうだと感じています</li>
</ul>
</li>
<li>より詳細なコンテクストが書けるとよさそう
<ul>
<li>ドキュメントの性質上、 <strong>この情報が弱いと決定内容の評価が片手落ちになってしまうケースもあるため</strong> 、ここは唯一シビアにみるべき内容なのだという印象を持っています</li>
</ul>
</li>
</ol>
<h2 id="%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB"><a class="header-anchor-link" href="#%E3%81%8A%E3%82%8F%E3%82%8A%E3%81%AB" aria-hidden="true"></a> おわりに</h2>
<p>クラッソーネでは、プロダクトとチームの双方をより良く改善していけるエンジニアを大募集中です。<br />
少しでも興味をお持ちいただいた方、カジュアル面談にて色々とお話できれば嬉しいです！</p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__e5035f0e535c9" src="https://embed.zenn.studio/card#zenn-embedded__e5035f0e535c9" data-content="https%3A%2F%2Fwww.crassone.co.jp%2Frecruit%2Fengineer%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.crassone.co.jp/recruit/engineer/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.crassone.co.jp/recruit/engineer/</a></p>



こんにちは、クラッソーネでエンジニアをしている菅野です。
ここ数日Kindleにて『鬼滅の刃』を一気読みしたので、これで世間の話題にもなんとかついていける気がしてます(遅)

私はここ数ヶ月ほど新規プロダクトの開発に関わっているのですが、
まっさらな開発プロジェクトということもあり、概ねゼロベースの技術選定を行なっていました。

その過程で ADR という手法を用いて技術的な意思決定に関するドキュメントを残す取り組みを行なってきたので、本エントリでは弊社での事例を紹介できればと思います。

ADR is 何？

Architectural Decision Records の略で、アーキテクチャ上の意思決定についてその背景や・経緯も含めて書き記して言語化しておこうというドキュメントとその手法を指します。

現時点でADR自体には明確にこれという形式・フォーマットが規定されているわけではないようですが、中でも Lightweight Architecture Decision Records というタイプが過去にTechnology Raderで Adopted になっていて、一定の権威付けがされているようです。

Lightweight Architecture Decision Recordsについて

以下の5つの項目で構成される軽量なADRフォーマットで、わたしたちのチームでもこちらを採用しています。

title (タイトル)
status (ステータス)
context (コンテクスト)
decision (決定)
consequences (結果)

参考

Architectural Decision Records | adr.github.io

Lightweight Architecture Decision Records | Technology Radar | ThoughtWorks

Decision record template by Michael Nygard | Github

弊プロジェクトでの事例

さて、ここからは実際に試してみた経過を事例としてお伝えしていきたいと思います。

位置付けとその狙い

まず、当社におけるADRの運用ですが、「アーキテクチャ上の」要素に限らず、プロジェクトに関わるあらゆる技術的な意思決定や利用ツールの選定を対象としました。
そのためリポジトリ内ではなく、全社で管理しているドキュメント管理サービスにADRを配置することにしています。この点は原義からすると多少離れたものになっているかもしれません。

また発足当初は2~3名の規模ではじまったチームでしたが、新規プロダクトということで 大きな機能要件も不明瞭で、かつ短期的にも人員の入れ替わりや増減が予想されたため 、以下のことを主な狙いとして取り組むことにしました。

精緻な内容を目指さす、とにかくカジュアルにドキュメントを残していく
    ただしコンテクストを極力ダンプしていくことは大切

あとからチーム全体でふりかえりを行うことで、情報共有と今後の改善に活かす
    後述しますがこの点はかなり重要だったと思います

運用

以上のことを念頭に折に触れてLightweight ADRの形式でドキュメントを残していました。

特に執筆の基準や固定化した運用ルールは定めずにカジュアルな運用を目指しました。
コードレビューの中でレビュアーが指摘事項として執筆を依頼することもあれば、書いたADRに対してコンテクストを詳細にしてくれといったプチレビューが入ることもあった気がします。

その結果「rubocopでの acceptsnestedattributes_for の利用是非」といった細かいものから「デザインツールの選定」に至るまで、大小様々なエントリが作られていきました。

Jobアダプタを選定した際のエントリ例

Jobアダプタを選定した例

ふりかえりの実施

さて、チーム発足から3~4ヶ月程度が経過して、プロジェクトもマイルストーンとなるタイミングを迎えました。
そこでこれまで書き溜めていたADRの数々について、チーム全体で集まって同期的なふりかえりを実施しました。

先述の通りLADRには「結果」の項目があり、その意思決定がチームやプロダクトに何をもたらしたのかをみんなで話し合って「良かった点」「課題点」を思い思いに記載していきます。

案の定チームの顔ぶれも発足当初から大きく変わっていたため、当時の背景を振り返りつつ、その中で「チームとしての思考/判断」に言及しながらひとつひとつ良し悪しをディスカッションしていきます。
この作業は非常に楽しくもあり、また情報共有・文脈共有の観点からも有益でもあったと感じています。

ただし「結果」と言いながら、実際のところその内容も 特定時点でのスナップショットでしかない ので、「ログ欠損」を抑制するため今後も必要に応じて継続的なふりかえりを行っていく必要性はありそうです。

まとめ

以上みてきた通り、このエントリではADRという手法を新規開発プロジェクトで小さく導入してきた事例を紹介してきました。
その中で個人的に感じた利点と反省点を最後に記しておきたいと思います。

利点

乱暴に言ってしまえば意思決定というイベントの ただのログ であるため、一度書いてしまえば完全にメンテナンスフリーであること
    マニュアルや仕様書など、一定のメンテナンスコストを要するものに比べるとこの利点は大きいと感じます
LADRに関して、導入・定着のハードルがかなり低い
    簡素ながらもツボを押さえた形式のため、日ごろからドキュメントを書く習慣のあるチームであればすぐに定着できるのではないかと思います
途中参入のメンバーにもチームやプロダクトの連続的な背景を共有しやすいこと
    通常の技術ドキュメントが現時点での「What」や「How」を記述するものだとしたら、過去のコンテクストや「Why」を可視化するドキュメント群はそれらを補完するものとして非常に有力だと感じます

反省点

フォーマットを間違えて運用していた
    status の項を完全に無視して運用してしまっていました。 これは恥ずかしい。
    とはいえカジュアル運用という意味ではさほど難を感じなかった(ゆえに発見が遅れた側面も...)
ふりかえり時期はあらかじめ個別に想定しておけるとよかったかもしれない
    どれくらいで結果が見えてきそうかは個別の決定内容によって異なるはずなので、大枠のふりかえりの時期も起票時点で決めておけるとより良く運用できそうだと感じています
より詳細なコンテクストが書けるとよさそう
    ドキュメントの性質上、 この情報が弱いと決定内容の評価が片手落ちになってしまうケースもあるため 、ここは唯一シビアにみるべき内容なのだという印象を持っています

おわりに

クラッソーネでは、プロダクトとチームの双方をより良く改善していけるエンジニアを大募集中です。
少しでも興味をお持ちいただいた方、カジュアル面談にて色々とお話できれば嬉しいです！

https://www.crassone.co.jp/recruit/engineer/


ADRはじめました


こんにちは、アプリケーションエンジニアの菅野です。
入社以来リモートワークをエンジョイしていますが、通勤時間がなくなったことにより本を読む時間がめっきり減ってきたのが最近の悩みです。

これは？

このエントリではテストにおけるfakeデータの説明や背景を紹介した上で、RSpecでfakeデータ生成gemを導入・利用することを簡単に解説していきます。

fakeデータって？

ここではテストを実行する際に用意する、 サービスの利用実態に合わせて捏造された事前データ のことを指します。
例えば 「ユーザーがログインできること」 をテストする場合、ログイン処理を実行させるために作られたユーザーアカウントのデータがそれに当たります。

ダミーデータじゃないの？？

両者よく似た語ではありますが、ことテストにおいては下記のように微妙にニュアンスが違ってくるんじゃないかと思います(たぶん)。

ダミーデータ ・・・ 本物を模して作られたハリボテ(モノとしての機能の有無は問わない)
フェイクデータ ・・・捏造されたもの(偽物ではあるが、モノとしての機能は保持している)

家や建物で例えれば、ダミーの方は演劇の舞台装置などにあるような表層だけを模した単なる板切れであるのに対し、フェイクデータはモデルルームのような実際の生活空間を再現したもの、といったところでしょうか。

テストでは現実の振る舞いをより忠実に再現した上で検証できた方が望ましく、その意味で語としてもフェイクの方がよりフィットしそうな感じがしますよね。

rubyの faker gemがこういう名前をしているのもそんな背景があるんじゃないかと思います。知らんけど。

で、なんで必要なの？

ではなぜフェイクデータが必要になるのでしょうか。
例えば以下のようなテストで考えてみましょう。

FactoryBot.define do
  factory :user do
    name { 'テストユーザー' }
    email { 'user@example.com' }
  end
end

RSpec.describe User, type: :model do
  let(:user) { create(:user) }
  let(:sent_email) { ActionMailer::Base.deliveries.last }

  subject { user.sendwelcomemessage }

  example '対象のユーザーにメールが送られること' do
    subject
    expect(sent_email.body).to include 'テストユーザー様'
  end
end

送信されたメールに該当ユーザーの名前が入っていることを検証しているのですが、このテストには大きく3つの問題点が潜んでいます。
それぞれ見ていきましょう。

問題点 1. テストの検証内容が外部に依存している

このケースではFactoryにて作成された テストユーザー という名前を期待してその文字列を検証しているのですが、ここに一つ目の問題があります。

この例の場合だと :user というfactoryデータは決してこのケースに固有のものではなく、すべてのケースに対してオープンになっているものになります。

テストはそれ自体で完結できていた方が望ましく、外部要因でその成否が変わってしまうことはなるべく避けなければなりません。
例えば今回の場合、誰か別の開発者がFactoryの name の値を直接変更してしまうと テスト対象の機能とは関係のない要因でこのテストがfailしてしまうわけです。

問題点 2. 特定の名前でしか検証しかできていない

記載の通り、このケースでは特定のユーザー名の場合しか検証できていないため 対象のユーザー名を参照していることが厳格に保証されていません 。
例えば極端な例ではありますが、以下のようにメールテンプレートでユーザー名を静的に埋め込んでいたとしても検証が通ってしまうことになります。これはよろしくありません。

テストユーザー様

会員登録ありがとうございます。
 に会員登録が完了しました。

現実の世界では登録ユーザーの名前は多種多様であり、テストにおいても様々な入力で正常に動作することを検証できた方が望ましい、ということになるわけです。

問題点 3. (おそらく) 現実に テストユーザー という名前で登録するケースはあまりない

テストと言えどなるべく現実のユーザーの振る舞いや状況を模して検証すべきなので、 テストユーザー という名前を検証の事前条件にするのはやはり適切とは言えないでしょう。

そこでfakeデータですよ

以上挙げ連ねてきた問題点を解消するため、ここでfakeデータの利用を検討してみましょう。

ここでは冒頭で言及した faker というgemを利用してみます。

導入してみた

といっても公式通り以下を Gemfile に記述してインストールするだけ

gem 'faker'

さらに日本語のfakeデータを作成する場合はlocaleを設定しましょう。

Faker::Config.locale = 'ja'

先ほどの例でみたテストデータは、fakerを使うことで以下のようになりました。

require 'faker'

Faker::Config.locale = 'ja'

FactoryBot.define do
  factory :user do
    name { Faker::Name.name }
    email { Faker::Internet.email }
  end
end

この段階で実行ごとに名前・メールアドレスが都度ランダムに捏造されるようになりました。

[1]pry(main)> Faker::Name.name
=> "渡部 太一"
[2] pry(main)> Faker::Name.name
=> "野村 彩"

つまり テストユーザー様 というユーザー名が含まれることを検証していた既存のテストケースはfailするようになったわけです。

それでは既存のテストで、ログインしたそれぞれのユーザーを厳格にチェックできるように修正しましょう。

RSpec.describe User, type: :model do
  let(:user) { create(:user) }
  let(:sent_email) { ActionMailer::Base.deliveries.last }

  subject { user.sendwelcomemessage }

  example '対象のユーザーにメールが送られること' do
    subject
    expect(sent_email.body).to include "#{user.name}様" # ここを修正
  end
end

上記の通り修正することで、対象のユーザー名を明示的に指定するよう変更されて無事にテストがパスするようになりました。
先に挙げた問題点も解消されて、検証の精度としても向上しているのがわかりますね。

余談

ちなみにこの faker gemですが実に多種多様なデータが用意されています。

https://github.com/faker-ruby/faker/tree/master/doc

pry(main)> Faker::JapaneseMedia::Doraemon.gadget
=> "Anywhere Door"

pry(main)> Faker::Quotes::Shakespeare.kingrichardiii_quote
=> "A horse! a horse! my kingdom for a horse!."

ドラえもんの秘密道具からシェイクスピア史劇の名台詞まで、「果たして使うシーンあるのか？」と思いたくなるものも含め非常に広範なジャンルが用意されてます。
この辺り眺めてるだけでも楽しいので是非一度試してみてください。

まとめ

以上まとめるとこんな感じです。

テストは外部に影響されず、ケースそれ自体で完結できるようにしよう
色々なパターンでテストできるようにしよう
なるべく現実世界に即した振る舞いをテストしよう
事前データを都合よく捏造してくれる便利なgemがあるので活用しよう

We are hiring!的な

クラッソーネでは各種エンジニアを積極採用中です！
少しでもご興味持っていただけたらお気軽にご連絡いただけると幸いです！

https://www.crassone.co.jp/recruit/engineer/

ありがとうございました。


クラッソーネ開発者ブログ

菅野幸助が執筆した記事

社内で初心者向けSQL勉強会を始めてみた話

開発なしで別プロダクトの新規施策を実現したという特殊な話

ADRはじめました

RSpecにfakeデータ生成ツールを導入する話

菅野 幸助が執筆した記事

社内で初心者向けSQL勉強会を始めてみた話

開発なしで別プロダクトの新規施策を実現したという特殊な話

ADRはじめました

RSpecにfakeデータ生成ツールを導入する話

菅野幸助が執筆した記事