僕の場合アジャイル開発という大雑把な括りで理解しているので、具体的な開発手法名はなかなか覚えにくい、というよりそれすらちょっと抽象的な表現なので分かりにくいと言ったほうが適切か。
スクラムとは、会社を機能単位に分割した階層や組織ではなく、どこをとっても会社のビジョンに向かった判断・行動パターンを共有する自己相似の知識創造活動であり、それを実践する人びとである
本書を読みきれば、上の定義があーなるほどと理解できるようになる。あとは、自分のフィールドに翻訳する必要があるのだが、カルチャーを変革する系の手法なので、ボトムアップな取り組みだけではうまくいかないだろうし、上の理解が必須かなぁと思った。なのでマネジメント層に読んでもらいたいなぁと。
- アジャイルは顧客満足を実現する手段であり可能性のひとつ
- アジャイル開発では知識の外部への伝播が語られていない（これは欠点）
- PDCAのPの前にはSECIのSを置くべき
スクラムを実践するには組織を変えていく情熱が必要である
これがなー、厳しい。リーンスタートアップみたいなやり方は時間がかかるしなぁ。
第三部の「アジャイルと開発とスクラムを考える」の野中郁次郎先生の考察が非常に深かった。アジャイルでは知識の外部への伝達が弱いのは技術者の流動性が高すぎるからだと考察している。流動性がそれほど高くない僕のいる業界なんかでは暗黙知の共有とか形式知化なんかは非常に重要なことなので、本書のオリジナルの論文（日本の製造業）と対比しながらの考察は理解が非常に深まった。
以下、製薬業界用メモ。
ユーザーストーリーのフォーマット
- ＜ユーザーの役割＞として
- ＜機能＞が欲しい
- なぜなら＜機能の価値や目的＞だからだ
動態担当として、logPを下げてほしい、なぜなら膜透過性が改善するからだ
みたいな、なぜ今そういう化合物を作っているのか？というストーリーを張っておかないと、振り返った時に個々の化合物が合成された背景を掴めないし、そのやり方がうまくいきそうかどうなのかが外部から判断できない。
ケミストの「うまくいったから、結果としてうまくいったんだ」というようなくだらないトートロジーに付き合わされるのはかんべんしてほしい、というのはみんなの願いであろう(ケミストそれ自身の願いでもある気がするw)。
プロダクトバックログ
プロダクトバックログとは、実現するかもしれない未来の詰め合わせである。創薬的には合成してもいいかなぁと考えている案のリストと考えることができる。リードオプティマイゼーションにおいてはそういうアイデアリストをプロジェクトごとにまとめて管理して確度の高そうな案から作っていくというやり方がプロジェクト的に理想的かなと思っているんだが5年くらい前からトライしているんだけどうまくいっていない。色々理由はあると思うんだけど知財的なことを考えると誰が作ったかが重要視されるのでまぁしょうがないのかなぁと。
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント