別にしんどくないブログ

技術のことや読書メモを書いています

『学びを結果に変えるアウトプット大全』を読んだ

学びを結果に変えるアウトプット大全 (Sanctuary books)

学びを結果に変えるアウトプット大全 (Sanctuary books)

ノウハウだけでなく、アウトプットする時にどういったところを意識すると効果が高くなるかを理論的に説明した良い本だった。
同じテーマの他の本と重複する内容もあるが、著者の知識や経験談だけでなく理論に基づく説明が多かったのが好印象でした。

特に気になった箇所をメモしておきたいと思います。

インプットとアウトプットの黄金比は3:7

インプットの量を3、アウトプットの量を7とすることを著者は勧めています。
例えば、勉強するときも参考書を読むより問題集を解くことを中心に勉強した方が効果があるとのことです。 アウトプット駆動で勉強することは効果が高いと感じます。
興味のある分野の勉強会があればLT参加を先に決めてしまったり、資格取得などゴールがあればSNSで公言してしまってやらざるを得ない状況にするのがオススメです。 読書感想文を書くこともオススメです。読書するときもブログを書くつもりで読むと質の高い読書ができるのではないかと思います。

タイピングより手で書くほうが脳への定着率が高い

手書きの方が脳が活性化されることはあると他の本でも度々述べられているので非常に信憑性は高いと思います。
この本でも手書きとタイピングでどちらが脳への定着率が良いか研究したところ、手書きの方が定着率が高いという研究結果が記されています。

最近は共有する必要がない自分用のメモや、自分の脳の中にあるものをバーっとブレストする時は手書きするようになりました。もしくは音声入力を使ってます。思いついたことをメモするには手書きか音声入力の方が効率的に感じます。
共有が必要なことがわかっている場合は、共有しやすいタイピング入力を使います。なので、使い分けが必要だと思います。
あと、手書きしてもすぐに棄てるメモは電子メモを使っています。紙に書いて破り捨ててもいいのですが、ボタンひとつで消せるのは便利です。

非言語コミュニケーション、内容ではなく身だしなみや表情などの視覚情報、声の大きさや質などの聴覚情報も重要。話すときは内容に自信がなくても笑顔で堂々と話すように心がける

カンファレンスや勉強会の登壇者で話が上手な方は全員非言語コミュニケーションが上手だと感じます。
非言語コミュニケーションに関して、最近は登壇するときは「なるべく聴講者の方を見て話す」「大きな声で話す」「大切なところは声の大きさや間のとり方に注意する」「明るく話す」ことを心がけるようにしています。

速く文章を書く

技術記事やブログ書こうと思ってもなかなか筆が進まないことが多かったです。また書き始めても完成するまで時間がかかりました。
これを何とかしたいと思ったことがこの本を読むきっかけでした。
2つコツがあります。

時間を決めて書く

速く文章を書く1つ目のコツは時間を決めて書くことだと本には書かれています。例えば、1記事を30分で書くと制限といったことです。最初は難しいですが、脳がトレーニングされていき最終的には質の高い短文を書けるようになるとのことです。 これに関しては愛聴しているPodcast PHPの現場の24回目でも話されていてこれは参考になると思いました。

しかし、実践しても大幅に時間オーバーするので修行が足らないのか見積もりが甘いのか何か間違っていると感じているので改善策を考えないと・・・と考えています。

構成を決めてから書く

2つ目のコツは、文章を書き始める前に構成を考えると3〜4倍速く書けるようになると著者は述べています。 これは僕の実感ですが、構成を決めずに書くと一貫性が保てないことが多いと思います。
先にアジェンダやまとめを先に書くだけでも効果があると思います。

プレゼンテーション資料を作る

先に構成を決めることに似ていますが、スライドを作成する前に全体の構成を手書きで作ってしまう方法です。
先日の登壇資料を作成するときに実践してみましたが、これは結構良い方法でした。
これまでアジェンダとまとめを最初に書くようにしていましたが、全体構成をざっくりきめてしまうと資料作成のときに一貫性を保つことができます。
具体的には1ページを4分割します。発表時間が60分の場合は15分ずつ4分割した紙に話したいことを時計回りにざっくり書いていきます。

