iOSアプリの自動更新サブスクリプション課金を実装した

副業で、iOSの自動更新型サブスクリプションの課金を担当して、サーバサイドとクライアントの実装をしたので、まとめた。
公式のガイドを見るのが一番だが、とっつきにくかったり開発する前の調査や理解に時間がかかったので、開発上の注意事項を中心に記載した。

環境

• サーバ
  • Ruby: 2.5
  • Ruby on Rails: 5.1
• iOS
  • Xcode: 10.2

概要

参考になるリンク集

進める上での落とし穴はいくつもあったが、基本的には公式のガイドを見るのが一番良いと思う。

• 概要
  • 自動更新サブスクリプション - App Store - Apple Developer
  • App Store Reviewガイドライン - Apple Developer
• 技術
  • レシート検証
  • App内課金プログラミングガイド

非技術的な仕様

料金設定

Appleが提示する金額リストから指定する形式のため、細かく自由に設定できる訳ではないので、注意。

審査

審査のガイドラインに記載されているように、あくまでも 継続的な価値を提供する必要がある。
ガチャのチケットを割り引いて配布するなどは、通らない可能性が高い(似たような条件でリジェクトされた)ので、他に購読ユーザ限定の機能を提供するなどの見せ方をする必要がありそう。

アップグレードとダウングレード

アップグレードとダウングレードは切り替えのタイミングが異なるので、注意。

	アップグレード	ダウングレード
切り替えのタイミング	即座に行われる	次回の更新のタイミングで行われる
差額の料金	元々のサブスクリプションの比例配分された金額が返金	そもそも発生しない

特に、アップグレードの切り替えは月途中でも行われるため、グレードに応じて特典の数量を変えるような場合は、要件を詰める必要がある。
アップグレード前のプランの日割り計算の料金で、1月分の数量を使用できるなどの状況が発生する。

開発

購読状態の監視

購読状態を監視するには、2つの手段がある。

• iOSアプリのStoreKit
• API(自動更新登録のサーバー通知)

サブスクリプション型の課金の更新は、アプリ内のライフサイクルだけでは完結しない。例えば、クレジットカードの有効期限が切れた、アプリをアンインストールし設定画面等から解約されたなど。
そのため、要件にもよるが、両方併用するケースが多くなると思う。

サーバ側

主には以下の3種類ぐらいのエンドポイントが必要になる。

• アプリ内での購入・キャンセル等のイベント
• 自動更新登録のサーバー通知
• 復元

レシートの中身がプロパティが多く、扱いがややこしいので、こちらのライブラリを使った。
メンテされてなさそう感はあるが、最低限の機能は揃っていたので便利だった。

github.com

ライブラリで加工して、以下のようなDBのテーブルに保存した。

+-------------------------+--------------+------+-----+---------+----------------+
| Field                   | Type         | Null | Key | Default | Extra          |
+-------------------------+--------------+------+-----+---------+----------------+
| id                      | bigint(20)   | NO   | PRI | NULL    | auto_increment |
| user_id                 | bigint(20)   | NO   | MUL | NULL    |                |
| transaction_id          | bigint(20)   | NO   | UNI | NULL    |                |
| original_transaction_id | bigint(20)   | NO   |     | NULL    |                |
| product_id              | varchar(255) | NO   |     | NULL    |                |
| quantity                | int(11)      | NO   |     | NULL    |                |
| web_order_line_item_id  | bigint(20)   | NO   |     | NULL    |                |
| first_purchased_at      | datetime     | NO   |     | NULL    |                |
| purchased_at            | datetime     | NO   |     | NULL    |                |
| expires_at              | datetime     | NO   |     | NULL    |                |
| cancelled_at            | datetime     | YES  |     | NULL    |                |
| created_at              | datetime     | NO   |     | NULL    |                |
| updated_at              | datetime     | NO   |     | NULL    |                |
+-------------------------+--------------+------+-----+---------+----------------+

自動更新登録のサーバー通知

AppStoreConnect上のApp情報から登録できるが、これは一つしか登録できない。 そのため、本番環境でも開発環境でも同じURLを使用することになる。

• リリース後
  • 本番のAPIのエンドポイントを登録せざるを得ない。
  • 本番環境ではsandboxのリクエストはスルーするようにしておく。
• リリース前
  • 本番サーバにデプロイしてデバッグしてると、永遠に時間がかかる。
  • GoogleAppScriptを利用して、スプレッドシートに出力してデバッグした。

function doPost(e) {
  var spreadSheet = SpreadsheetApp.getActive()
  var sheet = spreadSheet.getActiveSheet()
  sheet.appendRow([new Date(), JSON.stringify(e.postData.getDataAsString())])
}

iOS

開発環境周りがとにかく色々辛い。特に辛かった点を記載する。

AppleIDアカウント

sandbox環境では、5分経過すると課金状態は1ヶ月進み、6ヶ月進むとキャンセルされるようになる。 そのため、非常にテストと開発がし辛い。 同じアカウントを使っていると時間がかかるので、捨てアド専用のサービスを使った。 もしくは、gmailのエイリアス機能を使ってもよいかと思う。

復元

アンインストールしたユーザが再インストールした場合に、購入状態を復活させる必要がある。
復元するには、iOSのStoreKitの SKReceiptRefreshRequestを使用するが、開発環境だと別のアカウントの情報も取得できるような挙動が見られた。
これの解決策はイマイチわからず終わった。

「ミラティブ × LIPS × クラシル】 開発トップが語る、ヒットアプリのグロース戦略」に参加してきた

bethesun.connpass.com

感想

• ミラティブ
  • 会社
    • 定量と定性をバランス取れてる印象を受けた。
    • 副業エンジニアが多く（20数名で、正社員の2倍ぐらい）、そんなに上手くまわるものなのか疑問に思った。
  • 発表内容
    • 配信サービスという性質もあり、実際の行動を追いやすいところがあるのは羨ましい。
    • チームの分け方にも定性定量の観点があって面白い
      • チームの目標を定性より、定量よりにそれぞれ設定して、全体のリソースのバランスをとっている。
      • 人数の規模感が近しいので非常に参考になった。
    • 定性的には、ユーザとのコミュニケーションを相互にとっていて、ユーザと向き合いながらグロースしている印象を受けた。
      • 運営が開発状況を配信
      • ユーザからのフィードバックを週次で共有して、解決策や現状の共有を行うのは取り入れたい。
    • 定量的には、ちゃんと段階的にリリースしたりABテストを行って、しっかり仮説検証を行っている印象を受けた。
      • slackでの速報や、リアルタイムのウォッチングは何かしらの形で取り入れたい。
