おうさまのみみはロバのみみ

ネット上での木の洞

Qiitaに寄稿システムっぽい仕組みがほしい

Qiitaに怪文書が出てから嫌な方向で盛り上がっているのがクソいなというお気持ちをまず表明したいと思います。 いいかここはチラ裏じゃないんだ。そういうのは増田でやれ。

さて、本題なのですがそういえばQiita改善の方法を書いているエントリを読んで「インセンティブよりもかつて所属していた会社のQiitaTeamから抜けたらその成果が虚無に消えたのが悲しかったので寄稿という形をとってほしいな」と思ったのがきっかけです。

当時QiitaTeamには社内向けで一般公開が出来ないもの、一般公開しても問題のないものの2種類エントリを書いていたわけなのですが問題なのは一般公開しても問題なかった投稿が自分の投稿一覧から消えてしまったことです、悲しい。 社内向け非公開というエントリが虚無に消えてしまうこと、これ自体はTeamから外れたのでいいのですがそうでない投稿の場合寄稿という形でQiitaTeamに投稿したいなという気持ちがあります。

最初から一般公開しても良い内容ならQiita(Teamでない)に投稿すればいいのですが、一般公開するには情報が足りなかったのか。ログ的に書き出していたからかQiitaTeamで書いてしまっていたエントリがいくつかあってその情報をかつてQiitaに書いたよなーと自分が投稿した一覧から遡ったところ「あ、これTeamで書いたから見れなくなってるわ!」となったので寄稿というシステムがあれば嬉しいなと思った次第です。

せっかくの経験や知識、なによりアウトプットしたものが見れなくなってしまうのがもったいないなと思ったのでそういう仕組がほしいですね!という意思表明しておきます。 あと寄稿という形ならスポット的に参加したメンバーとかも投稿しやすいような気持ちがしたけどただの推測なのでよくわかりません。

響け!ユーフォニアム 公式吹奏楽コンサート ~北宇治高校吹奏楽部 第3回定期演奏会~

前回参加したとき(多分第一回)はまだ東京に住んでいたのですが、今回は宇治で参加なんだなーとなかなか感慨深いものを感じながら参加してきました。

ここのところあまり体調が良くなく(のちにアレルギー性の鼻炎が原因と思われることが発覚)、当日になったら早めにいって宇治の聖地巡礼してやろう!とか思っていたのですが叶わず、ギリギリまで休んでいました。残念。

せっかくの自転車日和という季節になったのに週末が悪天候になりがちであまり今年は楽しめないでいることが多かっただけに結構残念に思っています、また大吉山まで行きたかったんだけどなあ…。

演奏は満足の一言でした。

前回のときよりも演奏の円熟度が増していたように思います、 個人的には宝島のテナー・サックス(低音のサックスだと思うけど確かでない)のソロパートがMVP上げたいくらい良かったです。 元々サックスとか低音パートのほうが好きなので個人的主観に基づいてるので実際に上手い下手は正直わかんないです、みんな上手いと思うんだよなあ。

TRUEさんの歌声などもなかなか迫力があり大変満足しています。

ただ演奏そのものの不満ではないのですが素人ながら前回ほどに音のボリュームというか圧がないように感じました。 これは指揮者の意図なのか、音楽ホールの設計の問題なのかわからないですが個人的には後者なんじゃないかなと思ってます。

こういうところでも差がでてしまうのかなー、音楽って難しい…みたいなことを演奏後に思い返していました。 そういう意味では宇治は聖地だし特別感があるんだけども、京都市内の音楽ホールや大阪のほうの音楽ホールだとどう聞こえたのかな?というのが少し気になりました。

非常によい音楽を休日に堪能できたなという思いと音楽はいいなーと3万回くらい思っていることを改めて感じました。 どうやら追加公演があるそうなのですが、残念ながらぼくは参加できそうにないのでもし参加できなかった!という方は応募されてみるのもいいのではないかなと思います。

anime-eupho.com

クリスマスイブだそうなので友達や家族と行くとリア充っぽくていいんじゃないかな。

この定期演奏会がずっと続いてくれるといいなーという思いでブログを書こうと思っていたのですが冒頭でいったような体調とどうにもここ数日トラブルが頻発していてブログを書く時間をなかなか捻出できなかったので1週間ほどたってしまいました。

