機能の多量生産から大量生産へ PandP part1

大量生産とは、単なる多量生産ではない。
(中略)
大量生産とは、動力、正確さ、経済、システム、継続性、スピードの原則に基づいた製造プロジェクトだ。

技術革新と不平等の1000年史　下より

---

ということで、技術革新と不平等の1000年史が面白かったので いくつか抜粋して個人的な所見や考察をメモ的に出力していきます。

原題はPower and Progress: Our Thousand-Year Struggle Over Technology and Prosperityであり、 海外ではPandPと略されているようで、そちらを踏襲しています。

この本の構成について

基本的な引用が下巻からになってしまうので、言い訳というか、構成について触れます。 PandPは上下巻で分かれており、上巻の前半では抽象・要約的な話を、後半から1000年史をたどっていき、11世紀〜19世紀について触れています。
下巻では19世紀から20世紀のより技術革新の速度が早くなった世界について、よりじっくりと事例も含めて語られています。

下巻を読んでから、上巻の前半を読むと具体例を思い出し、また楽しく読めるというスルメ的な側面もあります。

そういうことで、より具体的な引用をするに際して下巻が中心となっています。

多量生産と大量生産について

最初の引用をみていこう。 多量生産とは、手段を問わず大量にものを作ることを指している。

例えば、人数を増やす・残業時間を増やすといったことで生産数を増やすことも多量生産になる。

一方で、大量生産は引用の通り、製造プロジェクトである。

引用はヘンリー・フォードの言葉だ。 フォードは機械を導入し、工場を再編・社員へのトレーニングを行い機械や工場の動きについての知識を与え多量生産から大量生産に移った。 実際フォードの行ったことと大量生産の要件は以下のように紐づくだろう

• 動力：機械化による生産能力の向上
• 正確さ：機械化や作業の標準化によって品質のばらつきの減少
• 経済：工程改善や規模の拡大によって、一単位あたりの生産コストの減少
• システム：工場・工程・役割を一つの生産システムとしての再設計
• 継続性：教育や待遇改善によって、安定して生産を続けられる状態への移行
• スピード：工程間の停滞を減らし、生産全体の流れを高速化する

AIによる多量生産

この引用文を真っ先に思いついたのがこれだった。

この時代において、エンジニアは無限に機能を作ることができる。
すでにエンジニア以外が機能を作っている企業もあるだろう。

そこで気になるのが、その作り方が大量生産の要件を満たしているかだ。
大量生産の要件をITエンジニア的に読み替えてみる。

• 動力：自動化・AIによるレバレッジ
• 正確さ：再現性・品質保証
• 経済：投入したコストに対するアウトカム
• システム：標準化・仕組み化
• 継続性：持続可能な開発・運用
• スピード：スループットやリードタイム

2026年9月現在、AIで課題とされているのは再現性と継続性だ。 その大量のコードを誰が持続するのか、 同じプロンプトで再現性を出せるのか、

これらはある程度エージェントやSkillをはじめ、各種ハーネスを用いることで解消が可能だが
それらができていないのであれば単なる多量生産と変わらない。

そうした仕組みが存在しないまま単純にコードや機能を増やしているのであれば、
それは大量生産ではなく、AIを使った多量生産になってしまう。

極端に言えば、AIという大量の労働力を投入し、とにかく機能を作らせている状況。
フォードが工場そのものを設計し直したように、AI時代にはAIを導入するだけではなく、
AIを前提として開発システムそのものを再設計することが必要になるのだろう

誰でも作れること・なんでも作れることの落とし穴

個人的に6つの中で重要に感じるのが「経済/アウトカム」だ。
多くのエンジニアが経験している「この機能作ったけど使われないなあ」を防ぐ手段はまだない。

AIによって今まで作るのが難しかった機能も今では作れてしまう。
それもエンジニアでなくともだ。

それらを正しく分析・検討して検証のために機能として出すのであれば、何も問題はない。
一方で「この機能が欲しいと問い合わせがあった」の場合は問題となる。
顧客は自身の表層の問題は出すが、根本的な問題は言わないことが多い。

なぜそれが必要なのか。 その機能を使って何をしたいのか。 本当に解決したい問題は何なのか。

「人々が欲しいのは1/4インチのドリルではなく、1/4インチの穴だ」

