imaizumeの個人メモ

コードとか旅とか飯とか

ベンチャーで総合職目指す人が自分の実力を把握したりアップできるかもしれない場をエンジニア視点でピックアップした

エンジニアの就活には自分の実力を知る機会がたくさんある

僕は来年からとあるITベンチャー企業でエンジニアになります。 ベンチャー企業のエンジニアを志望する場合、就活対策として自分の今の実力や会社が求めるスキルレベルの把握が重要です。 なぜなら多くのベンチャー企業は一般の大手企業とくらべて現在の実力を重視するところが多いから。 実力とはエンジニアでいえばプログラミングやマネジメントのスキル、経験や成果物のこと。

そして自分の実力は他人と比較して初めて立ち位置がわかるものです。 スポーツで言えば毎日一人で練習していても、試合に出なければ全体の中での自分のレベルがわからないのと同じ。 立ち位置が分からないと、志望する職種でやっていけるかという漠然とした不安に襲われるだけではなく、改善のための具体的な行動につなげることが難しいため、周囲から「意欲はあるけれど行動ができない、あるいは間違った努力をしてしまう人」という認識を持たれてしまうのです。 また友達がスゴそうなところから内定をもらったり、何かスゴそうなこと(インターンとか学生団体とか)をしたりするのを見て、自分がダメに思えてならなくなるときがあったりします。 そのときにも、他人とのレベル差を客観的に捉えることで、必要なフォローアップと無駄な思い込みを発見することにつなげられると思うのです。

エンジニア志望だと、自分の実力を測れる機会がたくさんあって、僕も学部生のうちからそういう活動に参加していました。 例えば僕が経験したものとしては

  • インターンシップ (ある程度の技術力が必要で、それでも社会人のエンジニアさんと働くことで実力不足を実感できる)
  • アルバイトや受託製作 (プログラマのアルバイトをやっている人が多い印象、あと自分は飲食店のHPを受託したりしました)
  • 起業やプロジェクト (友達で起業したり、起業までは行かなくても何か面白い企画をやろうとしている人がいてそこに加わるとか)
  • 自作アプリやWebサイトの公開 (たいがいフリーで作って全世界に公開できるのでかなり自己アピールに有利)
  • ハッカソン (数時間から数日で一気にアプリやサービスを製作し発表するというイベント、アイデア・技術力・マネジメント力の全てが試される)
  • プログラミングコンテスト (ハッカソンよりも技術力勝負の大会)
  • オンラインのプログラミングスキルチェックサービス (プログラミングの問題を解くことでレベルを客観的に評価してくれるサービスが多くある)
  • LT会 (いわゆるプレゼント大会、ここでの発表資料も大会後には一般公開されることが多い)
  • ブログやQiitaなどでの情報発信 (自分が作ったものや技術解説をしてドヤる文化)

こういう場では、少なからず自分と近い年の人が多く参加していて、必ず自分よりもレベルが上の人に出会います。 そのため自分の実力はどの程度のレベルか、彼らに追いつくには何をすべきかを知る良い機会になるのです。 また何かしらの成果物は出来るものなので『成果物のクオリティ = 今の自分の実力』というわかりやすい構造があるのも事実です。

よって僕はベンチャーを志望する人へは、変な就活セミナーよりも自分の力を試す機会を就活イベントとしてオススメしています。

総合職志望だと実力を把握できない!?

ところが先日後輩と話をしていてベンチャーの総合職を志望している人が自分の実力を知るにはどうすればよいのでしょう??」と聞かれて、その場ではうまい返答が思いつかず悩んでしまいました。

いろいろ考えてみましたが、エンジニアと違って総合職には「技術力や成果物 = 実力」というような構造がありませんし、「この会社に入るにはこれくらいの力が必要」という感覚をはっきりつかむのも難しいだろうなと思いました。

その後輩は学部の早いうちから有名企業のインターンシップに行きたいようで、どうすれば受かるのかを知りたがっていたようでした。 僕はエンジニアには前述のようなイベントをオススメしているのですが、総合職の場合はどうなのかということについて全く考えたこともありませんでした。

