2017年のふりかえり
これまでやったことありませんでしたが、いろんな人がふりかえりをされているのを見て気が向いたので気が向いている内に1年を簡単にふりかえってみます。
2017年ふりかえり
今年はなんといってもモブプログラミングな年でした。
おかげさまでたくさんアウトプットする機会をいただいたり、イベントやモブプログラミング現場体験会などを通していろんな人と出会うきっかけができました。
こういった活動が継続できているのも、お仕事がうまくいっている＝価値につながっているからこそです。モブプログラミングを通して、ずっとやりたかった大きな会社でのリーンスタートアップがようやく形になり、役割やしがらみを越えて少しずつ事業を成長させることができてきました。
飽きるまではもう少しこの活動は続けていこうと思いますので、何かあればお気軽にご用命ください。
インプット
来年はさくっと出せるように読んだ本とかまとめておこうと思った。
アウトプット
- 社外発表 15回
- ブログ記事 5本
- ブログ 2本
- Qiita 3本
- 執筆 1回
2017/1/12 Regional Scrum Gathering Tokyo2017【発表】
非常に珍しく体調を崩して高熱が出ていたのであまり覚えていない。
2017/1/28 DevLOVE 199 越境CON 【発表】
その場でLTをつくるいつもの芸。
2017/4/5 モブプログラミングを実際にやってみた【Qiita】
モブプログラミングをはじめるきっかけとなった記事。
2017/4/25 DevOpsDays Tokyo 2017【発表】
ある意味、黒歴史となったワークショップ。
- モブプログラミングワークショップ
- 朝まで生DevOps（パネルディスカッション）
2017/4/26 Azure FunctionsでサーバレスにさくっとHipchat通知してみる【Qiita】
サーバレスうはうは。でも今ならFunctionすら書かずにLogic Appでどうにかしそう。
2017/5/25 アジャイルチーム未来会議【運営】
2017/6/18 DevLOVE 200 Bridge【発表】
おかげさまで8万PV（2017/12/29現在）です。
2017/7/11 モブプロディスカッション【運営・発表】
楽しかったなー！
2017/7/21 DevLOVE関西「心理的安全性」のことに思いを馳せる【発表】
関西すごい！また行きたい。
2017/8/25 Geeks Who Drink in Tokyo-Agile Team Edition-【発表】
2017/8/25 追われる開発と追う開発【ブログ】
2017/9/10 モブの宮【発表】
2017/9/16 XP祭り2017【発表】
2017/10/28 Rakuten Technology Conference2017【運営】
2017/11/2 Microsoft Serverless Hackfestにモブで参加してきた！【ブログ】
2017/11/8 エンタープライズアジャイル勉強会【発表】
2017/11/12 DevLOVE リンスタ関ヶ原 〜敗軍の将、兵を語る編〜【発表】
2017/11/16 ヴァル研究所ライトニング大会【発表】
2017/11/18 JJUG CCC 2017 FALL【ワークショップ】
2017/12/11 アジャイルひよこクラブ 結局スクラムってなんなの？日本のパイオニアから学ぶアジャイルの歴史【発表】
2017/12/22 WEB+DB PRESS Vol.102【執筆】
2017/12/25 Azure Bot Service ✕ Cognitive Servicesで英語に翻訳するChat Botを作ってみる【Qiita】
2018年の抱負
来年はさっそくRegional Scrum Gathering TOKYO 2018とDeveloper Summit2018で登壇させていただきます。
あとはこっそり海外イベントでの登壇もやってみようかなーと思っています。
来年はもう少しエンジニアとしてのアウトプットを増やしたいなーと思っているのと、ブログや執筆にもチャレンジしてみようと思います。
ちなみに来年は社会人10年目の年になります。 同じ会社でずっといるのですが、サービスや部署が変われば転職したのと同じくらい変化がある会社なので2〜3年に一度は変化を体験しているのと、常にやりたい挑戦に挑んでいるんで飽きずにここまできました。
ただ、それはそれでリスクかなーと思っているので去年くらいから 転職 は真剣に考えています。 ところが最近重要な問題に気付いたんですが、常に今がピークな自分なのでネガティブな理由でやめることがないことができません。今も今までで一番いいチームで今まで一番いい仕事をしています。
ということで、引き続きおいしいお肉とおいしいお寿司を募集しております！！
俺のコードレビュー勉強会を開いてみた【勉強会ふりかえり編】 #devraku
2014年11月5日に俺のコードレビュー勉強会を開催しました。
オープニング資料はこちら。
ライトニングトーク資料はこちら。
当日の様子もまとめました。
Why
とあるサミットで感銘を受けたプレゼンを社内で勝手に再演した際に、
「こんな活動をやってる人が社内にいるなんて知りませんでした。」
と言われたことが今思い返すときっかけでした。
その再演の際、まったく意図はしていなかったのですが、再演後にチームに共有するついでに声をかけた他部署のメンバーを巻き込んでアツいディスカッションが生まれました。
再演をやってよかったなーと思うと同時に、せっかく同じ社内にいるのにすぐ手をのばせば届く人やノウハウにたどり着いていないことが本当にもったいないと感じました。
そこで起きたアツいディスカッションをもう一度意図的に起こしたい、という想いをこじらせて今回開催に至りました。
What
聴衆型の勉強会は社内外に多いので、今回は対話型の勉強会にしました。
Where
テーマ的にセンシティブな内容を含む可能性が強く、そこを気にしてディスカッションをシュリンクさせたくないので今回は社内勉強会として開催しました。
Who
今回の勉強会でメインターゲットにしたのは、勉強会や本などからインプットしたことを現場で実践する・実践しようとする人たちです。
How
コードレビューをテーマにしたライトニングトークを募集。
当日なぐりこみOKで特にとりまとめもせず、当日集まったものを順番でLT。
ライトニングトークを媒介に場を盛り上げた後は、Scrum Master's Night形式のディスカッションを採用（この形式の勉強会をやってみたかった）。
テーマであるコードレビューについて話したいトピック・聞いてみたいトピックを付箋に書いてもらい、内容を説明しながらホワイトボードに貼っていってもらう。
出尽くしたところで、「これいいな！」と思ったトピックにドット投票をしてもらい、票の多いトピックから時間の許す限りディスカッションする形式で進行しました。
ふりかえりKPT
Keep
- 「極力楽に運営する」という姿勢をスコープとして固定した
- 各地方拠点（北海道・仙台・大阪）とスムーズにやりとりができてよかった
- 想定よりもディスカッションがかなり白熱した
- 勉強会に出て「持ち帰りがあった」割合が多かった
- Tryにできるコードレビューパターンが多く見つかった
- 運営者が一番楽しんだ
- Tech Talkとのコラボレーションができた
Problem
- ライトニングトークに時間制限がなかった
- ちょっと終了時間が押してしまった（盛り上がったからだけど）
- ふりかえりのアウトプットを形として残せなかった
Try
- さんま力（トークファシリテーション）に磨きをつける
- ワールドカフェ形式でふりかえりをアウトプットする
やってみてどうだったか
Learn（学んだこと）をGenba（現場）に活かすことができることが理想です。
基本一方通行なインプットをする機会は多く存在するため、今回はそこで学んだことを実際に現場で実践する部分をターゲットに勉強会を開催しました。
いきなりそんなにうまくはいかないだろうと期待はしていなかったのですが、予想以上に議論は白熱してとてもいい勉強会になったと自負しています（内容自体については別記事で紹介予定）。
ライトニングトーク中は聞いてるだけで大人しかった参加者のみんなも、自分たちの現場のストーリーを話しだすと饒舌になっていました。よくよく考えてみると、そもそもみんな想いを持っているから集まっているのであって、それを出し合う場・仕組みをつくってあげるだけで盛り上がるのは当然でした。たったの2時間あまりの時間で、本当にたくさんの学びがうまれました。
こんなに楽なことはない！
久しぶりに運営して心からよかったと思える勉強会になりました。
社内外に関わらず得た学びを現場で活かす。
それを現場同士で結びつけて、次の学びにつなげる。
具体的に言うと、Tech Talkや社外の勉強会でみんなが得た学びを現場で実践した頃合いを見計らって、お互いの事例を今回のような場を設けて共有し合う。もっといい現場改善につながり、それを成果としてTech Talkや社外の勉強会で発表してもらう。
この学びのフィードバックループがぐるぐるまわりはじめると、面白いことになるんじゃないかとワクワクしています。
でも期待しません、勝つまでは。
ということでやってよかったので、今回MVPでTryしてみた勉強会をDev楽と銘打って不定期でまわしてみようと思います。
無理をしない・楽をする、そして最高に楽しいがモットーなので、Continuousなペースでの開催になりますが、盛り上げてくれればすぐに調子に乗るタイプなので、取り上げて欲しいテーマがある方はのせてください。
また、無理に社内に閉じようとは考えていません。ぜひ機会があれば一緒に胸ぐらつかみ合って学びましょう。
楽にいこうぜ！
レガシーコードについて考えてみた #wewlc_jp
レガシーコード改善勉強会 in東京 - パスマーケット に参加しています、なう。
勉強会出ててくる内容（キーワード）や雰囲気はハッシュタグから追えると思いますのでぜひ！
参加レポートではなく、せっかくなので勉強会のテーマの “レガシーコード” について個人的な想いをつらつら書いてみます。
レガシーコードってなあに？
- レガシーコードとはテストのないコードである
というわかりやすい定義もありますが、
- 仕様がわからないコード
- 意図がわからないコード
- 読めないコード
といった主観的なイメージもよく聞きます。
定義としてレガシーコードとはなんなのかはともかく、上記に書いたようなコードはどれも無いほうがうれしいし、あったとしたら減らしていきたいものです。
【余談】このあたり読むと面白い！
レガシーコードとの遭遇
今までの自分の経験では、コードが存在するところには（程度の違いはあるけど）必ずレガシーコードが存在していました。
仮にレガシーコードが存在しないステキな環境があったとしても、半年後に自分の書いたコードを覚えてなかったりするので明日レガシーコードが存在している可能性はあるでしょう。
ってことは、スタートアップだろうと保守運用だろうと自社開発だろうと受託開発だろうと、レガシーコードとどう向き合っていくかはエンジニアやっている限り切っても切り離せないものなのかなーと思うようになりました。
よくあるレガシーコード
今までレガシーだなーと思ったコードを思い出してみました。
- メソッドでやりたいことがわからない
- インデントや条件が複雑すぎてどうやったらそこを通るかがイメージしにくい
- メソッドが大きすぎてテストコード書こうにも複雑すぎる
- AメソッドとBメソッドそれぞれでは問題なさそうだけど、設計に統一性がない
- 変更部分にしか注意がまわっていない書き方をしている
- 歴史を感じるくらい人によって書き方がバラバラ
- そもそもシステムやテストの設計方針がない
- とにかくわけがわからない
思い返してみるとこれらの共通点は、
- テストコードが存在しない
でした。
もちろんテストコードがあればいいってわけじゃないけれど統計的に！
レガシーコードができそうなにおい
今度はコードレビューしていてレガシーコードになりそうだなーと感じた瞬間を思い出してみます。
これらを見つけた時に聞いてること。
- メソッドが長い
→「このメソッドの目的ってなに？」
→「このメソッドテスト書いててつらくなかった？」 - インデントが深い
→「ここ通るときの条件を教えて！」 - 条件文が複雑
→「この条件文を文章で説明してほしいなー」 - メソッドからreturnするパターンが多い
→「このメソッドのreturnのパターンを教えて！」
コードを書かない時にもレガシーなにおいを感じるタイミングはあります。
- 説明が不安そう
- 仕様理解があいまい
- タスク自体のDoneの定義があいまい
- （項目・コード問わず）テストが書けてない
- 本人がぱつってる
こんなときはあやしいですよね。
レガシーコードとどう向き合ってきたか
もちろんこれまでにレガシーコードを見てイラッ☆としたことはたくさんあります。
でも前任者だけでなく自分自身もレガシーコードを生む可能性があることに気づいてからは、それほどネガティブな感情を持たなくなりました。
でも、そこでネガティブな感情をもって立ち止まったら、自分自身も同じようにレガシーコードを生んでしまいます。それはレガシーコードに負けた気がするし、自分自身もまた加害者になってしまいます。
だから、
状況次第でなかなかリファクタリングできない・進まないことはあるかもしれないけど、少なくとも増やさないようにして少しずつ減らしていこう
ってことを考えるようになりました。
今後レガシーコードとどう向き合っていくか
今後以下の2つのアプローチを考えてます。
- やってきたことをアウトプットする
- 知識をインプットする
1. やってきたことをアウトプットする
レガシーコードと向き合うようになって、いろんな失敗を経ながらもどうにかレガシーコードを減らしてきました。
自分は本能で動くタイプなので、やってみたあとから、
「あのときやったことに名前・方法論があったんだ」
と知識がついてくることが多いです。
それはそれでいいと思うんですが、やってきたことを形式知としてアウトプットして知識に転換していくことがそろそろ必要だと思っています。
2. 知識をインプットする
アウトプットをする一方で、今なら効率よく知識をインプットできる気がするし、頭でっかちにならずに知識を経験に転換していくサイクルをまわすこともできるので、引き出しを増やせばもっとはやくもっと多くの改善ができるんじゃないかなーとわくわくしています。
考えるきっかけを下さった登壇者の皆様、運営の皆様ありがとうございました。
おわり！！
リリース手順書について本気出して考えてみた #CleanReleaseManual
社内でエンジニア向けのプレゼンをする機会があったので、リリース手順書について本気出して考えてみました。
手順書書くくらいなら自動化すればいいじゃん
もちろんそうです。
でも、まともなリリース手順書をつくれなければ、自動化されたリリース作業を行うことはできても自ら自動化することはできません。
自動化やContinuous Deliveryはもちろん大事ですが、自分と一緒にはたらくエンジニアには自動の前に考えてほしいことがあったのでプレゼンにまとめてみました。
新人の頃の教訓
この内容は、すべて自分が新人の頃にリーダーから伝えてもらったことです。
- 「変化前の確認⇒変化⇒変化後の確認」さぼらない
- 上から下までコピペでリリースできることが最低限
- リリース手順書には相手がいる
- 相手の事を思いやって書く
- 意図を持って書く
最初はなかなかうまく書くことができませんでしたが、新人の頃に癖づけることができて本当によかったです。
いろんな人のリリース手順書を見てきましたが、震えるような手順書には出会っていません。
たかがリリース手順書、されどリリース手順書！
リリース手順書に限らないコツ
このプレゼンのメインはリリース手順書ですが、そのコツは手順書に限るものではありません。仕事と作業を分けることを意識して大事な事に集中したいものです。
いろいろと賛否両論はあるかもしれませんが、すべて受け止めます。
ご意見ご感想はご自由にどうぞ。
ホウレンソウ、○○管理って本当に必要!?
とある先輩がメルマガと称して率直な意見をぶつけ合うメールを配信しているのを見ていいなーと思い、チームメンバーに同じことをしはじめました。
せっかくなので当たり障りない範囲でブログにも残してみます。
ホウレンソウ…
タスク管理…
スケジュール管理…
いろんな本・記事・プレゼンで語られているし、誰もが新人の頃に上司や先輩からうるさく言われた経験があります。
ひょっとしたら無条件で『必要だ！』と教えこまれてきたかもしれません。
でも、本当に必要なんでしょうか？
私はなくてもうまくいくならばいらないんじゃないかと思います。
コミュニケーションコストだってかかるし、
管理コストだってかかるし、
時間だってかかるし、
かったるいし、
もし無くせるなら無くしたい！
その時間使って新しい機能つくってお金もうけたい！
その時間の分早く帰って合コンに行きたい！
って心から思います。
とはいえ現実的に考えると、やっぱりホウレンソウやなんとか管理は必要になってしまうことが多いです。それはなぜかというと他人とコミュニケーション無しで同じ方向へ進むのは難しいから。
「あそこに向かうぞー」（ホウレンソウ）って認識合わせたり、
「ちょちょ、そっちじゃない！こっちだよー」（なんとか管理）ってチェックしたり、
やっぱり必要になってしまう。
しかし、
（今必要である）＝（だから必ずやった方がいい）
（今必要である）＝（どこの誰にとっても必要である・なくすことはできない）
と考えてしまうのは思考停止です。
無条件で「必要だ！」「当たり前だ！」と思っていたホウレンソウやなんとか管理は、なくすことはなかなかできないかもしれないけど少なくとも減らすことはできます。
もし減らすことができたらもっと大事なことに時間が使えることでしょう。
普段やってる仕事の進め方を思い返してみて、
今やってる朝礼がなくなった時、
今やってるかんばんがなくなった時、
今やってるスクラムの儀式がなくなった時、
どうすればいいのか想像できないのだとしたら、それは何かに頼って思考停止してしまっているのかもしれません。
うまくいっている時ほど“当たり前”や“成功”の中身を疑ってみると見えてくるものがあるものです。
2013年をふりかえってみました
（DevLOVE現場甲子園打ち上げより）
2013年も残すところわずかとなりました。
毎年恒例の個人年間ふりかえりを行ったところ、2013年も多くの出会い・学びがありました。簡単ではありますが今年にふりかえりのほんの一部を公開させていただきます。
数値でふりかえり
- カンファレンス・勉強会参加 : 47
- 発表（社外） : 10
- スライド公開数 : 5
- ブログ投稿数 : 10
- KPT総ファシリテート数 : 73
- 読んだ本 : 30
- クリアしたゲーム : 12 ※神々のトライフォース2含む
- 回収したアニメ : 20
- 握手会参加数 : 1
KPTT
Keep
- 新しいチームも自他共認めるいいチームに変われた
- サービス（楽天レシピ）が大好きになった
- 年初に立てたチーム年間計画をクリアすることができた
- 2012年から2013年の1年にかけて個人的4大ドームツアー講演達成した
（Scrum Gathering、XP祭り、デブサミ、アジャイルジャパン）
Problem
- 業務内でエンジニアリングに携わる時間が減ってきた
- いろいろ計測してみたけど仮説の設定があまくあんまりいい指標ではなかった
- 大きなイベントが重なって継続的でなかった
- Agile2013のセッション通らなかった
- 出世払いが増えてきた
Try
- 業務外でエンジニアリングする（内容は決めてあるけど濁します）
- 1年を通してのKPIを設定する
- ブログを月1以上書く
- 発表を依頼されるようになる
Thanks
To チーム・部署
新しい環境でも遠慮なくやらせていただきました。一緒にやってる仲間から「仕事が楽しくなった」「自慢できるチーム」といってもらえたのがなによりでした。もしかしたら賛否両論ある方もいらっしゃると思いますが、変化が起こっているということなのでそれもまた嬉しいフィードバックです。
サービスとしてもチームとしても今年は準備の期間と計画していたので計画以上に進めることができたので2013年としては優かもしれませんが、サービスとしての価値がうまれないとなんの意味もなさないと思います。遠慮したり安定させるのは大人に任せて、来年以降もこれまで以上に空気を読んで空気を壊して行こうと思いますので引き続きよろしくお願いいたします。
To 会社
ありがとうございました。
会社を変えてやりましょう！
To 勉強会・コミュニティ
たくさんの出会いと学びをありがとうございました。
現場を変えてやりましょう！
いろんな会社の若手エンジニアを収穫してきた！＠オブラブ収穫祭 #oblove
オブラブさん主催オブラブ収穫祭〜若手エンジニアの集い、実りの秋〜に参加してきました。
まずはいつもの・・・
フライングオラクルなう！ #oblove (@ 日本オラクル株式会社 本社) 4sq.com/Tn9j6q
— takao.oyobeさん (@TAKAKING22) 10月 13, 2012ギリギリ若手枠で参加中！ ： オブラブ 収穫祭 〜若手エンジニア、実りの秋〜 esminc.doorkeeper.jp/events/1746
— takao.oyobeさん (@TAKAKING22) 10月 13, 2012なぜ参加したか
主には以下の2つの視点で参加してきました。
- 同年代のエンジニアがどんな経験をしているのか
- 他社の新人教育制度はどんな感じなのか
私自身社会人4年目のエンジニア（ギリギリ若手枠：25歳前後）で、約1年前から勉強会等に参加するようになって他社の方と交流する機会が増えたのですが、自分より年上の方が圧倒的に多い印象でした。そんな時にこの会を知り、他社の同年代の人達がどんなことをしているのかのぞいてみたくなりました。
またこの4年間の間にメンター（新人教育担当）を何度かさせていただいた経験もあるのですが、他社がどのような教育を行っているのか教育側からのお話も聞けるいい機会だと思い参加しました。
参加者は若手エンジニアが過半数、教育担当者10数人、学生数人でした。
講演レポート
以下講演のポイントをまとめさせていただきます（ムラはご容赦下さい）
講演概要
- 各社新卒1〜2年目数名＆教育担当者の方の発表
- COOKPAD、paperboy & co.、DeNA 、GREE、永和システムマネジメントの順
- 井原さん（@ihara2525）
- 社長室エンジニアの方（教育側）
- 教育制度は基本的には無い
- やりたいことをやってもらうという方針
- 新人に求めることは、会社に何かをしてもらうのではなく会社を利用して何をするのか
- 遠慮は悪
- やりたいこと、得意なこと、やるべきことの重なる部分を見つける
- やる気がある人を集める
- やらせるのではなく、やりやすい環境をつくってあげること
発表スライド：How to Glow Up in COOKPAD
- 中村さん（@r7kamura）
- 2012新卒入社エンジニア
- 本人主義の中でどうやって強くなろうとしたのか
- 初日から自走、責任（本番権限）、成果
- 下手なコードを書くと全エンジニアから指摘が飛んでくる
- Githubの全てのdiffをチェックしていたらコードを書けるようになった
- 社内から得たものだけでは社内以上にはたぶんなれない
- 勉強会などの社外活動やオープンソースを通して社外からも情報を得る
- 自分自身も新しい知識（アジャイルなど）を社内で展開していく
- PM5:00を過ぎたらリファクタリングすることにしている
- 中尾さん（@shikakun）
- 2012年新卒入社デザイナー
- 大学時代に映画作り→他人とつきあうのはつらい→Web業界なら1人でも→入社
- デザイナーがいない部署に配属
- 1週間缶詰めで新人だけでサービスづくり（まめぶろ）
- サービス作りは盛り上がり、その後もコピー機の後ろでカンバン
- エンジニアに混ざってRailsを勉強
- shikakunアプリ公開中（shikakunのアカウントでTweetできちゃうアプリ）
- やってみると、誰かと一緒になにかをつくることは楽しい
- 黒瀧さん（@kurotaky）
- 2012年新卒入社エンジニア
- Nexus7を購入した際、宛名がBlack Waterfall（黒瀧）と送られてきた
- 新人研修でカスタマーサービス研修→人がサービスを使っていることを実感
- emacsを使わないと教えてくれない研修
- 一ヶ月でRailsをマスターする研修
- 社内のスーパーエンジニア達に箱詰めで教えてもらう（ドクターペッパー付）
- ひどいコードを書くとさらされる
- 問題が発生したらログを読む／エラーメッセージを読む／テストする
- サービスリリースしたらくす玉を割る文化
- 社内に意識本棚という意識が高い本が並ぶ本棚が存在
- 損失も負けじと意識本棚（お金がないので平積み）を実施中
- 後藤さん（@go_to_mo）
- 新卒2年目のエンジニア
- エンジニアを大切にする会社だと実感
- エンジニア研修をクリアしないとエンジニアになれない
- 新卒でもいい意見は採用される
- エンジニアもバリバリ企画にからむ
- 社内にすごい人がたくさんいる
- 自分よりすごい人がいないと成長が止まってしまう気がするのでいい環境
- 大事にしていることは次の3つ
- いい環境は自分でつくる
⇒うまくいく方法を自分で考える - 人のせいにしない
⇒成長しないし誰も得しない - 人にやさしく
- バイブルはリーダブルコード
リーダブルコード |
- 武部さん（@nuichi）
- 新人研修設計担当者（教育側）
- 日本でもトップレベルのエンジニア研修だと自負
- あるある一般的な研修
- 現場の負荷が高い
- チームやメンターに教育が依存してしまう
- 現場「やっぱり受け入れなきゃダメですかね？」
- DeNAの研修
- 基礎を終えましたではなく一流にする
- ポテンシャル採用なのでプログラム未経験者も多数
- 現場「待ってました！よく来てくれました！」
- 「東京大学に二度入学するよりも難しい（研修）」 via 研修担当者
- 「宇宙飛行士になる訓練よりは、少しマシ」 via 研修責任者
- ↑ざっくりな研修内容
- 研修する側が大事にすべきこと
- 育てることは生半可なことではない
- 現場がほしがる人材を育てる
- 吉川さん（@tsuyoshikawa）
- 教育側
- 社内テンプレをつかいなさいってアレ・・・orz
- メンターをつけて後はよろ！は現場の負担が大きい
- GREE Bootcamp （参考リンク）
- 基本的なGREEの開発の流れの習得
- 技術とマインドは切り離せない
- 教える側のスキルも向上させる（教える側の振り返り）
- 教育の基本は（自分が）もらったものを（後輩に）返して行くこと
- 露木さん
- 2012新卒エンジニア
- 今回が勉強会デビュー
- 入社前に思っていた会社像と大きく変化した
永和システムマネジメント
発表スライド：スキルアップ作戦
- 馬場さん（@kbaba1001）
- 2012新卒入社エンジニア
- 入社して感じていることはコードを書くスキルの向上
- Githubのpull requestに対して今週だけで146個のコメント
- 教えていただけることがありがたい
- コードを介したコミュニケーション
- 永和のGit Masterには変なコードは存在しない！
- 社内のコードを読むことで本とは別の知識を得られる
- 外部勉強会は正直めんどくさいと思っていた
- が、社内にはスーパースターばかりなので同じレベルの人とも出会えるいい機会
- 同レベルの人とのふれあいの中で教え合うことでレベルアップ
- 今の一番の課題は続けること
- 田垣さん（@akiinyo）
- 新卒2年目エンジニア
- プログラム未経験で入社
- 自分でWebアプリをつくれたらいいなーというあこがれで入社
- 入ってみるとそこは想像以上にわけのわからない世界だった
- 最初は動きそうなコードをコピペ（結局大量のコードを読むので勉強になった）
- キーワードでひたすらgrep
- おすすめは自分のPRJのコードをとにかく読むこと
- 最初は「テストを先に書くといいらしい」からスタート
- そうすると・・・実装しやすくなる、意識高いらしい
- やってみてもよくわからない、でもやる！
- 最初は仕事ができる気がしなかったけど今は少しだけ自信がついた
- pull requestするとはなまるマークやくじらさんの絵文字がもらえるようになった
- その世界の住人になりたいと思う気持ちがあれば大丈夫
- みんな受け入れてくれるし、楽しいことや嬉しいことがたくさんあった
- 諸橋さん（@moro）
- 10年目エンジニア（教育側）
- われわれはどうしてお金をもらっているのか考えることが重要
- 誰がお金をだしてくれているのか
- お金をもらうには、「ちゃんと仕事を終わらせる」「普通にやる」
- ちゃんと仕事を終わらせるにはアウトプットの意識が重要
- シンプルに議事録てアウトプット意識してもらう研修
- 報告することは自分の気持ちを伝えること
- 悪いニュースこそ早くいう
- チームであればたいていのことは解決できる
- 普通のことをふつうにやる
- 新人の子の発言「テスト書かないでどうやってコード書くんですか？」（純粋）
まとめ
大量採用への対応のために大きな仕組みづくりが求められているケースもあったり、会社の状況も様々なので教育に対する取り組みも多種多様でした。
しかしその中でも、
- どう成長してもらうかを本気で考える
- 状況によって教育も常に変化させていくこと
は共通事項のように感じました。
業界動向も最新技術も入ってくる人材も大きな流れの中で大きく変化していくため、教育もそれにあわせて変化していく必要があります。
本勉強会のように、他社のリアルな教育への取り組みとそれによる被教育者の成長を知ることができる機会はとても貴重だったように思います。
という真面目なまとめの後で個人的な感想です。
まずは同年代（よりもちょっと後輩だったかな）のエンジニアの皆さんが活き活きとなにより発表されていることが印象的でした。それを見ながら、
やっぱりプレゼンテーションはテクニックや名前じゃなくて、想いやメッセージや臨場感だのぅ。まー単純にそっちの方が好きなだけかもですが…
— takao.oyobeさん (@TAKAKING22) 10月 13, 2012なんて感じたり。
中でも個人的な今日一は、田垣さんのプレゼンでした。
プログラミング未経験で永和さんに入った新卒2年目エンジニアの女の子のお話、同じく未経験で入ったのですっげーわかるなあw（4年目だけど） #oblove
— takao.oyobeさん (@TAKAKING22) 10月 13, 2012私自身も未経験からのエンジニアスタートなので共感する点が多かったこともありますが、等身大で全力なプレゼンテーションがとってもすばらしかったです。
それにしても・・・
プログラム未経験で入った2年目の女の子が普通にTDDで実装してpull requestを送って絵文字のコメントをもらって喜ぶ永和さん恐るべしです！！
また個人的にうれしい出来事もありました。
勉強会に参加しながらまわりの後輩を連れてきたかったなーなんて思っていたのですが、
同じグループの新卒エンジニアの子を勉強会で発見！グループのエンジニアMTGで自分が行く勉強会や面白そうな勉強会をちまちま紹介していたのを見てきてくれたそう。こーゆーの嬉しいなー
— takao.oyobeさん (@TAKAKING22) 10月 13, 2012難しいことだけでなく、学びってこういう小さなところからつながっていくこともあるんですね！
