『Clean Agile 基本に立ち戻れ』一人感想戦

hgsgtk

2020/10/03 に出版されました。『Clean Agile 基本に立ち戻れ』が出版されました。これは、Robert C. Martin氏（愛称：ボブおじさん）の"Clean"シリーズの四冊目となる『Clean Agile: Back to Basics (Robert C. Martin Series)』の日本語訳版。

Robert C. Martin氏は、アジャイルについての実践を考えた人であれば必ず見たことがあるであろう、アジャイルソフトウェア宣言に署名した一人だ。

そんな著者が、アジャイルについて「基本に立ち戻れ」とサブタイトルにある通り、アジャイルとはなにか、について始まりの歴史から、軽快な語口で話を展開する。

アジャイルとは、小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイデアである。アジャイルとは、大きなことをしている大きなプログラミングチームの大きな問題を扱う大きなアイデアではない。
大きなことは大きなチームなんかじゃできない。小さなことをする小さなチームがいくつも集まり、コラボレーションしながら大きなことを成し遂げるのだ。
このことを、我々はあらためて認識する必要がある。（https://www.amazon.co.jp/dp/B08KRHDS84 より）

分量はそこまで多くなくて、たまの出社の電車の中や、ちょっと朝早く起きた数時間で、楽しく読めた。

読んでいて、ちょっと頭の中でめぐらした考えの発展を、備忘録としてメモしていく。

※ 長々と書いているが要約というよりかは本当にただ思ったことをいちいち突っかかって感想・考察を書いているので70%くらいは個人的な解釈を書き連ねています。

アジャイルとは、小さなプログラミングチームの小さな問題を扱う小さなアイデアである

はじめに、こういったメッセージがある。

アジャイルとは、小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイデアである。アジャイルとは、大きなことをしている大きなプログラミングチームの大きな問題を扱う大きなアイデアではない。

アジャイルについての情報を仕入れている方だと、「じゃあ、LeSSとかSAFeとかは？」ってなるが、著者はこれらのアイデアを否定しているわけではない。ただ、オリジナルのアジャイルのメッセージではない、ということを主張している。オリジナルのアジャイルのメッセージを発した人だから言えることで力強いですね。

実際、最後の方まで読みすすめると、大規模なアジャイルについて評価は、あくまで自身の考えに過ぎないことを強調している。大規模アジャイルについての著者の書きっぷりは正直で面白いので是非手にとって読んでほしい。すごく失礼な表現をすると「かわいいおじさんだなw」と思いましたはい。

アジャイルのソフトウェア以外に関する適用についても、オリジナルの出発点にいたRobおじさんだからこその主張が見て取れる。

アジャイルの歴史は 5 万年以上前から

いつからアジャイルが使われ始めたかについて、著者は 5 万年以上前からだといっている。お互いに協力して、共通の目標を達成する、という行為を指す。

ソフトウェアにおけるアジャイルの利用については、アラン・チューリングの 1936 年論文執筆の様子や、1946年 ACE(Automatic Computing Engine)の最初のコードがそうだったんじゃない？っていう話を展開している。そして、初期のソフトウェア開発は現代のアジャイルのような振る舞いだったようだ。そして、その後科学的管理法に代表されるティーラー主義についてのかんたんな補足が入る。

Fumihiko Kinoshita さんが発表されていた、近代史とアジャイルの発表に近い感覚のものがあるなとおもった。

ウォーターフォールの出自

これずっと気になっていたのです。アジャイルやXPの生まれの前史は、クリストファー・アレグザンダーのアレコレを学んでいると、いろいろわかるのだけど、ウォーターフォールって言われの始まりはどこかなってところ。

「ウォーターフォール」という言葉がどのように広まったかは定かではない。だが、その起源はWinston Royceの論文とされており、以下の図を参照することが多い。

画像1

この論文は（滝のようにタスクが流れ落ちていく形状から）ウォーターフォールの考えの起源であると広く認知されている。だが、「ウォーターフォール」という言葉は、この論文には登場しない。この名前が後にどのように登場したかは定かではない。

「ウォーターフォール」を提示した論文ではなかったというところが、おもしろいなとおもったところですね。視覚的にわかりやすいものがただ間違って広まってしまう歴史の怖い点ですよね。

最近だと、「k8sでDocker非推奨」みたいなタイトルだけろくに中身を見られずに広まっていくといったことがあったけど、歴史は繰り返しされ続けるし「もう所詮その程度のことで躓くのが人なんだ」くらいという現実認識のほうがいいのかもしれないですね。

スノーバートでの「アジャイル開発宣言」

この書籍の中で一番臨場感があり当事者しか書けない内容だとおもったのはこの章だった。当時の背景・経緯・様子が当時の体験を持って語られている。主催者はRobおじさんだったんだな。この章についてはなにかメモしておくというよりかは定期的に読み返して追体験し直すくらい価値のあるのストーリーだと思った。

「個人と対話」「動くソフトウェア」「顧客との協調」「変化への対応」という 4つの価値が特定された。部屋の前にはホワイトボードがあり、誰かがそこに4つの価値を書いた。そして、これらは好ましいものだが、「プロセスやツール」「ドキュメント」「契約交渉」「計画」の価値を置き換えるものではなく、補完するものであるというすばらしい考えを述べた。

「アジャイルではドキュメントは〜」みたいな話もこの章読んだら理解がもう少しオリジナルなものによるんじゃないかな。