セオドア・レビット

今はカスタマーサクセスがPRを投げられる時代だ。
「ここにCSVダウンロード機能が欲しい」をそのまま受け取るのではなく
「そのCSVで何をするのか」まで把握することが、以前より重要になっているのではと感じる。

作ることが難しかった３、4年前は実装コストそのものがある種のブレーキとして機能していた。
しかしAIによってそのブレーキは外れ、作れるものを作るのではなく、なんでも作るに変化した。
そうなってくると、作るべきものを選ぶ能力の価値が相対的に高くなったように感じる。

AIは、多量生産を驚くほど簡単にした。
次は「大量生産」に変えるための業務・組織設計と、そもそも何を生産するべきなのかを判断する力なのかもと感じる

読書が贅沢になりつつある

これはかなりアルコールが入った状態で書いています。 マノックモア美味しい🥃

読書が贅沢になりつつある

AIの台頭によって、あらゆるデータに簡単にアクセスできるようになった。

本の要約も、論文の整理も、以前よりずっと簡単になった。
そんな時代に、あえて本を読む意味について書いてみたい。

本、読んでますか？

論文に関しては、正直あまり読んでいない。

最近はNotebookLMに放り込んで、マインドマップを作らせるのが個人的な流行りだ。

要約というより、章立てや論点のつながりを見やすく構成してくれる。
そのため、全体感の把握から個別の要素の確認まで、かなり効率よくこなすことができる。

GEPAの論文でのマインドマップ on NotebookLM

正直、これがあれば全文を読む必要はほとんどない。

全体の要約はすでにされている。
要素の把握もできる。
自分が特に知りたい部分にも、すぐにたどり着ける。

それでも、僕は本を読む。

混ざる前に溢れていく

アイデアやひらめきとは、コップに知識という水を溜め込み、それが溢れたときに生じるものだと思っている。

ただし、溜め込めばいいというものでもない。
じっくりと混ざる時間が必要なのだ。

AIを使ったインプットは、とにかく速い。
必要な情報をすぐに取り出せるし、読むべき箇所も教えてくれる。

だが、その速さゆえに、知識が自分の中で混ざりきらない。

コップの中に、水とワインとウイスキーのように比重が異なるものが混ざっている。 そこにさらに注いでも、後から入れたものがただ溢れるだけになる。

今の自分のインプットは、少しそれに近い。

だから、コップの中の液体を混ぜる時間が必要になる。
それが読書なのだと思う。

瞑想という名の読書

文章を噛み、今ある自分の知識と合わせて咀嚼する。
すぐに答えへ飛ばず、行間で立ち止まる。
その時間の中で、ばらばらだった知識が少しずつ混ざっていく。

そしてようやく、アイデアやひらめきに昇華される。

以前は、本を読んでから瞑想することで、そうした整理をしていた。
だが、AIによってインプットの速度があまりに速くなりすぎた。

となれば、咀嚼するタイミングを変える必要がある。

僕にとって、それが読書に成り変わった。

もちろん、瞑想は続ける。
瞑想はさらに高い視座から、思考全体を整理するための時間だからだ。

けれど、AI時代における読書は、もはや単なる情報収集ではない。

読書は、知識を集めるための行為ではなくなりつつある。
知識を自分の中で混ぜるための、贅沢な時間になりつつある。

だいたい誰かがボールを拾わされている

こにふぁーさんの以下の記事が非常に良かったので僕も筆を取ってみようと思いました。 こにふぁーさんの記事では、間に落ちそうなボールを拾う人の葛藤や、その後どう振り返るべきかが書かれていました。

僕は「で、拾われなかったボールは最終的にどこへいくの？」について個人的な経験多めで書いていきます

konifar-zatsu.hatenadiary.jp

間に落ちるボールはどこへいく？

どこへいくんでしょうね。大体の場合、3だと思っています。

1. 誰かが拾う
2. 誰も拾わない
3. 誰かが拾わされる

3だと何が問題なのか。

自部署のボールの場合

リーダーやその機能・プロダクトに詳しい人が指摘されて対応する形になるでしょう。

指摘されて対応するので、意外と緊急性が高まっていたり、純粋に急にタスクが増えるというストレスがあります。

