今まで読んできて印象に残った本を10冊ぐらい。。。?にまとめてみた

ふと思い立ったので、今まで読んできた本で印象に残っているものをまとめてみた。

別に体系だてておもいだしたわけでもなく、まとめたわけでもないので、「なんであの本がないのか?」みたいな意見があるかもしれない。

そんな時はコメントをしてもらえるとうれしい。
すでに読んだ本でも、新たな本でも、手によって読む機会になるので。

ちなみにシステム関連の本が多いのは読んでいる比率の問題であって、システム関連の良書を紹介しようという主旨ではない。

◯UMLモデリングレッスン

UML記法によるデータモデリング学ぶのに最適な1冊。

これ以前に、『UMLモデリング入門』(以下、『入門』と略す)などで、UMLおよびデータモデリングの考え方に親しんでおく必要があるかもしれない。

とはいえ、UMLをつかいながら業務分析をしたり、システムについてコミュニケーションをとったりするための基礎を身につけるのに最適な1冊。

『入門』は、基礎的なUMLの書き方やモデリングの方法や考え方を学ぶ本ではあるけれど、それゆえに内容が概念的で難しい。

本書では、『入門』で学んだ考え方や取り組み方を「実際にモデル図としてどう表現するか」、実際の業務などの「どのような点をモデル化するか」、そして、「どのようにUMLで表現するか」を20ほどの演習問題で学ぶことができる。

ひとりで読むのもいいけれども、読書会を開いて皆で読みながら問題を解いてゆき、「どうしてこんなモデル図になるのか」と議論すると理解はより一層深まると思う。

自分がやってきた読書会のなかでも、楽しく読書会を行えたという記憶があるので、その点でも本書への思いが強いかも。

◯実践UML 第3版

価格も高く、分厚い本なので読んだ時の達成感もひとしお。 

データモデリングという手法を通じた業務分析やシステム設計の手法を学んだら、実際のその手法を活かしてどのようにイテレーティブな開発プロセスを実現するか、についてこの本で学ぶとよい。

イテレーティブ、アジャイルという言葉から、軽量、小規模というイメージを導きやすいが、想像以上な大きな規模でもイテレーティブな開発が可能であると気付かされる。

本のなかでも、

・概念   :考え方
・Tips、技術:関わり方、やり方
・プロセス ;プロジェクトにおける進め方、活かし方

というざっくりとしたわけがあると思って読んでいるが、この本は、考え方、やり方、進め方を網羅しており、アジャイル、データモデリング、デザインパターンなどの様々な本の知識を体系的に1冊にまとめあげている。

これ1冊で十分、というのではなくて、さまざまな本で語られている知識を1本の線でつないでくれている、という点が本書の良いところだと思う。

◯考える技術・書く技術

日常生活で、考えたり話したり文章を書いたりする機会があるのならば読んでおくと役に立つ。

システム開発においても、メール、ドキュメント、プログラムのコメント、IRCなど文章で自分の考えを表現する機会は様々ある。

また、ビジネスにおいては、どのよう思考を整理し、整理した結果をいかに表現するか、必要になる。

プログラマが”CleanCode”を実践するために、『実装パターン』や『レガシーコード改善ガイド』から基礎知識を得るように、一般的な文章やコミュニケーションにおける”Clean”さを追求するための基礎知識を得ることができる。

この本を読むと最初は実践は難しいような気もするけれど、本で得た知識を意識しながらメールや設計書などの文章作成に取り組んでゆくと、徐々に慣れてくる。
読みやすい文書、そして読みやすい文書を書くための思考法がシンプルであると理解できる。

最初は実践するのが難しいと思うが、2ヶ月もすれば慣れてくる。
ブログで悪文を晒している僕がいってもあまり説得力はないけど。

◯「先読み力」で人を動かす

成果をあげる人は、時間をうまく使う。
タイムマネジメント系の本は類書がたくさんあるけれども、自分にぴったりとはまったのはこの本だった。

最近はサボりがちだけれども、週に2時間は来週を中心とした3週間分のスケジュールを、ある予定を実現するためにどのような作業が必要か、という視点で見つめ直すと、ダブルブッキングがなくなり、予定の優先順位も立てやすい。

とりわけ忙しい時には、スケジューリングを行わなくなりがちだけれども、「どの作業は今やる必要はないか」という視点で、計画的な予定の先延ばしができるので、必要な時間の確保できるようになる。

ただ、スケジューリングのために、週に2時間まとめた時間をとるのは簡単なようで難しい。
僕のおすすめは、本書の教えとは違うけれども、日曜日の朝一番に時間を確保して取り組むこと。

◯デザインのためのデザイン

人月の神話』の著者、ブルックスがデザインについて言及した本。

よりデザインを生み出すための試行錯誤の方法ではなく、優れたデザインを生み出すプロジェクトのプロセスについて、自身の豊富な経験から語っている。

