4つの価値

プロセスやツール<個人と対話

• 上から言われたことに忠実に従って開発するよりも
• 個人個人がコミュニケーションを取りながら開発を進めていくことが大事

包括的なドキュメント<動作するソフトウェア

• 開発したものをドキュメントで説明するのは難しい
• ドキュメントコミュニケーションから生まれた認識の齟齬によって顧客の想像と違うものを作ってしまったというのはよくあること
• 頻繁に動作するソフトウェアを見せることが大事

契約交渉<顧客とのコラボレーション

• VUCA時代においては最初に決めた契約通りに進めても価値あるプロダクトは生み出せない
• 顧客と開発側がワンチームとなり開発を進めることが価値あるプロダクトにつながる

計画に従うこと<変化への対応

• VUCA時代には計画に従うよりも変化に対応していくことが大事
• 結果的にはお客さんを満足させることにつながる

12の原則

顧客満足

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

• こちらが設定した期限までにシステムが納品されなかった
• ユーザーにとってどの機能が重要か？を考えて、優先度の高いものから迅速にデリバリーしていく
• 顧客満足につながる

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

• 市場の変化によって開発する機能の変更を要求したが開発側が受け入れてくれない…
• 発注側も最初に計画したものを遂行することが目的化してしまい、市場が変化し仮に計画が実態と合わなくっても開発を続行してしまう

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

• 長期間かけて開発チームが作ったシステムが想定と違うものだった…
• 最初に作った仕様書通りに作っても認識違いが生じてしまうのはよくあること

チームワーク

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

• 作りたいものを仕様書としてまとめて開発チームに渡したら、あとは別のことをしていると言うのはよくあること
• 市場の変化に対応していくにはビジネス側と開発者が一つのチームで開発を進めていく必要がある

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

• やって欲しいことを指示する-指示されたことを実行する という関係性は対立を生む

  • 言われたことをやってくれない
  • いつも無理な依頼をしてくる
• プロダクト開発への意欲に満ちた自律的なメンバーでチームを構成し、お互いを信頼すれば、コミュニケーションが生まれて対立はなくなる

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

• 文字情報で意図を伝えることは難しい
• チャットも同様
• 個人的な経験だとチャットでうまく伝えられず文章を考えてる間に無駄な時間を過ごしていた

• 対面で話をするようなマインドと環境が大事

  • POの方にどのように声をかけたら良いか認識を合わせておくなど

開発プロセス・品質

動くソフトウェアこそが進捗の最も重要な尺度です。

• やっとのことでシステムが完成したが実際に動かしてみたらバグがあった
• 例えばパワポなどで作ったもののプレゼンを作成して進捗を共有しても実際の開発状況を知ることはできない

アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

• そもそも市場のフィードバックを得ながらプロダクトの改善をし続けるのだから開発体制も持続可能でなければならない

• ウォーターフォールだと忙しかったりやることがなかったりする

  • 期限の一番最後だけめちゃ忙しいとかよくある
  • 心身に悪影響を及ぼし持続可能ではなくなる -　アジャイルのアプローチだと開発期間を1~4週間程度に区切ることで一定のペースで開発ができるようにする

技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

• 変更ができずビジネスの変化についていけない設計はだめ

• VUCA時代においては変更が取り入れられるような設計が重要

  • オブジェクト指向などの設計手法
• 逆に言うとアジャイルだから設計は適当でいいなんてことはない

シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

• 従来型の開発では最初に要件定義したものを長期間かけて実装しリリースする
• 最後の最後にお客さんからのフィードバックが得られるため、使わない機能を実装していたなんてことはよくある
• 短い開発サイクルでお客さんからのフィードバックを頻繁に得ることで無駄をなくしていく

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

• 優秀な人材を集めても助け合いがなくプロジェクトがうまくいかない…
• システムの品質はそもそも良いチームから出ないと生まれない

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

• 従来型の開発だと定期的に振り返ることがあまりなく、チームによっては開発が完了するまで反省会をしないなんてこともある
• アジャイルは短いサイクルで振り返りの機会を必ず設けて、問題の顕在化と改善策の立案をしていく
• 開発が進むにつれてチームが成長していく