なんとなくアジャイルに参加している私が「Clean Agile 基本に立ち戻れ」を読んでみた
はじめに
初めまして、かめごろと申します。
私がエンジニアとしてのキャリアを歩み始めてから 2 年ほど経ちましたが、その中で最も聞いたワード No.1 は 「アジャイル開発」 であると自信をもって言えます。
ウォータフォール式の開発もアジャイルと呼ばれていた開発にも参加したことはありますが、私には大きな差異は感じられず、どのような成果を生み出していたかはわかりません。
運が良いことに炎上案件と呼ばれるプロジェクトに参加した経験は無いのですが、それは正しくアジャイル開発が機能していたという事だったのでしょうか。
今回は 「アジャイル開発とは何か」 を知るために、「Clean Agile 基本に立ち戻れ」を読んでみることにしました。
TL;DR
- 「アジャイルとは何か」を説明する記事ではありません。感じたことを章ごとにメモとして残しています。
- 私の解釈で読み進めますので、誤った解釈等ありましたらコメント頂けますと幸いです。
- 章ごとに進めますので、前半と後半で異なる解釈をしている可能性があります。
第一章 アジャイル入門
アジャイルはマネジメントをどのように支援するのだろうか？ データを提供するのである。アジャイル開発チームから、マネージャーが適切な意思決定をするために必要なデータを提供するわけだ。
前提としてマネージャーとチームが分けられているプロジェクトはどの程度あるのだろうか。
アサインされているエンジニア工数の都合上、テックリードがこの辺りを管理しているケースが多いのもあってハイパフォーマンスメンバーが開発にコストを割けていない現場をよく目にする。
プロジェクトについて最初に知るべきことは何だろうか？プロジェクトの名前や要求を知る前に、最初に知るべきデータがある。それは納期だ。納期が決められると、もう動かすことはできない。凍結されたのだ。交渉の余地はない。
ココがアジャイルで解消されるのかが理解できない要素の一つ。
私がアジャイルは全ての開発の問題を解消してくれる便利な開発方式だと思い込んでいる節もあるが、納期が設けられている以上、結果的にウォータフォール式になってしまうのではないかと感じてしまう。
アジャイルではスプリント毎にストーリーを作成し、見積もり、計画し、設計することを繰り返すが、何故この進め方で納期までの予測を立てられるのだろうか。
アジャイルとは、どれだけうまくいっていないかをできるだけ早く知ることだ。できるだけ早く知りたいのは、そうすれば状況をマネジメントできるからだ。これがマネージャーのやることだ。
なるほど。根本のアジャイルへの理解が違っていた。
第一章を読んで
正直な所、今までアジャイル開発とは、「最終的には何とかするので暫くは我慢してください！アジャイルなので！」とプロダクトオーナーに理解をしてもらう物だと思っていたけれど、アジャイルで計測したデータを元に交渉する機会を貰える良い開発手法なのだと知った。
とは言え、ソフトウェア開発において全ての開発の予測は不可能である事への理解は必要そう。
第二章 アジャイルにする理由
アジャイルでは、単純なルールでこれを解決する。各イテレーションの終了時点でシステムが技術的にはデプロイ可能な状態でなければならない、というルールだ。「技術的にはデプロイ可能な状態」とは、開発者として見たときに、システムがいつデプロイされても問題ない程度に整っているということだ。この状態のコードはクリーンで、テストもすべてパスしている。
フロントエンド開発では、リリースまでの工数やエンジニアの技術面から初期段階ではテストを導入しないケースは少なくないと思う。
途中段階でのテストの導入は苦しく、何故最初から導入しなかったのだろうか後悔したことは、幾度となくあったが開発の初期段階では、テストの有無では大きく変わるため納期との兼ね合いで導入されていない気がする。
第二章を読んで
TDD の重要性が強く伝わる章だった。
新規サービスの立ち上げしか経験しか無いのか、運が良いのかテストが無いことでの大きな事故にあったことがない。
この本を読み終わったら TDD に関する技術書も読んでみたいと感じた。
権利と期待をお互いが引き受けて協議するという規律のある専門性こそが、ソフトウェアの倫理的な基準の土台となるのだ。アジャイルは開発プロセスでもなければ、流行りの何かでもない。単なるルールの集合でもない。アジャイルとは、倫理的な専門性の土台を形づくる権利、期待、規律の一式である。
プログラマーの私には意識しない領域の話でとても面白かった。
私は、開発者と顧客は常にぶつかり合いお互いの主張を押し付け合う存在であるというイメージが何故が染み付いてしまっている。
これは、アジャイル問わずソフトウェア開発者に携わる人達には刺ささりそう。
第三章 ビジネスプラクティス
失敗していない！イテレーションは失敗しない。イテレーションの目的は、マネージャーのためにデータを生成することだ。コードができていればすばらしいが、コードができていなくてもデータは生成されるのである。
なるほど。少しずつ分かってきた。
リファクタリングはストーリーではない。アーキテクチャはストーリーではない。コードのクリーンアップはストーリーではない。ストーリーには常にビジネス価値が存在しなければいけない。心配しないでほしい。リファクタリング、アーキテクチャ、クリーンアップについては、あとで触れる。だが、ストーリーのところではない。
ベロシティを工数として見ているため、「リファクタリング、アーキテクチャ、クリーンアップ」の時間をどのように組み込めば良いのだろうか。
アーキテクチャの変更は、該当ファイルを触ったタイミングに一緒に更新するでは効率が悪いようにも感じる。
ストーリーは、INVEST という頭字語のガイドラインに従う。
INVEST とは下記のことを指すらしい。
- Independent（独立した）
- Negotiable（交渉可能）
- Valuable（価値がある）
- Estimable（見積り可能）
- Small（小さい）
- Testable（テスト可能）
アジャイルにおいて、ビジネス側がストーリーが完成したことを担保するテストを明確に示す必要があるのか。分かりやすいEstimableが欠けていた場合に成り立たない事が、想像できるようにTestableも同等の必要性があると認識するべきなのだろうか。
イテレーションの終わりには、新しく完成したストーリーをステークホルダーに簡単にデモする。このミーティングは、イテレーションの期間によって違うが、だいたい 1〜2 時間程度である。
デモでは、すべての受け入れテスト（これまでの受け入れテストも含む）とすべてのユニットテストを実行する。また、新しく追加された機能も見せる。開発者が機能していないところを隠せないように、ステークホルダーがシステムを操作するといいだろう。
確かにテスト無しでは、顧客の「開発の進捗や機能が正確に実装されているかを知る権利」の担保は取れない。
テストは品質担保だけでなく、開発者体験を上げるためのツールだと思い込んでいたが、このような視点では考えた事がなかった。
第三章を読んで
この章は、私が最も苦手とするテストに関する重要性がわかる章だった。
特に、受け入れテストの「要求はビジネス側が仕様化する」という、プログラマーには現実味を感じ無い体制も、テストの粒度やビジネス側とプログラマーを繋ぐ支援ツール等を利用して可能である事を理解できた。
初半から 4 年経った今では、この辺のツールは私レベルのプログラマーでも耳にすることは増えた気がする。
第四章 チームプラクティス
徹夜する自分たちのことを誇りに思っていた。これが本物のプログラマーだと思っていた。我々は献身的だ。我々には価値がある。なんたって重要なプロジェクトを我々が救済しているのだから。これがプログラマーだ。そして、我々は燃え尽きた。激しく燃え尽きた。
ソフトウェア領域を開拓してきた彼らのような人でも、燃え尽きることがあるのかと驚いた。
第四章を読んで
この章は、チーム間でのコミュニケーションや働き方に関することを中心に書かれていた。
睡眠の大切さや無理な残業はするべきでは無いなど、普通の事が書かれているが、逆にあまり意識してはいなかった。
エンジニアをしている業務外であっても常に自己学習をしないと周りと差をつけられる不安は誰にでもあると思うが、ふとした瞬間に燃え尽きてしまうのではと怖くなる事はある。
第五章 テクニカルプラクティス
TDD は 3 つのシンプルなルールで記述できる。
- 失敗するテストを書くまではプロダクションコードを書いてはいけない（テストはコードの不足が原因で失敗する）。
- 失敗するテストを必要以上に書いてはいけない（コンパイルの失敗も失敗に含める）。
- プロダクションコードを必要以上に書いてはいけない（失敗しているテストをパスさせるためだけに書く）。
TypeScript に初めて出会った時の感覚に似てる。
なぜ、私はエンジニアになって最初から TDD での開発をしてなかったのだろうかと。
ただ、実は「実践テスト駆動開発」を以前買って読み始めてみたものの、サッパリで途中で挫折していたことからも理解はできなかったと思う。
あとからテストを書いたことがあれば、あまり楽しくないことを知っているだろう。
だが、3 つのルールに従ってテストを先に書くと、楽しい。新しいテストはいつも挑戦である。
グサグサと刺さる。
後からテストを書く場合、無意識に落ちないテストを書いているかもしれない。
仮にテストが落ちたら、苦労して進んできた道を戻るかもしれないから。
何のためのテストを書いているのか...
リファクタリングとは「テストで定義された振る舞いを保ちつつ、コードの内部構造を改善する」プラクティスである。言い換えれば、テストを壊すことなく、名前、クラス、関数、式を変更することだ
テストの無いコードのリファクタリングは恐怖でしかない...
依存関係が多いほど気が重たくなる。
リファクタリングが継続的なプロセスであることは明らかだ。スケジュールを立てて実行する物ではない。
なるほど。第三章での疑問点が解消された。
アーキテクチャの変更は、アジャイルのサイクルの中で継続的に、少しずつコードを移行していくらしい。
ただ、バージョンのアップグレード等の全て同時に更新せざる得ない場合はどうだろうか。
全て移行しきったと確認が取れてからアップグレードするのだろうか。
変化の激しいソフトウェアの領域において数ヶ月の移行で最適解が変わることもあり得ると思う。
その時はどうするのだろうか。まだモヤモヤは残る...
ペアプログラミング
ストーリはペアに割り当てる物ではない。ペアではなく個人のプログラマーがストーリの責任を持つ。
ペアプロの良さは理解しているけれど、時間を大きく割かれてしまう点と解散後の疲労感から避けがちになってしまう。
普段からメンバー同士のコミュニケーションが適切に取れていれば、そんなことは無い気もするが、正直あまりペアプロは得意ではない。
第五章を読んで
個人的にはこの章が一番面白くて刺さる章だった。
「テスト・リファクタリング・ペアプログラミング」について詳しく書かれている。
上記の三点が満たされてないアジャイル開発もあると思う（果たしてアジャイル開発なのだろうか）
第六章 アジャイルになる
インフォーマルで頻繁なやり取りのなかで、アイデアは生まれ、インサイトが手に入る。一緒に座って頻繁にコミュニケーションするチームは、奇跡を起こせる。
ご時世の都合からリモート文化が浸透しているが、一番のデメリットはコミュニケーション部分だと思う。
常にビデオチャットで繋ぎながら会話するのと面と向かって会話するのでは温度感やカジュアルな会話が難しくなる。
フルリモートで有難いと思う反面、皆心の中で出社しての作業のほうがパフォーマンスが高くなることは気がつき始めていると思う。
誰かが「認定」スクラムマスターだとしても何の意味もない。認定資格とは、研修を受けた人がコーチのように動けることを保証するものではなはい。「認定スクラムマスター」に特別な何かがあると思わせることがバカげている。
ここまで読み進めてみると、その通り何の保証にもなれないことは理解できる。
チームで実際にスクラムを回してみて学ぶものだ。
第六章を読んで
この章ではアジャイルを導入するにあたって「何をするべきではないか」が書かれている章だった。
アジャイルを取り入れたい組織ではコーチングはどのような事を意識するべきか等も書かれているが、私の知る限りコーチングポジションとして採用されているケースは見た事がない。
皆、チームで試行錯誤しながらアジャイルを導入・運用している（むしろ、それこそがアジャイルの良さでもあるのかもしれない）が、一度コーチングを受けてみたいとも感じ> あじた。
第七章 クラフトマンシップ
アジャイルは ソフトウェアを高速に提供するプロセス に変わっていた。
誰かにそう教わった訳ではないが、何故だかそう解釈してしまっていた。
第七章を読んで
少し難しかった。
アジャイルのような開発においてのプラクティスをチームに導入するにあたって注意・考慮するべき要素がまとめられている章だった。
プログラマーはそれぞれ開発において信念があると思う。
それを否定せず良き着地点を探るコミュニケーションは難しい。
まとめ
一週間かかりましたが想像していたより読みやすかったです。
この本は、実際にアジャイルを回しているが各スクラムイベントや理論の理解が浅い人や、ウォータフォール開発で失敗経験がある人には良いと思います。
逆に、プログラマーとしてのキャリアが浅くテストやデプロイ経験が無い人には、アジャイルで得られるメリットが想像が付きにくいかもしれません。
もし、これを読んでいる方がアジャイルへの知見が浅いチームに参加しているのであれば、あなた以外のメンバーにも是非勧めて欲しいです。
TDD・リファクタリング・ペアプロなどは最初からアジャイルにおいての思想を理解するに難しいと思います。
アジャイルの効果を最大限発揮するにはメンバーの協力は不可欠であると私は感じました。
長くなりましたが、ここまでご愛読頂きありがとうございます。
Discussion