BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル アジャイルの限界

アジャイルの限界

ブックマーク

原文(投稿日:2010/07/19)へのリンク

まず次の点をはっきりさせたいと思います。私はアジャイルソフトウエア開発がいつでもどこでも適用できると本当に信じています。究極的にはアジャイルはフィードバックと学習の変更が基礎にあります。したがって、アジャイルの原則はどんな環境でも適用できます。私たちは試行錯誤と学習を繰り返すからです。

しかし、昨年くらいから私は、非伝統的な環境下でアジャイルを適用しようとしているいくつかのチームと一緒に働きました。これらのチームが直面した問題は、アジャイルが適用できないことでもフィードバックのサイクルが始めからうまくいかないことでもありません。アジャイルのスイート・スポットの外では、アジャイルの技術を適用するにはさらなる障壁があり、コストがかかること。これが、彼らが直面した問題でした。これらの障害物はアジャイル自体の適用を妨げるものではありませんが、アジャイル適用のコストを引き上げます。

私が一緒に仕事をしたチームでは、実際の顧客とはかけ離れた環境で仕事をしていました。彼らは高度に階層的な組織構造の中で、非オブジェクト指向言語を使って仕事をしていたのです。

アジャイルのスイート・スポット

アジャイルのスイート・スポットとはソフトウエア産業全体の中でアジャイルの手法の経験が最も豊富な場所のことです。通常はJavaまたはC#の環境で、組み込みではなくウェブアプリケーションを最終的なエンドユーザや実際の顧客とかなり近い環境で開発します。これがアジャイルのスイート・スポットでの開発です。

チームの大きさはふつう、かなり小さいです。すべてで12人にも満たないでしょう。しかし、大きなチームでの経験も蓄積され続けています。チームの中には他の場所にいるメンバもいるかもしれませんが、チームの中核はエンドユーザのかなり近くで仕事をします。

まだ開発が始まっていないプロジェクトがアジャイルのスイート・スポットだと主張する人も多いでしょう。しかし、私の意見は違います。私はいつも既存にシステムの方が簡単にアジャイルを適用できるということを見てきました。重要なのは、今では新しいプロジェクトでも既存のシステムでもアジャイルで開発するための十分な経験が蓄積されているということです。

アジャイルのスイート・スポットの中だけでアジャイルが実践されるわけではありません。アジャイルについての素晴らしい知識が存在するのがスイート・スポットなのです。このスイート・スポットには好循環が存在します。すなわち、多くの経験が多くの成功をもたらし、その成功がまた経験を得る機会を生み出します。

エンジニアリングの実践

チームはアジャイルの導入をどこから始めるべきかという問いに対して私の答えはいつも同じです。すなわち品質です。もしチームがイテレーションの終わりに、ひとつの仕事が完成したときにバグがなく配置の準備ができている、ゴールドシールが張ってあるような品質を実現できなかったら、信頼できるイテレーションスケジュールを組むことは不可能になっていきます。

アジャイルのスイート・スポットの中で活動するチームには豊富な知識やケーススタディの蓄積があります。そして、最も重要なのがツールです。Javaを例にとりましょう。テストのためにはJUnitJMockFITが使えます。EclipseIntelliJはリファクタリングが簡単にできる強力な開発環境を提供してくれます。また、これらのツールの使い方を説明する多くの書籍や雑誌記事、ブログがあります。

しかし、例えばCやCOBOL、SAPなどを使っているチームにはこのような環境は広がっていません。理論的にはこれらの言語でTDDやそのほかの実践が適用できない理由はありません。究極的に言えば、すべての計算機械言語はチューリング互換であり、チューリングマシン向けのテストフレームワークを想像することは可能です。したがって、TDDを実践することは全く問題ありません。

