AgileJapan2017 富山サテライトで発表してきた

2017/6/24に開催されたAgileJapan2017 富山サテライト会場にて機会を頂いたので、発表させていただきました。

資料はこちらです

speakerdeck.com

内容

Misocaでのミーティングやふりかえり方法について、やり方やメリット、注意点などについて話しました。

SIerから転職してからまだ数ヶ月ということもあって、以前感じていたジレンマなども踏まえて話すことができたので、ITベンチャーなどが少ない富山県のエンジニアに対しては響く内容になったのでは?と勝手に思っています。

意識したところ

現実的な話をしたかった

過去の経験として、こういった発表や資料を見た際に、

「すごい!勉強になる!あ、でもうちじゃ無理だわ!!」

と思うことがありました。

前提となっている環境の部分のハードルが高すぎて、とっても参考になるしタメになるけど、導入ができないな〜というものです。 組織が根本から異なるので、やっぱり難しいんですよね。

という経験も踏まえ、少しでも現実的な着地点をお伝えできるように意識しました。

具体的には

  • 「人間ってそういうものです」
  • 「そうはいっても無理だよね〜」

  • 「じゃあ、それを踏まえてどうするか?」

みたいな話を交えました。

方法より理解、そして小さくやっていく

上記スライドではあまり触れていませんが、実際の発表時には「とにかくコンテキストや意識を共有するのが大事だよ!」というのを何度も繰り返し話していました。

手法だけを導入しても上手くいかないのは、意識の部分での共有が不足しているために反発が生まれるせいだと思っていて、同時にその意識を共有するという部分が一番難しい点だとも思います。

歴史が長かったり規模が大きい組織では、現実的には無理だろうという部分もあるので、そのあたりも踏まえて、小さくやっていこうね!というお話をさせて頂きました。


資料を作る過程で、自分でも「なるほど!こういうことだったのか!」という発見もいくつかあり、とても楽しかったです。

(がっつり資料をレビューしてくれた社内の皆さんには感謝です)

当日参加して聞いていただいた皆様、ありがとうございました。

さー!次は何しよう!

プランニングポーカーをVue+websocketでつくってみた

作ったものの雰囲気は以下の画像を見てもらえればわかると思う

https://raw.githubusercontent.com/wiki/mugi-uno/plahhhh/images/image.gif

プランニングポーカー大きさわかりにくい問題

プランニングポーカーをやる機会がちょくちょくあり、それについて以下のような話を耳にしたことがあった

  • ポイントの差異が直感的ではない
  • 8ptは1ptの8倍ある。8倍ってことを意識できてるのかな?

最近は趣味でVue.jsを触ってることも多かったのと、今更感あるけどwebsocketを使ってみたいな〜と思ってたので、それらを利用して自分で作ってみた

github.com

使ったのは

  • Vue.js 2.0
  • Vuex
  • Vuetify
  • express

よかったこと

人によって好き嫌いありそうだけど、Vuetifyが結構よかった。

見た目がイケてたので軽い気持ちで突っ込んでみたけど、 必要な要素は一通り用意されてるし、導入も苦労がなかった。

基本的に全てのコンポーネントを *.vue ファイルにしてcssもその中に書いていった。

大きな規模でデザイナーさんがいたりすると違う苦労が出てきそうだけど、個人の趣味で使うぶんには全然コレでいいじゃん!って感じだった。

たいへんだったこと

websocketによるデータのやり取りとVuexによるfluxフローを繋ぐのがややこしかった。

Vuexにプラグインの仕組みがあるので、そこで適宜Vuex向けにmutationをコミットする感じだったけど、なんかどうにもコードが冗長になってワケがわからなくなってた。

あとはまあ、とりあえず細かいことは考えずに作っていったので、

  • DBへのデータ保存はまったく考えてない。全部メモリで動いてる
  • ソースが汚い

みたいな問題が密かに残っている

つかってもらってみた

実際にお仕事でプランニングポーカーをする際に使ってもらってみた。

