別にしんどくないブログ

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

『たいていのことは20時間で習得できる』を読んだ / 効果的学習のための10のルール

この本は超速でスキル獲得するためのTipsが書かれた本である。
要約すると、習得したいスキルをできるだけ細かくサブスキルに分解し、少しのリサーチ時間と最も重要なサブスキルに20時間を費やすというものです。
最も重要なサブスキルに集中して習得することで、その後の学習効率が大きく変わるということ。
もし、重要なサブスキルを身に着けて満足であればそこでやめてしまってもいいのだ。

本は理論編と実践編で構成されており、実践編はヨガやプログラミングと具体的なスキルの習得について書かれている。
そのため、実践編は習得したいスキルのところだけ読めばいいだろう。この本自体は理論編が70ページほどで実践編も、例えばプログラミングだと、80ページほどしかない。そのため、読むのには時間がかからないだろう。

理論編では「超速スキル獲得方の10のルール」と「効果的学習のための10のルール」の2つのチェックリストについて紹介されている。
特に「効果的学習のための10のルール」のほうが気になったので今回は「効果的学習のための10のルール」の方を重点的にメモを残しておきたいと思う。
「超速スキル獲得方の10のルール」に関してはルールだけ記載しておく。

超速スキル獲得方の10のルール

  1. 魅力的なプロジェクトを選ぶ
  2. 一時に一つのスキルにエネルギーを集中する
  3. 目標とするパフォーマンスレベルを明確にする
  4. スキルをサブスキルに分解する
  5. 重要なツールを手に入れる
  6. 練習の障害を取り除く
  7. 練習時間を確保する
  8. すぐにフィードバックが返ってくる仕組みをつくる
  9. 時計のそばで一気に練習する
  10. 量と速さを重視する

効果的学習のための10のルール

  1. スキルとそれに関連したトピックについて調べる
  2. わからなくてもやってみる
  3. 心的モデルと心的フックを知る
  4. 望んでいることの「逆」を想像する
  5. 実際にやっている人の話を聞いて予想を立てる
  6. 環境から気が散る要素を取り除く
  7. 覚えるために間隔をあけて反復と強化をする
  8. チェックリストとルーティーンを設ける
  9. 予測を立て、検証する
  10. 自分の生物学的欲求を大切にする

1. スキルとそれに関連したトピックについて調べる

20分かけて習得しようとしているスキルと関連がありそうな本やDVDなど資料を少なくとも3点見つけること。ここでの目的は、最も重要なサブスキル、重要な構成要素、必要なツールを知ることである。スキルについての広範な知識をてっとり早く集め、全体像をつかむこと。

2. わからなくてもやってみる

初期リサーチの段階では理解できないことが多いが、経験を積むと同じ情報が理解可能になる。また、混乱を認識すること自体が、理解の一形態である。具体的に「何に」混乱しているのかはっきりさせ、それを解決するために次に調べること、するべきことを理解することにつながる。練習をすればわかるようになると自ら言い聞かせることで、混乱から理解へと最速で進むことができる。

3. 心的モデルと心的フックを知る

心的モデルとは、繰り返し登場する概念や技術であり最も基本的な学習単位である。存在するモノ、あるいは関係性を理解し、分類する手段である。
心的フックとは、新しいことを覚えるときにすでに知っていることと類似性や比喩を用いて理解することである。
初期リサーチで心的モデルや心的フックをたくさん集めておけば、特定の行動をしたとき次に何が起きるか予測しやすくなる。

4. 望んでいることの「逆」を想像する

「反転」という問題解決の手法で、物事の本質を理解するのに役立つ。望んでいることの逆を調べることで、一見気づかない重要な要素を特定できる。
行動するときに、何もかも失敗したら何が起きるかを頭の中でシミュレーションしておくことで必要なモノや行動がはっきりわかる。

5. 実際にやっている人の話を聞いて予想を立てる

目標とするスキルを既に身につけいている人に話を聞き、上達にともなってどのような変化が期待できるか、予め知っておくことができる。そうすることで練習中に興味を失わず、モチベーション喪失を防ぐことができる

6. 環境から気が散る要素を取り除く

気が散る原因は、電子的なものと生物学的なものに分類できる。電話、インターネットなどの電子的なものは電源を切る。悪気のない家族、同僚などの生物学的なものは事前に知らせて邪魔をしないようにお願いをする

7. 覚えるために間隔をあけて反復と強化をする

忘却曲線を理解し、間隔を置いて反復と強化をすることは、重要な概念や情報を定期的かつ体系的に学習するのに役立つ。このテクニックは情報をすばやく思い出すのが大切なスキルに有効である。

