RSGT2024 1日目で印象的だったセッション3つ
普段はこういうの書かないんだけど、今日は覚えておきたいので書く。
よいチームをよい雰囲気を保ったままよい組織にスケールさせていくためにできること
及部さんも毎年のように RSGT でセッションを担当されていて、毎年とは言わないけど、結構な割合でその発表を見させてもらっている。そうやって「連続モノ」としてとらえるようになり、最近は及部さん自身の「キャリアの旅」みたいなものを感じるようになった。自分の先を走るスーパースター（スターじゃなくてモンスター？）も、こんな風に一人の職業人としてキャリアを積んでいくんだとリアルタイムで実感したり、数年前とは全然違う仕事をしていて、それでいて全部が及部さんらしい、少し不思議な感覚を覚えたりする。
今回の及部さんのセッションは、序盤で「良いチームを作ることに興味があるが、それをスケールさせたり、複数のチームをマネジメントすることには興味がわかない」と書きながら、結局は現職でその仕事に「自身のやり方」で踏み出し始めた話が（敢えて頭悪い書き方をするけど）最高にエモかった。そして及部さん自身がそれまでのコミュニティ活動で培ってきた経験やプラクティス、さらに各種理論で裏付けながら自分の仕事の変化をまとめられている様子を見させてもらい、「あぁ自分ももっとこうやって裏付けを持って仕事で成果出していかないとな！」と、今年もRSGT特有の元気をもらえた瞬間となった。
エンジニア組織の経営論 〜エモい開発と売上数字は両立するか〜
「物好きが集まった」（漆原さん談）ナイトセッションも、さすが漆原さんというトークだった。
最近も話題になった「経営がわかるエンジニア論争」だが、漆原さんの指摘は「経営やビジネスの話をエンジニアが "うっ" と思うのは外発的要因に紐づく数字ばかりがビジネスや経営だと思うからではないか。」というものだった。細かい話の流れは省略してしまうけど、結局は「経営者やビジネスオーナーの内発的動機を揺さぶるワクワクするものに共鳴できるか」。漆原さんいわく、マツダの人はこっちが追いつけないくらい発動機の話をするし、カゴメの社長はリコピンがいかにすごい物質であるかを語りだしたら止まらない。そんな人たちに、技術の専門家として立ち向かっていけるか。
自分自身のこれまでのキャリアを簡単に振り返っても、仕事が楽しいときは、「社内のいろんな人がワクワクしてるもの」を聞き、それに共感できること自体が楽しかったし、その「ワクワクの振動」に「自分が楽しいと思うもの」をぶつけてさらに面白がりあえることが楽しみだった。逆に言えば、楽しくなかった仕事には共鳴するワクワクを見出せなかったこと*1ばかりだった。
経営者として技術組織を経営するためにできることは「没頭・成長・ポジティブ」に溢れる環境づくりだ、という話も、当初期待していたものではなかったけど、いろんな勇気をもらえた。忘れないで今年1年を過ごしたい。
証券取引所のサービスをアジャイルに開発し続ける上での学びと取り組み〜信頼性とアジリティの両立を目指して〜
自分のキャリアの半分以上の時間は金融領域でエンジニアリングしてきた時間が占めているので、「金融領域の仕事だからアジャイルでいられない」とは全く思っていない。それでも、というか、だからこそ、制約の多い環境下で実際にアジャイルであり続けようともがく人の話はやっぱり聞きたくなるし、話を聞きながらいろんなことを想像してしまう。
品質保証における「最も防ぎたいシナリオ」を出発点とした重点施策の話や先物対比に関するプロダクトリサーチの実例も興味深かったが、一番印象深かったのは「チームイベントの持続的な改善」にまつわる話だ。
午前中の基調講演で Dynamic Reteaming が取り上げられていたが、この事例でも「チームのメンバーは年単位で見れば大半が入れ替わる」ということを念頭に置きつつ、立ち上げ期の思想や情熱が人員異動とともに失われてしまうことの対処として、スクラムイベントやプラクティスなどの「チームのあり方」を定期的に見直す仕組みを導入した、という話。
組織の中に様々な仕事があったとき、ともすると、何かの「立ち上げに関わること」が最もチャレンジングな仕事であると捉えられてしまうパターンは少なくない。何も無かった更地を自分色に染め上げて一旦の「完成」にたどり着き、それを「自分の作品」と呼んでしまえば、たしかにわかりやすい成果になるし、組織内でも評価されやすいだろう。
他方で現実問題として、大きい組織であればあるほど「新しく始める仕事」よりも「保ち、さらに大きくする」仕事が多くなるのも必然だ。そこに関わる人も同様に評価されるべきだが、少し気を抜くと、「保つ仕事」には「自分で考えて新しい何かを作る」機会が生まれず、「保ち、更に大きくする仕事」が「単に保つだけ」の仕事になってしまうこともある。
今回の事例では、「チームのあり方を作る」という観点ではその時々にチームに身を置いたものが自分でチームを作るという仕組みがあった。こういうチームが組織内にいくつかあって長く続けば、そこで育った人材がまた巣立ってゆくという新陳代謝が生まれる。そうすると、組織全体で見ても「あそこで育った人ならきっと大丈夫」という安心感のある「ブランド」として機能するし、組織全体にとって良い影響をもたらす。私自身の経験になるが、かつて働いていた職場で「開発リードのゆりかご」と呼ばれたプロダクトチームがあった*2のだけど、あのチームはこういう土壌から生まれたんだろうか、と、講演を聞きながら想像を巡らせていた。
当日の撮って出しな記事なので乱文な部分もあると思うが、ここらで。明日も目一杯ギャザろう。
ライブコーディングで GitHub Copilot を使うべきかどうか
TL; DR
- 場合による
- "How to" を教えるライブコーディングの場合は、切ったほうが良い
- 設計議論を中心に行うライブコーディングの場合は、使うと良いことがある
文脈
最近の仕事の中で、プログラミングを学んでいる人々の前で、オーディエンスのスキルアップを目的としたライブコーディングを実施したり、ライブコーディングセッションのアレンジをしたりファシリテーションをしたりしている。少々性格の異なるライブコーディングを数パターン行うなかで、「ライブコーディングで GitHub Copilot を有効にするべきかどうか」という問いに答えるに当たって一つの指針が見えてきたので書き残しておく。
How to を教えるライブコーディングでは Copilot を切る
自分が担当したライブコーディングは、特定のテスティングフレームワークの使い方やテスト駆動開発の講義だったのだけど、このような「特定のツールやフレームワークの使い方を教える」や「手法を教える」ことが目的の場合は、Copilot は明確に切っておくべきだ。
このような「How to」を教える手法としてライブコーディングが優れているのは、同じコードを書き起こす場合でも、どのような考えに基づき、どのような順番でコードを書いているのかの思考をオーディエンスがリアルタイムでトレースできることだ。とても単純な例だが、仮にエディタによる補完が効かない状況で console.log(message) と書くだけでも、最初に console.log() とまで書いてから、末尾にあるキャレットを1文字戻してから message と入力するだろう。本当のプログラミング初心者なら、より経験あるプログラマのこのような所作ひとつでも学びになる。しかし、Copilot を有効にしてしまうと、こういった体験をほぼ全てすっ飛ばしてソースコードが出来上がってしまう。
また、このような How to を教えるコーディングの題材は単純なものであることも多く、それまでに書いたコードから Copilot が提示してくる候補の精度も比較的高いことがある。一旦提案を受け入れた後に議論をするように試みても、すんなりと「良いコードですね」という結論になって終わってしまい、コンテンツ的にも面白みのないセッションになる可能性が高い。
設計の議論が目的の場合は、Copilotを使うとセッションの濃度が上がる
逆に、オーディエンスが必要なプログラミングのハードスキルを一定程度持ち合わせていることを前提として、ライブコーディングを通じて設計の考え方を伝えたり、インタラクティブに議論をしながら簡易アプリケーションを作ることを目的とする場合は話が変わってくる。
同じ時間・同じコード量を書くことを前提とする。すると、まず Copilot があることで、コードを書き起こすことに費やす時間が減ることで、コーディング実施者が自分の考え方について説明したり、トレードオフを整理して簡単な議論をしてからコードを書く、ということを丁寧に行えるようになる。オーディエンスもわかり切っているコードなら、さっさと Copilot に書かせたほうが良いに決まっている。それはライブコーディングセッションでも変わらない。
濃度だけでなく、持久力も向上する
加えて、個人的には想定外だったのは、Copilot があることでコーディング実施者・オーディエンスともにセッション参加に際してのスタミナ消費が抑えられるのではないか、ということだ。
実際にやってみるとわかるのだが、人がだらだらとコーディングしている様子をただじっと眺めているのは意外と疲れるし、飽きる。その飽きを回避しようと思っても、プログラマーは他のトークを回しながらコーディングをすることはできないし、仮にプログラマーと別にファシリテーターがいても、コーディングの様子を眺めるアテンションを吸い取ってまで有意義な話を差し込むのはあまり現実的ではない。
Copilotがあることで、この退屈な時間をすっ飛ばして、より議論に入り込めるようになり、うまくいくセッションなら「時が経つのも忘れる」モードに持ち込める可能性が高まってくる。自分が実施した例だと、Copilot無しでは60分続けるのが色々な意味で限界だったセッションが、Copilotありの場合は90分も余裕だった。
ただ、これに関しては筆者自身も試行回数がまだ多いわけではなく、コーディング実施者を固定して複数パターン試行したわけでもなく、いま持ち合わせている経験だけで言い切るのは少し無理があるかな、と思っているのも事実。今年も色々とトライしてみようと思う。
まとめ
改めて振り返ると、普段から生成 AI を利用する際に気をつけていることと大きくズレた話ではないと思う。ライブコーディング自体はトレーニングのメインコンテンツにはできないけど、目先を変えたりオーディエンスの視野を広げるには良い手法なので、今回取り上げたようなコツをうまく踏まえて活用できたら良いと思う。
2023年のこと
例年以上に「年納め」という感覚の分からない状態だけど、なんか書かなきゃいけない気がするから書く。
どんな働き方をしてたか
2021年末から複数の企業と業務委託または契約社員として関わる働き方を始めた。2023年なので、もう2年も経ったことになる。
何をしていたか
人材開発
今年、大きく状況が変わったのは、1つの企業に大きく重心を乗せるようになったことだ。1年のトータルで見れば7割強の時間を1つの会社で過ごすことになった。主な仕事は人材開発であり、具体的には研修に盛り込む具体的な技術要素や、研修のインストラクショナルデザインをマクロ・ミクロ双方の粒度で検討したり、実際にその設計に基づいて研修で講師として喋り倒したりしていた。
この仕事に就いた去年（2022年）の半ば頃、自分には明確なロール名は与えられていなかった。それが去年の末から年明けにかけて仕事が進んでいく中で「自分のやりたいこと」と「会社に必要なこと」のすり合わせができてきたように感じる。自分は先生になりたい訳ではないし、「憧れや目標になる先輩」として振る舞うにもトレーニーとは歳が離れている。自分がやるのは、それまでのエンジニアリング・マネジメントの経験を活かした、エンジニアリング組織との橋渡しとトレーニングのクオリティ向上だ、と考えがまとまるようになった。今年の春が訪れる少し前の頃、その役割を「テクニカル・ディレクター」と勝手に呼ぶようになった。
当然のことだけど、それまで組織になかった仕事をするのは難しい。それまで「技術者としてキャリアを歩んできた人が人材開発に携わるとは、具体的に技術を1対1に近い形で教えること」以外がほとんど存在しなかった組織では、「テクニカル・ディレクター」と言われてもピンとこない人がいないわけでもなく、自分としては「ひとつずつ成果を残していくしかない」状況だった。そのことを自覚しつつ、幸いにも会話をすれば意義を感じてくれる人に恵まれた組織であることも手伝い、スムーズに仕事をさせてもらえた1年だったのではないか思う。目の前の仕事を着実にやり遂げつつ、このロールがちゃんと組織に根付いて、どこかのタイミングで誰かに後任に任せることができる（ロールについてのおおよそのイメージが湧く・組織がそのロールありきで組織を考える）ようになることが当面の目標かな、と考えている。
去年の振り返りでも「人材開発の仕事は来年どこかで話せれば」みたいなことを書いていたが叶わず。どこかでちゃんと知見としてアウトプットする機会は、来年こそ作ろう。
アジャイルコーチング
加えて、これも昨年までと同様にチームの開発プロセス確立のための支援や、チームリーダーの壁打ち相手となるための支援をしてきた。
個人的に嬉しかったのは、今年の春先で支援活動を一旦終了したクライアントから、支援したチームや事業のその後の成長について、この年末になって話を聞けたことだ。コーチングの一貫で行う支援活動に即効性がないことも多く、その活動の真っ只中には「果たして報酬に見合う貢献をしているのだろうか」と不安になることも多かった。それらが実際に実を結んだんだという実感を、タイムラグが有りながらも持てたことは大きかった。「アジャイルコーチング」と銘打って行う仕事の割合は僕の中では減らしてしまったのだけど、「こうやったら良さそう」という引き出しが増えたこともとても大きい収穫だったと思う。
この1年で思ったこと: スパンの長い仕事を頑張る
思えば2018年ごろから、ソフトウェアエンジニアが10~30人程度の企業・組織で、組織づくりやチームづくりから担う仕事にずっと携わっていた。この規模の組織を直接マネジメントしたり率いたりしていた頃は、即効性とインパクトの大きさを両立した施策を打つ余地も多かったし、出したインパクトも実感しやすかった。
それが、規模の大きい組織での仕事（100人を越える研修対象がいるトレーニング）だったり、直接自分が事業や組織を動かしているわけではないコーチングの仕事には、また違った難しさがあった。もちろん、インスタントに打てるROIの高い施策も存在しないわけではないけど、そういう施策だけを探して手当たり次第に実行しているだけではすぐに手詰まりがやってきてしまう。そんな時に「より労力がかかってインパクトが残る、重要な仕事」を見つけるのが重要なのだけど、これまでの自分は「課題自体の純粋な難しさ」だけに着目しがちだったように思う。この1年の経験で「長いタイムスパンでインパクトを残す」方向を意識して難易度を上げる引き出しが出てきたんじゃないかと思う。答え合わせまでのスパンが長いので、小さなサイクルでの仮説検証と、揺るがない信念の両面が大事になってくるんじゃないかな、きっと。ということで来年も頑張ろうと思います。
そんなところで。プライベートの話は別のメディアで。
『単体テストの考え方/使い方』を読んで現実的なテスト駆動エンプラ開発を考えよう
年末年始に『単体テストの考え方/使い方』(原著: Unit Testing Principles, Practices, and Patterns, 以下 UTPPP) を読んだ。
UTPPP 内でも紹介されているが、テスト駆動開発 (TDD) には大きく「デトロイト学派1」と称される考え方と「ロンドン学派」と呼ばれる考え方が存在して、その最も大きな違いはモック (テスト・ダブル) に対する考え方にある。自動化されたテストによるアプリケーションのテストカバレッジを向上させる上でテスト・ダブルの活用は避けて通れないが、テスト・ダブルの利用にはメリットもデメリットもあるため、2つの学派のスタンスを踏まえた上での落とし所を見つけることが重要となる。
テスト駆動開発にはざっくりいうとモックを積極的に使う派（ロンドン学派）とあまり使わない派（デトロイト学派、古典派）がありまして、私は後者なのでほとんど使わず、このエントリに深く同意するところです / “モックは必要悪で、しないにこしたことはない - …” https://t.co/VjDvospTKu
— Takuto Wada (@t_wada) 2021年10月15日
デトロイト学派のバックグラウンドとなる書籍として有名なものが Kent Beck による『テスト駆動開発』(通称: TDD本) であり、一方でロンドン学派による TDD 手法が解説されているのが『実践テスト駆動開発』(通称: GOOS) である。JUnit を始めとする "xUnit" と称されるテスティングフレームワーク群を用いたテスト手法パターンを解説した『xUnit Test Patterns』(通称: xUTP) もバイブルとして挙げられるだろう。UTPPP では、この3冊の内容を踏まえた上で、現実的なエンタープライズアプリケーションにおける自動テストの実践方法が説かれている。 TDD本やGOOSが単体テストを通じた「真っ当なオブジェクト指向プログラミング」へと導いてくれるように、UTPPP も書籍を通してテスタブルなアプリケーションアーキテクチャを実現してゆく過程で ヘキサゴナル・アーキテクチャへと行き着く流れがよく出来ていると感じた。
極めて個人的な視点で、そんなUTPPPの推しポイントを2点紹介してみたい。
エンハンスし続けるアプリケーションの目線からみたテストの価値観
「良い単体テストとはどのようなものか？」という問いに対するよく聞く回答の一つに「良い単体テストは F.I.R.S.T. の原則を満たす」と言われる。
- Fast: 高速に実行される
- Isolated / Independent: 他のテストケースや依存先から隔離され、独立している
- Repeatable: 繰り返し実行できる
- Slef-validating: テストの成功・失敗を単体テスト自身が判断できる
- Thorough: 網羅性がある2
この F.I.R.S.T. の原則は間違いなく重要だし、効果的な単体テストを書くスキルを身につけるための出発点であることは間違いない。一方で、F.I.R.S.T. には「プロダクションで動くアプリケーションをメンテナンスし続ける」ために必要なバランスという視点が欠けているようにも思える。『Googleのソフトウェアエンジニアリング』にて「エンジニアリングとは、プログラミングを時間方向に積分したもの」という言葉があるが、F.I.R.S.T はまさにプログラミングの視点で「テストを書く」ための指針なのである。
そこで参考になるのが、UTPPPの示す「良い単体テストを構成する4本の柱」だ。これはまさに単体テストの「エンジニアリング的」な価値基準を表しているのではないだろうか。それぞれの詳しい解説は本書に譲るが、具体的には、以下の4つである。
UTPPP の中ではこの4本の柱の中でも「保守のしやすさ」以外の3つはトレードオフの関係にあると述べている。1つめの「リグレッションに対する保護」はテストの存在意義そのものであるためトレードオフ上捨てるという選択は存在しない。どのように残りの「リファクタリングへの耐性」と「迅速なフィードバック」のバランスを取り、テスト・ピラミッドを構成してゆくのかを考えることが本書のテーマだ。だから「単体テスト」と題名に冠されているが、最終的にはインテグレーションテストまでを扱うことになっている。
モックの使いどころの理路整然とした解説
これまで自分自身も、サーバーサイドアプリケーションを開発する上でさまざまなテスト・ダブルを活用してきた。「この場面ではXXXをモック化するべきか、実態を利用するべきか」は常にチーム内で議論になるものだし、言語化も難しいテーマだ。なんだかんだ開発がスムーズに進む場所で落ち着きはするのだが、もう少しロジカルな納得が欲しいと思っていた。
UTPPPでは、依存関係を「共有依存」と「プライベート依存」、「プロセス外依存」などの分類をしながら、どの依存関係にテスト・ダブルを導入するべきかを説いているところが良い。自動テストのピラミッド理論を知っていたとしても、そのピラミッドを体現するための匙加減や技術的なコツをしっかりと言語化した資料にはなかなか出会えないのではないだろうか。
言うなれば、UTPP はテストに関する経験値稼ぎのショートカットになるのではないかと思う。これまで「ちょうどよいテストピラミッドを構成するための勘所はメンターと仕事を共にして養おう」となっていたものが、そのようなメンターに恵まれなくてもなんとか試行錯誤をする勇気をくれるのではないかと思っている。
各論でいえば「そうは書かないだろう」と思う部分もあるし、C#というプログラミング言語に疎いが故に持つ違和感もあるのだが、全体的にはとても良く整理されている書籍だと思いました。気になる方はぜひ。
2022年のこと
昨年の振り返りで書いたように、2021年10月をもって正社員として働いていた会社を退職して以降、半独立した形で複数の企業と関わる1ようになった。
結局は2022年もこの形式のままフルで過ごした。既に関わらなくなった企業を含めると今年1年で5社と関わったことになった。もちろん自分にできる貢献を各社にしつつ、様々な学びをさせてもらい続けた日々だった。求めてくださった皆様に感謝の限り。
「アジャイル・コーチング」と言う恥ずかしさが消えたのは
一番多かった仕事は開発プロセスやチーム運営に関する支援だ。スクラムの実務経験がないメンバーでチームを組成している状況で手本を示したり、チームリーダーの壁打ち相手になるような仕事である。これまで自分自身が経験してきたことを踏まえつつ、クライアントの「外側」にいる立場だからこそ「こういう事もできるけど、あなたはどうしたいの？」と問うことで、クライアントにも自分にも様々な発見があった。
当初は自分の仕事を「アジャイル・コーチング」と呼ぶことにどこか恥ずかしさがあった。日本国内を見ても、アジャイル・コーチというキーワードで出てくる顔ぶれが錚々たるもので、自分がその人々に肩を並べて同じ働きをできるのか？と思ってしまったのだ。自分がやっている仕事は所詮 "自称: アジャイル・コーチ" でしかないのでは？とも思っていた。
この気持ちを拭うきっかけになってくれたのが、これまでも何度か自分のキャリアの転換点を作ってくれた横道稔さん (id:ykmc) だった。今年の前半のどこかで彼とお話しさせてもらったとき、
誰だってきっと最初は "自称" だったんだよ
という言葉をもらって重荷が取れたように思う。確かに、認定資格があるわけでも、誰かが自分の "アジャイルコーチング" を評論したり点数をつけるするわけでもない。目の前のクライアントに向き合うこと以外の邪念の多くを捨てることが出来たような気がしている。感謝しかない。
「教育」と言うのはおこがましいけれども
アジャイルコーチングの他に、"ITプロフェッショナルの卵" を対象にした研修にも関わるようになった。自分が新卒で入社した会社を退職するまでの4年半の間には、内定者研修を手伝ったり、新人を現場で指導するメンターとして働くこともあった。その頃から「もっとこうすればよい新人が育つのに」と思うことも多かった。その当時の思いも胸にしつつ、これまでにないバランス感覚の求められる仕事をさせてもらっている。
実際に研修の企画や実施を行うとなると、想像した以上に変数が多い難しさを感じる。社会人生活を初めて3〜4年目の青かった頃の自分がそのまま新人教育に関わってたら大変なことになっていただろうなぁとさえ思う。エンジニアリングマネージャーとして働いたり、様々なフェーズの会社に身を置いてきた自分だからこそ出せる成果やできる貢献がある、と思って仕事をしている。
来年は研修周りの話もどこかでパブリックにできれば良いと思っている。
翻訳レビューとか翻訳とか
仕事外のことでいえば、書籍『ソフトウェアアーキテクチャ・ハードパーツ』の翻訳レビューに関わったことも新鮮だった。
翻訳レビューに参加した『ソフトウェアアーキテクチャ・ハードパーツ』の献本が届きました！ほんの少しですが初めて書籍制作に関わらせて頂いて様々な学びがありました。過去の職場で悩んだことをおさらいになったり発見があったり、読書としても最高の体験でした。 @snoozer05 さんお疲れ様でした！ pic.twitter.com/RxOy87VUai
— むらみん (@Mura_Mi) 2022年10月21日
内容もさることながら、その編集プロセスを見ることが出来たのが個人的に大きな経験だった。CSS組版などの概念は知っていたけれども、実際にそれがワークしているプロジェクトを見たのは初めてだったからだ。
普段の自分の生業であるシステム開発では当たり前のように継続的インテグレーション (CI) や継続的デリバリー (CD) を実践していたし、それがない世界を考えたことが殆どなかった。一方で自分の中ではこれまで「書物」や「ドキュメント」を CI と紐付けたことがなかったので、この経験を通じて CI が存在する意義や生産性の圧倒的な向上を再認識したように思う。この学びは本業にもフィードバックすることが出来て、研修コンテンツの制作には Vivliostyle — Enjoy CSS Typesetting! を活用して、 textlint や markdownlint を組み込むと言った鉄板構成に取り組むようになった。
また、InnerSource Commons JP コミュニティに関わることになり、そこでも英語コンテンツの翻訳に関わるようになった。インナーソースの話は個人的に大きな関心を持っているんだけど、どうしても仕事と絡んだ話になるので、また別の機会にじっくり話したいと思う。
innersourcecommons.connpass.com
総括とか来年とか
そんな感じで、2022年はこれまでにない経験をたくさんできて、これまでの職業人生活とは違った充実を感じ、大きな進歩を実感することとなった年であった。この記事では言及してないけど、私生活でも息子が産まれて2年が経ち、今年も未知の世界を息子に見せてもらい続けた。
一方で、ストレスゆえか身体に出るような不調があったのも事実で、ハイテンションで駆け回って知らぬうちにダメージを負ってたのかなというのもある。公私それぞれ思い当たる節がないわけでもないので、自分なりにストレスを受け流したり忘れたり遠ざけたりしながら、来年もいい感じで生きていこうと思う。
「完了の定義」と「受け入れ基準」から逆算で考える「スプリントバックログ」
スクラムにて効果的なスプリントバックログを書き出すには？という話です。スクラムに則っていることを前提とします。
スプリントバックログとはどうあるものか
スプリントバックログ (以下: SBL) は「スプリントに設定された目標1を達成するために必要だとチームが考えている作業の一覧」です。スクラムではこのスプリントに設定された目標を達成するために取り組むプロダクトバックログ (以下: PBL) を選定するので、SBLの大半は「PBL を完了させるために必要な作業」となります。2
ただし応用として、複数のPBLの上流となる作業が生じることもあるし、PBLとは直接関係しない作業もSBLとして扱うこともあります3。単純なPBLとSBLによるツリー構造になるとは限らないことに注意したいです。
有用なSBLを書き出すことで、PBLの完了間際になってチームが慌てふためくことを防いだり、大半のPBLが未完了のままスプリントが終了してしまうリスクを軽減したりできます。これは、PBLが完了するまでの道のりが SBL として明文化されてチームで共有されるためです。これはスクラムの柱のひとつである「透明性」の実現にあたります。
有用なスプリントバックログをどう書き出すか
「完了の定義」と「受け入れ基準」を活用することで、予め抜け漏れが生じづらい有用なスプリントバックログを書き出すことが出来ます。むしろ、後から困ってしまうような「完了の定義」と「受け入れ基準」を運用しているならそれは問題で、改善する必要があると言えるでしょう。
これを上手にやるには「完了の定義」と「受け入れ基準」をそれぞれ理解している必要があります。
完了の定義と受け入れ基準
完了の定義 (Definition of Done = DoD) は、開発者を中心としてチームが主体的に定める「すべてのPBLが完了時に満たすべき事項の一覧」です。インクリメントはどの程度テストされているべきであるかや、開発環境にデプロイするところまでをもって完了とすること、など。完了の定義は、PBLの実装内容に依らず共通するはずです。
受け入れ基準 (Acceptance Criteria = A.C.) は、「PBLがプロダクトオーナーの意図した通りに実現されていることを確認するための手段」です。受け入れ基準はPBLごとに異なります。例えば、「タイトル欄が未入力で送信することができないようにする」というPBLと、「タイトル欄に絵文字を入力できるようにする」というPBLでは、実現する機能や価値が異なるので、PBLが完了とみなされる基準 (= プロダクトオーナーが受け入れる基準) も当然異なります。受け入れ基準は PBL の一部なので、その記述内容はプロダクトオーナーに責任があります。
完了の定義と受け入れ基準からスプリントバックログを導き出す
「PBLを完了させる」とは「完了の定義と受け入れ基準を満たす」ことであり、「PBLを完了させるために必要な作業をSBLとして書き出す」のだから、「完了の定義と受け入れ基準に沿ってSBLを書き出す」ようにすれば、必要な作業の大半を洗い出すことができる はずです。
ここまで来ると、スプリントバックログの表現方法ごとに再現性のある書き出し方法を工夫できます。
- miro などのオンラインホワイトボードツールなら、完了の定義を満たすバックログはコピー&ペーストやテンプレート呼び出しで一気に出せるようにする。
- ホワイトボードの物理カンバンなら、受け入れ基準やその他の PBL は付箋で、完了の定義はマグネットシートで表現する。
- Jira のサブタスクで SBL を表現しているなら、完了の定義に相当する SBL を書き出すオートメーションを実装する。
自動化や型化できるところにマインドシェアを割かず、スプリントごとに異なる要素にクリエイティビティを発揮できるようになると、自ずと成果につながるスクラムの実践ができるんじゃないかと信じています。
相対見積もりが機能するために必要そうなこと
この1年、様々なチームを支援する中で共通して出てくる話題もなんとなく見えてきて、そのひとつが「相対見積もり」の取り組み方に関することだ。そして、テクニックの話の前に、相対見積もりに対する「発想」や「スタンス」に問題があって機能不全や逆効果に結果することが多いと思っていて、その話をしたい。
ちなみに、個人的には「相対見積もり」のことを「ストーリーポイント」と呼ぶのは好きじゃないんだけど、その話はまたどこかで。
ベロシティはスプリント計画の「予算」
1つのスプリントが終わった時にそのスプリント内で「完了」したプロダクト・バックログの相対見積もり値の合計のことを「ベロシティ実績」と呼ぼう。次のスプリントを計画するときに、直近の数スプリントのベロシティ実績から、次のスプリントで実現できそうなベロシティを予想する。例えば直近最大5スプリントの平均値をこのスプリントの予想ベロシティとしよう。スプリント計画では、この「予想ベロシティ」にほぼ収まるようにスプリントに取り組むプロダクト・バックログを選ぶ。ゆえに「予想ベロシティ」はスプリント計画の前提となる「予算」である。相対見積もりを行う目的は、この「予想ベロシティ」を算出することに他ならない。
誤ってもスプリントの中盤から終盤になって誰か (大抵の場合はマネージャー) が相対見積もり値の予定と現時点の実績を持ち出して「XXポイントを完了させなきゃいけないのにまだYYポイントしか出来上がってないよ」と鐘を叩いて急がせるような真似をしてはいけない。また、スプリントの終了時にスプリント計画時よりも大幅に下回ったベロシティ実績 だけ をみてチームの能力や成果を判断してはならない。一度そうしてしまったら、相対見積もりを行う開発者は次から自らの身を守るために保守的な見積もりをするようになる。開発力も見積もり能力も上がらずに相対見積もりの値だけが大きくなる様子は、インフレーションというよりスタグフレーションという例えが適切に思える。
ベロシティは変動する
「ベロシティ」という言葉は長い道のりを自動車やマラソンなどで走り切る際の「速度」にインスパイアされた比喩だ。このとき、速度には2種類ある。速度計が指し示す「瞬間的な速度」と、特定の地点からもう一つの地点までの走行距離を走行時間で割った「平均的な速度」だ。スクラムの相対見積もりにおける1スプリントの実績ベロシティは瞬間的な速度である一方、スプリント計画時に利用する予想ベロシティは平均的な速度の考え方に則って算出する。
大切なのは、車にしても人にしても、終始一定の速度である程度長い距離を走ることはない ということだ。例えばレースの中盤に差し掛かって走者の身体が温まってくることもあるし、逆に異変が生じるかもしれない。走っている道がフラットな一直線なのか、入り組んだ市街地なのか。カーブが続く道で速度計のみを凝視して運転してはならない。
だから、スプリント計画を行う時には、必ず予想ベロシティ以内にチケットを収めなければならないわけでもないし、予想ベロシティ以上を積むのを禁じるわけでもない。でも迷ったら少なく積む方を選ぶかな。少なく積んで集中して確実に仕留めるのが「リーン思考」のハズなので。
互いの「コミットメント」を信じる
日本語で「コミットメント」というと、「後に引けない程に覚悟を持った約束事」のような意味合いで使われることが多い。一方で commitment を辞書を引くとかなり多義なのだけれど、そのひとつに 「献身」 という意味がある。積極的な関わりとか、傾倒していることとか。以下の椎葉さんの記事にもあるように、どうやら「スクラムの価値基準」にあるコミットメントというのは、献身の意味で捉えるのが正解なようだ。
コミットメントは『献身』であり、それは最終結果に対してではなく、行動や努力に対して適用するものである
相対見積もりが正しく機能して生産的なチームを支えるために一番必要なのは、スクラムチームのメンバーが互いのコミットメントを信じることができる状態なんじゃないかと思う。
マネージャーが相対見積もりを使って開発者の尻を叩くのは、開発チームのコミットメントを信じていないからではないだろうか。開発チームがベストを尽くしているなら、そんなことをしても成果は改善しない (ストーリーポイントをインフレさせればベロシティは向上させられるだろう)。コミットメントを信じられない一方で、相対見積もりという分かりやすい数字が手に入ってしまったが故に、入り組んだ道をアウトバーンと同じ速さで走るように求めてしまうことはないだろうか。「スプリントに少なめにプロダクト・バックログ・アイテムを積んで開発者は遊んだり手を抜いたりしないだろうか」という誰かからの指摘に対して「早めに全て完了すれば、プロダクト・バックログから適切なアイテムを自主的に取るか、必要に応じて生産性向上のための投資をします」と、自信を持って言えるだろうか。
そして、1人の開発者としてコミットメントを信じてもらえるように、透明性の高いプロセスで最高の成果を出すことはできているだろうか。信頼の構築は「鶏と卵」だ。「鶏と卵」の問題は自分が動かせるものから動かすしかない。
そんな前提を成立させるところからスプリントプランニングやリリースプランニングの成功は左右されるんじゃないかな、と最近は考えている。
