コミュ障でもコミュニティで新しく友達を作れる ~ コニュニケーションが苦手な人ほど登壇しよう

登壇すれば、自己紹介が完了した状態を作れる。ただし、そこには「貢献」の心が伴うこと

Comunity Leaders Summit in 高知 Returns というイベントでLTした内容です。スライドが超絶言葉補足前提のものだったので記事で補うものです。「コミュニティ活動を通して得たビジネスやキャリアに関係する良い影響」がお題だったのですが、僕としてはその「良い影響」を得る過程で得たある気づきがとても大きかったと思い、そんなお話をしました。コミュニケーション能力強者が多いコミュニティリーダーの方々、僕のような奴を見かけた時にアドバイスしてやっていただければ幸いです。

eventregist.com

www.slideshare.net

コミュニティイベントで登壇すればコミュ障でも新しく友達を作れる

コミュニティ活動に参加することの大きなメリットに「人との繋がり」があります。コミュニティで知り合った人から仕事の依頼をもらえた、知り合った人の会社に転職した、社内では相談しづらい悩みを相談できた、などなど、人と繋がると良いことがたくさんあります(コミュニティ活動で得られる良い事についてはイベントで色々な方々が語られておりますしたので割愛)。

しかしながら、その「人と繋がること」自体が僕らコミュ障にとっては難しい。 同じような興味関心を持つ人たちのあつまるコミュニティの中とはいえ、新たな関係を自分から構築すると言うのはとてもハードルの高い事なのです。

ということでこの記事では、僕のようにコミュニケーション能力に自身がない人でも実践できる「コミュニティにおける勉強会やイベントで新しく友達を作る方法」についてお伝えしたいと思います。

  • 勉強会でのネットワーキングが苦手な人こそ登壇しよう。登壇すると、会場全体に自己紹介が完了した状態が作れるから、話しかけてもらえる確率があがるよ
  • 登壇の敷居が高い!と言う人はコミュ力以外で役に立てることを見つけてやってみよう(些細なことでも良いから続けてみよう)。きっと誰かがみていてくれるよ
  • 「貢献する」って思いがなければ何をやってもダメ!絶対にダメ

勉強会でのネットワーキングが苦手な人こそ登壇しよう

僕はいわゆるネットワーキングタイムというのが苦手です。初対面におけるコミュニケーションで色々考えてしまい、なかなか滑り出しで良い会話をする事ができません。 昔の自分も、師匠の教えに忠実に外と繋がるべく、勉強会、懇親会に積極参加したものの、一向に成果は得られませんでした(技術的知識の蓄積にはなったのだけど、ここでいう成果とは、色々相談できるような人とか一緒に頑張ろうぜできる人との出会い)

ネットワーキングが苦手な理由

僕と同じような感じの人いるんじゃないかと期待して書いておきます。 そして、こんな人にこそ 登壇 という手段がおすすめです。

自分から話しかけるのが苦手

話しかける人のことがわからないので、自分との会話や繋がりで価値を感じてもらえるかどうかが不安、そこからくる話しかけたけど微妙な反応をされることへの恐怖故に話しかけられない。話しかけるタイミングを伺うのも苦手、既に誰かと話をしているところに割り込んでいくのは上記の理由より問題外です。

心の中(この方どう言う方なのかな。仮に自分が話しかけたとして、この人に何か有意義な時間を提供できるのだろうか。対話システムとかITとか興味あるのかな。またはめっちゃ知ってて僕なんかと話しても新しい情報一つも増えないような感じにならないかな。というかなんか疲れてしゃべりたくない気分だったりするんじゃないかな...あ、誰かと話し始めた。他に空いてる人いないかな〜。あ、とりあえずピザ美味しそうだからピザ食べておこう)

こんなことを考えて、お腹だけ膨らませて帰るのが日常でした。

自己紹介が苦手

シンプルに「僕は〜〜で〜〜をやっています」というのに大きな心理障壁があります。