8. チェックリストとルーティーンを設ける

たいていのスキルには何らかの決まった手順がある。練習のたびにしなければならないことを確認するにはチェックリストを使う。これはプロセスを体系化し、もっとも重要なことに注意を集中できるようにする。
ルーティンは、スキルの練習に毎日同じ方法で取り組めるようにする構造だ。
チェックリストやルーティンをつくることで、効率よく練習できるようになる。

9. 予測を立て、検証する

予測をたて検証する習慣をつけること。そのために予測や試行錯誤の結果はノートなどに記録しておく。

10. 自分の生物学的欲求を大切にする

最適な学習サイクルは約90分、それより長くなると頭も身体も自然と休憩を求める。無理をせずに休憩をとるほうが生産的である。練習を始めるまえにタイマーを設定することで忘れずに休憩を取るようにする。必要であれば練習時間を細かく区切って20分練習して10分休憩といった具合でもいい。

最後に

すべてのスキル獲得のために10のルールが必要ではないかもしれないが、10のルールをチェックリストとして使うことで効果的な学習に役立つと思う。

関西Node学園 7時限目を開催しました #kng7

nodejs.connpass.com

LINE KYOTO様の会場をお借りして開催しました。
京都で開催するのは1年ぶりで前回もLINE KYOTO様で開催させていただきました。ありがとうございます。

当日の様子

togetter.com

登壇内容

気軽な Node.js バックエンド開発には TypeORM がちょうどいい by potato4d

speakerdeck.com

TypeORMはNode.js + TypeScriptで使えるORマッパーのライブラリです。

github.com

Node.jsでは他にSequelizeやBookshelf.jsなどがあります。
TypeORMはTypeScriptで開発されているのでTypeScriptで使うときにも型がきちんとあたるところや自動マイグレーション機能、ActiveRecord/Repositoryパターン両対応といったメリットがある話をしていただきました。
日本語情報が多いSequelizeを選択しがちだったのですが、話を聞いてTypeORM便利そうだなと感じました。最近はNode.jsもTypeScriptを使うケースが増えていると思うので、型がはまってくれるのは嬉しいです。

ReactDOMでDOM以外を操る by mochiya98

docs.google.com

canvasを例にReactDOMでDOM以外を操る話をしていただきました。サンプルコードはこちらにあります。

github.com

発表資料だけでなくサンプルコードを読んだほうが具体的にわかるかと思います。npx parcel serve src/index.htmlで動かせます。
このリポジトリでコードを追うことでReact HooksやContext APIの勉強にもなるかと思います。
Reactでcanvasを使ったことがなかったので勉強になりました。

しくじり先生 〜俺みたいになるな!〜 メモリリーク編 by plum_shiga

speakerdeck.com

メモリリークの基本とV8(ChromeやNode.jsのJavaScriptエンジン)でのメモリリーク発生時の原因特定方法について話していただきました。
発表でも紹介されていました--expose-gc--trace-gc-verbose以外にもガーベッジコレクションに関するオプションあるのでターミナルで以下のNode.jsのコマンドを実行して確認してみてください。

node --v8-options | grep gc

発表中に便利なツールとして紹介されていたnode-heapdumpはこちらです。

www.npmjs.com

Node.jsでのメモリリークについては古川さん(@yosuke_furukawa)も過去に記事を書いています。 こちらも大変参考になります。

yosuke-furukawa.hatenablog.com

知ってました? Firebase Cloud Functionsで TypeScriptが使えるよ! by Daikids2

speakerdeck.com

Firebase Cloud FunctionsでTypeScriptを使うことができる紹介をしていただきました。
公式にもJavaScriptまたはTypeScriptで記述することができると書いています。

firebase.google.com

また、TypeScriptでCloud Functionsを使い方については公式ページも存在するので参考にしてみてください。

firebase.google.com

最後のページにもありましたTSLintへの言及については以下TypeScriptのissueにありますようにTSLintはアーキテクチャに問題がありパフォーマンスに影響があるとされています。

github.com

そのため、TypeScriptはESLintを使っていくことを発表しています。ESLintチームがTypeScriptチームが協力してtypescript-eslintを開発しています。

github.com

Firebase Cloud Functions自体を久しく使っていないためTypeScriptが使える話は僕は知りませんでした。firebase-toolsから簡単に使えるようになっているのは大変便利そうで勉強になりました。

懇親会

LINE株式会社様から懇親会スポンサーをしていただけることになっていたので、久々に懇親会を行いました。

スポンサー紹介

今回は@tech_manyさんを始めとしたLINE株式会社様に全面協力していただきました。LINE様ありがとうございました。