「アジャイルプロセスに固まっちゃってると〜」みたいな一般的なそれらにたいする懸念みたいなのがあるが、おそらくそういう人がいたんだろうが、その体験だけ記憶に残って考え方が危惧に囚われて前に進まず、アップデートされない当人の世界観が1番かわいそうだなって常々（脱線した）。この本読んでほしい。

鉄十字

ソフトウェアプロジェクトには、基本的な物理的法則があることをまず理解することを説く。

マネージャーがソフトウェアプロジェクトの基本的な物理法則を理解していないからである。この物理法則があるために、あらゆるプロジェクトは鉄十字と呼ばれるプロジェクトマネジメントのトレードオフに従わなければいけない。つまり「品質」「速度」「費用」「完成」のうち、好きな3つを選べる。

鉄のトライアングルなんて読んでるものもありますよね。

なお、たしか『アジャイル見積もり』本にて、アジャイルの三種の神器なんかもこの概念の説明として提示してた記憶があったのだが検索結果とは一致しなかったので違うんだと気がついた。

アジャイルの三種の神器ってVCS, BTS, CIなんですね。ここ別の概念とごっちゃになってたなぁ。

そして、これらの鉄十字のそれぞれには係数がありアジャイルはこれらの係数をコントロールすることを可能にしようとしている。

このように開発者・マネージャーのプロジェクトマネジメントに重点を当てているため筆者はこのように説く。

アジャイルとは開発者やマネージャーが実践的なプロジェクトマネジメントをすることを支援するフレームワークであることを理解してくれたと思う。

フレームワークであるということは一つ示唆に富んだ表現だと思う。「アジャイルであること」といった文化的側面が強調されることが多いし、実際に文化なくしてアジャイルが機能することも難しいと思っている。次のブログポストで言うところの「レフトウィング」と言える。

一方で、チーム文化と開発環境を内包したプロジェクトマネジメントフレームワークと捉えると、フレームワークとの付き合い方を考えねばならない。自身は『みんアジャ』を読んで「アジャイル開発をやろうとするのではなく自身の組織状況に目を向けて分析して結果なにが求められているのかを導き出す」思考に非常に共鳴しチーム文化のアレコレを考えた経緯がある。

​「アジャイル開発がやりたいわけじゃない」と当初よく口に出していたが、この感覚はなにかな〜と振り返ると「フレームワークを採用したいんじゃなくて課題解決のために取りうる手段としてアジャイル開発というフレームワークがどうかを考えたい」ということだったのではないかな、と理解した。

フィードバック駆動の開発

フィードバック駆動の開発という表現をしている。しかし、自分が特筆してなるほどなと思った点がこれだ。

アジャイルソフトウェア開発を実施する理由のひとつは、プロジェクトの成果を可能な限り高めるために、鉄十字の係数を設定するマネージャーに必要なデータを提供することである。

バーンダウンチャートの章でこの言葉が出てきた。これについて重要だと思ったことはプロジェクトの鉄十字の係数調整のためのデータを提供することだ、というもの。

アジャイルによって製品自体の形について、顧客に動作するソフトウェアを提示することで継続的フィードバックを受ける、ということを重視することがフォーカスされる。実際、目標の不確実性をコントロールするためにそれを抜きにしたプロダクト開発は多かれ少なかれ難しい現状があるだろう。そのための仕掛けとしてスプリントレビューといったイベントやバーティカルスライスなユーザーストーリーといった切り口が用意されている（と理解している）。

しかし、それだけではなくソフトウェアプロジェクトにおけるマネージャーに対するデータ提供を通じた継続的フィードバックのリズムを生み出すという視点は、あまり取り上げられることがなかったように感じるので覚えておこう。

後にイテレーションの運営について説明されるが、たとえ20ptのストーリーポイントを計画して18ptだったとしてもそれは決してイテレーションが失敗したわけではないと強調している。アジャイルは希望マネージメントを行うという視点が本書では出るが、実測値として事実がスコープ及びスケジュールを調整するマネージャーにデータ提供できた時点でイテレーションは成功していると解釈するものとしている。

イテレーションゼロ

これはもともと現場でも使っている言葉。勝手にカスタマイズして「スプリントゼロ」という表現をしている。

最初のイテレーションはイテレーションゼロとも呼ばれる。イテレーションゼロでは、ストーリーで構成された短い機能リストを作成する。（中略）また、イテレーションゼロでは、開発環境の設定、ストーリーの見積り、初期計画の策定などを行う。

『More Effective Agile』ではアジャイルの境界線という言葉を使いフィードバック駆動な開発リズムとそうではない領域について境界を設ける考え方を示していた。

自身の現場でも状況によって全てイテレーションでスプリントレビューといったプロダクトレビューするようなリズムを作れるかというと、現実問題他社との関係の中で「要件定義フェーズ」が必要になることがある。これについて、イテレーションゼロの前段階で行うことをフェーズ分けてじっくりやっているという解釈になるので、そのフェーズについては明確に違うものとして捉えられるように「スプリントゼロ」と読んでたりする。これがいいやり方なのかというある意味仕損を生みやすい危うさを伴うため、積極的に使う手ではないとも思ってるが、現実との兼ね合い。

ストーリーを作成し、見積もり、計画し、設計するプロセスは、停止することがない。

これはもちろんそうだなと思う。たとえ最初に時間をとって要件を見定め見積精度をあげるにしても、プロジェクト全体で見積・計画・設計は続いていくので、適切にプロジェクト内での決定の遅延を行うことが肝要だろうと思う。

