成功させるプロセス改善の技術と極意』で変更要求仕様書などの記述に使われていたUSDMについて書かれた本だ。前著に興味を持ったので,こちらも読んだのだが,こちらはややいまいちだった。細かいことがけっこう書いてあり,読んでいて面倒くさくなった。具体的な書き方が始まる第6章に入るまで,書籍の半分近くの文量を占める1-5章が既存の問題の説明やなぜ要求が必要なのかといったことがひたすらひたすら何回も書かれている。この時点で既に読む気が失せていた。第6章以降も同じような感じで,細かいことや似たようなことを繰り返し説明していた。言いたいことがいろいろあるのはわかるが,もっと要点を絞って簡潔にまとめてほしかった。書き方の説明があったり,計測について説明があったのはよかったのだが,全体的に記述が冗長で,ひたすらくどいうという印象だけが残ってしまった。前著が悪くなかったので期待していたのだが,全体的に記述が冗長でくどいところだけが印象に残ってしまった。くどい書籍から自分に必要なところを取り出すのはけっこうしんどい作業だ。具体的な記述や計測に関する話は比較的よかったので,全体としては残念だった。派生開発の極意は記録にあり!概要XDDPやUSDM,PFDなど,一部で採用されている開発手法が解説されている本だ。ソフトウェアやシステム開発においては,新規開発と既存の資産をベースに機能修正・改良を行う派生開発の2種類が存在する。開発手法では新規開発に焦点をあてたものが多く,派生開発を念頭に置いたものがなかった。トレーサビリティ・マトリックスPFD修正箇所に関する情報を,仕様書としてきっちりと文書に残すことで,修正の漏れや修正箇所・方法の誤りが分かるようにしている。開発の工数,変更行数などをきっちりと計測することで,生産性を計測している。冒頭で,既存の派生開発でよく生じる様々な問題が説明されており,共感した。記録を残すというやり方はいいなと感じた。ドキュメント作成の方法がまた独特なので,クセがあるが,一度試す価値はあるかなと感じた。書籍が冗長な記述が多いので,もう少し要点を絞ってコンパクトにできないかなと思った。文量が多いので,けっこう読むのはたいへんだった。結論2018-12にある現場の面談で,USDMという文書形式で開発文書を残すという話を聞いて,USDMという単語が気になって調べ,この本に辿り着いた。開発資料をきっちり文書に残してトレーサビリティを確保するという考え方はいいなと感じた。実際にこの方法を取り込むには,それなりにやり方を整理して,学ぶ必要があり時間がかかるだろう。普段の開発でも,自分の生産性を考えることはあまりなかった。計測して,今後に役立てたいと感じた。概要UMLの入門本となっている。2019-04に現場で納品資料としてユースケース図,クラス図,シーケンス図を要求され,必要に迫られてPlantUMLでUMLを書いていた。UMLをきちんと勉強したことがなく,書き方があっているのか自信がなかった。そこで,UMLの入門としてこの本を購入した。この本はいろんなところでUMLの入門本として推薦されている。具体的には,以下の3サイトで推薦されていた。1.0の情報まで書かれている。そのため,若干内容が古いようにも感じた。2.0までのUMLに関して一通り書かれている。教科書としても利用可能だ。対応」を使って合格できた。設計に必要なUMLモデリングの基礎は技術者として必要」にも記している。開発プロセスが試験の出題とやや内容が違うくらいで,その他はだいたい一致していた。問題集でわからないことがあれば,この本を見ればだいたい分かるだろう。入門書籍としては,この本の他に,オージス総研の「その場でつかえるしっかり学べるUML2.0」というのもある。実は,こちらの本も購入したのだが,試験勉強の都合で本書に絞って参照したので,受験勉強中には参照しなかった。1.0の古い書き方が省略されており,そして開発プロセスについても書かれているなど,こちらをメインの教科書に使えばよかったなと若干後悔してしまった。本書では解説が少ないパッケージ図やオブジェクト図についても解説があるので,やはりオージス総研の「その場でつかえるしっかり学べるUML2.0」のほうがよかったかもしれない。使わないパッケージ図やオブジェクト図のような余計なことがあまり書いていないというシンプルさでは,本書も悪くはないかもしれない。L1試験の対策教科書としても利用可能で,実際UMLを一通り解説されている。悪くないUMLの入門本だった。購入するならば,網羅性からオージス総研の「その場でつかえるしっかり学べるUML2.0」のほうがよかった。これはUMLについて知識が身についたから判断できるのであって,UMLの知識がないならば,何でもいいから入門書を1冊きちんと読んで知識を身につけるのが大事だろう。どちらの本にしても,絶版で中古本を当たるしかないので,入手しやすいほうを買うのが良いだろう。ノミネートされていたので興味を持って読んだ。ソフトウェア開発の現場をよりよくするために,著者の経験を元にしたフィクションのストーリーとその解説を中心とした内容となっている。スクラムやらチームづくりなどについて書かれている。自分にはあまり響かなかった。いうのも,第一部であるように,結局,自分の考えに賛同する都合のいい人物の登場により状況が改善するからだ。チームづくりに関しても小手先のテクニックな感じがしてならなかった。チームづくりに関しては,チームというよりかは人と人とのコミュニケーションについての本のほうが役に立つ気がした。人を助けるとはどういうことか」などだ。そもそもスクラムやらこの本で述べられている開発手法については経験したことがなく,おとぎ話のように感じてしまった。一度体験しないと理解できないだろう。タスクボードの基本TODOを洗い出すと、すっきりする反面、量が多くなってタスクの全体像が俯瞰しづらくなる。TODOには直近で必要な一定期間分のタスクのみを貼り出すようにして、先々のタスクや気付いたことなんかは、別の場所にためておくようにすると良いだろう。優先順位をつけずに、いったん預けておく場所という意味合いだ。タスクには取り組むべき順番がたいていはある。TODOのステージで、上下の並びで優先順位を表現すると良いだろう。Kanbordというカンバン方式のタスクボードサービスを使っている。カンバン方式のタスク管理はやり方がいまいちよくわかっていなかった。普通に使うと,TODOが大量に出てしまい,縦に間延びしてしまう。ここでタスクボードの使い方が参考になった。結論ネット上での評判が良かったので期待していたのだが,自分には合わなかった。いう開発手法というのは,周りにある程度理解者がいたり,自分が権力を行使できる立場にならなければ,発揮できない。したことができるような現場に入ることや,もっと根本的には人とのコミュニケーションの取り方について学んだほうが有益ではないかと感じた。