しかし、これらの言語はスイート・スポットの外にあります。これらの言語を用いたアジャイルの実践について知識の蓄積がほとんどありません。確かに、COBOLUnitABAP Unit(SAP向け)がありますが、これらの使用例はほとんどありませんし、フォーラム上にも使い方の質問はほとんどありません。また、利用できそうな書籍やケーススタディもありません。要するに、これらのツールを効率的に使う方法はコミュニティで共有されていないのです。

これらの言語はその言語独自の課題を持っています。これらの課題のいくつかは技術的なものであり、また文化的なものもあります。例えばSAPの開発者はプログラミングという考えを遠ざけます。SAPでは"構成"という言葉を使います。確かに、多くのSAPはシステムのオプションやテーブルを通して構成します。しかし、これはプログラミングの異なるひとつの形態に過ぎません。

現代的なCOBOLは多くの機能を含んでいます。例えば、オブジェクトです。これらの機能を使えばJavaのようなスタイルの単体テストを提供します。しかし、主要な既存のCOBOLシステムはほとんど本質的にレガシシステムであり、これらの機能は後になって実装されたものです。したがって、これらの機能を利用できる開発者はほとんどいません。

伝統的なCOBOLではダイナミックリンカを使います。これは自動のTDDを実施したい欲望にかられる機能です。しかし、レガシなコードベースが邪魔になります。レガシコードはそれ自身は邪魔になりませんが、問題はこれらのレガシコードがデータハイディングや、凝集度や結合度のような概念が確立され、広く利用される前に開発されていることです。

JavaやC#のように活発なオープンソースコミュニティが何らかのツールを提供してくれることもありません、JavaとC#とは違って developers, COBOLやSAPの開発者が自分の都合がいいときにツールを作成できるような開発環境を持つことは到底不可能です。そして、そのような活動をオープンソースとしてリリースすることは組織が許しません。

さらに複雑なのは、COBOLやSAPの古いシステムの場合、特定のベンダに束縛されてしまうことが課題になります。例えば、ソースコード管理システムをより良いCIのサポートがあるシステムに置き換えることすら簡単にできないかもしれません。

アジャイルの観点から見た場合これらの言語の中では、おそらくCが最も前途有望かもしれません。なぜなら、(a) Cの開発者はオープンソースコミュニティで活発に活動していますし、 (b) C++の単体テストツール、例えばCuteAerynを借りてくることができるかもしれないからです。しかし、Cの場合もその使い方に関する知識が蓄積されていません。

つまり、C、COBOL、SAPでアジャイルの実践は可能だが、知識や経験の蓄積がないということです。これらの言語でアジャイルを実践したいと考えている組織は、新しい分野を切り開き、新しいツールを作り、知識を蓄積するために高いコストを払わなければならならいでしょう。既存のツールをどこからかダウンロードすることはできませんし、経験のあるコンサルタントを雇うこともできません。

テスト駆動開発について議論するにしろ、受け入れテスト駆動開発や、継続的統合、リファクタリングやその他のエンジニアリングについて議論するにしろ、上述したことはすべてに当てはまります。レガシ技術にはアジャイルを適用できないわけではありません。しかし、実践しようとすればコストと困難が増大します。こうした高い壁を乗り越えることもできるかもしれませんし、現に乗り越えた組織があるかもしれません。しかし、それは極端な例で、ほとんどの組織は高すぎる壁があることを認識しただけです。

マネジメントの実践

エンジニアリングリングの実践ではアジャイルには現実的な限界があります。マネジメントの実践には一見する限界がないように見えます。結局、スタンドアップミーティングや短いイテレーションには技術が必要ないからです。

ツールの補助なしでは、いつひとつの作業が完了したのか知ることは困難です。ひとつの作業が完了しなければ、意味のある固定長のイテレーションの実践を維持するのは不可能です。イテレーションからイテレーションへ作業を続け、実装とテストとデバックとテストを繰り返しても、実際の仕事が完了する保証はありません。こういう順で作業をすると、イテレーションを長くしようとする圧力が高まり、その結果、短いサイクルとそこからの定期的なフィードバックが台無しになってしまいます。