希望マネージメント

この表現が面白かった。

この希望の喪失がアジャイルのゴールだ。希望がプロジェクトを殺す前に、アジャイルで希望を破壊するのである。（中略）アジャイルは速く進むことだと思っている人もいる。だが、そうではない。これまでそうだったこともない。アジャイルとは、どれだけうまくいっていないかをできるだけ早く知ることだ。

希望がプロジェクトを破壊する、面白い表現。実際イテレーションの中で得られた実測データが見積もりの推測値に対する誤差を示し、それによって現実的なスケジュールが明らかになってくる。

アジャイルの実践をしていくと分かるが、それによってプロジェクト進行が早くなるかというと実際そうではないと思う。「蓋を開けたら全然進んでない」という状況にならずイテレーションごとにPOと会話し頻繁に期待値の調整ができる点にある。イテレーションごとに明らかになる実測データは「ブラックボックスの蓋がずっと空いてて見れる」状態を作れていると思う。

鉄十字マネージメント

よくアジャイルではリリース日は最初から決められないものだと主張する人がいるが、半分あっていて半分間違いだと思っている。

筆者は鉄十字マネージメントにおけるスケジュールの操作について次のように語っている。

まずは、スケジュールから始めよう。ステークホルダーに納期を11月1日から3月1日に延期できないかと聞いてみよう。おそらくダメと言われるだろう。この日付はビジネス上の正当な理由から選ばれたものだった。ビジネス上の理由は高い確率で変更できない。したがって、納期の延期はビジネスが何らかの大きな打撃を受けることを意味する。

この話に続いて仮ぎめされた日付なら伸ばせるかもしれないという但書は続くが、筆者はとても現実を見ていると思う。この現実感からも「アジャイルはリリース日は決められない」は、ビジネス上それが最優先の場合決められざるを得ない状況について言及している点から、間違えた理解であるとわかるだろう。

だからこその鉄十字マネージメントであり、それ以外の変数「スタッフ」・「クオリティ」・「スコープ」をコントロールするという視点につながってくる。

実測データをもとに鉄十字のなかで操作可能変数を調整するのであり、スコープが第一義なのであればスケジュールは分からないというのが解釈としてより有用な理解だと思う。

なお、スタッフについてはブルックスの法則、クオリティについては次の厳しい言葉で読者に戒めを与えている。

がらくたを作っても速くはならない。逆に遅くなってしまう。プログラマーを20〜30年続けた教訓が、まさにこれだ。速くて汚いものなどない。汚いものはすべて遅いのだ。 速く進む唯一の方法は、うまく進むことである。 したがって、クオリティは最大にしよう。スケジュールを短縮したければ、クオリティを上げるしかない。

コードレビューやリファクタリングの話をしているので内容としては内部品質について言及したものだ。t-wadaさんの『質とスピード』では数々の調査・レポートによって明らかになった内部品質とスピードの関係性を言語化している。

クオリティ自体の操作すること自体が逆効果であることはもう明らかになっていることが示されている。

さらに後ほど、ケントベックらがまとめた顧客と開発者の権利章典の中では、「アジャイルは事前計画をしない」という主張の誤りについても顧客の権利から逆算して説得力を持って説明している。ビジネスには計画が必要であり計画には納期とコストが含まれ、それらには実用に足りうる正確さを伴う見積もりが必要であるという点だ。

もちろん事前に予測して正確なものを作り出すことは無理だということは「ウォーターフォール」を実践し痛い目を見てきた歴史が証明している。それ故にアジャイルの考え方は「やってみないとわからない」ことについて不確実性を実測値をスケジュールに反映していく。

顧客に完全に固定されたスコープと納期の両方は約束できないが、確率ベースの納期とコストを知る権利をケントベックらがまとめた権利章典では顧客の権利として保証していると理解できると思う。

アジャイルとはつまり

筆者はこう締めくくっている。

上空2万フィート（約6キロ）から見たアジャイルだ。多くの詳細が失われている。だが、重要なところは押さえてある。アジャイルとは、プロジェクトをイテレーションに分割するプロセスだ。各イテレーションのアウトプットを計測して、スケジュールを継続的に評価する。最も価値のあるものが最初に実装されるように、ビジネス価値の順番で機能を実装していく。クオリティは可能な限り高める。スケジュールはスコープの調整によって管理する。

そういえば、『ユースケース駆動開発』でも上空2万フィートから見るがどうして上空2万フィートから見たがるのかな？

さらに、後述するが特にろぶおじさんの関心はプロフェッショナルリズムだ。アジャイルについて、

プロフェッショナルなソフトウェア開発を支える規律のフレームワークだ

と示している。開発プロセスやルールに焦点があたりがちだが、重要なことは倫理的開発の土台となる権利・期待・倫理の一式を指している点を大事にするべきであろう。

これについて思うことは、人に説明するとき、あるいは説明されるときにこういった権利・期待・倫理感といった点はきれいさっぱり捨象されてしまうことあるよなぁと感じている。このような規律は内部コンセンサスとして開発者の中で暗黙知として息づくがあくまでブラックボックスとなり外から見えないためこのような考え方がインプットされていない状況の場合、アジャイルはプロセス論に終止してしまう。

