もうカタログを増やすだけの勉強は、やめた

はじめに

めずらしく読書記録でも、技術学習記録でもなく、ポエムであり、決意表明をする記事です。

きっかけ

転職活動中、ある会社とのカジュアル面談で、CTOの方と面談した。

CTOという肩書きの方と話すのがはじめてで、僕なりのその時点のCTOの役割は、技術をビジネス価値にするための責任を持つひと、だと思っていた。

転職活動中に考えたかったテーマ、"技術とは何か"について、自分の中で答えを持っておくべきだと思っていて、考えたかったことだった。

せっかくの機会なので、CTOという枠割のミッションや、技術とは何か、技術を高めるために必要なことは何か、ということをお話した。

CTOの役割

その方の答えは「技術を、企業成長、サービスの成長につなげること」で、必ずしも技術をビジネス価値、つまりお金に変えるとは思っていない、とのことだった。

さらに話を聞いた。

技術は問題解決のためのツール

エンジニアという人間は現実の課題、問題を解決してなんぼ。

問題解決にとにかく執着したという。

問題解決に執着することで、自然と技術がついてくる。問題解決への執着と、技術習得は両輪。

そう考えると、僕は、問題解決の量が圧倒的に足りないと思った。

技術だけを身につけること

技術ってなんだろう？の答えは置いておいて、技術知識だけを身につけて、問題解決をしないことは、カタログセットを持つだけで、エンジニアとして無価値だと思った。(これはこの話をしての僕の考えです)

前述するように、これは両輪で、問題を解決しないといけない場面に、自分の中のカタログがあればそれは心強いときもあるだろう。

でも僕は自己研鑽での学習を、問題解決に特につながるわけではないけど好きだから、興味があるから学んでいたことと、直近で困っているから解決するために学んでいることを、明確に区別できていなかったように思う。

そしてまわりの優秀なエンジニアは、問題解決のための技術学習を行っているなぁ、とハッとした。

これから

もうカタログを増やすだけの勉強はやめる。

問題を解決すること、みんながうれしくなることを実現に技術を使う。学ぶ。

開発業務の改善はしぬほどやってきて、問題解決をしてきた。今後はそれをベースに、プロダクト、サービス、ビジネス課題を解決できる領域に、僕は行きたい。

「イシューからはじめよ」を読んだ

はじめに

読んだ。

イシューからはじめよ―知的生産の「シンプルな本質」

評判もよかったということもあって、年始に読みました。が、ブログにあらためてアウトプットする時間が全然ないので読書メモという形で今回は記してクローズする。

読書メーターでの私の感想は以下。

各所で評判が良かったので読んでみたが、その通り良書でした。サイエンスとコンサルタント両方の経験がある筆者だから書ける考え方で、特に「分析」とは何で、どう見せるのか、という点についてはビジネスパーソンだけでなく、大学生/大学院生も読むべきだと思った。読み返して自分の仕事にどう当てはめることができるか再確認する。

bookmeter.com

以降はkindleのハイライトを順に追っていく。便利だなあ。物理本は最初からパラパラとめくって復習がしやすいけれど、特定箇所のマーキングが本に手をいれない限り難しい。逆に電子本は全体をパラパラめくるのは難しいが、ハイライトが素晴らしい。一長一短ですね。

「悩む」と「考える」の違いを意識することは、知的生産に関わる人にとってはとても重要だ。ビジネス・研究ですべきは「考える」ことであり、あくまで「答えが出る」という前提に立っていなければならない。

10分悩んでも解決しないなら1度休む。悩むことをするな、答えがある前提で答えに向かって考えろ、という最初の主張。「悩む」が自分の中で判断保留とも捉えられるので、答えを出せということですね。

それは「根性に逃げるな」ということだ。 　労働時間なんてどうでもいい。価値のあるアウトプットが生まれればいいのだ。たとえ１日に５分しか働いていなくても、合意した以上のアウトプットをスケジュールどおりに、あるいはそれより前に生み出せていれば何の問題もない。

どうしようもないときは根性に逃げがち。というか、せめて根性ぐらい出さないと、という考え方をしてしまう。本当によくないので反省。

プロフェッショナルとしての働き方は、「労働時間が長いほど金をもらえる」というレイバラー、あるいはサラリーマン的な思想とは対極にある。働いた時間ではなく、「どこまで変化を起こせるか」によって対価をもらい、評価される。あるいは「どこまで意味のあるアウトプットを生み出せるか」によって存在意義が決まる。そんなプロフェッショナル的な生き方へスイッチを入れることが、高い生産性を生み出すベースになる。

労働時間ではなく、バリューで答える、バリューでのみ評価される、そんな世界は怖いけれど、そっち側にいかないといけない。

問題に立ち向かう際には、それぞれの情報について、複合的な意味合いを考え抜く必要がある。それらをしっかりつかむためには、他人からの話だけではなく、自ら現場に出向くなりして一次情報をつかむ必要がある。そして、さらに難しいのは、そうしてつかんだ情報を「自分なりに感じる」ことなのだが、この重要性について多くの本ではほとんど触れられていない。

現場がすべてっていうのはいろんなところで言われてる気もします。まずはやってみる。マネジメント、リーダーといった実作業をしていないひとたちには本当の問題が何かわかりづらい。現場のつらさを救える働き方をしたいと思う。(ちょっとそれた)

「やってみないとわからないよね」といったことは決して言わない。ここで踏ん張り切れるかどうかが、あとから大きく影響してくる。

ウッ　言いがち。。。エンジニアリング、まず実験、まず動かすというのは大事な姿勢だが、ここは知的生産の場なので、それはダメだろう。

僕が「言葉にすることを徹底しよう」「言葉に落とすことに病的なまでにこだわろう」と言うと驚く人が多い。僕は「理系的・分析的な人間」だと思われているようで、そうした僕から「言葉を大切にしよう」というセリフが出ることが意外なようだ。

言葉にすることで、それが言葉として(一旦)確定される、というのは僕も普段から意識しています。明文化する、言語化する、技術文章であれば一意に取れるようにする。現在の課題も言葉にしてこそ共有される。言葉は大切。

人間は言葉にしない限り概念をまとめることができない。「絵」や「図」はイメージをつかむためには有用だが、概念をきっちりと定義するのは言葉にしかできない技だ。言葉（数式・化学式を含む）は、少なくとも数千年にわたって人間がつくりあげ磨き込んできた、現在のところもっともバグの少ない思考の表現ツールだ。言葉を使わずして人間が明晰な思考を行うことは難しいということを、今一度強調しておきたい。

思考はどこで行うか？という話がありますが、こうやって文章にしながら思考もできますよね。言葉にすることを諦めたら本当に試合終了だと思う。

分析の大半を占める定量分析においては、比較というものは３つの種類しかない。表現方法はたくさんあるが、その背後にある分析的な考え方は３つなのだ。このことを押さえておくだけで分析の設計がぐっとラクになる。では、この３つの型とは何だかわかるだろうか？　答えは次のようなものだ。 　１　比較 　２　構成 　３　変化 　どれほど目新しい分析表現といえども、実際にはこの３つの表現のバラエティ、および組み合わせに過ぎない

後半は分析方法について。「何がイシューなのか」を考え抜いて定めた上で、そのイシューをどう解決すべきかをデータを使って説得する、知的生産はこのシンプルな方法で行うという話でしたね。

脳は「異質な差分」を強調して情報処理するように進化してきており、これは脳における知覚を考える際の根源的な原理のひとつだ。そしてこれが、分析の設計において明確な対比が必要な理由でもある。明確な対比で差分を明確にすればするほど脳の認知の度合いは高まる。そう、分析の本質が比較というよりは、実は私たちの脳にとって認知を高める方法が比較なのだ。そして、私たちはこれを「分析的な思考」と呼んでいる。

分析とは何か？に着目したときに、必ず比較が必要ということですね。どちらかというと、ひとが「わかる」ために比較が必要、という話を聞いたことがあります。比較というか、自分が今まで経験して、知っていることと結びつけて理解するという話。それに少し近いのかな。

分析イメージを設計する際（第４章で詳説）には、同じような分析の型が続かないようにすることが重要だ。私たちの脳は異質な差分しか認識しないため、同じかたちのグラフやチャートが続くと、２枚目以降に関しては認知する能力が格段に落ちる。同じかたちが３枚続けば大きなインパクトを与えることは相当難しくなる。チャートの表現レパートリーは多くもち、極力同じかたちが続かないように工夫する。

ストーリーとしての、分析の続け方も、同じ方法を極力取らないことを強調。

ここで異なる情報をもった２つ以上のニューロンが同時に興奮し、それがシナプスでシンクロ（同期）したとき、２つ以上の情報がつながったということができる。すなわち、脳神経系では「２つ以上の意味が重なりつながったとき」と「理解したとき」は本質的に区別できないのだ。これが第３の特徴、すなわち「理解するとは情報をつなぐこと」という意味だ。

さっきの理解の話はここでしたね。

何度も情報のつながりを想起せざるを得ない「なるほど！」という場面を繰り返し経験していると、その情報を忘れなくなる。当たり前のように思えるが、これは日常ではあまり意識されていない。

これのもっと激しいのが「そういうことだったのか！」ってやつ。すっげー気持ちいいよね。

このようなカギとなるサブイシューを検証する場合は、どちらに転ぼうと意味合いが明確になるタイプの検証を試みるようにする。答えを出そうとしている論点を明確に認識し、右なのか左なのか、それに答えを出すのだ。

どっちに転んでも有益なイシューを選ぶこと。意識したことなかった。「できないということがわかった」ってやつだよね。

(自分の知識や技では埒が明かないときにどうするか？) もっとも簡単なのは「人に聞きまくる」ことだ。格好よく言えば「他力を活用する」わけだ。それなりの経験ある人に話を聞けば、かなりの確率で打開策の知恵やアイデアをもっているものだ。運がよければ同様のトラブル時にどのようにして回避したかを教えてもらえることもあるし、通常では手に入らない情報の入手法を聞けることもある。自分の手がける問題について、「聞きまくれる相手」がいる、というのはスキルの一部だ。自分独自のネットワークをもっているのは素晴らしいことだし、直接的には知らない人からもストーリーぐらいは聞けることが多い。

人に聞ける、人を頼れるのってかなり重要なスキルで、僕はこれが苦手だと自覚しています。聞きまくれる後輩くんうらやましい。。。

(リチャード・ファインマンについて) 「いわゆる天才とは次のような一連の資質を持った人間だとわしは思うね。 　●仲間の圧力に左右されない。 　●問題の本質が何であるかをいつも見失わず、希望的観測に頼ることが少ない。 　●ものごとを表すのに多くのやり方を持つ。一つの方法がうまく行かなければ、さっと他の方法に切り替える。 　要は固執しないことだ。

多くのやり方を持つことできるの、大事だなあ、普段から鍛錬しないといけない気がする。固執しないために必要。

１回ごとの完成度よりも取り組む回数（回転数）を大切にする。また、90％以上の完成度を目指せば、通常は途方もなく時間がかかる。そのレベルはビジネスではもちろん、研究論文でも要求されることはまずない。そういう視点で「受け手にとっての十分なレベル」を自分のなかで理解し、「やり過ぎない」ように意識することが大切だ。

