意外と知らないアジャイル開発の１２の原則

2023-02-18 24分14秒

アジャイル開発とは

アジャイ開発とはソフトウェア開発を行ううえで重視する「マインドセット」を意味しています。

　このアジャイル開発におけるマインドセットは、従来型のソフトウェア開発のやり方とは異なる手法を実践していた17名のソフトウェア開発者が、それぞれの主義や手法についての議論を行い、2001年に「アジャイルソフトウェア開発宣言」として公開します。そこには、彼らがソフトウェア開発を行ううえで重視している「マインドセット」が書かれており、このマインドセットが、世界中のソフトウェア開発者達に支持され、”アジャイルソフトウェア開発” という名で呼ばれるようになりました。

　そして、このアジャイル開発を実現するために、従うことが望ましい原則、つまり根本的・根源的な取り組み姿勢について「アジャイル宣言の背後にある原則」に明記されています。

https://agilemanifesto.org/iso/ja/manifesto.html

https://agilemanifesto.org/iso/ja/principles.html

アジャイル開発における重要なマインドセット

アジャイル開発におけるマインドセットでは以下の4つの価値を重要視しています。

プロセスやツールよりも個人と対話
包括的なドキュメントよりも動くソフトウェア
契約交渉よりも顧客との協調
計画に従うことよりも変化への対応

　このアジャイル開発におけるマインドセットで重要なのは「プロセスやツール、ドキュメント、契約、計画」を疎かにしていいわけではないという点です。

　上記4つの価値について「左記よりも右記に価値を置く」と解釈できることから、「プロセスやツール、ドキュメント、契約、計画」は疎かにしてもよいと解釈され、アジャイルソフトウェア開発ではドキュメントを作成しなくてもよいとか、計画は考えなくてもよいなどの誤解が生じることがあります。しかし、「左記のことがらにも価値があることを認めながらも」という一文にあるとおり、「プロセスやツール、ドキュメント、契約、計画」にも価値があることを、アジャイルソフトウェア開発宣言では明言しています。故に、アジャイルソフトウェア開発でも“価値のある”必要なドキュメントの作成は行いますし、事前に計画を立てて作業も進めていいきます。加えて、開発を効率的に進めるための有用なツールを活用することも重要になってきます。

　アジャイルソフトウェア開発宣言では、まず「個人と対話、動くソフトウェア、顧客との協調、変化への対応」というマインドセットがあって、そのうえで「プロセスやツール、ドキュメント、契約、計画」を考えるべきであるということを伝えています。

　このマインドセットは、「個人と対話、動くソフトウェア、顧客との協調、変化への対応」として簡潔に表現されていますが、「アジャイル宣言の背後にある原則」を踏まえて独立行政法人情報処理推進機構（以下IPAとする）は以下のようにまとめています。

• 「対面コミュニケーション」
　　個人同士の対話を通じて相互理解を深めることで、よりよいチームが作られる。
• 「実働検証」
　　動くソフトウェアを使って繰り返し素早く仮説検証をし、その結果から学ぶことがよりよい成果を生み出す。
• 「顧客とのWin-Win関係」
　　お互いの立場を超えて協働することにより、よりよい成果と仕事のやり方を作ることができる。
• 「変化を味方に」
　　顧客のニーズやビジネス市場の変化は事前計画を狂わす脅威ではなく、よりよい成果を生み出す機会と捉える。
https://www.ipa.go.jp/files/000065601.pdf

「アジャイル宣言の背後にある原則」の考え方

顧客の満足を求め続ける

「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

基本的な考え方

　最も重要な活動は、価値のあるソフトウェアを利用者に提供することでビジネスゴールを達成することであり、「Quality（品質）Cost（コスト）Delivery（納期）」（以下QCDとする）の向上ではありません。

　多くの企業は、近年の劇的な市場の変化への対応に迫られており、ビジネスを支えるITシステムの構築は企業の存続を左右するほど重要な要素になっています。故に、ITシステムを構築する際に、システム利用者の満足度を高めつつ、ビジネスゴールの達成を最優先に考える必要があります。

　そのため、顧客の満足とは何かを定義することからはじめ、ビジネスの観点で十分に評価可能な動くソフトウェアを素早く継続的に提供し、顧客の満足度がどのような状態なのか明らかにしていきます。

具体的な行動例

ビジネスゴールについて初期の時点で徹底的に話し合う
QCDの達成ではなく、ビジネスゴールの達成を目指す
ビジネスゴールに向かっているかどうかを常に確認し、方向がずれていたら素早く修正する
ソフトウェアで実現すべき要件を利用者の立場で一緒に考える
利用者が価値を確認しやすい単位に機能を分割し、素早く継続的に提供し続ける

