アジャイル開発とは(後編)
スクラムとXPの調和

スクラムとXPの調和

本稿では、アジャイル開発プロセスの事例を紹介します。
アジャイル開発の代表的な方法論である「スクラム」と「エクストリームプログラミング(XP:eXtreme Programming)」の特徴を活かし、調和させた開発プロセスの事例です。

スクラムとXPの特徴

スクラムとXPの特徴について、簡単にまとめます。

表 スクラムとXPの特徴
スクラム XP
実態 反復型開発をうまく回すための仕組み
(フレームワーク)
よいものをつくるための知恵の集まり
(パタン・ランゲージ)
チームとビジネスサイドの関係 スプリント期間中は没交渉
・スプリントの前に要求確定
・スプリント後に確認レビュー
全期間に渡って深く関与
・要求の決定、変更、抹消
・受入テストの作成実施
・開発技術者と常に同席
プロセスの特徴 フレームワークの実行に開発技術は不要
・外部干渉を遮断したブレークスルー指向
・ブレークスルーを利用したプロダクトアウト指向
プラクティスの実行に開発技術が必要
・プラクティス自体はマネジメント指向
・顧客との緊密な関係はマーケットイン指向
適した領域 ブレークスルーが必要な新製品の開発 継続的な成長を望む寿命が長い組織
チームに適した人材 能力の高い開発技術者たち ふつうの開発技術者たち
能力が高ければ高くてもよい
人材とチームの能力 早期のチームビルディングが可能
個々の高い能力がチームによって活かせる
プラクティスのほとんどは人材/チームの育成が目的
人材/チームの成長は長期継続的

スクラムとXPの調和

スクラムとXPのそれぞれの特徴を活かしたアジャイル開発プロセスの事例を、具体的なプラクティスをもとに紹介します。


図 スクラムとXPの調和

スクラムフレームワーク

プロセスの骨格にはスクラムフレームワークを利用します。これは、スクラムの「早期のチームビルディングが可能」という特徴を利用するためです。

スクラムフレームワークは、スクラムガイドブックに明確に規定されており、チームが反復増加型の開発サイクルを短期間で修得することが可能です。また、スクラム自体の知名度が高く、フレームワークの導入に対して抵抗感が少ないことも有利なポイントの一つです。

なお、本事例では専任のスクラムマスターは配置しません。スクラムマスターの役割は、リーダーと開発技術者たち自身が担います。


図 スクラムとXPの融合プロセス

PO(プロダクトオーナー)の常時同席

本事例では、POと名乗りつつ、実態はXPの「オンサイト顧客」です。

  • POはチームの一員です。開発技術者と常に同席します。
  • POは機能の受入条件を作成します。また、開発技術者と共働して受入テストを作成、実施します。
  • POは受入テストをスプリントの終了を待つことなく実施します。
  • POはビジネス的な視点に基づき、チームが開発する機能の意思決定を行います。

実態はXPのオンサイト顧客なのですが、スクラムフレームワークのPOという言葉が広く浸透されているため、その名称を利用します。

  • POが開発技術者と常に同席し緊密なコミュニケーションを図ることで、機能の詳細/技術上の制約/ビジネスサイドの目的を明らかにします。
  • 常時同席しているPOが、動作するソフトウェアを直接確認するため、確認待ち時間が最小化され、機能の開発完了までの時間が短縮されます。
  • POからのすばやく詳細なフィードバックによって、使い勝手の良いソフトウェアとなります。
計画ゲーム

POが同席し開発チーム全員で行います。
ビジネスサイドからのリリースタイミングの制約と、チームが開発可能な規模の折り合いをつけることが目的です。

  • 開発技術者は機能の規模を見積り、POは機能の優先順位を提示します。
  • 開発技術者とPOが技術的な見積りと優先順位をもとに、スプリントで開発する機能を決めます。(見積りには実装方法の検討つまり設計行為が必要です)

ビジネス戦略の実現に、開発チームが無理なく継続的に貢献することが可能となります。

ペアプログラミング

開発はすべてペアプログラミングです。プログラミング以外の開発作業もすべてペアワークです。

ペアプログラミングの本質は、単なる技術の伝達や知識の共有ではありません。
ペア間での対話によって自らに新たなナレッジを生み、そのナレッジがほかのメンバーに伝搬されることで、さらなるナレッジを創造する機会が生まれます。

相互作用を重ね、ナレッジのスパイラルアップを狙います。

開発設備も共同所有

