Elasticsearchを1.7系から5系にバージョンアップした

私が仕事で携わっているRailsプロジェクトで使っているElasticsearchのバージョンアップを行った。1.7系から一気に5.5.2 5.1.2*1にアップデートしたため、ハマりどころも多かったので、自分の備忘録のために記録しておく。

Dockerを使ってElasticsearchのバージョン切替

まず、ローカルでのElasticsearchのバージョン切替には、Dockerを使った。Dockerで対象バージョンを切り替えると、もし既存のプログラムに不具合が出た場合でも対象のElasticsearchを以前のものに切り替えるだけでいいので、メンテナンス性に優れている。 以前はHomebrewで入れていたのだが、ミドルウェアのバージョンアップを行うのは大変なので、開発の途中段階でDocker for MacとKitematicを導入し、Elasticsearch、Postgresql、Redisなどのミドルウェアは全てDockerを使って扱うようにしている。

Docker HubからDocker Imageを取得

Macを使っているので、Kitematic経由でElasticsearchのofficialから5.5.2-alpine 5.1.2-alpine*2を取得した。

kuromojiのインストール

デフォルトのイメージだとkuromojiプラグインが入っていないので、shellにログインしてインストールした。

elasticsearch-plugin install analysis-kuromoji

とりあえずこれでローカルの環境はOKとした。（あとでオリジナルのDocker Imageを作った）

Elasticsearchのmappingの修正

Railsでは、elasticsearch-rails、elasticsearch-modelを使っている。とりあえず1.7のときの記述のまま動かして、Elasticsearchのログを見ていると、Warningが大量に出ていた…。もちろん動かない項目もたくさんあった。以降に出てくるコードはRailsの各Modelでのmappingの修正項目なので、Rubyのコードである。

mappingはdynamicをfalseに

Dynamic mappingを有効にしておくと、fieldを定義しなくてもよきに計らってデータ登録ができるみたいであったけれど、fieldを管理したかったのでfalseに設定しておいた。

Before(Elasticsearch 1.7)

mapping do
  # 略
end

After(Elasticsearch 5.1.2)

mapping dynamic: false do
  # 略
end

検索対象項目を全てmappingしなければならない

1.7の頃は、as_indexed_jsonメソッドで渡した要素が全て検索対象になっており、明示的にindexesで設定しなくてもよかった。ところが、5系ではindexesに登録しているfieldでないと、検索項目として無視されてしまった。1.7の頃はanalyzerを指定していたfieldだけindexesを書いて登録し、数字などのfieldはas_indexed_jsonで渡すだけだったのだが、全てindexesで定義し直した。 （ここまで書いて1.7の頃はデフォルトでdynamicがtrueだったってことか？と思った…）

typeがstringのものを、textまたはkeywordに変更

string型が非推奨になっており、textまたはkeywordを指定する必要がある。textはanalyzed, keywordだとnot_analyzedという感じで使い分ける模様。keywordはメールアドレスやタグ等のような文字列に使うそうな。また、ソートに使う項目の場合はtypeはkeywordにしなければならないので注意！

www.elastic.co

indexオプションの引数をbooleanに変更

Elasticsearch1.7の頃は、indexesのindexオプションは、

• analyzed
• not_analyzed
• no

の3種類があったのだけれど、これらについてWaningが出ていた。 indexオプションはbooleanを渡すようになった模様。

www.elastic.co

ただし、index: falseを指定すると、そのフィールドは検索クエリで使えないので、基本的にはtrueにするといいと思う。なお、このオプションは省略しても検索対象になったので、デフォルトでindex: trueの模様。検索対象にしたくない場合のみ、index: falseを指定するのがよさそう。

Before(Elasticsearch 1.7)

mapping dynamic: false do
  indexes :start_date, type: 'date', index: :not_analyzed
end

After(Elasticsearch 5.1.2)

mapping dynamic: false do
  indexes :start_date, type: 'date', index: true
end

関連データの指定方法の変更

