勘と経験と読経

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

ソフトウェア要求、The DevOps他がKindleで50%以上オフ以上のセール中(対象じわじわ拡大中)

book Kindle

定点観測したところ、ソフトウェア要求が50%オフ、The DevOpsが50%オフ＋20%ポイント還元のセール中の模様。ちなみにどちらも自分でKindle Paperwhiteで読了済。特に支障なく読めます。
3/16追記：デマルコのデッドライン、ワインバーグさんの本、ソフトウェアテスト293の鉄則、ソフトウェア見積りもポイント還元あわせて50%以上オフになっている模様。ロジックがよくわからないけれど…
さらに追記：よくわからないけど1日2-3冊くらいずつセール範囲が拡大している。発見したものは末尾に追加。
3/17追記：デマルコの熊とワルツが追加された。じわじわ感。

ソフトウェア要求　第3版

ソフトウェア要求　第3版

↑上流工程に関する課題はこれ一冊でかなりカバーできている印象。第3版でアジャイル開発プロセスへの考察も追加されている。

The DevOps　逆転だ！究極の継続的デリバリー

The DevOps　逆転だ！究極の継続的デリバリー

↑「ザ・ゴール」のような小説形式で学ぶソフトウェア開発プロジェクト最適化の話。根底には、制約理論(TOC)とリーン開発が含まれている(アジャイル開発プロセスへの言及はあまりない印象)。

MSでDevOps普及の活動をされている牛尾さんも推薦しているようだ。

追記

以下の本もセール中の模様。

テストから見えてくるグーグルのソフトウェア開発

テストから見えてくるグーグルのソフトウェア開発

↑50%オフ。この本は開発プロセス改善という観点でおすすめ。

闘うプログラマー［新装版］　ビル・ゲイツの野望を担った男達

闘うプログラマー［新装版］　ビル・ゲイツの野望を担った男達

↑古典的デスマ小説、というのは上段だけど、困難なソフトウェア開発のドキュメンタリーとして読んでおきたい一冊。

さらに追記

ロジックがよくわからないのだけど、デマルコのデッドラインも50%オフになってた。こちらもThe DevOps同様に小説仕立てでソフトウェア開発を論じる本、というか元祖っぽい気がする。

デッドライン

デッドライン

3/16さらに追記

以下もポイント還元込みで50%以上オフになってた。

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

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

↑過去に以下の記事でもオススメしている良著。

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則

↑こちらもとても参考になる良書。しびれる名言がたくさん書かれている。

プログラミングの心理学　【25周年記念版】

プログラミングの心理学　【25周年記念版】

パーフェクトソフトウエア

パーフェクトソフトウエア

↑こちらもソフトウェア開発の名著。

3/16さらにさらに追記

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

↑良い本だけど玄人向け。

コンサルタントの道具箱　勇気と自信がもてる16の秘密

コンサルタントの道具箱　勇気と自信がもてる16の秘密

↑確か未読。

はじめて学ぶソフトウェアのテスト技法

はじめて学ぶソフトウェアのテスト技法

↑良書。

3/17追記

熊とワルツを　リスクを愉しむプロジェクト管理

熊とワルツを　リスクを愉しむプロジェクト管理

↑名著のひとつだが、実はちゃんと読んだことが無かったのでこの機会に購入した。

情報システムの障害状況ウォッチ（2015年後半）、ポストモーテム

Project Management Postmortem

SEC Journal44号で2015年前半の情報システム障害状況まとめが公開されたので読んでみる記事。
前回記事はこちら。

SEC Journal最新号の入手はこちらから。

http://www.flickr.com/photos/7119320@N05/22856576053
photo by Sean_Marshall

情報システムの障害状況ウォッチ（2015年後半）

詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をニュース記事などとザックリ照らし合わせてみた。全般的にトラブル発生時の速報はあれど、原因や再発防止などが公開されていることはあまりないのが残念なところ。また、日経コンピュータさんがいろいろ取材されて深掘りされているようなのだけど、記事がほとんど公開されていないのはちょっと残念。ビジネス的な判断なのだと思うのだけど、公益性も鑑みてトラブル事例は公開していくことを検討して欲しいと思う。