真面目だからやりすぎてしまう。。。これも何が求められるレベルなのかをすり合わせないといけないと思う。まず早く出して、フィードバックをもらうことだね。

ひとつ、聞き手は完全に無知だと思え 　ひとつ、聞き手は高度の知性をもつと想定せよ 　どんな話をする際も、受け手は専門知識はもっていないが、基本的な考えや前提、あるいはイシューの共有からはじめ、最終的な結論とその意味するところを伝える、つまりは「的確な伝え方」をすれば必ず理解してくれる存在として信頼する。「賢いが無知」というのが基本とする受け手の想定だ。

今回の案件で、自分の案件の技術的なことについて、普段全然話さない他部門のひとに話してさっぱり伝わらなくて苦労した。相手の知識レベル、技術レベルがどうしてもわからなかった。ただ、事前知識を持たないという意味での無知と、適切な情報を与えれば理解はできる(極度にレベルを下げ過ぎない)高度な知性の想定は重要な視点だと思いました。

コンサルタントは高いフィーをもらう代わりに確実に変化を生み出し、クライアントに喜んでもらうのが仕事だ。科学者も限られた時間のなかできっちりと成果を生み出すのが仕事という点は変わらない。いずれも結果に対する強い自己ドライブがないと仕事を楽しめない。報酬は年棒だけで「時間外労働」という概念の一切ない世界においては、こうした考え方をしていないと最悪の場合、奴隷のような生活になってしまう。

コンサルタントと科学者の共通点。両方経験した著者ならでは。

「人から褒められること」ではなく、「生み出した結果」そのものが自分を支え、励ましてくれる。生み出したものの結果によって確かに変化が起き、喜んでくれる人がいることがいちばんの報酬になる。仕事がうまく進んだとき、僕が感じるのは「うれしい」というよりも「ほっとした」というものだ。自分の会社やクライアントに約束した価値を無事届けた、このこと自体が何とも言えない達成感を生む。 　この価値を生み出す根っこにあるのが、「イシューからはじめる」という思想であり、脱「犬の道」という考え方だ。これをしっかりともつだけで僕らの生活は格段にラクになる。そして毎日が格段に充実したものになり、一日一日で生み出す価値は遥かに大きなものになっていく。 　このことを最後に共有できたら、と思う。

人から褒められることも嬉しいけどね。出した結果でさらに褒められるといいよね。僕はまず自分のチームのために大事なことを生み出して、そしてビジネス価値を組織に出していく働き方をしていきたい。

おわりに

kindle便利やな。

「TeamGeek」を読んだ

はじめに

読んだ。たまたま訪問してカジュアルに面談したとき、とある部長さんが求める人材像のところで、HRTのくだりがでた。「TeamGeak」って読んだことありますか。と問われ、なかったので訪問後即購入。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

章ごとに内容を振り返っていく。

1章 天才プログラマの神話

まずこの章は「チームでうまくやること」の必要性について、いろいろな例をあげて説明されている。

天才は「チームとうまくやる」天才

やはりこの章で印象深い言葉はおそらく多くのひとと同じで以下だと思う。

だが、ちょっと待ってほしい。現実的に考えてみよう。君は天才じゃない。(p7)

天才とまではいかなくても、1人で十分に成果を出せる優秀なプログラマだと思ってるひともいるかもしれない。(僕はまったく思わないが)

仮に君が天才だったとしても、それだけでは不十分なんだ。天才だってミスをする。優れたアイデアやプログラミングスキルがあっても、開発したソフトウェアが必ずしも成功するとは限らない。今後のキャリアがうまくいくかどうかは、同僚たちとうまく協力できるかにかかっている。(p7)

スティーブ・ジョブズ、マイケル・ジョーダンといったスーパースターをあげ、誰もが"天才"というロールモデルを設定したがり、それになろうとする。だが実は彼らは「チームとうまくやる」天才だったのだ。

Linuxカーネルの作者リーナスの功績は偉大だが、何よりLinuxコミュニティを継続して発展させたことがもっとも偉大とされるのも同じだ。

プロジェクトのバス係数を減らせ

最近は「オープン」という価値観が広がってきているように（個人的には）感じるけれど、やっぱりみんな隠すよね。自分が書いたコード。見せたらいいのに。

素晴らしいアイデアを隠しておいて、それが完成するまで誰にも話さないというのは、リスクの高い大きな賭けだ。早い段階で設計ミスをしやすくなるし、車輪の再発明をする可能性があるし、誰かと協力するメリットが失われる。(p9)

トラックナンバーともいうが、プロジェクト内で何人バスに轢かれたらプロジェクトが破綻するかをバス係数という。つまり、自分しか持たない情報を作らないこと、すなわち常にフルオープンにしておき、いつ自分がいなくなってもいいようにしておくことが重要である。これにはとても同意する。なかなかできることではないらしい。自分が心がけていることのひとつ。（仕事はすべてgitにある。）

これに関しては今の職場ではかなりできていると思うし、自分が率先して進めてこれたと思う。mattermostによる個人部屋、分報の導入で悩みや業務内容をクリアにしたし、トラブル調査内容、ノウハウはチケットに記載すること、ツール類はcloneして使えるよう整えてgitに格納、などなど「引き継ぎに一週間必要です」が死ぬほど嫌いな僕が努力し、率先して実践し、勧めてきたのは正しいことだったと思う。

チームがすべて

ここは引用のみで。

ソフトウェア開発はチームスポーツである(p13)

さらに

隠れ家に1人でいたら、才能が開花することもない。秘密の発明をこっそり準備していたら、世界を変えることもできないし、数百万人のユーザーを喜ばせることもできない。誰かと一緒に仕事をしなければないけないんだ。ビジョンを共有しよう。仕事を分担しよう。他人から学ぼう。そして素晴らしいチームを作るんだ。(p13)

三本柱 - HRT

本書の主張はこれに尽きるといっても過言ではないと思う。

• 謙虚(Humility)
• 尊敬(Respect)
• 信頼(Trust)

この3つ。今のチームはこれがあるチームなので本当に恵まれていると思います。

2章 素晴らしいチーム文化を作る

DevOpsのくだりが記憶に久しいですが、「文化を作る」という言葉はちょっと取り扱いが危険です。行動の結果が文化になるので、文化先行だとダメだ、なんて意見も見たことがあります。

パンの喩えがあったので引用しておきます。

スターター(創業者)がパン生地(新来者)に菌(文化)を植え付ける。イースト菌と乳酸菌(チームメンバー)が発酵(成長)すると、おいしいパン(チーム)のできあがりだ。(p32)

パン作りしたことないのでわかりづらい。。。

が、どの会社も独自の文化を持つ。その文化を最初に作るのは、最初にいたメンバー(スターター)だろう。その後も文化は変化/成長し続ける。

チームの文化の定義・維持・防御に責任を持つのはチームメンバーだ。誰かが新しくチームに参加したときは、チームリーダーから文化を教えてもらうのではなく、チームメンバーから学ぶのである。'p34)

文化という言葉は何気なく使っているけどここで意味を再確認しておこう。

www.weblio.jp

① 〔culture〕 社会を構成する人々によって習得・共有・伝達される行動様式ないし生活様式の総体。言語・習俗・道徳・宗教、種々の制度などはその具体例。文化相対主義においては、それぞれの人間集団は個別の文化をもち、個別文化はそれぞれ独自の価値をもっており、その間に高低・優劣の差はないとされる。カルチャー。

ふむ。チームの行動様式ということですね。

その後はよりよいチーム文化の例を、コミュニケーション、議論、コードの観点で紹介されている。

3章 船にはキャプテンが必要

リーダーシップについて語られているのが本章。かなり注意深く「マネージャ」という言葉を使わないようにしている。役職上マネージャーというのは現在でもあるだろうが、そこは話題の外のようだ。実際、人モノ金を管理するマネージャーも、リーダーであるべきだし、それこそ後に出るサーバントリーダーであることが望ましいだろう。

サーバントリーダーとは、従来の「管理」するマネージャー（リーダー）と異なり、チーム全体を謙虚・尊敬・信頼の雰囲気を作り出すリーダーのことだ。

これはエンジニアでは対処できない社内の障害物を排除することかもしれないし、チームの合意形成を支援することかもしれない。あるいは、夜遅くなったときにチームに夜食を買ってくることかもしれない。(p69)

サーバントリーダーはチームにアドバイスを与えるだけでなく、必要であれば　チームが順調に進めるように穴を埋める。自らの手を汚すのがサーバントリーダーだ。サーバントリーダーが管理するのは、技術的な側面とチームの人間関係である。両方やらなくっちゃあならないってのが「サーバントリーダー」のつらいところだな（人間関係のほうが難しい！）(p70)

これもうちの上司はできていて本当にすごいなぁと思います。僕だったらメンバーに僕がいたら僕の仕事を信頼して任せられない（笑）

サーバントリーダーは最近だとマイクロソフトの牛尾さんが、ロッシェル・カップさんと共同でやられているのを見ました。

simplearchitect.hatenablog.com

アンチパターンはそりゃそうだよなーって感じなので目次だけ。

• 自分の言いなりになる人を採用する
• パフォーマンスの低い人を無視する
• 人間の問題を無視する
• みんなの友達になる
• 採用を妥協する
• チームを子どもとして扱う

面白かったのはリーダーシップパターンですね。うちのリーダー/マネージャーは本当に鋼の心というか、まさに「禅マスター」なんですよね。。。すごい。。。

たとえ何が起きても、どんなにひどいことが起きても、どれだけの惨事が起きても、彼は決してパニックにならなかった。彼はいつも片腕を胸に当てて、もう片方の腕でアゴを押さえ、問題の状況をエンジニアに質問した。(p79)

うまく（時にはジョークをまじえて）質問することで、パニックになるエンジニアを落ち着かせる質問をするという。うちのリーダー/メンバーは大規模障害でもとても落ち着いてるので本当にすごいと思います。。。

管理ではなく、"信頼"した上でどんどん委譲していくこと。大事ですよね。

リーダーシップパターンも目次を載せておきます。

• エゴをなくす
• 禅マスターになる
• 触媒になる
• 先生やメンターになる
• 目標を明確にする
• 正直になる
• 幸せを追い求める
• その他ヒントやトリック
  • 委譲せよ。ただしては汚せ。
  • 自分自身に置き換えようとする。
  • 事を新たてるときを知る。
  • カオスからチームを守る。
  • チームを空中擁護する。
  • チームのいいところをフィードバックする。

リーダーシップとして大切なことが詰まってる章です。何度も読みたい。

4章 有害な人に対処する

言葉にウッときそうだが、チームを破壊するような"振る舞い"を排除することをだと、注意深く説明されている。

大切な"良いチーム文化はどのように守られ、継続され、必要に応じて進化していくかというと

文化が長続きしているのは、高い基準を設けているからではなく、その文化が自己選択的だからだ。素晴らしい人たちは、素晴らしいコミュニティに惹きつけられるのである(p101)

有害な振る舞いからチームを守るためには、ミッションステートメントを決めて、文化を強固にしておくことが大切だ。

どんな振る舞いが有害かというと、目次を貼っておく。

• 他人の時間を尊重しない
• エゴ
• 権利を与えすぎる
• 未熟なコミュニケーションと複雑なコミュニケーション
• パラノイヤ
• 完璧主義

そのひとが意図しているしていないに関わらず、プロジェクトの生産性の影響を与えることですね。

