アジャイルバッファマネジメント -2-

昨日は天気に恵まれた北摂地方ですが、今日は梅雨らしい天気になりました。昨夜から結構強い雨が降っています。

ひょうたんの花が沢山咲いています。

前回より新テーマとして、アジャイル型IT開発におけるバッファマネジメントについて考えています。

　　プロジェクトの納期を保護するために、プロジェクト工程の最後に期間のバッファを設ける、バッファマネジメントの概要について前回ご紹介しました。

　　考察を先に進める前に、アジャイル型IT開発について少し触れておくことにします。

アジャイル開発については、もう充分ご存知の方もいらっしゃるでしょうが、基本的な考え方についてご紹介します。

    アジャイル開発は、従来型の開発手法の弱点を補うために考えられました。

    従来型の開発とは、要件定義>基本設計>詳細設計>コーディング>テスト>完成 と言う手順を踏み、基本的にはこの工程を後戻りする事はありません。つまり、各工程で完結した上で次の工程を開始するというやり方になります。一般的に ウォーターフォール型 と呼ばれる手法です。

ではこの手法のどこに問題があるのでしょうか？

    先に書いたように、ウォーターフォール型開発では後戻りが許されません。しかし、どうしても後戻りが必要になる場合があります。

    最も典型的なパターンは、最初に決めた要件が間違っていたか、あるいはビジネス環境の変化などのために、要件そのものが変化した場合です。

    特に後者のパターンが、最近のビジネスの複雑化と変化スピードの加速のため、大きな問題となって来ています。悠長に要件定義に時間をかけていると、環境の変化が追い越してしまうわけですね。

アジャイル開発では、これを回避するため大きな最終目標を決めておいて、そこに到達するために、優先順位を付けた必要な機能を、幾つかの開発サイクル（イテレーションと呼びます）を繰り返すことで、最終形態に近づけて行きます。

　　一つ一つのイテレーションの最後では、実装した機能について実際に動かすしてみて、ソフトウエアの評価とプロジェクト環境の再評価を行います。その上で、次のイテレーションで何を優先して実装するのかを決定し、作業に入ります。

　　こうすることで、環境の変化に対応できることと、実際の機能を動かして検証しながら、次第にソフトウェア全体の目標に近づけて行くことが可能になります。

　　なにより特徴的なのは、アジャイルではスピードを優先することです。そのため、要件定義書などの従来必要とされていたドキュメントは極力作りません。必要な情報はソースコードと、動くソフトウェアにあるという考えです。

　　もちろん難し面も沢山あります。典型的なのはマネジメントのあり方が従来型と大きく異なるため、新しい考え方でマネジメントすることが必要となることです。他にも、一つのイテレーションで予定した機能が実装できなかった場合の対処方法など、考慮しないといけないことは沢山あります。



さて、これで今回のテーマに関わる２つの要素「バッファマネジメント」と「アジャイル開発」の説明が終わりました。次回はこの要素同士の関係について考察を進めて行くことにします。