ソースコードはもちろん共同所有します。それだけではありません。開発設備も共同所有します。机や椅子、ディスプレイも共同所有です。
一日の仕事が終了したら、毎日毎日所定の位置に格納します。デスクトップPCも配線やキーボードを外して収納します。

整理、整頓、清掃、清潔を維持、習慣化します。
ドキュメント、ファイルの管理方法はもちろん、構成管理(例えばGitのブランチ)や要求管理(例えばRedmineのチケット記事)、ソースコードやテストコードのリファクタリング、開発プロセス、管理プロセス、成果物も整理、整頓、清掃、清潔の維持が習慣化します。

これは全て、品質のためです。ソフトウェアの品質を維持向上させる行動の習慣化のために、共同所有し、毎日毎日綺麗に片付けるのです。

ペアもタスクもクジ引きで

ペアプログラミングの相方は毎朝クジを引いて決めます。ペアが担当するタスクも毎日くじを引いて決めます。
ランダムに決まるペア。ランダムに決まる担当タスク。
公平とか不公平とかではありません。

ランダムに決まると得手不得手が発覚します。

開発技術者たちそれぞれが持つ技術や知識、持っていない技術や知識が、否応なく表面化するのです。
表面化したそのときが、学習の機会です。
より多くの学習の機会を得て、開発技術者の技術や知識、チームの能力向上を図ること、それが狙いです。

テスティングプラクティス
  • 一行テスト
    機能が記載されたシナリオやユーザーマニュアルなどドキュメントの記載通りにシステムが動作するか、ドキュメントの記載一行ずつを全てテストします。
    開発技術者が利用者の仮面を被り、本当に使えるのか?使い勝手はよいのか?使うと嬉しいのか?を感じながらテストすることで、品質向上のポイントを見つけることが、一行テストの狙いです。

  • 探索的テスト
    テストにかける時間を決めた上で、テスト対象を設定し、開発メンバーがユーザー利用の観点で、目標とした不具合検出数を目指してシステムの動作テストを行います。
    検出した不具合を診て、その傾向やインパクトの大きさを検証します。ソフトウェア構造に起因する不具合、処理性能にかかわるような不具合が検出されていれば、異なる発生条件、異なる不具合現象が発生する可能性が高いと判断されます。
    より効果的な品質向上のポイントを探すのが探索的テストの狙いです。

見える化

単なる可視化やグラフ化を見える化と呼ぶことがあるようですが、ここに述べる見える化はそうではありません。
リアルタイムな異常検知と迅速な対応のためのプラクティスが見える化です。
いつもと違う状態、問題が発生する可能性が高まる状態をあぶり出すことを狙っています。
アナログなかんばんやバーンダウンチャートをプロジェクトルームに貼り出します。チーム全員が常に見える状況は必須です。メールで送られてくるスプレッドシートや、バグトラッキングツールでは見える化は実現しません。
貼られている状態、貼り変えようとしているチームメンバー、それ自体が見える化の対象です。
プロジェクトの進行状況が一目でわかるようすること、正常状態と非正常(異常)状態の判別が誰にでも付くことで、リアルタイムな異常検知と迅速な対応が可能になります。

オープンキッチン

チームの一員であるPOはもちろん、その他お客さまを含むステークホルダーにも開発過程のすべてを公開しています。アナログツールによる進行状況の共有だけでなく、内部検出した不具合、規模や工数見積りの予定と実績、開発者間のチャットやブログまでも(生々しい不満も愚痴も悪口も)公開しています。エビデンスではなく、プロセスそのものがお客様の目の前で進行するその様は、さながら「オープンキッチン」です。

オープンキッチンのメリットは以下の2点です。

  • つくったソフトウェアもそのつくり方も常に公開されていることで、チームに、そして開発技術者それぞれに「見られている」感覚が生まれます。その感覚は適度な緊張感と規律を生みます。決して手を抜かないクラフトマンシップと、さらなる品質向上をめざしたチャレンジの組織文化・風土を醸成します。
  • 常に公開されていること、頻繁なインタラクションが発生することなど、ソフトウェアやそのプロセスを介した濃密なコミュニケーションが相互理解を進行させます。チームにはお客様の趣味嗜好への洞察が、お客様には開発チームの技量への期待が生まれ、オープンキッチンが共創の場へと進化します。
優秀な開発メンバーを引き抜く

常に誰かが居なくなるかもしれない。当初からそう宣告します。
要らない人を追放する訳では決してありません。優秀な開発技術者が、よりチャレンジングでエキサイティングなプロジェクトで活躍するためです。

