🗂

アジャイルー組織のアジャイルの普及についてー

2022/12/12に公開

本投稿は スクラムギャザリング&スクラムフェス Advent Calendar 2022の12日目の記事です

前提

私はWebサービス(B2B)企業の内製開発者です。
「この話をRSGT 2024にプロポーザルとして出せたらいいな!」というつもりで、内製開発にスクラム開発を持ち込んだ上での経験を語っていこうと思います。

まず最初に失敗した話をして、次にその失敗を踏まえてどうしようとしたかという話をします。

大事な点は、スクラム開発は多くの人にとって従来の常識とコンフリクトします。
地球は丸くて、宇宙の中心にはなくて、太陽の周りを回っているという地動説のように、です。
従来の常識とのコンフリクトはストレスを生み、ストレスを感じた人々はストレス源を魔女狩りしようとします。
今回は黒焦げにならずにゴールに辿り着くための話をしようと思います。

私はそれを美しいと思った

過去のアジャイル開発ブームやアジャイルサムライ読書会ブーム。
そこで現場の課題や解決策、アジャイルの導入について語り合う人々。
私も当時そこにいて、目を輝かせる人々と出逢いました。

来日したジョナサン・ラスムセンやryuzeeさん、長澤さんたちの基調講演。
そこで語られる理想。
私はそれを美しいと思いました。

いつかアジャイル開発をやってみたい。
そう考えるようになりました。

そして転機が訪れる

えっすあいあーからWeb会社に転職してエンジニアになった私に転機が訪れます

オラがムラにもスクラム導入がやってきた

ついに弊社でもアジャイル開発の一種、スクラム開発の導入の機運が高まってきます。
偉い人がこう言いました

  • 「開発組織では全部署的にスクラムを導入していくぞ!」
  • 「指名された人間は認定スクラムマスター研修に行ってもらう!」

かつてアジャイルに目を輝かせた私もワクワクを隠せません。

人々も喜びます

社内でも多くの人が声を上げます

  • スクラム開発は前の職場でもやったことがあるんですよ
  • スクラムフェスで見たことがあります。ぜひやってみたいですね
  • スクラム開発は前から興味あったんです。自分はSCRUM BOOT CAMPを読んだだけですけど

社内にもスクラム開発の賛同者がこんなにいたんだ!という思いで嬉しくなります。

俺たちで最強のスクラム開発の開発組織を作っていきましょう!
そういえばアジャイル型開発組織立ち上げ経験があるすごい人も役員待遇で入ったらしいよ、やったね!

  • スクラムは最新=最優のマネジメント方式!
  • これで開発プロジェクトが納期スリップしまくり問題も解決するぞ!
  • スクラム導入で生産性爆上げだ!

なんよ良く分かってなさそうな人もいるみたいですけど、スクラム開発に対してポジティブな雰囲気があるのはいいことですよね!

順調だよ!楽しいよ!(ただし最初はね)

スクラムマスターとして指名された人間は認定スクラムマスター資格の研修に行ってきました。
「講師の人が熱かった!」と熱く語ってくれます。
デイリースタンドアップ、スプリント計画、スプリントレビュースプリントレトロスペクティブというスクラムイベントが導入されました。

初期にスクラムについて興味があった、経験があると言っていた人間は「スクラムに詳しいマン」としてチームで導入時に特に頼りにされます。
「こういう時どうすればいい?」と聞かれるので当人も張り切っています。

もちろんまだまだ課題もあります
まあでも大した問題ではないだろうと皆が考えています。
なにしろスクラムは順次改善していく開発のやり方なので、そのうちいい感じになるはずです。

  • デイリースタンドアップは進捗報告っぽい
    • スプリント計画とつながっているかって?
    • そもそもスプリント計画ってコミットするものなん?
  • スプリント計画はバックログ並び替えてプランニングポーカーするだけ
    • ユーザー目線はあまりない
    • フィードバックって?POの人の意見は聞くよ?
  • スプリントレトロスペクティブはKPTするだけ
    • ふせんに書いてぺたぺた貼って読み上げて終わり。お疲れ様でしたー
    • なんか出てくる情報が浅い。事前の情報出し?そういうやり方もあるんですね。

