アート・オブ・アジャイルデベロップメント読書会 第1章
===
###### tags: `アートオブアジャイルデベロップメント読書会`

[読書会インデックスページ](https://hackmd.io/qzr55OUxR_aKBNKZjRaxwA?view)

# Discord開始位置

* [1回目 Discord開始位置](https://discordapp.com/channels/767540649418686486/774111081634332673/777486569015345192)
* [connpass募集ページ](https://agiledevs.connpass.com/event/193498/)
* ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs)
* [2回目 Discord開始位置](https://discord.com/channels/767540649418686486/774111081634332673/785091823315845141)

# 自己紹介

- ファシリ役
- 松岡
- タイムキーパー役
- 坂本
- 読み上げ役
- こばやし（t2_Kobayashi）
- まだい(madai0517)

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

[アートオブアジャイル輪読会はじめの1歩 - Speaker Deck](https://speakerdeck.com/t2kob/atoobuaziyairulun-du-hui-hazimefalse1bu)

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はアジャイル非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1: :+1: :tada:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 参加者アンケート | |
| 20:25-20:35 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:35-21:35 | 60分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:35-21:40 | 5分 | 次回開催日と読む範囲決めてクローズ | |

# 下に感想などを書いていって下さい。どんな些細なことでもOKです。

---

# 「はじめに」&「第1章 なぜアジャイルなのか？」(12ページ)
## 目安の時間
- 30分

## 感想・気づき

### 監訳者前書き
> 監訳者前書き、本文を読む上で助けになる（補助線になる）ようなことを結構書いてくれていて、ちょっと飛ばすのはもったいなかったかもしれない

というコメントをいただいたので、こちらについても感想などあれば記載お願いします！

* > 　なお、本書の題名となっている、『The Art of Agile Development』ですが、ここで言う Art は日本語の「芸術」とはちょっと違います。アートはサイエンスに対する言葉として用いられ、人間が関与する「技芸」と 訳したほうがいいかもしれません。例えば、日本語でいう、「文系・理系」は英語では、「Art/Science」ですし、空手や柔道などの武芸は「Martial Arts」といいます。これらは、人間が具体的なプラクティスから体系化した技なのです。本書の求めている「道」が、この Art という言葉にはこめられています。 - p.x
* [Discord](https://discordapp.com/channels/767540649418686486/774111081634332673/777497647682420737)
* 「はじめに」でも「道」や「極める」という表現が頻繁に使われているあたり、本書の *Arts* に込められた（上記のような）意味を確認しておく意義はありそう
* Liberal Arts(教養)の *Art*
* 孫子の兵法も "art of war".
* 「道」の概念や、型、守破離の考え方が念頭にありそう。

### 初めに
* > エクストリームプログラミングはソフトウェア開発のエチュードだ。 - *p.xv*
* XP全体を、ソフトウェア開発のための「練習」として明確に位置づけているのを見るのは、初めてかもしれない
* c.f. https://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%81%E3%83%A5%E3%83%BC%E3%83%89
* > [練習曲](https://ja.wikipedia.org/wiki/%E7%B7%B4%E7%BF%92%E6%9B%B2)のこと。
* > 私たちも、開発の現場でアジャイル開発を実践してきて、やはり「アジャイルは難しい」と感じています。技術的にも人間的にもたゆまぬ自己鍛錬が必要になります。 (...) 本書の「はじめに」には少し突き放したような表現で「練習あるのみだよ！」と書かれています。ユーモラスに表現していますがここには本質が潜んでいます。 - p.x
* ↓の部分について、なぜ破って良いのか、なぜ手を加えて良いのか、に対しての良い説明（XPはあくまでエチュードに過ぎないから）にもなりそう
* > 確信が持てたらルールを破ろう。自分たちの状況に合わせてもっとうまくいくように、私たちの指針に手を加えよう。 - p.xiv
* > プラクティスは、スタート地点としてはOKですが、 それを自分たちで考えて、カスタマイズし、現場に適合させてはじめて定着するものです。 - p.xi
* ↓の部分について、なぜ最初は遅くなるのか、の説明にもなりそう（練習の効果がすぐ本番に出ると思うなよ、的なアレ）（量が質に転化する）
* > チームがアジャイル開発を学ぶには、そのための時間が必要になる。学んでいるあいだは、仕事のスピードは1/4とか1/2とかになってしまうだろう。速くなるんじゃなくて、遅くなるんだ。 - p.3
* (あまり関係ない話だが)プラクティスを実践して、慣れたら変えていくのを推すスタンスが、武道の「守破離」の考え方に似ている。空手の話を出したり、アジャイル開発の「道」という言葉を使用していたり、影響を受けてそう。
* P.xiii「まず、プラクティスに従おう。そして何が起こるのか観察しよう。なぜうまくいくのか、なぜうまくいかないのか、考えよう。それから、もう一度やってみよう。何が同じだったか？何が違っていたか？なぜだろう？じゃあ、もう一度やってみよう。何度も何度も。」
* まずは何度も試して、観察して、考えろと。

### 1章冒頭

p.3 「単に生産性を上げるためだけにアジャイル開発を導入するのはお勧めできない」:+1::+1::+1:
* アジャイル＝生産性向上 は一般に思われている気がする
* 下にもありますが生産性とは何ですか?
* 「アジャイル」と日本語検索して1、2件目の記事にそう書いてある！悲しい
* 「アジャイル」と同等の比較対象になるのは「ウォーターフォール」だけなのでしょうか？ XPやスクラム、他の開発手法などとの関係を明らかにしたいです。 :+1: :+1:
* 「生産性」とは何か :+1: :+1: :+1: :+1: :+1: :+1::+1::+1: [Discord](https://discordapp.com/channels/767540649418686486/774111081634332673/777498607242838037)
* 「費用対開発機能数」ではなく「費用対収益」 となることがポイント
* :memo: ↑の定義って、本文のどこかで言及あった感じでしょうか？（一般によく注意されることという印象はありつつ、本書でもその意味で「生産性」という言葉を使っているのだろうか、の確認） :+1:
* どこまでが本文の内容から実際に読み解ける部分で、どこからが個人の知識・体験と紐付けた解釈なのか、注意しながら読みたいところからの確認です
* 失礼しました、投資収益率に関しては「個人的な成功 経営幹部や上級管理職」節で明記されていたものです。生産性、というものとの結び付けは個人的な解釈です。 :+1:
* 作るものが決まっていた場合、「開発期間の短縮」はダウト
* アジャイル関連の本を読んでいると、「生産性向上＝ニーズに応える速さ」となってくると思っていますが、理解した人達の定義を見つけても、世間の思う生産性(コストに対する開発時間)の使われ方は残り続けると思いました。なので、その場その場で認識を合わせるか、別の言葉を用意する方が現実的な気がします(「生産性向上＝開発期間の短縮」だと思っている層に自分の思う定義を前提に話しても認識相違が起きるだけなので。大切なのは同じ方向を向くことだと思う)。:+1:
* :memo:生産性が定義されているところは、どこかにある？
* :memo:特になさそう？
* :memo: P.151の 6章に書いてある。ソフトウェア開発の生産性は測定するのが難しいことで知られている。
* > 生産性とは時間当たりの生産量だ。 - p.151
* :memo:「生産性 is 何」の話ではなく、「どうやって生産性を測定しようか」のお話っぽい
* :memo:クソコードを大量生産しても生産性高いとは言えないよね、という話ですねｗ
* :memo:githubのコミット数も微妙そう
* :memo:やってそう。行く先の現場によってはやらされそう。
* :memo: 【アンケート】実は未だに書いたコードの行数を計測している（または経験がある）
* A: はい 6
* B: いいえ 22
* C: 過去にやっていた 13
* :memo: 逆に、「こういう指標がいいっすよ！」みたいなアイデアある人いたりしますか！ [Discord](https://discordapp.com/channels/767540649418686486/774111081634332673/777500893485858847)
* :memo:コード追加より削除多い人のほうがイケてるイメージすらある
* :memo:書いた量が多いからといってなんの参考にもならないけど、書ける量がするない人は生産性悪そうって思われるのもそれはまあなくはない気がする。
* :memo:機能数とか、チケット数とか？
* :memo:うちでは、ストーリーチケットごとにPOにポイントを振ってもらってます
* :memo:Issueとかのポイントの消化数ってのはわかりやすくはあるけど、それも一概には言えないから難しいねぇ。
* "ソフトウェア開発において、アジャイル（アジャイルと書かれることもある）は、自己組織化されたクロスファンクショナルチームとその顧客/エンドユーザーの共同作業を通じて、要件を発見し、解決策を開発するアプローチである。"
* 重要なのは「アジャイル開発は僕らがもっと成功するのに役立つのか？」と問いかけること [Discord](https://discordapp.com/channels/767540649418686486/774111081634332673/777502504991981579)
* この問いかけから始めるのはすごく面白い :+1: :+1: :+1::+1::+1::+1:
* :memo: [discord](https://discord.com/channels/767540649418686486/774111081634332673/777503445183102977) 資料が見つからないですけど、以前Cynefin に照らし合わせて「Simple/Obvious なら waterfall」「Complicated, Complex なら Agile にしよう」な話を聞いて、それ基準に考えてます。(Waterfallの計画が破綻する)
- 
* 学んでいるあいだは、仕事のスピードは1/4とか1/2とかになってしまうだろう
* このように言い切っているものを初めてみたので新鮮でした
* スピードが遅くなる原因として慣れは当然あると思うけど他にどういった原因があるか改めて振り返ってみたいと思った :+1:

### 1.1 成功を理解する
* 成功の定義に対する感想
* システムを完成させることをゴールとするならば、従来の成功の定義がしっくりくる。
* ビジネスに好影響を与えることをゴールとするならば、アジャイルにおける成功の定義がしっくりくる。
* （成功の定義に対する感想を持つとともに）受託開発でアジャイルを導入するのは構造的に難しい場合が多いのかもと感じた。システムを完成させるという責務をカプセル化したのが受託という開発形態だから。例外は顧客側ビジネスの成功にコミットしている（コミットすることを許されている）プロジェクト。 :+1: :+1::+1: [discord](https://discordapp.com/channels/767540649418686486/774111081634332673/777524683267637278)
* 厳密にいうと、「顧客側がアジャイルでやる気持ちがないのに受託側だけでやろうとするのは難しい」だと思う

---

**ここからだよーーー！！**

### 1.2 納期よりも大事なもの
* アジャイルの目的に組織の成功、さらに個人的な成功までスコープに入ると言うのはとても面白い！
* 白本でソフトウエア開発を通じた自己実現が強調されていたことを思い出した。「個人的な成功」が含まれているのもしっくりくる。
* > 「XPとは、ソフトウェア開発で人間としての欲求を満たすことである」 - Kent Beck eXtreme Programming 2nd 第一章
* > そして幸い、XPには工夫する余地があります。仕事を楽しんでもいいんだということ、そしてソフトウェ ア開発がこんなにも生き生きとした人の活動であることを私たちに教えてくれたのは XP でした。 - p.xi
* 保守性だの最新技術云々言う前に顧客に価値を提供しないと意味ないだろvs保守しやすいコードでないと価値提供し続けられないだろ :+1: :+1::+1::+1::+1:
* 自分はよくバトルになってますが、3つの成功の定義を全員が持っていればバトルにならずに済むのかな
* > 挑戦的な締切はスケジュールを短縮するのではなく延ばすだけの結果になるだけだし［McConnell 1996, p.220、和書『ラピッドデベロップメント』ではp.228］
* 感覚的にはわかるけど、何故？ 引用元でのロジックが知りたい。
* :memo: [パーキンソンの法則](https://ja.wikipedia.org/wiki/パーキンソンの法則)とか？（出典未読）
* パーキンソンの法則だと、挑戦的な締め切りを設定した方が良くなるのでは？(クリティカルチェーンのようにバッファを取らない締め切りの方が効率化されるのでは)
* しまった、まるっきり逆に勘違いしてました
* 採用でマッチング率を重視するのも、この辺の話に紐づくと感じた。

### 1.3 組織的な成功の重要性
* 「比較的容易に達成できる技術的な成功や個人的な成功を奨励しているソフトウェアチームでは、組織的な成功が軽視されてしまうことがよくある。しかし、たとえあなたが組織的な成功に責任を負っていなくても、組織の上層部はあなたのチームをこのレベルで判断していると断言できる。」(p.5)
* ビジネスの成功は開発チームの主たるミッションではないにせよ、ビジネスの成功に開発チームが寄与できているか、は気にするべきだと感じた。:+1:
* 将来のメンテナンスコストを抑える為に設計やリファクタに力を入れたくても、組織的成功(ビジネス視点)で「待った」がかかることが多い。:+1:個人+技術的成功の観点から考えているだろうと思われてしまう。長期的に見たら保守性を高めることが組織的な成功に結びつくと思ってはいるが、上手く説明できずに悩むことが多い。また、そのソフトウェアが本当に長生きするかなんてわからないので、「リファクタした方が長期的に見てコスト減になります」とも言い切れずに終わる。。
* 「顧客忠誠心の強化」でちょっとギョッとした - p.6
* 原文では *Enhanced customer loyalty*
* https://www.oxfordlearnersdictionaries.com/definition/english/loyalty?q=loyalty
* > the quality of being constant in your support of somebody/something
* > Companies are eager to build brand loyalty in their customers (= to keep them buying the same brand).
* ここでは、顧客が「引き続きお願いしたい」とより強く思うようにする（そういうプロダクトを提供する、それだけの利益を提供する、etc)、的な意味かな

### 1.4.1 組織的な成功
* > プロジェクトの初期にそのプロジェクトへの期待を設定する
* この認識無かったかも？　「期待」とは何を指してるのか不明。要件じゃなさそうなので、ストーリー？ :+1::+1::+1::+1: :+1:
* 成功の定義みたいなことですかね？
* →トレードオフスライダー的な印象
* > ビジネスの専門家をチームに入れて
* 私のチームには居ませんが皆さんのチームではいかがですか。メリデメは何ですか。
* > その上、アジャイルチームはコストを削減する。彼らは技術的卓越によって、ある程度これを実現している。 - p.7
* アジャイルなチームがコストを削減するには、技術的卓越が（ある程度）前提になっていることに言及している（ように見える）:+1:
* 技術的卓越が前提とされているなら、「アジャイルなら、（誰がやっても）コストが削減する」という類の言説はフィクションということになる
* 「はじめに」のエチュードの話だったり、章冒頭の「最初はスピードが落ちる」という話にも繋がりそう（卓越していないなら、まずは卓越しないと。卓越するまではスピードは落ちるでしょ、という話にできそう）？:+1:

### 1.4.2 技術的な成功
* > こうした開発の仕組みに加えて、エクストリームプログラミングは技術的卓越につながる高度に技術的なプラクティスを含んでいる。 - p.7
* 「技術的卓越に**つながる**」にちょっと目が止まった:+1:
* 「高度に技術的なプラクティス」は、技術的卓越に**つながる**ものではあるが、そうしたプラクティスの実践は、直ちに技術的卓越を意味しない（プラクティスの実践 ≠ 技術的卓越）、という風に見える
* TDDをする = 技術的卓越ではなく、TDDを通じて設計手法を身に着けたり、分離や結合の勘所を掴んだり、プラクティスを通じて何かの知識・技能が身についてようやく技術的卓越に至る、というような :+1: :+1::+1:

### 1.4.3 個人的な成功
* 各役割ごとに成功を定義されていて、エンジニア以外の人にも価値を感じてもらう際に参考になると思う :+1: :+1: :+1::+1:
* ビジネス成果をまとめると「投資対収益率の向上」「長期的にソフトウェア提供の継続」「リリース頻度の向上」
* > 単純な繰り返し作業を減らしてもっとやりがいのある仕事ができることを高く評価するだろう。 - p.8
* テスターの項について
* たまに、アレコレ考えたりややこしいことをするのではなく、「単純な繰り返し作業」をひたすらこなしたい、というタイプの人もいる
* そうしたタイプの人は、バッサリ「アジャイルなスタイル」に向かないとなるのか（そうなりそう）
* そうした人を、部分的に取り込むことはできそうな気はする（が、その部分にはアジャイルとは違う思想・理論が棲み着きそう）
* そもそもとして、そうしたタイプ(=単純作業を好むタイプ)を"テスター"/(と呼ぶな|とは呼ばない)/感　:+1::+1: :+1::+1::+1::+1:
* > テスターは探索的テストを利用して、ソフトウェアに存在する予期せぬ 問題や認識違いを見つけ出す。 - p.21
* > 本当に価値のあるソフトウェアを定期的に出荷する。毎週、進捗をデモする。これまで経験したことがないくらい、ソフトウェア開発を楽しむことができるはずだ。 - p.8
* 「毎週、進捗をデモする」のところで「うへぇ」となる人もいそう
* 「エンジニアなら、みんなそういうのが楽しいはずだ！」というステレオタイプを感じる
* 「はずだ」と言い切っているあたり
* 言い方を変えれば、そこに楽しさを感じない人はアジャイルには向いていない（違うスタイルを取った方が良い）、ということになりそう :+1: :+1::+1:
* > 注意深く読み進めれば、XPによるアジャイル開発をチームにうまく導入できるだろう。あるいは、自分にはうまく合わないと判断するのに役立つかもしれない。 - p.xiii
* 『アジャイルサムライ』の「誰もがこの働き方を気にいるわけじゃない」(p.7)というのを思い出しました。 :point_left: :+1::+1:

## 疑問・参加者に聞いてみたいこと
* アジャイル＝速度向上、と思っている人は多い？ :+1:
* [Twitterでアンケートとってみた](https://twitter.com/little_hand_s/status/1325240161324556288?s=20)結果、みんなそこまで「アジャイルの目的は開発速度を上げること」と思っていなさそう
* ↑（皆分かってそうだけど）主な回答者層は松岡さんのフォロワーのはずなので、どこまで信用できるかは。
* おっしゃる通りでございます・・！
* 逆にアジャイル＝？　って皆さん思っているのだろう
* 「納期と予算と仕様を全て満たしたけど失敗に終わったプロジェクト」をみたこと、拘ったことがある人はいますか？
* 多額のお金貰ってたので予算上はOKでも、長時間労働&頻繁な作り直しでエンジニアが疲弊しきってしまったプロジェクトは見たことあります
* ECサイト作ったけど、売上がぜんぜんなかったとかあります。
* XPをオフショアで成功させるのが難しいと感じています。XPをオフショアで実践されている方はいませんか？ :+1:
* この難しさは↑の受託開発のところと同じ問題じゃないですか?
* 「日本人ユーザーを対象にしているのに、インド人の感覚でモノを作る」（一例）みたいな、ただの受託より一段階また苦難のレベルが上がっているイメージ
* 学んでいるあいだは、仕事のスピードは1/4とか1/2とかになってしまうだろう :+1::+1::+1:
* [diiscord](https://discord.com/channels/767540649418686486/774111081634332673/785107062458941440)
* と、ありますが、導入された経験のある方に、「実際導入して最初のほうは1/4から1/2くらいになりましたか？」
* テストコード書いたことない人がテストを書くようにすると2〜3倍かかるかなと感じたことはあります。もし、厳密にTDDするならもっと時間がかかるように思います。
* :memo: twadaさんの講演で近い話がありました！ https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition?slide=74 (20-30%は投資と決めた)
* :memo: 手慣れてない内は、「今はエチュードやってるんだから」と自覚するのが重要な感
* :memo: TDDとかデザインパターン、スプリント短いになれるのは人に結構依存するなーという印象。メンタリティを持っているひとやスキル持っている人ならスムーズですが、慣れてないと１か月はベロシティ下がる感覚です。
* ソフトウェア開発、楽しんでますか！ :+1:
* [discord](https://discord.com/channels/767540649418686486/774111081634332673/785110055493828608)
* > アジャイル開発はゲームのルールを変えてしまう。新しいやり方でソフトウェアを開発して提供するのは、 とても大変なことだ。それでもなお、一貫して厳格にアジャイル開発を続けていけば、あなたは驚くべき体 験をすることになる。本当に価値のあるソフトウェアを定期的に出荷する。毎週、進捗をデモする。これま で経験したことがないくらい、ソフトウェア開発を楽しむことができるはずだ。 (p.8)

### 1.4 アジャイルへと踏み出す
* > アジャイル開発は、個人的な成功、技術的な成功、そして組織的な成功を同時に達成することを重視している。 - p.6
* **同時に**というのが、アジャイル開発とその他のスタイルを隔絶するポイント、ということだろうか > 太字の意図

### 1.4.1 組織的な成功
* > アジャイル手法では、価値を提供することとコストを削減することを重視して組織的な成功を達成する。これは直接的に、投資収益率を増やすことに結びつく。 - p.6 [discord](https://discord.com/channels/767540649418686486/774111081634332673/785103919628943360)
* 章冒頭の「生産性を上げるためだけにアジャイル開発を導入するのはお勧めできない」との整合性について
* アジャイル手法において「価値を提供することとコストを削減することを重視」するというのは、上記の文章と穏便に整合するか？
* 以下解釈
* :memo: 本書では「単に生産性を上げるためだけにアジャイル開発を導入するのはおすすめできない。」なので、単にということも必要なキーワードだと思います。
* おそらく、著者としては「価値を提供することとコストを削減することを重視」するのは「生産性を上げる」ことに等しいと考えている
* 直後の文章でも「アジャイルチームには平均以上の生産性がある」と言及しており、「生産性」および「生産性を上げる」というフレーズを、ことさらネガティブには扱っていない
* 続けて「それを一番の動機にしてはいけない」とも言う
* 「一番の動機」にしてはいけないということは、それ（「生産性を上げる」）は動機たりうる、あるいはしても良いが、それを「一番」にしてはいけない、ということ
* 「生産性を上げる」ことはアジャイル開発において重視されることである、と読んでも特に矛盾は無さそう
* しかし、それを「一番」に、ましてや唯一の動機としてはいけない、という意図か
* ただし、そうした意味での「生産性が上がる」のは結果にすぎず、その「生産性が上がる」という結果を生み出すために必要な要素として「個人的な成功」「技術的な成功」も欠くことはできず、さらにそれらの達成のための取り組み（学習、エチュード、プラクティス）も必要
* さらに「生産性が上がる」の結果として「組織的な成功」が達成される、という関係
* それらを無視して「生産性が上がる」という結果**だけ**を得ようとしても、うまくいかないよという警句が、冒頭の一文か（とするなら、特に問題なく整合しそう） :+1: :+1::+1::+1::+1:
* 一部の結果**だけ**を狙い撃ちすることはできないということであれば、「個人的な成功」**だけ**、「技術的な成功」**だけ**を狙い撃ちするのもまた、うまく行かないということにもなりそう :+1:
* [discord](https://discord.com/channels/767540649418686486/774111081634332673/785105293184073774)
* :memo: 「やりたい」と「やるべき」を混同しちゃうぅ〜
* :memo: エンジニアは3つの成功、読んだ方がいい
* :memo: 「成功」の解像度を高めるのは大事ですよね。「成功」というワードレベルだとずれやすいなあと。
* :memo: p.6 「アジャイル開発は、個 人的な成功、技術的な成功、そして組織的な成功を同時に達成することを重視している。」
* ここも生産性に関する定義の違いのような気がします:+1::+1:
* 「価値を提供すること」→顧客の要望にあったものを作る
* 「コストを削減すること」→無駄なものを作らない、手戻りの時間を減らす
* 生産性向上は副次的効果であって、主目的ではないかと
* あと、生産性は極端な書き方をすると「(価値があるかわからないが)成果を出すこと」と「(必要最低限の機能だが価値を生み出す)成果を出すこと」の2つのスタンスで書かれている気がする
* :memo: この2つのスタンス、本文のどのあたりから推測できそうか知りたいです
* :memo: 「生産性」という言葉の定義（あるいはソレに対するイメージ）の違いによるものだというのは、多分その通りですね。そのあたりを本書ではどのように扱っているのか、どのように本文の内容を整理・読み解けば良いのかなーと。
* そもそも「アジャイル開発」≠「アジャイル手法」っぽい？:+1::+1:
* 2章で「アジャイル手法」の定義が記述されている
* 原文でも、「アジャイル開発 = Agile Development」「アジャイル手法 = Agile Methods」で使い分けされていそう
* 「アジャイル開発」の話をしている中で、なんの断りも無しに「アジャイル手法」の話をするのはなぜ？
* 原文の該当箇所でも、「Agile Methods」が使われているので、訳の問題ではないっぽい
* > Agile methods achieve organizational successes by focusing on delivering value and decreasing costs. (...) Agile methods also set expectations early in the project, (...)
* せめて参照は貼ってほしかった……（「これは2章で定義しているよ」的な）

* ソフトウェアの価値を測る指標には具体的にどのようなものがあるのだろう？:+1:

---