@kazuo_reveマネージャー・リーダーの私にとって有益な知見が得られた書籍
記事を拝見して、bookmeterへと飛んだ。
そして、amazon.co.jpへと飛んだ。
すると、amazon.co.jpには感想が書いてあるのに、bookmeter.comには書いてないものを３つ発見した。
読書メーターの「今まで買ってよかった技術書を紹介しよう！」
という企画でも、amazon.co.jpには感想が書いてあるのに、bookmeter.comには書いてないものが同様に３冊発覚している。
合計６冊の紹介と、他の @kazuo_reveさんが紹介しているもののうち、
私が読書メーターに感想を記録していたものを紹介する。
この記事を書こうと思ったのは、このQiitaの期間限定行事での私の記事いいねの最高数をあっというまに抜き去ってしまった記事への感謝と内容への謝辞を込めてるんです。
先端技術者のためのトラブルシューティング技術―組込みシステムの品質問題をこの一冊で原因究明
開発中止を上から言い渡され、市販品を使わされ、バグ取りに奔走させられ、よくある大企業での開発現場の状況が描写されている。判断できない人が判断したことによるつけまで、現場に追わせるような人がいる会社では、後追い不具合対策で手一杯になる。不具合対策で、原因究明の経験を、それなりに分類して説明してくれている。だいたいが、思い当たる。きちんと書籍になっていることは嬉しい。おまけに、わかりやすい図表が入っているので、他人に説明する際にも役立つ。開発中止を上から言い渡され、市販品を使わされ、バグ取りに奔走させられ、よくある大企業での開発現場の状況が描写されている。判断できない人が判断したことによるつけまで、現場に追わせるような人がいる会社では、後追い不具合対策で手一杯になる。不具合対策で、原因究明の経験を、それなりに分類して説明してくれている。だいたいが、思い当たる。きちんと書籍になっていることは嬉しい。おまけに、わかりやすい図表が入っているので、他人に説明する際にも役立つ。技術者で表現が下手な人がいると、誤解を受けることがある。ちゃんとした表現をしている本書を使って、自分が表現できないことは、他人の表現を見せることによって、解決していくのがよいと思いました。しばしば本書を薦めさせていただいています。
@kazuo_reve さんの感想
金子さんの講演は楽しい、刺激がある。経営者やPMは、是非一度話を聞いてみるみよい。トラブルシューティングについて、体系的に知識を整理した本ははじめて見た。自分の中に、本書で示されているような方法論を持ち、使いこなせるようになりたい。
トラブルシューティング(デバッグ)について実体験から学んだこと
「失敗の本質―日本軍の組織論的研究」，戸部 良一, 寺本 義也, 鎌田 伸一, 杉之尾 孝生, 村井 友秀, 野中 郁次郎
戦略研究(OR: operational research)の専門書では、 日本とドイツには、ORがデータに基づいたものがなかったという評価がある。 結果論なので、どうともいえるが、失敗を反省すべきところはすればよいと思う。 企業経営において、同じ過ちを繰り返さないようにするのがいいか。 国家経営と企業経営が違うのか。 見極めが必要だと思った。
#「ゆとりの法則 － 誰も書かなかったプロジェクト管理の誤解」，トム・デマルコ
ゆとりが、改善ののりしろ。ゆとりがないと、改善できないという話がつかみ。 P37 「NPO（非営利組織）では、管理をしないか、または管理をして全員いなくなってしまうかだ。」 「管理者は１００％自分に管理権限があると思い込み、私の仕事はすべてを管理すること、 部下の仕事はすべてをやることだと思っていた。違った考えをするまでには、長い時間がかかった。」 非常にうまい点を捉え方をしている。 ファンが多いのもうなづける。
@kazuo_reve さんの感想
プレッシャーがパフォーマンスに与える影響を認識する必要あり。リスク管理は、専門の担当者がいたほうがよい。いろいろと大切な考え方多数。周りの管理者もみんな読んだほうがよい。自分も、もう少し経験を積み上げ、もう一度読み直す。
それ以外の「マネージャー・リーダーの私にとって有益な知見が得られた書籍」で感想をあげている本
##「人月の神話【新装版】」，Jr FrederickP.Brooks
恥ずかしながら、有澤先生の「ソフトウェア工学」を読んでブルックスがソフトウェア工学の大家であることを知りました。この本はその前から読んでいたかもしれません。プログラマには当たり前のことが書かれていて納得感あり。ソフトウェア工学の大家の書いたことと、この本とが一致したのは何年か後のこと。仕事で何か行き詰ったときに、この本を読み返すとよい。ソフトウェアを書かずに、現場の役にも立とうとする人は必読。管理者や大学の先生は現場の意見を聞く前に本書を読んでおくとよい。本書を読んで何がわかったかがリトマス試験紙かも。
##「「派生開発」を成功させるプロセス改善の技術と極意」，清水 吉男
参考文献の参考文献は参考文献だ「「派生開発」を成功させるプロセス改善の技術と極意」を超えて
世界中でシステム設計の現場では「新規開発」より「派生開発」としての動いているシステムの変更や機能追加が多い。その点に着目した著者の経験が凝縮。派生開発の場合に何が課題になるかの仕立て。仕様をどうやって明確にする知見が豊富。仕立て(tailoring)だけでなく，現場にあわせた着付け(fitting)もできる。決めたことを決めた通りにやるだけなら能力のある技術者はいらない。どういう制約条件のもとで決めたことか条件が変わったらどうするかを考える能力があるかどうかが課題。
数少ない日本の相談業務（コンサルティング）を頼みたくなる方。一度，清水さんの話をお聞きになられた方なら感じられたと思う。相手を引きつける力、相手に頼む力、相手の話を聴く力がある。自分の経験を大事にする技術者としての感性を持ったまま，経営的な課題に取り組もうとする姿勢がある。著者の書かれたことを勉強するだけでなく，著者そのものを勉強することをお勧めしたい。
@kazuo_reve さんの感想
ドラえもんのポケットの例え好き。変更だけでなく、移植についての言及もある。
ソフトウェアエンジニアリング論文集80's デマルコ・セレクション
IT教育の基本としてきたこと。ソフトウェアエンジニアリング論文集80's デマルコ・セレクション参照。仮説・検証（184）
経営. ソフトウェア工学の超構造化管理 , Gerald M.Weinberg 銀の弾丸はない , Frederick P.Brooks, Jr ソフトウェアコストの理解および制御 , Barry W.Boehm, Phillip N.Papaccio ソフトウェア研究についての私見, Dennis M.Ritchie 測定. ソフトウェア開発見積りのメタモデル , John W.Bailey, Victor R.Basili 方法.生産性改善のためのソフトウェア開発環境 , Barry W.Boehm
「経産省はITSSなるものを打ち上げたのですが、浸透は十分とは言えません。それは表面的な知識を要求しているからです。」 「Hoareの仕事であるCSP(communicating Sequential processes)やHansenの並列パスカルと比べてどこを改良したのかと聞いたところ、そんなものは知らないというのです。私は驚きました。」 「論文の構成」「参考文献の読み方」「重要語にこだわる」 ソフトウェア費用の理解および制御 論文の後に「本論文の今日的意義」「解説」「コンピュータ倫理と職業倫理」
@kazuo_reveさんの感想
すごく面白い。ワインバーグさんの論文で言っている以下は大切。1自分に対する圧力を緩め、自分の業界や分野以外に興味をもち、他の業界や分野から学ぶ時間を作る。2自分に対する過度の管理をやめれば、他人への過度の管理もやめられる。 TEXを開発したKnuthが、エラーログを公開し、エラーログを記録しても同じ誤りをすると述べている。凡人でも天才でも、同じような誤りを繰り返す。自分が誤りを犯すことを認め（予見し）、誤りを探し修正することが大切。
##ソフトウェアプロセス成熟度の改善 ワッツ・S. ハンフリー
CMM関連文献で最初に読んだのが本書でした。1994年頃。CMMを始めとするプロセス評価モデルの標準化として、ISO/IEC15504のTRをISO/IEC JTC1 SC7 WG10で審議していた。本書翻訳者の藤野先生が国内の委員会の主査をされていた。優秀な技術者を集め、当時の技術の最高峰であるAdaを使っても、納期が守れない状況に対して、SEIが、日本などのソフトウェア工場的な仕事の仕方を調べて作成したのが成熟度モデル。アメリカのような歴史の浅い国は成熟した日本社会には学ぶものも多いと推測。
当初はISO/IEC 15504の内容も、経験的な事項で役に立ちそうなことが沢山書かれていました。その後、標準として他の規格との整合性を取ろうとして、形式的な記述が増えてしまったかもしれません。 ちょうど、2008年にJISが発行されました。約１５年かかったことになります。 JISを読む人も、この本も併せて読むとともに、PSP、TSP、PeopleCMMも併せて読むとよいかもしれません。
1993年にISO 9000のソフトウェアへの適用を検討していました。情報処理学会情報規格調査会の会員企業の方から推薦されて、ISO/IEC15504の標準化に取り組むことになりました。
@kazuo_reve さんの感想
！おすすめの本！ソフトウェア開発者（特にプロセス改善に関わる人）は必ず読むべき本。 いろいろの方が述べているが「約束の規律」「約束の作成」「約束の階層」という節は、私も感銘を受けた。また、この本を読むとSQAのイメージも変わると思う。
##「データ指向のソフトウェア品質マネジメント―メトリクス分析による「事実にもとづく管理」の実践」，野中 誠, 小池 利和, 小室 睦
6.1.4 欠陥の分類 がよい。 機能性欠陥 発展性欠陥 に分類している。 全体の章が影響の把握，静的モデル，動的モデル、測定方法という構造が良い。 金融系で聞く具体的な不具合について、データでの分析があると嬉しかった。 事故があっても分析結果を公開していないため不可能かも。
@kazuo_reve さんの感想
私の師匠達の本。現場で活用しやすい、ソフトウェア関連メトリクスの活用ノウハウ。（ソフトウェア品質技術者のための）データ分析勉強会で、テキストとして使った。
分類
ピープルマネジメント、テクノロジーマネジメント、プロジェクトマネジメント、プロダクトマネジメントの評価は貴重ですね。
プロダクトマネジメントの本を読んでないのは、@kazuo_reveさんが、プロダクトマネジャーとして一流だからだと思う。人の本よまずに、ご自身で製品について本を書かれることをお勧めします。
私は移植とか、市場ぶんせきとか、広告宣伝でしか成果をだしておらず、
基本構造を書いたことは、遊びのソフトウェア以外ないんです。
遊びといっても、展示会用のデモソフト、展示会用ゲームソフトなんですが。
試験用ソフト、測定ソフトは本業です。汎用的なものではなく、測定対象に依存した作りになっていて、構造で自慢できることはほぼない。
読書メーターの行事で発覚した３冊
今まで買ってよかった技術書を紹介しよう！
上記、人月の神話と、下記２冊。
Effective C++
Qiitaに一度記事を書きかけたことを思い出しました。
Efective C++をやりはじめなんとか仕事ができるようには 短歌
やっつけの記事。
コンサルタントの秘密
ワインバーグ コンサルタントの秘密
２０代のころ、コンサルが主催する合宿形式のセミナに１週間参加したことがある。設計段階の３人ごとの班単位での参加。コンサルの言うことにことごとく反論したら、つぎつぎ別の知見を提供してくれた。コンサルは吊るし上げなきゃダメなんだということがわかったことと、大事なことにそれぞれ優先順位をつけてから３人で相談しろというのは今でも継承している。一緒に参加した方からは、その後すごく信頼された。吊るし上げなければ、コンサルは何も教えてくれなかったろうと。そんな文脈で読むと面白いかも。吊るし上げなくても教えてくれてる。
感想
あるオープンソースの事業で、技術者のスキル判定をしていた。
スキル判定をする私のスキルは誰に判定してもらおうってなって、
amazon.co.jpに１万冊感想書くから、それを評価してって、
北海道立工業試験場の 掘武司 さんに感想を読んでもらっていた。
読んで、内容に問題がなければいいねをつけてもらう感じで。
3333冊を超えたころに、「もう勘弁してください」って言われた。
国会図書館に籠って、多い時は３０冊以上の感想をあげるから。
１日に３０冊読んだわけではない。そえまでの50年間くらいで読んだものの、
感想をあげるために手に取っているだけだから。
１万冊という目標は、amazon.co.jpで reviewerの１位になれば、
掘武司さんの確認だけじゃなくて、社会的な評価にもなるから、
確認した掘武司さんの責任じゃなくなるっていう筋書き。
３年間で１万冊という目標だった。
結果としては、４年半かかった。
１万冊になったころに、No.1 Reviewerにもなった。
いいねの数が３万ちょっとだから、10分の１は、掘武司さんがいいねしてくださったおかげ。
amazon 殿堂入りNo1レビュアーになるまで。仮説・検証(102)
ありがとうございました。
上記bookmeterの「今まで買ってよかった技術書を紹介しよう！」行事でかいた記録。
技術書は、紹介してもなかなか反応がなく、嫌気が指すかもしれません。
amazonに１万冊感想を書くという目標を立てたとき、技術書ばかりを書いていて、
反応がほとんどなく、底なし沼に石を投げているような感覚に襲われたことがあります。
そこで５つの手を打ちました。
１つは、芥川賞、直木賞を読むことにより、文学の投稿をするようにしました。
芥川賞、直木賞を読む コミュニティ
https://bookmeter.com/communities/332458
芥川賞、直木賞を読む イベント
https://bookmeter.com/events/786
２つめは、オフライン行事に参加することでした。
2013年4/10 【第19回 名古屋de朝活読書会】
https://bookmeter.com/events/150
３つ目は、オンライン行事に参加することでした。
新潮文庫夏の100冊2014を読破しよう！
https://bookmeter.com/events/1399
100冊まとめては結構捗る。
4つ目は、オンライン行事を主催することでした。
第１回お茶（緑茶・紅茶・烏龍茶）を飲みながら読書会
https://bookmeter.com/events/1310
５つ目は、絵本に焦点を絞ったことでした。
【読メ絵本部】
https://bookmeter.com/communities/334325
これは、小坂井大輔さんが主催されていた朝活読書会で絵本の紹介があったときに、
かこさとし が、技術士だということを知ったのに衝撃を受けて、かこさとしの
絵本の全部読み（紙芝居以外は完読）しようとしたことによります。
いずれにしても、恵まれない技術書に愛の手をが、この企画の趣旨かもしれません。
#100冊
#文書履歴
ver. 0.01 初稿 20210902
ver. 0.02 ソフトウェアエンジニアリング論文集80's デマルコ・セレクション 追記 20210903
ver. 0.03 表現補足 20210904
ver. 0.04 amazon 殿堂入りNo1レビュアーになるまで。追記 20210905
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.