bootjp

「分散システムの高い専門性」と「組織・事業への理解」で、技術から事業成長にレバレッジをかけるエンジニア

## 分散システムを専門領域として取り組んできたこと 私は、分散システム・分散ストレージを専門領域として、技術そのものを深く理解するだけでなく、研究領域に蓄積された知見と、顧客・事業への理解を組み合わせることで、価値のある課題を解決できるエンジニアを目指しています。 これまで、大規模なコンテンツ配信基盤、分散KVS、キャッシュ、Raftを用いた分散ストレージ、複数プロダクトを接続するイベントバスなど、分散システムに関わる設計・実装に取り組んできました。 ## 実務の課題を、研究領域まで遡って考える その中で感じているのが、実務で直面する課題の多くは「まだ誰も解いていない課題」ではないということです。 一見すると新しい技術課題に見えても、研究領域では過去に同種の問題に対して複数の解決方法が提案され、その前提やトレードオフまで評価されていることがあります。 そのため、技術課題に直面したときは、現在使われている製品や一般的な実装方法だけではなく、関連する研究論文まで遡って調べるようにしています。 論文を読むことで、 - その課題がどのように定義されているのか - 既存手法では何が解決され、何が未解決なのか - どのような前提のもとで成立するのか - 性能・一貫性・可用性・コストの間にどのようなトレードオフがあるのか - どのような方法で有効性が評価されているのか といったことを知ることができます。 すでに存在する知見を知らずに同じ問題を一から解き直すことを避けられるだけでなく、自分が持てる解決策の選択肢そのものを広げることにもつながります。 分散システムやデータベースの論文は継続的に読んでおり、得られた知見は技術メモや登壇資料として公開しています。 論文・技術メモ： https://memo.bootjp.me/ 発表資料・活動一覧： https://about.bootjp.me/#Publications:~:text=%E7%99%BB%E5%A3%87%E3%83%BB%E7%99%BA%E8%A1%A8%20(Presentations) ## 自分自身でも研究を続ける また、自分自身でも研究活動を続けています。 現在は、分散システムの安全性を確保する仕組みや、LSM-treeを用いたストレージの効率化について研究し、データベース・分散システム分野の国際会議へ論文を投稿しています。 現在は査読過程にあるため、研究内容の詳細はまだ公開できません。 ## 技術だけでは解けない問題がある 一方で、研究上優れた解決方法を知っていることや、高度な技術を実装できることだけでは、ビジネスにおいて価値のある課題解決にはならないことも、これまでの経験から学びました。 特にそれを強く意識したのが、以前プレイドで働いていたときの経験です。 当時は技術的に難しい問題を解くことに強く関心を持っていましたが、実際のビジネスでは、技術力だけで顧客に価値を提供できるわけではありませんでした。 顧客が何を実現したいのか、その実現を阻害しているものは何なのかを理解して初めて、技術を使って何を解くべきかを考えることができます。 ## 顧客や事業を見る視点を取り戻すための独立 もともと私は、独立して自社サービスを開発した経験や、所属企業で市場調査を行い、その結果をもとに新規サービスを立ち上げた経験があります。 その一つが「忍者アクセスランキング」で、市場を調査し、その中で見つけた需要と、自社が持っていた技術や強みを組み合わせてサービスを立ち上げました。 （詳細は年収評価シートの「市場調査からの新規サービス立ち上げ（忍者アクセスランキング）」をご覧ください） プレイドでの経験を通じて、技術を深く追いかける一方で、こうした顧客や市場を見る視点が以前より弱くなっていることにも気づきました。 そこで、もう一度技術だけに閉じずに仕事をしたいと考え、2023年に独立しました。 一人で法人を運営すると、技術だけを考えているわけにはいきません。 顧客にはどのような課題があるのか、自分の専門性でどのような解決策を提供できるのか、それに価値を感じてもらえるのかを日々考える必要があります。 この経験を通じて、技術的に解ける問題を探すのではなく、まず顧客や事業の側から解くべき問題を考えることを、改めて意識するようになりました。 ## 顧客が実現したいことから、解くべき課題を考える 技術的に解決可能な問題と、顧客が本当に解決したい問題は必ずしも同じではありません。 まず顧客が何を実現したいのかを理解し、そのうえでどのようなアプローチを取るべきかを考える必要があります。 たとえば、 - 顧客が実現したい状態は何か - 現在それを阻害しているものは何か - その問題はどの程度重要なのか - どこまで解決すれば十分なのか - 性能、信頼性、開発速度、運用コストのうち何を優先するべきなのか といったことは、技術だけを見ていても決められません。 顧客や事業を理解して初めて、研究や技術から得た選択肢の中から、その状況に合った方法を選べると考えています。 ## プリンシパルエンジニアとして、解決策を組織に広げる 現在のプリンシパルエンジニアとしての仕事でも、単に技術的に高度なシステムを作るのではなく、複数のプロダクトやチームが抱えている問題を整理し、必要な保証や制約を見極めたうえで、アーキテクチャや共通基盤として解決することを意識しています。 マルチプロダクト展開を支えるイベントバスの設計も、その一例です。 単に非同期メッセージング基盤を作るのではなく、サービス間の依存関係、障害の波及、開発者の認知負荷、既存システムからの移行コストまで含めて考え、設計・実装・導入を進めました。 発表資料： 「疎結合でスキーマ駆動開発を実現するイベントバスの設計」 https://speakerdeck.com/hacomono/building-an-event-bus-for-schema-driven-development-in-a-loosely-coupled-architecture プリンシパルエンジニアとして仕事をするようになってからは、自分一人が難しい問題を解くことだけではなく、その解決を他のチームでも利用できる形にすることも以前より意識するようになりました。 アーキテクチャや共通基盤、開発の仕組みとして残せれば、自分が直接実装できる範囲を超えて、プロダクトや組織全体に影響を与えることができます。 ## 今後目指していきたいこと 今後も、分散システムという専門性はさらに深めていきたいですし、研究領域の知見も継続的に取り込んでいきたいと考えています。 一方で、それだけを目的にはしたくありません。 顧客が何を実現したいのかを理解し、解くべき課題を見つける。 そのうえで、研究で積み重ねられてきた知見から解決方法を探し、自分の技術的な専門性を使って実際のシステムに落とし込む。 そして、その解決を一つの機能だけに閉じず、プロダクトや組織、事業全体に広げていく。 そうした形で、より大きな事業を技術からスケールさせられるエンジニアでありたいと考えています。