やがて暗雲が立ち込める。解決しない問題

  • スクラム導入で生産性爆上げと言っていたが、上がっている気がしない
  • 役員「一番解決したかった開発プロジェクトの納期スリップ問題が解決していない」

このような声が社内で聞かれ始めます。

  • スクラム開発の導入が「完了」しているのにチームのレベルが上がっている感がない
  • スクラムイベントをちゃんと回しているのに開発スピードが上がっている気がしない
  • ふりかえりで開発スピードをあげる施策がでてこない

こう言う声が社内から聞かれ始めます。
もっとも、それを拾い上げたりお悩み相談する役割の人がイネーブリングチームにいるわけでもないので、マネージャー会議や雑談で不満として出てくるに留まっていますが。

一部のチームではスクラムイベントをさらに簡素化したり、一部のメンバーだけで実施することで会議時間を圧縮し、コーディング時間を確保する施策に出ているようです。

アジャイル型開発組織立ち上げ経験があるすごい人も役員待遇で入ったらしいよ、やったね!

そういえばあの人どうした?
え?1年もたずに辞めた!?

人々は掌を返す

かつてはスクラム開発導入に対して好意的な反応や期待を示していた人々も、やがて掌を返し始めます

  • 納期の決まった開発プロジェクトの締切に間に合わせることが最重要と言われているのに、スクラム開発は寄与していいない
    • むしろ会議ばかりでコードを書いていない
  • 生産性が上がるというが、ベロシティはじりじりと上がっているがスケジュール遅延はひどくなるばかりだ
  • いつになったらプロジェクトの終了時期がはっきりと分かるようになるのか
    • まったく目処も立たない
    • むしろ「完了見込み」 はどんどんアテにならなくなっている。ベロシティは上がっているはずなのに

最も解決したい問題は「事前に決まっている開発プロジェクトの納期に対してプロジェクト開始後の納期スリップが多発する」だったことが明らかになります。
そのソリューションとして「スクラム導入=開発スピード爆上げ」が期待されていたことがこの段階でようやく明らかになりました。
課題解決が果たせないならスクラム開発に価値などない、と皆が考え始めるのも当然のことです。

  • 「我々はスクラム開発から期待した利益を得ることはできなかった」
  • 「スクラム開発に意味なんてなかったのでは?」
  • 「我々の開発のやりかたは "特別" すぎた。スクラムはフィットしなかった」

「全部お前らのせいだ!」

スクラム開発が無価値だという見解が主流になる頃、初期のスクラム導入時にキャッキャしていた「スクラムに詳しいマン」はいまどうなっているでしょう?

  • どうやればスクラム開発で生産性は爆上がりするのか
  • どうやればプロジェクトの完了見込みを高精度で着手前に、事前に予測できるようになるのか

これらの課題に回答するよう詰め寄られ困りきっていた「スクラムに詳しいマン」はチームで「納期スリップを解決できなかった戦犯」として燃やされるか、あるいはその前に逃亡(転職)していたりします。

まあ大体こうなります。

宗教裁判や魔女狩りの行く末は火炙りと決まっているので最後はこう。

ああ、ひどい目にあった

いやあなんかひどい目にあいましたね
(灰から再生する)

そもそも何が問題だったのか

スクラム開発で生産性を爆上げする よう求められているのは、変更不可の上位レベルの計画があって、それに合わせるために手持ちの少ない予算やリソースでそれを達成できるよう求められるからです。
本質的問題は 変更不可の上位レベルの計画 が実際には粗すぎる精度の見積を前提とした最初から達成不可能な杜撰な計画だからです。
なぜ杜撰な計画が立てられるかというと、人間が正しく見積もって計画を立てるには、情報が少なすぎ、また現実的でないほど高い計画/見積能力が必要なのに計画/見積する側の人間にそれがないからです。

どうやればプロジェクトの完了見込みを高精度で着手前に、事前に予測できるようになるのか

これはもう不可能です。
かぐや姫が出した難題(龍の首の五色の珠や燕の子安貝のようなやつ)そのものです。
ウォーターフォール全盛期から世界のあまたの叡智が挑んで失敗した問題への解を、自社にいる凡百の人材がなぜ持っていると思うのでしょう?

なぜ不可能なものを求めてしまったのか

