空飛ぶ羊

勉強したり登壇したり勉強会参加したり

夫のエバンジェリストになりたい #惚気 #夫大好き

この記事は妻・夫を愛してるITエンジニアAdvent Calendarの最終日です。

www.adventar.org

うらがみさんTwitterのノリで決めたらその2までできてて衝撃でした。笑

TL;DR

エンジニア夫婦はいいぞ。meetupやるからきてね eventdots.jp

馴れ初め

勉強会「dodosoft」で出会い、結婚しました。今結婚して3年目です。
付き合ってすぐ同棲したので、一緒に住んでるのは4年くらいです。

okoysm.hatenablog.jp

旦那の好きなところ

優しい

あれやりたいからここ行ってきていい?とか一緒にこれやろうよ!とか受け入れてくれる優しいところが好きです。
松村Advent Calendarや妻・夫を愛しているITエンジニアAdvent Calendarにも参加してくれました。
夫のおかげで社内外で活躍できていると心から思います。

www.adventar.org
muramurasan.hatenablog.jp

交友関係に寛容

学生時代から男友達が多い私で、仲いい友人と二人で出かける時とかも、予め言っておけば行っていいよって言ってくれるところが好きです。この信頼関係が築けているのが良いです。

エンジニアトークで盛り上がれる

rebuildで〜とか、今日はもくもくデートしようとか、そういうノリを受け入れてくれる、むしろお互い楽しめる関係性が築けているところが好きです。

記念日を大事にする

付き合った日、入籍記念日、挙式日、誕生日すべてを大事にしてくれて何かしらイベントをやってくれるところが好きです。

家事ができる

一人暮らしの期間が長かったので家事がほとんどできる。で、私が許せないレベルのところはどんどん直してくれて、今ではすべて任せられます。(例えばおしゃれ着を普通の洗剤で洗うことがなくなりました)

育ちがいい

ご飯を用意する時に、副菜とかもちゃんと用意してくれるところが好きです。

よく褒めてくれる

私が「これできたよー!」とか「発表やりきったよー!」とか言うとよしよしって褒めてくれるところが好きです

一緒にお家Hackできる

詳しくはこちらで。 qiita.com

病気に理解がある

私は精神疾患を患っています。それについて知識・理解があるところが好きです。

私のことをよく見てる

ちょっと調子が悪そうなときとか、疲れているときとか、自分より早く気づいてくれるところが好きです。

お笑いのネタを日常会話に入れて会話できる

サンドイッチマンアンジャッシュが特に好きな夫の影響でお笑いが好きになりました。日常会話で入れてる/入れてたネタを少しだけ紹介します。

いいだしたらキリがなくなってきた

のでこのあたりにしておきます。

22くらいで結婚してどうだった?

正直早い方だとわかっていますが、でも、こんな素敵な男性もう現れないだろうなと思いながら結婚しました。
今でもたまにLIKEな男性がでてきたりしますが、「総合的に夫を超えられるか?」と考えると無理ですね

まとめ

こういう話をできる夫婦Advent最高だなーという感じです。これからもよろしくおねがいします。

夫婦エンジニアMeetupやるよ!

夫婦でエンジニアの人って結構いると思うので、仲良くなりたいです!なのでmeetupを開催することにしました!
keynoteはおしどり夫婦でエンジニアとしても活躍されている大場夫妻です。
Hangout参加枠やキッズスペース用意などもしているので、是非お越しください〜
参加できるのは夫婦エンジニアだけでなく、それに憧れる女性や、お子さんです。

eventdots.jp

おまけ:今年のクリスマスの予定は?

昨日二人でホテルランチしてきました。最高でした。お昼スタートだったのでゆっくりした時間を過ごすことができました。

今日は我が家で私の同僚を呼んでクリスマスパーティーをします!
初めてのクリスマスホームパーティーにわくわくです。やっていいよっていってくれた旦那大好きー!

それではみなさん、メリークリスマス! f:id:okoysm:20161215091010j:plain

主催イベント:Geek Women Japan 2016のふりかえり #geekwomenjapan #gwjp2016

この記事は松村Advent Calendar 2016 最終日です。

www.adventar.org

最終日は私が強力な友人と企画したカンファレンス「Geek Women Japan 2016」のふりかえりをします。

Geek Women Japan 2016とは

Geek Women Japan 2016は11/3に新宿で開催した、エンジニア女子が中心となって一同に集まり、ギークなセッションを繰り広げるカンファレンスです。
主催はGeek Women Japanで、今回が初の開催です。

私はコアキャスト(メインの運営者)とスピーカーとしてカンファレンスに参加しました。スピーカーとしてのブログはこちら
okoysm.hatenablog.jp