これがどういうときに厄介になるかというと、自チームはいいとして他チームが「真似してやってみよう」となったときにプロセスだけ取り入れてしまう点だと思う。まぁこの難しさがあるから文化面からトレーニングするアジャイルトレーナーといった人のニーズがあるのだろうなとも思う。

サークルオブライフ

この内容が一番個人的にいろいろためになった。物事を整理するための概念図を手に入れた感覚である。本書はXP入門という位置づけもできるくらいXPについて多く語っている。

本書ではXPのプラクティスを選択した。すべてのアジャイルプロセスのなかで、XPが最も適切に定義され、最も完全で、最も混乱が少ないからだ。すべてのアジャイルプロセスは、XPのサブセットまたはバリエーションと言えるだろう。

このサークルオブライフに基づいて様々な概念を整理している。例えばスクラムは一番外側の円にフォーカスしたものであるといった整理を進めている。

「サークルオブライフ」は3つのリングに分割できる。最も外側にあるのが、ビジネス向けのXPのプラクティスだ。これはスクラム＊27のプロセスに相当する。これらのプラクティスは、ソフトウェア開発チームがビジネス側とコミュニケーションするためのフレームワークと、ビジネス側と開発チームの両方がプロジェクトをマネジメントするための原則を提供している。

世の中のプラクティスがおもにどこに着目したものなのかという視点で見ると面白い。

ちなみに、自チームでは開発の中で得られた経験を振り返り「自分たちにとって有用だったギミックや考え方」をプラクティスとしてまとめている。このギミックについてサークルオブライフの観点で分類することが有用かチームで思考実験したことがあった。その時の結論としては「分類しない」という結果が得られた。自チームは自分たちが作ってそれを自分たちで面倒見続ける事業会社内のフルサイクル開発者のチームとして己たちを定義している。ビジネスとテクニカルがかなり密接に結び付けられているため、あえてこれらを分ける必要はないだろうという洞察が得られた。この思考実験でおもしろいと個人的に思っているのは「より一般化されたフレームワーク」と「特殊化された一つの現場」で取るべき考え方・スタンスは違うという至極当たり前な点が、概念の整理の仕方にも現れるという点だった。

ちょっとスタンスの違いで面白いなと思っているのは『More Effective Agile』の著者は効果的なアジャイルの始め方はスクラムからやることだ、としていることだ。

アジャイルをまだ実践していない、あるいは実践しているが思ったほど効果が出ていないという場合は、出発点に戻ることをお勧めする。アジャイルでは、スクラムから始めることを指す。スクラムはアジャイルアプローチの中でも最も規律的である。 / Steve McConnell. More Effective Agile ソフトウェアリーダーになるための28の道標 (Japanese Edition) (Kindle Locations 914-916). Kindle Edition.

間違った理解と方法でやるなら一回最小限を兼ね備えたスクラムのプロセスを使って使っていくうちに理解していけ、という主張だと理解しているが、おそらく「最小」の範囲をどこに置くかという点で彼らは微妙に主張が違うのかなと解釈した（が有識者の方々はこの辺の違いをどう捉えているのかはちょっと興味がある）。

一応補足では初期のスクラムについて言及している事を但し書きしていた。なので『More Effective Agile』の著者が取り上げているのはXPを多く吸収したスクラムの姿について言及しているものと言えるかもしれない。

少なくともスクラムが考案されたときはそうだった。現在のスクラムは、XPのプラクティスの多くを吸収している。

プロフェッショナリズム

筆者のRobおじさんはインタビュー動画でも言及していたが、ソフトウェアエンジニアとしてのプロフェッショナルのあり方について長年関心を寄せ研究されている方のように感じている。

アジャイルについてもプロフェッショナルをもたらすものだと評価されていた。TDDやペアプログラミング、シンプルな設計等それぞれのプラクティスはプロフェッショナルをもたらす「約束とコミットメント」だと。クラピカの制約と誓約みたいな。

その背景としてソフトウェアが世の中になくてはならないものとなっており、人命すらも握る重要なものになった今、ごみのようなソフトウェアをリリースするわけにはいかないという強い使命感と課題感を感じた。それについて筆者はいくつかおすすめな書籍を紹介していたので追って読んでみたい。

こう、目の前の自分よりももっと大きい全体に対して課題感と使命感を持って動こうとする人にはとても敬意と憧れと「自分もそう動いていきたい」と度々思う。世界はtwitterランドで様々人間〜といったある意味失望するようなことが多いけれど、それでもより良い世界にすることを使命感にエネルギー持ってフォースを働きかけていく姿はかっこいい。

イテレーションごとに技術的にデプロイ可能

イテレーションで開発したもの、スクラムではインクリメントと表現しているものは、ビジネス判断でリリースしない可能性はあるにしても技術的にはデプロイ可能な状態とするもの。実際に毎イテレーションリリース可能なものを作らないといけないわけではないと『アジャイル見積り』本では説明していたりするが、ここの判断軸が明らかな表現として示されている。

つまり、開発者視点ではなくビジネスオーナー、プロダクトオーナー視点での「リリースしない」という判断を委ねる、委ねられる状況を作ることをイテレーションで求めるものとなる。

個人的にはここに最近の関心が強い。開発者視点でデプロイ可能なものを作るにあたって、開発者はビジネスロジックだけでなく、デザイナーもいてUIプログラミングも含み、テスター視点でのスクリプトテスト（ここは自動化の大いなる余地がある）・探索テストなどをクリアし、内部統制やセキュリティ観点での脆弱性の有無なども関心に入ってくる。

