「派生開発」を成功させるプロセス改善の技術と極意 の商品レビュー

清水吉男【著】

2019/06/30

# 書評☆4 「派生開発」を成功させるプロセス改善の技術と極意 | 派生開発の極意は記録にあり！

## 概要
XDDPやUSDM，PFDなど，一部で採用されている開発手法が解説されている本だ。

ソフトウェアやシステム開発においては，新規開発と既存の資産をベースに機能修正・改良を行う派生開発の2種類が存在する。

開発手法では新規開発に焦点をあてたものが多く，派生開発を念頭に置いたものがなかった。そこで，著者が派生開発のための開発手法として，XDDP (eXtreme Dervied Development Process) を編み出した。

XDDPは以下の成果物から構成される。

* 変更要求仕様書
* トレーサビリティ・マトリックス
* PFD

修正箇所に関する情報を，仕様書としてきっちりと文書に残すことで，修正の漏れや修正箇所・方法の誤りが分かるようにしている。

また，開発の工数，変更行数などをきっちりと計測することで，生産性を計測している。

冒頭で，既存の派生開発でよく生じる様々な問題が説明されており，共感した。そして，記録を残すというやり方はいいなと感じた。

ドキュメント作成の方法がまた独特なので，クセがあるが，一度試す価値はあるかなと感じた。

ただ，書籍が冗長な記述が多いので，もう少し要点を絞ってコンパクトにできないかなと思った。文量が多いので，けっこう読むのはたいへんだった。

## 結論
2018-12にある現場の面談で，USDMという文書形式で開発文書を残すという話を聞いて，USDMという単語が気になって調べ，この本に辿り着いた。

開発資料をきっちり文書に残してトレーサビリティを確保するという考え方はいいなと感じた。

実際にこの方法を取り込むには，それなりにやり方を整理して，学ぶ必要があり時間がかかるだろう。

普段の開発でも，自分の生産性を考えることはあまりなかった。開発修了時に，変更前後のコード差分と，かけた時間で自分の生産性 (1日あたりの変更行数) を計測して，今後に役立てたいと感じた。

パーマリンク: https://senooken.jp/blog/2019/08/26/

2018/11/12

前から入手してあったが、ついに読了。読んだだけですぐに成功すると思わず、粘り強くこの本に戻って、XDDPを手に入れたいと思う。

2014/12/28

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

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

ごもっともです。

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

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

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

2014/03/29

改善や改修に特化した開発プロセス方法が記載されている。ソフトウェアの話として書かれているが、機械や電気系の人にも役立つと思う。特に、組み込み系をやられている方は、殆どの場合、既存製品のモディファイが開発となると思われるので、参考として手にとってはいかがだろうか？

XDDPと呼ばれる筆者が考えた方法論が書かれている。背景まで丁寧に書かれているので、手っ取り早くノウハウを得たい人にはやや冗長に映るだろう。基本的に本手法の肝は、要求からの漏れチェックのための視覚化と要求からの変更内容を導く思考過程の可視化だと思った。よって、その場限りのコード改修と異なり、レビューがしやすくなる上、設計者の従来機種への理解が深まるというメリットが有るように思う。

本手法が新規設計が少ない組み込み業界の開発プロセス標準の一つとなり、多くの設計者が報われるようになることを望みたい。

2012/07/27

希望が見えるような気もするけど、自分の問題への適用可能性は正直やってみないと分からないなーという感覚。手法のエッセンスとバックグラウンドについては完全に同意できる。

2012/07/07

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

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

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

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

2012/05/01

ソフトウェアエンジニアリングの教科書には「新規開発をどう上手くやるか」について書いてありますが、私たちが日々格闘している「派生開発」については「保守」としてひとくくりにされ、十分な記述がありません。

もちろん、新規開発のノウハウが役立つ部分もあるのですが、筆者の清水吉男は「派生開発の現場では、時間に追われバグを見つけ次第直すという間違ったプロセス」にメスを入れています。
つまり、派生開発においては、
　o 変更要求仕様書
　o トレーサビリティ・マップ
　o 変更設計書
を作るプロセスを提案しています。これらは、実践的で非常に役立つノウハウと思います。口語調で話が整理されていないためちょっと読みにくい点がちょっと残念です。

2012/01/03

派生開発について書かれた唯一の書籍。
書いてある内容はとっても納得できて効果があるなと思っているのだが、
ちょっと内容がまとまっていない気がする。
本当に必要なところだけにすれば、半分くらいのページ数になるのでは無いだろうか？

この本をベースにして、ＸＤＤＰを広める活動を起こさないと、なかなか浸透しないと思う。
でも、適用できれば手法自体はかなり効果的だと思っている。

2011/12/31

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

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

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

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

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

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

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

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

2013/11/24

・良書。久しぶりに自分でも試してみようと思ったソフトウェア開発プロセスの本。
・個人の思い込みや勘違いを防止する為に、レビュー（他者の視点＝組織力）を重視する所は、ワインバーグのエゴレス方式に近い。　≪参考≫ジェラルド・M.ワインバーグ(著)「プログラミングの心理学―または、ハイテクノロジーの人間学」
・設計に時間を掛ける事で、事前にバグを防ぎ、その結果、プログラム修正の時間は減らせるという考えは、デマルコの思想に近い。　≪参考≫トム・デマルコ (著)「デッドライン―ソフト開発を成功に導く101の法則 」

・XDDPの成果物は下記の通り。レビュー時に他者の気付きがされ易いように工夫されている。
　　変更要求仕様　　　　　　　　　…（What ）　どのような振る舞いを変更するか？
　　トレーサビリティ・マトリクス　…（Where）　どのモジュールを変更するか？
　　変更設計書 　　　　　　　　　…（How ）　変更方法について記述する