このあと追い出し方まで丁寧に書かれています。この章はどちらかというとオープンソースコミュニティの運営に役立ちそうな章だと思いました。

有害な人を追い出す、の目次貼っておきます。

• 完ぺき主義には別の方向性を示す
• 生命体にエサを与えない
• 感情的にならない
• 不機嫌の真実を探せ
• 優しく追い出す
• 諦めるときを知る
• 長期的に考える

最後にも注意があり、多くのひとは望んでプロジェクトに不利益を出しているわけではない。

無能で十分説明されることに悪意を見出すな(p116)

よくわかっていない人をプロジェクトから追い出すことが君の仕事ではない。破壊的な振る舞いを受け入れず、HRTに対する自分の期待を明確にすることが君の仕事だ。そのためには、その違いを理解する頭と実際に行動するスキルが必要である(p116)

継続して健全なチーム文化を守るためには必要なことですね。

5章 組織的操作の技法

この章はチームや、コミュニティから少し枠を超えて、組織という少し大きい単位での悪い例(悪いマネージャ、悪い組織)をあげ、それに対する切り抜け方が乗っている。気になった節のメモだけ。

許可を求めるより寛容を求めるほうが簡単

まずは組織で許されていることを把握しよう。許可を求めると責任を押し付けることができるが、逆に「ダメ」と言われる可能性もある。上司の許可を得なくてもできる範囲を知ることが重要だ。ただし、可能なかぎり会社にとって正しい事をしよう。(p132)

これ本当その通りだと思います。現在は寛容な部なので助かっている。。。

道がないなら道を作る

会社でチャンスを作るもうひとつの戦略は、草の根レベルでアイデアを受け入れてもらうことだ多くの人にアイデアを受け入れてもらったり、プロダクトを使ってもらったりすれば、たとえ官僚組織であってもつぶすことはできない。マネジメントもそのことに気づかざるを得ないので、受け入れるか抵抗するかになるだろう（抵抗すると政治資本が必要になる！）。これは多くのエンジニアが長年使ってきた戦略だ。たとえば、毎日の仕事が楽しくなるように、オープンソースツールをこっそり取り入れるのである。(p133)

これもやってますね、別に戦略的にやってるわけじゃないんですが（笑）

上司の管理方法を学ぶ

「マネージャーをマネージせよ」とはよく言ったもので、自分のためにうまく伝えよということである。

君が「うまく」やっていることを上司やチームの外部にいる人たちに知らせる必要があるということだ。

ここで「攻撃的」な仕事と「防御的」な仕事がでてくる。プロダクトのローンチという政治資本の増加につながる仕事は攻撃的な仕事で、リファクタリングや保守といったものが防御的な仕事。防御的な仕事も大事だが、その割合は全体の1/3〜 1/2になるようにせよとアドバイスがある。とはいえ大きい企業だと「攻撃的」な部と「防御的」な部になってしまいがちだが。。。

運と親切の経済

運は親切によって強化することができるという話、面白いと思いました。

自分の仕事に関係がなくても、他の人の仕事を手伝うようにすれば、その人から恩返しされる保証はないが（もちろん「しっぺ返し」もないが）、いずれ誰かが喜んで手伝ってくれるようになる。(省略)親切の経済で少しだけ信頼を稼ぐことができる。この信頼は掛け金のようなものだ。

6章 ユーザーも人間

最後に作ったプロダクトを使うユーザーについての章。ユーザーにとって使いやすいソフトウェアを作りましょう、ユーザーに対して良好な関係を築きましょう。ここでもHRTが出てきますね。

マーケティング ソフトウェアがどのように見られるかに気を配ろう。それによって、ソフトウェアを使ってもらえるかどうかが決まる。 ユーザビリティ ソフトウェアが簡単に試用できなかったら、遅かったら、使いにくかったら、アクセスできなかったら、ユーザーは立ち去ってしまうだろう。 顧客サービス ユーザーとの長期的な関係構築が、ソフトウェアの進化やユーザーの定着に影響を与える。(p177)

プログラマの仕事には中断がいっぱいだ。(中略) ソフトウェアを書く理由を簡単に忘れてしまう。そのソフトウェアは君のためではない。チームのためではない。会社のためではない。ユーザーの生活を豊かにするためである。ユーザーがプロダクトについて何を考えているか、何を言っているか、何を体験しているかに注目することが、長期的に重要なことになる。ユーザーはソフトウェアの成功に欠かせない血液だ。自分でやったことは、すべては自分に返ってくる。

おわりに

付録でも言っているが、本書で述べられていることはソフトウェアに限った話ではなく、あらゆるコミュニティでHRTが重要であり、あらゆる問題はHRTいずれかの欠如によって起きるものだとしている。その通りだと思う。

その認識をもとに、あとの章で語られているサーバントリーダーシップ、有害なひとの排除、組織を有効に活用すること、ユーザーを大切にすることはそれぞれ適した場面で役にたつだろう。その折に読み返したい。

「エキスパートのためのMySQL運用＋管理トラブルシューティングガイド」を読んだ

はじめに

読んだ

エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

業務ではMariaDBを使っているが、正直MariaDBとの差を明確にわかって使っているわけではない。しかし、トラブル時も調査の方針、方法などはMySQLのものも参考になると思い、購入。

ただし、全部は読んでない。自分の中にインデックスをつけるのが目的。

第1章 MySQLの概要

その名の通り概要です。MySQLのことをよく知らないひとでも安心できる、親切設計ですね。不足している方は読んでおいたほうがいいでしょう。

5.7本でもこの手の解説はありましたね。

詳解MySQL 5.7 止まらぬ進化に乗り遅れないためのテクニカルガイド (NEXT ONE)

take-she12.hatenablog.com

また、構造的な特徴について興味がある方はさらにこちらを見るといいとのこと

詳解MySQL

プラガブルになっていてストレージエンジンを変更できることや、レプリケーション機能について記載しています。ディレクトリ構造やシステムデータベースの内容も丁寧に解説されています。my.cnfの設定解説と設定例までついてるので、1章だけでも相当詳しい内容ですね。。。

タイトルに運用/管理とある通り、この章でも堅牢に運用するためのTipsが乗っています。

1. mysql_secure_installation
2. DNSへの問い合わせを取り除く
3. (clientが同一ホストにいる場合)TCP/IPを使用しない 4.(クラッシュリカバリのために)バイナリログを有効にする
4. (オーバヘッドになるような)クエリキャッシュを利用しない
5. メモリのサイジング
6. ディスクキャッシュに関する注意点
7. InnoDBにおけるディスク関連のチューニング

さらにインストール時のよくあるトラブル対策まで。。。見事な1章だ、これ1冊で本になれるぐらいですね、さすが。。。

第2章 開発時のおける問題

文字化け

MySQLの文字化け/文字コード問題は私もMariaDBでぶつかったことがあります。p112の図2-1はよく覚えておきましょう。

         1     2          3,4  5
client ---> session ---> table--->filesystem
       <---         <---      <---
         6

1. 送信するSQL文の文字コード
2. クエリの実行に利用する文字コード
3. データを蓄える際の文字コード
4. テーブル名やカラム名に対する文字コード
5. ファイル名を解決する際の文字コード
6. クエリの実行結果に対する文字コード

それぞれで文字コードを設定可能で、異なる場合はMySQLが変換してくれるようです。しかし、統一したいですね。。。

p126、データがlatin1で格納されてしまっている問題、出会いました。。。

幸か不幸か、latin1文字コードを接続文字コードとテーブルの文字コードの両方で使用している場合、マルチバイト文字をそのまま格納することができてしまいます。(latin1はシングルバイトなので、ちょうどでコードされたような形でデータが格納されてしまいます)

MySQLのデフォルトの文字コードはサーバ側もクライアント側もともにlatin1なので、文字コードの設定が抜けていても、上記のように、問題なく日本語の入出力ができてしまいます。そのため、設定が抜けていることに気づいてもらえない、かわいそうなMySQL Serverが世の中にはたくさん存在していることでしょう。

いるやろなぁ。。。

以下の問題が発生します。

• 称号順序が狂ってしまう(latin1_swedish_ciを用いて1バイトずつ比較されてしまう)
• 本来の文字コードを指定して接続すると、文字化けしてしまう

特に後者の問題は、システムの刷新に伴うデータ移行などをする際に発覚することが多いものです。

まさにそれだった。。。

アプリケーションを含めて、1番最初に設定しておくべきですね。

MySQL CLI上のエラーを理解する

MySQL CLI上でのエラー対処の方法です。大前提として、3つのレベルがありますね。

• ERROR 重大なエラー。SQL文が実行できなかったことを示します
• WARNING 影響度が大きいエラー。SQL文は実行できたが、何らかの副作用があり、要求を完全に満たすことができなかったことを示します。
• NOTE 補足的なメッセージ。SQL文の実行には問題ありません。

多分、log_levelの設定値で、errlogにどこまで出すかを設定できるはずですが、SHOW WARNINGSコマンドで直近(直前？)のSQLのwarningが見れるようですね。

おもしろいのが以下

SHOW WARNINGSコマンドを利用してエラーメッセージを表示する際に気をつけなければいけないのは、SHOW WARNINGSコマンドが保持する渓谷の内容は直前に実行したSQL文のものだけだということです。(最悪のパターンは、SHOW WARNINGSのスペルを間違ってしまうことです)

やっぱり直前のみなんですね。

よく、ストレージエンジンのエラーとしてまとめられるのをみますが、perrorコマンドっていうのがあるんですね。はじめて知った。

ERROR 1030(HY000): Got error 139 from storage engine

に対して

shell> perror 139
MySQL error code 139: too big row　（行のサイズが大きすぎるよ！9

エラーコードの意味を教えてくれるんですね。

トランザクション

ACID特性と分離レベルについての解説がまずあります。

そして高度なトランザクション時のトラブル事例が乗っていますね。ロストアップデートとか、クラッシュ時のエラー回復など。

SQLモード

SQLに対して、どのような尺度で受け入れるのか、切り捨てるのか、エラーにするのかを決定する変数群のこと。これがバージョンによってデフォルトが違ったりするからこの概念を事前に知っておくのは重要。

アプリケーションによるエラーハンドリング

アプリケーション(client)側からみた、MySQLがエラーとなったときどのような例外にすればいいかが記載されています。重要だ。。。！

各言語ごとの補足方法、クラスも書いてあって親切だー！今のところアプリと1から書く経験に出会えていませんが、そのときは参照したい。

第3章 MySQLの状態を見る

SHOWコマンドとINFORMATION_SCHEMA

SHOWコマンドとINFORMATION_SCHEMAは同じ情報源から情報を取得してるんですね。

SHOWコマンド

SHOW VARIABLEやSHOW STATUSは普段から使ってます。特にSTATUSはどのようなものがあるか知っていたほうがいいですね。

よく見るのはConnectionでしょうか。handler〜はストレージエンジンに対しての捜査が行われた回数のようです。累積なのかな。定期的に取得することでどのぐらいの書き込み量があるのかがわかりそうです。

connectionについてはMax Used Connectionが最大風速を記録してるので便利ですね。

SHOW TABLE STATUSはテーブルごとの各種情報(例えば文字コードとか)を引き出すのに使えそうです。COLUMNS、INDEXも同様です。