結果として、当初の動機だったポイントの大きさの可視化ではなく、 コンセンサスが取れた場合に派手に表示されることのウケがよかった。

f:id:mugi1:20170609222638p:plain

コンセンサス=良い!という考えはそれでいいのかという気もするが、 とりあえず賞賛されて嫌な気持ちにはならないし、それがよかったのかもしれない。

おためし

herokuボタンがあるので、自由に試してもらえば良いかなと思う。

私の無料dynoに乗ってるのも適当に公開してます↓
https://plahhhh.herokuapp.com/

地方中小IT企業から転職してリモートワーカーになりました

新卒で入社した地元富山の企業を辞め、3月からリモートワーカーになりました。

Toyama.rbに来てくれた人などには直接話したりはしてるのですが、一応3ヶ月間は試用期間ということもあったので、ブログには書かないでいました。

(とはいえ、すでに開発ブログで自己紹介エントリを書かせてもらったりはしてるのですが)

転職に至るまで

前職は、いわゆるよくある中小SIerで、基本的には受託開発がメインでした。

ブラックとかそういう類の会社ではなく、わりと良い会社だったのではないかと思います。

ただ、昔ながらのウォーターフォールでの受託開発という性質上、工数(みんな大好き人月計算)と納期との戦いになり、本質的な価値に繋がらない部分に大きなコストをかける必要が多いことに「ぐぬぬ〜」と日々感じる生活をしていました。

自分も含め、環境を変えようと頑張っている人が少なからず存在してはいたものの、社内にも社外にも色々としがらみがあったりして、やはりそう簡単には変えられないのが実情で。

年齢もそれなりになってきて、「このままでいいのか?」と改めて考えた結果、受託開発ではない、 自社サービスを提供している環境で働いてみたい!という思いから転職することにしました。

「〜が悪い」「〜がイヤ」というよりは、会社の目的と自分の方向性がマッチしなくなった、という感じかも。

勉強会に参加するようになったり、Toyama.rbをはじめて違う世界の人に話を聞く機会が増えたりしたことも大きなきっかけになったと思います。

ただ、前職では自分の近くで一緒に仕事をしていた皆さんは良い人が多く、特に最後の上司は現場が自由に動けるよう尽力してくれていました。

そのおかげで通常では難しいような挑戦的な技術選定を行うこともできたので、今のスキルセットに繋がっている部分もあり、とても感謝しています。

リモートワーク

やりたいことをやろうと思ったら、さすがに地元で探すのは難しく、リモートワークという手段を取る必要があった、という感じです。

あくまでも、ちゃんと自分とマッチする会社だろうか?というのを最優先に考えていたので、その上でリモートワークができる会社が無かった場合は転職は諦めていたかも…

現在のところ良い環境に来れたと思っているので、この時の考えは間違ってなかったな〜と思います。

肝心のリモートワークですが、過去にソニックガーデンの倉貫さんにお話を聞いたり、なぜかToyama.rbに多数のフルリモートワーカーがいて相談し放題で何となくイメージできたり、という恵まれた状態だったこともあり、それほど心理的抵抗もなかったです。

いろんな人から「運動不足になるよ〜」とか「体に気をつけて〜」と言われることもあるのですが、冷静に考えると、もともと運動不足なのであんまり気にしてませんでした。 (リモートワークとはまた別の問題として運動しなければいけない、という気持ちはある)

実際転職してみて

今までと一番違うなと思うのは、全員がちゃんと作ってるものの価値とエンドユーザのことを考えているな〜という点。

受託開発の場合も「お客様の価値を〜」みたいなことを聞く機会もありましたが、まあ正直ほぼ綺麗事を並べているだけで、実際は納期までにいかに納品して検収を終えて利益をあげるかが一番重要だったのではないかと。

今の環境では、たとえばボタンの文言1つを決めるだけでも、それが必要なのであればちゃんと時間をとって議論しよう、という姿勢はいいな〜と感じます。

技術的な話をすると、「レベル高くてやべー!」と日々ひぃひぃ思いながら仕事してる感じ。

