「風車や滝(ウォーターフォール)を相手に戦ったことのあるすべてのプログラマーへ...」
という出だしから既にグッとくる、Cleanシリーズの最新刊。数々の書籍で知られるロバート・C・マーチンさんによる、アジャイルの歴史を振り返りながら再定義していく本です。小さなチームの小さな問題を扱う小さなアイデアがアジャイルであり、そもそも大きなところを対象にはしていないというスタンスで記されています。
- 「風車や滝(ウォーターフォール)を相手に戦ったことのあるすべてのプログラマーへ...」
- 第1章 アジャイル入門
- 第2章 アジャイルにする理由
- 第3章 ビジネスプラクティス
- 第4章 チームプラクティス
- 第5章 テクニカルプラクティス
- 第6章 アジャイルになる
- 第7章 クラフトマンシップ
- 結論とあとがき
- まとめ：ボブおぢさん節でアジャイルの源流と歴史を再確認できる本
- おまけ クリーン本シリーズ
Clean Agile 基本に立ち戻れ (アスキードワンゴ)
- 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,角谷 信太郎
- 発売日: 2020/10/16
- メディア: Kindle版
第1章 アジャイル入門
2001年2月にユタ州スノーバードに集まった人たちが有名なアジャイルマニフェスト宣言を行い、そこからアジャイルの歴史が始まりました。そこからいろんな人が装飾したり拡張したりはたまた誤解したりして、アジャイルは変容してきました。ここで事実関係を明確にして、改めてアジャイルとは何かを振り返る章。
アジャイルの歴史
アジャイルの歴史はいつから？ →おそらく５万年前、人間が洞窟に住んで狩りをしていた頃からだというボブおぢさん流解釈がおお～となります。根本的には直感的で人間的な営みであり、近代産業でもふつうに行われていた訳ですね。
これに対して、厳密に分析してスケジュールを最後まで立ててきっちりやるトップダウン型である『科学的管理法』が登場します。1970年代のウィンストン・ロイスWinston W.Royce)氏の論文にある、いかにもウォーターフォールっぽい四角が順に流れていく図が登場します。
なんとこの方法はよくないよと論文の中で論破する予定で最初の方に載せたものが、逆にウォーターフォールという手法として有名になってしまったそうです。これは本書を読んで初めて知りました。まさに事実は小説より奇なり……!
www.artemisagile.com (記事の最初の図です)
このウォーターフォールが業界を「30年間支配」したあと、1980年代後半から後にアジャイルにまとまっていく様々な考え方や手法が登場します。90年代になってボブおぢさんがケント・ベック氏と出会って XP(Extreme Programming) を知ったり。あのマーチン・ファウラー氏と出会ったり。そして『軽量級プロセスのサミット』という名前のイベントで創設者たちが一堂に会します……
スノーバード
合計17人が伝説的な集まりに集結。ボブおぢさんはXPチーム、ユーザ駆動開発手法の人、動的システム開発手法の人、そしてこれも名著の『達人プログラマー』のアンディー・ハントさんなども登場。読んでいるとここで歴史が動いたのか……! と震える気分になります。ここでかの有名な、アジャイルマニフェスト宣言が為されます。
有名な話なのでなにやら凄いイベントのように思えますが、文中の描写からすると、日本だったら都内の高いホテルを借りた大規模なカンファレンスのようなものではなく、一室に面々が集まったオフ会のようなノリだったようです。
ネーミングについてはボブさんは「ライトウェイト(軽量級)」を提案。他の候補には「アダプティブ(適応型)」、軍隊で流行っていたから「アジャイル」。ネーミング候補の中でアジャイルが抜きんでて良かったのではなく、実は他の案がイマイチだったので「アジャイル」が選ばれた、というのが興味深いです。
アジャイルの概要
伝統的な管理手法では、神を信じるマネージャーの間では「希望と祈り」が人気だ、という皮肉でジャブをかましながらアジャイルの概要を語る節。
- 鉄十字：「品質」、「速度」、「費用」、「完成」(日本語なら納期でしょうか)の4つの鉄十字がある。このうちから3つを選べるが４つ全部は無理。アジャイルはマネジメントを支援するフレームワークである。
- 壁のチャート：作業をどれだけ完了させたかをポイント単位で示す「ベロシティ」のグラフ、次のマイルストーンまでの残りポイントを表す「バーンダウンチャート」のグラフ、この２つのデータがアジャイルにはある。このデータを提供して未来の予測を支援する、フィードバック駆動のアプローチがアジャイルである。
- 最初に知るべきこと：納期は決まると動かせない。その中で要求は変わるのに成果は出さねばならないのがソフトウェア開発である。
- よくあるミーティング：そもそも要求が決まっていないので分析フェーズの期間が適当に決まってしまう。
- 分析フェーズ：予定の２ヶ月が終わると魔法のように自動的に完了！
- 設計フェーズ：機能が追加されたり予期せぬ事態が色々起こる。でも予定の2ヶ月が終わるとこちらも自動的に完了！ これは明確な完了基準がないからである。
- 実装フェーズ：分析と設計は終わったことにできるが、実装は完了したふりはできない。そして遅れに遅れて、納期間際に悪い報告をしてステークスホルダーが青ざめることに。
デスマーチのフェーズ：炎上して疲弊する。開発者は「次はもっとうまくやろう」と考えてしまう。やめずにもっとやろうとするので「暴走プロセスのインフレ」とボブおじさんは命名している。
- イテレーションゼロ：最初の回では「ストーリー」で構成された機能リストを作って見積もり、計画を立てる。毎回のイテレーションで分析/設計/実装が続き、プロジェクト全体を探索していく。イテレーションの中をフェーズに分割するのではないので、ミニ・ウォーターフォールではない。ここがよく誤解される。
- アジャイルが生成するデータ：最初のストーリがすべて完成する可能性はほぼゼロである。正確な見積ができないから。2～3回のイテレーションを続けると精度が上がってくる。
- 希望とマネジメント：こうして、希望がプロジェクトを殺す前にアジャイルで希望を破壊するのがゴールである。(パワーワード頂きました～)
アジャイルは速く進むことではなく、どれだけうまくいっていないかを速く知ること。そうすればマネジメントができる。最初に望んだ通りの成果は出なくとも、ステークスホルダーに可能な限りの最高の成果を提供できる。
鉄十字のマネジメント：「品質」「速度」「費用」「完成」の４要素の中でどれを変えられるかについて。
- スケジュールの延期はたいてい無理である。
- そして人を増やしてもプロジェクトは遅れるだけなのは「ブルックスの法則」で示されている。
- そして品質を下げることについて。ガラクタを作っても速くはならない。これがプログラマー人生から得た教訓である。速くて汚いものなどなく、汚いものはすべて遅い。速く進む唯一の方法はうまく進むこと。クオリティは最大に。
- ４要素の最後、スコープを変える。これは可能であり、結局これになる。
プロジェクトを複数のイテレーションに分割して、アウトプットを毎回計測して、スケジュールを評価する。ビジネス価値の高いものから順に実装し、品質は可能な限り高める。スケジュールはスコープの調整で管理する。これこそがアジャイルである。
……と、ボブおぢさん節でずばっと定義しています。
サークルオブライフ
ロン・ジェフリーズ氏による XP(Extreme Programming) のプラクティス図が登場します。
文中に有名なケント・ベック氏、ウォード・カニンガム氏が登場。『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』は日本でも2000年に登場しました。
- 作者:ＫｅｎｔＢｅｃｋ,ＣｙｎｔｈｉａＡｎｄｒｅｓ
- 発売日: 2017/07/14
- メディア: Kindle版
一番外側のリングがビジネス向けのXP手法。中間のリングがチーム向けの手法。内側のリングがプログラマー向け手法。これらはアジャイルマニフェストの目標とほぼ一致。
しかしXPはじめ幾つかの考えが統合されてアジャイルとなった訳なので、完全に一致ではなく「非常に深くて絶妙」な関係だと本書では述べています。
結論
帯にもありますが、「小さなソフトウェアチームが小さなプロジェクトをマネジメントするための小さな規律」こそがアジャイルである、と定義しています。こうしてアジャイルの歴史が始まったのです……
第2章 アジャイルにする理由
何が問題になっているのかを、なぜアジャイルをやっていくのかを解説していく章。
プロフェッショナリズム
ソフトウェア開発はとにかく失敗しやすく、プロフェッショナリズムが切実に必要だよという話。
- あらゆるところにソフトウェアが：いまや生活や物事、すべてがソフトウェアに支配されている。
- 我々が世界を支配する：実際のルールはプログラマーが書いており、プログラマーが世界を支配しているのだ！だがその仕事はなかなかにお粗末である。きちんと保証できるか？ トヨタのリコール話が出てきます。
- 大惨事：いずれ人の命を奪うような事態にもなってくる。そうすれば非難の矛先がエンジニアに向けられる。アジャイルの規律により、名誉ある職業を目指そう。
まっとうな期待
まっとうな期待に応えるのもプログラマーの仕事だ。ちゃんとした仕事をやろう、そのためにアジャイルには様々なプラクティスがあるよという話。
- ゴミをリリースするわけにはいかん！：テスティング、リファクタリング、シンプルな設計、顧客からのフィードバックは、ゴミをリリースしないための対処法である。
- いつでも技術的な準備を整えておく：アジャイルでは、各イテレーションの最後でシステムが技術的にデプロイ可能な状態を保ち続け、品質を維持している。
- 安定した生産性：時が経つとコードは雑然としはじめ、生産性が落ち、人が追加されて又悪くなり……と負のスパイラルが起こる。(ここでいつもの昔話が登場します)
アーキテクチャ、設計、コードは可能な限りクリーンに保ち続けよう。テスティング、ペアリング、リファクタリング、シンプルな設計、計画ゲームがこれを助ける。 - 安価に変更できる：要件が変更されたらアーキテクチャがだめになるなら、そのアーキテクチャはゴミだ。(パワーワード頂きました～)
変更コストは小さく、増加は線形となるのが理想である。TDD,リファクタリング、シンプルな設計がこれを助ける。 - 継続的な改善：時と共に設計やアーキテクチャはより良くなっていくはずである。継続的で着実な改善、時間の経過でシステムが良くなるのを期待されている。プラクティスがこれを助ける。
- 大胆不敵に力を発揮する：変更に対する恐怖を乗り越えて、コードをクリーンにしていく。TDDがこれを助ける。
- QAは何も見つけない：QAがテストをしても問題が見つからないぐらいがよい。
- テストの自動化：どんどん機械にやらせよう。TDD、CI、受け入れテストがこれを助ける。
- 互いにカバーしあう：もし誰かが休んでも誰かが代わりをやれるようなチームにする。ペアプロ、チーム全体、共同所有がこれを助ける。
- 誠実な見積：機能同士の相対でよりよい見積もりを出せるように。計画ゲームとチーム全体のアジャイルプラクティスがこれを助ける。
- 「ノー」と言うべき：解決策が本当に見つからなかったらノーと言うのが正しい開発者。チーム全体のアジャイルプラクティスがこれを助ける。
- 継続的かつ積極的な学習：学び続ける。
- メンタリング：新メンバーにも教え、互いに教え合う。
権利章典
顧客：いつまでに何がどれくらいのコストで達成できるか知る権利、最高価値を手にする権利、テストを通して進捗具合を知る権利、機能の差し替えや優先順位を変更する権利、スケジュール変更の連絡を受ける権利を持つ。
開発者：何が必要かと優先度を知る権利、質の高い仕事をする権利、助力を受ける権利、自分から見積もりをする権利、責任を自ら引き受ける権利を持つ。
ビジネスと開発の分断を修復するための権利章典で述べられている、それぞれの権利を解説しています。開発者として質の高い仕事をする権利、仕事を自ら引き受ける権利があるというくだりは、前にで語られているプロフェッショナリズムをもって仕事をしようという話とも関連していますね。
結論
プロフェッショナルなソフトウェア開発を支える「規律」のフレームワークがアジャイルである。プロセスやルールの集合ではなく、倫理的な専門性の土台を形作る権利/期待/規律の一式である、と最後に結論付けています。
『Cean Code』『Clean Coder』『Clean Architecture』など一連の本でも職人魂を持った規律あるプロとしての相応しい仕事をしていこう…という姿勢はたびたび語られていますが、本書でも色濃く続いています。
第3章 ビジネスプラクティス
ビジネス向けの4つのプラクティスを解説する章。
計画ゲーム
なるべく時間をかけずにできるだけ狭い範囲でより正しい見積もりをしていく話です。
- 三点見積り：最良ケース、最有力ケース、最悪ケースの3パターンで見積もりする方法。プロジェクト全体には有効だが細かい見積もりには効かない。
- ストーリーポイント：システムの機能をユーザーの視点からできるだけ簡潔に書いたもの。物理のインデックスカードに書く。
- ATMのストーリー：例をあげて、5機能をカードに書き、みんなで話し合いながら相対で開発にどれくらいポイントがかかるかを見積もる。ポイントは1〜6。そこから計画を立てていく。
- ストーリー：Independent(独立した)、Negotiable(交渉可能な)、Valuable(価値のある)、Esitmatable(見積り可能)、Small(小さい)、Testable(テスト可能な)の頭文字で
INVESTの特徴を持つ。アーキテクチャ改善やリファクタリング、コードをきれいにしていく作業はストーリーではない。 - ストーリーの見積り：全員が後ろを向いて指を出す「フライングフィンガー」、フィボナッチ数列を使う「プラニングポーカー」がある。その後グルーピングしたり細分化したり見積りが難しい機能を新たなストーリーにしていくのをスパイクと呼ぶ。
- イテレーションのマネジメント：各イテレーションでストーリーを開発していく。プログラマーが自分でアサインしていく。QAは自動テストを書く。
- デモ：イテレーションの終わりにステークスホルダーに対してデモをする。
- ベロシティ：受け入れテストを通過して開発完了したストーリーのポイントを数えて、そのイテレーションのベロシティが測れる。何回かやると平均が分かってくるようになる。
文中の流れだと「スパイク」の定義がよくわかりませんでした。こちらの記事などでスクラムにおける定義が書かれています。あるストーリーや作業を見積もって実際に行う前に、調べたりして明らかにしていく作業ということでしょうか。
一方AWSなどクラウドの世界では、WebサイトやAPIへのトラフィックが急に増えるのをトラフィックスパイクと呼びますね。
小さなリリース
- ソースコード管理の歴史：大昔のパンチカードの写真入り。出したりしまうのも大変なので、あるプログラムに対するプログラマーの占有時間が長かった。
- テープ：1970年代になるとこちら。依然として大変だった。
- ディスクとSCCS：1980年代にソースコードの置き場所はディスクに。ようやくバージョン管理システムが登場。SCSSのあとのRCSのあとのCVSでようやく楽観ロックが実現、プログラマーの占有時間が減ってサイクルタイムが減ってきた。
- Subversion：CVSの後がSVN。楽観ロックで複数人がチェックインできてサイクルタイムが大幅に減った。
- Gitとテスト：チェックアウトの時間がなくなった。歴史的な慣性でサイクルタイムが数日〜のままのチームもあるが、数分まで減った。
本文ではSubversionから楽観ロックを提供と記述されており、おいおいそれはCVSからできてるよ！と思ったのですが、すかさず訳注でツッコミがしてありナイスフォローでした。
ソースコード管理の技術が進化したので、コードを取り出す→修正→しまう の時間がどんどん短くなってきたという事ですね。
受け入れテスト
- ツールと方法論：プログラマーによる自動テストを支援するツールはいろいろあり、それが逆に混乱を招いた。
- 振舞駆動開発：
BDD: Behavier-Driven Development。テストから専門用語を排除してビジネス側の人達もやれるように考えた方法論も登場。 - プラクティス：結局はビジネス側の人がユーザーストーリーの振舞いをテストで記述し、開発者側がそれらのテストを自動化する。QAは様々なテストパターンを考えて、これまでのテスターより前方で活動する。
チーム全体
チーム全員が同じスペースで活動して能率を最大化する。チームプラクティスでなくビジネスプラクティスになる。
労働コストが安い国の労働力を使う方法は1990年代から始まったが、思ったほどコスト節約にはならなかった。その後のインターネットや技術の発展で家からリモートもできるようになったが、完全に同じ場所で働くほどではない。
結論
ビジネスと開発の分断を修復することが目標であり、ビジネスプラクティスはそれらを支援する。
2020年現在のコロナ禍のように、チーム全員がリモートでアジャイルは可能か？という話については、ボブおぢさんは全員が同じ場所で働くほどのパフォーマンスは発揮できない、とはいえ自分も離れたチームと過去うまくやった経験はある、というスタンスのようです。このへんのリモートアジャイル周りの話は、現在の日本でもいろいろ考えたり試したりしている方もおられるかと思います。
第4章 チームプラクティス
今度はチームについての話を述べています。
メタファー
制約と規律を持つ用語や概念をメタファーと呼ぶ。うまく使うとチーム内のコミュニケーションを効率化する。しかし顧客に不快感を与えるような悪い言葉をメタファーに使うと失敗する。
プロジェクトの用語辞書のようなものですかね。とあるプロジェクトでメモリ空間のバッファを「ゴミ収集車」と呼び、顧客のことを「ゴミの商人」と呼んで現場では笑っていた若気の至りのころを、をボブおじさんも反省しています。
その後かのエリック・エヴァンスのドメイン駆動設計が登場し、このメタファーに「ユビキタス言語」というもっと相応しい名前がつけられます。
- 作者:Eric Evans
- 発売日: 2013/11/20
- メディア: Kindle版
接続可能なベース
いつもの昔話が登場し、若き日のボブおじさん(18歳)が週80Hぐらい徹夜もして頑張ったが燃え尽きて、ソフトウェアも完成せず、結局周りと一緒に会社を辞めて飛び出した話が出てきます。週40Hの2倍、今だったら労働基準法で完全にアウトですね…
- 残業：技術的な過ちは、深夜の熱狂的な時間帯に作られることが多い。仕事は昼間にやるべきである。
- マラソン：ソフトウェア開発は短距離走でなく長距離走である。持続可能なペースを保って最後まで持ちこたえられるようにペースを配分していく。
- 献身：残業しても献身を示したとは限らない。残業によるコストが大きくなりやすいことを意識する。
- 睡眠：プログラマーの生活でもっとも重要。ちゃんと寝る。
ボブおじさんは1日7時間睡眠派で、6時間が続くと生産性が落ちてくるそうです。自分は平日は6時間弱なので、もっと寝なきゃな…と思いました。
共同所有
コードは個人でなくチーム全員で共有し、知識をチーム全員に広げようという話。その昔プリンターの開発にいた頃、社内文化のためにハードごとに分断されてしまっているソフトウェアに重複コードが多くて酷かったという昔話が登場します。
この共同所有はバージョン管理システムが一般化した現在では、アジャイルでなくともどこでもやっているかと思います。
継続的インテグレーション
最初の継続的ビルドツールは2001年に出たThoughtWorks社のCruiseControlだったという話が出てきます。
文中に出てくるツールだとJenkinsはオンプレ環境ではおなじみですね。これで継続的インテグレーションの間隔は数分まで縮んでいきます。
継続的ビルドは絶対に壊してはいけないという話で、壊したら専用の「私がビルドを壊しました」Tシャツを着る罰ゲームの小噺が登場します。このTシャツは洗濯していないそうでこれはヤですね...
スタンドアップミーティング
よく名前は聞くプラクティスですが、実は開催は任意で頻度も自由、10分以内がよいとされています。各自が話すことはシンプルに、何をしたか/これから何をするか/問題の3つ。
4つめで任意の質問を追加しても良く、「誰に感謝したいか？」がおすすめされています。#ここアジャ本にも出てきましたが、こういうのは良いですね。
結論
これらのプラクティスを使うことで、小さなチームが「本物のチーム」として振る舞うことができる。
第5章 テクニカルプラクティス
テスト駆動開発
- 様式簿記：TDDもこれと同じで、正しくあるべきな重要な対象物のエラーを弾く。
- TDDの3つのルール：失敗するテストコードを書いてからプロダクションコードを。失敗するテストは必要以上に書かない。プロダクションコードも失敗するテストコードの分だけ書いていく。
- デバッグ：TDDを実践しているとバグが減っていくので、デバッガーを使う機会、時間は減っていく。
- ドキュメンテーション：テストコードもサンプルになったりして対象機能のドキュメントになる。
- 楽しさ：3つのルールに従って先にテストを書いていくと、小さな挑戦と小さな成功の連鎖が楽しくなっていく。
- 完全性：デプロイして問題ないかを判定するために、テストのカバレッジは100%完全を目標としなくてよい。カバレッジはマネジメントの指標にしてはいけない。カバレッジが不十分でもビルドを失敗させてはいけない。
- 設計：TDDを実践するとテストが難しい機能を書けなくなり、自然とテスタブルな設計になる。TDDは設計手法と呼ばれることも多い。
- 勇気：TDDをやっていればコードを変更する恐怖がなくなり、クリーンにしていく勇気を与えてくれる。
自分も完全なTDDはやっていないのですが、テストを意識すると設計が良くなっていくことは同感です。カバレッジをマネジメントに使うな！と強く主張しているあたりには実体験が伺えます。技術やプログラミングが分かっていない管理職がいかにも言いそうですね……自分も経験あります。
リファクタリング
マーチン・ファウラー氏の書籍『リファクタリング』はここでも推奨されています。TDDとも強く結びついていますね。
- レッド/グリーン/リファクター：まずは失敗するテストを作成し、テストをパスさせ、そのあとリファクタリングデコードを変更、戻ってテスト…の繰り返し。リファクタリングは計画に入れるような活動ではなく、ソフトウェアを書くアプローチの一部である。
- 大きなリファクタリング：設計やアーキテクチャを変えたほうがよいことに気付いた時も、同じように小さなステップで少しずつコードを移行して行ったほうが良い。
- 作者:ＭａｒｔｉｎＦｏｗｌｅｒ
- 発売日: 2019/12/06
- メディア: Kindle版
シンプルな設計
- すべてのテストをパスさせる。
- コードは意図を明らかに。関数を分割し、名前を改良し、読みやすく表現を高める。
- 重複を排除する。いくつかのデザインパターンが使える。
- 要素を減らす。重複を排除したら、クラス/関数/変数など構造的な要素の数もできるだけ少なく。
設計が複雑になるとプログラマーへの認知的負荷が大きくなり、これを本書では「設計のウェイト」と呼び、できるだけ軽いほうが良いとしています。
しかし複雑な設計を使えば複雑な要求もシンプルに解決できる。機能に適切な設計を選択すればシステムの全体的な複雑さも減らせる。設計と機能の複雑さのバランスを取るのがシンプルな設計のゴールである、常に小さくリファクタリングし進んでいく…とあります。
『Clean Code』や『Clean Architecture』にあるように、常により良くすることを意識しながら、シンプルさを保って上手くやっていくということでしょうか。
ペアプログラミング
- ペアリングとは？：2人がナビゲーターとドライバーになってプログラミングの課題に取り組むこと。多くは1−2時間程度。スケジュールで決めるものではない。ストーリーはペアに割り当てるものではない。経験のあるシニアプログラマーは若いメンバーと組むべき。
- なぜペアなのか？：チームメンバの知識を共有するため。設計の品質が向上することが多く、コードレビューをペアリングに置き換えることもできる。
- コードレビューとしてのペアリング：コードを書きながらチェックするような動的なレビューとすることができる。
- コストについては？：算出するのは難しい。研究ではコストが15%増しとあり、コードレビューの代わりになれば生産性は落ちないことになる。
- 2人だけなのか？：別にもっと多くても良い。大勢で作業する場合は「モブプログラミング」と呼ぶこともある。
- マネジメント：マネージャーがペアプログラミングを禁止するような干渉は、自分の場合は見たことがない。あなたは専門家なのだから許可を得るのではなく、あなたが決めてやってほしい。
ペアプロ、モブプロは話は聞くけど未経験なので、実際どんなものなのだろうなーと思います。一方、比較的経験の浅い人の席の横で同じ画面を見ながら環境設定を手伝ったり質問に答えたり、コードレビューの結果を画面で伝えたりするのは自分もやるので、あれこれってペアプロに近いのでは？と思ったりもします。
最後のところでペアやテスト、リファクタリングなどの何かをするなら許可を求めてはいけない、自分で決めようと強調しています。これはグレース・ホッパー女史のエンジニア名言「許可を求めるな謝罪せよ(it's easier to ask forgiveness than it is to get permission.)」と通じますね。
結論
テクニカルプラクティスは、アジャイルの中でもっとも重要な要素である。
第6章 アジャイルになる
アジャイルの誤解を解き、Be Agileを解説する章。
アジャイルの価値基準
かのケント・ベック氏が４つの基準を上げていたそうです。
- 勇気：品質と規律で開発速度を上げて、小さな単位でデプロイする勇気を持つ。リスクを取る。
- コミュニケーション：高速で頻度の高い、混沌とした、インフォーマルなやりとりを重視。
- フィードバック：フィードバックの頻度と量を最大化し、有益な成果を出す。
- シンプリシティ(Simplicity)：直接的であること。コードもコミュニケーションも直接的にして、間接的なものを減らして、シンプルにする。
この文脈でのシンプリシティ＝シンプル ではないようですが、「シンプルであれ」というのはプログラミングの原則やアーキテクチャの原則でよく出てきますね。
動物のサーカス
様々なアジャイル手法が乱立したが、大きな混乱を巻き起こしている。「サークルオブライフ」の外側を実践しただけだとマーチン・ファウラー氏言う所の「ヘロヘロスクラム(Flaccid Scrum)」になる。完全なサークルオブライフを導入すること。
明確な用語ではないですが日本語でいう「なんちゃってアジャイル」みたいな、中途半端なアジャイルが蔓延してしまったということでしょうか。
トランスフォーメーション
アジャイルへの価値基準の移行について、中間管理職の層が障害になることが多い……と過去の実例を挙げています。
- 策略：あるプロジェクトでアジャイルへ移行でみんな楽しみに。しかしテックリードとアーキテクトが自分の役割がなくなると反対した。
- ライオンクラブ：大企業のある部門でVice President of Engineeringの人が頑張ってXP導入が雑誌に載るほどの成功。しかし次のVPoEが全部殺してしまった。
- 涙：証券会社のアジャイル移行プロジェクトで、うまくいっているように見えたが、難しくてついていけない人が実はいた。
- ごまかし：アジャイルに反対する中間管理職を満足させるように成果物を出しながら、内部ではアジャイルを密かに実行したチームもいる。
- 小規模な組織での成功：中間管理職の層が薄いので、成功することが多い。
- 個人の成功と変化：個人がアジャイルの価値基準を受け入れると、アジャイルでない組織ではうまくいかない時もある。同じ会社の中でアジャイルなチームを探すこともあるし、アジャイルを受け入れている会社にみんな転職してしまうこともある。
- アジャイル組織の作成：お堅い大きい会社では既存部門をアジャイルに移行するのではなく、アジャイルな組織を新たに作る形になるはずである。
ボブおじさんの予想では、大企業はアジャイル導入に際し、外部のアジャイルコンサルティング企業をより使うことになるだろうと述べています。日本では2020年代の今後どうでしょうか。
コーチング
一定期間アジャイルの振舞い方を教えるようなアジャイルトレーナーでなくアジャイルコーチは、時には必要となる時があるかもしれない。コーチはトレーナーではなくチームの一員。メンバーが交代で担当する。マネージャーではない。スクラムの考え方では、コーチは「スクラムマスター」となる。
スクラムマスターの認定資格については、最近はプロジェクトマネジメントの仕事をするだけのスクラムマスターを見かけるようになったと弊害を嘆いています。
認定資格
今あるアジャイルの認定資格は、「完全にジョークであり、完全にバカげたものである」とボブおじさん節が炸裂しています。チームの誰かでなく全員がとるもの、そしてあるとしたら半年ぐらいの長いコースだろうと述べています。
日本では以下の資格をよく聞きますが効果の方はいかほどでしょう。調べて知ったのですが、研修に20万～30万もかかるんですね！
www.agilebusinessinstitute-jpn.com scruminc.jp
大規模アジャイル
アジャイルはそもそも小規模～中規模のチームに関するもので、ソフトウェアに関するものである。大規模アジャイルなんてものは元から存在しない。
と熱弁を振るっています。
開発手法としてはSAFe: Scaled Agile Framework、LeSS: Large Scale Scrum が名前だけ出てきますが、本書では一笑に付される立ち位置です。日本だとNTTデータ、オージス総研などが資料を出していますね。
大きい組織であればその中を小さなチームに分割し、それぞれでアジャイルをやっていく……という話は日本の各方面のイベント資料などでも目にします。まずはそうするしかないのかなあと思います。
アジャイルのツール
- ソフトウェアツール：ここはアジャイル関係なく一般的に重要なツール。
- 便利なツールとは?：目的達成の支援になり、すぐ学習でき、ユーザにとって透明であるかのようにふるまい、拡張が可能で、安いこと。バージョン管理なら2019年時点ならGit。常に状況は変化することに注意。
- 物理的なアジャイルツール：ホワイトボードやカードやマーカーも使える。壁に貼り付けると情報ラジエーターになる。
- 自動化のプレッシャー：プログラマーなら自動化したくなるだろうが、物理的ツールの方が便利な場合もある。大事なのは使用しているツールが優れていること。
- 富裕層のためのALM：アジャイルライフサイクルマネジメント(ALM)というリッチな機能を持った商業ツールがいろいろ出たが、結局良いツールとはいえない。後からでも導入できるのでまずは物理ツールから。
ALMツールについてはかなり皮肉っています。まあ確かにいかにも儲け優先の企業がパッケージソフトのネタに考えそうな話ですからね。カードをシンプルなソフトウェアツールで実現するにはTrelloを勧めていて、これは日本でもよく見聞きしますね。
またホワイトボードにペタペタするのに「情報ラジエーター」というメタファーを使っており、オッこれはこの前読んだ #ここアジャ 本(『ここはウォーターフォール市、アジャイル町～』)と同じ喩えだ！と思いました。
コーチング(もうひとつの視点)
この節は違う視点をということで、違う意見を持ったデイモン・プール氏の執筆になっています。
- アジャイルにつながるさまざまな道：意図せずその道を歩むこともある。デイモン氏もその筋。
- プロセスの専門家からアジャイルの専門家へ：最初は苦痛だったが、アジャイルは「市場で高い価値を生み出す機能を見つけ収益に変えるアルゴリズム」だと理解した。
- アジャイルコーチングの必要性：アジャイルになるのは難しい。コーチングをして自分たちで課題を解決しゴールに届いてもらうのが良い。
- 普通のコーチをアジャイルコーチにする：書籍『Coaching Agile Teams』があり、認定アジャイルコーチ(ICP-ACC)の学習目標になった。
- ICP-ACCを超えていく：認定には様々なスキルがあり合格には大量のトレーニングも必要。
- コーチングのツール：質問やゲームプレイ、その他もツールがいろいろ増えている。
- プロフェッショナルコーチングのスキルでは不十分：プラクティス群を知らないチームにティーチングをすることもある。
- 複数チームのコーチング：最近のアジャイルコーチングは複数チームに対して行っている。
- 大規模アジャイル：アジャイルの導入をアジャイルの取り組みとして扱い、コーチングのスキルを適用する。
- アジャイルとコーチングでアジャイルになる：様々なプラクティスで構成された既製品のレシピをフレームワークとして使いながら行う。
- アジャイルの導入を広げていく：ニーズに合致するプラクティスを選んで試していくと良い。
- 小さく集中して大きくなる：複数チームにアジャイルを導入すると、複雑なことに対応する際に問題が多い。チーム間調整に使えるプラクティスもある。
- アジャイルコーチングの未来：明るい！
と、こちらはアジャイルコーチや大規模アジャイル手法を肯定する立場からの意見となっています。
結論(再びボブから)
本章は「何をすべきでないか」を述べてみた。
大規模アジャイルに夢を見る若者に噛みつく年寄りの雷オヤジみたいなものだ……と自分のことを表現しつつ、ボブおぢさんご本人は大規模アジャイルなんてものは存在しない！認定資格はゴミだ！と吠えています。一方で最後の節の担当のデイモン氏はコーチングや認定資格も整ってきており、大規模アジャイルも可能だと述べています。
うーんこのへんどちらか片方が結論という問題ではないですね。この先10年、日本でどうなっていくか慎重に見ていきたいところです。
第7章 クラフトマンシップ
最初は開発者たちに興奮をもたらしたアジャイルですが、業界を席巻して何処の会社もこぞって導入したあとは伝言ゲームのように間違って伝わり、ソフトウェアを高速に提供するプロセスに変わっていった……
と悔恨を漂わせながら、そのあたりの伝わり方とアジャイルの新しい分派的な「クラフトマンシップ」を解説する章。
アジャイルの二日酔い
アジャイルが企業に広まり、マネジメント層に伝わると、従来型のマネジメントに利用されるようになってしまった。アーキテクチャや設計を考える余裕はなくなり、単にバックログを消化するだけになり、マネージャーは敵のままである。「我々対彼ら」の文化がそのままである。
これを本書では「アジャイルの二日酔い」と称しています。
期待の不一致
アジャイルでは開発者は新しいプラクティスを習得する必要があり、予算やスケジュールが必要だが、単に協調して作業すれば仕事が速くなると思われている事が多い。定期的なリリースを習慣的に行うにも様々な規律と高度なエンジニアリングスキルが必要だが、このへんが企業側に理解されていない事が多い。
開発者のアジャイル離れ
アジャイルトランスフォーメーションを実施した後ビジネスはうまくいくようになったが、開発者たちは指示をしてくるアジャイルコーチを新しいマネジメント層だと見なすようになった。アジャイルと開発者がお互いに離れようとしている。
ビジネスをより良くするのに技術も重要であることに企業がまだ気付いていない。今でもアジャイルは、ソフトウェア開発の実践あるいは実践を手助けする活動を通じて、よりよい開発方法を見つけ出そうとしているのだろうか？
「私にはよくわからない」…と語りつつ、アジャイルが正しく広まっていないことを嘆いています。
技術書の類を読むとアジャイルは頻繁に出てくるため、アメリカではもう浸透しているのかなと思いますが、やっぱり表面的にアジャイルをなぞっただけで導入したつもりになっている企業は、海外でもまだまだあるのかなーと思います。
ソフトウェアクラフトマンシップ
プロの仕事の基準を引き上げてアジャイルの本来の目的を再構築しようと、開発者グループがシカゴに集まって2008年に作った新たなムーブメントが「ソフトウェアクラフトマンシップ」。
動くソフトウェアだけでなく、精巧に作られたソフトウェアも
変化への対応だけでなく、着実な価値の付加も
個人との対話だけでなく、専門家のコミュニティも
顧客との協調だけでなく、生産的なパートナーシップも
こちらのブログにも原文と日本語訳のニュアンスの記事があります。
こちらも何千人もの開発者が同意してくれてアジャイル初期の興奮が復活。そして今度はあくまで開発者のものであるよう、ムーブメントが乗っ取られないように誓ったとのことで、それだけアジャイルは広まって変容して利用されてしまったのだなあと思います。
イデオロギーとメソドロジー
アジャイルマニフェストの12の原則にはイデオロギー(根本的な考え方)があり、それを実現するための様々なプラクティスがメソドロジー(方法論)に当てはまる。
プラクティスは目的達成の手段であり、原則がないまま単に実行してはいけない。プロであればニーズに応じて使っていくのだ……と述べています。
ソフトウェアクラフトマンシップにプラクティスはあるか？
陳腐化を避けるために特有のプラクティスはなく、よりよいプラクティスを追求し続けることが良いとされているそうです。
- XPは常に最高のプラクティス
- TDD、リファクタリング、シンプルな設計、CI、ペアプログラミングはXPのプラクティスだが、これも支持
- クリーンコード、SOLID原則、小さなコミットとリリース、継続的デリバリー(CD)、あらゆる自動化、堅牢で柔軟なソフトウェアを生み出すプラクティスも推奨…
と、技術寄りであくまで開発者にフォーカスし、時代の変化に合わせて良いものはなんでも取り入れていくというスタイルに読めます。
プラクティスでなく価値にフォーカスする
よくある間違いが単にプラクティスだけを推奨すること。最初に話し合って達成したい目標について合意するのが大事。提案されたプラクティスに代替案を出さずに否定するのは絶対だめと述べています。
プラクティスの議論
プラクティスを取り入れるかがテクノロジーにしか関係ない場合は開発者だけで議論。ビジネス側のコストや期間に影響するビジネスの価値の話である場合はビジネス側の人間と開発者側の人間の双方で会話。
その場合は「なぜ」「いつ」「何」を重視し、「どのように」やるかは開発者側で決め、許可を得るのでなく自分たちから行うべきだ...と述べています。
クラフトマンシップが個人にもたらすインパクト
クラフトマンシップとしては、単に仕事でやるのでなく職業としてソフトウェア開発を行うことを推奨。プライベートを犠牲にせよと言っているのではなく、人生に意味を与えてくれ、個人としての喜びと充実感を得ることのできる、スキルを高めてキャリアを築ける職業としてソフトウェア開発者をやっていこうと述べています。
このあたりはこちらも名著の『達人プログラマー』や『情熱プログラマー』などに共通する、誇りと規律を持ったプロフェッショナルの姿勢をもってやっていこうという話とも通じますね。
- 作者:Andrew Hunt,David Thomas
- 発売日: 2020/11/21
- メディア: 単行本
- 作者:ＣｈａｄＦｏｗｌｅｒ,でびあんぐる
- 発売日: 2017/07/15
- メディア: Kindle版
クラフトマンシップが業界にもたらすインパクト
アジャイルは人とプロセスに重点を置くがクラフトマンシップは技術的な側面に重きを置き、様々なコミュニティで技術を学んだり広めたりしてきた。あらゆる開発者を歓迎し、安全で有効的な空間で、次世代の開発者にも居場所を用意しようとしている。
クラフトマンシップが企業にもたらすインパクト
ソフトウェアクラフトマンシップはアジャイルのようにビジネス的な魅力がないため、多くのマネージャーはあまり理解していなかったり落ち着かない感じになっている。2000年代初頭のアジャイルコーチは技術的なバックグラウンドを持っていたが、現代のアジャイルコーチはそれがない。
それでも企業でシステムを上手く作っていくためのモチベーションの高い有能なチームを作っていくために、ソフトウェアクラフトマンシップは役に立つ。物事をうまくやることに熱心であり、新しいことを学んだり、学習する文化を持つのは企業にも役に立つし開発者にもインスピレーションを与える。
クラフトマンシップとアジャイル
アジャイルの方向性に不満を抱いた開発者が多かったことも、クラフトマンシップのムーブメント誕生に関係している。ビジネスや人々の問題を軽視していて視野が狭いと、アジャイルとは相容れないものだと感じている人もいる。一方でアジャイルのムーブメントに参加していてその後クラフトマンシップにも参加している人もいる。
双方から批判がされているがどちらも似たようなことを達成しようとしていて、どちらもプロフェッショナリズムを求めている。協調的で反復的なプロセスだけでなく優れたエンジニアリングのスキルもビジネスのアジリティ達成に必要であり、アジャイルもクラフトマンシップも両方組み合わせれば良いと述べています。
結論
この2つのムーブメントの価値観は強く関連しており、いつの日にか再び一緒になってほしい…というあたりに、アジャイル創設時から関わってきたボブおじさんの気持ちが伺えます。
この「ソフトウェアクラフトマンシップ」というのは日本であれば、会社の枠を超えて活動していたりイベントに行ったりコミュニティで活動したり継続的に学びを続けていたりITエンジニアとしての姿勢を持っていたりする、多くの方にズバリそのまま当てはまることではないでしょうか。
今このブログをご覧の方にも多いのではないかと思います。技術の側面に重きをおいている分、技術志向のITエンジニアにはアジャイルより親しみやすいんじゃないかなと思いました。
結論とあとがき
後半の章では時代と共にアジャイルの受け取られ方が変わってきたことも述べつつ、Uncle Bobは創設時のメンバーとしてアジャイルが雪玉のように転がって大きくなり、ぶつかったりしながら進んでいくのを見るのは楽しかったと述べています。
アジャイルの基本となる価値や原則、規律は変わらない、ソフトウェアエンジニアリングの世界で多くの偉大な人々が語ってきた事とみなどこかで繋がっている。こうした根っこの部分は真実であり、いつでも意味を持ち、ソフトウェア開発の中核なのだ……と最後を締めています。
また訳者あとがきでも、IT界のバズワードとしてアジャイルが不正利用されてきたこと、2010年代ではアメリカでもアジャイルが「死んだ」時代だったこと、そして今こそアジャイルの基本に立ち戻る時である話が語られています。
最後のサブタイトル「幼年期の終わり」がSFファンの僕の心を捉えて離さないのですが(といいつつ原典は読んでないｗ)、「次世代の開発者に居場所を用意する責任がある」というのはエンジニアとしても心に留めておかないとなあと思いました。
- 作者:アーサー C クラーク,福島 正実
- 発売日: 2012/12/21
- メディア: Kindle版
まとめ：ボブおぢさん節でアジャイルの源流と歴史を再確認できる本
まさに Back to Basics、基本に立ち戻れ。アジャイルマニフェスト創設メンバーの一人自らが語るアジャイルの原点回帰ということで楽しく読めました。Cleanシリーズの他の本に比べると実は薄いので、読みやすいと思います。
アジャイルマニフェスト宣言は伝聞でしか知らなかったので、なにやら凄いイベントのように勝手に思っていたのですが、1章を読むと実はもっと親近感のある地に足の着いたイベントだったのが分かります。1～2章のあたりでアジャイルの本質を語る部分も、いつもの調子でズバズバ痛快に書かれているので原点での考え方がよく読めます。
Cleanシリーズはどれも主張が強いのでそこが読んでいて面白いのですが(おい)、本書でもボブおぢさん節は健在。
大規模アジャイル？→(ほぼ)全否定！ 認定制度？→バカげてる！ コーチ？→いらん！ の流れを見ていると、さすがワイたちのUncle Bob、この本でもぶれない平常運転だぜ……と思います。もちろん大規模アジャイルをうまくやっている方、模索している方もおられるでしょうし、賛否両論いろいろあるでしょうね。
また本書ではアジャイルはソフトウェア開発にフォーカスしたものだ、となっています。この前読んだ『ここはウォーターフォール市、アジャイル町』(#ここアジャ)ではアジャイルは開発だけのものではなく運用にも使えるんだ……というスタンスになっていますし、このへんもアジャイルという思想が広がっていく中で考え方は様々あるのでしょう。
他の本に比べると少なめですが、恒例のパンチカードの話などいつもの昔話も健在。この方は昔話の持ちネタを一体幾つ持ってるんだろう……と思います。
脚注に加えて訳注も多く、ところどころUncle Bobの記憶や詳細が曖昧な所をフォローしています。冒頭でも、プログラマーの人口も「現在では一億人に近づいている(ﾄﾞﾔｧ...)」 →訳注ですかさず「1億人は言い過ぎで、実際には数千万人だと思われる」と冷静に補足していたりして、ナイスツッコミもといフォローが光っています。
一連のCleanシリーズでは職人魂を持ったプロフェッショナルとして、誇りを持った職業エンジニアとして、良い仕事をしていこうという姿勢が一貫してあり、本書でもそれは続いています。7章で語られている「ソフトウェアクラフトマンシップ」もまさにこれを具現しています。
このあたりはもうアジャイルを実践しているかどうか関係なく、エンジニアとして生きていく上で学びになるし、全部ではなくともお手本にしたいものです。
僕の属しているエンタープライズな世界ではアジャイル開発は広まっているとは言い難いですが、じゃあ伝統のSIerといえばガッチガチのウォーターフォールをいつでもやってるのかというとそういう訳でもありません。
社内にはアジャイル愛好家のコミュニティもあるし、いろんな仕事の中で「あっいま実はアジャイル的なアプローチをしてるな」と思うこともあるし、今後の変化に向けた施策や資料の中で、根本はアジャイルと通じているであろう事柄が出てくることも増えてきました。
アジャイルの幼年期が終わった今後の2020年代、日本企業でアジャイルがどう受け止められていくか、広がっていくのか。本書にある「次世代の開発者に居場所を用意する責任がある」先輩エンジニア(のはず)の一人としても、注意深く見ていこうと思いました。
おまけ クリーン本シリーズ
『アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技』がアジャイルを語る文脈でよく出てくるロングセラー。原著が2002年、翻訳が2008年。
アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
- 作者:ロバート・C・マーチン,Robert C. Martin
- 発売日: 2008/07/01
- メディア: 単行本
『Clean Code アジャイルソフトウェア達人の技』が原著2009年、翻訳が2017年。こちらはコードを書く際の諸々にフォーカスした本。当ブログにも先日感想を載せました。
- 作者:Robert C.Martin
- 発売日: 2017/12/18
- メディア: 単行本
『Clean Coder プロフェッショナルプログラマへの道』が原著2011年、Kindle版が2018年に出ましたが紙の本は2012年からあり、帯の色が違います。プロフェッショナルなプログラマーとしての在り方、仕事への取組みの姿勢などにフォーカスした本。
- 作者:Robert C. Martin
- 発売日: 2012/01/27
- メディア: 大型本
Clean Coder プロフェッショナルプログラマへの道 (アスキードワンゴ)
- 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典
- 発売日: 2018/08/01
- メディア: Kindle版
『Clean Architecture 達人に学ぶソフトウェアの構造と設計』が原著2017年、翻訳2018年。エンジニア界隈でも大きく話題になりました。当ブログでも感想と自分なりの解釈をのせています。
Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)
- 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘
- 発売日: 2018/08/01
- メディア: Kindle版
最初の『アジャイルソフトウェア開発の奥義』以外は読破したので、これでUncle Bobのクリーンな職人魂を少しは分かってきたぜ……という気持ちになりました。本書『Clean Agile』についてはUncle Bobご本人＋訳者陣の皆さんが揃っているインタビュー動画もあります。(字幕付き)
