あなたも翻訳家になれる! エダヒロ式 [英語→日本語]力の磨き方

枝廣淳子さんの著書を読んでみたくなって購入しました。

プロの翻訳家を目指しているわけではありませんが、エダヒロ式学習法に興味がありました。もちろん「翻訳とは何か」という氏の哲学もとても興味深い内容です。それを読むと、私は恐れ多くてプロの翻訳家を目指そうとは思えませんでした。

それよりもどういった視点や考え方でその独特の学習スタイルを築いたのかに私は興味をもちました。そのため、ここでは翻訳に特化した話題よりも、勉強方法を考えるきっかけ作りを主に紹介します。

エダヒロの天職公式

冒頭の序文から興味をそそります。おもしろい公式です。

「好き」x「得意」x「大事」=「天職」

私はプログラミングが「好き」ですが、「得意」ではないし「大事」というのは抽象的過ぎてよく分かりません。しかし、こういった要素があれば、お仕事が楽しそうだという雰囲気は伝わってきます。本書を読み進めながら、これらの要素が何かを考えるきっかけになります。

プロとアマチュアの決定的な違いとは

プロの翻訳家とアマチュアの翻訳者の大きな違いの1つは、持久力です。

あぁ確かに！と思った一文です。私もちょくちょく技術ドキュメントを翻訳していますが、やりかけのまま途中で止めてしまったものや、途中で疲れて完了するのに想定以上の時間がかかったものがいくつもあります。

プロとは、高い品質で分量をこなせないといけないと説いています。

その表現を「知っている」と「使える」は違います

良いなと思える表現をストックしておいて、何度も読み直して慣れ親しんだり、実際に意識して使うと良いと説かれています。