• AppBrew
  • 会社
    • かなりエンジニア主体の会社の印象を受けた。
    • 機械学習周りは特に強そう。
    • 文化的にも、仮説検証を前提として共通認識がある印象を受けた。
  • 発表内容
    • 方法論は大体ブログに記載されてるものって感じだった。
      • tech.appbrew.io
    • 方法論より、組織として実践していくのが難しく重要というのはかなり共感した。
      • やはり採用と評価から組織文化を変えないと厳しいなと思った。
    • フルスタックエンジニアではなく、 マルチスタックエンジニアという捉え方はしっくり来た。
• dely
  • 会社
    • あまり会社については触れなかったので、特になし。
  • 発表内容
    • 新規獲得とチャーンが釣り合ったら成長が止まる構造を理解してない人が案外多かった。
      • DAU = 新規獲得 + 継続利用ユーザ + 復帰ユーザ - 離脱ユーザ

メモ

注意事項

• なるべく主観は取り除いてますが、少しは私の解釈が入ってます
• 聞き取れないorメモに記載できなかった箇所もあります
• 私があまり興味ない or 自明なものは省略してます

①「Mirrativのプロダクト開発について」

登壇者: 夏 澄彦（株式会社ミラティブ CTO）

• 2015年に株式会社ディー・エヌ・エーに新卒入社、ミラティブに最初期から加わる。
• 2015年度新卒MVP（1名）受賞。
• エンジニアチーム全体のマネジメントを担当し、サーバ・クライアント両面の開発にも従事。

沿革

• 2015年8月 DeNA社にてMirrativリリース
• 2018年2月 株式会社エモモ（株式会社ミラティブの前身）登記
• 2018年2月 DeNAからのMBOと10億円超の資金調達を発表
• 2018年4月 オフィス移転
• 2018年5月 株式会社ミラティブに社名変更
• 2018年8月 バーチャルアバター「エモモ」リリース
• 2019年2月 総額35億円の資金調達を発表

サービスの説明

• 数タップでスマホだけで配信できる。
• サービスコンセプト：友達の家でドラクエやってる感じ
• ゲームを中心とした、「コミュニケーション」
• リリース時はOSの機能のレベルの問題で、Android5のみ対応でiOSでは視聴のみだったが、iOS11がリリースされたタイミングで配信可能になり、そこでグンと伸びた

ポジショニング

ビジネスモデル

• マネタイズ
  • 視聴者の課金
  • 他配信者によるギフト
  • アバターショップでの素材購入、ガチャ

ミッション

• わかりあう願いをつなごう

人員構成

• 22名正社員で、半分は開発

エンジニアの割合

領域	人数
iOS	2人
Android	1人
Unity	1人
サーバサイド	2人
インフラ	2人
グロースハック	1人

評価、目標設定

• 四半期ごとにOKRで設定
• 全社のOKRをみんなで決めて、そこからチーム毎にOKRを設定して、みんなが納得感があるように

チーム構成

• ライブ体験改善: 数字ドリブン
• エモモ:体験ドリブン
• R&D: エンジニア主導
• 開発体験向上: エンジニア主導

OKRの例

開発体験向上チームのOKR

項目	内容
O	開発に夢中
KR1	期初に洗い出した辛みを解消し、全プラットフォームで理想の状態を確立する
KR2	みんなが手軽にフルスタックになれる土壌を整える
KR3	テックブログ2週間に1本

エモモチーム

• 基本的な機能をブラッシュアップ・改善
• スナップ機能
• 礼和Tシャツ

R&Dチーム

• ボイスチェンジ
• 配信の遅延が最低2,3秒なので、1〜1.5秒とかにしたい
• 配信するにはパーミッションとらないといけないが、よくわからんし、毎回手動で切り替えないといけないのがめんどくさい
  • ユーザの画面の画像認識で推定して、自動で切り替えるように試行錯誤中

R&Dチーム

• 開発上の不満解消
• 全プラットフォームのベースラインの知識を備え、さらに得意領域を伸ばす
• エンジニアが増えてもスケールできるように

MVPでのリリースへの捗り

• どの機能も他に類を見ない機能
  • 目指したい世界観はあれど、ユーザに受け入れられないものに時間はかけない
• ユーザさんの体験を定量・定性的の両方で追える
• 実際に使ってくれる様子をリアルタイムに観測可能
  • 少人数からの展開であれば視聴者として実際にやりとりできる
  • 録画を見て振り返ることも可能
  • リリース直後からリアルタイムに分析できる仕組み
• 熱狂的なファンのニーズや不満に応える姿勢、そこを起点に徐々に他のファンにも展開

ロジカルさとエモさの両立

• 定量的
  • 新規リリース後、1時間後には速報値がでるように分析チームが待機
  • 1日数回slackに各KPIが自動更新で表示され、全員チェック可能な体制に
  • 新機能リリース時にはKPIを見ながら段階的に解放。仮説とのギャップを見ながら必ず判断
• 定性的
  • ユーザがその機能を使っている様子をリアルタイムで観察できる
  • 見守りチャンネルを機能毎に作成して、配信者の様子を見守る

ユーザに向き合い、ユーザから学ぶ開発体制

• 運営が直近の開発の内容や、リリース予定の機能などを配信してユーザに共有
• 毎週1時間かけて、ユーザからのフィードバックを見直して認識をあわせてる
  • AppStoreのレビュー
  • お問い合わせ
  • twitterのDM

ユーザ体験？？？

• ユーザのスマホのあらゆる体験から、発明
• ユーザが勝手に発明してくれる
  • ex. 質問箱の配信

副業

副業20数名と大量にいる。

• 情報は事業状況含めフルオープン
  • slackだけではキツいので、毎月のプレミアムエモいデー
• 必要のない時間管理はなし、プロ意識に一任
  • slackで日報で共有
• 不安解消
  • 簡単なUI改修などから入ってもらう
  • R&Dよりの期限のないものをお願いする
• 社員の状況がわからないので、質問し辛い
  • 分報チャネルで話してもらって、手の空いてる社員が対応

質疑応答

• 新機能と改善のリソース配分はどうしてるか
  • チームわけて、優先順位を決めてる
  • 新機能とバグ対応の優先順位を決める
  • チーム分けるときは、アーキテクチャも意識する
    • お互いの作業がコンフリクトしてしまうと意味ない

②「LIPSのグロース戦略とプロダクト開発について」

登壇者: 深澤 雄太（株式会社AppBrew CEO）

