なぜアジャイルをやってみたいのか考える
退職しましたで、「アジャイルやりたいなぁ」と書いたのですが、もう少し掘り下げてみます。
経験した現場の何がダメだった？
- 成果
- 予算・期間：オーバー
- 品質：低い
- 使いにくい
- バグ多い
いわゆる失敗プロジェクトですね。
経験した現場がなぜダメだった？
- 工程
- 無駄とおもえる作業が多い
- 大量のドキュメント
- 生産性が低いフレームワーク、開発の規約
- 明らかになっているリスクへの無対策により発生するコスト
- 単体テストまで完了させたのにリリースしない機能（予算超過のため）
- コミュニケーションエラー
- 仕様について言った言わない
- ここからは契約外なのでできません（追加費用が発生します）
- 追加要求のみしてくるユーザー、1次受け
- 無駄とおもえる作業が多い
- 体制、組織風土
- 改善提案を受け入れられない
- PDCA・カイゼン活動をしない
- リスクコントロールしない
- 名ばかりの管理者（1次受けの人）
- 形だけのレビュー
- 技術力不足
- 明らかなテスト不足による障害
- 保守性・拡張性に乏しいコード
集約するとこんな感じかと思います。
- 開発工程・契約
- 顧客・開発のプロジェクト管理能力不足
- 開発の技術力不足
じゃあどうしたらいい？
そこでアジャイルという可能性に出会いました。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。
そう、これだよ！
決められているやり方に縛られて契約上にしか価値の無いドキュメントを作るのをやめて開発作業にもっと力を注いで、「契約だからできない」ではなくてどうやったらお互いにWinWinになれるか考えて、実際には必ず発生する変化を前提に取り組めば、プロジェクトが成功する確率はもっと高くなると思いました。
さらに
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
プロジェクトの成功には顧客側の積極的な関わりが必須。
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
ヤル気ない人、定時内に出勤している事が仕事だと思っている人はプロジェクトにとってマイナス。いない方がいいです。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
技術者は技術に対する努力をし続けるべき。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
組織は人の寄せ集めでは無いです。人員を代替可能なものとして見積もるやり方はもうやりたくないです。
というわけで、考え方にとても共感できました。
この考え方に共感できる人が集まっているプロジェクトなら、とても良い仕事ができるんじゃないか、と。
で、どうする？
SI業界でもアジャイル化の動きが出ていますが、結果が出るのはもう少し先かと思います。
となると、Webサービス系の企業にチャンスがありそうです。
でも、今までやってきたBtoBのSIを、ちゃんと成功させてみたいなぁ、という気持ちもあります。むむむ。
