InfoQ

News

50人の開発者に聞きました: アジャイルについて、あなたのCIOに知ってもらいたいこと

作者 Mark Levison, 翻訳者 畠山 貴 - (株)永和システムマネジメント 投稿日 2008年2月29日 午後11時53分

コミュニティ
Agile
トピック
リーダーシップ
タグ
Retrospectives,
Agile入門,
Culture Change,
マネジメント

あなたは自社のCIO(情報システム担当役員)へ、アジャイルソフトウェア開発の利点を説明しようとしているところだろうか?あなたの上司は第三者によるアジャイルの有効性の証明を求めているだろうか?そうだとしたら、CIOマガジンのEsther Schindler氏(source)があなたのためにその大仕事をやってくれている。50人以上のアジャイル開発者へ彼女はひとつの質問をした。「あなたの上司に、アジャイル開発についてひとつだけ理解してもらえるとしたら、あなたは何を伝えたいですか?そしてその理由は?(source)」開発者から返ってきた回答は以下の7つのカテゴリに分類された。

1. アジャイルはより良いソフトウェアをつくる

Sonic Innovations社の技術リーダ、Kelly Anderson氏は以下のように述べている。「低い品質にはさまざまなコストがともないます。お金に換算すると大変な額になるでしょう。アジャイルならより高い品質を達成できるので、そのコストを抑えることができます。」また、「ソフトウェアテスト293の鉄則」「基本から学ぶソフトウェアテスト」の著者Cem Kaner氏はこう記している。「アジャイル開発は、開発後半での仕様変更のコストを下げることができます。それにより、ステークホルダの要望の変化に、より容易に対応できるようになります。」

2. アジャイルなマインドセットは、開発プロセスという枠にとどまらない

Wizewerx社のMike Sutton氏は、アジャイルとは「仕事の方法」であるだけでなく「仕事についての考え方」でもあると言っている。「アジャイルは、今までは<これでいいか>と思っていた仕事のやり方に対して<本当にそれでいいのか>と疑問を投げかけます。それは組織と個人に対して、ムダ、非効率性、欠陥と向き合うという、痛みの伴う作業を強いることになります。」

3. アジャイルが変えるのは開発ワークフローだけではない

Esther氏は以下のように指摘している。「アジャイルは、開発プロセスを変えると同時に、会社の文化も変えてゆきます。組織への頻繁なフィードバックと、部門間のコラボレーションの増加は、組織が長らく放置していた問題へ取り組むことを余儀なくさせます。」

 また、頻繁なフィードバックは、顧客へのすばやい価値の提供と、提供した価値をベースとした顧客から開発者へのフィードバックを可能とします。iDIA Computing社のコンサルタントGeorge Dirwiddie氏はこう発言している。
「フィードバックを返すまでの時間をできる限り短くする必要があります。判断を下した時点から、正しさを検証するまでの時間を短くすることで、無駄な時間の浪費をずいぶん減らすことができるでしょう。」

4. アジャイルは「いい加減な開発」の免罪符ではない

 Deltacom社のQAマネージャ、Mike Emeigh氏は、アジャイルなチームはやみくもにコードを書いているわけではなく、きちんと要件定義や分析設計を行っていると指摘する。「彼らは分厚い紙束の作成に多くの時間をさこうとしないだけです。実際には、開発メンバーがシステムの要求を理解しないままにコードを書き始めることはありません。」

5. アジャイルは効果が表れるのを気長に待とう

TEKSystems社のサービス提供部門幹部、James Kricfalusi氏によると、アジャイル導入のメリットは、すぐには表れないかもしれない。氏は、目先のメリットを追いかけてアジャイルを採用するのではなく、以前経験したことのあるプロジェクトと同じような規模のプロジェクトへアジャイルを適用してみて、その生産性を比較することでアジャイルの有効性を検証することを薦めている。

6. アジャイルは銀の弾丸ではない

 <優秀さ>は、細心の注意と、細部への目配りを必要とする。優れた物を作ろうとするあらゆる試みには同様のスキルが必要となる。独立系のコンサルタントであり「The Art of Agile Development」の著者であるJames Shore氏はこう言っている。
「…チームには自律性(仕事に対して規律正しくあること)が求められます。また、アジャイルを身につけるためには、マネジメント層からのサポートと、それを習得するための期間が必要となります。…アジャイルな人々が大きな成功をおさめたとしたら、それは<優秀さ>に起因するものです。<平凡さ>からではけしてありません。」

7. プロジェクトの成功は人にかかっている

 Colosseum Builders社のオーナー、Miano氏はこのように言っている。
「アジャイルな開発は開発メンバーの人柄に大きく依存する傾向があります.... アジャイル開発に携わる人は、他のメンバーの突拍子もない言動などを許容できる心の広さを必要とします。」

また、ベテランのソフトウェアエンジニア、Steve Reiser氏はこう言っている。
「成功体験をともなう小さなリリースを何度も繰り返すことで、チームメンバーは自信をつけると同時に、リリースに対しての喜びを得ることができます。」

本稿ではアジャイル開発者からの回答のうちのいくつかを紹介した。もっと多くの回答を読んでみたい方は、彼女自身の書いた以下の記事を参照していただきたい。Getting Clueful: 7 Things CIOs Should Know About Agile Development..(source)

原文はこちらです:http://www.infoq.com/news/2008/02/agile_for_cio

ブックマーク
digg+,
reddit+,
del.icio.us+,
dzone+,
Hatena

No comments

返信

特集コンテンツ一覧

Typemock: その過去・現在・未来

Eli Lopian氏率いるTypemock社の過去・現在・未来について、インタビュー形式にて記します。

企業とSaaSの仮想化がもたらすのは、迅速性(アップ)だけではない

この論文では、仮想化やクラウドサービスの複雑なメリットと実世界における応用を検討します。さらに重要なこととして、Contegixが複雑な問題の解決に仮想化を実装している方法や、仮想化を使うべきではないケースについて詳細を提供します。

RubyのFiberを非同期I/Oに使うNeverBlockとRevactor

Fiberはユーザに試練を課すことなくこの考えを実装する有益な並行性ツールとして、ライブラリが2つあります。まさにこのためのソリューションとしてあるのがNeverBlockライブラリです。私たちはNeverBlockプロジェクトのMohammad A. Ali氏とRevactorライブラリのTony Arcier氏に話を聞きました。

拡張性に関する悪習慣

システムの保守容易性や拡張性を確保するためのベスト・プラクティスに関する記事は数多くありますが、この記事では避けた方がいい、いくつかの悪習慣(ワースト・プラクティス)を強調します。

トップスポーツチームの監督に教わる秘訣

この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。

事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

Agile2008チーム参加レポート - 帰国そして変化

Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。

SilverlightとJavaのインターオペラビリティ

マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。