リレーションデータも検索対象とする際に、同様にindexesにマッピングしていたのだけれど、オプションを追加しないと動かなかった。 typeにnestedを指定すると、1対多を表現できるようになる模様。省略すると、typeがobjectとなり、1対1になるみたいだった。 また、include_in_rootを指定しないと、検索クエリを生成する際にnested用のクエリを作らないといけなくて、大変なので入れておいたら楽だった。

include_in_rootを指定したほうがいい場合と、しないほうがいい場合のメリット・デメリットがわかっていないのだけれど、私がクエリを書く分には、メリットしかなかった（クエリで"foos.name"と書けるようになった）。 デメリットがある場合は教えてほしい…。

Before(Elasticsearch 1.7)

mapping dynamic: false do
  indexes :foos do
    indexes :name, type: 'string', index: :analyzed, analyzer: :ngram_analyzer
  end
end

After(Elasticsearch 5.1.2)

mapping dynamic: false do
  indexes :foos, type: 'nested', include_in_root: true do
    indexes :name, type: 'string', index: :true, analyzer: :ngram_analyzer
  end
end

Elasticsearchのクエリの修正

クエリに関しても、なくなったオプションや、指定方法の変更などが発生していたので、覚えている限り書いておく。

FilterからQueryに統一

一番大きな変更だったと思うのだが、Filterが使えなくなっていた。Queryの中で処理するということになったので、全てQuery内で処理するようにした。ただし、これだと検索結果のスコアに影響を与えるため（filterはスコアには影響を与えなかった）、場合によってはこれだけではダメかもしれない。

Before(Elasticsearch 1.7)

definition = Elasticsearch::DSL::Search::Search.new
definition.query do
  filtered do
    filter do
      bool do
        must do
          range :start_date do
            gte start_date_gteq
            lte start_date_letq
          end
        end
      end
    end
  end
end

After(Elasticsearch 5.1.2)

definition = Elasticsearch::DSL::Search::Search.new
definition.query do
  bool do
    must do
      range :start_date do
        gte start_date_gteq
        lte start_date_letq
      end
    end
  end
end

termsのexecutionオプションの廃止

termsはデフォルトでor条件になるのですが、execlution: :andと指定するとand条件に変更できた。しかし、これがなくなっていた。これに関しては、どうすればいいんだーとtwitterで呟いていたら、Elastic社の@johtaniさんにtwitterでアドバイスをしていただけた。

多分、boolとtermをfilterのところに書く感じかなぁと。参考はこの辺ですかねぇ？https://t.co/K2YkiqJTTW

— Jun Ohtani (@johtani) 2017年8月31日

ということで、termを複数指定するしかなさそうだった。

Before(Elasticsearch 1.7)

must do
  terms bar_id: bar_ids, execution: :and
end

After(Elasticsearch 5.1.2)

bar_ids.each do |bar_id|
  must do
    term bar_id: bar_id
  end
end

Fieldのmissing指定の廃止

Elasticsearchの場合はfieldの値がない場合はそのfieldが作られないので、nullの場合みたいな条件指定ではなく、そのフィールドがない場合(missing)、という条件指定になっていた。 これが、must_notとexistsを組み合わせる形を使うように変更になっていた。

Before(Elasticsearch 1.7)

must do
  missing field: :end_date
end

After(Elasticsearch 5.1.2)

must_not do
  exists do
    field :end_date
  end
end

やったあとの感想

1.7から5.1.2に一気に上げたので、変更点も多く、思ったよりも時間がかかってしまった。とはいえ、公式ドキュメントやtwitterでのアドバイスを参考にしながらちゃんと更新できたのはよかった。ずっと気になっていたものをやり終えることができたのは素直に嬉しい。

変更が多かったが、RSpecで期待の検索結果のテストを書いていたので、安心して修正することができた。できたんだけれど、検索のテストなのでテストデータの登録が大量にあり、かつ検索条件が大量にあるせいでテストケースも多いため、テストにかなり時間がかかって、ちょっとした変更でも確認するのが大変だった。とはいえ、テストコードがなかったらもっと大変である…。テストコードの有り難さを再確認できた。

参考にしたサイト

• Elasticsearch 5.xの新機能と、1.xから5.xへのアップグレード - Tech Beans
• 【基礎編】Elasticsearchの検索クエリを使いこなそう | eureka tech blog

