CSMをとった話

はじめに

2020/12 に Scrum Alliance の認定スクラムマスター(CSM)を取得した．
ので，why? な部分とあわせて，これまでの経緯や動機をまとめておこうと思う．
これは僕のメモ書きで，誰かの参考のため，とかは一切考えていないのであしからず．

きっかけ(昔話)

7-8 年くらい前の大型受託開発案件でスクラムをやろうとしてプロジェクトが炎上し， 会社判断により途中で完全ウォーターフォールに切り替えられるということがあった．

それから なぜだろう？ という疑問がずっとくすぶっていたが，これにはいくつかの質問が 込められている．

• なぜスクラムは失敗したのか？
• なぜスクラムをやろうとしたのか？

それから，もうひとつより個人的な疑問があった．

• なぜ僕はチームにコミットできなかったのか？

思い返せば，僕は案件のリーダにも招聘されたスクラムマスターにも心を開いていなかった．
「残業時間を積み上げるのではなく，無理なく開発を進める」「ワークショップを通じてアジャイルについてわかりやすく伝える」 という彼らの言葉は残念ながら「よくわからないけども，ヌルく開発してもいいらしい」という 風に僕の耳には聞こえた．
※ もし，当時の関係者がこれ読んでたらすいません，と謝りたい．残念ながらそう感じたのは僕だけではなかったというのは このあとの展開が証明している．

で，案の定？，プロジェクトは進みが悪く，お客さんに約束したものをこのままでは 到底納めることは出来ない，という状況に追い込まれた．
チーム構成や設計に問題があった，と今なら分析できるんだけども(例えば，コンウェイの法則で説明できる 典型的なダメなパターンにはまり込んでいた)，その話はスクラムとは関係ないので措く．
もちろん，メンバ(代表的なのが当の僕であったりするのだけれども)が，スクラムというフレームワークが 措定している何を守って何は自由にしてよいのかといったルールへの理解が不足していたことは 原因に大きな割合を占める．

見かねた会社の上層部が介入して，経験豊富なマネージャがアサインされ，人員をどんどん投入し， 期間内に約束した機能を全部盛り込める線表(WBS)が顧客との約束になり，・・という感じに変わっていった．

スクラムマスターは気がついたら会社を去っていたし，もはや誰も「スクラム」なんて言わなくなっていた． Redmine 上に作られたプロダクトバックログは誰も見なくなっていて，気づいたときには破棄されていた．

僕は元気に週末や休日も働き，ときどき徹夜したりしてプロジェクト完了まで見届けた．
バグ検出数が何ヶ月も収束しない悪夢のような状況や，致命的なパフォーマンス問題などいろいろ あったけれども，非常に勉強になったし，こういう開発は無我夢中でやってるうちは当人たちはけっこう楽しかったりするものだ．

中だるみ

スクラムはウチではうまくいかない．
そもそも社内で誰もやっていないし，それで特に困っているわけではない(表向きは)．
・・という空気の中，たまに思い返したりもしつつも，僕はこの件を棚上げにした． これまで体験してきた大変だったり炎上したりした案件のひとつという位置づけにしたのだ．
どちらかというと，仕事をとってくるほうが仕事をまわすより大変で，とってきてメンバを集めて 回しだせばなんとかなる．いや，なんとかするのがエンジニアの仕事である，と考えていた (これは一面真実ではある)．

そうこうしている間に海外でのスクラムの勢いはとどまるところを知らず， 国内でも徐々に盛り上がりを見せているのはなんとなく知ってはいた．

大学院進学

僕は 2019 年に産業技術大学院大学(AIIT)というところに，社会人大学院生として入学した．
僕は情報系の学部を出ていない．加えて 昨今のトレンドの移り変わりの早さを見るに，アカデミックに本質的なところを学びたくなった というのがざっくりした進学動機だ．
このあたりの話は社の勉強会で喋った(スライド参照)．

同学で アジャイル開発手法特論 という講義があって， アジャイルと(主に)スクラムの概要を講義形式(+ちょっとしたワークショップ)で教えてくれる．

講義内容紹介
https://aiit.ac.jp/master_program/isa/lecture/

