#2-19 アジャイルソフトウェア開発宣言
前回までの記事で、プロジェクトのスタート地点に立ったあたりの話は概ね触れたので、今回は少し狭いジャンルの、ソフトウェア開発の「アジャイル」のスタート地点のお話をしようと思います。
↓アジャイルについて
以前掲載していた、アジャイルソフトウェア開発宣言について、少し深掘りします。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。
すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく
アジャイルソフトウェア開発宣言は、アジャイル開発の土台になっている考え方なので、アジャイルを理解するためのスタート地点、とも言えます。
アジャイル宣言の背後にある原則
アジャイルソフトウェア開発宣言には、「アジャイル宣言の背後にある原則」が１２コ明記されています。
私たちは以下の原則に従う:
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
①「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」
（Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.）
：QDC（※）を満たしたモノではなく、ビジネスゴールを達成して満足してもらえるようなモノを作る必要がありますよ、という話です。
※QCD……Quality（品質）、Cost（費用）、Delivery（納期）のこと。
まず、顧客（ユーザー）の満足とは何か、ビジネスのゴールは何なのかを明確に定義して、ビジネスの観点で評価可能な動くソフトウェアを素早く継続的に提供して、満足度を分析し、ビジネスゴールの達成を目指します。
私はよく「どんなユーザー体験を作るのか」という切り口で話します。
②「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」
（Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.）
：言われるがままになんでも受け入れるワケではなく、開発後期でも要求の本質を見抜き、価値の上がることなら、勇気を持って受け入れましょう、という話です。
③「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」
（Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.）
：アジャイルと言えばコレという程、かなりユニークな原則です。短い時間間隔でリリースするので、仮説→検証→仮説→検証……と、短い期間で多くのフォードバックを得ていきます。
、ビジネス側も開発側も、要求は不確実であり、変化することが前提という認識をもつ必要があります。
④「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。」
（Businesspeople and developers must work together daily throughout the project.）
：ビジネス側と開発側は、共通の目的を明確に認識して、一緒にビジネスを成功に導く、という気持ちで協働しましょう、という話です。
↓関連記事
⑤「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。」
（Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.）
↓関連記事
⑥情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
（The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.）
↓関連記事
⑦「動くソフトウェアこそが進捗の最も重要な尺度です。」
（Working software is the primary measure of progress.）
：進捗確認には、報告書などの文書ではなく、動くソフトウェアで確認することが非常に大事です。
進捗を、％で測るのではなく、実際のテストの合格・不合格で測りましょう、という話です。
私は、実際に動くソフトウェアで確認するまでは、「順調です」という報告を半分くらいしか信じませんし、上長に「順調です」とも言わないです。実際に動かしてみないと気づけないことや分からないことが沢山あるからです。
⑧「アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。」
（Agile process promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.）
：無理のない一定の開発ペースを保つことがビジネスの成功に繋がる、という話です。
⑨「技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。」
（Continuous attention to technical excellence and good design enhances agility.）
：より良い技術を追い求め、その技術を活用しましょう、という話です。
⑩「シンプルさ（ムダなく作れる量を最大限にすること）が本質です。」
（Simplicity--the art of maximizing the amount of work not done--is essential.）
：価値につながらない作業や機能は無駄なので、減らす努力をしましょう、という話です。
「その要求は本当に必要か」という検討をして、顧客にとって本当に必要かわからない機能を先に作ってしまうような「つくりすぎの無駄」を極力避けるようにすべきです。
また、会議を短く、報告資料シンプルにするなど、日比の作業の中から無駄を見つけたら削減して、コスト削減と生産性向上を意識しましょう。
⑪「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。」
（The best architectures, requirements, and designs emerge from self-organizing teams.）
↓関連記事（「遂行期」を目指しましょう、という話です）
⑫「チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。」
（“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.）
：この原則でいう「振り返り」は、プロジェクトの進行中に、定期的に短い期間で行うことです。（最後にまとめて大きく、ではないです）
チームの成長のためには、理想で言えば、週に1回の振り返りを行い、自分達のやり方を調整し続けることが大事です。
プロジェクトの作業を全て原則通りに進めることとは難しいですが、原則を理解して、変化とスピードに対応できるプロジェクトマネジメント力を身に付けることが大事です。
この記事が気に入ったらサポートをしてみませんか？