DevSecOpsやQAエンジニアがイテレーションに入っていくという開発プロセスについては、mercariさんの次の記事たちが記憶に新しい。

もちろん、DevOpsとアジャイル開発は概念とは違うしこれらを混同してDevOpsイコールアジャイル開発などとは全く思っていないが、イテレーションで開発者視点でのデプロイ可能な成果物を作るためには、CIやテスティングなど組織的・テクニカルプラクティスにて重なり合うものがあると思っている。開発者視点でデプロイ可能なものを作るという領域は奥が深く広大だ。

テスティングマニフェストで、開発者全員が品質に対して責任を持つという文化を示している。

そのためにテストピラミッドの土台となるユニットテストをTDDという規律を持って作っていくことが求められる。まぁそこまでは特筆して「難しい」話ではないと思っているが、さらにそこからcheckingではなくtestingの視点で検査された開発物を生み出すためには組織論についても自然と考察が必要になるし、デザインクオリティを高めようとなるとプログラミングを行う開発者だけでは気がつきにくい「探索的視点」があるため、自己組織化された組織とそのなかのネットワーキングプロセスの考察につながっていく。

とりあえずまずはテストピラミッドの上に登りアジャイルのテストの四象限のカバー範囲を広げていく意味で、Agile Testingの一つの有効なプラクティスとされるATDDにようやく歩みを進めていこうとしているのが自信の現在地点。

なお、この点についてはイテレーション運営においてQAが受け入れテストを（できれば開発者とともに）準備してストーリーを完成させることについて言及している。受け入れテストが書かれることがストーリーの準備完了であるため、開発者とQAのチーム構成が適切であることも必要になる。

3点見積もり

ビジネスプラクティスの一つとして計画ゲームをあげており、見積もりがそもそも推測であるがゆえに正確性と見積もりコストとのトレードオフ関係にある点等を示している。最強に正確な見積もりをするならばコード一行レベルまでブレークダウンして見積ればいいがそもそも期待されている見積もりはそういう手を動かさぬ状態でビジネス計画として用いたいものだ。

その際に3点見積もりというプラクティスが紹介されていた。これは直近の現場の課題でも使える方法だと思ったので取り入れていきたい。

三点見積りとは、プロジェクトの作業時間や、その作業の金額を楽観値、最可能値、悲観値の三点から見積もる手法のことです。
「三点見積り」とも、「三点見積法」とも呼ばれます。
冷戦期にロッキード社がアメリカ海軍の潜水艦発射弾道ミサイル・ポラリスを開発するプロジェクトでPERT法ととも三点見積りを導入し、プロジェクトを成功に収めたことで有名になりました。

着手前のタスクに対して「甘く見積もってしまった」というケースが最近現場で多くなった。開発者は往々にして着手前は自分の作業進捗に対して楽観的で希望的になりがちだと思っている。そういった中で3点見積もりは楽観的・悲観的両方の帽子をかぶることを促すいい方法だなと思った。見積もりのブレが起きやすいという判明しているものについては3点見積もりを「見積もりの問い」として使うように取り入れてみよう。

数学的手法としてはPERT法も示されている。これはチャートで見たことあれねという理解だけなら勉強したほうがいいと筆者は推奨していた。

意図的な詳細化の回避

ユーザーストーリーを洗い出す際に、詳細化の誘惑をたち避ける鍛錬が必要だと示している。実際ユーザーストーリーを作成してそれに対する相対見積もりを行うストーリーポイントを用いた技法は軽量見積もりでその見積もりの寿命が長いことを利点とするが、詳細化しようとすると見積もりコストはあがり更にその見積もったユーザーストーリーは詳細が変に決定されているため数週間後に事情が変わっていることは往々にしてある。

仕損リスクも高いし書き込まれた詳細が有益なものとはならない可能性が高い。

だからといって全てタイトルだけですませろというわけではないだろうが相対見積もり可能なところまでにとどめて、それ以上の詳細は適切な決定の遅延を図るプロジェクト設計の脳みそを鍛錬してつける必要があるし、見積もりの会を催す場合も適宜そういったティーチングを介入することが必要になるだろう。いわゆる決定を遅延させる勘所をいかに磨いていくかと解釈した。

本書では、ストーリーは統合・分割・変更・破棄されるものであり、要件ではなくプレースホルダーに過ぎない点を強調していた。

見積もりの基準点となるゴールデンストーリー

ユーザーストーリーに対して見積もりをみんなで行う際、ひとつのストーリーを基準点としておくが、これを本書ではゴールデンストーリーと呼んでいた。ネットでさくっと調べたが該当する言葉を見つけれなかった。本書の中での造語だろうか？

ユーザーストーリーは時間を見積もるのではなく労力を見積もるものであることは、もう何度もどの書籍でも説明されている。

とにもかくにも「ゴールデンストーリー」という用語自体は便利なので、いままで「基準となるユーザーストーリー」みたいな言い方をしていたが便利な語彙として使わせてもらおうかと思う。

イテレーションの運営

イテレーションの運営にて2weekの例が出ている。そこでは中間チェックというプロセスが紹介されており、2週目の月曜日に中間状況を見て計画に新たなポイントを足し引きしていたりする。

現状の現場では1weekでのイテレーションを回しているが、おいおい2weekのプロジェクト運営が必要になることがわかっている。その際にイテレーションの始めと終わりにイベントを置くだけが手段ではないということを意識しておこう。中間チェックという概念により、思考の幅が少し柔軟になった。

