日が経ってしまったのですが、さった 1 月 14 日に沖縄で開催された勉強会のことを書きます。アジャイルプロセス協議会の合宿を兼ねて、沖縄のプログラマーコミュニティであるJava Kuecheと合同で行いました。休日にも関わらず 30 名ほどの参加があり、盛り上がりました。
プレゼンテーションの中で、興味を引いた点を箇条書きでメモします。
- 「ウォーターフォールモデル」が成立するなら、実は最もわかりやすい。現実には、このモデルに合致する「単純な」システムがほとんどない。ちなみに日本では 1 サイクルで終わるという考えだが、米国では 2 回以上のサイクルになると位置づけられている。
- 作業の主体である「人間中心」で考える。1週40時間労働の真意は、モチベーションをあげること、生産性を上げること。
- コミュニケーションを通した合意形成（確認、承認）が正しく行われていない。特に契約においては、信頼関係が大切。
- 自律を意識した組織体でなければ、アジャイルの実践は難しい。
- ビジネス側（発注）と開発側（受注）の対峙ではなく、同じ「問題」と向き合う関係をつくることが大切。
- アジャイルプロセスへの誤解がある。最初のイテレーションの納品だけみると、早く、安く見えるだろう。しかし当初要求をすべて満たしたシステムをつくったあとで評価するなら、ウォーターフォールと変わりない。というのも、つくらないといけないことは誰がどうやっても時間もコストもかかるわけだから。変わるはずがない。アジャイルプロセスは、銀の弾丸ではない。
- 顧客との空中戦をしないためには、「実物」をはやくつくること。実物でコミュニケーションする。
- アジャイルは変化を抱擁する代わりに、あいまいさを排除する。従来は変化を抱擁しないが、あいまいさを受け入れた。仕様があいまいなまま開発を続けてしまう。本来は、仕様が確定すればテスト仕様が書けるはず。しかし現実には「プログラムができなければテスト仕様書が書けない」という。これはよくない。あいまいさがあると機敏に動けない。なお双方が共通理解できている時間は、それほど長くない。あいまいだと、対応すべき範囲が広がってしまう。
- 契約の目的は？ 本来は、PJ を成功に導くためであるべき。実際は、PJが失敗したときの被害を最小にするために書いてある内容が多い。
- 見積の目的は？ 何を見積もっているのか、何のために見積もっているのか？ コストの見積ではなく、このビジネスを成功できた場合のメリット（収益）の見積ができれば。
- アジャイルプロセスだから見積もらない、ということはない。「あなたが、この業務を行うなら、いくらかかるか？」個人によって金額が異なることを可とする。
- プロジェクトの成功とは？ QCD を守ること... それだけ？重要なのは管理体制？ビジネスに対する貢献度を意識するべき。
- 目標は？ アジャイルプロセスを実行することが目標ですか？ 正しくプロジェクトを管理する事が目標ですか？ Engineer の QOL を高めたい。
- アジャイルプロセスの普及度について。「アジャイルしています。ドキュメントを書いていません」というような誤解もあるが、本質を理解している人は少しずつ増えている。ただ、IT 業界全体の普及はこれから。むしろビジネスチャンスは、あるはず。
当日は私もライトニングトークで発表しました。「アジャイルプロセスの実践には、自動生成技術の利用が効果的」という持論を 5 分で、まくしたてました。これはまた別の機会にまとめます。