• 1994年生まれ、2013年度東京大学入学。
• 中学時代に独学でプログラミングを習得。
• 大学入学後の2013年に友人らと共に「東大無料塾」を立ち上げた後、大学を休学しfreee株式会社で1年間インターンを経験。
• 個人でのシステム開発の受託などを経て、2016年2月に株式会社AppBrewを設立。
• コスメのコミュニティアプリ「LIPS」を2017年1月にリリース。

プロダクト説明

• 300万DLL突破
• コスメのクチコミ「コミュニティ」
  • 探す・見る
  • 共感する
  • 投稿する
  • 共感される

プロダクト開発ってなんですか？ 「仮説検証のサイクル」
運用は実は難しい。
仮設・検証があってるかどうか

プロダクト作りの大前提: 「仮説検証のサイクル」

• 目標地点を定めておく（短期・中長期）
• 仮設を立てる
  • 現在と目標の差分（課題）の解決
  • 適切なサイズとコストとインパクトの大きさ（枝葉末節に陥ってないか）
  • 検証可能性（= 基本は数値ベースで測定・比較）
• 実行/検証する
  • 仮説通りに変化したか
  • それを踏まえて、次の仮説に

LIPSの「仮説の立て方」

• 短期目標：「ユーザの求めるコスメ・美容レビューの提供」
• 長期目標：「ユーザ（若年女性）の求める実用的なレビュー全般の提供」

仮説の必要要素を固める(githubのissue templateを利用)

• ユーザの抱える問題
• 問題の解決策
• インパクト想定
  • 対象： ヘビーユーザ, 全ユーザ, 他の特定ユーザ（ex: 投稿ユーザ）
  • 対象画面のDAUU
  • 使用頻度： daily, weekly, monthly
  • 改善する数値
  • 数値の伸び幅：○倍 or ○％
• コスト想定
• 検証内容

仮説の具体例

通知許可率の向上についての仮説

• ユーザの抱える問題
  • 通知許可しないことで、本来ニーズがあるはずの情報も受け取れない
• インパクト想定
  • 対象： 全新規ユーザ
  • 対象画面のDAUU：数千〜
  • 使用頻度：1度
  • 改善する数値：通知許可率
  • 数値の伸び幅：数％ = 通知の開封数にして数％
• 問題の解決策はなにか
  • 「許可しないと損するかも」という訴求を加える。実際他社で通知のABテスト行ったエンジニアいわく細かい文言の調整も効いたとのことだったので、とりあえず「許可しないと〇〇できません」の文言追加
• コスト想定
  • 文言変更のみなので小さい

検証の方法

• 数値の取得（分析基盤・ログの仕込み）
• 数値の変化を観る
  • A/Bテスト（時系列だけの観測では外部要因が多い）
  • できるだけ多角的に（ある数値が増えた分、他が減ったなどはよくある）
    • 検索だと、CTR下がるのは本当は良いことが多い
    • ユーザが解決することが重要
• 仮説通りにならなかった場合
  • 想定・現実間の差分を把握し、次の仮説に反映
  • 機能自体を差し戻すか否かの判断

検証結果の具体例

通知許可率の向上についての仮説

• 検証内容
  • ABテストが必要か: yes
  • 取りたいイベント: 通知許可
• 結果
  • 全体で2%程度向上→長期のRRにも寄与

仮説の具体例2

「おすすめ」タブのCTR向上についての仮説

• ユーザの抱える問題
  • フィードに興味のあるコンテンツが十分に出てきてない
• インパクト
  • 対象： DAU全体にたいして9割
  • 対象画面のDAUU：xxxxx
  • 使用頻度：起動ごと
  • 改善する数値：CTR、投稿の閲覧数
  • 数値の伸び幅：数％〜数十％ = 閲覧数も同様に変化
• 問題解決策はなにか
  • 協調フィルタリングのアルゴリズムの特徴量を少しだけナイーブに変える
• コスト想定
  • アルゴリズムの導入自体は大きいが、特徴量の変更だけなので小さい

検証の具体例2

「おすすめ」タブのCTR向上についての仮説

• 検証内容
  • ABテストが必要か: yes
  • 取りたいイベント: 「おすすめ」タブのクチコミのタップ率
• 結果
  • 約10%程度改善
  • (特徴量に関しては、数十回試していて、その中の1つ。ほかは僅差か悪化)

開発フローのまとめ

実際には仮説のうち、3割は悪化、5割は変化なし、2割が改善
さらに1割=2%が事業に大きなインパクトを与えられる

だから、

• ディスカッションでも一喜一憂せず、想定と現実のずれをいかに把握して次に活かす
• とにかくスピードもって打席を増やす

積み重ねるのが難しいので、組織文化・風土作りの方が重要

開発フローへの組み込み方

• zenhub
• 検証中フェーズを設けて管理
• 週一のMTGで検証中のissueを一つずつディスカッション

一人ひとりがE2Eで仮説に関わる

マルチスタックの要求

• 全員がE2Eで施策に関わるために、AppBrewのエンジニアは「マルチスタック」の精鋭
• 「サーバとフロント」ではなく、仮説検証のベーススキル（入ってから身につけるでもよし）と各カテゴリのスキルセット
• 各カテゴリへの高い専門性も要求すると同時に、技術のみでは採用しない
• 大きく、ソフトウェア・アルゴリズムに分かれてる
  • ソフトウェア：サーバ、クライアント、インフラ
  • アルゴリズム：統計やデータアルゴリズム、ML
  • 共通の基本：データ分析、仮説検証リテラシー、事業理解

開発組織を支える文化

• 少数精鋭・ユーザ主義
  • マルチスタックの少数精鋭
  • 数値や事業のリテラシーと仮説検証
• オープン
  • 事業に関する情報全公開(リテラシーにそのまま繋がる)
  • 給与や、SOまで含めて公開
• 自律分散的
  • フラットで、各々が意思決定する（誰も命令しない・スタンスをとることを要求）
  • ルールなどを最小化し業務の邪魔をしない（勤務時間自由・フルリモート可）
  • 評価や査定を全て相互評価（分散的に評価する）

ユーザが熱狂するプロダクトを再現性を持って生み出す

機械学習スタック

③「グロースの構造を理解する」

登壇者: 大竹 雅登（dely株式会社 CTO）

• 2014年、慶應義塾大学在学中にdely株式会社のCTOに就任。
• 数回のピボットを経て、2016年1月よりレシピ動画サービス「クラシル」を運営。
• CTOとして開発を牽引したレシピ動画アプリ「クラシル」が、Google Play ベスト オブ 2016「ベスト自己改善アプリ賞」、App Ape Award 2016「スタートアップアプリ賞」を受賞するなど、昨年5月のリリースから約1年半で国内最大のレシピ動画サービスとして成長させた。

