勘と経験と読経

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

デス・マーチ著者Ed Yourdonさんの『ソフトウェア工学で大切な10の考え方』を再読する(後編)

Project Management Professional Engineer Software Architect

前々回、前回記事の続き。デス・マーチ著者のEd Yourdonさんが先日(2016/1/22)亡くなったとのこと。合掌。これを機会に同氏が2009年に公開し平鍋さんが和訳を公開している『ソフトウェア工学で大切な10の考え方』を再読してみた。この後編では「9.一貫性は才能+デスマーチに勝る」から後に関して記載。勉強不足により誤読、勘違いをしているかもしれない。指摘やフィードバックは大歓迎。

デスマーチ 第2版　ソフトウエア開発プロジェクトはなぜ混乱するのか

デスマーチ 第2版　ソフトウエア開発プロジェクトはなぜ混乱するのか

9.一貫性は才能+デスマーチに勝る

グローバルな不況は、少なくともここ数年、デスマーチプロジェクトを増加させるだろう……
SEI-CMM, ISO-9000, six-Sigma, ITIL, etc, etc.のようなアプローチに注目せよ。

「個人の才能よりもプロセスやチームに着目せよ」ということだと理解。また、デスマーチを防止するには規律を重視した（特にリスク）マネジメントは重要だろう（ただし、失敗しないことと、成功することは同じことではない）

少し古いデータだけれども、マコネルの「ソフトウェア見積り」では10万LOC規模のソフトウェア開発における見積りに影響する人的要因(COCOMO2)を以下と紹介している(第5章　見積りに影響するもの)

  • 要求アナリストのスキル　(影響度2.00)
  • プログラマの(一般的)スキル (影響度1.76)
  • 要員の継続性(離職率) (影響度1.59)
  • アプリケーション(業務領域)の経験 (影響度1.51)
  • 使用言語とツールの経験 (影響度1.43)
  • プラットフォームの経験 (影響度1.40)
  • チームの結束 (影響度1.29)

ただし500万LOC規模になると、プロセスの成熟度 (影響度1.94)やチームの結束(影響度1.59)などの影響が増大する。

プロジェクトの計画とコントロールの観点からこれが意味することは、小・中規模のプロジェクトでは、個人の力量で成功の大部分は決まるということである。大きなプロジェクトでも個人の力量はやはり必要だ。しかし、大きなプロジェクトでは、どれだけプロジェクトがマネジメントされるか(特にリスクマネジメントに関して)、どれだけ組織が成熟しているか、そしてどれだけ個人がチームに溶け込むかといった要素のほうが重要になる。
ソフトウェア見積り　人月の暗黙知を解き明かす

ソフトウェア見積り　人月の暗黙知を解き明かす

ソフトウェア見積り　人月の暗黙知を解き明かす

というわけで「個人の才能よりもプロセスやチームに着目せよ」というのは重要だと思うのだ。

10.車輪を再発明しない

ベストプラクティス (ボトムアップ！)
ワーストプラクティス (233 もブログがある！)
SWBOK

読んで字の通り。なお紹介されている「アンチパターン」はとてもオススメの本なのだけれども絶版なのが悲しい。

アンチパターンは、ソフトウェアの開発や導入が成功するためには何を避けるべきか、という教えの集大成です。そういう、やってはいけないことを現にやっている、あるいは、このままだとやりそうだ、ということに早期に気づくこと、…アンチパターンは、その自覚と早期発見がきわめて重要です。本書はソフトウェア開発に関連したさまざまなアンチパターンを詳しく解説し、ソフトウェアの設計（デザイン）、アーキテクチャ、およびプロジェクト管理の各面に見られる多くのアンチパターンを、ユーモアに富んだ軽い文章で指摘してくれます。しかし本書が読み物としてどれだけおもしろくても、それらのアンチパターンの発生を、私たちは必死で防がなければならないのです。
アンチパターン―ソフトウェア危篤患者の救出

ソフトウェアの失敗が普遍的なのは、なぜだろうか。われわれはひとつの結論に達した：実践されているデザインパターンよりは、実践されているアンチパターンのほうが圧倒的に多いのだ。
アンチパターン―ソフトウェア危篤患者の救出