そこで今回は、ベンチャー企業でエンジニア就活をした視点から、ベンチャーの総合職志望者にもオススメできそうな、自分の実力を把握したりアップできそうな場について紹介してみようと思います。

1. ハッカソン

[blogcard url='https://note.mu/ideagram/n/nb81049a87d15']

ハッカソンは、数時間から数十時間をかけてチームでアイデアを出し合って一気にアプリを作りリリースするところまで持っていくエクストリームなイベント。 一見すると完全にエンジニア向きなイベントのようにも見えますが、実はそれ以上に非エンジニアの力が必要となる場面が多々あるのです。

例えばチームの進捗管理。 エンジニアはプログラムを書くことに必死で自分以外のことを気にしている余裕がありません。 それ以上に (主観ではありますが) エンジニアはチームをまとめる役に回りたがらない人が多く、個人プレイを好む傾向があります。 このため全体の進捗管理、課題やアイデアの整理といった部分にはぜひとも非エンジニアの方の力をお借りしたい所です。

また最終発表のプレゼン作成はプレゼンのスキルアップに直結すること間違い無し! 自分たちで作ったサービスの利点や魅力を伝えることで、実際の営業活動とほぼ同じ経験ができるうえ、他チームを見てプレゼンスキルを比較・改善する良いきっかけになるでしょう。 もちろんプレゼンには審査員からの講評もあるので、サービスのことをしっかり理解して質問に答えるという訓練にもなると思います。 僕が参加したハッカソンでも、最終プレゼン資料を作ってくれたのは非エンジニアのメンバーでした。 つい技術の話ばかりしてしまう僕らと違い、非エンジニアの方がずっと上手くユーザー視点に立ってサービスの魅力を伝えられているなぁと思っていました。

別のメリットとして、エンジニアと一緒に作業をすることで多少なりとも技術に対する理解が深まるということもあげられます。例えば

  • 「この機能を使うにはログインが必要か」
  • 「購入が終わったらどのページに遷移すべきか」
  • 「このメニューはスマホでどう表示されるべきか」

といったようなことをエンジニアと話すことで、技術的な単語や知識を知りエンジニアとの意思疎通の難しさを経験できるのです。 (彼らは本当に難しい生き物なのです...) 多くのベンチャー企業では、サービスを作っているエンジニアとも話しをして仕様を把握したり問題点を確認したりする機会が必ずあります。 彼らとの話し方を知っていることは企業側から見ても、とても魅力的なポイントであることは間違いないでしょう。

2. ビジコン / Starup Weekend

ビジコンとは「ビジネスプランコンテスト」のことで、ハッカソンがアプリ製作を伴うのに対してビジコンは事業のアイデアや収益化の方針といった事業計画をまとめてプレゼンするイベントになります。 サービスのアイデアが事業として収益が成立するかということを、企業のCEOや投資家の人たちから指摘してもらいながら考えて投資を受けるためにプレゼンするという実践的な内容のイベントです。 ただし実際のサービスを作るわけではなく、あくまで『具体的なアイデア』止まりになるものなので、「ビジコンは評価されにくい」という評価をしている友人も居ます。 とはいえ経験としては充分に参加する価値はあると思いますけどね。

また僕自身ビジコンには参加したことがないのですが、似たようなものでStartup Weekendというイベントに出たことがあります。 こちらもスタートアップ企業を2-3日で立ち上げてビジネスモデル (計画は要らない) を作り、場合によってはサービスのベータ版まで作って披露するというものです。 期間中は部屋の中ではなく実際に街に出て自分たちが考えたサービスのデモンストレーションやアンケート調査を行い、お客さんとなり得る街の人達からフィードバックをもらうことに重点が置かれています。 より起業や小さな会社での事業立ち上げに興味がある方にはこちらの方がさらに実践的でオススメかもしれません。 またエンジニアやデザイナーと一緒に作業することになるので、その意味でも僕自身はこちらを推しています。

[blogcard url='http://tokyo.startupweekend.org/']

3. 初心者向けプログラミング勉強会 / LT会