注目事例

SEC Journal44号の紹介記事の中でも取り上げられているけれど、「長期間の不具合放置」関連の事例が目立っている(1524,1526,1530,1541など)。SEC jounal44号の記事では

以上の5件はいずれも、一見正常に運転されているにもかかわらず、実は重大な問題を抱えたまま運用されていた事例である。不具合によってシステムがダウンするなどの現象が発生すれば、誤りは直ちに検知されるが、この種の事故は開発段階での綿密なテスト計画の策定とその着実な実施という基本的な対策でしか回避の方法はない。
(SEC Journal44号 連載 情報システムの障害状況 2015 年後半データ より)

と書かれているのだけれども、ちょっと違う印象を持った。リスク管理の問題ではないだろうか。

  • 最終テストとして、何を確認して、何を確認していないのか明確にする
    • 例えば[1541]の緊急通報メール発信トラブルについては、システムと通信事業者間の疎通確認はやったけれども、通信事業者から利用者までのメール発信の疎通は(おそらく)実施していない。本番環境でのテストは実施しないという判断はあり得るが、テストしていないという事実をきちんと関係者間で共有していたのかというと、おそらくしていないのではないかと思う。
    • [1527]メタボ検診システムについても、実データでのテストは実施していないということを明確にしておくべきだったのではないかと。これもセキュリティ等の観点で、実データを利用しない判断があったとしてもこれは問題ない。しかし、何を「やっていないか」を明確にすべきだろう。
  • 実機で確認できていないことは、どんな代替手段でリスク軽減(検証)したのかをはっきりとさせる
    • 実機確認できないものについても、テスト環境で検証するか、それも困難であれば綿密な机上確認するなどによってリスクは軽減できるはずであり、それを検討すべきと考えている。
  • 残余リスクについて、そのリスクが消滅するまで継続監視する
    • システムの構造上、なかなか本番稼動しない機能はあると思う(1年に1回しか動かない、とか災害時にしか動かないとか)。とはいえ、本番稼動実績のない機能はリスクが残っている。こういったリスクは解消するまで(初回稼動が終わるまで)トレースしていかないと、思わぬところで足をすくわれる事になるのでは無いかと思っている。

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則

技術書の無料試し読み(Kindle/GoogleBooks/他)

book Kindle

技術書を図書館で借りようというブログ記事を見た反応。個人的にも公立図書館はフル活用していて、至急性の高くない「読んでおきたい本」は借りるようにしている。が、最近技術書は他の手段でも試し読みできることが多いのでそっちで読むことが多い。というわけで無料試し読みの方法について整理してみる。なお出版業界の方には申し訳ないけど、物理書店は目的が達成できなかったり、余計な買い物をしてしまうリスクが大きいので最近行かないようにしている・・・・・・。

Bookstore cat

無料試し読みの方法について

出版社の方針などで書籍によって最適な方法は異なるのだけれども、自分が最近使っている手段はだいたい以下の通り。

  • Amazon Kindleでサンプルを読む
    • 専用アプリかKindle端末が必要。Web経由でもごにょごにょすれば閲覧できるという話もあるけれど割愛。
    • この方法だと、目次、まえがき、第1章くらいはだいたい読める
  • Kindle非対応の書籍の場合、出版社が独自で試し読みに対応していればそこで読む
  • Google Booksで読む
    • 規則性はよくわからないのだけど、おそらくGoogle Playの対象書籍が対象となっている
    • 翔泳社さんの本は最近どれも対応されていて、有難い

出版社別のワビサビを統合して効率よく試し読みができるサービスがあるといいのだけれども、現時点では未発見(ひょっとしたらあるかも)。

せっかくなので、いくつかの技術書ランキングに掲載されている書籍について実際に無料試し読みが出来るか調べてみた。