*1:HerokuのAddOnのSearchBoxのバージョンが5.1.2だった

*2:こちらもバージョンをSearchBoxと合わせた

幼児のドア開け閉め対策のアイテムを導入した

子供の成長を見守るのは楽しい、のですが、彼らの行動範囲が広がるにつれて、心配事もどんどん増えていきます。つかまり立ちができるようになって、ソファーによじ登って、ソファーから落ちたりとか、歩けるようになってコケて顔を畳で擦ったりとか、もうハラハラものです。その中でも、我が家で最近一番の困りごとは、「玄関へのドアの開け閉め」でした。

玄関へのドアの開け閉めであって、玄関のドアではないのですが、玄関には色々物がおいてあったり、段差があるし、ドアでの指詰めとかもありそうで…とか、なんだかんだで危険が多いのです。でもうちの子供はドアを開けるのが楽しくて仕方がないらしくて、ちょっと目を離すとドアに一直線。開けて玄関側に行っては閉めて、また開けて…と繰り返しています。これだとそれを止めるまで目が離せず、夫婦のどちらかがずっと見守っておかなければなりません。どちらかが出かけていると、ただでさえ気が抜けないのですが、本当に気が抜けず、何もできず満足するまで見守るのみになります。もし自分たちが寝ている隙にドアを開けられて、何かあったらどうしよう…という心配もあります。

また、うちの妻は関節リウマチを患っていて、幼児とはいえ、止めるために抱えたりすると腕に負荷がかかり、炎症を起こして痛そうだったので、早く改善案を考えなければなりませんでした。とはいえ、ドアに鍵をつけるのも難しいだろうしなぁ…と思って調べたら、以下のアイテムを見つけました。

“ドアモンキー” 子どもが操作できないドアロック＆ピンチガード

もうお急ぎ便で発注してしまいました。

設置

設置は簡単。モンキーの胴体側でドアを挟み込み、長い尻尾のほうをドアの向こう側に出すようにするだけです。もちろん、子供が手を伸ばしても届かないところに設置しましょう。

ドアモンキーを設置したところ

試してみる

一応、動画を撮ってYouTubeにアップしてみました。ちゃんとドアが開かなくなっています。

ドアモンキーを使ったところ

開けるときは、尻尾に近いほうのレバーを押すと、尻尾が動くので、開けられます。反対側からは、尻尾を持って動かせばいいだけです。

感想

とりあえず、メリットとデメリットを。

メリット

• 子供がどこかに行くとか怪我の心配が減る
• 親が何かできる時間が増える
• 気楽に家事ができる
• 気楽にトイレに行ける（超重要）

デメリット

• 常時、ドアが少し開きっぱなしになる
• ゆえに、エアコンとかの効きが若干悪くなる…？（あまり気にはなってない）

総括

いやもう、これもっと早く買っておけばよかったなぁ〜と思いました。子供は開け閉めできなくなって泣いてしまいましたが、今はもう普通に他の玩具で遊んだりしています。まぁ子育てしてても目を離さざるを得ない時はあるから、そういうときの心配を減らせるだけで、育児は肉体的にも精神的にも楽になりますね。

CloudGarage Release Tourに参加してきた

CloudGarageという定額クラウドサービスがリリースされており、そのリリースパーティーが9/2(土)に岡山でも開催されるということだったので、参加してきました。

cloudgarage.jp

会場は、岡山の懇親会の会場でよく使われるRyoutei 座・スタジアムです。 飲食に関しては、適度な参加人数だったのでバイキングも快適で、とてもよかったです。

CloudGarageのサービス紹介

最初にCloudGarageの責任者でもある角さんから、サービスの紹介が行われました。

CloudGarageはIaaSだけれど、他と違い定額制のクラウドサービスです。

最安料金だと、1,480円から

• CPU 1Core
• メモリ 1GB
• SSD 50GB

を3インスタンス立ち上げることができるので、1インスタンス辺り500円を切るという格安な料金です。プランは豊富にあり、BOX(インスタンス数)だけ増やしたり、ハードウェアを強力なものにしたり、そのどちらもできたりしますが、かなり安い値段設定です。