デザインのためのデザインというタイトルは、優れたデザインを実現するためのプロセスをデザインする、という意味で付けられたものと思われる。

そして、そのタイトルはまさに本書を正確に言い表しており、どのようなデザインを生み出すかではなくて、より良いデザインを生み出すプロセスをマネジメントするための考え方がつまっている。

「銀の弾丸はない」という表現でも有名な著者は「チームで仕事をすることは銀の弾丸ではない」と警告している。

優れたデザインは、個人かせいぜい2人の強調的な仕事から生み出されるのであり、協調的な多人数よる仕事が常に素晴らしい成果を残すとは限らない。

ブレインストーミングのようなアイデア出しには集団が向いているかもしれないが、その他の作業において集団による思考や決定が必要になるかは、都度、見極める必要がある。

僕自身、仕事はチームによる意思決定が重要だと考えて過ぎていたような気がしていて、目からウロコな指摘だった。

◯構造化分析とシステム仕様

デマルコといえばプロジェクトマネジメントの大家というイメージだったが、本書に出会ってイメージが変わった。

エリック・エバンスのドメイン駆動設計』が出版されて以来、ドメイン駆動設計(以下、DDD)ヘの注目が高まっているように感じるが、DDDにたいする先駆的な考えが本書には詰まっている。

アジャイルにやるためには、「設計と実装を切り離さない、設計と実装を切り離さないことが重要だと言われる。
本書では設計の更に前、要求を浮き彫りにし、整理するための分析とその分析をいかにシステムに反映してゆくかについて、述べられている。

要求は常に変化にさらされる。

そのため、システムそのものはもとより、システム作りのコミュニケーションや知識を集約するためのツールも、変化を取り込みやすくなければいけいない。

DDDでは、分析もまたフェーズゲートのようにすっぱりとある段階で終了するものではなく、設計と実装から分離不可能な要素であると、考えられてる。
が、その考えはすでに本書で述べられている。

構造化分析なんて時代遅れ、構造化設計とまぜこぜにして考えがちだけれども、本書を読めば時代がデマルコの構造化分析に追いつき始めてきた、と感じるとおもう。

上記のエリック・エバンスの本と合わせて読むと理解が進むと思う。

◯パターン指向リファクタリング入門

リファクタリングといえば、マーチン・ファウラーの『リファクタリング』だけれども、僕が印象に残っているのは、この本。


デザインパターンとリファクタリングのおいしいとこどりをしている。

振る舞いを変えず、プログラムの構造を洗練されることがリファクタリングの目的だ。
リファクタリングをちょっとだけでもやった人はわかると思うけど、単純にムダに重複したコードを削除するだけでも、実は根深くこんがらがったプログラムにおいては、解きほぐすための労力が必要になる。
また、プログラムの構造がおかしいことに気付いた後に、今度はどのようなプログラムの構造が理想かを思い浮かべる必要がある。

どのようすればそれが可能になるか、一番の方法は実際にプログラムを書く経験をつむことなのだろうが、その学習速度を上げてくれるのが本書だと思う。

◯デザイン思考が世界を変える

僕がデザインに興味をもつきっかけになった1冊。

デザインとは見た目をデコレーションすることでもなければ、珍奇な形を生み出すものでもない。

デザインを通じて生み出されたデザイン思考が、自身が取り組む仕事の役に立つこと、そして、システム開発においてもデザイン思考を含めてデザインの必要性を感じ取ることができる。
UXとか流行っているし、とおもってデザインに興味を持った人は、読んでおいて損はないと思う。

◯Manage It

プロジェクトマネジメントに関して、経験豊富な筆者の考え方、取り組み方がストレートな言葉で語られている1冊。

かっちりとプロジェクトマネジメントについて書いてある本の中では、僕はこの本が一番好き。

アジャイルとくくられるイテレーティブな開発やフェーズゲート開発まで言及しながら、イテレーティブでタイムボックスが設けられた開発の優位性を語っている。

大抵、プロジェクトマネジメントを語るのは元・プログラマが多く、品質保証をメインに仕事をしていた著者が語るマネジメントという意味でも珍しいような気がする。
こうしたバックボーンをもつ著者が書いたという意味で、イテレーティブな開発は品質劣化が心配、という人は、この本を読むと少しは安心するかもしれない。

◯仕事を100倍楽しくするプロジェクト攻略本

アジャイル開発を学ぶのではなく、アジャイルにやる方法が学びたいならこの本を入門とするのがいいと思う。

アジャイル開発を導入したいなら管理者には『リーン開発の本質』を渡し、プログラマには『XPエクストリームプログラミング入門』を渡せ、という言葉があったような気がするが、僕がだったらこの本を入社間のない新人に渡して、「こんな開発やりたいよね」と洗脳する。

この本がアジャイルを意識して書かれたとは思えなけれども、フィードバックと自らのチームの状態をふりかえる仕組みを取り入れつつ、チームで目的を達成するためのマネジメントについて、アジャイルに近しい文脈で語られる。