私のやったこと

一人でやったことばかりじゃないですが、主な役割です。

企画

カンファレンスで何を行うのか、どんなプログラムを実施するのかなどなど企画しました

運営

  • カンファレンスを運営するためにタイムスケジュールを作成したり、ボランティアスタッフを集めて事前説明会をしたり、当日の指示・サポート・運営活動を行いました
  • コミュニティコラボセッションの企画推進を担当しました(締め切り守ってメール送ったり)

広報

2015/10に始動したばかりだったためまずは知名度をあげるために様々な場所でLTを行ったり、懇親会で興味のありそうな人と名刺交換してスポンサー候補として連絡を取り合ったりしました。

Web

Geek Women Japanの公式ページカンファレンスページを作成しました

配布物作成

チラシを作成しました

スポンサー集め

スポンサー集めました

自分の感想

めっちゃ疲れました。特に9月10月は忙しかったです。自分としては初めてのカンファレンススタッフがまさか当日じゃなくてメインスタッフという。

ボランティアスタッフとの記念写真

私が撮ったので自分が写ってないという(;´・ω・)

得られたもの

  • カンファレンスを運営する経験
  • SPAを実装するくらいのマークアップスキル
  • 人的ネットワーク
  • チラシ納品ノウハウ

犠牲にしたもの

  • 体力
  • 精神的な健康
  • 夫と二人で過ごす時間

Geek Women Japanコアキャストの感想

  • 初回の割には成功した!でも課題はいっぱい
  • 1回目をやれたから、そこからブラッシュアップして2回目はやろう。

またやりたい?

やりたい。てかやりますよ!!!現在準備中です!!

Geek Women Japan代表になりました

もう少しコアキャストほしいので、カンファレンスを創る楽しさ味わいたい人、運営やってみたい人いつでも声かけてね!
あと関西でもやりたいから、そっちでやってくれる人も募集中!

逃げるは恥だが役に立つ #転職

このブログは転職Advent Calendarの23日目です。

qiita.com

昨日は同じ高専出身の先輩で、会社の後輩のいわたんでした。
qiita.com

この記事について

自分がやりたいこと、本当に大切なことを見つけて伸ばせるから、転職はいいぞって話をします。ドラマ「逃げるは恥だが役に立つ」の話は出ません。恋ダンスはサビだけ踊れます。

自己紹介

しょこ (@okoysm) です。高専*1を卒業し、20歳・新卒で総合電機メーカーのソフトウェア開発部門に設計開発者として入社しました。 そして、今年の3月より現職でサーバーサイドエンジニアをやっています。

TL;DR

  • 転職してよかったか?と聞かれると失敗と成功半分半分。でも、人生経験として転職はいいぞ。
  • 自分のやりたいことと会社に求められていることが一致していると仕事しやすい

逃げるは恥だが役に立つ」?

ダンスで話題の「逃げ恥」ですが、このタイトルはもともとハンガリー語のことわざです。

Szégyen a futás, de hasznos.      (ハンガリー語)
= Running is a shame, but useful. (英語)
= 逃げるは恥だが役に立つ

意味は「戦場を選べ」、つまり「自分の土俵で戦え、自分の得意分野で勝負しろ」という解釈になります。

自分の場合

どこでも役に立てない、中途半端なスキルセットでした。ことわざに合わせて言うならば「戦える土俵がない」と思ってました。なのに逃げました。そんな自分を高く評価してくださった、一番初めに内定をくださった今の企業の内定を承諾し、今働いています。

転職のきっかけ

主なきっかけは3つです。
1. 夫が転職した
2. 作ってるもの・使ってるユーザーがわかりやすいものを作りたくなった
3. 会社の方針が自分の方針と合わなくなってきた

夫が転職した

詳しくはこちらのエントリで
muramurasan.hatenablog.jp

夫が転職したのは昨年の10月です。それまでもなんとなくWeb系への憧れがありましたし、いつかそういうので働きたいなーって思ったりしてました。ただ、身近な夫が転職したのは自分の中で大きなきっかけになりました。夫が人生を考えている今、自分はどうだろう?と。そして、夫が転職して新しい会社で色々なものを得ているのを見て、とりあえずDODAに登録しました。

作ってるもの・使ってるユーザーがわかりやすいものを作りたくなった

もともと作っていたのはオンプレミス環境向け管理パッケージソフトで、主なユーザーはデータセンター管理者を想定していました。開発の理念である「お客様にThank you!と言われるものづくりをしよう」にはとても賛同していましたが、作るもの・想定ユーザーどちらも遠く、「自分が作ったプロダクトは本当に喜ばれているのだろうか?」と考えることが多かったです。
それよりは、もっと身近なものを、身近な(ITリテラシー低い人でも使える)ものを作りたいと考えていました。

