エンジニアはスクラムマスターの夢を見るか？～なんちゃってアジャイルからの脱却とそれにまつわるアレコレ～

こんにちは、たむらです。

突然ですが、皆さんの組織ではアジャイル開発を行っていますか？　恐らく程度の差はあれど、かなり多くの会社でアジャイル開発を少なからず取り入れた開発を行っているのではないかと思います。

でも・・・・、それ本当にアジャイル開発になっていますか？　こんな?感想が出てくる「なんちゃってアジャイル」になってしまっていませんか？

「アジャイル開発は納期を定めないから or 最初に要件を全て決めなくて済むから楽だと思っている」
「アジャイル開発ではPM（プロジェクトマネージャ）をPO（プロダクトオーナー）という別称で呼ぶものだと思ってる」
「スクラムの５つのイベントをやったりやらなかったりしてる」
「現場と開発の仲が悪い。なんなら開発メンバー間でも仲が悪い」
「アジャイル（＝俊敏な）な成果やメリットを感じたことがない」

実はラクーンでも上記の様な「実はウチってなんちゃってアジャイルなんじゃないか？」という不安があり、昨年度からアジャイルコーチの支援を受けてスクラムの導入に取組みました。今回はこの取組みとそれにまつわるアレコレについて書きたいと思います。

アジャイルコーチに加わってもらう背景

さて、今書いていた通りですが、ラクーンでも随分前からアジャイル開発自体は行っていました。もともと内製開発の体制ですし、新しいものを取り入れる風土のある会社なので、プロジェクトやチーム毎に適宜スクラムなどのアジャイル手法を取り入れていました。例えばCORECは、0→1サービスの開発として完全なスクラム開発で取り組んだプロジェクトの１つです。

しかし、しばしば発生する開発の課題を鑑みると、前述したような「これって本当にアジャイルな開発といえるのかな？」という疑問がぬるりと頭をもたげることがありました。例えば以下のようなものです。

開発品質とスピードの問題

弊社では、複数のサービスが運営されており開発需要が供給を超過することが頻繁に起きています。が、その改善は単純に人を増やせばいいという訳ではないのは明白であり、限られたリソースの中で「より精度の高い要件をより的確に作る」ということが非常に重要なのは言うまでもありません。この課題をもっと改善していくことはできないのか？と感じていました。

現場と開発の情報の非対称性の問題

ラクーンは内製している会社ではありますが、どうしても現場と開発の持っている情報や視点は異なります。得てして現場側は技術的な背景や状況が分からず、開発側は事業部側が考える企画の背景や業界の動向が分からなかったりします。そしてその差異は時には相互不信やコミュニケーション齟齬を生み出してしまいます。ラクーンは会社としてチームワークを重視している風土ではありますが、同じ目的を共有し協力し合う、より質の高い「ワンチーム」になるにはどうすれば良いか？と思っていました。

なんちゃってアジャイルの問題

上述の二つも内包する部分ですが、結局スクラムはやっているけど、「アジャイルソフトウェア開発宣言」のイズムを実感できていないのがモヤモヤの一番の部分かもしれません。「顧客との協調」、「変化への対応」などを、本当により重視する行動をできてる？と。
スクラムは方法論ではあるものの、マインドセットが重要とはよく聞く話です。確かに形としてはスクラムっぽいものはやっている。でもそのポリシーを理解し、そのメリットを正しく生み出せているのか？に疑問があったのです。

アジャイルコーチを招聘

上述の様な背景を踏まえて、一度真っ当なアジャイル開発を体験してみようという話が上がり、外部のコーチに加わってもらい指導をしてもらうことにしました。アジャイルコーチは、メルカリや楽天でエンジニアとして働き、今はアジャイルコーチとして独立されている藤原　大さんにご支援いただきました。

※コーチをして貰った結果の感想ですが、藤原さんはエンジニアとしてのスキルは勿論、ファシリテーションや1on1などの知見も豊富で、忌憚のない鋭いアドバイスを頂ける最適なコーチだったと思います。さすがコーチです。ありがとうございました！！