「新春座談会 このコンピュータ書がすごい！ 2016年版 －2015年に出たコンピュータ書ならこれを読め！－」開催報告：レポート｜gihyo.jp … 技術評論社

  1. たった1日で即戦力になるExcelの教科書
  2. 人工知能は人間を超えるか ディープラーニングの先にあるもの (角川EPUB選書)
  3. スッキリわかるJava入門 第2版 (スッキリシリーズ)
  4. リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
    • 残念ながら試し読みできず
  5. 暗号技術入門 第3版 秘密の国のアリス
  6. 深層学習 (機械学習プロフェッショナルシリーズ)
  7. HTML5&CSS3デザインブック (ステップバイステップ形式でマスターできる)
    • 残念ながら試し読みできず
  8. 伝わるデザインの基本 よい資料を作るためのレイアウトのルール
  9. ハッカーの学校
  10. インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門

ITエンジニアに読んでほしい！技術書・ビジネス書 大賞 2019

ビジネス書系は省略。

大賞
技術書部門 (上記と重複は省略)

調べてみた感想

  • オライリーさんはDRMフリーの電子書籍を発行していただけているのは大変あり難いのだけれども、試し読みビリティは低いのが残念
  • 技術評論社さんは、書籍によって対応が異なる。WEB+DB PRESS plusシリーズはNGなのが残念
  • というわけで電子試し読みできない本は、図書館か書店で見るしかなさそう

「ビヨンド ソフトウェア アーキテクチャ」あるいはパッケージソフトウェアの作り方

Software Architect Project Management Professional Engineer book

「ビヨンド ソフトウェア アーキテクチャ」に関する読書メモ。ソフトウェアアーキテクチャ全般に興味があるので手に取ったのだけれども、同書はざっくり言えばパッケージソフトウェアの作り方に関する本である。なんとなく、このタイトルでは必要な人の手に渡らないような気がするのだけれども。なお同書のKindle版は2/25まで50%オフのセール中なので興味のある方はお早めに判断を。

ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics

ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics

「ビヨンド ソフトウェア アーキテクチャ」

翔泳社さんの書籍紹介は次のように書かれている。

「アーキテクチャ」について技術的な観点から書かれている本は数多くありますが、ビジネスの視点からシステムを商品として見た時に考えるべきことを教えてくれる本が、実はありませんでした。本書は、アーキテクチャにおけるビジネス（マーキテクチャ）と技術（ターキテクチャ）をつなぐ架け橋として、情報システム部の方全員に読んでほしい本（情シス必読書）です。エンジニアにとっては、マーケティングの基礎を学ぶ上でも役に立ち、かつ、技術面でのアーキテクチャ論としても、経験豊富な著者の実体験に根ざす優れた考察に富んだ一冊となっています。

上記はちょっとミスリードがあると思っている。本書は「ソフトウェア製品開発に関わるアーキテクト」が想定読者になるのではないだろうか。そういう意味では、ユーザ企業の情報システム部門に所属する人（買い手）というよりは、ソフトウェア製品開発（作る人）に関わる人に読んでおいてほしい内容だと思う（あくまで個人的な感想）。

さて、本書の基本的な骨組みは上記紹介にも書かれている通りだが、

  • ソフトウェア製品は、「テクニカルアーキテクチャ（ターキテクチャ）」と関連する「マーケティングアーキテクチャ（マーケテクチャ）」を持つ。
  • マーケテクチャ検討上の重要な観点について論じる（第４章以降）

である。

本書では、ソフトウェアアーキテクチャという枠組みを越えてソリューションをうまく構築するために、幅広いビジネス課題とアーキテクチャ上の選択との関係について議論する
ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics まえがき、より

