実装優先時の考慮点 その４ - パッケージとしてのアジャイル開発 -

実装優先時の考慮点を説明してきました。ここまで実装を優先してリスクを回避する際に、実装したソフトウェアに引きずられない事、自動化により実装・確認・フィードバックのループを早く回すと共にリファクタリングを容易にする事、バランスを考えながら効率の良い言語と環境を選ぶ事を説明してきました。

これらをふりかえると、アジャイル開発のいくつかのプラクティスは、実装優先で開発してリスクを低減する際には実施しないとうまくいかないか、効果が減ってしまうという事に気付きます。

さらにアジャイル開発を見直すと、他のプラクティスも同じように必然であることに気付きます。実装優先をプロジェクト全体に広げるには、チームとしての活動が前提になるからです。

ゴールの共有

インセプションデッキなどによるゴールの共有は、チームが同じ方向に向かう為に必要です。

上流のドキュメントに仕様が定められたプログラムを実現する場合には、ゴールが明確でなくてもそれなりのものが実現できます。しかし、何をどのように作れば良いかを実装して確認する場合には、向かうべき方向と現状の共有が必要になります。

ゴールを共有して、現在の状況を共有するからこそ、今後の進め方がわかります。実装を優先して開発するにはゴールの共有が必要です。

情報共有

実装優先で開発してリスクを低減する場合、開発中に気付いた事やできたものを見て気付いた事を、今後の仕様や開発法をフィードバックしないといけません。しかし、気付きをチーム全体で共有できないと、実装を優先しでも意味がありません。

そこで、気付きを共有して知恵を出し合う仕組みが必要になります。ふりかえりを実施すれば、過去の問題を共有し、今後に活かす事ができます。改善する事はWikiやカンバンボードの注意書きなどにまとめておき、具体的な作業はタスクカードやチケットにすると良いでしょう。

見える化

情報共有はふりかえりだけでは不十分です。実装による確認があまり必要でない場合はスケジュールの制約を利用して期限内にやるべき事を明確にできます。しかし、実装を優先してわからない事を発見する場合は、直近のゴールとしてマイルストーンを定めて迷走しないようにします。

バーンダウンチャートなど短期的なプロジェクトの計画と進捗を可視化する事で、その問題点を見える化できます。タスクボードはイテレーション内の進捗が見える化できますし、チケット駆動開発ならロードマップ全体の進捗を見える化できます。

イテレーションとリズム

マイルストーンはソフトウェアを動作させて知見を得るタイミングです。マイルストーン間の期間が短いと得られる知見が少ないほか、デプロイや説明資料など動作させるために時間が取られるので、自動化してる場合てもある程度の期間をあける方が良いでしょう。

その期間を一定にするとチームはリズムを感じだし、習熟します。一定の周期の中で、計画やリリースなど定型的な作業の期間が安定するほか、メンバーの役割も安定してくるでしょう。それがイテレーション（あるいはスプリント）や組織パターンのロールだと考えられます。

サーバントリーダーシップ

実装優先で開発する際にはメンバーが指示で動くだけではなく、メンバーが能力を最大限に発揮して多くの気付きを得て、その気付きをチームで共有します。

あらかじめ理論的に確認する事が難しい場合、実装して少しずつ確認します。それはリーダーも同じで、全てを理解している訳ではありません。チームのみんなで協力して確認します。

外部とのインタフェースとなる（プロダクトオーナなどの）担当者は、チームのボトルネックになり易く、作業効率化の要として行動しないといけません。関係者の意見を集約し、チームを方向付けます。

サーバントリーダーシップはアジャイル開発への壁となる価値観の壁だと思っていましたが、これも実装を優先してリスクを低減する場合は必然だと言えます。

顧客との協調とドキュメント

対象の業務を最も知っているのは顧客です。成果物や実装の終わったソフトウェアを評価してフィードバックします。効率的なフィードバックを得るには、適切ナタイミングで顧客が関わらないといけません。できれば同席が望ましいでしょう。

組み込み開発の場合には共通ライブラリも開発対象となる事が多く、ドキュメントによる確認を行う事も多いでしょう。また、他チームと連携する場合にも適切なドキュメントが必要になります。

逆に業務が小規模な場合や対象業務を小規模な範囲に追い込めた場合には、ドキュメントがあまりなくてもソースコードで十分な場合もあるでしょう。

パッケージとしてのアジャイル開発

このように実装優先の開発を考えると、アジャイル開発のプラクティスは必然であると思えます。

エクストリームプログラミングでは、各プラクティスの依存関係が説明され、全ての実施が好ましいと考えられてきました。しかし、プラクティス間の依存関係を意識して注意深く代替プラクティスを用いれば、期待するアジャイル開発の効果を得る事ができます。

効果的なXPの導入を目的とした プラクティス間の相互作用の分析 from Makoto SAKAI

ソフトウェア工学の個別の技術がCMMに体系化された事で発展し、大きナ効果を得る事ができました。しかし、それと同時に当時のプロセスモデルに固定化してしまい、実装優先で開発する際の応用を難しくしてしまいました。

スクラム開発などのアジャイル開発は、実装優先の枠組みの中で必要とされる現代の技術を体系化し、パッケージ化したものと考える事ができます。パッケージとして受け入れる事で、効果を発揮するでしょう。

しかし、それぞれのプラクティスがなぜ必要であるかをきちんと理解していれば、本来必要なプラクティスを闇雲に省いてしまう事なく、最適で効率的なソフトウェア開発が実現できると思います。

まとめ

アジャイル開発は新しい技術なので、これまでの開発法をあてはめて理解するのではなく、別物として理解するように言われる事や、守破離のように先ずは守れと言われる事もあるようです。

しかし、上に述べたようにアジャイル開発は、必須と思われるプラクティスを組み合わせたパッケージであると考えられます。今回はリスクを低減すべく「実装優先で開発する」という視点で見直す事で、プラクティスの依存関係を必然性として考える事ができました。

アジャイル開発には、リスク低減以外にもオブジェクト指向の視点やファシリテーションの視点など、様々な視点があります。それぞれの視点で見直す事で、アジャイル開発がより実践的で応用の効く技術になるでしょう。