はじめに

こんにちは、Autifyエンジニアリング部署でプロダクト開発をしている武藤です。この記事では、2025年現在におけるAutifyのエンジニアリングカルチャーはどのようなものか、またどのような変遷を経て、どういう問題意識を持って現在の形に辿り着いたのかということを、わたし自身の所感もまじえてご紹介したいと思います。なお、わたし自身は現場の一エンジニアであり、エンジニアリングカルチャーの変革を主導した立場ではありません。記事作成にあたっては、変革のキーパーソンの１人であるVPoEのトマ・サントンジャ氏に背景を取材しました。

Autify黎明期

あらゆるテックスタートアップと同じように、Autifyもたった数人のエンジニアのあつまりとしてはじまりました。ここからしばらく、エンジニアたちは目の前のバーニングニーズを満たすために、とにかくがむしゃらに機能を実装していきます。しばらくはAutify NoCode Webという一つのプロダクトしかなく、エンジニアリングチームもひとつのみです。

わたし自身は、Autify2番目のプロダクト、2つ目のチームとしてNoCode Mobileが立ち上がると、二人目のエンジニアとしてそちらのチームに移動しました。NoCode Mobileには最初期から今にいたるまでずっと関わっていますが、わたしが関わりはじめたときには、基本的な形はすでに一人目のエンジニアによってほぼ単独で開発され、ほとんどの部分ができあがっていました。

プロセスとして、2週間のスプリントがありましたが、チームとしてひとつの目標に取り組むというよりは、どちらかというと各エンジニアがプロダクトのうちの一部分をエキスパートとして担当していました。技術的な意思決定についても、各人の裁量で提案用のドキュメントを書いて、非同期で共有するというのが主で、同期的な会議の場はまれでした。ローンチから3年以上、Autifyでは、このようにどちらかというとボトムアップによる試行錯誤でエンジニアリングカルチャーを醸成してきました。

3年経ったとき、そこにあった問題

立ち上げから数年経ち、エンジニアの数も増えてきたAutifyにおいて、日々の開発で、新しい機能やバグフィックスが定期的にユーザーに届けられてはいました。エンジニアの数は20人程度といったところです。一方、問題もありました。サイロ化の兆候がすでに起きはじめていたのです。

どういう意図で設計され、どういう仕組みで動いているのか、誰も知らない

わたしが実際にAutifyで体験したことをすこしお話します。どのような組織においてであれ、人が去っていくことはたぶん避けられません。あるとき、NoCode Mobileの基盤刷新を主導してくれたバックエンドエンジニアがAutifyを去りました。それ自体はしかたのないことです。もちろん引き継ぎは行われ、ドキュメントもけっこう書いてくれていたので、残ったエンジニアで引き続きシステムを運用していきました。

そして数年後。あるとき、一見してまったく使われていなさそうなAWS Lambda関数があったため削除したところ、システムが部分的に動作しなくなっていることに気付き、あわてて元に戻しました。そのLambda関数が導入された意図や仕組みを知っている人はもはや誰もなかったため、消してみてはじめて、それが必要なコンポーネントであったことを開発チームは理解しました。運の悪いことに、その部分についてはドキュメントでも言及されていませんでした。もちろん、すべてはコードなので解析すれば理解することは可能ですが、動いているシステムの中に、だれも把握していない部分があるというのは、恐ろしいものです。

いまから思うと、当時の基盤刷新は非常に急ピッチで行われ、ある程度の期間で達成されはしました。しかし、かわりに、情報の共有や設計のレビューといったことはだいぶおざなりになっており、１人か２人のエンジニアの独断でどんどん進められたという面があります。

期待と実際のミスマッチ

また、エンジニアリング部署として、ステークホルダーからの期待に応えきれていない部分もありました。約束した機能についてしばしば遅延が発生し、機能をリリースしたにも関わらず、実際に期待されていた要求を満たしていないということもありました。たとえば、ある内部的な設計変更については、期待された時期から2四半期以上遅れてデリバリーされたにも関わらず、完全には機能していない状況でした。

エンジニアリングカルチャーの再構築

現VPoEのトマはAutifyに入社して、まずすべてのステークホルダーに時間をかけてヒアリングを行い、問題の洗い出しに着手しました。わたしもトマと面談し、上記の話のような、自分が現場のエンジニアとして問題と思っていることを共有しました。そうして見えてきた問題にたいして、スクラムの実装を軸として、トップダウンでの改革がいくつか行われました。ここからは、こうした変化を経て現在Autifyに根付いているエンジニアリングカルチャーについてご紹介します。

見積・スプリント・デモ

わたしがもっとも大きいと思う変革は、エンジニアリングのプロセスがチーム横断で定義され、それに沿って開発が進められるようになったことです。詳細部分の実装は個々のチームにゆだねられますが、フレームワークはエンジアリング部署全体で共通のものを使っています。

機能の実現にあたっては、まずフィーチャーと呼ばれる大きな単位で定義・議論されます(フィーチャーリファインメント)。次に、フィーチャーはユーザーストーリーの集合に分割され、チケット化されます。チケットに着手する前にはチームとしての見積(チケットリファインメント)が必須であり、見積られたユーザーストーリーは、順次、スプリント計画に配置されます。そして、スプリントを通じてユーザーに届けられた価値は、仕上げとして、ステークホルダーを集めたデモミーティングを通じて披露されます。これがAutifyにおける、基本的な価値創出のパイプラインです。