ストーリーのガイドライン INVEST

Independent 互いに独立し特定の順番で実装する必要はない（ゆるいガイドライン）
Negotiable 開発者とビジネスで交渉可能であること、手段について開発者からの提案が可能
Valuable ビジネス価値が明確であること、ゆえにリファクタリングやアーキテクチャリングはストーリーではない
Estimatable 開発者が見積もり可能なくらいには具体的
Small 一回のイテレーションで1-2人の開発者が実装できるサイズを超えない
Testable ビジネス側はストーリーが完成したことを示すテストを明確に示す

Independentについてはある程度順番が大きな方向性として組み立てる必要がある場合に、ユーザーストーリーマッピング等の大枠の見積もり整理術が行われる認識を持っている。

Negotiableはいつも「要件は何か」というところで最初にPOが示した方法・手段が最も良いわけではないことを思うので、一度必ず聞いて吟味して本当に必要なことは何かを問うためのフィードバックループをいかに即座に回すかを考える。多すぎる詳細化は避けるという点について、詳細化を適切に避けたことによってイテレーション内で設計や仕様についての意思決定の遅延を図ることが重要であるということだろう。

Valuableについては現場でも注意を払っている。なんでもかんでもとりあえず「ユーザーストーリーなんだ」というふうに捉えてしまうと、本来ユーザーストーリー形式にすることの意義は見失ってしまう。

ユーザーストーリー形式にすることで目標の不確実性を低減させていくというような利点を活かすという選択肢を取るかどうかは実際ものによる側面もあるが、大事なことは「選択をした」ことが明らかであることだろう。

選択せずになんとなくユーザーストーリーってやつにリファクタリング入れておきます、の先にあることは、スプリントレビュー実施の際にフィードバックを得られないようなものしかできてないという可能性だろう。ビジネス価値が明確なものだけをスプリントバックログに埋めるべきだというわけではなく、ビジネス価値が明確なユーザーストーリーとそうではないタスクは明確に分けるべきで、明確に分けた上で量のバランシングをイテレーションプランニングで取ることが大事なんじゃないかと思っている。

Smallの話は『アジャイル見積もり』本では、5日以内くらいに終わるサイズのユーザーストーリーに収めるべきで、そうならないものは適切に分割していこうねと語られたりもしてる。

ユーザーストーリーの分割については所属企業にエントリを投稿していたりする。

見積もりとスパイク

スパイクは読んだ翌週にすぐ現場に展開したワーディングだった。これまで技術的調査や検証が必要なものについて「少し多めにポイントを降っておく」といったようにユーザーストーリー自体の大きさに対して加算する方法をとっていたのだが、やはりそういう類の見積もりはブレが多いことが散見されていた。

スパイクは、ryuzeeさんの次の記事ではこう説明されている。

リリース可能なプロダクトを作るのではなく、質問に答えたり情報を収集したりすることを目的とした作業。 開発チームが技術的な質問や設計上の問題を解決するための実際の作業を行うまで、見積りができないようなプロダクトバックログ項目が出てくることがあります。 解決策は、「スパイク」を行うことです。 目的は、質問に対する回答やソリューションを見つけることです。

実際の作業を行うまで見積もりができないと判断されたものに対して、見積もれるところまで情報収集や検証を行うものです。

そしてその中の1つが技術的な調査です。 スプリントでプロダクトバックログ項目に着手してから実現方法を調べたり、技術的な制約によって大幅な方針転換したりするのでは遅い上に予測性が低いので、先に技術調査をするわけです。 このことをスパイクと呼びます。

プロダクトバックログに入れるべき内容についてreadyである必要があるということを下の記事でも述べており、readyであることに2つの条件を上げていました。

開発チームとして必要な情報が揃っている
開発チームとして受け入れ可能な品質

過去の歴史的経緯などによって大きくぶれうるようなものに対して事前に「スパイクを打って」大きな手戻りや必要な情報を集めようという使い方をやっていく中で見つけていったりした。

ベロシティの認識をマネージメントする

ベロシティは開発チームメンバーに「あげようとする」強い誘惑があると思っている。過去、「アジャイルな」現場で嫌な経験をしたことがある人の話を聞くと、このベロシティをあげるような強制された雰囲気があり、そのために手軽なポイントをとっていくようなインセンティブが働いてしまったといったエピソードを聞いた。

現場ではそれはないように心がけているがやはり「ベロシティ上げていきたい」というインセンティブがちょくちょく働いてしまう。

前述したとおり、イテレーションが成功したかどうかは高いベロシティではなく、意思決定に有用なデータを提供できたかとなる。

ベロシティあげたいとなると、例えばユーザーストーリーの70%が出来ていたとして、それをタスクに分割して当イテレーションに完了したものとしてポイント加算するというようなハックが可能になるが、「プロジェクトの意思決定のためのデータを提供する」という観点においては意味なく、むしろデータを曖昧にするだけになる。

このような点についてベロシティが上がったケースと下がったケースについて、それ自体が好ましいわけではないことを示した上で、インフレもデフレも避けた上で一定にしたいという運営指針を示していた。

小さなリリース

イテレーション駆動での開発はつまりイテレーションごとに小さなリリースをするということが必然的に含まれる。いわゆる継続的デリバリーが目標の一つになる。変更するたびに本番環境のプロダクトへリリースしていく。継続的デリバリーはデリバリーのフェーズのみだけでなくすべてのフェーズを短縮していくことを話のスコープとしては含まれる。

