デス・マーチ著者のEd Yourdonさんが先日(2016/1/22)亡くなったとのこと。合掌。これを機会に同氏が2009年に公開し平鍋さんが翻訳した『ソフトウェア工学で大切な10の考え方』を再読してみた。同資料のサブタイトルには「この困難な時代だからこそ」である。年月は経ったが引続き困難な時代は続いている。
- Memories of Ed Yourdon | an Agile Way
- Ed Yourdon の『ソフトウェア工学で大切な１０の考え方』を訳しました。：An Agile Way：オルタナティブ・ブログ
- 残念ながら元資料はアクセスできない状況(いろいろ探してみたけれども見つからない)。
なお、そもそも『ソフトウェア工学で大切な10の考え方』が非常に難しい。自分の勉強不足で誤読、勘違いをしている可能性もあるのでご注意いただきたい。指摘やフィードバックは大歓迎。
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
- 作者:エドワード ヨードン
- 発売日: 2013/09/12
- メディア: Kindle版
0.イントロダクション
ほとんどのキーとなるソフトウェア工学のアイディアは、新しいものではない
しかし、それは一貫性をもって実施されていない
世代が新しくなるたびに、基礎を再発見する運命にある
以前に本ブログでも紹介したのだけれども、ソフトウェア工学のアイデアや課題の多くは1968年に発表された「ソフトウェア工学の諸問題に関するNATO報告書」ですでに書かれており、かつその多くは解消していない。という意味では「新しいものではない」のはその通りである。
もちろん研究は進んでおり、様々な解決策が発明・発見されてはいる。しかしそれが実際の開発現場まで浸透しているかというと、そうではない。有名な「Code Complete」の序文でもこの状況について言及がある。
本書を執筆する上で私が最も配慮したのは、業界の第一人者や教授らの知識と、一般的な商用プラクティスとの差を縮めることである。多くの強力なプログラミングテクニックは、一般のプログラミングに浸透するまで何年もの間、専門誌や学術論文に埋もれている。 近年、最先端のソフトウェア開発プラクティスが目覚ましい進歩を遂げている。しかし、一般的なプラクティスの方はそうではない。多くのプログラムは依然としてバグだらけだし、スケジュールは遅れ、予算をオーバーし、ユーザーのニーズに応えていない。（中略）いくつかの調査で、研究開発が商用プラクティスとして普及するには、一般に5～15年、あるいはそれ以上かかることがわかっている。本書は、そのプロセスを短縮し、重大な発見を平均的なプログラマに提供しようとするものである。
Code Complete 第2版 上 完全なプログラミングを目指して （はじめに、より引用）
Code Complete 第2版 上 完全なプログラミングを目指して
- 作者:スティーブ マコネル
- 発売日: 2014/04/02
- メディア: Kindle版
1.計測できないものは制御できない
これはデマルコの名著「品質と生産性を重視したソフトウェア開発プロジェクト技法」に書かれている有名な言葉。その後、デマルコ自身が誤りを認めたという話もある(ただしこの話は、メトリクスによる管理が不要と言っているわけではない点に注意が必要)
では、Yourdonさんは何を言わんとしていたのか。これがスッキリと理解することは出来ていない。いったんの個人的理解は次の通り。
- ソフトウェアの品質管理におけるメトリクスは有効である
- 生産性を管理するための計測、メトリクスは実は有効ではない
- 一方で作業者による見積りを通じて生産性をコントロールすることはできる。
開発者による見積りと、そのデータを活用した生産量のコントロールは現在は主にアジャイル開発のプラクティスとしても定着しつつあるという認識。
2.ピープルウェア
人は（いつの時代でも）プロジェクトにおける最大の生産性要因である。
最もよい人材を採用して、Googleの人材管理をまねよ。
書かれている通りで、異論なし。
基本的には「十分に優秀な人を採用しろ」ということだという理解。
なぜ私はこのことに関してそんなに強行なのか? それはいい候補者を落とす方が、まずい候補者を採用するよりもずっとましだからだ。まずい候補者にはたくさんの金と労力がかかり、彼らのバグを直すために他の人の時間が奪われることになる。
http://local.joelonsoftware.com/wiki/%E6%8E%A1%E7%94%A8%E9%9D%A2%E6%8E%A5%E3%82%B2%E3%83%AA%E3%83%A9%E3%82%AC%E3%82%A4%E3%83%89(version_3.0)
Googleのやり方というと、「ワーク・ルールズ！―君の生き方とリーダーシップを変える」ではなく「How Google Works (日本経済新聞出版)」が詳しいが、読む時間がなければ最近話題になった以下のブログ記事が参考になるかと。
- 作者:エリック・シュミット,ジョナサン・ローゼンバーグ,アラン・イーグル,ラリー・ペイジ
- 発売日: 2014/10/17
- メディア: Kindle版
3.インクリメンタル開発 (vs ビッグバン開発)
プロトタイプは貴重である。
「デイリービルド」、継続的インテグレーションアプローチを使え。
変更管理を奨励し、スコープクリープとスコープ変更を警戒せよ。
異論はないし、継続的インテグレーションのアプローチは現在では主流になりつつあると理解している。
ただ、Yourdonさんの資料で「実践 行動経済学」が紹介されている理由がよく理解できていない。
いろいろ調べていたら以下の記事を発見したのだけれど、「(バイアスなどに左右される特性により)人間は正しく判断することは難しい」という前提にたってスコープ変更を管理せよ、ということなのだろうか・・・。
4.反復
古典を見よ(“有史前”, インターネット前) 1970年の論文「Managing the Development of Large Software Systems: Concepts and Techniques」
大きな誤りを後でするよりも、小さな誤りを早期に。
コンセプトの適用は、「all or nothing」である必要はない。
最近のオブジェクト指向バージョン: “refactoring ”
近代的なツールを使う (高速な協調的なイテレーションのためにTwitter, wiki, などを使う）
Wikipediaでも解説があるのだけれど、ウォーターフォール型開発モデルの原典とされている論文では(実は)反復型開発を推奨しているという話がある。
この論文から始まりウォーターフォールモデルがどう誤解されていったのか、についての論文(日本語)が非常に興味深い。
- ウォーターフォールモデルの誤解を解く « 儲けの秘訣を伝授します
- (上記記事の論文リンクは切れているようだ。こちらからhttp://hdl.handle.net/10252/5163)
- ウォーターフォールの興亡２ - Always All Ways
結局は「ロイスの論文を読んだ人がほとんどいなく、単純な一度きりのライフサイクルだと思われている」「一度で終わらせるウォーターフォールは、説明したり記憶したりするのが簡単である」といった経緯から、一回限りのウォーターフォール開発プロセスが広まってしまったということらしい。
かなり長くなってしまったので、ここでいったん区切ることにする。次回は「5.欠陥が下流に「漏れる」と修正コストが増加する」から「8.リスクマネジメントが鍵」までを取り上げるつもり。
![ブラック・スワン[上]―不確実性とリスクの本質](http://ecx.images-amazon.com/images/I/41snE5NgDHL._SL160_.jpg "ブラック・スワン[上]―不確実性とリスクの本質")
![ブラック・スワン[下]―不確実性とリスクの本質](http://ecx.images-amazon.com/images/I/418YGKMMriL._SL160_.jpg "ブラック・スワン[下]―不確実性とリスクの本質")
![デス・プルーフ プレミアム・エディション [DVD]](http://ecx.images-amazon.com/images/I/51pEO0J4CPL._SL160_.jpg "デス・プルーフ プレミアム・エディション [DVD]")
