あうとかむ

やったこと。どーでもいいこと。思いついたこと。技術系。読書系。etc.

アジャイルマニフェスト:メモ

アジャイルソフトウェア開発宣言

冒頭

ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている

4つの価値

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

左記のことがらに価値があることを認めながらも、 私たちは右記のことがらにより価値をおく

12の原則

  1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
  2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
  3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
  4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
  5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
  6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
  7. 動くソフトウェアこそが進捗の最も重要な尺度です。
  8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
  9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
  10. シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
  11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
  12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

読み解き方

アジャイルソフトウェア開発宣言の読みとき方 (IPA)

アジャイルソフトウェア開発宣言」に対する誤解と真意

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

原則01 顧客の満足を求め続ける

  • 基本的な考え方

    • 顧客に(QCDの達成ではなく)ビジネスゴールの達成の観点で満足してもらう
    • ビジネスの成否はビジネスごとに異なります
  • 行動規範

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

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

  • 基本的な考え方
    • 最初から要求に明確な答えがないことが多く、作るものが不明確な場合があります
    • 開発の後期であっても、要求の本質を見抜き、与えられたコスト・納期・スコープのバランスと要求の優先順位から、変更の受け入れを判断する必要がある
  • 行動規範
    • ビジネス側の人と開発者は
      • 変化を「新しい価値」の発見の機会ととらえる
      • 改善に繋がる要求を生み出すことに努める
      • 価値があるのであれば、積極的に変更を受け入れる
        • ただし顧客に言われるがままに変更を受け入れることはやめる
      • 間違いについてもオープンに議論する
      • よりよいフィードバックを生み出すようなリリースをする

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

  • 基本的な考え方
    • 長い開発期間中に当初顧客が望んでいたゴールが変わり、顧客が本当に欲しかった成果を得られなくなっている可能性がある
    • 成果物を頻繁にリリースすることで、顧客からフィードバックを得ることができ、結果として顧客が本当に欲しいものを作ることができる
    • たとえ後戻りがあったとしても小さくすませることができる
  • 行動規範
    • ビジネス側の人と開発者は
      • 要求は不確実であり変化することが前提であることを共有する
      • 価値に結びつかない中間成果物ではなく、ビジネス観点で評価できるものを提供する
      • 成果物のリリース間隔をビジネスの観点から決める
      • 市場からのフィードバックを共有する

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

  • 基本的な考え方
    • 不確実性の高いプロジェクトでは、状況が刻々と変化するため、共通の目標が見えないまま進めると、認識の齟齬などが発生する可能性がある
    • 作るソフトウェアの価値やプロジェクトの状況について、常に共通目標に向かってベクトルを合わせながら働く
      • ビジネスの価値を最大化するため
  • 行動規範
    • ビジネス側の人と開発者は
      • 一緒の場所で働けない場合は、工夫して、方向性を共有する
      • 一緒にビジネスを成功に導くという共通目標を日々確認する
      • 全員で双方向のコミュニケーションが図れるようにする
        • 要求の出しっぱなしはやめる
        • フィードバックをもらうために、頻繁にリリースをする
      • 全員が共通認識を持つために、必要最低限のドキュメントを書く

原則05 人の意欲は信頼から

  • 基本的な考え方
    • 意欲のある前向きな人々を集めて、彼らが働きやすい環境を整えることが求められる
  • 行動規範
    • 顧客の価値創造のために、自らが考え、自らの行動と判断に責任を持つ
    • 自分の作業だけでなく、顧客の価値創造のために何ができるかを考える
    • 積極的にデモを行い、顧客からのフィードバックを受ける
    • お互いが協調し、集中して作業できる環境を作る

原則06 コミュニケーションは直接対話で

  • 基本的な考え方
    • 伝えたい情報や開発者間で伝え合う情報の中には、仕様とは異なり、目的、希望、夢、心配ごとなど、正確に表現できないものもある
      • そのような情報は、言葉では伝わりにくかったり、伝える際に齟齬や誤解を起こしやすかったりする
  • 行動規範
    • 決まった仕様を伝えるだけのような一方通行はやめる。
    • 他の役割の人と話すことで自分の範囲を広げ、これまで気づいていなかったことにも気付けるようにする
    • 何か気になることがあったら、直接会話をする
    • しぐさや表情から、言葉にならない本心(心配ごと、違和感)を感じ取りる

原則07 進捗も品質も現物で

  • 基本的な考え方
    • 進捗状況を正確に把握するためには、動くソフトウェアを確認することが、最も信用できるやり方
      • 求められている価値をどれだけ実現できているか
    • この場合の動くソフトウェアは、計画通りに進んでいるかということではなく、市場にリリースできる程度の品質を満たしている必要がある
  • 行動規範
    • 動くソフトウェアを早いタイミングで見せられるように、小さな単位でモノを作る計画を立てる
    • 顧客の期待に合っているか判断する
    • 受入基準をビジネス側の人と開発者で作る
    • 動くソフトウェアに求められる必要な品質が担保されているべき
    • 開発中の仕掛りを極力少なくする
    • 実物に対する受入基準の合格/不合格で測る
    • 実物を触って進捗を測る

原則08 一定のペースでプロジェクトにリズムを

  • 基本的な考え方
    • ゴールを目指して過負荷なパフォーマンスを求められることがある。

      • 無理をした状態では創意工夫をしたり、改善をしたりという意欲が起きない。
      • また、無理をして一時的に生産性を上げたとしても、その無理が祟ってその後の生産性が落ち、結果的にトータルパフォーマンスは低下してしまいます。
    • 開発者の生産性を最大限に引き出し、価値あるものを提供し続けるためには、

      • 開発者だけでなく、ビジネス側の人も心身ともにベストな状態を保ち、
      • 無理のない一定のペースを維持することが重要。
  • 行動規範
    • 定期的に繰り返す「リズム」を大切にする。
    • 一定のペースを保つために、生産性を見える化し、適切に計画を見直しする
      • 持続可能なペースは、開発者ごとに異なる
    • コミュニケーションを密にし、お互いの考えを共有して助け合う
      • 無理が生じている箇所(ボトルネック)を見つけ、助け合って改善する