そういえばこの辺でCleanシリーズではわりとおなじみなパンチカードのエピソードが出てくる。ロブおじさん本人へのインタビュー動画で訳者が「パンチカードでのプログラミングはやったことがないが、多数の著書を読んでいく中でパンチカードでプログラミングしたことがある気がするようになってきたw」というエピソードを話されていて、言われてみればパンチカードのエピソードをロブおじさんの著書を通して語れるようになってるなと思ったw

すでに前述していたが、リリースという用語自体は「技術的にはデプロイ可能である」ことを示したものだ。この概念定義を見失ってこのプラクティスを批判してしまうとすべてが的外れになってしまうので注意が必要だ。

受け入れテストと「完成の定義」

テスト、とくに受け入れテストについて解説している中で、受け入れテストは「ビジネス側がユーザーストーリーの振る舞いを形式的なテストで記述し、開発者がそれらのテストを自動化する」ものであるとしていた。そして、このテストはイテレーションにおけるストーリーの完成の定義であるといっている。

Scrumにおいても「完成の定義」がある。

更新された日本語訳では、完成の定義を次のように表明している。

完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。
プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。

ここで話題にあがるのが「完了の定義」ではないよという話だ。正直、この話について自身は一家言無いのだが、この訳し方の違いによって主体が変わる印象があるなと思っている。つまり、「完成」は少なくとも開発者ではない第三者あるいはビジネス側の定義によって受け入れられるという、ビジネスが主体となって定義するものであり、「完了」はある意味開発者自身が「自己満足的に」完了と宣言できてしまう印象を持った。

そう考えるとユーザーストーリーのような顧客価値を明確に示した記述であれば「完成の定義」は可能だが、具体的な作業を記したタスクには「完成の定義」はなく定義できても「完了の定義」になってしまうのではないかと考えた。

実際業務におけるすべての仕事を「ユーザーストーリー」だけで分類して見積もれるかというとなかなか難しいものがあると思っている。一方でだからといって「タスク」ばかりに分類していくと、今度は目標の不確実性が低減されず、作成されたソフトウェアや成果物に対するフィードバックループは回らなくなる。

基本的には、どれだけ目標の過程に対するフィードバックループを回したいか、という目的感によってそれぞれ決めればいいのではと考えているのが現在地点ではある。そのうえで、フィードバックループをそこまで重視せず、やっている仕事の透明性やブレークダウンをきっちりやることを重視するという「意図」が周りから明確になるような仕事のフレームが必要だと思う。

そのため、筆者は現場では「タスク」・「ユーザーストーリー」のどちらとしてこのチケットを扱いたいかという点は明確な意図が見えるように、共通認識を育てていったりといろいろなことを工面している現状。

QA in Agile

AgileにおけるTesterおよびQAの役割については海外のウェビナーを見たりして色々興味を持っている。本書ではまずビジネスアナリストと比較して幸いっていたりした。

ビジネスアナリストはハッピーパス（正常系）を仕様化し、QAはハッピーではないパスを書く。

基本的に仕様を持っているのがビジネスアナリストないしProduct Managerである事が多いため、この整理はしっくりきた。そして、QAが後方待機するのではなく、前方で仕様策定者となるのがAgileにおけるQA Engineerであるとしている。

さらに、Testerは開発者であるということをいっていて、QAはあくまで受け入れテストを書くところまで実行はしない。テストをパスするかどうかを検証するのはプログラマーの仕事の範囲であると表明している。

プログラマーの仕事の範囲であることを考えると、小さなサイクルでテストを書いていくcheckingにあたるTDDと、受け入れテストで駆動するATDDといったテスト実行のライフサイクルを生み出す開発プラクティスがこの文脈で有用とされるのも一貫性を感じる。

継続的ビルドの規律

継続的インテグレーション（CI）の文脈におけるビルドは絶対に壊してはいけないと強く主張している。現実世界で生きていると唐突に幽霊のように壊れることはいくつかある。flakyなテストがあって唐突にテストスイートが失敗したり、脆弱性検査をフローに入れていれば新しい脆弱性でビルドが落ちることもある。

これについて根気よく規律を持って直し続ける・再発防止を考え続けることの価値を本書では強いプロフェッショナリズム・規律として示していた。この考え方は日々忙殺されていると後回しになってしまいかねないが、組織の文化としてしっかり「当たり前の振る舞い」として定着させていきたいと感じた。

そして、アジャイルコーチという役割はこの継続的ビルドを守ろうとしなかったときにしっかり指摘することも役割であると語っていた。

テクニカルプラクティスの重要性

この辺の議論はDDDが戦術面だけフォーカスされ揺れ動くように戦略面だけフォーカスされ「お前らな〜」ってなるあれを想起される話だが、著者はテクニカルプラクティスなしでアジャイルを始めようとしてしまうのは意図されたものではなく骨抜きにされた役立たずだと断言している。

テクニカルプラクティスとは、サークルオブライフ内のTDD・リファクタリング・シンプルな設計・ペアプログラミングといったものを示している。

これを Martin Fowler氏は「Flaccid Scrum（ヘロヘロスクラム）」と表現している。

I've mentioned Scrum because when we see this problem, Scrum seems to be particularly common as the nominative process the team is following. For many people, this situation is exacerbated by Scrum because Scrum is process that's centered on project management techniques and deliberately omits any technical practices, in contrast to (for example) Extreme Programming.