関西Node学園ではスポンサーしていただける方、会場提供していただける方を募集しています。次回は未定ですが、Node.js v12がLTSになりv13がリリースされる予定の10月末前後に開催できればいいなと考えています。

最後までお読みいただきありがとうございました。質問や不備については@shisama_までお願いします。
関西Node学園への要望なども気軽にしていただけると幸いです。

多様性のある組織にしたら離職率が下がった / 『チームのことだけ、考えた』を読んだ

著者はサイボウズ青野社長。この本はサイボウズの創立から現在までを辿りながらチームワークのことやサイボウズの多様性のある組織作りについて試行錯誤を繰り返して学んだことについて記されている。 かつて28%あった離職率をどのように4%にまで下げたのか。そのキーワードは多様性だった。

サイボウズの多様性を考えて取り組んでいる制度や考え方についてはオウンドメディアで発信していて、サイボウズといえばこのサイボウズ式の印象が強い人も多いのではないかと思う。
サイボウズ式 | 新しい価値を生み出すチームのメディア

特に印象深かった言葉をメモとして残しておく。

人間は理想に向かって行動する

現実として「空腹」で、理想として「満腹」があったとき、「食べる」という行動をする。とてもシンプルな法則だ。 社員が辞めるのも辞めることで理想を実現したいからである。 「人間は理想に向かって行動する」シンプルだが最重要な基本原理だ。サイボウズでは組織全体で最高最大の理想を決めることで一体感が生まれると考えた。会社全体で共通の理想を探すことが最も大切であると考えた。

公明正大

の場でるみに出ても、しいときな声で言えること」 これはサイボウズの中でも特に重要な行動規範である。
元々は「誠実であること」としていましたが、抽象すぎるとのことで「正直であること」に変わった。しかし正直すぎるのにも問題があったので、この公明正大になった。
サイボウズ社はとにかく嘘はつかない文化を築いてきた。

「100人いれば100通り」の前提条件

このビジョンには「1人1人が自分の理想を言葉にして伝えることができる」前提条件がある。多様性のある組織なのでは、「質問責任」と「説明責任」が必要である。「質問責任」とは自分が気になったことを質問する責任であり、自分の理想を伝える責任であり、その結果、自分の理想が叶わなかったとしても受け入れる責任である。「説明責任」とは自分の意思決定について説明する責任であり、他のメンバーからの質問に答える責任であり、その結果、批判があっても受け入れる責任である。
多様性のある組織の中では、この「自立」の精神が必要である。

「事実」と「解釈」は別物である

実際に起こったことが事実で、それを見て思ったことが解釈。たいてい事実は大したことなく、解釈を付け加えることで人は感情的になる。
事実は、五感で確認できる確かさの高い情報。解釈は、事実を得て考えた情報である。事実は人を通じて解釈になる。事実がinputで解釈がoutput。解釈は人によって異なるため、事実を共有しなければ共通認識を持つことは難しい。しかし、解釈によって自分の意欲を高めることができる。どの事実をどのように解釈するかで大きく行動が変わる。事実と解釈を使い分けるスキルが重要。

サイボウズ式・問題解決メソッドでは
①「問題」を発見する
②「問題」を認識する
⇛以下の表に分類する

解釈 事実
理想
現実

③「原因」を検討する
⇛「現実」の「事実」を引き起こした「原因(人の行動)」を探求
④「課題」を設定する
⇛「原因」に対応する「課題」を設定

例えば、ソフトウェアに問題があったとき以下のように分類できる。
現実は、「不具合が多い」状態
原因は、「不具合を出した」から
理想は、「不具合が少ない」状態
課題は、「不具合を減らす」こと

「モチベーション」とは「理想に対する思いの強さ」

モチベーションが高いほど、その理想にを実現するために進んで行動する。例えばとても痩せたい人は、多少お腹が空いても、画面して炭水化物の摂取量を減らすだろう。 モチベーションの制御には3つの条件が揃う必要がある。やりたいこと(Will)、できること(Can)、やるべきこと(Must)の3つである。もしモチベーションが下がったのであれば、3つの要素に分解して課題を設定する。

給与は「市場性」で決める

決まった基準で評価しても、その基準は誰かにとって有利であり、誰かにとって不利である。完全な公平など存在しない。社員同士を比較するのは難しいので、もしその人が転職するなら、果たして給与はいくらになるかで決める。
給与のグレード(等級)は社員をカテゴライズし、多様な社員が増えるほど比較して説明することは難しいのでグレードは廃止した。
もし全社員が給与を下げることなく転職できる状態であれば、いつサイボウズがつぶれても生活に困らない。それでもあえてサイボウズで働き続けたいといってくれる状態が理想だと考えた。

