会社は "アジャイル推進" というミッションを、本当の意味を理解する前に設定しまうことがよくあります。しかしすぐにほころびが出始め、期待が失われ、誰もが "アジャイル推進" の価値そのものを疑問に感じるようになり、アジャイルを達成する機会はまったく損なわれてしまいます。
実際は、アジャイル推進によりチームの生産性があがり、プロジェクトを早く引き渡せるようになりますが、それは全員がルールに合意できる場合に限ります。e コマースの大企業、Gilt 社の Heather Fleming と Justin Riservato が、アジャイルの原則に対するコンセンサスを得ることが、プロセスの実装よりも重要である理由についてお話しします。
具体的には、Heather と Justin は、チームがアジャイル導入の作業に取りかかる前に答えを用意しておかなければならない 3 つの重要な質問への回答を検討します。
- 「では、いつ実行しますか?」アジャイルに行動する際に、締め切りの概念を排除することが最も重要 (かつ最も困難) な会話である理由。
- 「これは私の最優先事項なのですが、来週までお会いできません。」ビジネス パートナーをチームのフル メンバーにできない (またはしない) 場合はどうすればよいか。
- 「私はコードを作成したいだけです。なぜ私がこれらのミーティングすべてに出席しなければいけないのですか?」スクラムの実装が、アジャイルに行動するための最初の一歩ではない理由。
見て学ぼう
Q & A
ここでは、Heather と Justin が、このプレゼンテーションの Q&A セッションで最も質問が多かった事柄をいくつかを選びました。アジャイル方法論を適用する方法について詳しく理解するのに役立つ内容です。
Q1：アジャイルボードにはデジタルと物理的なものがありますが、どちらを選びますか。
A1: それはまさにチームの状況次第です。全員が同じ場所にいますか。チームの大きさはどれくらいですか。大きな物理的なボードを設置するスペースがありますか。Gilt では両方使っていますが、会社が成長し、チームが何十にも増えるにしたがい、Jira Software のアジャイル ボードの方が物理的なボードより実用的だとわかりました。アジャイル ボードは設定や変更が簡単で、リモート チームのメンバーと共有しやすいのです。物理的なボードで気に入っているのは、それがぱっと目の前にあって、何といっても無視できないことです。さらに、現在の作業について緊急の議論をしたり、スタンドアップ ミーティングをしたりするのに最適です。
Q2：アジャイル プロセスについていけない、または理解していない管理者やクライアントとどのように仕事しますか。時々、自分がうまくいっていないワークフローのコーチのような気がしてきます。
A2: アジャイルに対する理解を深める順序を考えることが重要です。アジャイルを信用していない人と一緒にアジャイルのプロセスで仕事をしようとしているなら、それは少し急ぎすぎです。アジャイルをうまく活用するのに最も重要なのは、プロセスを実行する前に、理念に対するコンセンサスを得ることです。チームが現在のプロセスで抱えているある問題を取り上げ、それをアジャイルの方法で解決することにより、コンセンサスを得たという経験が過去にあります。マネージャーやクライアントが解決しようとしている実際の問題に取り組んでもらうことはできますか。それをアジャイルのフレームワークでやるならどうしますか。プロセス全体を一度に大きく変更するのではなく、少しずつアジャイルの方法に近づけていくことができますか。チームが作業をこなせるようになるに従って、徐々にアジャイルの方法で実際の結果を出せるようになります。要するに、アジャイルを推進するには、アジャイルの方法で取り組めばよいのです。
Q3：プロジェクトが固定契約または固定スケジュールで、実装する要件の一覧が付いている場合、アジャイルのプロセスをどのようにして実現できるのでしょうか。
A3: まず第一に、実装要件が一覧で固定されているプロジェクトを固定スケジュールで完了することは不可能です。ですから、このようなプロジェクトは夢の国のお話であるとみんなに同意してもらう方法がありますか。締め切りや要件に関する制約のほとんどは本当の制約ではありません。それは願望といったものです。仕事をしている理由は何か、または解決しようとしている問題は何かについて話し合うことから始めましょう。プロジェクトの目標と制約の理由を本当に理解すれば、チームが適切な時に適切な仕事をしていると確認できるようになります。横に日付を添えて要件をすべて書き出せば、それで魔法のようにすべてが予定どおりに運ぶわけではありません。
Q4：ほとんどのプロジェクトでは、ふつうパートナーや顧客にリリース日を伝えています。この場合、交渉可能なのは機能セットだけです（ただし、品質上の妥協はあります）。固定された期限の制約の中でどのように作業しますか。
A4: ご質問の中に答えがあるように思えます。つまり、スコープを交渉することで可能です。そうしないと、おっしゃる通り品質が低下してしまいます。お構いなしにスコープに詰め込めると考えるのは夢物語です。つまり、人が聞きたくないことであっても、チームは現実と向き合って作業していることをはっきりさせる必要があります。Heather がこの話題に関する短いブログをここに投稿しているので、読んでみてください。
Q5：スクラムの実装方法を変更すべきだという主張をどう思いますか。
A5: スクラムの固定性は、スクラムの一番の問題点です。作業の内容やチームの構成に関係なく、すべてのチームに対して、単一の厳密に規定されたプロセスが機能すると考えるのは思い上がりです。多くのチームで機能した例を知っていますが、スクラムだけがアジャイルの方法ではありません。役割、ユーザー ストーリー、受け入れ基準、ミーティング、アーティファクトなどすべてを規定どおりにして、指定の方法でスクラムを実装しなければならないと考えたために、数多くのチームがアジャイルで失敗してきました。Heather は「スクラム マスター」とタイトルで課題についても書いています。
Q6：関係者がチームメンバーに直接影響を与えるのをどのように防ぐことができますか。
A6: そうですね、優れた関係者はチームのメンバーの一人です。ですから、みんなで仕事ができるようにチームに主要な関係者を入れると理想的です。チームに仕事を丸投げするような、またはプロジェクト中に飛び込んできて、すべてを変更しようとするような関係者がいる場合、取り組んでいる作業の内容と理由をチーム全員が理解していることが重要です。そうすれば、関係者が誰と話そうと、答えは同じになります。その姿勢が個人の集まりでなく、チームを作るのです。大いに話し合い、全員が共通認識を持ち、同じ方向を目指すようにする必要があります。
ストーリーの見積は大まかな桁数の (時間) 見積を基にしますか、またはポイントを基にしますか。
A7: 私たちは両方使いますが、まったく見積をしないチームもあります。ポイントは抽象性が高く、特定のカレンダー時間に縛られない点で優れています。チームが見積に抵抗を感じている場合は、具体性が高い時間が移行措置として役に立つかもしれません。見積の長所は、スプリントが重すぎるのか、または軽すぎるのかを判断して修正できる点にあり、いったんスプリントを開始すると、実際に何の役にも立ちません。しばらくチームとともに作業をすると、見積のプロセスが不要になることがわかります。誰でも作業を見れば、それがスプリントに適切な量であるかどうかごく簡単に見分けられるからです。
Q8：深い分析能力と製品知識を持つプロジェクトリーダーやマネージャーと、単に技術者とビジネス関係者の会議を調整して要件を収集するのとでは、どちらにどれだけの価値を置きますか。
A8: ほとんどすべての価値です。会議の調整、記録作成などは専門的なスキルではありません。そうした仕事は誰でもできます。重要な仕事かもしれませんが、それが実際チームに提供できる最大の付加価値になるわけではありません。管理業務しかしていないのであれば、その人がチームの一員である理由をチームが疑問に思うのももっともです。Gilt の PMO では、誰でも業務の遂行のために関連するテーマやツール、技術を深く理解し、一緒に仕事をするすべてのチームにその知識理解を伝えています。私たちの多くはかつてエンジニアであったり、また Gilt の他の部署と協力して作業したことがあるため、それぞれ固有の分野の専門知識を身につけています。
Q9：Gilt では、一般的にチームの規模はどの程度で、メンバーはどのような経歴を持っていますか。
A9: 理想的には、当社のチームは小規模だけれども自足できる程度の大きさで、他のチームに依存することなくプロジェクトを進められる程度であってほしいと考えています。当社では「ピザ 2 枚」ルールに従っています。チームの人数はピザ 2 枚で足りる程度でよいという意味です。また、チームのメンバーはそれぞれ独自の才能を持っていて、その人の職名が何であれ、才能をチームのために使ってほしいと強く願っています。従来、プロダクト所有者がすべてのプレゼンテーションに責任を持っていますが、その人にプレゼンの才能がなく、ある技術者が話が上手で聴衆を惹きつける力がある場合、その技術者にチームで才能を発揮してもらいます。人を職名で判断することはできません!
Q10：特に開発とは別のスプリントでテストを行っている場合、個別の QA チームをどのように管理しますか。
A10: これは当社で最も議論のある方針の 1 つですが、Gilt では個別の QA チームを設置していません。当社では、開発およびデプロイの全プロセスにわたり、自動テストに信頼を置いています。チームは自分たちが作るコードの品質に責任があります。コードを書く時間と技能があるなら、コードのテストを書く時間と技能があるはずです。テスト作成を QA チームに丸投げしても、決してよい結果が生まれず、QA チームに必要な情報を提供するには多量のドキュメントと時間が必要になります。
Q11: 同時に複数の「製品」に取り組んでいる複数のチームがある場合、スプリント計画中にプロダクト マネージャー全員を 1 室に集めて、製品間の相対的な優先度を決定させるというやり方はうまく機能するでしょうか。また、他にアイデアはないでしょうか。
A11: だめです。そのやり方は明らかに機能しません。チームには自分のチームのプロダクト マネージャーがいるべきであり、チーム外の複数のプロダクト マネージャーのもとで複数の製品に取り組むべきではありません。誰がチーム リーダーの役割を果たすにしても、その人がこの場面で力を発揮して、優先度に関するチームの方法論とこの方法論に基づいて作業の実行に取り組む順番について、その概要を明確にする役割を果たすべきです。これは私たちが主張している点につながります。すなわち、「プロセスを実行する前に、方法論の考え方を揃えなければならない」ということです。
Q12：私はマーケティング分野のクリエイティブサービスチームにアジャイルを導入しようとしています。わが社では指定の日付に納入しなければならない成果物をいくつか扱っています。(雑誌に掲載する広告の制作) このプロジェクトをアジャイルのフレームワークにどう当てはめればいいでしょうか。
A12: アジャイルはこのような制約に対処できます。何をいつまでに完了すべきかを明らかにし、それに応じてスプリントを計画するのはチームの仕事です。アジャイルが行うのは、スプリントごとに優先順位と計画した作業 (スコープ) を調整しやすくし、それによって期限を守れるようにすることです。ベロシティのトラッキングを開始すると、意外に期限よりも早く作業を終えられそうかどうか、すぐに分かるようになります。その段階で、チームの成功に必要な交渉をするのが優秀なチーム リーダーの役目です。
Q13は：目標の変更はスコープクリープに見えないでしょうか。
A13: そう見えます。しかし、当社ではプロジェクト中の変更を推奨するので、「スコープ クリープ」とは呼びません。アジャイル理論の最大のメリットの 1 つは、コントロール範囲外の事柄に適応できることです。競争環境の変化やビジネス要求の変化、または新しい技術の登場があっても、何か月も前に作られた要件表に従って、遅々とした歩みを本当に続けたいですか?顧客に最高の製品を届けたいのなら、変化を受け入れ、それをメリットに変えてください。アジャイルには「スコープ クリープ」は存在しません。(ここにジェダイのマインドトリックをしのばせておきます。)
