[書籍レビュー] システム設計とドキュメント

kindle書籍を購入したときに、kindle用の書籍と、通常の書籍のscanデータをkindle化している書籍の2パターンがあります。 今回読んだ書籍は、後者の方で、いわゆるテキストではなく、画像を読むタイプの書籍でした。 読んでいるうちにいい事が書いてあると、テキストをマーキングする事ができる機能を利用する事ができず、 ページのしおり機能を使って、ページごとマーキングするしかないので、若干機能不足を感じるのと、 テキストサイズなどが変更できない点や、スキャン状態のほとんどが、少しインクが薄く見えるので、読みづらい箇所などがあるのがストレスでした。 とはいえ、爆速で読書ができるKindle端末とその環境に感謝です。 今回読んだのは、仕事で活用する事を目的とした、プログラミング開発系の「システム設計とドキュメント」という書籍です。

レビュー

★★★☆☆

可もなく不可もなく、的な標準的な印象でした。 Windows環境における、ツールを使った、比較的大きな規模でのシステム開発を例に挙げた内容で、 最近Macを使った開発員が多い中、非プログラマ系のSEを対象にした書籍の印象がありました。 プロジェクトに関する失敗理論や実例についてや、プログラミングよりも設計にかける時間は、3対7というような、プロジェクト論的な話は非常に面白く読めたんですが、 設計書やドキュメント関連の作り方については、あまり参考になるところがなかった。

学びのポイント

家を建てる時の設計書と、システムを作る時の設計書の違いについて書かれてあった事が非常に印象的だった。 大きな違いは、家を建てる場合の設計者と、実際に組み立てる大工さんは、ほとんどの場合が別であり、それらの指示を適切に伝えるための設計書という意味になり、 システム開発は、設計者と実際にプログラミングを行う人が同じ場合も割合として多いため、他人に伝えるという視点がないがしろになりがちなのだそう。 確かに、設計書などを書くぐらいならプログラム書いた方が、早いし工数も少なく済む。 何より、自分がやる作業を自分でメモするように描き控えるという２度手間的な行為がなんとももどかしいしストレスに感じるのもよくわかる。 こうした環境の違いにより、システム開発の設計書は、書かれない事が多いというのが現実で、それによって、担当者変更の際などにトラブルが起きがちというのも、非常にみにつまされる話である。

モックアップとプロトタイプの違い

1. スケッチ 2. ワイヤーフレーム 3. モックアップ 4. プロトタイプ

なんとなく、これまでモックアップとプロトタイプを同じ意味合いで使ってきていたけど、上記の順番で機能追加したものの呼び名らしい。 でも、現実的には、この境界線には明確なルールなどはなく、曖昧だという事も書かれていた。

あとがき

この手の書籍には、ウォーターフォールとアジャイルの比較的な書き方がよくされている場合が多く、 ウォーターフォールとアジャイルは、水と油のような解釈もされていて、読者が困惑してしまいがちになるが、 今現在開発を実体験している感覚から言うと、小さなウォーターフォールをスプリントとして、回し続けるのがアジャイルという、階層的な感覚の方が近いと思う。 この書籍には、似たような記述があり、比較的新しい思考で書かれている事がわかるが、わかりやすく書かれていたかと言うとそうでもないと感じた。 開発経験が無く、学習のつもりで読むと、意味のわからない箇所が多く、 開発熟練者が読むと、自分とは合わないケースで参考にならないと言う印象を持ってしまう場合が多い書籍でもある感じです。 世の中に同じ開発が２つと無いように、開発とエンジニアって、コミュニケーションする関係性なのだと思い、 それらをつなぐのが設計書であるということは、この書籍が伝えたかったポイントでは無いかと言うことを勝手に読み解いた。 AMAZONのkindle書籍で、以上にポイント数が高い書籍は、スキャン書籍である事がわかった、今回の読書感想でした。