[#Agile] アジャイル開発の課題と対策 その２

前回の続きです。対策を考えるとどのようになるか考えます。

以下の図ではDBとUIとしていますが、基盤部とUIでも構いませんし、全く異なる切り分けでも構いません。順序に関する制約があるなら、同じようなことを検討すると思います。

前回の復習

アジャイル開発の普及が遅れている理由として、以下の３点をあげました。

• 日本では データが変わると大変なことになる」と考えている DOAが普及している
• ビジネスを重視するRADが普及しなかった
• ルールの明確で複雑な基幹業務が多い

これらによって、逐次開発する事に対する危機感はある反面、必然性がなかった事になります。

そこで、解決策として、ベーム氏の「アジャイルと規律」から

• リーンやFDDなどのリスクベースのアジャイル手法と計画駆動を組み合わせる
• アーキテクチャ設計を予め行う
• 開発内容にあわせて計画駆動のチームとアジャイル開発のチームに分ける

の３つを取り上げ、さらに

• ビジネスの視点でアーキテクチャを考える

という提案をしました。

開発イメージ

今回は、アーキテクチャ設計後の開発をどのように行うかを考えてみます。
まずは基本イメージを見てみましょう。

WF（ウォーターフォール）は予めDB設計を行った上で、UIなど他の部分を開発するでしょう。アジャイル開発はDBとUIの開発を並行して行います。単純に考えるとこのようなイメージですが、実際はもう少し工夫しているでしょう。

現実のWFでは、DB設計が終わるまでにプロトタイプを開発しています。開発者を早めに投入する事でコミュニケーションを容易にし、DB設計が終わった後にすぐにUIの開発ができるようにします。

プロトタイプは性能などの評価、操作性の検討、 HTML作成(MayaaやWicketのようにHTMLがそのまま使えるフレームワークもありますね)、 横展開のひな形、部分的な本格実装、などが考えられます。WFなのでこの期間には各種設計書も書かれるでしょう。

現実のアジャイル開発では、ストーリ単位で開発されますので、DB設計とUI設計が交互に行われるでしょう。ある程度仕様が固まるまでDBは構築せず、モックで開発を進めるかもしれません。

アジャイル開発では単純に優先度の高い順に開発すると思われるかもしれませんが、手戻りのリスクも考える必要があります。早く実装するとリスクの下がるものと上がるものがありますので、リスクを考慮して開発順序を決めます。

チームに分ける場合は、WFとアジャイル開発を組み合せます。粗な関係で分離できるなら、インタフェースだけを決めておいて単純な組合せで独立して開発できるかもしれません。

もし、開発法で分けられないなら、DBチームとUIチームに分ける方法もあります。UIは共通処理の開発やモックによる開発などをすすめ、DBは早めに決めるべき所から設計します。チームは厳密に分けてしまうと、作業の融通が利かなくなりますので注意してください(多能工ではなくなりますので、アジャイル開発のアンチパターンですね)。

まとめ

この他にも色々な組合せがあると思います。単純にこの方法が良いというものではなく、ベーム氏の５つの重要要因にあるように、開発対象の業務や規模、メンバーのスキルなども考慮すべきだと思います。

物事を２元論的に捉えると、違いが明確になってわかりやすいという効果があります。しかし、ソフトウェア開発は複雑な作業の組合せであるほか、業務と直結していますので、「試してみる」ということはなかなかできません。

プロジェクトを成功させるには「xxと言われているから」ではなく、具体的なイメージができる程度には理解が必要です。なぜそのようになるかを理解し、チームの能力を最大限に生かすべく、様々な工夫を凝らす事が、大切だと思います。（続く）