要求の本質を見抜き、変更を前向きに

「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

基本的な考え方

改善に繋がる要求は、新しい価値を見つけた証拠です。

勇気を持って変更を受け入れることで、変化に強くなり、企業の競争力を高めることに貢献します。

　従来は、定型業務の処理や記録を扱う基幹系システムなどのビジネスが多く、最初から作るものが明確なシステムが大半でした。しかし、人とモノの繋がりを重要とする業務改善や変革を目的としたビジネスは、最初から要求に明確な答えがないことが多く、作るものが不明確な場合があります。

　このような、特性が異なるITシステム開発を、従来と同じソフトウェア開発プロセスで実施しても、成功確率は上がりません。そもそも、顧客にとって価値のないシステムを作っても、意味はありません。そこで、たとえ開発の後期であっても、要求の本質を見抜き、与えられたコスト・納期・スコープのバランスと要求の優先順位から、変更の受け入れを判断する必要があります。

具体的な行動例

変化を「新しい価値」の発見の機会ととらえる
改善に繋がる要求を生み出すことに努める
価値があるのであれば、積極的に変更を受け入れる
– ただし顧客に言われるがままに変更を受け入れるというわけではない
間違いについてもオープンに議論する
– 例えば小さな間違いをそのままにしておくことにより、重大な問題の原因になる
よりよいフィードバックを生み出すようなリリースをすることに努める

成果物を2-3週間で、リリースし続ける

「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference tothe shorter timescale.”

基本的な考え方

　積極的にビジネスの舵取りができるよう、開発者は2-3週間の短い時間間隔で、成果物を定期的にリリースし続けます。

　リリースするというと、比較的長期間(例えば半年から数年など)の開発の後に、顧客に納品することを思い浮かべるかもしれません。しかし、長い開発期間中に当初顧客が望んでいたゴールが変わり、顧客が本当に欲しかった成果を得られなくなっている可能性もあります。

　ここでいう短い時間間隔とは、2-3週間から2-3ヶ月です。ビジネスゴールが変わって要求が変更になることが想定される開発の場合は、仮説検証型で進める必要があります。成果物を頻繁にリリースすることで、顧客からフィードバックを得ることができ、結果として顧客が本当に欲しいものを作ることができます。また、たとえ後戻りがあったとしても小さくすませることができます。

具体的な行動例

要求は不確実であり変化することが前提であることを共有する
価値に結びつかない中間成果物ではなく、ビジネス観点で評価できるものを提供する
成果物のリリース間隔をビジネスの観点から決定する
市場からのフィードバックを共有する

全員で共通の目標に向かおう

「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。」
“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.”

基本的な考え方

顧客が求める価値が何かを考え、その価値に直結しない作業や機能をムダと定義し、そのムダを減らすためにたゆまぬ努力をしましょう。これは、アジャイルソフトウェア開発における本質の活動です。ムダの中には、組織にとって現在必要なものも含まれるので、見逃しがちです。

これまでの常識や慣習にとらわれず、新鮮な目で現状を直視しましょう。日々の作業の中からムダを見つけ、削減することは、身軽になり機敏性を高めるだけでなく、コスト削減と生産性向上にも貢献します。

具体的な行動例

顧客の要求を鵜呑みにせず、「その要求は本当に必要か」確認する
– 顧客にとって本当に必要か分からない機能を、先に作ることは無駄になることが多い
ムダについて、真剣に話し合う
– 例えば、ある作業を100倍して、その価値も100倍になっているか考えてみる
価値をもたらさない会議や報告をなくす
– 進捗会議は短く、報告資料はシンプルにする

よいモノはよいチームから

「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。」
“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.”

基本的な考え方

チームが成長し続けるためには、定期的に(長くても2〜3週間、オススメは毎週)ふりかえり、自分たちのやり方を調整し続けることが大事です。“ふりかえり”というと、プロジェクトの最後の反省会を思い浮かべるかもしれませんが、たいていの場合、次のプロジェクトは周りの環境もチームも異なることが多く、“ふりかえり”の結果を活かすことは難しいでしょう。

　この原則で言う“ふりかえり”とは、プロジェクトの進行中に定期的に、短い時間で行うことです。 “ふりかえり”を繰り返すことで、よいやり方はどんどんよくなり、もし、失敗したとしても(うまくいかなかったとしても)影響を最小限に留めることができます。定期的な“ふりかえり”の場があることで、チームメンバーは、プロジェクトにとって有用ではあるが言いにくいことを言えるようになります。