アジャイルの練度を上げたいと言われたときに私が考えてること

はじめに

本記事は、Uzabase Advent Calendar 2025 12日目の記事です。

書こうと思ったきっかけと目的

ユーザベースに入社してから5年目になりました。

入ってから2〜3年くらいはスクラムとXPの違いは何か、フルタイムのペアプロや計画づくりが難しいということで右往左往していました。

アジャイルについて造詣の深いメンバーが多く在籍しているおかげもあり、最近はようやくアジャイルについて多少理解できてきました。

そうなったときに「アジャイルがもっと上手くなるにはどうしたらいいのでしょうか」という相談を受けることが増えてきました。

そのたびに私は「プラクティスを忠実に実践すること」「そのプラクティスの背景や紐づくValueや原則を意識すること」「そのプラクティスは何のためにやるのかを考える」という回答を続けていました。

今でもそう思うことに変わりありません。ですがあらためて考えると具体性に欠ける感覚です。

せっかく相談してくださった相手も「なるほどー…」という腑に落ちたような落ちてないような、曖昧な感じで終わってしまう印象で、伝え方にのびしろを感じていました。

そうした背景もあり本記事では「どうしたらもっとアジャイルが上手くなるのか」という問いに対して、もう少し深堀りしていく試みをしていきます。

（上手くなる・上達する、と言うとDo Agile感があるのですが、本記事ではあえて上達すると言うことにします）

前置き

ユーザベースのSpeedaプロダクトチーム（以下、プロダクトチーム）では、XPをベースとしたアジャイルな開発を実践しています。

本記事で出てくるプラクティスや価値、原則については基本的にXPにあるものを記述します。

はじめに
書こうと思ったきっかけと目的
前置き
アジャイルが上達するの本記事での定義
スキルを身につけた、という不確かさ
形だけなぞらえたスキルは環境が変われば発揮されない
なぜ上手くいったのか・上手くいかなかったのかをふりかえる
ふりかえりによって、プラクティスの関係性や背景に焦点が当たる
暗黙化によるスキルの文脈依存性への影響
手順や行動に意識を向けすぎない
上手くいっている人たちの真似をする
- 自身の解釈を脇に起き、見たままを真似する
ロールモデルが見つからない
おわりに
参考文献

アジャイルが上達するの本記事での定義

最初に考えていきたいのは、「アジャイルが上達する」とはいったいどういう状態なのかです。

いままで相談してきてくれたメンバーの話を聞いていると、今の状態ではアジャイルが上手くなっていないという感覚はあれど、上達するとはどういう状態なのかの解像度がそこまで高くない印象でした。

私の観測範囲ではありますが、アジャイルの練度が高いメンバーの行動を観察したときに、以下の3点があると思いました。

不確実性の高いプロジェクトを安定的に進めることができる
新しいメンバーに対してアジャイルのプラクティスのやり方とそれをなぜやるのかを説明できる
それぞれのプラクティスがどう関係しているのかを説明できる

1つ目はプラクティスを実践することでプロジェクトを安定的に進めるという結果出せる。2、3つ目はそれを他者に説明できるほどの理解を有している状態と言えます。

ただこれらは目指す状態ではあると思いますが、少し遠い場所に見えます。もう少し手前の何かが無いかを考えたときに、個人的には以下じゃないかと考えます。

アジャイルの上達とは、プラクティスを効果的なタイミングで正当な理由で実践できる、あるいは実践しないこと

XP白本には価値とプラクティスが紐付いたときに、どういう事ができるかが書かれています。

プログラマーがプラクティスを効果的な時期に、正当な理由で実行できることが、価値とプラクティスが結び付いているという意味である。価値はプラクティスに目的をもたらしてくれる。

ーー『エクストリーム・プログラミング』p.12（強調は筆者）

「正当な理由」がポイントだと考えます。これは結果的に適切なタイミングで実行できてしまうこともあるので、理由がちゃんと説明できた上で実践できることが大切です。

実践する理由が説明できるということは、価値とプラクティスの紐付きが理解できているということです。逆に考えれば、今は実践しないほうがいいという理由も説明できるはずです。

チームやプロジェクトの状況に応じて、ツールあるいは武道の技のように、適切なタイミングでプラクティスを実践していけることをアジャイルの上達である、ということを本記事では前提としていきます。

スキルを身につけた、という不確かさ

では適切にプラクティスを実践できる or できなかったというチェックリスト的な考え方で上達したと言えるのでしょうか。

