2020 年に Wayfair に就職したとき、私は膨大なビジネスを推進する B2B ツールを管理する、スリムでまとまりのあるチームに参加できることに興奮しました。私は主にサイロ内で働いていた役割から来たので、再び開発チームの一員になれることに特に興奮していました。しかし、すぐに、チームのメンバーの多くが私たちが使用しているツールに精通していたため、他の開発者も自分たちと同じ背景、経験、知識を持っているという先入観を持っていたことに気付きました。大きな問題は、私たちが取り組んでいたツールが社内専用のものであったため、新しい開発者の多くは、経験豊富な開発者ほどそれらをよく知らなかったことです。これは一般的には問題ではありません。しかし、Jira チケットがほとんど詳細なしで作成、優先順位付け、見積もり、割り当てられたときに、非常に問題になりました。確かに、タイトルは一般的な問題を説明し、それを書いた経験豊富な開発者は、変更を加えるためにどこから始めればよいかを正確に知っていたでしょうが、プラットフォームに慣れていない私たちには、始めるための基盤がほとんどありませんでした。これにより、効率性に大きな欠陥が生じ、より経験豊富な開発者にさらなる情報を求めて絶えず追い詰められることになりました。 この設定のもう 1 つの副作用は、見積もりのために提示されたチケットについて質問する人が増えるにつれて、技術設計会議が長引く傾向にあることです。会話の中で詳細が絶えず語られていましたが、記録されていませんでした。これらの会議は長引いて、チケットが割り当てられると、同じ質問が再び出てきました (割り当てられた人が、数週間前に最初に質問された会話を魔法のように思い出せる場合を除く)。 このワークフローは、非常にイライラさせられる非効率的なものでした。しかし、希望はあります。この問題を認識して話し合った直後、会議はよりスムーズに進み、時間が短縮され、より効果的なものになりました。チケットには詳細が豊富に含まれ、簡単に対応、テスト、完了できました。その方法は次のとおりです。 問題: チケットの準備不足と長時間の会議 技術設計会議は、チケットの詳細が不十分なために、しばしば頓挫していました。開発者、設計者、その他の関係者は、追加情報を探したり、タスクのあいまいな側面を明確にしたりするのに時間がかかりすぎていました。これにより会議が長引くだけでなく、割り当てられたチケットが頻繁に戻され、作業を進める前にさらに明確にする必要が生じ、開発が遅れることもありました。 その良い例としては、ベテラン開発者が報告したチケットで、「フロアリング SKU の価格を修正する必要があります」とだけ書かれていたものが挙げられます。 明らかに、十分な背景情報がなければ、このチケットを受け取ったときにできることはまったくありません。フロア SKU の価格設定の問題は何ですか? 何が起こると予想されますか? カート内の SKU の数量は重要ですか? 未解決の質問がたくさんあり、会議に参加せずに作業を開始する方法はありません。より良いチケットの説明は次のようになります。 「フロア SKU はまとめ買い価格になっており、カート内の数量がまとめ買い価格のしきい値を超えると、当社のシステムは価格/数量の計算を適切に処理しません。」 ここではまだ詳細が十分ではありませんが、少なくとも問題は適切に説明されています。 この例を詳しく説明するつもりはありませんが、開発者は、現在のタスクに応じて、見積もりやチケットの作業を行うのに十分な詳細が得られるまで、繰り返し質問、会話、プレゼンテーションを行って、これらすべての詳細を具体化する必要があります。これにより、開発者として取り戻すことのできない多くの時間が失われました。 解決策: チケットテンプレートの実装 この問題を解決するために、私たちは、行われている作業の種類に合わせて調整された構造化されたチケット テンプレートのセットを開発しました。これらのテンプレートにより、バグ レポート、設計変更、機能要求、最適化タスクなど、すべてのチケットに、議論または割り当てられる前に必要な情報がすべて含まれていることが保証されました。ルールはシンプルでした。テンプレートが完全に完成していない場合は、チケットは会議や開発の準備ができていないというものでした。 バグレポート 説明： 問題の簡潔かつ詳細な説明 期待される動作: スクリーンショットや Figma 参照など、どのように動作するかについてのより詳細な説明。 実際の動作: 何が起こっているのか、そしてそれが予想される動作とどう違うのかの詳細な説明 再現手順: 問題を再現するための具体的で詳細な手順。誰かがツールで新しいシークレット ウィンドウを開き、手順から逸脱することなく問題を再現できるようにアプローチする必要があります。 (オプション) 開発者メモ: これはオプションのセクションであり、どこに配置すべきか、どのように開発すべきかについてすでに良いアイデアがある場合に、提案されたアプローチを含めることができます。開発者に特定の方法で作業するように強制するつもりはありませんが、ここでのガイダンスは、後でチケットの実行を迅速化するのに役立ちます。 (オプションだが推奨) 外部の影響: ここでは、この作業に影響を与える可能性のある外部ソースを呼び出します。API のバグに対する回避策をすでに作成していて、修正時に通知する必要があるチームはありますか? このバグは、修正にかかる時間に影響を与える可能性のある情報を他のチーム/API/ソースに依存していますか? (オプション) 影響: これは、チームまたはビジネスに既知で測定可能な影響を与えていますか? これは必ずしも既知ではなく、測定も容易ではないため、オプションのフィールドになっています。ただし、存在するかどうかを知ることは、優先順位付けのために重要です。 デザインの変更 説明： 問題の簡潔かつ詳細な説明 期待される動作: 期待される設計された動作のスクリーンショットまたは Figma リンク。 実際の動作: 実際に何が起こっているかを詳しく説明したスクリーンショットやビデオ、また何が起こっているのか、そしてそれが予想される動作とどう違うのかの説明 (オプション) 再作成の手順: これが特定の状況でのみ表示される特定の UI 要素である場合、変更をテストする方法がわかるように、これがいつどのように表示されるかを正確に把握する必要があります。 (オプション) 開発者メモ: これはオプションのセクションであり、どこに配置すべきか、どのように開発すべきかについてすでに良いアイデアがある場合に、提案されたアプローチを含めることができます。開発者に特定の方法で作業するように強制するつもりはありませんが、ここでのガイダンスは、後でチケットの実行を迅速化するのに役立ちます。 (オプション) 影響: これは、チームまたはビジネスに既知で測定可能な影響を与えていますか? これは必ずしも既知ではなく、測定も容易ではないため、オプションのフィールドになっています。ただし、存在するかどうかを知ることは、優先順位付けのために重要です。 機能リクエスト 説明： 機能に関する完全な詳細図。どのように機能するか、予想される入力/出力は何かなど。また、この機能が要求されている理由についてもここに含める必要があります。 開発者ノート: 開発者はこのセクションを使用して、コードベースの残りの部分にシームレスに適合させるために利用する必要がある既知のフレームワーク/パターンに関するガイダンスを提供する必要があります。開発者に特定の方法でコードを記述するように強制するつもりはありませんが、ここでのガイダンスにより、チケットの実行が高速化され、PR の会話がより合理化されるはずです。 (オプションだが推奨) モックアップ: 開発のガイドとなるサンプルのペイロード、スクリーンショット、Figma 参照がある場合は、すべてここに含めてください。 (オプションだが推奨) 外部の影響: ここでは、この作業に影響を与える可能性のある外部ソースを呼び出します。API に欠けている機能の回避策をすでに作成していて、その機能を追加したときに通知する必要があるチームはありますか? この機能は、ビルドにかかる時間に影響を与える可能性のある情報について、他のチーム/API/ソースに依存していますか? (オプション) 影響: これは、チームまたはビジネスに既知で測定可能な影響を与えていますか? これは必ずしも既知ではなく、測定も容易ではないため、オプションのフィールドになっています。ただし、存在するかどうかを知ることは、優先順位付けのために重要です。 最適化タスク 説明： 問題の簡潔かつ詳細な説明 現在の状態: コードが現在どのように動作し、なぜ非効率的であるかについての詳細な説明。 優先する州: この最適化で何を修正しようとしているのか、どのような目標を達成しようとしているのかの詳細な説明 開発者ノート: これは、最適化の必要性を訴える開発者からのガイドです。編集が必要な特定のファイルとテスト、およびパフォーマンスのボトルネックまたは混乱の原因となっていると思われる特定のセクションを指摘する必要があります。 : テスト この最適化を検証または確認する方法に関するメモ。このプロセスから実際に何かを得たことを確認する必要があるだけでなく (自慢できるものになる可能性もあります)、変更がコードの変更に依存する既知の外部プロセスに影響を与えなかったことを確認する必要もあります。 外部の影響: ここでは、この作業に影響を与える可能性のある外部ソースを呼び出します。この機能は、ビルドまたはテストにかかる時間に影響を与える可能性のある情報について、他のチーム/API/ソースに依存していますか? インパクト： これは、チームまたはビジネスに既知で測定可能な影響を与えていますか? これは必ずしも既知ではなく、測定も容易ではありませんが、リファクタリングまたは最適化を正当化するには、この情報が必要です。 テンプレートの影響 結果はすぐに出ました。 1 時間の技術設計会議で、以前の 3 倍ほどのチケットを処理できることがすぐにわかりました。また、これらの会議で行った議論は、より有益で影響力のあるものになりました。詳細を把握しようと時間を費やすのではなく、エッジケース、影響を受けるチーム、プロセスにおける潜在的な障害やボトルネックを指摘し、開発者を作業に備えさせました。また、このフィードバックをすべてチケットの説明またはコメントに記録するというパターンを自分たちに課しました。テンプレートは、これらの詳細が重要であり、存在して簡単に見つけられる必要があることを常に思い出させてくれました。ある意味で、これらのテンプレートは、これらのチケットに対してドキュメントを優先するアプローチを取るように私たちの脳を再訓練し、チケットを手にした人が初心者開発者であろうと熟練エンジニアであろうと、高品質のコードを書くのに十分な情報が得られるようにしました。 次に、開発サイクルがより簡潔になり、見積もりがより正確になり、スプリントで切望されていた 100% 完了マークをこれまでよりもはるかに頻繁に達成していることに気付きました。ボードをほぼ一貫してクリアすることができました。これは、私たちが受け取ると伝えた更新を受け取っていたためビジネスにとって重要であるだけでなく、常に成功の立場に身を置くことでチームの自信を大きく高めました。利害関係者は、効率とスループットの向上を見て、チームとプロセスに対する信頼を高めました。また、実際の問題に集中する時間を増やすことができたため、コードの品質が向上したことにも気付きました。 これによって開発者としての私たちの生活がより良くなることは最初からわかっていましたが、ビジネス パートナーにもこれほど大きなプラスの影響を与えるとは考えていませんでした。 他のチームにとっての重要なポイント チームが情報不足で常に負担を強いられていると感じる場合は、構造化されたチケット テンプレートの作成が効果的かどうか調査してみる価値があるかもしれません。ただし、チケットを詳細に記述して対応できるようにするために、開発者の時間がさらに必要になることに注意してください。これは正当なコストであり、ワークフローを大幅に改善するため、長期的には大きなコスト削減につながると私は信じていますが、これらの変更は無料で行われるわけではないことも指摘しておく必要があります。誰かが時間をかけて調査を行い、高品質のチケットを作成する必要があり、その誰かとは開発チームである可能性が高いです。 そうは言っても、これがチームにとってどれほど大きな勝利になるかは簡単にわかります。まずは、いくつかの簡単な手順を実行することをお勧めします。 、本当に問題があるかどうかを評価します。1 人か 2 人の開発者がドキュメント作成や知識移転に苦労している場合もありますが、それはチケットに全面的な問題があることを示すものではありません。オンボーディングやドキュメントの改善など、他の方法でこれらの問題の一部は解決できるかもしれません。 まず これが解決を必要とする広範囲にわたる問題であることがわかった場合、次のステップは、通常どのような種類のチケットを受け取るか、そしてそれぞれにどのような種類の情報が必要かを分類することです。明らかな候補はバグと機能ですが、会社のビジネスの性質によっては、システム内を常に流れ、異なるニーズを持つ他の種類のチケットがあるかもしれません。チームが ETL パイプラインを管理していて、それに関連するチケットにどのような入力/出力が影響するかを知る必要があるかもしれません。チームが SDK を所有していて、それに関連するチケットを特別/優先的に処理する必要があり、変更によって影響を受ける可能性のあるビジネス機能を含める必要があるかもしれません。チームとその要件を把握して、必要なテンプレートの種類を正確に判断できるようにします。 次に、 この情報をすべて入手したら、それを誰もがアクセスできる共有の場所に文書化します。共有ドキュメントや、チームが管理してアクセスする wiki ページなどです。あるいは、Jira 自体にテンプレートを作成して、ユーザーに使用を強制することもできます。どのようなアプローチを取るにしても、チームと開発者の同意を得る必要があります。つまり、彼らがそれを見ることができるようにする必要があります。これは最も重要なステップの 1 つです。チケットを作成するすべての人から 100% の同意が得られなければ、このプロセスはそれ以上先に進めないからです。これらのテンプレートをチームに提示し、フィードバックを集め、この新しいプロセスが自分と関係者にどのような影響を与えると思うかを説明します。チーム全員が新しいプロセスに慣れていることを確認します。 次に、 、これらの変更を実施する必要があります。十分な詳細がないまま提示されたチケットは、議論せずにすぐに返送する必要があります。テンプレート ガイドラインに厳密に従うことが重要です。そうしないと、人々は常に回避する理由を見つけてしまいます。「この問題は重大すぎるので、書く時間がありません」というのは、私たちがよく受ける苦情です。ただし、テンプレートの必要性を厳格に伝え、回避しようとしている人々と協力すれば、最終的には彼らを納得させることができます。 最後に Wayfair では、上記の小さな変更を加えることで、チームのプロセスと士気が大幅に向上しました。これが皆さんのチームにも役立つことを願っています。
