自分の場合の解釈

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

• 原文と公式日本語訳

  Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

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

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

  ＝マインドセット。目指す状態。

  🚀アジャイル宣言の背後にある原則

  私たちは以下の原則に従う:

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

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

1️⃣　プロセスやツール　＜　個人と対話

Individuals and interactions over processes and tools

• 対比の把握　：　○対話(Individuals and interactions)　⇔　✕命令、指示、説得

  • 推奨されないこと：
    • 上司やクライアントなどの関係が、命令をする役割と受ける役割に分かれてしまっている
    • メンバーに命令したのであとは何もせず待つ
    • 他部署からの指示をうけてただつくる
    • エンジニアへ指示をだした、あとはできるのを待つだけ
    • 一方的に説得する
  • 推奨されること：
    • 役職、部署などの上下関係、人間関係、評価/被評価の関係関係なく、対話をする
    • 指示待ち、思考の受けて側だけにならず、自分事としてチームのメンバーと対話をする。

• 対比の把握　：　○個人と対話(Individuals and interactions)　⇔　✕プロセスの維持、ツールの徹底

  • 例：チケット切ることやプルリクなどのプロセス、営業に同行した際のコミュニケーションではお互いの常識がぶつかることがある。その際、チームで対話をして決める。一方的な指示命令はしない。認識の齟齬があれば、対話する。「私の前職では○○だったのでそうして」「こうするのが当たり前」といった会話で閉じない。
  • 会議のルーチーンや発言ルールなどのプロセスに縛られず、必要だと思ったら対話をする。
  • プロセスの維持、ツールの利用自体を目的化しない。
  • プロダクトにもつくり方にも「正解」があるわけではないので、チームで対話をし、自分たちで定義をする。

2️⃣　包括的なドキュメント　＜　動くソフトウェア

Working software over comprehensive documentation

• よくある誤解

  • ドキュメント(文章)でまとめる必要はない
    • →どちらを優先するかという判断基準の話。文章よりも動くものを優先しようという話。

• 用語理解：動くソフトウェア(Working software)とは？

  • アプリやWEBなどのインターネットサービスを含むが、その狭い定義ではない。

  • 定義例：顧客にすぐに価値を届けるものに焦点をあわせる。すべての種類のプロダクトや成果物は「動くソフトウェア」に相当する。※その成果物によって「動くソフトウェア」に該当するものは変わる。下記例。

    成果物	「動くソフトウェア」に該当	「包括的なドキュメント」に該当
    プロダクト	Figmaのプロトタイプやモック、MVP	プロダクトの仕様書、ドキュメント、プレゼン資料
    キャンペーン	SNSやメールでテストを実施	エクセルの計画書、パワポのプレゼンスライド
    書籍	章のサンプル、ネーム	企画書
    ケーキ	試してつくる/試し焼き	細かいレシピを検討する
    プレゼン	ラフなプレゼンスライドや実際にしゃべって練習すること	文字による説明文

    定義と表の出典『みんなでアジャイル　変化に対応できる顧客中心組織のつくりかた』P44

• 動くソフトウェアがなぜ「包括的ドキュメント」の価値に優先されるのか？

  • 動くソフトウェアがあれば、ユーザーやメンバーが具体的に利用することができ、利用を通じて認識の齟齬の修正や、価値があるかどうかのフィードバックが容易になりかつうけとれるフィードバックの量が増えるから。
  • ユーザーのFBの結果、価値が間違っていれば、修正が早い段階できるから。

• MVPとは？

  • Minimum Viable Productの略。特定の体験の価値を十分検証するためだけの最小限コストをかけた動くもの
    • ※定義はいろいろある。
      • 『リーン・スタートアップ』の定義：
        • 検証したい仮説について、「構築−計測−学習」のループを最大限まわせる最小労力のプロダクトや体験、機能。
        • 学びのプロセスをすばやく始められることが重要。
        • 「その課題を解決できれば人々は使ってくれるのか」「ユーザーが使ってくれたら、それをもとにして実際に価値のある製品を作れるのか」を考える
        • 作り込みすぎたり約束しすぎたりという衝動をいかに抑えるかがポイント
        • MVPで悩ましいこと→　従来的な考え方の品質と相反すること。優秀なプロフェッショナルや職人は、優れた質の製品を作りたいと願う。（能力を試したいし、メンバーや外部に対する見栄。）
      • ※リンスタが古いという記事もあるが、だいたい原本読んでない記事なので気にしないでOK。
        • リンスタの弱点で使い方間違えると小さい改善サイクルに閉じこもってしまうので注意。
        • ピーター・ティールのリンスタ批判は読んどいたほうがいい。

• 動くソフトウェア(Working software)をもっと簡単にいうと「たたき台」。

  • よりよいのは「叩きやすいたたき台」。
    • 例）デマルコの「かかし」と「マクドナルド理論」
  • 「叩きやすいたたき台」への姿勢：
    • 「たたき台」をつくる人がえらい。

3️⃣　契約交渉　＜　顧客との協調

4️⃣　計画に従うこと　＜　変化への対応

「自己組織的なチーム」とは？

「要求の変更はたとえ開発の後期であっても歓迎」とは？

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

参考