BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル リーンとアジャイル: この組み合わせは天国か、それとも矛盾か

リーンとアジャイル: この組み合わせは天国か、それとも矛盾か

原文(投稿日:2009/2/13)へのリンク

ええ、私はわざと挑発的にしようとしています。そうです。非常に特殊な方法で、私はこの質問の後ろの半分は本当だと信じています。

リーンアジャイルはソフトウェア開発の世界の中で1つの言葉になっているように見えるので、これは意外なことかもしれません。だから、おそらくいくつか抗議が寄せられることでしょう。

私は、10年以上にわたって、Mary Poppendieck氏とTom Poppendieck氏を知っています。私たちは、ミネアポリスの世界で1番大きなObject Technology User Groupの友達であり、仲間です。Tom氏はセントトーマス大学 (バージン諸島ではなくミネソタにある大学。冬はあまり過ごしやすいところではありません) の私の学生でした。Tom氏は、オブジェクトに関する私の本の技術的なレビューワーの1人でした。

彼らの本が私の本よりかなりの割合で多く売れたという事実を別にすれば (このことで彼らのことは決して許さないでしょう)、その本の内容とアイデアにただ尊敬と称賛を感じるばかりです。彼らの本は非常に優れた論文であり、その内容はソフトウェア開発者がどこででも学び、適用すべきものです。たぶん、アジャイル開発者も含まれます。

では、何が問題でしょうか?

要するに、リーンとアジャイルは、根本的に異なる世界観に基づいています。従って、必然的に重大な点で対立することに気付くでしょう。

次の段落において、対立する世界観を示し、対立が起きている点を1つ説明します。そして、どうやってこれら2つの見解の折り合いをつけるのかを提案します。

リーンの世界観 = 生産

リーンの世界観が生産の世界観だという私の主張を紹介するために、「Lean Software Development, An Agile Toolkit」(邦題:リーンソフトウエア開発~アジャイル開発を実践する22の方法~)から数ヶ所を引用します。

Jim Highsmith氏が序文で述べました。「... Mary Poppendieck氏とTom Poppendieck氏は、リーン産業のプラクティスを新しい段階にしました。彼らはソフトウェア開発にこれらのプラクティスをどうやって適用するのか私たちに教えてくれます。」さらに、「... 産業的な場面からソフトウェア開発へリーンの技術を適用することに関して、豊富な情報を与えてくれます

Ken Schwaber氏の序文にいくつかのフレーズがあります。「産業的プロセス制御」、「アジャイルプロセス」、「製造業と製品開発のMary氏の経歴

序文のページxxiiから、「適用を誤ったメタファの危険を認識する一方で、ソフトウェア開発が製品開発と同様であり、製品開発アプローチの変化がどのように製品開発プロセスに影響を与えるのかを確かめることにより、ソフトウェア開発産業は多くのことを学べると私たちは信じています。

生産とプロセスの語彙やメタファがこの本全体を通して使われています。生産に関する19世紀のアイデア (例えば、テイラリズム (Taylorism)) は明らかに拒絶されていますが、進んだ生産モデル (例えば、トヨタ生産モデル) は同じくらい明らかに適用されています。

特定のアジャイルプラクティスは、生産への貢献の点から評価されます。特定のアジャイルプラクティスがリーン生産プロセスモデルと対立しているような場合、そのプラクティスは修正されるか除外されなければなりません。

リーンは全部がプロセスについてではありません。例えば、リーンの7大原則があります。

  • 無駄をなくす
  • 学びを拡大する
  • できるだけ決定を遅らせる
  • できるだけ速く納品する
  • チームに権限を与える
  • 完全性を確立する
  • 全体を見る

最初の1つだけが明らかにプロセスと生産に結びついています。

これらの原則は、リーンの他のすべての面で明らかに生産の世界観を超越する方法を提案します。この記事の最後の部分で、この可能性について語ります。

アジャイルの世界観 = 理論構築

私は、アジリティの発案者や提唱者の多くの友人たちと付き合いがあり、私自身を仲間としてくれるすばらしい特権を持っています。私は、アジャイルの哲学的基盤に関して次のアイデアを検討し、それらが一致していることに気付きました。ただ1人、Alistair Cockburn氏がこのアイデアを活字にしました。
 