プラクティスを実践していて感じるのは、一定期間できるようになったと言って、それはそのスキルを身につけたと言えるのかどうかです。

TDDを例にしてみると、

書籍を開いてTDDの基本的なサイクルであるRED→GREEN→REFACTORを理解して、サンプルコードを見ながら実際に手を動かしてみる
概念を理解したし、プロセスに沿ってコードも書ける
更にそれを現場のプロダクションコードで初めて実践してみて、数ヶ月続けている

これを一般的には「TDDのスキルを身につけた」と表現されると思います。

ただここで一つ考慮しないといけないのは、スキルの文脈依存性です。

人の学びについて書かれた「私たちはどう学んでいるのか」から能力の文脈依存性について以下のことが書かれています。

これらのことは私たちの知的な行為を支える原因とされている能力が、その言葉が持つイメージに反して内在性、安定性を持たないことを示している。（中略）もう1つ述べるべきことは、認知的変化を含めた人の知性を文脈、つまりそれが発現する環境から切り離して論じることは適当ではない、ということである。

ーー『私たちはどう学んでいるのか』p.41

先程のTDDのスキルの例で言えば、そのスキルはいまの現場のプロジェクトの環境やプロダクションコードという文脈に依存しているということになります。

この状況で別のプロジェクトで別の言語で書かれたプロダクションコードでTDDを実践する場合にはどうなのでしょうか。

同じプロジェクトでもリリース時期が直近など、切羽詰まった環境ではどうか。

テストのないレガシーコードで積み上がってきたところで途中からTDDを始めるにはどうか。

大抵の場合は、最初の環境で実践できていた通りのTDDはすぐには実践できないと思います。

それは発揮できたスキルがそのときの状況に依存しているからであり、その状況が変わることにより、今までできていたものが発揮されないという不安定さがあるからです。

形だけなぞらえたスキルは環境が変われば発揮されない

環境が変わることで過去に発揮できてたスキルが発揮できなくなるというのは、私自身の経験則としても当てはまります。

私の中で印象に残っているプロジェクトの1つに、ユーザベース入社して2年目の新規機能立ち上げプロジェクトがあります。

そのときのプロジェクトでは、エンジニアのキャリアとして初めて1からモノを作っていく経験をしました。

チームが新しく作られるわけなので、今までの既存チームで頼りにしていた計画づくりのためのベロシティも存在しません。当時の私としては新しく触る技術も多かったです。

そのときの私は入社してからXPに触れ、ペアプロ・TDD、プランニングなど様々なプラクティスを学び、アジャイルに関しては割と自信を持っていました。

ただ、そうした今までと全く違うプロジェクトの状況に飛び込んだ時に、今まで出来ていた（と思っていた）プランニングだったり、ペアプロやTDDがスムーズにできなくなってしまい、とても悔しい想いをしたことがあります。

このとき、今まで培ってきたスキルは環境が変わることで再現できなくなるということを実感しました。

なぜ上手くいったのか・上手くいかなかったのかをふりかえる

スキル・能力には文脈依存性があると考えた時に、プラクティスを繰り返し実践することには意味がないのか。ではどのように覚えていくといいのだろうかという疑問が湧いてきます。

1つ鍵となるのはふりかえりです。

プラクティスを実践した後、1日や週の終わりにふりかえってみる。そこまで時間を取る必要も無いと思うので、毎日取れるなら1日5〜10分くらいで十分だと思います。

プラクティスがなぜ上手くいったのか、逆に上手くいってなかったらどうしてなのか。それをもっとより良くする（もしくは改善する）にはどうしたら良いのだろうか。という問いを続けます。

ふりかえりを続けていると、「これは前もあって上手くいった」「同じ状況だったけど上手くいかなかった」という知識が積み重なっていきます。そうするとプラクティスのどこが本質であり、どこが省いたり変化させても良いかが見えてきます。

私の場合はペアプロを行っているときに相手を置いてけぼりにして認識が揃わなくなってしまったり、ずっと指示をするようなナビゲーターをしてしまって相手と衝突することがありました（今もそれなりにあります）。

どうしてそういう状況になったのかをふりかえったときに、リリースを急いでいる状況だったり、相手の知っていることを聞くよりも先に私が知っていることを一方的に喋るようなコミュニケーションの仕方をするというリスペクトが足りない状態だったことに気づきました。

その後は喋る前に一息相手を待つようにしたり、モニターばかりではなく相手の表情がちゃんと見えるような位置に座っていくのを試したりして、どうなるかを観察していきました。その結果を見て、何か変えるかどうかを考える、その繰り返しを日々しています。