最近、英会話で "absolutely", "exactly", "affordable (price)" を使う機会を狙ってたりします。頭の中でチャンスがあれば言ってやろうと思っていると、その時が訪れたときに良いタイミングで実際に声に出すことができます。慣れないと間が少しぎこちない感じですが (^ ^;;

訳文の欠点を見つける - 声を出してチェック

目はスキャンするのが得意な感覚器で、耳はメリハリをつけた形で情報を取捨選択する感覚器だと説明しています。

本文の中では訳文の仕上げに「声を出して読む」ことで、しっくりこない表現やつながりの悪い表現を見つけるのに大きな効果があると紹介されています。これは訳文のみならず、日本語においても文章を書くこと全般に応用できることも追記されています。

なるほど。声に出して耳から聞くというのは、これまでの私のスタイルにはなかったものなので取り入れていこうと思いました。

2つの必須事項 - ビジョンと自分マネジメント

いっときの情熱でやれるのは短期間だけであり、中長期で取り組むには「ビジョンと自分マネジメント」という「しくみ」が必要だと主張しています。システム化することが大事であり、続かなかったと自分の意志の弱さを責めても仕方ないというのは、私にとって身にしみる言葉でした。

バックキャスティングでビジョンを描く

「バックキャスティング」という言葉を初めて知りました。環境の世界で使われる用語のようです。言葉の定義を氏のメルマガから引用します。

「それが達成できた時に、最終的にどういうところに行きたいのか？」

http://daily-ondanka.com/edahiro/2008/20080207_12.html

ビジョンを描くときに、現状の問題点を改善するのではなく、在るべき姿になったら自分はどうしたいのかを考えるやり方です。これはものごとを現状の延長線上にのみ考えないという視点を得るのにとても良さそうです。

自分の力を120パーセント引き出す時間の使い方

時間をどうマネジメントするか、自分の集中力やパフォーマンス (翻訳の質) をどうやってあるレベル以上に保つかが大事なスキルとなってきます。プロとアマチュアの違いの1つは、「必要な集中力で継続して作業できるか」です。

このためのトレーニング方法として、あえて時間制限を設けて作業するトレーニングが良いそうです。「時間を計る」という行為そのものが見積もりの精度を高めたり、計画作りにも生きてくるようです。

まとめ

すごく読みやすくてさっと読めてしまうものの、後から読み直して気付く内容がいくつもありました。もちろん翻訳のコツもたくさん紹介されていて参考になります。翻訳を通して英語の勉強をしようと考えている人にとっては一石二鳥な良著だとお奨めできます。

あなたも翻訳家になれる!―エダヒロ式 [英語→日本語]力の 磨き方

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方

誰かの書評を読んでウィッシュリストに入れていたのを、ある時にお祝いとして id:rokujyouhitoma から頂きました。読むのが今頃になってしまいましたが、ありがとうございます！

しかし、いまとなっては、誰の書評を読んだのか、なぜ私は本書をウィッシュリストに入れたのか全く思い出せません (> <)、それでも id:rokujyouhitoma には感謝しています！

積んどく状態でしたが、ふと読み始めたらおもしろかったです。読みやすく、分かりやすく、統合性があって良い書籍だと思います。

小さく営むための知恵

著者の言う「小さな ISV」とは、いわゆるパッケージベンダーです。

ISV は作りたい製品を構想し、それを作り上げた時になってもまだ欲しがる人がいることに賭け、リスクを取る。ソフトウェア製品を持たない会社は ISV ではない。「小さな ISV」というのは ISV の大きくないもののことだ。

小さな ISV は小さいままでいる傾向がある。大きくなるにしても、成長はゆっくりしている。有機的に成長し、自身の利益を投資することで成長する。小さな ISV は地味でも収益を上げていることが多い。

執筆された時期が 2003-2005 年の記事が多いので、やや古い内容もありますが、その知恵は時代や状況が変わっても応用できそうです。考え方の要点や注意を向ける視点について、経営資源の「ヒト」「モノ」「カネ」に対して、小さな ISV ならではの、フットワークの軽さを考慮して書かれています。

ここで「小さな」というのが重要な点で、大きな組織と小さな組織ではやり方が異なるというのを認識するのにも適した内容です。

ギークのためのファイナンス入門

本書の特徴の1つとして、ソフトウェア開発者の視点から企業や業務活動全般を俯瞰した内容を網羅している点です。

例えば、私にとっては「第4章 ギークのためのファイナンス入門」が、財務の専門的な用語や仕組みの理解を必要とせず、要点のみをシンプルに説明したもので分かりやすかったです。もちろん著者も本章を財務上のアドバイスとして受け取るべきではなく、ファイナンスの専門家に相談する必要があると説いています。ただ、ファイナンスの専門家のアドバイスも必ずしも全てが適切であるとは限らないということです。

戦略的意思決定にかかわる財務諸表として、以下の3つは読めるようになった方が良いと奨めています。

• 損益計算書
• 賃借対照表
• キャッシュフロー計算書

開発者が財務のことを知る必要はないという意見もあるかもしれませんが、私はある程度分かった方が良いと考えています。というのは、当たり前の話しですが、ビジネスが成り立たないと開発を継続できません。開発を継続できないと、技術的な挑戦や自身のキャリアを磨くこともできません。このプロジェクト (企業) は先細りだなとか、数年後に潰れそうだなとか、開発者も自ら判断して取捨選択していくことが重要になっていくように思います。

私がこれまで働いた企業だと、経営者は賃借対照表のみを説明したがります。しかし、パッケージベンダーの賃借対照表は全く当てにならないです。ソフトウェアは、無形固定資産や棚卸資産に含めて、それなりに数字を誤摩化せるからです。実際、ある程度は仕方ないのでしょうが、そのバランスはどのぐらいが適性な状態かを開発者が理解することは難しいと思います。

また、売上総利益率という指標から、その高低でビジネスモデルの違いを述べ、さらにオープンソースビジネスモデルが難しい理由を売上総利益率が低いからと説明しているのはおもしろい視点でした。

Just Do It

おそらく最も一般的な誤りは、ソフトウェア製品を作りたいと思いながら、それについて何もしないということだろう。

エピローグが (私にとっては) 最もユーモアのある、ちょっと良いお話でした。

アイディアは誰でも思い付くし、それが売れるものかどうかなんて、やってみないと分からない。小さなアイディアを小さく始めて、失敗したらまた別の小さなアイディアを始めれば良いだけの話しである。

結論: 私は2週間の注意深い作業をして「今を生きよ」という以上のことを何も言っていないアーティクルを書くことになるだろう。
そんなのは馬鹿げている。

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方

Jython プログラミング

ずっと積ん読になっていました。

購入したのはおよそ3年前。最近、私が Java を勉強し始めたという動機もあり、3日で読んでしまいました。3年も読めなかった本をいま読めてしまうというのは、いつか読むかもしれないから気になった書籍は取りあえず買っとけという気にさせてくれますね (^ ^;;

さて、本書は Jython の入門本であると同時にプログラミングの抽象概念を、著者の考察と簡潔な論理で説いてくれるので、とても分かりやすく参考になります。私は何となくそういうもんだと解釈していたことが、意図するものの背景を知って、新たな発見がいくつもありました。

Java の世界と Python の世界を行き来する

序盤は Eclipse の使い方や外部ライブラリのパスの通し方も丁寧に紹介されています。私は Eclipse を使い始めたばかりなので、そういった気遣いも嬉しいです。

Jython とは、Java で実装された Python の処理系です。JavaVM 上で Python の処理系が動くので、ほんの数行で Java の世界と Python の世界を行ったり来たりすることができます。本書を読む方は、どちらかの言語をある程度、知っていないと読んでいて混乱するかもしれません。本書内でも Java プログラマ向けに書かれたものだと説明されています。

Python から見たオブジェクト指向

5章まるまる1つの章がオブジェクト指向について著者の考察がサンプルコードと共に展開されます。冒頭の目的から引用します。

世の中の「オブジェクト指向」という言葉の使われ方を見ていると、おおざっぱに言って2つの「思想」があるように思えます。1つは「関連する変数や関数がコードのあちこちに散らばるのはよくない。ひとかたまりのモノとして扱えるべき。」という思想です。もう1つは「整数や関数などのいろいろなモノが、モノによって扱い方が違うのはよくない。統一的な方法で扱えるべき。」という思想です。この2つの思想はまったくの別物です。しかし、同じ「オブジェクト指向」という言葉で語られることが多く、まぎらわしいです。

私にとっては、5章が最もおもしろくて、とても勉強になりました。プログラミングは、ただ単に要件や仕様に沿ってコーディングするということじゃなくて、背景に「いろいろ」あって、効率良くプログラミングするために「いろいろ」あって、うまく言えないんだけど「いろいろ」考えとかないと後で大変なんだよー (> <)

。。。

といった「いろいろ」あるモノの1つが5章で分かりやすく説明されています。実際、私も経験して初めて実感したり、学べば学ぶほど新たな発見があったり、プログラミングって本当におもしろいものです。

オブジェクト指向にクラスは必須ではない

オブジェクト指向とは、クラスを作ってインスタンス化を指すのではないということを説明するために、Python のディクショナリと関数でクラスもどきを実装しています。

以前、私も同じようなことをハンズオン *1 で体験しましたが、当時の私には全く分かっていませんでした。クラスを使わずにクラスもどきを実装することで、オブジェクト指向の本質的な概念を理解するのに有用だと本章を読んで気付かされました。

• インスタンス化はなぜ必要なのか？
• 継承とは何なのか？

タプルはなぜ生まれたか

Python のタプルから私が連想するものは、

• 不変オブジェクト
• ディクショナリのキーになる
• 関数の返り値を1つするためにパックされるもの

といったものでした。厳密には、ディクショナリのキーになるのは、特殊メソッド __hash__ を実装して、ハッシュ値が算出できるオブジェクトという定義の方が正しいようです。

ディクショナリの検索は、ハッシュ値からキーに対する値を取得できますが、人間はハッシュ値ではなく、キーの中身で認識します。キーの中身が同じでハッシュ値が異なるものや、キーの中身が違うのにハッシュ値が同じものがあっては困ります。だから、リストではなく、タプルが必要なんだと、実際のコードサンプルと一緒に紹介されています。

継承は慎重に。多重継承はもっと慎重に。

「多重継承を使ったほうがいいコード」とは限りません。むしろ「使わないほうがいいのに多重継承を使ったコードはとても悪いコード」です。Java の作者が「いっそ多重継承は禁止にしてしまえ」と考えるほどです。きちんと理解せずに使うと大変なことになる、そんな危険性を秘めたテクニックだということを、まずは肝に銘じてください。

多重継承を考える際に、問題なのは菱形継承 (ダイヤモンド継承) であると著者は述べています。

Java はその複雑さを取り除くために、クラスの多重継承を禁止して、インターフェースのみ多重継承できるように解決しました。Python は C3 線形化アルゴリズム で MRO (メソッド解決順序) を解決します *2 。

とはいえ、Python においても (理由なく) 菱形継承を行わない方が良さそうです。そういった課題はあるものの、多重継承ができるおかげで Mixin をうまく使って MRO を簡単に切り替えるというテクニックも使えます *3 。

テスト駆動開発に Jython を

Python は、wikipedia:グルー言語 としても便利なので、他の何かを扱うのも得意です。

本書では、JyConsole という補完機能をもつ Jython の対話的コンソールを Java プログラム (テストプログラム) 内に組み込むことで、「テストの清書」をする前に「テストのラフスケッチ」をすることを奨めています。

テストのような、地道に何度も実行して確認したりする用途には、Java でやるよりも Python の方がお手軽で良さそうです。対話的コンソールで、テストを書く前に試しに動かしてみる、色んな引数を与えてみるといったことも簡単にできます。おそらくそのお手軽さに反対する人はいないでしょう。

他にも Python には doctest というドキュメントにちょっとしたテストを兼ね備えた仕組みもあります。

リファレンス

• Jythonプログラミング
• 404 Blog Not Found:初心者本3.0? - 書評 - Jythonプログラミング
• Yoshioriの日記: Jython本が素晴しすぎて俺も写経し始めたから紹介が遅れちゃう件

Jythonプログラミング

*1:そうだ！EuroPython 2011へ行こう #2 CPythonについてのハンズオン，講演 -ディクショナリで考える-

*2:http://d.hatena.ne.jp/t2y-1979/20101103/1288786838

*3:そうだ！EuroPython 2011へ行こう #2 CPythonについてのハンズオン，講演 -Pythonのsuper()ができること-

アジャイルサムライ−達人開発者への道−

オーム社 様に献本いただきました。ありがとうございます。

私は、実際にアジャイルな開発プロジェクトに参加したことがなく、一種の憧れのようなものを抱いていました。本書は、私のようなアジャイル開発って何か凄そうだけど、具体的にはよく分からないという人にとって、とても分かりやすく「アジャイルって何なのさ？」という質問に対する答えになる本だと私は思います。

私が本書を読んで得た答えは、アジャイルって文化なんだと強く感じました。それは他の人にとっては違う答えになるかもしれませんが、そんなことにあまり大きな意味はないということが本書を読むことでよく分かると思います。気になる方は、どうぞ本書を読んでみてください (^ ^;;

期待マネジメント

漫画とかに「戦場は生き物だ」のような台詞がよく出てくる気がします。それは開発プロジェクトも同じようなものだと私は考えています。ただ指示された通りに作業を行い、求められた品質基準を満たし、予定された期日に納めれば良いのですが、実際にはきれいに描かれたプロジェクト管理表のように成功する開発プロジェクトはほとんどないでしょう。

人間が関わる以上、そこに感情的な動きがあって、信頼関係や誤解があり、人間的な成長もあり、利害関係の対立も起こる。

本書では「期待をマネジメントする」という表現がよく出てきますが、私はその言葉をとても気に入っています。機能は満たしたけど使い勝手が悪い、最低限の機能しかなくて何かしょぼいなぁ、開発プロジェクトの中でそう思うことがよくあります。

要件は満たしていると主張する人もいるでしょうし、使いやすいものに改善しようと提案する人もいるでしょう。それは個人の気付き力や想像力に依るものではありますが、もう少し分かりやすい形で「期待」という言葉で明確にしてお互いの認識をあわせていこうとする心の動きを表すうまい表現だなと私は思いました。

インセプションデッキ

インセプションデッキ *1 という、プロジェクトを始める前にプロジェクトの関係者全員に向けて行う10個の手ごわい質問が紹介されています。インセプションデッキというツール (質問) により、顧客も含めた関係者全員の認識を一致させることで、プロジェクトの方針やゴールを明確にしようという意図があります。

質問の内容そのものは、難しいことでも何でもありません。むしろ、当たり前のことではありますが、プロジェクトを始める前に確認しておくべき内容を10個の質問に絞り込めているということそのものが、著者の数多くの開発経験によるノウハウの集大成だと思います。

インセプションデッキという言葉そのものが、アジャイル界隈でも新しめの用語のようです。

リファクタリングの考え方

本書の内容として特筆することではないと思いますが、私が誤解していた内容だったので紹介します。本書では、リファクタリングはどんどんやって、継続することが重要だと書かれています。これまで私は、何か要件や仕様の変更があり、現状の設計がそれにあわない場合にリファクタリングしたり、即席で書いた練られていないコードを余裕のあるときにリファクタリングしていました。

本書は、プロジェクトの最初から「継続して」「少しずつ」リファクタリングに取り組むべきだと言っています。リファクタリングの工数を日々の開発の中に取り組むことで、リファクタリングによる進捗の遅れという考え方そのものをなくすという狙いもあります。つまりプロジェクトの終盤にリファクタリングする余裕がないという状況そのものをなくしてしまうということです。

また、私のように、何かあったらとか、後でまとめてリファクタリングしようという考え方だと、開発期間中に何も機能追加されない時期が発生してしまい、リファクタリングに汚名が着せられるケースがあるとコラムでも紹介されています。

本書を読んで、私は日々リファクタリングするようになりました。小さなコードに対して考えるきっかけが増えたことにより、頭の中に残っているせいか、数日経ってからもっと良いコードを思いついたりするようになりました。

プロジェクトの最初から「継続して」「少しずつ」リファクタリングする。これは良さそうです。

アジャイルサムライ読書会

本書の読書会も活発に行われているようです。たくさんの人たちと議論する中でアジャイル開発の理解度が格段に高くなると思います。ぜひ参加されてみてはいかがでしょうか。

アジャイルサムライの読書会(渋谷道場)をします #agilesamurai | Act as Professional - hiroki.jp

翻訳レビューへの参加

【急募】"The Agile Samurai"の翻訳レビュワーを募集します - 角谷HTML化計画(2011-04-26) の呼びかけに応募して、私もレビューアの1人に加えてもらいました。以前にアジャイルプラクティス *2 を読んでいたので、翻訳が素晴らしいのは分かっていたけれど、レビュー向けの原稿も私が想像した以上に日本語として分かりやすいように工夫され、練られた翻訳だと私は思いました。私のレビューの貢献は微々たるものなので、レビューアの1人と名乗るのもおこがましいですが、そのときの体験談を少し紹介したいと思います。

約20名のレビューア陣による容赦ないレビューがメールで送られます。原文と読み比べてより正確な文意を指摘するレビューアもいれば、日本語の係り受けを詳細に指摘するレビューアもいます。毎日何通ものメールが送られて、毎日原稿を更新してビルドされ、毎日必ずレビューアが指摘した内容に対して返信する角谷さん (@kakutani) 。

私は、今回のレビューに参加している期間中、ずっとこう感じていました。オンラインのやり取りのみだけど、何だか信頼感があるな。参加している他のレビューアも楽しんでやってそうだな。そして、きっと本書は良い本になるだろうな。

！？

そっか。アジャイルってきっとこういう文化なんだな。やってて嫌にならない、プロジェクトの方向性に意志があり、きっとこんなものが出来るんだろうと想像できる。その期待感が楽しみになり、自分も何かしら貢献しようと思えてくる。そういう雰囲気作り、チーム作りがアジャイルの最初の取っ掛かりではないかと私は思いました。

また、日常の生活の中で、他人の翻訳を原文とあわせて読む機会は少ないです。翻訳のレビューをやってみると、自分だったらこう訳すけど、この翻訳もすてきだな、この文章はこんな風に訳せるのかと、私自身にとって参考になりました。実際、私はレビューアなのに原文の翻訳内容に感心することの方が多かったです。

楽しい翻訳レビューに参加させてもらってありがとうございました。

リファレンス

• アジャイルサムライ−達人開発者への道−(Jonathan Rasmusson/西村 直人/角谷 信太郎/近藤 修平/角掛 拓未) - capsctrldays(2011-07-14)
• [Agile][書評]アジャイルサムライー達人開発者への道 #agilesamurai | Ryuzee.com

アジャイルサムライ−達人開発者への道−

*1:[Agile]インセプションデッキ日本語版 | Ryuzee.com

*2:

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

俺のコードのどこが悪い？ -コードレビューを攻略する40のルール-

コードレビューは、アプリケーションの品質を向上させる上でとても重要な取り組みだと認識されるようになっています。そんなコードレビューですが、私も以前、叩かれてへこんだりしたこともありました。そうこうしているうちに慣れて、むしろ指摘してもらえることで知らなかったことを知る機会となり、プログラマとして成長する良い機会でもあると、いまは考えています。

例えば、本書の中で、行の折り返し位置の体裁について2通りの折り返し方法を紹介しています。

1. 横幅最大値を超えた時点で機械的に折り返し
2. 構文木上の、より上位の要素において折り返し

後者の構文木の上位要素という考え方は、私には全くなかった考え方で純粋にそんなやり方もあるんだなぁとおもしろかったです。知らないことを知る場として楽しめるようになると良いけれど、お仕事だと厳しい意見もちらほら聞くかもしれませんね。

さて、本書の「レビュー準備編」では、コードレビューでへこまないための心構えや、そもそもコードレビューはどんな風にやれば良いの？といった、体系的な方法論とチェック項目を網羅しています。レビューチェックシートのサンプルも掲載されていて参考になります。

主題の「レビュー実践編」ですが、本書はコードレビューのためだけのノウハウ本ではなく、C/C++/Java といった言語仕様まで突っ込んだ特性を、コラムで説明しながら、こういう仕様の落とし穴があるからコードレビューでそこを注意しましょうといった解説になっています。私は C/C++/Java の開発経験がほとんどないので、へー、そういう仕様なのかと興味深く読ませてもらいました。コラムだけでも、著者の培ってきた実業務の経験が垣間見えたりします。

著者自身もあとがきにこのように書かれています。

あらゆる知識はお互い密接に関連しあっています。ということは、「汝、〜〜すべからず！」の裏側にも、コンパイラやインタプリタ、OS、CPU などの愉快な仕掛けが隠されているわけです。プログラマにとってこんな楽しいものはありません。レビュー項目に隠された、そんな楽しさの一端をなんとかして伝えたい、そんな目的をこっそり忍ばせて書き進めた結果、コラムや脚注がやたらと多い、珍妙な本になってしまいました。

いくつか私にとって興味深かったコラムを紹介すると、以下のようなものがあります。コードレビューを、プログラミングに関する背景を教える場と捉えても良いかもしれませんね。

• switch 分岐の効率

if/else 文は条件指定が増えるほど条件判定を実施するコストが増えるが、switch 文では case ラベルが増えてもアドレス格納テーブルのサイズが増えるだけで条件判定のコストは増えない。

• スタック渡しによるコスト

x86 アーキテクチャの 32 ビットモードはスタック渡しで、64 ビットモードはレジスタ渡しになる。6引数の関数を呼び出すために引数を準備するコストは、スタック渡しが 6.0 クロックに対してレジスタ渡しが 0.1 クロックだった。

• 言語として「頼り過ぎ」に舵を切った Python

Python のイテレータは next() で次要素の取り出そうとするが、要素が無ければ StopIteration 例外を発生させる。例外を多様する実行制御をもつ言語特性がある。これは 用語集 にもある EAFP の考え方の違いですね。

• fork() の使用

fork した子プロセスで execv() などの exec 系システムコールを使用して子プロセスを上書きする

• 「具象」から「抽象」へ

最初に基底クラスから定義しようとして上手くいかないのは「抽象」は多くの「具象」をもとに「抽象」化されるので、その順番でやってみると良い。

コラム単体を読んでもおもしろそうなので、コラムのインデックスがあると良かったなと思います。

読んでいるとコラムで横道に逸れることも多いのですが、もちろん本文も技術的背景が詳しく説明されています。読み進めていくとコードレビューというよりは、プログラミングのコツを教えてくれるように受け取れます。はまるポイントをコードレビューでチェックしようとしているのですから、プログラミングの深い洞察につながるのは道理ではありますね(^ ^;;

「レビュー実践編」はかなり幅広い内容を網羅していてプログラミングの気を付けるポイントとして実用的な項目がたくさんあります。本書で一通りチェックしてからコードレビューに臨むと指摘される項目がずっと少なくなると思います。とても勉強になりました。

リファレンス:
『俺のコードのどこが悪い？』へのご意見・ご要望・誤記情報 - 彷徨えるフジワラ
技術系執筆情報

俺のコードのどこが悪い?―コードレビューを攻略する40のルール

ゆるく考えよう 人生を１００倍ラクにする思考法

はてなダイアリーで著名なブログの1つ、Chikirinの日記 で有名なちきりんさんの著書です。[TopHatenar] Chikirin さんの順位 のランキングも凄まじい数字ですね。私は2008年ぐらいから購読しています。技術系以外のブログで私が最も読んでいるブログの1つで、生き方そのものや人生の選択の参考になっていたりします。

本書のコンテキスト *1 はよく練られていると思います。さらにオリジナルがブログなのでタイトルもうまく付けられています。例えば、実際、私は3章の 10年以上のローンはだめです から読み始めました。ブログで読んだことあるなと親近感があったからです。すると、その次節のタイトルは 大半の保険は不要 でしょう。読むしかないじゃないですか(^ ^;;

3章から読み進めて最後まで読んでしまい、せっかくなので1章 -> 2章もそのまま読むという変な読み方をしてしまいました。どこから読んでも良いし、タイトルで 釣られた 気になったところから読んでも良いと思います。ブログの内容から加筆・修正されてますし、本という、まとまった文章を読むことで考えることや受け取ることも変わってくると思います。気楽に読んでみて、ちょっと考えたりしながら、おもしろかったなーという感じの本だと思います。

本書を読んで印象に残ったことをいくつか紹介します。著者のブログに原文があるので気になった方はそちらを読んでみてください。

ゆるく考えよう

書名そのものが好きです。いまの時代、おそらく今後も、ものごとが複雑化・多様化している中で、これが絶対良いといった価値観を真面目に考えても分からないし、世の中は矛盾だらけなのでおそらく答えなんてありません。偉い人や年長者が言っただけで、さもそれが常識であるかのような風潮にもついていけない。答えなんて分からなくても、格好良い人生観がなくても生きていけるならそれで全然良いことだと思います。

wikipedia:認知的不協和 を抱えた状態で生きていくのは辛いです。嘘を付いて気にならない人は本物の嘘付きになるだけですが、真面目な人はうつ病になります。ゆるく考えるというのは、そういった状態から抜け出すためのヒントになると私は思います。

人生は早めに諦めよう！

私は過去2回ほど挫折して引きこもってたことがあるのですが、立ち直るきっかけは諸々を諦めたことでした。分不相応な考えは改めて目の前のことだけをコツコツやっていると、また道が開けてきたりしました。結局のところ、実力が足らず行動も伴わないことを実現できるわけがなくて、目の前のことだけでも真面目にやっていれば、(望むと望まないと) 何かしらの結果が出るということを経験的に学びました。著者と同意見なのですが、とっとと人生を諦めて、目の前のことに専念した方がもっとずっと良い人生になるんじゃないかと私は思います。

エリート家系な人には通じないですが、挫折して落ち込んでいるときに母親が言った言葉を、いまでも何か失敗したときに思い出したりします。反省することは大事ですが、落ち込む必要はないのでそんなときに役立ったりします。

田舎の、普通の家の、普通の子がそんな大変なことできるの！？やめときなさい。

自分に近いものにこだわりすぎるのはやめよう！(原タイトル:判断を誤らせるもの)

こだわりが客観的判断を遠ざけることと、そのものごとに対する影響力が強くなってしまうことの2つの難しさがあると述べられています。顧客や上司の何気ない一言を過大に解釈して失敗した経験がある人もいるのではないでしょうか。例えば、最近こんなことがありました。お仕事でいくつかの開発課題の優先度とスケジュールの打ち合わせで、営業さんと私の開発課題の優先度が違ったことがありました。営業さんの方が顧客の要望に近いという判断のもと、営業さんの意見が取り入れられましたが、開発後に実際に顧客と打ち合わせしてみると、営業さんが優先した開発課題は他の課題よりも優先度の低いものでした。

オープンソースソフトウェアの開発やコミュニティ活動は「プログラマがプログラミングを通して世界をより良くする」とも言えますが、距離感が遠そうで良いんじゃないかと思います。

自由であること

自分を縛るものをなるべく減らした方が楽な生き方になりそうです。先に書いたこだわりとも関連しますが、ある対象との距離や関係性が密になればなるほど自由からも遠ざかる気がします。昔、何かの記事で

研究で最も成果をあげるため、研究員に自由に研究させた

ようなことを読んだことがあります。実際、ほとんどの大学の研究室も自由な感じだと思います。自由にやらせて研究成果が出るからくりは簡単で、自由には責任が伴うからです。何かに縛られるというのは、広い意味で自分に対する言い訳を肯定してしまいがちになります。誰かや何かのせいにするよりも自己責任で生きる方が楽なのかもしれないですね。

よかった確認

いままでの私の人生の中でこれはなかったなーと感心しました。どんな悪いことが起きても必ず「よかった」ことを探すという心がけです。本書でもいくつか事例が紹介されています。例えば、こんなのです。

大事な仕事に寝坊をしたときにさえ、「そんな大事な日に起きられないなんて、相当疲れていた証拠よ。もしも起きられていたら、無理がたたって病気になったかもしれない。起きられなくて（倒れる前に体力が回復できて）本当に良かったね」

結局のところ、起こったことは変えようがない。それをどうこう言っても言わなくても前に進むしか選択肢がありません。「よかった」という言葉には前向きな意思が表れて良いですね。

ゆるく考えよう 人生を１００倍ラクにする思考法

*1:ある編集者さんにこの言葉を教わりました。直訳すると「文脈」ですが、読者が読み進め易いように、分かり易いように内容を編纂したり章節を構成することを指すようです。

中日ドラゴンズ論

http://ameblo.jp/beproud-inc/entry-10748515926.html と http://ameblo.jp/beproud-inc/entry-10748552752.html でおもしろく書評を読ませて頂いた翌日に、たまたま書店で小一時間潰す間があり、そのときに目に入り、読み始めたらおもしろくてそのまま購入してしまいました。

2000年以降はほとんどプロ野球を見ていませんが(そもそもテレビがない)、1990年代はよく見ていました。著者の今中慎二氏の全盛期をテレビで見ていた野球ファンとして懐かしくもありました。中日ドラゴンズは毎年強いというイメージがあります。そのはずで9年連続Aクラスにいる理由が、夏場にピークを持って行く戦略のユニークさや、プロとして当たり前にやることの重要性、練習に裏付けられた自信など、とても説得力のある内容でした。

普段の自分の生活を鑑みて当たり前のことを当たり前にやっているか、全然そうじゃないなと反省する気持ちになりました。

やっぱり恐い星野監督

私にとって一番興味深かったのは星野監督の恐さが書かれた章や伝統として先輩が後輩を指導する内容が書かれた章でした。

私は高校まで野球をやっていました。野球部の監督というのは得てして恐いです、、、怒声、張り手もつきものでした。今でこそ、暴力事件とか問題になるようですが、十数年前は別に問題ではありませんでした。そして監督も恐いけれど、また違った意味で先輩も恐ろしい存在でした。監督がいない練習中に声が出てないと、バットを持った先輩が同級生を次々と、、、

おっと話が大きくずれかけました(- -#

本書を読んで、大半の選手が星野監督が恐くて恐くて叱られないように緊張感を持って行動していたことが分かります。もちろん、その次の段階は自分で考えることが重要だと分かり、選手たちが自主的に行動するお話へ展開されます。私はあまりこういうお話が好きではありません。正しい正しくないのお話ではなく好きではないのです。

以前、あるセミナーの講師が仰っていた言葉が好きです。

大人にものを教えるのに叱る必要はない。

叱られても叱られてもその次のレベルへ進めるのは、叱られ耐性に強い精神力を持った人のみだと思います。業界や業種にも依るでしょうが、叱られ耐性に強い精神力を持った人のみが認められるというのは、私のような、そうではない人から見るとやっぱり辛いものがあります。もちろんプロ野球のような、勝負ごとに負けん気の強さも重要でしょうから、そういった精神力も資質として必要なのかもしれません。

叱られてまず考えることは「叱られないようにする」ことだと思います。その叱られた問題の解決方法が単純であればあるほど、叱る効果も高いことは分かります。しかし、それが複雑な問題だと本質的な問題の解決から遠ざかる可能性があります。そのリスクを指導者が全て負えるかというと、指導者も強いプレッシャーに苛まれそうな気がします。何だかみんな幸せじゃなさそうで、私はあまり好きではないです。

しかし、新卒で入社した会社のことを思い返してみました。とにかく上司、先輩が恐かったです。当時の私が問題の本質を追求していたとは思えませんが、今よりは目の前のことに対してひた向きさと緊張感を持って行動していた気がします。

自分の行動を自分で律するというのは、叱られないと継続しなくなってしまうぐらい難しいことかもしれないと本書を読んで考えさせられました。

中日ドラゴンズ論 (ベスト新書)