「ソフトウェア・グラフィティ」の感想
ソフトウェア・グラフィティを読んだ。
エッセー風の語り口が読みやすかった。
感想をラフなメモ書き。
ソフトウェア・グラフィティは、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目的にすると楽しくない。
ソフトウェアファクトリーは、駅弁をどうやって早く安く作るかを目指したものであり、料理人にとって楽しい仕掛けではない。
(ソフトウェアの工業化の方向性は、アジャイル開発とは全く違う。
アジャイル開発における開発環境の整備は、リリースするサイクルをいかに短くして価値あるソフトウェアを作っていくか、が根本的な発想。
チケット駆動開発もその流れの一つ。)
| 固定リンク
「IT本」カテゴリの記事
- ビジネス書の名著はどれ?(2023.09.18)
- 「ゲームをテストする バグのないゲームを支える知識と手法」の感想(2023.06.10)
- JavaGold SE11の感想(2022.12.25)
- 「Redmineハンドブック」は良い本です(2022.12.17)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
「プログラミング」カテゴリの記事
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのモジュールシステムは複雑性をより増している(2022.09.10)
- Javaはなぜ関数型言語になろうとしているのか(2022.09.02)
- Javaのラムダ式の考え方(2022.08.10)
- Javaはオブジェクト指向言語ではなく関数型言語だった~「[増補改訂]関数プログラミング実践入門」はお勧めの本だ(2022.08.06)
「プロジェクトマネジメント」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
「ソフトウェア工学」カテゴリの記事
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- 「ゲームをテストする バグのないゲームを支える知識と手法」の感想(2023.06.10)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
コメント