ふりかえりによって、プラクティスの関係性や背景に焦点が当たる

日々のふりかえりをする上で知っておくと良さそうな考え方に、マイケル・ポランニーが提唱した近接項（proximal term）、遠隔項（distal term）という概念があります。

外界から知覚・体感できる情報を近接項と呼び、それらを生み出す原因・意味を遠隔項と名付けており、これらの関係性が包括的に理解されたときに暗黙化されて身体化されるという考え方です。

「私たちはどう学んでいるのか」の中で近接項と遠隔項について説明されている記述を引用します。

私たちは世界からさまざまな情報を受け取る。これらは近接項と呼ばれる。つまり自分が実際に体感できる情報である。（中略）一方、世界の側ではそれを生み出す原因系が存在する。これが遠隔項である。そして近接項から生み出された内部モデルを遠隔項と結びつけたときに真正の理解が生み出されるという。

ーー『私たちはどう学んでいるか』 p.197

引用では遠隔項のことを原因系と言っていますが、Web上で調べていると近接項が生まれた原因・対象や意味、というニュアンスもあったので、この記事では原因・意味という解釈をします。

以下に箇条書きでまとめます。

近接項
- 自分が接触したり知覚したり体験できる事物や行動
  - 例:自転車のハンドルを握る感触やタイヤから伝わる振動など
遠隔項
- 近接項が生まれる原因・対象や意味
  - 例:自転車のタイヤの先にある道の凹凸など

日々実践しているアジャイルのプラクティスは近接項と言えます。そのプラクティス自体を生み出す意味として原則や価値があります。これらは遠隔項と考えられると思います。

以下にTDDサイクルを例したときのそれぞれの関連を図にしました（他の価値や原則も紐づくはずですが、書ききれないためここでは絞ります）。

TDDを例としたときに、人が知覚しやすいのはTDDのRED→GREEN→REFACTORのサイクルです。

落ちるテストを書き、それを一刻も早くパスさせるという考えはフィードバックの価値だったり、リファクタリングを通して改善することでシンプルさの価値へつながることが見えてきます。

これらの近接項（TDD）と遠隔項（フィードバック・シンプルさ）の繋がりが包括的に理解ができるようになってくると、TDDというサイクルの手順は無意識になって暗黙化されていきます。

RED→GREEN→REFACTORの各ステップを常に意識して、やった・やってないというチェックリスト的に分解していくという目の前で知覚できる事象へ焦点を当てた理解ではなく、素早いフィードバックループの形成やシンプルさを保つためにどこからテストを書くか、どこまでの実装にするのかというプラクティス背後にある価値という遠隔項へに焦点が当たった状態です。

いま見えている近接項・遠隔項自体も、また別の近接項と遠隔項につながって多層的になっていきます。

たとえばTDDを実践することによって、テストが書きにくいというシーンに遭遇することがあります。

それ自体も人が知覚できる近接項であり、それが生まれた原因でもある遠隔項の1つとしてTDDとなります。

もう一つの原因としてテスト対象に依存しているオブジェクトなどが多すぎて、そもそも事前準備が大変だったりするという遠隔項が存在するかもしれません（テストの書きにくさの原因はいろいろあるので、あくまで一例です）。

これも最初のうちは「テストが書きにくいな。どうしてだろう」という、いま知覚出来ている近接項への意識が向きますが、何度も経験してふりかえっていくと、テストの書きにくさという近接項は暗黙化されてすぐに「依存関係が多い」という感覚に行き着くようになります。

暗黙化によるスキルの文脈依存性への影響

近接項（プラクティス）が暗黙化されることによってスキルの文脈依存性についてどう影響するのか。

プラクティスそのものが暗黙化されるというより、プラクティスの細かい手順が暗黙知となり、自身の身体の一部と同じような感覚で身体化されていきます。

コードを書く人が val hoge = 1と書くのに、「左手人差し指を動かしてvキーを押し、左手小指を動かしてaキーを押して…」ということをいちいち考えずとも、打ち終わっていると思います。あのような感覚です。*1

TDDのサイクルの中で行われていることをいくつか抜粋すると、

小さく検証をする　→　素早いフィードバックループための手段
問題（テスト対象）を小さく分割する　→　小さく設計するための直観
テストを通すためだけの実装する　→　やりすぎない、必要なときに最低限必要なことをする