規律が複数あり、役割が交差しているチームをマネジメントするのもアジャイルの実践のひとつです。専門の領域だけで仕事をする人よりも、次にやらなければならないをする人を抱えている方が、優先度の高い作業を確実に終わらせることができ、ワークフローを平にすることができます。しかし、これもレガシシステムではとても難しくなってしまいます。

長い間、レガシシステムと一緒に仕事をしているメンバは新しい手法を学ぶこと、または古い手法をよみがえらせることに熱心です。しかし、古い技術を使って働くのに気が進まなない若いメンバはそうではありません。CとJavaのように互いに近い関係にある技術でさえ、そのまま引き込まれてしまうのを恐れて、身につけたがらないメンバを私は見てきました。

COBOLやCのレガシな性質では助けになります。ひとつの大きなシステムについて知り尽くすには、何ヶ月、あるいは数年の経験が必要かもしれません。経験豊富なCOBOL開発者が飛び込んで、全く知らないシステムの一部を一晩で改修するのに期待することは非現実的でしょう。

SAPの場合、状況はさらに複雑です。SAPは共通のものとしてシステムを販売していますが、実際はSAPのモジュールごとに必要とされる実装技術は異なります。SAP HRで必要な技術はSAP Financialとは違います。SAP Financialに必要な技術はSAP Logisticsに必要な技術とは違います。そしてこれらすべての技術は、基幹部分に適用できるCOBOLに似た言語であるABAPを使うのに必要な技術とは異なるのです。あるSAPモジュールの開発者に別のSAPモジュールの開発を頼むことは、C#の開発者にErlangの開発を頼むのと同じようなことです。

さらにSAPがそのエコシステムによって実行されるビジネスモジュールになってしまうことも複雑さの一因です。ふつう、SAPの開発プロジェクトはその企業のIT部門の中核能力ではありません。したがって、複数のコンサルタント会社からコンサルタントをつれてきて、システムの個別の部分を実装させます。コンサルタントやコンサルタントに雇われた実務者は自分たちの中核のSAP技術、自分たちに任されたSAP技術でのみ作業をすることを望みます。他のモジュールまで手を出そうとはしません。

このように、開発者たちがSQL、HTML、PythonやUnixを学習しながら成長していく可能性があるJavaプロジェクトと比べれば、いくつかの理由によってSAPでは複数の機能を持つチームを構築するのは難しいです。

でもスタンドアップミーティングは実践可能でしょう、とあなたは言うかもしれません。ええ、おそろく可能かもしれません。しかし、賃金を低く抑えるために、多くの古くからある作業室ではメンテナンスの実施を地理的にも組織的にも分散させています。したがって、SAPのコンサルタントは不足しがちです。マイル数がたまる一方で、移動するために数日や半日をつぶしてしまうことが常にあるからです。このような状況ではスタンドアップミーティングに都合がいい時間を見つけるのは難しくなります。そのような時間が見つかったとしても、コンサルタントは携帯電話を手にして座ってしまうでしょう。

それだけではありません。多くの巨大組織に取り付いているコストが意味するのは、"あなたはなにを達成したのか?"という問いに対する最も正直な答えが"賃金を請求できる作業時間として8時間費やしました。"という答えになってしまうことです。このような文化では、人々はアウトプットや達成に注目するのではなく、インプットとコストに注目するようになります。

レガシシステムのもうひとつの特徴は実際の顧客とチームの間にある断絶の度合いです。メインフレームシステムは現代的なフロントエンドシステムによって顧客から隠されていることがあります。これはユーザに緑色のスクリーンを見せないようにするためです。

レガシシステムを覆うレイヤ化された技術によって、チームはビジネスから隠され、開発者からはビジネスが見えなくなります。これでは、価値がどこにあるのか理解するのはとても難しくなります。そして、ビジネスが求めるものやどんなものを実装すれば最低限動作するのかについても理解しにくくなります。

