読者です 読者をやめる 読者になる 読者になる

今日学んだこと

読書感想文とか、勉強した内容とか

「ハッカーと画家」から何を学ぶか

読書感想文

世の中には2種類の人間がいる。

名著と呼ばれるものを読んで「ふーん」で終わる人間か、もしくはそこから何かを学び取ることができる人間だ。

僕は残念ながら前者である。

世の中には「ハッカーと画家」という名の名著がある。嬉しいことに日本語に訳され出版されている。

僕は数年前に読んだが、内容をほとんど覚えていなかった。Lisp讃歌な本だったという認識がうっすらあるだけだ。

世の中では名著とされており、少なくない頻度でTwitterやブログなどで読んだ感想や引用を見かける。

が、僕も読んだにもかかわらず内容をほとんど思い出せない。

今、本棚を整理するなんていうことをやっているんだけど、その中で改めて表紙と向き合ってみても内容を思い出せない。画家ってどういう意味だっけ? と。

そんな感じで、長いイントロになってしまったけど、また読み直してみたというお話です。

本の内容を3行でまとめると

  • オタク/ハッカーって凄いんだぜ
  • 色々なことに対して思考実験してみよう
  • Lisp最高

となるのかな、と思ってる。

エンジニア界隈で名著とされている本書だけど、コレを読んだからといって何か技術がつくだとか、そういう類の本ではない。技術書ではなくエッセイ集だ。

僕は読み物としてしか読めず、僕の力不足というか想像力不足のせいで、世の評判ほどこの本から何かを得ることはできなかった。

Amazonのレビューを覗いてみても

刺激的な内容だけに自分はどう考えるか、何をしたいかを考えざるを得なくなります。知らず知らずのうちに常識に埋もれて停止していた頭の中の歯車が回りだすような感覚です。

という人もいれば

著者の経験と主観的な主張が延々と述べられているに過ぎず、単なるエッセーである。論旨に客観性もなければ斬新な学びも無く、ここでの高評価の意味がわからない

と受け取った人もいる。僕はこの例のどちらほどにも極端ではなく、「読んでいて面白かった」という身も蓋もない中間的な評価だったりする。

僕はこの本から何を学んだか

そんな僕でも学びがなかったわけではない。3つほど挙げてみる。

何を言うにしても成功してなんぼ

3行まとめで「オタク/ハッカーって凄いんだぜ」とした部分について。

「学校ってクソだよね」とか「企業ってクソだよね」という論調の話が多い。そして、そういういわゆる「枠組み」がオタク/ハッカーを滅入らせるんだ という話だ。

僕が日本人だからそう思うのかもしれないが、何も成してない人が、たとえば「頭でっかちの上司(この本では"スーツ"という言葉を使っている)がクソで仕事にならないよ」と長々と述べたところで「人のせいにしてないで仕事しろよ」となると思う。

「気に食わないことの上を行った上で」懐古としてクソだよねと述べたり、「気に食わないことを打破しようとしている最中に」ぶっ潰すという意気込みとしてクソだよねと述べるのであれば共感を呼べる(この本は前者(懐古)だ)。

つまり、何かを批判する時は、成功してなんぼなのだと思っている。

僕も、特に仕事で気に食わないことが沢山ある。のちに、負け惜しみじゃない文句を言えるようになる日は来るのだろうか。そんなことを思いながら読み進めた。

思考を言葉にするのは難しいけど不可能ではない

3行まとめで「色々なことに対して思考実験してみよう」とした部分について。

たとえば「富とは何か」「世の中のタブーとされているものについて」といったものに対して著者なりの考察が書かれている。

こういったとりとめもないお題について、頭の中でぐるぐるさせることは、現代の人ならよくあることだと思う。僕の場合だと「理想の会社とは」とは「人口減少を食い止めるには」とか。

ただ、こういった思考はとりとめなくされるもので、たとえばそれを文章にまとめるとかになると途端に難しくなる。

それを、この著者はうまくやってのけていて(そして、著者の説が妥当に思える様な論調で)、なるほどこういうのを文章にすることも不可能ではないのか と感心させられた。

言語を愛してるエンジニアは強い

3行まとめで「Lisp最高」とした部分について。

経験則でもあるんだけど、世の凄腕エンジニアな人は、特定の言語に愛を持っていることが多いと思っている。逆に、「言語なんて何でも良いよ」なんて言う人は、稀に例外もあるが凡な人が多いとも思ってる。

似た様なことがエディタにも言えると思ってて、つまり自分の道具に愛を持っている人は強い/強くなる と思ってる。

そういう推測をこの本は補強してくれる。

この本の半分はLisp(の中でも著者はCommon Lispを好んでる)という言語の讃歌だ。そして、この本の著者は、少なくとも成功しているエンジニアだ(なお、現在はYコンビネータの代表をしていて、エンジニアというよりは実業家というような立ち位置だ)。

Lispって言語いいよね という捉え方もできるが、「僕も彼の様に、自分の道具を愛せているだろうか?」と自問しながら読み進めていった。

僕はこの本を人に勧めるか?

勧めるか否かを結論で言えば、勧める。

何故かというと、僕は「エンジニアの間で名著とされている本は、合う合わない考えずに読んでおいたほうがいい」と思っているからだ。

エンジニアが読む様な本というのは、知識を深めるという側面と、他の人と同じ情報/文脈を共有するという側面があると思っている。

議論のベースになることもあれば、相手が読んでいる前提で引用されることもある(「妊婦増やしたところで子供が早く生まれる訳ないのにね」「銀の弾丸なんてないのにね」といった人月の神話を基にした言葉を言われた/言ったことは一度はあるんじゃないだろうか)。

しかし、そういった名著にだって、人によって合う/合わないは当然ある。

僕は、この本は合わなくはなかったが、合ってるとも言い難かった。もちろん、絶賛している人は沢山いる。

合う合わないはあるにせよ、少なくとも小難しくて体力がいる様な本ではない。気軽に読める本である。

もし、まだ読んだことがなければ、この本から何を学べるか、ぜひ気軽に読んでもらえたらと思ってる。

読み終わった後に「Lispは良いぞ」と言ってくれることを願いつつ。

今更ながらGTDに再入門してみる:GTD原典を読み返したまとめ

読書感想文 GTD

仕事で帰れない日が続いていた昨今ですが(ブログの更新が無かった言い訳)、先々週から一ヶ月ほどの夏休みを頂いています。

独身社会人の夏休み

さて、夏休みも2週間が過ぎたのですが、何をやっていたかと言うと・・・

  • 大掃除
  • GTA5(Save 33% on Grand Theft Auto V on Steam)
    • GTA4があまり楽しめなかった僕ですが、5はものすごく面白かったです。今、英語字幕にして2週目やってます
  • 富士登山(こちらは別途記事にしようかなと)
  • 積ん読消化
  • 多くの時間を何もせずぼーっと・・・

といった感じで、あまり有意義なことができていません。

特に旅行といった予定も入れておらず、「今日は何をしようかなー」と考えて、結局何もせず終わりな日々でした。

で、そんな日々を振り返ってみて、「ちょっとマズイぞ」と。

もう少し、時間を有意義に使わねばと焦り始めたはいいものの、どうやって時間を有意義に使えば良いかわからない。なんとなくやりたいなということはたくさんあるけど、なんとなく思ってるだけでは結局だらだらしてしまうのは目に見えてる。

人間の悩みなんちゅうのはいつの時代も同じや。そんで本ちゅうのは、これまで地球で生きてきた何億、何十億ちゅう数の人間の悩みを解決するためにずっと昔から作られてきてんねんで。その『本』でも解決できへん悩みちゅうのは何なん?自分の悩みは地球初の、新種の悩みなん?自分は悩みのガラパゴス諸島なん?

上記は、「夢をかなえるゾウ2」の一節です。

夢をかなえるゾウ2 文庫版

夢をかなえるゾウ2 文庫版

どうやってやるべきことを整理するか。自分にマッチした方法を考えるというのも悪くはないですが、僕みたいな凡人は、もっと賢い人が真剣に悩んで考え出した方法にまずは従ってみる方が確実に良い成果が出せるはずです。

ということで、10年ほど前に一世を風靡したGTDに関する以下三文献を再読し、自分の理解及び気づきをまとめてみようかと思います。(本当は全部について本記事にまとめようと思いましたが、最初の本だけで1.4万文字とかになってしまったので、残り2つはまた別の記事で)

はじめてのGTD ストレスフリーの整理術

はじめてのGTD ストレスフリーの整理術

ひとつ上のGTD ストレスフリーの整理術 実践編――仕事というゲームと人生というビジネスに勝利する方法

ひとつ上のGTD ストレスフリーの整理術 実践編――仕事というゲームと人生というビジネスに勝利する方法

ストレスフリーの仕事術―仕事と人生をコントロールする52の法則

ストレスフリーの仕事術―仕事と人生をコントロールする52の法則

なお、GTDに関しては、ネットを漁ればわかりやすくまとまった情報がいくらでも出てきます。また、GTDの概要は、すでに頭に入ってます。そして何度も試しています。
が、自分に定着していない。また、GTDを今でも回していて(回せていて)うまくいっているという人は少なくとも僕の周りにはいません。

