yn2011's blog

技術メモ

書籍「Clean Agile」を読んで、アジャイル開発の正しさを支えるソフトウェア開発の経験則について考えた

書籍「Clean Agile 基本に立ち戻れ 」を読んだ。

この書籍は、アジャイルソフトウェアマニフェストを策定したスノーバードの会議の主催者でもある Robert C.Martin 氏 が、近年広まっているアジャイルに関する誤解を解くために、アジャイルの歴史やアジャイルとは何なのかについて改めて説明しようという趣旨で書かれている。

書籍全体を通じて、「アジャイル開発の正しさはソフトウェア開発に関するいくつかの経験則が正しいということを前提にしている」ような記述が多かったことが個人的に面白かった。著者のロジックとしては、これらの経験則が真であるからこそウォータフォール開発は失敗しアジャイル開発が妥当な開発プロセスなのだ、ということのようだった。

これらの経験則は書籍の中で1つのリストとしてまとめられているわけではなく、文章の流れの中で必要に応じて言及する形になっているので、抜粋して一覧にしてみると便利そうだなと思いリストにしてみた。

アジャイル開発を導入する際には、いきなりプラクティスの説明から入るのではなく、始めにこれらの素朴な経験則についてビジネス側・エンジニア側双方で意見を交わしておくことでアジャイル開発に対する納得度が高まる気がする。

以下が書籍に登場していた経験則の一覧(もしかしたら他にもあるかもしれない)

経験則① エンジニアは開発に要する作業時間を正確に見積もることができない

はい。ここまできっぱり断言されると気持ち良い感じがする。

実際にコードを書き始めてみると、当初の見積もりとは全然違う工数になりそうだと分かるという経験はエンジニアならあるあるだと思う。そういう場合に大体の人は見積もりが間違っていたかな、次はこうしよう等と反省する。そして運が悪いとマネージャーに「なぜ見積もりを間違えたのか」あるいは「バッファを積みすぎたのではないか」などと質問されて「すいません」みたいなことになったりする。

しかし、ソフトウェアの複雑さを事前に評価することはできないので、この経験則では正確な作業時間見積もりはそもそも不可能だという。これはエンジニアの能力や態度の問題ではなく、ソフトウェアの性質という本質的な問題なのでどうしようもない。

そもそも不可能なことを上手くやろうとしても仕方がないので、アジャイルでは事前の見積もりの精緻化ではなくイテレーションの実績を元にしてスケジュールの問題に対処する。

具体的にはユーザーストーリーという最小限の機能単位と、相対見積もりによる曖昧な数値(ストーリーポイント)を使用して、実績ベースでプロジェクトの残作業(開発対象)やチームの速度を定量化する。

このユーザーストーリーを利用する背景についての明確な説明も自分はこの書籍で初めて知って、ああユーザーストーリーは本来そういうことがしたかったんだなーと腹落ちした感が凄くあった。

経験則②ソフトウェア開発プロジェクトの時間見積もりは不確実性が高い

これは経験則①が真だと仮定するなら当然で、個別の開発タスクを正確に見積もれないのだから、その総和としてのプロジェクトの時間見積もりも正確にはできない。正確にできないどころか大幅に上下する可能性が高い。

また、(特にウォーターフォール開発では)プロジェクトの終盤で要件が変更になったり、想定以上の不具合が検出されるなど、とにかくプロジェクト中は最後まで何が起こるか分からないというのはエンジニアなら感覚として分かることではある。

ウォーターフォール開発で定番のガントチャートは横軸に時間を取るが、そもそもプロジェクトの時間見積もりは不確実性が高いので当然スケジュール通りにはいかないよね、そんなことするよりならユーザーストーリが残り何ポイント分残っているかを視覚化する長期のバーンダウンチャートを使って... みたいな話になっていく。それだけでなく、アジャイルでは各イテレーションで常にリリース可能な状態を保つので、ウォーターフォールのようにプロジェクト終盤のリスクもほとんどない、むしろ時間が経過するほどに実績を元にした見積もりが正確になっていくのでアジャイルは良いよねという話にもなる。