レプリケーションをするしないのかかわらず、binlog出力する場合はSHOW BINARY LOGSはかなり使いますね。レプリケーション関連はMySQLのレプリケーションを使ってないので飛ばしました。

SHOW CONTRIBUTORSってコマンドもあるんだ、面白いね。

INOFORMATION_SCHEMA

すべての情報はこのテーブルにあるようですから、SHOWコマンドでとれる情報も元はこちらにあります。

細かく取得したかったり、SHOWコマンドで望み通りの形式で取得できない場合はこちらからとってくればいいでしょう。

SHOWコマンド廃止論もあるようですが、まだSHOWコマンドでしか取れない情報があるようです。

EXPLAIN

効率の悪いクエリを調べる時に使用します。今の所そのシーンに出くわさないのでスキップ。

プロファイリング

EXPLAINがクエリに実行計画であることに対して、プロファイリングはクエリがどのように(実際に)実行され、どのようなリソースが消費されているかがわかるツールです。

変数profilingで有効にし、クエリを実行したあと、SHOW PROFILEで実行できます。簡単ですね。

これもEXPLAINと合わせ、性能改善等でクエリを調べる時にまた見返したいと思います。

MySQLのログ

大事な6つのログ。復習しておきましょう。

• エラーログ
• バイナリログ
• 一般クエリログ(generallog)
• スロークエリログ
• トレースファイル(MySQL server本体をデバッグするときに利用)
• ストレージエンジンが作成するログファイル
  • 上記のログと混同しない、WAL概念におけるログ。

InnoDBモニタ

これまではMySQLレイヤでの情報収集方法でした。InnoDB(ストレージエンジン)レイヤではより詳しく情報を取得できます。

SHOW INNODB STATUSコマンドを実行したことがない人は、いないでしょう。

はい。

本当によく見るし、負荷があがってきたり、待たされてるクエリが増えるとエラーログに急に吐き出してドキッとするよね。

しかしこの本に詳しく解説があったとは、もっとはやく知っていたかった。次トラブル起きた時にみよう。。。

テーブルモニタ、テーブルスペースモニタも、特定のテーブルで問題が発生した時に役立ちそうですね。

システムの状態を調べる

MySQLではなく、OSレベルでの調査コマンドについて解説されています。親切だ。。。！

システムの状態を知る

• uname(OSのタイプ)
• df -h(ディスク情報)
• ps(プロセス)
• stat/file/fuser/lsof/strings/nm(ファイルやディレクトリ)

システムリソースを調べる

• free(空きメモリ)
• vmstat(メモリ使用情報)
• top(CPU/メモリ使用状況)
• ipstat(ディスクI/O状況)
• netstat(NICごとの統計情報)
• sar(システムの統計情報を詳細に調べる)

ネットワークを調べる

• ifconfig
• netstat
• traceroute
• nslookup
• ping

プロセスのメタデータを格納する/procディレクトリ

• /proc/cpuinfo(CPU情報)
• /proc/meminfo(メモリ使用状況)
• /proc/sys/fs/file-max(システム全体で同時にopenできるファイル数)
• /proc/sys/fs/file-nr(現在openされているファイル数)
• /proc/sys/kernel/threads-max(システム全体で同時に作成することができるスレッド数)

上記はシステム全体ですが、これらはプロセスごとに調べることができます。知っておくべきですね。

第4章 DTrace

はじめて知りました。Solaris、Mac OS X、Free BSDで使える、システム追跡ツールのようです。今のところLinuxメインなので使う予定はありませんが、存在は知っておきます。

D言語もはじめて知った。。。！

https://ja.wikipedia.org/wiki/D言語

第5章 運用中に起きる諸問題

レプリケーション

MySQLのレプリケーションに関する問題なので、(現在使ってないこともあり)スキップ。

MySQL単体のトラブルより、レプリケーションのトラブルのほうが多そうです。トラブル事例は役に立ちそう。

また、レプリケーションを堅牢にするためのテクニックは、他のレプリケーション(クラスタ)システムを使っていても同様のことが言えそうです。羅列しておきます。