そんな悲しい現実に対して、GTDがダメだと考えるのではなく、「ちゃんと理解できていないのではないか」、「ちゃんと正しいプロセスを踏めていないのではないか」と疑い、再度ちゃんと本と向き合い、内容を咀嚼した上で再度チャレンジしてみよう、再入門してみようという企画です。

そんなわけで、以下再読した読書感想文もとい読書メモです。

読書感想文もとい読書メモ

いわゆるGTDの原典とされている本です。

はじめてのGTD ストレスフリーの整理術

はじめてのGTD ストレスフリーの整理術

はじめに - さあ、GTDを始めよう!

すでに読んだことがある本の再読なので、こういったイントロダクションは読み飛ばしても良いのですが、あらためて読み直すと発見があります。

あなたが日頃やっていることは、ふたつに分けることができる。ひとつは、興味があったり重要だったり、何かの役に立ったりすることだ。もうひとつは、やりたくはないがやらなければならないことである。前者の場合は、費やした時間とエネルギーに応じた成果をあげたいと思うだろう。後者については、さっさと片付けてほかのことをしたいと思うにちがい無い。

僕のタスク管理の失敗の原因として多くを占めるのが、後者をずっと後回しにし破綻するという有りがちな失敗。GTDでいうと、タスクとして管理はされ、週次レビューもされるのだが、タスクを見るたびに嫌な気分になりつつ当該タスクが実行に移されることは無い という状況である。

さっさと片付けてほかのことをしたい。恥ずかしながらそういう考え方はできてなかったし、「やりたく無いことはずっとやらないでいたい」が基本方針な様なところがあったので、そこは心持ちを変えていきたいなと思った次第です。

第1章 仕事が変わった。さて、あなたの仕事のやり方は?

私が提唱するGTDの柱はふたつある。ひとつは、やるべきことを"すべて"把握しておくということだ。今やらないといけないこと、あとでやること、いつかやる必要があること……大きなことも小さなことも、すべてを頭の中からいったん吐き出し、信頼できるシステムに預けることだ。当たり前のように聞こえるかもしれないが、ほとんどの人はこれができていない(「あなたのやりたいことを今ここですべて見せてください」と言ったら、あなたは見せることができるだろうか)。柱のふたつ目は、人生において常に降りかかってくるあらゆる"インプット"にその場で対処できるようにすることだ。それらが発生したときにどう判断を下し、どういった"次にとるべき行動"を見極めるべきか。これも常識に思えるかもしれないが、ほとんどの人にはそうした習慣がない。そしてその習慣がないがゆえに、日々降りかかってくる「やるべきこと」に振り回され、「あれもしなくちゃ」「これもしなくちゃ」という焦りだけが頭の中で空回りしつづけることになる。

ひとつめについての僕の理解は、曲解かもしれないけど「本を読んでるときにふと何かきになることが思い浮かんで集中できなくなる。そんな時にしかるべきにリストに放り込んでおけば目の前の読書にまたすぐ集中できるよね」といった感じである。

ふたつめについては、いまの僕そのままで「やらなきゃいけないことは色々あるけど、どれも気が乗らないなぁ」と思っているといつの間にかその日が終わっているという状況は宜しく無いよね という理解している。

やるべきことをうまく管理するためのポイントは次のようなものだ。

  1. 「やるべきこと」が頭の中に居座っていると、心が澄みきった状態を作り出すことはできない。終わっていないと感じているすべてのことを、頭の外の信頼できるシステムに預ける必要がある。そのうえで、定期的にそれらを見直す必要がある。
  2. 「やるべきこと」に対してあなたが本当にしたいのはなんなのかをよく考え、それを終わらせるために何をしなければならないかを見極めなくてはならない。
  3. 「やるべきこと」に対してとるべき行動がすべて明らかになったら、それらを思い出す手がかりとなるリマインダーを信頼できるシステムに登録し、定期的にレビューしなくてはならない。

僕がタスク管理に失敗する原因として、2を蔑ろにしているしてるという点があると思う。「それを終わらせるために何をしなければならないか」、これを明らかにする作業は割と苦痛を伴うことがある。なぜなら、「英語ができるようになりたい」を考えるのは楽しいけど「英語をできる様にするために、何をしなければならないか(単語集やるとか)」は、全くもって楽しくなかったりする。

あくまでも、結果が欲しいわけで、その過程は考えるとうんざりする というのは僕だけでは無いと思う。

しかし、結果を手に入れるのであれば過程は経る必要があるのは明らかであり、そこはもう腹をくくるしか無い部分だと思っている。

過程を無視して、できる自分を夢想するのは楽しい。ただしそれでは何も変わらない。

第2章 生活をコントロールする

この章では、GTDのプロセスについて概要を説明している。いわゆる有名な例の図のフローについて、それぞれの要素についての概要を説明している。

f:id:nakazye:20160802151630j:plain

以降の章でそれぞれの要素について詳細な説明があるので読み飛ばしがちだが、見逃しがちな重要なことが書いてある。

多くの人が整理術で失敗するのは、これらのステップをいっぺんに終わらせようとするからである。時間がないので、ほとんどの人はリストを作るときに、「もっとも重要そうなこと」の収集にとどめ、具体的な行動については考えることをあまりしない。

要は、ちゃんと各ステップを確実に、提示した順番でやっていけよ と。

GTDって、簡潔な説明がネット上に多く出回ってますよね。で、上の図にある説明をざっと見て、理解した気になっちゃう。そうじゃなくて、ちゃんと意味があって、考えに考えた上でのステップになってるから、ちゃんと遵守しましょうね と。

第3章 創造的にプロジェクトを進めるために

本章では「気になること」を「次にとるべき具体的な行動」に落とし込むためのコツを"ナチュラル・プランニングモデル"という言葉で説明している。

具体的には

  1. 目的と価値観を見極める。
  2. 結果をイメージする。
  3. ブレインストーミングをする。
  4. 思考を整理する。
  5. 次にとるべき行動を判断する。

としている。1と2、そして5はイメージが沸きやすいが、3と4が説明無しだとイメージが沸きづらい。

これは、

望んでいることと現在の状況の間にギャップがあることを認識し、そのギャップを埋めるための手段を自動的に模索しはじめる。ただし、このときの脳は、かなり自由にさまざまなことを思い浮かべている。 そこで、次のステップが必要になる。十分な数のアイデアや具体的な可能性が浮かんできたら、それらを「整理」するのだ。

として、説明されている。

いきなり、「これについて何かいいアイデアがあるかな?」と先走るのではなく、GTDを進めていく中でも頭を使ってやるべきことを落とし込んでいくべきだという主張だと僕は理解している。

第4章 さあ、はじめよう

GTDを始めるにあたっては、まとまった時間と作業ができる場所、さらに必要なツールを用意しよう。作業を行う場所は快適なところを選ぼう。そうすれば心理的な抵抗が少なくなり、作業がぐっとはかどるはずだ。一般的には、2日まるまる確保するのが理想的だ。なかなか時間がとれない人は、2日空くのを待つ必要は無い。先延ばしするくらいなら、短い時間でもやったほうがいいし、GTDの原理やテクニックの効果はそれで十分体感できる。「収集」を完全にやると、6時間以上かかる場合もある。次に「収集」したことのすべてを「処理」して「次にとるべき行動」を決定し、外部のシステムに預けるには、さらに8時間はかかるだろう。

GTDを始めるにあたっての、準備編である。ここにかかれている時間は一つの目安である。2章にて、「中途半端にいっぺんにやろうとするなよ」といった話があったが、そこにも通じると思っている。何が言いたいかというと、やはり2日は確保したほうが良いのだろう。

大量の「解決していないこと」を収集して処理するにはかなりのエネルギーがいるというだけだ。長いあいだ放置されていたり、停滞していたりするものに取り組むならなおさらだ。この作業の途中で邪魔が入ると、かかる時間が倍になることもあるので注意が必要となる。

単純に作業量が膨大という話ではなく、上記の様な説明もされている。ここはものすごく同意できる部分で、特に僕は目を背けていたいことにたいして向き合うのにものすごくエネルギーを使う。

また、上記引用で「さらに必要なツールを用意しよう」とあるが、ツールについては以下が基本ツールとして挙げられている。

一からすべてそろえるとするならば、机の上に必要なもののリストは次のような感じになるだろう。

  • 書類トレー(3段以上)
  • A4の紙
  • ペン
  • 付箋紙
  • ペーパークリップ
  • ダブルクリップ
  • ホッチキスと針
  • テープ
  • 輪ゴム
  • ラベルライター
  • ファイル、バインダー
  • カレンダー
  • ゴミ箱、リサイクルボックス

全てが必要であるかというと必ずしもそうでないと思うし、代替が効くものもあると思う。現に、僕は紙の整理についてはスキャナを使ってしまう。なので、クリップやホッチキス、書類トレーやファイルは不要となる。

第5章 収集

ここから、GTDの各ステップについて具体的な説明がはじまる。

