「こんなにうまくいかないのは、何かが根本的におかしいんじゃないか？」
優秀なメンバーが集まり、全員が真面目に取り組んでいるのに、なぜかプロジェクトはいつもギリギリ。良いものを作りたいのに時間がない。改善したいのに余裕がない。そんなフラストレーションを抱えながら、私は開発リーダーとして悶々とした日々を過ごしていました。
当時の私には想像もできませんでしたが、その後10年以上にわたって続くアジャイル実践の旅が、この疑問から始まったのです。
「Agile Journey」をご覧の皆さん、こんにちは。天野祐介（@ama_ch）です。先日、新卒入社から16年間という長い時間を過ごしたサイボウズを退職し、現在は充電期間中です。
私のキャリアは、ソフトウェアエンジニアとしてスタートしました。その後、長い間「kintone」の開発に携わり、開発チームのリーダーを経てサイボウズの一人目のスクラムマスターになりました。以降はスクラムマスターとして組織の内外で実践を重ねてきました。プライベートでは2021年に東京から仙台へ移住し、スクラムフェス仙台を立ち上げ、月に1度仙台のアジャイルコミュニティ「すくすくスクラム仙台」を開催しています。
今回「はじめてのアジャイル」の企画にお声がけをいただき、これまでの道程を振り返りながら、アジャイルとの出会いが私と組織をどう変えたのか、そしてアジャイルにどう向き合い実践してきたのかを紹介させていただきます。この記事が、今まさにアジャイル実践に悩んでいる方、これから始めようと考えている方の背中を押すきっかけになれば幸いです。
- 開発リーダーとして感じた壁 ─ 「このままでは絶対に良いものは作れない」
- 「アジャイルサムライ」を再読して得た直感
- 「正解が分からない」が「前に進むしかない」
- アジャイルを追求する過程でアジャイルコーチに
- 自分の考え方は違う組織でも有効なのか……社外での活動
- 「どうやら正解はない」アジャイルを追求する旅は続く
- 合わせて読みたい関連記事
開発リーダーとして感じた壁 ─ 「このままでは絶対に良いものは作れない」
皆さんも経験があるかもしれませんが、技術的なスキルを積み上げてリーダーになったとき、まったく違う種類の困難に直面することがあります。私にとって、まさにそういう時期がやってきました。
サイボウズはもともと「Office」や「Garoon」といったグループウェアプロダクトを開発していました。これらは社内のサーバーにインストールして稼働させるパッケージ製品だったのですが、世の中のクラウド化の波を捉えて、サイボウズも大きく舵を切ることになります。kintoneは、サイボウズ初のクラウドサービスとしてリリースされることになったのです。
私は新卒で入社してkintoneの前身となる研究開発プロジェクトチームに配属され、最初はパッケージ製品を想定した開発に取り組んでいました。ところがある日突然、リリースするものがクラウドサービスに変わるという、なかなかドラマチックな経験をしました。
当時の組織は、長年のパッケージ製品開発に最適化されていました。駆け出しのエンジニアだった私は他のやり方を知らなかったこともあり、「開発とはこういうものだ」と、既存のプロセスに何の疑問も持たずに従っていました。
しかし、キャリアを重ねて開発チームのリーダーになったとき、大きな壁にぶち当たったのです。
ウォーターフォール開発に悩んだ日々
当時の開発プロセスは、端的に言うと「3カ月ウォーターフォールプロジェクトを年4回リリースする」というものでした。計画→実装→試験→リリースと段階的にプロセスが進み、なおかつ、あるバージョンの試験期間中に次のバージョンの計画が開始するというオーバーラップ構造がありました。
これが何を意味するか、想像してみてください。エンジニアは常に実装か試験の締め切りに追われていました。実装フェーズで「これをもっと良くしたい」と思っても、試験フェーズで改善しようとすると想定外の作業となり、次のバージョンの計画に支障が出てしまいます。結果として、改善する余裕が一切ありませんでした。
良いものを実装したくて実装期間を長めに取ると、試験への皺寄せが来るため、不十分な状態で機能をリリースすることも珍しくありませんでした。
皆さんも同じような経験をしたことがあるでしょうか？ 良いものを作りたいのに、既存のプロセスに阻まれてできない……そのフラストレーションを開発の至る所で感じていました。
一緒に働く人たちはみな優秀で、良いプロダクトを作ろうと真面目に努力している。それなのに、どうしてこんなにうまくいかないのか？ 何か根本的にやり方がおかしいんじゃないか？ そんな思いを抱えながら、悶々と悩む日々を過ごしました。
「アジャイルサムライ」を再読して得た直感
ヒントを求めて開発プロセスやチームワークに関する書籍を読みあさっていたとき、「アジャイル」というキーワードが目に留まりました。アジャイルという言葉は何となく知っていましたが、改めて『アジャイルサムライ』を読み返したとき、まさに「これだ！」という感覚に襲われました。
アジャイルサムライ――達人開発者への道
オーム社本の中に描かれていたのは、私が実現したいとイメージしていた開発現場そのものでした。特にアジャイルでは、「企画の人」「開発の人」「テストの人」と役割や工程を明確に分けるのではなく、チーム全員が一丸となってプロダクトの成功に責任を持つという考え方に深く惹かれました。この考え方は、サイボウズの「チームワークあふれる社会を創る」という企業理念そのものではないか。チームワークを何より大切にする企業文化の中で働いていた私にとって、まさに理想として思い描く姿でした。確信にも似た直感があり、自分のチームで実践してみたいと強く思いました。
ただし、現実は簡単にはいきませんでした。kintoneの開発には一つのバージョンに数十名が関わっていて、各工程もこれまでの経緯と知見を踏まえて徐々に形作られてきたものです。数十名で数カ月かけて進めるウォーターフォールプロジェクトを、インクリメンタルでイテレーティブなプロセスに変える具体的な手順は、どの本にも書かれていませんでした。
それでも、とにかくやってみるしかないと思い、kintoneの開発に関わる主要なメンバーに「次のバージョンからスクラムで開発を進めたい」と提案しました。
なぜスクラムを選んだのか？ アジャイルにはさまざまなプラクティスがありますが、スクラムはフレームワークとして責任・作成物・会議体の一通りの要素を抑えているため、導入しやすいと考えたからです。同時に、「発案者である自分がスクラムマスターをやります」とも伝えました。
この提案が、私のキャリアをエンジニアからスクラムマスターへと大きく変化させるきっかけになりました。
「正解が分からない」が「前に進むしかない」
組織で新しい取り組みを提案した経験がある方には想像がつくと思いますが、私の「スクラムをやりたい」という提案には、案の定多くの反対意見がありました。
「仕様が頻繁に変わるのは非効率では？」
「何回もリリースしたら試験が無駄になるのでは？」
「開発工数が減らないか？」
「会議の時間が増えるのでは？」
「リリースの手順はどう変わるのか？」
と、数え出したら切りがないほどでした。
周囲からのどの懸念も理解できるものです。しかし一方で、スクラムを実践した先にある「チームが一丸となってチームワークを発揮し、ユーザーにより多くの価値を届ける」という理想に向けた挑戦を止める理由にはならないと感じていました。
そこで私が行ったのは、できる限り話を聞き、対話することでした。
・ランチ会を開く
・各部署のメンバーの具体的な業務内容を聞く
・懸念される問題点について一緒に考える
・小さな実験を一緒に試す
……そういった活動から始めました。これらの活動を進める上で、組織に新しいアイデアを根付かせるためのパターンを紹介している『Fearless Change』は大いに参考になりました。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
丸善出版スクラムマスターとしての初回は“大失敗”
周囲の理解を得ながら何とかスクラムの「はじめの一歩」にこぎつけたのですが、スクラムマスターとして臨んだ初めての開発は、率直に言って「大失敗」でした。
開発の期日は守れず、メンバーは残業まみれで疲弊し、不具合も大量に発生してしまいました。当初は開発者とスクラムマスターを兼務することで開発工数への悪影響を抑えると説明していたのですが、この失敗を通じて「スクラムマスターは片手間でできるものではない」ということを痛感し、専任でスクラムマスターに取り組むことにしました。
当時は、社内で他にスクラムを実践しているチームもなく、コミュニティへの参加経験もほぼなく、社外の知見を持った人とのつながりもありませんでした。そのため得られる情報は書籍やWebが中心となり、情報を読み込み、自分なりに解釈・実践し、内省し、改善点を次のスプリントで実行する……ということを延々と繰り返していました。
今振り返ると、この頃に「正解が分からない状況でも手を動かし模索し続ける」という思考・行動様式が身に付いたように思います。これは、後の私のキャリアにとって重要な財産となりました。
「戻りたい」とは一度も思わなかった
「スクラムをうまくやれている」という感覚はまったくありませんでした。それでも、前のやり方に戻りたいと思ったことは一度もありません。もがき苦しみながらも、小さな改善を積み重ね、スクラムの実践を続けました。
1年間の試行錯誤を経て、kintone開発チームではスプリントプランニング・デイリースクラム・スプリントレビュー・ふりかえりといったスクラムの主要なイベントが定着し、スクラムによる開発が自然と回るようになってきました。
そのうち私たちの取り組みを見て、他のプロダクトチームもスクラムに興味を持ち、採用するチームが現れました。マネージャーの協力もあり、開発組織全体でトレーニングを受講する機会にも恵まれました。スクラムを実践して1〜2年ほどたつ頃には、開発組織ではスクラムが事実上の標準プロセスとなり、スクラムを採用しないチームも、カンバンやモブプログラミングなど、何らかのアジャイルプラクティスを実践することが当たり前になっていました。
反骨心から「前に進むしかない」と思い続けた結果、気がつけば組織全体が変わっていたのです。
アジャイルを追求する過程でアジャイルコーチに
私がスクラムマスターになったのは、自分が開発していたkintoneをより良くするためにスクラムを導入した、という経緯からでした。導入直後はいかに自チームでスクラムをうまく実践するかにフォーカスしていましたが、組織の中でスクラムを導入するチームも増え、自然と彼らがスムーズにスクラムを導入し実践できるようサポートすることも、自分の責務だと捉えるようになりました。
kintone開発チームでもまだまだ改善の余地があったので、スクラムマスターとしての自チームでの実践と、組織内アジャイルコーチとしてのアジャイルの導入・実践支援という両輪で取り組むようになりました。
自チームでは、デザインや品質保証のプロセスをより計画・実装フェーズに近づける方法を探求したり、複数チーム体制でプロダクトを効率的に開発するためにスケーリングフレームワークのLeSSの導入に挑戦したりしました。その一方で、新たにスクラムを導入するチームへのトレーニングや初期のチーム支援、時には炎上したチームへの介入など、コーチとしての伴走支援にも時間を割くようになりました。
運命を変えた出会い ─ 「こんなプロがいるんだ」
この頃、私にとって大きな転機となる出会いがありました。社外で活動するアジャイルコーチである大友聡之さん （@toshiotm）に入社いただき、私が彼からコーチングを受けながら、2人で同じ現場でチームを支援するという経験をしました。支援する側でありながら同時に学ぶ側でもあるという、教育と実践が一体化した貴重な体験を得ることができました。
私にとっては初めて現場支援を受ける経験であり、大友さんと一緒にペアコーチングをする過程で、これまで靄がかかっていたような「実践のコツ」が、急速に解像度高く理解できるようになりました。
こんなプロフェッショナルが世の中にはいるんだ――。 この出会いが、私のアジャイルコーチとしての視野を一気に広げてくれました。
スクラムマスターを職能として定着させる
社内で活動するアジャイルコーチが私一人ではなくなり、組織全体のアジャイル実践をより高いレベルに引き上げるためには、独立して支援できる体制の方が向いているだろうと考え、私が中心となって開発組織内にアジャイルコーチチームを設立しました。
アジャイルコーチチームの設立を契機に、私はkintone開発チームからは離れ、一段外側からの活動になる一方で、組織内のより広範なチームを支援するようになりました。サイボウズの開発組織は全体で数百名の規模に成長し、支援の重要性と効果が高そうなチームを優先して活動していました。
その間、開発本部では部署とマネージャー職を廃止してフラットな体制を志向するなど、組織としてもこれまでの機能単位による枠組みから、よりクロスファンクショナルチーム中心のアジャイル実践に適した形を模索するようになりました。もはやアジャイルは変わり者の新たな試みではなく、組織として追求するものになっていたのです。
その後、開発本部では改めて人材マネジメントを強化するために専門性に基づき職能を整理することになりました。職能を整備する際にスクラムマスターが正式に職能となり、私はスクラムマスター職能のマネージャーになりました。
スクラムマスターを職能化するに当たって、私はその責務を「チームを健全に保つこと」と定義しました。多くのリーダー・マネージャーは目標の達成やタスク遂行に意識が向きがちです。しかし、私はこれまでの経験から、ハイパフォーマンスなチームを作るにはそれだけでは不十分だと感じています。真に自律的なチームを作るには、チームを健全に保つことも欠かせません。普段見落としがちなこの点にリーダーシップを発揮し、組織により多様なリーダーが活躍できるようにしたい……そんな思いを込めました。
自分の考え方は違う組織でも有効なのか……社外での活動
自チームへのスクラム導入を始めた頃から、意識的にその活動を発信するよう心がけていました。当時はスクラムの導入が成功するか失敗するかまったくの未知数でしたが、たとえ失敗に終わったとしても、その事例と気づきを共有することで参考にしてくれる人が一人でもいれば、発信する価値があるのではないかと考えていました。
このような考えと、コミュニティで実践者とつながりたいという思いから、実践の初期から外部イベントで自分の取り組みを紹介していました。最初はLTが中心でしたが、実践が進むと同時に登壇機会も増え、kintone開発チームにおけるスクラム導入事例を、日本最大のアジャイル実践者が集うカンファレンス「RSGT（Regional Scrum Gathering Tokyo）2018」で紹介することができました。
RSGTでの登壇をきっかけに社外で認知される機会も増え、知人から「うちでもスクラムを導入してもらいたい」と相談をいただくようになりました。発信からこのような機会につながるとはまったく想像していなかったので、最初は驚きました。
ある程度アジャイル実践を重ね、それなりに理解は深まった感覚はありました。しかし、自組織だけで実践していた私にとって、「この学びは他の組織でも通用する普遍的なものなんだろうか？ それともサイボウズという環境だからこそ、たまたまうまくいってるんだろうか？」という疑問は常にありました。この相談は、私にとってまたとない成長のチャンスだと思えました。
サイボウズは「100人100通りのマッチング」を掲げる通り、働き方の柔軟性が非常に高く、複業が自由にできることも背中を押しました。社外の現場で実践経験を積むため、サイボウズでの働き方を週4日に変更し、週1日は個人事業主のアジャイルコーチとして他社を支援するようになりました。
その後は複業の案件調整やオーバーワークを避けるため、サイボウズを週3日として、2018年ごろからは一貫して週3日の社員＋個人事業主という働き方を続けてきました。
二足のわらじによる実践は、非常に学びの多いものになりました。組織の中のメンバーとして深い実践を探求する傍らで他社の現場も見ることで、それぞれの学びを他方に生かすことができ、より豊かな気づきを得ることができたのです。
「どうやら正解はない」アジャイルを追求する旅は続く
スクラムを始めた頃の私は、まるで暗闇の中で手探りしながら歩いているような感覚でした。毎日のように「これでいいのか？」「本当にうまくいくのか？」という疑問が頭の中を駆け巡り、時には眠れない夜もありました。書籍を何度も読み返し、海外の事例を調べ、「どこかに必ず答えがあるはずだ」と信じて探し続けていたのです。
しかし、これまでの10年以上にわたる実践を通じて、私は一つの重要な結論にたどり着きました。それは、「どうやら正解はない」ということです。
どんなに経験豊富な専門家が「このやり方がベストだ」と力強く主張したところで、それが実際に機能するかどうかは、チームの文化、メンバーの個性、組織の制約、プロダクトの特性……あらゆる要素によって変化します。私たちが向き合っているのは、まさに生きた人間同士の複雑で繊細な関係性なのですから。
「正解がない」から始まる本当の実践
では、「正解がない」のであれば、私たちはどうすればよいのでしょうか？
私が今確信を持って言えるのは、「正解はない」という現実を受け入れることから、本当の実践が始まるということです。不安や迷いを感じながらも、まずは目の前の小さな一歩を踏み出してみる。その勇気こそが、全ての変化のきっかけになります。
常により良い方法を模索し続け、それぞれが実践から得た知見を持ち寄り、時には激論を交わし、時には支え合いながら進んでいく。そんな関係性の中にこそ、正解を超えた何かがあるのではないでしょうか。
私と関わり対話することで人々が変わり、さらに私も新たな気づきを得て変わっていく。この学びの循環こそが、アジャイルの神髄だと感じています。正解の分からない環境でも、勇気を持って一歩を踏み出すことのできるリーダーが、一人でも多く生まれることが、正解を探すよりもずっと大切なことです。
皆さんのこれまでの、そしてこれからの実践の道が、困難も含めて発見と成長に満ちた素晴らしいジャーニーになることを、心から応援しています。
編集・制作：はてな編集部
- 天野 祐介（あまの・ゆうすけ）@ama_ch
- 元サイボウズのスクラムマスター・アジャイルコーチ。東京→仙台移住しました。スクラムフェス仙台実行委員会。すくすくスクラム仙台運営。一歩立ち止まって、今後の生き方を模索中です。
ブログ：天野 祐介 (ama_ch)｜note
