「ソフトウェア・グラフィティ」の感想
ソフトウェア・グラフィティを読んだ。
エッセー風の語り口が読みやすかった。
感想をラフなメモ書き。
ソフトウェア・グラフィティは、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本」カテゴリの記事
- 「コーディングを支える技術」は良い本だ(2022.05.26)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
- 実践した後に勉強するのがエンジニアの本来の道(2022.01.09)
- OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない(2021.08.01)
- INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントの感想~日本に足りないのはプロダクトマネジャーだ(2021.08.01)
「プログラミング」カテゴリの記事
- Javaはオブジェクト指向言語ではなく関数型言語だった~「[増補改訂]関数プログラミング実践入門」はお勧めの本だ(2022.08.06)
- JavaSilverの感想~Javaはオブジェクト指向と関数型言語の2つの性格を持つ(2022.07.06)
- Javaのenum型はシングルトンクラスみたいだ(2022.06.20)
- 「コーディングを支える技術」は良い本だ(2022.05.26)
- 「RubyやRailsは終わった」という記事のリンク(2022.01.09)
「プロジェクトマネジメント」カテゴリの記事
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- 初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ(2022.04.17)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
「ソフトウェア工学」カテゴリの記事
- Javaのラムダ式の考え方(2022.08.10)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
- メトリクス分析のコツは良いIssueを見つけること(2022.06.29)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
「チケット駆動開発」カテゴリの記事
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
- Redmineにメンション機能が入るらしい(2022.01.15)
「Agile」カテゴリの記事
- 組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない(2022.08.05)
- 製造業の業務にスクラムを適用できるのかという疑問~全てのビジネスモデルにスクラムを適用できるのか?(2022.07.31)
- 認定スクラムプロダクトオーナー研修の感想(2022.07.28)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
コメント