Engineer Career Study #1 – スペシャリストとしてのキャリアを拓くに参加しました

Engineer Career Study #1 – スペシャリストとしてのキャリアを拓く

https://forkwell.connpass.com/event/200159/

に参加したので、そのときのレポートです。

 

オープニングセッション:古川陽介「スペシャリストになる覚悟」(20分)

スペシャリストとマネジメントは対立しているのか?

 → 両者に求められるものは同じ。どちらもマネジメントの要素を含んでいる。

  • スペシャリスト
    • 個人で成果を出す
  • マネジメント
    • 組織の成果に責任をもつ

この2つは対立していないし、境界線もはっきりしていない。

 

ソフトウェア開発において、個人で動くことは少ない。

また、マネージャーもソフトウェアの知識が必要。

両方において、人をリーディングしたり育成したりするというのは共通

そこで、マネージャーをやりたくないと思うのはもったいない。

 

しかし、両方やるのは大変。。。

 

古川さんの例

  • シニアエンジニアとして
    • アプリケーションの開発に入るのは少ない
    • プロトタイプ開発がメイン
  • マネージャーとして
    • メンバーのタスクアサイン
    • 採用・育成
    • コミュニティ作り

 

つまり、スペシャリストとマネージャー両方やるのは大変?

大変。しかし、両方やれることが大事。

そもそもスペシャリストになるにはどうすればいいのか?

古川さんの場合

リクルートにおけるシニアの要件

  • 社内外でエキスパートとして認知されること
  • その人が一人いるだけでプロダクト戦略が変わる

そういう人ができる人がシニアの要件。

スペシャリストになるために心がけること

  • 自分の責任にする
    • 以前、node.js 界隈は混乱していた
    • 当時、グローバルで起きていることを日本に伝えるしかなかった。
    • そこで、node.js io.js の差分をそれぞれフィードバックするように努めた。
    • 技術的に起こっていることを誰かに任せるのではなく、自分事にする。
  • 息を吐き続ける
    • 要はアウトプットし続けるということ
    • アウトプットし続けていたら、自然とインプットもできるようになる。
    • アウトプットのクオリティは上げ続けていく。
  • 何かしらのチャレンジを続ける
    • 最近は、マネージャーだけど毎日コードを書くのにチャレンジしている。
    • 常に何かやる。手を動かすことをやめない。
      • コンフォートゾーンに止まらないようにしている。

まとめ

マネージャーとスペシャリストは対立概念じゃない。

 → それを生かして共通項を見つけて行こう

 → しかし、両立するのは大変。だが、乗り越えればやりたいことができる。

スペシャリストになるには

  • 自分の責任にする
  • 息を吐き続ける
  • 何かしらのチャレンジを続ける

特別対談:「スペシャリストとしてのキャリアを拓く」

古川陽介さんパート

広木さん

node.js という領域を決めて走ったのが転機だったと思うが、どういう感覚で node.js に関わるようになったのか?」

古川さん

「楽しかった。やっていけばやっていくほど、こんなことができるんだというのが分かっていった。

そうしているうちに自然と。」

広木さん

node.js の実装って若干混乱していたスタートだし、激しい界隈だと思うが疲れないのか?」

古川さん

「疲れた感じはとてもある。コミュニティとして激しいし、変化も激しい。

最初はそれが気にならないくらい夢中だった」

広木さん

「スペシャリストってキャリアっていいなと思っている人にとって、没頭できるのはいいきっかけだと思いますね」

古川さん

「僕自身エンジニアコミュニティに育ててもらった。モチベーションの源泉だった。

一緒にやれる人を探すのはいいことだと思う」

広木さん

「内側でも外側でもオーガナイザーをやられていたので、その間でキャリアを積んでいったんですか?」

古川さん

「そうですそうです。」

松本亮介さんパート

広木さん

「すごい人に囲まれてたことが多いと思いすが、見るものを変えてたりしてたんですか?」

松本さん

「意識していると、それまで漠然とできないと思っていたことを意識すると具体的にできないことになる。

そうすると、あるときできるようになっていることに快感を感じる。

なのでひたすらそういう選択をしているというのはあるかもしれない」

広木さん

「サーバースペックについて論文に落としていくのは素敵だと思います。

ご自身の活動はどう定義づけていますか?」

松本さん

「エンジニアをやっていく中で、みんなが使っているものって良さや理由があると思う。

エンジニアと研究をしていくなかで、そういう部分を言語化して体系的にすることで、もっと狙っていいものを作れるのではないかと思っていた。また、言葉で明らかにしたかった。」