会社の方針が自分の方針と合わなくなってきた

自分のいる部門が自社製品を設計開発するのではなくSEとして出向して開発するように会社の方針が変わりました。SEとして一時期金融系B2Cシステムの開発に従事していましたが、あくまでも「ベンダー」だったので、何をするにも制約があり苦しかったです。ここで私は改めて 自分にベンダーは向いてない と思いました。

転職活動どうだった?

基本的に仕事の後だったのと、別業界からの転職だったので体力・精神ともに結構苦労しました。
ちなみにこのときの転職活動はWantedlyと転職エージェント(DODA)を使いました。

嬉しかったこと

いろんな会社のいろんな社風・考え方に触れられた

これは転職活動しなくてもできたのですが、転職活動をきっかけに様々な会社にWantedly経由で訪問しました。
自分の会社とは変わった考え方、服装などとても新鮮でした

メーカーでやってきた「当たり前」が評価された

SIを経験したWeb業界で活躍する方に聞いて気付かされたのですが、例えばテストの方法など、メーカーでは「MECEに」「境界値をみる」など当然とされていることが、Webしか知らない人だと「この辺プログラム難しかったしバグ多かったからテストしておこう」となってる人が多いので、その意味で、メーカーの当たり前をそのまま適応するかは置いておいて、考え方などは悪くないと言われ嬉しかったです。

好きでやってた社外での活動が評価された

当時、私は業務外で女性エンジニアコミュニティ「dots.女子部」の若女将(運営メンバー)をやっていました。また、dots.女子部のイベントを中心に様々なイベントで登壇していました。私自身は好きでやってただけなのに、それが転職において「強み」として評価されたのは嬉しかった

辛かったこと

主に辛かったのは3つです。

業務後疲れた状態で面接を迎えること

ちょうど転職活動していた時期が忙しかったため、頭が回ってない状態で役員面接を何度も迎えました。
もし本命を受けるときは半休とるなどしたほうが良かったなと今では思います。

自分のスキルセットがWebと合わない

自分が主にやっていたのはフロントエンドとバックエンドの開発とオフショア開発のブリッジSEだったのですが、それがWebのスキルセットと合いませんでした。
私がやってたフロントエンドは前時代的なもの(Flex/ActionScript3.x)でしたし、バックエンド開発をやっているといってもWebサービスではなかったのでバックエンドも合わず、ブリッジSEは英語アピールの一つくらいにしかならず、インフラは業務知識であるだけで自分のやりたいことに合わない。
とても苦しかったです。

ゼネラリストではなく、ほどほどにしかできない器用貧乏

私の職務経歴書を見ると分かるんですが、年齢(25歳)の割に経験してきた担当工程めちゃくちゃ広いんですよ。ただ、これは裏を返せば「これなら任せてください」という強みがないということです。
転職活動において、自分を採用するメリットをPRするのはとても難しいです。

今の会社に評価されたポイント

入社前後で聞いた話を踏まえると以下の3点かなと思います。

ポテンシャル

20歳で就職したので面接時は24歳なのに4年目で前職での担当工程はビジネス側から開発のテスト・納品まで多岐にわたり、かつオフショアのブリッジSEもやったり、研修の一環で営業や工場のラインやったりと、いわゆる理系大学院2年生と同じ年でたくさんのことをやってきていました。
それに加え人見知りしないので、新しいものをどんどん吸収するために周りを巻き込めるのではという点でした

テクノロジーブランドの向上要員

私は社外での活動が好きですが、弊社の多くのエンジニアはあまり発信しません。「勉強会に参加しよう」って言われてるくらい、参加すらしない人が多いです。
そんな中、勉強会に参加するだけじゃなく、企画したり運営したり登壇したりする人が来るだけで社内に新しい風を吹かせられるという点が評価されました

会社にいない「新しい風を吹かせてくれる人材」

自分で書くのも恥ずかしいですが、勉強会に登壇したり、新しい仕組みを導入したり、アジャイルな開発に慣れていたり、一通りの工程を経験していたり、とにかく行動力とスピードがある。そんな人材弊社には居ませんでした。
ですので、テクノロジーブランドを向上すべく「新しい風を社内に吹かせてくれそう」という点が評価されたと思います

転職した感想

成功したと思った部分

新しいこと・楽しいことをガンガンできる

「新しい風を吹かせてくれる人材」と見られているので、デザイン思考*2や、アジャイルのプラクティス、新しいフレームワークの導入など、新しいこと面白いことをたくさんやらせていただいています。
Mashup Awards for Proにも出させていただき、実際にチームを優勝に導きました。 okoysm.hatenablog.jp