字が汚い&写真写りが悪いので見苦しいかもしれませんが、前述した電子メモに記載したときのプレゼンテーションの構成です。

f:id:Shisama:20190203190631j:plain
Denoについて発表したときの資料作成の前に書いた構成図

読書感想文を書く

読んだ本の読書感想文をブログとして書くことで記憶の定着率や読解力が上がります。このエントリのように実践しやすいアウトプットだと思います。

要約を140文字で書く

Twitterです。読んだ本や読んだ記事などのインプットを140文字で要約します。要約力を高めるために良いアウトプット実践だと思いました。

最後に

手で書くことの効果と非言語コミュニケーションの大切さをこの本から学ぶことができました。
この本に記載されていることは科学的根拠を用いた説明が多いので信憑性があると言えます。
本の構成上、気になるところだけ読んでも学ぶことができるように工夫されています。また図や絵なども載っているのでイメージもしやすいと思います。
アウトプットが出来ていなくて悩んでいる方やアウトプットの質を高めたいと考えている方にはオススメできる本です。

最後までお読みいただきありがとうございました。オススメの本やこのエントリに関するご意見はTwitterまたははてなブックマークにてお願いいたします。

登壇前のスライド公開はメリットしかなかった

関西Node学園 5時限目 - connpassで登壇したのですが、今回は登壇前にスライドを公開してブログに貼りTwitterでも告知しました。
これはid:Soudaiさんがいつも登壇する時にされていることです。いつも登壇前にスライドを公開しておられます。
builderscon 2018に参加したときに先にブログでスライドを読んでから実際話を聞いても全然新鮮さを損ねている感じがしませんでした。もちろんそーだいさんの話が上手なのもあると思います。しかし、先にスライドを読んでいたことで話が頭に入ってきやすかった感覚を覚えています。

soudai.hatenablog.com

今回の発表に話を戻します。
今回の発表内容はまだ多くの方が知らないDenoについての話だったので「本当に楽しんでもらえるのか」や、まだ僕も経験が少ないので「間違っているところはないか」と少し不安がありました。
もしかすると何かフィードバックもらえるかもしれないと思い、そこで先に公開して反応を見てみることにしました。

すると、こんな反応がありました。

フィードバックいただきました!!
しかも、お二方ともDenoの開発をめちゃくちゃやっている方々だったので、非常に自信に繋がりました。また、発表前にご指摘いただけたり新しい情報を共有していただき助かりました。

「こんなものか」「Denoの話、楽しみにしてたけど全部知ってるからキャンセルしよう」とか思われるかもしれない、と公開前は不安が少しありましたが結果としては公開するデメリットは一つもなかったですし、メリットしかなかったです。

今後も登壇前にできるだけスライドを公開したいと考えています。
スライドが登壇ギリギリまで完成していない時は厳しいかもしれませんが、そもそもそうならないように余裕を持って資料作成を行わなければ!(と自分に言い聞かせています)

最後までお読みいただきありがとうございました。もし他にも登壇前にこういうことすると良いよなど勉強会やカンファレンス登壇についてアドバイスがあればTwitter宛までご共有いただけると嬉しいです!

『関西Node学園 5時限目』を開催しました #kng5

nodejs.connpass.com

2019年最初の関西Node学園はサイボウズ大阪オフィス様で開催させていただきました。
サイボウズの岡田さん、榎原さん、太田さんありがとうございました。

今回は自分も登壇しました。
最近Denoのコードを読んだりコントリビュートし始めたのと、最初ryが発表した頃から中身も変わっていてGoからRustに書き換えられていたり、 日本でもDenoのモジュールを開発している人やコアにコントリビュートしている人も増えてきたので、話をしたら楽しんでもらえるかもしれないと考えました。

shisama.hatenablog.com

他のセッションもすべて面白かったです。
今回は知らないことが多く、自分も非常に勉強になりました。 (恥ずかしいですが、分散データの話とか全然ついていけませんでした・・・)

資料に関しては以下のconnpassのページにまとめています。

nodejs.connpass.com