他部署からのボールの場合

大体リーダー層にメンションが飛びます。 その後リーダーが対応するか、リーダーがメンバーにタスクをパスする事になることが経験上多いです。

個人的にこちらの方がリスクは高く、以下の2つがネックになります。

1. エンジニアメンバーへの不信感が高まる
2. リーダーの時間が取られる

他部署とキャッチボールをする

エンジニアメンバーへの不信感が高まることの課題は色々あります。

• 会議において発言を通しにくい
• 改善の要望が他部署から出てこない など、期待されないことに繋がってきます。

お互いのチームが全力でやっているということを常に対話を通して動けている組織であれば、 上記のような問題は出てこないかもしれません。 しかし、そのような環境でない場合は、いかに対話しやすい状態にできるかが重要になります。

そこには投げたボールを取ってくれるという信頼は絶対条件だと思っています。 もちろん「ただボールを拾ってやる」のではなく、意味を考えて対話することが前提です。

これらの信頼がないと以下のような損失につながります。

「エンジニアチームに言ってもしょうがないしなあ」 1. スプレッドシートで管理するか a. 自動化や知識かの阻害 2. この問い合わせはお礼で対応するか a. 不要なリソースの消費

よく分からないボールが、強い駒の動きを止める

突然ですが、僕はワールドトリガーの弱い駒の理論が好きです。

「弱い駒が強い駒の働きを止めてる」ってのが既に戦果として充分なんだ」

ワールドトリガー9巻より

今回でいえば、結局リーダーの時間が奪われるというのが大きな問題だと思っています。 間に落ちるボールで言うと

間に落ちるボールというよく分からない駒に、リーダーという強い駒の動き止められている

と言う状態なわけです。 もちろん、よく分からない駒なので、実は強い駒の可能性があります。 しかし、それを分析することができます。 本当に強い駒、自分が敵わない駒であればリーダーにヘルプを求めればいいのです。

なぜボールを拾うのか

エンジニア組織にもメリットがあり、個人の成長や立場が有利になりやすいからです。 後者は割と現金な理由です。

エンジニア組織のメリット

まず、知っている人が増えます。 すなわち属人化の防止につながります。

また、知らない→知るという過程の中での学びを社内Wiki、Claudeをお使いであればSkillやknowledgeにしておくことで 誰でも参照可能になります。

個人的に以下の部分が最大のメリットだと感じています。

知らない→知るという過程の中での学びを言語化する

個人のメリット

純粋に他のメンバーから信頼を得られます。 積み重ねていくと、気づいたら存在しない役割が与えられたりします。

「サブリーダーってかっこう君だよね？」

とか

「この分野ってかっこう君強いよね？これいける？？」

のようなことが増えてきます。

こう言うことをやっていくと自分が会社でできることも増え、給料も増えやすくなるのでおすすめです。

ボールを落ちる前に拾うことの良さ

間に落ちるボールを拾うことは、ただの雑用ではありません。

もちろん、全部を拾い続ける必要はないし、一人が拾い続けている状態は健全ではありません。 それでも、ボールを拾うことで見える景色はあります。

どこに情報がないのか。 誰が困っているのか。 どこで信頼が途切れているのか。 何を言語化すれば次から楽になるのか。

そういうものを見つけて、WikiやSkillや仕組みにしていく。 そこまでやって初めて、拾わされたボールが組織の資産になるのだと思っています。

副業でバーを始めてました。準備から半年まで振り返り

週1モルトバー始めました

というわけで始めてから半年くらい経ったので振り返りです。

https://www.instagram.com/bar.casadh/

書いてあることの要約

• 副業の利点
  • 節税や副業を始める時の注意ごと的なこと 副業を始めたい人はここだけさらっと読んでください
• 生成AIと副業
  • 本業と違う業界で働く際の生成AIの強みについて、デザインの代行からマルチエージェントを含めた活動方針の委託がある程度できている

なんのお店？

ーズや限定ボトルが中心のモルトバー

小田原にバーは数あれど、意外とボトラーズがあるお店って少なかったりします。

加えて、僕が無駄に趣味でウイスキーエキスパートなど資格を持て余している＋よくいくお店のマスターから促されたのが要因となります。

副業の利点

さて、それでは副業の利点についてさらっていきましょう。

