アジャイル開発はスペシャルな手法ではない
アジャイルについて過去にも説明会に参加する等、ある程度の内容は把握しているが、開発方式というよりも精神論の側面が強く、システム開発の上でやるべきタスクは従来のウォーターフォールと変わらないのではないか。 例えば設計書に対する記述内容を薄くできるわけでもなく、各成果物に対する検証(レビュー、テスト)を省略できるわけでもない。 ある文献には、アジャイルにも向き・不向きの風土、人の性格があるとという論調もあり、開発工数の短縮により残業時間を減らし、個人の売上が減ってしまうという矛盾を指摘する人もいる。
そのような側面から、アジャイル開発とは、PDCAサイクルを短期に回していくという、きわめて簡単な思想に基づく開発スタイルなのではないか。そしてそれに最低限必要な要素の一つのは、作業者の予定工数を把握すること、すなわちリソース管理が特に重要なのである。 PJに携わってつくづく思い知ることは、投入可能な工数の把握ができないことである。それは現場の仕組みや仕事に対する考え方、文化によるものでもあるが、アジャイルにせよウォーターフォールにせよ、投入可能なリソースを把握することが、全体計画を策定する上での第一歩ではないだろうか。
朝会の有効性
アジャイル開発の方法論の一つに、コミュニケーションを重視するというものがある。コミュニケーションを密にすれば、お互いの認識する最終イメージも近くなり、設計フェーズで用意すべき成果物に多くの時間を割かず、ドキュメンテーションの負担を軽くできると言う。 仕様書の簡素化だけが目的ではないが、朝会を行うことでチームメンバーが抱えている課題をデイリーに共有することができる点で、非常に有効と言える。朝会の効果は主に次の項目と言えよう。
- 課題の共有
- Face to faceでのコミュニケーション
- 信頼関係の構築
- 仕事以外のコミュニケーション
バーンダウンチャート
設計に対する検証(=レビュー)が十分になされていない状況では、仕様書の品質が十分に担保されているとは言えず、仕様不備による変更対応が頻発することは仕方がない。 また、バーンダウンチャートにおける全体作業量が日々増加している場合、いつチャートがX軸に到達するのかを予測することは困難である。 このように、全体作業量が変わりやすい状況においてバーンダウンチャートを導入しても、そのメリットを感じることは無いのである。 バーンダウンチャートにより作業の収束傾向を把握するのであれば、作業の全体量を確定させる必要があり、それはつまり上流側での設計をフェーズごとに仕様を確定させていく必要がある。 全体作業量の変動を見ず、あるいは全体作業量が増加していることを問題とせずに、日々の残作業量が増減を繰り返していることに着目しても、このツールが果たす効果はゼロと言える。