Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

アジャイル開発とプロトタイピングとPoCと……の使いわけ

アジャイル宣言では「顧客とのコラボレーション」がうたわれているけれど

  • 顧客が何を作ったらよいか分からないのでアジャイル型開発にする
  • 仕様を決めるためにユーザの声を聞いた結果、仕様の決定権がユーザ側にあることになってしまう
  • 開発リソースの投下を行うプロダクトオーナーは顧客側にいるが、収支面の判断責任はベンダー側の責務になっている

みたいな状況まで想定した書籍ってあるのかな。「仕様が分からない」のと「仕様を決められない」のは別のはずだと思うんだけど、そういった点が状況ごとにカバーされていると嬉しい。たとえば以下のような感じかな。

  • 何を作るか決めるのは顧客で、何を作ったらよいかまだ分かっていない …… ペーパープロトをすること、プロダクトオーナーによる仕様決定を投資判断として顧客側責務にすること、それに合わせた契約形態にすること
  • 何を作るか決めるのはベンダーで、何を作ったらよいかまだ分からない …… モックアップを作ってPoCや研究開発の建て付けでユーザビリティテストをすること、ユーザビリティテストの対象者と仕様決定の権限を持つ人とは重なってはいけないしソフトウェア仕様以外の利害関係があるのもいけない
  • 何を作ったらよいかは分かっているが、どう作ったらよいか分からない …… 要検証項目を列挙してプロトタイピングをすること、研究開発費で開発するか技術研究組合で開発すること
  • 何を作ったらよいかは分かっているし、どう作ったらよいかも分かっているが、それが本当に役に立つのか分からない …… アジャイルソフトウェア開発にすること、PoCという建て付けでもよい
  • 何を作るか顧客側は分かっていないがベンダー側で決められるし、どう作ったらよいかも分かっているが、それが本当に役に立つのか分からない …… アジャイルソフトウェア開発にすること、PoCという建て付けでもよい、プロダクトオーナーはベンダー側にすること
  • 何を作ったらよいかは分かっているし、どう作ったらよいかも分かっている。開発予算は年度ごとに決められている。今年度中に作らないといけない機能は決まっているが、優先度の高い機能からリリースしたい(先にリリースした機能ほど多くのフィードバックをユーザからもらいたい)。予算は一通り機能を揃えるので手一杯なので、今年度中の改善作業はできなさそう。早めにリリースした機能に対するフィードバックを見て、来年度以降の予算案を作成し、改善は来年度から行う …… 単年度契約にして、リリース間隔を狭める方針で進めた方がよいのでは?