自分が本当に大事にしたいことが分かる

転職した時は「ITリテラシーが低い人でも使ってるB2CのWebサービス開発がしたい」と思っていたのですが、実際転職して自分が大事にしたいことは、 「職能に縛られず自分がチームで考えたいいとおもったコンテンツを世の中にガンガン出したい」「技術面の師匠がすぐそばに居ること」だったことです。
失ってから初めて気づくとはよく言いますが、まさにそれで、前職はとても恵まれていたのだなと改めて感謝しました。

失敗したと思った部分

※注意※以下の失敗した部分については、自分なりになんとか失敗にしないように改善案を検討・実践しています。

面接官の話していた言葉の定義が自分と違った

面接官は「上流から下流のテストまでできる」と聞いていたのに、実際はウォーターフォールみたいな開発手法を採用しており、サーバーサイドエンジニアはディレクターから降りてきた仕様を詰めて、実装するというスタイルでした。悪くいうならば社内外注ですね。
私はこの言葉を「上流のコンテンツ検討からデザイン、フロントエンド開発、サーバーサイド開発、テストすべてに携われる」と思っていました。
ですが面接官は「上流のマネジメントや下流の担当レベルの開発までできる」という意図で話していたことが入社後にわかりました。入社当時フロントエンド・バックエンド両方やりたいと思っていた自分としてはまずここで大きな失敗をしたと思いました。

開発環境が想像以上にレガシーだった

まずウォーターフォール開発で一つ一つのフェーズで中間成果物を作成して開発しているためとてもリリースまでに時間がかかっています。前職ならこれくらいもっと早く終わったのに・・・悔しい・・・という気持ちを感じることが多かったです。
この会社に転職してから定時後2週間ほど某社に社会人インターンに行っていたのですが、初めてRuby on Rails触った人が実装しても、弊社なら3ヶ月かかりそうな規模のリリースを行いました。

開発環境のレガシーさは語ればキリがないので一つだけいいます。メインサービスはEOLを数年前に迎えているPHP5.x系*3で動いています。PHPの最新バージョンは7.1です。

自分の伸ばしたいスキルと会社に評価されるスキルの不一致

半期に一度の上司から評価されたのですが、評価が高かったのは「この会社で身につけたスキルを発揮した時」ではなく「前の会社や社外で自分が見つけたスキルを発揮した時」です。中途採用者だしそういうものなのかもしれないけれど、自分は普段の業務で手札を増やすために転職したのに、外や前職で手に入れた手札を出すことのほうが評価されてしまっている。もっと言えば、業務よりその手札を出すことを期待している人も社内に少なくありません。

そんな状況で今25歳。ここで20代後半を過ごして30以降エンジニアとして生きていけるのだろうかと日々考えて、色々試したりしています。例えば、アーキテクチャ検討・Scalaの実装に集中できるチームに異動したり、転職DRAFTにENTRYするなど。

今後どうする?

逃げるは恥だが役に立つ。でも、やりたいこともやる!

ここでタイトルに戻ります。意味は「自分の土俵で戦え、自分の得意分野で勝負しろ」でした。
そして自分のやりたいことが、「職能に縛られず自分がチームで考えたいいとおもったコンテンツを世の中にガンガン出したい」「技術面の師匠がすぐそばに居ること」です。
だから、今後は自分の得意分野を活かしつつやりたいことができる職場に今の職場を改善するか、私の得意分野を求めていて、かつ私のやりたいことができる職場に移るかしていきたいと思います。

Always Job Hunting!!

20代後半ガッツリ働きたいので、「あなたみたいな人材がほしい!師匠もつけるよ!」という会社のみなさま、Wantedlyなどで連絡ください。

www.wantedly.com

github.com

参考リンク

*1:高等専門学校。中学の後に進む5年制の学校。詳しくはググって

*2:スタンフォード大学のd.schoolが提言しているサービス開発手法の一つ

*3:小数点以下は秘密らしいです

学習メモ: クラス (2/2) #dwango #Scala

この記事について

ドワンゴScala研修テキストを学習したときのメモです。 okoysm.hatenablog.jp

前回はこちら okoysm.hatenablog.jp

DOING

クラス

メソッド定義

メソッド本体が1つの式だけからなる場合

基本形(実態)。

(private[this/package名]/protected[package名]) def methodName(parameter1: Type1, parameter2: Type2, ...): ReturnType = ???

一般的な定義

  • ={}を使ったスタイルのほうが{}内に複数の式を並べて書けることを利用した派生形。
  • こっちのパターンのほうが使うことは多い
(private[this/package名]/protected[package名]) def methodName(parameter1: Type1, parameter2: Type2, ...): ReturnType = {
  ???
}

