別にしんどくないブログ

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

関西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_にメンション飛ばしていただけると助かります。

チームに必要な「5つの法則」とチェックリスト / 『THE TEAM 5つの法則』を読んだ

GWは実家に帰省していました。同様に帰省していた弟が『THE TEAM 5つの法則』という本を持ってきていました。書店でも見かけたことがある表紙だったのでパラパラと読み始めると面白かったので一気に全部読んでしまいました。

この本はよく言われる「良いチーム」への誤解を主張するところから始まります。  

例えば「目標を確実に達成するのが良いチームだ」「チームはコミュニケーションが多ければ多い方が良い」「みんなで話し合って決めるのが良いチームだ」といった当たり前のように良いと思われていることに対して、実は時にチームが十分にパフォーマンスを出せない原因になり得ると主張しています。著者は「チームの法則」を用いることで、こういった誰もが持つ誤った認識を解消し、本来あるべきチームの姿をつくることができると主張しています。

その法則は「5つの法則」に分類することができます。

これら本書はこの5つの法則が章ごとに分かれて構成されています。気になる章だけ読んでも完結するようになっています。  

また、各章は「法則」「具体的事例」「チェックリスト」「学術的背景」で構成されており、好きなところから好きなところだけ読んでもいいようになっています。   このエントリでは本書のチェックリストをベースに読書メモを書き残しておきたいと思います。自分が後からチェックするのに使うためにこのブログに残しておきますが、このエントリを読んでくださっている方も読んでて気になるところがあれば気になった章だけでも本書を読むことをおすすめします。

Aim(目標設定)

チェックリスト

  • チームの活動の意義が明確になっているか?

  • チームの創出すべき成果が明確になっているか?

  • チームは推奨している行動が明確になっているか?

  • チームではかつどうの意義と創出すべき成果、推奨している行動が適切に接続されているか?

  • チームが活動する意義、創出すべき成果、推奨されている行動を日常的に意識できているか?

メモ

チームのパフォーマンスは目標設定によって決まります。適切でない目標が設定されているとすべてが台無しになることもあります。  

目標設定には3つのレベルがあります。

  • 行動レベルの目標設定

  • 成果レベルの目標設定

  • 意義レベルの目標設定

意義レベルの目標設定では最終的に実現したい抽象的な状態や影響を示したものです。意義レベルの目標にはチームのパフォーマンスにブレークスルーを起こす力があります。  

昔は行動レベル、成果レベルの目標が重視されてきましたが、時代とともに意義レベルの目標が重視されるようになってきました。意義レベルの目標設定にはGoogleやメルカリなどが導入しているOKRを使うことができます。

チームが何のために存在し、すべてのメンバーが意義目標を意識し、自発的に行動し成果をあげることが求められるようになってきています。

Boarding(人員選定)

チェックリスト

  • チームの活動の特徴を語られるか?

  • チームのメンバーには適切な多様性があるか?

  • チームには適切な流動性があるか?

  • チームに必要なメンバーの特徴を理解しているか?

  • チームのメンバー集めやメンバー選びに貢献しているか?

メモ

環境の変化度合いや人材の連携度合いによってチームの特徴は変わります。チームにとって必要な人材を選定する前にチームの特徴を把握することが大切です。  

チームが置かれた状況に応じて多様なメンバーを集めるか均質なメンバーを集めるか変わります。どちらかに偏っている場合は採用基準を見直す必要があるのではないでしょうか。同じく状況に応じては固定のメンバーよりもメンバーに流動性がある方が良いときもあります。ビジネスの環境変化が速い今日では必要なときに必要なメンバーを選定できるようにしている組織であったほうがいいと言えるでしょう。

Communication(意思疎通)

チェックリスト

  • チームはルールを明確化できているか?

  • チームはメンバー同士がお互いの過去や特徴を理解するような機会を持てているか?

  • チームは問題やアイデアメンバーが安心して共有できる雰囲気をつくれているか?

  • チームメンバーの過去や特徴を踏まえたコミュニケーションを取れているか?

  • チームメンバーに恐れや迷いなく自分が感じる問題やアイデアを発信できているか?

メモ

適切な緻密さを保ったルールを決めることでコミュニケーションコストを少なくすることができます。逆に過度なルールはコミュニケーションコストを増やします。コミュニケーションは多ければ多いほど良いチームであればルールを再設定したほうがよいです。無駄なコミュニケーションを減らして効率化する一方で、「お互いを理解するコミュニケーション」や「安心して意見が言える場づくり」は大切にする必要があります。心理的安全と相互理解に基づくコミュニケーションによってチームメンバー間の連携が取れて相乗効果を発揮することができます。

Decision(意思決定)

チェックリスト

  • チームは状況に応じて最適な意思決定方法を選択できているか?

  • チームはスピーディーに再現性のある議論ができているか?

  • チームは意思決定者が孤独を恐れず決断できているか?

  • リーダーの意思決定を自らの手で正解にすべく活動ができているか?

  • 決断が必要なタイミングで「強く」「速く」意思決定ができているか?

メモ

まず、どのような方法で意思決定するか意思決定する必要があります。チームの意思決定には「独裁」「多数決」「合議」の3つがあります。状況に応じてスピーディーに意思決定する必要がある場合は全員で決めるより誰かが一人で決めるほうが良い場合もある。合議は時間がかかるのでスピーディーに意思決定するためには選択肢を用意します。まず選択肢を決める基準を決め、選択肢の優先順位を決めます。最後に優先順位に合致する選択肢を選択することで素早く意思決定できます。

「5秒で考えた手」と「30分かけて考えた手」は86%が同じ手なので5秒以内に打った方が良いというファーストチェス理論という考え方があります。これに基づくことでとにかく速く意思決定ができます。ソフトバンクの孫さんが実践しているそうです。

合議による意思決定に時間がかかる場合は独裁も必要です。そとのときに大切なことは意思決定者が反対や孤独を恐れずに決めること、しかしメンバーは意思決定者を孤独にしないことです。

「専門性」「返報性」「魅了性」「厳格性」「一貫性」を有したメンバーを意思決定者にすると意思決定の成功確率が上がります。

Engagement(共感創造)

チェックリスト

  • チームでは金銭報酬や地位報酬だけでなく感情報酬がメンバーに提供されているか?

  • チームではメンバーに何に共感してもらうかが明確になっているか?

  • チームにはメンバーがチームの魅力を感じる仕組みが埋め込まれているか?

  • 自分が何を求めてチームに参加しているかを明確にできているか?

  • チームがメンバーの共感を生み出すことに貢献できているか?

メモ

すべてのメンバーがモチベーションに左右されるというのはすべてのチームにあてはまることです。モチベーションを高めるために4つのPがある。

  • Philosophy(理念・方針)

  • Profession(活動・成長)

  • People(人材・風土)

  • Privilege(待遇・特権)

4つのPすべてを提供することは難しいのでどれかに注力する。例えば、マッキンゼーはProfession、リクルートはあPeople、ディズニーはPhilosophyの魅力で束ねています。社内だけでなく社外にも魅力が伝わることで応募者とのミスマッチ防止にも繋がります。

今回は『THE TEAM 5つの法則』のチェックリストと読書メモを紹介しました。
チームのパフォーマンスに悩んでいる方や他の本で良いとされている方法がうまくいかない方におすすめです。

最後までお読みいただきありがとうございました。不備や質問はブコメTwitterまでお願いします。

THE TEAM 5つの法則 (NewsPicks Book)

THE TEAM 5つの法則 (NewsPicks Book)