具体的には例えば「興梠です。NextremerっていうAI Techベンチャーで働いています」って言うと同時に心の中(AIって言っちゃったけどこの方はどういう属性なんだろう。AIの定義とか気にする人なのかな。だとするとあとでウチが対話UIメインでやってるって知ったら「対話UI=AI」みたいに考えていると思われちゃうかもしれない。ちょっといやかも。事業としては対話UIが中心であるものの、深層学習/強化学習周りもやっているよと伝えるべきだろうか、対話にしてもDNN使った対話とかも取り組みの研究をしていることを共有すべきだろうか。あ〜いや、だけどそこまで反応ない人だと困るよな。そうだ、僕が前にSIerで働いていたり、IoTとか色々手を出しまくってた話もした方が良いのかな。というか、エンジニアですって言うとどう思うのかな。ちょっとエンジニアリングだけではなくて営業的な部分とか会社経営サイドちっくなお仕事もやっているって言った方が興味持っていただけるのかな、、あ、名刺に高知って書いてある。東京と高知両方あるって言った方が良いのかな。なんで高知でこういうことを〜とか語った方が良いのかな、、、あ〜〜とりあえずどうしようどうしようどうしよう) みたいなことを考えてしまってスムーズにわかりやすく自分を伝えられない事が多いです。

せっかく会話が始まったのに、いまいち盛り上がらずにピザを食べて帰るのが日常でした。

登壇すると「自己紹介が完了した状態」になるので、話しかけてもらいやすい

話しかけるのが苦手なら、話しかけてもらう

勉強会で登壇すると、発表中での自己紹介の内容、趣味嗜好、今取り組んでいること、考え方、レベル感、などなど、多くの情報を参加者に届けることができます。相手が自分のことをある程度知ってくれている状態、もっというと 何が共通の話題になるのかを知ってくれた状態を作れます。

共通の話題が見いだせる相手には話しかけやすいものです。思い返してください。他の参加者の方には話しかけずらかったかもしれませんが、登壇者にはなぜか話しかけやすかったはずです(空いてれば)。

発表での自己紹介は、一対一の自己紹介よりも難易度が下がる

登壇は自己紹介の難易度自体を下げる効果もあります。1on1状態の自己紹介とは違い、長く喋っても大丈夫です。そして何より、スライドを使うことができます。

登壇するなら場に貢献できる事を話そう【重要】

発表するならば、まずは長時間の発表ではなく、尺の短いLT(ライトニングトーク)等が良いでしょう。勉強会によってはLT枠を募集しているものもあるので、そこにエントリーすることでチャンスを得ることができます。

ただし、LTといえども舞台を私物化して好き勝手な話をしても状態は好転しないので要注意です。 ギブから始まるのが世の常です。何を喋ったらみんなの役に立てるかを考えましょう。

僕の人生初のLT登壇は、人生の中で最も思い出したくない瞬間の一つです。発表中は頭が真っ白になり、発表後はすぐにでも出て行きたい気分を必死でこらえ、懇親会的なものにも出ずに帰ったことを覚えています。

敗因はもうわかっていて「全然凄くもないのに背伸びをしてすごい人っぽいことをしようとして無価値な発表をしていた」というものです。

大抵のコミュニティは寛大です。すごい人たちも強い力を持つがゆえに寛大です。。。寛大な傾向があると思います。しかし、それはコミュニティに貢献しようとする姿勢があることが大前提です。場を私物化して好きなことをいって、それが有益でもないような奴に誰も興味は持ちません。

具体的には?

では具体的にどんな内容を喋るのが良いでしょうか。ここでは技術系イベントのLTを想定します。

客観的に誇れる成果や知識がある場合は素直にそれをシェアすれば良いでしょう。しかし、なかなか見つかるものでもありません。そんなときは「自分の体験」を語るのがポイントです。もちろん、無理に深夜アニメのスライドを挟んでボケる必要はありません(できることをやりましょう)。

  • コミュニティでフォローしている技術を現場に適用した!
    • 多様な現場に当該技術がFitする/しない という知見や、新たな適用方法、組み合わせのアイディア、その課題などを提供
    • より良くするためのHowを考えるきっかけを提供
    • 普及活動に前向きに取り組む仲間がいるという勇気を提供
  • コミュニティでフォローしている技術の習得に挑戦した!
    • 多様なレベル感の人のハマるポイントなど、学習における感じ方を提供(会社での教育に使えるかもしれない)
  • 他の人の以前の発表を実践した!
    • 発表者への勇気づけ
    • シェアした知識が色々な人によって磨かれていくというそれはもう美しい...

ネガティブな内容でも全然ありですが、大事なのは身の丈にあった発表をすること。決してマスターではないのにマスターな振りはしない。挑戦のハードルは背伸びしても届かない程度の物が良いかもしれませんが、発表の姿勢は謙虚であることに越した事はありません。

ドヤりたいなら発表の前に相応の血反吐を履きましょう。

登壇するのはハードルが高い!というひとは、とにかくその場で役に立つと思ったことをやってみよう

