数週間前、私たちEPDチーム（エンジニアリング、プロダクト、デザイン）は、新しいタイプのスプリントをテストすることにしました：ディテールウィーク」です。社内ではこう呼ばれています：ディテール＆スライブ」です！
このスプリントは、Gather の体験の細部に完全に焦点を当てたものでした。そして、たった2週間で116ものバグフィックスと改善をプラットフォームに押し付けたのです。マジで拍手喝采です！👏
このスプリントの苦労を称え、Gather のコミュニティ責任者であるリズ・ジョージが、チームの3人のメンバーと一緒に舞台裏を紹介しました。
ライブストリームの録画はこちらで、書き起こしは以下でご覧ください。
リズ：みなさん、こんにちは。Gather のコミュニティ責任者のリズ・ジョージ です。それでは、チームの皆さんに自己紹介をお願いします。
ジャスティン： 皆さんこんにちは。私はジャスティン・キーで、Gather でプロダクトマネージャーをしています。プロダクトマネージャーとしての私の仕事は、一言で言えば、私たちが作る製品のビジョン、戦略、機能要件を設定することです。そして、設計やエンジニアリング、その他社内外のステークホルダーと協力し、製品を市場に送り出すことです。
ジョシュ： みなさん、こんにちは、私はジョシュです。バンクーバーを拠点に、コアアプリチームのエンジニアリングマネージャーを務めています。Justinが言ったように、私たちはプロダクトやデザインと密接に連携して、ユーザー向けの機能を構築しています。
(⋈◍＞◡＜◍)◍ラウです： そして私はラウです。Gather でデザインチームを率いています。私たちの課題は、インタラクションデザインからビジュアル、ブランドまで、あらゆる分野に及んでいます。また、エンジニアリングやプロダクトと協力し、ユーザー中心の方法でこれらの問題を定義しています。
リズ：素晴らしい！リモートワークの精神に則って、みんながお互いの場所を共有できたらいいと思うんです。私はサンフランシスコのベイエリアにいます。
(￢_￢)ラウです： 普段はカナダのトロントで仕事をしていますが、今はアイルランドのダブリンにいます。
╱Josh:さっきも言ったように、普段はバンクーバーにいるんだけど、今はサンフランシスコにいるんだ。
ジャスティン：私はシアトルを拠点にしています。
リズ：では、さっそく 始めましょう。新しいユーザーのために、Gather が何なのか、また、製品チームが今何を重視して いるのかを教えてください。
ジャスティン: Gather では、分散しているチームや遠隔地にいるチーム がデジタルスペースを構築することで、みんなが集まり、 バーチャルな交流がより人間らしく感じられるよう にすることをサポートしています。私たちのお客様がバーチャルスペース（バーチャルオフィス）を利用するとき、会議でのコラボレーション、コワーキング、誰かのバーチャルデスクに立ち寄るなど、チームとのつながりは、チームメンバーがどこにいても、生産的な仕事、共同作業、企業文化を実現できる、より活気ある体験となります。
例えば、画面録画や、より詳細なカレンダーとの連携など、ユーザーがGather でミーティングを予約したり、ミーティングに参加しやすくするための機能など、ミーティング体験の強化です。デスクトップ・アプリケーションの改良に加え、来年には、まったく新しいGather モバイル・アプリケーションをリリースする予定です！
ラオです： そうですね、Justinが概説してくれたことは間違いなくすべてです。私は、このデザインに焦点を当てたいと考えています。Gatherプラットフォーム自体のデザイン上の課題は本当に興味深いもので、世の中にあるものとは全く違うものだと思います。
私たちは、人々が互いに交流するプラットフォームについて話していますが、それだけでなく、それに付随する世界も存在するのです。その中で、人々がどのように働いているのかに焦点を当てようとしています。
この製品で働く魅力は、既存の製品にあるものを利用しながら、常に新しいインタラクションパターンを考案していることです。ミーティング・プラットフォームにはUIパターンが存在しますが、私たちはそれを、人々が互いにつながる方法として非常に新しいこの世界に適応させているのです。
ですから、リモートワークに焦点を当て、世界のどこにいても、あるいは時間帯に関係なく、人々が互いに簡単につながれるようにすることは、私たちにとって本当に素晴らしい挑戦なのです。
ジョシュ： ジャスティンとラウが完璧にカバーしてくれたと思います。私が言いたいことをすべて言ってくれました。
リズ：では、次の質問 です！さて、今日はチームが行った新しいことについてお話しします：ディテールウィークについてです。その内容や、通常のプロダクトやエンジニアリングのスプリントとどう違うのか、共有したいですか？
ジョシュ： ジャスティン、君がスタートを切って、僕がエンジニアリングの視点を加えたいんだけど？
ジャスティン： はい、 私からキックオフします。Gather では、お客様に新しい製品や機能をお届けするために、非常に速いスピードで動いています。いつでも、いくつものプロジェクトがあり、その数は数え切れないほどです。
新機能を構築し、ローンチし、反復するうちに、必然的にカスタマーエクスペリエンスにバグが発生します。また、必要な機能の改善や変更、お客様の声を取り入れることもあります。
そこで、Details and Thriveスプリントでは、チーム全体が細部を正しく理解することに集中するための時間を確保しました。バグを修正し、小さな機能追加要求を取り入れ、チーム全体で集中的な作業に優先順位をつけ、より幅広い機能バックログに取り組むための時間を確保しました。
ジョシュ:さらに付け加えると、エンジニアリングの観点から、多くの企業では常に「いかに迅速に動くか」と「いかに本当に出したいものを作るか」のバランスを取ろうとしています。そして、"本当に出したいものをどうやって作るか？"と "本当に高品質であることをどうやって確認するか？"のバランスを常に考えています。
そして、どちらか一方に偏りすぎてしまうことがあります。なぜなら、ユーザーのために作りたいものがたくさんあり、それが素晴らしいものであることを本当に確認したいからです。しかし、完璧にしようと一つのことに時間をかけすぎて、他のことに手が回らなくなってしまうことがあります。
しかし、その逆もあり得るのです。ワクワクするようなことを作り出そうとするあまり、細部にまで目が行き届かなくなってしまうのです。
そのため、細部のために明確な時間を確保することができたと思います。また、私たちはそれを非常に意識的に行ったと思います。
そのため、自分たちが何をしたいのか、それをするための時間を確保することを意識することができました。
(￢_￢)ラオです： Gather 自体が非常に若いということも、非常に重要だと思います。先ほど、新しいインタラクションのパターンについてお話しました。私たちが最初に始めたときは、実験として始めたのです。これは定着するだろうか？このまま進めていっていい機能なのか？例えば、MVPを受賞した後、どのように進化させるのか？
そして、1年が経ち、「よし、調整しなければならないことは何だろう」と振り返る中で、私たちは初期の頃の実験から多くのことを学びました。そして、そこから多くを学んだだけでなく、他のプラットフォームで実世界を見たのです。
私たちがこの分野で大きな反響を呼んだため、他の多くのプラットフォームも私たちのパターンを取り入れ、それを模倣し、世に送り出しています。
ですから、私たち自身のデザイン・エンジニアリングの負債だけでなく、私たちが実験しているだけのものを置いてくれている他のプラットフォームにも負債を負っているようなものでした。
ですから、今回、振り返ってみて、私たちのプラットフォームや人々が互いにつながる方法にどのような影響があったのか、また、人々がGather 、実際に必要なことを簡単で楽しい方法で行えるようにするにはどうすればよいのかを確認できたことは、私たちにとって本当によかったと思います。
リズ：教えてくださってありがとう ございます。これは、今までの様々なアプローチとは本当に違うものなのでしょうか？
╱Lau：ジョシュとジャスティンが言ったように、私たちは非常に速く動くことができます。ジョシュやジャスティンが言ったように、私たちは非常に速く行動します。それは、私たちが本当に速く多くのことを学ぶことができるので、素晴らしいことですが、その過程で多くの失敗もします。
だから、振り返ってみて、"そうか、もう少し違うやり方があったかもしれない "と思えるのです。この学びを次のチャレンジにつなげることができるのです。ですから、私たちは、エンジニアリングとプロダクトで互いに協力し合う方法だけでなく、私たち全員が互いにつながる方法において、非常に複雑な空間の中で働く方法も常に学んでいます。
リズ：お三方の役割は極めて異なって います。スプリントにおけるあなたの役割を説明してもらえますか？
ジャスティン: 何よりもまず、チームワークが大切です。具体的には、ジョシュとラウ、そして彼らのチームと協力して、スプリント中に取り組みたいバグや機能改善のリストを整理し、優先順位を付けました。そして、すべてを構築し、意図したとおりに動作させるために、それぞれに私の意見を述べました。
ジョシュ: ジャスティンが言ったように、それは間違いなく共同作業でした。私はエンジニアリング・マネージャーとして、チームが適切なツールを持ち、サポートされていると感じられるようにしたかったのだと思います。
前述したように、やり遂げたいことは山ほどありました。素晴らしいブログ記事もありました：116のバグ、詳細、そして私たちが行った改善。
それ以上のチケットもあったんですよ。乗り切りたいことが山ほどあったんです。だから、チームがサポートされていると感じられるように、また、それらのことを解決する方法を理解できるようにすることが大切でした。
㊨ ラウです： ジャスティンやジョシュと非常に似ていますが、私たちは毎日一緒に仕事をしていました。ユーザーからのフィードバックや社内チームからのフィードバックなど、私たちが収集したすべてのタスクを、私たちのチームが簡単に手に取り、意味を理解し、設計やエンジニアリングができるように、毎日数時間、お互いに顔を合わせて、きちんと見て、分類していました。これが、私たちが行った共同作業だったわけです。
そして、デザインの観点から、私の役割は、デザインチームがそのチケットに基づいて意思決定する権限を与えられていると感じられるようにすることでした。彼らは十分な情報を得た上で、既存のフォーマットの改良を行い、さらに全体的なデザインに仕上げることができるのです。
私たちが受け取ったフィードバックや、これらのチケットに添付されたタスクは、プラットフォームのあらゆる種類の異なる部分からのものでした。ビデオや設定など、あらゆるものがあちこちに散らばっていたのです。そのため、私たちのチームが持つビジュアルUI、インタラクションパターン、デザインの原則を、全チームに徹底させ、すべてが同じプラットフォームの一部であるかのように見せることが必要でした。
╱ リズ：今 、それが何であるかという話をしました。このような細部に、チーム全体を丸2週間も割くことになったのはなぜでしょう？
Justin: このような仕事は、先ほどのような大規模で戦略的なプロジェクトに優先順位をつける際に、バックログに入れられることが多いのです。バグや機能の改善など、ひとつひとつは小さなことです。しかし、それが積み重なると、Gather の機能に対するお客さまのイメージに影響を与えるようになります。
細部にまでこだわることで、Gather 、お客様のニーズと期待に応えられるような、洗練された体験ができるのです。
┣ ラウです： デザインは基本的に、私たちのプラットフォームを改善する方法を常に探しています。ある時期を待って、どうすればもっと良くなるかを考えるのではありません。私たちは常に物事を見て、「うーん、これはあまりよくなさそうだ」と思っています。そのため、自分たちの週の中で時間を決めて、厄介な小さな問題に確実に対処するようにしています。
しかし、DETAILS WEEKのおかげで、そこに焦点を当て、最優先で取り組むことができるようになったのです。他のデザイナーがそうであるように、私たちも自分のプラットフォームに悩まされることがあります。見れば見るほど、不完全な部分が増えていく。だから、やりたいことが無限に出てくるんです。
ジョシュ： そうですね、それに加えて付け加えたいのは、私たち全員が同じようなマインドセットを持っていたということですね。みんな同じ時期に取り組んでいたんです。
通常、私たちは多くのプロジェクトを並行して進めており、大きなバケットでさまざまな問題を考えています。DetailsとThriveは、私たち全員が、小さなディテールを克服し、製品全体を改善するという考え方で、同じページに立つことを助けてくれました。これは本当に役に立ちましたし、一度に全部が揃うというのはとても良いことだと思います。
╱ リズ：そこで、私たちは問題を特定 しました：これらの多くは、バックログにありました。私たちは常に画面を見つめていて、バグが飛び出してくるのを目にしているので、物事を完璧にしたいのです。どれに焦点を当てるかは、どうやって決めたのですか？
ジャスティン：まずプロセスから考えると、何ヶ月もかけて集めたバグや機能に関するフィードバック、お客様の要望などのバックログがすでにありました。
このDetails and Thriveスプリントを実施することが決まったら、社内の幅広い組織（Gather ）にも働きかけ、チームからのインプットやフィードバック、機能の要望を募りました。最終的に300以上の新しい要望や機能が集まり、チケットとして整理されました。これらのチケットは、このグループ（プロダクト、デザイン、エンジニアリング）で1つずつ検討し、作業の優先順位をつけました。
そして、ラウと私は、必要な部分にプロダクトとデザインの定義を加え、実際に作りたいもの、その見た目や感触を定義するのに役立てました。そして、チームを結集させたのです。
ジョシュはそのチケットをすべて受け取り、自分のチームと協力して、さまざまなエンジニアに割り当てました。ラウは彼女のデザインチームと同じことをしました。そして、2週間ほどかけて、これらの改善をGather のカスタマーエクスペリエンスに反映させるために協力したのです。
╱ リズ：すごいですね！レビューや開発プロセスはどのようなものだったのでしょうか？
ジョシュ： 基本的には、他の機能と同じようなプロセスを踏んでいます。私たちは通常、やりたいことのアイデアを持っています。ジャスティンが言ったように、私たちはそうしたインサイトをすべて集めているので、何に焦点を当てるべきかはよく分かっています。
そして、作業に取り掛かるとレビューを行います。QAを行い、デザインレビューを行い、コードレビューを行い、コードの品質が良好であること、さらに問題を持ち込まないことを確認します。さらに追加していく中で、品質が向上していることを確認したいのです。
そして、良いものができたら、コードでレビューし、承認してマージされ、通常は完成してから1週間以内に本番を迎えます。
リズ：少し話は変わりますが、チームが修正したバグで一番気に入ったものは何ですか？
ジョシュ：私としては、自分のアバターがフォローされないようにする方法が欲しいという要望がずっとありました。これはいろいろな場面で出てきますね：例えば、デモをやっていて、誰かがちょっと席を外すと、その人が気まずそうにあなたのアバターを追いかけてきて、あなたは席を立つか、参加するか、しなければならない...。
だから、それを追加したのですが、表面的に見えるよりもずっと多くの努力が必要であることがわかりました。このような時間を確保することができなければ、このようなことはできなかったでしょう。それにね、かなりインパクトのあるものだと思うんですよ。私にとっても便利な機能なので、この特別な機能には本当に興奮しました。
(￢_￢)ラオウ：次は私が行きます。バグというより、最終的にやった機能なんですけどね。ゲストエクスペリエンスに関するすべてのこと、そして私のお気に入りの部分は「ゲスト」タグです。リモートワークで、自分のオフィスにはいない新しい人が来たとき、その人の名前と参加者リストに「ゲスト」タグを追加して、その人がチームメンバーでないことがわかるようにしました。
そして、いくつかの理由から、私はこれがとても好きなのだと思います。1つは、実際のオフィスでの経験を考えてみると、あなたは同僚を見ることでその人のことを知ることができます。そして、新しい人を見ると、その人の顔を見たことがないので、自動的に「認識」します。
でも、ここGather では、私たちはアバターの後ろに隠れているようなものです。もしかしたら、ハロウィンの頃にアバターをお化けに変えるかもしれません（去年のハロウィンはGather でコウモリになっていたような気がします）。そして、時々、自分の名前がないときは、「バットマン」とかにして、誰も私だとわからないようにすることもあります。
もし、私がゲストで「バットマン」という名前だったら、「ああ、これはラウだ」と思うかもしれませんが、そうではなく、実はゲストなのです。このように、直接タグを付けることで、オフィスマネージャーや面接をする人、特定の人を探している人が、「よし、この人はゲストだ」とすぐに分かるようになります。
カンファレンスに行くと「Hello my name is...」というタグがあり、その時点で誰が誰なのかがはっきりしているようなものだと思っているんです。
リズ： 「ゲスト」タグはとても役に立ちますね。そこで、「社外の人と話しているのだから、時間に余裕を持たせなければ」と思いました。そして、「ゲスト」というタグを見ることで、それを尊重することができるようになりました。このような非言語的なキューをとても楽しんでいます。
ジャスティン：みなさんがおっしゃることすべてに、大きなプラス1があります。Gather のユーザーとして、チャットとエモートのエクスペリエンスに加えられたいくつかの段階的な改良にとても感謝しています。これらの改善により、Gather で同僚とコミュニケーションをとるのがより簡単になりました。このようなことは、比較的小さなことであっても、私たちがよりつながりを感じられるようにするために大いに役立っています。
リズ：同じようなタイプのDetail Sprintに興味がある他のチームにアドバイスを お願いします。
ジョシュ：以前にも触れたと思うのですが、時間を作ることは本当に大切なことです。大きなプロジェクトに集中して物事を進めるのはとても簡単で、小さな小さな問題が出てきてもすぐに解決できますが、その間にあるものはなかなか時間を作ることができません。
そして、今回、この時間を設定して、それを刻み、全員が同じ意識でいたことが、本当に重要だったと思います。だから、このようなことをするのであれば、それはお勧めできる重要なことだったと思います。
ラウ： 私のアドバイスは、タスクを書くときや、思考やフィードバックを整理するときに、解決しようとしている問題、なぜそれを解決しようとしているのか、以前はどうだったのか、そして、その後どうなるのか、あなたの考えをきちんと説明できるようにしておくことです。
たとえそれがデザインプロセスに入った時点で変わるとしても、アイデアを少し根拠づけておくと、"これはどういう意味なのか？"を考えるのに費やす時間が少なくなります。
だから、タスクを管理するというより、自分のプラットフォームで注力したい部分を設定するという感じですね。
ジャスティン：最後になりますが、今回のことは、お客様にとってGather をより良いものにするためのものです。ですから、私のアドバイスはこうです：お客様の立場になって考えてみてください。お客様の立場に立って、製品を使った日々の体験を理解することです。
もし、あなたが詳細を正しく理解していないのであれば、製品を気に入ってもらえない可能性はかなり高いでしょう。少なくとも、満足はしてもらえないでしょう。だから、あなたが彼らのために細部にまで気を配るようにしましょう。
全体として、このようなアプローチは、Gather の体験に支障をきたしていた多くのバグや問題を解決するのに非常に有効であったと、チームは合意しました。私たちは、Gather を少しずつでも最高のものにしていくために、今後もそのプロセスを共有していきたいと考えています。ぜひ、ピクセルパーフェクトの詳細をご覧ください：116 Bug Fixes & Improvementsブログで、チームが取り組んだすべてのことをご覧ください。
まだまだ始まったばかりのこのようなライブ配信にご期待ください！
少しずつでも良いものを作っていく
-Gather チーム