支援は主に以下の２つの軸で行っていただきました。

実際の開発チームのスクラムでスクラムマスターとして参画
マネージャ層の課題解決ミーティングでのコーチ

「1.実際の開発チームのスクラムでスクラムマスターとして参画」に関しては、スクラム開発を経験したことがないチームにスクラムマスターとして入ってもらい、スクラムをチームで体験していくという支援です。最初「スクラムとはなんぞや？」というガイダンスを現場側メンバーも含めて実施してもらった上で、２～３ヶ月で一通りスクラムが回せているという状況迄もっていってもらいました。

もう一つの「2. マネージャ層の課題解決ミーティングでのコーチ」は、今後を見据えたもので、組織にアジャイル開発の考え方を展開していくための中心となるメンバーでアジャイル手法を踏まえた課題解消ができるようにするための取組みでした。いわゆる「Scrum of Scrum」を想定したものです。ラクーンでは、基本的には事業課題は各開発チーム内で意思決定を行っており、マネージャは技術指針や制度設計など組織全体の舵取りを行っています。スクラムでは自分たちのチームで解決できない課題をエスカレーションしますが、その受け手こそマネージャ層になる筈であり、部門課題を各チームから吸い上げ解消していく形態を狙ってここにもスクラムを適用しコーチをしてもらいました。

コーチに入ってもらって

支援をしてもらった感想です。

スクラムの成果実感が得られた

現場と開発の情報の非対称性が低減したと思います。主に感じたのは下記の２つです。一番得たいと思っていた部分なので非常に成果を感じた部分です。
- チームの一体感が向上
- メンバーの当事者意識が向上
PDCAサイクルがしっかり回るようになりました。実利のある成果の可視化やレトロスペクティブができるようになり、単発の成果報告や振返りがシームレスに次の行動に繋がるようになったと思います。

タスクや課題の可視化が進んだ

コーチに見てもらう必要があるのも理由の一つですが、見える化がかなりできるようになりました。

アジャイル開発への取組みに対する現場側の理解度が格段に高まった

第三者のコーチである強み（その１）です。アジャイル開発の知識自体は現場側より開発側が先行しているが故にどうしても開発側からの現場側へのオーダーという感じになってしまっていたのですが、世間一般の動向や考え方をフラットな立場で伝えて貰うことでスムーズな理解に繋がったと思います。

問題を部門や人と切り分け客観的に捉えられる機会を作れた

第三者のコーチである強み（その２）です。どうしても当事者同士だと問題を人や組織と結び付けて考えてしまいますが、仲介（仲裁？）するコーチのお陰で、問題を客観的に捉えることができたと思います。

書籍などで読んだ知識が繋がった

スクラムという活動の中で個々の知識をどの様に生かせばいいのか解像度が上がりました。例えばWIP制限がなぜ必要か？どんな時に考えるべきか？などです。薬の用法・用量が分かった感じ（？）でしょうか。

コーチングやファシリテーションのスキル研鑽に繋がった

メインじゃない副産物ですが、スクラムマスターはコミュニケーションをとるポジションなのでこれらのスキルは非常に重要なのは言うまでもありません。会議の進め方、1on1などを通して実践的な学習ができたと思います。

こう並べると、ある意味「（自宅で勉強が捗らず、第三者の存在がある）図書館にいった結果勉強が捗った」的な要素が多いという感想を抱かれるかもしれませんが、そのちょっとしたことが実は大きかったりしますよね。また、様々な経験を踏まえたアドバイスを、課題に対してピンポイントでして頂けたことでただの知識を有効な知恵に変えていただけたのもコーチがいてこその部分だったと思っています。

そしてこの取組の発端となった自分の中の「もしかしてラクーンは ”なんちゃってアジャイル” じゃないのか？」の疑念は、支援を頂いた結果、以下の様な理解になってます。どれも「そんな当たり前のことが結論？！」って内容ですが、これが素直に実感として得たものです。

