2018年振り返り

自分語りエントリーです。今年を振り返る。

React Hooks やっていき

エンジニアがアウトプットすること

昨今の周辺環境

筆者はWeb業界のエンジニアであるが、昨今のまわりのできるエンジニアを見ていると、以下に列挙するような活動を息をするようにしている印象を受ける。

• LT会・カンファレンスでの登壇
• 技術書・技術同人誌の執筆
• ポッドキャストの配信
• Qiitaや個人ブログへのポスト
• OSSへの貢献
• etc

もちろん全てコンプリートしている人は割合として少ないけれど、どれもやってないのであれば多少の危機感を持ったほうがいい、という程度には浸透してきているのではないか。

なぜするのか

上に挙げた項目たちは基本的に業務外で行うことが多いようなものだ。多少は業務内に行うこともあるかもしれないが、会社の業務から外れることは多い。

そんなに大変なのになぜするのか。 例えばいくつか項目を抜き出して見ると以下のような作用が挙げられる。

• LT会
  • 話をして懇親会で様々な人と出会うのは知識と人間関係が広がる
• Qiitaやブログ
  • 記事を投稿してたくさんいいねしてもらえるのは単純に嬉しいしやる気が出る
• OSS
  • 自分の好きなライブラリやフレームワークにJOINできる

そこから、推測すると以下のように言語化ができそうだ。

• 心理的安全性
  • 他社からの評価や実績を積み重ねることによる、承認欲求や自己肯定への影響
  • 活動を通して業界への影響度が高まる
• キャリアラダーへの影響
  • 採用面接などで自分の強みとしてアピールできるポイントが増える
  • 転職やスカウトされやすい状態を維持しやすい
• 成長
  • OSSなどで優秀なコミッターからレビューしてもらえる
  • お互いに切磋琢磨できるような人間関係の形成
• コミュニティへの貢献
  • 技術コミュニティを活性化させるための貢献

他にももちろんあるんだろうけれど、ざっくりこんな感じになるだろう。 そして、回数が増えれば次になにか活動するときにもどんどん動きやすくなっていく。技術も上がっていくだろうし、これはまさに乗るべき電車に乗れるようにする準備の一つと言える。

hb.matsumoto-r.jp

必ずしも強制的に行わなければならないものではないが、給料や待遇・環境をよりよくしたり、高みを目指すのであれば、上に挙げた行動は大きな武器になる。我々の業界は一つの会社で一生を終えることは少なく、転職のハードルも他業種に比べて低いことも、モチベーションとして多少影響しているようにも見える。

CustomerからSupplierへ

そんなわけで、技術者は今や発信者になってきている。キャリアラダーの観点から見ても、CustomerからいかにしてSupplierになるかは重要なファクターだ。インプットと同量もしくはそれ以上のアウトプットが求められてきていることは、現場で働くエンジニアとしては自分自身もひしひしと感じている。

何を話せばいいのか問題

まず、行動しよう！と息巻いてもなかなか腰が上がらないこともあるだろう。資料を作ろうと思ったときにこんなことを懸念にしたことはないだろうか。

レベルの高い話をしないといけないんじゃないか

聞いてくれる人や読んでくれる人が満足してくれるものを書かないといけないのではないか。こんなレベルの低いことを伝える意味なんてないんじゃないか。白い目で見られたらどうしよう。こうなるとなにか行動はしたいけれどできずに辛い。これを克服するに少し発信内容を整理する。

アウトプットを考察する

まずは発信内容を少し整理しよう。例えば以下のようにざっくり分けることができる。

• マインド・心構え
  • 文化や社内風土
  • 人生設計
  • 開発者としての普遍的な心構え
  • etc
• 実際の技術
  • 既存知識の整理
  • 新しいフレームワーク・技術の紹介
  • 独自に取り組んでいるTips
  • 発生ベースのナレッジ共有
  • etc

ここで大事なのは「既存知識の整理」だと思う。 新しくてみんなが知らないことを話すことは必須ではないのだ。LT会で自分がすでに知っていることを話している人がいたとしても、つまらないという感情より先に、「わかるー」とか「それな」なんて気持ちになることが多い。そして、既存知識の整理は初心者や最近触れていない場合には手助けになる。無駄ではない。

自分の血を通わせる

ただし、一点だけ守っていきたいことがある。

発信する内容には自分の血を通わせてほしい。

どこかの記事にあった内容をつぎはぎにしても発信することはできる。だけどそれでは成長に繋がらない。自分自身がどう思ったのか、そして問題があるならどうしたらいいと思うのか、それらを言語化する必要がある。

血を通わせるというのはそういうことであり、血が通っていないコンテンツはどれも面白くないだろう。アウトプットすることが自体素晴らしいことではあるが、自分の文章や発信するコンテンツには正直でいてほしい。

そして血を通わせるにはある程度の知識が必要である。だから我々は毎日はてぶを眺めたり、海外の技術ブログを頑張って翻訳する。そうして得た知識から自分の経験と照らし合わせ言語化する。それはきっと面白い内容になると思う。そこでしか得られないあなたを通した知識になるのだから。

IT芸人化を避ける

人前に立って発信することはエキサイティングだ。他の会社のエンジニアとの交流は楽しい。そしてそれは全て素晴らしいことだと思う。だからこそ、時間は有限であることを忘れないようにしたい。業務の時間を削ってまで傾倒してしまえば、当然本業に影響が発生する。人事や採用担当者はこのあたりに敏感で、いくら業界的に著名であったとしても「あの人IT芸人だから...」という理由で不採用になることは少なくない。自分とコミュニティの成長のための慈善事業と言うと胡散臭くなるけれど、目的と手段を見失わないマインドは持っておきたい。

アウトプットすること自体が素晴らしい

そんなわけで、アウトプットすることは素晴らしい。自分が話したいことを思うがままに話していいと思う。幸い間違っていたら誰かが教えてくれる。失敗しても部分的成功だと思うと少しは楽になるかもしれない。 何かを発信するときは勇気を出して、自分の血を通わせたコンテンツを思い切って投げつけてみよう。もちろん本業を大切にしつつ。

yarn.lockに複数のバージョンが存在する問題の回避方法

社内にあったプルリクエストを見て参考になったのでここに備忘録を書く。

問題

1. TypeScritptを使用しているプロジェクトで、すでにReactがインストールされている

2. Reactのバージョンアップを実行

   yarn add react@latest -S yarn add react-dom@latest -S

バージョンアップは問題なく実行できるが、tsc実行時に大量のエラーが発生するようになった。

Argument of type 'ComponentClass<Props, any>' is not assignable to parameter of type '"tspan"'.

原因

yarn.lockの差分を見ると、@types/react@* と@types/react@^16.7.6という2つのセクションに分かれていた。

解決

yarnでは、"resolutions"でバージョンを固定することで、yarn install時に自動的にバージョンを統一できる。

Yarn

package.jsonの"resolutions"にバージョンを指定することで固定させる。

"resolutions": {
  "@types/react": "16.7.6",
  "@types/react-dom": "16.0.9"
},

この状態でnode_modulesを一度削除し、yarn installし直すと、インストールされた@types/reactが混在しなくなり、エラーは発生しないようになった。