返り値の型は明記しよう

  • 省略しても特別な場合以外は型推論してくれるけれども、読みやすさのために明記する習慣をつけよう
    • 個人的にはこれがいいから静的型付け言語好き

アクセス権

  • アクセス権は3種類 (private, protected, public)
    • private:そのクラス内だけからのみアクセス可能
    • protected:派生クラスからのみアクセス可能
    • public:どこからもアクセス可能
    • 何も付けない:publicになる((ここだけJavaと違う。Javaの場合protected〜private程度のアクセス権だった))

Scala独特のアクセス権まわりの書き方

  • private[this]:同じオブジェクトからのみアクセスが可能
  • private[package名]:同一パッケージに所属しているものからのみアクセスが可能
  • protected[package名]:派生クラス+同じパッケージに所属しているもの全てからアクセスできるようになる

メソッドを実装してみる

メソッド名に+を指定できるのが衝撃だった

scala> class Point(val x: Int, val y: Int) {
     |   def +(p:Point): Point = {
     |     new Point(x + p.x, y + p.y)
     |   }
     |   override def toString(): String = "(" + x + ", " + y + ")"
     | }
defined class Point

scala> val p1 = new Point(1, 1)
p1: Point = (1, 1)

scala> val p2 = new Point(2, 2)
p2: Point = (2, 2)

scala> p1+p2
res0: Point = (3, 3)

複数の引数リストを持つメソッド

メソッドは複数の引数リストを持つように定義することができる

def methodName(parameter11: Type11, parameter12: Type12, ...)(...)(parameterN1: TypeN1, ..., parameterNM: TypeNM): RerurnType = ???

用途

実装してみる

複数の引数リストを持つ加算メソッドを定義してみる。

  • 複数の引数リストを持つメソッドはobj.m(x)(y)の形式で呼びだす
  • 一番下のように、最初の引数だけを適用して新しい関数を作る(部分適用)こともできる
scala> class Adder {
     |   def add(x: Int)(y: Int): Int = x + y
     | }
defined class Adder

scala> val adder = new Adder()
adder: Adder = Adder@5132ea8c

scala> adder.add(2)(3)
res2: Int = 5

scala> adder.add(2) _
res3: Int => Int = $$Lambda$1791/569849097@1ceeb7d7

疑問点

  • 複数の引数リストを持つメソッドで、最初の引数だけを適用して新しい関数を作る(部分適用)の使い所はどこ?

フィールド定義

定義

(private[this/package名]/protected[package名]) (val/var) fieldName: Type = Expression

val/var

  • val: 変更不能なフィールドになる
  • var: 変更可能なフィールドになる

アクセス権

  • private : そのクラス内だけからのみ
  • private[this] : 同じオブジェクトのみ
  • private[package名] : 同一パッケージからのみ
  • protected : そのクラスの派生クラスからのみ
  • protected[package名] : 派生クラスと同一パッケージに所属しているもの全て
  • なにもつけない:public

private[this]は若干高速

  • JVMレベルでのフィールドへの直接アクセスになるため、若干高速
  • 細かいレベルでのパフォーマンスチューニングをする場合は意識すると良い

継承

クラスのもう一つの機能が継承

継承の目的

Javaの継承の目的とあんまり変わらん

  1. 継承によりスーパークラスの実装をサブクラスでも使うことで実装を再利用すること
  2. 複数のサブクラスが共通のスーパークラスのインタフェースを継承することで処理を共通化すること

実装の継承におけるJavaとの違い

ScalaはTrait(次々回)を使うことで複数の実装の継承ができる

実装の継承には複数の継承によりメソッドやフィールドの名前が衝突する場合の振舞いなどに問題があることが知られており、Javaでは実装継承が1つだけに限定されています。 Java 8ではインタフェースにデフォルトの実装を持たせられるようになりましたが、変数は持たせられないなどの制約があります。 Scalaではトレイトという仕組みで複数の実装の継承を実現していますが、トレイトについては別の節で説明します。

通常のクラスの継承の構文

Javaと同じくextends書く

class SubClass(....) extends SuperClass {
  ....
}

メソッドをoverrideするとき

JavaアノテーションJavadocで記載していたが、Scalaでは明示的に書く

scala> class APrinter() {
     |   def print(): Unit = {
     |     println("A")
     |   }
     | }
defined class APrinter

scala> class BPrinter extends APrinter {
     |   override def print(): Unit = {
     |     println("B")
     |   }
     | }
defined class BPrinter

scala> new APrinter().print
A

scala> new BPrinter().print
B