グロースとは？

概念の説明ばかりふわっとした理解になりがち。
解像度高くしたい。

成長曲線のS字カーブ

DAUの成長はS字カーブを描くので、サービスがどのフェーズにいるのか理解するのが重要。

• 広告とか打てば打つほど、DAUが伸びるフェーズ
• DAUが寝てくるフェーズ
  • スナップチャットはDAUが寝てる
  • 新規獲得とチャーンが釣り合うとそうなる

成長曲線のS字カーブをデータや構造から理解する

1. リテンションカーブ
2. リテンションコホート
   • リテンションカーブより情報量が多い
3. 積み上げDAU
   • コホートを斜めに足せば算出できる
   • エクセルでは結構表現するのが難しい
     • 
4. チャーンユーザ
5. DAU成長率

新規獲得のボリュームによって、DAUが寝るタイミングは変化する

広告突っ込んでも、長期的にはチャーンと釣り合うようになるので

いかに新規獲得を増やすか

• 広告: 新規獲得数 = 広告予算 / CAC
  • 予算を増やす
    • 資金調達
  • CACを下げる:
    • Organic CAC: 口コミとか
    • Paid CAC

• オーガニック獲得のチャネル
  • SEO
    • アプリ主体で始まったサービスでも途中からSEO頑張るのは結構ありがちなパターン
  • 口コミ
  • 招待プログラム（招待した人にインセンティブ付与）
  • 復帰ユーザ(機種変更など)
  • TVCM（直接計測不可なのでオーガニック扱い）
    • クリエイティブを見た直後と、ランキング上昇してDL増えたとか副次的な影響に分解できる
  • オフライン施策(リアルイベント、チラシ配布)
  • ASO

自然独占の法則

• ライトユーザは大きなブランドを好む
• 市場シェアを拡大するほどライトユーザが獲得しやすい

ブランディングの科学 誰も知らないマーケティングの法則11

オーガニック獲得を増やすために広告を踏むという逆説的な施策もあり

質疑応答：クラシルで特にグロースで頑張ったのは？

• SEO頑張った
• SNS

「THE TEAM 5つの法則」を読んだ

THE TEAM 5つの法則 (NewsPicks Book)

目的、モチベーション

4月にエンジニアリーダーになったので、マネジメントのお勉強をしたいと思ったからというのが大きな目的。
SNSで話題になってたり、Amazonでも評価高いから一応読んでおくかぐらいの温度感で読み始めた。

全体の感想

役に立つところもあったが、正直求めてた感じとは違った。
途中まで読んだエンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリングを真面目に読み続けておけば良かった。
良くも悪くも体系的に教科書的にまとめたという印象で、頭の中が整理はされたが、ビジネス書を普段ある程度読んでたら知ってることが多いと思う。
Amazonで評価が高いのは、Newspicksが絡んでるのでマーケティングの戦略上、売上立てるためにレビュー集めたんだなぁという印象を受けた。
発売してから2週間ぐらいでこの評価。

マネジメントは実践するのが難しくそれが全てで、状況に応じてやるべきことが異なるのもあって、一般論になってしまいがちで仕方ない側面もあるような気はした。

個人的な自戒は下記。

• メンバーの志向のタイプを意識すること。
  • 私はアタックとシンキングが強めで、その基準が当たり前にしがちなので気をつけてコミュニケーションを取ろうと思った。
  • エンジニアはそういう傾向の人がそもそも多い気がするので、非エンジニアに対しては特に。
• (読む前から思っていたが、)チームの目標とメンバー、文化に応じて最適解は変わる。
  • 正解はないので、常に考え続けること。
  • コミュニケーションとって状況を常に把握し、変化していく。
  • 「イケてる」ものをチームに取り入れる前に、他でそれが上手く回っている前提や構造を理解すること。

目次

概要

第1章 Aim(目標設定)の法則〜目指す旗を立てろ! 〜

「共通の目的がない集団」は「チーム」ではなく「グループ」

目標設定しないと、ただのグループ。
チームのレベルと目的に合わせて、目標の設定の仕方を変える。

• 意義：ブレークスルーは生まれやすいが、何をしたらいいのかがわからなくなるケースがある。メンバーが自主的に意義を持って動くと強い。
• 成果：中間。
• 行動：具体的だが、ブレークスルーが起きにくい。自由にやったほうがパフォーマンスが出るメンバーにとってはやりにくい。

時代の流れ的に、やるべき行動がすぐ変わるので、OKRなどで意義目標を立てて、メンバーが自発的に成果を出すためにどのような行動を起こすかを考える

第2章 Boarding(人員選定)の法則〜 戦える仲間を選べ〜

チームは何のために組織されたかによって、人員選定の最適解は異なる。 チームのタイプは、環境の変化度合いと人材の連携度合いの2軸で4つに分類できる。

人が入れ替わるチームは本当に駄目なのか?

• 環境の変化度合いが大きければ、入れ替わった方がよい。環境が変わると必要なスキルが変わるから、組織の新陳代謝をあげる。
• 環境の変化度合いが小さければ、入れ替わらない方がよい。入れるメンバーを厳選する。

チームには多様性が必要だという誤解

• 連携度合いが低ければ、多様性は無いほうが良い。個人戦の傾向が強くなるので、似た人が多い方が組織としてまとめやすい。
• 連携度合いが高ければ、多様性はあったほうが良い。同じような人ばっかりだと、脆い。

「ゴットファーザー」より「オーシャンズ11」型のチームが強い

時代の流れ的に、連携度合いが強く環境変化が激しいので、新陳代謝のある多様なチームが求められる傾向にある。

第3章 Communication(意思疎通)の法則〜最高の空間をつくれ〜

ルール設定のポイント

• ルールの設定粒度
  • 環境変化が小さく連携度合いが大きければ、ルールを多くすべき
• 誰が決めるか
  • 環境変化が小さく連携度合いが大きければ、独裁的に決めるべき
• 責任範囲
  • 環境変化が大きく連携度合いが大きければ、チーム成果に責任を負うようにすべき
• 評価対象のルール
  • 環境変化が小さく連携度合いが大きければ、プロセスを評価し、逆は成果を評価する
• 確認頻度
  • 環境変化が大きく連携度合いも大きければ、頻度を高くすべき

メンバーの志向・能力の理解を深める