ベンチャー企業だと、自社サービスの理解のために総合職であってもプログラミングの勉強を課しているところも多いみたいですね。 僕が知っている範囲だと、未経験からエンジニアになられた方でリブセンスの渡邉さんという方の記事がネットだと有名だと思います。 今見たらリブセンスの新卒採用ページに未経験者エンジニア採用のページまでできていました...

[blogcard url='http://newbie-engineer.livesense.co.jp/']

なので面接とかでもある程度はそういう技術的な話をされるのかもしれません。

「プログラミングの勉強会に参加するのは敷居が高そうだなぁ...」と思う方もご安心を! 最近は初心者向けのプログラミング勉強会がたくさん開かれているのでぜひ行ってみましょう。 意外にも「文系で総合職だけどプログラミングもちょっと始めてみました♪」みたいない人がたくさん来ていて刺激になると思います。 当然同じ初心者でも参加者間でレベル差はあるので、お互いにどういう勉強をしているかとかを聞いてみると、システムに関する技術・知識レベルをより客観的に把握できると思います。 もっとガッツリやってみたいなら、夏休みとかにTech Campに参加するのもアリかもしれないです。 これはブートキャンプ式でプログラミング未経験者がプログラミングを勉強しエンジニアになるための基礎を身につける教室で、最近かなり人気らしい。 てかだんだん話がエンジニア寄りになっている気がするけれどまぁいいか...

[blogcard url='https://tech-camp.in/']

LT会は"Lightning Talk"の略で、いわば短いプレゼンの発表大会のこと。 これもエンジニアの文化の1つで、テーマに合わせてプログラミングでの成果物をドヤしたりウケを狙ってネタを仕込んできたりするのですが、こちらも初心者向けのLT会が増えているように思います。 学び初めてすぐ発表している人だと「1ヶ月でここまで勉強した」とか「数週間でこんなもの作ってみた」というようなテーマのLTが多いです。 残念ながらベンチャーに限って言えば「総合職だからプログラミングとかよくわからない」という時代ではなくなっていますので、自分のプログラミングに対する理解を深めるには、自習だけではなくこうしたイベントに出て、中途半端でも発表してみることが実力把握につながるんじゃないかなぁと思ったりしました。

学生や初心者限定の勉強会やLT会はdotsとかで探すとたくさんヒットします。

[blogcard url='https://eventdots.jp/']

4. ブログでの発信

https://twitter.com/kensuu/status/795424198990524416

ブログでの発信も実力把握やアップには有効でしょう。 自分の考えを文にまとめて伝える技術というのは、どんな仕事でも必須のスキルですし、レポートや卒論作成にも少なからず役立ちます。

逆に言えば最初は文章を書けない自分に絶望しますが、それこそが実力把握なのです。 また訪問者の統計を見たりはてブやコメントをもらうことは、自分の文章の他人からの評価そのもの。 好きなことで良いのでブログを通じてアウトプットし、他のブログを読んで勉強しましょう。 もし動画の方が得意ならYouTubeでチャンネルを開設するのもアリだと思います (自分の知り合いにもYouTubeで情報発信している人はいます)

ブログは発信だけではなく記録の側面も持っています。 自分の活動を発信するのはもちろんのこと、自分で見返して「あぁ、オレこんだけ成長したんだな」と振り返ることも大変有用です。 そういう実感が「やれば出来る!」という成功体験をもたらし、新たなチャレンジへと自分を進めることにつながるでしょう。

「でも書くことがないし...」と悩む人もいるかもしれませんが、始めはこんなところで良いのではないでしょうか。

  • 読書記録を感想、意見、考察付きで書いていく (ビジネス書が定番だけどなんでも良いと思う)
  • 参加したイベントの忘備録 (後述の勉強会だったりゼミだったり)
  • 流行のネタやトピックについて (Pokemon Goとかピコ太郎とかなんでも)
  • 不満とか問題提起とか、ただしTwitterの裏垢的なことはしない、あくまで論理的な話を展開する

ただブログは続けるのが難しいというのも事実。 そのために目標を決めたり、アフィリエイトでのお小遣い稼ぎを狙ったり、書き方を工夫したり (なるべく短くするとか中途半端でも出すとか) することも必要かも。 かく言う自分もこうしてブログをやっていますが、ちゃんと目標を決めてやっているわけではないのでダラダラしがちです (汗)

