のみほーだい! のみほーだい!TOP のみほーだい! は、(株)トラストサービス ITソリューション事業部 　が運営する、技術情報交流サイトです。 アジャイル・プロセス（Ａｇｉｌｅ　Ｐｒｏｃｅｓｓ）の導入について 第１回　XP(eXtreme Programing)の概要 @author m.matsushima ■はじめに アジャイルプロセスって？ アジャイル（ａｇｉｌｅ）とは元来は「俊敏な」「機動的な」という意味ですが、ソフトウェア開発においてはユーザーの要望に対し迅速に対応できることを意味します。 これは、昨今の「短納期」「低予算」「要求の複雑化」という三重苦のような状況の中で生き残るためには不可欠の要素でしょう。 従来のウォーターフォール型の開発では納期になるまでユーザーは完成品を見ることができず、果たして自分の希望したもの・満足のいくものができてくるのか、そもそも納期にきちんと完成するのか、 不安を抱きながら待ち続けるしかありませんでした。そして気に入らない点があっても追加コストの発生やら納期延長の問題があり自由に要望を言うことができませんでした。 プロトタイプを先に作ったとしても所詮「お試し版」である以上限度があります。 このような問題を解消し本当にユーザーの満足できる製品を提供するにはどうしたらいいのか。「機械的な」１つの手法で、まるで工場の生産ラインにのせるが如く作業を進めて、 早く・高品質な製品ができあがらないものか。。。 2001年２月に米国ユタ州で活発な議論が交わされ「アジャイル開発宣言」が採択されました。内容は、 ●プロセス・ツールよりも、個人と相互作用（職人は道具より腕が大事） ●包括的なドキュメントよりも、動作するソフトウェア（絵に描いた餅よりも実物が大事） ●契約交渉よりもユーザーとの協調 ●計画に従うよりも変化に対応（あくまで臨機応変にということで計画の重要性は変わらない） 結論は、「人の力を最大限に引き出すことにより、勝利を得る」ということです。 言い換えると「アメリカ的発想」から「日本的発想」が見直されたともいえます。 原則として以下の要件が要求されます。 1． 早期かつ頻繁に価値のあるソフトウェアを納品することによりユーザーを満足させることを最優先とする。 2． 短期のタイム･ボックス（単位期間）を好み、ソフトウェアを頻繁に（２週間～２ヶ月ごと）に納品する。 3． 進捗を測る最良の方法は動作可能なソフトウェアである。 4． 開発の後期でも要求の変更を受け付ける。 5． プロジェクトの期間中、ユーザーと開発者は毎日一緒に作業する。 6． モチベーションの高いメンバーを中心にプロジェクトを立ち上げる。 7． 最も効率的かつ効果的に情報を伝達する方法は、直接対話することである。 8． 最善のアーキテクチャ、要求、設計は自己組織化したチームから生まれる。 9． アジャイルは常に技術的な素晴らしさや優れた設計に注意を払うことにより強化される。 10． アジャイルを用いれば開発者とユーザーは最適なペースで開発を続けることができる。 11． シンプルさが大事。やるべき仕事の量を最小にする技が必要不可欠である。 12． チームは、より効果的な方法を探るため定期的に見直しを行い、それに従って行動を調整・修正する。 アリスター・コーバーン著「アジャイルソフトウェア開発」より これらを実現する手段として最近XP（エクストリーム・プログラミング）が注目されています。この中には我々ITDの技術者にとっても非常に示唆に富んだ内容が含まれているので、今回はXPの概要について説明します。 似たような手法にRUPというものがあり、これも反復的なシステム開発を行なうものですが、説明は別の機会に譲ります。 ■XP(Eｘｔｒｅｍｅ　Ｐｒｏｇｒａｍｍｉｎｇ) ２０－８０の法則 　ソフトウェア開発者には有名な法則に「２０－８０の法則」というものがあって、これは「実際に必要な（使われている）プログラムの８割は納品したプログラムのうちの２割の中に入ってしまう」ということです。逆に言えば、残りの８割のプログラムは納品しただけで殆ど使われていない－つまり、ユーザーは使いもしないプログラムの製造に大部分の金を支払っていることになります。 　発想を変えて本当に必要な２割分だけを全体の開発期間の１／５（実際には共通部品の整備などがありもう少し必要になります）で完成させてしまい、それを先にユーザーに使ってもらえば、その後もっと的確な要望が出てくるし、開発側としても余分なものを作らなくて済むので余裕を持って作業できるはずです。 　また、よくトラブルを起したプロジェクトにありがちですが、納期直前になって必要なプログラムができあがっておらずユーザーに対してただひたすら謝って納期を延ばしてもらうということもなくなります。 リスク回避 　XPの具体的な説明に入る前にソフトウェア開発にはどのようなリスクがあるか、失敗経験をもとに考えてみましょう。 ・スケジュールの遅延： 納期が来たのに、ソフトウェアが完成するまであと数ヶ月かかるとユーザーに頼まなければならない ・プロジェクトのキャンセル： 度重なる納期遅延の末にプロジェクトは稼動（運用）されずに取りやめとなる ・システムの陳腐化： ソフトウェアは無事稼動したが、数年後には改良のためのコスト・欠陥率が高くなりすぎシステムを取り替えざるを得ない ・欠陥率： ソフトウェアは稼動に入るがバグが多すぎて使われなくなる ・要件の誤解： ソフトウェアは稼動に入るが当初掲げられた業務上の問題点が解決されない ・環境の変化： ソフトウェアは稼動に入るが設計当初解決すべきと判断していた業務上の問題点が、運用時にはより切迫した別の問題とすり変わってしまった ・誤った機能強化： プログラマの興味によって様々なおまけの機能が付加されていたが、ユーザーには何の利益ももたらしていない ・スタッフの退職： 数年後、プロジェクトにいた優秀なプログラマが開発（改良）していたプログラムに嫌気がさして去ってしまった 　これらの問題に対してXPはどの様に対処しようとしているのでしょうか。 ・スケジュールの遅延： XPは短いリリースサイクルを要求するので遅延の範囲が限定される ・プロジェクトのキャンセル： XPは、ユーザーにビジネス上の最も価値のある最小規模のリリースを選択させる その結果、稼動に入る前にプロジェクトが悪い方向に進むことは少なくなる ・システムの陳腐化： XPは、包括的なテスト群を作成してシステムを維持するので常に品質が保たれる ・欠陥率： XPは、プログラマが書いた関数毎と、エンドユーザが書いたプログラム機能毎の両方の観点からテストを行なう ・要件の誤解： XPは、ユーザーにチームの統合的な役割をすることを要求するので、チームはユーザーから学んだことをソフトウェアに反映できる ・環境の変化： リリースサイクルが短いので１つのリリース内でビジネスの変化にともなう仕様変更などの影響が少ない ・誤った機能強化： XPは、優先度の最も高い仕事だけを扱う ・スタッフの退職： XPではプログラマに自分の仕事の見積もりと完了に関して責任を持たせるので、無理な要求を押し付けられて欲求不満になることはない 具体的な方法 すべてを導入するのはとても無理ですが、状況に合わせて使えるものから利用しましょう。 ①計画ゲーム ビジネス上の優先度と技術的見積もりを結合し次のリリース範囲（機能）をすばやく決定します。 要点は、このフェーズを通して自分たちの見積もり精度をどんどん向上させリスクを減らすことです。 「見積もりは経験にもとづいて立てるもの」 ゴール： 計画ゲームのゴールはチームが生産するソフトウェアの価値を最大にすることです。 ソフトウェアの価値から開発のコストとリスクを差し引いて判断します。 戦略： 投資を最小にして、もっとも価値のある機能をなるべく早い時期にシステムとして稼動させます。 ピース（単位）： 計画ゲームのピースはストーリーカードです。 これに対し、実際の開発のピースはタスクカードになります。 プレイヤー： 計画ゲームには、開発側とビジネス側の二種類のプレイヤーがいます。 開発側はシステムの実装に責任のある人です。 ビジネス側はシステムが想定するものを決める人です。 展開： 探検 システム全体がこれから行なうべきことを判断します。（ストーリーカードを書く） 必要な時間の見積もりを行ないます。（理想的なエンジニアリング時間） ストーリーの一部が他より重要だと判断されたら、ストーリーの分割を行ないます。 コミット 実現可能な要求のうち次に行なうものを決めます。 価値を分類します。 ①それなしではシステムが機能しないもの ②より本質的でないが多くのビジネス価値を含むもの ③あればいいもの リスクを分類します。 ①正確に見積もれるもの ②合理的にほぼ見積もれるもの ③まったく見積もれないもの 開発側は１ヶ月の生産性をビジネス側に伝えます。 ビジネス側はストーリーカードの山から今回リリースするものを選択します。 運転 現実が計画とは違ったときに開発をガイドします。 イテレーション 各イテレーション（１～３週間程度）毎にビジネス側はその中で実装するにあたり最も価値があると思われるカードを選択します。 最初のイテレーションで選ばれたストーリーが未熟でもシステムの端から端までつなぐようなものにします。 リカバリ 開発側が速度を過剰に見積もっていた（見積もりが甘かった）ことに気づいた時はビジネス側に調整をお願いし、今回のリリースに入れるストーリーを再度決めます。 新ストーリー ビジネス側がリリースの開発途中で新しいストーリーが必要なことに気づいた時はそのストーリーを書くことができます。 開発側が立てた見積もりにもとづき、それと同じくらいの見積もりのストーリーと差し替えます。 再見積もり 開発側が計画はすでに自分たちの見積もりと違ってしまったと思ったら残っているストーリーを再見積もりして、速度を再設定します。 　 ②短期リリース シンプルなシステムをすばやく稼動（運用）させます。 また、新しいバージョンのリリースを極めて短いサイクルで行ないます。 ③メタファ（比喩） すべての開発を、システム全体がどのように動くかというシンプルで共有されたストーリーによって導きます。 ④シンプルな設計 システムは常にできるだけシンプルに保つように設計すべきで、複雑さを見つけたら取り除かなければなりません。 将来の問題を予測して余計なものを設計に持ち込んではいけません。 「明日が来ないこともある」（20-80の法則を思い出せ） 「明日にはもっとよい方法を学ぶこともある」 ⑤テスティング プログラマは常に単体テストを書き、開発が続く限りそのテストは絶え間なく実行されます。 ユーザーは機能の完了を検証するテストを書きます。 テストファースト： プログラマは実際のプログラムをコーディングする前に、そのコードをテストするプログラムを先につくります。 　→　仕様の不明点がコーディング前に洗い出されます 　　　テストの自動化が可能になり常に品質が保証された状態に保たれます ⑤リファクタリング プログラマはシステムの振る舞いを変えずにシステムを再構築します。 重複を取り除き、コミュニケーションを改良し、シンプルにし、融通性を持たせます。 ただし、再構築は１回のイテレーションが完了した時に行い、開発の途中では行なわないでください。 場合によっては今までのコードを全部捨て去ることもあります。 「よりよい明日のために勇気を持とう」 ⑥ペアプログラミング 作成されるコードは全て二人のプログラマが１台のマシンに向かって書きます。 相棒はただ横で見ているのではなく二人の対話によりプログラムをよりよくすることに努力します。 ⑦共同所有 誰でもいつでもシステムの全てのコードを変更できます。 ただしテスト環境が整っていない状況での共同所有は自殺行為。 テストを行なっていないコードは絶対に共有フォルダに入れてはいけません。 ⑧継続した結合 １日に何度も、ひとつのタスクが完了する度にシステムを結合しビルドします。 つまり、システムは常に完結した状態で稼動可能にしておかなければなりません。 どのコードも結合されないまま２時間以上置いていてはいけません。 ⑨４０時間労働 週４０時間以上働かないことをルールにします。→　４０時間でできる範囲を正確に見積もることが鉄則です。 ２週続けて労働時間が超過しないようにします。 ⑩オンサイトのユーザ 実際のユーザーをチームに加え、いつでも質問に答えてもらえるようにします。 ⑪コーディング規約 プログラマはコードを通してコミュニケーションを強調するルールに従って、すべてのコードを書きます。 アジャイルプロセスの導入について 第１回　ＸＰの概要 第２回　ＸＰの光と影 第３回　テストファーストの考え方 第４回　リファクタリングの考え方 参考文献 ページトップ のみほーだい!TOP トラストサービス ITソリューション事業部 Copyright(C) Trust Service Co.,Ltd. All Rights Reserved.