またそのうち時間を取って宇治まで聖地巡礼してみたいな。 とりあえず来年の新作映画が鋭意製作中だと思うのですが楽しみに待ちたいと思います。

Instagram post by るっかふぉーと • Nov 4, 2018 at 9:40am UTC

以上、参加レポートでした。 絵書いたり音楽できたりするのってなんかカッコいいなーって感じでいいですよね。

暗くなってきました。

Instagram post by るっかふぉーと • Nov 4, 2018 at 9:39am UTC

宇治市内

今回わかったのは宇治市内の夜は京都市内に比べてめちゃくちゃ暗い、ということです。

頑張るということをしたくないという話しをしました

ことの発端はお酒の席での雑談だったのだけど後々考えてみるとこれは一考する余地があるように感じたのでまとめておこうと思う。

誤解されそうなタイトルなので補足すると努力放棄するということではなく、仕事をするうえで頑張るという評価軸は正しくないのではないか?と考えているという話しをしたぞということです。

事の発端:

どういう話しの流れだったのかもう思い出せないのだけど先月末あたりに会社の飲み会の最後のほうに同僚がぼくを「そういえば最近頑張ってますよね?」と評価してくれたことに端を発するのがきっかけだったように思う。

それに対して「ぼくは頑張るということをしたくないと考えていて、何故なら頑張るというのは自己満足の域を出ないと思っているのでそういうエモーショナルな観点から評価されたくない。」と返したんだという流れだったような気がする。

ぼく自身はお酒を飲んでいなかったのだけどしばらく時間が空いてしまったので正確なところは覚えていない。 ただこの件で反省していることがあってもう少し言い方というか表現を変えることができなかったかな?という気持ちがある。

君の頑張りを私は評価しています!というポジティブな意見に対して反論してしまっているので「評価してもらって嬉しいけどもぼくは頑張りではなく成果を出してそこで評価されるようになりたい」という感じに言い換えれたら良かったのになーという気持ちに後日なった。

もしかすると本人は気にしていないのかもしれないがぼくはこの手の発言したあとで大いに気にしてしまうことがあり、その辺り本当に気遣いができない人間だと思っている。

とまれそこはこの話しの本質でないのでここまでにするが何故ぼくが頑張るという言葉に過剰反応してしまったのかという点に関していくつか理由がある。

  • 1つ目は、以前働いていた会社で「頑張るのは当たり前」という言葉が飛び交っていたことに対する不信感があったこと。
  • 2つ目は、ぼく自身は頑張っているというよりは仕事に対して真剣に取り組んでいるだけであって特段頑張っているつもりがなかったこと。
  • 3つ目が、ぼく自身が頑張るというエモーショナルな観点から評価されるのが歪だと感じていて、それを仕事の評価に取り込んでほしくないと思っていたこと。

他にも細々したことがあるのかもしれないが大きくはこの3つが原因かなとみている。

「頑張る」という不信感

頑張るという言葉は非常に便利だ。 日本語のこういうファジーな表現は非常に使い勝手が良いし日本語の優れた点だと思う。

とはいえ、頑張るというのは常日頃から行っているのが当たり前だと息切れをするのではないかとぼくは思っていて、つまり頑張るというのはここぞというときにだけ使うべき必殺技のようなものだというのがぼく個人の見解であり、そうありたいと願っている。

なので頑張っていない状況で働いている時間だけをみて「頑張っている」という評価は不当、あるいはフェアでないと感じたのだろうと思う。 こう書くと怒っているようなニュアンスに受け取る人もいるかもしれないが、ぼく個人の感情としては怒りではなくフェアでないので正しい評価に戻すという印象が近い。

さて、そこで件の頑張るのは当たり前という件に戻る。 頑張るのが当たり前という言葉はかなり語弊があるとぼくは思う。

頑張るのが状態化しているのならそれは頑張っていないことに等しいというのがぼくの考えであり、 期待しているのは頑張るという過程の行為に対する時間や労力ではなく真剣とか真面目とか真摯とか仕事に対する姿勢を問われていると思うのでこの言葉は選択を間違えているのだとぼくは考えている。