登壇が効果的であるとはいえ、それは崖から飛び降りるような行為でもあって、中には踏み切れない人もいるでしょう。僕自身は「やってやるぜ!」と息巻いて飛び出すことはできたものの、その後の人生初のLTで大失敗した心の傷はなかなか癒えず、なかなか2ndチャレンジをする事ができませんでした。初対面におけるコミュニケーション能力をあげる以外はいつかは超えなければならない壁ではあるものの、やはり、いきなり超えるのは厳しいものです。

というわけで、そこに到るまでのステップ、ないし代替案としてのオススメの行動が 場に貢献する事 です。どんな些細な事でもいいから、以下のような役に立つ行動をしてみましょう。地味ですが、どれも喜んでもらえると思います。

  • 前の方の席に座るようにする
  • 会場の現状復帰を手伝ってみる(椅子並べ直し / ゴミ捨て)
  • 登壇者の言葉に積極的に反応して(うなづく等)登壇者を孤独にしないよう助ける
  • イベントハッシュタグ付きで実況する / 登壇してくれた人を褒める

これの何が良いかと言うと「話しかけられるきっかけになること」です。 「ありがとうございます〜」「いえいえ〜」というやりとりから「普段何やられている方なんですか?」って話しかけられるパターンが期待できます。なんせコミュニティ活動です。コミュ力の高い人は必ずいます。頼りましょう。まず役に立って自らが敵でないことを証明しましょう。すぐに友達とはいかないかもしれませんが、この積み重ねが信頼を産むのです。コミュ力がない分は行動でカバーです。椅子を運ぶのにコミュ力は要りません。

続けていけば「You次しゃべっちゃいなよ」みたいに機会を与えてくれたり、発表内容についてのアドバイスをくれるかもしれません。コミュニティのコントリビュータのサポートがあるのです。これなら恐怖の壁も超えられます。

まとめ

  • コミュ障だけどコミュニティで新しく友達を作りたいと思ったら「コミュニティに貢献」しよう
    • それは登壇でも些細なお手伝いでも良いはず
      • 登壇の場合は自分勝手な発表内容でないか注意しよう
        • 学習者は潔く学習者としての立場で!
    • そこにいるだけで価値のあるスーパーマンとかは、確かに話しかけられるけど、そんな事は他者が決める事であって背伸びしてすごい人っぽいオーラとか出すとシラけるよ!(自身があるなら良いけど)

終わりに

発表の内容まとめるつもりだったのにリライトみたいになってしまいました。 今回はLTで話した情報量を全部補う(+α)スタンスで書いてみましたが、かなりの文字数いくんですね。

それでは

追記 : コミュ障という言葉についてうんぬん考えたが一旦これで発表してしまっているのでこのまま公開する。議論が生まれればする。

Active Book Dialogue をやるときは「場の心理的安全性の確保」が重要だと思った話 - ABD x エンジニアリング組織論への招待 をやってみて

f:id:rocky_manobi:20180729001257p:plain

Nextremerが主催する勉強会「Nextremer Tech Meetup@高知」の第二弾として、「Active Book Dialogueで"エンジニアリング組織論への招待"を読む」というやつをやりました。その際に「あ〜このイベントは場の心理的安全性の確保が大事っぽい」と思ったのでその話を書きます。

nextremer.connpass.com

イベントの様子はこちら!(本当にありがとうございます)

ABD - Active Book Dialogue とは

ABDはざっくり以下のような流れで進行するアクティビティです。

  • みんなで集まる
  • 一冊の本を切り刻む
  • みんなで分担して読み、要約する
  • 成果物を張り出し、順番に発表する
  • みんなが興味を持った所について対話する(ダイアローグ!!)

ねらい/効果等は以下、公式サイトより開発者様の言葉を引用します。

アクティブ・ブック・ダイアローグ®は、読書が苦手な人も、本が大好きな人も、短時間で読みたい本を読むことができる全く新しい読書手法です。 1冊の本を分担して読んでまとめる、発表・共有化する、気づきを深める対話をするというプロセスを通して、著者の伝えようとすることを深く理解でき、能動的な気づきや学びが得られます。 またグループでの読書と対話によって、一人一人の能動的な読書体験を掛け合わせることで学びはさらに深まり、新たな関係性が育まれてくる可能性も広がります。アクティブ・ブック・ダイアローグ®という、一人一人が内発的動機に基づいた読書を通して、より良いステップを踏んでいくことを切に願っております。

同サイトにてマニュアルも配布されていますので、やってみたいと思われる方はぜひ。

また、タイトルにもありますが、今回はエンジニアリング組織論への招待 という本でABDしました。

場の心理的安全性の確保が大事