基本的に副業の利点は節税にあります。開業届を出して副業を青色申告を行うことで家賃や電気代、各種デバイス代などを経費として計上し控除することができます。

この辺に関しては、節税に詳しいライオンの動画をご覧ください。

そのため、基本的に副業を行うのであればエンジニアは特に自宅できる開発をすべきです。

僕の場合は、生涯で飲みきれない酒を減らすことであったり、ボトラーズというオフィシャルとは違うウイスキーの楽しさを広めることを目的にしています。

副業の準備

開業と青色申告申請

これらはマネーフォワードの開業申請のサービスが非常に簡単です。

というのも、これを使うことで開業届と青色申告申請の2つを意識せずにセットで行うことができます。

税理士の方とも話しましたが、手動で行うと以下のようなミスをやらかして節税できず逆に辛い思いをする方もいるとのことで、セットでやってくれるというのは非常に心強いです。

手動でやると開業届だけして青色申告申請を忘れてて一番出費のある1年目に特別控除が受けられない人が時折いる

衛生管理責任者になる

飲食店を経営するにあたって、必須になるのが衛生管理責任者の資格です。

これは1店舗に一人は必要なので、基本的に店長がとることになります。

昔は1日かけて講座を受ける必要がありましたが、現在はオンラインで自分のできる時間に受講することができるため、仕事終わりに1時間をこつこつやるだけで資格を得ることをできるのでオンラインがおすすめです。

ロゴデザイン

お店を持つにあたって楽しく難しいところの1つが、店名とアイコンだと思います。

正直ここがネックで今まで開業しようと思っていなかったところがありますが、現在は生成AIのおかげで自分のイメージに合わせてアイコンを作ることが可能になりました。

当時はChatGPTがメインでしたが、現在はGeminiの🍌など色々な選択肢がありますね。

また、名刺や店舗カードの作成もイラストレーター完全初心者でも、一週間の無料期間内で作成できるレベルなのでAIの下駄の高さを再認識しました。

場所を確保する

副業の中でも飲食店の難易度が高い理由はここだと思います。

現在はシェアキッチンなども増えてきていますが、僕の場合は幸運にもよくいくバーを貸していただけることになりました(もちろんお金は払っています)。

オープン前のクラウドファンディングの支援もしていたこともあってか、非常に良くしてくださっているので感謝しかありません。

運営する

さてここからはどうやってマネタイズをしていくかです。

なんせ間借りで週1なので、認知を得る方法やインスタの運用など様々なところを考える必要があります。

これに関してはautogenを使うことで、初心者でも様々な施策を打つことができました。

役職を適当に設定し動かすことで、以下のように今後の動き方やブランディングをどう作るかのテンプレ的な動きがわかります。

## 各エキスパートからの最終アドバイス

### 🎯 マーケターより

「Instagram運用の鍵は**継続性**です。完璧を目指さず、まずは週3回のストーリーズとフィード投稿を習慣化してください。リール動画は最初は質より量で構いません。3ヶ月続ければ必ず結果が出ます」

### 📍 地域活性化コンサルタントより

「小田原という地域で長く愛されるバーになるためには、**地域コミュニティとの信頼関係**が重要です。間借りのマスターとの良好な関係、商店街との連携を大切にしてください。3ヶ月後には『地域に根ざしたバー』として認知されるはずです」

### 💰 ファイナンシャルアドバイザーより

「黒字化達成後も、**経費計上の最適化**を継続してください。青色申告特別控除65万円を活用すれば、年間の節税効果はさらに大きくなります。副業として健全な財務状態を維持することが長期継続の鍵です」

### 🎨 クリエイティブディレクターより

「SNSは『情報発信』だけでなく、**ストーリーを語る場**です。『なぜあなたがこのバーをやっているのか』『なぜボトラーズなのか』という想いを、写真や動画を通じて伝えてください。共感した人が必ず来店してくれます」

### 💼 ビジネスストラテジストより

「この3ヶ月は**基盤構築の期間**です。焦らず、一つ一つの施策を丁寧に実行してください。週次で振り返り、効果のある施策に資源を集中する。このPDCAサイクルを回せば、必ず目標は達成できます」

上記だけでなくSNS投稿のテンプレなど、

