DuolingoのMathチームは、共同制作、スクラッププロトタイプ、そして絶え間ない実験を重視する従来のハンドオフを廃止しました。
Duolingoの方法: コラボレーションが業務進行の中核 を共有
Jon Hanによるイラスト
ハンドオフについては、デザインからエンジニアリングへのきれいなバトンタッチが行われると信じられていますが、実際には製品開発はそれほど直線的に進むものではありません。特に、Duolingo Mathチームのようなスピーディーで探究的な環境では、これが当てはまります。このチームは、より大きな会社の中でスタートアップのように運営されています。このチームは、世界で最も認知されているエデュケーションアプリの1つとして数学学習のあり方を定義する任務を負っています。そのため、反復的でコラボラティブなアプローチを採用し、デザインとエンジニアリングを密接に関連させ、最初のスケッチから最後のビルドまでリアルタイムで試行錯誤を重ねることができます。
チームの基本原則に関するシリーズの第4弾として、私たちはDuolingoのMathチームのプロダクトデザイナーのColleen MacDonaldとソフトウェアエンジニアのSammi Siegelにインタビューしました。共創、定期的なコミュニケーション、継続的な実験によって定義される、柔軟性の高いプロトタイプ駆動のプロセスを通じて、DuolingoのMathチームがどのように構築を進めているかを紹介します。
一緒にアイデアを出す
DuolingoのMathチームは、ゼロから新しい学習モジュールとゲームを構築しているため、従うべき設計図はありません。これらのレッスンとゲームは、数学スキルの流暢さ、速さ、記憶の正確性を向上させるために設計されており、インタラクションが多く、適正なものにするには多くの調整と反復が必要です。「他のチームは類似の機能のテンプレートを使用できますが、私たちはまだそこまでには至っていません」とSammiは言います。「私たちはまだまったく新しいものを数多く作っている段階なので、プロセスは少し違い、少し大規模なものになります。」
デザイナーが製品開発プロセスを単独で開始するのではなく、Mathチームのメンバー (デザイナー、エンジニア、プロダクトマネージャーなど) が、共有されたFigJamファイルで一緒にアイデアを出し合ってプロジェクトを開始します。チーム全体が明確な方向性に到達した後、デザイナーはFigmaでプロダクトのモックアップを作成し、モーションなどの特定の要素がどのように実現するかを計画します。
DuolingoのエンジニアはJiraを直接Figmaに接続 しているため、デザインをコードに実装する際のコンテキスト切り替えが少なくなり、作業の速度を維持できます。
Duolingoのエンジニアは、このプロセスのこの部分に積極的に参加しており、構築する前にFigmaで複雑なインタラクションや動きを評価し、実装が難しいと思われる点をコメントで指摘することができます。
迅速なプロトタイプによる実験
デザインモックアップの調整ができたら、エンジニアはDuolingoのデザインシステムからのコンポーネントを活用して、最初のプロトタイプを作成し始めます。デザイナーとエンジニアは、共同で作業用プロトタイプを完成させると、それをチームミーティングに持ち込んでテストし、広範なグループから意見を求めます。グループのSlackチャンネルでは、デザイナーがFigmaファイルを共有し、エンジニアがプロトタイプを共有し、両チームがフィードバックや質問を交換します。
チームはこのプロセスを各製品機能ごとに、最終バージョンに到るまで繰り返します。この迅速なループ (プロトタイプ、テスト、調整) は、チームによる構築の中核となります。「かなり多くのやり取りがあります」とSammiは言います。「『デザインがこれを引き渡し、エンジニアリングが先へ進める』というわかりやすい話ではありません。もっと複雑な連携があります。」
「デザインがこれを引き渡し、エンジニアリングが先へ進める」というわかりやすい話ではありません。もっと複雑な連携があります。
チームは「語るより見せる」というDuolingoの原則に基づいています。—アイデアについて話すことは、それを作ることほど効果的ではないという考え方です。
このプロトタイプファーストのアプローチは、新製品を明確なものにします。これらのプロトタイプを使用して仮定をテストし、製品が実際にどのように感じられるかに基づいて意思決定を行います。これをDuolingoハンドブックでは「語るより見せる」と呼んでいます。その目的は、構築する前にデザインを完璧にすることではなく、迅速に進めて一緒にやり方を見つけることです。「迅速な反復を数多く行います」とColleenは言います。「重要な意思決定のため、実体験が必要になることも多くあります。」
改善とリリースを一緒に
この継続的なコラボレーションにより、チームは迅速な意思決定を行い、進行中の改善を行うことができます。また、迅速な作成のために、アニメーションの簡素化など、機能を基礎的なものにまで絞り込むこともあります。
そのスピードは、チームが初めて教育ゲームの市場に見合った製品を見つける任務を与えられたとき、特に重要でした。2つの高度なゲームを構築する代わりに、彼らは最小限のデザインで追加のメカニクスを持たない簡単なゲームの最初のバッチから始める方が、ユーザーの共感を得られる方法を確認するのに適していると判断しました。彼らはこの方式を迅速に立ち上げ、どの機能を優先するかを事前に決定しました。7つの異なるプロトタイプで反復をした後、デザインとエンジニアリングの間の緊密なフィードバックに基づいて、成功したものに集中し、最も高度なアイデアを4つ選んでリリースしました。ゲームは簡素化されていましたが、それでも品質、楽しさ、直感的であることの基準を満たすことができました。「機能の範囲については妥協することはできますが、仕上げや楽しさなどの要素については絶対に妥協しません」とColleenは言います。
共有言語と信念の採用
このスピードで製品を設計し発売するためには、チームが製品のリリース時期について同じ認識を持っている必要があります。Duolingoでは、プロダクトビルダーは「v1 vs. MVP」という哲学に従います。これは、ある機能の最初のリリースが最終形ではなく、継続的な反復を通じて洗練させるための出発点であるという考えです。最初から完璧を目指すのではなく、着実な基礎形をリリースし、それを時間をかけて改善することに焦点を当てています。「後でやりたい反復があるが、それが今の時点では範囲外だということもよくあります」とSammiは言います。
Duolingo Mathチームは、「v1.」をリリースする前に満たすべき条件について合意しています。まず、その機能に関して最低限の洗練度を達成することを目指しています。そのために、レビュー過程には初日から多めの時間を設けています。「私たちがリリースするもののすべてで、その水準の洗練度が期待されています。新機能を試すときにはそれが目標となります」とColleenは言います。
デザインとエンジニアチーム間でインセンティブを揃え、「完了」の共通認識について合意することは、難しい作業になることがあります。当社のデザインリーダーに向けたハンドオフガイドでは、その方法を詳しく解説します。
また、各製品がDuolingoスイート内でシームレスに適合するようになります。これにより、デザイナーとエンジニアはデザインシステムのコンポーネントを使用して各機能を構築し、まとまりをもたせ、広範な経験を可能にします。「私たちのコースは、よく知られているすべての言語コースとあわせて開設されています。そのため、アプリのデザイン言語を共有し、エンジニアリングコンポーネントを共有することが重要です」とColleenは言います。
私たちのコースは、よく知られているすべての言語コースとあわせて解説されています。そのため、アプリのデザイン言語を共有することが重要です。
最後に、彼らはDuolingoが「信頼のバッテリー」と呼ぶ概念を実現しました。これは、信頼が意味のある貢献を通して得られるという考え方です。積み上げられてきた信頼にその貢献が上乗せされ、コラボレーションが次第に強化されていきます。Duolingo Mathチームはオープンなコミュニケーション、所有権の共有、透明性を通じて、相互の尊敬と信頼性の強固な基盤を築いてきました。最終的には、この信頼があってこそ、速やかに動き、共に決定を下し、自信を持ってリリースできるようになるのです。
Duolingoの方法について詳しくはこちら。次回の連載では、チームが製品を作り上げる方法と、その作業の基準となる原則やプロセスを紹介します。