これらが暗黙化されて自分の身体を動かすくらいに自然になると、プログラミング以外の別文脈でも適用できることに気づいてきます（「私たちはどう学んでいるのか」で言うところの、必要な場面で場面に応じた形でほぼ無意識に働く、場面応答性）。

たとえばユーザーストーリーを出して見積もりをするときでも大きすぎるストーリーがあればどう分割するかは転用できますし、議論が白熱して場が膠着したときにもいま必要な分だけ決めてそれが決まったら他は後の機会で決めるという選択をすることもできます。

こうした繋がりを発見するには、リアルタイムで実践していく中で気づくのはなかなか難しいと思います。どんなに経験がある人でも目の前で体感できる情報に目が向きがちだと思います。

そのため、日々のふりかえりを通して関係性を理解できるように練度を高める機会をつくることが上達に近づいていくと考えます。

手順や行動に意識を向けすぎない

近接項と遠隔項の話の中で面白かったのが、近接項に注目しすぎるとかえって遠隔項を見失う傾向があるとのことです。

こちらも「私たちはどう学んでいるのか」に書かれています。

一方、無理に近接項に注目すると、遠隔項が知覚できなくなってしまう。（中略）私は誤字脱字が多いのだが、この訂正を行う時には文の意味がわからなくなることがよくある。つまり文、文章の全体ではなく、それを構成する近接項に注意を向けることで、全体を表す遠隔項が見えなくなってしまう。ポランニーはこのことを「（部分＝近接項に注意を向けると）意味はすべて、我々自身から遠くの方へ離れていくような傾向を持つ」と述べている。

ーー『私たちはどう学んでいるのか』p.199

私自身、はじめてアジャイルな開発を実践した現場で似たような経験がありました。

当時はスクラムを導入していましたが、スクラムのイベントをどう実践するか、それぞれのプラクティスをどうやってやるのか、という方向に目が向きがちとなり、3ヶ月後にリリースした機能はそもそもユーザーにとっては要らないものだったという体験でした。

別に私も含め同じチームメンバーが、ユーザーをおざなりにしている、フィードバックをもらいたくない、ということでは無かったのに、です。

どうアジャイルをやるのか、という近接項ばかりに目がいき、そこで実現したかったフィードバックループを早くするなどの価値（遠隔項）が置き去りになってしまっていたということだと思います。

上手くいっている人たちの真似をする

アジャイルのプラクティスやその背後にある原則・価値、また他のプラクティスの紐付きを理解するためにはふりかえりが有効だと書きました。

ですが、そうは言ってもそこまで意識をするようなふりかえりにしていくのも、難しいと思います。

私がはじめてアジャイルを実践したプロジェクトのように、誰もがまず近接項レベルのところへ意識が向き、背後の遠隔項へ意識を向けられずに、いつの間にか大事にしたかった原則や価値が置き去りになってしまうことはありえます。*2

自然と背後にある考え方にあるものへ思いを馳せるようになんとかできないでしょうか。

一つ良いと思っているのは、上手くいっている人・チームを真似することです。

アジャイルのプラクティスを実践して既に上手くいっている人たちは何かしら理由があるはずです。

もし自分が所属しているコミュニティにそういう人やチームがいるのであれば、状況的にも適用する可能性が高いので、その人たちを真似をしながら上手くいったかいかなかったかをふりかえっていき、知見を溜めていきます。

もう一つ大事だと思うのは、真似をする上では自分が真似をしたいと思える、すなわちロールモデルと感じられる人たちを見つけることです。

ロールモデルの真似をすることの重要性について、「私たちはどう学んでいるのか」には以下のことが書かれています。

模倣者＝集団の新しいメンバーは、この所作、動作を観察することを通して、彼に対しての威光を感じ、それが動機となって模倣を行う。生田は、これは強制的な模倣ではなく、あくまで学習者が自ら行う価値判断、そして相手を「善いもの」とみなすことが基礎にあると述べている

ーー『私たちはどう学んでいるのか』 p.209　（強調は筆者）（ここで出てくる生田とは、「わざ」から知るの著者・生田久美子さんのこと）

ロールモデルとする相手は、基本的に相手を深く尊敬し、自分の模範としたいという感情が湧き上がっているはずです。

それは自然とロールモデルを「善いもの」とみなすことに繋がり、ロールモデルの行動を真似してふりかえり、ロールモデルとの差異を見つけ、自然とロールモデルとする相手の行動の背景を考えていきます。その中で先ほどにも話した近接項と遠隔項の繋がりがわかっていき、暗黙化されて習熟につながっていくことになります。