「まぁ妥当だろうな」という結果が出てくるので非常に面白いです。

売上は？

当たり前のように現在は赤字です。

これに関してはおおよそ想定通りです。

幸いにも、身内以外のリピート率は高く小田原の本格的なモルトバーの需要はありそうでした。

これからはボトルの購入頻度を抑えて、新規をどれだけ増やすかというAutoGenの結果の通りの動きをしていく形です。

最後に

小田原にきた際にはぜひお越しください。 日曜日以外は小田原で唯一のフルーツカクテルが楽めるお店なので、ぜひ

従業員効率を高めていくエンジニアを考える

なんの記事か

従業員満足度(以下、EX)に対してエンジニアが寄与する意義と、どのようなモチベーションで何を行うのかということ。

簡単にまとめると、書籍「みんなでアジャイル」の理想的な状態になるような組織に、エンジニアマターで進めていくこともできるんじゃない？という個人的な推論です。

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

冒頭

そもそもEXとは以下の定義とされていることが多いです。

仕事内容・職場環境・人間関係・給与待遇・福利厚生・ワークライフバランスなど、従業員が「仕事と職場に関してどれくらい満足しているのか」を示す指標

こう見るとかなりHR領域に近いのですが、

この中でも「仕事と職場に関してどれくらい満足しているのか」の「仕事に関してどれくらい満足しているのか」の部分を解決することでEXを高めて行こーという話になります。

EXを高め従業員が円滑に動くことでCS・利益や利益につながる各部署、会社全体のPDCAの速度を高めることが目的になっていきます。

何がいいのか

上述のことを踏まえると、当記事におけるEXの定義は「仕事に関してどれくらい早くこなせるか・PDCAを回せているか」と言ってもいいでしょう。

私たちの会社のメンバー行っていることを自動化、または無くしていくことで、たとえばマーケティングなら施策のテストサイクルを早くする、CSならば対象とするユーザーの絞り込みや、どの層を対象とするかをより分析することが理想となります。

何をするか

個人的には以下を順にやっています。

1. 他のチーム・部署が行なっていることの把握
2. 作業の中のボトルネックや無駄に見えるチャットの把握
3. 「こうなればいいのになー」を拾い上げる・引き出す

上から順にやっていくことで、信頼を得て課題や理想を話してくれるようになります。

ただ、最終的な目標は組織全体のPDCAを早くすることであり、目の前の人の持つ課題を解決することではないことは意識すべきです。

1,2はよくある話ですが「無駄に見えるチャットの把握」は注意が必要です。

自動化を行う時のデメリットとして、自動化することで今まで確認していたことが確認できなくなるということがあります。

これは壮子の羽鶴瓶の逸話からも汲み取れますが、自動化することで確認できず静かに状態が悪化していくことがあります。そのため、自動化すべきなのか・自動化すべきではないのか・自動化しても通知などの工夫が必要なのかなどチャットの前後作業を把握する必要があります。

また、「こうなればいいのになー」とぼやいているところに「なんでそう思うんですか！？」と積極的に話しかけにいくのは根本的な課題を探るだけでなく、後々「これできないですか？」という相談を受けるキッカケにもなるのでとても重要です。

これができると、勝手に課題が回ってくるようになるので非常に簡単になってきます。

最後に

この方法は比較的ベンチャー向けだと思っています。大きい企業では、縦割りも大きく他の部署は独立して最適解やKPIを設定することが多いためです。

一方でベンチャーでは、部署ごとにKPIがあったとしても企業としての成長が最重要な事項になります。そのために、企業全体のPDCAを早く回す必要があり、エンジニアは他の部署に比べ「広い視点・長い視点」を持っており、そう言った環境づくりに対して最適だと考えています。

ベンチャー初期であれば機能優先になるかもしれませんが、ある程度軌道に乗ってくれば他のチームのサポートをするのもありな選択ではないかと考えています。

「クリーンアーキテクチャ」選択を残して開発をするための設計

adventar.org

気づいたら時は流れ、アドカレ16日と＋X日になっていた...

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

というわけで最近また話題になっていたクリーンアーキテクチャについてです。

書籍『Clean Architecture』を読んで理解すると「クリーン・アーキテクチャで作りました」という発言は出なくなる。わかる。 pic.twitter.com/LkrWiNF1IP

