アジャイル開発の道案内

kan

ビジネス部のITに対する主体性

  • ITの主体は米国ではビジネス部門であるが、日本ではSIer等のITサービス企業であり、それに依存。そのため、日本ではビジネス部門がITを活用した変革できる能力があるとはいえない。

ウォータフォールとアジャイルの価値に対する考え方

  • アジャイル開発

    • 初期の段階でビジネス価値の高いものを顧客に提供し、妥当性を確認する

    • ビジネスの価値の80％は全ソフトウェアの20％で実現されるため（パレートの法則）、この20％を初期の段階から開発する

  • ウォータフォール開発

    • 価値の高いもの、低いものを纏めて最後に提供されるため、必要のないものも作ってしまうことになる

スクラムのルーツ

  • スクラムはトヨタ生産方式（TPS)から始まっている

開発効率

  • 以下の理由でアジャイル開発はウォータフォール開発に比べて、1.5~3倍の開発効率になる

    • スプリントレビューにより確認するため、無駄なドキュメントを作成しない

    • CICDのような自働化ツールを活用して、確認作業・繰り返し作業を効率化する（自動化は死活問題であり、リーダーの優先課題

    • ドキュメントではなく、ソフトウェアを見せて顧客から確認を得る

計画

  • アジャイル開発では予め詳細化するのではなく、開発を始めるときにJust in Timeで最も新鮮な状態でユーザーストーリーを定義する

組織改革

  • WF⇒アジャイルになるためには文化・技術面からの大きな飛躍が求められる

  • ボトムアップでは改革できず、トップレベルの決断が必要になる。トップの説得、人材育成、アジャイルプロジェクトの実績が必要になる。

参考書籍

この記事が気に入ったらサポートをしてみませんか？