別にしんどくないブログ

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

【資料公開】#v_kansai 11でVue.jsのパフォーマンスについて話します。

vuekansai.connpass.com

京都Devかふぇ#7〜Vue.jsLondon2019参加報告会(非公式)〜【v-kansai共催】 - connpass と共同開催みたいで、こちらの参加枠はまだ空いているのでお時間あればぜひ。

表題のとおり、v-kansaiでVue.jsに関するパフォーマンスTipsについて話をします。本当はWorkerDOMの話も盛り込みたかったが時間が足らなかったのでまたどこかで...。
言い訳がましい感じになりますが、転職してからVue.jsを触っていないので、もっと良い方法はあるかもしれません。マサカリ待っています。

speakerdeck.com

参考にした記事

今週末のVue Fesは参加しないですが、台風は来ないであげてほしい。参加数1400名の大規模カンファレンスということもあり、運営さんは気が気じゃない想いだと思います。

ウェブリオを退職しました。「いい話」から5年経ったいま

この記事は念の為元上司に査読していただきました。

2019年8月末でウェブリオ株式会社を退職します。
ウェブリオはオンライン辞書サービスを運営する会社です。

インターネット上にウェブリオの中の人の声や退職エントリは少なく、ウェブリオに入社しようと考えている人にとって情報が少ないと思いこの記事を書くことにしました。ウェブリオへの入社を検討されている方に参考になれば幸いです。

「いい話」

とても多くの人に読まれたウェブリオの退職エントリがあります。
以下の記事ははてなブックマーク数1000を超え、「ウェブリオ 退職」で検索すると検索上位に出てきます。
そのため、ウェブリオに入社を考えている人は一度は読んだことあるかと思います。
便宜上、本記事では「いい話」と呼ばせていただきます。

takeda25.hatenablog.jp

しかし、5年前の記事で情報が古くなっています。

その後W社の社風や開発者の扱いに変化があったかどうか等についてご自身で最新の情報を得ていただければと思います。

と「いい話」の冒頭にもありますように、本記事ではウェブリオの現在についてお伝えできればと考えています。
これから書くことはあくまで2019年時点の情報です。もし数年してこの記事を読んでいる人がいれば参考になさらずご自身で最新の情報を探していただければと思います。

「いい話」から5年経ったウェブリオのいま

この節では「いい話」を読まないとわからない内容が含まれています。

「いい話」が投稿されたのが2014年4月で、僕が退職したのが2019年8月なので5年が経過しています。
そのため、会社の中は変わっています。
もちろん「いい話」に対して批判を書くつもりはございません。 というのもこの方とは在籍期間が重なっておらず、全く面識がありません。また、在籍していたオフィスも違います。
そのため「いい話」に関しては真実かどうかも判断できません。 ちなみに僕は「いい話」の流動性には共感する部分があります。

実質上司について

まず、「いい話」に出てくる実質上司はすでに退職しています。
僕が入社した2016年8月時点ですでに退職されていました。
「いい話」に登場するエンジニアの方々はすでに全員退職されています。
現在在籍するエンジニアの中には「いい話」に出てくるような性格の方はいないかと思います。

OSSについて

MIT ライセンスの JavaScript 外部ライブラリを使おうとすると、「使っても問題ないか調査してください」と言われ、またできれば外部のものは使わずに実装してほしいと言われた。

OSSのライブラリについてはむしろ使っていきましょうという雰囲気です。
ウェブリオ自身もGitHubにMITライセンスでソースコードを公開しています。

github.com

役員との関わりについて

偉い人レベルでの、従業員は使い捨て可能・交換可能な部品であるという見方。

これについては私は結構大切にしていただいていた方だと感じています。
意見を尊重してくれましたし、最終出勤日に営業部の幹部の方から労いの電話をいただいきました。
人によっては合う合わないありますが、幹部の方と従業員の距離は非常に近いです。
また、意見をする人を尊重・評価する傾向があり会社に意見はしやすかったです。

良かったところ

ここから先は「いい話」とは関係なく、私がウェブリオに感じたことを書いていきたいと思います。
私自身の体験や感じたことに基づくので、違った意見や考えもあるかもしれませんがそれは他の社員の方が書いてくれることを期待しています。

