SEの読書術 -「本質を読む」力を磨く10の哲学 [プログラミング]
10人のSEが自分の読書術について語ったものをまとめた本
後藤大地 事実から本質を見抜く
UNIXやJava中心にシステム開発や執筆活動をしているかた。
まったくしらない技術を調べるときは内容に関係なく、有名そうな本を何冊かかってきて、有名なものから読む。全部はよまない。インストールとかプラグインはとばす。そしてあとの本は差分をよんでいく。それで全体を網羅できる。
本は著名なものを選ぶ、それは多くの人が「いい」といっているから。
でも本の著名度より信頼している人が「いい」というものを優先する。
本の情報は鵜呑みにしない。誤植やバグがあるから。ネットはコピーなので間違いが増殖していることがある。
全体を網羅したらネットでアップデートする。
一年間読まない本は不要としてすてているが、すてたのを後悔している本もある。
どちらかというと検索方法を覚えるようにしている。
得たノウハウは手元にまとめておく。プログラミングならソースコードを残しておく。それを部品にする。
そうしたソースがないときには、やりたいことに近いソースを改造する。
基本の言語を一つバリバリにしておいて、既存のコードと組み合わせれば、だいたいなんでもできる。
司馬遼太郎の「坂の上の雲」をよんで、自分の考えるようなことは、前の人がだいたい考えているので、そっちを調べたほうが早いと思った。ただ間違っていることもあるので注意だけど。
本当に大事なところは暗誦できるまでよみこむけど、あとは捨てる。丸覚えしないで本質だけを抜き出して覚えるようにしている。
物事は良いところと悪いところ両面で考える。
ただ、何かを創造するときは盲目的になるのも重要かもしれないと思う。
原田洋子 原点から読んでいく
Java Servletの第一人者
情報収集には時間をかけたくないので、おもしろいと思うことを中心にチェックする。
全然しらないものは雑誌でチェック。話題もチェック。だいたい何月号くらいって覚えておく。
書店でまえがきや目次をみて、最初の1章くらいとAppendixをみて、覚えられれば買わない。内容がすぐわかならければとりあえず買う。
必要なければ洋書はいなない。それしかないなら読む
人が書いたものでわからなければ仕様書を読む。読みこなすには慣れがいるが、慣れると一番わかりやすい。
仕様を読んだら、ちょっと時間はかかるがプログラムを書きながら理解する。
ネットより本のほうが仕様はよみやすい。
本もソースコードをみて「こういう風にかく」「こんなクラス名をつける」とみることが多い。
本のサンプルコードはキレイすぎるので、実用にするときは参考にするだけ。
本は基礎力アップのために読むもの。そっから先は人からのフィードバックで。
山本啓二 多くを取り入れ視野を広げる
システム開発者。システムアーキテクチャ、開発手法、チーム運営のコンサルティング。
できるだけ書店に足を運ぶ。タイトル、帯、出版社、値段ををみて、前書きや最初の章を読む、文章がうけつないならやめる。図版などもわかりやすそうかみる。おもしろければそのままよんで、そうでなければ、目次から拾い読みして本当に必要なら買う。
最後に著者略歴をチェック。
技術解説の本は前書き見てから本文を２，３ページ開けば詳細かどうかわかる。ちゃんと背景から書いて、その技術の目的や何のためにどういう文脈で出てきているのか踏まえられているのがよい。
インデックスみたいになっているものは通読しないで、こまったとき引く、3回助けてもらえれれば元はとれたとおもう。だからたくさん技がのっているほうが当たる確率が高いと考えている。
読みたい本に出会うために、興味が同じ人が発信している情報をみる、聞く。
目の前の課題を解決したいとネットサーフィンしたとき目にはいった情報をプリントアウトしておいて、喫煙室にもっていってざっと目を通す。細切れの時間で土地勘を養う。
技術書は正確性を期すために細かく規定してあるので、プログラムを解析する感覚で、あんまり深いところは気にしないで、気にしなきゃいけないところとメリハリをつけて読む。
コンサルティング会社なので、ロジカルシンキングやマッキンゼーの本も経営者の考えを理解するために読む。業界の本も必要に応じて読む。違う業界は土地勘がないので、アマゾンのレビューなどをみて、一番うれている入門書を読む。詳しい人の勧める本はレベルがあわないこともある。とっつきやすいものは、たいてい食い足りないので、まんべんなく情報量が多く、定番になっているものを読む。
業界ではなく業務をしりたければ雑誌を読む。現場の空気感がある。入門書だけだと現場の人間とは話がはずまない。
ビジネス書はお客様と同じ語彙でしゃべるためによむ。
読んだ本は読書ノートにしている、まじめに書くと続かないので、1冊3行くらい、タイトル、著者名、感想1-2行とか。
読んだ本をひとことでまとめる作業をすると、自分にとっての意味合いを明確にできる。リファレンス系なら、何の課題にために買った、解決できた、記述もしっかりしていたなどと、かいておく、時間ができたらまた読み返すと違う感想があるのでそこを1行かく。まとめておくと何ができるかをアピールするときに役にたつ。
メソッドとしては「量を読む」嗅覚もつくし、目も磨かれる。目の前の課題を解決してくれる本を選べるようになるのは重要。
目の前の仕事に追われてリファレンスをめくるだけだと場当たりの技術だけを追い求めることになってしまって、技術の概念がつかめなくなってしまう。
本をよむことで、地力、コンピテンシーが育つ。
平鍋健児 好きなことを人につなげる
オブジェクト指向技術、アジャイル開発、ファシリテーションのコンサルティング
メンテナンス性の高いプログラムをもとめてオブジェクト指向にであった。読むときは洋書とか意識せず、タイムギャップをうめるために読んでいる。
気になるキーワードの本は全部買う。前書きと目次だけしか読まないこともある。
読んでもまとめない。いいフレーズだけ紙にかいて壁にはったりしている。書評は昔かいたり、部内で読んでおくべき本リストをつくったこともある。ワインバーグだと「ライト、ついていますか」がおすすめ。
プログラミングでもHowToや文法でなく「なぜこうなの？」が重要なので技術を作った人が書いたバイブルみたいな本が好きで、まず読みたいと思う、
おすすめ
Kernighan & Richie
James Gosling
Guy Steel
Bertrand Meyer
まつもとゆきひろ
Grady Booch
Ivar Jacobson
James Rumbaugh
Tom Demarco
Tim Lister
Gerald Weinberg
Frederick P.BrooksJr.
技術の基盤と目的を理解する。±１運動＝自分がそれを作ってお客さんはどうつかうの（プラス１）、JavaでプログラムをかいたけどJavaVMってどうなっているだろう(マイナス１）で考える。上下両方の理解が必要。
好きの理由がわからないとモノがいえないので、価値観を示している本が好き「理科系の作文技術 (中公新書 (624))
」、XPの白本
高校までまったく本をよまなかった。ロジックですべてわかると思っていた。でもそれでは男女の恋愛とかまったくわからないので大学からは本を読んだり映画をみたりジャズを聴いたりするようになった。今の自分がやっているのはソフトウェア開発を批評空間とした批評活動ではないか。
新幹線では小説を読む。何度も読むと自分の成長を感じられる。
情報収集では自分とよく似た興味を持つ人が、どういう発言をしているか聞くのが一番てっとりばやい。
たくさんよんで、興味あるところを掘り下げる。縦の強さが、横の広がりになっていく。掘り下げたものをもっていないとだれも相手にしてくれない。
重要なのはハート、好きなことが持てるかどうか。
羽生義治の「決断力 (角川oneテーマ21)
」のなかの言葉「才能とは、継続できる情熱である」
浅海智晴 自分のスタイルを持つ
大学教授、オブジェクト指向、Java,XMLに関する活動。
本を買うことは将来への投資。わからなければ買っちゃう。
速読と精読をつかいわける、ちゃんと読まないといけないなら何年もかけることもある。
原典はちゃんとよむ。
原典から派生した本は疑いながら読む。
原典が何冊かあるならクロスチェックして読む。そしてみんながかぶっているところは大丈夫とチェックする。
ネットは情報を整理するのに使う。勘違いもたくさんある。
客観的な事実をつみあげてこそプロ
知識を組織化するには、だれかの視点を使う。
蓄積したものを交流するのは意味があるが、そうでないと顔見せ以上にはならない。交流よりまず蓄積。
ミッシングリンク＝これさえあればを探す。新しい技術は、「あの問題を解決できるからブレークするんじゃないか」という感じで見る。
流行りそうだからとやっていると中途半端になるので、自分がこうかなと思うことをやるのがいい。慈雨bんはたまたまやっていたことが波になっただけ、流行ると思ってやっていたわけではない。
「自分が楽しいとおもっていることをやると、自然にお金が入ってくるシステムをどう作るか」が大事。
生活習慣も同じ、どんなものを食べ、どのくらい仕事して遊ぶか。自分のフォームをきちんとつくる。
柴田芳樹 基礎を固めて継続する
富士ゼロックス社員、ソフトウェア設計コンサルタント。
読みたいのが洋書なので洋書が中心。初心者、中級者用は浅い。
いい技術書をしるためにアメリカの出版社のホームページを定期的にチェックする。
雑誌より専門書のほうがよい。
英語を読むのに必要なの文法力、次に基本単語をきっちりおさえる。しっているからと調べないとおもうと違う意味だったりする。
図に書いてみると理解できているかわかる。
専門書にはまちがいがけっこうある。100％正しいと思わないこと。
間違いは知らせてあげる。そのとき「英語の敬意表現
」という本で勉強したことを使った。
新しい技術に仕様書があれば読む。一度ではわからないので繰り返し読む。
勉強会をひらいている。週2回5か月で1冊の本を読む。参加するときは教えてもらえるではなく、自分から学ぶ姿勢でいくと成果がでる。
新しいことに興味をもって使ってみるのが重要。業務のどこかで役にたつ。
時代とともに消えていかない、基礎(アルゴリズムやデータ構造）は、本質的なことを知っていないと解けないときに役にたつ。
新卒のときこそ、しっかり学習する習慣をつくることが大事。5年で1人前に仕事ができないとそこまで。
途中やらないことがあってもとにかく継続すること。
いい本にであうと視野がひろがる。「Effective java」など
荒井玲子 「本物」だけを読む
富士ゼロックス、日本ラショナルで、オブジェクト指向導入、研究開発、人材育成活動。
あたらしいものをすぐに知りたければ、ネットが雑誌。英単語は辞書。
本は著者は翻訳者から、次は出版社。何度も増刷されている本をだしているようないい出版社を選ぶ
本の引用から他の本を探す。
手帳に読んだ本を書いておく。技術バカにならないために。あと買いすぎて破産しないために。
知らない分野の洋書は索引のついているものを買う。用語があまりに知らないものばかりなら、読まないで1年後にもう一度ひらいてみる。
技術書は1冊まるまるより、部分的に深く読む。何度も読むべきと思ったもの以外は売る。
速読を覚えた。「Power Reading」
経営者を説得するためにビジネス書を読むようになったが、ドラッガーなど本物だけを読む。
本物は一番底に基本がある。基本がないとワザを覚えてもすぐに役にたたなくなる。
プログラムが動いておもしろいでおわってしまうと設計できない。教えるときは具体例をやらせてから基本に戻って説明する。
ものづくりは「美しい」ものにこだわる。コードの設計も同じ。
アーキテクトに必要なのは変化を予測すること。技術は人を変える。
技術は違ってもやることは同じなので、一流のプログラマは違う言語でもすぐ覚える。抱えている知識が違う。
他の人の経験値を得るという意味で、本はお得。
考え方のキャパシティを広げるには、あふれてもいいので一度パーっと頭にいれてみるのがいい。
ヒューマンスキルはモデルを探す。いなければ本で「闘うプログラマ」とか。
上司も率先して本を読むのが大事。
二上貴夫 外の世界に目を向ける
東陽テクニカ ソフトウェア・システム研究部部長。IEEEソフトウェアのゲストエディタとしてMDD特集を編集。
情報があふれているので、検索エンジンを使って良い情報に素早くヒットさせる技術が必要。検索法とボキャブラリーを勉強する。
読んだ本は時系列で整理、そうするとアクセスが定期的にある本が一定の場所にキューイングされていく。「「超」整理法―情報検索と発想の新システム (中公新書)
」と同じ。
速読ができると会議などで自信になる。
好きな本で慣れるとよい。
わからなくてもとにかく1冊読み通す。英語を身につけるのに役にたった。
だめもとで著者にコミュニケーションしてみる。
翻訳がダメだとおもったら捨てる。
わからないものはとっておいてあとでみる。捨てない。
ソフトやさんでもハード（現実の世界の動き）を理解するのを忘れてはいけない。
最先端をおっかけるより、自分の足場を固める。
海外で仕事すると、仕事以外の情報がないと仲良くなれないと思って、書評をたよりに他の知識を読むようになった。
「同門」という茶道の本からソフト教育のヒントをもらったこともある。どんな情報でも役にたつ。自由度の高いSEならなおさら。
単なるプログラマでなくエンジニアやアナリストとしてシステムレベルのスキルが必要なことをやりたい人が増えてほしい。それにはノウハウものだけではだめ「困ります、ファインマンさん」など説明することのお手本としておすすめ。
ソフトウェアの最終的な問題は日本語がかけて読めるか。
山崎敏 知識と実践をループさせる
自称「武蔵流プログラマ」。
自分のレベルとあっていないと読んでもおもしろくない。１・２冊よんで嫌いだからってあきらめない、気にしない。
本屋にあってもリンクは張れないので、どんなことが書いてあったかだいたい覚えておいて置いておくだけでも意味はｎある。
言葉には力があるのでカバーはかけない
ネットはばらばら、本はまとめてある。なんで本を書こうとおもったのかから得られるものはある。
書いてあることは最低ライン。本のとおりだけでなく、もっと試して、どうしてそれを選んだのかいえないといけない。
本に書いてあることは書いた人の考え、感じて次につなげることが大事。
読んでやるだけでは意味がない。PDCAサイクルで全体をまわさないと。
本に書いてあることをうのみにしない。テクニックに頼るとかえってバグが増えるようなもの。
視点を変えてものをみましょうという本。「金持ち父さん貧乏父さん
」
お客さんがハッピーにならなきゃ、いいものをつくっても意味はない。技術書だけでは外の世界は見えない。
萩本順三 理想と現実をつなげる
豆蔵取締役。政府技術顧問やIT戦略の企画・実施を支援。
早くたくさんよむのばかりにこだわると、自分の考えがなくなる。情報発信する立場だから人の真似をしない、余計な情報をいれないようにしている。
技術を受け入れる「器」をつくる。目的、概念、メカニズム、具体例に分けて考える。
本質に注目する。よけいなことは連想記憶で思い出せる。オブジェクト指向の言語はメカニズムやコンセプトのレベルでは共通だが、なんで採用したかにその言語の特徴がでている。
若いときはたくさんよんだ。ひとをきにせずがむしゃらによんで、わかんないのはおいといて後でわかるようになってよんだ。
ソースのロジックの意味はイメージでとらえるようになったらわかるようになった。
もとは会計士をめざしていた。いまでもその知識は役にたっている。
しらない業界の人と仕事するときには、一応勉強するが、相手の知識をいれて、整理して返すことで成果をだしている。
自己主張もいきすぎると傲慢、「荘子 第1冊 内篇 (岩波文庫 青 206-1)
」でブレーキを踏む、周りをみて考えることができるようになった。
人がわからないことを形にするはすべのビジネスに当てはまる。ひとにどう理解させるかが重要。
オブジェクト指向は人間が物事を認知する方法。ソシュールがおもしろかった。
理想と現実は違うが、つなげる努力はすべき、ただ深追いははまってしまうのでロスがでる。
伝えることの限界はある。だからオブジェクト思考は続く。
仕事はモチベーションの高さで決まる。能力ではない。
後藤大地 事実から本質を見抜く
UNIXやJava中心にシステム開発や執筆活動をしているかた。
まったくしらない技術を調べるときは内容に関係なく、有名そうな本を何冊かかってきて、有名なものから読む。全部はよまない。インストールとかプラグインはとばす。そしてあとの本は差分をよんでいく。それで全体を網羅できる。
本は著名なものを選ぶ、それは多くの人が「いい」といっているから。
でも本の著名度より信頼している人が「いい」というものを優先する。
本の情報は鵜呑みにしない。誤植やバグがあるから。ネットはコピーなので間違いが増殖していることがある。
全体を網羅したらネットでアップデートする。
一年間読まない本は不要としてすてているが、すてたのを後悔している本もある。
どちらかというと検索方法を覚えるようにしている。
得たノウハウは手元にまとめておく。プログラミングならソースコードを残しておく。それを部品にする。
そうしたソースがないときには、やりたいことに近いソースを改造する。
基本の言語を一つバリバリにしておいて、既存のコードと組み合わせれば、だいたいなんでもできる。
司馬遼太郎の「坂の上の雲」をよんで、自分の考えるようなことは、前の人がだいたい考えているので、そっちを調べたほうが早いと思った。ただ間違っていることもあるので注意だけど。
本当に大事なところは暗誦できるまでよみこむけど、あとは捨てる。丸覚えしないで本質だけを抜き出して覚えるようにしている。
物事は良いところと悪いところ両面で考える。
ただ、何かを創造するときは盲目的になるのも重要かもしれないと思う。
原田洋子 原点から読んでいく
Java Servletの第一人者
情報収集には時間をかけたくないので、おもしろいと思うことを中心にチェックする。
全然しらないものは雑誌でチェック。話題もチェック。だいたい何月号くらいって覚えておく。
書店でまえがきや目次をみて、最初の1章くらいとAppendixをみて、覚えられれば買わない。内容がすぐわかならければとりあえず買う。
必要なければ洋書はいなない。それしかないなら読む
人が書いたものでわからなければ仕様書を読む。読みこなすには慣れがいるが、慣れると一番わかりやすい。
仕様を読んだら、ちょっと時間はかかるがプログラムを書きながら理解する。
ネットより本のほうが仕様はよみやすい。
本もソースコードをみて「こういう風にかく」「こんなクラス名をつける」とみることが多い。
本のサンプルコードはキレイすぎるので、実用にするときは参考にするだけ。
本は基礎力アップのために読むもの。そっから先は人からのフィードバックで。
山本啓二 多くを取り入れ視野を広げる
システム開発者。システムアーキテクチャ、開発手法、チーム運営のコンサルティング。
できるだけ書店に足を運ぶ。タイトル、帯、出版社、値段ををみて、前書きや最初の章を読む、文章がうけつないならやめる。図版などもわかりやすそうかみる。おもしろければそのままよんで、そうでなければ、目次から拾い読みして本当に必要なら買う。
最後に著者略歴をチェック。
技術解説の本は前書き見てから本文を２，３ページ開けば詳細かどうかわかる。ちゃんと背景から書いて、その技術の目的や何のためにどういう文脈で出てきているのか踏まえられているのがよい。
インデックスみたいになっているものは通読しないで、こまったとき引く、3回助けてもらえれれば元はとれたとおもう。だからたくさん技がのっているほうが当たる確率が高いと考えている。
読みたい本に出会うために、興味が同じ人が発信している情報をみる、聞く。
目の前の課題を解決したいとネットサーフィンしたとき目にはいった情報をプリントアウトしておいて、喫煙室にもっていってざっと目を通す。細切れの時間で土地勘を養う。
技術書は正確性を期すために細かく規定してあるので、プログラムを解析する感覚で、あんまり深いところは気にしないで、気にしなきゃいけないところとメリハリをつけて読む。
コンサルティング会社なので、ロジカルシンキングやマッキンゼーの本も経営者の考えを理解するために読む。業界の本も必要に応じて読む。違う業界は土地勘がないので、アマゾンのレビューなどをみて、一番うれている入門書を読む。詳しい人の勧める本はレベルがあわないこともある。とっつきやすいものは、たいてい食い足りないので、まんべんなく情報量が多く、定番になっているものを読む。
業界ではなく業務をしりたければ雑誌を読む。現場の空気感がある。入門書だけだと現場の人間とは話がはずまない。
ビジネス書はお客様と同じ語彙でしゃべるためによむ。
読んだ本は読書ノートにしている、まじめに書くと続かないので、1冊3行くらい、タイトル、著者名、感想1-2行とか。
読んだ本をひとことでまとめる作業をすると、自分にとっての意味合いを明確にできる。リファレンス系なら、何の課題にために買った、解決できた、記述もしっかりしていたなどと、かいておく、時間ができたらまた読み返すと違う感想があるのでそこを1行かく。まとめておくと何ができるかをアピールするときに役にたつ。
メソッドとしては「量を読む」嗅覚もつくし、目も磨かれる。目の前の課題を解決してくれる本を選べるようになるのは重要。
目の前の仕事に追われてリファレンスをめくるだけだと場当たりの技術だけを追い求めることになってしまって、技術の概念がつかめなくなってしまう。
本をよむことで、地力、コンピテンシーが育つ。
平鍋健児 好きなことを人につなげる
オブジェクト指向技術、アジャイル開発、ファシリテーションのコンサルティング
メンテナンス性の高いプログラムをもとめてオブジェクト指向にであった。読むときは洋書とか意識せず、タイムギャップをうめるために読んでいる。
気になるキーワードの本は全部買う。前書きと目次だけしか読まないこともある。
読んでもまとめない。いいフレーズだけ紙にかいて壁にはったりしている。書評は昔かいたり、部内で読んでおくべき本リストをつくったこともある。ワインバーグだと「ライト、ついていますか」がおすすめ。
プログラミングでもHowToや文法でなく「なぜこうなの？」が重要なので技術を作った人が書いたバイブルみたいな本が好きで、まず読みたいと思う、
おすすめ
Kernighan & Richie
James Gosling
Guy Steel
Bertrand Meyer
まつもとゆきひろ
Grady Booch
Ivar Jacobson
James Rumbaugh
Tom Demarco
Tim Lister
Gerald Weinberg
Frederick P.BrooksJr.
技術の基盤と目的を理解する。±１運動＝自分がそれを作ってお客さんはどうつかうの（プラス１）、JavaでプログラムをかいたけどJavaVMってどうなっているだろう(マイナス１）で考える。上下両方の理解が必要。
好きの理由がわからないとモノがいえないので、価値観を示している本が好き「理科系の作文技術 (中公新書 (624))
」、XPの白本
高校までまったく本をよまなかった。ロジックですべてわかると思っていた。でもそれでは男女の恋愛とかまったくわからないので大学からは本を読んだり映画をみたりジャズを聴いたりするようになった。今の自分がやっているのはソフトウェア開発を批評空間とした批評活動ではないか。
新幹線では小説を読む。何度も読むと自分の成長を感じられる。
情報収集では自分とよく似た興味を持つ人が、どういう発言をしているか聞くのが一番てっとりばやい。
たくさんよんで、興味あるところを掘り下げる。縦の強さが、横の広がりになっていく。掘り下げたものをもっていないとだれも相手にしてくれない。
重要なのはハート、好きなことが持てるかどうか。
羽生義治の「決断力 (角川oneテーマ21)
」のなかの言葉「才能とは、継続できる情熱である」
浅海智晴 自分のスタイルを持つ
大学教授、オブジェクト指向、Java,XMLに関する活動。
本を買うことは将来への投資。わからなければ買っちゃう。
速読と精読をつかいわける、ちゃんと読まないといけないなら何年もかけることもある。
原典はちゃんとよむ。
原典から派生した本は疑いながら読む。
原典が何冊かあるならクロスチェックして読む。そしてみんながかぶっているところは大丈夫とチェックする。
ネットは情報を整理するのに使う。勘違いもたくさんある。
客観的な事実をつみあげてこそプロ
知識を組織化するには、だれかの視点を使う。
蓄積したものを交流するのは意味があるが、そうでないと顔見せ以上にはならない。交流よりまず蓄積。
ミッシングリンク＝これさえあればを探す。新しい技術は、「あの問題を解決できるからブレークするんじゃないか」という感じで見る。
流行りそうだからとやっていると中途半端になるので、自分がこうかなと思うことをやるのがいい。慈雨bんはたまたまやっていたことが波になっただけ、流行ると思ってやっていたわけではない。
「自分が楽しいとおもっていることをやると、自然にお金が入ってくるシステムをどう作るか」が大事。
生活習慣も同じ、どんなものを食べ、どのくらい仕事して遊ぶか。自分のフォームをきちんとつくる。
柴田芳樹 基礎を固めて継続する
富士ゼロックス社員、ソフトウェア設計コンサルタント。
読みたいのが洋書なので洋書が中心。初心者、中級者用は浅い。
いい技術書をしるためにアメリカの出版社のホームページを定期的にチェックする。
雑誌より専門書のほうがよい。
英語を読むのに必要なの文法力、次に基本単語をきっちりおさえる。しっているからと調べないとおもうと違う意味だったりする。
図に書いてみると理解できているかわかる。
専門書にはまちがいがけっこうある。100％正しいと思わないこと。
間違いは知らせてあげる。そのとき「英語の敬意表現
」という本で勉強したことを使った。
新しい技術に仕様書があれば読む。一度ではわからないので繰り返し読む。
勉強会をひらいている。週2回5か月で1冊の本を読む。参加するときは教えてもらえるではなく、自分から学ぶ姿勢でいくと成果がでる。
新しいことに興味をもって使ってみるのが重要。業務のどこかで役にたつ。
時代とともに消えていかない、基礎(アルゴリズムやデータ構造）は、本質的なことを知っていないと解けないときに役にたつ。
新卒のときこそ、しっかり学習する習慣をつくることが大事。5年で1人前に仕事ができないとそこまで。
途中やらないことがあってもとにかく継続すること。
いい本にであうと視野がひろがる。「Effective java」など
荒井玲子 「本物」だけを読む
富士ゼロックス、日本ラショナルで、オブジェクト指向導入、研究開発、人材育成活動。
あたらしいものをすぐに知りたければ、ネットが雑誌。英単語は辞書。
本は著者は翻訳者から、次は出版社。何度も増刷されている本をだしているようないい出版社を選ぶ
本の引用から他の本を探す。
手帳に読んだ本を書いておく。技術バカにならないために。あと買いすぎて破産しないために。
知らない分野の洋書は索引のついているものを買う。用語があまりに知らないものばかりなら、読まないで1年後にもう一度ひらいてみる。
技術書は1冊まるまるより、部分的に深く読む。何度も読むべきと思ったもの以外は売る。
速読を覚えた。「Power Reading」
経営者を説得するためにビジネス書を読むようになったが、ドラッガーなど本物だけを読む。
本物は一番底に基本がある。基本がないとワザを覚えてもすぐに役にたたなくなる。
プログラムが動いておもしろいでおわってしまうと設計できない。教えるときは具体例をやらせてから基本に戻って説明する。
ものづくりは「美しい」ものにこだわる。コードの設計も同じ。
アーキテクトに必要なのは変化を予測すること。技術は人を変える。
技術は違ってもやることは同じなので、一流のプログラマは違う言語でもすぐ覚える。抱えている知識が違う。
他の人の経験値を得るという意味で、本はお得。
考え方のキャパシティを広げるには、あふれてもいいので一度パーっと頭にいれてみるのがいい。
ヒューマンスキルはモデルを探す。いなければ本で「闘うプログラマ」とか。
上司も率先して本を読むのが大事。
二上貴夫 外の世界に目を向ける
東陽テクニカ ソフトウェア・システム研究部部長。IEEEソフトウェアのゲストエディタとしてMDD特集を編集。
情報があふれているので、検索エンジンを使って良い情報に素早くヒットさせる技術が必要。検索法とボキャブラリーを勉強する。
読んだ本は時系列で整理、そうするとアクセスが定期的にある本が一定の場所にキューイングされていく。「「超」整理法―情報検索と発想の新システム (中公新書)
」と同じ。
速読ができると会議などで自信になる。
好きな本で慣れるとよい。
わからなくてもとにかく1冊読み通す。英語を身につけるのに役にたった。
だめもとで著者にコミュニケーションしてみる。
翻訳がダメだとおもったら捨てる。
わからないものはとっておいてあとでみる。捨てない。
ソフトやさんでもハード（現実の世界の動き）を理解するのを忘れてはいけない。
最先端をおっかけるより、自分の足場を固める。
海外で仕事すると、仕事以外の情報がないと仲良くなれないと思って、書評をたよりに他の知識を読むようになった。
「同門」という茶道の本からソフト教育のヒントをもらったこともある。どんな情報でも役にたつ。自由度の高いSEならなおさら。
単なるプログラマでなくエンジニアやアナリストとしてシステムレベルのスキルが必要なことをやりたい人が増えてほしい。それにはノウハウものだけではだめ「困ります、ファインマンさん」など説明することのお手本としておすすめ。
ソフトウェアの最終的な問題は日本語がかけて読めるか。
山崎敏 知識と実践をループさせる
自称「武蔵流プログラマ」。
自分のレベルとあっていないと読んでもおもしろくない。１・２冊よんで嫌いだからってあきらめない、気にしない。
本屋にあってもリンクは張れないので、どんなことが書いてあったかだいたい覚えておいて置いておくだけでも意味はｎある。
言葉には力があるのでカバーはかけない
ネットはばらばら、本はまとめてある。なんで本を書こうとおもったのかから得られるものはある。
書いてあることは最低ライン。本のとおりだけでなく、もっと試して、どうしてそれを選んだのかいえないといけない。
本に書いてあることは書いた人の考え、感じて次につなげることが大事。
読んでやるだけでは意味がない。PDCAサイクルで全体をまわさないと。
本に書いてあることをうのみにしない。テクニックに頼るとかえってバグが増えるようなもの。
視点を変えてものをみましょうという本。「金持ち父さん貧乏父さん
」
お客さんがハッピーにならなきゃ、いいものをつくっても意味はない。技術書だけでは外の世界は見えない。
萩本順三 理想と現実をつなげる
豆蔵取締役。政府技術顧問やIT戦略の企画・実施を支援。
早くたくさんよむのばかりにこだわると、自分の考えがなくなる。情報発信する立場だから人の真似をしない、余計な情報をいれないようにしている。
技術を受け入れる「器」をつくる。目的、概念、メカニズム、具体例に分けて考える。
本質に注目する。よけいなことは連想記憶で思い出せる。オブジェクト指向の言語はメカニズムやコンセプトのレベルでは共通だが、なんで採用したかにその言語の特徴がでている。
若いときはたくさんよんだ。ひとをきにせずがむしゃらによんで、わかんないのはおいといて後でわかるようになってよんだ。
ソースのロジックの意味はイメージでとらえるようになったらわかるようになった。
もとは会計士をめざしていた。いまでもその知識は役にたっている。
しらない業界の人と仕事するときには、一応勉強するが、相手の知識をいれて、整理して返すことで成果をだしている。
自己主張もいきすぎると傲慢、「荘子 第1冊 内篇 (岩波文庫 青 206-1)
」でブレーキを踏む、周りをみて考えることができるようになった。
人がわからないことを形にするはすべのビジネスに当てはまる。ひとにどう理解させるかが重要。
オブジェクト指向は人間が物事を認知する方法。ソシュールがおもしろかった。
理想と現実は違うが、つなげる努力はすべき、ただ深追いははまってしまうのでロスがでる。
伝えることの限界はある。だからオブジェクト思考は続く。
仕事はモチベーションの高さで決まる。能力ではない。
- 作者: 浅海 智晴/荒井 玲子/後藤 大地/柴田 芳樹/萩本 順三/原田 洋子/平鍋 健児/二上 貴夫/山崎 敏/山本 啓二
- 出版社/メーカー: 技術評論社
- 発売日: 2006/01/30
- メディア: 単行本（ソフトカバー）
タグ：浅海 智晴
コメント 0