奇しくも対象とした本にも書かれているワードですが、このアクティビティを運営するにあたっては、場の心理的安全性を担保することが何より大事だと感じました。

本の一部分のみから得た情報を要約するわけです。「完璧なものを出さなきゃ」「変なまとめしたらバカにされる」などという心理が働いていては手が動きません(きっと)。対話においても「いいこと言わなきゃ」「コレを言ったらバカにされるのか」なんて思っていたら発言なんてできません(きっと)。

前提条件や目的を丁寧に共有する(した方がよさそう)

参加者同士は学びを得るための仲間であり、競争相手ではないこと。対象の本を読んだことがある人も入れば読んだことの無い人もいること。対象の本を専門としている人もいればそうで無い人もいること。同一の事象/事実でも、重要だと感じる部分は人によって違うこと。要約や発表に慣れている人もいれば慣れていない人もいること。何より 目的は対話を通じて得られる能動的な気づきや学びであり、完璧な要約を分担して作ることでは無い ということを丁寧にインプットすることが、より質の高い場づくりに寄与するのだと感じました。

もっと言うと、これは僕の所感ですが、多様なバックグラウンド、多様な受け取り方の人がいた方が、むしろその場の学びの総量は大きくなるのでは無いかと思いました(コレはあとで)

現場ではどうしたのか...

なにぶん作業している途中で気づいたので、超アドホックな対策であることを先に言い訳しておきます。

一応僕なりの工夫としては「これ難しいです」「要約ってこんなに難しいんですね」「これ、完璧なのは無理ですよね..全体読んでいる訳では無いし(僕は読んでるけど)」「完璧じゃなくてもいい!ていう場の心理的安全性が大事ですよねコレ...」「時間足りないかもしれないです」のような発言を時折することで「そもそも難しいことをやっていること」「失敗が許容される場であること」を発信してみたりしました。効いたかどうかは分かりませんが、最後まで参加者全員で要約/発表./対話と、勧められたので良かったと思っています。

その他感想/気づき/学び

チームビルディングに使えそう

松浦春選さん によるレポートでも触れられている通り、これはチームビルディングに効果がありそうです。 お互いについて知り、価値観を共有するのに有用なツールだと感じました。週一でチームで時間をとって、取り入れようとしている考え方、導入を検討しているプラクティスなどの書籍を対象に実施して見ると良いかもしれません。

ある事柄について、担当個人がまとめたものをベースにディスカッションするのも良いですが、ABDのように一冊の本を分担し、そのなかで皆の関心の高い事柄について対話をすることで、皆で作り上げた解釈/価値観を共有することができるような気がしています。

多様なバックグラウンドのある人でやると面白そう

今回は参加者全員が「IT系」という属性を共有しつつ、「学生」「社会人」という属性に大きく別れていました。対話における発言の色にも「学生 vs 社会人」の差が出ていて、やはり同じものを見ても背景によって捉え方は違うのだと改めて認識しました。加えて、自分が発言するときにも「この例え方だと SE経験者にしか伝わらないからどう伝えようか」というトレーニングにもなったかと思います。受け手に合わせた情報発信の心ですね。

というわけで、デザイナーさんの仕事の仕方について書かれた本をビジネス屋さんとエンジニアとデザイナーさんで読んでみるとか、アジャイル開発系のプラクティスをユーザ企業さんとエンジニアで読んでみるとか、特定の業務知識の本を同じくユーザ企業さんとエンジニアチームで読んでみるとか。やってみると面白そうですね。

あ〜、それぞれの立場について主張したい本を一冊出して、それについてABDをやる、、ってすると本当に相互理解できそう。なるほどチームビルディングに使えそう(前項につながる)。

f:id:rocky_manobi:20180727141107p:plain
皆さん認知の歪みに興味があった模様

(というか学生さんでエンジニアリング組織論への招待を読んで何らかの感想がもてるなんてすごいな〜最近の学生さん本当に頭いいな〜)

個人のトレーニングとしてもやはり良い

本を読んで、要点を抽出して、視覚的に表現して、発表して、対話する、、とまぁ普段なかなかやらないというか、数が稼ぎにくい作業だと思いますので、単純にその手のことに取り組めるのは良いです。特に「発表」のトレーニングとして、とても有効なのではと感じました。

発表が上手くなるには「発表することと、その時のフィードバックを得ること」の積み重ねが大事だと思っています。上達のためになるべく数をこなしたい一方で、毎回「発表すべきネタの採掘」という作業が発生し、これが中々時間をくいます。そう言う意味で、ABDに参加すると嫌が応にも発表するネタが降ってくるので、それは良いなと。また、必然的に似たようなトピックに対して皆が発表するので、「上手な人の発表を参考にする」という作業がやり易いというのも良いです。

