「新しい機能のデータストア、どれにしますか」とチームで相談が始まると、つい機能の比較表を作りたくなります。
候補を横に並べ、性能・機能・人気に丸をつけ、いちばん丸の多いものを選びます。
見た目は公平ですが、この表には、選んだ後に何年も払い続けるコストの列がないことがほとんどです。
テックリードが決める立場になったとき、比較表のどこに何を足せば判断が変わるのでしょうか。
私もテックリードを目指して学んでいる途中なので、公開されている一次情報をたどりながら整理してみます。
「その仕事に最適な道具」は視野が狭い
出発点にしたいのが、Etsy などでエンジニアを務めた Dan McKinley 氏のエッセイ『Choose Boring Technology』（2015年）です。
同氏は、「その仕事に最適な道具を選ぶ」という考え方を、「最適」と「仕事」の両方を狭く捉えすぎていると批判しました。
技術を一つ足すと、監視の仕組み、テストの書き方、触る人が覚えるべき知識、起動や運用の手順まで一緒に増えていきます。
エッセイはこの荷物を、主に「運用」と「認知的な負荷」と呼んでいます。
そのうえで、システムを安定して動かし続ける長期のコストは、作るときの不便さをほぼ常に大きく上回ると書かれていました。
だから同氏の言う「最適な道具」は、個々の課題で一番優れたものではありません。
できるだけ多くの課題に対して「いちばん悪くない」位置にいる道具、という定義に置き換わるのです。
比較表の丸の数が教えてくれるのは、この「足した後の重さ」を除いた部分だけ、ということになります。
エッセイの原文はChoose Boring Technologyで読めます。
技術を足すたびに増える認知的な負荷をチームの側から捉え、受け持つ領域の量と種類でチームを設計する考え方は、チームトポロジー入門の記事で整理しました。
新しい技術には「予算」がある
同じエッセイで有名なのが、イノベーショントークンというたとえです。
会社はおよそ3枚のトークンを持っていて、好きな使い方ができますが、その枚数は長いあいだ増えません。
新しい言語やデータベースを採用するたびに、この貴重な1枚を使う、という考え方になります。
ここで言う「退屈な技術」は、「悪い技術」の意味ではありません。
MySQL や Postgres、Python、cron などが例に挙がり、できることだけでなく、壊れ方までよく知られている点が価値だとされていました。
どんな技術にも「分かっていない未知」と「分かっていないことすら知らない未知」があり、新しい技術ほど後者が大きくなります。
選定で問うべきは「この技術は優れているか」より「ここでトークンを1枚使う価値があるか」、と言い換えられそうです。
新しい技術を一切使うな、という主張ではない点にも注意が必要です。
エッセイ自身も、手持ちの構成で全文検索を実装するのは現実的でなかったため Solr を採用した例を挙げています。
既製品を買うか自分たちで作るかも、同じ「足した後の重さ」で比べられるので、内製と SaaS 導入の分かれ目は別の記事で整理しています。
比較表には「選ばなかった理由」を書く
では、比較表そのものはどう作ればよいのでしょうか。
McKinley 氏がまず勧めているのは、何も新しく足さずに目の前の課題を解くとしたらどうするかを考えてみることです。
この問いは、「課題」の正体が実は「誰かがその技術を使ってみたい」だった場合を早めに見つけてくれます。
そのうえで、今の構成のどこが課題を解くのを非常に高くつかせているのかを、具体的に書き出すよう求めていました。
新しい技術が既存のものと重なったり置き換えたりするなら、古い仕組みから移行しきると約束し、その時期の見通しも示すことも条件に入っています。
こうした質問票を宿題として埋め、会議で話し合う、という軽い手続きで十分だというのが同氏の見立てです。
もう一つの手がかりが、Google の設計ドキュメントの書き方を紹介した記事『Design Docs at Google』です。
この記事は「検討した代替案」の節を、設計ドキュメントの中でもとくに重要な節の一つと位置づけています。
書くべきなのは、代替案それぞれがどんなトレードオフを持ち、それがなぜ選んだ案に劣ると判断されたのか、という理由のほうでした。
記事の本文は「Design Docs at Google」で読めます。
二つを合わせると、比較表に足したい列が見えてきます。
- 何も足さなかった場合の案と、その限界
- 採用すると増える運用と、覚えることの量
- 既存の仕組みと重なる部分と、移行の見通し
- 選ばなかった案と、選ばなかった理由
丸の数ではなく、トレードオフと理由が残る表にしておくと、後から入ったメンバーも同じ判断をたどれます。
設計ドキュメント全体の書き方と運用は、Design Doc 入門の記事にまとめました。
チームの採用状況を「地図」にしておく
一件ずつの選定とは別に、チームとして何を使ってよいのかを見える形にしておく方法もあります。
参考になるのが、Thoughtworks の「Technology Radar」です。
技術を「テクニック」「プラットフォーム」「ツール」「言語とフレームワーク」の4つの区分に分け、Adopt（採用）・Trial（試行）・Assess（評価）・Hold（保留）の4段階の輪に置いて整理します。
同社の説明では、Adopt は適切な文脈で使わないのは無責任になりかねないほど推せるもの、Trial は自分たちの道具箱に入れるかを試しながら決めるもの、という位置づけです。
同社は自分たち用のレーダーを作れるツールも公開していて、作る作業そのものを組織のあらゆる階層で技術の一覧を見直す会話として勧めています。
チームのレーダーがあれば、「いまトークンを何枚使っているか」を全員が同じ絵で確かめられるでしょう。
新しい候補を足す議論も、「Assess から Trial に動かすか」という小さな単位に分けやすくなります。
作り方の手順は「Build your Own Radar」にまとまっています。
最後に
技術選定の比較表に足したいのは、選んだ後に払い続ける運用の重さと、選ばなかった理由の二つでした。
新しさを使う「予算」には限りがあると意識しておくと、どこで冒険し、どこで退屈な技術に頼るかの線が引きやすくなります。
決めた理由を後から読める形で残すなら、ADR という記録の型が役に立つでしょう。
私自身は、次に何かを選ぶ場面で「何も足さなかったらどうするか」の一行から書き始めてみるつもりです。
以上です。
コメントを残す