Another works Developers Blog

<p>こんにちは！<br>
Another works で AIエンジニア、データサイエンティストをやっているノブです！</p>
<p>今回は、弊社 <strong><a href="https://anotherworks.co.jp/">Another works</a> と <a href="https://smarthr.co.jp/">SmartHR</a></strong> さんで 2023/7/25(火) に開催したLT×交流会 <a href="https://anotherworks.connpass.com/event/288878/">顧客に価値を届けるプロダクト志向なエンジニアリング</a> のイベントレポートをお届けします！</p>
<h1>■ イベントの概要</h1>
<p>Another worksでは、他者のチームの取り組みについて知りたい、他社のエンジニアと交流を持ちたいと考えている方々を対象に定期的にイベントを開催しています！</p>
<p>SmartHRさんとオフラインでイベントを共催するのは二度目です。<br>
<a href="https://anotherworks.connpass.com/event/278310/">前回</a>同様、SmartHRさんのイベントスペースをお借りしてイベントを開催しました！（いつも素敵なスペースを本当にありがとうございます）</p>
<p>前回は「FRONT-END DEEP DIVE」とフロントエンドにフォーカスしたイベントだったのですが、今回は「<strong>エンジニアリング</strong>」とテーマを変えての開催に、どんなイベントになるのか楽しみな反面、緊張感もありました。</p>
<p>そんな不安を払拭するかのように 19:00 の開場から受付には人がたくさんいらっしゃり、結果オフライン・オンライン合わせて 60名を超える方にご参加いただきました！<br>
会場では多くの温かい拍手や熱い視線が、X（旧：Twitter）上でも #AwEngineerMeetup のハッシュタグで盛り上がり、オンライン・オフライン共に大盛況でした！</p>
<p>ご参加いただいた皆様ありがとうございました！！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/3b78addf-b92c-43d5-a99e-ac0a206163f9/F14HjMqaMAACeH-.jpeg" alt="F14HjMqaMAACeH-.jpeg"></p>
<h1>■ LT登壇内容</h1>
<ol>
<li>株式会社SmartHR プロダクトエンジニアグループ 高倉 拓也様 <strong>「スプリントゴールと仲良くしたい」</strong></li>
<li>株式会社Another works CTO 塩原 基弘 <strong>「エンジニアが要件定義に上手く絡むには」</strong></li>
<li>株式会社SmartHR プロダクトエンジニア 根岸 勇弥 <strong>「ミッションから紐解く、フィーチャーチームへの意識改革」</strong></li>
<li>株式会社Another works PdM 宮内 北斗 <strong>「エンジニアリングがどうプロダクトの企画に活きるのか」</strong></li>
</ol>
<h2>1.「スプリントゴールと仲良くしたい」</h2>
<p>高倉 拓也 株式会社SmartHR プロダクトエンジニアグループ / <a href="https://speakerdeck.com/tkkrtky/supurintogorutozhong-liang-kusitai">登壇資料</a><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/f64aecd4-4ce1-4433-ae4f-9c1470dbf9e7/part1.jpeg" alt="part1.jpeg"></p>
<p>内容</p>
<ul>
<li>LeSSを導入していると各チームで触る機能が異なり共通のスプリントゴールを設定するのが難しい</li>
<li>スプリントゴールが先にあって、それをもとにプロダクトバックログアイテムを選択する方法を１チームで試してみた</li>
<li>プランニングのタイミングで顧客価値を設定</li>
<li>得られた効果
<ul>
<li>コミュニケーションや意思決定の面で恩恵を受けることができた</li>
<li>顧客の価値について考える習慣ができた</li>
</ul>
</li>
</ul>
<p>ひとことレポート</p>
<p>チームの中で「共通の言葉」がある姿が、非常に良いなと感じました！<br>
細かな方向性の違いも「共通の言葉」によって正せそうですね。</p>
<h2>2.「エンジニアが要件定義に上手く絡むには」</h2>
<p>塩原 基弘 株式会社Another works CTO / <a href="https://drive.google.com/file/d/19S2UO-8usmiqndc-Oy9bEqb4z7bJ9gBg/view?usp=sharing">登壇資料</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/3e5e7293-1533-4436-b1ad-7d6d39ea3f0d/part2.jpeg" alt="part2.jpeg"></p>
<p>内容</p>
<ul>
<li>「要求定義」と「要件定義」
<ul>
<li>要求定義：誰のどの課題を解決するか（What）なぜその課題を解決するのか、課題であるのか？（Why）</li>
<li>要件定義：どういう手段で解決するのか？（How）</li>
</ul>
</li>
<li>要求定義が終わった段階で、それを元に要件定義書を Pdm・デザイナー・エンジニア含め４人くらいで同期的に作成する「要件定義会」を導入してみた
<ul>
<li>エンジニアの役割：課題解決手法の立案、コストの見積もり</li>
</ul>
</li>
<li>要件定義に積極的になるにはどうすれば良いか
<ul>
<li>意見を出すのが難しい時はピンポイントで考えてみる</li>
<li>定期的にサービスを触る癖をつける</li>
</ul>
</li>
</ul>
<p>ひとことレポート</p>
<p>「エンジニアのみなさん、要件定義は好きですか？」の問いから始まった本セッションでは、弊社チームの取り組みである「要件定義会」や「毎朝QA」が紹介され、改めてその開催意味を理解しながら聞いていました。<br>
それぞれの専門領域を活かして異なる提案が出てくる要件定義会は、施策の質・スピード共にアプローチできる良い方法だなと感じました！</p>
<h2>3.「ミッションから紐解く、フィーチャーチームへの意識改革」</h2>
<p>根岸 勇弥 株式会社SmartHR プロダクトエンジニア / <a href="https://speakerdeck.com/negi_andleek/mitusiyonkaraniu-jie-ku-huitiyatimuhenoyi-shi-gai-ge">登壇資料</a><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/eaf75e14-e925-4f02-a1e3-b7c71d1a6a7d/part3.jpeg" alt="part3.jpeg"></p>
<p>内容</p>
<ul>
<li>課題：組織の拡大に伴い分業化が進み、顧客価値を中心にチームで働くのが難しい</li>
<li>顧客中心の機能を実現する、安定した長期存続することを目的としたフィーチャーチーム誕生
<ul>
<li>フィーチャーリードを通じてプロダクトエンジニアも使用について考えるようになった</li>
<li>課題解決のために、第三の案を考えられるようになった</li>
</ul>
</li>
<li>チームとして、プロダクトに責任を持つことは大事</li>
<li>チームの意識・体質を改善するには時間がかかるが、良いプロダクトを作ろうという共通認識を持っているのは悪いことではない</li>
</ul>
<p>ひとことレポート</p>
<p>顧客価値に徹底したフィーチャーチームとても格好良いなと思いました！<br>
こういったチームを筆頭にメンバー全員が顧客価値志向なエンジニアになった時には色んな Howが出てきて楽しみだなと感じました！</p>
<h2>4.「エンジニアリングがどうプロダクトの企画に活きるのか」</h2>
<p>宮内 北斗 株式会社Another works PdM / <a href="https://drive.google.com/file/d/1ZkvglS4P0x4lPAz8-XI0xOGdw85skMqi/view?usp=sharing">登壇資料</a><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/fcec7c8f-889b-4470-b129-f2b7f5432c3a/part4.jpeg" alt="part4.jpeg"></p>
<p>内容</p>
<ul>
<li>元エンジニアが PdMをやってよかったと思ったこと
<ul>
<li>エンジニア、デザイナーとコミュニケーションが取りやすい</li>
<li>課題に対する解決策の具体性や実現性が高い</li>
</ul>
</li>
<li>エンジニアとして施策の価値向上に貢献できること
<ul>
<li>要件定義のブラッシュアップ
<ul>
<li>ユースケース漏れ許さないマン</li>
<li>そもそもマン（本当に必要か？）</li>
<li>シンプルis正義マン</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>ひとことレポート</p>
<p>エンジニア出身の PdM だからこそ思う、エンジニア知識があってよかったと思うこと、エンジニアに頼りたいことが聞けました！<br>
個人的には「ユースケース漏れ許さないマン」を尊敬しており、目指してみようと思いました！</p>
<h1>■ 交流会</h1>
<p>交流会は、LT登壇者と当日お越しいただいたオーディエンスの方々で行いました。<br>
LTの内容についての深掘りや考え、技術の話、それぞれのチームの取り組み… など様々な話題で大変盛り上がりました！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/498a611f-afb9-46c9-85ed-5a7f265b86f6/PXL_20230725_122252457.MP.jpg" alt="PXL_20230725_122252457.MP.jpg"></p>
<h1>■ 最後に</h1>
<p>Another works では今後も学びと交流の場となるイベントを開催していく予定です！</p>
<p>Connpassでグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！</p>
<p><a href="https://anotherworks.connpass.com/">Another works Connpass</a></p>
<p>なお今回のイベントの感想など #AwEngineerMeetup のハッシュタグ付きでツイートをして盛り上げていただけると嬉しいです！</p>
<p>SmartHRの皆様、ご参加いただいた皆様、本当にありがとうございました！！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/d2a0f35a-c394-4c7c-99ce-44a24007e91f/PXL_20230725_114625834.MP.jpg" alt="PXL_20230725_114625834.MP.jpg"></p>