原則09 よい技術、よい設計、よい品質の追求

  • 基本的な考え方

    • 新しいビジネスを支えるソフトウェアは、状況に応じて、いつでも素早く変更できることが求められる
      • 優れた技術力に支えられた、優れた設計になっている必要がある
      • よい品質には、高い保守性が欠かせない
    • 設計やソースコードの可読性などについて、技術的な問題が蓄積されると、ソフトウェアの保守性が低下し、素早く変更できない状態に陥る
      • 市場の変化への対応が遅くなり、ビジネスを成長させる際の大きな阻害要因となってしまう
    • よりよい技術を追い求め、効果的にその技術を活用することで、素早く、品質よく、変化に対応し続けることができ
    • 技術力を磨き、プロダクトへの適用技術と設計に対して、常に注意を払うことが重要
  • 行動規範

    • 常に最新の技術を学び、効果的な技術はプロダクトへ適用する
    • ソースコードの状態を目視やツールで常に診断し、常に変更して高い可読性を維持する
      • 可読性を高めると、多くの場合、コードの行数は減ります。
    • 自動化されたテストを作成して常に実行し、問題をすぐに発見する
    • 全員上記の行動に価値があることを認める。

原則10 ムダ=価値を生まない、を探してヤメる

  • 基本的な考え方

    • 顧客が求める価値が何かを考え、その価値に直結しない作業や機能をムダと定義し、そのムダを減らすためにたゆまぬ努力をする。
    • ムダの中には、組織にとって現在必要なものも含まれるので、見逃しがち。
    • これまでの常識や慣習にとらわれず、新鮮な目で現状を直視する
    • 日々の作業の中からムダを見つけ、削減することは、身軽になり機敏性を高めるだけでなく、コスト削減と生産性向上にも貢献する
  • 行動規範

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

原則11 よいモノはよいチームから

  • 基本的な考え方
    • 最良のアーキテクチャ・要求・設計は、最良のチーム(=自律型のチーム)から生み出される
      • 自律型のチームとは
        • メンバー一人ひとりが自らの行動、作業に責任を持つとともに、
        • お互いの連携により、チームとしての成果を最大限に発揮することができる
優秀なメンバーが集まったチームだとしても、お互いに連携や協調がなければ、
チームの能力は、個々のメンバーの能力の和でしかありません。あるいは、個々の
作業が重複していたり、相反する作業をしていたりすれば、チームとしての成果に
悪影響を与えます。
一方自律型のチームでは、メンバー一人ひとりが常に改善の意識を持ち、お互
いの能力を高めながら共通の目的や目標に対しての取り組みが継続されます。
そこには相乗効果が生まれ、チームとしてメンバー個々の能力以上の成果を発
揮することが可能になります。その結果、自律型のチームから、ベストな成果が生
み出されることになるのです。
  • 行動規範
    • チーム
      • プロジェクトの達成すべき目的や目標と、それを支える規律・ルールを共有する
      • 自分たちで規律・ルールを決める。
    • メンバー
      • 自ら率先して作業の改善や課題の解決に取り組む。
      • 自分の不得意な作業、領域についてもチャレンジして取り組む。
      • お互いの作業状況をオープンにし、共有する
      • 困っているメンバーがいたら、助け合う

原則12 自分たちのやり方を毎週、調整する

  • 基本的な考え方

    • “ふりかえり”
      • プロジェクトの進行中に定期的に、短い時間で行うこと
      • よいやり方はどんどんよくなり、もし、失敗したとしても(うまくいかなかったとしても)影響を最小限に留めることができる
      • プロジェクトにとって有用ではあるが言いにくいことを言えるようになる
  • 行動規範

    • だらだら続けることはやめる。
    • “ふりかえり” のルールはチーム全体で決める。
    • チームで問題に立ち向かう。
      • 個人の責任を追及してはいけない。
    • 必要に応じて周りに協力をあおいで解決する。
    • 挙がった課題をすべて解決しなくても気にしないようにする。
      • 失敗は許容する。すぐ改善すればよい。

おわりに

  • 変化とスピードが要求されるこれからのビジネスに対応するためには

    • 変化とスピードがプロセスにあらかじめ組み込まれているアジャイルソフトウェア開発にシフトしていく必要がある
  • アジャイルソフトウェア開発へのシフトの阻害要因の一つとして、

    • アジャイルソフトウェア開発宣言」および「アジャイル宣言の背後にある原則」が、日本においては十分に伝わっていないことがあげられる
    • 伝わっていたとしても正しく伝わっていないケースが少なからず見受けられます。
  • 価値を追い求めるために、

    • 常に考え続け、体現し続けていく姿勢こそが、アジャイルソフトウェア開発に一番大事なマインドセット
    • その姿勢を維持し続けるためには、自分たちに合った方法を常に試していく必要がある
    • その失敗の中からより最善の策を見出し、その時に一番よい方法を見つけ出していきましょう。
    • 失敗を、効率よく成功の糧
      • よいと思ったらまずやってみて、うまくいかなければ短いサイクルで「改善」を繰り返していけばよい、という考え方
    • アジャイルソフトウェア開発とは「改善」をたくさん試せる手法