この「収集」のプロセスは必ず完全に行わなくてはいけない。それは次のような理由による。

  1. 取り組まなければならないことの全体量を把握することができる。
  2. 何をどこまでやれば終わり、ということがわかる。
  3. まだどこかに気になることがあるかもしれないという意識があると、次に行う「処理」と「整理」に集中できなくなる。注意が必要なものがすべて1箇所にあるとわかっていれば、安心してそれらのステップを行うことができる。

と説明されている通り、まずは気になることを完全に洗い出す必要がある。

この収集のプロセスで特徴的、かつネット上のGTDの説明では省略されていることが多いこととして、いわゆるタスクだけでなく、物理的なものも対象としている点である。

最初にやるのは、実態のある身の回りのもので、あるべき場所やあるべき状態ないものを探し、inboxに入れることである。これらは未完成のものだったり、何をすべきかを判断しなければならないものだ。これらをすべてinboxに放り込み、「処理」に回せるようにしておく。

例では、郵便物、電話のメモ、名刺、引き出しの中に眠ったままになっているもの、配置を変えたい家具なども挙げられている。

たとえば、僕の場合は未読の本、内容が思い出せないが再読したいと思っている本、未視聴のDVD、壁に立てかけられたままのギターなどがinbox行きになる(そして何をすべきか、なぜそれをしたいのかを判断していく)ことになる。

もちろん、そういった物理的なものだけでなく、実体の無いものも対象になってくる。

頭の中のことを収集するには、20分から1時間くらいかかるだろう。おそらく、小さなことや大きなこと、個人的なこと、仕事に関することがランダムに浮かんでくるにちがい無い。 ここで大事なのは、量に重点を置くことだ。取りこぼすくらいなら、やりすぎたほうがいい。 不要なものはあとで捨てられる。最初に「オゾン層を守るために何かできないか」という考えが浮かんできて、次に「キャットフードが切れそうだ」という考えが浮かんでくるかもしれない。それらを全部「収集」してしまおう。

これらをリストアップするために、気づきをあたえてくれるリスト(こういうの忘れてない?リスト)がP.120〜大量に掲載されている。

英語版であれば、GTDの公式サイトから参照できるが、本の方がより詳しく多くの項目が掲載されている。

http://gettingthingsdone.com/wp-content/uploads/2014/10/Mind_Sweep_Trigger_List.pdf

第6章 処理

GTDのステップの「処理」と「整理」は、意識しないと混同しがちである。「処理」は、収集で集めたタスクをプロセスに従いどのリストに収めるか決め、必要に応じてブレークダウン(次の行動を決める)することを指し、「整理」はどのリストに収めるか決めたものをしかるべき信頼できるシステムに転機・属性付け(リマインダー/コンテキストの設定)をすることを指す。

「処理」と「整理」は密接に結びついているので、inboxの「処理」にとりかかる前に、本章と「整理」を扱った次章を先に読むといいだろう。でないと二度手間になるものが出てくる。クライアントを指導しているときも、「処理」の単純なステップと、「処理」されたものを実際に整理システムに組み込むためのやや複雑なステップとのあいだで行ったり来たりするケースは必ず出てくる。

とされているので、その通りにするのが良いだろう。

処理については、前述のフローを以下のルールのもと対応していくとしている。

  • いちばん上のものから処理していく。
  • 一度に1件ずつやる。
  • inboxに戻さない。

これらは、全てを処理する必要があるので、ごちゃごちゃ考えずに上からやっていった方が効率的だし、気が乗らないものが沈み続けるという事態が防げるというのが理由だと理解している。

inboxの中には、行動を起こす必要のないものが一定量混じっているはずだ。これらは次の3つのタイプに分けられる。

  • ゴミ
  • 保留にするもの
  • 資料

ゴミはその名の通り(2重線を引くなり)捨て、保留については「いつかやる/多分やる」リストもしくは「カレンダー」に内容に応じて分類、資料もその名の通り「資料」フォルダ行きにする。

inboxから取り出したものが、行動を起こす必要があるものだった場合、その行動が何かをはっきりさせなければならない。もう一度説明しておこう。「次にとるべき行動」とは、現状を求めるべき結果に近づけるために必要な、目に見える物理的な行動である。

〜中略〜

次にとるべき具体的な行動が決まったなら、あなたの選択肢は次の3つのどれかになる。

  • 実行する(2分以内にできるとき)。
  • 誰かに任せる(ほかにふさわしい人がいるとき)。
  • あとでやる(すぐに実行できなくて、人にも頼めないものは行動の選択肢のひとつとして整理システムに移しておく)。

実行するの基準が2分以内にできるとき となっており、優先度が考慮されてない部分は一つのポイントである。優先度が高かろうが低かろうが、2分以内にできることであればさっさとやってしまおう というのは明快である。

誰かに任せるについては、引き継いだ後にその記録が「連絡待ち」リストに行くことになる。

あとでやるについては、次の整理のタスクにて、「プロジェクト」「カレンダー」「次にとるべき行動」「いつかやる/多分やる」リストに据えられることになる。

第7章 整理

この章では、inboxで「処理」したものを振り分けていく「整理」のステップとそのためのツールについて解説する。inboxに入ったものを「処理」していくと、「整理」の必要なリストが次々に出てくる。その際、それらを収めるための場所やツールが必要なわけだが、最初から完璧なものを目指す必要はない。気になるものを「処理」し、自分にとってベストだと思う場所に組み入れていく作業を繰り返しているうちに、どんなものが必要なのかが自然とわかってくる。

との出だしで始まる章である。つまり、「収めるための場所やツール」に収めることをここでは整理と呼んでいる。

「整理」して管理・把握しておくべきものは、主に次の7つだ。

  • 「プロジェクトリスト」
  • 「プロジェクトの参考情報」
  • 「カレンダー」に記入する行動や情報
  • 「次にとるべき行動」リスト
  • 「連絡待ち」リスト
  • 「資料」
  • 「いつかやる/多分やる」リスト

各々の整理対象が上記どれにあたるかは、あまり悩むことは無いと思う。1点気になるとすれば、「いつかやる/多分やる」リストで、ここに入ったが最後、永遠にここに居座ってしまうのではないかという懸念で、いっそリストから消してしまう方がいいのではと悩んでしまう点である(以前チャレンジした時はまさにそうだった)。

これについては、明確に答えが書いてあり

「いつかやる/多分やる」は、ゴミ箱に入れるべきではない。これまで経験したことのないクリエイティブなものや興味深いものが眠いっている可能性がある。

と直接のゴミ箱行きは否定されている。

このリストの意義として、タスクというよりは夢に近いと思っている。レビュー時にこのリストからインスピレーションを受ける、場合によっては一念発起して取り組み始めたりと、必ずしも完了に持って行くことが目的では無いという認識である。

また、次章のレビューの説明において

「いつかやる/多分やる」リストのレビュー:着手したプロジェクトがあれば「プロジェクトリスト」に移動する。関心のなくなったものは削除する。

と、状況に応じて(関心がなくなったものは)削除することも前提になっている。つまり、漠然とした夢の様なものは、"とりあえず"くらいの気持ちでここに入れても何ら問題ないという理解をしている。

そして、1点僕が勘違いしていたものとして、「カレンダー」についても挙げられる。

月曜なら"月曜にやりたいこと"をカレンダーに書いてしまう。そして、そこには絶対に月曜にやらなくてはならないことではなく、火曜日にずれ込むかもしれない行動まで書き込まれてしまうこともある。そのような誘惑にはくれぐれも気をつけよう。カレンダーは「聖域」であり、その日に絶対やるべきこと以外を書いてはいけない。

"いつやりたい"というのは、ぶっちゃけ全てのタスクに対して設定することができる。それはすなわち優先順位付けと何ら変わりがなくなってしまう。GTDの理念が、「優先順位付けなんてしなくても、各リストがしっかりメンテされていれば、その状況に応じて最適なものを実行できるよね」という理念に基づいているので、そこに反してしまう。

何でもかんでもカレンダーにぶっこまない(期限を切らない)というのは、割と重要なポイントだと思う。

本章では、各リストに対して、リマインダーという"属性"を付与することを推奨している。"属性"とは僕が理解のために勝手につけている言葉で、いわゆるタグみたいなものである。各整理対象は、一つのリストにしか入れることができない。「資料」と「次にとるべき行動」の両方に1つのものを入れることはできない。しかし、属性(リマインダー)は複数割りあてることが可能である。「家でやる」かつ「会社でやる」があっても問題無いし、どういった状況で処理するかという「カレンダー」「次にとるべき行動」等とは別の側面での属性付けである。

本書で例として上がっているのは

  • @電話
  • @パソコン
  • @買い物・雑用
  • @会社(組織や団体により変更)
  • @自宅
  • @協議事項(人または会議)
  • @読む/評価

などである。

こういった分類がされていると、適した状況で素早くタスクを処理ができる という考えである。つまり、こういったリマインダーを設定するのは行動を起こす必要があるものに対してで、「資料」などには付与されない。「カレンダー」「次にとるべき行動」(プロジェクト配下の次にとるべき行動も含む)が主となる。