リリース

最後に、エンジニアリングにもマネジメントにも分類される実践が残りました。それは、頻繁なリリースです。LinuxやWindowsの世界では、リリースは簡単にできるようになりました。しかし、メインフレームやSAPシステムではリリースはまだ高価な作業です。これらのシステムを操作することは組織にとって致命的です。したがって、ひとつひとつのリリース作業が大きなリスクを伴いますので、アジャイルのようにリリース回数を増やすのではなく、リリースを少なくする圧力が働きます。

システムを多重化することでこのような問題を回避しているサーバ環境もあります。ひとつのサーバが動作している間、ふたつ目のサーバで次のリリースの準備をします。新しいバージョンのソフトウエアに変更するには、新しいサーバの方へスイッチすればよいのです。そして、この方式でバージョンアップを繰り返していきます。しかし、このような方法はメインフレームや大きなERP/CRMシステムの場合、ハードウエアやライセンスのコストに阻まれてしまうでしょう。

他の言語は?

ここまで、C、COBOL、SAPに着目して議論してきました。しかし、他の言語では状況が大きく異なると考える理由はありません。実際、多くの場合、PascalやPL/1はCとCOBOL比べてインストールされている環境が少ないでしょう。したがって、利用できる知識も少ないので、より多くの困難があると思います。

OracleアプリケーションスィートはSAPよりも利用されていますが、合併と買収の産物です。各アプリケーションはそれ自体として扱う必要があるかもしれません。複数の技術を扱うチームを構築するのは困難です。

現在のアジャイルの知識の蓄積状況において、境界に位置する言語はC++または、Visual Basic 6かもしれません。C++にはCI、TDD、リファクタリングを実践するには十分な言語ですし、ツールもそろっています。しかし、Javaに比べれば半分くらいの使いやすさです。さらに新しい言語はもっとしっかりサポートされていますが、オブジェクト指向でない古い言語にはそうしたサポートはありません。

手続き型言語でアジャイルを実践する場合、動的ディスパッチ機能がないので、常に複雑になります。“IF x THEN do Y”という形式でどのくらいの手続き的なコードが書かれているのか簡単に忘れてしまいます。オブジェクト指向や動的言語では、テスト目的で制御フローを変更するのはとても簡単です。

価値はあるのか?

上述してきた困難はどれもアジャイルを妨げるものではなく、どれもアジャイル適用のコストを増大させるものです。これらがまとまって、巨大で乗り越えるのに大きな費用がかかる障壁になるのです。こうなると、早かれ遅かれ次のような質問が出てくるのが自然です。すなわち、そのコストは利益を上回るのか。

ここではっきりとした答えを示すことは不可能です。場合によりけりだからです。これを考える上で、他のことよりも先に理解しておく要因がふたつあります。

1. そのシステムは利益になったと思えるほど長い間、現役でいられそうか?

新しいSAPシステムが毎日、構築されインストールされていますので、数年は現役でいられると思います。レガシなCやCOBOLシステムの場合、組織はそのシステムの平均寿命見積もっておく必要があります。システムによっては、現役でいられない場合もあるはずです。アジャイルにはのもろもろの広告やら保証やらがありますが、次の2年か3年でシステムの寿命が終わりになるのであれば、それ以上なにかする価値はないと思います。

2. 現在のプロセスはどれだけしっかり動作しているか?

対象のシステムが20年かそれ以上存在すること、そして、そのシステムを育てることが組織的に許されていれば、そのシステムは目的に合致してます。要求されたものを提供できるレガシシステムとチームがあるのなら、なぜ変える必要があるのでしょうか。

とはいうものの、ビジネスの環境や企業戦略や技術が変化するなかで、現状維持を続けるのは実行可能な選択肢ではないかもしれません。もし組織がメインフレームの開発環境では要求された変更を所定の時間内に提供できないということに気付いた場合は、何らかの対策が必要です。