すべてのセッションが終わって片付けしながら、終了予定時刻まで時間が少しあったので、その間に参加者と登壇者の方々が交流していたことが嬉しかったです。
Denoについても質問いただけたので、とても嬉しかったです。
登壇してフィードバックもらえることは嬉しいし、登壇した甲斐があったなと感じます。 参加者の中には「質問して大丈夫かな」「変なこと聞いたら失礼かな」などためらう方も多いかと思いますが、多くの登壇者はどんなフィードバックでも嬉しいと思うので、どんどん質問や感想をするとお互いにとっても良いかと思います。また、そういったことができるのがオフラインでの勉強会の良いところだと思います。

また、終了後に@zilch8@Ajido@leichtgewichtと小規模懇親会として飲みに行きました。
そこでもとても楽しい時間を過ごしました。

次回の開催ですが、4月末か5月始めころにNode.js v12がリリースされるのでその付近で開催できたらいいなと考えています。
登壇者と会場提供してくださる方を絶賛募集しています。

では次回もよろしくお願いいたします!

f:id:Shisama:20190202155428j:plain
懇親会で食べた肉盛り合わせ

関西Node学園 5時限目でDenoの話をします #kng5 #denoland

表題の通り、2019-02-01に主催している関西Node学園でDenoについて話をします。 現状僕が知っていることを話します。 Coreのコードについても話したいですが、時間の都合上割愛する予定です。

スライドは発表までに修正するかもしれません。

speakerdeck.com

質問や不備はTwitterブコメでお願いいたします。 間違いは特にメンション飛ばして教えてほしいです。

blink-devのススメ。Chromeの最新動向キャッチアップについて

最近、情報収集の一環で新しく始めたことがあるので紹介したいと思います。

blink-dev

知っている人も多いかもしれないですが、blink-devというchromiumレンダリングエンジンBlinkに関するグループが存在します。

https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev

ここではBlinkの機能や仕様について活発に議論がされています。 このグループは誰でも参加可能で、誰でも投稿することができます。

このグループのフォーラムを眺めているとchromiumの最新の情報を得ることができます。 すべての情報をキャッチアップするのは大変ですが、ここでは僕がなるべくやるようにしていることを紹介したいと思います。

Intents

上記のblink-devのページを開いてもらうとわかると思いますが、各投稿はIntent to 〜というタイトルになっています。Intentは意思とか意図とかって意味だそうです。 そのIntentsにも種類があります。

  • intent to Prototype: explainerや仕様、設計が書かれている(Idea phase)(design phase)
  • intent to experiment: Origin Trialなど試験運用がされる(Implementation Phase)
  • intent to implement: 実装が始まったもの(Implementation Phase)
  • intent to ship: stableに入る(Implementation Phase)
  • intent to remove: 削除される機能 などがあります。

そもそも多すぎてタイトルだけでも確認するのが大変なので、intent to shipまたはintent to implement and shipだけ見ることもあります。

chromiumのプロセスについては以下に書かれています。

dev.chromium.org

メールで確認する

興味のある内容は抑えておく

このグループのメンバーになると投稿があるとメールで通知が来ます。毎日結構な数が来るので、すべて見ているわけではないですが興味のあるタイトルは概要だけでも読むようにします。
内容をちゃんと読みたい場合はページを開いて議論の内容も見ます。

知らないけど気になる内容も見てみる

タイトルを見て知らないけど気になったメールも見るようにしています。
メールを見てまったく興味がわかない場合もありますが、その場合はアーカイブして終わりです。
知らない単語が出てくることも多いですが、その都度調べることで新しいことを学ぶことができます。

無知で恥ずかしいですが、最近知ったのはCross-Origin-Resource-Policyです。

他のグループ

blink-dev以外にもchromiumに関するグループはあります。 例えばdevtools-devやChromium-devがあります。全く投稿が無いグループもありますが、グループ名から興味のあるグループを覗いてみるといいと思います。

https://groups.google.com/a/chromium.org

他のブラウザ

自分はChromium派生ブラウザを使うことが多いのと(良し悪しありますが)ブラウザの進歩をリードしているのはChromiiumだと考えているので、他のブラウザについては全く見ていません。
しかし、他のブラウザでも最新情報を追う方法はあります。
Jxckさんが配信しているmozaic.fmでは毎月Webの最新動向を配信するMonthly Webがあるのですが、それを聞くと毎月の最新情報はキャッチアップできます。
Jxckさん自身がどうやってキャッチアップしているかというのは以下のエントリにまとめてくださっています。僕もこのエントリを読んでblink-devを知りました。