著者は完全なサークルオブライフを採用することを強くアドバイスしており、特にテクニカルプラクティスが重要であるというスタンスを取っている。もちろん自分たちのニーズに合わせたプロセスの調整が必要であることも言った上で。

TDDと複式簿記

TDDと複式簿記の比較は、簿記3級勢の自分でも「あぁなるほどたしかになぁ」とめちゃくちゃ納得した。

テスト駆動開発は、それに対応するプログラマーのためのプラクティスである。必要となる振る舞いは、必ず2回入力する。1回目はテスト、2回目はそのテストをパスさせるコードだ。この2つの入力は、貸借対照表と同じように対になっている。両者を一緒に実行すると、結果はゼロになる。つまり、失敗したテストがゼロということだ。 / Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,角谷 信太郎. Clean Agile　基本に立ち戻れ (Japanese Edition) (Kindle Locations 2201-2205). Kindle Edition.

この洞察はTDDを単なる開発手法として筆者が見ていないことが如実にわかると思う。つまり、仕組みとして不可欠なふるまいとして行い、正しくあるべき重要なドキュメントとしてのエラーを防ぐという、ソフトウェア開発全般における「規律」をいかにもたらすかという大命題が主題であり、そのための一つの拘束力のあるふるまいであるという見方が浮かび上がってくる。

この著書はRobおじさんの「プロフェッショナリズム」の洞察が随所に出てきているが特にテクニカルプラクティスではより顕著で面白い。

もうひとつTDDについて個人的にはよくおすすめしていた点だが、あまり書籍での言及が見られなかった点として「楽しさ」が挙げられていて、「それそれ」って思ったことがあった。


テストコード自体を書こうねという最初の段階のころ、開発現場は「テストを書くのが面倒くさい」という話が色々あったし、同じチームでもその声はあった。「後でまとめて書こうとするから夏休みの宿題になって辛いんですよ...」といっていたりしたのだが、全く同じ主張をオリジナルに近いRobおじさんが言っているのはとても心強い。

「テスト辛くないよ〜」だけに全フォーカスした発表をそういえば2年前にしていたことを思い出した。

t-wadaさんが訳された『テスト駆動開発』では、TDDは開発者の不安をコントロールするとよく表現する。本書ではこの点について「勇気」という表現を使っていて、コードをクリーンにする恐怖に対する勇気を生み出す点を一番強調していた。

アジャイルコーチ

特にアジャイルに詳しい人間ではないのだが、「もしかして今やっていることはアジャイルコーチなんだろうか？」と思うときがあったのだが、本腰を入れてその役割についてちゃんと理解しようと努めたことはなかった。本書ではアジャイルトレーナーとアジャイルコーチがまず違うと区別した上で、アジャイルコーチはチームのメンバーでありプロセスで定義された役割であると説明している。

開発者がプロセスを「ちょっと悪い方向に」変えてしまった際に指摘する役割だとしている。

自身は、最近だと「レトロスペクティブのあり方自体を振り返りしませんか？」と課題提起して、レトロスペクティブの「良い点」・「改善点」を再認識する、といった時間を意図して作ったりしていた。

背景としては「レトロスペクティブ自体の価値」をもう少しうまく発揮できると思うんだよな、といった課題感からしたものだが、ある意味「耳の痛い」こともちょっと言うような振る舞いをとった。

アジャイルコーチってこういうことなのかしら？と思ったエピソードを振り返った。そしてこれを明示的ないし暗黙的に役割としておいたものがアジャイルコーチであるという理解をした。そして、スクラムではこれを「スクラムマスター」と呼ぶ（これ関連の章でRobおじさんが認定資格についてディスってるのが面白いので是非本書を手にとってほしい）。

ソフトウェアクラフトマンシップ

最後の30%弱の章は他のAgileエキスパートたちの寄稿となっている。その中でもサンドロ・マンキューソ氏の章での「ソフトウェアクラフトマンシップ」という概念が紹介された。正直初めて知った。

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

たとえば、well-crafted software（精巧に作られたソフトウェア）は、設計・テストが上手く行われ、変更可能でありビジネスの反応速度を高める、柔軟性・堅牢性両方に長けたコードのことをしめしている。

2008年創設のこのコミュニティだが、ここでもXPが現在利用可能な最高のアジャイル開発プラクティスであるという見方をとっている。


おわりに

持続可能なペースでは18歳のRobおじさんの徹夜エピソードが盛り込まれている。1970年代の話らしい。まだ自分が生まれる気配のなかった時代の話だが親近感を持って笑ってしまった。

まさに基本に立ち戻る本であり「おいおいお前だどこ行ってんだよ」と業界全体に声をかけるような一冊だった。

ここまで長々と書いた文章の中で本書の内容に直接触れているのはほんの30%程度くらいだったはずなので、もしここまでクソ長い一人感想戦にお付き合いいただいた方は、是非本書を手にとってほしい。

最後印象的だったインタビューでの話として「こんなにCIが早くなるとは想像してなかった」という言葉があった。ここから取れる大事なことは技術の進歩・道具の進歩と考え方は両方揃って初めて成立するという点だった。どちらか一方に価値を置くポジショントークが繰り広げられがちだが、そうではない。両方の翼がしっかり生えて初めて成立するということを忘れてはいけない。

この記事が気に入ったらサポートをしてみませんか？