142 7 原則と 8 原則の対応を調べてみると、元々あった 7 原則が再整理された印 7 原則 ムダをなくす 知識を作り出す 決定を遅らせる 速く提供する 人を尊重する 全体を最適イ匕する 品質を作りこむ 8 原則 ムダをなくす 学ぶの重要 学ぶの重要 リリース重要 活き活きしたメンバー 全体を最適化する 品質を作りこむ 顧客に焦点を当てる よりよくし続ける 『リーンソフトウェア開発 ~ アジャイル開発を実践する 22 の方法 ~ 』にもあ リーンソフトウェア開発には、原則とプラクティスを考えるた るように めの 22 のツールがある。つまり、プラクティスがない。プラクティスは、 自分たちで考えなければならない。 だから、リーンソフトウェア開発は難しい。 142
ェクストリームプログラミングの原則を編する (I) はじめに 天野勝、永和システムマネジメント 97 なるのが、原則なのです が良いのま、その場の状況に応じて判断しなくてはなりません。そのよりどころに ーーケーーシ - ョン・ 会話によるコミュニケーションが良いのか、ドキュメントによるコミュー ーっである「コミュニケーション」について、それが大事だということが分かっても、 価直は抽象的であるがゆえ、行動のキ十にはなりにくいのです。たとえば、価値の てはいくつあるのかすら知らない方が多いのです - 。罕は 14 個です。 ように個数を、価値と実践について知っている人は多いのですが、なぜか原則につし、 プラクティスとして 13 個、応用プラクティスとして 11 個が提 ] 昌されています。この 方が提唱しており、『エクストリームプログラミング入門第 2 片 [ * 4 ] では、基礎 バック (Feedback) 」「勇気 (courage) 」「尊重 (Respect) 」の 5 つあり、実践は多くの は、「コミュニケーション (ünnunication) 」「シンフラレさ (Simplicity) 」「フィード は価値ー原則ー実践 ( プラクティス ) の階層で、その体系を形作っています。価値 の原則とは 多いようなので、紹介をいたします。 に私にとっては、とても価 f あると思うの原則なのですが、意外と知らない人が この問題を解決するところのよりどころとなったのが、の原則でしたこのよう しまい、その先に進んでいかないというものでした。 なって直面した問題は、プラクティスを真似てし、るだけではすぐに限界がおとずれて ル開発を行いたいという方のお判云いをするお仕事をしています。お云いする側に れて実践をしてきました現在は、開発者として働くことはありませんが、アジャイ 私自身は、 2001 年から業務で、部う預勺ではありますが、のプラクティスを取り入 ラミング ( でした [ * 3 ] 。 のころに最も多く日本で採用されていた軽量な開発プロセスはェクストリームプログ 言葉はまだ発明されておらず、「軽量な開発プロセス」などと嚼 - していました 10 年以上が経ちました 2000 年当時は、「アジャイルソフトウェア開発」 [ * 2 ] という 『エクストリームプログラミング入門』 [ * 1 ] の邦訳本が 2000 年に出版されてから、
1 10 2. 1 テスト目的を考える際の留意点 なおシステムテストのテスト目的としては、システムの機能要件・夛財幾能要件・ 外部旧信との合致性検証、 ( 取りうる手段やコスト範用内での ) 外部旧を介 した糸琲曲勺な欠陥の識別の 2 つが一ヨ朝一。ただアジャイルでは変イ匕に対応す るために以下の 2 点に留意して、それをさらに時系列で展開していく必要があり ます。 ソフトウェアカ勺に変更されるため、最初から大規模なテストを構築す ると、テストの賻構築コストや呆守コストが増大し開発効率を低下させます。 そのためテスト要求と保守コストに応じて段 ; 部勺にテスト目的を勤艾してい く方針が重要です一。 アジャイルではテストや品質確保のプラクティスが一一癇勺に取りノⅵ - しられる ため、しばしばシステムテスト立置づけが変化することがある点、留意が 必要です。例えば TDD を嗣ーネ 1 , ば実装ミスによる欠陥を削減できます。 テスト自衂匕を行えばデグレードを削減でき、また受けノはもテストを自動化 できれば、歟から DSL のレベルまでのトレーサビリティを一定範用でイ描正 できます。こうしたプラクティスが機能していれば、システムテストではそ のプラクティスの妥当性の評価と、そのプラクティスでカバーできない翕印或 のテストが、果たすべき責務となることがあります。 2.2 システムテストを支えるテスト方針 なおテスト目的の段「部勺な達成に当たっては、開発ライフサイクル上に複数の テストを配置してフロントローディングを志向していくことになります。 とりあえず今回は説明のために、システムレベルでのテストの判立として以下 を定義します。 囹本に対するテスト。ソフトウェア自本に対 I ー , 網勺に実施するシステムテ スドぐ 3 ー。下記 2 つのテストでカバーできていない領域含めテストします。 変更に対するテスト。変更に対するテストと、その影皹井に対するリグレ ッションテストマ冓成されます。主にイテレーションごとに実施されます。 糸襭勺なテスト。開発と並行して糸売実施されるテストです一。自動化された 受けノテストを 0 で糸売実行するもの等がこれに該当します。 効果的なシステムテストの実現に当たっては、上記のテストの立を以下のテ スト方針で展開していくと良いでしよう。 1 1 0
5. 夢のに向けて タスクボードの特性からチケット駆動開発で考慮すべきポイントを考察しました。 チケット馬亜」開発で用いるチケットシステム (ITS) は、プロセス関心事に文月一る表 現力が高く、表現すべきものは何か、規律、場、を決める必要がありました。 チケット駆動開発には様々な実現方法があります。 2 章で示したようにアジャイル 開発の障壁をイ弋替プラクティスで乗り越えれば、アジャイル開発に期待してし、たこと が実現できますし、アジャイル開発の第 1 ステップとしても論効でしよう。しかし、 タスクボードとチケットシステムのイ督且みは同じでも、必要なことが異なることを認 識してください。まずは、チケットシステムでどんなことができるのか、障害管理か ら始めるのもよいでしよう。 理想的なプロジェクトの実現は難しいものです。開発者はより良いプロジェクトを 求めて、理想的なプロジェクトを夢見がちです。しかし、その理想的なプロジェクト ( To ) に直接たどりつくには、大きな負担が伴います。まずは現伏のプロジェクト 叭 sls) の問題点を見極めて、最も大きな問題を解決する方法を感がるところから始 めるのはどうでしよう。 2 害旧割 ( パレート ) の法則が成り立つなら、大きな効果が得 られるはずです。 大切なのは夢をあきらめないことです。あきらめず、現状を受げノ朝 - して、問題を少 しずっ改善することが、理想への首ではないでしようか。 6. 参考資料 アジャイルの夢を現実に - プラクティス・プラクティス h叩://肭、W. slideshare. net/Mak0toSAKAl/xp2013 『チェンジ ! 』の考え方 ~ マネしゃんと ~ h叩:/んⅥ肌V. slideshare. net/Mak0t0SAKAl/ss-15005 図 0
él 46 ◆アジャイルだから 「アジャイルたからこれをやってみよう ! 」 このような言葉はチームの中て一切出てきません。 アジャイルたからユニットテストをするとか、アジャイルたからチケット駆 動にするとか、目的がアジャイルになるとプラクティスを正しく行うことに 注意が向き、結果、ユーサにとってもチームにとっても正しいことを行うこ とがてきなくなってしまいます。 ユーサへこんな価値を提供できるからこんなプラクティスをやってみようと か、チーム内の認識を合わせて進めるようにこんなツールを使ってみようと か、目的かユーサやチームの [ へ向いた取り組みを行うことにより、アジャ イルなチームになっていきます。 アジャイルにするのてはなく【アジャイルになる】ことがとても大切てす。 ここまて紹介した要素は、アジャイルなチームへ新メンノヾが参入するときの課題 を解決するためだけてなく、新しくチームをつくるときにも同じように採用てき るものてす。さらには、システム開発に限らすどのようなことにも通じる要素て あると思っています。ですので、この記事を読んで頂いている同じ課題を持つみ なさんにとってもヒントになれは幸いです。 ~ さいごに ~ チームメンハみんなか [ 人のためロ考え、 [ 人のために ] 実践し、 [ 人のためロ 改善する。この取り組みが [ を幸せにするということてあり、まわりまわっ て [ 自分 ] を幸せにすると信じています。ここで言う [ とは、ユーサてありチ ームメンハてあり・・・プロジェクトに関わるすべての [ を指しています。 すべての [ 人のためロ、そして [ 自分のためロ、さらなる進化をしていける。 そんなアジャイルなチームをメンハみんなでつくっていきたいてすね。 おわり 146
→ 141 ( 8 ) よりよくし続ける ベストプラクティスなどない。 世の中の変化と同じぐらい速く変化していく 昨日得た知恵は、今日になって障告になり、明日には愚かな行為になるだ とるにたらないことに ) 嶂する 不快な騒音 (Noise) に耐えられないときや、小さな失敗が深く調べあげら れ、訂正されたときに、信頼できるパフォーマンスが生まれる。 科学的根ある方法を活用する 仮説をたてる。素早い実験を行う。簡潔なドキュメントを作る。 択を実践する。 その後に、別の問題の対応を始め、再度それを繰り返す。 最高の選 141
1 17 3. ソフトウェア開発プロセスをする ~ 図を使った DSL 相手に合わ世た図表を作るのも、一種の DSL といえると思います。 一年ほど前になりますが、自分が知っている手法や、必要と考えている手法を整理し ました。ビジネス、プロジェクト、チームの 3 段 ; 皆に整理しています。 Researeh Business/P 「 oduct Layer 、 Sk を日 0 は、 / : p き′ SO な as Product M 田 1 金 g 印 A ~ ch は 0 秋 u ′ 0 、 / ⅵ「 0 れ men F をを d ト練 / AhalYSiS Operation f 「 us ⅳリ 0t0 ′ 0 、 Test Manage Release A む toma も 0 れ Mo ⅲ to を Campåign De5iÉn St リ市 0 日 0 謇 Project/Delivery Layer Team/lmprementation Layer 0 Project を、 Criteria 、、 T を st ⅲ g 00 朝 g い - ed た t ョ b に 物 R を SO r003 、一 m ent m : 莎い物 Re & r を SS ー 0 物、 朝 M a n;agce Ⅳを一 0 ty を科第 ua 要 00 0 飛。 Rev 物 Se れ贏い : 、む 0 物 n これだとちょっと複雑なので、さらにもう一歩整理したのがこの図です。 開発プロセスよりも、学ぶべきプラクティスにフォーカスをあてています。 プロセス顧客満足要求、仕様 ビジネス / ューザーー Scrum 技術プラクティスーーー テスト、品質計測スムーズなリリース 1 1 7
143 アジャイルなチームのつくりかた アジャイル札幌阿部智紀 アジャイル開発をはじめるときに、最初に取り組むことは何でしようか ? 適用可能なプラクティスからはじめたり、スクラムなとの手法を採用してその枠 組みにはまるように進めたりと、何からはじめるのかはメンハの基礎知識や現場 の状況などによって異なります。 しかし、最初に取り組むべき最も重要なことは「チームをつくる」ことであると 思っています。 チームは、チームメンハみんなでやってみて、失敗して、改善して、を繰り返し ていくことによって、アジャイルなチームへと成長していきます。 はじめは、チームメンハがそれそれ異なった知識・経験を持っていても「ヨーイ ドン」でスタートすることにより、チームメンノヾみんなて経験してきたことか積 み重なって今のチームをつくりあけていると言えます。 このように、これまては何もないところからチームをつくりあけることに注目し、 さまさまな情報を収集したり、てきることから実践したり、と改善を続けてきま したが、ここ数年の間に新しい課題か出てきました。 それは新メンパの参入です。 新しいメンハは、アジャイル開発の ( 知識を持っていたとしても ) 経験か無い場 合が多く、きつらり詳細まて書かれた仕様書カヾ渡されて作業をしてきた人にとっ てはまったくの別世界に思えることもあります。 たとえアジャイル開発の経験があったとしても、チームが異なれは重視する価値 も異なるため、これもまた別世界に思えることもあります。 新しいチームて新しい案件を手掛けるのと違い、ある程度の文化が出来上がった チームに新しいメンノヾが加わることは、チームのべロシティが ( 下がるとまでは いかなくとも ) 上がらなくなってしまい、より良い価値を提供ノ売けることに支 障カることになります。そして、新しいメンハにとってもチームの文化に慣れ るまでにはたくさんの時間がかかってしまいます。 143
103 TDD のはじめかた 最翔に要なもの モチの -- - ション 指導してくれる人や、手引きとなるもの やさしい問題 ツールと環境 あるアジャイル先進企業では TDD が何年にもわたって基本的プラクティスとして実 践され、基本的に全員がほぼ常に TDD で開発を進めている。ある新人はプログラミン グ歴なしで組織のメンバーに加わった教育と実務の中で、先輩からコードを書くと きは常にテストを書くよう教わり、ペアプログラミングで TDD のリズムやテクニック をイ等していき、またプロジェクト内外のソースコードを見て学んできた。仕事の上 では、スクラッチではもちろん TDD を使し、、既存コードがある場合でもそれも TDD で 開発されてきているので、 TDD で追加変更をするうえで特段の障害はない。結果数年 後には、広い意味のプログラマーとしてはまだまだ発展途上であるものの、 TDD プロ グラマーとしては一級に成長している。 こうした環境は新たに TDD を始めるのに格好である。整理すると、以下のような要因 がある。 TDD 以外ありえないという強いモチベーションがある。逆にいうと、あたりまえ であるため、 TDD というものに対して特別なモチベーションを必要としない。 先導者、指導者がそばにいて、実演や実践も見られるし、疑問もすぐに解決でき る。 TDD のためのツー外ーや環境がそろっている。テスティングフレームワークだけで なく、個丿、環境でテストを誡 - しず実彳〒茆るよう支援するツール、 0 環境、など。 よいお手本がある。 テストを簡単に追加できる既存コードベースに対して TDD をしている。 TDD を一から始めるときには、まずモチベーションが必要となる。 TDD を始めようと いう気持ちがなくて始めることはない。モチベーションを引き起こすには、書籍や記 事で TDD を知ったり、 TDDBC(TDDY-- トキャンフ ) へ参加したりするのが妥当である。 筆者は TDD ライプと称して、ペアプロで TDD を実演して見せながら、 TDD のメリット 103
クライアントのこ意向で、最後に「ライトニングトークス大会」を開催したこれ は、参加者全員が 30 分でオンサイト研修の感想を書き、発表するという興味深い内容 であった。 盛況の内に、オンサイト研修は幕を閉じ、「やってみればできるもんなんだ」と、 自分に対する大きな自信に繋がった。 3. おまで巻き込んだオンサイト研修 2012 年 4 月。 勉強会で知り合った方に頼み込んで、オンサイト研修を実施させて頂いた 開催内容の言田をメールで決めている中、「お客様も一に参加するが良い か ? 」とのお問い合わ迂を頂いたお客様にと一緒に受けて頂ければ、アジャイ ル開発の導入が一気に進むのではないかと考え、とても興奮したその言市を僕 が務めるなんて、本当に凄いことだと感じた 偶然にもクライアントの社長が、 XPJUG 関西の理事でもある前川直也さんと 交流があり、僕と前川さんの 2 名でオンサイト幵彦を実施させて頂くこととなっ 「 XP 入門」 ・午後 「 TDD 入門ハンズオン」 「 XP ワークショップ」偂川直也さん ) 前川さんと僕のコンビが織りなすアジャイルワークショップに、あちこちで笑 いが起こり、予定畤間を 1 時間オーバーしつつ、研修は無事終了した 研修後の飲み会で、お客様が「 TDD を使えば、豐土から仕様とテストパター ンを提示ることで、品質確保できるのでは ? 」といった、とても車辟万で前向き な意見が飛び出した また、研修の翌日から毎日「ふりかえり」や「ペアプログラミング」を当たり 前の様に実施する様になったとのご連絡を頂し、たたった 1 日しカト修を実施し てし、ないのに、アジャイル開発プラクティスを皮膚呼吸でもするカ様に吸収し、 寒される様になったのである。言市である自分でも、この激変には本当に驚か された 82