イケハヤさんの「武器としての書く技術」はブロク初心者向けに続けるためのコツやブログでの稼ぎ方がまとめられていて、読み応えもあるのでオススメの一冊です。 ただし実行に移すのが難しいという難点が...というのは僕側の問題ですね、すみません師匠。

武器としての書く技術 (中経出版)
KADOKAWA / 中経出版 (2013-06-27) 売り上げランキング: 5,075

終わりに

という感じで挙げてみたけれど、やっぱり実力を把握できる具体的な場所っていうのはあまり思いつきませんでした。 求められているものが技術的な部分ではないですし、成果物としてパッと目に見えるものが作りづらいからですかね... 本当にベンチャーで総合職の人はどうやって実力つけているだろうかと気になって仕方ありません。 また他の方に聞く機会があったら続きの記事を書くかもしれません。

社会人でやり続けるとマズいエンジニアの勉強方法5選

僕は専攻が情報系ということもあり、周りにはIT業界でシステムエンジニア(SE)やプログラマを志望する学生さんがたくさんいて、プログラミングなどでの相談を受けたりすることがよくあります。 するとその中で「この勉強の仕方を社会人で続けたらまずいな」と思う人がそこそこいます。

僕が見た範囲だと、多くの学生さんは普段授業で習った範囲でプログラミングをしていて、卒研や修論をしていても新しい言語やライブラリの使い方などの勉強は正直そこまで力を入れているという印象がありません。 僕はこういう『今の自分にできる範囲』で課題を片付けようとしてしまう姿勢に、いつも疑問を感じてしまいます。

課題提出期限までの時間がないとか、(モダンな)プログラミングに詳しい人がいないとか、社会人経験がいないというような事情があるのもわかりますし、そういうことは社会人になってから身につければ良いという考え方もあるかもしれません。

しかしSEにとって、勉強とは習慣であり、習慣は身につけるのにも直すのには時間や労力がかかるものです。時間のある入社前に「SEとしての正しい勉強方法」を知っておくと、入社後の成長の下地になると思います。

そこで今回は僕が感じた、社会人でやり続けるとマズいエンジニアの勉強方法を5つ紹介します。

1. プログラムやエラー文をしっかり読まない

プログラムやエラー文をしっかり読まない

まずはしっかり自分が書いたプログラムやエラー文を読む習慣を付けましょう。

経験ある人も多いかと思いますが、自分も研究室で「○○っていうエラーが出てるんですけどどうしたらよいですか???」みたいな質問を受けます。 そこでたいてい言うことは次の通り。

  • まずエラー文はちゃんと読んだ?
  • エラーの発生前はどんな処理をしている?
  • エラーの位置は何行目の何文字目?
  • その関数は何を入力に何を返却するもの?
  • 公式のリファレンスにはなんと書いてあった?

すると「よくわかっていないけど、とりあえずコピペで動かしてみた」というケースがやたら多いのですが、これは絶対に直した方がいいです。 今自分が書いたコードは何をしているのか、どんなエラーがどうして発生したのかをよく読む癖をつけないと、いつまでもパターンを覚えられず、関連するプログラムへの知識が一向に深まりません。

関連する話としてデバッグの方法を知らないという人も多いですね。 例えばステップイン実行をするだけで、変数の値がどこで予期せぬ値に変わるのかが分かりますが、見ているとそもそもやり方を知らないという人が多いので覚えておきましょう。

2. 知らない言葉を調べない

知らない言葉を調べない

Unixには「知らないコマンドは絶対叩かない」という格言(?)があります。 これは、逆に言えば意味を知らなければ何もできないということです。

プログラミングをしていると、知らない言葉に頻繁に出会いますが、そういう時に放置してしまう姿勢は考え物です。 単に自分が困るだけではなく、クライアントやチームメンバーと話をするときもわかったフリして話を進めた結果、タスクの実行が困難になったり期待はずれのことをしてしまい全体に迷惑がかかるからです。

ここで注意してほしいのは、必ずしも100%の理解をする必要はないということ。

