いわゆるエンプラ(笑)技術者向けにお勧めする本をまとめてみた。というか某方面からピックアップの依頼を受けて考えたもの。SIer勤務でお固めのドメインの受託開発に従事しているエンジニア向けになっていると思う。世の中的には「エンタープライズ」とか言われている領域をイメージしていただければよいかと思う(一部で、「エンプラ(笑)って何だ?」みたいな議論もあるみたいだけど、いまいちピンときていない)。なお、初心者向けにはなってはいない。
ソフトウェア開発ライフサイクル全般
共通フレーム
いろいろと批判があることはわかっているけれども、ソフトウェア開発のゆりかごから墓場までに実施すべきタスクを全方位に把握するならまず共通フレームがお勧め。注意を払うべき様々な標準についてのインデックスとしても有用である。ただし、読んでて面白い本ではない。そして分厚い。なおIPAの有償セミナーで参加すると一冊貰える場合があるので、あわせてチェックすると良さそう。
プロジェクト管理
デッドライン
プロジェクト管理の基礎的なことを学習するなら、情報処理技術者試験のPMや、PMIのPMPをやれば良いと思っている。というわけでここで紹介するのは、もう少し深くプロジェクト管理について考えるための本である。
この本はまず小説形式になっているので大変に読みやすく、あまり仕事で読書をする経験が無い人にもお勧め。物語のなかで、様々なプロジェクトマネジメントの鉄則が出てくる。例えば有名なのはこれ。正しい管理の四つの本質
- 適切な人材を雇用する
- その人材を適所にあてはめる
- 人びとの士気を保つ
- チームの結束を強め、維持する
(それ以外のことは全部管理ごっこ)
人月の神話
こちらは古典中の古典なのだけれども、ソフトウェア開発に従事するなら一度は読んでおきたい。ソフトウェア開発について書かれた本、ブログでたびたび登場する「銀の弾丸」の概念の原典でもある。どんな本なのかはWikipediaにとても詳しく書かれているので参考までにチェックしてみると良いと思う。
アート・オブ・プロジェクトマネジメント
プロジェクト管理の最後は鉄板の名著としてこれを上げておく。本書にはプロジェクト管理の技芸に関する本だ。プロジェクトマネージャが考えるべきことについて書かれている。けっこう厚いけれど、文章もかなり面白いので楽しめると思う。
このあたりも参考に巨大で危険な物体を操縦するときには、操縦桿をしっかりと握っているだけでは不十分です。あなたが操縦しようとしているものが巨大であり、多くの人が関与しているのであれば、より大きな慣性が働くのです。プロジェクトマネジメントにおいても同様ですが、巨大な機械(自動車、飛行機、航空母艦等)を操縦する場合、初心者は進路変更操作をしてから、実際に変更し始めるまでの時間を過小評価しがちです。
見積もり
設計
システム設計の謎を解く
業務システムの設計に関するバランスのとれた本。というか割とこの分野のチョイスが難しい。コードを中心とした本や、オブジェクト指向設計のパターン本ならいろいろあるけれども、割と汎用的な設計に関して書かれた本というのは思い当たらなかった(日経SYSTEMSあたりのムックでもいいのかもしれないけれど、読んでいないのでよくわからない)。
しかし、いかに現場の経験が重要といっても、プログラマの延長上で、泥縄式に設計ができるようになるわけではない。
(巻頭の推薦文より。株式会社メソドロジック代表取締役社長 山岸さんの言葉)
筆者は「設計とは"考えること"であり、アウトプットはその一側面である」と考えているからです。設計は単純に右から左に書き写せばよいものでもありませんし、機械的にできるものでもありません。設計には他にも重要な要素がありますうが、最も重要なのは「考えること」です。
(はじめに、より)
ユースケース実践ガイド
ちょっと古いし、実は絶版で入手困難だけどぜひとも読んでもらいたい本。本書はUMLにおける棒人間のアイコンで書かれるユースケース図の本ではない。テキストで、わかりやすく、適切なユースケースを記載することについて書かれた本である。もっと噛み砕いて言えば、ソフトウェアの外部仕様を、ユーザにわかりやすく平文で記載する方法について書かれている。ちなみに、本書はオブジェクト指向設計とも結びついていない。学ぶ点の多い本である。
ユースケースは、フローチャートやシーケンス図、ペトリネット、プログラミング言語を使って記述することもできますが、基本的にはテキスト形式で記述します。通常、ユースケースは人とのコミュニケーションの手段として使いますが、すべての人が専門的なトレーニングを受けているとは限りません。そのため、単純なテキストが適している場合が多いのです。
(イントロダクション、より)
テスト
基礎から学ぶソフトウェアテスト
ソフトウェアを作ったら、検証を行わなければならない。というわけでテストについて一冊あげるなら、ちょっと、というかかなり古い本なのだけれどもお勧めしたい本。
「この本が対象とするのは、必ずしもみんながルールを守らない、または守るつもりがない、もしくは守る必要がないときのテストの進め方だ」
コンストラクション全般
Code Complete
ここまで割と努力してコードが登場しない本を紹介してきたのだけど、やはり避けては通れない気がする。というわけで詳細設計以降のソフトウェア開発に必要なこと一式=コンストラクション全般に書かれた鉄板本が本書である。高いけどなんとかして手に入れるべき。なお苦手であればプログラミングそのものを扱っている章は飛ばして読んでもいいと思う(ただし、いつかちゃんと読むこと)。
本書を執筆する上で私が最も配慮したのは、業界の第一人者や教授らの知識と、一般的な商用プラクティスとの差を縮めることである。多くの協力なプログラミングテクニックは、一般のプログラミングに浸透するまで何年もの間、専門誌や学術論文に埋もれている。
近年、最先端のソフトウェア開発プラクティスが目覚しい進歩を遂げている。しかし、一般的なプラクティスの方はそうではない。多くのプログラムは依然としてバグだらけだし、スケジュールは遅れ、予算をオーバーし、ユーザーのニーズには応えていない。(中略)いくつかの調査で、研究開発が商用プラクティスとして普及するには、一般に5~15年、あるいはそれ以上かかることがわかっている。本書は、そのプロセスを短縮し、重大な発見を平均的なプログラマに提供しようとするものである。
目次や一部の章が以下のリンク先から読める
コミニュケーション
Team Geek
最後にコミュニケーションに関する本について取り上げてみる。ソフトウェア開発におけるコミュニケーションに関する本である。本書のかわりに「人を動かす」を読んでもいいのかもしれないけど、この本ではソフトウェア開発独特のコミュニケーションの仕方についていろいろと示唆を与えてくれる。
本書は、ソフトウェア開発の社会的危機について扱ったものだ。したがって、君が確実にコントロールできる変数を取り上げたい。君自身だ。
本書の基本的な考えは単純である。ソフトウェア開発はチームスポーツであり、技術的要因と同じだけ人的要因が影響するというものだ。何十年もかけてプログラミングの技術面を学んだとしても、人間的要因を学んでいない人がほとんどだ。成功するにはコラボレーションについて学ぶことも必要である。ソフトウェアエンジニアリングの「ソフトスキル」に投資すれば、同じだけの努力でより大きな効果が得られるだろう。
以前に書いた感想はこちら