私はアジャイルを「ろくろを回して楽しい人」がやるものだと思っていたのですが、
この本で「良いもの(この本でいう正しいもの)」をお客さんに渡して尚且つ(無駄な)会議をなくしたいだけだったのかもなぁと思えました。
知らなかった言葉、内容のメモ
・SOR
->
動作に信頼性が求められるもの(要件定義が重い)
etc>社内システム、基幹システムなど
・SOE
->「こうあるといいのではないか」という機能の実装(誰も正解をもってない可能性がある)
etc>ECサイトなど
●不確実性との戦い方
(これまで)
・要求定義によって確実性を上げる
・合意を重視する
・合意形成を遵守する
これらの戦い方をしても開発に付随する不確実性には勝ち続けることはできなかった
(要求定義時点に戻るような手戻り、技術的な難しさなど)
->この点を解消するのがアジャイル開発としている
「あたりをつけながら開発する、関係者内で合意形成しながら進める」
(スプリントごとに開発するような形になるため、ユーザーに試してもらいやすいなど)
スクラムの難点
->経験主義(実践知)
「対話、動くソフトウェア、(顧客側などとの)協調、(計画の)変化への対応」に重きをおいている
(『アジャイルマニフェスト』)
ここの対話の部分に「心理的安全」などがかかってきている気はする。
2-4スクラムイベント 辺りを読んでいると「無」の会議をしたくないんだろうなというのは伝わってくる。
早く(少しだけ)形にできることで得られる良さとは何か？」内の④チームの学習効果が高いはSESでチームが変わる自分からすると魅力的に思えた。
3-4 スプリントの強度を高める技術
->やり抜く力(リモートワークでの開発中のコミュニケーション不足からさらに求められるようになった)
・小さくとも成果を認める必要がある(これが自分は下手)
->表面的にではなくチーム内のお互いの信頼感を醸成するには、「このチームはやれる」という期待が必要
他の参考本
・『カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで』は「主人公がいて...」という物語の形式になってしまっている部分が強く
(このことはあんまり言い出したらキリがないため、言ってもしょうがないのだが)
「こうしてみんなアジャイルによって幸せに暮らしましたとさ」というオチにつながりすぎているように感じた。
(本当にそれでみんなが幸せな開発が可能なのかという疑問がぬぐい切れなかった)
・『正しいものを正しくつくる』とプロフィールで同じ人だったことに気が付くなど