タイプ	反応しやすいキーワード	嬉しい言葉
アタックタイプ	勝負/敵味方/損得	すごいね
レシーブタイプ	善悪/正邪/愛憎	ありがとう
シンキングタイプ	真偽/因果/優劣	正しいね
フィーリングタイプ	美醜/苦楽/好嫌	面白いね

心理的安全性を高めましょう。

第4章 Decision(意思決定)の法則〜進むべき道を示せ〜

意思決定は3種類に分類できて、求められるスピードに応じて変える。

• 独裁
• 多数決
• 合議

意思決定する場合には、それぞれの選択肢の特徴を列挙してから比較するのではなく、選択基準とその優先順位を決めてから必要なだけ選択肢の調査を行う。 そうしないと時間が無駄にかかる。

独裁は必ずしも悪いとは限らない。
意思決定が求められる場面では、メリットとデメリットが拮抗していることが多いので、早く意思決定することの方が重要なことが多い。 そして、チームはその意思決定が正しいものになるように実行することの方が重要。

第5章 Engagement(共感創造)の法則 〜力を出しきれ〜

超一流でもモチベーションに左右される。組織の仕組みを作ってエンゲージメントを高めるには4Pの軸で考える。

• philosophy(理念・方針)
• profession(活動・成長)
• people(人材・風土)
• privilege(待遇・特権)

メンバーによってどこに魅力を感じるかは変わり、リソースは有限なのでチームメンバーに応じて最適化する必要がある。

エンゲージメントは以下の3項目に分解できるので、それぞれの4Pで適切に設計する。

• will(報酬・目標の魅力) 目標を立てる
• can(達成可能性) 段階的なプロセスを示す
• must(危機感) ペナルティ

世の中の流れ的に、人材不足かつ流動性が高まっているので、エンゲージメントを高めることが重要で、エンゲル係数が下がり続けており、感情報酬を与えるのが重要。

THE TEAM 5つの法則 (NewsPicks Book)

『ファウンダーが語る「toC × Big Market の最前線」 #10XTALK』に参加してきた

10x.connpass.com

参加メモ

※ 悪意はないですが、とにかく濃く速かったので、誤ったor不適切な表現になってる箇所もあります。あくまでも個人のメモとして参考程度に参照してください。

• パネラー
  • 株式会社Fablic/創業者 堀井 翔太
  • 株式会社ミラティブ/創業者 赤川 隼一
  • 株式会社10X/創業者 矢本 真丈
• モデレーター
  • コネヒト株式会社/創業者 大湯 俊介

各社紹介

コネヒト株式会社/創業者 大湯 俊介

• 25歳でママリで創業
• ビッグマーケット的な観点から見たママリ
  • 家族に訪れるライブイベントの入り口を抑える
  • 中長期的には、その後に保険だったり、教育教材を売っていくイメージを描いてる

株式会社Fablic/創業者 堀井 翔太

• 経歴
  • フリマアプリのFrilのFablicを創業
  • 楽天に売却
• 直近
  • 起業準備中
  • ANGEL PORT
• Frilの創業時のマーケットの考え方的には、SNSの服のやり取りのリプレイスから考えた

株式会社ミラティブ/創業者 赤川 隼一

• 2Cサービスがとにかく好き
• DeNAで何個も新規事業をやった
• プロダクト作りたいし、作ってないと錆びる感覚もあり、役員を辞めて、MirrativをMBO
• Mirrativ：スマホだけでゲームを実況
  • 結果論的には、大きなマーケットになった
  • アクティブユーザの20%が配信する
  • 「友達ん家でドラクエやってる感じ」のコミュニケーションサービス
  • 「ガチャ10連回して、Mirrativeに投稿しないのは意味不明じゃない？」といったような次のtwitterを目指す
  • 中国のライブ配信の分野で一番伸びてるのは、ゲーム実況
  • スマホゲームだけで1兆円市場
  • fortniteに代表されるアバター市場
    • 強くなったりするわけではないが、着せ替えとかで課金する

株式会社10X/創業者 矢本 真丈

• 経歴
  • 丸紅、NPO
  • スマービー
  • メルカリ
• プロダクト作るのが楽しくなって、コード書くようになったり
• タベリー
  • 東京の人は使わない
    • 週1.7回しか自炊しない
  • 東京以外の全国的な平均は週6.5回料理する
• なぜタベリーか
  • 原体験は、育休中の家内の献立の大変さ
  • 事業プランは30個ぐらいスプレッドシートで温めている
  • その中でも、市場規模が大きく、ITが進んでない分野は限られている
  • 生鮮食品でITが進んでないのは、難しいからタッチされてない
  • 消費者の財布のうち、最大のポーション 25%は食費

第1部: マーケットインサイト/エントリーの見つけ方

どういう匂いを嗅ぎ分けてなぜこのサービスにたどり着いたのか

• 堀井
  • iPhone4が出て浸透し始めるぐらいのフェーズ
  • 事業として成り立つレベルの、まともなアプリもそんなにない
  • C2Cにしたのは、Techchrunchの海外イベントでC2Cやクレイグリストが来ていた
  • ガラケーの方が多く、アプリで来るかもわからない状況
    • 海外の方がクオリティが高くて、日本でも来そう
    • スタンフォード大学(?)の卒業の時期に物理的な掲示板でやり取りをやっていて、Webに持っていきたい
  • 最初はメルカリアッテのように、地域でマッチングする方向で進めていて、実際にリリースできるレベルでプロダクトを作った
  • しかし、ユーザインタビューとかしてると、何でもできるのは難しくて誰も使わなさそう
  • 女子大生の服なら行けるかも？
  • 100人ぐらいインタビューして、1から作り出したのがFril
    • 3ヶ月ぐらいかかった
    • 1人あたり1〜2時間かけた
• 赤川
  • 失敗の嵐
    • DeNA時代にいっぱい
      • 早すぎたNewsPicks
      • ヤフーモバゲーで早すぎたShowroom
      • クラウドゲーミングやろうとして、大ゴケ
    • 運とタイミングは重要
    • 失敗から学びながら当てていく
  • ショートカット
    • Android5.0のAPIで画面共有の機能を自身で発見
    • 趣味のコミュニティのサービスが好きで、ゲーム実況やりたかった
    • twitchで1億ユーザで、ゲーム市場ある
    • 自分の考えがバチッと刺さることは大天才以外はほぼ無い
    • ゲーム実況やるのに、ユーザペインのポイントが明らかに沢山あった
      • そのペインをショートカットしてあげる
    • ユーザの顕在しているユーザペインを解決するのが王道
    • チケキャンも同じ発想でtwitterでニーズを拾って始まった
  • いずれそうなるものはいずれそうなる
    • Androidで4%ぐらい、iOSは提供されるかどうか不明で、反対された
    • いずれは100％になるのでチャンス
    • iOS11で対応されて伸び始めた
    • 5Gになるので伸びるのは間違いない
  • 3年も待った胆力は？
  • 圧倒的な熱量とショートカットはキー

