開発チームでスクラムを取り入れてから半年が経過したエンジニアです。スクラムマスター、プロダクトオーナーをはじめ全員がスクラム未経験者の状態からスタートしました。（私は開発メンバーの一人でした。）

よくわからないなりに感じたことを備忘録として記述します。

背景

現在、多くのアプリケーションやWebサービスはユーザーの使用方法や利用状況をモニタリングしたうえで、少しでもユーザーの利便性や満足度を向上させるように絶えず改良されています。また、個々のユーザーの利便性や満足度の向上のが、DL数や閲覧数、だけでなく会員数や課金継続率（売り上げ）の向上につながることが期待されています。

そのようなソフトウェアを開発するにあたり、開発当初からソフトウェアの最終形態の仕様を決定することは困難ですし、作り出すソフトウェアが将来的に変更が繰り返されることを前提とした場合、たとえ最初のリリース前であっても、開発初期段階で決められた固定的な仕様を開発期間すべてをかけて作りこむことに多くの無駄が存在することになります。

この前提で『品質の高いソフトウェア』を開発するためには、開発依頼者、及び開発者の両者がソフトウェアの品質を『固定の要求に対してソフトウェアの実装に不良がない（狭義の品質）』ではなく『開発されたソフトウェアを使う人がより満足すること（広義の品質）』と共通に認識し、『ユーザビリティの向上』に対して試行錯誤することが必要になります。

スクラム開発は『要求に応じたソフトウェアの作成』と『作成されたソフトウェアに対する評価の実施』という試行錯誤を可能な限り繰り返すことで、開発期間と予算が限られた環境下で最終成果物の方向性のずれを小さくするだけでなく、想定するユーザの利便性や満足度を可能な限り向上させることを目指します。

スクラム開発のあるべき姿

アジャイル開発の定義

アジャイル開発とは、『正しいと確認できるもの』を継続的に作り続けるソフトウェア開発手法

スクラム(≒アジャイル)開発の定義

スクラム開発も『正しいと確認できるもの』を継続的に作り続けるソフトウェア開発手法だと考えます
- 「正しい」とは単に当初の要求仕様に対しバグがないソフトウェアを提供するという狭義の意味だけでなく、「現状の仕様で当初の目的が果たせるか？」「ユーザーの満足は十分に得られるか？」という仕様面の正しさも含まれます。
- つまりバグがないこと（開発者目線でのテスト）とユーザビリティの計測（ユーザ目線でのテスト）の両方を実施し続けることが必要になります。
- 「正しいことを確認する」ことに対して開発チームとステークホルダが認識を共有するだけでなく、確認そのものを協力しあう必要があります。

スクラム開発の特徴

機能的に『正しいと確認できるもの』を早期に提供することで、ステークホルダによる評価、及びフィードバックを獲得し、製品へ反映させることで、ユーザー価値を向上させる。
ステークホルダから定常的（ランダム）に発生する要求に対し、できるだけ俊敏に（アジャイルに）ソフトウェアを開発して、ステークホルダの不満足な状態をできるだけ短くする。