『ＳＥの読書術』　著者10名　（技術評論社）

イメージ 1

　何冊かの技術系の著作を出版している10名のＳＥ(システム・エンジニア)の方々が、読書や仕事に関する考え方を述べている。

 

 

【まずは著名な本を読んでおく　：　後藤大地さん】
　本というのは出会いなので、その出会いが少なくなると、将来的に不利に働くんです。(p.10)
　限られた時間の中で、できるだけ良い出会いをするためには、多くの人が　「いい」　と言っている本を読むのが良いと言っている。つまり、著名な本を読んでおく。
　ＳＥの読書術とすれば、無難な方法なのだろうけれど、仕事と関係ない一般人読者の私に言わせれば、こんな大衆迎合的な読書術は全然つまらない。
　　　《参照》　　　『「逆」読書法』　　　日下公人　　HIRAKU
　　　　　　　　　　　　　【逆読書術の　”奥儀”　】

 

 

【人と人とのつながりを見る　：　平鍋健児さん】
　情報収集に関して言えば、僕とよく似た興味をもっている人がどういう発言をしているかを聞くのが一番手っ取り早いですね。うちの会社にもそういうのが好きな人がいるんですけど、その人に　「なんか最近新しいの読んだ？」　とかって聞いたほうがよっぽどいい情報をもらえます。 ･･･(中略)･･･　。人のつながりが知識のつながりなんですね。つまり、ソーシャルネットにつながることが重要。だから、技術者もだれがだれに序文を書いていて、っていうのを追いかけていくのが好きなんです。(p.66)
　上掲の後藤さんの意見を、より特化させた方法が、序文やあとがきの寄稿者のつながりを辿ることなのだろう。
　技術書に関してなら、この方法はなかなか良いかもしれない。しかし、一般書では　“ヨイショ”　的なものが多いのであまり参考にならない。

 

 

【新人のときが大事　：　柴田芳樹さん】
　新卒のときに、しっかり学習する習慣をつけておく必要があります。
　５年で一人前の仕事ができないと、やっぱりそこまでなんですよね。10年後もそのままですし、そうなると本人たちも不幸ですし、会社にとっても不幸ですよね。
　ただ、「読んで予習してこい」　っていえば、新卒の人たちはわりと素直ですよね。就職してすぐで、「いやだ」　なんて言える立場じゃないし。
　一番難しいのは、勉強する習慣がつかないまま中堅になった人ですね。もう　「本読め！」　って言ってもなかなか読まない。それで、たとえばＣ＋＋ができるっていうので仕事させてみると、あんまりできない。「じゃあ１年で本何冊読んでるの？」　って聞くと、１冊も読んでいない。(p.105-106)
　ＪａｖａやＣ系列言語などは、新しい言語だし進化が早いから、率先して学ぶ習慣がないと、なかなか良い仕事はできないのだろう。心にコレステロールがつくと、「職場内の誰かが書いているソースコードの実例から学んじゃえば、それで十分じゃん」　となりやすい。やはり進取的な勉強癖がないと、なかなか頭もスマートになれないものである。

 

 

【美しいものをつくる　：　荒井玲子さん】
　開発っていっても、「動けばいい」　っていうものではなくて、設計にしても、実装、コードを書くにしても、見た目がわかりやすいインターフェースを作るにしても、きれいなものっていうのは使いやすくて長持ちする。複雑なものっていうのは長持ちしない。それはもう決まっているんです。(p.124)
　白州正子さんの　『日本のたくみ』　なんかを読んでいるんですけど、その方もおんなじことを言っているんです。本物をたくさん見ること、それにはやっぱり古典を知らないとだめです、って。そういう、ほかに分野の本物の話、特に職人の話とかを読むと、得るものはすごく多いですね。　(p.125)
　プロとして一流のプログラマはすぐに（新しい技術を）おぼえます。「一芸に秀でる」　って言葉があるじゃないですか。おんなじですよ。そのレベルの人って、背後にかかえている量が違うんです。ＯＳの知識から何から何まで全部持ってる。(p.128)
　背景が全部わかっていて、シンプルで美しいものを作る人って、確かに一流。
　一般図書の分野でも、販売されている書籍はたいそう簡単に分かりやすく書かれているけれど、講演に行ってみたら奥の深い話がいくらでも出てくる人と、書籍には興味深い内容が多いけれど、講演に行ってみたら書籍とほとんど同じ話ばかりという場合がある。

 

 

