現在の製品開発はコラボレーション抜きに成立しなくなっています。しかし、エンジニアとしてコラボレーティブであるとはどういうことでしょうか? それは、コーディング中心の思考にとらわれず、役割や責任の境界を超えて考えることから始まります。ここでは、Figmaのエンジニアリングチームがどのようにしてコラボレーティブな最適解を見つけたか、業務の定義に役立つ原則とプロセスを説明します。
役割＝ルール、ではない理由を共有
Marcus Oakleyによるイラスト
私が契約社員としてFigmaに入社したのは2016年で、そのとき12人のエンジニアがいました。入社する前は、コラボレーティブでパフォーマンスの高いツールをウェブブラウザで構築できるのか、正直なところ懐疑的でした。今となっては昔のことのように感じますが、当時は、アプリとモバイルデバイスが再び重視され、盛り上がっていました。ネイティブアプリに匹敵するウェブ体験を構築しようとして失敗した試みも多数ありました。Figmaが実現できるようになるには、技術的、文化的な変化による大きな転換が必要でした。WebGLやWeb Assemblyのような下位レベルのブラウザAPIが導入されたことで、ウェブで何が可能かを再考することができました。これは、Google Docsのようなツールで育った世代によってもたらされ、さらに、ここ数年のハイブリッドワークやリモートワークによって加速しました。これにより私たちは、同期型コラボレーションの価値が十分に認識するようになったのです。
今日、私たちのツールはデフォルトでマルチプレイヤー対応していることが期待されています。そして、変化したのはツールに対する期待だけではありません。私たちがお互いにどのように関わるかということであり、またお互いに対する期待も変わっています。契約社員としてコードを書いていた初期の時期からチームのリーダーとなる現在に至るまで、私はそれがエンジニアにとって何を意味するのかについて考えてきました。製品開発がリニアではなくなるにつれ、私たちの役割はどのように変化しているのでしょうか? エンジニアとしてコラボレーションとはどのようなものであるべきでしょうか? そしてそれは常に良いことなのでしょうか?
他人の知恵を活用することと、自分自身の明確な方向性を持たずに右往左往することとは、紙一重であることがわかりました。
自分ひとりですべてやろうとするのは簡単なことですが、緊密に協力することがより強力な成果につながるのであれば、常にフィードバックを得てアップデートしない手はないでしょう。概して、他人の知恵を活用することと、自分の明確な方向性を持たずに右往左往することは紙一重であるということに私は気付きました。実際には、ひとりで自主的に取り組むべき時もあれば、他人を巻き込むべき時もあるでしょう。私は経験から、分散と集中の理想的なバランスは、それぞれの文化、作っている製品、最適化するための理由など、一人ひとり違うことを学びました。適切なバランスを見つけるために、エンジニアリングや製品開発全体における、私たち自身のコラボレーティブなスイートスポットへの考え方をお伝えしたいと思います。
もはや、製品開発はデザインから始まり、エンジニアリングで終わるという時代ではありません。しかし、多くの企業では、プロダクトマネージャーとデザイナーがロードマップを設定し、エンジニアがそのロードマップを実行する責任を負っています。これは、プロダクトチームにおける私のカウンターパートである山下祐樹と私が、正しく理解したいと思っていたことです。私たちは非常に緊密に協力し合い、それが組織の他の部門にも波及しています。エンジニアは単にどのように作るかを定義するだけでなく、部門横断的に仲間と密接に協力し、顧客からのフィードバックを聞きながら、何を作るべきかを考えるのです。
新しい仕事の流れをスタートさせる際には、私たちは常にチームに、できるだけ早い段階でさまざまな視点から意見を引き出し、製品開発チームの他のメンバーからの意見に基づいてコンセプトドキュメントを作り上げていくことを勧めています。エンジニアには早い段階で考えを書き留めることが期待されており、「改善が進んだ」と感じてからではなく、取り組んでいる最中にコラボレーション仲間からフィードバックを得ることを目標としています。事実上すべてのプロジェクトには、この初期の考えを記録するための何らかの文書があります。課題は、チームが自分たちの仕事に邁進しているときに、素早くフィードバックを得ることです。
そのため私たちは定期的に、デザイン部門とエンジニアリング部門にまたがる、エンジニアリングの「批評会」を開催し、他のチームからのフィードバックを得るための専用の時間と場所を常に確保しています。エンジニアリング批評会の役割は非常に特殊です。早い段階から頻繁にフィードバックを求める場であり、技術的なデザインについて専門家のサポートを得るためのフォーラムなのです。承認プロセスではありません。エンジニアリング批評会の集まりで何かを決めたり、何かを解決したりはしません。目標は、本当に承認を必要としないところまでデザインを引き上げる手助けをすることです。私たちはFigJamを使ってこのミーティングを運営し、全員がリアルタイムで楽しんで参加できるようにしています!
エンジニアリング批評会は、承認プロセスではなく、他のチームから早い段階で頻繁にフィードバックを得るための時間です。批評会の参加者には、WIP (進行中の)作業を受け入れ、決定に飛躍することなく、生産的に問題を指摘することを奨励しています。こちらは、Figmaで使用しているテンプレートです。
しかし、インプットが多すぎたり、相反するフィードバックがあったりすると、どうなるでしょうか? 生産的かつ探求的でありながら、物事を前進させるという適切な組み合わせがない場合に、プロジェクトが軌道から外れてしまうのを見てきました。最初の価格モデルを定義するような、難しいトレードオフがあったり、曖昧な部分が多かったりする場合は、特に難しいものです。競合する視点や新しいアイデアが多すぎると、すぐに身動きが取れなくなってしまうのです。
そのため、私たちはプロジェクトをいくつかのマイルストーンに分けています。単純に聞こえるかもしれませんが、マイルストーンを明確に定義し、それを伝えることで、他の関係者との期待関係を管理したり、進捗と勢いを考えて収束させる時期を意識したりするのに役立ちます。勢いは非常に重要なものです。勢いがあると、目標まであと数歩という気持ちになる。勢いがなくなると、空回りし始め、自分たちのしていることに疑問を抱くようになります。
Figmaでは、マイルストーンは、チーム内の収束に役立つだけでなく、チーム全体で物事が計画通りに進んでいないことに気付くこともできます。物事が危機に瀕しているときに、早い段階でコミュニケーションを取ることで、お互いに専門知識やリソースを提供し合い、勢いを立て直すことができます。このようなときこそ、より多くの意見が役に立ちます。私は、プロジェクトが失速しているのがわかると、飛び込んで行くこともあります。私の肩書きのせいで、特定の分野に深く踏み込むと驚かれることもありますが、お互いに垣根を取り払い、お互いを支えている細部から誰も離れすぎないようにすることが重要なのです。
基礎的なレベルでは、私は Figmaでの仕事を依存関係の木と考えたいと思っています。葉は、木の他の部分にほとんど危険を及ぼすことなく、急速に変化することができますが、根はしっかりとしている必要があります。根のレベルでプロジェクトを計画しているとき、考慮すべきことは、葉のレベルのものとはまったく異なります。データベースを構築しているのであれば、自分だけで「速く動いて物事を壊す」ようなことはしたくないはずです。技術スタックの上位にあるものに比べて、下位レベルのシステムで作業しているときは、インプットが正しいか十分に考える必要があります。インターフェースは変えるが、基礎となるデータモデルには手を触れないというような機能で作業しているなら、自分だけで実験したほうがリスクが低いことが多いのですが、それでもユーザーのためには「物事を壊す」べきではありません。私の役割の大部分は、根であるルートノードから葉のノードを分離し、主要な関係者からのフィードバックを得ながら、チームにとって迅速に進められることは何か、より原則的なアプローチを必要としているものは何かを明確にすることです。
製品の変更もルートノードである場合が多いです。たとえば、自動レイアウトのような新しいデザインプリミティブを検討しているとき、本当に万全を期して新しいプロパティを公開する必要があります。後から変更すると、既存のワークフローやデザインが壊れてしまう可能性があるからです。そのため、重要なローンチや技術的機能の多くは、単一のフレームワーク、言語、抽象化の境界を超えて、根から枝、葉に至るまで考える必要がありました。
重要なローンチや技術的機能の多くは、単一のフレームワーク、言語、抽象化の境界を超えて、根から枝、葉に至るまで考える必要がありました。
これは、フロントエンドの経験があり、システムプログラミングやインフラストラクチャの仕事は初めてというような、ひとつの分野のみを専門としているエンジニアにとっては変化かもしれません。重要なのは、私たちは皆、素早く学ぶという能力を過小評価しているということです。そのため私たちは、エンジニアが葉と根の両方を担当できるよう意図的にチームを編成し、技術スタックの上下を問わず仕事ができる体制を整えています。一緒に働くことで、互いの専門知識に頼り合い、課題を回避するのではなく、課題に正面から立ち向かうことができるのです。優秀な製作者は、ある分野に深く特化しているだけではありません。挑戦をいとわず、積極的に新しいシステムを素早く学びます。彼らはどこにいようと問題を追い求め、自分の役割に縛られることはありません。このような働き方が、プロダクトデザインをウェブに持ち込む勇気を私たちに与えてくれたのです。
優秀な製作者は、ある分野に深く特化しているだけではありません。挑戦をいとわず、積極的に新しいシステムを素早く学びます。
高成長を遂げているさまざまな企業で、多様な原則やフレームワーク、プロセスを見てきましたが、「正しい」やり方はひとつではないということを知りました。実際、大きく成功している企業は、こうした決定にもかかわらず成功していることが多いのです。変化し続けるエンジニアリングとコラボレーションの展望を共に切り開くとき、過去の経験によって、新しい問題の微妙な違いを解決するチームの能力が制限されることがあってはなりません。同様に、自分たちの役割や肩書きに縋りつきたいという衝動にも抵抗しなければなりません。役割やプロセスなどの定型的な定義にとらわれがちですが、第一原理から考え、エゴを捨てて、過去に経験した制約を超えていく、という姿勢が実践では求められるのです。