あとは、普通に読むよりも「深く読める」という効能も確実にあります。僕は以前に「エンジニアリング組織論への招待」を読んだことがありましたが、作業中には「こんなこと書いてあったっけ?」と思うことがなんども。やはり「要約して伝える」を前提にして読むときとは、読む深さが違うのだなと改めて感じました。

ABD x エンジニアリング組織論への招待 をやったきっかけ

A. エンジニアリング組織論への招待めっちゃいい本だよ!みんな読んだ方が良いよ! と言っていたら「じゃあ Active Book Dialogueやろうよ」と言われたから

ぼくは「エンジニアリング組織論への招待」とう本が大好きです。

これはもう良書中の良書というか、凄い本です。どれくらいすごいかというと、読みながら「そうそうそうそう!!!」と叫ばずにはいられないくらいです。チームや組織で仕事をしている人皆が感じ、直面しているであろう課題感(もちろん解決策も)を見事に言語化していて、普段感じていたモヤモヤが一気に晴れるというか、そんな気分にさせられます。

絶対みんな読んだ方がよい。チームを作る人も、チームに所属する人も、人類みんな読んだ方が良い。そうすればみんな少しだけでも優しくなれるというか、ちょっと幸せになるというか、不幸が減る。

まぁ、めちゃくちゃ雑ですがとにかくそんな本です。

と、そんなことをNextremer主催の勉強会@高知 の場で話していたら、その場にも参加頂いていた松浦さんに「Active Book Dialogueやりましょうよ」とお声かけ頂き、開催することになった次第です。

追記: あまりにも雑すぎるので書評へのリンクを... (おんなじ感想感覚だと思っています)

blog.shibayu36.org

note.mu

shufo.github.io

最後に

企画/準備/ファシリテーションと、イベントのほぼ全てを取りまとめて頂いた松浦さん、ABD経験者としてアドバイス頂いた杉尾さん、参加頂いた参加者のみなさま、僕の「やりたいっす!」に協力頂いたNextremerスタッフのみなさんにこの場を借りてお礼を申し上げます。ありがとうございました!

最後の最後に

Nextremerではエンジニアを募集しています:) ぜひ!!

www.wantedly.com

とある課題について

とある塾の課題です。急遽参加できなくなってしまったため、課題をWebに上げたものです。

ふと生活していて気になったこと〜からの〜こういうことだったのか!という気づきについて纏めるものです。

100均のフック(?)

知人の自宅の壁に100均で買えそうなフックが貼り付けてありました。 3つのうち1つが90度傾けて張ってあったのでなんだろうと効いてみたところ、、、

f:id:rocky_manobi:20171115170931p:plain

こんなふうにタブレットを設置して、ベビーモニタを表示しているとのこと。 (実は写真は撮り忘れていたためウチのものです。早速導入しました。タブレットの画面...90度傾いてますね)

f:id:rocky_manobi:20171115170912p:plain

イオンスタイル豊田

母校に講演に行った際に立ち寄った愛知県のイオン豊田で子供のオムツ替えをしていたところ、普段は大暴れするのにおとなしく上を向いて止まっていてくれました。 渡したおもちゃに集中しているわけでもなく、おかしいなと思って上をみたら、天井にアニメが投影されていました。

f:id:rocky_manobi:20171115094513p:plain

洗濯バサミ

この手の一般的な製品は、洗濯ばさみの中心の金属部分に紐(といっていいのか)がついていることが多い気がしますが、わざわざ接合部を2箇所にしてあります。 下方向の力が加わると洗濯ばさみが開く方向にも力が加わるようになっていて「片手で引っ張って取る」というのがやりやすいようになっているのでは、と考えました。

f:id:rocky_manobi:20171115134621p:plain

Macの充電器

恥ずかしながら、この羽をこう使えるとは、他の人が使っているのを見るまで気づきませんでした。

f:id:rocky_manobi:20171115170455p:plain

f:id:rocky_manobi:20171115170407p:plain

余ったコードを巻き付ける(今更??って言われそうですが)

f:id:rocky_manobi:20171115170422p:plain

以上となります m( _ _ )m

Herokuで複数Dynoにするとsocket.ioが繋がらなくなる問題への対処

最近HerokuでSocket.io依存のサービスを運用する機会があったので手順だけメモ。 (日本語記事あまり見つからないので、もしかしたら socket.io-redisがこの問題をも解決してくれているのかな…)

症状