働く環境について

働きやすさ・風通しの良さを求めている人にはウェブリオはおすすめです。 「いい話」にも出てきましたが、残業は本当に少ないです。有給休暇も1時間単位で取れました。申請こそありましたが、却下されることはありませんでした。これが個人的には一番最高でした。
10:00〜16:00コアタイムのフレックスだったので、僕はたまに朝1時間の有給をとって11:00に出社していました。朝起きて「11時に出勤します」とメールするだけなので、有給のとりやすさは抜群に良いかと思います。
非常に働きやすい環境かと思います。子育て、コミュニティ活動、OSS活動を並行して行えたのはこの働きやすさがあったからだと感じています。

学習支援について

技術書やビジネス書などの書籍は申請なしで購入することができました。各々がAmazonでポチるだけです。申請はいりませんでした。
備品も正当な理由があれば購入してもらえます。
勉強会やカンファレンス参加も業務として行くことができ、参加費用や旅費を出してくれる制度もあります。
地方に住んでいるエンジニアとしては東京で行われるカンファレンスに参加しやすかったです。
そういった学習支援を重視している人にとっても良い会社だと思います。

良くないと思うところ

評価について

マネジメントよりコードを書き続けたいタイプの人にはおすすめしません。コード書いてるよりマネジメントしてる方が評価される傾向があるように感じました。成果を出し続けている技術力ある人よりマネジメントしている人の方が評価されていました。私の推測ですが、幹部にエンジニア上がりの人やCTOのような技術のわかる人がいないのが原因なのかなと思いました。これは幹部の人も対応しようと考えていてリーダークラスのエンジニアの意見を評価の参考にするなど技術に対して評価できるように試行錯誤しているようにも見えました。

給料について

給料は低いです。私は給与テーブル上の平社員ではそこそこ上のほうにいたと思いますが、年収450万円弱でした。そのため、ほとんどの社員が400万円台なのではないかと推測できます。私自身転職ドラフトの指名額などを参考に市場価値に合った給料をいただけていないことを把握していました。
これはウェブリオに限った話ではないですが、市場価値に合わせた待遇にしなければ良い人は採用できませんし社員は辞めていくと思います。
ウェブリオもこれについては人事を中心に考えていると思います。一気に給料UPはなかなか難しいと思いますが、少しずつでも改善されると期待しています。

ちょっと話がそれますが、報酬の総定額を採用プロセスの早い段階で言ってしまった方がいいんじゃないかなと思います。内定出してから報酬を伝えることが多いですが、その時点で大きくズレが生じていて辞退することになることは珍しくありません。双方にとって面接などにかけた時間とかもったいないと思うんですよね。その点、最初から金額がわかっている転職ドラフトは良かったです。転職ドラフトに限らず、今回オファーいただいた企業は最初に参考値を提示してくれました。大変助かりました。

退職理由

転職前に昇進の話をいただいてて給料も上がるし評価もいただいてたので、上記の理由が直接的な退職のきっかけになったわけではありません。優秀な方々が徐々に辞めていったことが大きかったです。他の人の退職に関しては様々な理由があるのですが、ここでは控えさせていただきます。
優秀な人が退職していきだんだんと楽しさを失ってたときに、ある企業からお誘いいただいたのが直接的な退職のきっかけになりました。
もちろん給料も前述の通り市場価値に沿った金額をいただきたいと考えていました。

最後に

「いい話」が書かれてから5年経ってウェブリオ内部の変わったところや私が感じたことを書きました。
色々書きましたが私はウェブリオに入社して良かったと考えています。子をもつ身としては働きやすかったですし、自由に色々させていただき成長につながったと思います。
もし興味があれば、応募してみてください。

www.weblio-inc.jp

次はサイボウズ株式会社のフロントエンドエキスパートチームで働きます。こちらも興味があればご応募お待ちしております!

cybozu.co.jp

退職のタイミングでなくてもいいのですが、会社のことを社外に発信することで採用のミスマッチを防ぐことができるかもしれません。どんどん発信していくべきだと思います。
この記事がウェブリオに入社しようか考えている人にとって参考になることを願っております。

最後までお読みいただきありがとうございました。質問などはTwitter宛やコメントなどでお願いいたします。

『たいていのことは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