リリースして1ヶ月弱のサービスですが、すでに結構使われているそうです。

使われ方について

普通の使われ方だと、ウェブサービスの本番環境などもあります、3BOXセットという点もあるので、本番環境、開発環境、テスト環境と分けて使ったりすることがあるようです。確かにこういうのは同時に契約していく必要があるので、最初からその分の環境を立ち上げられるだけBOXがあると便利だと思います。

また、BOXの価格がお安いので、エンジニアが好き勝手に実験していい環境として1人1BOX与えるという福利厚生として利用されているという例もあるそうです。「レンタルサーバを借りるとお金がかかるしなー」と思って躊躇してしまうエンジニアは多いと思うので、こういう福利厚生あるといいですね！！（欲しい）

テンプレートもある

IaaSといっても、利用パターンがある程度決まっているからということでしょうか。WordPressやRedMineなどの有名OSSのテンプレートが最初からあるようでした。それを使うと環境構築の手間がある程度省けるからよさそうです。この辺りは、他にもどういうテンプレートがあったら便利か知りたいと言われていたので、リクエストを出したら対応してくださるそうです（たぶん）。

CloudGarage x Rancher でスピード開発！（新藤さん）

ゲストセッションで、Rancher Labs社の新藤さんの発表がありました。Rancherについて、私は事前知識も全くない状態だったので、とてもためになりました。 Rancherの意味は牧場で、牧場にコンテナを飼うような感じで、コンテナの管理をGUI化できるというものでした。 Rancher自体はCloudGarage以外のクラウドサービスでもコンテナを管理できるのですが、CloudGarageはRancher OSを使うことができるので、Rancherを使ってみるのに最適だし価格も安いから相性抜群ということでした。

Docker Imageをカタログ化できる

お話を聞いていて面白そうだったのは、ファイルに設定を書いておいたら、Docker Imageをカタログ化できるので、ポチポチ押していくと環境が作れるというところでした。カタログ化しておけば使いまわせるだろうし、GUI上で色々なミドルウェアを組み合わせられそうだし、いいなぁと思いました。

LT

LTも面白かったです。ロードバランシング機能の検証実験とか、GitBucketを立ててみたとか、BSD系のOS入れてみたとか、WordPress立ててみたとか、Mackerel（マカレル）の話（宣伝？）とか。

ロードバランシングも3パターンの設定ができるのですが、それら全てちゃんと動いていて、現場では「おおー」という声が。スタッフの方々はちゃんと動いてよかったという安堵の声が。

締めの挨拶

プレゼント企画などもあり、一通り盛り上がったあと、スタッフの中村さんの挨拶。 「岡山という地でぜひともツアーをしないといけないと思っていた」と言うだけあって、熱のこもった挨拶でした。 印象的だったのは、「売りに来たんじゃない。会いに来たんだ。」というメッセージで、この言葉が今回のリリースパーティを表していました。とてもいいリリースパーティーで、参加してよかったなと思いましたし、CloudGarage使ってみたい！と思いました。

オマケ

twitterのまとめがあるのでリンクしときます。

CloudGarage Release Tour in Okayama まとめ #CloudGarage - Togetterまとめ

システム化は無機質な管理ではなく人間性を尊重した管理が可能になる

バックオフィス系の運用の効率化を行う際に、結局使われないとか、開発側の独りよがりになったりしないためにはどうすればいいかを知りたくて読んでみた。実はずいぶん間から家に置いてたし、何回か読んでたんだけれど、再度読んでみた。

事務の「見える化」が会社を救う

日本人は「捨てる技術」が身についていない

筆者は国内と海外の銀行に勤めていた経験があり、日本と海外のシステム設計の違いを教えてくれた。

• 日本のシステムは、1つのものを流用して全てに対応しようとする。あれもこれもと詰め込む。結果、網羅的なテストが必要となる。組み合わせ爆発が起きやすい。
• 海外のシステムは、複雑な箇所用のシステムを新たに作る。結果、影響がシステム毎の範囲で済むため、必要最小限のテストでよい。