• 矢本

  • ブログをよく書く
  • どうやって課題をとかは、ブログに書いてある
  • Day One | Yamotty (@yamotty3)
  • ファウンダーマーケットフィット的にもマッチしている
    • Mirrativeインターネット的じゃない
  • プロダクトの観察する際の切り口
    • 可処分時間を使うものか、つくるものかという切り口で見る
    • タベリーはハサミとか包丁とかみたいに、ペインキラーで泥臭くて自分にあう
  • マーケットも泥臭い
    • イオンとかセブンイレブンとかユニクロは、何十年も徐々に育てて積み上げてくる泥臭さが自分に似合ってる
  • 社長の性格や自己顕示欲と事業のタイプが合わない責任者は苦しみがち

• SHOWROOMのコードからMirrativはできた

  • 自分でもできる
  • 50フォロワー記念配信の熱狂できる環境
• 必ず通るところを軽視しない

大きいことやるには時間が必要だが、どういう時間軸で考えて経営しているか

• 矢本
  • 起業して30年やるつもり
  • 30年勤める必要はないが、働く期間はマッチできるような人しか働かない組織にしたいので、熱量はあまり心配していない
  • スキルの高い人は誰でもパフォーマンス発揮できる環境は用意する
  • 投資家は、「1発当てるつもりで投資してください」というふうに説得
  • 一貫性を保って、キャッシュ面でも人材面でも
• 堀井
  • 始めたタイミングはアプリにかけて、一番最初に出せたのは良かった
  • 1年ぐらいで黒字で継続してユーザが使うことはわかったが、グロースするアクセルを踏めなかった
  • 事業会社出身で、お金を調達する発想がなかった
  • 黒字でPL経営を続けていくのが重要という思考だった
  • 当時は調達してCM打つのもメジャーでなかった
  • メルカリはCMをハックした
• 赤川
  • ブレークまで約3年ぐらいかかった
  • 良い事業は早すぎても確度は作れる
  • 母数はダメでも、割合的な数字は良かった
  • ずっと伸びていたので、なんとか説得できた
    • iOS11で配信できるようになって、Android含め跳ね上がったが、その前も
  • 競合にやられるとしたら中国企業
  • MixChannelでも、TikTokのアルゴリズムと資金で潰された
  • 先行優位はあり最初は大丈夫だが、速く市場を取らないと取られる

資金調達の仕方・コツ？

• このジャンルは自分が負けたら日本は負けるといった形で説得してファイナンスするのも良いのでは

ユーザインタビューの仕方

• 堀井
  • 仮説を持ってる状態で、課題のある人をインタビュー
  • どういう状況の人が、今どうやってそれを解決しているかを把握したい
  • 一次情報を掘り下げる
  • 仮説の課題を持っていて、不合理な解決方法
  • バイアスを回避するには？
    • フラットな状態でやるのは、常に心がけてる
    • 行動を掘り下げる、質問をするのでバイアスはそもそもかからない
• 矢本
  • ユーザインタビューは、ユーザを理解するのが目的
  • ユーザは自分の欲しいものを知らない
  • 課題の情報を引くのが目的で、解決は自分でする
• 赤川
  • まおさんの記事オススメ
  • 「柔らかいロボットのように質問する」
    • 共感しすぎても、バイアスとかが入るのでダメ
    • 信頼して話してもいいかなって思わせることが重要
  • 一緒にジェンガするなどのインタビュー方法も

上手く行ったペインといかなかったペインはあるか

• 赤川
  • 視野の狭さ（モバゲー上でやった）
  • プロダクトが悪かった（UI/UXとか）
  • ピコピコタウンは完全に失敗した
    • youtubeを一緒に観る
  • 一見ペインだが、わざわざするほどでもないものかを見極めることが重要
  • 熱量が低かったらわざわざやらない

グローバルマーケットをどう考えてるか

• 赤川
  • 最初からグローバルを捉えるのは危険
  • どこかで刺さらないと、どこでも刺さらない
  • リソース分散になってしまう
  • グローバルに闘う手段を持った状態で、ローカルファクトリーが基本では？
• 堀井
  • 配送とかの現地の文化、非言語的な面も重要で、全く同じプロダクトでグローバルに行けないものもある
  • 言語だけ変えればいけるものだと行きやすいのでは

ママリのユーザインタビュー

• 当時は300円インストールして3日使ってもらってskypeでインタビュー依頼してた
• そのまま使ってくれる人が半分ぐらいだったので、グロースの側面もあった

第2部: 各マーケット戦うチームの作り方

チームで大切にしてること

• 赤川
  • 最高、最強、エモい
  • 仕事にプライオリティを置いている人にとって重要なのはエモいとか感情的な部分で、それを尊重できる文化
  • ユーザや仲間に対しても
• 矢本
  • 7人の少数精鋭で一騎当千
  • プロダクトでマーケットと闘うには、コミュニケーションコストのかからない、最強な人が少人数でやるのがベストだから
• 堀井
  • ユーザファーストを文化に
    • 言葉でだけではなく、CSとかはユーザから採用
    • ビジネスモデル的にもユーザファーストを貫きやすい
      • 広告が嫌だとかとかで営業VS開発みたいなことにならないモデル
• メルカリはCSを（物理的にも）真ん中に置く（ユーザからお金を）

組織構築においてこういうのは捨ててる、やらないと決めたこと

• 赤川
  • 営業をめちゃくちゃ少なくする
  • 事業開発で、頭よい仕事できちゃう人は、新しいアライアンスとか決めちゃう
    • 提携ありきの開発が発生する
  • プロダクトに重きを置く
• 矢本
  • オペレーティングを絶対やらないと決めて起業
    • 記事を書く、レシピを書くなどはしない
    • レシピのアノテーションのメタデータの紐づけ以外はやってない
  • マネタイズは有料課金、広告は捨てた
    • 広告載せたら思ったよりも運用の手間がかかった
    • 作るのがめちゃくちゃ速いので、なぜとかを考えるリソースを確保するのが最重要
• 堀井
  • 最初の10番までは創業者を信じて入るので、文化を決める
  • テッキー、ユーザドリブンでやっていて、プロダクトを磨く文化を貫けた
  • 良くも悪くもお金かけてグロースするとかの発想がなかった
    • テレビCM打つとかのグロースとかの文化を取り入れられなかった？
    • 成長に応じて組織のアップデートはあまり上手くできなかったのかも