Ken Schwaber風に言えば「ウォーターフォール脳だから」
これにつきます。

  • 上位の計画が確定した正しいもので、下位の計画はそれをブレイクダウンしたもの
  • 開発において計画が正しく、現実をそれに合わせなければいけない
  • フロー効率よりリソース効率
  • 基本的には作るものは事前に決まっている。そこにできるだけ多くの時間を注ぐことが生産性の鍵
    • それ以外のことは暇な時に、余った時間でやる
    • フィードバックとは、上位者が下位者に。上流から下流に流れてくるものである

書き出すと無限に続いてしまうのですが、ウォーターフォール的価値観とスクラム的価値観はコンフリクトします。

  • このコンフリクトを理解しない人間、スクラムを表面的にしか理解していない人間が
  • 今自分が抱えている本質的な問題に対して
  • 無理やりウォーターフォール的常識の上にスクラムプラクティスをトッピングして解決しようとする

ためにこれらの問題は起きるのです。

表面的なスクラム理解の図

図に示してみましょう

これが従来のやり方

ウォーターフォール的アプローチの図です。
あるいは実際にはもっといい加減な計画しか立てていないかもしれません
しかし「要求すれば得られる」という発想がある時点でウォーターフォール的な価値観と言えると思います。

本来スクラムに必要な知識

本来スクラムに必要な知識は広範です。

スクラムイベントとは特定の思想やガイドラインに沿って表層に出てきたものにすぎません。
しかしインターネットでちょろっと調べたり、研修に出ただけで分かった気になったり、入門本を一冊読んで完全に理解した気になっている人が学べるのはその表層だけです。

実際にはスクラム開発を最後までやり切るには不足します

ではどうする?

かんたんです。
今持ち合わせている知識で埋めるのです。
しかしこんなものは「ほぼウォーターフォール開発」です。
この知識しか持たずに無理やりスクラム開発っぽく回そうとしても失敗するに決まっています。

「唯一絶対の真実」

そもそもウォーターフォール開発的アプローチとスクラム開発アプローチの両方の知識があればものごとを相対的に見ることができます。
しかしウォーターフォール開発的アプローチの知識しかなければ、それはその人にとっては唯一絶対の真実です。

唯一絶対の真実に対して明らかにそぐわない話が出てくればそこに拒否感を持つのは当然のことです。
たとえばスウォーミングというやりかた。
ユーザーやステークホルダー、市場からフィードバックを素早く得ることの重要性を知らない人間が聞いても、リソースの非効率な使い方としか思えないでしょう。

「太陽や星は中心である地球の周りを回っている」 という唯一絶対の真実とそれを取り巻く 「常識」 にとらわれているからこそ、人は真顔でこういう言葉を言うのです。

さて新天地へ

私ごとですが転職しました。
新天地でもスクラム立ち上げをしていて、スクラム詳しいおじさんが要求されているらしいです。
もういっぺん頑張ってみましょう。

新天地で私がやったこと

知識です。
知識の共有です。

以下のことをやりました。

まず最初に

「スクラム/アジャイル系書籍マッピング」をしました。一部は社内に公開しています。

  • 難易度分け(初心者向け/中級者向け)
  • ユースケース分け(全体ざっくり理解/導入でつまづいた時/スクラムイベントについて学ぶ時)
  • ターゲット分け(PO向け/スクラムマスター向け/EM向け/メンバー向け/Biz職向け)
  • 読み方分け(独学できる本/経験者と読むべき本)

開発チーム全体向け

  • 理解に役立つおすすめ本を何冊か用意してご紹介しました
  • ざっくり分かる!アジャイル/スクラム講座 を開講しました
  • スクラム初心者向け読書会を開催しています
    • 最初は「アジャイルサムライ」から始めました

スクラムマスター向け

  • 理解に役立つおすすめ本を何冊か用意してご紹介しました
  • 実体験に基づくスクラム現場話をしました
  • 「スクラム開発がレベル50になると、どうなるの?」講座を開きました
    • ここまでいくとようやくレベル50だよ。レベル上げ頑張ろうね、という話をしました
    • スクラム開発とかいう無駄に会議の多い開発スタイルは、開発チームがこのレベルに達するとようやく会社は元が取れるんだよ、という話をしました
      • このレベルに達しないスクラム開発は単なる肥満開発でしかない、という話もしました