アジャイルは万能薬ではありません。アジャイルはメインフレームの作業室の改善を支援するかもしれませんが、その利益は限られています。C、COBOL、Pascalで新しいシステムが作られることがほとんどないのには理由があります。新しい言語がもっとさまざまな機能を提供してくれるからです。組織は最終的には新しい技術を導入する必要があります。

結論

アジャイルはいつでも適用可能かもしれませんが、適用することが常に適切であるとは限りません。もちろん、ウォーターフォールが自動的に正しい解決策になるということではありません。可能性はあるかもしれませんが、私個人は想定どおりに進んだウォーターフォール開発を経験したことはありませんし、それが可能だとも思っていません。

COBOLやその他の言語、環境ではアジャイル開発ができないと言っているわけではありません。私はできると思います。しかし、その場合、私たちが知っているアジャイルにはならない、コストがかかる、ということを言っているのです。実際には新しい知識に基づく新しいアジャイルを開発しなければならないでしょう。

この記事の読者は私が解説してきた障壁を克服したケースを知っているかもしれません。- 私はそのケースについて聞いてみたいです。 - しかし、一羽のツバメの到来が夏の到来になるわけではありません。総合的かつ全体的に見て、これらの環境ではアジャイルを適用方法についての知識や理解が不足しています。ひとつやふたつのケーススタディでは不十分です。何十という事例が必要です。COBOLを使ったTDDのプレゼンテーションがひとつあるだけでは不十分です。この件について議論するためのメーリングリストが必要です。トレーニングコースや書籍も必要でしょう。

アドバイスをいくつか

アジャイルを実践したいと思っているアジャイルのスイート・スポットの外にいる組織が増えていますので、いくつかのアドバイスをしてこの記事を締めくくりたいと思います。

この道を進むつもりであれば、あなたは新機軸を開いているということを忘れないでください。歩みことができるすでに切り開かれた道はありません。間違えた場所で曲がってしまうこともあるでしょうし、行き止まりに突き当たることもあるでしょう。これらのことはすべてコストになります。

一夜漬けでアジャイルを適用できると期待しないでください。アジャイルという魔法の粉をプロジェクトに振りかけてもうまくいきません。きつい仕事とお金が必要です。

スイート・スポット内で使えるツールを開発したことがある人を見つけて雇いましょう。COBOLプログラマがTDDを学ぶよりも、JavaプログラマがCOBOLを学ぶ方が簡単です。多くの開発者がnUnit、JMock、CruiseControlを使ったことがありますが、そのようなツールを作る技術を持っている開発者はほとんどいません。そのような開発者は現代的な実践と古い技術の断絶を乗り越えることができますが、安くはありませんので節約はできません。

心を開いて努力とツールを共有してください。インターネットに事例を公表して、新しいツールをオープンソースで利用できるようにしましょう。また、一緒に開発してくれる仲間、テストをしてくれる意思のある仲間を見つけましょう。開発者にしろ、テスト担当者にしろ、採用することにはあなたの未来にとって利益があります。第一に人々はあなたを尊敬するでしょうし、第二にあなたのツールを知っている人もいるでしょう。

スタンドアップミーティングやイテレーションのようなマネジメントの実践は簡単で、アジャイルのなかの2、3の実践でしかありませんのでアジャイルと呼べるものではありません。エンジニアリングの実践による支援がない限り、マネジメントの実践は限られた価値しか持ちません。したがって、エンジニアリングの実践から始めてください。マネジメントの実践を始めるまえに、コードと品質を改善してください。エンジニアリングの実践だけを採用することで、マネジメントの実践が重要な相違点を作ります。

最後に、この実践をプロジェクトや戦略だと思わないでください。これは新しい生き方です。プロジェクトや戦略は終わります。アジャイルを実践することは、常に変化と改善を続けていくことです。

この記事に星をつける

おすすめ度
スタイル

BT