広木さん

「現在研究職のキャリアだと思うが、これから研究職目指している人にアドバイスありますか?」

松本さん

「自分の経験だとたまたまできたと思うので、一般化は難しいと思うが、いろいろ考えてきた

古川さんもおっしゃっていたが、自分が没頭できることを見つけて、それを社会に還元するようなサイクルを考えて言語化していけば、うまくやっていけると思う。」

和田 卓人さんパート

広木さん

「ご自身の中でキャリアを築いていくときの原理原則はありますか?」

和田さん

「スキルセットとしてはオールラウンダーではなくて技術に長けていた。得意不得意がはっきりしていた。

得意なものを伸ばし、不得意なものを得意なもので補うというのが合っていた。それが良かった」


アフタートーク

ここから先は forkwell 様に登録されている人だけが見れるコンテンツなので

ブログには書かないことにしました。

今回勉強会の運営をしてくださった forkwell 様ありがとうございました!

エンジニア用語を恋愛に置き換えてみた

最近アラサーになり、周囲の人でも

恋愛の話や結婚の話がチラホラ出てくるようになりました。

エンジニア友達と話をしていると、

何かをエンジニア用語で例えることが多く、面白いなと思ったので

関連表を作ってみました。

環境に関すること

dev 環境 彼氏 / 彼女がいるカップルの環境
staging 環境 同棲している環境
production 環境 結婚している環境
local 環境 妄想 / 片思い / 二次元嫁 / アイドル
close 別れること
sandbox お試しの付き合い
チーム 家族 / カップル

動作に関すること

deploy / release

出産 / 婚約届けの提出など

障害対応 子供の夜泣き / 相手からの深刻な急な呼び出し
お気持ち表明 告白 / 別れ話
ペアプロ 一緒に問題解決
リファクタリング 男磨き / 女磨き

その他

案件がある / ない 彼氏彼女になる可能性のある人がいる/いない
キャッシュ 前の相手をひきづっている
障害 喧嘩
プロジェクト 結婚式 / サプライズバースデイ
タスク デート / 結婚式の準備など
MTG 家族会議

 

他にも何かあったり、こっちのほうがしっくりくるっていうのがあれば

教えてください。

随時 update していきます。

【目標設定の技術を勉強する会 #1】に行ってきました

目標設定の技術を勉強する会 #1

https://engineers.connpass.com/event/113403/

に行ってきたので、そのときのレポートです。

 

仕事が長引いてしまい、4つ目の LT から参加しました。

 

2018年目標を達成できなかった私が今年こそ達成するためにしていること

発表者:花井宏行さん

 

目標について、障害が起きたときの

プランを立てておくことが大事。

例えば、減量を目標にしていて、

「お菓子を我慢する」だけではなく、

「代わりにガムを噛むとか歯磨きをする」

などの、お菓子を我慢できない場合の代替プランを考えておく。

これを、ヘミングウェイ方式という。

振り返りをする

前進していることの感覚をつかむ。

どこでつまづいているのかを観測できる。

長期的な目標だと日々の進捗がわかりづらいので

目標に幅を持たせる。

減量を目標にしている場合、例えば、

減量は -7 ~ -13 kg など

まとめ

  • マンダラチャートをつかって、目標ができていない理由の分析をしよう。
  • 目標の建て方はヘミングウェイ方式
  • 見積もり通りに実行するために、あらかじめ時間を抑えて、カレンダーに登録しておくなどしよう。

海外移住を実現するためのこれまでとこれから

発表者:スコーンさん

自己紹介

日英通訳志望から、海外移住のためにエンジニアにキャリアチェンジ。現在エンジニア2年目。

 

今日話すこと

ゴールを決めて、そこからマイルストーンとアクションに落とし込んでいくということ

話さないこと

目標設定のフレームワーク

 

今回のゴールは

永住権を get すること

 

マイルストーンは

  1. エンジニアになる
  2. 現地就職する
  3. 数年働いて永住権ゲット

 

マイルストーン 1 の「エンジニアになる」を達成するために

3つの action を定めた。

  • progate をやってみる
  • スクールで勉強する
  • エンジニアとして就職

マイルストーン 2 の「現地就職する」ということを達成するために

3つの action を定めた。

  • 3年実務経験を積む
    現地では3年以上の経験が求められている
  • 開発スキルと英語を伸ばす
    pramp というサービスを使っている。
    → 英語面接する人が勉強したりしている。
    プルリクのレビューを英語でやったりしている。
    1日に10分は触れるようにしている。
    action のコツは、細く、長く
    1日のやることは小さくても、トータルでみて大きなことに繋げる。
  • 現地に行って就職活動

 