座学なんだけども，why agile? というところからどんどん掘り下げてくれる．
受講生も教室いっぱいになるくらいの人気講義だった．質問もいっぱい出るし．
講師もアジャイル界隈の有名な方 で 僕は偶然知ったクチなんですが，アジャイルの研修と同等の内容を個人としては格安で受講できるので このために受講生になる人がちらほらいるとかいないとか．

ここで僕は最初のふたつの疑問の答えがおぼろげにわかったような気がする．

• なぜスクラムは失敗したのか？
• なぜスクラムをやろうとしたのか？

実のところ，スクラムガイドの一番最初に答えは書いてある．
スクラムガイド 2020 の冒頭には次のようにある．

Copycopy code to clipboard
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。

https://scrumguide-ja.kdmsnr.com

あるいは，クネビンフレームワークを想起してもよい．
たとえば，@ryuzee 氏のブログ記事の一部をひっぱってくるんだけども．

スプリント1を始める前にどんな準備をするか
https://www.ryuzee.com/contents/blog/7147

「2.2 クネビンフレームワークによる問題の分類」にはこのようにある．

Copycopy code to clipboard
これから解決しようとしている問題が明白な領域や込み入った領域であれば、従来のウォーターフォール型の
開発が効率的でしょう。
一方で複雑な領域とカオスな領域ではアジャイル開発が適しています。問題にあった開発手法を選択する必要があるのです。

クネビンフレームワークでいうところの「複雑な領域」「カオスな領域」はいくら計画たてたところで どだい，予測自体が無理だよぅという話だけれども，これはだから，スクラムを取り入れればうまくいく という話でもない．
スクラムはあくまで仕組みであって，ただ，当時の案件のリーダとスクラムマスターはこの仕組みを使って 要件もふわっとしている大型案件という「複雑な領域」もしくは「不確実性」を舵取りしようとしていた．
問題は，開発チームにスクラムを使って不確実性に立ち向かう，という意識が希薄だったこと なんじゃないか，と今の僕は考えている．
じじつ，スクラムから完全ウォーターフォールにシフトするんだけども，開発チームのメンバ各位には あまりインパクトがなかった．なんかやり方変わるのねフーンくらいの気持ち．

スクラムの文脈では開発チームは自己組織化していくことを求められる．
それがいつまでも変革できなかったのは，それまでの会社のやり方にメンバが 染まっていて，マインドチェンジするのが難しかったからなんじゃないか．
つまり，失敗したのはなんのことはない，僕らが原因だったのではないか．

講義を受けながらそんなことを考えていた．

ちょっとした成功

僕は 2020 年の半ばで転職しているんだけど，その直前にリーダを担当していた案件で (それまで例の失敗した大規模案件をやっていた会社に在籍していた)大学院の講義を活かすべく スクラムベースで開発を試してみた．
習いたてのスクラムをいじってみたくて仕方なかったのだ．

受託の開発案件だったので，要件は最初からある程度決まっている．
ただ，細かいところや使い勝手等も考慮して途中からある程度，仕様を 変えさせてほしいと先方の担当者から言われていた．
そこで僕はスクラムベースでイテレーティブに開発を進められないか練った．

しかし，そのままスクラムを導入するわけにはいかないと思った．
社内で「アジャイル」とか「スクラム」とか言うと変な新興宗教にかぶれたように見られそうだし， お客さんもウォーターフォールを念頭に置いているようだった．おそらく「スプリント」 「プロダクトバックログ」「スプリントレトロスペクティブ」・・とか用語切り出しただけで 目を丸くさせることになる．
そこでエッセンスだけ取り出して，一切スクラム用語を使わずに提案する作戦をとった．

例えばこんな感じ．

スプリント → イテレーション1, 2...

約束した開発期間を 2 週間ごとに切ったものをイテレーション(反復)と定義し， 短い開発期間を繰り返すことで徐々に要件が満たされていく，という説明をした．

いわずもがな，スプリント，スプリントレビュー，プランニングの話です．

インクリメント → β 版リリース

イテレーションごとに β 版を提供するので，これに対するフィードバックのみを 要件変更として受け入れる旨を説明した．

また，同じように開発チームにもスクラム用語は一切使わずに説明した．

デイリースクラム → 定例