例えば5時間かけて苦悩して問題を解決した人と片手間に鼻くそほじりながら15分くらいで問題を解決した人を第三者が見た場合にどう感じるか?という問題がある。

ぼくらのようなエンジニアやクリエイターであれば、苦労した時間が必ずしも成果に対して比例しないので後者のほうが効率よく作業をしたとみなす傾向がある。 そう、あくまでそれを視界にいれていなければ。

文字だとそんなの後者を評価すればいいじゃんとなるのだけど現実にそういう苦労する姿をみてしまうとそれだけでバイアスが自覚、無自覚を問わず働いてしまう。

そこには「頑張っている」というバイアスがかかっている。

苦労をして問題を解決したことに対して尊さを感じていたり、あるいは問題解決そのものよりも苦労することそのものに価値が生まれてしまっているのかもしれない。

人間にとって苦労することはわかりやすい指標なのかもしれない。

苦労しないように苦労をした場合その過程を知らなければ検知することができない、世界一有名な箱の中の猫のようなものだ。 観測されるまでその事実はなかったものとして扱われる、なんという理不尽!

真剣に向き合うことは頑張りではない

努力は報われるべきだし、その点が評価されないのは不当だと思う。 先の例でいうならば仕事という観点で見た場合に評価されるべきは後者であるとぼくは考えている。

仕事の評価という意味においてこの「頑張る」というバイアスは正しい評価を歪ませてしまうので悪、というと語調が強すぎるが良くないものだと考えている。

仕事の評価というのは究極的にいうなら会社の利益にどれくらい貢献したのかだと思っている。 会社は言うまでもなく営利企業なので利益を追求するべき組織だ。

とはいえ、それだけだと目に見えるようになった数字しかみない存在になってしまう。

これの悪い例としてよく上がるのがノルマだろうと思う。 ノルマという制度、もしくは仕組みそのものは悪いわけではないのだと思うがその運用を人間がやると多くの場合、悪化するのではないかとぼくは考える。

ぼくが知るノルマの悪い点は数字を絶対化しすぎていて数字化できない部分で会社の利益に反する行いが横行してしまいがちだということだ。

数字上は良くなっているはずなのに実態は悪化しているという状況はこの数字外の部分で会社に不利益を与えてしまっているからではないだろうか。

そういう思いが根底にあったのでつい過剰に反応してしまったのだと思う。 ぼくは評価はフェアであってほしい、あるべきだと考えているのでそこに無用なバイアスをかけてほしくなかった。

それがポジティブな面であってもそれを許してしまうとネガティブな面のケースでもバイアスがかかるのを許してしまうのが人間だ、ぼくは人間を、特に自分という人間を最も信用していない。

そのため評価に対して「頑張る」というバイアスをかけるのには反対だと考えている。

仕事に対して真剣さや真面目さは必要だと思う、但し仕事に頑張るという方向性を持ち込むのは悪手でむしろ頑張らなくても良いようにしていくのが本質的な仕事の価値ではないかなと考える。 その点においてもやはり頑張るという曖昧な努力目標を仕事の持ち込むべきではないと思う。

頑張るという評価はエモーショナル

頑張るってものすごく感情面に左右された評価だと思っていて、それが大きく影響されるのがフェアでないなと考えている。

同じ労力で2時間の作業をした場合に片方が苦悩しているアピールをしているケースと淡々と仕事をしているアピールをしていた場合により頑張っていると感じるのは前者なわけ。 だとするとあまりよい表現ではないけど演技力のあるほうが評価されるということになる。

自己アピールも能力の一つだとは思うし、それはそれでその人の持つスキルや属人性の一つと言えないこともないと思うのだけど 作業や仕事、やっていることに対してそういった演出によるバイアスがかかってしまうとそれが苦手な人は不満を持つんじゃないかな? 同じくらい苦労しているのに彼、彼女は大げさにアピールすることで自分よりも良い評価を得ているみたいな。

「それも1つの生存競争における闘い方だろう?」という人もいる、それはそのとおりだと思う。 だけどそれに左右される評価式は果たして正しいのだろうか?

ぼくはその式に欠陥があり、不純物を混ぜ込んでしまっていると思う。