blog.jxck.io

このエントリに書かれているように他のブラウザでも最新の情報を能動的に得る方法はあります。

また、ChromeにCanaryがあるようにFirefoxにはNightlyがあり、SafariにはTechnical Preview版があります。それらを使ってみたり、CHANGELOGを追うのもいいかもしれません。

今回は最新のChromiumの情報を得るために行っていることを紹介しました。
最後までお読みいただきありがとうございました。質問や不備などがありましたらTwitterまたははてブとかでコメントしてもらえるとキャッチアップできると思います。

Kyoto.js 15で"off-the-main-thread with WorkerDOM"というタイトルで登壇しました

kyotojs.connpass.com

表題のとおり、Kyoto.js 15で登壇してきました。

speakerdeck.com

off-the-main-threadについては昨年のNode学園30時限目で@kosamariさんが発表していたあたりから関心はありました。

speakerdeck.com

Kyoto.jsの翌日に開催された次世代Webカンファレンスでもoff-the-main-threadに関しては何回か言及されていましたし、注目されていると思います。フロントエンドのセッションでは「2、3年後には当たり前になっているかもしれない」とも話されていました。


Frontend - 次世代Webカンファレンス #nwc_front

WorkerDOMに関しては、社内のインターン生から「AMPページでスクロールしたらでこういうバナーを差し込みたいのですが・・・」って質問されて「amp-position-observerでできないですかね」って話すと、要件が色々あるみたいでどうやら試したけどできなさそうでした。

www.ampproject.org

JavaScript使えるならここのdivのdisplay書き換えるだけでいいんですけどね」って話をしていたのですが、「そういえばAMPでJavaScript使ってDOM操作できるライブラリをどこかで見たぞ」と思い出して調べると、amp-scriptがそれっぽくて中でWorkerDOMが使われていました。

github.com

WorkerDOMはReactなどのライブラリとも互換性があると書かれていたので、試してみたところ成功しました。

developers-jp.googleblog.com

せっかくなのでJSの勉強会で話そうと思っていた時にKyoto.js開催が決まったので今回話したという経緯になります。

発表ではcreate-react-appで作った雛形をビルドしたJSファイルをWorkerで動かすということもできることを話したのですが、実際はcreate-react-appで雛形作ってnpm run buildでできたJSファイルをWorkerで読み込めばいいのですが、そのためには多少初期設定から変更が必要でした。

index.htmlを書き換えたり、webpack.config.prod.jsを書き換える必要がありました。それらに関しては時間の都合や話の本質ではない(webpackの話をしたいわけではない)ので発表時には話しませんでした。

diffを貼っておくので興味があればみてください。「いや、こうやればいいでしょ」などツッコミどころがあればどんどん教えていただけると嬉しいです。

github.com

最後までお読みいただきありがとうございました。質問などはTwitter(@shisama_)までお願いいたします。

『エンジニアのためのマネジメントキャリアパス』から学ぶ、キャリアアップを楽しむためには

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

O'Reilly Japan - エンジニアのためのマネジメントキャリアパス

内容はいちメンバーからマネージャー、CTOや経営幹部までのキャリアパスや各職務についてわかりやすく明確に書かれています。
上のO'Reillyのリンク先に内容の説明書きと目次が載っているので惹かれるものがあればそこから読んでみても学びや気づきはあるかと思います。

この本を知るきっかけになったのは及川さんのこのブログ記事でした。

takoratta.hatenablog.com

この記事の中でも以下にとても共感できたので読むことにしました。

どのように地位が高くなろうと、自ら手を動かし技術に触る機会を持つべきであると一環して言われているように、高い技術力と組織作りの両方が要求されるからであるが、技術をやり続けられるならばと魅力を感じる人も多いであろう。

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド - Nothing ventured, nothing gained.

この記事では、自分の経験を照らし合わせながら本の中で特に心に残った箇所を書き残しておきたいと思います。

相手の言葉をよく聴き、相手の言葉で話す