Another works × SmartHR【顧客に価値を届けるプロダクト志向なエンジニアリング】イベントレポート

<p>こんにちは！Another works エンジニアのまっちです！</p>
<p>今回は、弊社 <strong><a href="https://anotherworks.co.jp/">Another works</a> と <a href="https://www.hrbrain.co.jp/about/">HRBrain</a></strong> さんで 2023/6/28(水) に開催したLT×交流会 <a href="https://anotherworks.connpass.com/event/285380/">プロダクト開発を支える技術</a> のイベントレポートをお届けします！</p>
<h1>■ イベントの概要</h1>
<p>今回は 3/30(木)に開催した <a href="https://anotherworks.connpass.com/event/276673/">Front-end Meetup 2023</a> に引き続き HRBrain さんオフィスをお借りして共催イベントを開催！</p>
<p>弊社イベントはこれまで、フロントエンドをテーマに数多く開催してきました。</p>
<p>今回は “プロダクト開発を支える技術” と、いつもと異なるテーマの開催だったのでドキドキでした！</p>
<p>そのようななか、オフライン、オンライン合わせて40名ほどの方にご参加いただきました！！</p>
<p>ありがとうございます！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/1eedf2d8-3275-40ad-bf00-3a03fa00fe79/PXL_20230628_103202096.jpg" alt="PXL_20230628_103202096.jpg"></p>
<h1>■ LT登壇内容</h1>
<ol>
<li><strong><a href="https://twitter.com/bellwood4486">鈴木 善晴</a> 氏 株式会社HRBrain テックリード： 「マイクロサービスのローカル開発環境をTiltを使って2年運用して得た知見」</strong></li>
<li><strong><a href="https://twitter.com/MotohiroSiobara">塩原 基弘</a> 株式会社Another works 取締役CTO：「施策のPDCAを回すためのデータ分析基盤」</strong></li>
<li><strong><a href="https://twitter.com/ingtk8">稲垣 隆徳</a> 氏 株式会社HRBrain テックリード：「ChatGPTとPythonを用いた高速なデータ可視化プロトタイピング」</strong></li>
</ol>
<h2>1.「マイクロサービスのローカル開発環境をTiltを使って2年運用して得た知見」</h2>
<p><strong><a href="https://twitter.com/bellwood4486">鈴木 善晴</a> 株式会社HRBrain テックリード / <a href="https://speakerdeck.com/bellwood4486/maikurosahisunorokarukai-fa-huan-jing-wotiltwoshi-tute2nian-yun-yong-sitede-tazhi-jian">登壇資料</a></strong><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/3ac01b79-3fe6-42a2-8c27-3dc50bec4b49/PXL_20230628_104529498.jpg" alt="PXL_20230628_104529498.jpg"><br>
<strong>内容</strong></p>
<ul>
<li>Tiltベースの弊社の開発体験の紹介</li>
<li>Tilt導入の工夫や得られた知見</li>
</ul>
<p><strong>ひとことレポート</strong></p>
<p>Tilt を利用することにより、マイクロサービス構成を気にさせない開発体験はいいなと感じました！</p>
<p>開発環境改善は日々の業務をするなかで優先順位付けが難しくなかなか着手し辛い側面があります。</p>
<p>その文脈ででた話で、開発体験の悪さから生じる憤りをエネルギーに変換することを「怒り駆動開発」という言葉で表現されていて、個人的にツボでした。笑</p>
<p>HRBrain さんのサービスも開発チームも成長し続けるなかでの生の話が聞けて非常に学びあるお話でした！</p>
<h2>2.「施策のPDCAを回すためのデータ分析基盤」</h2>
<p><strong><a href="https://twitter.com/MotohiroSiobara">塩原 基弘</a> 株式会社Another works 取締役CTO / <a href="https://drive.google.com/file/d/10rXQj6jqELGQixIMAUSPjI6n1V51-z24/view">登壇資料</a></strong><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/3661c92f-0a59-4d8f-946b-a24e2d6b26f8/PXL_20230628_110608327.MP.jpg" alt="PXL_20230628_110608327.MP.jpg"></p>
<p><strong>内容</strong></p>
<ul>
<li>分析基盤の概要</li>
<li>ログデータを BigQuery に取り込む</li>
<li>分析用ログを Cloudwatch に吐き出す</li>
<li>まとめ
<ul>
<li>データの活用は後からでもできるけど、基盤の構築は早い方がいい</li>
<li>厳密であることはコミュニケーションをシンプルにする</li>
<li>厳密さを保ちつつ、コストを下げることはセットでやるべき</li>
</ul>
</li>
</ul>
<p><strong>ひとことレポート</strong></p>
<p>データ分析においてデータサイエンティスト、PdM、実装者と関係者が多い故にコミュニケーションが繁雑になってしまう。この現状に対して ALL TypeScript で対応しているなどの工夫の部分が「なるほど」と改めて勉強になりました！</p>
<h2>3.「ChatGPTとPythonを用いた高速なデータ可視化プロトタイピング」</h2>
<p><strong><a href="https://twitter.com/ingtk8">稲垣 隆徳</a> 株式会社HRBrain テックリード / <a href="https://speakerdeck.com/ingtk/chatgpttopythonwoyong-ita-gao-su-nadetake-shi-hua-purototaipingu">登壇資料</a></strong><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/c0f257bc-a899-4c88-9250-c171d4cc1421/PXL_20230628_111936489.MP.jpg" alt="PXL_20230628_111936489.MP.jpg"><br>
<strong>内容</strong></p>
<ul>
<li>バックエンドエンジニアのプロトタイピングへの関わり方
<ul>
<li>なぜプロトタイピングをやるのか</li>
<li>プロトタイピングの課題</li>
</ul>
</li>
<li>データ可視化アプリケーションを爆速で作る</li>
</ul>
<p><strong>ひとことレポ</strong></p>
<p>最近弊社 Another works でも最近プロトタイピングを取り入れて開発をしていたのでタイムリーでした。実際に動くものを見せることでコミュニケーションが円滑になるという話は非常に納得でした！</p>
<p>あと個人的に “LLM アイデアソン” を実施したというのが非常にうらやましかったです。うちでもやりたい。。。</p>
<h1>■ 交流会</h1>
<p>交流会にはLT登壇者も参加しました。</p>
<p>LT内容についての話や、技術の深い話、普段の開発におけるあれこれ、など最後まで大変盛り上がり、話題の尽きない時間でした！<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/1ab56a86-21d7-4291-899a-bd7838bcac67/PXL_20230628_115818845.jpg" alt="PXL_20230628_115818845.jpg"></p>
<h1>■ さいごに</h1>
<p>Another works では今後も学びと交流の場となるイベントを開催していく予定です！</p>
<p>Connpassでグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！</p>
<p><a href="https://anotherworks.connpass.com/">Another works Connpass</a></p>
<p>なお今回のイベントの感想など <strong>#AwEngineerMeetup</strong> のハッシュタグ付きでツイートをして盛り上げていただけると嬉しいです！</p>
<p>HRBrain のみなさま、ご参加いただいたみなさまありがとうございました！<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/bf64f452-ca3e-453e-b33d-08cbdcae37ec/PXL_20230628_113759123.MP(1).jpg" alt="PXL_20230628_113759123.MP(1).jpg"></p>


