「アジャイル推進」にストップ!

始める前にしておく必要がある 3 つの会話

Martin Suntinger Martin Suntinger
トピック一覧

会社は "アジャイル推進" というミッションを、本当の意味を理解する前に設定しまうことがよくあります。しかしすぐにほころびが出始め、期待が失われ、誰もが "アジャイル推進" の価値そのものを疑問に感じるようになり、アジャイルを達成する機会はまったく損なわれてしまいます。

実際は、アジャイル推進によりチームの生産性が上がり、プロジェクトを早く引き渡せるようになりますが、それは全員がルールに合意できる場合に限ります。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: そうですね、よい関係者はチームのメンバーの 1 人です。ですから、理想的には、チームに主要な関係者を入れて、みんなで仕事することができます。壁越しにチームに物を投げこんでくるような、またはプロジェクト中に飛び込んできて、すべてを変更しようとするような関係者がいる場合、取り組んでいる作業の内容と理由をチーム全員が理解していることが重要です。そうすれば、関係者が何を言おうと、答えは同じになります。その姿勢が個人の集まりでないチームを作るのです。大いに話し合い、全員が共通認識を持ち、同じ方向を目指すようにする必要があります。

ストーリーの見積もりは大まかな見積もり (時間) を基にしますか、またはポイントを基にしますか。

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 つは、それによってコントロール範囲外の事柄に適応できることです。競争環境の変化やビジネス要求の変化、または新しい技術の登場があっても、何か月も前に作られた要件表に従って、遅々とした歩みを本当に続けたいですか。顧客に最高の製品を届けたいのなら、変化を受け入れ、それをメリットに変えてください。アジャイルには「スコープクリープ」は存在しません。(ここにジェダイのマインドトリックをしのばせておきます)

次の記事
DevOps