Team
ものづくりの過程では、多くの思考が表に出ないまま埋もれてしまいます。私たちの取り組みの範囲や影響が広がるにつれ、共有する価値のある多くの学びが蓄積されてきました。それらは、エンジニアリング、プロダクト、そして組織づくりに関する意思決定にまで及びます。
このブログは、そうした思考の一部を外に向けて発信する場です。今後は、どのようにプロダクトを構築しているのか、どのように意思決定を行っているのか、そしてスケール、品質、スピードをいかにバランスさせているのかについて書いていく予定です。このブログが、私たちの仕事の進め方を理解する一助となり、私たちが誇りに思うエンジニアリングカルチャーを伝えられれば幸いです。
私は現在、AxonでChief Product and Engineering Officerを務めていますが、日々の業務上のロールはMTS（Member of Technical Staff）です。これは、チームの多くのメンバーと同じ役割です。日常の仕事ぶりも、チームの他のメンバーと大きく変わりません。コードを書き、設計に向き合い、技術的な議論に時間を費やしています。Axonのエンジニアリングやプロダクトを率いるリーダーたちも同様です。
私たちは、方向性を示す立場にあるリーダーこそ、ハンズオンの仕事に近いところにいるべきだと強く信じています。細部への深い理解、システムが実際にどのように振る舞うのか、どこにトレードオフが生じ、どこに複雑さが潜んでいるのかを把握すること——それこそが、長期的に良い意思決定を行うための土台になります。
Axonにおいて、「ビルダーであること」は、いずれ卒業するフェーズではありません。私たちが意図的に持ち続けたい、仕事であり、ライフスタイルそのものです。
この考え方は、社内コミュニケーションのあり方にも反映されています。私たちは、作り込まれたリーダー向けレポートや、プレゼンテーション中心のアップデートに過度に頼ることはしません。代わりに、「成果物そのもの」を通じてコミュニケーションを行うことを重視しています。コード、ダッシュボード、デザイン、そしてシステムそのものが、現状や進捗を可視化します。実際に本番で動いている成果物に根ざしたコミュニケーションは、誠実さを保ち、意図のズレを最小限に抑えてくれるのです。
私たちの哲学は、言葉にするのは簡単ですが、実行するのは決して容易ではありません。 それでも私たちは、次の3つを同時に実現することを目指しています。
私たちは、これらの目標が互いに相反するものだとは考えていません。もし、どれか一つが継続的に犠牲にされているのであれば、何かが間違っています。多くの場合、それはインセンティブ設計、組織構造、あるいは「良いもの」を見極める感覚の問題なのです。
私たちは、極めて大きなスケールで稼働するプロダクトに責任を持っています。それに比べると、私たちのチームは、同規模の企業で一般的に想像されるよりもずっと小さいかもしれません。
しかし、これは偶然ではありません。
私たちは、比較的スキルセットが均質な、マルチファンクショナルなチームとして運営しています。役割を過度に細分化したり、硬直したオーナーシップの境界を設けたりすることは避けています。その代わり、仕事の進化に応じて、課題領域や技術、プロジェクトを横断して動ける自由をメンバーに与えています。
この体制によって、少人数でもスピード感を持って動くことができ、組織的な摩擦を減らし、意思決定が行われる現場にコンテキストを保つことができます。もちろん、トレードオフは明確です。このモデルは、強固な基礎力と高い信頼関係を前提とします。私たちは、そのトレードオフを意識的に選んでいるのです。
私たちはスコープを厳密に固定せず、原則として、ほぼ誰でも、ほぼどの領域の仕事にも関われるようにしています。その結果、過去に自分たちが作ったシステムを守り続けなければならない、あるいは永続的に背負い続けなければならない、と感じる必要がありません。何かを作り、基準を満たすまで改善し、その後は次へ進む。オーナーシップや保守の責任は、Axonのエンジニアリングチーム全体で共有されます。
こうした仕組みによって、長期間運用されるシステムにありがちな「見えない摩擦」を大きく減らすことができ、情報のサイロ化を防ぐことにもつながっています。
これは一般的な常識とは相反するかもしれませんが、私たちは過度なドキュメント作成を推奨していません。その代わりに、「直感的に理解できるエンジニアリング」へと重心を置いています。
アンチパターンが少なく、論理的で美しい構造を持つシステムは、それ自体が理解しやすく、進化させやすいものです。ドキュメントは、ときに設計のまずさを正当化するための“免罪符”として使われてしまうことがあります。その結果、多くの企業では、古く、不完全で、誰にも読まれないドキュメントが量産されがちです。
私たちは、ドキュメントの質を後から改善しようとするのではなく、そもそもそれを必要としない設計を目指しています。このアプローチは、情報のサイロ化を防ぎ、オーナーシップの共有を現実的なものにし、設計段階でより高いエンジニアリング規律を求めることにつながります。
私たちは、エンジニアリングの品質と「美意識」を非常に重視しています。
重要度の高い課題については、既存のソリューションでは要件を満たせない場合、内部で高度に最適化されたシステムを深く作り込むことがあります。その一例が、最近オープンソース化したAxonCacheです。
一方で、車輪の再発明をしないという規律も大切にしています。適している領域では、成熟したクラウドインフラや既存の基盤を積極的に活用します。こうした判断の積み重ねこそが、私たちがスリムなチーム体制で運営できている大きな理由の一つです。
私たちは、エンジニアリングとプロダクトの両面において、AIを単なる目新しい技術としてではなく、実用的な「力の増幅装置」として積極的に活用しています。
プロダクト面では、安全性の担保、プロダクトインテリジェンスの強化、そして自動化のためにAIを活用しています。エンジニアリング面では、デバッグ、ロードマップ検討、反復的な作業の効率化、さらには設計や問題解決に参加する“バーチャルエンジニア”としてもAIを使っています。
私たちはAIに大きな可能性を感じていますが、同時に冷静さも大切にしています。本当に役立つ場面では積極的に使い、注意を散らすだけの過度なブームには流されない——そのバランスを意識しています。
このブログの目的はシンプルです。
少人数で、高い信頼関係を前提としたチームで複雑なシステムを構築している人たちにとって、役立つかもしれない学びや実践を共有したいと考えています。
技術的に深く踏み込む記事もあれば、プロダクトに関する意思決定に焦点を当てたもの、あるいは組織運営におけるトレードオフを振り返る内容もあるでしょう。
いずれのストーリーも、私たちの働き方そのものである「ビルダーの視点」から語られます。