Cockburn氏の「Agile Software Development」(邦題:アジャイルソフトウェア開発) の付録B、227-239ページに、「Programming as Theory Building」(理論構築としてのプログラミング) というPeter Naur氏が1985年に書いた記事が転載されています。

Naur氏は、ソフトウェアを開発する行動が生産活動、「プログラムとある特定のテキスト」を生産することとして誤ってとらえられていると論じています。彼は、経験的データで開発の生産モデルと矛盾するものの例をいくつか挙げています。それには、完全さと厳密さが定められていないドキュメントによって、初期の製作にかかわっていない人たちにプログラムを理解するよう伝えることは、もしできるとしても、ほんの少しだという事実も含まれます。

Naur氏が掲げる理論構築は、以下に対する個人および集団の努力です:

  • 世界を理解する。
  • ソフトウェアが世界によってどのように形作られ、その世界にどのように統合されるかを理解する。
  • ソフトウェアの重要な点とその点をどのようにもっともよく表現できるか (コーディングできるか) を理解する。
  • 最初の3つを正しく理解したかどうか知る。

理論構築に関係する注目すべき活動には以下のものが含まれます。数多くのストーリーを話す。アイデアを探る。物事がうまくいくかどうか見ようとする。理解を確認する。理解を思い起こさせるもので物理的な空間を埋める。総合的にますます増やしていくようにこれらのことを繰り返し行う。

まるでアジャイル環境のように見えるかもしれませんが、製造環境に少し似たところがあります。

理論を所有することに関するRyle氏のアイデアを引用していること以外に、Naur氏は理論構築の基礎を成す一連の原則をはっきりと説明していません。もし彼が説明したなら、それらの原則は、ほぼ確実に、シンプルさ、コミュニケーション、勇気、フィードバックというXPの価値と一致していたでしょう。

対立する世界観

リーンは、ソフトウェア開発を概念から製品へと動くプロセスと見なします。リーンは、最適化の伝統的な (例えば、テイラリズム) 試みよりも、完全に異なった方法と完全に異なった価値にもかかわらず、そのプロセスを最適化したいと考えます。

アジャイルは、この理論の副産物である表現の結果により、世界の共感理論を構築するためのプロセスとしてソフトウェア開発を見なします。

2つの側面の基本的な世界観は劇的に異なるので、対立が起きることは避けられません。これらの対立は、通常ツールとプラクティスのレベルで現れます。

例えば、プロダクトバックログです。

アジャイルは、ユーザストーリーに基づいてモジュール化した作業という考え方を前提にします。ユーザストーリーは、「顧客がシステムにしてほしいことの1つ」(Kent Beck氏) です。

ユーザストーリーは、顧客やビジネスという別名を持つユーザから始まります。ストーリーは、特に、大規模プロジェクトの初め、または、ゴールが企業全体を「アジャイル化する」ものである場合、それらが実装されるよりもずっと速く作り出せます。

ほとんどすべてのアジャイルプロジェクトは、実装するストーリーをまとめてプロダクトバックログを作ります。このまとまりは、かなり大きくなることもあります。私は、何百ものストーリーからなるプロダクトバックログを持つプロジェクトを見てきました。

リーンはプロダクトバックログを眺めて、「在庫」と「ムダ」と見なします。Mary Poppendieck氏は、プロダクトバックログを廃止するか、チームの全体のベロシティと同じくらいのサイズにまで削減して最小限にすべきだと発言しています。

アジャイルは、プロダクトバックログを新たな理論が断片的に見えるものと見なします。たとえ、断片的な考えが壁いっぱいのストーリーカードとして物理的に明らかであっても、それは在庫ではありません! 各カードが詳細な会話を (思い起こさせて) 呼び起こし、物事がどのようにうまくいくのか理解することによって、壁に貼ったカードが外部メモリの形で役に立ちます。

アジャイルは、非常に大きいプロダクトバックログがあり、そのバックログの構成が大量に動く場合にもっともよく機能します。この激しい動きは、ストーリーの本質に関する話し合いから生まれます。ストーリーの優先順位、理解されないストーリーに関する開発者からのフィードバック。予想より開発が簡単、または難しいと分かったストーリー。開発がさらに理解し易く、または、扱い易くなるようにリファクタリングしなければならないストーリー。完成したストーリーをユーザが受け入れてからのフィードバック。

