勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ウォーターフォールを殺しにきている書籍「継続的デリバリーのソフトウェア工学」を読んだ

読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第52回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。

さて、今回取り上げるのは「継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣」である。ちょっと長いので通常2週間のイテレーションを延長して3週間で読んでいる。

ちなみに先に言っておくと、私の好きな開発プロセスウォーターフォールではなくUnified ProcessもしくはDADである。別にウォーターフォールに思い入れはない。あしからず。

ウォーターフォールへの新たな刺客!

さて本書だが、わかりやすくウォーターフォールを刺しに来ているのが興味深い。新たな使徒登場である。
ちなみに個人的な観測範囲での前回の使徒はマコネルの「More Effective Agile “ソフトウェアリーダー”になるための28の道標」である。ただこちらは、ふんわりとした太刀筋なので攻撃されたことに気づかなかったかもしれない。

煩雑系であるという絶対的な確信がある場合以外は、プロジェクトを複雑系として扱い、アジャイルラクティスに投資するほうが安全である(なお、プロジェクトを煩雑系として扱う場合は、シーケンシャルアプローチがうまくいくだろう)。
More Effective Agile “ソフトウェアリーダー”になるための28の道標、第3章より

同書の感想記事はこちら

さて、本書はよりストレートにウォーターフォールに切り込んでくる。直球である。

  • ウォーターフォールを中心とした「これまでのソフトウェア工学」には誤謬があり、停滞している。この停滞はハードウェアの進化に隠蔽されている。
  • 場合によっては誤ったプラクティスによって退化している場合もある。

このあたりは本書でも紹介されているグレン・ヴァンダーバーグの講演に通ずるものがあり、実際本書のプレストーリーはその内容とほぼ一緒である。

ウォーターフォールの思考様式を広めた人々はよい意図からそうしたのです。彼らは、ウォーターフォールこそ、最良の仕事の進め方だと思ったのです。ソフトウェア産業は、数十年をかけてこのアプローチを軌道に乗せようとしましたが、うまくいきませんでした。
継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣、第4章より

ただし、それではアジャイル開発を推奨しているのかというと必ずしもそうではない点が興味深いところだ。明確にアジャイル開発を批判しているわけではないのだが、クラフトマンシップでは不十分ということも述べている。

ソフトウェアクラフトマンシップという考え方はかつて重要でした。この考え方のおかげで、以前の製造重視で儀式的な開発アプローチから重要な一歩を踏み出せたのです。私は、ソフトウェアクラフトマンシップという考え方が間違っているとは思っていません。それでは不十分だと思っているのです。
継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣、第2章より

じゃあ、どうするの?というのは本書の主題である。

本書で紹介されている新たな「ソフトウェア工学」の骨子

ざっくりとまとめると、以下のように要約できるだろう。

  • Accelerate本を前提に、安定性とスループットがKPIとなる
  • このKPIを役に立つ判断指標として「学びのエキスパート」「複雑さ管理のエキスパート」を最重要スキルと定義する
  • この2つの最重要スキルごとに様々なプラクティスを整理したものが新たなソフトウェア工学、本書の原題である「Modern Software Engineering」である

本書はこの点について、例示や知的好奇心を満たすコラムも交えながら(興味深い!)語っていて非常に有用な整理をしている。
特にAccelerate本を前提としてソフトウェア開発アクティビティの改善に取り組んでいる組織には、非常に有用な書籍だろう。自分も読んでいて、いろいろと見直すべき点などを考え始めている。

ただ、一方でちょっと気になる点も感じたのだ。

ウォーターフォールはオワコンなのか?

本書の著者であるデイビッド・ファーリーさんの原点はLMAXという市場系取引プラットフォームのようである。ファウラーさんのブログにも紹介されていた。QConで講演も視聴できるようなので近日中には観てみたい。

こういった領域のソフトウェア開発については少し経験があるのだけれども、探索的であり、ソフトウェアの改善が収益に直結するので非常にエキサイティングな領域なのだ。エンジニアリング・ハッピーだ。雰囲気としてはこの映画(大好き)のイメージである。

ただ一方で、探索的であってはいけないプロジェクトも存在するわけで、そういったプロジェクトをどうするかという問題は本書のアプローチだけでは解決できないと思っている。

  • 許容される試行錯誤の範囲が狭い(高い精度で正解に近づく必要がある)
  • 複雑な利害関係があり変更許容性が低い(例えばオペレーションに多数の人間が関わっており、頻繁にオペレーションを変更できない)

などなど。ただこういった反論をしたくなるのも、古いソフトウェア工学の呪縛から逃れられていない証拠なのかもしれないけれど。
引続き、いろいろ思考をアップデートしていく必要があるわけである。

参考文献