日本のシステムは、旧来のシステムを捨てることができずに延命に延命を続けるため、システムを刷新したくても肥大になりすぎていて手がつけられないということもよくあるらしい。このあたりはなんとなく感覚的にそうだなぁ〜と実感した。

効率化・システム化の落とし穴

効率化やシステム化は、自然と抵抗勢力が生まれてしまい、なかなか上手くいかないと思うので、そこをどう乗り切るのか？という点を本を読むときの質問として考えていた。そこを注意深く読んでいくと、発見が多かった。

効率化は顧客目線でプロセスチェックすることが重要

独りよがりの効率化になると、顧客を置いてけぼりにしてしまい、顧客満足度が下がり、顧客が離れていってしまう。お問い合わせ窓口などの効率化を目指した場合によくハマるものだという。自動応答システムなどを導入して、たらい回しにされているような感じになったり、なかなか繋がらなくてイライラしたりなどだ。また、事務のミスというのは、「ないのが当たり前」というふうに思われているので、少しのミスであっても顧客への信用は一気に落ちてしまう。

効率化・省力化を目指すにしても、顧客を失っては元も子もない。信頼を失わないプロセスを構築しなければならない。

効率化は「○○の神様」によって阻まれる

例えば、経理の神様とか、事務の神様など、属人性が高くなってその人しか処理できない業務がある場合など。なぜ阻まれるかというと、効率化によって、その人自身が不要になるのではないか？という怖れからだったりする。そのため、一般的な顧客分の処理を行うシステムを作ると、重箱の角をつついて、ダメだししてくる。ここで、前に書いていた「1つのものを流用して全てに対応させようとする」という、よかれと思ってのダメ出しによって阻まれるそうである。

その意見に耳を傾けすぎると、いつまでたっても完成しないか、業務フローが複雑になりすぎてコスト高になってしまう。そのため、そういう神様たちの居場所を作ってあげる必要がある。

99%の顧客が満足するメインストリームを作る

例外は、1%程度だろうという想定で、99%の人が満足するメインストリームを完成させる。システム側でその1%に対応するように頑張るとコストがかさむので、やらない。1%は別の方法で対処したほうが安上がりである。なによりメインストリームの速度を落とさないことを重視する。

メインストリームを作るに当たって、事務のプロセスを見える化する必要がある。見えないものは管理できないからである。本線だけを明確に作り、例外は全て本線から退避させる（これが1%）。では、退避させた1%はどうするのか？そこに、事務の神様を置く。そもそもその1%は神様しか処理できないものばかりなので、エキスパートに任せたほうがいい。

また、時間が経過していくとその1%の中でも傾向が見えてくるものがあるので、それをまたシステム化できるか検討、というサイクルを回す。

改革の肝は人

人の気持ちを無視して仕組みを真似ただけでは上手くいかなかったり、定着しない。最終的には人次第。

システム化によって働きやすい組織に

システム化されたことで、個人的なスケジュールの見える化が行われるようになったという。 保育園の送り迎えなどがある人などは、先にそれをシステムに登録しておくと、時間になりそうだったら表示され、マネージャーもそれを把握しているので無理な仕事の割り振りは行わないようになる。

また、時間単位で作業量を計測しているため、時間によって効率が落ちてくる場合は、その時間帯は気分転換に違う仕事を割り振ったり、もともと苦手そうな場合は異なる仕事をふったりなど、もっとも得意なことが何なのかを探れるようになった。わざわざ苦行を行わなくても、得意なことで気分良く働いてもらえるようになる。

システム化することによって働きやすい職場になるよう、人間性を尊重したシステム作りに力を注いだという。

キャリアパスを作ってあげる

事務仕事といってもメインストリームの仕事だけでなく、例外的な仕事も処理できるようになっていく必要があるので、認定制度を作り、自分はどれだけの仕事ができるようになった、どれくらいの立場で動けるようになったなどをわかるように、またモチベーションを高く保てるようにキャリアパスを作ってあげることも大事であるそうだ。

