Making Softwareを読んで、ソフトウェア開発の技芸と工学について考えた

ソフトウェア開発は技芸（アート）か工学か、という問題についてときどき思い起こして考える。アジャイル開発やその周辺について学び考えている時はソフトウェア開発を技芸と捉えていることが多い。ソフトウェアは、高いマインドセットを持つ少数のエンジニアによって作られる作品だ。大規模ソフトウェアや、システムオブシステムズといった複雑なソフトウェアについて考えるときには、ソフトウェア開発を工学として考えている。生産性と品質を管理し、作業のパイプラインが淀みなく流れていくようにマネジメントするのだ。どちらが正しくて、どちらが誤っているということはない。境界に立って、腕をまくる・・・。

2011年9月に刊行された「Making Software ―エビデンスが変えるソフトウェア開発」を読んで、ソフトウェア開発の工学的な側面についてまた考えることになった。
本書はひとことで言うと(私の理解では)『ソフトウェア開発に関する実証・証明付き論文エッセイ集』である。

そこで本書ですが、上のような考えに基づき実証的ソフトウェア工学を推進する著者たちが、その基本原理的な部分から、開発プロセス、組織、言語などの個別の話題に至るまで、さまざまな切り口から実証的ソフトウェア工学の実現例、言い替えればエビデンスの具体例を取り上げて解説してくれている、というのがその内容です。この1 冊だけで、実証的ソフトウェア工学がどんなものかということから、具体的に何をすればその恩恵に預れるのかまで、分かるようになっています。
「Making Software ―エビデンスが変えるソフトウェア開発」訳者まえがきより

オライリーのサイトで興味深い本書の目次が読める。
O'Reilly Japan - Making Software

また、私が興味深いと思った個所はPookに抜き書きをしているので興味があったら参照していただきたい。
Making Software ―エビデンスが変えるソフトウェア開発 on Pook

とはいえこの本はもの凄く難しいーッ

興味深い本であるし、個別のテーマも興味深いのだが、とても難しい本でもある。言うまでもなく結論の前にデータがある。分析がある。これを詳細に読み解くのはなかなかに難しいのだ。この手の書籍を読んだことがないのであれば、書店などで実物をよく見てから購入すれば良いと思う。また、初心者はいきなり手を出さず、「ソフトウエア開発 55の真実と10のウソ」あたりをまず手を取ると良いと思う。

以下、特に興味深かった内容に関してのわたしのメモを公開しておく。

3章システマチックレビューから学べるもの
- 複数の研究を精査することにより有用な知見を得る手法に関する紹介
- システマチックレビューにより「ソフトウェア開発の一般常識」を改める例が興味深い
  - (有名な)1994年のスタンディッシュグループのCHAOS報告書(ソフトウェア開発の成功率は低いという内容のもの)は「超過率の計算がおかしい」「意図的に失敗のストーリーを集めている」「予算を下回ったという分類が無い」「コスト超過の定義が明確でない」ため信頼できない
  - 複数の研究から総括する「ペアプログラミングの効果」
6章性格・知能・専門性がソフトウェア開発に及ぼす影響
- 以下の3つの疑問に関する研究
  - 優秀なソフトウェア開発者であるとはどういう意味なのか
  - 優秀な開発者を見つける方法
  - 人に焦点をあてるべきか、ツールに焦点をあてるべきか
10章アーキテクティング：いつ、どれだけ？
- アジャイル手法とアーキテクティングアプローチのどちらを使うべきか
11章コンウェイの法則の系
- コンウェイの法則(システムを設計する組織はどんな組織でも、その組織のコミュニケーション構造と瓜二つの構造を持った設計をしてしまうものである)に関する研究
- Microsoft Vistaのある部分にバグがあるかどうかは、コードを見るよりも、その部分を書いた人たちがどのように組織化されたかを見たほうがわかる！
12章テスト駆動開発はどれくらい効果的か？
- 「もしTDDが錠剤だったら、あなたは健康のためにそれを飲みますか？」
15章品質戦争：オープンソース対有償ソフト
- FreeBSD vs Linux vs Solaris vs Windows
16章コードを語る人
- プログラマはどのようなコミュニケーションをしているのか
- アジャイルメソッドはコミュニケーションに良いか
19章共同作業場か、閉じるドアか？
- プログラマに適したオフィス空間のレイアウトは何か
- 個室、共同作業場？
22章デザインパターンのエビデンス
- デザインパターンを使う場合、使わない場合の対照実験
- デザインパターンを使うということはどのような効果があるか
24章バグレポート収集の技芸
- 開発者と報告者の視点を踏まえた「良いバグレポートとは何か」という研究
25章ソフトウェアの大半の欠陥はどこから生じる？
- 百万行クラスの大規模システムの分析による、欠陥の原因分析
28章工学ツールとしてのコピーペースト主義
- コピペは本当に「悪い」のか
30章 10倍が意味するものは？プログラマの生産性のばらつき測定
- このエッセイの筆者がSteve McConnellだ！
- 開発者の生産性は本当に10倍の差でばらついているのか