その気持、わかります。
事業開発者、経営者やプロダクトマネージャーたちが抱えがちな悩みの一つ。それは、競合他社や業界の改善スピードに自社のプロダクトの開発スピードが追いつかないという問題です。
実際には、競合企業のリリース情報や世の中の新ニュースに単に踊らされているだけ、ということもあるわけですが…！？それはそれとして、開発のリリースサイクルや開発生産性は時間が経つほど勝手に悪化していくものなので、エンジニアであれば常に改善しようという心構えを持つべきでしょう。
では、そのことにどう対処すべきなのか？
ここでお話するのは、スケジュールやロードマップを調整するとか、人を増やすだとか、そういう直感的な方法論ではありません。「継続的デリバリー」のような、技術側に寄った非直感的なアプローチです。
やれば開発スピードのみならず、生産性や品質といった様々な指標にも影響を与えるわけで、その効用も多くの書籍で語られているわけですが。これをやったことない人には、全然理解できない、想像もできない、非直感的に見えてしまう、という性質を抱えたものでもあります。なので、僕の経験談なんかも交え、できる限りイメージが伝わるようにお話できればと思います。
1. デプロイの時間を短く、そして簡素に
「エンジニアのためのマネジメントキャリアパス（O'REILLY）」の著者であるCamille Fournierが、Microsoft所属時に開発チームの改善のために、まずはデプロイ、すなわち本番環境へのコードの反映作業を高速化させることに集中したと語っていました。僕はその時、その意図を全く理解できませんでした。しかし実際に、デプロイに1時間を要する環境と、5分で完結する環境の両方を僕自身が経験した時に、開発の現場にもたらす大きな違いを発見したのでした。
1時間が5分に縮むこと、デプロイ作業の簡素化によって得られるのは、単純な作業時間の短縮という人月的なコストメリット…ではなく、メンバーの「デプロイに対する心理的負担の低下」です。
心理的負担が減ると、僅か数行のコードのデプロイを、ためらわずにすぐに出せるようになります。Pull Requestの大きさ、すなわちデプロイするためのコードの修正範囲は小さくなり、それによってリリースサイクルも短縮化されます。バックログ・開発タスクの処理に何日もかかっていたのが、一日に2-3件でもテンポよく潰せるようになります。エンジニアが入社初日にいきなりPull Requestを作りデプロイできてしまう、なんてことも普通に起こります。
ミーティング中に出てきた課題を、わざわざスケジュールに盛り込むではなく、その場でコードを書いてPull Requestにする。ミーティングが終わった時には本番環境に反映されてしまう、なんていうスピーディな対応を僕は何度も目撃しました。メドピアの事例がまさにその典型例でしょう。
また、デプロイのオペレーションが簡素化されると、チームのリードのような権限を持つ人々以外にもデプロイできる構造が生じます。新人エンジニアのみならず、非エンジニアまでもデプロイに直接関与する可能性が生じます。CSやオペレーターのような技術からやや遠い距離にある人々が、簡単な文言やハイパーリンクの修正、デザインの微修正を率先して自分で行える、何をするにも「エンジニアさんにお願いする」という状況から脱却する可能性も生まれるわけです。
非エンジニアが最短の解決方法を考え、Pull Requestという形にしてエンジニアにレビュー依頼をする。これは、開発プロセスのあらゆるコミュニケーションコストが削減されるに違いありません。一度でもコードをマージされたことがある非エンジニアの提案には、エンジニア目線でみても驚くほどリアリティを持ったものです。
過去にやってきた現場では、以下のようなことも起こっていました。
実際にはCS向けに技術勉強会を開くといった多くの労力を割いていたのですが、CSからこういう技術的アクションが起こるというのは、間違いなくデプロイの仕組みを徹底して高速化し簡素化するという、地道な努力があったからこそ成せたに違いありません。
「あの課題は、自分の力で、自分が考えるアプローチで解決するのが最速だなぁ」と、プロダクトに関わる多くの人々にそう思わせることができたのならば、間違いなく勝ちです。
2. カナリアリリース・ABテストを扱えるようにする
カナリアアップデートというのは、全ユーザーの数%に対してリリースするという手法です。徐々に、最新のリリースをユーザーに対して提供していき、数日、場合によっては1ヶ月という期間をかけて全ユーザーに広げていくというアプローチです。
カナリアやABテストというのは、そのリリースによって機能が、ユーザーに使われるのかどうか、あるいは良い結果を生み出せるのか、というのをテストするための手法という風に紹介されがちです。ただ実態としては、本番環境で動かしたことによって見つかる未知のバグを発見したり、インフラが負荷に耐えられるのかを実地で確認できる、といったエンジニア側にとってのメリットも多分に含んでいます。デプロイの心理的負担を下げることができるのです。
ユーザーにみえないところで、ロジック側でこっそりと特定のリスクが高いメソッドを呼び出し、その負荷状態をみる、といったアプローチもできます。これからハイリスクなリリースをしなくてはいけないという状況ならば、ユーザー側に見えないところでこっそりと問題を探るといったことができるわけです。Facebook（現Meta）は数年前に、EC機能に必要なJavaScriptのコードが本番環境に混ざっていて、それがたまたまリリース前に発見されれるという事件がありました。
これらのアプローチは、そこまで難しいものではありません。理想はプロダクトにカナリアやABができる仕組み自体を作り込むことですが、生まれたてのプロダクトであればコード上に直接書いてしまうという簡素なやり方でも十分機能します。ユーザーIDの下一桁で、古いコードと新しいコードとで分岐させたり、独自にランダムな数値を生成してWebStorageやCookieに書き込んで使い回す、という方法でも良いでしょう。
これらの狙いは、リリースのあり方にバリエーションをもたせること、エンジニアに手札を多くもたせること、これが本質だったりします。
大規模なリリースであれば、「サイレントアップデート」と呼ばれる手法もあります。正式な告知を行う数時間〜数日前にリリースし、ユーザーの反応をみながらリリースの意思決定をする、というアイデアです。いきなり出すことで生じるリスクを取り除き、安心安全にリリースを行えるというメリットがあります。
また、「導線だけを作ってLPを置く」というアプローチもあります。これは、機能開発をする前に、導線だけを作り、その先には未完成である旨を伝えるLPやニーズ調査をするフォームを置くという手法です。リーン関連の書でも何度か触れられており、Shopifyもこのアプローチを扱っていたなんてことを聞きますが。負の面も大きいため、プラットフォームの規模によりけりというのが僕の所感です。
3. テスト追加やリファクタリングに2割以上のパワーを割く
「エンジニアのためのマネジメントキャリアパス（O'REILLY）」の著者であるCamille Fournierは、同書の中で「システムの持続可能性維持作業には2割の労力をさけ」と語っています。つまり、テストの追加やリファクタリングのような活動に対して、それぐらいのコストを割くべきだと言ってるわけですね。
僕はGoogle Chromeの開発リポジトリを眺めるのが趣味だったのですが、一昔前だと開発体制がGoogle Presentationで公開されていて、各メンバーがどういう仕事をしているのかを確認できてとても勉強になったものです。そこでは、2割どころか4割ぐらいのメンバーをそういう活動に注力させているようなチームも見当たりました。彼らは「Refactoring」「Architecture changes」みたいなコミットログをひたすら生産していました。
全体を通してアーキテクチャの問題を直していく、TypeScriptや最新のPHPなら型定義を網羅的に入れていく、みたいな活動もあり得るのでしょうが。Chromeだと、ロードマップ上に存在するこれから行う機能開発に対して、下準備をする形でリファクタリングをしているようなケースが散見されました。実に合理的だなぁなんて思いみていたものです。
ただ、デプロイの仕組みに手を入れる、リリースのワークフローに手を入れる、というアプローチと同様に、テスト追加やリファクタリングもまた非直感的なものです。一旦は、2割と決めてルール化してやってしまうのも手ではないかと経験則として思います。
最後に - 「非直感的」を行動に移す能力
スケジュール・ロードマップを変える、とか、人を増やすとか、この手のアプローチは直感的だしマネジメントとしても比較的容易に扱えるように思えます。しかし、もしエンジニアリングマネジメントという役割を担っているのならば、専門性を持つ僕ら自身にしか理解されないであろう非直感的な活動に向き合う必要があるかと思います。
これを良しとして通すか否かは、組織あるいはチームでの実行力にかかっていると僕は思います。人間と一緒に何かをしないといけないわけで、つまりは人間に向き合うことからは逃れられないということですね…！
先日、元東急ハンズ・元メルカリのCIOである長谷川 秀樹氏と食事をしに行ったのですが。彼が色んな会社へコンサルティング活動をしている中で感じている、以下のような言葉を印象的に感じています。
「僕はアフターデジタルを知っているのだけど、それを実現するには、実行に移せる役員やチームがいることが何よりも大事」
また、現在PR TIMESでCTOを務めるcatatsuy氏とも年末に食事に行ったのですが、彼もやはり同じようなことを言っています。
「実行する権限がもつことが必要。だからPR TIMESへの入社にあたり、執行役員へなることにこだわった。」
専門家にしか捉えられない非直感的なアプローチを、ちゃんと実行に移せる組織の体制、あるいは権限を持つというのが何よりも重要なことだと彼らは語ったわけですね。
サイレントリリースなんてやってる暇があるならとっととリリースしてほしい、デプロイやリファクタリングに時間を使うぐらいなら全力で機能開発をしてほしい、そういう直感的な要望は日々寄せられますが。そこに「NO」と言い、強い気持ちを持って本質的な問題の解決にあたる、その意思の強さが大事なんだと彼らから学んだのでした。
僕も彼らのように、非直感的なことに向き合い頑張りたいと思います。