第8章 レビュー

やるべきことをやってきて、やっていないことについても、今はそれでも大丈夫という確信が得られなければならない。このように定期的に見直す作業はシステムの機能を維持するために不可欠である。

〜中略〜

あなたの整理システムは、いざ行動をとるというときに、いつでもすべての選択肢が見渡せる状態になっていなければならない。考えてみれば当たり前のことだが、そこまで機能的なシステムを確立している人は実際にはほとんどいない。

上記は本章の冒頭からの抜粋である。レビューによって目指すべき状態が上記の状態と理解している。

ここで、考えると重要な点がある。"いつでもすべての選択肢が見渡せる状態"であることも重要だが、"いつでも全ての選択肢を見渡す"ことも重要という点だ。せっかくレビューして、最新の全てのことがリストかされたとしても、それが活用されないと意味が無い。その日の最初にカレンダーを見て"必ずやらなければならないこと"を確認し、リマインダーを元に今の状況で対応できることを確認し、といった感じだ。

そういった行動の礎となるためのメンテナンス作業として、本書では"週次レビュー"を勧めている。

週次レビューとは、簡単に言ってしまえば頭を再び空っぽにするための作業だ。ここではワークフロー管理の一連のステップを再度行うことになる。すなわち、現在あなたがかかわっているすべてのことを収集・処理し、整理して、レビューするわけだ。それが済んで初めて、「できていないことはすべて把握できているし、その気になったときには実行できる」という確信を持つことができる。

つまり、すでに処理・整理したものがその位置にあることが正しいことを再確認し(関心がなくなったら削除するなど)、新たに生まれた関心ごとを一連のプロセスにかけてあるべきところに落ち着かせる ということを、しっかり時間をとって週に1度やると良いよ という提案である。

しっかり時間をとって の部分を太字にしたのは、本書に以下の様にかかれてるからである。

習慣がみにつくまでは、必要なことをきっちりやらないといけない。週に1度、うまく自分を誘導して数時間、忙しい日常から離れるようにしよう。忙しさから逃げ出すのが目的ではない。より高いレベルからすべてを見直し、システムを最新の状態に保つためだ。

第9章 実行

さまざまな作業に追われる日々の仕事において、ある特定の時間に何をするべきかはどうやって選んでいけばよいのだろう。答えは簡単だ。いままで行ってきた「収集」「処理」「整理」「レビュー」を実行したあとに残っている選択肢の中から、直感を信じて行動を選択していけばいい。ここまでGTDを実践してきたあなたは自分の直感に自信をもつことができるはずだ。逆に「収集」から「レビュー」のプロセスを事前にこなしていない人は、実際に行動を起こすときに自信をもって決断を下すことができない。ほかにやるべきことがないだろうか、と心配しながらおそるおそる思いつくことの中から行動を選んでいくことになるからだ。

上記引用の太字部分は僕が勝手に太字にした部分である。実行のキモは、GTDをやってないと太字な状況に陥るのを回避することにある と思っている。

前章でも感じたことだが、やることをしっかりとリストの中から選ぶ習慣をつけないと、元も子もないのだ。

直感を信じて行動できる とあるが、基準も明示されている。それは

  • そのときの状況
  • 使える時間
  • 使えるエネルギー
  • 優先度

とされている。優先度については、あらかじめ設定していたものではなく直感によっての優先度を指している。

さて、ここで実行についての問題が出てくる。

たとえば風呂掃除(やらなくていいならやりたくない)、たとえば英語の勉強(やらなくていいならやりたくない)、たとえば確定申告の書類書き(やらなくていいならやりたくない) といったものをどう実行に落とすかだ。

これについては、本書に書かれている内容ではないが、レビューのプロセスで考え抜くことが大事だと思っている。

本当にやりたくないなら、いっそリストから削除するべきであり、それでもリストに残したいのであれば、なぜ残したいのか考え抜くことで原動力を得ることができる。

つまり、実行に二の足を踏むようなら、レビューのプロセスで再評価する対象となるべきである。ずっとリストの奥底に眠るようなら、いっそ削除することも検討すべきだ。

第10章 プロジェクトを管理する

本章では、プロジェクトの管理方法というよりは、コツ的なものが色々と示されている。

プランニングにあたり、ブレインストーミング、整理、会議、情報収集といった手段があるよね といった話。思考ツールとして良い筆記具をやお気に入りの電子ツール使うと気分良いよね といった話などである。

自分のやりやすい方法でやってもらって構わないが、そのやりやすい方法を見つけるためのヒントとして著者はこの章を設けたのかな と思っている。

「次にとるべき行動」のリストと同様に、「プロジェクトリスト」も最新の状態にしておく必要がある。それができたら、1時間から3時間くらいかけて、それぞれのプロジェクトをさらに上の視点から見渡してみよう。できる人は今すぐ、そうでなくてもなるべく早く、今いちばん関心のあるプロジェクトをいくつか選び、情報やアイデアを収集して整理してみよう。使うツールはなんでもいい。

〜中略〜

大事なのは、ごく自然にアイデアを考えたり活用したりできるようになることだ。エネルギーを効率よく振り向け、求めている結果に必要なときに集中することで、ストレスなく物事をこなしていけるようになるはずだ。

そんな結びで本章は終わっている。

第11章 収集の習慣を身につけると何が変わるか

すべてを「収集」するプロセスを実行していると、ほとんどの人は不安を感じるようだ。〜中略〜これまで面倒で手をつけなかったものが見つかれば、罪悪感だって湧いてくるだろう。「なぜこんなに放置しておいたんだ」と自分を責めてしまうわけだ。その一方で、解放感や安心感、自信のようなものも湧いてくる。不安と安心、もうだめだという感覚と自信という、まったく逆の感情がほぼ同時に起こってくる。これはいったい、どういうわけだろう。

〜中略〜

マイナス感情の原因は、もっと別のところにある。誰かが約束を守らなかったとき、あなたはどんな気持ちになるだろうか。〜中略〜それと同じで、inboxに入ってくるものは、あなたがあなた自身に課した"約束"である。その約束を破ったからこそ、嫌な気分になったのだ。

〜中略〜

自分に対する約束を破ることでマイナス感情が起こってくる。これを避ける方法は次の3つしかない。

  • 約束をしない。
  • 約束を果たす。
  • 約束を見直す。

本章では、収集中に現れる不安についての対処法が記載されている。これはGTDにせよ普段の生活にせよ、重要な話だと思っている。できないものはできない。やりたいならどうやればやれるか考える。当たり前のことではあるが、やることに連ねて放置というのはよくあることである。

言い方を変えると、不安の原因が見えているのだから、不安に思った際は、「本当に遂行できるか?ステップは正しいか?」、場合によっては「これは今やる必要があるのか?将来だったらやる必要があるのか?」と不安にならないところまで掘り下げていけば良いことになる。

第12章 次にとるべき行動を決めると何が変わるか

クライアントとリストを一緒に見ていたときに、「タイヤ」という項目があった場合で考えてみよう。私が「これは何ですか」と尋ねると、クライアントは、「車のタイヤを変えないといけないのです」と答える。次に私は「具体的に、次にやる行動はなんでしょう」と訊く。すると、クライアントは眉間にしわを寄せて考えはじめ、ほどなくこんな結論を述べる。「店に電話して値段を聞いておくことですね」

〜中略〜

タイヤのことは、しばらく前から気になっていた可能性が高い。他の電話のついでに店に電話する機会も無数にあったはずだ。なぜそれをやらなかったのか。電話の前にいるときに、タイヤを替えるのに電話が必要だと思い浮かばなかったからだ。

本の中でも何度も取り上げられている、「具体的な行動に落としておくと、対応しやすいよね」「リマインダーをあらかじめ設定しておくと、しかるべき時に対応できるよね」という部分を再度丁寧に説明している。

この具体的な行動の決め方として、「次にとるべき行動を決めるときは、同時にどれくらい時間がかかるかも添えておくといい。どれくらい時間がかかるかイメージできなければ、それは具体的な行動というには粒度が荒い」という考え方が良い。この考え方は本書ではなく、すでに絶版となっているLifeHack系の本でGTDの説明に添えられていた話だが、なるほどと関心し記憶に残している。

次のとるべき行動を明らかにすれば、よりスマートに不安を解消できるのだ。プロジェクトを全身させるのに必要な物理的行動を見極めることで、あなたはやらなければならないこと、現実から変えなければならないことへのプレッシャーから確実に解放される。状況そのものには何の変化もないものの、行動可能な、完了できるタスクに意識が向くことで、方向が定まてモチベーションや気力が高まるのである。

次にとるべき行動を明らかにする作業においては、嫌々やるのではなく、上記の考えを念頭にポジティブに対応していけば、いくぶん晴れやかな気持ちで作業をすすめられるのかなと思っている。

第13章 望んでいる結果に目を向けると何が変わるか