— Takuto Wada (@t_wada) 2024年1月11日

このツイート、私も実際にクリーンアーキテクチャを読了して「わかる！！！」となったので、その辺りを話せればなと思います。

このよく見るあの図だが、本書では1度しか登場していません。 また、文脈としてもヘキサゴナルアーキテクチャやDCIアーキテクチャ、BCEなど様々なアーキテクチャの特性を統合したものとしている。

よく見るあの図

すなわち、「クリーンアーキテクチャ」というアーキテクチャというものはそもそも存在していません。では、本書が語っているクリーンアーキテクチャとは何なのか、なぜ行うのからに触れながら個人的に気になったところを書いていこうと思います。

なぜ設計を考える必要があるのか

ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。

様々な設計に関する本で語られている様に、この書籍でも技術的負債を溜め込まずリリースごとに労力が増えるといった状態になるのを回避することを考えている。

変更の難易度は、変更の形状ではなく、変更のスコープに比例しなければいけない。

これは非常によくある悪い状況の見方だなと感じる。

例えば画面に表示する1文を変更する要望があったとする。コードを見てみると、その文字列を別のところでも使っていてそっちの修正も必要になってきて、あれDBにも保存している？という厄介な問題になることがある。

これは変更の形状に対して、難易度が圧倒的に高い。よく設計が出来ていればスコープを文字程度簡単に修正し、ビジネスロジックの大きな変更など大変だと思われるものに、その通りの難易度が伴う形になる。

関心事の分離と依存関係のコントロール

個人的にこの書籍で最も語りたいところがこの部分だと感じる。

よく見るアーキテクチャもこの部分の影響を強く表しているという風に感じますね。

関心事をドメインなのか・技術なのかに分離し、ドメインが技術に依存しない様にコントロールする。これをするために、オブジェクト指向の様々な手法を使うことが記載されているのが本書になります。

この様に関心事を分離し、依存関係のコントールをすることで"ドメインに関してはフレームワークも含め、全てから独立させるべき"ということが実現します。

さてこれができると何がいいのか、ドメインにフレームワークやライブラリなどが依存している場合、それらの影響を受けることになります。それがバージョンアップならばまだ良いですが、放棄でもされた時には溜まったものではありませんからね。

また、ドメインを独立させるためにフレームワークの選定にも注意を促しています。

フレームワークの作者にとって、自分の作った基底クラスを大勢のユーザーが継承することほど、自尊心が満たされることはない。

少しマサカリのようだが、この様な記載がある。一旦モヤモヤを取り払い、性善説的に「大勢が基底クラスを継承することで新たな価値を提供しやすくなるために基底クラスを継承させたがっている」とでも解釈しておこう。

フレームワークをドメインに依存させない方法は簡単で、Entitiesなど内側に入れないこと、円の外側に対してのみ使用する。

関心事の分離と選択肢

この書籍はソースコードレベルの話ではなく、DBや提供する方法も含め"変更を容易にする設計をどの様にするか"という話になっています。

その中でデプロイという話も入っており、昨今のマイクロサービスの話が脳裏をよぎった。さて、ここでマイクロサービスでサービスを作った時、いざリリースの時に起動のタイミングなどが重要になったりする。

関心事を適切に分離することで、DBや提供方法といった"プロダクトの価値以外の選択肢を残すことができる"ことも利点となります。

クリーン・アーキテクチャで作りましたと言えなくなるについて

私個人の感想ですが、「作りました」と言っている時点でクリーンアーキテクチャではないと言えるのでは？と感じました。

なぜならばクリーンアーキテクチャとは、選択肢を常に残すことでプロダクトの提供方法といったビジネス的な決定や、技術選定を遅らせたり、移行のしやすさを保っているソフトウェアだからです。

なので、クリーンアーキテクチャかどうかは実際に運用に乗せ様々な課題を軽く往なせるかというところで判断するしかないのだと私は思っています。

「失敗から学ぶRDBの正しい歩き方」いつの間にか辛いを避ける歩き方

adventar.org

アドカレ15日目

失敗から学ぶRDBの正しい歩き方 Software Design plus

プロダクトコードの負債より、DBの負債の方が大変だと感じています。DBの負債を変える場合、プロダクトコードにあるDBの読み込み・更新まで全て変更する必要がありますからね。