COVID-19 の猛威ふるいはじめで，開発チームメンバはほぼ全員在宅ワークで， しかも急ごしらえのチームだったため，お互いにはじめて一緒に仕事する，という ありさまだった． 毎日昼前に集まって，15 分めどの短いミーティングをやることを伝えた．
オンラインでタスクボードを用意し，仕掛中のものと問題の有無を手短に報告 してもらうようにし，詰まっているメンバへのフォローは別の時間をとった．

スプリントレビュー → リリース作業

開発対象が Windows アプリケーションだったので，最後にみんなでビルドして 各自手元で要件を見ながら動作確認を行い，先方の担当者にリリースするところまで 行った．
本来なら担当者も含めてお披露目が必要だが，なかなか難しかったのでいったんそこは 社内だけのセレモニーとした．

結果的に，最終リリース日にはすべての要件がそろって動く状態のものができており， 余裕をもってリリースすることができた(と聞いている)．
僕は退職のため，休んでいたのでそのあたりの事情は知らないのだ．

この成功体験は社内的には全然注目もされなかったが，僕にとってはとても大きな収穫だった．
スクラムはうちでは無理，と思っていたのが，実質出来てしまったのだ．

SaaS 企業へ転職

さて，それまで僕は受託ベースのシステム開発に携わってきた．
受託開発の基本は「作るべきものは顧客が知っている．これに沿って作って納める」になるだろう．
本当にそう？ というのがアジャイルへの入り口になるのだけれども，実際のところ，この 疑問をどこまでも突き詰めるのは実際問題，受託ではしんどい．

顧客は自分のほんとうにほしいものを知らない は実にわくわくする考え方だけれども 実践するのは結構難しい．だって，かれらもなにも考えてないわけじゃない．逆に最善を 考えた末，ややこしい仕様が出てくることが多い．
このへんの話はいろんなところで記事があるので省くけども，とにかく，当時の会社で 僕の立場ではアジャイルな考え方を周囲巻き込んでおしすすめるのは難しそうに思えた．

このあたりの話はインタビューで話したことがある．
https://bs.bell-face.com/2020/11/24/2020112401/

他にもいろんな理由があって辞めたんだけど¹，転職にあたっては次のようなことを大切に考えていた．

• 自社でプロダクトを開発・サービス提供している
• 開発組織がアジャイル的な思考に基づき成り立っている

で，入ってみたらそんなにかっちりアジャイルになっていない・・というか，ただのカオスだった．
メンバはチームというより，プロジェクトにぶら下げられ，プロジェクト完了時には バラバラにされて，また別のプロジェクトにアサインされる．
プロジェクトマネージャやディレクタが線引きした線表に従い，あいまいな優先付けの 名ばかりロードマップのもと何本も開発のラインが走る．
当然，メンバの士気は総じて低い．

これが受託なら仕方ないと思う．
しかし，SaaS 提供してて，これから大きくなろうというベンチャー企業である．
そして，僕にはメンバがかつてスクラムに，チームにコミットできなかった僕じしんに重なるものを 感じるのです．違うかもしれないけど．

これ，アジャイル的な考え方，スクラム導入できたら超たのしいんじゃないの？

Conclusion

そうして，スクラムの伝道師になろうと思った僕は 2020/12 に認定スクラムマスター(CSM)を取得した．

何問か落としたけど，ひとまず取れました(問題文の日本語が怪しいせいにしたい気持ちはちょっとある・・)．
今後は，耶蘇教の伴天連が如く・・ってやつです pic.twitter.com/CpQqUUrYUA

— yk (@youknowcast) December 12, 2020

僕が受けたアギレルゴコンサルティングの CSM 研修
https://www.jp.agilergo.com/training

オンラインで認定スクラムマスター研修をしてくれた Cope は
「こんなのはただの資格でテスト受ければ取れるけど，もし僕がスクラムマスターを認定する権利を持っていたら，スクラムマスターとして実際にチームに雇われて チームがやがて自立してスクラムマスターであるあなたをクビにしたその瞬間に認定したい」
というようなことを言っていた．

というわけで，新米認定スクラムマスターの僕はチーム(か組織かわかんないけど)を 自己組織化した暁にクビになるためにまずは頑張ろうと思う．