人生や仕事は、行動とその結果の積み重ねである。日々の営みにおいて、入ってきたことのすべてを、あらゆるレベルにおいてこのような視点で整理していくと、意識の深い部分で変化が起こり驚くような成果が現れてくる。生産性がぐっと高まり、イメージを明確に描きつつ、それらを実現していけるようになるのだ。

〜中略〜

必要なところに集中していくと、他の手法では得られないメリットがもたらされる。人生のあらゆるレベルにおいて効率が高まり、よりよい成果を上げられるようになるのだ。

本書で述べられていることは、上記引用に集約されていると思う。

日々のやるべきこと、やりたいこと、資料などのリストなどなどが適切に管理され、それらがうまくまわると、おのずと人生もうまくいくよね と。

ただ単純にタスクをこなしていく手法と捉えるのではなく、人生をよりよく(本書の言葉を借りるならストレスフリーに)していくための手法として捉えて、そして活用していってね という著者からのメッセージだと思っている。

読み返して

以上で読書メモは終わりです。

当たり前ですが、本1冊になっている内容を、簡潔にまとめるなんてできないんですよね。著者が伝えたいことを詰め込んだ内容が1冊になってるんですから。上記メモは僕が重要だと思ったところや、気づきがあった部分です。他の人が読めば、また違った部分にマーカーが引かれることになると思います。

ここまで読んでくれた人はあまりいないと思いますが、知っているつもりのGTDでも読み返してみるといろいろな気づきがあります。GTDをやろうと思っている/やっている/やっていた な人で、まだ読んでない人は一度読んでみる/読みかえしてみるのも良いかもしれません。

はじめてのGTD ストレスフリーの整理術

はじめてのGTD ストレスフリーの整理術

続けて、本記事では書けなかった、他の2点の本についても再読し、気になったところをメモとしてまとめていこうと思います。

そして、再度GTDチャレンジしてみようかなと思ってる次第です。

勉強嫌いな僕のTOEIC300→770点の道&現状どれだけ英語が使えるか

英語学習

英語に関する記事をいくつか書いていますが、いままで「TOEIC300点の僕でもめげずにできる(結果が出るかはわからないけど)勉強法」という論旨で記事を書いていました。

例えば

nakazye.hatenablog.com

とか

nakazye.hatenablog.com

とか。

これで英語力アップ!となかなか言えないのが心苦しいなぁとずっと思っていましたが、この度客観的に英語力を測る機会、すなわちTOEIC受験の機会に恵まれ、実際に効果あったよ!というのが証明できましたのでご紹介です。

TOEIC300→770の道

TOEIC300点というのは約10年前のスコアだったりします。その後、仕事でもプライベートでも特に英語を使う機会などなく、また勉強する機会もほとんどありませんでした。

そんな中、前の記事の通り読書やゲームに英語を混ぜ始めたのがこのブログを始めたくらいから。つまり3年くらいかけてることになりますね。

で、先日受けたTOEICの結果がこちら。2ヶ月連続で受験しています。

f:id:nakazye:20160726213040j:plain

リスニングのスコアが大きく違いますが、最初に受けた方で回答を悩んでいる最中に次の問題文が始まり、試験中に「このやり方じゃダメなのか?回答先に読んだ方がいいのか?」などとパニックに陥って後半撃沈したことが大きいと思ってます。

何が言いたいかというと、TOEICの試験だけで見れば慣れも必要。リーディングも速度重視で解いていかないと追いつかない(僕は両方とも時間切れで一部回答できませんでした(適当にマークはしましたが))というのもあり、自分のスコアがどれくらいか知りたい場合は2回受けると試験不慣れ補正が外れてより正確なスコアがわかるかと思います。

実際に周りで何度も試験を受けている人は、「短期間ではスコアはほとんど変わらない。そういう点ではよくできてるテストだと思う。」という感想を聞きます。

TOEIC770点がどれくらいの力とみなされるかというと、公式的には「どんな状況でも適切なコミュニケーションができる素地を備えている。」という歯切れが悪い言い回しですが、そんな感じらしいです。

f:id:nakazye:20160726220422j:plain

英語が苦手な状態から、上記公式資料を信じれば海外部門でもやっていけるよな状態に3年で到達できたというのは、個人的には上出来かなと思ってます。

何かすごい得点アップの秘訣とか無いの?

英語学習の記事は度々バズるのを見かけますが、多くが「○ヶ月で××な成果が出ました!」的な短期学習型が多く、少なくとも僕みたいな凡人には根性的にも時間的にも無理です。そして、勉強嫌いな僕が詰め込み型の勉強をしたところでめげるのは目に見えてます。

ということは必然的に細く長く戦略となるわけですが、勉強の習慣が無い人にありがちな罠である「ふと気づけば最近何もしてない」が頻繁に発生するわけです。1ヶ月気づけば英語に触れてないとかザラです。

で、ここで勉強が嫌いな僕の秘訣ですが、TOEIC○○点を×月までに!」といった目標ではなく「生活に英語を組み込む」という目標にしたことです。

期間が決まってる目標であれば、ブランクが空くとそこでめげるかと思います。だけど僕の場合は「生活に英語を組み込む」が目標なので、ブランクが空いてることに気づいたら「んー、英語やる気起きないけど、とりあえず海外ゲームでも復帰のとっかかりにやりますかねー」と、少しずつ英語に触れる生活に戻ることができるわけです。

とっかかりとしておすすめは、以前も紹介したことがある、Steamで配信されているゲームでGo! Go! Nippon!が激しくおすすめです。全体的に平易な文章で、誇張抜きに中学英語でOKです(辞書はしばしば必要になりますが)。英語が苦手であっても、日本語同時表示も可能なので、英語に慣れたいという全ての人におすすめしたいです。

前の紹介記事を書いた後にDLCで、Go! Go! Nippon! 2015というのが追加されているので、これは必ず入れましょう。行ける場所が格段に増え、長く楽しめます。

上記を筆頭に、前に書いた様なゲーム&本、その他もろもろネットコンテンツなど、辛いと思わない程度に英語に触れる様にしました

ネットコンテンツであれば、隙間時間を使って主に以下を活用しました。

読みもの系

一時期は色々と漁ってましたが、最近は数個に収束しつつあります。

digg.com

英語のはてなブックマーク的立ち位置だと思ってるDigg。海外メディアはその傾向が強いけど、動画コンテンツが多いのがちょっと悲しい。見出しをざっと見て、世の中でどんなことが話題になっているのか見てました。

www.cio.com

CIOと名が付いている通り、技術系の中でも言語やフレームワークなどよりもう一歩上の視点で書かれた記事が多い。記事の更新がそこまで頻繁でも無いので、時間をかけて読んでも記事の場所を見失うことが少なく重宝してました。

Medium

日本語版もあるmedium。日本語記事でよく見かけるのは技術系記事ですが、英語版をトップページからみるとライフハック系が多いです。

動画・音声系

www.aljazeera.com

アルジャジーラをよく見るというと変な目で見られることが多いですが、真っ当なニュースコンテンツです。特筆なのがライブ配信で、24時間いつでも最新のニュースをライブストリーミングで見ることができます。若干中東情勢に寄ってますが、いろんな国の英語を聞けるのも良い。おすすめ

www.bloomberg.com

経済ニュースのブルームバーグ。こちらもライブ配信があります。注意点が1つあって、ブラウザからみるとしょっちゅう広告が入ってちょっとイライラします。Apple TVからみると広告がなくなる(といってもその分為替情報表示が長くなる)ので、Apple TVを持っているならそちらからみるのがおすすめです。
あと、ライブニュースでもちろん日本の株式の情報も流れてくるのですが、最近は中国の話も多く、グローバルな経済の中で日本の立ち位置がどんなもんか・・・というのをリアルに感じられるのは悲しいけど面白いです。

www.bbc.co.uk

こちらはBBCのラジオのストリーミング。海外からBBCのテレビ番組はネット越しに視聴はできないのですが、ラジオはリアルタイムストリーミングで視聴可能です。
個人的な意見かもしれませんが、アメリカ英語よりイギリス英語の方が聞き取りやすいかなと思ってます。

受験前の2ヶ月ほどは勉強もしました

どうせ受けるならちゃんと点数取りたいなと思い、いやいやながらも勉強らしい勉強もしました。

ガイドは定番の「英語上達完全マップ」。

英語上達完全マップ―初級からTOEIC900点レベルまでの効果的勉強法

英語上達完全マップ―初級からTOEIC900点レベルまでの効果的勉強法

これは、勉強の仕方のガイドとしても重宝しますが、モチベーションを上げるのにも重宝します。

この本では、「簡単に英語ができる様になる方法なんて常識的に考えてありえないよね。地道にやっていくしか無いでしょ。」というのが基本コンセプトなので、モチベーションが上がらない時にパラパラ見て地道に頑張るか という気にさせてくれます。

このガイドに従い、日頃読んでいる文章は音読を心がけ、1点圧倒的に足りて無い部分として文法もガイドに従い問題集を始めました。

文法の点数をそこまで劇的に取れてない僕が言うのもおこがましいですが、良い本です。解説がすごくしっかりしているので、1問1問なるほど!と思える。