この章での疑問点

  • コンストラクタの引数をそのまま公開したくない場合などあるのだろうか(Javaでいうprivateな変数にしてgetter/setterで取らせたいみたいなやつかな)
  • 複数の引数リストを持つメソッドで、最初の引数だけを適用して新しい関数を作る(部分適用)の使い所はどこ?

進捗

DONE

TODO

  • オブジェクト
  • トレイト
  • 型パラメータと変位指定
  • 関数
  • Scalaのコレクションライブラリ
  • ケースクラスとパターンマッチング
  • エラー処理
  • Implicit
  • 型クラスの紹介
  • FutureとPromise
  • テスト
  • Javaとの相互運用
  • S99の案内
  • トレイトの応用編:依存性の注入によるリファクタリング

好き・嫌いを決めてしまうから難しい。でも、メンターはいいぞ。 #メンター #イベント運営

この記事は松村Advent Calendar 2016 22日目です。

www.adventar.org

最初は不安だらけの松村Advent Calendar 2016ですが、たくさんの松村さんのおかげで走りきれそうです。
ありがとうございます。

本題

今年は4つのイベントでメンターしてきました

女性だけのEngadget電子工作部 (3/12, 26)

NTTドコモとEngadgetが共同で開催した、女性参加者のみによるハッカソンです。
主な参加者:Webエンジニア・組み込みエンジニア japanese.engadget.com

Hour of Code こどもの日1万人プログラミング (5/5)

2013年にアメリカで始まった、小学生から始められるプログラミング入門教育のプロジェクトです。
主な参加者:小学生 eventdots.jp

社内デザイン思考ワークショップ (8/24, 9/8)

スタンフォード大学のd.schoolが提唱しているサービス開発のプロセスの一つを実際に体感するワークショップ
主な参加者:弊社エンジニア・ディレクター・デザイナー

東大ガールズハッカソン (11/4〜12/4)

東大女子のための、プログラミングをゼロから学べるアプリづくりコンテストです。
参加者:東京大学の女子学生 http://www3.nhk.or.jp/news/html/20161205/k10010795611000.html?utm_int=news-culture_contents_list-items_013www3.nhk.or.jp

メンターって何やるの?

イベントごとにかなり違うのでまとめます

女性だけのEngadget電子工作部の場合

  • イベント自体の企画・提案(女性への配慮は足りているか、女性イベントならではの気遣い、食事のチョイス)
  • 参加者と同じ目線で相談できる相談役
  • 各チームの様子をみてアイデアのヒントを出したり、アイデアを出しやすい方法を提案
  • コミュニケーションの活性化(議論するFacebookグループにメンバーとして入っておく)

Hour of Code こどもの日1万人プログラミングの場合

  • 5〜6人でHour of Codeのプログラムを教える
  • プログラマな考え方を提案してみる(今動いてるけど、もっと短く書く方法あるから工夫してみようとか)
  • メンターした子どもたちにHour of Code修了証書授与
  • その他イベント運営

社内デザイン思考ワークショップの場合

  • 参加者の募集
  • デザイン思考のプロセスに関するアドバイ
  • その他イベント運営
  • 主催者・メンターでのふりかえり

東大ガールズハッカソンの場合

  • イデアソンでアイデアを出させるためのサポート
  • イデアをブラッシュアップするためのアドバイ
  • イデアを実現するための技術的アドバイ
  • 当日のプレゼンアドバイス・撮影補助
  • 弊社メンター同士でのふりかえり

メンターって難しい

私が今年メンターとして関わったイベントはどれも「今までしたことない人が初めてやってみる」イベントでした。ですので、ここで「俺には合わない、苦手だ」と思われてしまうとそこでその人は一生やらなくなってしまうのも往々にしてあると思っています。そういう人を減らして、むしろ「このイベントじゃ足りない、もっとやりたい!」と思わせるメンターの関わり方って難しいと思いました。

そういう意味で言うと、社内のものはその後実際の仕事にデザイン思考を取り入れたコンテンツ開発を行うところまで持っていけたので成功でした。ただ、他のものは一期一会、その場限りの出会いなので実際どうなっているかはわかりません。もう一生プログラムは見たくないって思ってる人がもしかしたらいるかもしれません。

でも、メンターはいいぞ。

メンターをやっていると得られるものたくさんあります。自分が教えることで脳内が整理されたりする経験も多くすると思います。だから、周りでメンター募集しているという話があったら是非チャレンジしてみてください。

抱負

来年もおそらくメンターやらない?っていう話が来ると思う(というかすでに来ている)のでいくつかやると思うのですが、そのときは「このイベントじゃ足りない、もっとやりたい!」と思わせるメンターでありたいなと思います。