このプラクティスを通じてやりたかったこと

人は誰しも疑問を抱きます。
自分の中の常識と、ある事象の前提が異なったときは特に、です。
地球が平面だと信じる人間にとって「地球は球体で、太陽の周りを回っている」と言われたら疑問を抱くでしょう。
球体なら下に全てのものは落ちてしまう。まさかそんなことがあり得るわけがない そう思うのも当然でしょう。

知識があると味方が増えます。

逆に、周囲に知識がないと敵が増えて燃やされるかもしれません。かつての私のように。

誰かが「お前のいうことは間違っている。地球の陸地は平面で、4匹の巨大な象と1匹のすごく巨大な亀に支えられている。マップの端に行くと崖から真っ逆さま」「人類は猿からではなく、アダムとイブから進化したんだ」と言っても、周囲に正しい知識がなければ "うーむ言われてみるとその通りな気がする。となると地球は球体で、人類が猿から進化したとか言っているあいつは狂人に違いない" と思われるかもしれません。
そんな人が多ければ魔女裁判すら始まるでしょう。

しかし周囲に正しい知識があればこの程度の反応を返せばすみます。
周囲もそれで納得します。
(実際には私はこんな冷淡な反応はしませんよ?)

  • 年間開発グランドスケジュールに現場の開発チームがプルリクエストを投げることは当然のことだし
  • リソースの稼働率は大して重要な指標じゃないし
  • プロジェクト開始前にざっくりとした粗い見積と完了時期しか分からなくても不安に思うべきではないし
    • (もちろんスケジュールの半ばを過ぎてなおそれらが粗いなんてありえません)
  • ユーザーや市場から早くフィードバックを獲得することには血眼にならなければなりません
    • 血眼にならないなんて出資者や関係者に対する背信行為ですらあります
    • 当然フィードバックを受けて、全てのレベルの開発計画は変更され得ます
      • 全て、ですよ? 取締役会で承認された五か年計画ですら、です。 そこになんの問題が?

しかしこれらはウォーターフォール脳の人たちをひどく不安にさせます。
不安は伝播し、魔女裁判を引き起こしさえします。
たとえ煽動者が詐欺師同然の男であったとしても、です

これもまた仕方がありません。
常識が古いものから新しいものに切り替わる過渡期ではよくあることです。
"常識"のコンフリクトとはそれほど人を不安にさせることだからです。
昔はシャツのタックインやUネックのアンダーシャツがダサいと言われた時代があったらしいですよ?(アラフォーにブッ刺さる表現)

私は何をイメージして何を目指すのか?

基本的にはゴールを意識した上で、どういう段階を踏んでそこを目指すことになるのか?
という構想を考えます。
次に関係者に対してゴールはここで、こんな感じで行こうと思う。という話をします。

東京駅から大宮駅(埼玉県, 北方向)に移動したいと考えるとき、東海道新幹線(南西の静岡方面に向かう)に乗る間抜けはいません。
しかし同時に、北に向かうから、という理由で常磐線に乗る行為は一見正当に見えても、狂気と評されて然るべきでしょう
(念のため言うと、常磐線は東京都足立区の北千住や綾瀬あたりまではまっすぐ北に向かいます。そのあと大きく東に逸れて茨城県に向かいます)
(埼玉県と茨城県がどれほど違うかは、映画「翔んで埼玉」をご覧ください)

"今はだいたい方向は合っているのだから、(道なりに)この方向に向かい続ければいつか「ゴール」に辿り着くだろう"

と言う考えは、一見正しく、そしてスクラム開発を開発組織に導入するにあたっては正しくありません。

私はあまり人の考えを否定するのは好きではありませんが、これだけは言います。
某「ジョジョ5部の黄金の意志」。
これは非常に悪い誤解をアジャイル界隈に与えました。

「意志を持って歩き続けているのだから、いつかきっとゴールに辿り着くに違いない。」
「大事なことは意志を持ち続けることなのだ」

一見立派な言葉ですが、この発言者の先輩警官は、警官という身分と捜査スキルを持った上で発言しています。
言われた側のアバッキオもゴールに辿り着けるだけのスキルと知識を保有していました。