同じ組織で働き続けていると感じるのが、この漠然とした「このままでいいのか」という不安だと思う。ステップアップしているのだという認識と、周囲への認知は大事だと思う。

徹底した教育、社会人としてのルールを教え込む

著者の会社では、半日の研修後にすぐ実戦投入できるところまで仕事が分解されているらしい。なので、いろんな経歴や国籍の方が非正規として雇われて働くらしいのだけれど、そこで大事なのが、どれほど大事な仕事をしているかという認識と、ルールとマナーの徹底であるらしい。

特に、アルバイトで来る人は、アルバイトを渡り歩いてきていて、ルールやマナーの研修などを受けたことがない人も多いらしい。ルールやマナーを教え込むというと、なんだか社畜にしようとしているのでは？というふうに思うかもしれないが、そうではなく、どこにいっても通用するように、ということらしい。もちろん教えていないと仕事がスムーズにいかないからというのもあるんだろうけれど、そこにコストをかけてアルバイトをちゃんと教育するのも、肝は人であるということをわかっているからなのだろうと思う。

マニュアルが絶対！

「よかれと思っての改善が事故を招く」という例が書かれていて、めちゃくちゃありそうだなぁと思った。マニュアルが守られずに独自ルールを採用していくと、マニュアルが形骸化してしまい、誰も見なくなるし、新しく雇った人の教育が大変になる。マニュアルの更新は熱意と根気でやっていくしかないということだった。ただ、マニュアルに手順だけを書くのではなく、何故こう書いてあるのか、というプロセスも学んでもらわないといけない。腑に落ちないから勝手に改善しようとしたりするのだろう。

段取りを考える習慣を教え込む

これはものすごく大事だと個人的に思う。スケジュールだけ考えさせると、それっぽいものは出てくるけれど、じゃあそれをどう実現させていくのか、という段取りにまで落とし込まないと、物事がスムーズに進まずスケジュールがガタガタになったり、無理なスケジュールを守ろうとしてミスや事故を起こしてしまう。段取り力こそが、仕事のできる、できないを左右するものではないかと日頃から感じている。

レポートラインを守る

レポートラインってなんだろう？と思っていたのだが、自分の上司との指揮系統のことだった。レポートラインを守るとは、どういうことかというと、仕事をしていると突発的に自分の上司以外から頼まれ事が発生したりすることがあるかと思うが、例えその頼み事をしてきた人が偉かろうと、自分の上司以外の命令には従わないということだ。それを許してしまうと、指揮系統の規律が乱れてしまう。仕事の速度も変わってしまう。マネージャーの知らないところでそんなことが発生してはいけない。マネージャーのところで調整するなどのプロセスを経る必要がある。

システム化にあたって

システム化に取り組む際、いいシステムはみんなの意見を取り入れては作れない。衆愚政治のようになってしまう。 ワンマンだとスピードが出るし、責任感を持って取り込むことができる。周囲からは文句が出るかもしれないけれど、進まないよりはずっといい。

気づき

やはり人が肝である。日本的なシステムもいい部分はあるんだろうけれど、モリモリになって完成しないとか、本当によくある。バックオフィスの効率化に関するハマリどころについて、知りたいことが書いてあったのでよかった。特に抵抗勢力になってしまう人たちに活躍してもらうところはよかった。ここには書いていないが、本の中でよく登場する銀行のシステムの話などもとても面白かった。

フォトリーディング速読勉強法を読んだ

こちらも図書館で借りてきた本。フォトリーディングを勉強にどう活かすのか、他の人はどういうふうにしているのかが知りたくて借りてみた。

超一流の人がやっているフォトリーディング速読勉強法

フォトリーディングのやり方を図解入りで説明

最初はフォトリーディングのおさらいのような内容だった。

1. 本を読む目的を決める
2. みかん集中法を行う
3. 予習を行う（目次を読むなど）
4. 開始のアファメーション
5. フォトリーディング
6. 終わりのアファメーション
7. キーワード探し（20個くらい）・質問作り
8. スキタリング・ディッピング・高速リーディング
9. マインドマップを作る

