Jim Coplien氏の認定スクラムマスター研修に行ってきた

アギレルゴコンサルティング社主催の7月2日〜3日に実施されたJim Coplien氏の認定スクラムマスター研修に行ってきた。

Jim Coplien - Wikipedia

認定制度には懐疑的なんだけど、個人的にJim Coplien氏の本は好みのものが多く、彼のスクラム・パターンの研修を受けて非常に感銘を受けたので、今回認定スクラムマスター研修に行ってきた。

以下は面白かった点の備忘録。自分の貧弱な英語で通訳なしで聞いた結果なので聞き間違いや、勘違いもあるかも。（通訳は提供されてたが、自分は使わなかった。）

また、色々主張は強いが、質疑応答などでも現場のコンテキストを尊重する姿勢があった。機械的にこうやれ、と言っているわけではないとおもう。高みを目指すなら正しいのは、こっちだ！という主張と理解している。

• スクラムアライアンスとスクラムを一緒にするな
• 開発マネージャーというのはない。チームがやる。マネージャの仕事は部署間調整などチームが働く環境を整えること、そして大幅な組織改革「カイカク」をやる。チームがやるのは「カイゼン」
• 基盤となるようなビジネス要求というのは、実は安定している。変化するのは要求の理解である。
• ユーザストーリーはバックログに入れるものではない。バックログに入れるのは、要求/機能、技術、課題である。ユーザストーリーは要求を理解するためのコミュニケーションに使うもの。
• JIRAのようなバグトラッカーは無駄である。バグはすぐ直す。バックログ管理は簡単なExcelシートで充分。
• 研修のようなものもバックログに入れる。そうでないとチームから時間を奪うことになる
• ユニットテストは無駄。システムテストは無駄だけど、現時点では必要
• 完了は完了（DONE is DONE）。それ以上やることがないこと。リファクタリング、文書作成、システムテスト、性能テスト、デプロイ。全部終えて完了。POと合意する。
• 信頼を築くには、まず、自分から信頼すること。
• 心理的安全性は単なる結果。パーソナルな問題も持ち込んでいい。もし、心理的安全性を保つために、パーソナルな問題に踏み込まなかったり、壁を作っているような場合、それは病んでいるってことじゃないの？信頼が大事。
• デイリースクラムでは、ペットが死んだ、みたいなものも共有して良い。開発の障害は全て。スクラムは全体性。仕事と個人を分ける必要ない。
• チームがコミットするのはスプリントゴール。スプリントゴールによって、一体感を醸成する。
• POが出してきた要求にもチャレンジすることが大事
• アジャイルコーチを雇っても、開発チームと接触しない。スクラムマスターに対してコーチングする。（どこまで強い主張かは不明）
• スプリント毎の振り返りでは、浅い振り返りになる。年に３日とか使ってしっかりと振り返りをして改革につなげたりする。
• ベロシティなども統計的に管理する。一度ブレただけで次の予測を変える必要はない。３スプリント連続で変わったりするなら再考必要

前から思っていたけど、ＰＯの役割が死活的に重要と改めて感じた。製品ビジョンを持ち、製品機能を定義し、ＲＯＩを想定しながら、順位付けをしていく。開発者の助けを借りて、やるのだけど、かなり技術にカンが働かなければ難しいとは思う。そもそも、トヨタのチーフ「エンジニア」の役回りの一部らしいので。

講師によっては、開発者が考える、と割り切って伝えている場合もあるようだ。

dev.classmethod.jp

coplienさんは、はっきりとは確認してないけど、基本的には開発者の助けを借りて、ＰＯが書く立場と思う（開発者も含めたステークホルダーは追記できはする）。プロトタイプを開発チームに渡して説明したりする、ということも言っていた。

ロールを全うするには、個人的には、ＲＯＩに責任もてない開発者がとやかくいうのではなく、ＰＯチーム側にエンジニアリングがある程度分かる人が入ったりする必要があるんではないか、と思った。