また、プロジェクトファシリテーションやレトロプロスペクティブなどの言葉は一切登場しないけれども同じ考え方が随所に登場する。

薄くて読みやすいので、回し読みをすれば、考えた方のよい共有になると思う。

◯パーフェクトソフトウェア

JSTQBなどテストの基礎的な考え方を学んゆくと、品質保証、テストのプロですら文脈によって「単体テスト」の意味が異なることがわかる。
ワインバーグのこの著作は、会社や人など文脈によってことなるテストについて、体系的な考え方を提示する。

近年はTDD、テストファーストという考え方を中心に、開発者、プログラムを書く人たちがテストについて知る重要性が増してきた。
くわえて、プログラムを書く人がいうテストの位置づけや役割と、品質保証と言われるテストのプロの人たちがいうテストの位置づけと役割も当然異なり、双方で理解しづらい部分もある。

双方の理解をすすめ、チーム内でテストの意義や役割、進めたかを合意する基礎として、本書の考え方は役立つと思う。

僕は、開発者として、同値分割などの方法論のみならず、プロジェクトおけるテストの重要性や位置づけを知るとより一層、効果的なテストコードをうみだすことができると思っている。

そのための、テストを知るための入門書として読むと良いと思う。

◯ハッカーと画家

ボール・グレアム、昨今、IT界隈では知らない人はいないY Combinatorの中心的人物のエッセイ。

文句抜きに面白い。

なぜか入社1年目で本書に出会い、Lispの勉強をはじめて人生で3ヶ月ぐらい無駄な勉強期間を過ごした。
今でも拭えないLispへのあこがれを僕に植えつけた一冊。

◯芸術起業論

プログラマはアーティスト(芸術家)だ、という主張をする人はぜひ、一読してほしい。

この本を読めばプログラマは現代の芸術家と重なる部分がある一方で、全く違う側面を持つことに気付かされる。

アート=自己表現、赤貧などという綺麗事、お花畑なお話とは一線を画する、世界で活躍する現代アーティストが自己表現とビジネスのバランスをとり続けるためになにをしているか、を知ることができる。
また、そもそも芸術がどういう活動であるのか、を知ることができる。

本書を1冊読めばアートを理解できわけではないが、現代アートというものがどのようなルールにおいて楽しまれているか、その文脈の一端に触れられる。
パッと見で、「いいね!」という楽しみ方も含め、アートの楽しみ方を知ることができる。

◯わたしを離さないで

今、話題になっているらしいカズオ・イシグロの著作。
前の会社の先輩に教えてもらって読んだ。

世の中には「知りたがり」と「信じたがり」の二種類の人間がいる。
どちらの人種が幸福な人生を歩むのかはわからないけれども、「知りたがり」の女の子が、自分が抱えている運命とどのよう向き合ったか。

淡々した表現と筆致で進んでゆく物語にノックアウトされた。

◯デュシャンは語る

現代アートは意味不明、というイメージを一般の人々に植えつけたアーティストの一人であろう、デュシャンの自伝的告白本。

アーティストは、「なぜ自らの作品が素晴らしいのか」を、視覚的な快を含めて説明できなくてはいけない。
だから、アーティストは格好つけたがり、というか、自分のやっていることをさも高尚にかたり、偉そうにしている印象があるものだけれども、本書に登場するデュシャンは全く違う。

素朴に自身の考えや感情を表現している。
人間くさく、友達思いのデュシャンの言葉は、難しいけれどもおもしろい。

◯まとめ?

ある人が、アジャイルにやる方法を教えるのは自転車にのるのを教えるようなもの、といってた。

教えられる人ができるようになるためには、教えられたことを実践する必要がある、と言いたいのだと思う。

だから、本を読んだだけでは実践はできない。

ただ、本を読まない、しらないでは、そもそもお話にならない。
それは、自転車をのりたいけれど買ってないとか、そもそも自転車自体を知らないってことだとおもう。

本ばかり読んで何のアウトプットもないのも問題だけど、それなりのアウトプットを出すには大量のインプットが必要になる。
このバランスが悩ましい。

このエントリを書いていて思い出した良書。
・モデリングの本質
・オブジェクト指向のこころ
・ライトついてますか
・スーパーエンジニアへの道
・ハイパワーマーケティング
・クラッシュマーケティング
・小さなチーム、大きな仕事
・塹壕よりScrumとXP
・ある広告人の告白
・コンセプチュアル・アート
・裏方ほどおいしい仕事はない

あと、今後読みたいと思った本。
・コードコンプリート(上、下巻)
・ノンデザイナーズブック
・プログラミング言語JAVA
・アジャイルサムライ
・Rails3.0レシピブック
・OnLisp
・プログラマの数学

なんだかんだでシステム関連ばかり。。。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中


%d人のブロガーが「いいね」をつけました。