好き・嫌いを決めてしまうから難しい。でも、メンターはいいぞ。 #メンター #イベント運営
この記事は松村Advent Calendar 2016 22日目です。
最初は不安だらけの松村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日目です。
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チーム!
発表資料
私たちは「全社員早押上司争奪戦」という特務内容(=サービス)について話しました。
結果は、優勝!!!!for Pro部門初代チャンピオンになりました!!!!!!!
speakerdeck.com
Hacklog
サムネイルの圧倒的吸引力
hacklog.jp
公式ページの結果発表
興奮覚めやらぬまま書いたブログ
登壇のきっかけ
For Pro自体を知ったのは弊社がMAのスポンサーで、出る人いませんか?と全体会議であったので出場を決める。あとは同期のデザイナーや仲の良いアプリエンジニア、出たいけどメンバーがいないフロントエンドエンジニアの子とチームを組んで出場し、ものやビデオ、LPなど作ってオンライン審査に登録。見事に通過しました!嬉しい!サムネイルの吸引力もあったからだと思うのですが、おそらくFacebookいいね!数一位でしたw
登壇振り返り
本当に優勝できて良かったです。
これまで何度も登壇してきましたが、360度の方向から見られるのは初めてだったのでとても難しかったです。
そして、久々に緊張しました。普段の発表は自分の評価ですが、今回の発表は素晴らしいチームメンバーが作ったプロダクトをプレゼンするってことで、5人分の結果を審査員にぶつけないといけないというプレッシャーがすごかったです。しかも、ファイナリスト席には一人しか座れず、他のメンバーと離れてしまいどんどんプレッシャーに負けそうになりましたが、LINEなどでなごませてくれてすごい助かり、いいプレゼンできたと思っています。ほんとうにありがとう!
また、事前にtouch&tryエリアで展示していたことで、審査員からの質問に即答できました。展示は大事ですね。今後もできるだけ手にとって使える状態での発表心がけたいです。
審査員の方々からの講評
【FESTA】 #MA_2016 #授賞式
— MashupAwards@12/17祭り (@mashupaward) 2016年12月17日
審査員麻生さんより講評
選出理由について、ForProの上司争奪戦についてですが、アイデアや仕組み自体は既存でもありましたが、それをストーリーを作って文脈があったこと、構成力が評価されました
【FESTA】 #MA_2016 #授賞式
— MashupAwards@12/17祭り (@mashupaward) 2016年12月17日
審査員麻生さんより講評
審査コメントとしてあがったのは「あるまじき力のかけ方である」というフレーズでした、ぐるなびさんの素晴らしさがわかりました。おめでとうございます
謝辞 (チーム加入順)
デザイナー:イーノ・ウエ
「まつむー(私)がいい感じに引っ張ってくれそうだし、ついてくよ」と言って加入してくれた。
もうまさにジェバン二*3。神。モノのロゴや「ぐ」をベースにしたマークや、デモ展示のときに飾るチラシや配布物のたたき台がすぐにあがってきました。
また、あの圧倒的吸引力のサムネイルを作ったり、服のコンセプトを考えたりと「全社員早押上司争奪戦」の世界観のクオリティをガンガン上げてくれました。
本当にありがとう。
アプリエンジニア:カイ・フク
あとで紹介するイワンコフと同じチームで最近入ってきた方で、MAまであまり絡みなかったけれど、「もしよかったらやりませんか?」と聞いたら面白そう!とやってくれました。
前職がゲーム系だったらしく、アプリの動きがすごくゲームっぽくてデザインを考えたデザイナーだけでなくチームメンバー全員が感動する動きをいい感じにつけてくれました。
またMESHとAndroidとの連携の開発もやっていただきました。ありがとうございます。
バックエンドエンジニア:イワンコフ
長い付き合いなのと、こういうの好きそうだからとで勝手にメンバーに入れちゃったけれど、影のリーダーとしていい感じにマネジメントもしつつサーバーサイド作ってくれました。
ランディングページにのせてるふざけた概要もほとんど彼が作りましたwおもしろさを追求できてたのしかったです。
また、動画撮影(THETA S)や動画編集 (You Tubeにアップしているもの)などもやってくれて本当に助かった。ありがとう。
フロントエンドエンジニア:セキメイ
Mashup Awardsチャレンジしたいけどチームが・・・と悩んでいたので誘いました。
仕事で引っ張りだこでなかなかできないと本人は言っていたけれど、夜中遅くまで作業してるの知ってます(コミットログみると午前3時になってたり)
アプリに負けないいい感じの上司画面と、このサービスのランディングページ作ってくれました。ありがとう。
まとめ
社内でおもしろいメンバー集めておもしろいもの作るのってすごい楽しかったです。
やっぱり何かを作るのは一人よりチームで、時間をかけて全力ってのが楽しいなーと改めて実感しました。
そして、自分たちがおもしろいとおもったものを評価してくれる機会を提供してくださるMA事務局の皆さんありがとうございました!
次回予告
明日はハード松村さん!週アス風同人誌、気になります!
職務経歴書をGitHubに公開するのはいいぞ #職務経歴書
この記事は松村Advent Calendarの19日目です。
登壇ネタは12/13までで終わったのでここからはノンジャンルでいきたいと思います。
- 本題
- まとめ
- おまけ
- Q:OSSというか「GitHubに置いた」が正しいのではないか
- 意見:MasterにPushするとCIでPagesのブランチにHTMLとして書き出すところまでやるとすごく良さそう
- Q:フォーマットはMarkdown, JSON, yamlのどれがいいんだ
- 意見:自分では思っていない良い点がPRで来るので社内の人事査定版みたいなのもあっていい話だ
- Q:便利そうだけど、いままでの職歴フルオープンにしても大丈夫なのかな…
- 意見:linkedinでいいのでは
- 意見:企業の人事の履歴が企業間で共通のフォーマットになっていていつでもダウンロード可能になってればいいんだろうな、とは思った。
- 意見:経歴詐称すると同級生とか元上司とかからPR来るのか。
本題
自分、売り込んでますか?
転職活動とは言わないけれど、自分を売り込んでいますか?エンジニアは売り手市場と言われていますが、それにいつまでも甘えてはいられません。私は実力の割にめっちゃ売り込んでいるつもりです。ちょっとした実績もWantedlyにめっちゃ反映しています。
すると、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がいいと思います。JSONやyamlだと同じ会社でいろんなプロジェクトでいろんな仕事をしていた場合に階層が深くなってしまうと思います。
意見:自分では思っていない良い点がPRで来るので社内の人事査定版みたいなのもあっていい話だ
導入したら教えてください!
Q:便利そうだけど、いままでの職歴フルオープンにしても大丈夫なのかな…
それは職歴次第です。NDA・企業秘密は守りましょう。
意見:linkedinでいいのでは
日本だとそんなにlinkedin流行ってないのでGitHubのほうがいいと思いました。
意見:企業の人事の履歴が企業間で共通のフォーマットになっていていつでもダウンロード可能になってればいいんだろうな、とは思った。
それな!それだったら毎回作成する必要もないですし。
意見:経歴詐称すると同級生とか元上司とかからPR来るのか。
来ます。それはそれで面白いかと思います。
明日は12/17にあったMashup Awards for Proの決勝について私が書きます。
業務外でもScalaは伸ばせる #Scala
この記事はdots.女子部 Advent Calendar 2016の18日目です。
昨日は私のQiitaの軽くバズった記事にコメントしてくださったTamilyさんです。
この記事について
業務でScalaがやれなくて何やれば良いのかわからない人でも、業務外でScalaのスキル上げられるっていう話をします。ただ、Scalaに限っていないので他の言語でも参考になると思います。
本題の前に
昨日はMashup Awardsのfor Pro部門決勝戦がありました。結果は優勝!!!初代チャンピオンになりました。やったぜ!
okoysm.hatenablog.jp
本題
TL;DR
伸ばしたいスキルがあれば「師匠(Sensei)」を見つけよう!
Scalaできるようになりたいけど・・・
私はScalaがやりたくてちょっと触ったり、コップ本買ったりしてました。でも分かんないんです、何から手を付ければ。しかも、その書いたコードがどれだけのレベルなのか。Scalaの良いところをつかえているのか・・・
初心者が行けそうな勉強会が少ない・・・
Scalaの勉強会って圧倒的に少ないし、あったとしても参加者みると「あ、あのヤバイ人だ」ってなって、なかなかいけませんでした。この前やっと初めてScala勉強会行きました。とても和やかな雰囲気でしたが、やっぱりレベルの高い人ばかりでした。自分はここに居ていいのだろうかという感じにもなりました。
自信つけるしかないしスキルあげよう!
でも、いつまでも自信がないままでも駄目なのでスキルを粛々と上げています。現在はGitHubでstudy-scalaというリポジトリを公開し、そこに勉強して書いたコードをアップロードしています。でも、書いただけじゃうまくなりませんよね。そこでコードレビューです。
業務外レビュワーを見つけよう!
私はTwitterで以下のように呼びかけてみました。
すると @kmizu さんが手を挙げてくださいました。現在色々基本的なところから見ていただいています。本当に感謝しています。ありがとうございます。業務だったら上司だったり同僚がコードレビューしますが、業務外だとコードレビューなかなかしませんからね。SNSを使って先生を見つけましょう!
できれば英語で書こう!
少なくともこのリポジトリでは、日本語は日本人しか読めないのでやりたいことや何を考えてるかは基本的に英語で書いています。
まとめ
伸ばしたいスキルがあれば「師匠(Sensei)」を見つけよう!
明日の担当はyuunaさんです。楽しみー!
Mashup Awards優勝したぞおおおおお #MA_2016
明日に向けての意気込み #MA_2016
明日はついにMashup Awards for Pro決勝戦!しかも初の360度ステージでのプレゼン!
ドキドキとわくわくが止まりません!
私たちの作品
「全社員早押上司争奪戦」です! hacklog.jp
デモ展示やります!
11:00〜14:00に会場内でデモ展示やります!発表前に触ってみたい方是非お越しください! 当日は限定ポストカードも配布予定です!
発表はfor Proの最後!
決勝は15:10から開始予定で私たちは最後です。 チームメンバー全員登壇します。
意気込み
狙うはもちろんfor Pro優勝です!
いいかお前らー! 私たちは逃げも隠れもしないぞー! 360度? 上等だ! 私たちの覚悟をしっかりと受け止めろー!
ちなみにこの言葉の元ネタはももいろクローバーZのしおりんの最初の言葉です。私の今の気持ちそのままなので引用しました!
ももクロ春の一大事2012~見渡せば大パノラマ地獄~ [DVD]
- アーティスト: ももいろクローバーZ
- 出版社/メーカー: キングレコード
- 発売日: 2012/09/05
- メディア: DVD
- 購入: 1人 クリック: 3回
- この商品を含むブログ (4件) を見る
どうやったら見に行ける?
下のDoorkeeper リンクから登録してください! 様々な作品があるので、2000円の価値はあるとおもいます! 是非お越しください!そして応援してください!
学習メモ: クラス (1/2) #dwango #Scala
この記事について
ドワンゴScala研修テキストを学習したときのメモです。 okoysm.hatenablog.jp
DOING
クラス
クラス定義
- 記述方法以外はJavaと同じ (パラメータの指定方法くらい?)
class ClassName(parameter1: Type1, parameter2: Type2, ...) { (a field or method definition)の0回以上の繰り返し }
例)点を表すクラスを定義する場合
class Point(_x: Int, _y: Int) { val x = _x val y = _y }
コンストラクタの引数をそのまま公開したい場合は以下のように短く書ける
class Point(val x: Int, val y: Int)
疑問点
使うからクラスを定義するんだろうし、そのまま公開するケースのほうが多い気がしたのだけどどうなのだろう?
ポイント
この書き方のポイントは大きく2点。
- クラス名の直後にコンストラクタの定義がある
- Scalaでは1クラスに付き、基本的には1つのコンストラクタしか使わない
- 文法上は複数のコンストラクタを定義できるようになっていますが、実際に使うことはまずないので覚える必要はない
- 最初の1つのコンストラクタをプライマリコンストラクタとして特別に扱っている
- val/varによって、コンストラクタ引数をフィールドとして公開することができる
- プライマリコンストラクタの引数にval/varをつけるとそのフィールドは公開され、外部からアクセスできるようになる
- コンストラクタ引数のスコープはクラス定義全体におよびます。
これを使うと、メソッド定義の中から直接コンストラクタ引数を参照できる。
このプログラムの場合+
メソッド定義の中から直接コンストラクタ引数を参照している
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 + ")" }
この章での疑問点
- コンストラクタの引数をそのまま公開したくない場合などあるのだろうか(Javaでいうprivateな変数にしてgetter/setterで取らせたいみたいなやつかな)
進捗
DONE
DOING
- クラス