例えば「HTMLとは何か」の認識が完璧にできていなくても

  1. HTMLというよくわらないもの
  2. HTMLというホームページを作るための書き方でカッコで何かわからない文字を尖りカッコで囲った難解な文章

では、その後にできることがだいぶ違いますよね。 「よくわからない」では相手もどこから話を始めていいか分からないでしょう。 でも、ある程度わかっていれば、ホームページの話をしていることは共通認識として持てますし、次はHTMLタグの種類を説明すれば良いというように、理解が足りない部分が具体的になります。

言葉の意味を多少でも知っておくだけで、再び勉強するときもとっつきやすくなるし、「ある程度知っているなら」という条件付きでプロジェクトに参加できる可能性も増えます。

3. 言われたことを言われた範囲でしかやらない

言われたことを言われた範囲でしかやらない

仕事でもそうですが、言われたことだけをやり続けるのもご法度。

例えばぼくの大学では1年生の授業でプログラミングを教える際、先生がエディタとしてTerapadというエディタを紹介します。 Terapadは汎用性があり軽量なのですが、補完やオートインデントなどの機能がないためある程度プログラミングをしていると不便に感じてきます。

しかし、卒研の段階でも複雑なプログラムやLaTeXで書く論文をTerapadで書き続けている人が大勢いるのを見てとてもびっくりしています。 「不便じゃないの?? もっと便利なエディタがいっぱいあるよ」と教えると「え、そんなものあったの??」というような顔をされます。 こうなってしまうのはTerapadしかない」「教えられたものだけしか使ってはいけない」という頭、言い換えれば「他にどんなエディタがあるのだろう」と発想できない頭になってしまっているからにほかなりません。

そうなってしまっては、学習の幅も機会も相当狭まってしまいます。 ぜひ言われたことの『上下左右』を考えましょう。

例えば最初にHTMLの勉強をしたら

  • なぜHTMLは表示されるのだろう
  • 同じことをまとめておけないだろうか
  • クリックしたら動くようにするにはどうするのだろう
  • サーバーってなんだろう
  • もっと楽にHTMLを書けないだろうか

などの思考を持つと学習することの幅がグッと広がります。

4. 英語を避ける

英語を避ける

これもあまりに多すぎます、英語しかないから諦めるという人。 海外の公式ドキュメントやStackOverFlowに当たっただけで、ブラウザのバツボタンを押しちゃう人がかなりいます。

これはとってももったいないこと! ほとんどの記事は高校レベルの英語力で充分に読めるので、少し時間をかけて読めば日本語のソースを探し続けるよりもよっぽど効率が上がります。 簡単な内容でも、なぜか日本語には答えがなく、逆に英語だとすぐに答えが見つかることも多いです。

かく言う自分も、実は以前インターンしていた時にあるフレームワークの使い方を日本語で調べていました。 その時は日本語の方が早く見つかるし理解も正確にできると思ってたのですが、先輩から「英語じゃないと一次情報(=誰かの伝聞や翻訳されていない公式の情報)に当たれないから、日本語はやめたほうがいいよ」とアドバイスされました。 それまでも特に英語には苦手意識はありませんでしたが、なんとなく日本語の方が読みやすいと思っていたのでついついそっちを見てしまっていたのでした。

それから英語のドキュメントを読む習慣をつけたところ、まるで道が開けたように使えるライブラリが増えたり知らない情報を自分のものにできるようになりました。 決して英語を勉強しなおす必要はなく、知らない単語だけ辞書で調べる程度で充分なのです。 大事なのは「英語だから見ない」という意識をなくすことです。

5. 勉強したこと自体に満足する

勉強したこと自体に満足する

勉強は何のためにするのでしょうか? それがわからないで盲目的に勉強することは、貴重な時間を無駄にするだけです。

会社の目的はお金を稼ぐこと。 あなたの興味と会社の必要性は、一致する場合もありますがそうでないこともあります。 (なので僕は可能な限りそこが一致する会社に行くことを選んだのですが)

なので「とても有意義に勉強できた!!」で終われば、それは会社的には何もやらなかったことと同義です。 趣味としてやる勉強自体はよいですが、しっかり普段の仕事のスキルを上げるための自分磨きをする習慣を付けたいところ。

