◆

（文系２年目社員）

本書は、StrutsやTomcatなどの有名オープンソースプロダクトの
ソースコードを題材にして、Javaでの設計と実装を学ぶ本である。

まず最初にプロダクトのアーキテクチャ／設計を解説し
それからソースコードを示すという構成のため、
今までオープンソースのコードを読んだ事がない人でも
UMLさえ読めれば、スムーズに入って行くことができるだろう。

特に、デザインパターンの解説に関して秀逸であり、
「実際のプロダクトではどう使われているのか」を
ここまでまとめて読める書籍は、私は他には知らない。

序盤ではCommons Loggingなど、
比較的分かりやすいプロダクトを扱っているが、
中盤以降はOSGi、JMX、JavaCCなど、
中級以上のJava開発者にとっても歯ごたえのある内容が目白押しである。

ただし、各プロダクトの深い所まで全て記述されてはいないため、
「もうちょっと、この機能をよく知りたいな」と、
設計だけではなく、そのプロダクト自体に興味を持った人は、
自分でソースコードをダウンロードして、読み解く必要がある。

デザインパターンを机上では学んだけど、実際使っているイメージが沸かない、
という人にオススメしたい。

（エキスパート系４年目社員）

この本は、高知工科大学のソフトウェアエンジニアリングの
授業内容を書き起こしたもの。

ソフトウェアエンジニアリングとは何か、
また、なぜ今こそソフトウェアエンジニアリングが必要か、
という問いに、統計データを使って明快に解説してくれる良書。

この本は、システム開発に必要な「考え方」を201個の原則として
コンパクトにまとめられている、初心者にも読みやすい本。

今から10年以上前の1995年に出版された本で、
その期間のソフトウェアの進歩を考えると、
すでに古臭い本のように感じるが、
実際は全くそんなことはない。

逆に、要素技術がどれだけ進歩しようが、
ソフトウェア開発で必要なスキルや考え方の本質は、
大きくは変わらない、ということがわかる。

例えば、 「原理１０６　すぐコーディングを始めるな」は、
最も基本的でありながら、研修でプログラムを学び始めた人に、
すぐに伝えたい考え方である。

また、「ソフトウェア開発の神話」という
古典的名著から抜き出した、
「原則１４０　人員と時間は交換できない」というエッセンスを、
コンパクトに解説している。

多くの比喩を用いながら、わかりやすく記述されているので、
情報専攻外からＳＥになった新人が、システム開発の基礎的な考え方を
学ぶのに最適だろう。

具体的には２進数や論理回路といったコンピュータの基礎からアルゴリズム、データ構造までを幅広く扱っており、まさに痒いところに手が届いた知識は「最近の若いモンはこんなことも知らんのか」と嘆く中堅エンジニアを納得させるのに十分な内容。
「番兵」や「ダミーノード」といったの往年テクニックについて触れられている点も、（中堅エンジニアの）感動を誘う。

また歯切れの良い簡潔な文体にも好感が持て、読み物としても純粋に楽しめる。
カタイ技術書が苦手な読者もサクサク読み進められるだろう。

難点を挙げるとすれば、掲載コードが全てＣ言語でかかれているという点。やや時代に逆行する感がある。
世の中はオブジェクト指向やアスペクト指向の書籍が売れているが、
本書で論じている「センス」は言語パラダイムを通り越して通用する概念である。
時代に流されない地に足の着いたエンジニアを見据えながら、本書の本質的な内容を理解して欲しい。

（エキスパート系６年目社員）

「SELECTとFROMとWHERE、どういう順番で処理してるか分かりますか？」

という問いに、すぐに答えられない人は、
この本をお勧めします。

実は「良い本だから絶対読め！」と先輩社員に
半ば強引に勧められて始めたのが本書。

なんて言いながらも、 入社直後で、SQLのSの字も知らなかった私にとって、
SQLの書き方から記述してある事が、とても助かりました。

特に良いのが、各章にある蜂のイラスト。
蜂のイラストを見るだけで、DBの内部でデータがどう流れるか、
直感的に理解できるようになりました。

また、くどいほど練習問題の量も、
数多くの問題をこなしながら理解していく私にぴったりでした。

