ブログ

かつては物事はシンプルでした。 90年代に、アジャイルを選択しようとすれば、XPを選択するしかありませんでした。そして、その後、スクラムがポピュラーになりました。組織がチームへのフォーカスによって、これらのアプローチの限界に突き当たるようになったのは最近の話です。それから、ソフトウェアにリーンの原則を適用することができるということが明らかになってきました。リーンソフトウェア開発および後のカンバンが一連の中に加わりました。今、もしアジャイルな開発手法を選ぼうとすると、非常に多くの選択肢があります。 単にどのメソッドを選ぶか、という点だけでなく、どこから始めて、トップダウンで行うのか、ボトムアップで行うのかを考え、自分の努力の範囲をどこまでにするか、というようなことも考えなければなりません。

色々考えなければならないことに気力をくじかれてしまうかもしれません。それをより少なくすることができるかどうか見てみましょう。

アジャイルって何だろうか？

アジャイルが意味するところを考えてみましょう。多くの人は、小さなステップ（反復）でソフトウェアを作ること、進捗やプロジェクトの健康状態は開発されたソフトウェアという観点で測定すること、作っているものが本当に有用であることを保証するために顧客のそばで働くことがアジャイルであるというかもしれません。 でもこれは、私が「チームのアジリティ」と呼んでいるものです。なぜならそれがフォーカスしているのが、チームとチームがどのように働くか、という点だからです。 現時点では、一番よく使われているアジリティの形で、多くの人に効果的であることは間違いないけれども、あなたが得ようとしている本当のゴールではありません。

わたしたちの仕事の本当のゴール＝成功 を測定するもっともよい指標は、開発組織が仕えるビジネスユニットがどれだけ素早い対応ができているかに着目することです。 私はこれを「ビジネスアジリティ」と呼んでいます。ビジネスアジリティはチームを超えたものをも内包しています。残念なことにビジネスアジリティを達成することはとても難しいことです。 ビジネスアジリティは、ビジネスまたはビジネスユニットがビジネス価値をクライアントに対してインクリメンタルに届けられる能力のことです。 ビジネスアジリティは、企業がマーケット環境が変化したり、新しい技術が出たり、新しいアイデアがでたときに、必要に応じて、すばやく反応することを可能にします。

ビジネスアジリティは素早く動ける、効率的な、必要なところに行ける車を持っているようなものです。 チームのアジリティは、ドライバーが望んでいる操作を可能にするよくチューニングされたエンジンのようなものです。言い換えると、ビジネスアジリティは本当の完全なるゴールであり、チームアジリティはそのための手段を意味します。 現時点では、十分に小さな組織においては、チームだけにフォーカスすることが適切かもしれません。しかし、一定規模以上の組織においては、チームにフォーカスすることによってにジネスアジリティを達成しようとすることは、ただエンジンのチューニングだけを繰り返してよりよいパフォーマンスをだそうとしているのと同じことです。 エンジンのチューニングも役にはたつでしょうが、トランスミッションやブレーキを改良したほうがよりよい結果が得られるでしょう。

一般的なアジャイルのメソッド：スクラムとXP

先に言ったように、スクラムと、今はちょっと少ないが、XPは、アジャイルムーブメントの中ではもっともポピュラーな手法でした。 XPはペアプログラミングやテストファーストや継続的インテグレーションや共同所有などの開発プラクティスにルーツをもつ開発手法です。 スクラムは一義的には組織の妨害事項をあらわにするプロセスのフレームワークです。 その根底にある想定事項としては、もし間違っていることをやっていても、問題は修正可能である、という考え方です。 スクラムの力は、数週間の中で問題を早期に明らかにできる、ということで、この点についてはウォーターフォールからの大きな改良であることに異論はないでしょう。 明らかになった問題への対応方法がはっきりしない場合があり、そのような場合の対応が課題となっています。

両方のメソッドは1から4週間隔のイテレーション、自己組織化、機能横断チームといったものを利用します。

