開発チームについて考えてアジャイルについて行動してみた | 書評『みんなでアジャイル ――変化に対応できる顧客中心組織のつくりかた』
TL;DR
- 『みんなでアジャイル ――変化に対応できる顧客中心組織のつくりかた』 を読んで、実際に現実の（渡しがいる）チームの問題について考えた
- 自分は、アジャイルのプラクティスについてなんとなく知っているが、実際に「アジャイルでのチーム開発」をやったことがない人間だった
- そんな人間にとって、「アジャイルとはそもそも何なのか？何だったのか？どうすれば現実にうまく適用できるのか？」を考えるきっかけをくれる良書だった。
『みんなでアジャイル ――変化に対応できる顧客中心組織のつくりかた』とは
この書籍は、2020年03月に、日本語訳版が発売された。この書籍の訳者である ryuzee さんは、fukabori.fm: 32. みんなでアジャイル w/ ryuzeeに出演して直接この書籍の内容について解説してくださっている。
著者の、Matt LeMayという方は、Sudden Compassの共同設立者兼パートナーであり、同社は、 「OUR CLIENTS」にある通り、American ExpressやSpotifyなどの組織の顧客中心主義を実践する支援をされている。
そんな著者の書いたこの書籍は次のように説明されている。
本書では、「顧客から始める」「早期から頻繁にコラボレーションする」「不確実性を計画する」をアジャイルの3つの原則とし、この原則を組織で共有し実践していく方法とその課題を解説します。原則を素早く実現するためのアイデアや方法、原則が適用できているかを確認する方法とうまくいかない場合の対応法などを紹介します。 アジャイルの原則を理解してゴールを定め（目標）、自分たちにあったアジャイルプラクティスを見つけ（方法）、現実的な成果をもたらしているかを計測し（成果）、これらを見直しながら繰り返すことでアジャイルを継続的に強化する方法を解説します。またワークシートを用意しており、自分の環境に照らし合わせて考えることができます。 https://www.oreilly.co.jp/books/9784873119090/
つまり、この書籍は アジャイルの原則を組織で共有しいかに実践するか、それに至るまで・実践する際の課題について解説したものだ。読者として読んだ感想としては、「プランニングポーカー」とか「イテレーション」とか、個別具体的な方法というよりかは、その考え方・仕事の仕方としてのアジャイルをどう捉えて実践するかに焦点を当てている。
また、リーン開発・デザイン思考との比較についての言及しているため、近い概念との境界・輪郭をよりはっきりさせてくれる。
リーン開発やデザイ ン思考は事業企画フェーズ、アジャイルは設計から実装を経てのリリースまで のフェーズ、DevOpsは実装後期から運用のフェーズ。もちろんオーバーラップ する時期もあるが、大きく分けるとこのようなフェーズごとのアプローチと解釈できよう。 本書では、これらに別の解釈も加える。リーン開発は効率性（投資効果の最大 化）を目的とし、アジャイルは迅速性を高めることを目的とし、デザイン思考は ユーザービリティ（使い勝手）を目的とする、と筆者は定義する。
「みんなでアジャイル」 まえ書き
自分は、何らかチーム開発のプラクティスを実践することについて、たしか2年前くらいから考えていた。しかし、アジャイルでのチーム開発をやったことがある人達の話を聞くと、「うまくいった」・「うまくいかなかった」という両極端の意見を聞くことが多く、とても戸惑っていた。
そもそも「アジャイルはうまくいく・いかない」という次元の手法の話なんだっけっていう疑問を持っていたが、それに対してうまく理解を落とし込む機会がなかった。しかし、この書籍は私のこの疑問に明快な言葉で説明してくれました。
以降、書籍を読んで自分が引っかかったこと・学んだこと・考えたことを記していきます。
アジャイルソフトウェア開発宣言
アジャイルムーブメントの始まりは、History: The Agile Manifestoにて知ることができる。
On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground—and of course, to eat.
スノーバードというリゾート地にて集まった17人が合意し、共有しようとした価値観は次の短い文章に集約されている。
ここには一切の手法・ツール・プラクティスのことが言及されていない。本書籍でもこのことを重要だと主張しており、アジャイルを単に「手法」と呼称していることについて次にように語っている。
そのため私は、アジャイルが単に「手法」と呼ばれているのを聞くたびに少し 苛立つ。そう、たくさんの手法があるのだ。前述したスクラムやエクストリー ムプログラミング、クリスタルもそうだし、最近開発されたSAFeやLeSSもそ うだ。アジャイルの価値観を実践に移すための青写真を提供してくれる手法は 多い。だが、アジャイルをプロセスやツールとして定義することがなぜ的外れ なのか、それを理解するためにアジャイルソフトウェア開発宣言の 208 文字を そこまで目を凝らして見る必要はない。
1.1 ムーブメントとしてのアジャイルを理解する
ムーブメントとしてのアジャイル
実際に、読んでいくと、この書籍は、アジャイルをつぎの2つに分類している
その上で、それらを連携させる「ムーブメントとしてのアジャイル」を提唱している。手法としてのアジャイルはプラクティスに重点がおかれており、マインドとしてのアジャイルはマインドセットに重点が置かれる。それに対して、ムーブメントとしてのアジャイルとは、マインドセットとプラクティスは容赦なくつなっがっている状態を目指すものである。
ムーブメントとしてのアジャイルでは、アジャイルの原則とプラクティスを明確にし、自分たちにどう適用するかを積極的に決定する、という役割が自身に求められる。言い換えると、他人が決めた価値・原則・プラクティスに従うという受動的な役割ではないことを、この言葉は示している。
そのため、思考と行動の双方に高い基準が求められ、新しい考え方と新しい働き方を必要とする。
脱線 概念が浸透していくプロセス
昨今、「流行っている」DDDなどを見ても同様に、戦術面にフォーカスがあたっている、いわゆるプラクティスに重点が置かれている状態から、（月並みな表現になるが）ビジネスに向けることといったマインドセットに重点が置かれるべきだと主張され、それらは一気通貫してマインドセットとプラクティスがつながるムーブメントとして捉える認識が広がっていく、といったふうな流れがあるように感じる。
なにか概念が広がっていくプロセスというのは、HOW的なプラクティスが注目され、なぜやるのか・その理由はなにかといったWHYに注目するように揺り戻され、最終的にWHY-HOWが一連の思考の枠組として理解される流れを踏んでいくものなのかもしれない。
スクラムやXP、LeSS、SAFeとアジャイル
正直、この辺がそれぞれお互いにどのような輪郭を持って捉えるべきなのか時系列がいまいちわかっていなかったが、歴史的経緯について非常に理解できた。
アジャイルの誕生は、たとえば印象派の芸術運動のように、何人かの実践者が独立しながら同時進行するイノベーションのもとで生まれたものである。書籍内に紹介されている通り、かんたんな年表にすると、次のように整理できる。
自分たちの北極星を見つけること
この表現は、自分が所属企業のチームで実践するに当たり、非常に気に入って使わせていただいている。自分たちの北極星という表現は、この書籍の訳者である ryuzee さんが出演したpodcast fukabori.fm: 32. みんなでアジャイル w/ ryuzeeにて肉声で説明いただいたのが一番分かりやすかったが、自分は、季節が移り変わっても北極星の位置が変わらないように、状況が変わり時間が立っても変わらない自分たちが大事にしたい・目指したい目標と理解した。
言われてみれば言語フレームワーク等の技術選定をする際には至極当たり前の思考プロセスとして、「なにか課題なのか？」・「どのようなソフトウェアを目指したいのか？」という問いが一番最初に来るのに、それがチーム論・組織論では例外なはずがない。
書籍では、自分たちの現状を厳しくみることの重要性や、仕事のやり方をちょっと変える参考の方法にするだけではあまり効果がない、ことについて指摘している。
成功するアジャイルの適用は、常に厳しく正直に現状を見ることから始まる。 何がうまくいっていて、何がうまくいっていないのか。アジャイルを今の仕事 のやり方をちょっと変えるだけのことと思っているなら、アジャイルから得られ るメリットもちょっとだけになるだろう。今のやり方を選んだ元になっている現
2章 自分たちの北極星を見つける
これらについて フレームワークの罠 と表現しているが、それを回避するためには次の2つのステップを経る必要を説いている。
- チームや組織がどうなりたいか、そして何がそれを妨げているかを正直に 厳しく見ること
- チームや組織が掲げられたゴールにたどり着くために従う必要のあるア ジャイルの原則を選ぶ（必要なら特殊化する）こと
これは、アジャイル云々関係なく、物事全般的に言えることであり、あらゆる場所で思い出していきたい。
脱線：自分たちの北極星はどこだろう
もともと、自分自身この書籍を手にとった理由として、開発チームとしてどこに向かえばより「生き生き」と仕事できるのか、という点について漠然とした課題があった背景がある。 どういう景色かというと、だいたい全体で150人くらいの規模のサービス会社の50人弱のエンジニア組織の中で、他チームからの協力も含めピザを囲んで食べれる規模の小さなチームにいる。
そこでは、良くも悪くも個人技の集積で絶妙なバランスで顧客に対する成果となるサービス・機能を提供・運用できていた。しかし、プロジェクトの関係者の増加・期間の大きいもの、並行で考える開発プロジェクトの増加、マーケティング施策の実現やCustomer Supportからの問い合わせに迅速に対応していくこと、などが求められる中で、個人の力の集積ではなくチームとしてどう成果を出していけるか、を考える必要を感じていた。
「遠くに行くにはみんなでいけ」的な言葉があるが、月並みな表現をすると「俺たち今日もいい仕事ができるな！ちゃんと世界に価値を発揮できてるぞ！」 と言いたいぞっていう具合だった。
どうやっていきたい？っていうの実際にzoomで話したりした結果、この課題感が「アジャイル的な表現」なのかと問われると、正直わからないが、次のようになった。
1. メンバー: 個々人の達成感 2. チーム全体: 関係各所との「約束」を守る そのために、進行において優先度高く取り組んでいきたいことは以下です。 個々人の納得感と達成感のあるマイルストーン と 重要マイルストーンに対するブレークダウンと見積もりの継続的評価
表現としては、「顧客中心」な表現とは言えないが、サービスを提供する顧客にしっかり価値を提供する、ことに対してブレークダウンしたお気持ちではある（※ 「北極星は変わらない」が、チーム内の宣言文は、より適した形でリライトされ続ける気がする）。
スプリントでの作業
アジャイル手法全体を一つのプラクティスに集約する一つの表現を書籍では、「タイムボックス化したイテレーションで作業すること」と表現していた。「スプリント」という表現がより聞き馴染みがあるかもしれない。
顧客ニーズに基づいて作業に優先順位をつけ一定期間のスプリントを実施する。スプリント後にフィードバックを得て、次のスプリントのて作業に優先順位をつける。短い期間で顧客のフィードバックを受けるフィードバックループを回すことが顧客中心主義となるヒントだ。
ここでいう「顧客」って誰になるんだっけ、を考える
自分はサービス会社にいるので、その文脈での確認になるが、自分自身のいる開発チームの動き方は大きく２種類のことを同時並行で行っている。
- 新規機能の開発
- 既存機能の改善・保守
「2. 既存機能の改善・保守」については、例えば2weekのsprintで顧客に届ける価値はそのまま本番にリリースして、顧客に使ってもらい、その後の反応をフィードバックとして得られれば次の計画に活かせるのでイメージが付きやすい。
「1. 新規機能の開発」については、2weekにおける顧客フィードバックを得るための顧客は、プロジェクトオーナーということだろうか。実際にプロジェクトオーナーと動くものを持って話すと「この機能はこうしたい」といったフィードバックが得られるので、そういうことなんだよな？
更に具体的なタスクレベルにブレークダウンしたときに、例えば、2weekで「backendのAPIを用意します」・「infra環境を作ります」といった場合は？それについてもプロジェクトオーナーと合意し、その成果について確認・説明すると、プロジェクト状況や「こういうことは対応してますか？」といった会話ができそうか。
実際の組織における課題「組織重力の3つの法則 」
ムーブメントとしてのアジャイルを実践するにしても、現実の組織は、変えることが難しいことがある。「従来の仕事の仕方」に人をつなぎとめておく力は、重力と同じように広範囲に及ぶ。筆者はそれを「組織重力の３つの法則」と呼んでいる。普段漠然と感じて考えていたことが明快な言葉で説明されていて腹落ちの度合いがすごかった。具体的には次の3つをあげている。
● 組織の個人は、日々の責任ややる気を伴わない場合、顧客対応を避ける。 ● 組織の個人は、自分のチームやサイロの居心地のよさのなかでいちばん簡単に完了できる仕事を優先する。 ● 進行中のプロジェクトは、プロジェクトを承認した最上位者の決定がない限り続く。
1章「アジャイル」とは何か？なぜ重要なのか
1. 組織の個人は、日々の責任ややる気を伴わない場合、顧客対応を避ける。
これについては、個人レベルでの組織レベルでも、心当たりがある事象だと感じた。自分のKPIや成果に焦点がいってしまい問い合わせ対応などの顧客対応の優先度が下がってしまう事象は、様々な要因で発生するように見える。
もちろん自身のKPIなるものを「全く達成できませんでした」とは言えないが、一方でサービス会社だと24時間365日サービスは顧客に使われ、そのサービスに何らか不具合や不明点があった場合には、顧客へ価値が届けられず、サービス業態によってはその人の重要な生計の流れが止まってしまう可能性がある。
「日々の責任」・「やる気」というバラメータは、それらの優先度を上げるかどうかについて、大きなバラメータになるし、組織・チームレベルでもそこに対する評価に対して一貫性が取れていない状態が危険っていうのはそうだなと。
サービス会社における「顧客対応」はタイムボックス内の計画でどう扱う？
これって、スプリント計画には当初入ってない "差し込み" タスクになると思うが、これについてどのように扱っていることが多いのだろうか。これを単に "差し込み" として扱って、スプリントレビューで「なんか成果出てなくない？」ってなるのは明らかに「顧客中心主義」の価値観とは違うよね。
これをどう扱うと、顧客対応に対して積極的であり続けて、かつチームとしてもそれを「いいじゃん！かっこいいなお前！価値出したな！」とわいわいできるんだろうか、というところに興味がある。
現時点の扱い方では、顧客対応ができた場合は、その難易度に応じた「ストーリーポイント」をつけて、当該スプリントで実施したissueに追加する、というふうにして、カンバン上で可視化している。
2. 組織の個人は、自分のチームやサイロの居心地のよさのなかでいちばん簡単に完了できる仕事を優先する。
うーあるわ〜（激しく首を縦に振りながら）だった。自分がすぐにイメージしたのは、例えばバックエンド領域のチームが、その他のレイヤ（フロントエンド・インフラ）を扱うために調整が必要なことをさけてむりやりバックエンドのレイヤだけで完結しようとする事象を思い立った（例えば、監視SaaSを使えばより運用上の有益なところに調整を嫌ってバックエンドの実装でそれを代用したり）。
後は、純粋に利害関係者が増えるとそれだけ多種多様な意見が出て、ソフトウェア開発者があんまり好きじゃないような組織間調整的なものが発生したりすると、億劫になってさけちゃいますよね。
後者については組織の文化や目指す先やプロダクトについての共通価値観の情勢などが影響するのだろうけど、前者はこの重量があるからこそ、可能な限り機能横断的である方がいいよな、と思っている。
着々と機能横断型の開発チームになりつつあるものの、その量に対して捌ききれなくなってきたので、事業をすすめるためにチーム開発力を云々でアジャイル／スクラムに関心が行くようになり、効率化するためにUI接点の見せ方なりシステム運用監視の整備のインセンティブが目に見える方になってきた
— Kazuki Higashiguchi (@hgsgtk) April 30, 2020
後記
アジャイルをやろうとしているにしても、やらないにしても、この書籍は非常に一般的な組織的な課題について語っているので、自分の景色を分析するための思考の枠組みとして、いい材料になった。
この書籍を読んだからこそ、「やっぱりチーム課題を考えよう」と重い腰を上げるきっかけになった。なんらか漠然とした課題・もやもや感を感じている状況の方は、『みんなでアジャイル ――変化に対応できる顧客中心組織のつくりかた』、ぜひ手に取ることをおすすめします。