最後まで、内製チームを想定しているみたいだったな。受託でやるときは、顧客側がＰＯチームにバックログアイテムの検討を支援するエンジニア/コンサルタントを、開発チームと別契約で結んで支援してもらえばいい、と思った。コンサルティング契約とかと似たようなもの。スクラムマスターは開発チームが必要に応じて連れてくればよい。

追記①----

• 多分、スプリントプランニングの時と思うけど、３本指テストでPBIをやり切れるか、の自信を試すといい。

追記②----

上に引用したブログによると、POは顧客ではなく、開発者の組織がやり、チームのROIに責任をもつ、とある。正直、自分には「チームのROI」の意味が理解できないし、プロダクトを実際に利用する顧客ビジネスのROIがスクラムのプロセスの中のどこで考慮されるのかが、分からないから、それはbad ideaじゃないかな、と思っている。

とはいえ、それで上手くいく場合も絶対あると思う。というか、そのほうが上手くいくことがほとんどかも。実際、スクラムじゃなくても、SIとかでは、顧客が考えられない場合、製品ビジョンは開発者側が考えちゃったほうが上手くいくこと多いと思う。全体的にくだんの講師のかたは現実解みたいなものを伝えている気がする。

でも、個人的にはそれには限界があると思うので、やはり高みを目指すなら、ということ。

 追記③----

coplienさんから回答が来た！

Great post! You are right — the developers help the PO with the tests, as they might help her with everything. But the PO does most of the work specifying the tests and has the final word on what end-user functionality to test and what the results should be.

— James Coplien (@jcoplien) 2018年7月7日

以下翻訳。

開発者は他のあらゆる面でPOを支援するのと同様に、テストによってPOを支援する。でも、どんなテストを実施するのか、を特定するためのほとんどの作業をPO自身が行う。そして、POがテストすべきエンドユーザー向けの機能とその機能が何をもたらすか、についての最終決定権を持っている。

google翻訳で読んだのかな？もしくはまだ、日本にいるから、誰かに訳してもらったのかも。 

追記④----

ユニットテストが無駄である旨の記事

https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

上記記事のからの引用

• Keep regression tests around for up to a year — but most of
those will be system-level tests rather than unit tests.

回帰テストは続けろ。でも、そのほとんどはユニットテストではなく、システムレベルのテストだ。

• Keep unit tests that test key algorithms for which there is a
broad, formal, independent oracle of correctness, and for
which there is ascribable business value.

広範性、形式性、独立性、正確さがあり、ビジネス価値に帰結する中心的なアルゴリズムに関してはユニットテストを維持しろ

（ビジネスルールのアルゴリズムとか？）

• Except for the preceding case, if X has business value and you can text X with either a system test or a unit test, use a system
test — context is everything.

上記以外の場合、そのコードがビジネス価値を持ち、システムテストでもユニットテストでもテストできるのなら、システムテストを採用しろ。コンテキストが全てだ。

• Design a test with more care than you design the code.

プロダクトコードをデザインするより注意深くテストをデザインしろ

• Turn most unit tests into assertions.

ほとんどのユニットテストをアサーションに変換しろ

• Throw away tests that haven’t failed in a year.

1年間テストして、失敗しなかったテストは捨てろ

• Testing can’t replace good development: a high test failure
rate suggests you should shorten development intervals,
perhaps radically, and make sure your architecture and design
regimens have teeth

テストはよい開発を置き換えたりはできない。高い失敗テストの比率は、開発のサイクルを短くするべきであることを示している。さらに、根本的には、アーキテクチャと設計に改善の余地が大いにあることを確証している。

• If you find that individual functions being tested are trivial,
double-check the way you incentivize developers’
performance. Rewarding coverage or other meaningless
metrics can lead to rapid architecture decay.

もし、テストされた関数が些細なものであったなら、開発者をどのように動機付けしているのかを厳重にチェックしろ。カバレッジやその他の無意味なメトリクスはアーキテクチャを劣化させる。

• Be humble about what tests can achieve. Tests don’t improve
quality: developers do. 

テストが達成できることに謙虚になれ。テストは品質を向上させない。それは開発者しかできない。