アンチパターン―ソフトウェア危篤患者の救出

アンチパターン―ソフトウェア危篤患者の救出

なお同書に掲載されている多くのアンチパターンはWikipediaでも紹介されている。

そしてSWEBOKも「ソフトウェア開発に関するベストプラクティスをまとめた知識体系」であり、注意を払うべきだろう。最新版の概略はIPA/SECの発行するSECジャーナルの記事が良いまとめなので紹介しておく。

11.透明性を重視。何も隠さないこと

2009年2月18日のTwitterでの会話をありがとう、Kent Beck, Ron Jeffries, その他のみなさん。
Kent Beck: “ソフトウェア工学は、ソーセージ工場に顧客が入るのを拒むのではなく、招きいれたときに、改善される。
Ron Jeffries: “隠すこと、について完全に同意。何も隠さないこと。透明性がすべてを決定する。”
Ward Cunningham: “きれいなコードにも技術的負債 (Technical Debt)があり、それは良いことなのだ。 なぜ か、このビデオをみよ。

書かれている以上のことはわからないのだけれども、当時の会話(?)を発掘したので貼り付けておく。

Ward Cunninghamさんに関するスライドの記述は上記とは関係無くて、技術的負債に関する1992年の発表のことを指している。Wikipediaの説明がわかりやすい。またYoutubeへのリンクも下記ページから。

12.結論

技術は中心課題ではない。
フレデリック・ブルックス(Fred Brooks): “銀の弾丸などない”
マーガレット・ミードの “地球時代の文化論”
新しいことを無視してはいけない。-例えば, Chandler

『ソフトウェア工学で大切な10の考え方』の結びなのに「技術は中心課題ではない」ということなのだけれども・・・「銀の弾丸などない」ことについてはWikipediaが詳しい。

人月の神話【新装版】

人月の神話【新装版】

ここで、マーガレット・ミードさんの「地球時代の文化論」が登場するのだけれども教養不足・情報不足のために文脈が読み取れない。Webで見れる各種の書評などから察するに、同書では今後社会や文化は「大人世代が若者世代をモデルとする」未来志向型になる、ということが書かれているようなのだけれども、ソフトウェア工学についても新しい世代に目を向けたらよいということを言いたかったのだろうか……

そしてChandlerであるが、これはデスマーチ化そして停滞したことで有名なOSSプロジェクトのことである。

その経緯は書籍化もされている。以前に読んだのだけれどもすっかり詳細は忘れてしまった。断片的なメモだけ残っているので貼っておく。

斧を研いだりヤクの毛を刈ったりする作業がどの時点でプロジェクトの本来の目的から逸れるかを見きわめ、プログラマーを楽しい道具の手入れの脇道から本来の仕事に呼び戻すことは、ソフトウェアマネジャーにとって厳しい試練である。
プログラマーのジレンマ 夢と現実の狭間

シェーファーは椅子の背によりかかり、ふくよかな腹をさすって言った。「昔からこう言うんだ。早く作るか、安く作るか、うまく作るか。どれか二つだけ選ぶことができる、と」
プログラマーのジレンマ 夢と現実の狭間

プログラマーのジレンマ 夢と現実の狭間

プログラマーのジレンマ 夢と現実の狭間

『ソフトウェア工学で大切な10の考え方』を読み終えて

自分なりにいろいろと関連書籍などを参照しながら『ソフトウェア工学で大切な10の考え方』を読んでみたのだけれども、原文がslideshareから削除されてしまっていたり、Yourdonさんのブログ記事なども軒並みアクセスできない状況で行間を読むのが大変であった（または、読めていない）。

提示されている12のキーワードは何れも文字通りの「大切な考えた方」であって、これから何度も振り返って再考していくことになるのだろうと思う。

私は、過去から学ぶこと、そして、自分たちのやり方を作っていくこと。両方大事なんだ、と信じています。
Memories of Ed Yourdon | an Agile Way

Ed Yourdonさんのご冥福をお祈り申し上げます。

関連する記事