【覚えた知識に振り回されない】
　今はＣＰＵパワーはいくらでもあるし、多少変なコードを書いてもパワーで押せる。ゆとりがあるので考え方を変えられるんです。
　となると、行き着くのは、読みやすいか、理解しやすいか、シンプルかっていうところになります。それに気づいたのは、サラリーマンプログラマ時代の後半でした。
　技術書を読むと、いっぱい手駒が増えるわけじゃないですか。それまでは、そのなかで　「一番強い」　駒を選んでしまっていたけれど、それからは　「一番わかりやすい（メンテナンスしやすい）」　駒を選ぶようになりました。 (p.167)
　マシンの性能（ＣＰＵパワー）が上がったのだから、人間の才能（「一番強い」　駒）は、それほど必要ないわけで、これに誰がするか分からないメンテナンスという視点を加えれば、「一番わかりやすいのが最適」、という揺るぎない結論に達する。これに異論を差し挟む余地はない。
　美しさ＝わかりやすさ、という方程式は　“最適”　の　“前提”　であり　“解”　でもある。

 

 

【読み書きできる能力を磨く　：　二上貴夫さん】
　ソフトウエアの最終的な問題は、やっぱり日本語を読めて書けるかにかかってると思います。
　要求文書とか仕様書を書くときに、「ほかの人が読む」　っていうのを意識しないで書くと、別の解釈をする人間が２割ぐらい出てくるような文章ができることがあります。でも、書いた本人が　「別の意味にとられる可能性がある」　ってわからないと、修正できないわけです。
　で、別の意味に解釈できるのがわかる人間が読めば、「変だな」　と思って修正できるんですけど、それがわからないとそのまま実装しちゃって　「こんなはずじゃなかった」　になっちゃう。そういうケースってけっこう多いんですよ。　(p.155-156)
　この事例は経験したことがある。机上に７０ｃｍぐらい積み上げられた、要件定義と上流設計書を読むという仕事を割り振られたことがあって、おもいっきりブルーな気分で数日間読み続けていたのであるけれど、終盤近くになって、特定の用語がどうも全体で同じ意味に解釈されていないのでは・・・と違和感を覚えつつ、一部分、先に上がってきた詳細設計書を見て、チーム間で違った解釈をしているのが明らかになったことがある。コーディング前だったから、数日間ほどの戻りで済んだけれど、そうでなければ、まさに　「こんなはずじゃなかった」　の世界に入ってしまっていたことだろう。
　でも、こんなことの発見は、読み書き能力と言うほどのことではなく、用語の定義をきちんと踏まえずに設計書を書いたチームがあったというだけのことである。用語の定義は全体に配信されていたのだから、それを軽視して自己流に解釈したか勘違いしたチームがあったのである。常識的なことだけれど、人員を信頼することと成果物をきちんとチェックすることとは別問題であって、後者は必ず為されねばならないのが基本である。
　ところで、最近の若者の書く文章の中に、助詞の使い方がヘンなのを見ることがある。場合によっては意味が取れないこともあるのでプロとしてはとうてい看過できるものではない。文章を読む習慣がないからこんなことになるわけで、本を読まない若者が増えているということなのだろう。
（私のブログの中にも、古いのを読み返してみると、文章を直したとき助詞を修正しそこなっている個所や、誤変換の個所をかなり頻繁に見つける。書いたばかりの時は、考えた通りに読んでしまうから自分ではなかなか気付けない。一人作業の怖さというのは、まさにこれであって、このようなミスは、しばらくたってから読み返すことでしか防げないものである）

 

 

【モチベーションが高まる理想を見つける　：　萩本順三さん】
　仕事をするうえで、基本的に能力の高い低いは関係ありません。モチベーションが高いか低いか、っていうところがほとんどのことを左右すると思います。能力的には教えればなんとかなりますけど、モチベーションの低い人は教えられないですからね。(p.189)
　やる気が第一と考えるのは、どの職業であっても同じである。
　　　《参照》　　　『知られざる日本の優秀企業　2008年版』　　特別取材班　　現代書林
　　　　　　　　　　　　　【ＳＥ（システム・エンジニア）は理系だけ？】
　モチベーションを高めるものは、人に依りけりだけれど、真面目な人には、下記の書籍。
　　　《参照》　　　『未来を拓く君たちへ』　田坂広志　（ＫＵＭＯＮ）
　　　　　　　　　　　　　【人生の意味・仕事の意味】
　理想という表現に違和感がある人は、下記の書籍の記述。
　　　《参照》　　　『昨日までの自分に別れを告げる』　中谷彰宏　（ダイヤモンド社）
　　　　　　　　　　　　　【動機はできるだけ不純な方が、持続する】

 

 

＜了＞