であれば、

  • 残されたチームの能力が決して低下しないようなプラクティスの利用が促進されます。
    「ペアプログラミング」、「ペアもタスクもクジ引き」などのプラクティスにより、1人の異動がチームにインパクトを与えなくなります。
  • いま所属しているチームで活躍すれば、よりやりがいのあるチームに異動できます。
    いま所属するチームで活躍する動機の一つとなります。
  • 優秀な開発技術者がいなくなれば、残された開発技術者に活躍のチャンスが生まれます。
    優秀な開発技術者がチームを去ることが、今後活躍する動機の一つとなります。

優秀な開発技術者の流動性を高めることが、いまのチームにも、異動先のチームにも、異動する開発技術者にも、残留する開発技術者にもよい影響を与えます。

(「優秀ではない人」が「重要ではない仕事」の担当に異動させられる。そんなことが習慣化されてしまえば…、誰が幸せになるというのでしょうか…)

一個流し

複数の機能を同時に着手すると、完了までに時間がかかります。
一つの機能に集中して開発すると、完了までの時間がより短くなります。

工程で分割して、複数の機能の開発を同時に進行させるウォーターフォール開発は完了までの時間がかかります。
また、アジャイル開発であっても複数の機能それぞれを担当割りしてしまうと、完了までの時間がかかります。

一つの機能の開発に集中して開発することを「一個流し」と呼びます。

少々大きな機能であっても設計や実装方法の工夫で、複数の開発技術者が寄ってたかって開発することで、一個流しは実現できます。

開発期間、すなわち提供までの時間を短縮することができるのです。

前編に、こう記しました。

変化の激しいビジネス環境の中で、ソフトウェアに対する要求の変化も激しさを増しています。要求の変化に追従するとともに新しいビジネス変化を生み出すために、より迅速なソフトウェアの提供が求められています。迅速にソフトウェアを開発する技法として、アジャイル開発が近年ますます注目されてきました。

変化に追従し、新しい変化を生み出すためには、よりスピードのある開発が必要です。

一個流しは、「環境の変化に追従」し「自ら新しい変化を生み出す」ためのプラクティスです。

最後に

XPの提唱者の一人であるKent Beckらの著書「Extreme Programming Explained」のサブタイトルは、「Embrace Change」です。

「Embrace Change」を「変化ヲ抱擁セヨ」と翻訳する"Agile practitioner and book translator"がいます。

XPに影響を与えたトヨタ生産方式で知られる大野耐一の著書「トヨタ生産方式」のサブタイトルは「脱規模の経営をめざして」です。
また、トヨタ生産方式を起源とする「リーン開発」の提唱者であるPoppendieckの著書「Implementing Lean Software Development」のサブタイトルは、「From Concept to Cash」です。

「From Concept to Cash」は、発想や要望が発生してから、実体化し、商品となり、価値を認めたお客様が購入し、お金を生むまでの時間のことです。
「脱規模の経営をめざして」は、規模の経済からスピードの経済への変革を意味します。

スピードを高めることが環境の変化に追従するための最大要因であり、変化ヲ抱擁スル態度こそが自ら新しい変化を生み出す源泉だと考えられます。

参考文献

  • Ken Schwaber, Jeff Sutherland. “The Scrum Guide”. Scrum Guides. 2017. https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf, (参照 2018-08-24).
  • Kent Beck. “Extreme Programming Explained: Embrace Change”. Addison-Wesley Professional, 1999, 224p, ISBN 978-0201616415.
  • Kent Beck, Cynthia Andres. “Extreme Programming Explained: Embrace Change”. 2nd ed., Addison-Wesley Professional, 2004, 224p, ISBN 978-0321278654.
  • Mary Poppendieck, Tom Poppendieck. “Implementing Lean Software Development: From Concept to Cash”. Pearson Education, 2006, 304p, ISBN 978-0321437389.
  • 株式会社永和システムマネジメント. “ - eXtreme Programming - Embrace Change”. オブラブ.http://objectclub.jp/community/XP-jp/xp_relate/essential-ec, (参照 2018-8-10).
  • 大野耐一. “トヨタ生産方式――脱規模の経営をめざして”. ダイヤモンド社, 1978, 232p, ISBN 978-4478460016.
  • 神部知明. Agile japan2010 "受託開発におけるアジャイルの取り組み事例". SlideShare.https://www.slideshare.net/slicks/agile-japan2010, (参照 2018-8-22).

ページの先頭へ

Agile+メインビジュアル