これは新入社員の研修メンターを担当したときに感じたのですが、自分の言葉で話しても伝わらないものです。
自分では当たり前と思っていたり、ある程度経験年数のあるエンジニアであれば"言わずもがな"な内容であったとしても、新入社員や経験の少ないエンジニアには相手が理解できる内容で伝えないと理解してもらえません。
当たり前すぎることですが、つい自分の言葉で話してしまい後から反省することはよくあります。
多くの自己啓発本やビジネス書の類の本にもよく傾聴力の大切さが書かれています。
指導方法も「こうしなさい」と最初から言うのではなく、相手の話を聞いて改善点はどこにあるのかを見極める必要があると思います。例えば、わからないことがあった時に調べ方が悪いのか、コードを読む力が足りていないのか等、改善点が異なっていることがあると思います。答えがわかっていて言いたい気持ちがあってもグッと堪えて相手の話を聞くことで相手の短所や傾向がわかってくるのかなと思います。
また、この本の中では相手の言葉を理解できているか確認するための「相手の発言を復唱する」「相手の発言を自分なりの表現で言い換え、返してみる」練習をする実地で行うことを勧めています。これは意識して取り組んでいきたいと思いました。

細かすぎる上司と、任せ上手な上司

人に任せることが難しく感じることはよくあります。例えば、部下に任せた仕事の進捗が良くないと細かく指示をしたり管理したくなってくることがあります。しかし、信頼して任せること、責任を負わせないことを貫くことが大切だと思っています。
そうすることで部下との信頼関係を築くことができます。
これも意識しておかないといけないと感じています。というのも、どうしても自分でやった方が早いからやっちゃう癖があるからです・・・毎回後から反省するので改善しなければいけないと思っています。

「チームの結束を乱す人」への対処

ブリリアントジャーク*1」「秘密主義者」「無礼者」をどう対処するかということが書かれているのですが、そもそもこの3パターンに自問自答してみた方が良さそうです。
自分が得意な分野で議論になったときにマウンティングしていないか不安になりました。故意でないとしても周りの空気を悪くしたり、攻撃的になっているときはあるかもしれません。気をつけなければいけないと心に釘を打っておきました。

ITスキルの維持

小規模な技術的成果物の作成(バグ修正や機能追加の開発)には携わるべきと著者がエンジニアリングリードになったときの職務記述書(JobDescription)に記載されています。管理者もコードの作成に積極的に関わっていれば問題が起きたときにもすぐに対処できるためです。
「確かな技術力の持ち主」という評価が無ければ技術者からの評価は得られないと思います。
開発が活発であればコードはどんどん変わっていきますし、技術トレンドもどんどん変わっていきます。管理者になっても技術に積極的に関心を持ち続けることが大切です。それを楽しめるように自分自身を管理する必要もあると感じています。勉強しなければいけないからやるのではなく、やりたくて堪らないから頑張って時間を作るぐらいの心構えが良さそうです。

好奇心をもって当たれ

著者が人間関係に悩みコーチに相談したときにアドバイスされる言葉だそうです。相手が何を考えているか考えること、さらには技術や戦略や事業にも好奇心をもつこと、自分の認識や考えが間違いであったことを論破されても喜んで受け入れるようにして好奇心を絶やさずに進んでいくことを読者にアドバイスしてこの本は終わります。

全体感想

心に特に残ったことは「好奇心を絶やさないこと」「相手の話を聞くこと(傾聴)」「コーディングや技術的なスキルの向上のための時間を作る努力を惜しまないこと」です。これらを身につけていると、役職や役割など立場の変化、技術トレンドの変化、チームや環境の変化にも対応し楽しめるのではないかなと感じました。
変化に対して好奇心を絶やさず楽しみながらキャリアアップしていけるのではないかなと考えています。

コーディングや技術から離れていくのが嫌でマネジメント職を避けていた方もネガティブなイメージを捨てて、あなたがなりたいあなただけのマネージャーを目指してみてもいいのではないでしょうか。
何が何でもマネジメント職になりたくない人にとってもチームで働くために必要なことが多く書かれているので是非読んでほしいと思います。
もちろん既にマネジメントに携わっている方にもオススメです。

長くなりましたが、最後までお読みいただきありがとうございました。

*1:優秀だけど嫌なヤツのこと