「黄金の意志が大事」とは、スキルと知識の保有あるいは将来的な獲得が前提です。
それがないのに意志だけあっても意味がありません。

ゴール意識と意志の盲信に意味はありません。
山で道に迷ったときに、南にあるはずの街に向かおうと考えていて、そして南に流れる沢を見かけたときに「沢に降りて、沢に沿って歩けばきっと街に着くだろう。だって街のそばを川が流れていたし」と思うほどには愚かな考えです。
沢で消防団が発見した多数の犠牲者も、家に帰りたいというゴール意識と意志は持っていたでしょう。

必勝の精神、あるいは 精神力は無限大!の大和魂 では鬼畜米英に勝てませんでした。
我々はすでにそれを80年ほど前に学んでいるはずです。

この記事の言いたいこと

まず言いたいのは、自分の生命を守ることです。
コペルニクスは、まあなんだかんだで歴史に名を残すまで生存しました。
だから「地動説」というワードと密結合して彼の名は歴史に残りました。

ではそれ以外の人間は?
火炙りにされたりあるいはそれ以下の扱いをされて歴史に名を残せませんでした。
彼よりも真実に近づいていたかもしれないのに。

大事なことは、命を守れ
次に大事なことを広めるために仲間を作れ
そのために戦場を選んで知識をつかえ、です。

戦場は選べ

この記事の元ネタであるチ -地球の運動について-の登場人物たちは、わりとカジュアルに死んでいきます。

ヴァルナの戦いでグッダグダになったP国で活動した点が彼らの運の尽きです。
所詮は政治が不安定な辺境でした

私は思います。
勝てる場所で、勝てる戦いをすべきだと。
圧倒的少数が圧倒的多数に勝てた戦いは教科書にはいくらでもあります。
しかし教科書に載ると言うことは例が少ない戦いです。
ファルサルスの戦いとかイッソスの戦いとかイエナの戦いとか、まあそういうやつです。

とにかく味方は作れ

世の中は「論理の正しさ」では動きません。
ダンガンロンパみたいには論理で人は動かないのです。
なので味方を作る必要があります。

(論理で納得させたあと、結論に従ってくれなかった人の例)
名探偵モノの謎解きパートで種明かしの後、銃で殺人おかわりとかそんなんある?

(本人の)納得は全てに優先するぜッ!!

味方を作るにあたり納得は重要です。

先ほど、ジョジョ5部のアバッキオの同僚(というか先輩)の言葉を否定しましたが
「ジャイロの納得は全てに優先する」は実感を持って肯定しています
だからこそ、私は勉強会や読書会を通じてアジャイル知識の伝播に努めています。
ただし無理強いは良くありません。
喉が渇いている人間しか水を飲みません。
我々にできることは水場に連れて行くことだけです。

戦場を選ぶ基準

冒頭の通り、私はアジャイル/スクラム開発に魅せられているのでスクラム開発が求められている戦場が必要です。

ではスクラム開発が求められる理由とは?
その怪しげな、今までの常識と反する開発を入れる合理的な誘因とはなんでしょう?
(偉い人の中にはすでに経験して失敗した人も多いでしょう)

それを自分なりの答えを出してから私は戦場を選びました。

最終的に何を目指すのか

自分はよいスクラム開発を今の職場では作れないかもしれません
(最大限の努力はします)

この記事の元ネタであるチ -地球の運動について-では最終的に地動説が世に出て認められます。

しかし意志を受け継いだ誰かが、どこかで、スクラム開発を開発現場に持ち込んで成功させてくれることを期待しています。

「成功」とは具体的にどのレベルか

daiksyさんのいるchatworksくらいのレベルでスクラム開発を機能させていきたいですね。
経営にとってスクラム開発がなくては成り立たないと思わせるレベルがゴールです。
別にスケジュール駆動開発でも機能するやろ?と思っているならまだまだということです。

今は何を望むのか

今の職場でスクラム開発をワークさせ、メンバーも役員クラスも「スクラム開発を導入した意味はあった」と思える程度まで進化させていきたいです。

「スクラム開発ってやつをすると、なんかこう全部うまく行くんだろ?」 的な幻想ではなく、現実的な利得を出さねば意味がありません。

今年1年それで頑張ってみて、それをRSGT2024で話せれば幸いです。

Discussion