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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

であれば、

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

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

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

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

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

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

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

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

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

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

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