|
[2011 年 8 月号] |
［レポート］
7月20日に江東区文化センターホールにて行われたAgile Conference tokyo 2011に参加してきました。
Agile Conference tokyo 2011 - イベントTOP
株式会社テクノロジックアートにより主催・運営されるAgile Conference tokyoは今回で3年目を迎えます。「回を重ねるごとに来場者数も伸びており、アジャイル開発がいよいよ日本国内で本格的に広がっていくのではないかという期待を抱かざるをえません。」と書かれているように、400名の定員に対して参加希望者が殺到して抽選制になるほどの人気で、特に、午前中のマーティンファウラー氏の基調講演の時には会場はほぼ満席の状態で熱気に包まれていました。
アジャイル開発プロセスはアジャイル開発宣言やScrum、XPといった開発手法が書籍等により広まったことで10年くらい前にわが国でも一時期ブームになったことがありましたが、その後いくつかの先進的な取り組みや成功事例はあるものの、日本において一般的な受託開発の分野においては今のところメインストリームの開発手法とはなっていません。しかしながら、今回の講演でも紹介されたように海外では着実に浸透して実績を上げてきており、開発生産性や品質の面で大きな成果をあげているようです。特に、欧米からのオフショア先として知られるインドではアジャイル開発プロセスを積極的に取り入れる体制が出来ているとも聞きます。
最近になって、こうした海外におけるアジャイル開発の成功事例や伝統的なウォーターフォール型開発への反省から、日本で再びアジャイル開発手法への注目が高まってきています。一方で、ツールや計画手法などでアジャイルを形式的に採用してはみたけれどどうもうまく回っていないという話も実際によく耳にします。
今回はまず、マーティン・ファウラー氏とジェズ・ハンブル氏より
などについて、説明がありました。その後、アジャイル開発をサポートする各種ツールやプラットフォーム、日本におけるアジャイル案件の適用事例、日本においてアジャイルを普及させるためのさまざまな取り組みについて紹介がありました。
商習慣の違いから、日本では真のアジャイルを普及させることが難しいといった悲観的な意見もありますが、日本のIT業界における仕事のやり方を今後より良い方向に見直すヒントを考える上で大変有意義なイベントであったと思います。
マーティン・ファウラー氏（ThoughtWorks Inc.）
マーティン・ファウラー氏は「アナリシスパターン」「リファクタリング」「エンタープライズアーキテクチャパターン」などソフトウェア開発の方法に多大な影響を与える数々の著作で知られます。また、Bliki (blog と wiki を折衷したもの) と呼ばれるサイトでさまざまな記事を発表しています。
アジャイル開発についても、XPを中心に早期から取り組んでおり、今からちょうど10年前の2001年に（ファウラー氏を含めて）17名で共同で、アジャイル開発宣言を発表しています。
現在は企業向けシステムインテグレーションとコンサルティングを行うThoughtWorks社で主席技術者として活躍しています。ファウラー氏の言葉に非常に説得力と重みがあると感じる理由として、学術上の理論としてではなく、実際の開発経験に裏打ちされたものであるという点が大きいと思われます。さらに、通常コンサルタントという言葉でイメージされるような上流の工程だけでなく、ファウラー氏自身はSmalltalkの熟練プログラマーであるだけでなく、Java、C#、Rubyといったオブジェクト指向言語を中心とした現役のプログラマーでもあります。今回はこのようなファウラー氏の講演を一度、聞いてみたいという人も多かったのではないかと思います。
さて、講演はファウラー氏が英語で語った言葉を数センテンスごとに日本語に翻訳する形式で行われました。したがって、講演時間の枠は約１時間あったのですが、実際にファウラー氏自身の話はその半分の約30分ということになります。
今回の基調講演のタイトルは「２１世紀のソフトウェアデザイン」ということですが、実際の講演は以下の2本立てで行われました。
まず、アジャイルの本質とは何かという点について、90年台のソフトウェア開発についての状況について言及がありました。当時はデリバリーまでに時間がかかりすぎて意味のないシステムを作り上げたり、品質の低いシステムとなったりするということは当たり前の状況であったとのことです。こうした状況に対処するため、計画駆動型開発(PDD)、CMM(Capability Maturity Model：能力成熟度モデル)といった方法論が試みられていたようです。しかし、そういった手法とは別にアジャイルという新しい考え方を支持する人々が出てきました。
現在では「アジャイル」という言葉は独り歩きしてさまざまなところで使われるようになっていますが、その場合は意味の希薄化（Semantic Diffusion）の問題に注意が必要とのことです。つまり、それが繰り返し多くの人によって語られる中で本当の意味が希薄化してしまい、もともとの考え方の本質が見えにくくなっているという問題です。ファウラー氏の思いとしては、まずアジャイルのような新しい開発手法に対する正しい考え方の原点を正しく理解してもらいたいということがあるようです。
最初に、計画手動開発における（日本で一般的なウォーターフォール型もこの考え方に属する）予測的な計画（Predictive Planning）とアジャイルの適応的な計画（Adaptive Planning）の対比を中心として話が進められました。土木建築では事前に仕様を決めてそれにしたがって設計し、建設の計画を立てるという流れになります。作業の手戻りが発生すれば多大な損失が発生しますから正確な予測が可能であれば事前に計画を立てて作業するということは合理的です。開発計画が要件に強く依存している以上、計画主導型の開発を成功させるには要件を事前に安定させる管理が求められます。しかし、ファウラー氏の経験からしても、ソフトウェア開発において事前に要件が固まるということはほとんどなかったそうです。実際、私の周りでもよく失敗したプロジェクトの話を聞くと必ずと言っていいほど「管理者が無能で要件を固定できなかった」「顧客がわがままで最後まで要件を決めてくれなかった」といったことが失敗の原因として語られます。
アジャイルの考え方では、要件が不安定であるということをソフトウェア開発の宿命であると認め、そういった状況でもきちんと作業が進められるように計画を適応させるという考え方をとったということです。まず、アジャイルの適応性という点を正しく理解する必要があるということですね。適応的な計画の中でユーザーも開発者も学びを続け、徐々にお互いが有効に機能する方向に収束していくということでしょうか。ですから、アジャイルに対する批判としてよく言われるように単に繰り返し型でずるずると計画を遅延させるというルーズな考え方とはまったく異なります。
そして、このようなアジャイルの適応的な計画を実行するためには、プロセス主導（Process First）ではなく、人主導（People First）であることの重要性が説明されました。フレデリック・テイラーの科学的管理法では人の役割を明確に定め、標準マニュアルによって作業を画一化しようとします。こうした手法の問題点は、優秀な人のアイデア生かされなくなるということです。
アジャイル開発では古典的な製造業の量産モデルなどで一般的なこうした考え方にも疑問を持ちます。標準プロセスによって定められたマニュアルに従って決まった方法を押し付けるのではなく、優秀な人々に作業のしやすい環境を与え、そして、そうした人々の改善案を柔軟に取り入れてプロセスを進化させていくといった考え方をするとのことです。また、話の中では、Perfectという言葉はソフトウェア開発においては名詞ではなく動詞なのであるというケント・ベックの考え方を引用していました。つまり、「完璧」なソフトはなくても「完璧を目指して改善する」ということが大切なのだということです。
講義の前半の内容については以下の論文でも説明されています。
後半は、前半のアジャイルの考え方を推し進めるテクニックとしての継続的結合（Continuous Integration、CI）と継続的デリバリー（Continuous Deliverey、CD）について説明がありました。
CIについてはファウラー氏の若いころの経験談も交えて、ソフトウェア開発において結合という作業がいかに困難なものであるかという説明がありました。これは今でも多くの開発組織でそういうところがあると思いますが、結合が面倒で困難だからなるべく結合の回数を少なく抑えようという発想になりがちです。たとえば、まとまった機能ごとにブランチを作成し（Feature Branch）、リリース大きな単位でマージするという方法があります。
対照的にCIではなるべく短い期間で結合を繰り返します。なぜ、痛みを伴う結合を何度も繰り返すことが有利なのでしょうか。ファウラー氏は結合間隔を横軸に痛みの大きさを縦軸にしたグラフを示し、間隔が増えると指数関数的に結合の痛みが増加するという経験に基づく事実を示し、それならば小さな痛みを何回か繰り返した方がよいと説きます。そして、CIにおいては問題が早期に検知され、リファクタリングの機会もたくさん得られるということが大切と説明していました。
最後にCDについてです。これは次のジェズ・ハンブル氏の紹介も兼ねる内容になっている（ジェズ氏はContinuous Deliveryの著者でデリバリーの専門家）のですが、CIによって開発したプログラムをテスト環境や本番環境にデプロイしていく流れを自動化し継続的に行っていくという考え方です。ソフトウェア開発は本番にデプロイされてユーザーに使われてこそ意味があるわけですから、いくらプログラムの品質が高くてもこのデリバリーの作業がスムーズにいかないと問題です。
さらに、ここではデプロイメントパイプラインという考え方が紹介されました。そして、パイプラインのテストや環境へのデプロイといった作業はなるべく完全に自動化することを推奨するとのことです。ただし、本番環境へのデリバリーは最終的にビジネスの判断が必要な場合もあるため、その点についてはビジネス側の判断できちんと承認する必要があるということも付け加えて説明していました。
全体的に、アジャイル開発的な考え方について再度考え直すきっかけとなる素晴らしい講義だったと思います。組織や契約の問題など、日本の業界で採用するには障壁があるということも事実かもしれませんが、自動化や継続的な改善など、可能な部分から取り入れていることが大切ではないかと思いました。
なお、今回のファウラー氏の講演については以下でも取り上げられています。
「本番環境への適用まで自動化して繰り返す」、Martin Fowler氏がアジャイルのテクニックを語る：ITpro
マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発（前編）。Agile Conference tokyo 2011 ? Publickey
ジェズ・ハンブル氏（ThoughtWorks Inc. Build and Release Principal）
午後の最初の講演者であるジェズ・ハンブル氏はThoughtworks社でビルドやリリースの専門家として活躍し、Continuous Deliveryの書籍の著者としても知られます。
ファウラー氏と同じく講演内容は2本立ての構成となっており、前半はアジャイル開発の事例の紹介と、アジャイルの組織への導入に関しての話、後半がCDを実践する上での技術面、非技術面でのベストプラクティスについてでした。
講義の開始時点でスライドのコントローラをファウラー氏が持って行ってしまっていて操作ができないというハプニングがあり、すかさず「発表もAdaptive（適応的）に」とフォローしていたところはさすがですね。
まず最初に、「なぜアジャイルなのか」という点に対して、従来の手法ではデリバリーに時間がかかりすぎるのが最大の問題であるという点を取り上げていました。実際、市場に投入するまでに半年もかかるというのはそれだけで大きな問題があるということです。実際、Web上で新しいサービスを始めるといったことを考えれば、ビジネスの視点からも考え付いたサービスを稼働されるまでに時間がかかっていては他社に先を越されてビジネスチャンスを逃してしまうという危険性が考えられます。
この説明の中で、大企業では
といった説明をしていたのが私としてはちょっと印象的でした。対照的にWeb2.0の世界でYahooに買収されたFlickrの場合には1日に10回ものリリースを行い、高品質なシステムを維持しているという話がありました。そして、こうした機敏性がない組織であれば、どんな大企業でも今後は小さなスタートアップ企業に食われることになるという警告も。こうした状況は、まさに日本の大企業とWeb系企業にもみられる特徴ですが世界共通の問題なのですね。
こうしたアジャイル開発とシステム稼働までの期間の短縮という点を念頭に置いた上で、次に2つの事例について紹介されました。
最初の事例は英国で最も有名なニュースサイトを運営しているGurdian紙のウェブサイトについてです。2006年まではレガシーなコンテンツ管理システム（CMS）やテンプレートエンジンが使われており、サイト内の記事はほとんど手作業で処理されていたそうです。ちょっとした変更を行うだけでも人手で何週間もかけて行っていたようです。さらに、そうした状況を刷新するために一度新規版の構築が試みられたのですが、それが失敗に終わっていたため、ユーザーの側はアジャイルなどますます新しいアイデアの導入に対して敏感になってしまっていたということがあったようです。しかし、顧客側の求めているものとのギャップはますます広がるばかりであり、インタラクティブ、ダイナミック、マルチメディア化、ソーシャルネットワーキング対応を全て行いたいといったものでした。
こうした状況に対して、まず、最初の2週間で方向付けを行い、今後のおおよその方向性についてラフスケッチを作成するのがThoughtworks流のプロジェクトの開始の仕方らしいです。重要なことは、この段階ではあくまでもラフスケッチを描くのであり、細かいところまで完全に分析、設計して決めるということではないということです。そして、全体の中から特に旅行部門を選択し、まずこの領域に集中することにしました。
結果として、8か月後にトラベルサイトの本番環境へのデリバリーを行い、結果的にページビューは10倍に増加したそうです。そして、ビジネスサイドからみて実際にこれだけ効果があるのかという確信を持ってもらうことに成功したとのことです。こうしたフィードバックをもとに学習した改善点を順次盛り込みながら、サイトを更新していき、最終的に想定の70%のコストで完了したようです。
2番目の事例はthetrainlineという1日あたり10万トランザクション、840万人のユーザーを処理する英国の鉄道のオンライン切符購入、座席予約サイトの構築についてです。
trainline: buy cheap train tickets, get UK train times & fares - book seats online
このシステムの最大の問題点はレガシーなシステムが乱立しており、複雑化していたということでした。
このプロジェクトには英国で50人、インドのオフショア先で150人の要員が関わっていたようですが、これも最初の事例と同じく小さなところからスタートして最初に顧客の満足を高めることに注力しました。そして、ThoughtWroks StudioのALM（アプリケーションライフサイクル管理）ソリューションを使い、6週間ごとの繰り返しリリースサイクルでビルド、デプロイ、リリースの自動化や環境の仮想化など幅広く利用したとのことです。
このように、大企業でも小さなところでもアジャイルは適用可能という事例です。
Forrester researchの調査結果によれば、アジャイル開発を業界全体で採用している割合は昨年から6%増加して37%にも上っているとのことです。一方、その他の開発プロセスの割合は以下の通りです。
| 開発プロセス | 割合 |
|---|---|
| アジャイル | 37% |
| プロセスなし | 28% |
| イテレーティブ | 19% |
| ウォーターフォール | 9% |
| ストラクチャー | 4% |
ただし、この場合アジャイルの採用に対して最大の障壁となるのは組織上の問題とのことです。会社の意思決定が統一されていない、縦割り組織、変化・リスクを回避しようとする姿勢などです。
従来開発プロジェクト管理では「スコープ」「スケジュール」「費用」というパラメーターを調整することが重要であると考えられていましたが、アジャイル開発では従来の三角形を「制約」として考え、「価値」「品質」を頂点とする別の三角形で考えます。
InfoQ: ’アジャイルの三角形’によるアジャイルのパフォーマンス測定
従来の三角形では品質は暗黙的に高品質であることが仮定されており、スケジュールやコストの範囲におさまれば成功であると考えられました。しかし、実際には決してユーザに使われない機能を作りこんでしまうことでいくら高品質でも価値のない機能を開発したのでは無駄です。ジェズ・ハンブル氏はiPhoneの初期バージョンの例が挙げ、最低限の機能で早期に市場に投入し、ユーザーのフィードバックを得て本当に求められるものを追加していくのがよいと説明していました。イノベーションはそうした繰り返しのリリースにより初めて得られるということです。
まず、仮説を立てる。次に、最小限実行可能な製品をデリバー、フィードバックを得る。それを繰り返す。実際、これは科学的手法に他なりません。そして、以下の書籍を紹介していました。
以下の著者のブログもあります。
CDを実行する上では、以下の3つが柱となるとの説明がありました。
ファウラー氏の説明でもありましたが、ビルド、デプロイ、テスト、リリースなどはなるべく自動化する。その上で、協調とプラクティスによって、開発者、テスター、顧客など関係者が最大のスループットを得られるようにお互いに協調し合うということが大切ということですね。まずは、自動化やパターンの導入から入って最終的には組織やメンバーの意識改革が欠かせないのではないかと感じました。
品質はテスターがテスト工程によって保証するのではなく、開発の初期段階から作りこまれたものである必要があるという点を説明していました。品質はプロジェクトにかかわるすべての人々が責任であり、テスターの役割は品質の確保ではなく可視化にあるという点を強調していました。
最後の話題はアジャイルにおける人というものの考え方について説明がありました。人は何によって動機づけられるのかという点に対して、多くの人はお金によって動機づけされると考えられますが、調査によるとそれだけではないとのことです。単純労働では報酬の大小が重要な要素になってきますが、ソフトウェア開発のような知的労働ではむしろお金は重要な要素とはならいこともあるというダニエル・ピンクの考え方を紹介していました。
この考え方では、
といったことが、むしろ、やる気の原動力となると説いています。
そのために、アジャイルでは自立した部門横断的（cross-functional）な製品チームを作るというAmazonの思想を紹介していました。お勧め商品、履歴、カートなどそれぞれの機能を自立したチームで開発し、何を作って実装したらよいかという目的をチームや個人ごとに明確化しているということです。
それから、フィードバックループをさまざまな場所で形成し、継続的な改善を推奨するような考え方により、メンバーのやる気を引き出すことが重要であると説明していました。
三井 伸行氏（株式会社 戦略スタッフ・サービス 取締役 エグゼクティブコンサルタント CTO / NPO法人ドットNET分散開発ソフトピア・センタークニカルオフィサー）
畑 秀明氏（日本アイ・ビー・エム株式会社 ソフトウェア事業 ラショナル事業部 クライアント・テクニカル・プロフェッショナルズ）
前半の三井氏は、Innovate2011に参加して得られた各国のアジャイル開発の状況から、日本と欧米との最大の違いは機械化の導入の有無にあると説明し、その中でPANDA : Poor And Non-Disciplined Agile という用語を紹介していました。安さを求めてTCOの概念がなく、またプラクティスを表面的に使っているといった状態を示しているようです。後半は分散開発をサポートするIBMのRational Jazzの製品紹介とデモが行われました。
IBM スマートなソフトウェアで生産性を向上 Rational Jazzポータル - Japan
ファウラー氏やハンブル氏の講演でプロセスよりも人を重視という話があったのですが、もともとのアジャイル宣言では「プロセスやツールよりも個人との対話」を重視するということが本来あります。今回のセッション自体の主張というわけではないと思いますが、この点を忘れて、機械化やツールの話は自動化ツールがあれば解決する、あるいは個人個人の能力やアイデアを軽視してもよいという誤解を与えかねないためツールや自動化の話をする際には注意が必要であると感じました。
長沢 智治氏（日本マイクロソフト株式会社 エバンジェリスト）
前のセッションに引き続き、マイクロソフト社の開発ツール（Team Foundation Server 2010）の紹介セッションですが、長沢氏は
という点を繰り返し強調されていました。今回は次期Visual Studio vNextで本格的に取り込まれる予定の「継続的フィードバック」というコンセプトをいかにサポートするのかという観点から実演を取り混ぜながら説明が行われました。なお、これらの機能は実際にマイクロソフト社の開発で有用と考えられる知見をツールに取り込み、また、自社の開発でも利用している(英語ではeat your own dog foodと言う)そうです。
全体的には圧倒されるほどの多数のアイデアやツールの紹介だったのですが、最後のメッセージは、
「no more tools!ツールを使いこなすことではなく、やらなければならない事を実現する為のツールの議論を」
ということでした。アジャイル開発ではツールに圧倒されるのではなく、何が有用なのかをチームメンバが主体的に考えて取捨選択していくことが大切ということだと理解しました。
講演資料は以下にアップされています。
【Agile Conference tokyo 2011】 継続的フィードバック
朝倉 慎一氏（株式会社 日立ソリューションズ 技師）
開発言語としてJRubyを利用し、通信制高等学校向けの「通信課程向け教育システム」をアジャイルを利用して実際に開発したという事例についての説明でした。講演者の朝倉氏は技術コンサルティング、全体的な管理の立場から参加し、実際の開発は島根の協力会社（プロビズモ社）によって地域を分散する形で行われたようです。
事前に要件定義の代わりに要件整理のフェーズがあり、その後1ヶ月をスプリントの期間として4回繰り返すことで開発を行い、最終的には顧客からかなり満足度の高い結果が得られたとのことです。途中で顧客が参加し、早期にアプリケーションを使用してもらうことで、フィードバックを得る仕掛けがあったようです。しかし、請負契約という制約から要件変更に対してどうしてもコストが増大するという問題があったようです。
日本におけるアジャイル開発の取り組みとして興味深い発表でした。契約形態や下請け構造といった業界の構造との問題により、今後どういうアプローチで取り込んでいくのがさらに効果的なのかを考えていく必要性も感じました。
萩原 純一氏（アクセラテクノロジ株式会社 取締役 技術開発部 部長）
アクセラテクノロジは10年ほど前に富士通のメンバーがスピンアウトして結成されたエンタープライズサーチの製品を開発している会社です。
当初はウォーターフォール型の開発プロセスで製品開発に取り組んでおり、各機能ごとに選任の担当者が割り当てられる結果となり、属人化してしまうという問題があったようです。ビジネスが低迷する中、エンジニアの流出という問題もあり、また、技術者を中途で採用するという試みも、なかなか業界でパッケージ開発のスキルや経験のある適任者が少ないという問題でうまくいかなかったとのことです。
そのような中で、アジャイルを中心とした新しい考え方に思い切って方向転換を図ったとのことです。
最初は基本に立ち返り、いろいな本を読むところからスタートを開始し、徐々に徐々にアクセラ流と呼ばれる独自の考え方を生み出していきました。この「まねる＋独自性」という姿勢について「富士山の上で1cmジャンプしよう」というアクセラテクノロジ社の社長の考え方を紹介されていたのが印象的でした。独自の改善点としては、
などを紹介されていました。最初は形式的なところからまねてみるが、徐々にプロセスを改善し、自社のスタイルに合ったように変形させていくというAdaptiveな考え方は非常に参考になりました。
依田 智夫氏（株式会社シナジー研究所 代表取締役社長・プリンシパルコンサルタント）
牛尾 剛氏（株式会社匠BusinessPlace チーフコンサルタント）
永瀬 美穂氏（株式会社ディアイスクエア アジャイルコーチ）
昨年結成されたE-AGILITY協議会について紹介がありました。
E-AGILITYはユーザー企業とアプリケーション開発者に、出会いと交流の場を提供する事を目的として設立された協議会です。ユーザー側は長期間使えて柔軟に進化可能なシステム構築戦略を必要としている一方で、開発者側は開発手法には関心があっても、何がユーザーのビジネスに価値をもたらすのかの感覚が不足しているとの指摘がありました。
E-AGILITY協議会では、今後年数回（目標4回）のカンファレンスと月例の勉強会を実施する予定とのことです。アジャイル開発は内製開発が中心のWebサービス企業などではかなり広く取り入れられているようですが、企業のシステムを開発するSI業界では伝統的な業界構造により、従来ユーザと開発者とがお互いに直接対話をする機会がほとんどありませんでした。アジャイル開発宣言でも、アジャイル開発の真の目的はユーザにとって価値のあるソフトウェアを開発することで、ユーザと開発者がお互いに対立するのではなく、協調するところにあるとされています。このような対話の機会が作られることでお互いの交流が進むということは形式だけでなく、真のアジャイル開発を推進する上で非常に大切であると思います。
戸田 孝一郎氏（株式会社戦略スタッフ・サービス 代表取締役社長）
アジャイル検定試験検について紹介がありました。
これまでのところ、総受験者247名に対し合格者は108名の合格者を出しているようです。現在のところ、最下レベルであるL1の試験のみですが、問題がXPに特化しているとのことですが、今後上位レベル・範囲の拡大なども視野に入れて展開されていくという事です。なお、L1は出題数30問4択形式（試験時間は30分）で無料で受験可能なようです。
| © 2011 OGIS-RI Co., Ltd. |
|