最初の10人をどう決めて、キーマンになったのは？

• 矢本
  • 共同創業者がキーマン
  • 企業文化は、共同創業者の最大公約数にすぎない
  • エンジニアリングはできるのは当たり前で、なんでもやります的なスタンス
  • そういうスタンス人が入ってきてくれてる
• 赤川
  • まおさん
  • ニコニコ動画のイベントで知り合った
  • イベント会場でもカメラマンまでやってて、何でもやるユーザに献身的な姿勢
• 堀井
  • カルチャーを牽引してくれる人がポツポツでてくる
    • zapposのCSのように
• 大湯
  • スキルセットも重要だが、カルチャーマッチするか
    • 企業のTシャツを面接に着てくるようなメンバー

チーム文化

• 赤川
  • プレミアムエモいデー
    • 50人みんなでエモいこと話して、心理的安全性を確保
    • 社内で自分で発信するとエンゲージメントが上がる
• 矢本
  • 自己紹介を超重視
    • ドキュメントに入社前に1歳ごとに時系列で自己紹介
    • モチベーショングラフでどういう配慮をすべき人なのか把握

チームづくり

• 堀井
  • テキストで「俺はこう思う」をあげる = ポエム
  • 社内ブログ
  • みんなポエムあげるようになった
• 矢本
  • 早く帰る
  • 家庭とか仕事以外のことも重視できる文化に
• 赤川
  • 心理的安全性をあげる
  • 経営陣・マネジメント層は特に、ダメな面を見せたり、くだらないことをいうのが重要

創業者がプロダクトの思いとかをメンバーにどう伝えているか

• 堀井
  • 社内向けにブログを書く
    • プロダクトの大きいアップデート、競合の資金調達とかのタイミングで、戦略や考えを発信
  • 全員の前で話すのは、四半期に1回締め回で自分で10分話す
• 赤川
  • インタビューのときの全文ログを社員に見てもらう
  • heyでは、佐藤さんに戦略的にインタビューを受けさせることで思考とかが整理される

勝ち続ける組織を作り続けるには

• 赤川
  • 慢心
  • Mirrativは周りからイケイケとは思われがちだが、危機感を持ってるメンバーの方が多い
  • テクノロジーを使うのもキー
    • （社員数の多い）Googleが企業文化を貫けてるのは、TGIFのおかげでは
    • グーグルCEOは社員6万人の声を聞いている | リーダーシップ・教養・資格・スキル | 東洋経済オンライン | 経済ニュースの新基準
    • サイバーの藤田さんの下方修正もブログで社員に向けて発信した
• 矢本
  • 事業がアップデートしてないのが悪い
  • 組織は事業にあわせてつくったりアップデートするもの

ネガティブFBの仕方

• 矢本
  • slack使わない
  • 感情とか弱みを対面で出す
  • 喧嘩になる前の段階で対面で潰す
  • 予防する発想

経営する上で組織が大きくなるときにアップデートできるように意識してること

• 赤川
  • 悪いことは起こる前提
    • 反脆い組織に

    • 反脆弱性[上]――不確実な世界を生き延びる唯一の考え方

    • 「社長は偉大だ！」みたいな雰囲気だと、失敗すると一気に崩れ去る
    • 失敗がプラスになる組織に
• 堀井
  • 未然に防げたことはあまりない
  • 最大の後悔
    • マーケとかのお金の使い方
    • 事業のアップデートに伴う、フェーズに見合った人材をあまり上手くは採用できなかった

最後に一言

• 堀井
  • オフィスを出ろ
  • 机の中に答えはない
  • ユーザと向き合ってペインを捉えて、種を探す
• 赤川
  • 最上志向的な考え
  • 一番イケてるとしたら？の発想を重要に
    • セガの岩城さんが採用できたのもその発想
  • 中庸はダメ
  • 資本主義では突き抜け続けないとダメ
• 矢本
  • 10倍違うもの = 異質
    • 2,3倍違うものはスイッチングコストが高いので使われない
  • そういうものを突き詰めるカルト的なチーム

「失敗から学ぶ RDBの正しい歩き方」を読んだ

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

目的、モチベーション

めちゃくちゃ目的意識がある訳ではなかったが、最近DB関連の勉強あまりしてないので、面白そうだから読んで見るかぐらいの温度感で読んだ。
私自身は、普段MySQLを使っていて、アプリケーションエンジニアとしてテーブル設計、SQLチューニングをしている。
体系的に学んだという観点では、本でいうと過去に↓あたりを読んだことがあるぐらいのレベル感。

• リレーショナルデータベース入門―データモデル・SQL・管理システム・NoSQL (Information & Computing)
• SQLアンチパターン
• 達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)
• 達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

実践ハイパフォーマンスMySQL 第3版も読もうとしたが、辞書すぎて途中で挫折した。。

知らないことも多く、読んで良かったのでオススメ。

全体の感想

• 全体的に、現場で起こりそうなアンチパターンを紹介して、その原因と対処法を書いてある形式で、話が入ってきやすかった。
• SQLアンチパターン（過去に既読）と重複してる部分も少しはあるが、運用面も対象にしている点が特に異なり、学びが多かった。
• DBの理解(特に運用面)が浅いことが認識できた。
• PostgreSQLとMySQLは結構違いがあって面白そうだと思った。
  • RDBはMySQLしか使ったことないが、PostgreSQLはアグレッシブ目な機能とかもありそうな印象を受けた。

目次

概要

第2章　失われた事実

アンチパターン：レコードをむやみに更新すると、履歴データが失われる

• 履歴データも保存することで解決するが、パフォーマンスとのトレードオフ。
• パフォーマンスを取るなら、他の手段でログを残すこと。

第3章　やり過ぎたJOIN

• JOINのアルゴリズムをまず理解することが重要。
  • NLJ(MySQLはこれだけサポート)
  • Hash Join
  • Sort Merge Join
• JOINはテーブル同士を掛け算するので、大きいテーブルをJOINするとコストが高い。

• 更新頻度が低ければ、別テーブルを作成したり、Viewを活用する。

• 参考: Where狙いのキー、order by狙いのキー

第4章　効かないINDEX

INDEXが効かないケース

• 検索結果が多い、全体の件数が少ない
  • テーブルスキャンの方がコストが低いために、使われない。
  • 検索結果がテーブル全体の20%未満が目安
  • 数万〜数十万行程度に、テーブルが十分大きいこと