真似をするにあたりロールモデルの行動を観察することになるのですが、いわゆるアジャイルの練度が比較的高い人は大抵の行動はとても自然に映ります。いとも簡単に。

そこには単一のプラクティスだけではなく、様々なプラクティスが組み合わさっていることも多く、1回観ただけではわかりませんので、わけがわからないなって感じることも少なくありません（私も何度もありました）。*3

真似をするということは、このプラクティスをやる、あのプラクティスをやる…というチェックリスト的な分割ができるものではなく、非分割的な活動を注意深く観察して見様見真似をすることになります。そういったわけのわからない中で自分なりに何度も解釈し直していくプロセスが、学習者自らのアジャイルの練度を上げることにつながっていくんじゃないかと私は思っています。

自身の解釈を脇に起き、見たままを真似する

ロールモデルを真似するのが大事だと思っている理由のもう一つに、自身の解釈から離れて相手の解釈に目が向きやすいのではないかと思っています。

先ほど自分が真似をしたいと思えるロールモデルとする相手の行動の背景を考えてくと書きました。

感覚的なものになってしまうのですが、相手の真似をする上では今までの自分の考えはいったん脇に置いて、心の中のカップを空にする必要があると思っています。*4

自分の考えで心の中のカップが一杯になっていると、自分のフィルターが掛かりまくった状態で相手の行動を見てしまい、見ながら自分なりの解釈しようとしてしまいます。

私はミーティング中に次に何をどう言うべきかで頭がいっぱいになってしまい、相手の会話がちゃんと入ってこないことがありますが、あれの感覚に近いと思っています（ついやってしまいます…）。

自分なりの解釈をしていけないというわけではなく、相手の行動を見た後で解釈をすれば良いです。相手の行動を観察するときは、自分の解釈を脇に置いて見ることに集中すること。そのあと、見様見真似を繰り返しながら、どうして相手はこのような行動をするのか、という自分なりの解釈を入れていく。

自分の解釈でありながら、それは相手の解釈に思いを馳せ、相手がその行動の中で大事にしている原則・価値を探る行為だと思っています。

最初は口癖でも良いと思います。その人の特徴的な口癖を真似をするのも立派な真似です。

口癖を真似る中で相手がどんな場面で言ったり、どんな背景で話しているかに自然と想いを馳せることになります。*5

ロールモデルが見つからない

とはいえ、いまの環境にそういう人が見つからないという人もいるかもしれません。

少しでも真似してみたいと思える人がいない場合、いくつかの選択肢があります。

書籍で探す
外のコミュニティで探す

私自身、アジャイルの始まりはカイゼン・ジャーニーという一冊の本からでした。

本の登場人物たちがやっていたことが善いと思い、真似してみて本のとおりの効果が得られるか。得られなかったら何がよくなかったかを考えながら実践していくことを繰り返していくことで、アジャイルの大切な価値観を少しずつ学んでいきました。

もちろん、生身の人から学べる多くの暗黙知が手に入りづらいという点はありますが、迷ったときはすぐに本を開いて戻って自身のペースで学ぶことができるのは強みです。

生身の人間という点では、勉強会などの外部のコミュニティで探すのもおすすめですが、定期的にその人の話ができる・聞けるように工夫は必要だと思います。

おわりに

ここまで書いてみましたが、そもそも私はなぜアジャイルが上達したいのか・練度を上げていきたいのかと、ふと思いました。

アジャイルな開発を実践することで得られる効果は色々とあると思いますが、私の現時点での回答としては、「現時点でアジャイルな開発を実践するほうが、ユーザーにとってより価値のあるプロダクトが届く可能性が上がる」「価値のあるプロダクトを届けて人の役に立ちたいという私自身の社会的欲求が満たされる可能性が高まるから」です。

そして、アジャイルな開発を実践していく延長線上に、私が「善いもの」と捉えていて、こうなりたいと思えるロールモデルが多くいるからです。

アジャイルは多くの開発現場に広まったと思いますが、私はあくまでエンジニアの生き方の一つだと考えています。

そもそもアジャイルかアジャイルじゃないか、というバイナリとして語れるものではなく、アジャイルな開発と言っている中には、弊社プロダクトチームみたいにペアプロもTDDもフルタイムで実践しているというのもあれば、ペアプロはやってないけどそれ以外やっている、TDDのみ取り入れいているよ、みたいな濃淡があります。

そうした色んな環境の中で自分にとって善いものを見つけて、それを探求していくことが大切なんじゃないかと思いました。