これからDBに触れようと思っている人、
基礎をもう一度押さえたい人に、ぜひお勧めしたい
参考書です。

（情報専攻外出身新人社員）

Webアプリケーションの開発プロセスや、アーキテクチャ面から、
リッチクライアント、DIコンテナなどのキーワードまで触れられており、
Webアプリ開発の「知ってて当然でしょう！」な知識を得られる本。

ボリュームも小さめなので、気軽に数時間で読破できるはず。

特に、これからWebアプリ開発を始める人や、
Webアプリ開発を行ってはいるものの、動向が良く分からない、という新入社員の方には、
週末を使ってサラっと読んでおくことをお勧めしたい。

（Web系アーキテクトを目指し始めた３年目社員）

私がPowerShellを初めて知ったのは、PowerShellがまだ「Monad」というコードネームで呼ばれていた2005年の夏です。当時から海外ではMonadに着目している技術者が多く、活発に議論されていました。ところが、日本語の情報ソースが皆無だったため、日本では全く知名度がなく、メディアに取り上げられることもほとんどありませんでした。

しかし、2006年11月、日本語ドキュメントを携えたPowerShellの正式版が遂にリリースされました。ようやく、PowerShellが国内で注目される下地ができたのではないかと思います。

本書では、少しでもPowerShellとその可能性を認知してもらおうと考えて、利用頻度や難易度に囚われずに様々なサンプルを用意しました。本書をきっかけにして、PowerShellを始めてみるユーザが増えてくれると嬉しいですね。

（執筆者：吉岡）

> 最後に、本書の執筆は家族によって支えられた部分が多いことを記させていただきます。
> 自慢になる話ではありませんが、私達は家庭でのコミュニケーションが全くできていません。
> にもかかわらず、本書を執筆できたことは、家族の愛情に甘えたことが大きかったと思います。

設計段階からこの本を傍らに置いておくことで、問題が発生するたびにそれに追われるのでなく、
問題を未然に防ぐことができる様になるのではないでしょうか。

いや、本当に置いておくだけにはしないでくださいね（＾＾；

（エキスパート系２年目社員）

タイトルからは想像できないこの本の内容をひとことで言うと、
「ソフトウェア業界で豊かな経験を持つ開発者Joelからのアドバイス」。
アドバイスと言うと硬いイメージがあるが、Joelの文章はとてもポップで
読みやすく、内容もプログラムをやったことがある人なら気軽に読める。

Joelは長らくマイクロソフトでExcelを開発していたプログラマーで、
ソフトウェア開発のノウハウを日々ブログに公開していた。そのブログの内容が
多くのソフトウェア開発者からの支持を受け、それを一冊にまとめたのがこの本だ。

特に面白かったのがソフトウェアチームの良さを計測するための
12のチェック項目「ジョエルテスト」。

例えば、「採用面接のときにコードを書かせている？」とか「テスタはいる？」など、
決して大上段に構えた議論ではなく、プログラマー視点でのソフトウェア開発効率を
追求した姿勢に共感できる。

プログラマーへのリスペクトに満ちたJoelの文章は、
少しプログラミングをかじった人へのモチベーションアップにお勧め。

（SE系4年目社員）

「日経システム構築」に紹介されていた事例から読者に好評だった70本の
システム構築事例が紹介されている本。

通常企業側からは出したくないだろう失敗事例や、長い時間を
かけて調査した結果についても掲載されているため、内容は濃い。

実際、22時間業務を止めてしまった事例や、１年以上かけてPostgreSQLの性能を
改善した際の設定ポイントなども紹介されている。

システム構築の際の苦労ポイントを、実感がこもった事例を通して学ぶことができる良書。
逆に言えば、システムエンジニアであれば必読と言えるだろう。

既に絶版となっている本であり、技術的に古い部分があることは否めないが、
事例の価値が下がるわけではない。

（SE系4年目社員）

プログラマとして、多くのデスマーチプロジェクトをたらいまわしにされ、
会社を辞めるまでにいたった著者の、切実な経験が語られている本。