• 条件にその列を使っていない
• カーディナリティの低い列に対する検索
• あいまいな検索
  • 部分一致でもINDEXを効かせたい場合は、Mroongaなどを使う
• 統計情報と実際のテーブルで乖離がある場合

第5章　フラグの闇

• アンチパターン：テーブルに状態を持たせる（delete_flgなど）
  • いちいちステータスを見ないといけないので、クエリが複雑化する
  • UNIQUE制約が使えない
  • カーディナリティが低くなり、INDEXが効きにくくなる
• 事実のみを保存する
  • 削除済みのテーブルを作る
  • Viewを使う
• JOINの対象にならない, INDEX不要などの場合は許容できる。
• 参考
  • SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
  • MySQLで論理削除と正しく付き合う方法
  • PostgreSQLアンチパターン

第6章　ソートの依存

• RDBは、そもそもは集合論のモデルなので、sortという概念がなく苦手な処理である。
• INDEXを使って、ソート済みの結果を使うなどの工夫が必要。
• OFFSETはソートした結果をfetchしてるので、ページングが奥になればなるほど高コスト。
  • idなどで、次ページを特定するようにして、OFFSETを避けるなど。
• またはNoSQLを使う

第8章　JSONの甘い罠

• デメリット
  • RDBのメリットであるはずの制約を与えられない
  • 検索、更新が困難
• 使い道
  • サードパーティのレスポンスなど、key名等が変わる可能性があり、参照さえできればよいデータなど

第9章　強過ぎる制約

無闇に強すぎる制約はよくない。
ビジネスロジックの変更の度に変えないといけなくなったりするのはよくないので、 アプリケーション側の規約と、DB側の制約をバランスよく使い合わせるのが大事。

第10章　転んだ後のバックアップ

アンチパターン: リストアしてるが、復旧できない状態になっていること

• バックアップの種類
  • 論理バックアップ
    • SQL等で保存して、DBそのものを再構築できるようにする方法。
    • 容量が大きくなってしまい、リストアとバックアップに時間がかかる。
    • バージョンアップ等にも対応できる。
  • 物理バックアップ
    • DBのデータのファイルを直接保存する方法。
    • サイズが小さく、時間も短い。
    • バージョンアップ等で使えなくなる可能性がある。
  • PITR
    • バックアップと、更新情報のログ（バイナリログ）が必要。
    • 最新の状態に戻せやすい
    • 上記より扱いが難しい。
• バックアップ設計の観点
  • RPO( Recovery Point Objective )
  • RTO( Recovery Time Objective )
  • RLO( Recovery Level Objective )
• 参考
  • MySQLバックアップの基本
  • OSC東京2013/Spring_JPUG資料
  • PGCon 2014 Tokyo【D1】PostgreSQL バックアップ入門（佐藤 千佳） - YouTube
• 自動化すべき
  • 本番のDBをリストアして、ステージングで復旧して、シナリオテストを実行して、本番環境とステージングでの差分が発生していないかを確認

第11章　見られないエラーログ, 第12章　監視されないデータベース

• ミドルウェア構築時の1プロセスとし、必ず設定して、可視化や通知を行うこと。
• サービスの成長とともに変化するので、定期的に見直すこと。

第13章　知らないロック

RDBMSによって、全然挙動が異なるので、思い込みは厳禁。

• Postgre
  • SELECT文でも AccessShareLockというロックを取る。
• MySQL
  • ギャップロック
  • ネクストキーロック
  • MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.2.6 InnoDB のレコード、ギャップ、およびネクストキーロック

第14章　ロックの功罪

トランザクション分離レベル

	ダーティーリード	ファジーリード	ファントムリード	ロストアップデート
read uncommitted	発生	発生	発生	発生
read committed	起きない	発生	発生	発生
repeatable read	起きない	起きない	発生	発生
serializable	起きない	起きない	起きない	起きない

• ダーティーリード
  • コミットしていない変更内容が他のトランザクションから見えてしまう現象。
  • PostgreSQLのデフォルト設定
• ファジーリード
  • トランザクション中に、他のトランザクションでコミットした内容が見えてしまう現象。
  • トランザクション中の参照するタイミングによって、取得できる内容が変わってしまう。
  • MySQLのデフォルト設定
• ファントムリード
  • 他のトランザクションがコミットした追加・削除が見えてしまうこと。
  • 例えば、SELECT COUNT(*)がズレてしまう。
• ロストアップデート
  • 複数のトランザクションで更新が並列で行われた場合に、後勝ちの結果になること。

第15章　簡単過ぎる不整合

• 基本的には非正規化はダメ。
• キャッシュを組み合わせてカバーする（キャッシュ乱用も良くない）。
• JOINを減らしたければ、CHECK型やENUM型で正規化の階層を減らすことを検討する。

第16章　キャッシュ中毒

• キャッシュは複雑度を上げる。
  • データがおかしいのか、キャッシュがおかしいのかなどの切り分けが大変。
  • 参照されたタイミングのキャッシュがどのデータなのか把握するのが困難。
  • パフォーマンス面であまり依存しすぎると、キャッシュが消えてしまったら大障害につながる。
• キャッシュの種類
  • クエリキャッシュ
    • クエリの結果がキャッシュか否かの判別ができない
    • テーブル更新されるとクリアされる(更新頻度が高いとパフォーマンスが悪くなる)
    • 全く同じクエリでないとキャッシュされない(日時が絡んだりするとアウト)
  • マテリアライズド・ビューとサマリーテーブル
  • アプリケーション側でのキャッシュ

第17章　複雑なクエリ

テーブル設計が悪いか、（知識がなく）SQLの書き方が悪いを見極めること。

第18章　ノーチェンジ・コンフィグ

公式ドキュメントで何がコントロールできるかを知ること。

• 19.1. パラメータの設定
• MySQL :: MySQL 5.6 リファレンスマニュアル :: 8.11.2 サーバーパラメータのチューニング

一度適切に設定したら、大体は使い回せるので、ソースコードをしっかりバージョン管理すること。
初心者で情報が多すぎる場合は、チェックツールがオススメ。

• PGTune - calculate configuration for PostgreSQL based on the maximum performance for a given hardware configuration
• GitHub - major/MySQLTuner-perl: MySQLTuner is a script written in Perl that will assist you with your MySQL configuration and make recommendations for increased performance and stability.

第19章　塩漬けのバージョン

• メジャーアップデートの方法
  • ダンプ・リストア
  • 専用ツール、レプリケーション
  • アプリケーションからの2重書き込み
• 過剰に恐れず、旧バージョンに戻せるようにリハーサルしておき失敗できる状態にしておくこと。

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