• マルチマスターレプリケーションを利用しない(そもそも安全じゃないよ)
• スレーブを更新しない(当たり前ですね。。。)
• 適切なモードを選ぶ(レプリケーションモードのこと。行(ROW)ベースかSTATEMENTベースかMIXか。ROWが好ましいかな。
• テーブルにPRIMARY KEYを付ける(RowBaseのReplicationでは必須)
• バイナリログを同期する(ディスクとbinlogの同期)
• ハードウェアと設定、バージョンを合わせる(マスタだけ豪華にするのは好ましくない)
• スレーブを複数用意する
• 一度に大量の更新をしない
• 負荷分散に対応した接続方法を利用する
• 堅牢なネットワークを利用する(信頼性の高いネットワーク)
• テンポラリテーブルを使わない
• 監視する

クラッシュ

MySQLのクラッシュが起きてしまった時の対処について。workaroundとして回避するか、ソースコードを修正するの2択がある。

(OSやハードではなく、)MySQL自身の問題によってmysqldがクラッシュしてしまった場合、その原因の99.999%はMySQLのバグによるものです。

つまり使用方法によって起きることはほぼないってことですかね。

特定にはOSと、MySQLのソースコードレベルの深い知識が必要そうです。

• シグナル
• スタックとレース
• コア解析(GDB)

クラッシュリカバリ

InnoDBのクラッシュリカバリだけ見ておきます。

InnoDBのWALの仕組みの解説から。こういうところが新設だよね。

InnoDB(MySQL)を含む多くのRDBMSではWALの仕組みが搭載されています。ログとテーブルスペース両方に書き込むことによって、少なくともいずれかには書き込まれている状態にすることでクラッシュ時にも自動でリカバリする仕組みです。すばらしい。

さらに堅牢にするためのダブルライトバッファ、MVCCのためのロールバックセグメンとなど、クラッシュリカバリの説明の章ですがInnoDBの基本的な用語と動きが丁寧に解説されています。素晴らしい。

テーブルスペースが壊れていないかの確認のためにダブルライトバッファがあり、リカバリのためにログがあるって感じですかね。

テーブルの破損

万が一破損してしまった場合の復旧の手引き。REPAIR TABLEやinnodb_force_recoveryの紹介があります。

p373にあるバージョンアップよる照合順序の修正が怖いですね。mysql_upgradeか、ALTER TABLEで救えるのか。

性能の低下

まずスロークエリログで遅いクエリを特定したのち、改善計画について説明されています。頼もしい。

• ハードウェアの増強(スケールアップ)
• レプリケーションによる負荷分散(スケールアウト)
• Shardingによる負荷分散
• memchaced

ハードウェア障害

コンピュータの代表的なパーツが壊れたときの対処法を以下に紹介します。

ネットワーク、CPU、メモリ、ディスクとそれぞれ壊れた時の対処法が載っています。

第6章 堅牢な運用を実現するために

バックアップとリストア

これ超大事ですね。基本的な使い方を押さえておかないと、結構難しいのです。--single-transactionをつけないでロックになっちゃって痛い目にあったこともあります。。。

mysqldumpだと、リストアに時間かかるのが難点。フルダンプ＋binlogによる差分dumpを使ってうまくリストアするのがよさそうです。ロールフォワードリカバリーは便利。もっとはやく知っておきたかった。

ちなみにPerconaのXtra Backupはmysqldumpより早いらしい。いいなあ。表6-1の比較表もうれしいですね！

High Availability

p410 表6-2がクラスタソフトウェアの巨大な比較表です。すげえ。。。HAクラスタにもデータをシェアすつタイプと、シェアしない、シェードナッシングタイプがあっていろいろですね。

ネットワークの冗長化についてもMySQLレベルの話ではないですが記載されています、(Link Aggregation) 確かに、接続ネットワークが切れては話になりませんしね。

あとは使ったことないですがMySQL Clusterですね。確か有償？

セキュリティ

商用で使う場合はセキュリティが必須ですね。不正ログインを防ぐように適切な権限設定をしたり、SSLで暗号化したり、SQLインジェクション対策したり。重要。

アップグレード

これも誰しもが運用中ぶちあたる問題ですね。これももっとはやく見ておきたかった。。。大事な文言があります。

よく「新しいバージョンにはバグ修正によって新たなバグが含まれていることがあるのでアップグレードはしない」というシステム管理者がいますが、これはナンセンスです。もし、新しいバージョンでいくつかのバグが修正されていることがすでにわかっているならば、道のバグの可能性を含んでいる新しいバージョンよりも、既知のバグが確実に修正されている新しいバージョンのほうが安定していると考えるべきです。(p471)

すべてのオープンソース・ソフトウェアに通じる話ですね。

どのようなときにアップグレードすべきかは大事な考え方ですねー。

アップグレードの概要(計画)はぜひ参考にしてスケジュールを組みたいところです。すばらしい。

MySQL(MariaDB)のupgradeが骨が折れる作業であることは、身をもって体験しました。。。

アップグレードをしても安全かどうか？アプリケーションや運用への変更はないかどうか？ということを知るためには、そのアップグレードによってどのような変更が起きるのかを把握する必要があります。そのためにはMySQLの変更履歴に目を通して、現在のバージョンから最新のバージョンに至るまでに行われている「非互換の変更(Incompatible Change )」や「既知の問題(Known Issue)」について目を通さなければなりません。現在のバージョンとアップグレードしたいバージョンに開きがあると、そのような変更点が多く、確認には少し骨が折れるかもしれません。

骨折れる。

アップグレード作業のところには

アップグレード作業の本質はパッケージの入れ替えです。パッケージの入れ替え自体は至極単純な作業ですので5分とかからないでしょう。しかし、作業の安全性を高める目的やバージョン間での仕様変更の影響により、前後でその諸々の作業をしなければなりません。

ダウンタイムを最小限にするための、レプリケーションを利用したアップグレード(p482)では、原則が記載されています。

• 原則1：低いバージョンのマスターから高いバージョンのスレーブへのレプリケーションは可能。逆は不可。
• 原則2：メジャーバージョンの差は1つまで

結論は、商用と同じ環境で、upgradeテストとその後のアプリケーションのQAテストをしろ、に限りますね。

ストレージエンジンに非互換があり、SQLでは問題ないにせよ性能が劣化することがあるので、やはり1バージョンずつ、そしてmysqldumpによるdump/restoreが現実的だと思います。1秒も落とせないサービスにMySQLを使うのは難しいですね。

第7章 ソースコードのビルド

ソースコードのビルド方法と、QAテストの方法が乗っています。ビルドをする予定は当面なさそうなのでスキップしておいて、QAテストのところをみておきます。

MySQL Test Frameworkというものが付属されてるんですね。知らなかった。。。いずれにしてもこれはMySQLのコードに手を入れるときに使うものですね。

ベンチマークツールはそうでないひとも使う機会があるでしょう。mysqlslap、sysbench、DBT-2が詳解されています。このへんは実践ハイパフォーマンスMySQLのほうが詳しいでしょう。

実践ハイパフォーマンスMySQL 第3版

take-she12.hatenablog.com

おわりに

さすが奥野先生、インデックスつけるためにパラっと見るだけのつもりが、半日かかった、本当に詳しい、そして頼もしい本です。MySQLはオープンソースで、信頼性の高いデータベースですが、その運用には確実にスキルが必要です。この本をそばに置いておけばトラブル時にかなり役にたつと思います。

2017年読んだ本15選

はじめに

読んだ本ははてなブログに書くとともに、記録のため読書メーターにも記載しています。

bookmeter.com

2017年は82冊でした。ここから10冊選んでみます！

だいたいこういうのはみでるよね！15になりました。(笑) 読書メータの記録メモを引用しつつご紹介。

小説(5)

これは経費で落ちません! ~経理部の森若さん~ (集英社オレンジ文庫)

これは経費で落ちません! ~経理部の森若さん~ (集英社オレンジ文庫)

面白かった。森若さんのどこまでもフェアでゴシップネタ嫌いで、波風立てないルーチンが好きで、太陽から迫られたときに途端に処理できず走り出しちゃうところとか、これは確かに男心をくすぐるなぁと思いました。あとは同期の美月との関係がとても好き。真夕ちゃんもめっちゃいい子だし、部長のキャラは薄すぎ。サブキャラ含め登場事物が魅力的に描かれてました。

森若さんのキャラ最高です。この話、絶対恋愛小説にしてほしくないんだけど！(笑) 続編が出てるので読む。

色彩を持たない多崎つくると、彼の巡礼の年+(文春文庫)

色彩を持たない多崎つくると、彼の巡礼の年 (文春文庫)

これまで読んだどの村上春樹作品よりストーリーがわかるし、先が読みたくてどんどん読んでしまうタイプでした。謎が謎のまま残っているものも多く、（シロのこと、沙羅のこと、灰田のこと、灰田の父親が出会ったピアニストのこと。。。）そこはそこで気になるし、つくるが受けたショックは16年経ったとしても許しがたいことだと思う。それでも巡礼し、わかったようなわからないような気がして、それでも意味があると思っていきていく、そういう話は、好きです。言葉にすれば、あまりに単純化されてしまうし、言葉にできないものが、誰にでもある。

村上春樹によりハマった1年だった気がする。この本はヒットしましたね、おすすめできる一冊です。ちゃんとストーリーがある。(笑)

わたしたちは銀のフォークと薬を手にして

わたしたちは銀のフォークと薬を手にして

食と旅と恋を描かせたらさすがの島本さんで、いつもおいしいお酒、おいしいご飯、旅と一緒に揺れる思考と感情を楽しむことができる。椎名さんがいい男すぎ。個人的には飯田ちゃんの性格が好きで（バーで言い返すところね）もっと話を聞きたかった。希望というのは、欠けているときに見え、逆に満ち足りると絶望が（それは絶望おれ自体が迫るという意味ではなく）見えるというのはなるほどなと思った。どの日常も特別であり、どの特別も日常だということを感じられる作品。一緒に焼き鳥を食べられる相手が1番だね。

"食と旅と恋を描かせたらさすがの島本さん"に尽きる。すっきりとした読了感で気持ちよかった。2018年も新刊が出るようで、楽しみにしています。(ナラタージュ見に行ってねぇ。。。)

回転木馬のデッド・ヒート (講談社文庫)

回転木馬のデッド・ヒート

他の作品よりも好きかもしれない。この話が事実かどうかはどうでもいいというか、事実を疑うよりも内容に没頭できるというか、実は事実を装ったやはりフィクションなんだろうかとか思いもしたけど、聞いた話だとしてもこんな風に文字で描けるのは小説家の才能だなと思いました。レーダーホーゼン、タクシーの乗った男、雨宿りが好きでした。どの人物も遠慮がちに、でも生き生きと、そして不思議そうに、だけど持っていられなさそうに話すので、自分も話を聞いてる気持ちになれる。

ノンフィクションでもフィクションでも関係なく楽しめましたね。村上さんというフィルタを通してみる他者の物語も面白い。

作詞少女~詞をなめてた私が知った8つの技術と勇気の話~

作詞少女~詞をなめてた私が知った8つの技術と勇気の話~

作詞少女に続いて！今回の師匠はまたキャラが強烈ですが、作詞の入門本という役割は立派に果たしています。中盤の展開はちょっとやりすぎではと思いましたが、それでも踏み込もうと筆者は思ったんでしょうね。これまで自分が作詞をするときに思っていたもやもやを見事にテクニックとして言語化されていて気持ちよかったです。

作曲少女ファンとして続編を。作詞家として納得できることばかりでした。母音探索は意識してやってはなかったですね。ちなみにYAMAHAのページの尚子ちゃんのバンドの曲がかっこよすぎてビビる。絶対聞いてほしい。

ビジネス/実用(6)

キャリアショック どうすればアナタは自分でキャリアを切り開けるか?

キャリアショック どうすればアナタは自分でキャリアを切り開けるか? (ソフトバンク文庫)

キャリアを切り開くための手段をパターン化した本。前提として終身雇用で永遠と同じ仕事をしていくことはないと自分も感じている。いろんなことを経験した上で自分が好きな仕事・やりたい仕事をやれるようになりたいと思うので、実践的な「やりたいことを膨らませ」た上でやりたくない仕事よりやりたい仕事の比率を増やす話は参考になった。偶然をいかに必然に近づけられるかが大事。

2017年はこの本をきっかけに、自分のキャリアを明確に意識し、アクションにつなげられた年になったと思います。良書です。

諦める力 〈勝てないのは努力が足りないからじゃない〉

諦める力 〈勝てないのは努力が足りないからじゃない〉

諦めることは決してネガティヴではなく、より良い道を選ぶ、選択でしかない。本書の主張はここに集約されており、前半部分で十分書かれている。著者のエッセイ集。諦めること、目標達成できないこと、つらく考えてしまいがちだけど、(全力で努力した上で)届かないなと悟るなら諦めて、自分が楽に勝てる場所探し続けたほうがいいよというのは真理だと思う。

これができたら苦労しないよね。いろんなことをやりたくなってしまう僕はそろそろ意識的に捨てる、あるいは中断する決断をしていかないといけないと思う。だいぶ絞れてはきた。

すべての教育は「洗脳」である 21世紀の脱・学校論 (光文社新書)

すべての教育は「洗脳」である 21世紀の脱・学校論 (光文社新書)

堀江さんの新刊が出ていたので購入。はっきり言い切るところがいいところです。極端だから、敏感なひとたちの反感は買うけど、そういうひとたちは本書でいう「N」の人材だろう。とかく「好きなことをやる」テクニックに目を向けてきたけど、そうじゃない、その根本には学校教育によってブレーキをかけているんだって結論にいたったのは堀江さんの中でも新しい考えだったんでしょう。（あとがきにもあるように）本書の内容はそんなに深くなくシンプルなんですが、各章について自分でも考えてみる。

堀江さんの本はだいたい主張が同じで、この本も「やりたいことをやれ」しか言ってないんですが、教育が洗脳だという着眼点はははあなるほどなと思いました。

アイデア大全――創造力とブレイクスルーを生み出す42のツール

アイデア大全

実用書かつ人文書というのは間違いなく、アイデアを発想する仕事、趣味、活動をしてるひとは何かしら引っかかるものがあるはず。あるいは無意識にやってたけど実は名前がついてたんだ！って発見もあると思う。42の方法から自分にできそうなものをチョイスして試してみるのも良いし、その思想が気になれば哲学的ルーツへ触れることができる点もとても良い。

これは本当に素晴らしい本ですね。実用書×人文書です。まさに。どちらも好きなひとに絶対にヒットします。

21世紀の「裏」ハローワーク: 人には言えないもうひとつの職業図鑑

21世紀の「裏」ハローワーク: 人には言えないもうひとつの職業図鑑 (未来文庫)

闇金、AV女優、キャバクラ嬢など明るみにでない職業の方へのインタビュー集。普段知ることのない情報があって、会話形式ということもあって読みやすい。高城さんはインタビューもうまいですね。豊富な知識と会話術がないとできないことだと思います。

高城さんのインタビュー系の本はもっと読みたいなぁ。「表」も合わせてどうぞ。

21世紀の「表」ハローワーク: 人には理解されないもうひとつの職業図鑑 (未来文庫)

ザ・ゴール ― 企業の究極の目的とは何か

ザ・ゴール ― 企業の究極の目的とは何か

いやー本当に面白くて土日で一気読み。生産的であるとはなんだ？この根本的問いに、ハッとさせられるひとも多いと思う。TOCという実践的な理論だけでなく、物語としても、ボーイスカウトや妻との問題が巧みに織り交ぜられているのも面白さの一員だと思う。生産的・効率的。果たしてそれはなにか。我々はそうやって成果を最大限にした残りの時間を愛する家族や趣味に使いましょう、そういうメッセージがなおのこと素晴らしい。

名作ですね。読み継がれているのも納得。

哲学(2)

勉強の哲学 来たるべきバカのために

勉強の哲学 来たるべきバカのために

めちゃくちゃ面白かった。勉強することを考える。今まで自分がしてきた勉強、してこなかった勉強、言葉が持つ言葉以外の意味。アイロニーとユーモア。これから勉強するのが楽しみになりました。

これは2017年ベストですね。この本でガーーーンと衝撃を受けた。もう1度読むのと、メイキングが出たみたいなのでこっちも読む。

メイキング・オブ・勉強の哲学

take-she12.hatenablog.com

弱いつながり 検索ワードを探す旅

弱いつながり 検索ワードを探す旅 (幻冬舎文庫)

エッセイのように軽く読めるんだけど、明確に観光学という名の哲学がある。グーグル検索は自分が見たいものしか見えないという点を指摘し、だからこそ旅で自分自身の検索ワードを変えなさい、それは永遠に旅する旅人ではなく、観光して戻ってくるような旅をしなさい、そういう主張。また、旅による偶然性によって人生はもっと面白くなったり、弱いつながり＝偶然が知らないことを知る結果になる、そういうことを大事にしている点も面白かった。

東さんの本はゲンロンも読んだんだけど、うまくまとめきれてないのでそのうち再読する。旅行が好きな自分は、この本を読んでなぜ旅をするのか、なぜ旅をしたいのかを考えるきっかけになった。弱いつながりは大事だということを知ることができた。

take-she12.hatenablog.com

技術(1)

技術書のカウントが結構漏れてましたので、ブログに書いてる分あわせて追加しました。

エンジニアのためのGitの教科書［上級編］ Git内部の仕組みを理解する(Kindle)

エンジニアのためのGitの教科書［上級編］ Git内部の仕組みを理解する

gitを使う(使わないひとはもはや少ないと思いますが)エンジニアは全員必読な気がします。gitのコマンドの動きは.git以下の動き、内部構造がわかればより自分の頭が整理されるでしょう。一通り読んだので実際に動かして変化を見てみようと思います。

技術的にはこの本が1番刺さって、ただでさえgitおじさんだったのがさらに拍車がかかりましたね。この本で勉強したことを勉強会で紹介したりもしました。いい本です。

take-she12.hatenablog.com

take-she12.hatenablog.com

カレー(1)

カレーライス進化論 (イースト新書Q)

カレーライス進化論 (イースト新書Q)

水野先生のエッセイ。進化論というよりは、著者が以前から持つ日本のカレー文化をどう世界に発信するのか？という問いについて歴史的にまとめなおしたものに近い。すでに世界へ進出しつつある日本のカレーチェーン店についての紹介と、随所に溢れ出るカレーを広めたいという愛情がたっぷり。個人的には「カレーのオープンソース化」は大賛成で、（IT系の人間なのでなおさら）カレーの教科書も買いましたが、システマチックにカレーを作れるプレイヤーを増やすことは大事ですね。

水野先生の考え方にはかなり賛同してて、1カレー好きなのカレーエンジニアとして(笑)何かエンジニアリングで貢献できないかなぁとふつふつと考えています。(実際に作ろうとも考えた)

おわりに

技術書をあとで追加カウントしますが、例年通り読んでるものの、小説を読む時間も増やしたいなあと毎年同じ感想(笑) 今年も読むぞー。おすすめ本あったら教えてください。そういう偶然のつながりで自分を広げていきたい。

2018年まとめるときは技術書とそれ以外でわけようかな。読者層的にもそうだろうし。

付録

読んだ本すべてです。読書メーターの「ブログでまとめる機能を使った。ながっ！

2017年の読書メーター
読んだ本の数：73
読んだページ数：15788
ナイス数：505

人生にゆとりを生み出す 知の整理術の感想
知の整理術ということで、インプットとアウトプットのコツが書かれてる。著書にもあったけど多分自分と考え方が近いからこそこの本を手に取ったんだと思う、現在自分が実践してることが間違いじゃなさそうだなあと納得したくて選んだんだろうな
読了日：12月29日 著者：pha
ザ・ゴール ― 企業の究極の目的とは何かの感想
いやー本当に面白くて土日で一気読み。生産的であるとはなんだ？この根本的問いに、ハッとさせられるひとも多いと思う。TOCという実践的な理論だけでなく、物語としても、ボーイスカウトや妻との問題が巧みに織り交ぜられているのも面白さの一員だと思う。生産的・効率的。果たしてそれはなにか。我々はそうやって成果を最大限にした残りの時間を愛する家族や趣味に使いましょう、そういうメッセージがなおのこと素晴らしい。
読了日：12月24日 著者：エリヤフ・ゴールドラット
ボカロビギナーズ! ボカロでDTM入門 (OnDeck Books(NextPublishing))の感想
DTM、およびボカロPになるために必要な作業内容が網羅されている。個人的にはこれを読んだからといってなれるようなものではないが、全体像を把握するにはいい本だと思う。
読了日：12月24日 著者：gcmstyle(アンメルツP)
作詞少女~詞をなめてた私が知った8つの技術と勇気の話~の感想
作詞少女に続いて！今回の師匠はまたキャラが強烈ですが、作詞の入門本という役割は立派に果たしています。中盤の展開はちょっとやりすぎではと思いましたが、それでも踏み込もうと筆者は思ったんでしょうね。これまで自分が作詞をするときに思っていたもやもやを見事にテクニックとして言語化されていて気持ちよかったです。
読了日：12月06日 著者：仰木 日向
新宿駅はなぜ1日364万人をさばけるのか (SB新書)の感想
多くのひとが言及しているけど、タイトルへの答えはなく、新宿駅ダンジョンの開発日誌と、地政学・歴史学からの新宿駅の構造に対する考察、そしてなぜ迷うのか、東西をつなげる道はどれぐらいあるのか。そして構造を把握するための「田ラみ」の暗号と、内容はバラエティに飛んでいて新宿駅を利用するひともしないひとも楽しめると思う。個人的には迷うので基本的に行かない場所ではある。個人的にはもう一歩踏み込んで、人間がなぜ迷うのか、その原因はどの構造にあって、ここを改善すれば迷わなくなる、のような考察がある本が読みたいと思った。
読了日：11月05日 著者：田村 圭介,上原 大介
不老超寿の感想
金と自由がある高城さんだからできたことではあるが、今後の医療の発展に期待ができる内容だった。不老長寿の時代は技術の発展によってだいぶ近づいているが、反面日本の医療業界ではそれははるかに遅くなるだろうということも、よくわかる。次の一言ばすべてをあらわしている。「日本人の余生は、民主化されたテクノロジーを持つ個人と、医療業界という既得権益者との戦いの場になるだろう。」医療もこの時代、しかそ、それを教授するには知識と、正しい医師に出会うことと、お金が必要だ。
読了日：11月05日 著者：高城剛
21世紀の「表」ハローワーク: 人には理解されないもうひとつの職業図鑑 (未来文庫)の感想
「裏」に続いてこちらも。地下アイドルの現実はもっと知られていいだろうと思った。あとはまいさんだけではなく、高城さんが現実的なアドバイスをしたり、今後の展望を聞いたり、単純に高城さんが誰かと話すのはもっとみたいなあ。野菜の栄養価が減っているのはショックでしたね。どの話も普段話さない面白いテーマでした。
読了日：11月05日 著者：高城剛
21世紀の「裏」ハローワーク: 人には言えないもうひとつの職業図鑑 (未来文庫)の感想
闇金、AV女優、キャバクラ嬢など明るみにでない職業の方へのインタビュー集。普段知ることのない情報があって、会話形式ということもあって読みやすい。高城さんはインタビューもうまいですね。豊富な知識と会話術がないとできないことだと思います。
読了日：10月14日 著者：高城剛
明日クビになっても大丈夫!の感想
ヨッピーさんのファンなので購入。編集の意図なんだろうけど強調部分が太字ならまだしも（それも嫌だが）サイズが大きくなっていてとにかく不快だった。大事と思うことは自分で決めます。こういう風にすると太字の部分だけ読んで読んだ気になる読者層がいるから編集がこうするんですかね？とにかくそれが嫌でした。内容はフリーランスになるならない別にして、本業以外に自分の好きなことを持つための体験を交えたコツがあって読んでよかったです。「生産型の趣味にすること」「わかる未来を予測すること」「好奇心にしたがうこと」
読了日：10月14日 著者：ヨッピー
死ぬほど読書 (幻冬舎新書)の感想
定期的に出る読書観の本（そしてなぜか読んでしまう）で、読書と私、といった感じのエッセイに近い。自分なりの読書観を整理すると、読んだものがある程度自分のものになるには、読みながら考えること、読んだものを振り返ることが必要という点は同意。こういう本は本を読まないひとには届かない（だって本なんだもん！）という矛盾を持ちつつ定期的に出て売れてるってことは、本を読むひとも本を読む効果を探りたがってるんでしょうね。僕もそうです。
読了日：10月13日 著者：丹羽 宇一郎
エンジニアのための文章術再入門講座の感想
要素としてはいいことが書いてあるんだけど例が悪すぎて全然しっくりきませんでした。（一応エンジニアなんだけどなあ）そんなドキュメントそもそも書く？って突っ込みたくなってしまう。
読了日：10月02日 著者：芦屋 広太
アンガーマネジメント入門 (朝日文庫)の感想
アンガーマネジメントの入門本ということで、怒りを感じたときどういうプロセスがあるのか、そしてどう対処すべきなのか、行動と認識(コアビリーフ)を修正する2つのアプローチが紹介されていました。自分自身はあまり怒ったりすることがないのは、後半で語られた"ストレス"がないからかなぁと思いました。書かれていることはわりかし納得できるのですが、怒りを抑えられないひとがここで紹介されている対策を本当に怒った直後にできるかどうか、疑問が残りました。
読了日：09月06日 著者：安藤俊介
<英語のカンを一瞬にしてモノにする!>世界に1つだけの英語教科書の感想
これまで義務教育で学習してきたことの疑問点や、なぜ暗記しなければならないのか、と思っていたこと、些細な違和感を説明していて新しい視点だと思います。もちろんこれだけで英語ができるようになるものではありませんが、1つの"視点"が手に入っただけでも大きいでしょう。こういう法則を見つけ出せるひとはすごい。
読了日：09月05日 著者：西巻 尚樹
はじめてでもわかる！稼げる！仮想通貨入門: 10年に１度のチャンスを見逃すな！の感想
仮想通貨の特徴と概要をざっくりさらう本、この本だけでは不十分なのでまず読んで次にいくべきですね。
読了日：08月11日 著者：上野義治
エンジニアのためのGitの教科書［上級編］ Git内部の仕組みを理解するの感想
gitを使う(使わないひとはもはや少ないと思いますが)エンジニアは全員必読な気がします。gitのコマンドの動きは.git以下の動き、内部構造がわかればより自分の頭が整理されるでしょう。一通り読んだので実際に動かして変化を見てみようと思います。
読了日：08月09日 著者：河村聖悟
金がないなら頭を使え 頭がないなら手を動かせ: 永江一石のITマーケティング日記2013-2015 ビジネス編の感想
ネットを使って金を儲けるノウハウ本。本のブログのまとめのようで、まっすぐ読むには量がキツく半分で断念。自分に必要な内容をブログで読んだほうが良さそう。
読了日：08月09日 著者：永江 一石
この日本で生きる君が知っておくべき「戦後史の学び方」―池上彰教授の東工大講義 日本篇の感想
戦前の日本史すらあやういですが、戦後史について学んだことがなかったのではじめて知る内容ばかりでした。この歴史から現状、今後どうなっていくか考えられるするために、まずは復習。。。
読了日：08月08日 著者：池上 彰
《新版2017》本好きのためのAmazon Kindle 読書術: 電子書籍の特性を活かして可処分時間を増やそう！の感想
kindleをはじめて使うひと向け。情報の収入源や、書評の書き方を紹介してもらえたのはよかった。
読了日：07月04日 著者：和田 稔
アウトライナー実践入門 ~「書く・考える・生活する」創造的アウトライン・プロセッシングの技術~の感想
思考ツールとしてのアウトライナーの使い方。ブログを書いたり、仕事したり、作品作りの構想を練ったり、、、常にとめどなく流れる思考を書き留めて形にするのに使えそうなのでさっそく試す。単なる見出しを作るわけではなく、たくさん可能性がありそうで使うのが楽しみ。
読了日：07月03日 著者：Tak.
筋トレビジネスエリートがやっている最強の食べ方の感想
ダイエットの原理原則にのっとる、シンプルで、本当に無駄なことが一切書かれていない良書。「栄養バランスが大事！」っていうけどその中身、数値について言及されてた本は確かにこれまで見かけなかった。しかし酒飲みなので酒とどう付き合っていくかは悩ましい。。。
読了日：07月02日 著者：Testosterone
カレーライス進化論 (イースト新書Q)の感想
水野先生のエッセイ。進化論というよりは、著者が以前から持つ日本のカレー文化をどう世界に発信するのか？という問いについて歴史的にまとめなおしたものに近い。すでに世界へ進出しつつある日本のカレーチェーン店についての紹介と、随所に溢れ出るカレーを広めたいという愛情がたっぷり。個人的には「カレーのオープンソース化」は大賛成で、（IT系の人間なのでなおさら）カレーの教科書も買いましたが、システマチックにカレーを作れるプレイヤーを増やすことは大事ですね。
読了日：07月02日 著者：水野仁輔
多動力 (NewsPicks Book)の感想
多分これまで堀江さんが言ってきたことのまとめなんだろうなぁと思って読んでみたらやっぱりその通りだし、本書内でもそのことを言及していましたね。堀江さんの本を読んだことがないひとはおすすめ。わりと納得できる内容が多い。ぼくもよくハマりすぐ飽きる人間なので、足りないのは睡眠時間を削っちゃうところと、目的を考えてしまうところですね。そこはあらためたい。
読了日：06月27日 著者：堀江 貴文
回転木馬のデッド・ヒート (講談社文庫)の感想
他の作品よりも好きかもしれない。この話が事実かどうかはどうでもいいというか、事実を疑うよりも内容に没頭できるというか、実は事実を装ったやはりフィクションなんだろうかとか思いもしたけど、聞いた話だとしてもこんな風に文字で描けるのは小説家の才能だなと思いました。レーダーホーゼン、タクシーの乗った男、雨宿りが好きでした。どの人物も遠慮がちに、でも生き生きと、そして不思議そうに、だけど持っていられなさそうに話すので、自分も話を聞いてる気持ちになれる。
読了日：06月13日 著者：村上 春樹
わたしたちは銀のフォークと薬を手にしての感想
食と旅と恋を描かせたらさすがの島本さんで、いつもおいしいお酒、おいしいご飯、旅と一緒に揺れる思考と感情を楽しむことができる。椎名さんがいい男すぎ。個人的には飯田ちゃんの性格が好きで（バーで言い返すところね）もっと話を聞きたかった。希望というのは、欠けているときに見え、逆に満ち足りると絶望が（それは絶望おれ自体が迫るという意味ではなく）見えるというのはなるほどなと思った。どの日常も特別であり、どの特別も日常だということを感じられる作品。一緒に焼き鳥を食べられる相手が1番だね。
読了日：06月11日 著者：島本 理生
ゲンロン0 観光客の哲学
読了日：06月01日 著者：東 浩紀
女子をこじらせての感想
まさに「こじらせて」というタイトルがぴったりだけど、実際その"こじらせ"を別の言葉でいうと、"女"というシンボルとの戦いの記録。女であることを望んでないわけじゃない、むしろ望んでいるが、世間から見る女というシンボルと自分とのギャップに苦しみ、さらにそれを越えようとAVライターをはじめても正当に評価されないと悩む。その正体は自分の中に男を内面化したことだった。女性がAVライター！？と思ったひとこそ、雨宮さんが越えたかったものなんだと思います。
読了日：05月27日 著者：雨宮 まみ
アイデア大全――創造力とブレイクスルーを生み出す42のツールの感想
実用書かつ人文書というのは間違いなく、アイデアを発想する仕事、趣味、活動をしてるひとは何かしら引っかかるものがあるはず。あるいは無意識にやってたけど実は名前がついてたんだ！って発見もあると思う。42の方法から自分にできそうなものをチョイスして試してみるのも良いし、その思想が気になれば哲学的ルーツへ触れることができる点もとても良い。
読了日：05月20日 著者：読書猿
コミュニケーションの哲学入門 (慶應義塾大学三田哲学会叢書 ars incognita)の感想
内容が難しく理解できなかった点もちらほら。あとで復習する。コミュニケーションには言語が必須ではない点が主な主張で、コミュニケーションの定義を理論的に説明された本だった。ただ僕は結局、言語の役割は何なのか、言語はどこにいるのか？が気になって仕方なくなったので入門書としては成功？なのかもしれない。
読了日：05月03日 著者：柏端 達也
レコーディング/ミキシングの全知識 [改訂版] (「全知識」シリーズ)の感想
自分でイチから作品作りに関して持っておこうと購入。アナログ/ハードウェア時代の考え方を大事にしつつ、改版でDAW全盛の今の時代に合わせて書き直された印象を受けました。いずれも双方を否定せず、その中で本当に大事なものは何か？ということを教えてくれています。全部理解はできませんでしたが、自分の知識が増すたびにまた読み直したい。レコーディングとミキシングに境界はないという考えは本当にそうだと思いました。
読了日：05月01日 著者：杉山 勇司
すべての教育は「洗脳」である 21世紀の脱・学校論 (光文社新書)の感想
堀江さんの新刊が出ていたので購入。はっきり言い切るところがいいところです。極端だから、敏感なひとたちの反感は買うけど、そういうひとたちは本書でいう「N」の人材だろう。とかく「好きなことをやる」テクニックに目を向けてきたけど、そうじゃない、その根本には学校教育によってブレーキをかけているんだって結論にいたったのは堀江さんの中でも新しい考えだったんでしょう。（あとがきにもあるように）本書の内容はそんなに深くなくシンプルなんですが、各章について自分でも考えてみる。
読了日：04月21日 著者：堀江 貴文
勉強の哲学 来たるべきバカのためにの感想
めちゃくちゃ面白かった。勉強することを考える。今まで自分がしてきた勉強、してこなかった勉強、言葉が持つ言葉以外の意味。アイロニーとユーモア。これから勉強するのが楽しみになりました。
読了日：04月19日 著者：千葉 雅也
藤子・F・不二雄のまんが技法 (小学館文庫)の感想
僕は漫画を書きませんが、音楽を創作する人間として共通するものがあるということで読みました。内容も平易で、小・中学生でもわかるように説明してある点に好感が持てるとともに、創作に共通する考え方が垣間見えます。まず、自分が楽しくこと。とにかく書き始めること。第九章の「さぁ、プロを目指してがんばろう！」では特に心持ちについて多く語られ、読んでよかったです。遠心力（自信）と求心力（劣等感）の両方に引っ張られるとはまさに経験しますね。
読了日：04月05日 著者：藤子・F・不二雄
色彩を持たない多崎つくると、彼の巡礼の年 (文春文庫)の感想
これまで読んだどの村上春樹作品よりストーリーがわかるし、先が読みたくてどんどん読んでしまうタイプでした。謎が謎のまま残っているものも多く、（シロのこと、沙羅のこと、灰田のこと、灰田の父親が出会ったピアニストのこと。。。）そこはそこで気になるし、つくるが受けたショックは16年経ったとしても許しがたいことだと思う。それでも巡礼し、わかったようなわからないような気がして、それでも意味があると思っていきていく、そういう話は、好きです。言葉にすれば、あまりに単純化されてしまうし、言葉にできないものが、誰にでもある。
読了日：04月05日 著者：村上 春樹
りちょうとえんさんの感想
「肉とそれを食べる人間しかいない」昨今のブログブームにしろ、いつの世も形を変えるだけで知性のあるものが考えることをやめた人間を騙してお金を取るモデルは変わらないんだなぁということをコミカルに描いた作品。冷静なえんさんの視点があるのでなおさら面白いです。
読了日：03月19日 著者：小島アジコ
校閲ガール (角川文庫)の感想
ハッキリ言い過ぎな悦子の物言いや貝塚との言い合いに時々苦笑いしつつ、校閲という仕事のあり方、重要性がわかる。ファッションに絡めて校閲との共通を見出すシーンも良かった。おれは絶対校閲はやりたくない(笑)サブキャラたちがみんな綺麗にキャラが立ってて会話が楽しい。ツッコミどころはあれどそれを上回る魅力があって先を読みたくなる小説でした。作者の他の小説も読んでみたい。
読了日：03月05日 著者：宮木 あや子
言ってはいけない格差の真実【文春e-Books】の感想
「言ってはいけない」のほうはまだ読めてないんだけど、経済格差は知能の格差によって生まれ、知能差は遺伝、もしくは人種によって決まってしまう事実。リテラシーの低い人間をカモにして知能があるひとが稼ぐ社会が知能社会。コンパクトにまとまっていてわかりやすかった。
読了日：03月04日 著者：橘　玲
今すぐ実践! カンバンによるアジャイルプロジェクトマネジメントの感想
ちょうど業務でgitlab issue-boardを使い始めていたので、実践例を見るために購入。完璧な現場目線と、「経営層への説明」からパターンごとの適用例（これも現場目線）最後に理論でなぜカンバンがうまくいくかを解説している良書。
読了日：03月04日 著者：Eric Brechner
これは経費で落ちません! ~経理部の森若さん~ (集英社オレンジ文庫)の感想
面白かった。森若さんのどこまでもフェアでゴシップネタ嫌いで、波風立てないルーチンが好きで、太陽から迫られたときに途端に処理できず走り出しちゃうところとか、これは確かに男心をくすぐるなぁと思いました。あとは同期の美月との関係がとても好き。真夕ちゃんもめっちゃいい子だし、部長のキャラは薄すぎ。サブキャラ含め登場事物が魅力的に描かれてました。
読了日：02月15日 著者：青木 祐子
たった、それだけ (双葉文庫)の感想
1つの物語を、別の視点から語るのはよくある形式だが、この物語は多くを語らなさすぎる点と時間軸がある点で、もはやまったく別の6作品。どんでん返しのラストがあるわけでも、たねあかしがあるわけでもなく、各話で各主人公が何に向き合ってきたか、何を考えてきたかが語られている、面白い本でした。個人的にはトータ最高すぎで、4話が一番好きでした。ただ、視点。。。進学校ではない、勉強ができない〜人生終わりみたいな価値観が透けて見えたのがしんどかったとこだけ気になりました。
読了日：02月07日 著者：宮下 奈都
世界はすでに破綻しているのか?の感想
すでに破綻しているのか、というタイトルは、前日まで穏やかな暮らしだった街もわずか1日で破綻する、実質的にはその前から破綻していたのではないか、ということだろう。25年間目と肌で感じた世界の崩壊をまとめている本。少しでも異変を感じれば自分の資産や生活を瞬時に変える力がないと、飲み込まれてしまうという警笛が書かれていた。生の声を現地で聞いているところがすごい。
読了日：02月06日 著者：高城 剛
1973年のピンボール (講談社文庫)の感想
「風の歌を聴け」から。鼠とジェイの関係が好きだ。断片的な物語がなんとなく過ぎていき、結局何だったのか、そんな読後感のある話ばかりだけど、ひとつひとつのシーンは好きなんだよなぁ。例えば僕と事務の彼女の食事のシーン、ラバーソウルを双子が買ってくるシーン、ピンボールと再開して記憶をそのままにしておくシーン。電話取次ぎをした女と最後に話して見送るシーン。「僕」の哲学がところどころに出てますね。入口と出口、ひととは分かり合えないこと。
読了日：02月04日 著者：村上 春樹
結んで放して (アクションコミックス)の感想
漫画を描く漫画。趣味、仕事、プロ、アマチュア。登場人物の思いがよく描かれてて、創作活動やってるひとはみんな読んだらいいし、同人活動いいなぁと思いました。僕は漫画はやらないけど、音楽もこんな風にいろんな形で愛し続けられたらなぁと思います。
読了日：01月07日 著者：山名沢湖
諦める力 〈勝てないのは努力が足りないからじゃない〉の感想
諦めることは決してネガティヴではなく、より良い道を選ぶ、選択でしかない。本書の主張はここに集約されており、前半部分で十分書かれている。著者のエッセイ集。諦めること、目標達成できないこと、つらく考えてしまいがちだけど、(全力で努力した上で)届かないなと悟るなら諦めて、自分が楽に勝てる場所探し続けたほうがいいよというのは真理だと思う。
読了日：01月07日 著者：為末 大
風の歌を聴け (講談社文庫)の感想
いろんなひと、話、ウイスキー、女、ハートフィールド。バラバラに散りばめられて、村上春樹の言葉でなんとなく並んでる、そんな小説でストーリーも何もない。ただデビュー作からこんな文章でそれが今も続いているとしたら新たな文章の確立という意味ではすごいことな気がする。とはいえ終始「よくわからん」に尽きる。
読了日：01月03日 著者：村上 春樹
大人はもっと遊びなさい (PHPビジネス新書)の感想
名前をつけたらなんでも遊びだったり、それをアウトプットすることだったり…あっちゃんと自分遊べてるなって感じでした。笑 遊んでない大人、いるのかなぁ、遊びを遊びと認識できてないひとはいるかもしれない。なんでもやって、名前つけて、ひとに話そうぜ！ってことが書かれてました。
読了日：01月02日 著者：成毛 眞

読書メーター

2018年1quarter目標

はじめに

2018年のマッチョな目標を立てました。

take-she12.hatenablog.com

昨年、やりたいことや、目標というのはその時期によって変わってくるので、一度立てた目標をやりぬくより都度修正することや、方向性を確認すること、現在地を確認することが大事だと思い、毎月目標＆振り返りをしようと思ったのですができませんでした。

振り返りをするというのは思ったよりヘビーな作業のようで、毎月は無理そうということで四半期ごとにやることにします。

1q目標

つまり、1月〜3月の目標ですね。あっという間なんだろうなあ。

音楽

猫の休日のレコーディングがはじまります。ただ、現状リリース目標は4/25にしているので、3月中のmix & mastering完了ですね。

バンド2枚目のリリース、ソロ含めれば3回目のmix & mastering作業で、当然クオリティはあげたいのですがどうやってあげたと言えるかわからない(笑)

機材は...

• モニタースピーカーの導入
• モニターヘッドホンの購入(壊れた)

出費がかさむ。。。

あとは作曲/編曲作業も裏で進めたいので、

猫の休日向け1曲作詞・作曲・編曲 とけてなくなる向け2曲作詞・作曲・編曲

を目指します。

技術

積ん読をガンガン消化していきたいと思います。具体的には

• Githubツールビルディング
• Goならわかるシステムプログラミング
• なるほどUnixプロセス ― Rubyで学ぶUnix (再読)
• オブジェクト指向設計実践ガイド　～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

結構ハードにになりますね。Githubツールビルディングはささっと通して、必要なところをかいつまんで終わろうと思いますが、残り3冊はちゃんと理解してゆっくり進めたいところ。

特にOSレイヤーの知識がないので、それをプログラミング言語を通じて学習できる2冊には期待です。

また、友人と今railsでTwitterのfavを整理するアプリを作ろうとしています。これはもっと短期で、冬休み中に最低限の機能を作り上げる予定。そのあとどうするかはそのあと考えます。

ここでrailsアプリをdockerで作り、CI込みでproductionまで公開するプロセスを踏むことで、今後自分でアプリが作れるようになる、その基盤作りが狙いです。

転職

一応、3月までは情報収集＆自己分析（？）期間として、受けないつもり。エージェントさんはガンガン受けるように進めてくると思いますけどね。。。

とりあえず今年受ける先として10社ぐらいまでしぼることを目標にしたいと思います。

カレー

毎日カレー食べます(笑)

英語

はやくもあやういんですが、以下の1冊を終わらせます。具体的にはすらすら言えるところまでですね。3ヶ月1冊とあえてハードルを下げています。

どんどん話すための瞬間英作文トレーニング (CD BOOK)

執筆

noteを3つ。予定テーマは

• 才能がない僕は必死にくらいつくしかない
• 人間関係維持のエネルギーと双方向性
• 恋愛的な好きという幻想

qiitaは仕事中の思いつきなので予告はできないんですが、少なくとも1つ

• ドキュメントを書くときの心構え

指導している後輩向けに書く予定。他6つぐらいは書きたい。(最低隔週)

はてなは300目標にしているので攻めの90ぐらいですかね。すなわち毎日ですね。ハハッ。アウトプットおばけかよ。

日記はカウントせず、気が向いたときに書きます。

運動

とりあえず体重計に乗る習慣をつけます。(笑) ハードルは低いところから。。。

毎日カレー食べる分毎日運動しないと肥えて死ぬ。

プライベート

この記事を書いている時点で未踏県であった福島に訪れ、残り4県になりました。秋田、長野、三重、福井ですね。

ただ、2月、3月と結婚式もろもろでかなり福岡に帰るので旅行はできなさそうかな。。。

上記全部達成しようとするとかなり忙しくなりそうなので、充実した毎日になりそうです。

仕事

2月末まで今の案件なんで淡々と終わらせていきます。

おわりに

これを印刷してトイレに貼ることも目標にします。(笑)

UNIXという考え方を読んだ

はじめに

読んだ。

UNIXという考え方―その設計思想と哲学

どの記事か忘れて恐縮なんだけど、あるブログで「UNIXという考え方」は本当にいい本だ、と紹介されていたのを見て、買った。本当に読んでよかった。エンジニアとして働き出して今や4年目だけど、これは1年目に読むべき本に違いない。

9つの哲学

Small is beautiful - 小さいものは美しい

この章では小さは何にもまして優れている説明がなされる。これは次の定理8哲学)にも関連するが、多くのことをしすぎないこと、余計なことをしすぎないこと。あれこれ親切に機能を加えてソースコードが大きくなってしまうと、保守はしづらいし、わかりづらいし、システムリソースに優しくない。