ここで、不安になりそうなことがQ&A形式で書かれていた。そんなに質問が出てこないとか、キーワードが抽出できないとか、逆に多すぎるとか、読書スピードが上がらないとかやり方があっているか不安とか。私も独学でやっているのでこのあたりの不安要素は結構似たようなことを思ったことがあったので参考になった。

質問を作るとか特に速読を要求しないエモーショナルリーディングの本でもそう書かれていた。著者に聞きたいことがあることで、ポジティブな気持ちでの読書になり、記憶に残りやすいのだと思うので、このあたりは重要ポイントなんだろうと思う。

本の中盤では、マインドマップの書き方についても説明があった。これも図解入りでわかりやすい。

資格取得にフォトリーディングを活用した例

後半は、フォトリーディングとマインドマップをどう資格取得に活かしたかというのを、実名入りで紹介されてた。若干宗教じみた感じでのフォトリーディングの紹介の仕方になってる感じの例もあって、うーん？と思うものもあったが、わりかし納得できる話も多かった。特に、どういうふうにフォトリーディングとマインドマップを用いたかという実例は参考になった。参考書と問題集をフォトリーディングしてから問題を解いて、解説を高速リーディングするとか、マインドマップは作るのに時間がかかるから、自分が苦手に思う分野だけに絞って作成したとか。

生真面目にやらず、自分の使いやすいようにアレンジしたらいいという言葉には、ちょっとホッとした。ルールに縛られてしまう気質なので、あの順番で作業してマインドマップも逐一作らないといかんのかなとか、考えすぎてしまうところがあったので、覚えにくいところだけ作るとかでもいいんやなぁ〜とか。

蛍光ペンを使う派？使わない派？

例では、蛍光ペンをよく活用していて、問題の肝の部分と回答の部分で色を決めておいて、対でマーカーを引くことにより、Aの場合はB、Bの場合はAという感じで紐付けが行えて、それを復習のリーディングのときに簡単に確認できるようにしたことで覚えやすくなった、という話があった。 この、「本にペンで線を引く」というやつは読書術ではよく話題になっていて、

• 線を引いたら読んだつもりになってしまうのでNG
• 線を引いたら重要ポイントをすぐ確認できるからOK

という派がある。どちらの意見もわからなくもないのだが、私は今は前者側の姿勢なのだが、資格取得の例では後者の意見だったので、何度も見返す問題集とかだったらもしかしたら有効なのかもしれないと思った。

気づき

人がどういう感じでフォトリーディングを活かしているかを知る機会はなかなかないので、実例が紹介されているのは参考になった。 その中で、「フォトリーディングはちゃんと本を読まなくてもいいということに気付かさせてくれた」と書かれていた。流し読みでもいいんだ、と。普段twitterとか適当に見ているのに、本になるとそれができなくなったりするから、もっと気軽に、楽しんで本を読んでもいいんだなぁとことに改めて気づいた。読書はリラックスして楽しもう。そろそろ資格の勉強もしたい。

エモーショナルリーディングのすすめを読んだ

一冊からもっと学べる　エモーショナル・リーディングのすすめ

こちらの本も図書館で借りてきた。多くの気付きがあったので良書だった。 最近自分が罠にハマっていたところが指摘されていたので、意識を変えさせてくれた。どういうところかというと、速読はあくまで手段であるという点だ。

できる人は速読をしない

「できる人は速読をしない。むしろ精読して、しっかり知識を吸収している。基本的な知識が備わった結果、理解力が上がって、本を速く読めるようになっている」という説明があったのだが、そりゃそうだよなーと納得した。速読は結果論なんだなぁと思う。

フォトリーディング系の速読が悪いとは思わないし、むしろ一度やっておくと全体的に読む速度が上がるという実感はあるので、否定はしない。だが、この本を読んだことで、読書法にこだわってしまうよりも気楽に読書を楽しむほうがいいなぁと思わせてくれた。

著者はブックナビゲーターをされている方なので、お仕事上、本を読まないといけないこともあるそう。あんまり興味のない本にあたったりすることもあるので、「どうやって興味を持つか？」という点にフォーカスしたところがあって面白かった（そういう内容ばかりではないのであしからず）。

