『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』を読んで 〜腕力〜
ソフトウェア界隈でとても話題になっている『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』を読んだのです。
一口に言うと、とてもリアルで身近な現場の話。VOYAGEグループの中のいくつかの事業を運営する開発現場のインタビュー集です。インタビュワーの和田さんの質問が的確に読み手の疑問を深堀りしていっている。
繰り広げられる会話が身近で共感できつつ、その中に考え方のエッセンスがうまく一般的な用語・知見とマッピングされています。それは、ところどころcolumnとして補足される情報から読み取れます。
また、ところどころ広告事業や人材採用向けサービスという事業領域に特化した業務知識の補足もあり、興味深かった。自分は事業とそこから生まれる要求に対して、どのように整理・意思決定していくか、という点に関心が強めです。そんな自分にとって本書で繰り広げられる話は、その意思決定のプロセスを trace で見るような面白さがありました。
そこで彼らが語ってくれ たのは、現実の世界で次々に発生する問題やチャレンジングな目標を時には腕力、時には調整力、時には洞察力でもって解決していく、当事者意識と技術力を備えた技術 / はじめに
以降、本書を読んでいて、「ここ興味深いな〜」というところをちょっと脱線しつつ、まとめていきます。
技術的負債を返済する腕力
fluct の管理画面の技術的負債の返済について、次のような話をしていました。
技術的負債の返済速度が開発速度を上回っ たのが 2018 年くらいといえそうですね。技術的負債は、賢くやるだけではなく、腕力がないと返済していけない。 / 第 1 章 fluct ――― 広告配信の舞台裏の技術者たち
技術的負債の解消、とくに大きな効果を生むような長期的な取り組みにおける、技術的負債において、「腕力」でががっと取り組む人かどうか、というのは成果の発揮に大きな影響を及ぼすと思っています。とまぁ、現職で他のテックリードやCTOを見ていて、「他とは決定的に違う点はなにか？」を考えたときに漠然と思っていたことです（自分が「テックリードとして足りてない行動傾向はないかと日々考える過程で色々思うことがあります）。
この腕力について、インタビュワーの和田さんの言語化は、とても納得感がありました。
関係ないところに手を出す力、放っておかない力、というのがまずあると思います。 重要だけど緊急でないから誰も手をつけないところをゴリゴリ巻き取っていくためには、 カッとなる力、放っておかない力が必要です。 そのうえで、それを短期間で仕留める力ももちろん必要になります。 率直に言うと、技術的負債を返済できる企業とできない企業があるのは、この腕力の有無 によるという面も否定できません。 / 第 1 章 fluct ――― 広告配信の舞台裏の技術者たち
関係ないところに手を出す力、放っておかない力って、言うは易く行うは難しで、とても貴重なように思えます。ここまで 2 社を経験したわけですが、この行動原理を持っているなぁと思い返して思う人は1桁くらいしか思い浮かびません（自分もそこまでこの行動原理を体現できている人間ではないと思っている）。
そして実際に行動を起こしきるには、そもそも放っておけないと思えるだけ現状の課題を感じられる経験と学習の広さ・深さ、その課題を解決する純粋なプログラミング力、様々な調整ごとをチームを越境して行い問題解決すること、と総合力のたわものでしょう。
fluct の管理画面の技術的負債の返済を推進したすずけんさんのエピソードには、たしかにその腕力が感じられて、素敵だなぁと思いました。
腕力の伝搬条件
上の腕力の話から、じゃあその腕力ってどう伝搬していくんだろうなぁとふと考えることがあるのです。
同じチームに、顧客対応に非常に積極的で素晴らしいムーブメントをしているの同僚がいるのですが、「すごいっすよね！」って話をしたときに、「東口さんがほかチームに単騎で乗り込んでいくような動きをしていて『そういうもんなのか』と思って...」みたいな意見をもらったのです。自分自身蓋を開けると、子会社所属の１エンジニアとしてグループ会社メンバーと蜜に連携するとなると、そういう課題解決の仕方になる、っていうだけだったのですが、身近な人間を見て伝搬していくのだなと（これは腕力が自分にあるということは前提としていなくて、身近な振る舞いが自然とその組織の文化になっていくのかもなって思ったっていうこと）。
実際にその同僚を見て、同じチームの違うメンバーも、同じような動き方に変わっていったりしていました。
良いものも悪いものも、近しい同僚の振る舞いが伝搬していく、と考えると、腕力のある人が周りにいるかいないかで、自分の腕力の想定的な差・不足している課題解決力、に気がつけるのかもしれない。
Zucksにおけるエクストリームなプラクィス
Zucksのエピソードの中で印象深かったのは、和田さんの次の言葉でした。
2000 年くらいに XP が出てきたときのことを思い出しました。あのとき、ケント・ ベックが書いた本を読んでも、それだけでは「なんでこのやり方でうまくいくの？」という のが全然わからなかったんです。 XP を解説した本では、いくつかのプラクティスが示されているんですが、一つひとつの プラクティスを見るとすごく無茶なものもあったりします。でも、実はそういう個々のプラ クティスが補完しながら、全体の系としてうまく回るようになっているんですよね。 / 第 2 章 Zucks ――― フルサイクル開発者の文化
Zucksさんの文化には、「ドキュメントがまったくない」文化や、「全員がフルサイクル」といいった個々で印象的な話があります。たぶん、Twitterとかで単体でこの話をすると、めっちゃめんどくさそうで、うるさいガヤがたくさん集まってきそうですよね。
ただ、「全体の系としてうまく回る」という表現はしっくりくるなと。ここのプラクティスだけを部分的に見て評価するのではなく、それが全体としてどのような脈を打っているか、組織の生命として成立しているのか、この視点はとても大事だなと。
一見歪な木が有るように見えても、これは森を見たときには非常に合理的ということがあり得るのでしょう。そして森の成長とともに、その歪な木は伐採しないといいけないのかもしれないし、そうではないのかもしれない。
おそらく、この全体の系としての成立は、主体としてZucksの河村さんや前田さんがいて、そこに第三者視点としての和田さんがインタビュワーとして会話していく、という構図によって初めて納得感を持って表現されているんだな、と感慨深くなりました。
葬りの知見
Voyage Marketingさんは、レガシーシステムに対して、機能・事業を以下に葬っていく（消していく）か、という話について印象深かったです。
自分自身、使われていない機能を消すということは現職で何度かやってきていますが、そのたびにそれなりの調整を持って強い意志で意思決定してぐっと力を込めて消す、ということをしてきた（はず）。消すという行為は難しいですよね。消極的になりすぎても課題解決に全くならないし、とはいえ積極的にやってしまうと「暴走」になって破壊してしまう。
本書で紹介されているのは、事業ごと消していく、という観点で、身近ではときおりCTOが局所的な機能に対して取り組んでいたりするのですが、本書の例のアプローチは一つの思考パターンとして、自分の中のインデックスに入れておこうと。
後発メディアの戦略
Voyage Lighthouse Studio さんの話では、ゲーム攻略のメディアを先行メディアがいるなかで立ち上げていく話ですが、ミニマムにシステムを作って事業をはじめて行く戦略が印象に残りました。
また、先行メディアのマネをするわけではないという、ランチェスター戦略的な事業経営を、いかに開発組織として支え・促進するか、0->1を行うソフトウェア設計が面白かった。
ぼくが一番大事にしてきたことは、システ ムがもたらす制約やコストを極力減らすことか もしれません。わかりやすくいうと、ランニン グコストの削減です。 / 第 4 章 VOYAGE Lighthouse Studio 数十万記事のメディアをゼロから立ち上げる
そしてこのフェーズにおいては、以下に事業を伸ばしていくか、という戦略に対して、逆算思考でのシステムアーキテクチャ設計が求められることを、学び取れました。
事業性格からMVPを捉える戦略
サポーターズさんの話では、外部ベンダーに依頼して作ったシステムと、現状の運用が大きく乖離した状態、でリプレイスを手掛けた話ですが。面白かったのは、彼らのリプレイスにおける優先順位設計・MVPをどこにおくか・リリース計画が、採用事業という事業特性に根ざしたものだった点でした。
新卒採用というフィールドならではの事業特性に合わせてリプレイスをうまく計画していて、これは事業を理解して、その中でタフでストレスフルな関係構築フェーズを乗り越えた先でないと、そうできることではないと思います。
かんたんな語り口で書いていますが、当時の現場がどれだけビジネスにより寄り添って奮起したか、その心境が慮られ、胸が痛くそして熱くなるエピソードでした。
エンジニアからデータサイエンティストへ
Zucksの西村さんのキャリアは、とても自分にとって参考になるものだった。自分が非常に機械学習・データ処理の比重が重い事業の中をしているか、この分野は自分たちの仕事のあり方・システム化対象の業務のあり方を大きく変えるポテンシャルがあると日々感じます。
「事業とその業務ドメインはどうあってもあり続ける」と言いますが、その事業ドメインのどう運営していくか、において、己が捨象して捉えた「ドメイン」という世界を定義するという、領域だけでは不易流行な人間になるのでは、と感じています。つまらない俳句を書いてしまうように時代遅れのシステムを作ってしまうのではないか。
つまり、アプリケーションのソフトウェアエンジニアも、データサイエンス・機械学習の理論・実現手段と距離を近く必要があるのでしょう。
というような事業上・個人の背景もあって、社のデータ戦略チームの定例MTGには毎週参加するのですが、その危機感の解消に対して一歩も進められていない自分がいるのです。
一歩前に踏み出さねば、と改めて刺激になりました。
おわりに
赤裸々な話が共感もあり学びもあり、非常にいい本でした。同時に、自社でこういうtech bookをもしやるなら、これだけ語れるだろうか？と考えたときに、もっと目の前で起きていることについて目を見開いて、分析を続けないといけない、と兜の緒を締め直したのでした。
この記事が気に入ったらサポートをしてみませんか？