また、小さくて、かつ1つのことだけをやるプログラムであれば他のプログラムと組み合わせて使うことができる。これはUNIX哲学の中でももっとも特徴的な2つの定理だろう。

巨大なソースコードのプログラムよりは小さいほうがいいことは納得いくと思う。これはコードゴルフ(できるだけ短くプログラムを書く)ことではないと思う。

Make each program do one thing well - 一つのプログラムには一つのことをうまくやらせる

1つめのSmall is beautifulと合わせて、UNIX哲学の中で1番大切な定理ではないかと思う。1つ目の定理を補完関係にあり、1つのことだけをやるプログラムはプログラムが小さくなるし、他のことと組み合わせて使うことになる。

Build a prototype as soon as possible - できるだけ早く試作する

これはどちらかというとウォーターフォールとアジャイルの開発手法の比較でアジャイルが優れている点として感じたことではあったが、この場合の不確実性は予測できないから小さく早くしよう、という考え方とは少しレベル感が違うように思う。

やっぱり周囲の優秀なプログラマを見ていても、プロトタイプが早い。とにかく先に作っている。細かいことはあと。こういう仕事の進め方が非常にうまい。この定理も真実なんだろう。

学習曲線という観点を述べている。何かを学ぶとき、最初からうまくできるわけがない。少しずつゆっくりと学びながらやっていくしかない。そのためにはさっさと作ってしまうというのは理にかなっている。誰も学習していないときの不確実な部分を補うことはできない。

