ライティングソフトウェア

プロダクトとプロジェクトを泥沼から救う工学的手法

【本書の内容】
本書は
Juval Löwy, "Righting Software",
Pearson Education, 2020
の邦訳版です。

オブジェクト指向以降、プロダクトを機能によって分解・構成する手法が一般化しましたが、再利用性やメンテナンス性は言うほど高まってはいません。それは、小さな変更が波及的にプロダクト全体の修正を要求するようになるからです。
そこで「機能」ではなく、「変動性」に着目することで、本来の「設計 (デザイン)」を取り戻します。

さらに、変動性を生む要因となる「プロジェクト」自体も、ヒト・モノ・カネ・時間・リスクといった複雑に絡み合う全アクティビティを定量化し、バランスのよい計画と軌道修正を可能にするプロジェクトデザイン (設計) の方法を提示します。

【本書のポイント】

・機能別分解思考から変動性抽出方法へのシフト方法

・プロダクトにかかる人員・品質・コスト・納期・リスクの評価

・全アクティビティのパラメータ抽出および評価方法

・破綻せずに妥当なラインに落とし込むバランスの見つけ方

・図版は 4 色

【読者が得られること】

・無理・無駄のないプロジェクト

・ブラックな現場をホワイト (せめてグレイ) にする手法

・炎上案件の見極め能力・修正能力

【著者について】
Juval Löwy (ジュヴァル・ローウィー) は IDesign の創設者で、システム / プロジェクトデザインを専門とするソフトウェアアーキテクトの重鎮である。納期、コスト内に高品質のソフトウェアを完成させるために、世界中の無数の企業を支援してきた。マイクロソフトに世界のトップエキスパート、業界のリーダーの 1 人として認められ、C#、WCF と関連テクノロジーの社内戦略的デザインレビューに参加し、「ソフトウェアのレジェンド」と呼ばれた。数冊のベストセラー本と現代のソフトウェア開発のほとんどあらゆる側面についての数々の論文を発表している。メジャーな国際的ソフトウェア開発カンファレンスで頻繁に演壇に立ち、現代のソフトウェアアーキテクトに求められるスキルは何か、デザイン、プロセス、テクノロジーのリーダーとしてどのように責務を果たすべきかを無数のプロフェッショナルたちに伝授している。

機能ごとにモジュールを切る設計は直感的ですが、小さな変更がプロダクト全体の修正を要求する構造を生みやすいという弱点があります。『ライティングソフトウェア』 (Juval Löwy 著、長尾高弘 訳、翔泳社、2021 年 4 月刊) は、この機能別分解をやめて「変動性」に着目してシステムを設計し、さらにプロジェクト自体もヒト / モノ / カネ / 時間 / リスクを定量化して設計する方法を説く一冊です。原著は Juval Löwy の Righting Software (Pearson Education、2020 年) で、副題は「プロダクトとプロジェクトを泥沼から救う工学的手法」。版元は本書を、システムとプロジェクトのデザインに構造工学のアプローチを取り入れる方法の説明と位置づけています。著者は IDesign の創設者で、版元の著者紹介ではマイクロソフトの C# や WCF に関する社内戦略的デザインレビューに参加し、「ソフトウェアのレジェンド」と呼ばれたと記されています。

第 1 部 システムデザインの 4 章、機能別分解から変動性に基づく分解へ

本文は全 14 章と付録 3 本で、序論にあたる第 1 章「ザ・メソッド」が方法論の全体像とそれが何ではないかを示した後、2 部に分かれます。第 1 部システムデザインは第 2 章から第 5 章までの 4 章で、第 2 章「分解」が機能別分解をしてはいけない理由と変動性に基づく分解、変動領域の見つけ方を説き、第 3 章「構造」がユースケースと要件、階層化されたアプローチ、サブシステムとサービス、オープンアーキテクチャとクローズドアーキテクチャを扱います。第 4 章「組み立て」は要件とその変更、組み立てられるデザイン、変化の処理を扱い、第 5 章「システムデザインの実例」で一つのシステムを題材にアンチデザインの試みから検証までを通して見せます。

第 2 部 プロジェクトデザインの 9 章、クリティカルパスとリスクの定量化

第 2 部プロジェクトデザインは第 6 章から第 14 章までの 9 章を占め、章数の上でも本書の重心です。第 7 章「プロジェクトデザインの概要」で成功の定義、作業量の見積もり、クリティカルパス分析、工程のスケジューリング、予定出来高までを一通り示し、第 8 章でネットワーク図とフロート、第 9 章でスケジュールの圧縮と時間とコストの曲線、第 10 章でリスクのモデリングと指標を掘り下げます。第 11 章「プロジェクトデザインの実際」と第 13 章「プロジェクトデザインの実例」はいずれも具体例を通す章で、基準ソリューションの特定からネットワークの圧縮、デザイン候補の比較、SDP レビューへの準備まで一連の手順を追います。第 12 章「高度なテクニック」にはゴッド工程やリスク交差点、非常に大規模なプロジェクトと小規模プロジェクトの扱いが並び、第 14 章がまとめとヒントです。付録 A はプロジェクトの進行管理、付録 B はサービスのコントラクトデザイン、付録 C は本書全体の鉄則とガイドラインを集めたデザイン標準です。

機能で切ると壊れる理由、変動性を軸に据える技術背景

オブジェクト指向以降に一般化した機能別の分解は、要件の一覧をそのままモジュールの一覧に写すため、要件が変わるたびに複数のモジュールへ変更が波及します。これは モジュール間の結合 が業務の語彙に沿って張られてしまうことの帰結で、サービスの境界をどこに引くかという問いに機能の粒度で答えても解決しません。変動性に基づく分解は、将来変わりうる領域を先に見つけ、それぞれをカプセル化する単位としてサービスを切るという発想の転換です。本書がプロジェクトデザインを同じ重さで扱うのも、変動性を生む要因はプロダクトだけでなくプロジェクトにもあるという版元の説明に沿っています。人員配置や納期の判断を勘で行えば、良いアーキテクチャも実装の途中で崩れます。クリティカルパスやフロート、時間とコストとリスクの関係を数値で扱う第 2 部は、プロジェクト管理 を経験則から工学へ引き上げようとする試みとして読めます。

向いている読者と、実装レシピを求める人には向かない点

版元が読者の得るものとして掲げるのは、無理 / 無駄のないプロジェクト、ブラックな現場をホワイト (せめてグレイ) にする手法、炎上案件の見極め能力と修正能力です。したがって最も元が取れるのは、システムの分割やプロジェクト計画の判断を任される立場のアーキテクトやテックリード、プロジェクトの見積もりと納期に責任を持つマネージャーです。前提として、階層化やサービス、見積もりやスケジューリングといった語が指す実務を一度は経験していることが望ましく、目次に特定の言語やフレームワークは登場しないため、コードの書き方や実装パターンを学びたい段階の人には向きません。設計書の読み方や関連書の位置づけから入りたい場合は 設計 / アーキテクチャ本ガイド で全体像を確かめてから本書へ進むと、第 1 部の主張がどの層の設計に効くのかを掴みやすくなります。

図版が 4 色で組まれた B5 変型判の一冊は、読み物としてより参照書として手元に置く性格が強く、付録 C のデザイン標準は設計レビューの基準として引きやすい形にまとまっています。機能で切ったシステムの変更コストに悩んでいる人、あるいは見積もりと納期の根拠を数値で説明できるようになりたい人にとって、設計とプロジェクトの両方を一つの方法論で貫く本書は、投じた時間に見合う判断基準を残してくれる選択です。