なので不純物であるエモーショナルなノイズを除去して俎上に載せましょうというのが理想形だと思うんだよね。 実際には努力したこと、挑戦したことは評価されるべきだと考えているのでノイズを全て排除してしまうと今度は逆にその評価式がおかしくなってしまう。

我々は飲み水がほしいのであって工業精製水がほしいのではない、みたいな感じだろうか? 同じ水という区分ではあるけど必要なミネラルや成分までも排除してしまうと今度は目的を達成することができない、あるいは目的は達せられるが付加価値がなくなってしまうという感じだろうか?

頑張るというのはエモーショナルでものすごくファジー、曖昧な表現なのだけど、努力するには必ず誰が?なにを?という主語と目的語が明確になっていなければならないと思っている。

頑張るはそれらが明確化しなくても使えてしまう。

悪い言い方をすれば具体的な目的、目標もなく逃げれてしまうので評価という点においては不適切だろう。 その点努力するは目標設定したうえでの宣言、コミットメントなのでエモーショナルさはさほど含まれていないというのがぼく自身の認識である。

現実にはそうではないのだけどぼくはそう切り分けて考えているという話しなのでその辺はどうでもいい。

まとめ:

頑張るという日本語はすごくファジーでエモーショナルなので使いやすく便利なのだけどぼくはあまり好きではない。

それよりはぼくが作ったものに対して「使いやすい」「もっとこうしてほしい」「この機能があるおかげで助かった」「こういう機能があると嬉しい」という評価のほうが個人的には嬉しいし、正当でフェアな評価だと思うのでそういう点で評価されるように自分の考えや価値観をまず知ってもらうよう努力していこうと思う。

というようなことを考えていたのでまず第一歩としてここに書き出したということである。

リモートワーク@tomaruba

TL;DR

5月入社で6月からリモートワーク開始してるのでそろそろ4ヶ月目くらい。 現在の状態をKPTでメモ。

Keep:

  • 最低でも週一リモートワークデイは維持
    • 週2回くらいまでは問題なし、それ以上だと問題が出てくる
  • 体調不良によるリモートワークなし
    • 休んできちんと直すのも仕事
  • 自宅だと昼寝するのに気兼ねなくできる
    • 職場だと騒音とか視線とかで心理的安全性にいくつか課題がある
  • トイレに誰かいるという状態がないのでお腹の調子が悪いときめちゃくちゃ嬉しみ
    • 個人用トイレが完備されているようなものなのでめっちゃ助かる、最高。
  • 就業時間を前倒しでやってもよい空気感
    • 職場来てるときと同じ就業時間が大原則
    • なにか予定があるとき便利
  • 通勤時間分の空き時間が生まれる
    • 朝いつもよりゆっくりしたり、なにか用事を済ませることができる
  • 紅茶/コーヒー飲み放題
    • 自宅なので自分の好きな銘柄や品種で入れられる、最高。

Problem:

  • 昼寝してタイマーかけ忘れると無限に寝れてしまう、1度タイマーかけ忘れたことがあって焦った
  • 職場よりも仕事への集中力が下がる傾向がある、作業的にただ手を動かすときは別
  • 小学生、中学生の帰宅時にモチベーションが下がる
  • 天気がいいときにモチベーションさがる、無性に旅に出たくなる

Try:

  • どっか外国行ったときに宿泊先から仕事してみたい
    • そういう状況ならではの問題があるはずなのでそれを経験したい
    • 海外に移住していまの仕事したいとかそういうわけではない、というかそんなのしたくない。
  • 昼寝するときはベッドで寝ない
  • リモートワークする前日までにただ手を動かすだけの状態にする
  • 小中学生の帰宅時間までに終業時間を迎えるよう、前に始業時間を倒す

良かった点:

  • 災害時でも自分で判断して出社するしないを決めれるので台風が来たときとかに指示待ち状態でヤキモキしたり出勤決定したときのガッカリ感がない
  • 災害時でも普段のリモートワークと同じように仕事できる
  • ちょっとした家庭の用事のときに遅刻した分残業する、みたいなことしなくてよくなる
  • 休日は混むのであまりいかないような自宅近辺の美味しいお店で御飯食べれる
    • そのために引っ越しするとき美味しいお店が多い場所にしたいという気持ちが湧く
  • 社内がうるさい!というときにふらっと近所のスタバにいって仕事しても見咎められない