ちなみに、私自身メンターなど誰かに教えることは学生時代から好きです。家庭教師や塾の自習室のチューターのバイトを2年ほどやっていましたが、生徒から「学校の先生よりわかりやすいのに、どうして先生にならないの?」とか「しょうちゃんに学校でも教えて欲しい」とか言われたりすることもあったくらいです。書きながら思い出しニヤニヤしてしまいました。笑

明日の担当者

ta9marさんです!カメラか子供かAndroidか…お話楽しみです!

今年の登壇振り返り:Mashup Battle final Stage For Pro #MA_2016

この記事は松村Advent Calendar 2016 20日目です。

www.adventar.org

Mashup Awards for Pro オンライン審査に通過し決勝でプレゼンしてきたのでそれについて書きます。これで今年の登壇は14回ってことになりました。笑
私自身はMashup Awards自体出場するの初めてです。

イベント概要

Mashup Awards(以降、MA)とは

2006年に始まった日本最大級の開発コンテスト。 様々なAPI、デバイス、ハードウェア、技術、アイデア、人、チーム、企業を Mashup(混ぜあわせ)し、新しい体験を生みだす、ものづくりの祭典です。 ものづくりに携わるすべてのITクリエイターに、楽しみと輝きを。 11年目の今年、MA2016より新しく「For Pro」がスタート!*1

Mashup Battle final Stage For Pro

MAの法人部門です。今年新設されました。最終的に決勝に残ったのは約30チーム*2中4チーム!

hacklog.jp

発表資料

私たちは「全社員早押上司争奪戦」という特務内容(=サービス)について話しました。
結果は、優勝!!!!for Pro部門初代チャンピオンになりました!!!!!!!
speakerdeck.com

Hacklog

サムネイルの圧倒的吸引力
hacklog.jp

公式ページの結果発表

mashupaward.jp

興奮覚めやらぬまま書いたブログ

okoysm.hatenablog.jp

登壇のきっかけ

For Pro自体を知ったのは弊社がMAのスポンサーで、出る人いませんか?と全体会議であったので出場を決める。あとは同期のデザイナーや仲の良いアプリエンジニア、出たいけどメンバーがいないフロントエンドエンジニアの子とチームを組んで出場し、ものやビデオ、LPなど作ってオンライン審査に登録。見事に通過しました!嬉しい!サムネイルの吸引力もあったからだと思うのですが、おそらくFacebookいいね!数一位でしたw

登壇振り返り

本当に優勝できて良かったです。 これまで何度も登壇してきましたが、360度の方向から見られるのは初めてだったのでとても難しかったです。
そして、久々に緊張しました。普段の発表は自分の評価ですが、今回の発表は素晴らしいチームメンバーが作ったプロダクトをプレゼンするってことで、5人分の結果を審査員にぶつけないといけないというプレッシャーがすごかったです。しかも、ファイナリスト席には一人しか座れず、他のメンバーと離れてしまいどんどんプレッシャーに負けそうになりましたが、LINEなどでなごませてくれてすごい助かり、いいプレゼンできたと思っています。ほんとうにありがとう!
また、事前にtouch&tryエリアで展示していたことで、審査員からの質問に即答できました。展示は大事ですね。今後もできるだけ手にとって使える状態での発表心がけたいです。

審査員の方々からの講評

謝辞 (チーム加入順)

デザイナー:イーノ・ウエ

「まつむー(私)がいい感じに引っ張ってくれそうだし、ついてくよ」と言って加入してくれた。
もうまさにジェバン二*3。神。モノのロゴや「ぐ」をベースにしたマークや、デモ展示のときに飾るチラシや配布物のたたき台がすぐにあがってきました。
また、あの圧倒的吸引力のサムネイルを作ったり、服のコンセプトを考えたりと「全社員早押上司争奪戦」の世界観のクオリティをガンガン上げてくれました。
本当にありがとう。

アプリエンジニア:カイ・フク

あとで紹介するイワンコフと同じチームで最近入ってきた方で、MAまであまり絡みなかったけれど、「もしよかったらやりませんか?」と聞いたら面白そう!とやってくれました。
前職がゲーム系だったらしく、アプリの動きがすごくゲームっぽくてデザインを考えたデザイナーだけでなくチームメンバー全員が感動する動きをいい感じにつけてくれました。
またMESHとAndroidとの連携の開発もやっていただきました。ありがとうございます。

バックエンドエンジニア:イワンコフ

長い付き合いなのと、こういうの好きそうだからとで勝手にメンバーに入れちゃったけれど、影のリーダーとしていい感じにマネジメントもしつつサーバーサイド作ってくれました。
ランディングページにのせてるふざけた概要もほとんど彼が作りましたwおもしろさを追求できてたのしかったです。
また、動画撮影(THETA S)や動画編集 (You Tubeにアップしているもの)などもやってくれて本当に助かった。ありがとう。