残業はほぼゼロなのですが、かなりスピード感があるので、1日働くともう十分疲れます。

個人的には一気にレベル1に戻った気分ですが、それがつらいということはなく、学べることも多くて楽しく働けてると思います。

内容的には、それなりに使えるフロントエンド側の知識をメインに頑張ってますが、逆にいうとそれ以外が相対的に一気に微妙なレベルに落ちた感があるので頑張らないとな〜という感じです。

うん…がんばろう

というわけで

今後もToyama.rbを続けつつ、心機一転頑張っていくのでよろしくお願いします。

(リモートワーク関連でも何かイベントとかできたらいいな〜)

Toyama.rbのロゴを作ってみた

Toyama.rbのロゴがない問題

Toyama.rbを1年以上続けていて、ロゴがないことがずっと気になってた。 管理用のリポジトリでもこんなissueが立っていて、1年以上放置されてたという・・

f:id:mugi1:20170226220158p:plain

ロゴって大事

でもやっぱ、ロゴって大事だな〜と今更改めて思い始める。

  • 「ちゃんと活動してるコミュニティ」感が出せる
  • Doorkeeperとかでパッと見つけやすい
  • ステッカー作ってmacに貼ったりしたい

お隣石川県で活動されているkanazawa.rbでは、とてもカッコいいロゴが用意されていて、いいな〜と思ってたのは秘密。

(以前参加した時にステッカーを貰って、Toyama.rb主催者にも関わらず嬉しくて今でもずっと貼ってるという)

どうやってつくる?

プランはいろいろあった。

f:id:mugi1:20170226222803p:plain

地元でなんとかしよう作戦

うっすら思ってたのは、「ずっと続けてればデザイナーの方とか参加してくれたりするんじゃないのか?」とかいうもの。

ただこれにはいろいろと問題が。

  • デザイナーの方が参加される気配はない
  • というかタダでやってもらおうなんて考えはそもそもプロに対して失礼
クラウドソーシングで依頼する

クラウドワークスランサーズのようなサービスを利用して、有償で依頼をかけてみたらどうか?というもの。

参加費で徐々に積み立てていって、そこから捻出すればいいかな?という考え。

結果としては、基本的にほぼ毎月収支0で運営しているような状態なので、運営費からの捻出は難しいかな〜?といった感じ。

(私の自腹は最終兵器)

私が描く

最も手っ取くかつコストがかからない方法。

ただ、自分は以前にとある事情から、某社のマスコットキャラクターのデザインをしてしまい、絶望的な仕上がりになったという前科がある。

が・・・、まあもう細かいことは言ってられない!

描く

描くことにした。

ツール

任意の大きさへの拡大や縮小なども考えると、ベクタ画像をいい感じに生成できるものがいいかな〜と思い、Sketchを使った。結果としては、直感的で非常にわかりやすかった。

Illustratorなどのほうが機能的には優れているっぽいけど、本気デザイナーではない私にはすぐに使いこなせるとは思えず、わかりやすさのほうが重要。

どんなデザインにするか