この章で語られている第一のシステム、第二のシステム、第三システムの話は面白かったなぁ、ぜひ本書を読んでみてください、あるある、と思いました。

本書8章で語られている言葉が印象深かった。

覚えておいてほしい。ソフトウェアは、実は作るものではなく、成長していくものなのだ。(p132)

これは移植性があれば新たなハードウェアに移し換えることができるということの他、小さいものを、はやく実現することで、今後くる様々な複雑な要求に最小限のエネルギーで対応できるということも意味しているように思う。

Choose portability over efficiency - 効率より移植性を優先する

言ってしまえば、プログラムレベルの効率(=性能)は、次の年のハードウェアの進化によって凌駕できる。プログラムの性能よりは、別のアーキテクチャに移植し続けることが可能なプログラムのほうが、結果的に長く使われ、結果的に性能がよくなるということだ。これはなるほどと思う。

Store numerical data in flat ASCII files - 数値データはASCIIフラットファイルに保存する

そのまんまだ。

動かせないデータは、死んだデータだ(p58)

Use software leverage to your advantage - ソフトウェアを梃子として使う

最初ちょっと掴みづらかったんですけど、1つのプログラマの結果をもらって、その力を使って別の問題を解決する、というニュアンスでしょうか。

具体的には、ある処理をパッケージして配布するようなことだと思う。別にシェルじゃなくても、いろんな言語の各ライブラリでもいい。めんどくさい処理を誰もが使えるようにして、自分の仕事であとの何億人のプログラマが同じ苦労をしないですむようにする、梃子のように莫大な省力化をもたらす。