Heroku上でクラスタリングしたsocket.io(node.js)との接続が確立できない。 エラーメッセージは下記2種類。ポーリングで接続成功した後に、websocketにupgradeしようとして失敗しているような感じ。最初に接続確立したときと違うサーバにつなぎに行こうとして怒られてしまっているみたい。

Failed to load resource: the server responded with a status of 400 (Bad Request)
WebSocket connection to ......... failed: WebSocket is closed before the connection is established.

手順

  1. heroku側でhttp-session-affinity をONにする
  2. socket.ioのfallback optionをwebsocket優先にする

現時点ではChromeFirefoxであれば1の対処だけでOK。 Mac/iOS Safariやnode.jsのsocket.io-clientなどの場合は2の対処までしてやる必要があります。

HerokuのHttp Session AffinityをONにする

詳しくは コチラ

heroku features:enable http-session-affinity

client側のsocket.ioのfallback optionをwebsocket優先にする

デフォルトではpolllingwebsocket の順番で接続をしていくsocket.ioですが、クラスタリングされたサーバに接続する場合は順番を指定して、websocketから繋ぐようにする。

const options = { 
  transports: ['websocket', 'polling' ]
};

const socket = io.connect( "URL" ,options);

付録

socket系 x クラスタリングで発生する問題としては、セッションが各nodeで共有されないことくらいで、broadcastのときに困るくらいだろうとタカをくくっていました。Broadcastの問題に関しては別のソリューションで解決していたので、今回はたまたまsocket.io-redisを使っていませんでした。もしかしたらこの問題自体、socket.io-redisが一緒に解決しちゃってくれる可能性もあります。

ちなみにsocket.io、以前はwebsocketから順番にfallbackしていっていたのを、どこかのバージョンで逆にするようにしています。そのほうがwebsocket非対応のオールドブラウザでの接続確立までの時間が短くなるという理由らしいです。

SI(お堅い/石器時代のシステム開発)業界から抜け出してイケてる開発がしたいと思ってやったこと

友人から相談を受けたのでせっかくなので公開する。

SIというか、「受託で硬いシステムを作っている会社に属していて、あまり1からのシステム構築とかやったことがない」という状態から、イケてる(と思われる)会社や開発現場に移るためにどんな準備をしたか、ということを書いていく。ちなみに現在はNextremerにてエンジニアをしつつ、高知AIラボのリーダーとして、イケてるエンジニアリング環境を作るため、色々と試行錯誤をしている。スーパーエンジニアではないけど、今は満足したエンジニアリング生活をしているので、誰かの参考になると良いな。

注意

  • 2012年付近での経験をもとに書いています。時代の違いによる周辺環境の変化についてフォローできているかどうかは保証しかねます。
  • SIがイケていないと言っているのではありません。僕のいた現場が(開発現場としては)イケていないだけです。
  • 何をもってイケているのか。よりお金が動いているのは当然SIじゃないか!という議論をここでするつもりはありません。割と僕、その考え方に共感しますが、相談内容にそって、エンジニア的視点から書きました。

はじめに

まずは前提条件から。抜け出さねば!!と思ったきっかけは以下のとおり。

  • 豊田高専情報工学卒 + 1年間米国留学 ののち、2009年にシステム開発会社(前々職)に入社(21歳)
  • 1年目,2年目と金融関連のプロジェクトに多数参画し、それなりにできるSE(自称)として勤務
  • 2011年暮れ、会社をやめてWeb系ベンチャーに行った同期組と1年ぶりに再開し、自分の技術力の無さ、及び周辺環境のヤバさに気づく
  • 2012年1月、レベルアップして環境を変えるための活動を開始

最初はなんとなく「バリバリのプログラマ」を目指してスタートしたのだけど、途中からは「ビジネスレイヤと技術レイヤの中間でいい顔をできるポジショニング」に方向転換している。当時考えていたことと、今思えばということとが錯綜しているので、読みづらくなること必至。

主にやったことは以下の3つ

  • アンテナとポートフォリオの整備
  • 技術力の向上(開発/設計/チームビルディング/スタートアップ)
  • プレゼンスとコネクションの整備

上の二つは2012年(当時24歳)に自分でやばいと思ってやったこと。エンジニア/ITビジネス屋としての基礎力をつけるためにやった。三つめは、2013年に出会った師匠的な人と一緒に仕事して感じてやった。最終的には「ビジネスと技術のハイブリッド」という方向性を目指すことにはなったけど、二つ目の技術力向上でやったことの蓄積がなければ、薄っぺらい奴になっていたと思うので今の所全部大事だと思っている。