なるほど!と思えない部分、例えば「ここは倒置公文だから・・・」といった「ソレなんだっけ・・・?」という部分も出てきたりするのですが、そこは文法書の定番Forestを横に再学習しつつ進めていきました。

総合英語Forest 7th Edition

総合英語Forest 7th Edition

実は別にTOEIC公式問題集も買ってたりするんですが、見比べてとりあえず文法部分は上記問題集でカバーできそうだと判断し、かつ他の部分を満遍なくやる気力もなかったのでほとんど使いませんでした。

TOEICテスト公式問題集 新形式問題対応編

TOEICテスト公式問題集 新形式問題対応編

で、受けた結果が前述の通り680&770といった感じです。

で、その英語力でどれだけ使えるの?

ぶっちゃけ、受身のコンテンツには太刀打ちできません。受身というと、例えば字幕なしで映画の内容を理解するとか、辞書なしで本を読むとか。

ただ、いわゆるコミュニケーションにはそこまで困ってません。少なくとも、仕事で読む・聞く・書く・話すの全てを使う様になりましたが、なんとかなっています。

読む

これは僕の英語の学習の中心なので、辞書さえあればほとんど困りません。そして、仕事であれば書いた人が身近にいたりするので、「ごめん、意味わからないんだけど」といえばOKです。

聞く

これもコミュニケーションにおいてはそこまで困りません。話空いても人間です。こっちが「ごめん、言ってることわからん」を連発すると、ゆっくり話してくれたり、言い回しを変えてくれたりします。

「Excuse me? I couldn’t catch that, would you repeat it?」は僕が一番よく使うフレーズの筆頭ですが、下記IBM資料のフレーズ集丸パクリで困った時は大抵切り抜けられます。

http://www.kidsfromusa.com/blog/img/telecon.pdf

どうしてもわからなかったら、最悪「書いて」っていえばいい訳ですしね。

書く

これも実はそんなにハードルが高く無い。ノンネイティブだし、現状実力が無い訳で、背伸びして高尚な文章を書く必要は無い と思えると(そして思っていい相手だと)格段に楽になります。

単語がわからなければGoogle検索で一発。日本語で同じ助詞が連続すると気になって推敲するけど、英語だと(少なくとも今の僕のレベルでは)文頭にSo, が続いても気にしない。

わからなかったらわからないと言ってくるだろ と開き直るのが重要です。

話す

これはさすがに簡単になんとかなる・・・とは言いづらい。けど、かろうじて何とかなってます。相手に多大な負荷かけつつ。

極端な話、"Is you have vacation when?"みたいな無茶苦茶な文法でも、相手も人間なので言いたいことは汲み取ってくれます。ので、文法はそこまで考えなくても伝わります。そして伝わらない時は聞き返してくれます。

ただ、単語が出てこない時は辛い。一生懸命言い換えを考えることになります。

たとえば、ぱっと思いついたレベルでいうと「延期」postponeという単語が出てこなかったとする(こういうレベルで出てこないのが多かったりする・・・)。そういう時にchange our deadline to ・・・とか言ったりする。

最初の頃は単語が出てこない時にものすごく焦りますが、だんだんと"Sorry how can I say ..."とか挟みつつ、(相手には悪いですが)ゆっくり考えれるようになり、大抵言い換えが出てくるか、相手が何を言いたいか当ててくれます。

つまりなにが言いたいかというと

現状の英語レベル。とてもじゃないですが、これで良しとしちゃダメですよね。

ただ、TOEICの僕のレベルを表す「どんな状況でも適切なコミュニケーションができる素地を備えている。」ってのは間違ってないと思ってます。

正確とは程遠い。ただし、最低限のコミュニケーションができて、悪いところを改善していけば良い。その下地はできてる。

僕の英語の勉強ですが、TOEICのスコアを取るためというよりは、「技術者として生きて行く限り、今後確実に英語の重要度が増してくる」と思ったからです。

決して「英語を話せる様になれば、それすなわち国際線CAさん全ての人と意思疎通が可能になる」なんていう動機ではありません。嘘です5%くらいあります。

英語が使える様になる。魅力的な響きですが、これこそTOEICスコアを上げること以上に一朝一夕ではいかない課題です。

つまり、継続していくしかない。

僕みたいな勉強が苦手な人間でも、例えばゲーム、例えば本、例えばネットコンテンツなど、できる範囲でやっていけば少なくとも下地はできる。長い時間はかかったけど。

そして、きっと続けていけば、もうちょっと自然に使える英語になっていくと信じてます。また数年後、「英語で不自由しなくなりました」みたいな記事が書けたらいいなと思ってます。

英語の記事が世の中腐るほどあるだろうなか、なんでこんな記事を書いたかというと、僕が世の中の学習記事に助けられたからです。

「あー、ほかにも頑張ってる人たくさんいるんだなー」と思える様な記事を読むと、自分もやる気になってきます。

僕の書いた駄文も、誰かのモチベーション維持に貢献できたらな、と思ってたら、思いの外長文になってしまった夏の夜でした。

インドのシリコンバーレ、バンガロールの今

ポエム

ばんがろーる?

出張でインドはバンガロールベンガルールと改名されたが、まだバンガロールの方がメジャーな呼び名だと思ってる)に来ています。

インドのシリコンバレーなんて呼ばれてるところですね。

ちなみにインドではバンガロール以外にも最近はPune(プネー(でも現地の人が発音するとプネと聞こえる))がインド東のシリコンバレーなんて呼ばれ台頭してきています。

そんな感じでインドではいろんなところでIT業が盛んだったりするのですが、その中でも際立ってるのが今僕のいるバンガロールだったりします。

実際どんなところ?

写真を見てもらうのが一番早いと思うので主にiPhoneで撮った写真を載せてみます。

f:id:nakazye:20160424213837j:plainf:id:nakazye:20160424213911j:plain

こんな感じで街中に貼られているビラに技術用語が並んでいたり・・・

f:id:nakazye:20160424214914j:plainf:id:nakazye:20160424214939j:plain

今いるホテルから近いところにあるので写真を撮ってみたCISCO、そしてみんな大好きAdobe、他にOracleIntelIBM、HP、DellGoogleMicrosoft、SAPなんかも見かけます。有名どころで見かけてないのはAppleくらいなんじゃないか(あるのかな?)というくらいいろんなIT企業が集まっています。それもアホみたいに大きなオフィスで。

WikipediaIBM Indiaの項を見るとインドで20万人の社員(大半がいわゆるオフショア要員と考えて良いはず)。ヘッドクォーターがあるここに数割いると考えると、それだけでものすごい人数です。

IBM India - Wikipedia, the free encyclopedia

僕がオフィスに行く途中にインテルの前も通りますが、朝はオフィスに入るための渋滞を見かけます。

じゃぁ街中もITが駆使されたハイテク社会になっているかというと

f:id:nakazye:20160424220849j:plain

こんな感じで街中にゴミが捨てられ、そのゴミを神聖なはずの牛様がむしゃむしゃしてたり(ちなみにどうしようもなくなるレベルでゴミが山になったら燃やす様です。たまにそんな光景を見かけます)

f:id:nakazye:20160424221059j:plain

これはベランダ湖と呼ばれる場所の端っこを今日通った時にタクシーの中かから撮影したんですが、水色に見えるのは泡です。生活汚水とかもうそういうレベルではなく危険物レベルの悪臭がして、過去にはこの泡が燃えたりなどニュースになってたりもします。

【衝撃動画】インドでフワフワの白い物体が大発生! 住民の生活を脅す / 正体は毒の泡 | ロケットニュース24

こうやって街中は日本人の感覚からすると酷い有様です。

インド人の身近なIT

こんな中、インドで急速に発展しているITがあります。ケータイ電話、いわゆるスマホですね。

去年来た時はWindows Phoneもたまに見たんですが、今はAndroidが主流、たまにiPhone(しかし多くはコネクタ形状古いようなやつ)を見かける感じです。Windows Phoneマジ頑張ってくれ・・・

若者たちはLINEではなくWhatsAppというアプリでメッセージをやり取りしています。なおWhatsAppは他の国でもメジャーな地域は多いので、海外行かれる方は導入しておいて損はありません(SMS認証あるので国内で設定しておかないと面倒)。

タクシーを呼ぶにはなんとUberが使えます。UberMOTOっていうのがすごく気になります。バイクの後ろに乗せてもらうんでしょうか?

f:id:nakazye:20160424222515j:plain

と、他人事の様に言っているのは、僕がUberを使ってないから。サポートがとにかく遅くて検討はずれで、イライラが極まり使うのをやめました。

ということでインドに行く機会があればお勧めしたい配車アプリは現地法人が展開しているOLAです。

f:id:nakazye:20160424222722j:plain

ほとんど似た様なUIですね。僕は休日や平日の夜出かける際は、このアプリを使って車を呼んで出かけています。日本車が配車されたら勝ち、TATAの車が配車されたら負けと思ってますが、今の所勝率は6割くらいでしょうか。

いわゆるリキシャーより安く移動できることが多いです。(↓リキシャー)

f:id:nakazye:20160424222904j:plain

