多分、誰かがおすすめしているのを見て、読みたかった本です。
第一般は1999年なので、やや古い本と言えなくないですが、今でも通用する話は多く載ってました。
いかに良質なソフトウェアを早く作るか。
私の人生はかなりの時間、それを考えることに費やされている気がします…。
この本が今でも通用する、というのは、○○駆動 という開発手法や方法論ではなく、
「人間とはこういう動きをするものだ」
という面からの話が多いからですね。
人間は何十年でそんなに変わらないですから。
本はそれなりの厚さですが、物語形式になっていて、とても読みやすく、ちょこちょこエンタメ要素もあります。
読んでいて心に残ったことを書いておきます。
①生産性を短期的に上げる方法はない
② ①のために、早くソフトウェアを作るためには、無駄な時間を削るしかない。なので、リスク管理が重要
③結束の固いチームは成果として考えるべき。むやみに解散させるべきではない。
④プロジェクトの初期に無駄にする1日も、末期に無駄にする1日も、等しく1日が無駄になっている
→いやー、これわかりますね…。プロジェクトの最初の方では、なんか時間がゆっくりと進んでいて、末期になると、時間が恐ろしいほど早く過ぎていく。
身につまされます。
⑤機能ポイントによる工数見積もり
→function pointと言ったほうが通じる人もいるかもしれません。ソフトウェアが作らなければいけない機能数によって、工数見積もりが正確にできるという考え方です。
しかし、これはこの本の古いところというか、あんまり現在のソフトウェアのトレンドとは馴染まない部分かなと思います。
とはいえ、開発当初に開発すべき機能を並べてみるというのは有意義なことだとは思います。
⑥優れたプロジェクトは設計に費やす時間が長く、デバッグに費やす時間が短い
→これは心の底から同意ですね！
そう、設計がちゃんとできてないと、デバッグに時間がかかるし、不具合を修正するのも時間がかかるのです。
しかし、プログラミングも3年以上やった方じゃないと、この話を中々分かってもらえないんだけども
「コーディングをしてから実際の設計が行われる」
なんですよね。
そういった詳細設計を「低レベルの設計」と呼ぶのは簡単です。
とはいえ、「低レベルの設計」が結局集まって実際の動くソフトウェアができあがっているわけです。
ここが、ソフトウェア開発のマジのマジで難しいところなんですよ。
大体のプロジェクトでは、大本の設計みたいなのはアーキテクトがやって、末端の詳細設計に関しては、プログラムを書く人がやる、という役割分担になっていることが多いと思います。
結局、バグが起こったり、肥大化して複雑になっているのはこの末端の部分であって、ここを場当たり的にメンテナンスしていると、将来的にどんどんわけがわからないことになっていって、気が付くと手がつけられないという状態になってしまうのです。
この本によると、そういった末端の設計まで先に作りこんでおけ、ということなんですが、まぁそれは現代では難しいと言わざるをえないでしょう。
しかし、「なるべく詳細設計まで作りこんでおく」ということは納得感のある話だったので、開発に取り入れていきたいと考えます。
⑦どうして人数の多いプロジェクトが失敗するのか
「人月の神話」という本を読みました
という記事にも書いたんですが、ソフトウェアとそれを作る人数の問題って本当に不思議なんですよね。
ソフトウェアって、ソフトウェアを作ったことがない人からすると、
A：100人で作っているソフトウェア
B：10人で作っているソフトウェア
があるとしたら、
「Aの方が10倍良い製品」
というのが当然のように思われると思います。
しかし、実際はAの方が微妙なもの、というケースはめちゃくちゃ多いです。
この本でもそれが取り上げられていて、この本ではその原因が
「100人のチームがあれば、最初っから100人に仕事を割り振らないといけない。
設計は5人ぐらいがすればいいことだが、その間、95人が遊んでいるわけにはいかない。
なので、おろそかなチーム分割と、機能分割、そして早くコーディングを進めてしまうことになり、結果ひどいものが出来上がり、工数も多くかかる。」
という話になってます。
うーん わかるな~ この話。
本当に設計が大事ですね。