総じて言えることが、逆算で action を明確にしたほうが良いということ。

また、action はより具体的なもののほうがよい。(例えば progate をやる、など)

そしてブレイクダウンした目標は遠いものよりも、近いもののほうがよい。(日々の成長を実感できるから。)


目標設定とその方向性

発表者:小松計之さん

 

コンフォートゾーンというものがある。

  • コンフォートゾーンとは
    自分が心地よい、リラックスした状態
    何かに縛られていない。
  • ストレッチゾーンとは
    少し背伸びした緊張状態
  • パニックゾーン
    慌てふためいて、何をしてよいか分からなくなる。

 

パニックゾーンに落ち入ったら

一度コンフォートゾーンに戻りましょう。

 

これを踏まえて目標設定するには

  • 少しハードルが高いが、自分で手が出せる
    → ゴールが果てしなくならないように

    • ゴールを見失わないようにしましょう。
    • 自分のペースで、他人と競争しない。
      他人と比べてしまうと、ペースが乱れてしまう。
  • 漠然とせずに、具体的にどうするのか
    → 資格であれば、参考書や教材

    • 分からなければ知ってる人に聞く。
      できればメンターをつけましょう。
    • 具体化しにくければ、箇条書きにしてからあとから肉付け。
      そのほうが、思っていたところと、実際に客観的にみたときに自分がどうしたいのかということを見直すきっかけになる。
  • いつまでにやるのか。
    → 期限を決める。

    • 余裕持った時間配分を
    • 仕事しながらとか他のことしながらとかあるので、自分のペースを乱さないために。
    • 期限内にできなくても自分を責めない。
    • できなくても、新たに再チャレンジすることが大事。

まとめ

  • コンフォートゾーン
    自分のモチベーションのありかたを確認しよう。
  • 少し背伸びした目標設定
    果てしなくならないように
  • 目標に対して具体化
    細かくしていくことが大事。
  • 期限を決める

成果をつくる目標管理

発表者:坂井健治さん

 

仕事で目標が達成できないとか、段階が踏めない人向けの発表です。

目標が適切か?

SMART の法則

https://boxil.jp/beyond/a5166/

