Agile Journeyをご覧のみなさん、こんにちは。今井健男（@bonotake）と申します。「ぼのたけ」と名乗っていることもあります。普段はフリーランスのアジャイルコーチをしつつ、現在は国立情報学研究所という国の研究所でスクラムの研究をしています。
今回、「はじめてのアジャイル」という連載企画に声をかけていただき、僕がアジャイルの道に進むきっかけをこちらに書くことになりました。ただ、執筆の依頼をお引き受けはしたものの、正直なところ、僕の体験が皆さんにとって何かしら参考になるかは分かません。もともとずっとソフトウェア工学の研究をしている研究者だった、という特殊な経歴の持ち主だからです。
恐らく他の人とはかなり変わった視点からアジャイルを体験してきていて、あまり共感されるような内容ではないかもしれませんが、それでも読者の方のうち何人かは面白がってもらえるかもしれないと期待して、ひとまず筆を進めてみようと思います。
- ソフトウェア開発のことばかり考えてきたキャリア
- ベンチャー企業でのスクラム導入体験と挫折
- 『SCRUMMASTER THE BOOK』との出会いと開眼
- 自分が感じたスクラムの合理性
- ソフトウェア開発の本質を探求したい
- 合わせて読みたい関連記事
ソフトウェア開発のことばかり考えてきたキャリア
僕の社会人としてのキャリアは、東芝の研究所でスタートしました。それから17年、その所属は変わらず、ほぼずっとソフトウェア工学を研究しながら過ごしてきました。最初はそれこそ社内独自の開発方法論を考案するなんて研究もしていましたが、後年は形式手法など、テストや検証の基礎理論に近い領域を研究していました。
その後は東芝を離れ、主にエンジニアとして過ごしてきました。ただ、その際も開発していたのはコンパイラやSDK（Software Development Kit）などの開発ツールでした。もともと学生時代も設計ツールやプログラミング言語が専門だったことも考えあわせると、トータルでだいたい人生の30年くらいを「良いソフトウェアをどのようにうまく作るか」を考えることに捧げてきた、とも言えます。
そうした中、最初にアジャイルを知ったのは東芝で新人の頃、ちょうど「アジャイルソフトウェア開発宣言」が出る前後でした。当時は学会誌に平鍋健児（@hiranabe）さんがXP（エクストリームプログラミング）を紹介する記事が載るなど、ソフトウェア工学界隈でもホットな話題ではあったのですが、しかし「自分が勤める大企業では関係のない話」という思い込みから、自分で実践してみようと思うほどの興味は持てませんでした。
実は当時、グループ会社に関将俊（@m_seki）さんがいて早くから自社でXPを実践されておられたので、自分の思い込みは完全に誤りだったのですが、当時は関さんの存在にも気づかず、自分の誤りにも気づくことはありませんでした。
この頃の話はスクラムフェス三河2023でも話していますので、当時どんな空気感だったかはそのときの講演資料「そのとき歴史は動かなかった」をご参照いただくのが早いかもしれません。
ベンチャー企業でのスクラム導入体験と挫折
それで東芝を退社後、あるベンチャー企業にテックリードとして転職し、そしてこのとき初めてスクラムを体験しました。もう詳細は忘れてしまったのですが、チームの誰かが「スクラムをやろう」と提案し、他に反対するメンバーもおらず「やろうやろう」という空気の中、するすると導入にこぎつけました。
実は、このときやっていたスクラムのことはあまり詳細に覚えていません。というのも、特につまづくことなく導入できてしまったからです。当時、知人で交流のあったアジャイルコーチの守田憲司（@wsfjp）さんから個人的にいろいろ教えてもらえたという幸運もあったものの、スクラムを実践する上でつまづきもなければ、トラブルや困ったことも特に発生しませんでした。
今にして思えば、そのチームはとても「スクラム向き」でした。もともとチームワークが良く、メンバー同士でサポートしあうことが自然にできていました。しかも、プロダクトオーナーになってくれた上司のマネージャーが見守り型の人で、エンジニアの自由にさせてくれた上に、経営陣からの無茶ぶりな要求をはねつける防波堤にもなってくれていました。本当に、今にして思えば、あまりにも恵まれたチームだったんです。
ただそのせいで、僕自身は「スクラムはこんな感じなのか」くらいの甘い認識に留まってしまって、それ以上深く興味をひかれることもありませんでした。
全くうまくいかなかった2度目のスクラム導入
それから数年がたち、僕は別のベンチャー企業に在籍して、2回目のスクラムを体験することになります。
あるときCEOとCTOに呼ばれて、新規事業を立ち上げるから、そのチームで開発をリードしてほしい、と言われました。そして、その詳細を打ち合わせする中で、CTOがぽろっと「もう僕らが面倒見切れない」と漏らすのを聞いたのです。そのベンチャーでは、それまでずっとCEOとCTOのどちらかが開発チームのマネジメントをしていたのですが、プロジェクトが増えて、もう手いっぱいになっていたのでした。
それで、僕はつい「じゃあ、チームにスクラムを導入して、僕がスクラムマスターをやりましょうか」と提案したのです。以前の会社でスクラム導入を簡単に成功させていた「甘い」認識から、軽々しくそんな話をしてしまったのです。
提案はCEOとCTOに受け入れられ、新しいチームはその会社では初めて本格的にスクラムを導入することになり、僕はそのチームでエンジニア兼任のスクラムマスターになりました。
……全くうまくいきませんでした。メンバーは不平不満ばかりを口にして、スクラムイベントの1つ1つに「何でそんなことをしなければならないのか」と猛反発を受けました。
以前の会社と違い、このチームはそれまでほとんど個人開発しかしてこなかったメンバーばかりで、チーム開発というものに全く馴染みがなかったのです。その上、コロナ禍より以前からリモートワークが積極的に導入されていて、ミーティングよりもSlackでの非同期コミュニケーションを好む企業文化だったことも災いしました。全く「スクラム向きでない」チームだったんです。
今でこそ振り返ってそうした分析ができるのですが、当時は、どうしてこんなにうまくいかないのか、全く訳が分かりませんでした。それで、自分がスクラムをなめていたことに気づき、改めていちから勉強し直す決意をしたのです。
『SCRUMMASTER THE BOOK』との出会いと開眼
そのときも守田さんにいろいろと助けてもらったのですが、そんな中で勧めてもらった本がZuzana Sochovaの『SCRUMMASTER THE BOOK』でした。
SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ
翔泳社自分はその本を読んで、強い衝撃を受けました。全く知らなかった世界がそこにありました。
本を通して書かれている内容すべてがとても興味深かったのですが、自分が一番衝撃を受けたのは、第1章の最初の方に書かれていた次の一節でした。
あるメンバーにとって気に入らないことがあるときは、チーム全員で話し合ってお互いを理解し、協力や助け合いの方法を変えていかなければなりません。最も重要な特徴は、一人一人のマインドセットです。
以降も、同書ではマインドセットの重要性が繰り返し述べられていました。そして、スクラムマスターの基本的な仕事の1つは、チームや組織にアジャイルなマインドセットを持ってもらうことだ、ということも強調されていました。自分はそこで、今までもやもやしていたスクラムへの理解がいっぺんに晴れやかになったような感覚を覚えました。自分の中では「スクラムに開眼」した瞬間でした。
正直な話をすれば、それまではアジャイルに対して、まだ「ハッカー文化のTシャツを着た兄ちゃんたちが適当に考えたもの」くらいの偏見に近い思い込みを持っていました。しかし、この気づきを経て、そこに工学としての合理性を強く感じました。そして、そこにはしっかりとサイエンスが眠っているように思えたのです。
それで、ただ業務のためだけではなく、ソフトウェア工学者としての知的好奇心からスクラム・アジャイルの世界に没入するようになっていったのです。
自分が感じたスクラムの合理性
ここまで読んだ方の中には、今までの話のどこに合理性があるのか？ スクラムの合理性って何？ と思われた方もいるでしょう。
『SCRUMMASTER THE BOOK』でスクラムに目覚めたという話は、僕は過去に界隈の方何人かにしたことがありますし、世間的にもそれほど珍しい話ではないと思います。ただし、当時の自分が感じた合理性が何なのかについては、実は全く人に話したことがありません。1人の研究者としてのあまりにマニアックな思索で、誰かに見せられるような代物ではないし、見せたとしても理解してもらえないだろうと思っていたからです。
ただ、それをお伝えしないと、この「はじめてのアジャイル」の企画に沿わない気がして、ですのでここに初めて、その内容を公開しようと思います。自分の中ではもっと厳密に書きたいという想いはあるものの、別にこの記事は論文ではないですし、読者の皆さんに多少なりとも分かってもらえるよう、多少は砕けた、その代わり厳密さには欠けた、学術的な視点では殴り書きのような内容になってしまうのはご容赦ください。
スクラムでは変化し続けることが重要なファクターである
ここでは説明を平易にするため、ウォーターフォールとの比較でその話を進めてみます。
ウォーターフォールでは、企業や事業部門の単位で標準プロセスを1つ定めて、みんながそこになるべく従うようにします。プロジェクトに応じて多少カスタマイズ（テーラリング）もしますが、その後プロジェクト進行中にプロセスを変更することは原則せず、変更する場合はかなり例外的な扱いになります。
しかし、スクラムは変化を許容します。そうするとプロセス自体を変更したくなった場合に、標準プロセスがあると邪魔になってしまいます。だから、スクラムは「フレームワーク」として定義されています。「スクラムガイド」は抽象的な文章で書かれ、さまざまな解釈の余地が残されています。その解釈の余地において、スクラムでは自分たちのやり方を自由に変更していいし、むしろ常に変化させていくことを推奨しています。
これはつまり、数学っぽい解釈をするなら、ウォーターフォールは点で、スクラムは空間で基準を定めているのです。そして、スクラムを実践する際は「改善」、つまり基準として置かれた空間の中で点から点へと移動しつつ、そのときそのときで最適な点を模索し続けることが求められる、というわけです。
スクラムとしての正しさは常に正しく変化し続けられるかにかかっている
しかし、このやり方には大きな問題点があります。空間の定義があいまいなため、「スクラムとして正しい」か否かの判断が極めて難しいのです。
ウォーターフォールの場合、標準プロセス（あるいはテーラリング後のプロセス）との距離・近さが「どれだけ正しいか」の指標になります。これは容易に定義できます。標準プロセスは書き下せるので、それに沿っているかどうか、どこが違っているのか、の判断も難しくはないはずです。
一方スクラムでは、チームは常に「改善」という名の「点から点への移動」をするので、「スクラムを正しく行っている」かどうかは「その移動が常に正しいか」にかかっている、といえます。言い換えるなら、その「移動」全体を表す関数がスクラムの正しさを保証できるか、という問題なのです。
プログラミング言語っぽい書き方をするなら、「スクラムである」空間を表すScrum型があるとして、この関数はScrum -> Scrumという型を満たしているか、という問題だとみなせます。関数の返り値がスクラム空間からはみ出してはいけないわけです。
で、その保証はとても困難です。まず、スクラム空間内の点となるスクラムの状態は無数に存在します。例えば、公式のスクラムガイドに書かれているプロダクトバックログのリファインメントひとつを取っても、
- スプリントプランニングの直前に行う
- スプリントの真ん中に行う
- 毎日少しずつ行う
など、さまざまなやり方があり得ます。どれが適切かはその時々の状況に応じて変わり、チームは最適な方法を判断し、選択しなければなりません。もしかすると「リファインメントの時間を確保しない」という一般的には推奨されない選択肢が、そのチームでは最適になる可能性もあります。
こうした選択の適切さは、チームが置かれている状況に依存します。メンバーの離脱やビジネスの状況変化に伴う新たな制約など、チームを取り巻く状況は予測不能な形で変化し続けます。チームがあらかじめ把握できる状況はその可能性の中のほんの一握りでしかありません。
つまり、チームは不測の事態を含めたあらゆる状況に対して「改善」という名の適切な選択を行わなければならず、その選択肢は無数に存在するのです。そのパターンをすべて洗い出して書き下すことは到底不可能ですし、フローチャートやプログラムのように形式的に記述することも恐らく困難でしょう。
つまり、「改善」を表す関数を直接的に定義することはほぼ不可能です。定義できないものの正しさを保証することは極めて困難です。
重要なのはマインドセットという名の暗黙知
しかし、ここで「スクラムのマインドセット」を導入することで、この問題は解決するのです。
マインドセットと聞くと、スクラム・アジャイルを知らない人は何かしら精神論的なものを想像するかもしれませんが、実際には、どちらかといえば思考法とか、ちょっとしたノウハウの集積に近いものです。不測の事態に際したとき、どのように考えればよいか、どういった思考の下で自分たちのやり方を変化させればいいかといった、言葉では表現しきれないさまざまな暗黙知のカタマリがマインドセットなのです。
そうしたマインドセットがある前提に立ち、「スクラムのマインドセットを持つ人間が実施する改善」として関数を実装することで、その関数がScrum -> Scrum型になることを保証できます。逆に言えば「スクラムのマインドセット」に求められる要件の1つは、その関数がScrum -> Scrum型になることだ、となるのです。
こうした仕組みが意図的に組まれたものなのか、あるいはスクラム実践者の中で自然発生的にできあがったものなのかは分かりませんが、私にはとても合理的な仕組みに思えました。そして、スクラムを断片的に理解していたことで自分の中に生まれていたいろいろなピースが、このように理解することで完璧にはまって1つになった感覚があったのです。
マインドセットの獲得は学習コストが高い
一方で、それまで自分が観測していた「スクラムの短所」とも呼べるような現象も、以上のような仕組みを前提にするとだいたい説明がつくように思えました。
たとえば、スクラムの実践においては暗黙知のカタマリであるマインドセットを持つことが鍵になるので、学習コストが高く、習得も「正しい」実践も容易ではありません。本やブログを読んだだけでスクラムを適切に実践することは不可能で、適切なマインドセットを持った人物から、そのマインドセットを何らかの形で伝授・継承してもらう必要があるはずです。
そういう意味では、僕はスクラムの道へと足を踏み入れるにあたって、たまたま知人に守田さんというアジャイルコーチがいて、いろいろ手ほどきをしてくださったことがとても僥倖なできごとだったといえます。だから、恐らく世間一般の人よりずっと「アジャイルの道」を最短に近いルートで駆け抜けられた、と思っています。
マインドセットを持つ者と持たざる者との間の断絶
また、マインドセットを持つ者と持たざる者とで、スクラムの理解に対する大きな隔たりが生じます。これはそのまま、両者の断絶につながります。
よく「スクラムをやったがうまくいかなかった、スクラムは使えない」といったブログ記事やSNS上でのつぶやきに対して、実践者が「なんちゃってスクラム」扱いをし、それに対して非実践者が「まるで宗教だ」と反応する、といったやりとりを見かけますが、結局これはマインドセットの有無が生み出す断絶の問題に帰着できるのではないでしょうか。
ここまで述べてきたように、マインドセットはスクラムを正しく運用するには不可欠な、暗黙知を多く含む独自の思考法なのですが、多くの人にはそれが分からず、せいぜい「ただの精神論だ」と考えがちです。そして、そうした人たちは「マインドセット抜きでスクラムのプロセスだけ取り入れる」といったことをよくやります。しかし、それではたいていスクラムの本質を欠いてしまい、実践者には「それはスクラムではない」と映ってしまうのですが、非実践者はマインドセットを持っていないが故に、その理屈を理解できないのです。
一方、スクラムは何かしらの神様を信仰する宗教ではもちろんありませんが、「スクラムをきちんと実践できるのはスクラムのマインドを持つ者だけ」という時点で、宗教に近しい何かではあるのです。恐らくは思想や信念などと呼ぶのが適切なものなのでしょう。
……といったあたりが、僕が『SCRUMMASTER THE BOOK』を読んだ後によく考えていたことでした。
ソフトウェア開発の本質を探求したい
スクラムに「開眼」した後、僕はCTOと相談してエンジニア兼任をやめ、スクラムマスター専任になりました。そして自分なりに「マインドセット」に忠実にスクラムマスターをやってみた結果、今まで全くまとめられなかったチームがある時期から嘘のように変貌し、チームは強い団結力とチームワークを有した、社内で一目置かれる存在にまで成長しました。
一方自分は、すっかりスクラムの面白さにハマってしまっていました。幸いなことに、バラバラだったチームをまとめあげた結果、スクラムの価値が社内でも見直され、他のチームにもスクラムが導入されるようになり、僕はその導入を先頭切って行う事実上の社内アジャイルコーチになっていきました。これが今のアジャイルコーチとしてのキャリアへとつながっています。
そして今や、スクラムを実際に自らの手で研究する立場にもなりました。そのあたりの経緯は以前に自分のブログでも書いたのですが、こうして振り返ってみると結局自分はずっとアジャイル実践者でありながら、少し離れたところでもう1人の自分がソフトウェア工学者の立場でアジャイルを見ていたのだな、と改めて感じます。
プロダクト開発の実現形態の1つとしてのアジャイル
ソフトウェア工学者の立場でいうなら、もしかしたら読者の方々の思いを裏切るのかもしれませんが、実のところ僕はアジャイルがこれ以上ない至高の開発手法であるとも思っていないですし、その思想に心酔しているわけでもありません。
ソフトウェア開発には――いや、これだけソフトウェアがさまざまなプロダクトの中に浸透した現代においては「プロダクト開発には」と言い換えるべきなのかもしれませんが――開発モデルによらないいくつかの「本質」が奥底にあって、どんな開発の形態を取ろうとも、それらの「本質」を組み合わせたものでないとうまくいきません。そしてアジャイルと呼ばれる開発モデルも、その「本質」を組み合わせて実現された、開発を実践するための一形態に過ぎない、と僕は思っています。
ただし、その一形態として見たとき、アジャイルは極めて合理的で、非常によくできたシステムだと感じています。少なくとも現時点では、いくつかの欠点がありはしますが、これを大きく上回るようなプロダクト開発のシステムは思い当たりません。
そして自らアジャイルを実践・探求してみて、自分の中にあった「本質」への理解は大きく拡がったと感じています。だから、アジャイルを実践して割とすぐに思ったことは「自分が得た知見をソフトウェア工学に還元したい」ということで、一時はどうやってそれを実現するかをずっと考えていました。その想いが結局、しばらく離れていた研究の道に自分を呼び戻すことになったように思います。
そんな僕の中の根源的な欲求は、アジャイルの探求というよりは、その裏にある「本質」の探求です。これからも「本質」に向かい合うべくアジャイルの研究と実践を進めていきたいし、そこで得られたものの1/100でもいいから、何かしらの形にして社会に還元していきたい、と考えています。
編集・制作：はてな編集部
- 今井 健男（いまい・たけお）@bonotake
- 2000年に東京大学大学院を修了後、東芝でソフトウェア工学の研究に従事。その後、複数のスタートアップでエンジニアなどを経験し、2023年にアジャイルコーチとして独立、また同年から国立情報学研究所に所属してスクラムの研究を始めた。著書（翻訳）に『抽象によるソフトウェア設計―Alloyではじめる形式手法（オーム社）』『型システム入門―プログラミング言語と型の理論（オーム社）』『なぜイノベーションは起こらないのか: 真正の需要を捉えるプロダクト創出の科学（丸善出版）』。