長時間同じ職場にいる必要はない

以下のことができていればチームワークができる。長時間同じ職場にいる必要はない。

  • コミュニケーションをとる
  • 共通の理想を決める
  • 役割を分担する
  • 互いの仕事の進捗を確認する
  • フィードバックし合う
  • 相互に調整する

「制度」は「風土」とセットで考える

サイボウズの人事制度についてはウルトラワークなどとても有名なものがある。それらについてはサイボウズ式に記載されているのでそちらを読んでほしい。
人事制度は作るだけではダメで、文化を変えなければならない。制度を活かすために、企業の風土を変える必要がある。しかし、風土を変える活動に終わりはない。

高い理想への共感が必要

多様性のある組織において、緩さが行き過ぎないようにするには、理想を強く持つことが大事。サイボウズでは「グループウェア世界一」という高い理想への共感が必要。

最後に、サイボウズは国内でも数少ないグローバル展開している企業である。
それゆえに企業として国内に留まらず、海外でも採用しており社員数も数百名と大企業になった。しかし、サイボウズでは多様な働き方が維持できている。
多様性を重視した結果、離職率も低い数値を維持できている。
簡単に真似できることではないが、この先より一層人材を確保することが難しい時代になると考えられる。人材流動性も一層高くなるし、複業も当たり前になる時代になるでしょう。
その時代を迎えるにあたり、各企業はサイボウズのような多様な働き方を取り入れざるを得ない状況になる。
働き手にとっても多様な働き方ができる企業は魅力的に感じるであろう。そのため、サイボウズはこれからも伸びるのではないだろうかと考えている。

最後までお読みいただきありがとうございました。ご意見などがございましたら、Twitter - @shisama_もしくはブコメなどでいただけると幸いです。

『Dockerを使ったレガシーシステムの開発環境の改善』について話します。 #RAKUSMeetup

この勉強会の存在を知らなかったのですが、たまたま見つけました。 以前からアウトプットできていなかったDockerでの改善について発表したいと思います。

speakerdeck.com

発表の前の日は半日東京に行く予定があり、資料が間に合うか微妙でしたがなんとかなりました。 最近は資料作りもかなり慣れてきました。この調子でどんどん発表したいと思います。

不備や質問などがありましたらTwitterで連絡いただけると幸いです。

twitter.com

#kansaits 1でTypeScriptのbuilt-in typesについて話します!

6/10に開催されるkansai.ts #1でTypeScriptに組み込まれている便利な型について話をします。 いつも通りスライドを公開しているので、もし興味あれば読んでフィードバックいただけると幸いです! 不備や質問もTwitter @shisama_までいただけると助かります!

speakerdeck.com

kansaits.connpass.com

GatsbyJSで英語日記を構築した

英語で短めの日記を書くのをやりたくてgatsby-starter-blogでサクッと構築しました。 https://diary.shisama.dev にしましたが、DNSの設定もこの記事を書く直前にしたので浸透していないためにNetlifyドメインにリダイレクトされるかもしれません。

diary.shisama.dev

この日記は継続して英語をアウトプットする習慣を身につけることを目的にしているため、とにかく短くてもいいし内容もどうでもいい日常の内容とかにする予定です。
そのため、見た目とかもほぼデフォルトです。タイトルも日付でいくつもりです。あと自分で構築した静的サイトの場合、技術的に実験する場所にもできます。GatsbyJSの土台の上に乗っているとはいえ思いついたことをやりたいと思います。

この日記を構築するにあたって最初はgatsby-starter-lumenを使う予定でしたが、記事ごとに書くメタ情報(titledateなど)がやたらと多く、だるかったのでgatsby-starter-blogにしました。

github.com

ホスティング先はNetlifyで行い、pushすればビルド&デプロイされると思っています。
そして、Gatsby最高だよ。めちゃくちゃ速い。Lighthouseで計測したらPerfomance 94点でした。

続けていく中で躓いたことや解決策が見つかれば英語・日本語ともにアウトプットしていきたいと思います。 日本語のブログ(このブログやQiita)も継続して続けたいと思います。

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

Node.js v12の気になる変更点について話すかも #kng6

登壇予定だった方がやむを得ない事情により、急遽登壇できなくなってしまったのでNode.js v12の変更点を話すかと思い資料を作りました。
まだ、発表枠は空けていますが2日前に登壇枠が空いたので流石に応募する人はいないようで、前日の今時点で応募が無いのでたぶん話す。応募があっても時間の配分によりますが、たぶん話すと思います。

例のごとく発表資料は先に公開します。

speakerdeck.com

もし不備などがありましたら、ブコメ@shisama_にメンション飛ばしていただけると助かります。