いまいちな点:

  • 相談したいときとか緊急対応だ!みたいなときは職場のほうがいい
    • 基本的に職場のほうがいい派です。
  • ガチで家の外に出なくなる危険がある
    • 元々出不精なのでより加速する
  • 家族がビデオ会議中に乱入することがある
    • だいたいご飯とか貰い物のお菓子をくれるときでありがたいんだけどめっちゃ恥ずかしいのでやめてくれー!?ってなる
  • 時間を気にせず仕事してしまうことがある
    • 終わりの意識が職場にいるときよりも低くなってダラダラ仕事してしまうことがある
  • 災害時にトラブルあるとめちゃ困る、仕事も集中できないのでいっそ休んだほうがいいこともあった

ITエンジニアの仕事環境はどういうのがベストか

仕事環境で重視する理由って人によって千差万別だと思うんですよ、例えばお金とかお金とかお金とか……。

その条件としてぼくがいま重要視してることってなんだろうな?と思ったら結構ざっくりしていたので書き出しておくかー!くらいの気持ちになったという話です。

ちなみに「そもそもお前転職しまくりやんけ!」とツッコミがあると思うんですが転職しまった結果わかったというぼく個人の経験に基づく内容だってことに留意してください。

……昔から気づいてたらこんなに転職しとらんわ!!!

尊敬できるメンバーがいる:

よく転職サイトとかでみかける「成長できる〜」ってやつ。

同じ職場で働くメンバーが信頼できないとそもそも成長以前の問題で辞めたくなるので 大前提で「リスペクトできるメンバーがいる」が必須になります。

なお、かつて働いたところで尊敬できない上司やメンバーがいたところは辞めたあともヘイトが残りましたが 尊敬できる、信頼できるメンバーばかりの職場はそんなこと微塵も思ってないのでそういう意味でも大事です。 (じゃあなんでそこ辞めたか?っていうとだいたいぼくが悪い。)

そういう意味ではTeam Geekは一度読んでおいたほうがいいかもしれない。

でも、これ転職前に知るのはめちゃくちゃ難しいですよね…インターンとか事前に働かないとわからない。 仕事の信頼や尊敬は一緒に働いてみるまでわかりませんからね。

信頼できる経営陣:

チームメンバーはいいんだけど社長(経営陣)に理解がない!!!とかなるとやっぱり辞めたくなる。 ということで経営者が信頼できる、尊敬できるのも重要です。

理由はすでに書いたので割愛。

組織に柔軟さがある:

尊敬できて、信頼できるメンバーや経営者だとしても組織に柔軟さがないと厳しいなってなります。

裁量労働制みたいな全部おまかせ!みたいにしろ!というのは現実的に難しいと思ってる、経営陣側とメンバー側双方にとって。 なのでメンバーを信頼してある程度セルフマネジメントさせてくれる柔軟さがほしいなって思います。

逆に台風明日来るらしいので早めに出社しろとか泊まれとか言われるとその瞬間にクソ辞めたくなる。

don't be evil!:

社会通念上、悪だと言われることをしない、させない。

以前働いていた会社がメールクライアントのBecky!秀丸を不正使用していたり、インターン学生にAdobeなどのアカデミック版を購入してもらい(お金は払っていたらしい)会社で使用するみたいなことをしていた。

「お前それいいと本気で思ってんの?」って感じのヘイトが溜まる会社に長居したくないし、まあそういうところとは付き合いたくないですよね。 人としても組織としても。 当然ながらそんな組織や会社を信頼するのは無理なので早く辞めような!

まとめ:

開発環境、git使えるとかMacBookProだとかIDEがどうとかメモリがどうとかオフィスチェアがどうとかってのは個人的には些事かなと考えていて、それよりもより換えの聞かないメンバーや経営陣のほうが重要だなと考えてます。

なにより結局「働く」って人間が一番ハンドリングするの難しいのでそこを重要視して、ハードウェアやソフトウェアは最悪誰かがお金出せば解決する問題なのでどうとでもなる、くらいに考えておくのがいいんじゃないかなって感じです。

というかそもそも信頼できるひとはそれらの問題をお金で解決するのにだいたい同意してくれるので順番が逆な風潮じゃないですか?という気がしています。

