アジャイルコーチ同士のスクラムガイド雑談会2020
2020年11月18日(水)に、スクラムガイドの最新版がリリースされました。
それを受けまして、アジャイルコーチの中村 洋さんからお声がけいただき、11月23日(月)朝に同ガイドの内容に関する雑談(1 on 1)をさせていただきました。
1時間半を超える熱のこもった内容になりましたので、せっかくですので内容を備忘録として書き出してみました。同ガイドの読み方・解釈方法の1意見として読んでいただければ幸いです。
ちなみに、中村さんは日本語版を、私は英語版を読んだ上での雑談です。その違いも含めて楽しんでいただければ〜
1. スクラムガイドの目的
スクラムの核となるデザインやアイデアを変更したり、要素を省略したり、スクラムのルールに従わなかったりすると、問題が隠蔽され、スクラムの利点が制限される。 (日本語版 1ページ)
- (中村)この「問題が隠蔽され」という点は、スクラムに取り組む理由の一つとして(自分自身がコーチ先のチームなどに)説明することがある。
- (伊藤)この記述を含め、今回のガイドは全体的に透明性・検査・適応とその相関関係とを強調している印象。
2. スクラムの定義
スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。 (日本語版 4ページ)
- (中村)スクラムマスターの必要性を明記している点が興味深い。単なる会議のファシリテーターとかではないことを強調する必要が出てきたのかも?
- (伊藤)それは確かにありそう。一方で、各ロールとその相関関係を含め、文字通りここで「スクラムの定義」を簡潔にまとめ、全体の見通しを良くしようという著者の強い意図を感じた。
スクラムフレームワークは意図的に不完全なものであり (日本語版 4ページ)
- (中村)「不完全」の解釈が分かれそう。自分は、1) プロダクトバックログの書き方や使用ツールといった、実践方法の詳細を明示していないという意味合いと、2) 仮説設定・検証やマーケティングなど、スクラムの「外側」のプロセスを明記していないことと捉えた。
- (伊藤)自分は、「イノベーションのチャンス」と解釈した。スクラムはフレームワークのベースラインだけの定義にとどめているため、実践時は各ドメイン・プロダクトに合わせた肉付けが必要。そこに各実践者の工夫や、スクラム自体を豊かにする余地があるのだと捉えた。
3. スクラムの理論
「リーン思考」の「リーン」は、「ムダを省き」という記述があるので、「リーンスタートアップ」ではなく「リーンソフトウェア開発」を指すだろう。
4. スクラムの価値基準
スクラムチームのメンバーは、スクラムのイベントや作成物を用いながら、これらの価値基準を学習および探求する。 (日本語版 5ページ)
- (中村)日本だと、(確約・集中・公開・尊敬・勇気といった)価値基準及びそれらの学習・探求の必要性をあまり明言していない印象。
- (伊藤)確かに日本では、これらを明示的に話していないかも。そういえば、Kubernetes Podcast from Googleなどを聞いていると、海外の団体・コミュニティなどでは、これらの重要性を明言していることが多いかも。
- (中村)日本のSIer所属のアジャイルコーチをみていると、こうした発想自体を持っているのか疑問に思うこともある。
- (伊藤)日本のSIerだと、一定期間過ぎたらチームが解散する「プロジェクト」の思考に馴れていることが多くて、中長期的思考を持ちづらいということはあるかも。
5. スクラムチーム
自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。 (日本語版 6ページ)
自己「組織化」から自己「管理型」に記述が変更されている。意思決定の責務を、(POを含む)スクラムチームとして持つことを明示したのでは?
スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。 (日本語版 6ページ)
- (中村)「すべての活動」とはどこまでを指すのか?例えば「検証」は、リサーチャーが行うプロダクトの仮説設定・検証を指すのか?
- (伊藤)仮説設定・検証も含めて「すべて」ではないか?ちなみに(会社の)自分のチームでは、大変ではあるがこれらをすべてやっている。
- (中村)「責任を持つ」の記述が重要。他チームなどに助けを求めてでも「活動に責任を持つ」という意味であって、自分たちが実施する責任(=自力でやらなければならない)という意味ではないと思う。
- (伊藤)ですね〜
5.1. 開発者
完成の定義を忠実に守ることにより品質を作り込む。 (日本語版 6ページ)
「完成の定義」という言葉がここに出てくるようになったことは、大きな変化だと思う。プロダクトの「作り込み」を強調する意図があるのかも。
一方で「品質の作り込み」は、スクラムガイドだけでは情報不足。ソフトウェア開発ならば、XP・CI/CD・DevOpsなどを取り入れる必要がある。
5.2. プロダクトオーナー
プロダクトゴールを策定し、明示的に伝える。 (日本語版 7ページ)
- (中村)「プロダクトゴール」を明記するようになったのは、スプリントだけを回して結果プロダクトのゴールを見失いがちになるスクラムチームが多かったからかも?
- (伊藤)それはありそう。書籍『A Scrum Book』でも、プロダクトバックログのインプットとしてのVisionやProduct Roadmapに多くの記述を割いていた。
A Scrum Book: The Spirit of the Game
- 作者:Sutherland, Jeff,Coplien, James O.,Heasman, Lachlan,den Hollander, Mark,Ramos, Cesario Oliveira
- 発売日: 2019/09/03
- メディア: ペーパーバック
5.3. スクラムマスター
スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダーである。 (日本語版 7ページ)
- (中村)「組織へのリーダーシップ」を明示したことは、大きな変化だと思う。チーム内だけに留まって、本来の価値を発揮していないスクラムマスターが多かったのでは?
- (伊藤)それはありそう。私たちはJames Coplienさんの認定スクラムマスター研修を一緒に受講して、Red Pill、既存の枠組みを外れてでも貢献する重要性を叩き込まれたので、「組織へのリーダーシップ」が当たり前になっている。それを全員が持っているわけではないので、明示には意味があると思う。
6. スクラムイベント
6.1. スプリント
スプリントゴールの達成を危険にさらすような変更はしない。 (日本語版 8ページ)
- (中村)「危険にさらすような変更」には、どのようなものがあるか?
- (伊藤)(考慮不足の)APIの破壊的変更など、スプリント内では対応しきれないようなうっかり追加作業。CI/CDをやっていると予防はできる。やはりスクラムガイドだけでは不足かも?
すでに発生したことだけが、将来を見据えた意思決定に使用できる。 (日本語版 9ページ)
- (中村)一連の文章で言いたいことはなんだろうか?(日本語の文章がやや複雑)
- (伊藤)メトリクスなどの「過去の」実績情報をベースに、経験主義的に行動しましょうという程度の意味では?(英語で読んだから詰まらなかった?)
6.2. スプリントプランニング
キャパシティ (日本語版 10ページ)
- (中村)「キャパシティ」は、時間・日数の意味か?
- (伊藤)Capability、学習の要素なども含む、広い意味での「能力」の意味合いではないか?自分がコーチングをする場合は、これを伸ばすタスクを意図的に追加したりしている。
6.3. デイリースクラム
プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。 (日本語版 10ページ)
- (中村)これは、(本来は禁止されているはずの)ロールの兼任をしろという意味なのか?
- (伊藤)帽子の被り直し程度の意味では?デイリースクラムの参加者を開発者に限定している旨の、前段の記述とも符合する。
6.4. スプリントレトロスペクティブ
スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである。 (日本語版 11ページ)
「効果」は、プロダクトとプロセスの両方を指す。
スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。 (日本語版 11ページ)
「仮説」は、プロダクトとプロセスの両方を指す。
スクラムチームは、自分たちの効果を改善するために最も役立つ変更を特定する。最も影響の大きな改善は、できるだけ早く対処する。 (日本語版 11ページ)
- (中村)「最も」と明記しているのは、改善項目をたくさん実施しても無駄が多いなどの点を指摘している?
- (伊藤)おそらくそう。TOC(Theory of Constraints、制約理論)の、「多くの問題は、少数の原因による」という考え方と同じではないか?
7. スクラムの作成物
プロダクトゴールは、スクラムチームの⻑期的な目標である。次の目標に移る前に、スクラムチームはひとつの目標を達成(または放棄)しなければならない。 (日本語版 12ページ)
- (伊藤)「達成または放棄」とは、プロダクトのPivot(方針変換)のことを指すのではないか?
スプリントゴールはスプリントの唯一の目的である。 (日本語版 12ページ)
- (中村)スプリントゴールは、1つにした方が良いでは?
- (伊藤)同意。もし複数必要になる場合は、ゴール間の優先度設定が重要。
7.1. インクリメント
また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。 (日本語版 13ページ)
- (中村)「徹底的に」という言葉が興味深い。リグレッションテストの重要性と、技術的プラクティスを軽視する近年の風潮への警鐘の意味合いがあるのでは?
- (伊藤)同意。技術的プラクティスがあって初めて、スクラムガイドが示す「徹底的な検証」ができる。
8. 全体
自分たちのような経験を積んだ実践者にとっては読みやすくなった一方で、初学者にとっては曖昧すぎて読みづらい内容になっているかも?
- 経験のあるコーチが、初学者とペアないしモブを組んで教えることを「前提」としないと辛いかも?
- 一方で、コーチの知識・経験を活かして初学者を導くスキームが想定されているかも
- 聖書と牧師さんの関係が似ているかも
最後に
同じアジャイル実践者でも、積んできた経験の差でこれだけ解釈が割れるのかという驚きと、その解釈の差を共有し合うことでさらに理解を深められる面白さの両方を体感できました。
このような雑談は、是非皆さんにもお勧めしたいです。
機会をくださった中村さんに感謝です!
Coderetreatに齢45にして初参加
2020年11月7日(土)に、こちらのイベントに参加させていただきました〜
ここ最近の週末は、GolangでLeetCodeの問題を解くか、Kubernetesのclient-goのソースリーディング・動作確認を続けています。一方で、ずっとひとりで学習を続けているので、たまには違った視点が欲しいなと思い、腕試しを兼ねて同イベントに参加してみました。
イベント概要
平たくいうと、ライフゲームというお題をみんなで実装してみましょうというものです。
但し、以下のようなルール・制約があります。
- 実装45分、振り返り15分の計60分のサイクルを、6回繰り返す
- 使用する言語・開発環境は自由
- 基本はペアプロ、慣れたり気分転換したくなったらモブプログラミングで!
- 45分経ったら、そのコードは破棄!
45分ごとに頭も気持ちもコードもリセットするため、いろいろなチャレンジができるチャンスでもあります。
自身の行動記録
覚えている範囲でメモ。ちなみに開発環境は、TDDのトレーニングで有名なcyber-dojoを主に使用しました。
Iteration 1 : まず慣れる
まずはTDDを忠実に実施することで、ライフゲームの仕様の理解とイベントのルールへの慣れを優先しました。ちなみに、言語・テストツールはJavaScript + Jestでした。
Iteration 2 : 設計を考える
次はJava + JUnitで、オブジェクト指向の観点から設計を意識して進めました。このあたりでライフゲームの実装イメージが掴めた感じ。
Iteration 3 : Golangでやけど
配列操作の都合と、自身が最近学んでいることを試してみたいことから、Golang + testingをチョイス。しかしながら、人数の都合でトリオを組んだメンバーが初Golangだったため、言語の勝手で詰まってしまい、私が言語仕様を説明している間にタイムアップ (´・ω・)
Iteration 4 : Golangおかわり
Iteration 3を受けて、Golangを試したい!という方が他にもいたため、再度チャレンジ。
最初の5分は、時間の節約と言語仕様の説明を兼ねて、私がIteration 3での実装内容を復元し、残りの時間でみんなでワイワイする形に。完了のイメージがはっきりと見えてきたところでタイムアップ。45分はかなり短い。
Iteration 5 : Clojureに散る
なぜかClojureをやろうということになって、モブプログラミングで試したものの… そもそも書き方が分からない、知りたいことがまるで検索で引っかからない(ググラビリティの低さ)、説明を読んでも意味が分からないと、文字通りの完敗。
Iteration 6 : Pythonで完成
最後は全員でモブプログラミング。リスト内包実装など様々なテクニックを皆さんから教えてもらい、時間内についに完成!
ちなみに私は、純粋に体力が尽きてしまい、このiteration途中でコーディングから離脱してアイデア出し係に。6 iterationはかなりハード。
感想
- 参加者と運営の皆さんのホスピタリティのおかげで、45歳でも多くのことを学べました。感謝。
- Golangの独習内容は、他者に説明できるレベルになっていたことを確認できました。
- 久々に会社以外のIT系の人と直に話せたため、かなりのリフレッシュになりました。
おまけ
株式会社アトラクタ様のおかげで、美味しいハンバーガーをいただきました。本当に感謝です。
お店はこちら。
Kubernetes Novice Tokyo #5でLTをさせていただきました
自身のKubernetes力を磨こうと、9/29(火)に「Kubernetes Novice Tokyo #5」というイベントでLTをさせていただきました。
Kubernetes関連のコミュニティ・イベントでは、初の登壇になります。
発表資料は、コチラになります。
私たちのチームが現在絶賛構築・運用しているKubernetesベースのテスト用インフラである「Testable Infra」について、自身の情報整理とコミュニティからのフィードバックを得ることを目的にお話させていただきました。
ちなみに、10分という発表時間と、CNCF系OSSのコミッターから「Kubernetesをそういう目的で使うという発想はなかった」と以前言われたことがあったことから、今回は概要レベルの説明にとどめています。
このイベントで得たもの
1) 大将さんから教えていただいた、1つのLoadBalancerを用意して配下のクラスタ群を切り替え可能にするアイデアを早速活用して、Kubernetesリソースの削減とTestable Infra自体のパフォーマンス向上につなげられています。
2) mikiさんの発表を参考に、私もKubernetesのclient-goのソースリーディングを始めました。
さいごに
別イベントから登壇依頼が届きまして、Testable Infraの技術詳細や構築・運用時のTipsなどを現在絶賛整理中です。近々みなさまにも共有できると思います。
RSGT2021に登壇できます!
多くの方の応援をいただき、Regional Scrum Gathering℠ Tokyo 2021(以下「RSGT2021」)のプロポーザルが通りました〜!
ちなみに、私のプロポーザルは↓コチラ↓になります。
Regional Scrum Gathering Tokyo 2021 - Tips of Product Management for Internal Tools/社内ツール・サービス・プラットフォームにおけるプロダクトマネジメントの勘所 | ConfEngine - Conference Platform
さて今回は、このプロポーザルの狙いを、簡潔に5分以内で読めるようにまとめてみました。
1. 自身のプロダクトマネジメントの知見を整理しフィードバックを得たい
ここ1年ほど、特に社内ツール・インフラの設計・開発に加えて、プロダクトマネジメントもやる必要が出てきました。
その際にぶつかった課題、試行錯誤して失敗した点/うまくいった点を整理し、みなさまからのフィードバックをいただいて洗練していきたいと思っています。
もちろんその結果として、現在担当している社内ツール・インフラをより確かなものに育てていく所存です。
2. 世界的な知見不足を埋めたい
今年5月に公開された、ThoughtWorks社のIT業界トレンドレポート『Technology Radar (Vol.22)』を読んだところ、以下の記述に特に目が止まりました。
要点としては、
- 社内ツール・インフラにプロダクトマネジメントの考え方を適用するトレンドが世界的にみられること
- 一方で、社内ツール・インフラならではの知見・方法論などの整理はこれから
というものです。
私は基本、スペースを見つけて走り込むタイプ(ゴールを決められるかはまた別)なので、これはチャンスだと思い、このレポートを読んだ直後からこのプロポーザルを書き始めていました。
3. Agile2021の公募にも挑戦したい
今年のRSGT2020で試したところ「行けた」ので、今回も狙ってみようと思います。
昨年は、Regional Scrum Gathering Tokyo 2020 - 特殊部隊SETチームの日常 - 技術と実験を融合した実践アジャイル術 - | ConfEngine - Conference Platformと題してお話させていただきました。
そこで皆様からいただいたフィードバックを活かして、Agile2020にプロポーザルを出したところ、なんとかacceptされました。
- 倍率は、7-8倍ほどでした。
- ちなみにイベントは、新型コロナの影響で中止となりました。結果として幻のスピーカー扱いに。
発表資料はコチラです。
せっかく資料を作ったので、日本国内で発表をした際の内容を、ログミーさんにまとめていただきました。
ちなみに、Agile2020の公募の経緯については、コチラもご覧ください〜
さいごに
新型コロナで鬱屈した気持ちを、少しでもみなさまとともにカンファレンスの場で発散できれば!
ウィズコロナ&ニューノーマルな生活の過ぎたるイチ事例
在宅勤務とストイックな生活をしすぎて体調を崩していると、先日医師に診断されました。
ただ、症状的に何が原因でどう対処すれば良かったのかが分かりづらいものだったので、似たような症状で困っている方のプラスになればと思い、症状・原因・対応策をまとめてみました。
症状
- 7月頃から、左手の人差し指・中指に痛み・違和感が出てきました。
- 7-8月頃から、肩こりが慢性的になり、どんなにストレッチをしても効かない状況になりました。
- 8月中旬頃から、両耳、特に右耳が聴こえなくなってきました。
- 特に右耳は、カパカパするような違和感に悩まされています。
- ギターなどの弦を弾いたような、謎の異音が聴こえるようになっていました。
- 9月以降、めまいと吐き気も出てきています。
めまいと吐き気の段階で「何かマズイ」と判断し、急ぎ鍼灸院と耳鼻咽喉科を受診しました。
原因と対策
- 背骨がねじれた状態になっていて、全身、特に首回りに大きな負荷が掛かり、結果肩や指を含む全身の痛みにつながっていることが分かりました。
- 生まれつき猫背だったことに加え、在宅勤務の長期化で、負担のかかる姿勢で長時間PCに向かい過ぎたことが原因とのことでした。
- 背骨を整体的に矯正し、現在も継続的に鍼・マッサージを続けています。
- 「耳管」という器官に障害が起きていて、めまい・吐き気につながっていると思われるとのことでした。
- これは、急激に体重を減らしたりすると、たまに起きる症状とのことです。(確かに今年に入ってから10kg以上減量している最中でした)
- ちなみに、脳は健康とのことでした。
- 右耳に1cm強の髪の毛が刺さっていて、これが異音につながっていました。(すぐに除去してもらいました)
- 在宅勤務で外出を避け続けたこと、また仕事に集中し過ぎてしまったため、メンタルが気付かぬ間にダメージを受けていたとのことでした。
- 確かに半年ほど、新型コロナ対策を忠実に守って、自宅近辺以外の外出を一切していませんでした。結果的に、仕事だけを突き詰めるライフスタイルになり、思考・メンタルの幅を狭めてしまっていました。
- 早速今日、無理やり外出をして、気分転換を始めています。
さいごに
ウィズコロナ&ニューノーマルな生活には、新しいメリットもたくさんある一方で、未知というか気付きづらい心身のダメージもあるようです。それらの原因と対策を見つけて集めて共有し合うことは必要だと、文字通り痛い目にあって痛感した次第です。
参考情報
鍼灸院で使っているストレッチポールです。背骨・首回りの痛みを、以前よりも軽減できています。
気分転換を意識して行うことの重要性とそのテクニックが、詳細にまとめられている一冊です。
サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法
- 作者:チャディー・メン・タン,一般社団法人マインドフルリーダーシップインスティテュート
- 発売日: 2016/05/17
- メディア: Kindle版
怒りやストレスの原因を見つけて解消するための技術が、簡潔にまとめられています。
おまけ:半年ぶりの外出
虎ノ門ヒルズ駅。まだ絶賛工事中。
虎ノ門ヒルズ本体。発展はこれからな模様。
愛宕神社にあった龍の像の出来栄えが見事
"Kubernetes the Hard Way"を完走しました
同僚に勧められて、GW早々"Kubernetes the Hard Way"を全てやりきりました!
"Kubernetes the Hard Way"とは
Dockerなどのコンテナの管理ツールとしてデファクトスタンダードになりつつあるKubernetesを、インストーラー任せにせずに、自力で必要なコンポーネントやクラスタ全てをセットアップして動作させるようにするという、一種の学習ツールです。
Google Cloud Platform (GCP)とGoogle Cloud SDKを使用して、インスタンス作成やネットワーク設定などを行う必要があるため、これらの学習教材としても有用です。
動機
大きく3つあります。
1. 実務でのKubernetesの利用が普通になってきた
ここ数年、社内でDockerの普及が進み、これらの管理のためにKubernetesの利用が普通になってきたことがあります。であれば、詳しく知りたくなりますよね〜
2. 書籍や公式ドキュメントだけでは理解しきれないところがあった
これは私だけの可能性がありますが、Kubernetesの書籍や公式ドキュメントを読んで動かし続けていたのですが、いまいちピンとこないところが多々ありました。 例えば、KubernetesのControl Planeは
で構成されていると公式ドキュメントにはありますが、これらには具体的にどのような設定が必要なのか?どのように連携し合って全体としての機能を提供できるのか?といったレベルまで理解しきれず、悶々としていました。
3. 以前から試してみたいことがあった
加えて、以前からDockerとKubernetesとを活用して、既存のテスト環境を(テストデータ込みで)必要な時に複製・破棄できる仕組み(チーム内では「Testable Infra」または「Testable and Disposable Infrastructure」と呼称しています)を作ろうと画策していまして、その実装やトラブルシューティングに、Kubernetesの内部構造の詳細な知識が必要だったこともあります。
やってみて分かったこと
1. 内部の詳細を体得できた
実際に手を動かすことで、以下のことを理解もとい「体得」することができました。(個人的な動機に叶うものでした)
- 各コンポーネントを動かすために、どのような設定ファイルが必要で、どのクラスタのどのディレクトリに置けば良いか?
- 各コンポーネントをLinuxのサービスとして動かすために、それぞれどのような設定が必要か?
- 各コンポーネント・クラスタ間の通信で、認証や暗号化がどう関わっているのか?またそのためにどのような設定が必要か?
2. トラブルシューティングができた
指示通りに設定したにも関わらず、kube-apiserverの起動に失敗するトラブルに遭遇し、原因究明およびトラブルを解決するという経験ができました。
トラブルシューティングの詳細は、下記GitHub Issueとしてまとめておきました。
「ツール系の学習にはトラブルシューティングが最適だ」と、昔会社の先輩に言われたことがありましたが、まさにそうでした。トラブルシューティングは、課題発見・解決力を磨く強力なツールです。
3. GCPの費用と節約方法が分かった
"Kubernetes the Hard Way"のREADMEには、GCPの費用の目安として
$0.23 per hour ($5.46 per day)
とありますが、必要時以外にGCPの各種リソースを停止・削除しておけば、1日あたり200-300円程度に抑えられました。
(インスタンスやネットワーク設定は、停止しているだけでは課金されるんですね〜)
まとめ
完走した感想ですが、Kubernetesのドキュメントやコードを追うことや、日々の業務で活用することももちろん有益ですが、より理解を深めるためにこれを試すのは、大いにありだと思います。 GW & Stay Homeなこのタイミング、実はこうしたことを試す/学ぶ良い機会かもしれません。
Agile2020公募採択とその歩み
世界最大規模のアジャイルのグローバルカンファレンス「Agile2020」に提出していた公募が採択され、登壇させていただくことになりました。2014年以来、2度目の栄誉です。
新型コロナウィルスの影響で、予定通り登壇できるかは正直不透明ですが、主催者によると、本稿執筆時点では予定通り開催するとのことです。
ちなみに、私のセッションの情報はこちらになります。提出した論文などは、こちらからご覧いただけます。
さて今回は、公募採択までの歩みについてまとめてみます。
動機と準備
Agile2014で採択された論文が、現在でも私たちの業務やチームの指針策定にプラスに作用していることが大きいです。個人・チームとして何か問題にぶつかった時に、考え方や解決策の引き出しとして活用できているのです。
一方で、前回の登壇から5年以上経過し、その間私もチームも多くのスキル・経験を蓄積してきました。そろそろ、蓄積してきたスキル・経験を整理して活用できるようにする時期だと判断し、昨年2019年の4月から行動を開始しました。
具体的には、以下のアクションを行いました。
- 業務上の気付き・考えたこと・取った施策・その効果などを、毎日メモとして書き溜める
- 業務中に書くことがポイントです
- 常に発信することを前提に、日々の業務を観察し実行していました
- 1週間おきに、書き溜めたメモを文章としてまとめる
- 1週間スプリント・ウィークリーリリースと書くと、イメージしやすいかもしれません
- 文章の通りが良くなったところで、実際に論文フォーマットを当てはめる
- 前回すでに論文のフォーマットを入手し、書き方を熟知しているため、早期からリリースできる状態で作りこみました
- 実際に提出前提のフォーマットで書き出してみると、記述の過不足などがよりクリアになります
- 同僚に定期的にチェックしてもらい、フィードバックを取り込む
上記の結果、昨年11月はじめの時点で、いつでも論文を提出できる状態にできていました。
そして、11/14に公募が開始されたので、早速論文を提出しました。
渋い反応
しかしながら、実際に論文を提出してみると、ネガティブなフィードバックばかりが返ってきました。
いずれにも共通するのは、「too general」というもの。
私はこれを、「記述範囲が広く一般論的な内容になってしまっているので、もっと具体的で踏み込んだ内容にして欲しい」という意味に捉え、年末年始の休みを使って、徹底的に詳細な内容に書き換え、再度提出しました。
しかしながら、以前よりはポジティブなフィードバックになったものの、やはり「too general」とのこと。
この時点で、何かがおかしいと気付きました。
ピボット
私が選択したトラック(=セッションカテゴリー)は、前回のAgile2014と同じ「Experience Report」でした。 このトラックは、アジャイルを試してみた経験談を深掘りするもので、具体的には「テスト自動化による想定外の学習効果」や「モブプログラミングのon-boardingへのプラスの効果と改善すべき点」といったものが求められます。
一方で私の論文は、SET(Software Engineer in Test)としての戦略策定方針やそのためのステークホルダーからの支持の得方、問題プロジェクトの課題発見とその解決方法、我々が構築した新しいコンセプトのテストツールなど、ここ数年の活動全体を整理・総括したもの。
どうやら、「Experience Report」トラックで求めているものよりも、はるかに広範で多岐にわたる情報をまとめすぎたようです。端的にいうと「書きすぎ」でした。それを「too general」と指摘され続けていました。
一方で私としては、論文でまとめたレベルの全体的な話をしたい、そのレベルの知見をまとめて今後の自身とチームの活動に活かしたい。登壇はしたいけれども、そこは譲歩したくない。
そこで、締め切りまで1ヶ月を切った1月の中旬、私は「ピボット」を選択しました。
改めてトラック一覧を確認し、自分の話したい事に近しいものを探してみたところ、「Development & Testing Practices」を発見。こちらは、30分だけ話せる「Experience Report」とは異なり75分も話せる、論文以外の過去の発表資料も評価対象にしてもらえる、そして何より、自分の話したいこととトラックの求めているものとが一致している!
そこで、ピボットを決意した次の日に、早速「Development & Testing Practices」に公募を提出し直しました。
ちなみにAgile20xxはこのように、トラックごとに応募方法や基準が異なります。
著名人からのフィードバックとサポート
ピボットを決意し公募を提出した次の日、早速ポジティブな反応が返ってきました。
まず、私にTDDを叩き込んでくださったJames Grenningさん。久々の再会です。
テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計
- 作者:James W. Grenning
- 発売日: 2013/04/24
- メディア: 大型本
次に、Agile Testingの考え方で日々お世話になっているLisa Crispinさん。まじか!
実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)
- 作者:Janet Gregory,Lisa Crispin
- 発売日: 2009/11/28
- メディア: 大型本
他の方たちからもフィードバックをいただきましたが、いずれにも共通したのは、「方向性は合っている」「より多くの人にアピールできるようにここをこう直そう」という、公募採択とその後を想定した具体的なものでした。
それらのフィードバックをもとに、公募内容の改善のやり取りを続けた結果、採択となりました。勇気を持って選択したピボットに成功したと言えます。
まとめ
公募を出す際も、アジャイルの考え方や方法論は役に立つぞというのが、個人的な所感です。
- 小さく準備しておく
- いつでもリリースできる状態にしておく
- フィードバックをすぐに取り込めるようにしておく/取り込む
- 必要であればすぐにピボットできるようにしておく/する