アジャイル開発は改善を継続する仕組み。そんな意味で「なんちゃって」かどうかの判定なんて意味はなく、改善が継続する状態であることに価値がある
アジャイル開発は（アジャイルソフトウェア開発宣言の）価値の理解と共感がありきの仕組み。みんなが理解しているべき。
アジャイル開発は凄い人たちが考えに考えた仕組み。守破離じゃないけど一度はしっかり形式に則ってやってみるべき。どれも意味がある

少なくとも、支援を受け、ラクーンはアジャイルな開発に取り組んでいると今は少しの自信をもって言えるようになった気がします。

ついでに認定スクラムマスター資格を取ってみた

この流れで社内のムーヴメントを維持するためにも自社内で運用できるように認定スクラムマスター資格の取得をしてみました。
支援は頂いていたものの、今後自分でスクラムマスターとして立ち回っていくには知識の補強は勿論、自信と覚悟を持ちたいと思った為です。
ちなみに、ラクーンでは技術サポート制度という制度があり、そちらで資格受験や研修の費用を会社が補助する仕組みがあります！

資格取得前

概要は知ってるつもりだが、まだ本質を分かってないのではという不安（言っていることは分かるけど、机上の空論っぽさがある感じで不審が拭いきれてない）
スクラム自体もやっているもののまだまだ成果を実感できていない
スクラムのコミュニティって若干宗教的な感じがしてコワイ

資格取得後

知らない何かは無かった。・・・が、スクラムマスターとして立ち回るには自信をもって取り組む必要があるので資格を取って（≒研修を受けて）損はない、と思う
実際に成果を出せている現場が沢山ある。実績を信じて取り組んでみるべき
スクラムは3-5-3の作法が大事だが、ゲームルールと捉えるべき。楽しもう！
場慣れと情報共有が必要。その意味でもコミュニティーに所属する必要がある
今後の自分のキャリアとして１つの枝を伸ばせることになったかも？

ちなみに、私が受けたスクラムマスター研修では、２０名位が受講していたのですが、大手の企業でスクラムをほぼ知らないが、業務指示で参画しているという人が結構いたのが印象的でした。一昔前は開発の一部界隈で興味関心がある人・企業が声を上げているという印象だったので、それだけ一般的で当たり前のものになっているのだと感じられました。

グランドマスターになるために

認定スクラムマスターを取りはしましたが、上に書いた通り本質的＆知識的にはほぼ何も変わっていません（汗）。なのでより価値のあるスクラムマスターになるためにはスキルの研鑽が必須です。スクラムは仕組みは単純ですが、それを円滑に運営するには特に以下の２つのスキルが重要ではないかと感じています。今後積極的に研鑽していきたいです。

ファシリテーションスキル（コーチング・ティーチングスキル含む）
- スクラムマスターは対話で成果を作る要素が大きいので結局はこのスキル如何だと感じます。
リーダーシップスキル
- どんな組織でもそうですが、スクラムチームは課題や目標と向き合うチームです。それを支援する為にも笑顔で粘り強く伴走できる能力が職種的に肝じゃないかと思います。

余談ですが、スクラムマスターという職種は求められている役割や知識体系を考えるに、組織マネジメント（特に０１を生み出すチーム運営）の体系的なナレッジに昇華できるものだと感じています。以前「リーン開発」が経営レベルにまで影響を与えたように、スクラムの運営ナレッジがもっと広い範囲で有効活用できるようにできないか？を考えてみたいですね。

以上、弊社のアジャイルコーチの支援とそれにまつわるスクラムマスター関連の雑記でした。
スクラムやっているよ！という会社はたくさんあると思いますが、いまいちうまく運用できていないとか課題が色々あるという会社は多いのではないかと思います。そんな会社に検討の一助の情報となれば幸いです。

さて、ラクーンではエンジニア・デザイナーを大大大募集中です！
ご興味ある方は、ぜひ気軽にご応募下さい！！