なので「一緒に働きたい!」って思えるのが一番大事。 そのうえでいろいろ揃ってれば文句ないよね!みたいな印象です。

どうせお金とかもらえるだけもらえるほうが嬉しいに決まってるじゃん。

読書アンチパターン

TL;DR

エンジニアの知的生産術を読んで自分の読書方法を鑑みたときに「これって読書アンチパターンでは?」と思ったものを残しておく。 全てが改善されるとは思わない、少しでも改善していけたら御の字というスタイルです。

せっかくなのでアフィリエイトのリンク貼ろうと思ったらKindle版が予約できるようになっていたのでさっそくポチった。

前提条件:

対象者:

  • ぼく

前提:

  • エンジニアの知的生産術の第4章「効率的に読むには」を読了していること
  • 技術書や実用書
    • 娯楽小説をそもそも早く読む意味はない。

結論:

  • 基本的に買うな、読むな
  • 読むなら厳選しろ
  • いま必要なものだけ読め
  • 脳内音読やめろ

ということです。

アンチパターン:脳内音読やめろ

静かな音読をしてしまっている。 脳内、もしくは声には出ていないが文章を音読してしまっているパターン。

ぼくは脳内音読派だったんだけどそのスピードでないといまいち頭に情報が入らない、ということで自覚はしていたのだけど脳内音読を継続していた。 ところがそもそも技術書の読み方を変えて一度目はさっと読んで、わからないところだけ何度も読むみたいな方法に変えるにはここが絶対にボトルネックになるのでここ変えないとどうしようもねえな!ってなったアンチパターン

小説とかは音読でも脳内音読でも問題ないと思います。 っていうかアニメ化とかされるとその印象にめちゃくちゃ引きづられるし、そのほうが楽しかったりしますよね。 娯楽小説はそれでいいのだー!

アンチパターン:定期的に嫁

小説は一気にガーッと読んでしまったほうがいい。 毎週末読むとかすると先週読んだ内容のかなりの部分を覚えていないので平日1時間読むとかそういうある程度の粒度が必要。 そのほうが週末に集中して読み切るよりも精神的コストが低い。 最悪1日読めない、あるいは今週厳しいとかあっても調整が効く。週末集中パターンだと調整が効きにくい。

アンチパターン:YAGNI式選書

必要なものだけを買え、そして買うべき書籍を厳選しろ。 ちょっとおもしろそうとかで買うとだいたい積むだけで読まない、最悪なのでやめろ。 興味を分散させるのは集中に対する最大のノイズ。

アンチパターン:目的が明確でないものは買わない、読まない

選書段階で「この本を読むことで期待するもの」が明確でないならまだ必要じゃない。 その手に持った技術書や実用書は棚に戻すんだ、いいな?

アンチパターン:遅延評価的勉強法

辞書的に引っ張ってくる技術書を買うことがまれによくある。 が、基本そういう書籍は本棚の肥やしになりやすく、また本当に必要なら会社で買ってもらうほうがいい。 本当にそれが必要になってから買うべき。

アンチパターン:読書メモは詳細読みのときに取る

通読時にメモ書くと時間が取られてしまい、スピード感がでない。 明らかに知らない、わからない単語などはむしろメモを取るべきだが、通読時にメモを取るとそれがボトルネックになって全体のスピードを落としてしまっているとは以前から感じていた。 詳細読みを行うときにだけ気になったやわからないこと、違和感を感じたところや私見をメモする形にするのが一番いいのではないか。 そもそもいまでもメモ取るところは知っていることではなく、知らないことが書かれたケースが大半なので通読時にメモしなくてもあまり影響なさそう。

アンチパターン:インなんとかさんはだいじだよ

目次を見て半分以上なに言ってるかわからないものは買わない→自分の知識レベルがだいぶレベルが低いのでミスマッチ

目次みてほぼほぼ内容が想像できる→自分の知識レベルですでに定着しているレベルのものをもう一度読み直す必要はあまりない、ミスマッチ

目次みて7割想像できるが3割がわからない→対象読者として一番レベル帯が近いものであることが多い。買い、但し読書の目的があいまいな場合はなし。

アンチパターン:図式カラー本は選書から外す

