はじめに
去年、自分が担当していた検索機能の改善で、ちょっと恥ずかしい失敗をした。レコメンドのロジックを差し替えたらクリック率が1.8ポイント上がったので、意気揚々と週次のレビューに持っていった。そこで「サンプル期間がキャンペーンと重なってないか」と聞かれて、何も答えられなかった。
コードは書けていた。テストも通っていた。でも、自分が出した数字が何を意味しているのかを説明する言葉を持っていなかった。実装力の問題ではなく、数字の読み方と問題の立て方の訓練をしてこなかったツケだと思った。
それからしばらく、フレームワークの本を買うのをやめて、計測と問題定義と学習のやり方そのものを扱う本を読むようにした。地味だが、効果は想像より早く出た。設計レビューで的を外す回数が減り、障害の振り返りで「で、何が原因だったのか」を言語化できるようになった。
この記事では、そのとき役に立った4冊を、データの読み方から実行の仕組みまで順番に並べて紹介する。どれも日本語版があって、分厚すぎない。1冊ずつ、今の自分の詰まりに近いところから読めばいい。
① 統計学をまる裸にする データはもう怖くない — チャールズ・ウィーラン
著者はシカゴ大学で公共政策を教える経済学者で、エコノミスト誌の記者も務めていた。数式を並べるより、どこで人が騙されるかを語るのが上手い。
扱うのは統計の考え方そのものだ。平均と中央値がずれる場面、相関を見て因果を語ってしまう瞬間、標本の取り方がすでに結論を決めている状況。教科書的な公式の導出はほとんど出てこない。
代わりに、実際に世の中で起きた誤読の事例が延々と続く。学校の成績評価、医療検査の精度、スポーツ選手の成績推移。読んでいると、自分がダッシュボードで毎日見ている数字がどれも同じ罠を踏みうると気づく。
自分に刺さったのは、標本バイアスの章だった。ログが残っているユーザーだけを分析対象にしていた時点で、自分の分析はすでに歪んでいた。離脱したユーザーはログを残さない。当たり前の話なのに、気づくまで半年かかった。
注意点として、推定や検定の実務的な手順を学びたいなら物足りない。これは土台を作る本で、計算の手引きではない。
こんな人に: A/Bテストやログ分析の結果を、自信を持って説明できるようになりたい人。
② 問題解決のアート — ラッセル・リンカーン・アコフ
アコフはオペレーションズリサーチとシステム思考の草分けで、ペンシルベニア大学で長く教えていた。組織を部品の集まりではなく相互作用の塊として見る、という視点を徹底している。
本書の中心にあるのは、問題への向き合い方の分類だ。分析して解く、経験で収める、そして条件を変えて問題自体を消す。この三つ目を、アコフは「溶かす」と呼ぶ。
エンジニアリングに置き換えると、腑に落ちるところが多い。遅いクエリをチューニングするのが一つ目、キャッシュで誤魔化すのが二つ目、そもそもその画面でその集計が必要なのかを問い直すのが三つ目にあたる。
もう一つの軸が理想設計だ。今の制約を全部外して、ゼロから作るならどうするかを先に描く。そこから逆算して現実に落とす。レガシー改修の計画を立てるときに、この順番はかなり効く。
やや古い本で、事例は企業組織の話が中心だ。そのままシステム設計に当てはめようとせず、構造だけ借りて自分の文脈に翻訳しながら読むのがいい。
こんな人に: 要件を言われた通りに実装するのではなく、問題の切り方から関わりたい人。
③ 習得への情熱―チェスから武術へ―:上達するための、僕の意識的学習法 — ジョッシュ・ウェイツキン
著者は全米チェスジュニア王者で、その後に太極拳の推手で世界選手権を制している。まったく違う二つの領域でトップに届いた人間が、自分の学習プロセスを言葉にした本だ。
話の軸は、技を覚える手順にある。ウェイツキンは駒がほとんどない終盤から学び始めた。要素を極端に減らして、原理を体に入れてから複雑さを足していく。
ミスの扱い方も繰り返し出てくる。一つの失敗が崩れを連鎖させる局面を、彼は「負のスパイラル」として分解し、どこで断ち切るかを訓練する。障害対応の最中に判断がぶれていく感覚に、心当たりがある人は多いと思う。
新しい言語やフレームワークに触れるとき、自分は最小構成から始めるようになった。チュートリアルを一気に写経するより、要素を一つずつ足して挙動を確かめたほうが定着が速い。この本を読んでから、やり方を変えた。
技術的な内容はゼロで、チェスと武術の話が延々と続く。そこを楽しめるかで評価が割れる本だとは思う。
こんな人に: 技術のキャッチアップ速度そのものを上げたい人。
④ 新装版 はじめてのGTD ストレスフリーの整理術 — デビッド・アレン
アレンは生産性コンサルタントとして30年以上企業向けの指導をしてきた人物で、GTDという手法の提唱者だ。本書はその入門にあたる。
中身は五つの工程に整理されている。頭の中にあるものを全部外に出す、それぞれが何を要求しているかを判断する、文脈ごとに並べる、定期的に見直す、そして実行する。
効くのは最初の一歩だと思う。やるべきことを記憶に置いている間、脳はそれを保持し続けるために容量を使う。全部書き出してしまえば、その分を考えることに回せる。実装に集中できない日が続いたとき、原因はタスクの量より未整理の量だった。
二分で終わるならその場で片付ける、という判断ルールも素直に使える。レビューコメントの返信やチケットのラベル付けみたいな細かい作業が溜まらなくなった。
一方で、仕組みを完璧に作り込もうとすると破綻する。自分も一度ツール選定に凝って挫折した。紙とテキストファイルから始めて、週次の見直しだけ守るくらいが続く。
こんな人に: 抱えている作業量は変わらないのに、集中できる時間が減ってきた人。
まとめ
| ステップ | 読む本 | 得られるもの |
|---|---|---|
| 数字を疑う | 統計学をまる裸にする | ログや実験結果を誤読しない目 |
| 問題を立て直す | 問題解決のアート | 要件そのものを問い直す視点 |
| 学び方を変える | 習得への情熱 | 新技術の定着を速める手順 |
| 実行を支える | はじめてのGTD | 考える時間を確保する仕組み |
今の詰まりに応じて、1冊だけ選ぶならこうなる。
- 分析結果の説明で詰まるなら、統計学をまる裸にする
- 言われた通りに作ったのに成果が出ないなら、問題解決のアート
- キャッチアップが追いつかないなら、習得への情熱
- タスクに押されて設計を考える余裕がないなら、はじめてのGTD
4冊とも、読んですぐ実装が速くなる類の本ではない。ただ、半年後にレビューで答えられる質問の数は確実に増える。自分はそこで効果を実感した。