ソフトウェア開発のあるある問題と解決策（アンチパターン）
アンチパターン ／ ソフトウェア危篤患者の救出
William J. Brown, Raphael C. Malveau, Hays W. McCormick Ⅲ, Thomas J. Mowbray ［共著］, 岩谷 宏 ［訳］
「アンチパターン」という本のタイトルを見ると、典型的な問題例をパターン化したカタログ本のような印象を受けますが、それだけではありません。アンチパターンは、問題の記述に加えて解決策も併せて示すものです。（これが本のサブタイトル「ソフトウェア危篤患者の救出」の所以だと思います。）
アンチパターンについては、ネットにも沢山の情報があります。特に、アンチパターンの内容だけを知りたい場合は、アンチパターンのカタログを参照すれば十分かもしれません。
- アンチパターン（Wikipedia）
- Anti Patterns Catalog
しかし、この本で私が一番興味を引いたのは、個々のアンチパターンの記述ではなく、アンチパターンの中心的な概念を導く基本形のところでした。これを踏まえたうえで、アンチパターンの記述を読むと、より理解が深まります。
また、有名なパターン本の多くは分析や設計、実装などの分野に特化したものが多いと思いますが、この本は、開発、アーキテクチャ、管理の３つの視点からソフトウェア開発に関する多くの部分をカバーしているため、大変お得です（笑）。
ところで、この本は、アンチパターンのカタログ本ではありますが、有名なGoFなどの少し硬いパターン本と違って、笑えるような（でも笑えない？）読み物という体裁でもあるため、とても読みやすい本です。
＜本の内容＞
ここでは、私が一番印象に残った「第2章アンチパターンの基本形」の概要を紹介します。
（とはいいつつ、この第2章が最も硬い内容で、少し退屈な部分かもしれません…）
パターンとアンチパターン
この本では、パターンとアンチパターンを以下のように説明しています。
- パターンとは、実践の中に頻繁に観察される、いわゆる、’よく見かける解法テクニック’である。
- ソフトウェアに関するそのほかの知恵とデザインパターンが違う点は、後者がテンプレートを使う事である。
- テンプレートは、パターンを構成する解法、設計方法、結果や効果などを形式的に文書化したものであり、その構造はどのパターンにも共通である。
- 通常のデザインパターンが問題と解法からなるのに対し、アンチパターンの本質は２つの解法である。
- 解法１：問題のある解法（良くない解法）
- 一般的に至る所で見かける解法であり、しかも深刻な否定的結果をもたらす。
- 解法２：再構想（抜本的見直し）による解法
- 再構想解は、アンチパターンを解決してより良い形式に組みなおすための、一般性のある解法である。
- パターンとアンチパターンは、関連している。
- デザインパターンは往々にして、アンチパターンに変わる。
- あるパターンが良好なパターンかアンチパターンかということは状況次第できまる。
そして基本形として、アンチパターンの中心的な概念を導く以下の3つの事項を説明しています。
- 根本原因（root causes）
- 中心圧力（primal forces）
- ソフトウェアデザインの対象レベルの各段階（Software Design-Level Model, SDLM）
根本原因
根本原因は、「ソフトウェア開発において犯される錯誤であり、それらの錯誤がプロジェクトの失敗、予算超過、納期／スケジュール遅れ、ビジネスニーズの非充足などをもたらす」もので、聖書の「七つの大罪」に倣って書かれています。
- 拙速（Haste）
- 拙速な決定は、ソフトウェアの品質を損なう。
- 無関心（Apathy）
- 無関心は、問題解決に不熱心なことではない。解決方法を頭から無視することである。
- 狭量（Narrow mindedness）
- 狭量は、効果的であることが広く知られている実用性のある解法の採用を拒絶することである。
- 無精（Soloth）
- 無精なデベロッパや管理者は、つねに最も安易な方法を選びたがり、そのために意思決定の内容もお粗末になる。
- 強欲（Avarice）／貪欲
- さまざまな形があるが、不正な意思決定に導く。
- 無知（Ignorance）
- 短期的ではない長期的なソフトウェアトラブルの原因を作り出す。
- 高慢（Pride）
- 高慢は、何もかも自分で作らなければ気が済まない、という病気だ。
それぞれについて、ドキッとする（思い当たる？）ことが書かれています。
中心圧力と対象レベル、職責
中心圧力とは、「ソフトウェアのアーキテクチャやソフトウェア開発のあらゆる部分に普遍的に存在する、複数のドメインや問題に共通の意思決定を左右する懸案事項や課題」とのことです。
これは抽象的な表現で分かり難いですが、具体的な中心圧力として６項目示されています。
- ソフトウェアの機能性の管理
- 要件への適合
- ソフトウェアの実行性能の管理
- 動作速度の要件への適合
- ソフトウェアの複雑性の管理
- 抽象の定義
- ソフトウェアの変化の管理
- ソフトウェアの変様進化の制御
- IT資源の管理
- 人員およびIT関連製品の、利用と実装の制御
- 技術移転の管理
- 技術変化の制御
さらに「ソフトウェアソリューションの適用対象のスケールの大小やレベルの違いを基準にして問題を分割し、設計課題のスケール別の把握形式（複数のレベルへの分割）を提示する」ために、以下のアーキテクチャのレベルが書かれています。
- 業界全体のレベル（global level）
- 企業のレベル（enterprise level）
- システムのレベル（sysem level）
- アプリケーションのレベル（application level）
- マクロコンポーネントのレベル（macro-component level）
- マイクロコンポーネントのレベル（micro-component level）
- オブジェクトのレベル（object level）
この中心圧力と対象レベルを中心に、重要度や担当職責の関係をまとめてくれています。
視点別にまとめられたアンチパターン
本編では、３つの視点で分類された多くのアンチパターンが記載されています。
- 開発のアンチパターン（Development AntiPatterns）
- プログラマがプログラミングの諸問題を解こうとするときに遭遇する状況を記述する。
- アーキテクチャのアンチパターン（Architectural AntiPatterns）
- システムの構造に頻出する問題とそれらの結果および対策に焦点を当てる。ソフトウェアシステムにおける未解決の深刻な問題の多くが、この部分で起きている。
- 管理のアンチパターン（Management AntiPatterns）
- ソフトウェア関連の組織を原因として頻繁に起きている問題を記述する。
＜感想＞
私はこの本を初版（日本語版は1999年）が発行されたときに買って読みました。少し古い本です。
当時は「オブジェクト指向における再利用のためのデザインパターン」の影響もあって、いろいろなパターン本を読み漁っていた時期でした。設計技術を磨く目的意識が強かったこともあり、上記で紹介した第1部の内容はほとんど読まずに、第2部のアンチパターンカタログをパラパラめくってみたものの、あまり興味がわかず、途中で読むのをやめてしまいました。
中心圧力のところに、以下の趣旨が書かれています。
- 最新技術の導入によってソフトウェア開発の基本方式が抜本的に改善された、という状況は無いため、（ソフトウェアの失敗という不吉な暗雲が取り払うためには、）技術以外の何かが大きく変わらなければならない。その技術以外の何かとは、ソフトウェアシステムの設計（アーキテクチャの決定・選択）と、リスク管理のための方法および行為である。それらが、大幅に変わらなければならない。
このあたりは、「銀の弾などないーソフトウェアエンジニアリングの本質と偶有的事項」に通じるところがあります。
「人月の神話」ほどではありませんが、今読むと、具体的な技術の例について書かれている部分は少し古く感じることもあります（ソフトウェア本の宿命ですね…）。しかし、パターンの記述内容は今でも通用するものだと思います。
また、この本では開発、アーキテクチャ、プロジェクト管理の３つの視点で書かれていますが、個人的な感想としては、開発に関するアンチパターンよりも、その他のアンチパターンの方が面白く、全体の印象としては、技術書というよりプロジェクト管理本でした。
ところで、この本では「アンチパターンはデザインパターンのより効果的な形式である」という考えが強調されているところが多い気がします。このあたりは、個人的にはどうでもよいです。（どちらが優れているというものでもないし、どちらも有用だと思います。そもそも、パターンという概念は、ちゃんとした定義が難しい気がするし。）
しかし、パターンにしてもアンチパターンにしても、ソフトウェア業界のユビキタス言語の語彙を提供してくれていると思います。
このアンチパターンのパターン名（語彙）は少し独特で、日本語訳で「肥満児」「梯子外し」「おんぼろ煙突化」「横紙破り」などなど、言葉から推測できて笑えるものもあれば、内容を読まないと理解できないものまであります。（日本語化の難しさや日本人の感覚の問題もあるかもしれません。）
独特の名前付けはアンチパターンが「ソフトウェア業界が頻繁に落ち込む落とし穴の悲惨を対象化することにより、ストレスに対するカタルシスになることを目指す」といったところを体現しているところと思います。
以前購入した時はほぼスルーしてしまった本ですが、プロジェクト管理的な側面で見ると、とても参考になる本だと思いました。
コメント
コメントを投稿