そして、いわゆる電子マネーも普及しています。Paytmというのが一番メジャーで、タクシーの支払いやカフェでも使えたりします。また、個人間送金もできたりして、日本だとLINE Payが近い感じですかね

f:id:nakazye:20160424223358j:plainf:id:nakazye:20160424223401j:plain

と、こんな感じで街はアナログ、住民はハイテク、そんな街なバンガロールです。

現地の技術者たち

少なくとも僕の周りの日本人より勉強しています。仕事が終わった後、技術系のスクールに行っていたり、オンラインスクールを受講している様な人がとても多い。いわゆる普通の技術者が、です。

そしていわゆるマネージャー層は管理一辺倒かと思えば技術の話にめっぽう明るい。ホント話していてこいつらどんだけ勉強してるんだ?って思うレベルで明るいです。そして頭の回転、決断が早い。

カースト制の名残なのか、凡な人と優秀な人が割と綺麗に分かれるというのが肌で感じた実情なんですが、別にカーストが関係している訳ではなさそうです。Googleの今のCEOのピチャイも普通の家庭出身の様ですし。

で、世界のアウトソーシング先として機能していることからもわかる様に、皆さん英語が達者です。

Rの発音が独特というのはホントその通りで、マルジと言われてマージだった時は「ホント他の国の人たちはこいつらの英語理解できるのか!?」とブチ切れたものですが、慣れるとだんだんわかってきます。

個人的に厄介なのは、Rの発音より速さです。言葉って、思考速度以上で発せれないじゃないですか。こんなところからも彼らの賢さがかいま見えるのですが、日頃英語に慣れてない身からするとホント辛い。

そしてそんな彼らのお給料。同じ様な役職であれば、日本人の月収が彼らの年収と考えるとそんなに遠くないというのが、いろいろ話してみた感想です。

普通に給料聞いてくるからね、彼ら。最初は僕が月収で話してるのに向こうは年収で話していて話がかみ合わなかったの覚えてる。

で、彼らは給料を上げるために、割とカジュアルに転職していくのです。面接に臨むためのゲストカードをもらうためオフィスのレセプションに列ができているなんていうのはよく見かける話です。

ここまできて引っかかりません?

我々の月収が年収の技術者(プログラマーと言いましょうか)。勉強家で、できる人が多い。プログラマーという言葉でくくるなら、いろんな国からいろんなオーダーを受けてる分、経験も豊富。英語も堪能。そしてものすごい人数がいる。

対して我々日本人。彼らより給料を多くもらっている理由は日本人だから。日本の給与水準が彼らより高いから。少なくとも僕は彼らより技術力が高いからではない。残念ながら。

仕事を遂行する能力で長けている点といえば、日本語が使えるから日本のお客さんとやり取りができることくらい。あとは日本の法律や商習慣に馴染みがあるといった点か。

例えば10年後、20年後、このアドバンテージが、どれだけ有用なものであるか。BtoCでいえばGoogleなりFacebookなりAmazonなりグローバルなものが今でも多い中どれだけ有用であれるか。BtoBで言っても、ドメスティックに専念した企業がどれだけ残るのか。基幹にSAPを入れてる企業は今でも多い中どれだけ有用であれるか。

もし他国と比べて日本が魅力的な市場になれば、彼らは日本語を勉強してやってくるかもしれない。一昔前はそういった中国人がたくさんいた。その時僕は彼らと比べて魅力的であれるだろうか。

もし他国と比べて日本が微妙な市場になれば、その微妙な日本で生きながらえるか、他の国に出ることも考えなければならないかもしれない。その時僕は彼らと比べて魅力的であれるだろうか。

僕は、日本が好きで、特にインドにいる今、心から「日本って住みやすい国だし今後もそうであってほしい」と思っているけど、市場というかわかりやすくいえば賃金で、微妙な日本になっていく可能性は低くないと思ってる。

世界 という視点で見た時に、僕の市場価値はどんなもんなんだ? とバンガロールに来ると考えさせられるのです。

オチや答えはない

現在、AdobeGoogleMicrosoftのCEOがインド出身で、良い大学があるというのは大前提として単純に人数が多い分確率論として傑出した人物が出やすいんだろうと思っている。

わかりやすい面としてそういったトップ層、そして各国の最大のオフショア拠点という事実があるインド。それが、平社員である僕が彼らと市場を食い合うとなったら。仕事のポストを食い合うとなったら。

彼らが日本を食いに来るのか、日本では食えなくなって我々が外に目を向けなければならない日が来て戦うことになるのかはわからない。

けど、そうした将来も見据えた上で、僕はどうすべきなのかと考える訳です。

ただし、少なくとも英語ができないというのは戦う上でも武器を磨く上でもお話にならないので、たくさんある「どうすべき」の中で確実に必要な一つとして学習を続けようと誓った今日この頃です。

Macに貼る為のステッカーを買ってみた

Mac

表題の通り、ステッカー買ったぜー!というお話です。

エンジニア向けの勉強会に行くとMac率が高い

そして、みんなステッカーをペタペタ貼っている。githubのoctocatが貼られている確率がその中でも高い気がする。

f:id:nakazye:20160324225133p:plain

↑こういうやつ

昔スケボーやってたんですが、スケボーでも似た様にステッカー貼る文化があるんですね。同じノリで、お洒落的な意味合いでみんな貼ってるのかと思ってました。

f:id:nakazye:20160324225638p:plain

Mac(MacBook Air)を持ってはいるんですが、なんとなく気恥ずかしくて、今までステッカーは貼らずにいました。ただ、最近たまに勉強会に参戦する様になり、お洒落的な意味合いとは別の意味があることに気づきました・・・

何かというと、Mac率が高いので、ステッカーでも貼っておかないと自分のPCがぱっと見どれかわからなくなるという問題が出てくるのです!

ということで、ステッカーを検討し始めました。

ステッカーはどこで入手できる?

先ほど紹介した、皆が貼っているoctocatのステッカーはGithub Shopなるところから買えるそうです。

ここで購入してみようかなーと考えたのですが、githubのcommit数が少ない状況でステッカー貼るのもな…と尻込みし、見送りました。

github.myshopify.com

で、ここからが本題ですが、各種OSSのステッカーを取り扱っているサイトを見つけました。

www.unixstickers.com

このサイトというかショップの素晴らしいのはステッカーを買うと、当該プロジェクトに対して売り上げの一部が寄付されます。

www.unixstickers.com

その他、例えばVimのステッカーを買うと、売り上げの一部がウガンダに寄付されています。先月だと

VIM (ICCF Holland) $61.12

となってますね。なお、我らがEmacsFSFへの寄付となりますが

GNU (Free Software Foundation) $24.43

となってます・・・FSFへ貢献したい方は、以下のサイト経由がオススメです。しかし、送料がかなり高めとなっているので、何か購入する場合は有志を募った共同購入がオススメです(Emacsマグカップを買おうとしたら、マグカップ本体より送料高くてびっくりした)

Support free software | FSF Shop

さっそく買ってみた

オーダーをしたのが今月の3日。で、本日24日に到着しました。

Non trackable via global mail $4.50 という送料が一番安いプランを使って、20日ほどかかった計算ですね。4.5ドルの送料で済んでるんだから良しです。

f:id:nakazye:20160324232908j:plain

こんな感じの封筒で、ポストに届いてました。宅急便ではないので受け取りサインもいらず、一人暮らしな社会人には嬉しいですね。

で、中をあけると・・・

f:id:nakazye:20160324233124j:plain

ステッカーが出てきました!当たり前ですがw

All our stickers are printed with top quality supports and inks, with the best accuracy in cutting and packaging. This grants you a perfect final product that lasts over time. Just place you preferred stickers on your computer, make it unique with a beautiful look!

などと謳ってますが、素人目から見ても良いクオリティだと思います。

特に、Emacsのステッカーがちゃんと縁取られてカッティングされているのが素晴らしいと思います。

f:id:nakazye:20160324233535j:plain

貼ってみたらこんな感じ(その他手元にあったものも貼ってます)。

センス良く配置するって難しいですね。僕みたいにセンスのない人は、少量をバランス良くというのは難しいと思うので、大量に買って埋め尽くすという方針が良いのでは と思いました。

というわけで、Macに貼る為のステッカーを購入してみたというお話でした。

追記

隙間が寂しかったのでもう少し埋めてみました!女子力高くなったやった!

f:id:nakazye:20160325225728j:plain

Spring Boot with JPA&React&Bootstrap4でWebアプリケーションを作ってみた

Java Spring React

進捗どうですか?

新年を迎えてからしばらく経ち、皆様当初の目標からの進捗はいかがでしょうか?

僕は全くダメです。

やりたいこと、やらないといけないなと思ってることは沢山あるんですが、「何をしようかなぁ」と考えているうちに、気づけば寝ていたり、気づけばデレステをやってる毎日です。マキノかわいい。

世の中にはタスク管理の手法は色々ありますが、それらはすべて「タスクをこなす意思がある人向け」であり、僕みたいな意思の弱い人間が、あれとこれをやりたいとリストアップしたところで、そのリストを前にした時点でうんざりしてしまうのは必然です。