ソフトウェアアーキテクチャについて言及することもあるし、技術的な課題を議論する場合もある。だが、私が集中して議論したいのは、アーキテクチャを図示あるいは文章化する最善の方法や、堅牢で、分散化されたWebコンポーネントシステムに関連する深い設計原理などではない。
ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics まえがき、より

ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics 目次

  • 第1章：ソフトウェアアーキテクチャ
  • 第2章：プロダクト開発入門
  • 第3章：マーケテクチャとターキテクチャ
  • 第4章：ビジネスとライセンスモデルの共益関係
  • 第5章：インライセンステクノロジー
  • 第6章：可搬性
  • 第7章：デプロイメントアーキテクチャ
  • 第8章：統合と拡張
  • 第9章：ブランドとブランド要素
  • 第10章：ユーザビリティ
  • 第11章：インストール
  • 第12章：アップグレード
  • 第13章：コンフィギュレーション
  • 第14章：ログ
  • 第15章：リリース管理
  • 第16章：セキュリティ
  • 補遺A：リリースチェックリスト
  • 補遺B：戦略的プロダクトマネジメントのためのパターン言語

ソフトウェア開発の上で必要な「マーケテクチャ検討上の重要な観点」というのが曲者であり、また本書の整理が非常に有効なポイントである。
ソフトウェアを構築するために必要な意思決定の多くはアーキテクトが利害関係者との調整において合意形成するものだが、ソフトウェア製品については「顧客」という最も重要な利害関係者が不在なのである。ではどうするか？というのが本書の主眼であると思う。

また、世の中一般で最も多い「自社利用のシステム構築」と、「販売するためのシステム開発」では根本的に異なる点も多い。

  • どのようなライセンスモデルで販売するかと、そのライセンスモデルを実現するための機能要件は何か
  • 利用しているサードバーティ製品やOSSのライセンス管理はどうするのか
  • どのような環境をサポートするのか
  • オンプレミスかサービス提供か
  • 他システム連携の考慮はどうするか
  • インストール、アップグレード、コンフィグ設定はどうするか

こういった観点が、本書のような形でとりまとまっているのは本当に有難い。

個人的には、何年かごとに製品開発にも関わってきているので、本書は非常に参考となった。
プロダクトとしてソフトウェアを出荷するような形で仕事に関わる方におすすめ。

PoEAAも対象。Kindleで翔泳社さんの技術書が44%以上オフのセール中！

book Kindle

現在開催されている技術者イベント、デブサミ開催に連携して、翔泳社さんの技術書がKindleで大幅なセール中の模様。ほとんどセールにならない近著「ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics」も50%オフになっているので、興味のある人はいま買うのがおすすめ。なおイベント連携なのでセール期間は短いものと思われる。

【2/19 9:15追記】
翔泳社さんから連絡いただき、セールは2/25までの期間とのこと。
またよくチェックしてみたらPoEAAが対象になってる！(買った)。末尾に対象書籍で興味深いものをいくつか追記した。

【2/19 10:45】
要望したら対象外だった「レガシーコード改善ガイド」がセール対象になった！即刻購入！

オススメ＋気になっているものをピックアップ

ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics

ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics

つい先日読了して、近々ブログ記事にレビューを書く予定。ソフトウェア製品を作る上でのアーキテクチャ考慮点について書かれた本といった感じ。製品開発やサービス開発に携わるアーキテクトやエンジニア向け。

達人に学ぶ SQL徹底指南書

達人に学ぶ SQL徹底指南書

実は未読。評判は良い印象。

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書

既読。オススメ。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

良書。

実践ドメイン駆動設計

実践ドメイン駆動設計

現在読んでいるところ。良い本という評判。

組織パターン

組織パターン

既読。なかなかに難解な本だけど、エンジニア組織やプロジェクトをマネージしている人にはオススメかも。

ディシプリンド・アジャイル・デリバリー　エンタープライズ・アジャイル実践ガイド

ディシプリンド・アジャイル・デリバリー　エンタープライズ・アジャイル実践ガイド

アジャイルソフトウェア要求

アジャイルソフトウェア要求

どちらも良書

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

実は未読。評判は良い印象。

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

マネジメント向け、またはマネジメントに説明するためのスクラム解説本。

エッセンシャル スクラム

エッセンシャル スクラム

実は未読。

おそらく他にもいろいろセールになっていると思われる。