Another works × HRBrain 【プロダクト開発を支える技術】イベントレポート

<h1>はじめに</h1>
<p>Another works でエンジニアをしているまっちです！</p>
<p>今回は**【package.json】 バージョンにつける「^」「~」は何を意味するのか？**というテーマを深掘って書いていきます！</p>
<p>自分の感覚では<code>^</code>チルダはじまりで<code>package.json</code>にのバージョン指定がされているライブラリが多い印象です。<br>
そこで <code>^</code>や `~' ってなんでつけてるの？<br>
という疑問から色々と調べたことを書いていきます。</p>
<pre><code class="language-json:package.json">  &quot;dependencies&quot;: {
    &quot;react&quot;: &quot;^18.2.0&quot;, // これ
    &quot;next&quot;: &quot;~12.0.2&quot;, // これ
    ,,,
</code></pre>
<h1>^ 表記で破壊的な変更がない範囲で最新バージョンを利用できる</h1>
<p><code>package.json</code>に<code>^</code>表記でバージョン指定が多い理由として<br>
<code>package</code>を破壊的な変更がない範囲で最新の機能を利用できるバージョンにできる（はず）だから、</p>
<p>と考えました。(違ったらすみません！)</p>
<p>その理由を後述していきます。<br>
前提として、</p>
<ul>
<li><code>package.json</code>の仕様</li>
<li><code>npm</code>の推奨しているセマンティックバージョニングについて<br>
理解したあと、</li>
</ul>
<p><code>package.json</code>のバージョン指定方法を説明しながら考えてみます。</p>
<h1>前提１： package.json にはバージョン範囲を記述する</h1>
<h4>package.jsonには</h4>
<p>インストールする package の範囲を記述します。</p>
<h4>package.lock.jsonには</h4>
<p>実際にインストールされている package のバージョン（などの）情報が記載されます。<br>
つまり、<code>node_modules</code>に入っている package 郡の情報が記載されます。</p>
<h1>前提２: npm の推奨しているセマンティックバージョニング</h1>
<p>ざっくり、<code>npm</code>はパッケージを<br>
<strong>意味のある数字でバージョンを管理しようぜ</strong>、ということを推奨しています。<br>
※<a href="https://eow.alc.co.jp/search?q=semantic">セマンティック(semantic)</a>: 意味の, 語義の, 意味論的な<br>
https://docs.npmjs.com/about-semantic-versioning</p>
<p>このセマンティックバージョニングではバージョンを表す3つの数字<code>x.x.x</code>に<br>
<code>[major, minor, patch]</code>という意味をもたせています。<br>
それぞれの意味するところは次のようなものです。</p>
<ul>
<li><code>major</code>: <code>前のバージョンと互換性を損なう変更</code>をするときに上げる数字</li>
<li><code>minor</code>: <code>前のバージョンと互換性を持つ新機能追加の変更</code>をするときに上げる数字</li>
<li><code>patch</code>: <code>前のバージョンと互換性を持つバグ修正の変更</code>をするときに上げる数字</li>
</ul>
<p>※つまり<code>majorアップデート</code>では<strong>破壊的な変更を含む可能性が高い</strong>ということです。</p>
<h4>例を用いて考える</h4>
<p><code>3.4.5</code>というバージョンが最新の<code>package</code>があった場合、<br>
セマンティックバージョニングに則れば</p>
<ul>
<li><code>majorアップデート</code>を3回</li>
<li>3系になって(<code>majorアップデート</code>3回目以降)から
<ul>
<li><code>minorアップデート</code>を4回</li>
<li><code>patchアップデート</code>を5回</li>
</ul>
</li>
</ul>
<p>おこなっているpackageということになります。</p>
<h1>package.json のバージョン指定方法</h1>
<p><code>~</code>, <code>^</code>を含めて大きく4つのバージョン指定方法があるようです。<br>
https://www.npmjs.com/package/semver/v/4.3.6</p>
<h3>1. バージョンの数字のみ記載</h3>
<p>範囲なし(固定)<br>
記載したバージョンをインストールする。</p>
<p><code>1.2.3</code>: 1.2.3 (記述したバージョンのみ許容)</p>
<h3>2. <code>x</code> or <code>*</code></h3>
<p><code>x</code>, <code>*</code>を記載した箇所のバージョン更新を許容</p>
<ul>
<li><code>*</code> : &gt;=0.0.0 (どのバージョンの更新も許容)</li>
<li><code>1.x</code> : &gt;=1.0.0 &lt;2.0.0 (major バージョン以外の更新を許容)</li>
<li><code>1.2.x</code> : &gt;=1.2.0 &lt;1.3.0 (patch バージョンだけの更新を許容)</li>
</ul>
<h3>3. <code>~</code>チルダ</h3>
<p>minorバージョンが指定されている場合、patchバージョンの変更を許容。そうでない場合は、minorバージョンの変更を許容。</p>
<ul>
<li><code>~1.2.3</code>: 1.2.3以上 1.3.0未満</li>
<li><code>~1</code>: 1.0.0以上 2.0.0未満</li>
</ul>
<h3>4. <code>^</code>キャレット</h3>
<p>３つの数字<code>[major, minor, patch]</code>で１番左側にある<code>0</code>でない数字を変更しない更新を許可。（ややこしい）</p>
<ul>
<li><code>^1.2.3</code>:1.2.3以上 2.0.0未満(1の変更は許容しない）</li>
<li><code>^0.2.3</code>:0.2.3以上 0.3.0未満(2の変更は許容しない）</li>
<li><code>^0.0.3</code>:0.0.3以上 0.0.4未満(3の変更は許容しない,つまり変更不可？)</li>
</ul>
<p>つまり<code>major</code>バージョンの更新を許容せずに最新バージョンに更新することを許容するようです。</p>
<h2>なるほど、つまり</h2>
<p><code>^</code>チルダ表記でバージョン指定をすれば前のバージョンとの互換性を保ちながら、最新バージョンに保たれる可能性が高いといえます。</p>
<p>ただし、セマンティックバージョニングに則っているpackageであること(majorアップデート以外で破壊的な変更がされない)という前提があります。</p>
<h1>さいごに</h1>
<p>恥ずかしながら今回書いたことは調べるまで知らないことだらけでした。<br>
ライブラリ(package)の開発者も利用者もセマンティック バージョニングについて理解しながら開発をすることが大事だと感じました。</p>
<p>お読みくださりありがとうございました！</p>
<h1>参考</h1>
<p>参考にさせていただきました。ありがとうございました。</p>
<ul>
<li>https://zenn.dev/luvmini511/articles/56bf98f0d398a5</li>
<li>https://zenn.dev/ikuraikura/articles/d6ff3821017e29539a7a</li>
<li>https://www.npmjs.com/package/semver/v/4.3.6</li>
<li>https://docs.npmjs.com/about-semantic-versioning</li>
</ul>


【package.json】 バージョンにつける「^」「~」は何を意味するのか？

<p>こんにちはAnother works CTOの塩原です。</p>
<p>複業クラウドのバックエンドではDDDとクリーンアーキテクチャを導入しています。</p>
<p>社内では、<a href="https://twitter.com/little_hand_s">松岡さん</a>の書籍やTwitterなどを参考にしながらDDDの開発に取り組んでいます。</p>
<p>DDDの記事は参考になるものが松岡さんの記事やその他の人が書いた記事など豊富にあるため、設計方法についてはそこまで困ることはありません。</p>
<p>DDDの記事を見ているとJavaやKotlin、Scalaだったり、一部フレームワーク独自構文を使ってDDDを実装しているものも多いため、今回はTypescriptで実装するための方法を記事にすることで、Node.jsを使っている方や、Typescriptを使っている方に参考になればと思い、書かせていただきました。</p>
<h1>この記事で書くこと・書かないこと</h1>
<h2>書くこと</h2>
<ul>
<li>ドメインイベントをTypescriptで実装する方法</li>
</ul>
<h2>書かないこと</h2>
<ul>
<li>ドメインイベントを始め、DDDに関する説明</li>
</ul>
<h1>シナリオ</h1>
<p>求人作成した際に、求人のデータなどを把握することができる求人レポートを生成することができる</p>
<h3>簡易ドメイン図</h3>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/d788e481-82e5-4a50-90d5-36177a978ec8%2F%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882022-12-1914.46.59.png" alt="スクリーンショット2022-12-1914.46.59.png"></p>
<h3>イベント周りの処理フロー図</h3>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/9f479852-ad4c-40cd-90b6-b57992fc4188%2F%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882022-12-1914.53.43.png" alt="スクリーンショット2022-12-1914.53.43.png"></p>
<h1>ドメインイベント</h1>
<p>まずはドメインイベントクラスを実装します</p>
<p>EventListenerでイベントごとに実行する処理を変える必要があるので、nameで判断できるようにします</p>
<pre><code class="language-tsx">export type DomainEventName = 'projectCreateEvent'

export interface DomainEvent {
    name: DomainEventName
}

type ProjectInfo = {
  title: string
}

/**
 * 求人作成イベント
 */
export class ProjectCreateEvent implements DomainEvent {
    name: 'projectCreate' = 'projectCreate'
    projectInfo: ProjectInfo

    constructor(params: { projectInfo: ProjectInfo }) {
        this.projectInfo = params.projectInfo
    }
}
</code></pre>
<h1>ドメインイベントの生成</h1>
<p><code>DomainEventStorable</code> という抽象クラスで、エンティティーがイベントを保持するための機能を抽象化しています。</p>
<p><code>ProjectDomainModel</code>で継承し、create関数の中で <code>ProjectCreateEvent</code> を発火するようにしています。</p>
<pre><code class="language-tsx">export abstract class DomainEventStorable {
    private domainEvents: DomainEvent[] = []

    protected addDomainEvent(domainEvent: DomainEvent) {
        this.domainEvents.push(domainEvent)
    }

    getDomainEvents(): DomainEvent[] {
        return this.domainEvents
    }

    clearDomainEvents() {
        this.domainEvents = []
    }
}

export default class ProjectDomainModel extends DomainEventStorable {
  constructor() {
    super()
    //...
  }

  static create(title: string) {
    //...
    // 
    model.addDomainEvent(
        new ProjectCreateEvent({
            projectInfo: {
                title
            },
        })
    )
  }
}
</code></pre>
<h1>イベント発行処理</h1>
<p>Node.jsにはEventEmitterという標準クラスがあり、イベント処理など行えるので <code>DomainEventListener</code> というクラスを使ってイベント処理をラップしています。</p>
<p><code>DomainEventPublisherImpl</code> はイベントを発行する処理で <code>ProjectRepositoryImpl</code> の関数の引数に渡して、repository内でpublish処理を行うようにする</p>
<p>publishする処理はドメインイベント全体で共通となっているので、ドメインイベントごとに作成する必要はありません。</p>
<pre><code class="language-tsx">import EventEmitter from 'events'

const emitter = new EventEmitter()
emitter.setMaxListeners(0)
export class DomainEventListener {
    static on&lt;T extends DomainEvent&gt;(
        eventName: T['name'],
        callback: (event: T) =&gt; void
    ) {
        emitter.on(eventName as string, callback)
    }

    static emit(eventName: DomainEvent['name'], event: DomainEvent) {
        emitter.emit(eventName as string, event)
    }
}

export interface DomainEventPublisher {
    publish(event: DomainEvent): Promise&lt;void&gt;
}

export class DomainEventPublisherImpl implements DomainEventPublisher {
    async publish(event: DomainEvent): Promise&lt;void&gt; {
        try {
            DomainEventListener.emit(event.name, event)
            new DomainEventEntity(DotEnvConsts.getFcLoggerEnv())
                .setData({
                    eventInfo: JSON.stringify(event),
                    eventName: event.name,
                    time: new DateLib().formatDate(
                        new Date(),
                        'YYYY-MM-DD HH:mm:ss'
                    ),
                })
                .save()
        } catch (e) {
            SentryLib.captureException(e)
            LoggerLib.error(`${event.name}: ${e};event: ${event}`)
        }
    }
}

export class ProjectRepositoryImpl implements ProjectRepository {
  async save(
        model: ProjectDomainModel,
        publisher: DomainEventPublisher
    ): Promise&lt;void&gt; {
    // 保存処理
    model.getDomainEvents().forEach((event) =&gt; publisher.publish(event))
  }
}
</code></pre>
<h1>イベントリスナー</h1>
<p>イベントリスナークラスはドメインごとに複数作成します。</p>
<p>今回イベントを受け取って振る舞いを定義するのはProjectReportになるので、 <code>ProjectReportListener</code>として作成して受け取ったイベントの振る舞いを定義しています。</p>
<pre><code class="language-tsx">export class ProjectReportEventListener {
  
  constructor(private repository: ProjectReportRepository) {
        DomainEventListener.on&lt;ProjectCreateDomainEvent&gt;(
            'projectCreate',
            (event: ProjectCreateDomainEvent) =&gt;
                this.callback(event)
        )
  }
  
  private callback(event: ProjectCreateDomainEvent) {
    // repositoryを使って、ProjectReportのsave処理を行う
  }
}

// index.ts
createConnection().then(() =&gt; {
    app.listen(DotEnvConsts.getAppPort(), () =&gt; {
        LoggerLib.debug(`Start on port ${DotEnvConsts.getAppPort()}.`)
        // Event Lisntenerを起動
        new ProjectReportEventListener()
    })
})
</code></pre>
<h1>まとめ</h1>
<p>今回はNode.jsとTypescriptを使って実装する方法を書きました。</p>
<p>TypescriptはkotlinやScaleなどと比較すると型システムとして足りない機能などありますが、ジェネリクスなどをうまく使うことでやりたいことを達成することができます。</p>


Node.jsとTypescriptでドメインイベントを実装する

<p>オブジェクトの型を指定するインターフェースに関してですが、クラスに関しても使えるということで、特に抽象クラスの定義について色々と調べてみました。</p>
<h2>TypeScriptにおけるクラスとは</h2>
<p>実はTypeScriptでは、JSよりも前にクラスを備えていました。<br>
特徴として、TypeScriptのクラス構文では2つの異なる側面を併せ持ちます。</p>
<h3>インターフェースとしての型宣言となる</h3>
<p>型のコンテキストにおいてはインターフェースとして扱われます。</p>
<h3>コンストラクタ関数(通常のクラスとして)</h3>
<p>コンストラクタ関数とかくとややこしいですが<strong>要は普通のクラス構文</strong>として振る舞うということです。JavaScript, TypeScriptではクラスはシンタックスシュガーであり、その実態はプロトタイプオブジェクトを継承してオブジェクトインスタンスを生成するための独立した関数となっています。</p>
<h2>抽象クラスの定義</h2>
<p>クラスが宣言されたとき、インターフェースとしての側面と通常のクラスとしての側面を併せ持つと言いました。よって抽象クラスにも2つの定義の仕方が存在します。<br>
抽象クラスとはそれ自身がインスタンスを生成できず、継承されることを前提としたクラスです。</p>
<h3>abstract修飾子</h3>
<p>まずは通常のクラスの扱いとしての見慣れているやり方ですね。抽象クラスをabstract修飾子で定義し、それをextendsによって継承して実装するというものです。</p>
<pre><code class="language-typescript">abstract class Rectangle {
  sideA: number;
  sideB: number;

  constructor(sideA: number, sideB: number) {
    this.sideA = sideA;
    this.sideB = sideB;
  }

  getArea = (): number =&gt; this.sideA * this.sideB;
}

class Square extends Rectangle {
  side: number;
  constructor(side: number) {
    super(side, side);
  }
}
</code></pre>
<p>ポイント</p>
<ul>
<li>実装の詳細を抽象クラスでかけてしまう</li>
<li>継承先で再実装しなくてもエラーにならない</li>
</ul>
<h3>interface</h3>
<p>初めに、クラスを定義したときはそれは型のコンテキストではインターフェースの定義と同等となるという説明をしました。<br>
つまりクラスはinterfaceを継承することができます。<br>
implementsを使用します。</p>
<pre><code class="language-typescript">interface Shape {
  readonly name: string;
  sideA: number;
  sideB?: number;
  sideC?: number;
  sideD?: number;
  getArea: () =&gt; number;
}

class Rectangle implements Shape {
  readonly name = 'rectangle';

  sideA: number;

  sideB: number;

  constructor(sideA: number, sideB: number) {
    this.sideA = sideA;
    this.sideB = sideB;
  }

  getArea = (): number =&gt; this.sideA * this.sideB;
}

</code></pre>
<p>インターフェースはもともとオブジェクトの型定義に使用されるものですがJavaScriptのスーパーセットであるTypeScriptではJavaScript同様にクラスとオブジェクトの間に本質的な区別はないからです。<br>
クラスももとを辿ればオブジェクト。なのでインターフェースで型定義することができ、またそれを継承することができます。</p>
<p>ポイント</p>
<ul>
<li>型だけを定義し、実装漏れを確実に防ぐ</li>
<li>？によって柔軟性をもたせることができる</li>
<li>実装の詳細を継承元で書かなくて済む</li>
</ul>
<h2>抽象クラスの弱点と　interfaceの良さ</h2>
<p>abstract修飾子は、実は実装の詳細を含むことができてしまいます。本当は実装すべきメンバの型だけを定義したいのにも関わらずです。これが唯一のabstract修飾子による抽象クラス定義の弱点でしょうか。</p>
<p>DRYでコードを書くことはRubyでも口酸っぱく言われていますが、継承というのは親に強く依存してしまいバグの発見がしづらくなるという理由から「継承よりも合成を使う」という考え方のほうが主流になりつつあるようです。<br>
比較的新しい言語であるGoやRustでは実装を伴った継承がそもそも存在しません。</p>
<p>その点インターフェースでは実装を伴わない型のみの定義が可能であり、抽象クラスの定義として優れています。</p>
<h2>結論</h2>
<p>よほどのことがない限り、クラスの定義はinterfaceを使ったほうが良いのではないのでしょうか。<br>
その「よほどのこと」というのも現時点では私の中では出てきていないので、もしユースケースがあれば教えていただきたいです！</p>


TypeScriptのabstractとinterfaceを比べてみた

<h1>はじめに</h1>
<p><code>TypeScript</code>での<code>null</code>と<code>undefined</code>の使い分け方に対する考えと、<code>null</code>と<code>undefined</code>の違いについて、自分なりに調べて学んだことを書いていきます。</p>
<h1>どっちを使うべき？</h1>
<p><strong><code>undefined</code>を積極的に利用していくべき</strong><br>
（<code>null</code>の利用を避けられない場合を除いて）</p>
<p>ではないか、という結論になりました。</p>
<p><code>TypeScript</code>開発チームのGithub wiki にあるコーディングガイドにも</p>
<blockquote>
<p>Use undefined. Do not use null.</p>
</blockquote>
<p>「<code>null</code>は使用せず、<code>undefined</code>を使用してください。」<br>
と記載されています。<br>
（あくまで<code>TypeScript</code>の開発チーム内での決め事ではありますが、）</p>
<p>https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined</p>
<h1>null と undefined の違い</h1>
<p><code>null</code>も<code>undefined</code>もプリミティブ型の値の一つ。<br>
どちらも「値が存在しない」ことを表現するものであるものの、<code>null</code>と<code>undefined</code>には明確な違いがある。</p>
<h2>意味合いでの違い</h2>
<p><strong>null</strong>: 代入すべき値が存在しないため、値がない（変数がメモリに対する参照を保持しない）<br>
<strong>undefined</strong>: 値が代入されていないため、値がない（変数が未定義である、初期化されていない）</p>
<h2>言語使用上での違い</h2>
<h2>nullは自動的に設定されないが、undefinedは自動的に設定される</h2>
<p><strong>null</strong>: 開発者が意図的に設定しない限り設定されない。<br>
<strong>undefined</strong>: 開発者が意図しなくても、自動的に設定される。</p>
<pre><code class="language-js">// 変数を宣言したときに初期値が存在しなければ、その変数にundefinedが設定される。
let value;
console.log(value); //=&gt; undefined
</code></pre>
<pre><code class="language-js">// オブジェクトに存在しないプロパティや配列にない要素にアクセスしたときも、自動的にundefinedになる。
const obj = {};
console.log(obj.foo); //=&gt; undefined
const arr = [];
console.log(arr[0]); //=&gt; undefined
</code></pre>
<pre><code class="language-js">// 戻り値がない関数の戻り値を取得したときもundefinedになる。
function func() {}
console.log(func()); //=&gt; undefined
</code></pre>
<h2>nullはリテラル、undefinedは変数</h2>
<p><strong>null</strong>: <a href="https://wa3.i-3-i.info/word15346.html">リテラル</a>なのでnullという名前の変数を作ることはできない。<br>
<strong>undefined</strong>: 変数なので<code>undefined</code>という変数を作ることができる。（グローバルより内側のスコープに限る）</p>
<p>※ ちなみに<code>window</code>オブジェクト（グローバルオブジェクト）は<code>undefined</code>というプロパティを持っている。この初期値は<code>undefined</code>。</p>
<table>
<thead>
<tr>
<th>コンソール（Google Chromeディベロッパーツール）</th>
</tr>
</thead>
<tbody>
<tr>
<td><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/621162/7c7bab83-0ee4-18e6-7b19-2c2f3ae481a2.png" width="300" /></td>
</tr>
</tbody>
</table>
<h2>typeof の挙動</h2>
<pre><code class="language-js">typeof null          // &quot;object&quot; (歴史的な理由で &quot;null&quot; ではないらしい)
typeof undefined     // &quot;undefined&quot;
</code></pre>
<h2>isNaN の挙動</h2>
<pre><code class="language-js">isNaN(1 + null)      // false
isNaN(1 + undefined) // true
</code></pre>
<h2>JSON での挙動</h2>
<p><strong>null</strong>: 設定できる。<br>
<strong>undefined</strong>: 設定できない。</p>
<pre><code class="language-js">console.log(JSON.stringify({ foo: undefined })); //=&gt; {}
console.log(JSON.stringify({ foo: null })); //=&gt; {&quot;foo&quot;: null}
</code></pre>
<h1>おまけ</h1>
<h2>== と === で比較</h2>
<pre><code class="language-js">null === undefined   // false
null  == undefined   // true
</code></pre>
<h1>まとめ</h1>
<p>冒頭でも述べた通り、<code>TypeScript</code>での開発では<br>
<code>null</code>の利用を避けられない場合を除いて、<code>undefined</code>を積極的に利用していくべき、かなと考えました。</p>
<p>理由としては、<br>
「値が存在しない」ことを表現する方法を、「自動的に発生してしまう<code>undefined</code>」に寄せた方が統一しやすいから、と思いました。（日本語難しい...）</p>
<p>ただ一方で、<code>null</code>を返すAPIなどのハンドリングをする場合などは<code>null</code>の利用を避けられなかったりするので、完全に<code>null</code>を利用しないことは難しいのかもしれない。</p>
<p>いろいろと調べてきたものの、</p>
<blockquote>
<p>使い分け意識を育てる労力は、それに見合うメリットが少ない</p>
</blockquote>
<p>との意見もありました。</p>
<h2>参考</h2>
<p>ありがとうございました！</p>
<ul>
<li>https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/null</li>
<li>https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/undefined</li>
<li>https://typescriptbook.jp/reference/values-types-variables/undefined-vs-null</li>
<li>https://typescript-jp.gitbook.io/deep-dive/recap/null-undefined</li>
<li>https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines#null-and-undefined</li>
<li>https://www.amazon.co.jp/%E7%8B%AC%E7%BF%92JavaScript-%E6%96%B0%E7%89%88-CodeMafia-%E5%A4%96%E6%9D%91-%E5%B0%86%E5%A4%A7/dp/479816027X/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&amp;keywords=%E7%8B%AC%E7%BF%92JavaScript&amp;qid=1639187025&amp;s=books&amp;sr=1-1</li>
</ul>


【JavaScript / TypeScript】null と undefined の違いと比較

<p>こんにちは。みやぞんです。<br>
かなり前の話ですが、MySQLのインデックスについて調べたことがあり、<br>
そのメモが残っていたので共有します。</p>
<p>インデックスとはなんぞやってところからB-tree構造まで、広く浅く調べたのでまとめてみました。</p>
<h2>インデックスとは</h2>
<p>インデックスは特定のカラムの、あるレコードをすばやく見つけるために使用されるものです。検索が爆速になります。</p>
<p>本を読む時、章ごとに付箋みたいなのを貼っておくと目的のページにたどり着くのが早いのと同じです。(貼らない人は、目次とか索引とかイメージしてもらえれば)</p>
<p>インデックスがないとMySQLは関連するレコードを見つけるために、先頭行から始めてテーブル全体を読みとらないといけなくなります。(<strong>フルテーブルスキャン</strong>)<br>
広辞苑くらいぶ厚い本に索引がなかったり、あいうえお順になっていなかったりしたら...大変ですよね...。</p>
<h2>インデックスの貼り方</h2>
<p>検索をかけるカラムにインデックスを貼るだけ。ほんと簡単なのでやらないのは損。<br>
参照コマンド(自分が貼ったインデックスがわかります。<strong>機能しているとは限りません。</strong>)</p>
<pre><code class="language-sql">SHOW INDEX FROM テーブル名;
</code></pre>
<p><strong>作成コマンド</strong></p>
<pre><code class="language-sql">ALTER TABLE テーブル名 ADD INDEX インデックス名(カラム名);
</code></pre>
<p><strong>削除コマンド</strong></p>
<pre><code class="language-sql">ALTER TABLE テーブル名 DROP INDEX インデックス名;
</code></pre>
<h2>インデックスの効果</h2>
<p>今回はあるテーブルのcategoryカラムにインデックスを貼ってみました。<br>
以下は250万弱のレコードのうち、カテゴリーナンバーが'5'である約２万レコードを抽出した時の例です。</p>
<p><strong>インデックスがない場合</strong><br>
<img src="https://i.imgur.com/e2EMAHY.png" alt=""></p>
<p><strong>インデックスを貼った場合</strong><br>
<img src="https://i.imgur.com/1H3CusK.png" alt=""></p>
<p>以上から分かるようにかかる時間が全然違います。</p>
<p>念のため、本当にインデックスが効いているかどうかをEXPLAINってやつを使って確認しましょ。</p>
<h2>クエリのパフォーマンスを見るEXPLAIN</h2>
<p>インデックスが効いているかどうかを実際に知るには、EXPLAINをクエリの頭につけて実行し確認する方法があります。</p>
<p>以下のコマンドで、どうぞ。</p>
<pre><code class="language-sql">EXPLAIN SELECT カラム名1, カラム名2... FROM テーブル名 WHERE 条件...;
</code></pre>
<p>コマンドを実行すると以下のような結果に。(見づらいけど)<br>
<img src="https://i.imgur.com/RUe6Njx.png" alt=""></p>
<p>これは、データベースからレコードを引っ張ってきているわけではなくクエリ実行時のパフォーマンスを表しています。<br>
１回目の実行結果はインデックスが効いている場合、２回目の実行結果はインデックスが効いていない場合です。<br>
色々読み方が難しいので、ここではインデックス実行時に見るべきところだけを説明します。</p>
<p><strong>type</strong><br>
レコードへのアクセス方法。ここが<code>ref</code>となっている場合は、constではないインデックスを使って等価検索を行いアクセスしたことを表しているとのこと。とりあえずこれならOK。<br>
<code>ALL</code>って書いてある場合は、<strong>フルテーブルスキャン</strong>していることを表し、インデックスが全く使用されていないことを示すため注意が必要です。</p>
<p><strong>possible_keys</strong><br>
貼られる可能性のあるインデックスを示す。ここでは<code>price</code>のみとなっているが、複数つけた場合は複数表示される。例えば<code>category</code>, <code>price</code>とあったら、カテゴリー順のインデックスと、値段順のインデックスどっちでも使える状態だよってことです。実際に使用されているわけではありません。</p>
<p><strong>key</strong><br>
実際に使用されているインデックス。ここに希望のインデックスがあるかどうか確認します。もちろん<code>possible_keys</code>の中から選ばれます。ここでは、使われたインデックスが<code>price</code>であることがわかります。</p>
<p><strong>rows</strong><br>
そのテーブルから参照される行数の<strong>大まかな</strong>見積もり。これがインデックスを貼った時に減っていればインデックスが効いていることになります。</p>
<p>だいたいこの辺の項目を見ておけばインデックスが効いているかがわかります。</p>
<h2>インデックスってなんで早くなるの？</h2>
<p>早くなるからただ使っているっていうのは、なんだか気持ち悪いので色々仕組みを調べてみました。</p>
<p>インデックスを貼ると、検索用に最適化されたデータベースが生成されるそうで、それを参照することで処理するレコード数を効率的に減らしているらしいです。<br>
検索用のデータベースってなんぞやってのを理解するためには、データ構造のひとつでMySQLが採用している<strong>B+tree構造</strong>(びーぷらすつりーこうぞう)について理解する必要があります。<br>
ですが、やや複雑ですのでよりシンプルな<strong>B-tree構造</strong>について先に説明します。</p>
<h3>B-tree構造</h3>
<p>一種のデータ構造のことで、下図のとおり二分探索しやすいように値を大小で振り分けたデータ構造のことを言います。MySQLでインデックスを貼る時に生成されるデータベースはこの構造になっています。</p>
<p><img src="https://i.imgur.com/VY8ZzIv.png" alt=""></p>
<p><strong>上図右側</strong><br>
インデックスを貼ってない普通のデータ構造です。先頭から順に計算していくため、ある一つのデータを抽出するためには最大７回の計算をしなければならないことになりますね。</p>
<p><strong>上図左側</strong><br>
対して<strong>B-tree</strong>は、ターゲットが中央値より大きいか小さいかで分岐させ、それを繰り返す二分探索をするため計算は最大３回で済みます。<br>
このデータ構造の仕組みにより、検索を高速化できます。</p>
<p>この**O(n)**ってやつのOはOrderで計算量を表します、()内のnはレコード数になります。インデックスを使うことで計算量は対数関数的に減っていきますよって感覚がわかりますね。テーブルが大きくなれば受ける恩恵は大きいってことです。</p>
<h3>カテゴリー検索例</h3>
<p>簡単な例を作ってみた。</p>
<p><img src="https://i.imgur.com/jbxJvpt.png" alt=""></p>
<p>インデックスが貼られた時、検索時に使用するデータを新たに生成します。それが上図右側のB-tree構造のデータです。</p>
<p>検索をかけた時には、検索用のB-tree構造のインデックスデータにアクセスし、該当するレコードだけを引っ張り出します。</p>
<p>例えば、category'2'を抽出したい時、普通であれば全レコード総数と等しい１５回の計算を行わなければなりません。しかしインデックスを貼った場合には、２回の計算で済むため効率的に目的のレコードを参照できることがわかります。</p>
<h4>補足</h4>
<p>以上の例では7種類の値をもつカテゴリーカラムに対してインデックスを使用する場合を例にあげました。B-tree構造を簡潔にしたいがためにそのような例にしましたが、実際にこのような貼り方は好ましくありません。詳しくは&quot; <a href="#%E5%8E%9F%E5%89%87%E3%81%AF%E3%82%AB%E3%83%BC%E3%83%87%E3%82%A3%E3%83%8A%E3%83%AA%E3%83%86%E3%82%A3%E3%81%8C%E9%AB%98%E3%81%84%E3%82%82%E3%81%AE%E3%81%AB%E8%B2%BC%E3%81%A3%E3%81%A6%E3%81%84%E3%81%8F">カーディナリティの高いものから貼っていく</a> &quot;に記載しています。</p>
<h3>実際のMySQLはB+tree構造を採用している</h3>
<p>名前が似ていてややこしいですがB+tree(びーぷらすつりー)について説明します。実は、MySQLはこっちの構造を採用しています。B-treeと似ているようで若干構造が異なります。<br>
とはいっても先ほどのB-tree構造を理解してしまえば簡単です。以下はB-treeとB+treeの構造を比較したものです。<br>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/386799/a263692d-a888-439d-e699-2dc945e56c60.png" alt="Untitled Diagram (3).png"><br>
今までに説明したB-treeは一番下の段(リーフノード)だけではなく一段目(ルートノード)、二段目(子ノード)にもデータを持たせており、探索時、上流でヒットすればそれだけ早く計算が終了するという特徴があります。<br>
それに対して<strong>B+tree</strong>では、リーフノードに全ての情報を持たせており、かつそのそれぞれを繋げています。上流にはデータを持たせていません、あくまで計算して分岐させるだけです。<br>
何が利点かというと、<strong>範囲検索に強い</strong>ことです。例えば3〜５の検索をした時、３までたどり着けばそのまま横にずれて4と5の条件も拾っていけます。B-treeだと範囲検索時はいちいち上流から計算し直さなければなりません。これがB+treeの利点です。</p>
<h2>インデックスを貼るときの注意点</h2>
<h3>インデックスをむやみに貼らない</h3>
<p>じゃあインデックスとりあえず全部貼っておくかってなりそうだけどそうはいきません。</p>
<h4>B-treeを生成するデメリット</h4>
<ul>
<li>データ容量を圧迫する</li>
<li>データ挿入時、更新時に処理が重くなる</li>
</ul>
<p>これらは検索用のデータを新たに生成する事による弊害です。<br>
データを増やすことが容量を圧迫することになるのは容易に想像できますね。<br>
また、データ挿入や更新時には他の全てのインデックス用データベースも更新しなければなりません。インデックスを１個しか使わなくていいものを１０個貼ったのなら、９個分のデータベースを余計に更新することになります。このことにより処理が重くなります。</p>
<p>ではどのようにインデックスを貼っていけば効率的なのでしょうか。</p>
<h4>原則はカーディナリティが高いものに貼っていく</h4>
<p><strong>カーディナリティ</strong>は多重度とか、選択度という意味があります。好みですが、選択度の方が理解しやすい気がします。</p>
<p>これはどういうことかというと、カラム内の値の種類が２種類しかない時、例えば男女で分ける場合には絞り込み度は50％となります。50%というのはカーディナリティがかなり低い部類に入ります。これはインデックスを貼ってもあまり効果が見込めません。</p>
<p>対して500万レコードの顧客情報に苗字カラムがあったとして、その種類が5千種類だとすると、インデックスを貼った場合の絞り込み度は0.02%になります。これはカーディナリティの高い状態であり、インデックス使用時の効果が高くなります。</p>
<p>ですので、原則インデックスはカーディナリティの高いものに貼っていくべきで、低いものに貼る場合にはしっかり効果を確認して判断する必要があります。(低いものでも効果が見込める場合があるため)</p>
<h3>インデックスが適用されない場合もある</h3>
<p>他にも、インデックスを貼ったはずなのに効いてないこともあるので注意が必要です。<br>
以下のような時にはインデックスは適用されません。</p>
<ul>
<li>LIKEが%で始まる場合</li>
<li>DB全体を読んだ方が早いとMySQLが判断した場合(レコードが全体の30%を超える場合や、1000件未満の場合など）</li>
<li>ORDER BYを使用している場合</li>
</ul>
<p>他にも色々あるので調べてみてください！<br>
とりあえず効いてるかはEXPLAINで必ず確認しておくといいと思います。</p>
<h2>参考</h2>
<p><a href="https://dev.mysql.com/doc/refman/5.6/ja/mysql-indexes.html">8.3.1 MySQL のインデックスの使用の仕組み</a><br>
<a href="https://qiita.com/C058/items/1c9c57f634ebf54d99bb#%E3%83%81%E3%83%A5%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AE%E3%83%A1%E3%83%A2">MySQLでインデックスを貼る時に読みたいページまとめ(初心者向け）</a><br>
<a href="https://qiita.com/kiyodori/items/f66a545a47dc59dd8839">B-treeインデックス入門</a></p>


#Backend

Another works × SmartHR【顧客に価値を届けるプロダクト志向なエンジニアリング】イベントレポート

Another works × HRBrain 【プロダクト開発を支える技術】イベントレポート

【package.json】バージョンにつける「^」「~」は何を意味するのか？

Node.jsとTypescriptでドメインイベントを実装する

TypeScriptのabstractとinterfaceを比べてみた

【JavaScript / TypeScript】null と undefined の違いと比較

MySQLのインデックスの仕組み

#Backend

Another works × SmartHR【顧客に価値を届けるプロダクト志向なエンジニアリング】イベントレポート

Another works × HRBrain 【プロダクト開発を支える技術】イベントレポート

【package.json】 バージョンにつける「^」「~」は何を意味するのか？

Node.jsとTypescriptでドメインイベントを実装する

TypeScriptのabstractとinterfaceを比べてみた

【JavaScript / TypeScript】null と undefined の違いと比較

MySQLのインデックスの仕組み

【package.json】バージョンにつける「^」「~」は何を意味するのか？