【感想・ネタバレ】「派生開発」を成功させるプロセス改善の技術と極意のレビュー

清水吉男

トラブルが頻発する「派生開発」を改善するにはどうしたらよいか。著者が現場で培ってきた方法論をまとめあげました。「派生開発」専用のこのプロセスにより，確実にプロジェクトを成功させます。現場で抱える問題の解決に必ず役立つ，「定番」となる一冊です。

[ブクログ · ★★★★★]

世界中で，システム設計の現場では、「新規開発」より、「派生開発」としての動いているシステムの変更や機能追加が多い。
その点に着目した著者の経験が凝縮されている。

派生開発の場合に何が課題になるかの仕立てをうまくしている。
仕様をどうやって明確にしていくかについての知見が豊富にある。

仕立て(tailoring)をしているだけでなく，清水吉男さんのよいところは，現場にあわせた着付け(fitting)もできることだ。

決めたことを，決めた通りにやるだけなら，能力のある技術者はいらないかもしれない。
どういう制約条件のもとで決めたことか，条件が変わったらどうするかを考える能力があるかどうかが課題だろう。

数少ない日本の相談業務（コンサルティング）を頼みたくなる方だ。
一度，清水さんの話をお聞きになられた方なら感じられたと思う。

相手を引きつける力
相手に頼む力
相手の話を聴く力
がある。

自分の経験を大事にする技術者としての感性を持ったまま，
経営的な課題に取り組もうとする姿勢がある。

著者の書かれたことを勉強するだけでなく，
著者そのものを勉強することをお勧めしたい。

[ブクログ · ★★★★☆]

最近、新規プロジェクトが少なくなってきたと聞く。
そうであれば、今後は、既存システムの改修案件が増えてくるであろうということで、読んでみた本。

よくあることだが、ソースを書いた人と保守する人は別の人。
だから保守する人はどこを直せばよいのか、わからないことがある。
そんな時、「部分理解」な人でも、できる限り手戻りなく修正するプロセスを確立しておけよってことがこの本の趣旨。

ごもっともです。

主軸は、レビューの大切さ。そしてレビュアーに気づいてもらうように（アンカー効果が働かないように）、変更内容の事前準備をすること。

その方法として、手順は５つ。
・変更内容とその理由を記載した、変更要求仕様書を作成すること。
・縦軸に変更内容、横軸に画面一覧（ソースファイル一覧）としたトレーサビリティマトリックスを作成すること。これで、修正漏れを少しでも防ぐ。だって同じようなソースが至る所にあること多いもん。
・どのように変更するかを記載した、変更設計書を「プログラム言語」ではなく「文章」で作成すること。before/afterを文章で書く。
・レビューを実施して、勘違い・考慮漏れなどを無くすこと。
・ここでようやくソースコード修正。これ直してよ。ちょろです。直しますね。は、ご法度。

まあ、C言語っぽい言葉がやたらと出てきて、SVNとか差分管理ツールとかないんかいとか思わせる言い回し、オブジェクト指向を前提としていないよねとか、オフショア開発ではなく1人プロジェクトを主体としていることが前提となっているように読めたから、使えるところだけ使おう。

[ブクログ · ★★★★☆]

現状の業務では、派生開発の機会が多いので、
実践的な進め方が記載されていて実務に役に立ちそうです。

既存のソフトウェアに対して、どう機能を変更＆追加していくか、参考になりました。

特にトレーサビリティマトリクスは、新規＆派生問わずこれから作成して行きたいです。


しかし、階層型仕様で核となるMECEに仕様を分解して行くスキルは、実践での試行錯誤で磨いていく必要があると感じました。