なにを目的とするか次第だが図が多すぎるものは初心者向けであわないことが多い。 カラー本は色という情報源が増えてしまい、ノイズになりがちな割に学習という意味で有効だったことがあまりない。 また再利用性(何度も読み直すこと)がほぼない、一度読んで古本屋にGo!するケースがほとんど。

啓蒙書とかは好きにしてくれ、俺は知らん!という感じです。

このアンチパターンから外れる例としてはデザイン関連が挙げられる、視覚的にどう捉えるのか?が脳内で合成できるレベルではないので最初からカラーのほうがわかりみがある。 それ以外のケース、HTMLの組み方とかああいうのは本当に無駄金だなって感じだった。

あとカラーや図が多いとお値段が高くなりがち。お財布的にも厳しいし重い。Kindleだと重さは関係ないけど。

アンチパターン:input → build → outputのサイクルの粒度が大きすぎる

いままでは1冊読む→読書メモから必要そうな文章を組み立てる→ブログ書くのサイクルだったがこれだとサイクルが遅すぎる。 例えば最初の章の内容をきちんと説明できないことが多い、これでは理解しているとは言えない。

1章読む→読書メモ書く→誰かに説明する、図説できる、くらいの粒度がベター。

技術書によっては章だと大きすぎるとかあるので粒度は適当に自分で考えて調整。 読書メモそのものは組み立てるためのパーツなのでアウトプットに含まない。

組み立てたものを説明したり、図説できたりすることのほうが理解しているかどうかのリトマス試験紙として妥当。

理解できていないな?と感じたら、再読リストにその章を突っ込むか付箋紙とかで印つけて読み終わったときにもう一度読み直す。

アンチパターン:パターン毎で読書方法を変える

Aが理解できていることが前提として後述のBが説明される、プログラミング言語を新しく覚えるときなどはこのパターンが多い。 エンジニアの知的生産術だと数学がそうだと書いてあった、足し算わからんのに方程式わからんよな?みたいな話。

ところがそうでなく、読み飛ばしても問題ないケースもある。 これらのいま読んでいる、読もうとしている技術書がどちらなのかを理解したうえで読み方を変える。

多くのケースは読み飛ばしても大丈夫なことが多い。ところが教科書のようなものは前提条件を積み重ねていくのでそうではない。 このあたりは目次みたり、実際に軽く読んでみて判断するしかない。

また前提条件が必要になる場合、理解せずに次に進んでも意味がないので時間がかかりすぎため、それを念頭においておくこと。 時間かかるなら他を優先して読んだほうがいいとかそういうこともあるよね。

アンチパターン:一定数読んだらご褒美をあげる

最重要なのは必要性だがそれだけで技術書を読み続けると正直つまらないし、疲れる。

なので一定書籍数読んだら自分で興味があって買っていたが必要性がそれほど高くないけど興味があって読みたいものを読む。

報酬があるとなんとなく読み切ろうという気になりがち。 娯楽小説とかも含む、クソエモ本は実用書でも技術書でもないのでご褒美本に入れる。

アンチパターン:買ったときに読まずに積読してしまう

基本的に小説でも技術書でも同じなのだけど買ったときが一番「読むぞ!」というモチベーションが高い。 読んでるうちにモチベーションが上がるケースもあるけどそんなのは数年に1度くらいのエッジケースなので考えない。

なので「必要」だから「買った」のに積読してしまうとモチベーションは下降し続ける。 そしてある一定積読したし、そのうち読むだろゾーンで下降が収まり、それ以降読むまでモチベーションが上がることがほぼなく一定の位置を保持してしまう。

こうなると読むぞ!という気持ちに持ってくるまでのフットプリントが大きくなりすぎてしまう。 なので買ったら少なくとも1章くらいは購入日に読む。

当然先に読まないといけないものがあるのに購入してはいけない、発売日に買う必要性は読者であるぼくにはない…やりがちだけど。

まとめ:

基本的に買いすぎ、集中の分散しすぎが積読の大きな原因。 読む速度の遅さは脳内音読のせいだなって感じ。

積読速度 >>>>>> 読む速度なのでできるだけ買わない、買うなら選書段階でしっかり時間をかけないといけない。

