Juval Löwy（著） , 株式会社ロングテール 長尾高弘（翻訳）
※1点の税込金額となります。 複数の商品をご購入いただいた場合のお支払金額は、 単品の税込金額の合計額とは異なる場合がございますので、予めご了承ください。
【本書の内容】
本書は
Juval Löwy, "Righting Software",
Pearson Education, 2020
の邦訳版です。
オブジェクト指向以降、プロダクトを機能によって分解・構成する手法が一般化しましたが、再利用性やメンテナンス性は言うほど高まってはいません。それは、小さな変更が波及的にプロダクト全体の修正を要求するようになるからです。
そこで「機能」ではなく、「変動性」に着目することで、本来の「設計（デザイン）」を取り戻します。
さらに、変動性を生む要因となる「プロジェクト」自体も、ヒト・モノ・カネ・時間・リスクといった複雑に絡み合う全アクティビティを定量化し、バランスのよい計画と軌道修正を可能にするプロジェクトデザイン（設計）の方法を提示します。
【本書のポイント】
・機能別分解思考から変動性抽出方法へのシフト方法
・プロダクトにかかる人員・品質・コスト・納期・リスクの評価
・全アクティビティのパラメータ抽出および評価方法
・破綻せずに妥当なラインに落とし込むバランスの見つけ方
・図版は4色
【読者が得られること】
・無理・無駄のないプロジェクト
・ブラックな現場をホワイト（せめてグレイ）にする手法
・炎上案件の見極め能力・修正能力
【著者について】
Juval Löwy（ジュヴァル・ローウィー）はIDesignの創設者で、システム／プロジェクトデザインを専門とするソフトウェアアーキテクトの重鎮である。納期、コスト内に高品質のソフトウェアを完成させるために、世界中の無数の企業を支援してきた。マイクロソフトに世界のトップエキスパート、業界のリーダーの1人として認められ、C#、WCFと関連テクノロジーの社内戦略的デザインレビューに参加し、「ソフトウェアのレジェンド」と呼ばれた。数冊のベストセラー本と現代のソフトウェア開発のほとんどあらゆる側面についての数々の論文を発表している。メジャーな国際的ソフトウェア開発カンファレンスで頻繁に演壇に立ち、現代のソフトウェアアーキテクトに求められるスキルは何か、デザイン、プロセス、テクノロジーのリーダーとしてどのように責務を果たすべきかを無数のプロフェッショナルたちに伝授している。
本書はJuval Löwy著『Righting Software』（Pearson Education, 2020）の邦訳版です。
オブジェクト指向以降、プロダクトを機能によって分解・構成する手法が一般化しましたが、再利用性やメンテナンス性は言うほど高まってはいません。それは、小さな変更が波及的にプロダクト全体の修正を要求するようになるからです。そこで「機能」ではなく、「変動性」に着目することで、本来の「設計(デザイン)」を取り戻します。さらに、変動性を生む要因となる「プロジェクト」自体も、ヒト・モノ・カネ・時間・リスクといった複雑に絡み合う全アクティビティを定量化し、バランスのよい計画と軌道修正を可能にするプロジェクトデザイン(設計)の方法を提示します。
本書は、システムとプロジェクトのデザインに構造工学のアプローチを取り入れる方法を説明します。このメソドロジはシステムデザイン（いわゆるアーキテクチャ）とプロジェクトデザインの2 つの部分に分かれており、それが本書の構成にも反映されています。これら2つは、互いに補い合うもので、成功のためには両方が必要です。付録では、本論を補うテーマをいくつか取り上げます。
第1章 ザ・メソッド
1.1 ザ・メソッドとは何か
1.2 ザ・メソッドは何ではないか
■第1部 システムデザイン
第2章 分解
2.1 機能別分解をしてはいけない
2.2 変動性に基づく分解
2.3 変動領域の見つけ方
第3章 構造
3.1 ユースケースと要件
3.2 階層化されたアプローチ
3.3 典型的な階層
3.4 分類のガイドライン
3.5 サブシステムとサービス
3.6 オープンアーキテクチャとクローズドアーキテクチャ
第4章 組み立て
4.1 要件とその変更
4.2 組み立てられるデザイン
4.3 機能はない
4.4 変化の処理
第5章 システムデザインの実例
5.1 システムの概要
5.2 アンチデザインの試み
5.3 ビジネスと歩調を揃える
5.4 アーキテクチャ
5.5 デザインの検証
5.6 次にすべきこと
■第2部 プロジェクトデザイン
第6章 プロジェクトデザインが必要な理由
6.1 なぜプロジェクトデザインか
第7章 プロジェクトデザインの概要
7.1 成功の定義
7.2 プロジェクトの初期の人員配置
7.3 知識に基づく判断
7.4 サービスと開発者
7.5 作業量の見積もり
7.6 クリティカルパス分析
7.7 工程のスケジューリング
7.8 プロジェクトのコスト
7.9 予定出来高
7.10 職務と責任
第8章 ネットワークとフロート
8.1 ネットワーク図
8.2 フロート
8.3 フロートベースのスケジューリング
第9章 スケジュールとコスト
9.1 ソフトウェアプロジェクトの加速化
9.2 スケジュールの圧縮
9.3 時間̶コスト曲線
9.4 プロジェクトのコスト要素
9.5 ネットワークの圧縮
第10章 リスク
10.1 デザイン案の選択
10.2 時間̶リスク曲線
10.3 リスクのモデリング
10.4 圧縮とリスク
10.5 リスクの弛緩
10.6 リスクの指標
第11章 プロジェクトデザインの実際
11.1 任務
11.2 基準ソリューションの特定
11.3 ネットワークの圧縮
11.4 効率分析
11.5 時間̶コスト曲線
11.6 プランニングとリスク
11.7 SDPレビュー
第12章 高度なテクニック
12.1 ゴッド工程
12.2 リスク交差点
12.3 弛緩ターゲットの見つけ方
12.4 幾何リスク
12.5 遂行の複雑度
12.6 非常に大規模なプロジェクト
12.7 小規模プロジェクト
12.8 階層構造によるデザイン
第13章 プロジェクトデザインの実例
13.1 見積もり
13.2 依存関係とプロジェクトネットワーク
13.3 基準ソリューション
13.4 圧縮ソリューション
13.5 階層構造によるデザイン
13.6 亜極限ソリューション
13.7 デザイン候補の比較
13.8 プランニングとリスク
13.9 SDPレビューへの準備
第14章 まとめとヒント
14.1 いつプロジェクトデザインをすべきか
14.2 全般的なガイドライン
14.3 プロジェクトデザインのデザイン
14.4 遠近法
14.5 移管
14.6 練習
14.7 プロジェクトデザインの反省会
14.8 品質について
■第3部 付録
付録A プロジェクトの進行管理
A.1 工程のライフサイクルと状態
A.2 工程の状態
A.3 プロジェクトの状態
A.4 進捗度と作業量の追跡調査
A.5 プロジェクトの今後の予測
A.6 予測と問題への対処策
A.7 予測についてさらに
付録B サービスのコントラクトデザイン
B.1 これはよいデザインなのか
B.2 モジュラー性とコスト
B.3 サービスとコントラクト
B.4 コントラクトの分割
B.5 コントラクトデザインのガイドライン
B.6 コントラクトデザインの課題
付録C デザイン標準
C.1 最高鉄則
C.2 鉄則
C.3 システムデザインのガイドライン
C.4 プロジェクトデザインのガイドライン
C.5 プロジェクト進行管理のガイドライン
C.6 サービスコントラクトデザインのガイドライン
Kitamuu さん
最高鉄則 要件に合わせてデザインしてはならない。 品質は究極のプロジェクト管理テクニック。ほとんど管理しなくてもチームは最大限の生産性を発揮するようになる。品質への非妥協的なこだわりをチームに定着させるとこだ。 ダニング＝クルーガー効果。ある分野のスキルを持たない人間は、その分野の複雑度、リスク、需要を過小評価し、その分野を軽視する。 前と同じようなことをしながら、前よりも良い結果になるだろうと思うのは、まともな人間のすることではない。
Kenji Hiranabe さん
2021-06-05
ほとんど話題になってないが、アジャイル逆張りの良い本。
翔泳社のプログラミング書籍の中から、入門・初級者向けの書籍をピックアップ！
【Linux本特集】入門～達人レベルまで！クラウド時代の必須知識Linuxを学ぶおすすめの本
ライティングのスキルアップにおすすめの本。Webライティングやコピーライティングなど
お金と経済の基礎知識から、資産形成・投資術、お金教育や介護まで。暮らしに役立つマネー本
おしゃれな部屋作りのヒントやインテリアの基礎知識、色使い、うつわや洋食器の知識まで、幅広い書籍をご紹介
Excel、日商簿記、業務の自動化を実現するRPAやPythonの技術など、事務職としてステップアップしたい人に！
