「ソフトウェア・グラフィティ」の感想

ソフトウェア・グラフィティを読んだ。
エッセー風の語り口が読みやすかった。
感想をラフなメモ書き。

ソフトウェア・グラフィティは、SRAを創立した岸田さんの自叙伝みたいなもの。
本来は詩人・画家と書かれているように、ソフトウェアの本と言うよりも文系に近い本なので、難解な部分もある。
でも僕には、ああなるほどと思える部分が多々あった。
以下、心に響いた部分を抜粋し、()の部分は僕の感想。

【1】構造化設計は2種類ある。
ダイクストラはGOTO文を破棄する方向。
それは、読みやすいプログラムをコンピュータ上でそのまま実行できるように設計しようとする発想。
逐次実行、分岐、反復の命令型言語への流れ。
ジャクソンやワーニエは、データ構造を反映するようなプログラムへ設計仕様とする発想。
対象システムのモデル化の発想は、多分DOAへの流れ。
つまり、二人の構造化設計の発想は全く異なる。

【2】ソフトウェア開発は演劇。
プロマネは舞台の監督。
シナリオ(システムの仕様書)をベースに、役者(プログラマ)のキャスティングを決めて、それぞれの演技(開発活動）をうまく取りまとめて、顧客(ユーザ)の満足を勝ち取る。
だが、本来ユーザが考えるべきシステムの問題解決をプログラマへ要求するようになるため、プログラマから特定分野のコンサルタントに転進していく人が多い。

【3】リーマンのソフトウェア進化論。
IBMのOS360プロジェクトを元に見出した経験則。
3つの法則がある。
第1の法則は、ソフトウェアサイズは時間の経過と共に増加する。
第2の法則は、ソフトウェアの品質は時間と共に劣化していく。
つまり、ソフトウェアもエントロピー増大の法則に従う。

第3の法則は、保守工程におけるソフトウェアの追加・変更・削除のモジュール数の増加は時間の経過と共に比例している。
つまり、ソフトウェア保守の組織的作業効率は常に一定である。
人を増やしても作業効率は変わらない。
作業の難易度や保守担当チームの人数などの要因に無関係に一定である。

(アジャイル開発では、「時間が経過してもソフトウェアのサイズや複雑さ、保守コストは抑えることができる」という発想から成り立つ。
だから、リーマンの法則に逆らう事象は可能だという発想ゆえ、根本的に異なる。)

リーマンの法則～ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

【4】リーマンによる2種類のプログラムの分類。
Sタイプは、仕様が確定できる(Specificable)。
一度仕様が確定できれば、その解決法(アルゴリズム)を表現したプログラムは、時間が経過しても変わらない。

Eタイプは、組み込まれた(Embeded)プログラム。
現実世界における業務を支援するために開発され、アプリケーションに組み込まれる。
仕様は利害関係者の最大公約数で決まるものであり、要求そのものは矛盾があるのが普通。
その時点の暫定的な仕様であり、時間が経てば、環境が変わったり、要求そのものが変わったりして、仕様も変わる。
1回目は「開発」、2回目以降は「保守」という開発サイクルは間違っている。

【5】プロジェクトマネジメントの基礎として、ソフトウェアの価値はどのように定義すべきか？
普通は、開発工数(人月)を元に評価し、進捗に応じて生産高を確定するのが主流。
(EVMみたいだ)
しかし、ソフトウェア開発は本来無形労働(Immaterial Labor)であり、その成果を定量的に把握するのは難しい。
むしろ定性的な値で評価すべきだ。
(アジャイル開発なら、リリースされたソフトウェアと言う現物で価値を測定する。ソフトウェアのROIが価値を表す。)

【6】ソフトウェア開発環境を議論にする時、生産性向上や品質改善を第1目的にすると楽しくない。
ソフトウェアファクトリーは、駅弁をどうやって早く安く作るかを目指したものであり、料理人にとって楽しい仕掛けではない。
(ソフトウェアの工業化の方向性は、アジャイル開発とは全く違う。
アジャイル開発における開発環境の整備は、リリースするサイクルをいかに短くして価値あるソフトウェアを作っていくか、が根本的な発想。
チケット駆動開発もその流れの一つ。)

日本型ソフトウェアファクトリーこそ真の敵 - 勘と経験と読経