スクラムはいくつかの理由によってよりポピュラーになってきました。 1つ目は、チームがXPの核となっているような技術的なプラクティスを採用しなくてもよいため、始めるのが簡単である、ということです。 XPが求めるような技術レベルの変化は、いくつかのチームにとっては非常に骨が折れるものなのです。 2つ目は、スクラムの認定プログラムが、スクラムを教えたり宣伝する「認定スクラムトレーナー（CST)を大量にこの世に送り出したためです。 結果として、多くの会社において、「アジャイルになる」ということは「認定スクラムマスター（CSM)」の資格を取得して、スクラムを適用することだ、と考えるようになってしまいました。

アジャイル界隈での挑戦

スクラムはウィルスによって成長しました。現在問題点が明らかになってきています。事実、スクラムの創始者のひとりであるケン・シュエイバー氏は、Agile Collabのインタビューにおいてこう言っていました。

「スクラムを使用する組織の75%は、スクラムに対して望む利点を得ることには成功しないだろう。」[1]

なぜそうなるのかについては多くの見解があります。著者は、含まれるであろういくつかの理由を以下に記述します。

• 開発チームが直面する多くの問題が、実際にはチームの外部で起こります。例えば、一度にチームに対して多くのプロジェクトを与えることによってチームを過負荷にすること
• 多くの大規模組織は、ソフトウェアのデプロイメントメソッドが貧弱であり、それ故にソフトウェアを世に送り出すことを困難にしています。スクラムが妨害事項を明らかにする一方で、彼ら自身ではそれを解決できず、スクラムそれ自体はどのようにそれを解決するかの指針も持ち合わせてはいません
• 多くの組織ではスクラムが要求するような機能横断的なチームを作ることは難しい。特定のスキル、例えばレガシーコードに関する知識をもった人や特定の専門分野をもった人たちはしばしば複数のプロジェクトのかけもちをすることを要求され、スクラムモデルのパワーをそいでしまう
• スクラムに不慣れな多くのチームが、製品開発フローの原則を教えられていません
• スクラムはもともと同一場所にいるチームのためのものとして設計されましたが、しばしば分散したチームでの開発を行っている

多くの熱狂的なスクラムファンは、組織がスクラムを利用した成功を経験していない本当の理由は、組織がそれらの問題を解決するのに必要な訓練や動機づけをまったくしていないからだ、と主張します。

原因が何であろうと、問題は残り続けます。この問題を解決するために、アジャイルに関する2つの他の方法が生まれました。それが、「リーンソフトウェア開発」と「ソフトウエアエンジニアリングのためのカンバンシステム（もしくは略してカンバン）」です。 これらのメソッドは双方ともにスクラムで行っていた場合に組織が抱えていた問題に対して直接的に取り組みます。 これが、私が5年前にリーン、3年前にカンバンに取り組み始めた理由です。

リーンソフトウェア開発

リーンソフトウェア開発は「リーン生産方式」の原則と製品開発手法がソフトウェア開発に適用可能であるという理解に基づいています。もちろん、プラクティスは異なりますが、マインドセット、考え方は同じです。

その起源は1990年代中盤のBob Charetteの記事にさかのぼります。 そして、メアリー・ポッペンディークとトム・ポッペンディークの本（最初の本は、「Lean Software Development, An Agile Toolkit」で2003年に出版されました)によってポピュラーになりました。 リーンソフトウェア開発は、無駄を省く（顧客にとって価値がない努力はしない）、全体最適（concept to cash)、素早い出荷、品質の作り込み、人に対する尊敬、絶え間ない改善、そして必要になるまで判断を遅らせる、といった考え方に基づいています。

Don Reinertsenの周り[2]から別の流れが起きました。 Reinertsenは、システムの中をどのように仕事のフローが流れているかを見ること通じて、人々が働いているシステムの評価や、その中にいる人達のスキルの育成や、仕事の滞在時間を観点としてリーンにアプローチしました。「フロー」によって彼はどこに遅れが生じるか、どこに大きなキューが生じるか確認することを意図していました。

どちらのアプローチを好むかにかかわらず、開発組織の内外の問題をどのようにして解決するかに関しての洞察を提供することは有用なことです。 フローのモデル（価値をより素早く届けるために、開発パイプラインの少しの小さなことに着目する）は、あなたのソフトウェア開発のバリューストリームを向上させる1つの方法は、開発チームは同時に複数の仕事を行うことを避けることだ、ということを示唆しています。 同時に多くのことをやっていたが故にどれだけ多くの開発チームが壊れてしまったかということを考えれば、直感的に分かるでしょう。