そういった点でも、いつの間にか沼地に迷い込んでいたということが起きないような道標になる良本です。

MySQLはjoinでNLJしか対応していない

Nested Loop Joinの略で参照される行数分だけループが行われるというもの。

dev.mysql.com

JOINの対象となるカラムにINDEXを貼ると速くなるのは参照去れる行数が減ることだったらしい。逆にFORCE INDEXで安定して早くなる理由も納得がいった。こういうのはやはり実装などをみておかないといけないなーと感じたところ。

Ruby on Railsなどは外部キーを作ると自動でインデックスも貼ってくれて、本当に意識せずに全部やってくれるなぁと感心する。

Viewテーブルかサマリーテーブルか

複雑なSelectクエリの発効が余儀なくされる場合の選択肢として、個人的にはViewを使うことが多いです。理由としてはやはり変更に強いこと。

サマリーテーブルはトリガーのタイミングなどを含め、実装が非常に複雑になる場合が多かったり、いざ即時のデータが欲しくなると時間がかかったりと痛い目を見たことが多いというのもあります。

Viewテーブルも参照時にクエリが走るなど辛くなってくる段階があるので、「そもそももっと使いやすい形にできないか」を考えてDB設計を考える必要がありますね。この辺はカーディナリティなどの話でも出てきますがデータの偏りなどを予想する必要が多いので「どのような特性のデータか」というところは十分に理解してからDBを設計する必要があるし、腕の見せ所だよなーとなるところ

クラウドやツールの大切さ

バックアップからログ、DBのモニタリングまで本当にクラウドの恩恵を受けていたのだなと感じるクラウド世代でした。

特にDBのチューニングなどは監視ツールを入れることで、スロークエリの順位なども見れるので立ち向かい方が変わってきます。特に、1ユーザーだけ特殊のデータの偏りをしていてインデックスが効いていないなど面白いことが見つかりますし、コンクションプーリングができていないなどの早期発見にもつながります。

本当に監視ツールは偉大。また、どこを監視するかについては監視入門などの書籍に譲ろうと思います。

また、クラウドの利点として「強制的にバージョンを上げさせられる」というものもありますね。19章の塩漬けのバージョンの対策にもなります。強制的にバージョンをあげるので、単なる利点とも言えませんが怠惰を重んじるエンジニアにとって、こういう強制性は重要になってきますね。

フレームワークと実行計画

ここで筆者のツイッターを見てみましょう。

ORMが吐くSQLは人類にもRDBMSにも厳しい

— そーだい@初代ALF (@soudai1025) 2018年5月28日

そう。ORMの作るクエリは人類には厳しすぎるんです。Ruby on Railsの作るクエリなどをみていると「え、何このクエリ。え、でも実行計画はいい感じだな」となることがあります。これは正しく外部キー制約が貼られているおかげでもありますね。

ただ、フレームワークのORMに依存しすぎて、実際のクエリをみない人がそこそこいるのも悲しいことです。どのようなクエリが作られ、どのような実行計画になるのかは常に確認するようにしようね！！！

状態を管理する

アンチパターンの1つだがとても見る。ユーザーテーブルにある権限のカラム、受注テーブルにある受注状況のカラムなど様々な状態を管理するカラムを見てきたし戦ってきた。

特定の状態毎にテーブルを作るのが良いのは本書を読めばよくわかるが、なぜそれをしないのか・思いつかないのかを考えていく。状態ごとによって持つ情報が変わること知らない知識の不足もあるし、単純に実装の容易さもあるだろう。また、論理削除と同様に考えるというのもありそう。何より状態が増えるたびにテーブルが増えるということも問題となるのだと思う。

人間の記憶の特性として、7つ以上のものは記憶や理解が辛くなってくる。そのため、状態毎のテーブルやそれに関係するテーブルが自身の理解できる範囲内に収めようという思考が働くように感じる。命名などで群として捉え易くするなど、人間が情報処理しやすい命名や設計も重要になりそうだ。

他にも

ロックなどいろいろなことが書かれているので是非

MySQLのギャップロックなど、DBによる特殊な挙動など専門書を読むとより詳しく書かれているのでそちらを読むと良さそうです