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