カンバン

カンバンはリーンと制約理論の双方に基づいています。約5年前にDavid Andersonによって作られ、関心が高まっています。[3] カンバンはいくつかの基本的な原則の上に成り立っています。 まず1つ目は、組織がアジャイルをはじめるために、一度に大きな変化を経験することを要求することは逆効果であるかもしれないということです。 人々に対して新しい役割や仕事を採用しなければならないことを異なった方法で伝えることは、しばしば組織の中に変化に対する恐れを創りだしてしまいます。以前の仕事のやり方が捨てられてしまうことによって、人々は自分たちの価値が下がったというように感じてしまいます。

アジャイルムーブメントの最初の数年間は、スクラムは既にあるチームに導入され、開発者やテスターやアナリストたちは変化を望んでいました。しかしもはやそのようなことは現状では、たぶん別に遭遇する困難のために、当てはまらなくなっています。

多くのアジャイリストたちは、この大量な変化を克服する方法はトレーナーやコーチを雇うことだ、というでしょう。しかしながら、別のアプローチによって、それほど破壊的ではない方法で、スムーズに最終的なゴールに向けて移行することができるかもしれません。

カンバンの本質はあなたがそこで3つのことから始めることです。

• あなたのゴールは何か、開発者がある時点でどれだけの数のプロジェクトで働くかについて、ステークホルダーと合意を結ぶこと
• バリューストリームマップによって、開発プロセスを視覚化すること。 「バリューストリーム」とは段階の流れで、コンセプト→定義→構築→デプロイ→利用の順に遷移します。どうやったら仕事がバリューストリームを移動するかについては明確に定義してください。これがとても重要であるのは、それが管理者がこれらのアクションがどのようにチームに作用するのかを分かることができるためであり、また、これらの明示的なポリシーに関しての議論が学習を加速させることができるためです
• 各ステップにおいて行われている仕事の量（WIP）を管理すること。 特に、チーム（と管理者）は仕事が後退してしまう場所を探す必要があり、それから、どうやって問題を取り除くのかについて理解する必要があります。この明確さが、チームが遭遇する妨害事項を解決するための洞察を提供してくれるのです

Corey Ladasは、カンバンをスクラムフレームワークに組み入れることで、「Scrumban」と呼ばれるハイブリッドな方法を作り出しました。 これはスクラムチームにカンバンを適用する際に有効な方法になっています。

ビジネスアジリティの達成:どこから始めるべきか

それでは、あなたはどこから始めるべきでしょうか？それはあなたがどんな状況にあって、どうしたいのかにかかっています。 私の経験では、パイロットプロジェクトからアジャイルメソッドの適用を始めることは常にベストなわけではない、と思います。 車のエンジンのように、チームのメソッドは問題ではないかもしれません。もし改善が必要だとしても、完了したソフトウェア全体のコンテキストをみて、それから改善できることを選択することが望ましいのです。 以下の2つを推奨します。

• バリューストリーム全体を見るところから始めること。どこに課題があって、何を改善しなければならないか？ これは、チームの範囲を超えてあなたがコミットする、ということではなく、そうすることで、チームの進捗がビジネスの進捗やビジネスアジリティの実現につながるようなヒントを得ることができるだろうからです
• チームにスクラムかカンバンを選択させてください。彼らは直感的に自分たちにとって最良なのはどちらであるか分かるでしょう。人を尊敬する、ということは、仕事のやり方を彼らが選ぶことを許すことです（もちろん、それはビジネスのコンテキストの範囲でですが・・・）。

全体のコンテキストを考えることは、「アジリティのスケーリング」と「大規模でのアジリティ」との差でもありますが、それについては別の記事にします。

もしカンバン、リーン、スクラムそしてXPについて、より詳細を知りたければ、Net Objectivesのリソースページにアクセスしてみてください。 http://netobjectives.com/resources

そして、以下の2つのサイトでは、これから開催されるカンファレンスを含め、さらに豊富な情報を見ることができます。 http://www.leanssc.org http://www.kanban101.com