重要なポイントは、各フィーチャーとユーザーストーリーについて、プロダクトマネージャーやエンジニアリングマネージャー含むチームの全メンバーをまじえた議論が発生するということです。これは作業に着手する前に必ず行われます。場合によっては、デザイナー、サポートといったステークホルダーも参加します。この過程で、計画に含まれる不確実性をなるべく洗い出し、必要な詳細や見落していた点を付け足したり修正していきます。見積は、計画のために必要なことですが、開発者間での見落としや認識の齟齬の発見にも役立ちます。ある開発者は2ポイントで終わると思ったストーリーが、他の開発者には5ポイントに見えていた、といったことはよくあることだからです。その場合、それぞれの開発者がどのような観点に基いて見積を行ったのか話し合うことで、チームがより良く同期し、不確実性を減らすことができます。また、スプリントごとに必ずひとつゴールを定め、そのデモを目標として、何としてもそれを達成すべくチームが一丸となるという動きかたに変わったため、個々人が都度割り当てられたタスクをなんとなくこなしていた以前とくらべて、チームとしての結束が強まったように感じます。

このように、基本的にすべての機能は何らかの議論や合意を経て実装に至るため、設計上の重要な意思決定が知らないうちに行われることは、すくなくとも同一チーム内においては、発生しなくなりました。この新しいプロセスにより、マイルストーンに向けたスプリント毎の目標が確実に達成されるようにチームとして動き、それがスケジュールの遅延に対する抑止力として機能します。

余談ですが、Autifyエンジニアの報酬には、プロダクトの売上だけではく、エンジニアリングチームとして、どれだけ上手に(遅滞なく高品質に)価値を顧客に届けられたかという観点も反映されるようになっています。これは、プロダクトの売上はエンジニアが直接制御できる因子ではないため、エンジニアにも公平な評価をするという配慮から来ています。

Architecture Decision Records

また、Autifyで推奨されている別の取り組みとして、Architecture Decision Records(ADR)というものもあります。これは、設計上の重要な決定について、広くフィードバックを得るためのフレームワークで、解決したい問題や背景が説明され、それに対するいくつかの解決策とその長所・短所が並べられます。このプロセスを経なければ機能を実装できないと定められているものではないですが、重要な意思決定についてはADRを作成し、広く意見を募ることが推奨されています。Autifyにはアーキテクチャ委員会というものが存在し、ADRを作成してレビューを依頼すると、スタッフエンジニアを含む経験豊富なエンジニアが、いろいろな観点から設計をレビューしてくれます。また、ADRは全社でひとつのだれでもアクセスできるデータベースに蓄積されています。そのため、アーキテクチャ委員会に限らず、すべてのAutifyエンジニアに対して、もし興味があれば、他チームのADRをレビューして、自身の持つ専門性を元にフィードバックすることが推奨されています。自分自身のチームのスプリントに手一杯であることが多く、なかなか他チームのことにまで目を配るのは難しいのですが、他チームのADRで行われている技術的な議論を目にするのは非常に興味深く、勉強にもなります。

Value Proposition

エンジニアリングカルチャーの再構築にともなって、Autifyでよく使われるようになった言葉として、Value propositionというものがあります。これは、つまるところ、行おうとしているエンジニアリングが、ビジネスに対してどのくらいインパクトを与え得るかということです。リファクタリングなどを含む、およそすべての提案や議論が、最終的にはValue propositionに照らして判断されます。このため、なにをするにも、そのアクションによってどういうインパクトがあるのかを、できるだけ具体的な数値も合わせて考えることが要求されます。この考えかたは、導入された当初なかなか窮屈に感じ戸惑いましたが、いまではどう扱うか、みんなだいぶ慣れてきたように思います。また、リファインメントの過程で、議論の遡上にある要求がどのようなどのような価値を持つのか、エンジニア側からビジネスサイドに対して、Value propositionにもとづいた説明を求めることもできます。

このValue propositionというコンセプトが、限られたエンジニアリングリソースをいかに有効に使うかという優先度振り分けを適切に行うための土台になります。

現在のプロセス

最後に、これまで説明したプロセスが、開発全体の中でどのような位置付けにあるのかをご紹介して記事を終わりたいと思います。以下の図は、実際にAutifyのプロセス全体像を説明するために内部で公開されているものです。

Stepは機能が立案されてから完了するまでのプロセス、Artifactsは各ステップの結果として生じる成果物、RACI(Responsible, Accountable, Consulted, Informed)は、各ステップにどの立場の人がどう関わるかを表しています。黄緑色と青の部分が、エンジニアが関わるステップです。必ずしもすべてのステップが常に行われるわけではなく、どうプロセスをどう運用するかはチームの裁量に委ねられている部分がありますが、おおむね全社的にこのような流れになっています。ADRのための技術的な議論は、必要に応じて、フィーチャーリファインメントからチケットリファインメントの間に行われます。そして、Value propositionは、アイデアの起草からチケットリファインメントまで、エンジニアに限らず、プロセス全体を通じて普遍的に利用されるAutifyのプロダクト開発に通底する概念として機能します。

まとめ

• ボトムアップによる未定義のプロセスが次第にサイロ化を招いた
• また戦略的な機能提供について遅延が常態化していた
• これらの問題に対処するためにトップダウンでフレームワークを定義・導入し、サイロ化が改善された

タイムライン

• 2019年3月: Autify NoCode Webクローズドベータローンチ
• 2019年9月: Autify NoCode Webオフィシャルローンチ
• 2021年1月: Autify NoCode Mobileベータアナウンス
• 2021年10月: Autify NoCode Mobileオフィシャルローンチ
• 2022年9月: トマ・サントンジャ、VPoEに就任
• 2022年11月: NoCode Mobile スプリント1
• 2022年11月: 最初のADR作成

リンク

• Autifyが築くグローバル企業としての日本の新しい会社の姿 - TokyoDevによるトマへのインタビュー

‍