Clean Agileを読みました

こんにちは。食べログのフロントエンドチーム の荒川です。
先日、「Clean Agile 基本に立ち戻れ」を読みました。
本日はこの本の要約を、私たちのチームの活動を交えてご紹介しようと思います。

著者の Robert C. Martin氏は、アジャイルマニュフェストの創案者の一人で、
国際的なソフトウェアコンサルティング、スキル開発を行っています。
https://agilemanifesto.org/iso/ja/manifesto.html

1章 アジャイル入門

アジャイルの歴史

アジャイルの歴史は５万年以上前、人間同士が協力して、共通の目標を達成しようとしたことが始まりと述べています。ソフトウェア開発においては、アラン・チューリングがチューリングマシンの論文を執筆した1936年の当時や、1946年にACE（Automatic Computing Engine）のために書いた最初のコード開発が、小さいステップを反復するアジャイルのような振る舞いで行われたのではないかと推察しています。

ウォーターフォールの誕生

1970年にウィンストン・ロイスが大規模なソフトウェアプロジェクトを管理するアイデアを論文にまとめた。
この論文には、論文の後半で論破する予定の図が書かれていたが、論文の1〜２ページ目に記載されていたため、この図から論文の内容が推測され、結果としてソフトウェア業界に劇的な変化をもたらすものとなった。

（引用元 https://en.wikipedia.org/wiki/Winston_W._Royce）

ソフトウェアの開発手法を学ぶと必ず出てくる、ウォーターフォールが誤解から生まれていたというのは興味深いです。元々、ロイスの論文は反復型の開発を提唱していて、現代に通じているとても先見性があるもののようでした。

スノーバード
アジャイルマニュフェストが創案されるに至った経緯が当事者の視点で語られています。（気になる方は本著をぜひ読んでください）

マニュフェスト自体は知っていましたが、本著を読むとなぜこの文章に至ったのか、理解に近づくことができたように思います。

アジャイルの概要
ソフトウェアの開発は「品質」「速度」「費用」「完成」のトレードオフであり、このバランスをマネジメントする手法について述べています。中でも興味深かったのが、以下の一文です。

アジャイルとは、どれだけうまくいっていないかをできるだけ早く知ることだ。

開発の当初は実績が何もないため、希望的な予測でプロジェクトが計画されることがままあります。
この希望を打ち砕くため、マネージャーは実態のデータを収集し、プロジェクトの成果を最高にすることがマネジメントであると語っています。

2章 アジャイルにする理由

数十年前とは異なり、現代においてはあらゆるものがソフトウェアの制御で動いています。
そんな状況の中で、顧客が期待する品質のシステムを、どのようにして安定した生産性と安価な変更コストで届けるかという点について触れています。

また、後半では顧客・開発者それぞれの立場が有する権利と、保つべき規律について述べ、アジャイルはこれらを形作る権利・期待・規律の一式であると締め括っています。
以下が具体的な権利の一部の要約です。

顧客
・再現可能なテストを通じてシステムが機能すること、システム開発の進捗度合いを知る権利
・機能を途中で差し替えたり、プライオリティを変更する権利
・発注を取り消し、その時点までの投資に見合った機能するシステムを手にする権利

開発者
・要件と、プライオリティを知る権利
・質の高い仕事をする権利
・責任を自ら引き受ける権利

著者はアジャイルにする理由は、顧客・開発者それぞれの立場で、互いにプロフェッショナルとしてプロジェクトを成功に導くことが重要だからであると述べています。

アジャイルといえば、開発の手法やツールに目が行きがちですが、根本となる倫理観が抜け落ちたままでは、単なるプロセス論になってしまうということなのでしょう。

3章 ビジネスプラクティス

アジャイルでプロジェクトを成功させるためのプラクティスについて触れています。「プランニングポーカー」「継続的ビルド」「受入テスト」などがキーワードです。

