BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース アジャイルをスケールするための方法を探る

アジャイルをスケールするための方法を探る

原文(投稿日:2014/07/08)へのリンク

アジャイルをスケールするのはアジャイルコミュニティにとって大変なことだ。スケールするとはどういうことなのか。どのように実現するのか。フレームワークや手法はどのようなものがあるのか。アジャイルをスケールすることに挑戦するのは、問題の兆候となる場合もある。小さなチームから組織全体のアジャイル導入へ移行する自然な成長の場合もある。

このスケールの問題に対処するための手法はたくさんある。そして、どのような状況でどのような手法を使うかについて多くの混乱がある。

Richard Dolman氏とSteve Spearman氏は異なるスケール手法を紹介するウェブサイトと比較に使えるメトリクスを公開している。

彼らはこの比較サイトを作成した理由を次のようにいう。

コミュニティに次の3つを提供することが目的です。
  • 可能な限り客観的な条件を加えた流行のアジャイルスケーリングフレームワークを比較するメトリクス。
  • 独自の比較に利用できるモデル。
  • 作家や業界のリーダーなどからの注釈。これによって比較手法に対する"意見"も得られる。

InfoQは彼らにインタビューを行った。

InfoQ:簡単に自己紹介をお願いします。

Steve Spearmanです。ソフトウェア産業で30年以上働いています。さまざまなクライアント、多くは企業ですが、アジャイルコーチィングとトレーニングを提供しています。CST、SAFe SPC、CSM、CSPO、PMP、PMI-ACPというような資格を持っています。
Richard Dolmanです。ソフトウェア、コンサルティング、金融サービスなどの世界で25年以上働いてきました。企業向けにアジャイルコーチングとトレーニングを提供しています。CSP、CSM、PMI-ACP、PSM I、ICPというような資格を持っています。

InfoQ:なぜアジャイルをスケーリングすることに着目したのですか。

業界のホットトピックにも関わらず、公正へ積極的な方法でさまざまな手法を情報を統合し示す試みがなされていないからです。ある手法をほかの手法の後ろに置く、というようなことをしたいのではありません。目的はコーチや企業が自分たちのニーズを評価し、さまざまな手法を理解し評価してニーズに最も適合する手法を見つけるのを手助けすることです。

InfoQ:なぜこの仕事をしたのですか。どのような問題を解決しようとしているのでしょうか。

私たちはふたりとも経験を積んだアジャイルコーチであり、拡大している企業と仕事をすることが多いです。2013年にはScrum Alliance Coaching Retreatの小グループでこのトピックを取り上げました。ここでわかったのはスケーリングの手法を客観的に比較する方法に対するニーズでした。
スケーリングについての質問に対する従来の回答は多かれ少なかれ"自分で見つけろ"です。これは強力なやり方ですが、多くの企業ではこれ以上のやり方が必要です。大企業でアジャイルがキャズムを超え、スケーリングについてのフレームワークやアプローチの人気に火がつきました。私たちはアプローチを比較し、自分たちの状況に最適な手法を見つけるのを支援したいのです。

InfoQ:“アジャイルのスケーリング”とはどういう意味なのでしょう。

私たちもこの質問からスタートしたのです。“‘アジャイルをスケーリング’をどのように定義するか”。
“アジャイルをスケーリング”するというのは2、3のアジャイルチームが複数、数百の開発チームにふくれあがること意味する場合もあるでしょう。3つ、4つのアジャイルチームを協調させながら一緒に働かせる場合はユニークな困難があります。ほとんどのスケーリングフレームワークは4つから数百のアジャイルチームが協力して働く場合に使えるアイディアと手法を提供しようとしています。また、ITを超えてアジャイルを広め、ビジネスのオペレーションや組織のIT以外の分野でアジリティを追求することを、スケーリングと定義する人もいます。人気の手法ではこのニーズには効率的には対処できません。

InfoQ:スケーリングに対する現時点でのアイディアにはどのような間違いがありますか。

これについてはさまざまな意見があります。難点のひとつは最適なスケーリング手法とスケーリングフレームワークとして認定することに対してさまざまな見方があるということです。記事やフォーラムの議論は白熱しています。
私たちは議論のどちらかに加担しないようにしています。議論している人たちのほとんどがアジャイルやリーンのやり方に賛同していますが、彼らが提案するスケールの問題への対処法は本当にさまざまなのです。
私たちが解決しようとしている問題はスケーリングの手法やアイディアというよりは議論に客観性を与え、組織のニーズに基づいた比較分析モデルに含まれるギャップを生めることです。

InfoQ:モデルの目的を教えてください。

いくつかの目的があります。
もっとも一般的なスケーリング手法についての情報や参照を集積したいと思っています。私たちはこの集積をAgile Scaling Knowledgebase (ASK)と呼んでいます。
また、比較マトリクスを簡単に理解できるようにし、自分たちの状況にあったスケーリング手法を選択するのを支援したいと思っています。
そして、異なるスケーリング手法を比較するための構造を提供します(私たちが把握している手法以外にも多くの手法があります)。これによって、必要に応じてモデルをカスタマイズしたり拡張したりできます。

InfoQ:モデル化のためにどのような手法を選択しましたか。なぜその手法を選択したのでしょう。

私たちはまず、もっとも人気のある手法に着目しています。しかし、ウェブサイトではほかの手法への参照も提供しています。比較マトリクスはScrum of Scrums(SoS)のような基本的なことを網羅しています。同時に Large Scale Scrum (LeSS)、Disciplined Agile Delivery (DAD)、Scaled Agile Framework (SAFe)のようなもっと複雑なモデルも扱います。Spotifyで使われている手法も扱います。これらは多くの議論を経て選び出されたものです。また、現時点での業界での使われ方も参考にしました。ASKマトリクスの利用者は自身の条件に従って手法の追加や削除ができるでしょう。

InfoQ: モデルを比較するときに重要な点は何でしょうか。

難しかったのは客観的な評価条件と主観的な評価条件のバランスの取り方です。まずは客観的な条件を強調しようとしましたが、難しい条件については主観的なレーティングを提供しています。多くの経験豊かなコーチにモデルについての助言を求めました。それに基づいてASKモデルを進化させています。
私たちが定着させたい特徴のひとつは、ASKを使った意思決定メトリクスをいくつかの重要で組織の状況に関連する条件から始めるということです。また、すべてのレビューアのコメントやフレームワークの作者の意見も含めたいとも思いました。近い将来にウェブサイトに追加される予定です。

InfoQ:このモデルを使ってスケーリングの手法を選択する人たちにアドバイスをお願いします。

これは比較するための数ある方法のひとつにすぎないということを覚えておいてください。利用者が私たちのモデルを使いやすいと思ってもらえることを望んでいますが、自分の考えやニーズに合致するモデルを探してほしいとも思います。
そして、フィードバックや、利用者が価値があると思ったほかの情報へのリンクをいただきたいです。それによって、私たちも自分たちのモデルや関連サイトに価値を加え続けることができます。私たちの業界にとって価値ある情報源になることを望んでいます。

InfoQ:モデルはどこで見ることができますか。

最新のマトリクスとサポート情報はここにあります。
また、このトピックについてオーランドのAgile2014プレゼンしました。興味がある方はご覧いただき、疑問点や感じたことをシェアしていただきたいと思います。

 

この記事に星をつける

おすすめ度
スタイル

BT