「リファクタリング」の完全読破。その5
今回からカタログに入る。第6章は内容が多いので2回にわけて。
今回は、総論と「メソッドの抽出(P110) 」「説明用変数の導入(P124)」をしっかりと。
第6章 メソッドの構成
総論
下記の通り重要な章。いくつかの項目を除けばクラス階層の変更が不要なので、やりやすいという面もある。
（経験上、クラスを作ったり消したりすると面倒になる職場が多い。悲しいことに。）
P109 メソッドを、適切にパッケージ化されたコードとして構成することが、本書のリファクタリングの大部分です。 問題を起こすのは、ほとんどの場合、長すぎるメソッドなのです。 メソッドを分解すると、その動作がより深く理解できます。そして、そのアルゴリズムがもっとわかりやすくできることに気づくかもしれません。
さて、いったいどこまでメソッドを小さくするといいのだろうか。
私はここに書いてある通りと考える。
P110 メソッド名とメソッド本体の間の意味的な距離が重要なのです。コードを抽出することで明快さが向上するなら、そうすればよいのです。 抽出されるコードよりも名前のほうが長いとしてもです。
ファウラーは、現実的、実務的な人だという印象が強い。（これは他の著書でも強く感じる。UMLでは顕著に。）
ここでも、見た目や体裁より如何に実際の作業で効果が上がるか、ということが書かれている。
本章の構成
本章では「メソッドの抽出(P110)」がメインとなり、それをいくつかのリファクタリングが支えている。
例えば、「問い合わせによる一時変数の置き換え(P120)」で一時変数を取り除く。
困難な場合は先に「一時変数の分離(P128)」を行う。
それでもダメなら「メソッドオブジェクトによるメソッドの置き換え(P135)」を適用する。
パラメータの場合は「パラメータの除去(P131)」を行う。
また「アルゴリズムの取替(P139)」を検討する。
などなど。（これらは次回取り上げる。）
知っての通り、今では簡単なリファクタリングは自分で書く必要はない。
例えば「メソッドの抽出」なら、Eclipse上で括って右クリックし「リファクタリング」「メソッドの抽出」を選択、そしてメソッド名を入力すると自動で変換される。
しかし、もちろんリファクタリングはそんな簡単なものばかりではない。
効果的なリファクタリングは、プログラマが意図的に書かなければならないものが多いので、しっかり学ばなければならない。
「メソッドの抽出(P110) 」と「説明用変数の導入(P124)」
「メソッドの抽出」は本章のメインとなるリファクタリングである。
「説明用変数の導入」は適用したくなる場面が多いが、ファウラーはその場合も「メソッドの抽出」を適用することを推奨している。
ここでは、両者を比較することで理解を深めようと思う。（本書でもそうしている。）
まずは修正前のコード。こういうコードをよく見る人も多いのでは。（下記のコード群は全てP125〜P127を元にしたもの。）
double price(){
//価格は、基本価格ー数量割引＋送料
return _quantity * _itemprice - //基本価格
Math.max(0, _quantity - 500) * _itemPrice * 0.05 + //数量割引
Math.min(_quantity * _itemPrice * 0.1, 100.0); //送料
}
まず、_quantity * _itempriceが複数回書かれており、意味もコメントの通りなのでbasePriceとして抽出する。
そして、Math.maxの行と、Math.minの行もコメントの通りに「説明用変数」として抽出する。
それだけで「説明用変数の導入」は完了する。
ここで重要な点は「コメントを取り除ける」ということ。修正後のコードは、コード以上のことを何も表現していないからだ。
（とはいえ、それでも書けというプロジェクトはいくらでもありそう。ご愁傷さまです。）
double price(){
final double basePrice = _quantity * _itemPrice;
final double quantityDiscount = Math.max(0, _quantity - 500) * _itemPrice * 0.05;
final double shipping = Math.min(basePrice * 0.1, 100.0);
return basePrice - quantityDiscount + shipping;
}
十分わかりやすいが、ファウラーは上記のとおり「メソッドの抽出」を推奨している。
それを適用するとこうなる。
double price(){
return basePrice() - quantityDiscount() + shipping();
}
private double basePrice() {
return _quantity * _itemprice;
}
private double quantityDiscount() {
return Math.max(0, _quantity - 500) * _itemPrice * 0.05;
}
private double shipping() {
return Math.min(basePrice() * 0.1, 100.0);
}
読みやすさとしては同じようなものだと思う。
メソッドにする利点は「他の部分からも使える」ことが大きく、必要に応じてprivateの解除を行って良い。
できる限り「メソッドの抽出」を行い、「説明用変数の導入」 を使うのは「メソッドの抽出」では手間がかかる場合だとファウラーは書いている。
今回書いたリファクタリングは、頭の硬い上司（やそれに準じる体制）がいてもできるのではないかと思う。
次回は、これを支えるリファクタリングについて記載する。
続く。
「リファクタリング」の完全読破。その4
今回は第4章と第5章。この次から、いよいよカタログに入る。
第4章 テストの構築
多分ここが、古いということで一番割を食ってる箇所。
JUnitの説明などは、今は他の本を読んだ良いと思う。
所々出てくる、今読んでも色褪せないなと思う部分だけ引用する。
（古い古いと書いているが、未だにJUnitすら使っていないシステム開発現場はあるし、むしろ経験上そっちの方が多い。）
P89 リファクタリングに限らず、よいテストを書くとプログラミングが加速するようです。 P90 テストを完全に自動化して、その結果もテストにチェックさせること。 P94 テストを頻繁に実行せよ。コンパイル時にはテストを局所化して、1日に最低1度はすべてのテストを実行せよ。 P97 バグレポートを受け取ったら、まずそのバグを明らかにするための単体テストを書け。 P98 不完全なテストでも、書いて実行するほうが、実行できない完全なテストよりもましだ。 P99 失敗の恐れのある境界条件を考えて、そこを集中的にテストせよ。 P100 失敗すると予測されるときに、例外が上がることをテストし忘れないこと。 P101 テストですべてのバグが見つからないからと入って、テストを書くのをやめてはならない。ほとんどのバグはテストで補足される。
テストのやめ時について、いくつか補足する。
カバレッジを100にする意味があるときと、あまり無いときがある。
まずはテストにおける収益低減点を考えること。
適当な時間で大部分のバグを補足するほうが良い。
継承とポリモーフィズムを踏まえるとテストの組み合わせはどんどん増えていくが、全部の組み合わせを試す必要はない。
ふと見ると、Kent Beckの「テスト駆動開発入門」も、相当に古い本だった。
私が持っているのは2008年の第3刷だけど、日本語の初版は2003年。
リファクタリングもTDDも、思想と技術は確実に身になってるんだけど、職場では強制されないし、逆に強制できないというのが少しもどかしい。
第5章 リファクタリング・カタログに向けて
こちらはタイトルのとおり、カタログ（第6章〜第12章）の記述方針等の説明。
注意点として、リファクタリングの説明に集中するために、金額をdoubleとしたり本来はまずしないような書き方もしているということ。
（それを踏まえると、Javaのバージョンが古いということも、ある程度は受け入れられるかな。）
また、GoFには「デザインパターンはリファクタリングの目標を提供する」と書かれており、リファクタリングを使うとき、デザインパターンはその出発点であることを心に留めるようにと書かれている。
・過去記事。
「リファクタリング」の完全読破。その1 - holyppの日記
「リファクタリング」の完全読破。その2 - holyppの日記
「リファクタリング」の完全読破。その3 - holyppの日記
「リファクタリング」の完全読破。その3
帰省などで間があきましたが、今回は第3章。8月中の読破を目標に。
第3章「コードの不吉な匂い」
テーマは、いつリファクタリングを始めていつ終えるか。
(P76) ここではリファクタリングの必要を示す不吉な兆候について説明していきます。 インスタンス変数はいくつ以上になれば多過ぎであり、メソッドは何行以上で長過ぎるかなどの感覚は、自ら養っていかねばなりません。
他に「経験で磨かれた人間の直感には、メトリックスをいくら集めてもかなわない」とも書かれており、経験の重要さが強調されている。
各項目はそれぞれ半ページから2ページで文量は少ないが、引用されている手法を確認しながら読むとかなり時間がかかる。
本エントリは後から見直せるように、見出しと簡単な説明を書いていく。
重複したコード
同一クラス内の複数メソッドに同じ式がある場合。
完全に同じでなく似通っている場合は、共通に使える部分とそうでない部分を分離し、TemplateMethodの形成(P345)を検討する。
複数のメソッドが、同じ処理を違うアルゴリズムで実装していた場合は、アルゴリズムの取り替え(P139)を適用する。
関係の無い二つのクラス間で、重複したコードがある場合は、クラスの抽出(P149)を行い処理を委譲する。
長すぎるメソッド
メソッドが長くて、ソースを追わないと何をしているかわからない場合。
メソッドの分割時に問題になるのは引数や一時変数が多いメソッドで、先に以下の手法を使ってスリム化を行う。
「問い合わせによる一時変数の置き換え(P120)」
「引数オブジェクトの導入(P295)」
「オブジェクトそのものの受け渡し(P288)」
「メソッドオブジェクトによるメソッドの置き換え(P135)」
条件分岐やループも「条件記述の分解(P238)」を使って抽出を検討する。
巨大なクラス
インスタンス変数を持ち過ぎたクラス、コード量の多いクラスは「重複したコード」の温床。
多すぎる引数
オブジェクトをそのまま渡し、メソッドがさまざまなデータをそこから取り出せば良い。
変更の発散、変更の分散、パラレル継承
設計は、一つの変更要求（DBの変更や商品追加など）に対して、1つのクラスの1箇所が常に修正対象となるようにする。
以下のような状態になったらリファクタリングを行うべき。
変更の発散：一つの変更に対して同一クラス内の複数のメソッドを少しずつ修正しなければならない。
変更の分散：一つの変更に対して複数のクラスを何度も修正しなければならない。
パラレル継承：一つの変更に対して複数の継承木にそれぞれサブクラスを作らなければならない。
属性、操作の横恋慕
見出しの翻訳が良いなと思う。
あるメソッドが他のオブジェクトのgetメソッドを何度も何度も呼び出している場合、メソッドの位置が悪い。
ただし、StrategyパターンとVisitorパターン（と、Self Delegationパターン）など例外はある。
上記のパターンは変更に必要な部分(この場合は振る舞い）を1か所にしているので、パターンを優先する。
データの群れ
「数個のデータがグループとなって」属性やシグニチャに頻繁に現れる場合は、オブジェクトとしてまとめてみる。
基本データ型への執着
基本データ型ではなくオブジェクトを使う。
例えば「電話番号」を最初に文字列で定義し、後から頻繁にフォーマット変更などの振る舞いが必要になった場合、オブジェクトにすると良い。
スイッチ文
スイッチ文を見たらポリモーフィズムを使って解決できないか考える。
1章で行った「State/Strategyによるタイプコードの置き換え(P227)」や、null値で分岐している場合の「ヌルオブジェクトの導入(P260)」など。
怠け者クラス
十分な仕事をしないクラスは排除する。「階層の平坦化(P344)」、「クラスのインライン化(P154)」など。
疑わしき一般化
「いつかこの機能が必要になるさ」と凝った仕掛けを作った場合。例えば、あるクラスやメソッドがテストケースでのみ利用されている場合など。
一時的属性
インスタンス変数の値が特定の状況でしか設定されない場合。クラスとして切り出すか、ヌルオブジェクトを使う。
メッセージの連鎖
クライアントがオブジェクトにメッセージを送り、そのオブジェクトが更に別のオブジェクトにメッセージを送り、更に……という場合。
getHoge()のような呼び出しが長い行となって連なっていたり、一時変数が非常にたくさん定義されているとあやしい。
仲介人
メソッドの大半が別のオブジェクトに委譲しているだけのクラスは除去する。
不適切な関係
これも翻訳が良い。見出しも本文↓も。
仲の良すぎるクラスは、いにしえの恋人たちのように、遠くに離してあげねばなりません。
この場合は「双方向関連の単方向への変更(P200)」、「以上による継承の置き換え(P352)」を検討する。
クラスのインタフェース不一致
処理が同じでシグニチャのみが異なるメソッドは「メソッド名の変更」を行う。
（見出しと説明文を読んでも、イマイチ何が言いたいのか理解できない。どういう場合？）
未熟なクラスライブラリ
再利用はオブジェクト指向の目的とよく言われるが、万能なクラスライブラリというのは非常に難しいもの。
既存のクラスライブラリに追加したいメソッドがある場合は「外部メソッドの導入(P162)」、「局所的拡張の導入(P164)」を行う。
データクラス
get,setメソッド以外に何も持たないクラスに、利用しているクラスから振る舞いを移せないか検討してみる。
接続拒否
サブクラスが親の属性と操作の一部しか利用していない場合、継承階層が間違っているというのが伝統的な見方になる。
兄弟となるクラスを新たに作成し、「メソッドの引き下げ(P328)」、「フィールドの引き下げ(P329)」を行う。
サブクラスが「振る舞いは継承するけどインタフェースは必要無い」場合は「委譲による継承の置き換え(P352)」を行う。
コメント
コメントは良いものだが、それが「わかりにくいコードを補うため」だとしたら修正する必要がある。「表明の導入(P267)」など。
「リファクタリング」の完全読破。その2
ソフトウェアシステムはほぼ間違いなく、汚く滅茶苦茶になってしまうことに気づいたからです。 最初はプログラマの心のなかでけがれのない水晶のように輝いていた設計が、時間が経つことで劣化し、悪くなった肉のように腐敗していきます。 1年前に構築した、こぢんまりした出来の良いシステムが、翌年には関数や変数が絡まり合ったひどい泥沼に変わります。 いったい何が起きているのでしょう。 「レガシーコード改善ガイド」まえがき
大きなシステムに携わったことがあるなら、痛いほど気持ちがわかると思う。
私はこの問題を、プログラマのレベルが低いプロジェクトにのみ起こる現象だと思っていたが、どうやらそうではないらしい。
そんな簡単な問題では無かった。
第2章 リファクタリングの原則
ここではリファクタリングの定義にはじまり、行う理由、いつ行うべきか、などが示される。
中でも、私はこの文が気に入っている。これは冒頭の問題への回答でもある。
(P55) リファクタリングなしでは、プログラムの設計は徐々に劣化していきます。 リファクタリングを定期的に行うことで、コードの状態をしっかりと保つことが出来ます。
つまり、システムが劣化していく、汚れていく、泥沼になる、というのは避けがたいことで、それを浄化するのがリファクタリングである。
汚れた泥沼というのはリファクタリングをしなかったシステムということだ。
リファクタリングの定義
ここで、リファクタリングの定義を引用する。
(P53,54) リファクタリング(名詞)：外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること。 リファクタリングする(動詞)：一連のリファクタリングを行って、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること
定義に続けて2点強調されている。
・ソフトウェアの外部的振る舞いを保つこと。
・ソフトウェアを理解しやすく、変更を容易にするために行うこと。
つまり、機能追加はリファクタリングでは無い。
リファクタリングをするときは「機能追加をしない」ことを意識するように書かれている。
いつリファクタリングをすべきか
明確な答えは無いが、いくつかのガイドラインがある。
・3回重複したコードを書いたとき/無駄なことをしていると思ったとき。2回なら我慢する。
・設計が原因で、機能追加が困難なとき。
・バグフィックスでコードが不明確なとき。
・コードレビューのとき。例えば二人一組レビューを行い、そこでリファクタリングを行う。
別の節で、Ward Cunnninghamは未着手のリファクタリングを借金に喩えている。
P66 借金に利子があるように、あまりに複雑化したコードは、維持と拡張のコストがかかります。 利子もある程度ならば払うことができますが、あまりに高くなると、自分の首を絞めることになってきます。 借入金は適切に保たねばなりません。ときどきリファクタリングを行って負担を軽減していくことが重要です。
管理者を説得するには
品質を気にする管理者は説得することができる、と方法が書かれているが、やはり面白いのは次の箇所だろう。
品質よりもスケジュールを気にするマネージャの場合はどうするか。これは引用しておきたい。
P61 いささか問題発言的なアドバイスをしておきましょう。彼らにはだまってリファクタリングするのです。 これはマネージャたちに対する反乱でしょうか。私はそうは思いません。 ソフトウェア開発者はプロとしての誇りを持っています。 （中略） スケジュールを気にするマネージャであれば、開発者が最も速い方法を選択するのを望むでしょう。 ただし、どのような手段で実施するかは、マネージャの知るところではありません。 最も速い方法はリファクタリングです。だからリファクタリングをするのです。
プロとしての誇りを持つソフトウェア開発者が、最も速い方法で開発する。そこには何の問題も無い。
まとめ
他にもいくつかの節があるが、読み通すことで思想が理解できる体験談・エッセイなので、要約のようなことは難しい。
それでも、最後に一つ紹介するならばこれ。
P57 ここで、Kent Beckが自らを語ったセリフを思い出しました。 「僕は、偉大なプログラマなんかじゃない。偉大な習慣を身につけたプログラマなんだ」。 リファクタリングによって、堅牢なコードがずっと効率よく書けるようになるでしょう。
ファウラー自身も、バグ探しは得意ではないと言っている。
ただし、リファクタリングできればコードに立ち向かえるようになると。
私もいろいろな場面で「自分は偉大なプログラマじゃないからこれができないんだ」とよく感じる。
しかし、それも偉大な習慣を身につけることで少しずつ変わっていくのかなと。
そして、偉大な習慣を身につける第一歩は、本書をマスターすることかなと理解して、進んでいる。
「リファクタリング」の完全読破。その1
ファウラーの言わずと知れた名著だけど、私は15章構成のうちカタログ部分（第5章〜第12章）を今まで読んでいなかった。
理由としては、やはり古いこと、そんなに難しい内容では無いこと、リファクタリングの思想という意味では理解していたこと。
ホントに古い本なので、もういいかなと思っていたんだけど、少し読み直したらやっぱり一度は全部書くべきだった。
リファクタリングの思想と同じくらい、カタログにある各種技術は重要だった。
それに「おすすめの本は？」と聞かれたときに、とりあえずこれを挙げることは多くて、そのくせ完読してないのは質が悪いというのもある。
ということで、今回は「はじめに」と「第1章」
はじめに
ここでは本書の説明と、リファクタリングについての話が少し。
・リファクタリングはリスクが高いのでやみくもに行ってはいけないこと。
・手順を守り、体系的に行うこと。
・具体的には「1度に1ステップずつ」行うこと。
それに、ファウラーとKent Beckが以前にした仕事の話がある。さらっと読む。
第1章 リファクタリングー最初の例
大まかには、3つのクラスからなるシステムをリファクタリングしていくという流れ。
最初の状態では、class Customerが、巨大なstatement()メソッドを持っており、明らかに悪い設計となっている。
まずは、Eclipseを起動してこの悪いコードを書き、本書の通りにリファクタリングをしていく。
内容は「1度に1ステップずつ」の思想を守っているので、非常に簡単。
頭を使うのは最後のポリモーフィズムだけ。
まず最初にテストの重要さが書かれる。
（P7~8） 最初にすることは常に同じです。対象となるコードについてきちんとしたテスト群を作りあげることです。 リファクタリングの成功は、良いテストを用意できるかで決まります。
とあるが、本書にはテストコードはないので、JUnitを使って自分で書く。
そしてリファクタリングをはじめる。
ほとんどが基本的なことだけど、改めて読むと勉強になる。
メソッドの抽出(P110)
switch文をメソッドにする。
ローカルなスコープを持つ変数は、新規メソッドの引数か一時変数にならないか検討する。変更されない変数はメソッドの引数として渡すことができる。
変数名を変更する
コンパイラが理解できるだけではなく、人間にとって解りやすいコードにする。
メソッドの移動(P142)
使用するデータを持つオブジェクトにメソッドは定義されるべき。
問い合わせによる一時変数の置き換え(P120)
代入した後に変更されない一時変数は、問い合わせメソッドにする。
一時変数は長くて複雑なルーチンの原因となるので、できるだけ減らす。
thisAmountやtotalAmountのようなそれっぽい変数があやしい。
P34 料金計算の条件文をポリモーフィズムに置き換える
ここだけ、ちょっと大きい。
「他のオブジェクトの属性を調べるswitch文を書くことは、常に間違いです。他のオブジェクトではなく自分自身について行うべきなのです。」
とあり、それを実現する。そのために以下の手順が必要。
State/Strategyによるタイプコードの置き換え(P227)
自己カプセル化フィールド(P171)
メソッドの移動(P142)
ポリモーフィズムによる条件記述の置き換え(P225)
まとめ
P52 （リファクタリングは）クラスの責任を分割させ、保守しやすいコードを書くのに役立ちます。 手続き的なコードとはかなり様子が異なるので、慣れるのには時間がかかるかもしれません。 しかし、いったん慣れてしまえば、もう手続き的プログラミングには戻れないものです。
「はじめに」でファウラーが言及したプロジェクトも汚いコードだったらしい。
その例も含め、リファクタリングの工数を見積もれるプロジェクトというのはほとんど無い。
本書を読んでもその事実は変わらず、これを読んだからって工数がもらえるわけではない。
ただ、そんな中でも本書のカタログにある技術を習得するのは大事。リファクタリング云々の前に、コードの質が良くなる。
ホントに古い本なので「今風の書き方」という意味では参考にならないけど、技術としてはその一歩手前の「設計」が学べる。
例えば上記の引用の通り「Javaで書いた手続き型のコード」があったら、それをスマートに修正できるようになる。
並行で他にもいろいろと読んでいるけど、8月中には「リファクタリング」を終えたい。
大局観（羽生善治）
書店をうろうろしていたら目に入ったので。
2011年2月10日初版、4月20日に四版なので結構売れていると思う。
はじめに
いったん本書の感想を書いたところ、格言集のようになってしまった。
「折り目」を付けたページを読み直し、それを順番に書いていったからだと思う。
文字通り「大局観」が無いとはこのことか、と反省して書きなおしてみた。
今度はテーマは何か、それを具体的、または抽象的に書いているところはどこか。
それを補足する（できればインパクトのある）エピソードはあるか、などを意識してみた。
読みなおしてみると、功を奏したとまでは言えないが、いくらかマシになった。
大局観
本書のテーマはそのまま「大局観」。
特徴としては、やはり将棋についての言及が多い。
将棋の格言であったり、自分の経験であったり。
まずは、言葉の定義から始まる。
P7 「大局観」とは一般には馴染みがない言葉だが、「大局を見て考える」などの表現ではよく使われる。「木を見て森を見ず」という格言があるが、これは「部分だけしか見ず、全体を見ていない」という意味でその反対の意味が「大局観」である。 P23 体力や手を読む力は、年齢が若い棋士の方が上だが、「大局観」を使うと「いかに読まないか」の心境になる。 将棋ではこの「大局観」が年齢を重ねるごとに強くなり進歩する。 自分の若い時代、「二十歳の自分」と闘っても負けない―― この「大局観」を身につけ全体を検証するのである。
つまり大局観とは、全体を俯瞰し、抽象的に現在の状態とその方針を感じる力だろう。
そして、おおよその方針を決めることで、具体的な行動を考える際に、無駄な選択肢が排除される。
この「いかに読まないか」というのは、私たちの（おそらく一般的な）仕事にも通じるところがある。
どんな仕事でも新人のうちは、本筋とは違うところに拘って余計な時間を使ってしまうものだ。
先輩に相談したときに「ああ、そこは掘り下げて考えなくて良いよ。こっちに関して３パターン考えてみて」と言われたりする。
それが、どんな新人でも３年ほど経つと「勘どころ」がわかってきて、どこが重要なのか判断できるようになる。
それに近いのではないか。
「大局観」について本書で最もわかりやすく書かれている箇所を以下に引用する。
今流行のコンピュータ将棋への言及でもある。
P200 コンピュータ将棋といいうのは、基本的に、可能性のあるあらゆる手をすべて読んで、最善手を探していく。つまり、計算をたくさんしていくことによって、より正確さを挙げていくわけだ。 プロ棋士の場合なら、局面を見た瞬間に、三手くらいに絞り込むことができる。あとの何百、何千という手は捨てるわけだ。 そして、最初に絞り込んだ三手ではどうしてもダメだという時になって、いったん捨てた手のなかから最善手を拾って検討する。 私は、コンピュータの指し手に対して、大きな違和感を持っている。 つまり、対局者が誰だかわからない状態で棋譜を見せられれば、これは人間が指したのか、コンピュータが指したのか、一目瞭然でわかるということだ。
この「プロ棋士の場合」に使われているのが「大局観」なのだろう。
後半の「一目瞭然」には少し驚いたが、「大局観」という観点で見ると、コンピュータ将棋は「一貫していない」ということだろう。
逆に考えると、コンピュータ将棋は「大局観」が無いのに、プロ棋士に近付いているということでもある。
これで「大局観」がどんなものか理解できたと思う。
大局観を補足する
本書は全体を通して「大局観とはなんぞや」を書いているわけではない。
集中力、ツキ、負け方、リスク、感情、記憶、知識、直感、確率など、内容は多岐に渡る。
全体としては「大局観」を補強する意味で書かれているが、「棋士の書いたビジネス書」のような雰囲気もある。
とはいえ「棋士生活二十五年の節目で書いた」とあるとおり、その視点はサラリーマンのものとはかけ離れていて、面白い。
例えば、以下にいくつか（勝手に）要約したものを紹介する。
「着手をする前に四つの香車を確認しなさい」 盤上の四隅、つまり晩の全体を見ることで見落としなどのうっかりミスが少なくなる。 「三ヶ月間毎日、一日も休まずに将棋の練習をするとアマチュア初段から四段になることを保証できる。」 将棋の場合、いい手が閃くとかたくさん読めるというのも才能だが、根源的な最も素晴らしい才能は「地道に、確実に、一歩一歩進み続けることができる」こと。 「もう少しゆっくり」 羽生さんが師匠に貰ったアドバイス。 将棋の世界では師匠が弟子に手取り足取り教えることはなく、自分で考える習慣をつけさせる。 「世の中の99.9%は金で決まる。しかし、残りの0.1%はそうはいかない。私は、この仕事を通じてそれを学びました。」 これは「ハゲタカ」から。羽生さんは、確率というのもそれと同じではないか、と言う。 「どんなジャンルでも一流の作品にたくさん触れなさい」 手塚治虫が「どうしたら上手に漫画が描けますか？」と訊かれたときに答えて。
運について
羽生さん自身は「ゲン」は今はまったく担いでいないらしい。
棋士の中には、将棋会館へ行くルート、着る物（下着も）、扇子、髭など、ゲンを担ぐ人はいるようだ。
そんな中で、ゲンとは少し違うのだが、この二つは感じるところがあった。
「きみは自分にツキがあると思うか？」 松下幸之助はよく訊いていたそうだ。相手が「はい」と答えると付き合いが続いていく。 「東京へ行く汽車に乗る時、上手くキセルをする方法は知っていたが、そんなことをすれば大きなツキを失うに違いないのでやらなかった」 米長先生の「人間における勝負の研究」にある一文。
終わりに
後半はそれこそ格言集のようになったが、自分で読み直しその度にストーリーを思い起こすために書いてみた。
羽生さんの著書は他に「決断力」を、将棋つながりでは「ボナンザvs勝負脳」も読んだが、どれも面白い。
ちなみに将棋は全く出来ません。
（はてな年間100冊読書クラブ、9冊目。）
回転木馬のデッド・ヒート（村上春樹）
動機
動機は、私が日頃から影響を受けているid:finalventのこちらを見て。
finalvent 長期というなら聖書かな。あまり本という感じはないけど。小林秀雄「考えるヒント」もなんども。村上春樹「回転木馬のデットヒート」なんかも。“@kazu_yama1003: @finalvent 先生が今までで一番読んだ本って何ですか。聖書ですか、やはり?” 4月30日
「考えるヒント２」も買ってきたけどそちらは未読。
感想
本書の内容は、村上春樹が人から聞いた話、つまり体験談集ということになる。
一つのエピソードは、２０から２５ページであり、長編と比べるまでもなく内容が凝縮されている。
感想を一言で言ってしまうと、全体を通して「理解はできないけど、納得はできる。」
細かく解読出来るかといえば出来ないけれど。ただぼんやりと、ああ、そういうことだよね。と。
エピソードは、その語り手ですら感覚的にしかわからない（と言っている）ものも多く、私が論理として理解できないのも自然であると思う。
ただ「そういうものなのよ。」ということは共有できる。
ところで、極東ブログの書評では、こうある。
最初の作品が発表されたのは１９８３年の秋で、私はその年に大きな人生の転機があった。印象深く思い出す。私が２６歳。春樹さん（まだ超メジャーな作家とも言えなかった）が３５歳だ。
読む時期というのはやはり大事で、それが何かの転機の前後であるとか、それこそ年齢としての転機の前後であるとか（まさに、それについてのエピソードもある。）、そういうときは普段より感じるところが多い。
また、ここでは「書かれた時期」についても言及しているが、この場合は読み手が書き手に追いつく年齢というのも、やはり重要になる。
ところで、今の私は当時の翁よりは年長で、当時の著者よりは年少だ。
なんらかの転機かと言われると、そういうものはここ最近感じていない。
そんな状況で一読したわけだが、特に「影響」を受けた感じはしなかった。
ただ、静かに、糧になったな、と。こういうものを摂っていかなければいけないのだな、と感じた。
（それを影響というなら、確かにそうなのだが。）
誰もが生きて行く中で、自分では決して通りかからない、足を踏み入れないような道というのはあって。
それがどんな道なのか、縁のない自分にはわからないし、何事もなければその道程を想像することすらできない。
本書は、そんな道の中でも、とびきりのやつを集めたような。
私が例えると、そういう印象の一冊。
村上春樹の中でも、特に長編と比較するとずいぶん読みやすい。平易という意味ではなく、簡潔であるという意味で。
★をつけるとしたら、ちゃんと5をつけられるし、図書館で読んだとしても、自分のために買ってしまうくらいの本。
こういうものを、しっかり摂っていかないと。
35歳までに、何度も読み返すことになりそう。
（はてな年間100冊読書クラブ、8冊目。）