アンテナとポートフォリオの整備

アンテナ : 情報収集能力

とりあえず、業界でイケてそうな奴らは何を見ていて、何を考えているのかを知りたかったので、著名なエンジニア(のちにビジネス屋)をTwitterでフォローした。「XX使って見た」とか「このイベント面白そう」とか「良記事!!」の情報を垂れ流してくれるので、とりあえず情報INPUTはこれだけでもいいくらい。最初は100人くらい。ココみたいなページが割とたくさんあるので参考にした。 特定のメディアとかをフォローする手ももちろんあるのだけど、自分で選ぶよりも、できる人たちがシェアしてるやつを掠め取った方が最初は効率が良い。その中でよく目にするようなメディアをピックアップしてフォローするのがオススメ。

ポートフォリオ : アウトプットする場所

即転職を意識、というよりも、必要あらばいつでも転職できるようにしておくため、自分が何者かを見てもらえる場所が必要だと考えた。内容はともかく、自ら情報発信をしているというマインドセットは加点になるはずだと考え、下記を始めた。

  • ブログ運用をはじめた
  • Github上での活動を開始した

ブログ運用

当時、自分はサーバ運用を全くしたこともなかったので、さくらVPSを契約してワードプレスを入れて、ついでに自分のプロジェクト管理用にRedmineを入れて運用してみた。今では不要だけど、コードも管理したかったのでSVNとGitの環境整備もしてみた。これらの作業を通じて、ポートやらサービスやらパッケージやらビルドやらSSHやらその辺りをなんとなく理解した。のちの技術書行脚に向けてはかなり役にたったと思っている。とはいえ、その辺りの技術習得の目的がなければ、はてなとかQiita等々、既にあるものに乗れば良いと。

ブログの内容は、勉強のときにハマったことだったり、業務で「ORA-XXXXX」的なエラーにぶち当たってトラブルシュートしたり、「xxxxxの調べ方調べて見て」というオーダーに対して調べたことなどのまとめが中心。それなりにアクセスがつくとやる気が出る。(残念ながらさくらVPSのお金払い忘れて解約してしまい、もうブログは残っていない)。

ただし、技術ブログは自分の底を晒すことにもなるので、ある程度のレベルに達するまでは見習い感が結構でる。その時はわからないのだけど、結構出る。事実、半年前に当時のエントリを読んだ時には悶絶というか、単純に消したくなった(全部消えたのはワザとではない)。書くことを繰り返すという訓練はとても良いことなのだけど、転職においては短期的な成果は得にくい。短期での転職を考えている場合は、とりあえず書き始めて、今回はそれをアピールせずにゆっくり準備をするなどしても良いと思う(転職先で転職したいと思うことだってあるでしょう?)。

ちなみに こんなバカなこと もしてみたことがある。

Github上での活動

優先度と書く順番が逆になってしまうけど、Github上での活動の方が今は大事かも。

まずは勉強の過程で作ったものなどはじゃんじゃんリポジトリにあげて公開してしまうのが良い。PCのdotfiles(設定ファイル)のgit管理とかをやってみるのも良い。現場では何らかの形でほぼ100%使うことになるので、使い方、UIなどに慣れておくという意味でも、きちんと使って見ることをお勧め。

技術力向上(開発/設計/チームビルディング/スタートアップ)

書籍を読んだ

今は動画や質問系サービスも盛り上がっているので前ほどの重要性はないとの見方が強いけども、なんだかんだで基礎力と語れる厚みを身につけるために本は読んでおいた方が良いと思っている。本当は読んだ書籍を列挙していきたいのだけれど、今出先なので方向性だけ列挙する。

注意 : 本当に時代の影響を強く受けるので注意。それから、相談してくれた人のことを考えながら書いているのでその辺りのバイアスはあるかな。デベロッパーでもSE的な感じでも、この辺りを知識として知っておいた方が良さそうだな〜と思うものをピックアップしたつもり

  • 言語/設計/開発
    • マーティン先生のリファクタリングに始まり、名著と呼ばれるものを中心に読み進める
    • 言語としては当時の唯一の使用言語Javaと、個人的に暑いと思っていたRubyを中心に勉強
    • 今だとSI以外に行くとすれば言語はPython,Ruby,node.js,php,JVM系となる気がする。
    • 関数型に手を出しても良いけどまずは必須ではないと思う。
    • 結城先生のJavaデザインパターン本を写経したのは記憶にある懐かしい(一応知識としては必要だと思っている)
  • ビジネス / マネジメント