モノ創りに憧れ、実装力、設計力を磨き続けたが、デスマーチプロジェクトでは、
とにかく苦しい日々。まさに「技術力では解決しない問題」である。
その中で「なぜこんなに辛いのか」「何が悪いのか」と問い続け、
「人を中心に考える」ことの重要性を実感していく。

社内で、この「表層的な技術力ではない技術」について常に話しているからこそ、
「できなかった現場」の話として改めて勉強になる点は多かった。

本の前半部分には、
苦しんだ著者のデスマーチを生まないためのアドバイスが詰まっている。
「ＷＢを使ってミーティングを行う」「チームとしてビジョンを共有する」など
当たり前のこと、として簡単に捉えてしまうこともできる。

が、後半に語られている通り、そうした当たり前のことが当たり前に実践されずに
多くのデスマーチが世の中では生まれており、
多くの人を不幸にしていることを考えるからこそ、
前半の「火事場プロジェクトの○と×」に改めて、深い理解と共感が得られる。

（デスマーチとは無縁の４年目SE）

システムを作る仕事にはいろいろな役割が存在する。
SE、コンサルタント、プログラマ、、、と挙げればきりがないが、
本書は、特に見えづらい「マネジャー」という役職に求められる要素を、
実際の事例や専門家へのインタビューも交えて、体系的にまとめた一冊である。

「プロダクトマネジャー」
―日本では聞きなれない言葉だが、本書では、
『新製品/サービスを開発→商品化→販売→販売後までの
　すべての責務を担うマネジャー』
と定義されている。
やや強引ではあるが、「プロジェクトマネジャー」と置き換えれば、
業界に属する人であれば納得できる内容ばかりだろう。

「プロダクトマネジャー」の職務は多岐に渡る。 ・計画立案
・マーケティング
・ブランド戦略
・財務
・開発管理
・研究開発

これらを全て身に付ける必要がある、と考えると大変だが、
私は逆にSEの仕事の延長上にある可能性を感じた。

私がSEを選んだのも、開発だけで終わるエンジニアではなく、
広い視点を持って、頭一つで世の中を変えていける可能性を感じたから。
本書は、そんな想いを実現するための具体的かつ実践的な指針を
示してくれる良書であると感じた。

巷では、IT業界の印象として、
「PCの前にかじりつく職業」
「35歳までしか働けない職業」
と言ったイメージを持たれるが、
本当は、こうしたイメージを持つ人にこそ読んで欲しいところ。

多岐に渡る知識と経験が求められ、多様な立場で活躍する、
IT業界の仕事の面白さとやりがいが理解してもらえるだろう。

（SEの先を目指そうと背伸び中の４年目）

著者のEric Sinkはソフトウェア業界のアカデミー賞と誉れ高い
Jolt Awardsで2008年製品部門賞を受賞したSourceGear社の創業者である。
ギークがソフトウェア企業をどのように運営して行けばよいのか？
ということを、惜しみなく、そして常にウィットを持って語っている。

この本で対象となっているのは
「小さなISV（Independent Software Vendor）」
と著者が定義するソフトウェア企業の運営についてである。
「小さなISV」とは、自己資金（ベンチャーキャピタルからの投資を受けていない）によって運用される、100人未満のソフトウェア企業のことであり、
エスエムジーもこの定義に従えば「小さなISV」であるため、親近感を持って読むことができた。

特にエスエムジーでは社員一人ひとりが経営者たれ、という社風があるため、
解決すべき課題について共感できる点が非常に多かった。

本書では、企業家、人、マーケティング、セールスと４つの章から構成される。
それぞれのトピックでは、小さなISVが直面する問題に対して、
技術者がどのように会社を経営していけばよいのか、
著者の経験（特に失敗談が豊富）からやさしい言葉で語られる。

例えば、多くの技術者が苦手とする「セールス＆マーケティング」についても、
まずその違いを明確にした上で、
純粋な技術者にとって、マーケティングが身近なものであることを教えてくれる。

技術者が、あくまで技術者にこだわるその立場を離れないまま、
そしてその技術者としての喜びを追求し続けながら、
会社を経営していくための、良い指南書となるだろう。

「小さなISV」でソフトウェアをビジネスにすることを考えるすべての人にお薦めできる。

（８年目　プロジェクトリーダー）