リストを前にすると尻込みしてしまう。であれば、目に見えるタスクを一つだけにしてしまえばいい。 導入が長くなりましたが、そんなモチベーションから「タスクを一つ選び出すツール」を作ったお話です。

どんなアプリケーションを作ったか

こちらになります。

https://gachamaker.herokuapp.com

ソースコードはこちら。

github.com

どうせだったら、タスクを選ぶだけじゃなくて、デレステにインスパイアされた感じですがガチャ形式にしちゃおうという目論見です。

って訳で、別にタスク管理ツールとして使わなくてもOKです。

f:id:nakazye:20160321235414p:plain

こんな感じで、SSRとして息抜きを入れることができたら、楽しく生産的な日々を過ごせるんじゃ無いかなぁと思ったりした訳です。

技術的な話

サーバー

サーバーは相変わらずherokuを利用しています。久しぶりに管理画面にログインしてみましたが、まだ日本リージョンはまだ無いみたいですね。ちょっとしょんぼりです。

サーバーサイドアーキテクチャ

そして、サーバー側は、僕にしては珍しくJavaを使っています。Spring Bootを試してみたくて。

IntelliJを使ってセットアップしたんですが、ものすごく便利です。

f:id:nakazye:20160322000129p:plain

プロジェクト作成時に、必要なライブラリをこんな感じでぽちぽちしていくだけで終了です。Maven Archtypeなんていらなかったんや・・・コレは感動しました。

また、DBアクセスについては、JPA(hibernate)を使ってみました。SQL書かなくて良いのはいいんですが

  • OneToMayとManyToOne双方指定しないといけない
  • equalsとhashの実装が地味にめんどい(自動でやって欲しい)
  • 複数PKに対応しているのは良い(Djangoはできなかったはず)。けど、PKクラスを用意したりと面倒な部分もある
  • Entityからテーブル作ってくれるのは良い

と、便利な点と不便な点がある感じで。複雑なSQLとなるようなものを書いてないので正確には評価できませんが、そこが問題無いのであれば仕事でも使っていきたいなぁと僕は思いました。

フロントエンドアーキテクチャ

Reactを使ってみたくて試してみました。

僕が使ったことがあるのがBackbone+Marionetteだけなので比較対象が少ないですが、Backboneよりはコード量少なく、かつ見通しも良いなと思いました。

しかし、当初画面要素の一部だけをReactで作ろうとしたところ、Reactのアーキテクチャ的にそれが許されないことを痛感しました。

Virtual DOMという言葉は有名ですが、言い換えるとReactから触るにはReal DOMではなくVirtual DOM経由でアクセスしないといけない為、一部だけ通常のHTMLでってのがなかなか難しいんですね。

既存にあるアプリケーションを徐々に置き換えて・・・といった使い方はできなさそうだなぁと感じました。

なお、Reactはオフィシャルに日本語のチュートリアルがあるので、まだ触ったことが無い方は一度コレをやってみるのをおすすめします。

僕もここから入って、チュートリアル終わらせて、あとはググりながらこれを作った感じです。

facebook.github.io

あとは、Bootstrapを3ではなく4にしてみたのですが、このレベルであれば使い勝手はあまり3と変わりませんでした。

Componentsのドキュメントが、今まで1ページだったのが種類ごとに分かれて、見た目から「どれつかおうかなー」と悩めなくなったのが辛かったです。

v4-alpha.getbootstrap.com

まとめ

明日朝早いのでがーっと書きましたが、

  • Javaはやっぱりちゃちゃっと書くには大変。慣れもあるけどPython(Django)の方が僕はストレスたまらない
  • Reactはチュートリル後にいきなりアプリケーション作り始めることが可能なくらいには分かりやすい
  • Bootstrap4はまだα版だけど、特に問題には当たらなかった。が、ドキュメントが以前と比べて分かりづらく、やりたいことを見つけるのに一苦労
  • SSRが1.5%というのは、やっぱり絶望的

といったあたりでしょうか。

Spring BootもReactも、このアプリケーションを作るにあたって初めて触れた技術です。

みなさんも、何か自分が触ったことの無い新しい技術で、何かを作ってみると楽しめるかもしれません。

補足

ガチャの例はこんな感じです

https://gachamaker.herokuapp.com/deck/0eba6a49-f48b-4e03-a6ad-562c28134161

見ての通り、レイアウトがちょっと崩れてます。これは明日直したいな・・・と思ってる次第です

↑追記:直しました!

SpringにおいてJPAのEntityをRESTのJSON返却値としてそのまま用いる際の注意点

Java JPA Spring Framework

Spring Frameworkを使ってREST APIを作りつつ、その返却値としてJPAのEntityを使いまわそうとしたところエラーに悩まされ。その解決策について、日本語で書かれている情報がなかったので、ここに共有します。

問題が発生する条件

  • JPAのEntityを返却値として用いている
  • Entityの中でリレーションを定義している

が条件となります。

どのような問題が発生するか

JPAでリレーションを設定する際、親から子へのリレーションだけでなく、子から親へのリレーションも定義する必要があります。

具体的にいうと

/** 親テーブル */
@Entity
@Table(name = "parent")
public class Parent  implements Serializable {

    @Id
    String id;

    String name;

    @OneToMany(mappedBy = "parent",
            cascade = CascadeType.ALL,
            orphanRemoval = true)
    List<Child> children; // 子の定義

  // 略

    @Override
    public String toString() {
        return "Parent{" +
                "id='" + id + '\'' +
                ", name='" + name + '\'' +
                ", children=" + children +
                '}';
    }
}
/** 子テーブル */
@Entity
@Table(name = "child")
@IdClass(ChildPk.class)
public class Child  implements Serializable {

    private static final long serialVersionUID = 1L;

    @Id
    @ManyToOne
    Parent parent; // 親の定義

    @Id
    String childId;

    String name;

  // 略

    @Override
    public String toString() {
        return "Child{" +
                "parent=" + parent.getId() +
                ", childId='" + childId + '\'' +
                ", name='" + name + '\'' +
                '}';
    }
}

といった形になります。

つまり、オブジェクトの形としては、親は子を持ち、子を親を持っているわけで、循環参照の形態をとります。

これを

    @RequestMapping(value = "")
    public Parent create() {
        Parent result = service.getData();
        System.out.println(result);
        return result;
    }

としてParentを戻りとしてcontrollerを呼び出すと、consoleでは

Parent{id='1', name='one', children=[Child{parent=1, childId='a', name='1-a'}]}

と表示されますが、ブラウザ上では先ほどの循環参照の問題にあたり

f:id:nakazye:20160320003125p:plain

としてグロ画像的な表示になり

2016-03-20 00:27:34.369 ERROR 18687 --- [nio-8080-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is org.springframework.http.converter.HttpMessageNotWritableException: Could not write content: Infinite recursion (StackOverflowError) (through reference chain: com.example.entity.Parent["children"]->org.hibernate.collection.internal.PersistentBag[0]->com.example.entity.Child["parent"]->com.example.entity.Parent["children"]->org.hibernate.collection.internal.PersistentBag[0]->com.example.entity.Child["parent"]->com.example.entity.Parent["children"]->org.hibernate.collection.internal.PersistentBag[0]->com.example.entity.Child["parent"]->〜略〜com.example.entity.Parent["children"])] with root cause

java.lang.StackOverflowError: null
    at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_65]
〜略〜

とStackOverflowErrorを起こしてしまいます。

解決方法

stackoverflow.com

に解決方法がありました。

@JsonIdentityReferenceを指定してあげるだけです。JSONに変換する際に、持っているオブジェクトを展開するのではなく、そのオブジェクトのIDを使うようにしてあげる感じですね。

先ほどの例だとParent parent;に対して

    @Id
    @ManyToOne
    @JsonIdentityInfo(generator = ObjectIdGenerators.PropertyGenerator.class, property = "id") // このアノテーションを追加
    @JsonIdentityReference(alwaysAsId = true) // このアノテーションを追加
    Parent parent;

としてあげることで

f:id:nakazye:20160320004332p:plain

JSONが出来上がりました。説明するまでもないかもしれませんが、@JsonIdentityInfoにて何を当該オブジェクトの識別子として利用するか明示し、@JsonIdentityReferenceにて、参照先展開の代わりに識別子を利用しろと命じている感じです。

なお、@JsonIgnorePropertiesというアノテーションをクラスに指定し

@Entity
@Table(name = "child")
@IdClass(ChildPk.class)
 @JsonIgnoreProperties({"parent"}) // これを有効化することで、parent自体をjsonに含めない指定も可能
public class Child  implements Serializable {
〜略〜
}

として本例でいうところのchildが持つparentをJSONに出力しないことも可能です。

ソースコード

github.com

ということで、日本語でJsonIdentityReferenceとグーグル検索しても出てこなかったので記事にしてみました。

同じ問題に長時間はまる人が1人でも減ることを祈ってます(RESTなアプリケーション作るのに、Javaって選択肢がそもそもあんまり無いのかなぁとも思ったりしますが)