『ソフトウェア開発の名著を読む』を読む - 令和の未来カエルのブログ

「『ソフトウェア開発の名著を読む』を読む」　というタイトルのブログですが、この投稿読んだ人は、【「『ソフトウェア開発の名著を読む』を読む」を読む」】となります。

（初版　2006/7/26　柴田芳樹 (著)）を読んで、その要点や感想などを紹介します。

結局は人

　ソフトウエアは、「人」が開発します。だから、「人」の心理、能力、管理が、ソフトウェアの開発の肝といえます。
　ソフトウェア以外でも、知識集約型、労働集約型の産業では、「人」の心理、能力、管理の大切さに該当することが多いでしょう、記載されていて、参考になりました。
逆に言うと、ソフトウェアの開発というのは、あまり特別視せずに、他の産業、業種のベストプラクティスなどの事例が適用できるように思いました。

ソフトウェア職人気質― (Professional Computing Series)

一番印象的なっだ名著は、

です。

　原題はSoftware Claftsmansihpで、ソフトウェア職人技といった略の方が原題の雰囲気が伝わるのかなと思いました。

　多くの現場で必要なのは、理論工学、技術でなく、優秀な管理者でなく、職人でしょう。組織化、制度化、標準化も必要であるが、職人を育てる努力や職人を尊敬する意識が必要なのは、どの業界でもいえることです。

　ソフトウェア業界で退職者が多いのも、職人気質の軽視に原因があるのでは。と感じまいた。ここでいう職人、職人気質、Claftsmansihpとは、
　〇　経験に裏付けられた熟練の必要な技芸、知識、勘がある。
　〇　継続的な学習を実践をしている。
　〇　芸術性に対する感覚がある。
　〇　人、そういった気質のことです。

芸術性に対する感覚は、
　いわゆる「きれいなソース」「見やすい画面」などにこだわるといった意味だと理解しています。
　ちなみに、職人って、英語でClaftsmanていうんですね。知りませんでした。

デッドライン

二番目に印象的だったのは、「デッドライン」です。

　プロジェクトには、管理と管理ごっこがあり、

　正しい管理は、

　●適材適所で人を採用　

　●適材適所で人を配置

　●士気を高め維持する

　● 組織の結束を高め維持する。
　であり、それ以外は管理ごっこらしいです。

　●優れたプロジェクトは設計に時間をかけ、デバッグの時間が短い。
　●短期的に生産性を高める方法は、インチキである可能性が高い。生産性は長期的な投資によって高まる。
　●プレッシャーをかけても、生産性、思考のスピードは上がらない。

とうことです。プレッシャーは、残業と置き換えてもいいかもしれません。

達人プログラマー職人から名匠への道

　三番目ぐらいに、印象的だったのは、「達人プログラマー職人から名匠への道

」です。ベンジャミンフランクリンの格言「知識への投資は最高の利息がついてきます。」を引用して、あなたの知識と経験は、あなたのプロの資産として大事であるが、陳腐化することを説いて今う。

　だから、毎年一つの新しい言語を習得する、四半期毎に技術書、技術書以外の書籍を読む、講習を受講する、ローカルユーザーグループに参加するなど推奨しています。

『割れた窓（つまり悪い設計、誤った意思決定、質の悪いコードなど）をそのまま放置してはいけいません。発見と同時にすぐに修復するのです。
もし正しく修復するだけのそれだけの時間がない場合は、その旨をわかりやすいところに明示しておくのです。』
と説明しているが、実際に割れた窓の修正が、デグレ、さらなる不具合につながるので、『言うや易し』で難しい。ただ、割れた窓を放置すればするほど、修復は難しくなることも事実で、修復のタイミングが重要だと感じています。

全体を通して

以下ような章立で、名著を紹介しています。本のタイトルにアマゾンのリンクを設定しています。

　第一部　ソフトウェアは「人」がつくる
　　ワインバーグ　「プログラミングの心理学」
　　ブルックス　「人月の神話」
　　デマルコ、リスター　「ピープルウエア」
　　デマルコ　「デッドライン」
　第二部　実践する開発者
　　マクブリーン　「ソフトウェア職人気質― (Professional Computing Series)」
　　ハント、トーマス　「達人プログラマー職人から名匠への道」
　第三部　読みやすいコードを書く。
　　マコネル　「プログラミング作法 (アスキードワンゴ)」
　　カーニハン　「【Code Complete 第2版　完全なプログラミングを目指して」

初学者、初心者に、上級者が必ず指導さえる『読みやすいコードは大事』といったことが、名著でも説かれていました。他人が直接ソースを解析することも少ない今でも大事なのかな。という感想も持ちましたが、自分が解析することを考えても、読みやすさはやはり大事なんでしょう。

　時の洗礼を経た名著ということだが、20年、30年経過しても、解決できない問題は、解決しようと努力する問題でないかもしれません。なぜ、解決できないのか、新しい視点が求められます。解決できない問題、解決が難しい問題はは、所与の条件として、リスクとして予め組み込んだ制度、計画が求められるかもしれまえん。

改めて本紹介

　時が流れ、技術が変わっても、ソフトウェアは人がつくるという事実は不変であり、この真実をとらえた書籍はけっして色褪せない。コンピュータ産業の歴史に多大な影響を与えてきた不朽の名著8冊から、ソフトウェア開発の「本質」を読み解く。
内容（「BOOK」データベースより）

コンピュータが人類の歴史に登場して以来、その進化のスピードは一向に衰えることなく、21世紀の現在ではさらに加速している。その一方で、ソフトウェアは「人」が開発するという事実は不変であり、この真実をとらえた書籍は時の経過にもけっして色褪せることがない。コンピュータ産業の歴史に多大な影響を与えてきた不朽の名著8冊から、ソフトウェア開発の「本質」を読み解く。

著者略歴 (「BOOK著者紹介情報」より)
柴田芳樹
1959年生。九州工業大学および大学院で情報工学を専攻し、以来、ソフトウェア開発に従事する(本データはこの書籍が刊行された当時に掲載されていたものです)