特に大事なのは

  • 計量可能かどうか?(Measurable
  • 関連性があるか?(Relevant
    → その目標が何と関連しているか?

なぜ計量可能が大事なのか?

人の意見からは目標達成できたか分からない。

なぜなら、人によって意見が異なるから。

だから、指標を用意してゴールの数値化をしましょう。

なぜRelevant が大事なのか?

何のためにその目標が大事なの?という、共感しない人が出てくるから。

何のために大事で、ということをみんなが共感できるようにしよう。

結果目標の注意点

自分だけでコントロールできない

行動目標のメリット

自分でコントロールできる。

決めてしまえば、あとはやるだけ。という状態にできる。

【サポーターズCoLab勉強会】エンジニアのためだけの英語入門に行ってきました

【サポーターズCoLab勉強会】エンジニアのためだけの英語入門

https://supporterzcolab.com/event/533/

に行ってきたので、そのときのレポート

 

以下、講義を聴きながらのメモ

 

登壇者の方は、留学の経験があるが、

留学したからといって、すぐに英語ができるわけではない

それがきっかけになって勉強しようと思った。

 

その辺の本屋で、「2語で伝わる英会話!」とかいう本が多いが

そういう楽して学べる英語は本当の英語ではない。

 

この勉強会を通して、

みなさんが英語への一歩が踏み出せればよい。

エンジニアが英語できると何がよいか?

嬉しいことはすでに分かっている。

が、英語を勉強するのはとてもしんどい

なので、目標やモチベーションが大切。

嬉しいこと1: 入出力のスペック大幅アップ

入力

  • 最新のドキュメントが読めるようになる。
  • 疲れずに英語のドキュメントが読める。

出力

  • 例えば、技術ブログなどを英語で書くと、海外の人も見てくれる。
  •  OSS 活動がしやすくなる(PR  のコメントやコミットメッセージなど)

嬉しいこと2: 市場価値の高い人材になれる。

嬉しいこと3: もちろん、お給料が増える

いろいろなデータを見ていると、英語ができていると年収が上がる人が多い。

嬉しいこと4: 転職の際の選択肢が広がる

例えば、海外企業に勤めたいというのがまず浮かばない。

それは、英語ができないから。

それで選択肢が減っているのはとてももったいない。

嬉しいこと5:  かっこいい。

 

英語のジャンルを4象限に分けたとき

  • listening (リアルタイム・自分でコントロールできない)
  • speaking (リアルタイム・自分でコントロールできる)
  • writing (ノンリアルタイム・自分でコントロールできる)
  • reading (ノンリアルタイム・自分でコントロールできない)

どれが難しいか?

ノンリアルタイムの方が、翻訳ツールなど使えるので簡単

事前に準備できるspeaking, writingは、自分でコントロールできるので簡単

逆に準備できないのは、相手に依存しているので、むずかしい。

準備すれば誰だって英語でスピーチできる。

結論からいうと、

listening が一番難しい。

speaking ができれば、writing はそれを書くだけなので speaking のほうが難しい。

エンジニア向け、英語表現テンプレート

英語の人は、あいさつの始まりに「調子どう?」みたいなのをめちゃめちゃ言う。

ただ、how are you? はほとんど言わない。

what’s up の返答は i’m fineじゃだめ

最近なんかあった?とかそういうことを聞かれている。なので返答は難しい。

 

ずっとyesを使ってると、硬い人だと思われるので、いろんな表現を使えると良い。(yup など)

コミットメッセージとかは、日本語よりも英語のほうが簡単だったりもする。

主語とかいらないんで、動詞から始まっていい。

speaking 攻略

格好つけずに簡単に喋る

 

発音

日本人を知ってる海外の人は、日本人が英語の発音がひどいことは分かっているので

海外の人もそこは日本人に合わせて喋ってくれる。

逆に、自信なくして小さい声で喋ると、もっと伝わらないのでよくない。

 

喋りながら、発音が難しい単語は避けるようにする。

R と L の発音は本当に難しい。

が、R と L を入れ違えたときに存在しない単語だったら

相手が意味を汲み取ってくれるので、意外と大丈夫だったりもする。

Q & A

Q1.

英語をはじめたきっかけは?

A1.

学生の頃の先生が良かった。

 

Q2.

こういう勉強方で良かったというのはあるか?

A2.

実際に喋るのがよい。skypeとかで喋れるサービスもある。

DMM 英会話など。

 

Q3.

話をしていると、分からない単語があって、スペル自体も分からないから調べようがなさそうだがどうすればよいか?

A3.

スペルが分からなくても、それっぽい単語でぐぐったら、googleがもしかしてこの単語?とサジェストしてくれるので、それをつかっている。

 

Q4.

下手な英語を喋って相手を怒らせたときの対処方は?

A4.

そもそも怒らないと思う。そうとう変なこと言わなければ。

 

Q5.

日頃、ものを主語にしてしまうことがおおいが、人を主語にしたほうがよい?

A5.

いや、それでもよい。

 

Q6.

ゲームのチャットで英語を勉強するのはよいか?

A6.

何もしないよりは良いが、ゲーム特有のスラングとかもあるので、仕事で喋るほうがよい。

 

Q7.

どの程度英語ができたら市場価値として英語ができると言えるか?

A7.

どのくらいかはわからない。ただ、自分は英語できますと言える。

 

Q8.

実務として、エラーを検索するときは、どういう検索の仕方をしたほうがよいか?(効率の良いググり方は?)

A8.

普通に日本語で検索することもある。そのほうがわかりやすいので。

 

Q9.

英単語を覚えるためにどっかに保存している?

A9.

頭の中に保存している。話すときに何か見たりはできないので。

補足:

alcというサイトが良い。

辞書のようなサイトだが、辞書ではなくて、その単語を使った例文が表示される。

 

Q10.

日常で使うテンプレートとかある?

A10.

それが難しい。エンジニアに限定すると用途に特化して作れるが、日常会話は難しい。ので、テンプレートは持っていない。

 

Q11.

英語のpod cast など使っているか?

A11.

聞いていない。ただ、聞くとしたら自分の英語レベルにあったものを聞いたほうがいい。

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得に行ってきました

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得

https://supporterzcolab.com/event/410/

に行ってきたので、そのときのレポート

対象者

  • 現在新規事業の立ち上げに携わっている方
  • これから新規事業にたずさわるかもしれない方
  • (もしくはたずさわりたいと思っている方)
  • ライブラリを書くより、プロダクト開発が好きな方

話すこと

  • 作りすぎて失敗したことの事例紹介
  • つくりすぎないために
  • コアバリュー大事

登壇者の方が作ったサービス

pook

https://s.pook.life/lp/

ランサーズは、オンラインクラウドソーシングの会社だが

pookはオフラインでやることに特化したサービス

 → オフィスで肩を揉んでくれたり

 → 栄養士の方が手作りご飯を届けてくれたり

本題

エンジニアの新規事業への関わり方

そもそも新規事業って?

新規事業とは、既存事業から生かして、新しい経済成果を生み出すこと。

対して、起業というのは0から始めること。

どうやって関わって行くの?

求められること

サービスを作ることが求められる。

実際には、プログラムを書くというよりは、問題を解決すること。

失敗1:作りすぎた。

リリース時に作ったのは、

  • APIの数150本
  • ページは80

ガチガチの仕様をその通りに作ってリリースした。

多いと何が悪いか。

多いとリリースが遅くなる

 → 多すぎたということは、無駄なことを作ってしまった。

  → 使われないコードはただのゴミ。

本当にあった怖い話

 nヶ月書けて作った仕組みをすぐに消した。

 顧客が本当に求めていたものと違った。

どうすれば良かったか?

作らなければよかった

 → しかし作って見ないと分からないこともある。

  → 作る前にそもそも考えることがあるはず。

  • 同じような体験ができるサービスを作って模擬する。
  • ユーザーにもっとヒヤリングする
  • プロトタイプで実験してみる。

反省

  • 作らないで実験できないか考えてみる。
  • 試したい仮説をすぐに実装できないか考える

失敗2:技術選定

エンジニアあるある。

最近イケてる○○という技術を使おうぜ!

 → 既存に縛られないので、使いがち

結果

情報が少なくて死ぬ。

社内で知識が多い人の助けも受けられない。

サービスがあたるか当たらないかという問題の前に

サービスが作れるか作れないかという問題が発生する。

反省

  • 枯れた技術を使うべきだった
  • もっと協力しやすい技術を選定すべきだった。
  • できるかどうか分からないは早めに潰す。

失敗3:仕様が変わる。

どうしてそうなった?

  • 作るべきものがあやふやだった
  • 目的を達成するための機能がもりもり
  • 全部マスト

どうすればよかった?

コアバリューを定めて、やらないことを決める。

コアバリューとは?

ミッションやビジョン実現のために、組織が独自にもつ共通の価値観。

これを選定することで、作らないものを決めることができる。

 → コアバリューはなんですか。どうしても欲しい機能はなんですか。と唱える。

  → そうすることで、議論の着地点も見つかる。

反省

コアバリューを決めて、作らないを決める。


まとめ

新規事業開発に置けるエンジニアの心得

  • 一番大事なことは作らないこと
  • また、そのために、コアバリューを決める。
  • エンジニアとして問題を解決することにコミット

とはいえ、経験がないと分からないことが多いので、経験をたくさんしよう。


Q & A

Q1.

コアバリューを決めることでいらないものが見えてくるということだったが

APIの数など具体的にはどの程度減ったりするか?

A1.

Apiの数は80本になったりした。大体全部合わせて半分くらいになった。

Q2.

やっていくなかで一番コストがかかることは?

A2.

新規事業でいうと、人件費が一番コストになる。

技術でいうと、どこにコストがかかるか?

 → 作って捨てればいいので、キレイに作らないことを考えればよかった。

  → 無駄にキレイにつくることを考えてしまった。

   → 結果、使われないキレイな部分ができてしまった。

なので、キレイに作るっていうところにコストがかかる。

Q3.

新規事業をやる上で、予算をどのくらいに抑えろとかあったか?

A3.

最初はなかったが、途中からなんでこんなに時間かかってんだとかあった。

最初はノリで始まったものだが、どうしてこれこんなに時間かかってるの?とか。

新規事業は黒転するまでに時間がかかる。

 → なので、試算を前もってしておいて(エンジニアどのくらい必要です。どのくらいでリリースできます。どのくらいで黒転しますとか)ロードマップ考えておこう。

Q4.

開発するに置いて、「これ使ったよ」みたいなツールとかあるか?

A4.

プロトタイプを作るツールでいうと、InVisionというツールを作っていた。

https://www.invisionapp.com/

InVisionというのは、web上ピピッと操作してプロトタイプを作れるツール。

逆にコンフルエンスを使ったのは失敗だったと思った。

コンフルエンスはバージョン管理ができたり、キレイに書けたりすることができるツール

別にキレイに書く必要はなかったが、キレイにかけるがために、キレイに描こうという空気ができてしまった。

それよりも、ガンガンアウトプットできるようなツールのほうが良かった。