また、顧客と開発メンバーが同じ場所で働くことも重視しており（昨今の事情では厳しいかもしれませんが…）、週に1〜2日は同じスペースで作業することによる、非言語的なコミュニケーションや、会話、即席のミーティングなどがコミュニケーションのミスを無くし、信頼を産むことに繋がると述べています。

私たちのチームでは、コミュニケーション不足に陥らないように、チャットルームに作業部屋を立てたりして、工夫を行なっています。

詳しくはこちらの記事に。

4章 チームプラクティス

3章に続いて、こちらではアジャイルなチームとして振舞うためのプラクティスについて述べています。
チームのコミュニケーションを円滑にするための「ユビキタス言語」、「持続可能なペース」、知識の「共同所有」、開発中の些細な修正でも「継続的なインテグレーション」で統合することなどがこの章のキーワードです。

5章 テクニカルプラクティス

5章では、アジャイルな開発を行うためのテクニカルなプラクティスについて紹介しています。
「TDD」「リファクタリング」「シンプルな設計」「ペアプログラミング」などが主な内容です。

FEチームでもこれらのプラクティスは取り入れており、リモート環境ながらも習慣的に取り組んでいけるようになりました。これらについては、今後、別の記事でご紹介すると思います。

実際、チームの開発にTDDとペアプログラミング、モブプログラミングを取り入れてからはコードの粒度が個人のスキルや思考によらず、かなり均一化されてきていると感じています。また、テストが必ずセットであるため、リファクタリングも取り組みやすく、クリーンなコードを保っていけています。

7章 クラフトマンシップ

アジャイル開発が普及するにつれて、ビジネスの高速化を重視するあまり、エンジニアリングで価値を生み出すような自動化テスト、リファクタリング、ペアプログラミングなどのプラクティスがおろそかになってしまうような事態が起こりつつありました。これを危惧してソフトウェア開発の水準を引き上げ、アジャイル本来の目的を再構築するために2008年11月に始まった新しいムーブメントが「ソフトウェアクラフトマンシップ」というものです。

アジャイルはソフトウェアプロジェクトの人とプロセスの側面に重点を置いていますが、クラフトマンシップのコミュニティは技術的な側面に重点を置いており、価値観が異なっています。

しかしながら、よく似た目的を達成しようとしていて、著者も「この2つのムーブメントは分けるべきではない。願わくばいつの日にか、両者には再び一緒になってもらいたい。」と締め括っています。

直近の食べログでは、エンジニアリングによってリリース速度を改善したり、プロダクション環境を整備してログのトレーサビリティを上げたりしていました。これらのように、エンジニアリングでサービスの価値を上げることもエンジニアのミッションで、2つの価値観をバランスよく保つことがソフトウェアの価値の向上に繋がると思っています。

まとめ

アジャイルとは所定の手法ではなく、概念のようなものであり、根本にはソフトウェア開発に対する顧客の期待を最高にするという思いが詰まっています。

私もこれまでアジャイル開発はしてきたつもりですが、改めて序盤の部分を読むと、アジャイルの倫理観的な部分が薄れて行っているのを感じ、身につまされる思いでした。

当時と比べるとコンピュータの性能や、アジャイルにまつわるツールは比べ物にならないくらい進歩していると思いますが、実際に開発に携わる顧客・開発者の観念も揃ってはじめてアジャイルな組織になれるということを忘れないように日々の業務に取り組みたいと思います。

最後に

現在、食べログではフロントエンドに関わるポジションとして以下の２つを募集しています。

気になったかたは是非チェックしてみてください！

・フロントエンド統括チームに所属するフロントエンドエンジニア
・フロントエンドをメインにサービス開発を担当していくWEBエンジニア

・難しい課題にチーム一丸となって取り組みたい
・React/TypeScriptでバリバリ開発したい
・レガシーなシステムのリファクタリングがしたい
・アーキテクチャについて探求したい
・食べログというプロダクトに貢献したい
・大規模なシステムの開発に携わりたい
・柔軟に働ける環境で自分のスキルを活かしたい

どれかに当てはまった方は以下のリンクも是非御覧ください！