まずは富山っぽいものってなんだろう?と考えてみた。

  • チューリップ(県花
  • 県自体の形
  • ます寿司
  • ブリ
  • 黒いラーメン

複雑なデザインは無理だと思うので、ある程度シンプルなもので、かつ富山っぽいもの。

見た目も良さそうで、シンプルに作れそうなものということで、ひとまず

  • チューリップ

を採用

作ってみた

アイコン的なもの

f:id:mugi1:20170226232229p:plain

名前入り

f:id:mugi1:20170226224951p:plain

自分でいうのもあれですが、割といい出来になったと思う。妻にもいろいろと意見を貰い、最終的にこの形に落ち着いた。

(始めたら意外と楽しくて、試作して捨ててみたいなことを繰り返してた結果、6時間ぐらいやってたという)

それなりに好評

Toyama.rbのslackで流してみたところ、それなりに好評だった。

f:id:mugi1:20170226230455p:plain

改良

いい感じだ!ということで、ここから改良を重ねる。

そして翌日。

試行錯誤の末

完成したデザインがこちらになります。

f:id:mugi1:20170226230646p:plain

大人気

f:id:mugi1:20170226231007p:plain

どうしてこうなった

私にも良くわからないが、「BURIRuby食ってるVerも作ってみたらどうなるか」という謎の衝動に駆られて作ってしまった。

アンケート

そうはいってもこれはダメだろ!という意見もあるかと思い、一応先に作ったチューリップバージョンと比較して、どっちが良いかアンケートもとってみた。

さすがにBURIは面白いけど、ロゴとなるとチューリップがいいよね〜

結果

f:id:mugi1:20170226231458p:plain

f:id:mugi1:20170226231520p:plain

かくして

f:id:mugi1:20170226231800p:plain

ロゴ完成!!

今後

ステッカーを作って、完成後は参加者に配りたい。 (BURIはちょっと・・・という方もいると思うので、チューリップverも多少は用意しようかと思う)

今後ともToyama.rbをよろしくおねがいいたします。

TDDBC Toyama 参加(と主催)してきた

こんなイベントに参加&主催側として色々やってきた。

tddbc.connpass.com

TDDBCとは

TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。

各地のコミュニティの方々が中心となって、全国各地で行われています。

(http://devtesting.jp/tddbc/ より引用)

Toyama.rbにも頻繁に参加してくれている @hikaruworld さんが中心となり、@kunitooさんと私で手伝うような形で準備していて、この土日に無事開催できた。

特別ゲスト

@t_wada 氏。もうこれ以上無い完璧なゲスト。
個人的には「えっ、まじで!?あの@t_wadaさん来てくれるの!?」って感じだった。

会場

秀夢木楽館

www.airbnb.jp

この会場がすごかった。

  • 5階建
  • 一棟丸々借りれる
  • 立派なキッチン
  • カトラリー使える
  • コーヒーメーカー使える
  • セミナールーム的な空間もある
  • 全体的にオシャレ
  • 木の雰囲気がいい感じ

こういうイベントのために存在してるんじゃないのってぐらいの会場だった。問題があるとすれば、一定の人数がいないと借りることができないというのがあって、たとえばToyama.rbで毎月借りれるような会場ではない。

TDDBC - Day1

@t_wadaさんによるライブコーディング

FizzBuzz問題を題材としてTDDを実践した場合の例を @t_wadaさん自らがライブコーディングしながら解説。

とても印象に残ったのは、「テストを減らす責任」という部分。

仕事のなかで “テストコード”, “TDD” といった文脈で会話をするときに中心に挙がるのは

  • テストを書く文化をどう根付かせるか
  • テストをうまく書くにはどうするか
  • 効率のよいテストはどう書けばよいか
  • テスト駆動をするためには何が必要なのか

みたいな、「テストを書く」といった部分にフォーカスすることが多かったように思う。

今回 @t_wada さんが言っていたのは、私の理解では以下のような内容。

  • 実装者以外がテストを消すことは心理的な面でも非常にコストが高い
  • 対称性の無いテストコードがあると、後から見た人には「意味があって非対称」「意味なく非対称」の区別がつかない
  • 実装者であればそこの判断がつくため減らしておくことができる

書くことも大事だけど、書いていく過程でテストコード自体もリファクタリングをしていき、テストコード自体が負債とならないような意識を持つことも大事だな〜と感じた。でもこのあたりは、いかに芯を捉えたテストコードを書けるか?ということにも繋がってくると思うので、経験と勘も必要になりそうだ・・。自分はまだ修行が足らなそう。

ペアプロで実践TDD

  • テーマ「セマンティック・バージョニング」
  • “1.4.2” といったバージョン情報を取り扱うクラスをTDDで徐々に拡張していく
  • 言語ごとにわかれてペアプロ
  • このときはjsで参加した

デモ

主催者側ということで、問題のさわりの部分のペアプロの雰囲気を @kunitoo さんと二人でデモをした。色々と困惑するような雰囲気も含めて全部デモとして伝えればいいでしょ!とか思ってたら、本当に細々と困惑して期待通りの結果になった。

  • 反省 : 事前に用意した不要なサンプルコードは邪魔なので消しとくべきだった。

ペアプロよかった

仕事ではまともにペアプロというものを経験する機会がなかったので、若干緊張していたのは秘密。

「ペアでやったからといって効率が落ちるわけではない。むしろ上がることもあるよ。」みたいな話を聞いたことがあったけど、実際やってみると確かにその通りだった。

一人だとついつい細かいところを考えすぎて手が止まっちゃうところで、二人でやっていると不思議と「とにかく前に進めよう」という気持ちになる。

ただ、これも噂に聞いていた通り、死ぬほど疲れるというのも事実だった。 逆に言えば一人のときに短時間でそこまでは疲れないので、「実は自分ってそんなにパフォーマンス出せてないんじゃないの?」という気持ちに。

教える学び

どちらかというとペアの方と自分とでは、自分の方がjsに関するノウハウは持っていて、教える側に回ることがちょくちょくあったけど、これは教えてる側も思考が整理される行為だった。

どこかで聞いたようなワードだけども、うまく教えるためには教える側がしっかりと理解していることが前提条件になってくるので、逆に自分がフワっとしてる部分も現実として突きつけられたりしてた。 (整数判定で自分が Number#isIntegerを思い出せなくて絶望したりした)

夜の部

なぜか尋常では無いご馳走が振る舞われた

  • ぶりしゃぶ

  • ぶりとふぐ

  • 乾杯

  • カワハギの肝

特にカワハギの肝が半端じゃなかった。

これを醤油に溶いてブリつけて食べたら、もう美味すぎて死ぬかと思った。
富山県民でよかった。
(ご用意していただいた @nagise さん、ありがとうございました)

Hololens

持ってきた方がいらっしゃったので、MicrosoftのHololensを体験させてもらった。

壁を認識しているようで、空間に映し出されているオブジェクトやウィンドウが、綺麗に壁に沿って配備されるのがなんだか不思議。

操作感としては、個人的には難しく慣れが必要だな〜と感じたけど、色々な可能性を感じるガジェットだった。

寝不足

色々と盛り上がってしまい、AM4:00まで起きてて完全に寝不足。

でも楽しかったし満足も多いので、まったく後悔はしていない。

でも寝不足。

TDDBC - Day2

ダメコード鑑賞会

二日目の朝は、まずはウォーミングアップということで、とある非常に強烈なダメコードを皆で鑑賞しながら、好きに喋ってみようみたいなことをやった。

途中、"&&“ と三項演算子が入り混じったコードがあって、全体的に「え?これって結果どうなるんだ・・?」みたいな議論が起きた。

ただ、肝心なのは「そもそもこういう議論をしないためにもちゃんとやろうね!」というところだな、という認識を改めて確認。

実践版リファクタリング&機能追加

あらかじめ用意されている Java/C#/Javascript/Ruby/PHP のサンプルコードを利用して、リファクタリング・機能追加をTDDを交えながら実際に体験。

サンプルコードについては極力言語差異が無いように、

  • 構造は同じ作り
  • 変数名も完全に同じ
  • 結果は標準出力のみ

といったものを事前に用意。

さらにいえば、

  • 実装漏れとなっている部分も同じ
  • バグも同じ

といった状態。

これは、Toyama.rbのもくもく会を使って用意した。
PHPのみに関しては事前に用意できず、1日目の夜の部のときにPHP希望者の方にご協力いただいて作成。(感謝)


余談として、Toyama.rbもくもく会では最初に「今日やること」を宣言しており、この時の私の宣言は「今日はJavaでクソコードを書きます」だった。もはや自分でも何を言っているのか解らなかった。


さらに言うと、クソコード作成中は「綺麗なコードですね。ダメです。」みたいなワードが飛び交っていて、カオスな雰囲気が実に良かった。

既存問題にどう立ち向かうか?

テーマとしては、

  • すでに存在しているコード
  • テストはない
  • 仕様もない

みたいなものにどう立ち向かっていけば良いのか?というところだったと思う。

アプローチとしては、まずは全体のアウトプットをテストするコードを用意し、内部を変えた場合にブラックボックス的に問題が無いことを維持できる状態を作っていた。

あとは、「機械にやらせる」というワードも覚えときたい。

@t_wadaさんも含め、ガンガンIDE(WebStormとか)の機能を駆使している光景が良く目に入ってきた。当然といえば当然だけど、確かに手でやるより安心してやれるわけだし、使えるもんは使った方がいいよね。

既存バグの恐怖

サンプルコードを用意した側としては、本音を言うと軽い気持ちでバグを仕込んだものの、これが参加者に対して「既存コードのリファクタリング中に既存バグに出会ったらどうするか?」を考える良いきっかけになった。

というか仕込んだ私自身がどうしたらいいか悩んだ。

悩みどころとしては

  • バグも含めて既存実装なんじゃないの?
  • いやいや仕様が明確なんだから直すべきでしょ

という点。
明確なゴールが定まっている場合にはテストを書いて修正する方法もあるけれど、そうではない場合は難しいこともあるし、こればかりは状況に応じて判断する必要があるようだった。

参加してみて

学べた

実に学びが多かった。

Toyama.rbでも「手を動かしたい!」というのは前から言っていて、今回もゴリゴリに手を動かして参加するイベントで、実際に何かが身についた感がある。

次は実践

「TDDはスキル」という言葉も印象的だった。

一人でも、まずは小さいところからコツコツやっていこう。

というわけで

参加者の皆様、そして @t_wada さんありがとうございました。

@hikaruworldさん、@kunitooさん、おつかれさまでした!

無線ルータをASUS RT-AC68U に変えたら色々改善された

昨年に家を新築したのですが、その際に無線ルータを新調しました。

その際に購入したのはBuffalo製の以下のものです。

buffalo.jp

3階建でもいけるよ!!みたいなことが書いてあったのと、Amazonなどでも売れ筋っぽかったので乗っかって買ってみたんですが、これがまた微妙でした。

  • 2階に設置して、1階にいると回線強度が弱い
  • 結構切断される
  • 速度が安定しない

wifiをOFF→ONとして再接続するとリカバリーすることが殆どでしたが、すぐに何かを確認したいときに切断されてたりすると、やっぱりイラっとするもので。

HPにはビームフォーミングがどうのこうのとか記載がありましたが、1年使ってみても、まったくそれらしい恩恵を感じることはできませんでした。

というわけで

無線ルータを買い換えてみました。

買い換えたのはこちら。

www.asus.com

知り合いからの情報やネットからの情報でも、比較的ASUS製のルータについては評判がよかったので、信じて購入してみた。

結果として、これがすごい良い買い物でした。
もともと抱えていた問題が全部解決。

  • 設置してからひと月くらい経つけど、一度も利用中の切断がない
  • 家中どこでも接続が安定している
  • オンラインの計測などでは、2〜3倍程度の速度に

今までの一体何だったのっていうレベル。

強いて欠点をあげるとすると、本体の大きさでしょうか。
存在感が半端ではないし、それなりに重量もありました。

我が家の場合は、2階の家族は使わない部屋(=私の書斎)の片隅に設置してあるので、大きさはそれほどデメリットにはなりませんでした。

5GHz帯と2GHz帯でSSIDを分けることができるので、スマートフォン類は2GHzに接続し、PCやChromecastなどは5GHzと、接続を分けています。

さらに使っていて驚いたのが、管理機能の速さ。
管理画面もサクサク動きますし、再起動もかなり速いです。

地味な部分ではありますが、こういうところも大事ですね。

無線ルータでなにを買おうか悩んでいる方にはおすすめです。

雑記でした。

社内ハッカソンを開催&参加した

あけましておめでとうございます。

年明け前の2016年の12月に、土日を利用して社内ハッカソンが開催され、 主催側として色々やったのと同時に、エンジニアとしても参加してきました。

中小SIer的な会社なこともあり、 「ハッカソン・・なにそれおいしいの?」 といった雰囲気も当初は漂っていましたが、なんだかんだいって上手くいったと思います。

事前準備

そもそも「ハッカソンやりたい!」といっても、課題がたくさん。

  • お金はどうすんの?
  • 平日?土日?
  • 会社の許可降りるの?
  • そもそも人集まんの?
  • etc...

解決のためにしたこと

  • 話自体は早めに進めた
    • ・・と思う
    • 会場とか予算とかは早めに
  • 初回なので規模は小さめにした
    • まずは1回うまくいった例が欲しかった
  • ホームページをガチで作った
    • 本気でやるからな!!という雰囲気を醸し出す

正直、「いらん根回し無しでスパっとやらせてくれよ!」と思っていた部分もありますが、まあ社風というか、言っても仕方ないし、それがやらない理由にはならないので地道に・・

私個人としてはホームページ作成を担当しました。 終了後のアンケートで「ホームページがかっこよかった」的な感想をいただけたので、うまいことガチなことが伝わるように作れたようです。

(ちなみにデザインにはMaterializeを使ってみました)

その他の部分は会社の先輩が尽力してくれたのがかなり大きかったです。感謝。

最終的には、土日開催で15人ほど集まりました。

つくったもの

チーム内にいたAWSに詳しいメンバーのアイデアで、AWSの操作をSlackから行うためのChatBotを作りました。

特徴としては

  • AWSの操作をSlackから行える
  • Serverless(AWS Lambda)で作る

2日間(作業時間は1日強ぐらい)で、EC2インスタンスを一通り操作できるところまで作れました。

(ミスを超煽って来るBOTの図) f:id:mugi1:20170108233126p:plain

serverlessで結構ハマりました。

というか、webpack+ES6+Babel+serverless の構成にしたときに、ビルドが通らなかったり、人のデプロイとぶつかったりして、コーディング以外の部分で結構つまづきました。

このあたりは事前準備が足りんかった。

感想(主催側として)

募集用のホームページや、開催終了後のレポートページを本気で作ったのは良かったように思います。(自分が作ったこともあるのでそう言っておきたいという節もありますが・・)

こういうイベントって、ノリや勢い、雰囲気といったものも重要だと個人的には思っています。 そういった部分を煽るためには、目立つ部分になるホームページなどをきちんと整備したのは正解でした。

また、長らく社内全体として技術への姿勢や考え方について課題があるな〜と思っていましたが、こういったイベントをやってみたことで、「お?意外と捨てたもんじゃないぞ?」という面があることにも気づくことができました。

ハッカソンを通じて普段接しない人と関わる機会が生まれたのも大きい要素だったように思います。

感想(参加側として)

事前準備が甘かった

個人的にはこれに尽きます。

テーマ自体は事前のアイデアソンで決まっていて、チーム内でフロントエンド部分の知識をある程度保有しているのが自分だったので、「ビルド環境などの整備はまかせてください!!」的なことを言っていたにも関わらず、そこそこつまづいてしまいました。 ルール上許可されるのであれば、コードを書く以外の不安要素はできるだけ取り払っておくべきですね。

すげーつかれた

仕事とは違う、なんともいえない疲労感がすごかったです。
達成感のある気持ちのいい疲れではありましたが、月曜日のパフォーマンスは正直落ちてた。

自分たちのスキルがわかる

うちみたいな会社ではよくある話なのかもしれませんが、 「結局だれがどのスキルをどの程度使えるのかがわからない」という問題をよく聞きます。

ハッカソンのようなイベントの場合、強制的にスキルを発揮しないといけないかつ、同じ時間の作業かつ最終的なアウトプットが存在するので、とてもわかりやすいんですよね。

経歴書などを書かせるよりもよっぽど正確なことが把握できるのではないでしょうか。

というわけで

機会があれば社外のハッカソンとかも参加してみたいな〜。

今年は色々と大変になりそうだけど、がんばるぞー!