それから、SIからの転職という意味では「チーム開発実践入門」は読んでみると良いかも。少し古いけど、このレベルでちゃんとやれてる開発現場はまだまだないし、SI現場だとなかなか想像つかないと思うので理想イメージ掴むためにも読んで見た方が良いかと。

一次情報へアクセスする癖をつけた

何か新しいツールや言語を試そうとする時、最初の方は日本語ドキュメントに頼ることになると思うけど、慣れてきたらインストールや環境構築は公式サイトに行って Get Started の項を参考に行うことをオススメする。一次情報にアクセスできるということは圧倒的なアドバンテージ、というか一次情報にアクセスできないのは圧倒的なディスアドバンテージになるので、英語文書へのアレルギーをなくしておくのはビジネス屋としての生存戦略上必須だと思っている。

プレゼンスとコネクションの整備

かっこよいサブタイトルだけど、要するにIT勉強会にでました、という話。目的は社外にエンジニアの仲間を作りたかったから。深い情報はやっぱりF2Fでの雑談に限るので。(だから運営を手伝ったりとかも積極的にやった) ジャンルは特定の技術だったり、アジャイルなんかの開発プロセスだったり、転職系、ワークスタイル系だったり、とにかく結構参加した。

おすすめとしては、無理目でもなるべく頑張って発表者になること。自分が発表しない勉強会の後の懇親会は辛い。自分から話しかけないといけないので緊張する。一方で発表者であると自分が何者かを全員にあらかじめ効かせた後なので割と色々な人が話しかけてくれる。

というわけで、こんな感じです。

  • コミュ力に自信がある人 : IT勉強会に行く
  • コミュ力に自信がない人 : IT勉強会で発表する

(コミュ力だけではなく、勉強会に参加する人間で一番学びを得ているのは発表者でもあるのでここはおすすめ)

付録 : 移ってから思ったこと

準備としてやったことはとりあえず生きているとおもう。実際に移ってみて大事だと思ったのは「カルチャーギャップを埋める」ということ。 仕事が降ってくる、というよりも社内で仕事をとりにいく、という考え方でないと振り回されることが多くて苦しいと思う。その代わり、割と自分で正しいと思うことができるし、何より周辺環境の変化に対応する力がついた。自分としては移ってよかったと思っている。(業態の違いと会社の規模が一緒に語られている感はあるけど、likely的な感じであっていると思う )

いま書きながら思ったことだけど、上記の3つの準備は「能動的に動く」という習慣をつけるのにも役に立ったのかなと思った。「自分のポートフォリオを作りたい」という意識でいろんなことを調べて色々なものを作って色々な人と話して色々な人と色々なものを作って、、大変だったけど「自分で何をするか決める」「自分でどうするか決める」という経験を積み重ねるのはすごく大事だと思う。周りを見て見ても、そういう活動をしている人の方が、環境変化にうまく適応できている気がする。

それから、 SIer時代の経験は決して無駄ではない ということ。成果物や仕事のやりかたは大きく違うけど、知識として知っておいた方が良いことは本当に沢山ある。「堅くやるならこうだけど、この案件の場合はこの方がいいな」的な判断は、そもそも「堅いやり方」を知らないとできない。なんだかんだでどんな開発現場にも社内外にお客さんがいる。一般的なやり方を知らないことと、知っていて違う選択をすることは大きく違う。SIer時代の経験は確実に生きていると今でも思う(というか最近"特に"そう思う)。

エンジニアとビジネス、Web系とSI系、時と場合によっていろんな帽子を組み合わせて戦える人材は、活躍の範囲がとても広くて重宝される。

とはいえ反対に、過去やってきたやり方に執着しすぎると、ギャップに対応できずに辛い。大事なのは、今いる場所と過去に居た場所と自分の居たい場所の、環境の違いをしっかりと認識して、アクションを選ぶことなのではないかと書きながら思った。このあたりは改めてちゃんと整理してエントリにした方が良いな。

おわりに

上記のとおり準備をしつつ、働きつつとやっていたら、機会に恵まれてフラフラここまで、という感じ。道中で大きな借りを作ってしまった方々も居て、現状その借りを返すために今いるところでまずはビッグになろうと言うのが現在のステータス。これから転職を考えている方に少しでも参考になればと思いますです。

とりあえず、早足だけどこんな感じ。Done is better than perfect なのでここで終わりにしよう。 ちゃんと推敲した記事はまたリライトします。

宣伝

Nextremerではエンジニアを募集しています。 スタートアップのカオス感はありますが、その中でちょっとでもイケてる開発現場になるよう、色々考えてやっています。

www.wantedly.com