これは1つのことをうまくやるようにできていないと、なかなか難しいでしょうね。

Use shell scripts to increase leverage and portability - シェルスクリプトによって梃子の効果と移植性を高める

シェルスクリプトすげーぞ！という話。自分はあんまり得意ではなく、別の言語で書いたりしてしまうので耳が痛い話。

シェルスクリプトをC言語で書き直すという誘惑に負けない(p82)

まぁC言語は書けませんけど。(笑)

シェルスクリプトのこともっと好きになりたいな、と思いました。

Avoid captive user interfaces - 過度の対話的インタフェースを避ける

これは次の定理であるフィルタとして使うことができないからですね。自動化の妨げになります。expectを使う手もありますが、やってられないです。他のプログラムと組み合わせて使うことを妨げるので、これは感覚レベルで嫌だなと思っていました。

Make every program a filter - すべてのプログラムをフィルタとして設計する

これも他の定理とゆるく関連ついていますね。何かしらのデータを入力として受け入れて、何かしらをフィルタし、それを標準出力として出す。この慣習を守ることによって、プログラムを小さく保ち、プログラム同士の結合を可能にするんですね。

以下はあまり意識できていなかったので心がけます。

1. データ入力にはstdinを使用する
2. データ出力にはstdoutを使用する
3. 帯域外情報にはstderrを使用する

10の小定理

全部はいいかなと思うので気になったものだけコメント残しておく。

• 1. 好みに応じて自分で環境を調整できるようにする
• 1. オペレーティングシステムのカーネルを小さく軽くする
• 1. 小文字を使い、短く
• 1. 森林を守る
• 1. 沈黙は金
• 1. 同時に考える
• 1. 部分の総和は全体よりも沖井
• 1. 90パーセントの解を目指す
• 1. 劣る方が優れている
• 1. 階層的に考える

森林を守る、はちょっと面白いなと思いました。

紙には気をつけることだ。それはデータの死亡証明書といってもいい (p112)

だいぶ社内もペーパレスが進んできました。

沈黙は金に関しては、うーーんわかるけど、やっぱり困るときはある、という印象です。(笑) これはエラー出力の親切さというより、標準出力で、フィルタした結果が何もないなら黙って何もない結果を出せばいいんだ、ってことだと思います。

90パーセントの解を目指すってのは、本当に素晴らしいですね。これは信頼性の話とも似てるなと思っていて、90%から99%を目指す、99%から99.9%を目指すにはかなり大きな労力がかかる。完璧を求めすぎないこと。やることを明らかにし、90%を満たすものを作ること。大事だなと思います。

おわりに

何度も述べているが、この9つの定理はゆるくつながっていてUNIX哲学を作っている。1つのことをうまくやる、小さいプログラムを作ろう。それはできるだけ移植可能であり、長く使われ続けるものであろう。さらに梃子の力を働かせるようなものを作り、車輪の再発明は避けよう。そしてそれぞれの小さいプログラムを組み合わせて、問題を解決しよう。

この哲学、本当大事ですね。仕事でちょっとしたシェルスクリプトを書いて社内のgitlabにあげてますが、(書かないよりはマシですが)そのプログラムは全然1つのことをうまくやるようにできていなくて恥ずかしい限りです。

みんなに梃子のようにうまく使って楽してもらえるようなプログラムをこれから書いていきたい、そう思える名著です。また読み直したいな。