Agile journeyをご覧のみなさま初めまして。株式会社ビットキーでEM（エンジニアリングマネージャー）・スクラムマスター・技術広報をしているパウリ（@pauli_agile）です。私は2015年に新卒でプログラマーとしてキャリアをスタートしました。
その頃の世の中ではすでに、アジャイル開発がさまざまな開発組織に浸透しつつある状況にあったかと思います。ただ、実際に配属された現場がウォーターフォール開発のような環境だったこともあり、私がアジャイルについて知るのは2年半から3年ほど後のことになります。
ここでは私がアジャイルに出会い、考え方や行動にどのような変化があったのかをまとめていきます。
アジャイルとの出会いと衝撃
今でこそ私もアジャイル、とりわけスクラムを用いたプロダクト開発により価値創出することが多くなりましたが、当時は新卒プログラマーとしていくつかの新規プロダクトを開発していた際にも、その後マネージャーとして参画したプロダクトでも、ウォーターフォール型の開発を進めていました。
その頃の私の関心事は「価値創出」にはなく、「指示内容の完遂」であり「納期遵守」であり、プロジェクトの状態を細かく把握するため工程ごとにWBS（作業分解構造図）やガントチャートを作成していました。また、メンバーのSlack投稿やJIRAの通知などをチェックし、チームの状況をできるだけ細かく確認・調整することに重きを置いていました。
また、チームの大半が協力企業や非正規雇用のメンバーで構成されており、トップダウンでの具体的な指示が必要とされる環境でもありました。いわゆるマネジメント1.0※のような統制をしていました。
※ ヨーガン・アペロ（Jurgen Appelo）の著書『マネジメント3.0 適応力の高いチームを育むための6つの視点PBL』（2022年、丸善出版、原書は2010年刊行）によると、マネジメント3.0はネットワーク型の組織を前提としたアジャイル開発のマネジメント体系であり、それに対してマネジメント1.0は階層型組織のトップダウン型マネジメントとされる。
後輩からスクラム導入の提案と衝撃的な指摘
いくつかサービスをリリースし、プロダクトマーケットフィット（PMF）に向けて機能拡張するフェーズへと以降していたある日、後輩からスクラムを導入したいという提案がありました。当時の私はプロジェクトを計画通りに進めることが最優先であり、アジャイルの価値に対する理解はありませんでした。
それでも開発プロセスへ影響する初めての提案を後輩がしてきたこともあり、開発者兼スクラムマスターとして活動することを承認しました。1週間スプリントでタスクを運用し、スクラムイベントの導入やストーリーポイント見積もりなど、さまざまなプラクティスが導入されていきました。そして会議のファシリテーションも後輩へ移譲していったある日、こう伝えられました。
「パウリさんがいるとメンバーが萎縮して発言しづらいので、スクラムイベントに出席しないでください」
…… 衝撃的でした。これまで上司からですら「会議に出てくれ」という依頼はあれど「会議に出るな」という指摘を受けたことなどありません。ましてや、それが後輩の口から出たことに驚きを隠せませんでした。
しかし指摘に従って、スクラムイベントからは徐々に抜けていきました。そして何か言いたいことがあれば、後輩へ直接伝えることにしました。マネージャーとしての振る舞いも再検討する必要があると感じました。
アジャイルな価値観へシフトしていく難しさ
指摘の後、後輩が推し進めているアジャイル開発とスクラムについて自分も学んでいくことにしました。まず「アジャイルソフトウェア開発宣言」や「スクラムガイド」、その他の書籍などに目を通しました。そして自分の解釈を後輩と対話することで、当該チームと自分への期待をすり合わせていきました。ときには夜通し話し合うこともありました。
その中で、私がスクラムを単に「短い開発期間で開発する手法」だと誤って解釈していたことに気づきました。そのためタスクを直接的に指示したり、改善案の意思決定権を自分が握り続けたりするなど、自律性のある組織形成を阻害する行動をとっていたのです。その後はスタンスを変更して、自分から指示するのではなく、メンバーが開発していてやりづらいと感じることを環境から変えるよう、支援することにしました。
とはいえ、根付いた行動や言動の癖というものは、一朝一夕で抜けるようなものではありません。重箱の隅をつつくような細かなことに対して口を出しそうになります。これに対して「チームへの指摘はスクラムマスターへのDMか直接の会話を通さなければならない」という制約を課したことで「伝えたいことをメモとして残して俯瞰する」プロセスが発生し、細かな口出しを抑制できました。
結果として開発チームは、私から直接のタスク実施を指示されなくともプロダクト開発ができるよう、成長していきました。一方の私も、徐々に現場から離れ、同じプロダクトで新プロジェクトを立ち上げたり、別のプロダクトを支援したりしていました。
自分の活動としては、経営層や事業責任者との対話を通して開発全体の方針や仕様を把握し、また開発環境とはいえ実際に動くシステムを開発することで利用者からのフィードバックを受けるループを体験をすることもできて、関係者と一緒にモノづくりをすることの重要性を実感し始めていました。
学習したアジャイルを実践する場所を求める
とはいえ開発チームに課題がなくなったわけではありません。システムの仕様について意思決定がPdMでも事業責任者でもなく経営層にまで及ぶこともあり、営業や企画チームと合意した仕様がリリース前に変更されたり、開発チームが関わっていない意思決定がうまく伝達されなかったりしました。
開発チームが変化を受け入れられず、硬直的な返答をせざるを得ないこともありました。期間内で確実に実現可能な仕様を合意するため「無理です」「できません」と否定したり、仕様策定のプロセスを厳密にするため記録を残す必要からコミュニケーションのコストも高くなり、対話することも減ってきました。そのため、とある事業責任者から「開発組織は敵」なのかと指摘されることもありました。
さらに人員配置の変更も伴ったことで、営業や企画チームとの良好な関係も再構築が必要になりました。ところが私自身も、対話の重要性を理解しつつ、挑戦して失敗したことによる疲弊が心身ともにあり、チームの雰囲気や関係性を改善できる状態ではなくなっていました。
一方でマネジメントやアジャイルについては学習を進めていたこともあり、その実践を別の場所に求めることにしました。とんとん拍子で転職が決まり、メガベンチャーの5名程度の開発チームにリーダーとして参画することとなりました。
新天地でスクラム推進を再スタート
転職して2ヶ月程度は自分でも実装しつつ、ソースコードと組織の両面からチームや隣接組織の状況を観察していました。そこで感じた違和感としては、開発チームのタスクやスケジュールを、企画チームがマネジメントしていることでした。
この形になった経緯を確認したところ、開発チームにマネジメントの得意な人がいなかったことから、企画チームでタスクマネジメントするようになったとのことでした。これが望ましい状態ではないという認識はありましたが、結果として「開発チームのタスクは企画チームが作成するもの」という空気感となり、開発チームから提案することはなくなっていました。
ただし、開発チームのメンバーにやる気がないわけでは決してなく、企画チームのメンバーから感謝されることに自己効力感（self-efficacy）を覚えており、むしろ企画チームがより業務しやすい環境になることに対しては前向きでした。また事業としてはPMFもしており、事業価値をより高めるフェーズとなっていました。
さらに、なぜかタスクを1〜2週間単位で管理する雰囲気が開発チームにあったことから（理由は後で判明）、スクラムを導入することを決意しました。目的としては、チームの自律性を上げることで企画組織としての専門性を最大化しつつ、自己効力感を維持するために共創的な環境を構築し、価値提供と仮説検証サイクルを損なわない手段とするためです。
スクラムの導入を今度は自分から提案
関係者全体へ「アジャイルソフトウェア開発とは何か？ スクラムとは何か？」をまずは共有し、価値観や実際のプロセス設計を浸透させました。アジャイルやスクラムの意義や進め方、推進する際の課題などは先人たちが残してきてくれたものを調べれば、これから導入するチームでも大枠が理解でき、実行可能な状態にまでできるのは非常に助かりました。
これにより、開発タスクが完了すると「次に何をすればいいか？」を企画メンバーへ聞かなくては分からなかった状況は、プロダクトバックログで優先順位が見える化されることで解消しました。リファインメントで施策への理解を深め、企画と開発の間にあった認識相違をどのように改善するかをレトロスペクティブでふりかえり、スプリントごとに改善していきました。
後になって聞いた話によると、もともとチームにスクラムマスターを自称する人がいて、1〜2週間のタスク管理はその頃の名残だそうです。しかし、スプリントが始まったらプランニングしたこと以外の作業依頼を全て拒否するなど、企画チームが望んでいない開発状況となっていて、スクラムへの猜疑心まで生じていたとのことでした。そのため私がスクラムを導入していることには、気が気でなかったそうです。
そういった心配をよそに開発チームは、企画チームや私が直接タスク・スケジュールを管理しなくとも、方針を合議して進められるように変化していきました。
また私はというと、その過程で取り扱う課題が抽象化していき、まだ方針の固まっていないプロジェクトの相談を受けたり、組織課題の改善のため1on1を実施したり、さらにはチームの再編なども任せられるようになりました。もともと企画チーム・開発チームの間で共創するような環境を構築したかったので、それを築くことができてうれしかったです。
複数チームによるスクラムの拡大
一方でシステムとしては、フレームワークやパッケージを新しいバージョンに追従する必要があり、リファクタリングなども塩漬けとなっていたことから、程なくしてリプレイスすることとなりました。このプロジェクトに向けたスタッフ採用や業務委託では、スキルだけでなくチームで開発することへの意識や実績を重要視して、チームを組成しました。
新しいチームでも、先述したチームと同じ目的を持った組織として、既存のシステムに価値提供する状況とリプレイスプロジェクトの状況を相互に理解して推進したいと考えました。そのためアジャイルをスケールさせるフレームワークについて学び、LeSS（Large-Scale Scrum）を導入しました。これによりプロダクトの全体を見通すことができ、双方のチームへ影響するタスクの調整が容易になりました。
さらに、リプレイスに伴う基幹システムのマイクロサービス化開発チームが別軸で発足しており、後々で連携することは見えていたため、先行して当該チームの状況の把握がてらSlackや会議に参加し、後に当該組織全体のマネジメントも手掛けることになりました。
責務の変化と信用の獲得
それぞれのチームが自律的になりタスク推進を任せることができたことにより、マネージャーとしては開発チームメンバーが個人で解決できない人間関係の問題やキャリアについての相談など、いわゆるピープルマネジメントにも目を向けることができるようになりました。
当初は開発チームのリーダーからスクラムマスターとして1チームを推進していた私でしたが、徐々にEMやアジャイルコーチへ責務を変更し、各チームのリーダーやスクラムマスターを間接的に支援するよう変化していきました。
この責任範囲の拡大から、さまざまなスタッフから「開発組織に依頼したいアレコレの相談の全てに乗ってくれる」という信頼感が生まれてきました。また「『無理』『できない』ではなく『どうすればできるか』というスタンスで話を聞いてくれるから信用できる」というフィードバックももらえました。
アジャイルに出会い、スクラムの導入を推し進めた結果、環境は違えど「開発組織は敵」から「信用できる」まで印象を変化させることができて本当に嬉しかったです。
さいごに
ここまで私がアジャイルに出会い、どのようにスクラムを推進したのか、また私自身の考え方や行動が変化することで、周囲からの評価がどのように変化したのかをまとめました。その後、スクラムマスターとともにEMとしての職務を追求するため2度目の転職をして、現在は技術広報も兼任しています。
スクラムは奥が深く、この価値観を実現するためにはまだまだ多くの知識が必要だと思っているため、今後も学んで実践してふりかえる姿勢は崩さないようにしていきます。私自身も先人たちが間接的に私を助けてくれたように、私も誰かの助けになれたらと思っています。
最後まで読んでいただき、ありがとうございました。
編集・制作：はてな編集部
- 岸田 篤樹（きしだ・あつき） X: @pauli_agile
- 株式会社ビットキーで、EM（エンジニアリングマネージャー）・アジャイルコーチ・技術広報を兼任する。コミュニティではEM Oasisおよびアジャイルひよこクラブなどの運営に携わる。2015年3月に東京工科大学応用生物学部を卒業。新卒で入社した株式会社EPARKでSE、チームリーダー、PMといった幅広い業務を経験する中でスクラムと出会う。2020年3月にレバレジーズ株式会社に転職し、EMやアジャイルコーチといった職務を経験する。2023年5月より現職。