結局のところ、激しい動きは小さくなり、プロダクトバックログは安定したものになります。新しいストーリーの追加はほんの少しに減って、ストーリーの優先順位付けが名目上だけ変更されます。この時点で、プロダクトバックログをますます在庫として見なしたくなります。

誘惑に耐えなさい。バックログは、今もなお理論の物理的な現れです。それは、行われた開発作業のすべてとって、絶対的に必要な背景を提供します。

バックログは、映画制作の台本の編集者と技術的なアドバイザーとしてソフトウェア開発のために同様の重要なサポートを提供します。1つの場面に注目している場合、前の場面の最後のフレームで、ヒーローが赤ではなく、青のシャツを着ていることを忘れるのは簡単です。空間に爆発の音が聞こえないということを忘れるのは簡単です。同様のミスは、ストーリー実装に取り組んでいるときに起き、台本と重要な点の誤解を修正するよう提供されるのは背景であるプロダクトバックログです。

私がコーチをしたすべてのアジャイルプロジェクトにおいて、スプリントトラッキング情報の隣に、ストーリーカード形式で壁にプロダクトバックログを示すことを私は主張しました。即座に注目すべきストーリーとプロダクトバックログのストーリーの両方が容易に見えるところで、デイリースタンドアップミーティングが行われました。プロダクトバックログは、計画ゲームとふりかえりのたびに詳細を再検討され、話し合われました。それは、ただ私たちの共同理論の状態に関連する皆の気持ちを新たにするためです。

この例の重要な点は、あなたの世界観は「物事」を解釈するのに必ず影響するということです。プロダクトバックログのような単純な成果物は、あなたの世界観に基づき、まったく異なる現実、目的、価値、そして、機能性を持ちます。この場合、「生産の世界観」は、実はアジャイルソフトウェア開発に害を及ぼすと解釈される結果になります。

私は、この議論を支持するために、かなり一般的な議論をし、単純な例を挙げています。これは、紙面の制限の結果であり、例がないからではありません。

和解

結婚は無上の喜びです。誤解、口論、対立するゴールを除いて。リーンとアジャイルは、そのような美しいカップルを作ります。この結婚は、間違いなく救えるでしょうか?

もちろん救えますが、3つの前提条件があります。1つはリーン、1つはアジャイル、そしてもう1つは両方に対して。

リーンは「生産のメガネ」を外し、リーンの7大原則を含む全体的な視野から、アジャイルとアジャイル開発プロセスの要素を見る必要があります。プロダクトバックログが「無駄をなくす」原則よりもそれ以上のものから評価される場合、「学習を拡大する。できるかぎり後で決定する。チームに権限を与える。完全性を確立する。全体を見る」ための貢献は明らかでしょう。

アジャイル実践者たちは、幾分皮肉なことに、まったく同じことをしなければなりません。アジャイル実践者が何をするかについて話しているのを聞くときに、彼らの語彙、メタファ、そしてプラクティスの実行は、生産の代替モードとしてアジャイルの考え方を反映します。Naur氏と理論構築に関してアジャイル仲間に聞いてください。あなたは彼らのぽかんとした顔を見るでしょう。

リーンとアジャイルは、文字通りに機械的な方法でツールとプラクティスを適用するのをやめなければなりません。ツールとプラクティスは、価値、原則、信条の表現以上のものではありません。それらは、たった1つの可能な表現ではありませんし、もっともよい表現でもないかもしれません。なぜプラクティスとツールがそれらのものなのか理解するまで、また、理解しなければ、どちら側も「使って、適応して、超越する」ために、それぞれの創始者の忠告を理解することはできないでしょう。

AgiLean (タブロイド、ベニファー、ブランジェリーナを考えてください) は一目ぼれのケースでした。ハネムーンは、アイデアを融合する新しい方法を見つけるウキウキするような楽しい時間でした。しかし、その時間は過ぎました。この結婚を生き残りたいならば、どちらも表面的な魅力への未練を断ち切る必要があります。この段階では、対立が必然的に起こりますから。

この記事に星をつける

おすすめ度
スタイル

BT