アジャイル開発の12の原則（前半）

どうも”おもり”です。

アジャイル開発には12個の原則があります。

今回はその1から6までの原則について説明をしていきます。

①顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

顧客が求めているアプリケーション・サービスを作ることが最優先です。

https://dic.nicovideo.jp/a/顧客が本当に必要だったもの

この図は、顧客が本当に必要だったものが、各チームによって解釈が全くことなってしまう例を面白おかしく描いた有名な図です。

ユーザーの要望が開発メンバーに届くまでに多くのチームによる伝言ゲームが行われます。その間に、本当にユーザーが思っていたものと違うものになってしまうなんて起こって当たり前です。

②要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

先程述べたように、毎日動くアプリケーションが動く状態を維持できる場合で開発の後期まで迎えたとします。その場合、ほとんどの実装は、ユーザーの要望に近い形で完了しています。

その中で、要望の変更が来たとします。根本的な変更が必要でない場合、開発者側もそれぐらいの変更なら対応できると答えられます。なぜなら動くアプリケーションが用意できているので。

③動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

こちらの第1原則のために必要なものです。動くアプリケーションを常に用意しておき、いつでもユーザーやPMに見せられる状態を維持します。開発者側もPMにこの状態で良いか、いつでも確認が取れます。

しかし、動くアプリケーションがリリースの1ヶ月前にしか見せられなかったらどうでしょう。始めて見せた時に、PMから『いや、こんなのじゃない』と言われてしまったら、大幅な見直しをしなければなりません。残り1ヶ月しかないのに大ピンチです。そうなると、求められた機能の一部をリリースできなくなったりします。

④ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

ここで言うビジネス側というのは、実際にユーザーに接する営業や企画・PMのことを指します。

先程も述べましたが、ユーザーが求めているアプリケーションを正確に開発者が作るには、適切に要望が伝わらないといけません。そのため、日々開発者側から完成形を見せ、ビジネス側の人からフィードバックを常に受けることが重要です。

もちろん、常に動くアプリケーションを開発者側が用意していることで、変更依頼や追加要望には柔軟に対応できるようにはなりました。それでも、作ったものが1回で要望通りに完成すれば、それが最も効率が良いです。

⑤意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

これは実際めちゃくちゃ大事です。意欲に満ちているというのは、作っているアプリケーションに情熱を持ち、自分でより使いやすいアプリケーションにしたいと常に考えられることです。

開発者側からも、最新技術の取り入れによってもっと便利にできたり、パフォーマンスを向上したり、デザインを他のアプリケーションと見比べて改善したいという意見をビジネス側の人に伝えられます。

⑥情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

ビジネス側の人達も日々忙しく、会社にいないことが多いかもしれません。出先でインストールしてもらい、見てもらうとします。そして、電話でフィードバックを得たとします。実際に画面を見た上で、本当に問題な所を伝えた方が、ミスリードには繋がりにくいです。

そのためには、実際にアプリケーションを見ながら話し合う方が効果的です。オンライン会議で、ビデオをONにしながら話す方が、声だけで伝え合うよりは効果的です。

今日はここまでにします。次回はアジャイル開発の原則（７～１２項）について説明していこうと思います。お楽しみに！