2/19 9:15追記

エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーションアーキテクチャパターン

名著。以前に読んだかもしれないけれど手元にないので改めて購入。

ユースケース駆動開発実践ガイド

ユースケース駆動開発実践ガイド

これもけっこう古いものだけれども、ユースケース駆動の開発プロセスICONIXについての解説書。
最近やユーザーストーリー駆動の開発が主流になるつつあるけれども、学ぶところは多いはず。

プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに

プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに

未読。価格を考えると購入のチャンス・・・！

ヘネシー＆パターソン　コンピュータアーキテクチャ　定量的アプローチ 第5版

ヘネシー＆パターソン　コンピュータアーキテクチャ　定量的アプローチ 第5版

未読。ちょっと手を出すのが怖いんだけど……

2/19 10:45追記

レガシーコード改善ガイド

レガシーコード改善ガイド

要望したらセール対象に追加されたッ。即刻購入……(いつ読むんだ)

デス・マーチ著者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さんのご冥福をお祈り申し上げます。

関連する記事

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

Project Management Professional Engineer Software Architect

前回記事の続き。デス・マーチ著者のEd Yourdonさんが先日(2016/1/22)亡くなったとのこと。合掌。これを機会に同氏が2009年に公開し平鍋さんが和訳を公開している『ソフトウェア工学で大切な10の考え方』を再読してみた。今回は「5.欠陥が下流に「漏れる」と修正コストが増加する」からを取り扱う。勉強不足により誤読、勘違いをしているかもしれない。指摘やフィードバックは大歓迎。

5.欠陥が下流に「漏れる」と修正コストが増加する

コストはライフサイクルのフェーズを1つ越えるごと に10倍になる。
1980年代前半の、Barry Boehmによる文書
Agileの人たちは不賛成であり、継続的なリファクタリングを強調している。
しかし、 Boehmは同意していない
それはプロジェク トサイズに依存している 『アジャイルと規律』(2004)

ソフトウェアの修正コスト曲線に関する話である。ソフトウェア開発のライフサイクル(設計→実装→テスト→運用)の後ろに行くほど修正にかかるコストが指数関数的に増加していくというもの。

初期のAgile界隈からの反論はおそらくXPエクストリームプログラミング懐疑編―XPはソフトウェア開発の救世主たりえるのか (The XP Series)に書かれているものを指していると思われる。残念ながら同書は未読なのだけれども、だいたい書かれていることは

で読める。

そして、変更コスト曲線の話については(Yourdonさんのスライドにも書かれている通り)『アジャイルと規律』で改めてBoehmがアップデートを書いている。同書でBoehmが言っていることを要約すると次の通り。

  • 大規模プロジェクトにおいては再検証してみても、やはり「納品後のソフトウェアの変更は要求フェーズでの変更より100倍も高くつく」傾向にある
  • 変更コストの80%はシステム全体に影響を及ぼす20%の変更からもたされれる。よって早期のリスク軽減や、変更の影響を局所化するアーキテクチャの設計をすることで、大規模システムでも「高価な20%」の変更コストを大幅に削減できる可能性がある。
  • 一般的に大規模プロジェクトは、変更コスト曲線の勾配がきつくなる傾向にあるので、XPを採用するのにふさわしい候補ではない。
  • 小規模なアジャイルプロジェクトについても、データを見る限りストーリー番号が増加するに従って変更コストは増加している。"これは、些細なものだとすませられる増加率ではないし、アジャイルの専門家がエピソードとして語る経験値ほど良くないことも明らかである"

とはいえ、その後Boehmは「すべてを先に決めないといけない」という考え方は誤りであることを認めている(2008年)。このあたりは平鍋さんの下記ブログも参考に。

さらにBoehmは2010年、Making Software ―エビデンスが変えるソフトウェア開発においてこの議論を総括している。