フロントエンドエンジニア:セキメイ

Mashup Awardsチャレンジしたいけどチームが・・・と悩んでいたので誘いました。
仕事で引っ張りだこでなかなかできないと本人は言っていたけれど、夜中遅くまで作業してるの知ってます(コミットログみると午前3時になってたり)
アプリに負けないいい感じの上司画面と、このサービスのランディングページ作ってくれました。ありがとう。

まとめ

社内でおもしろいメンバー集めておもしろいもの作るのってすごい楽しかったです。
やっぱり何かを作るのは一人よりチームで、時間をかけて全力ってのが楽しいなーと改めて実感しました。 そして、自分たちがおもしろいとおもったものを評価してくれる機会を提供してくださるMA事務局の皆さんありがとうございました!

次回予告

明日はハード松村さん!週アス風同人誌、気になります!

職務経歴書をGitHubに公開するのはいいぞ #職務経歴書

この記事は松村Advent Calendarの19日目です。

www.adventar.org

登壇ネタは12/13までで終わったのでここからはノンジャンルでいきたいと思います。

本題

自分、売り込んでますか?

転職活動とは言わないけれど、自分を売り込んでいますか?エンジニアは売り手市場と言われていますが、それにいつまでも甘えてはいられません。私は実力の割にめっちゃ売り込んでいるつもりです。ちょっとした実績もWantedlyにめっちゃ反映しています。

www.wantedly.com

すると、WantedlyやFacebookメッセンジャー、Linkedin、GMailなどにかなりの頻度でスカウトがきます。スカウトされたら半分くらいは、会うようにしています。興味ある企業だったらいいんですが、案外話してたら面白い企業とかあったらもったいないので。

書類めんどくさい

でも、スカウトされた後返信するとよく言われるのは「履歴書と職務経歴書をください」いちいち書類かくの面倒ですし、こちらから志望したのではなく、向こうからスカウトなのであれば志望理由とか書けないし、でもとりあえず会ってみたい。
そんなときってないでしょうか。

そこで履歴書だったらWantedlyです。一般的な履歴書にある情報のうち住所以外が書いてあります。スタートアップだったりWeb系企業だとこれで問題ない時が最近多いです。
ただ、職務経歴書だけはなかったんですよね・・・

ないものは作る

だってエンジニアですからね。私は、職務経歴書GitHubでプレビューできるように職務経歴書リポジトリを作成して、それのREADME.mdに職務経歴をまとめました。また、他の人も利用できるようにテンプレートのリポジトリを作りました。ここにある内容書けばだいたい職務経歴書と同じ情報を提供できるでしょう。
github.com

これを作ったいきさつについての詳細はQiitaにまとめているのでそちらを御覧ください
qiita.com

まとめ

やるべきことに力を注ごう
エンジニアの本業は人と人とのやりとりをするためのドキュメントを書くことではなくものづくりのはずです。だから、そこに集中できるように他の部分はどんどん省いていきましょう。

おまけ

おまけが本番。Qiitaの記事についてTwitterはてブコメントでみつけた疑問とか意見にここで答える。

Q:OSSというか「GitHubに置いた」が正しいのではないか

その通りです。そのため、テンプレートにはCC0のライセンスを設置しています。ご自身の職務経歴書については自分で考えてくださいw

意見:MasterにPushするとCIでPagesのブランチにHTMLとして書き出すところまでやるとすごく良さそう

今はdocsで同じブランチに管理もできるようにもなりましたし、良さそうですね!

Q:フォーマットはMarkdown, JSON, yamlのどれがいいんだ

私はMarkdownがいいと思います。JSONyamlだと同じ会社でいろんなプロジェクトでいろんな仕事をしていた場合に階層が深くなってしまうと思います。

意見:自分では思っていない良い点がPRで来るので社内の人事査定版みたいなのもあっていい話だ

導入したら教えてください!

Q:便利そうだけど、いままでの職歴フルオープンにしても大丈夫なのかな…

それは職歴次第です。NDA・企業秘密は守りましょう。

意見:linkedinでいいのでは

日本だとそんなにlinkedin流行ってないのでGitHubのほうがいいと思いました。

意見:企業の人事の履歴が企業間で共通のフォーマットになっていていつでもダウンロード可能になってればいいんだろうな、とは思った。

それな!それだったら毎回作成する必要もないですし。

意見:経歴詐称すると同級生とか元上司とかからPR来るのか。

来ます。それはそれで面白いかと思います。

明日は12/17にあったMashup Awards for Proの決勝について私が書きます。