経験則③遅れているプロジェクトへの要員追加は更にプロジェクトを遅くさせる(ブルックスの法則

Frederick Phillips Brooks 氏が書籍「人月の神話」で提唱した法則。遅延プロジェクトに要員を追加すると更に遅延する。理由として人月の神話では以下のように説明している。

  • 追加された要員のオンボーディングに時間がかかるので既存メンバーの時間が奪われ追加前より遅延する
  • 開発対象が分割不可能なら(順次的制約が強いなら)そもそも要員を追加しても意味がない(妊婦さんを集めても出産は十月十日かかるしかないという有名な例が人月の神話にある)
  • 仮に開発対象が分割できるなら追加要員のために作業を分割するという作業が追加で必要になる
  • 分割された作業間でコミュニケーションが必要な場合は(大抵のソフトウェア開発が該当する)以前よりも更にコミュニケーションに時間が取られて進捗が遅くなる

ブルックスの法則については既に研究論文で実証もされている、らしい*1。研究の結果として法則は大きくは間違っていなさそうという結果が得られているし、ソフトウェア開発の業界でも多くの人が正しいと認識していることなので、これはもう経験則というより事実と言ってもいいのかもしれない。(ちなみに研究によるとプロジェクト初期の要員追加に限っては有効らしい。まあ初期ならそんなに遅延もしてないし当然なような気もするが)

経験則④品質を下げても(汚いコードを書いたりテストを省略しても)プロジェクトは加速しない

コードレビューやテストコードを省略して開発時間を短縮するというのは個人的によく見聞きする話ではあるが、本書ではこれも明確に間違っていると断言している。

理由としては

  • 汚いコードが積み上がると不具合が多くなって修正も困難になるし、機能追加も難しくなる(それはそう。わかりみが深い)
  • チームの新規参画者が既存コードを理解しにくい上に、新しく書かれるコードの水準がその汚い既存コードに合わせられるから

むしろ品質を上げることが速度に繋がると強調されていた。一見分かりにくいけどそうなんだよなあ。

この話は有名なスライド「質とスピード」でも取り上げられている。

更にスライド中で、「そもそも上手くコードが書けない人はどれだけ時間を与えても結局は同じようなコードしか書けない」という経験則を述べるツイートが引用されている。これが正しいとするなら、品質を上げるためにはハイスキルなエンジニアを採用するか育成するしかないことになる。だからジュニアのエンジニアはチームに不要なんだとまでは言わないが、ペアプログラミングやレビューをして品質を期待する水準まで高める必要がある(余談だがこういうところでも、「人月」という人と月が交換可能であるかのような概念でエンジニアを扱うことがいかに愚かなことかというのが分かる)

優秀なエンジニアがもたらす品質が速度となってプロダクトの競争力の源泉となり、最終的にはビジネス上の優位性となるのであれば、各社エンジニア採用にコストをかけて様々な工夫をしているのも頷けるなあという感じがする。

経験則⑤品質、速度、費用、要件の全てを満たすことはできない

言い換えると、「可能な限り費用を抑えながら、最高の品質で最高の機能を持つ製品を最高の速度で提供することはできない」これはまあそう、という感じで異論ないと思う。

インセプションデッキのワークショップに登場するトレードオフスライダーと同じで、どれかを高めるためにはどれかを低くする必要がある。

ただし本書では、これまでに挙げてきた経験則を踏まえると論理的に考えてアジャイルではスケジュールを守るためには要件(スコープ)以外は変えられない。変えても意味がないという主張がなされる。

これはどういうことかを簡単に書くと

  • まず経験則④から品質を下げても速度が下がるので品質を落とすという選択肢はなくなる
  • 次にブルックスの法則から、速度を上げるために要員を追加してもむしろ遅延するので費用を上げる選択肢もなくなる
  • すると残っているのは要件(スコープ)しかない。スケジュールを守るためにはスコープを変更するしかない。

とても論理的で筋が通った説明に感じる。ビジネス側に、あるいはマネージャーに対して、アジャイル開発をする以上はスコープを変更するかスケジュールを変えるかのどちらかを選択するしかないことを最初に分かってもらうの大事。

まとめ

Clean Agile は今まで読んだアジャイル系の本の中で1番分かりやすくて面白かった気がする。論理的に考えてアジャイルしかない、という点に凄い説得力と魅力を感じた。日本の開発現場では今でもウォーターフォール開発が蔓延している。自分が引退する頃にも日本では多くの人々がウォーターフォール開発をしているんだろうか?

少なくとも自分は本質を捉えた正しいアジャイル開発のチームで仕事したいよなーと改めて思いました。

*1:自分は読んではないが Software Project Dynamics: An Integrated Approachに詳細が載っていると人月の神話に書いていた