そのためには「この勉強をすることで仕事にどう役立つのだろう?」という疑問を考える習慣をつけるべきです。 普段の勉強でも、目的を考えてやるだけでその後のアウトプットが大きく改善されると思います。

チャットで絶対に返答してもらえるちょっと面倒だけどシンプルな方法

全体に投げたけど返事来ない問題

LINEやSlackの「全体にメッセージ投げたけど誰からも返事が返ってこない」問題。

このとき、メッセージを投げた人は「大事なことだからお前ら全員回答しろーーー!!!」って思っているし、投げられた方は「ああ、全体になんかメッセージ来てるな...(からの既読にして画面を無言で閉じる)」みたいなことをしていると想定します。

そしてメッセージの内容は(投げる側にとっては)どうでも良くない問題であることが多く...

 

  • みんなこのアンケート回答して!
  • 誰かこの仕事代わりにやって!!
  • 週末の飲み会の出欠の返事くれ!!!

そしてことごとくメンバーからシカトされ、後々メッセ投げた人間の負担が増え、それによりチーム内の空気が険悪になるという負のサイクルに....

「全体」ではなく「個人」宛にDMを送る

ではどうやったら確実に全員から返事をもらえるか

答えはとってもカンタンで「全体ではなく個人ごとにメッセージを送る」ことです。

LINEであれば全体ではなく個人LINEへ、Slackであれば@channelや@everyoneをつけるのではなくDM(ダイレクトメッセージ)で送るなどするわけです。

実はたったこれだけで本当に回答率が上がります!!!

試しに想像してみてください、誰かから冒頭に例示したようなメッセージが、全体LINEで来た時自分宛てに直接来た時を。

「やべっ、回答しなきゃ!!」と思ってしまうのはどちらでしょうか

「あぁはいはい...」とスルーしたくなるかのはどちらでしょうか。

人間は都合よく「全員」に「自分」を含めるという心理を持つ

なんでこういうことが起きるかというと、人間は「全員」に自分が含まれるかどうかを勝手に都合よく解釈してしまう心理を持っているからです。

都合よくというのは、ポジティブなことについては「全員に自分も含まれている」と解釈するのに対して、ネガティブなことについては「全員の中に自分は入っていない(=他人事)」と解釈してしまうということです。

例えば「全員におみやげのお菓子あります」と聞くと、人間誰しもこの「全員」に「自分も含まれてほしい」と思うわけで、実際頭はそう解釈します。

よって普段活動をサボっているようなメンバーでさえも「自分はおみやげをもらう権利がある!!」と考えるわけですね。

一方「誰かこのタスクをやってください」と聞くと「オレには関係ない、他の人がやってくれる」と勝手に期待してしまうというのは、皆さん誰でも経験のあることではないでしょうか。

これはネガティブなことについては「自分を対象から除外したい」という心理が働くため、結果として他人事として解釈しスルーしてのです!!

よって「全員」や「誰か」ではなく、名指しで「あなたがやらなければいけない!!」とメッセージすることで、受けた側は「自分がやらなければいけない」という気になり、結果として回答率が上がるのです!!

それでも無視したら、その後確実にお互いの会話で触れることになりますから、逃れられないですしね(笑)

僕もこの方法によって、本当に全員からの回答が必要なものはほぼ回答を得ることができています。

とは言え対象の人数が数十人いたり、頻繁にメッセージを送ることがあったりすると、労力は馬鹿になりません。

なので、本当に全員に言わなければいけないことを吟味したり、そもそもチームの命令系統がトップダウンになってしまってはいないかなどを確認することも必要ですね。

 

「@channel厨」問題も解消する

あとこれはSlackなどのメンション機能があるチャットに限った話ですが、よく全員に通知したいがために頻繁に@channelや@everyoneを付けて頻繁に発言する人=@channel厨がいて、問題になったりします。

その意味でも、@channelや@everyoneの使用頻度を減らすことで全体へのチャンネルに書かれた内容が見やすくなるという効果もある思います。

まぁそこら辺については、みんなでもう一度@naoya氏の有名な情報共有のまとめスライドを見て勉強しましょう(笑)