スキル創造研究室 Book Review(4)
スキルアップのきっかけは読書から
大内隆良(@IT自分戦略研究所)
2006/10/13
読書の秋。読書は手軽に知識を蓄えることが可能な手段だ。ITエンジニアにとって繁忙期となりそうな年末、3月決算期の前に、少し余裕を持って読書にいそしむことをお勧めしよう。
今回紹介するのは4冊。それぞれ異なる分野の本だが、多くのITエンジニアの知識を広げるきっかけになるだろう。
|
意外と気になる他人の読書術 |
SEの読書術――「本質を読む」力を磨く10の哲学 技術評論社編集部著 技術評論社 2006年2月 ISBN:4774126624 1344円(税込み) |
ほかのITエンジニアは、どんな本を読んでいるのだろうか。そんな疑問に答えてくれる1冊だ。
登場する10人がどんな書籍や雑誌を選択し、どんな読み方をしているのかを明らかにする。本書を読んで分かるのは、読書に対する意識や読み方は十人十色だということ。
最初に登場するオングスの後藤大地氏は、知らない分野はまとめて読むという。「Eclipseが話題になったときは、3、4冊ぐらい分厚い本を買ってきて、まずその中で一番著名なものを頭から読みました」という。ただし、必要ないと感じたところは飛ばして読み、2冊目以降は、1冊目に書いていない差分だけを読むようにしているという。
ウルシステムズの山本啓二氏は、技術文書はプログラム言語と同じだと思って読むそうだ。「言語が自然言語なだけで、プログラミング言語みたいなもんなんだ」と指摘し、しかもその文章を「予約語」と思えばいいという。
日本フィッツの荒井玲子氏は、技術書を読む場合、1冊丸ごと読むのではなく、「部分的に深く読む」方法を取る。入門書などはあまり読まないそうだ。荒井氏の言葉によれば、「競技ものとか、武道とか、基本の形ってやっぱりあるじゃないですか。技に走っていて基本を忘れちゃうと、やっぱり弱くなっちゃう」という。
本書から自分に合う読書術を見つけることができれば、本書の中にある表現をそのままお借りすれば、まさに「元が取れる」だろう。
ITエンジニアも理解しておきたい法律の知識 |
基礎から学ぶSEの法律知識 大澤恒夫、市毛由美子、鮫島正洋著 日経BP社 2006年5月 ISBN:4822282600 2100円(税込み) |
ITエンジニアと法律とは、あまり関係がないと思う人が多いようだ。しかし現実は、ユーザー企業との契約などを含めて、ITエンジニア(の仕事)と法律とは密接にかかわっている。そんなITエンジニアがかかわりそうな法律関係のこと、契約などについて解説したのが本書だ。
口約束で契約は成立するか。答えはYes。口約束でも契約は成立する。では、なぜ契約書が必要となるのだろうか。ITエンジニアにも理解しやすいよう具体例を挙げながら説明する。
契約書を締結してもトラブルは起きる。そこでトラブルを起こしにくいような契約書や、トラブルが生じても対応しやすい契約書の例を挙げる。
例えば「個別契約にかかる納期は甲乙協議の上、適宜変更することができます」という条文は、何も決めてないのと同じだと指摘する。納期の変更はあり得ることだが、もう少し具体的に記述するべしとアドバイスをする。
本書は一般向けの書籍のため、平易な解説を心掛けているようだ。あまり契約などにタッチすることがないITエンジニアにも、知っておくべき参考知識程度として読むことをお勧めする。
ソフトウェア開発で伸びない人とは? |
ソフトウェア開発で伸びる人、伸びない人 荒井玲子著 技術評論社 2006年1月 ISBN:4774126535 882円(税込み) |
ソフトウェア開発で伸びる人、伸びない人、というのは、どこに違いがあるのだろうか。
著者の荒井玲子氏は、まず初めにチェックリストを掲げる。そのうえで、伸びない人の素養をつくる原因として、次のようなものがあると指摘する。
・プライド
・解決策偏重
・正解はひとつ主義
・受け身
・階級闘争
ここでは、上記の中から1つだけトピックを取り上げよう。それは「正解はひとつ主義」だ。荒井氏は、伸びない人は「銀の弾丸」を探し求める傾向があるという。伸びない人は「技術そのものに反応」し、使い方には詳しくなるが、目的、つまりその技術は何のためにあるかという肝心な点を押さえない傾向があるというのだ。しかも結局使えないといってはその技術を見捨て、違う技術を追い求める。最終的にはそれだけですべてを解決できるはずの「銀の弾丸」を追うと指摘する。
反対に伸びる人には、次のような要素があるという。
・言語力
・目的思考
・構造力
・日々の習慣
・人との関係
・美的センス
・プロ意識
この中の「言語力」で荒井氏が重要なものとして挙げるのは、国語力、英語力、抽象概念、論理的思考と文章作成スキルだ。「オブジェクト指向技術を使用する場合、国語力のなさは致命的」と指摘する。「クラスの抽出」ができない、「クラスの属性、オペレーションのネーミングが曖昧」と続ける。
さらに「日本語は曖昧(あいまい)だから、仕様書も曖昧になるのは仕方がない」という人に著者は、「プログラミングは曖昧でもいいのですか?」と聞くことにしているという。そのうえで、曖昧な設計書から明確なロジックを組むことはできないと説く。
皆さんの周囲には、伸びる人と伸びない人、どちらが多いだろうか。
デスマーチを避けたい人に |
システム開発 火事場プロジェクトの法則――どうすればデスマーチをなくせるか? 山崎敏著 技術評論社 2006年9月 ISBN:4774128813 1764円(税込み) |
デスマーチは、どんなITエンジニアも避けたい事態だろう。
本書の冒頭に4分野のデスマーチ・チェックリストがあり、これに答えていくと、自分が携わっているプロジェクトの現状がどのような状態にあるのかを簡単なレーダーチャートで把握できる。そして次の第1部で現状から体質改善できるようなヒントが書かれている。第2部は、著者のデスマーチ体験が綴られている。
現状からの体質改善のヒントは、非常に基本的な、シンプルな言葉で記されている。いわく、「顧客にとって良い物を考える」「自分/チームにできることを書き出してみる」「地図を持つ/Must−Win−Canの図を描く」「わかりやすいコードを書く」などだ。
つまり、デスマーチを解決する絶対的な解はない。結局は基本的なことをきちんとやることが、デスマーチを防ぐ道に通じる、ということだろう。
書評にあるボタンをクリックすると、オンライン書店で、その書籍を注文することができます。詳しくはクリックして表示されるページをご覧ください。 |
そのほかの書評ページ | ||||
|
@IT自分戦略研究所は2014年2月、@ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、@IT自分戦略研究所をよろしくお願いいたします。