本の読み方、どういうところから学べるかを抽出した一冊

著者のいう、一言で紹介でいうと、こんな感じ。

読書は本の著者との対話と位置づけ、対話しながら、感想に感情を絡めていくと記憶にも残りやすいという話だった。自分的には、記憶に残るというか、発見が多いなと思った。もっと主観的に学べるところを探しながら読んでいくと、実りある読書になると気づかされた。

その上で、アウトプットするときのノウハウをたくさん披露されていた。一言で紹介も、そのノウハウの1つ。知人に紹介するとしたらどう説明するかとか、こういう人にはこう紹介してみたらどうか？というパターン集などなど。

感情のパターン

感情のパターンが載っていたので、参考にするためにリストにしておく。

1. 驚き
   • 未知・発見
   • 敬服
   • 体感
2. 好奇心
   • 疑問・質問
   • 期待感
3. 笑い
   • 口調・文章
   • エピソード
   • テーマ・コンセプト
4. 喜び
   • 勇気
   • お得感
   • 共感
   • 爽快感
5. 恐れ
   • 危機感
   • 不安
6. 怒り
   • 反論
   • 正義感
   • 発奮
7. 嫌悪
   • 不信感
   • 拒絶
8. 感銘
   • 座右の銘

気づき

読書・著者との対話をもっと楽しもう、という気持ちにさせてくれた。知らず知らず、多読ノルマ化みたいにして、「もっと読書しなければ！」と思い込んでいた。本を読んでも、学びが少なければ意味が薄い。学びのある読書の取り組み方の視点を気づかせてくれたこの本は一読の価値があると思う。もっと気楽な気持ちで読んでいこうと思う。

記憶に残る速読を読んだ

最近は図書館に行ってプログラミングの本を借りていたのだけれど、なかなか実践できずに本を返してしまうことが多かったので、サクッと読める本だけを借りることにしようと方向転換して、本の読み方や勉強の仕方の本を借りるようにした。

記憶に残る速読 あなたの脳力はまだ眠っている

速読や多読が目的と化してしまい、結局記憶に残っていなかったり、行動に移していなかったりしなかったら意味がないということに気づかせてくれた。面白かったのが、本のカバーだけ入れ替えて速読の達人に本を渡したら表紙の題名に近いような話ばかりして本の内容は読めてなかった、みたいなエピソードだった。これは笑える。似非の速読なんだろう。

本を読みきることが目的になっている場合は、理解ができてなくても読み進めてしまうことがある。重要なのは、本から学ぶことであって、本を読みきることではないというのに。読書が中断すると、短期記憶を忘れてしまうことがあるから、読書を再開するときは2〜3ページ前に戻って読み直すと記憶に定着しやすくなるらしい。面倒臭がって「よくわからないけれどまぁ読み進めよう」という姿勢はよくない。何度でも戻って読み進めるほうがよさそうだ。

読書中の音読はあってもいい

本を読んでいると、本の内容が頭の中で音読される人と、そうでない人がいるという話があった。私も本を読んでいるときは音読されるのだが、この音読があるとそのスピードの影響を受けて読書スピードが上がらないという説がある。なので、どうしたら音読がなくなるのか？ということを気にしていたのだが、この本の中では、映像のように本を読むほうが、映画を見るようなものだからその速度に縛られてむしろ音読よりも遅いというふうに書いてあった。これはなんだかホッとした。音読の速度を上げていくほうが、自分にはあってそうだ。

読書速度は多読の結果で速くなってくるという説明と、自分で音読したものを録音して、徐々に再生速度を上げていくと頭の中で読む音読のスピードが上がって本を読むスピードもあがるというトレーニング法の説明があった。速聴によって理解できるメッセージ量を増やすというのは理にかなっていると思うので、効果がありそう。

本を何冊読んだかよりも、本から何を学んだかが重要であるという点はちょっと頭の中から抜け落ちていたので、そりゃあそうだよなぁ〜と考えさせられた。目的と手段が逆になってはいけない。

気づき

冊数よりも、何を学んだかと、本の内容を実践して得られる経験値にもっとフォーカスを当てて、読書を楽しんでいこう。