第10章 アーキテクティング：いつ、どれだけ？ バリー・ベーム（Barry Boehm）
この章では、プロジェクトや組織がソフトウェア開発に際して、どのような時にアジャイル手法とアーキテクティングアプローチのどちらを使うべきかを判断する助けとなる研究を紹介します。ソフトウェアプロジェクトやソフトウェア主導なプロジェクトの管理者たちがアーキテクティングの重要性を十分に認識しているとしても、彼らの手持ち資源は常に有限であるため、「どれだけアーキテクティングを行えば十分なのか？」と自問することはよくあります。
Making Software ―エビデンスが変えるソフトウェア開発

詳細は同書を確認していただくとして、「すべてを先に決めないといけない」というわけではないながらも、プロジェクトの規模や特色によって慎重に検討する必要があるといった事が書かれている。少なくとも、欠陥が下流に「漏れる」と修正コストが増加することは否定されていないという点に注意が必要である。

Making Software ―エビデンスが変えるソフトウェア開発

Making Software ―エビデンスが変えるソフトウェア開発

  • 発売日: 2011/09/24
  • メディア: 大型本
なお本書はオライリーでPDFを購入することができる(私はそっちを買った)。

6.トレードオフは非線形

人と時間のトレードオフは、3次多項式
Capers Jones ( 『ソフトウェア見積もりのすべて』) によると、 欠陥 = k*ファンクショ ンポイント**1.25
頭で計算することは困難！
小さくないプロジェクトでちゃんとした交渉をするためには、十分に強力な見積もりツ ールが必要 (例えば.,SLIM,Costar)

人と時間のトレードオフが非線形であることは以前に以下の記事でも取り上げている。

なにはともあれ、直感的な見積りほど信用ならないものはない。
この記事でも紹介しているけど以下の本がおすすめ。

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

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

7.再利用は重要

コードの再利用だけでなく、設計、仕様、プロセス、計画、 予算テンプレート、チーム、などの再利用。
再度: 技術はビジネス/文化的な問題よりも重要ではない
再利用のコストを無視してはいけない

かなり古典だけれどもソフトウエア開発 55の真実と10のウソで詳しく取り上げられている問題ではある(その後に発表された技術書で本テーマを扱ったものをあまり知らない)。

  • 15.小規模な再利用(例えば、ライブラリやサブルーチン)は50年前に始まり、既に解決済みの問題である。
  • 16.大規模な再利用(コンポーネント単位)は、誰もがその重要性を認識し、なくてはならないと感じているが、今なお未解決である。
  • 17.大規模な再利用は、類似システム間ではうまくいく可能性が高い。応用分野の類似性に依存するため、大規模流用の適用範囲は狭くなる。
  • 18.再利用には、2つの「3つの法則」がある。
    • 再利用可能なコンポーネントを作るのは、単一のプログラムで使うモジュールの開発に比べ3倍難しい
    • 再利用可能なコンポーネントはライブラリに取り込む前に、3つの異なるプログラムでテストする必要がある。
  • 19.プログラムを再利用する場合、流用母体の変更はバグの原因になる。20-25%も変更する必要があるなら、最初から作った方が効率が上がるし、品質も良い。
  • 20.デザインパターン方式の再利用は、ソースコードの再利用における問題を解決する一手段である。

ソフトウエア開発 55の真実と10のウソ

ソフトウエア開発 55の真実と10のウソ

ソフトウエア開発 55の真実と10のウソ

コードの再利用に関してはこのとおりであって付け加えるものはあまりない認識。
ビジネスレベル、文化レベル(プロセスレベル)の再利用を考えるべきということではないかと考えている。

8.リスクマネジメントが鍵

リスクマネジメントの共有が肝
再度: 議論の中心は文化的な問題であり、政治であり、技術ではない。(2007-2008 の銀行危機と同じように)

有名なのはこの本だけど、現在はリスクマネジメント技法は標準化されているのでそれに従えばいいと思っている。

熊とワルツを　リスクを愉しむプロジェクト管理

熊とワルツを　リスクを愉しむプロジェクト管理

どちらにしても、技術の問題ではない。

後編に続く。

関連する記事