ここを改善するだけで大きく読書スピードが上がりそう。 勘違いしてほしくないんだけど、速く読むことそのものには意味がないし、それを目指しているわけじゃない。

ただあまりにも足りていないものやことが多すぎるので技術書や実用書を読んでなんとなくわかって気になれる程度にはレベルを上げておきたい、という目的のために読書スピードの改善を行う必要があっただけの話。

エンジニアの知的生産術でも書かれていたけど「読書は手段、目的は別」、特に技術書や実用書は。 小説の場合は読むことによって目的が達成されるのでこの限りじゃないし、小説は楽しんで読みたいじゃんね。

エンジニアの知的生産術 -効率的に学び、整理し、アウトプットする-

読んだ。

この本を読んだ大きな目的としては4つ。

  • 技術書を早く読む技術の向上、もしくは問題の解決
  • モチベーションの維持管理を学ぶことでムラのある管理方法に一定の持続性をもたせる
  • 何を「いま」学ぶべきか?を論理的に行えるようになる学習効率の最大化を図る
  • 大学に入り直すべきか?という学歴コンプレックスに端を発する欲求に区切りをつける

更にいうなら、この中で重要視すべきは読む速度の向上とモチベーションの管理方法を改善するのがマスト、 なにを学ぶか?と大学に入り直すのは可能であればくらいの気持ちで読み始めた。

感想:

モチベーションに関する管理方法はまだ自分のなかできちんと根を張っていないように感じているが、その他の項目には一定期待した効果を得られたのではないか?と考えている。

モチベーション、つまりはやる気だがその管理の説明は一定納得する部分があるものの根源的にどうやる気を生み出すのか?の部分を解決してくれなかったのでそこを期待していたぼくとしては少々物足りなさを感じる結果となった。

ただ、その維持管理するための方法論や問題点に関しては概ね納得できるものが書いてあったので大きく外しているわけではなさそう。

良かった点:

  • 遅延評価的勉強法ができていないことに気づけた
    • 評判だから、流行っている技術だから、タイトルがキャッチーだからで買ってしまう技術書が多すぎたことに気づいた。
    • いま必要な技術以外に興味を持つのはいいが、数を厳選しないなら単に集中力が分散してしまっているだけになっていると気づけた
  • 読む速度が遅い原因は脳内で音読してしまっていたため、その速度に引きづられてしまっていた
    • 音読する速度以上にならない、小説であればそれでも問題ないが技術書でそれを行う意味がない
  • 今読んでいる本が全て理解しながら読み進めるのがよい技術書とまず全体に目を通してわからないところだけ何度も読み直す技術書のどちらか?というのを気にする必要があることに気づいた。
    • エンジニアの知的生産術は後者だと個人的に思っている。
  • 読んでいる、もしくは読もうとする技術書が「閉じている」本なのか、「開いている」本なのかで読み方を変える必要があることに気づいた。

いまいちだった点:

  • やる気に関する期待したような解答がなかった。
    • ただ書かれた内容がピンポイントで解決してくれなかったからといってその中身が有用でないわけではないが物足りなさを感じた点としてしこりを残した。
  • 説明としては必要と判断されたのだろうけども少々迂遠すぎる説明がところどころにあった
    • あれは省略してもよかったのではないか?という気がしている。

まとめ:

全体的に読むための技術とその際に注意すべき点は大きく改善された、もしくは改善できそうだと感じられた。 但し、やる気に関してぼくが期待したポイントはこの本では示されていなかったため、具体的にどうしなければいけないのかを自分で考える必要がありそう。

これを読むタイミングとしては最も最適なのは実務に関わるようになって半年〜3年目くらいに読むのが一番刺さるんじゃないかと思う。 会社に1冊あると興味がある人が勝手に読むんじゃないか?という気がするので、個人で所有するよりはどこか不特定多数の人が読めるところに置いておきたくなる実用書だった。

ぼくは何度も辞書のように読み返したり、個人的に重要だと感じた書籍は紙媒体で持つようにしているのだけど、そういう文脈でいうとこの本は電子書籍でほしいなと感じた。 重要でない、というよりは読んだ文章に対してメモを書き込みたいという意味あいが強いのと、なにかあるときにふと読み返せるようにしたいという2つの意味で電子書籍版を期待している。