2020年12月7日
『DMM.com を支えるデータ駆動戦略』（石垣 雅人 著，松本 勇気 監修，マイナビ，2020年9月26日）を読了。
アジャイル開発の基本は「プロダクト開発において確実なものなど存在しない。失敗することが前提」という考えのもと，「小さく早く作ってリリースする」ことを大事にしています。「なぜその機能が必要なのか」を考えた上で，いかにプロダクトにおける最小限の機能を構築して，すばやく市場へ投入できるか。そこからユーザーの反応を見て学習し，再度最適化された機能を提供できるか，といった方法が主流になって広がり始まりました。
私はこの考え方が大好きです。（p. 4）
私もこの考え方を真似したいです。
組織の中で，データアナリストなどのデータに関わる人だけがデータ駆動することで，影響力が局所的な部分でとどまってしまいます。組織にいる全員が「データに基づく意思決定」の重要性を理解して，本書で述べていくプロセスを実践していかなければなりません。（p. 5）
まずは，データに基づく意思決定ができる人を増やしていく。
ユーザーという指針を頼りにしながら，実験を繰り返し，そこから得られる結果をデータという大きなファクターをもとに学習して意思決定していくことが大事になってきます。
これは，エリック・リースのリーン・スタートアップという考え方に通じるものがあります。2011 年に出版されたリーン・スタートアップの中では「地図を捨て，コンパスを頼りにして進めよ」という概念があります。（p. 97）
コンパスはユーザーである。
一方，施策が失敗したとしても組織としてきちんと振り返りを行い，「なぜ受け入れられなかったのか」をあらゆる観点で分析して，次の施策へ活かす活動にすることで組織に改善のノウハウを貯めていくことが大事です。
そうすることで改善施策の再現性が徐々にですが現れてきます。こうした改善ノウハウによって，私たちは大きなインサイトを発見して大きく施策を当てるのではなく，数 % の改善を多く続けることで事業全体をスケールさせることが可能になります。（p. 104）
失敗したら，その振り返りを行い，新しいチャレンジにつなげる。
反復型開発とは，Interative and Incremental Development という名前からもわかる通り，イテレーティブ（iterative）とインクリメント（increment）を組み合わせた開発です。
つくるべきシステムをいくつかの部分に分解していき，その部品ごとに要件定義→設計→開発→テストという工程を繰り返していき，段階的に結合します。つまり，イテレーティブ（反復）にインクリメント（積み上げ）していく開発スタイルです。（p. 118）
まずは，因数分解して，因数ごとに工程を進めていく。
仮説を問う検証が必要であれば，アジャイルで開発してみる。
ベイビーステップ（Baby Steps）
何をするにも，大きく変更をするのではなく，小さなステップを踏みながら改善を繰り返していきましょう。それが結果として大きな変更になっていれば良いのです。大きな変更を一気に実行すると危険です。できるだけ小さな改善を細かく積み上げていき，その都度出てくる課題をこまめに潰して行きましょう。（p. 252）
大きなステップではなく，小さなステップを歩んでいく。
YAGNI とは，"You Aren't Gonna to Need IT." という意味です。解釈は様々ですが，実際に必要となるまでは機能追加はしない方が良い，ということです。先を予測して，現段階では不要な機能を盛り込んで実装することで，ムダが発生します。できるだけ，シンプリティを大事にして「いま」必要なもののみを対応して，随時必要なものをリファクタリングしながら追加していきましょう。（p. 256）
必要な機能を必要なときに追加できるようにする。
案件やプロジェクトを個の手腕で回しているだけでは二流で，それに再現性をもたせる部分までできれば一流です。個人に依存する形ではなく，個がもっている暗黙知をパターン化して，ある程度誰がやっても成功するパターンをつくれることこそが戦略的 Unlearn で目指すべき部分です。（p. 324）
誰がやってもできるようにしておけば，自分の手を離れる。
- 意思決定の速さ……少人数であること
- 意思決定のスムーズさ……外からの介入率が低いこと
- 小さく失敗できる……失敗許容性を分析できる予算の可視化（p. 330）
今のチームは，上記の 3 つが実践できるかも。
データ駆動とは，データドリブンともいい，データを見ることで次の行動に駆動してつなげることです。データを動かすことで，見えてくる新たなデータの価値を観察しながら，私たちは日々事業改善を行っています。（p. 337）
データドリブンで日々改善を行っていく。
DMM.com では，各技術領域や言語単位でチャットツールのチャンネルがあります。普段の業務の中で，技術的に困った部分や相談したいことがあれば，気軽にチャットで相談しノウハウの展開をしていきます。そこで大事なことは，誰でもパブリックな情報にアクセスできる透明性を担保することです。（p. 341）
メールのようなクローズなコミュニケーションよりも，チャットのようなオープンなツールでノウハウを展開してみよう。
- データレイク（Data Lake）……データの湖
- データウェアハウス（Data Warehouse）……データの管理倉庫
- データマート（Data Mart）……価値があるデータ（p. 346）
データレイクから，価値のあるデータをくみ取ろう。
そこで，DMM.com ではデータ定義が社内の OSS（オープンソース）と呼ばれるもので，誰でも変更申請ができる形のコミュニティで運用されています。例えば，特定データの意味を補足したい場合にはこの OSS に対してプルリクエストと呼ばれる変更内容のリクエストを担当部署に送ることができ，承認されればマージされドキュメント更新ができるような形で，ドキュメントがわかりやすく更新される運用になっています。（p. 362）
社内の規則の解説（マニュアル）は，オープンにしてみてもよいのかもしれない。
