
- 作者:JonathanRasmusson,西村直人,角谷信太郎
- 発売日: 2017/07/14
- メディア: Kindle版
本棚から発掘した『アジャイルサムライ』を久しぶりに読み返した。
同じ著者による『ユニコーン企業のひみつ』が話題になっていたから…というわけでもないけど、たまたま最初に読んだ時以来読み返していなかったなーと思って。
原著は2010年出版、翻訳も2011年に出版されているので、もう10年経っている。その元となるアジャイルマニフェストが2001年の発表なので、20年経っていることになっている。
たぶんこの10年でもインフラとしてのクラウドの利用や、企業活動におけるソフトウェアの重要性の高まり、またそれを契機としたソフトウェア開発の内製化への回帰…いろいろな要素がアジャイル向きの環境に変わっていってきている。
結局SoE型のシステムが増えてきていて、プロジェクトって形で明確な切れ目を定義するのが難しくなってるんですよね。プロダクトとして仮説検証という方向がやはり増えてきてはいるので。
— カルロスわらふじ@牛勢 (@RyoMa_0923) May 9, 2021
企業活動とソフトウェア開発が不可分になれば、それはもうプロジェクトではない。プロジェクトは有期であることがその定義だが、企業活動は(一般的には)無期だからだ。
従来のOA化や、業務改善であれば切れ目も作れるか、企業活動に切れ目は無い。ずっと続けていかないといけないし、その中で変化していくことが求められる…それが早いか、遅いかは業務特性に依るが、その活動をスケールさせるためのソフトウェアの変化も、そのスピード感に依っているわけで。
アジャイル対ウォーターフォールという対立軸で見てしまうと、それは違うと思っていて、要は自分たちが必要としている要素に合致しているか否かじゃないかと思っている。
で、そんなことを考えながら『アジャイルサムライ』を読み直してみると、前半がもう全然アジャイルに固有ではない、普遍的なソフトウェア開発のノウハウの話だった
『アジャイルサムライ』を読み直しているけど、前半はほとんどアジャイルは関係無くて、普遍的な「ソフトウェア開発を成功させるための要素」が書かれている
— magnoliak🍧 (@magnolia_k_) 2021年5月9日
仮に、『できる!ウォーターフォール開発」って本が書かれても前半はほぼ同じになると思うんだけど
ウォーターフォールは計画の変更に関わるコストが大きくなりがち(ドキュメントなど付帯成果物が多い)、そのコストを細切れにしてリスクを小さくして、変更・手戻りと見せないところにアジャイルのポイントがあるわけでは
— magnoliak🍧 (@magnolia_k_) 2021年5月9日
権限が適切に委譲されてて、メンバが自律した自走組織を形成していて、顧客がしっかり参加していて、計画変更が折り込まれていて…そりゃ成功するよね!! https://t.co/yxfqQCCioh
— magnoliak🍧 (@magnolia_k_) 2021年5月9日
ウォータフォールだったら開発チームに権限はなくてもいいとか、チーム間は縦割りでもいいとか、顧客は参加しなくていいとか、自己組織化されていなくていいとか、メンバはプロフェッショナルでなくてもいいとか、熱意はなくてもいいとか、そんなことを言う人はいないと思うんですよね。プロジェクトスタイルの方法論ではなく、プロジェクト運営の問題をウォータフォールというラベルで代用していませんか?という話で(というか、この本の中でもべつにウォータフォール批判はされていないんですよね)。
というわけで、自分のプロジェクトがアジャイルかどうかは関係なく、読んでみるといいなと思います。後半はよりアジャイル向きのプラクティスになっていきます。
とはいえ、プロジェクトの可視化、テストコード、リファクタリング、継続的インテグレーションなどは、アジャイルとは切り離しても有効なプラクティスになってきているので、実質は「第8章アジャイルな計画づくり:現実と向きあう」と、「第9章イテレーションの運営:実現させる」「第10章アジャイルな意思疎通の作戦」くらいだったりしますが。
あと、なんとなくですけど、あんまりこの本で語られているアジャイルって、自社サービスというより、コンサルティング会社やSIerみたいな、業態が受託でソフトウェアを作るシチュエーションが暗黙の前提になっているなーって感じました。同じ会社に居るプロダクトオーナーが非協力だったら、そもそも事業を運営する体裁が整っていないだけかなと。その辺は実は自社サービスのアジャイルは、また違うような気もします(よくアジャイルは自社開発じゃないと無理みたいな論調もありますが、そうとも限らないと、この本を読んで思いました)。
なお、この本でぜひ読んで欲しいところといえば「5.4 何を諦めるのかをはっきりさせる」です。
最近有名な「荒ぶる四天王」こと、「時間」「予算」「品質」「スコープ」のトレードオフについての話題です。
はるか昔、とある方に「我々は、”まだどのくらい品質を落とせば、どのくらいコストが落とせるか”、という相関関係をコントロールできるような技術は持っていない」と言われたことが強く記憶に残っていて、この本でも書かれている通り、品質は高い水準で維持するしかないんです。
バグの数を5%増やせば、コストが10%低下する、その際の事業リスクは最大で10万ドルです、みたいな計算式は作れないのです。
最後に、昔オンプレ主体の時代だと、そもそもインフラの購入・設置・構築にすごく期間がかかり、その前段のアーキテクチャ検討も含めてプロジェクトスケジュールの基礎がそこに依存していたプロジェクトも多かったと思うんですけど、そんな時代のアジャイルはどんな風景だったんでしょうね。イテレーションゼロの時点でどこまでインフラを揃えていたんでしょうね。ちょっと実体験をしていた方々に聞いてみたいところです。
というわけで10年経っても色褪せない名著なので、未読の方はぜひ読んだ方がいいですよ。きっとあと10年後でも役に立っていると思える1冊です。