Shippio に入社していました
転職していました
6年半勤め続けていた前職を5月末に退職し、6月から Shippio という会社に入社しました。
Shippio | 貿易業務の可視化・効率化クラウドサービス
このたび8月末で無事試用期間が終わったためご報告です。
いつも通りなら入社した日に即、各所にご報告していたのですが、今回自分の中で大きなチャレンジ(後述)をしようと決めて入社したため、このタイミングでの報告になります。
今回の転職で重要視したこと
実は2021年は体調を大きく崩し、業務にうまくコミットできていなかったこともあり、自分の中で次のチャレンジの重要性が増していました。
体調は2022年の2月頃には軽快したのですが、自分が今後どういうことができるのか、どうやっていくのか、どうなっていくのか。たくさんのことを今回の転職活動の判断基準に選びました。
その中でも以下のことをより重要視しました。
世の中にインパクトがあることを事業にしていること
自分の仕事を通して何がどう世の中に影響しているかがわかりやすいこと
しかしこのことを重要視するとなかなか採用プロセスに進もうという会社に出会えませんでした。
今回転職活動をエージェントにサポートしてもらいながら案件を確認し、少しでも良いと思えた会社にはカジュアル面談をお願いするということを繰り返していました。
かなりの案件数に目を通したと思いますが、幸い現職に出会うことができ、更には入社することができました。
何が決め手だったか、何をチャレンジするのか
スタートアップということもあり無限にやることがある
事業と目的が明確
事業のための情報収集と整理の頻度と速さが抜群
整理した情報を元に UI/UX が良い形で実現されている
プロダクト開発における公用語が英語(non Japanese なメンバーがたくさんいます)
UI/UX については意思決定のプロセスやプロダクトの開発の上手さがモロに出る領域だと思っていたので特に重要視したポイントでした。
最後に大きなこととして英語を使う環境にチャンレンジできるというものがあります。
自分は正直英語は全く得意では無くコンプレックスだったのですが、今回自分のステップに合う形でのチャレンジができそう、ということもあり大きな決断をすることにしました。
英語に関しては @yoshiori が自分の周りで大きなチャレンジをしつつ頑張っているのを見ていたので、直接相談したりもしました。ヨシオリさんには今回の決断を大きく後押ししてくれたと思っているので、とても感謝しています。
最後に採用情報
Shippio ではあらゆるポジションで仲間を募集しています!
もし気になる方は気軽にお声がけください!!!!
ActiveRecord を使っていて NoMethodError: undefined method `new' for BigDecimal:Class と言われたら
ActiveRecord でクエリを実行した結果 BigDecimal 型のインスタンスを組み立てるようなものが含まれている場合、使っている Ruby のバージョンや他ライブラリのバージョン次第でこのようなエラーが出ます。
NoMethodError: undefined method `new' for BigDecimal:Class
先日詳細知らされていない状態でこのエラーを渡されたのでとりあえず調べてみると以下の Qiita の記事がトップに出てきました。
結論から言うとこの記事に書いてある対処方法は端的に言ってよろしくないのでやめましょう。
そもそもこのエラーが出る問題の原因として BigDecimal の扱いが、とあるバージョンから変わっているからです。 バージョンによる BigDecimal の取扱方の違いは README.md にちゃんと書いてあります。
前述の Qiita の記事の何が良くないかって、古いバージョンに固定して対処していることなんですよね。 しかもこうしろと書いてある。
gem 'bigdecimal', '1.3.5'
次に BigDecimal の README.md に書いてある説明を引用します。
version | characteristics | Supported ruby version range |
---|---|---|
3.0.0 | You can use BigDecimal with Ractor on Ruby 3.0 | 2.5 .. |
2.0.x | You cannot use BigDecimal.new and do subclassing | 2.4 .. |
1.4.x | BigDecimal.new and subclassing always prints warning. | 2.3 .. 2.6 |
1.3.5 | You can use BigDecimal.new and subclassing without warning | .. 2.5 |
1.3.5 は確かに BigDecimal.new が使えるので一見大丈夫そうに見えるんですが、これサポートされる Ruby バージョンが 2.5 までなんですよね。
2.5、EOL date: 2021-03-31 なんですよ...。
じゃあどうするのがいいかと言うと、この Qiita の記事にはどこでどんな形でエラーが発生しているかが明記されていないので、自分が調べた限りの想像ですが。
(そもそもちゃんとエラーの詳細を記事に書きましょうよ...)
mysql2 のバージョンが古いのが原因です。
もしこのエラーが発生して、手元の mysql2 のバージョンが < 0.5.0 ならこれを疑いましょう。 rails new すると mysql2 のバージョンが固定された Gemfile が生成されるからバージョン上げるの放置してて Ruby のバージョン上げたら踏んだパターンなのではないですかね。
この記事執筆時点で 2.5 の EOL が目前なので、これ踏む人増えそうなので書き残しておきます。
DeNAを退職します
このエントリーについて
10/30をもって最終出社となり、DeNAを退職することになりましたのでそのご報告です。
現職において社内外の皆様には大変お世話になりました。
本来ならばお一人お一人に直接ご挨拶させていただきたいのですが、諸々の制約のためこのような形を取ってしまうことをお許し下さい。
DeNAで働くということ
DeNAには4年半勤めていたことになりますが、入社当初を振り返ってみると技術的にもマインド的にもまだまだな段階で採用してもらえたことはとても幸運でした。
しかも当時は大物エンジニアが続々と入社している状況で、そんなすごい人達と一緒に働くことを楽しみにしていた反面、ちゃんと会社に貢献できるのかどうかとても不安でした。
DeNAという会社は誰にでも自分のMaxより目一杯ジャンプしてやっと届くか届かないかというところにハードルを置くのがとてもうまい会社で、なおかつ周りのハイスペックなエンジニア達に囲まれ、常に自分の立ち位置を認識できるような環境の中でした。
そんな中入社以降無力感を感じることもあれば成長していることを実感できる充実した日々を過ごすことができました。
その過程で技術力はもちろん、様々なアイディアが色んな場所から無限に湧いてくるような中、更に猛烈なスピードで事業が展開されていくという環境で一致団結していくために必要なコミュニケーション力(個人的には大人力と呼んでいるやつ)も高めることができました。(大人力は今も全然足りていないので引き続き頑張るぞい)
DeNAに入社する際に考えていた自分がこうありたいというエンジニア像を遥かに超え、それまで苦手だったり無関心だった技術領域に踏み込んでいくことができたのは今となってはかけがえのない財産になっています。
今後のキャリアに大きく影響するような経験をさせてもらった会社、DeNAで働く全ての人達に感謝します。ありがとうございました。
また、以前はRubyコミュニティでしか活動していなかった自分ですが、そのままだと決してクロスしないような多くのコミュニティ、優秀な社内外のエンジニアの皆様と交流する機会も増え、多くのものを頂きました。
本当にありがとうございました。
DeNAという会社の魅力
DeNAは永久ベンチャーという言葉を標榜しているわけですが、この2年ほどは以前にも増して社内にいてもびっくりするほどベンチャースピリットに溢れる企業になっています。
様々な事業を行っているということもあるのですが、その裏にはたくさんの失敗や成功があり、それをこれから生まれてくる新しい事業に有機的に繋げることができる企業です。
失敗したらタダでは起きないなんて言葉は生易しい。
その文化を更に加速させ、チャレンジしている企業です。
それは各事業に携わっている人を見ると明らかで、個々の事業が起業したての会社のようにエネルギーに溢れ、人が情熱を持って事業にフルコミットしている稀有な状況があります。
その中で、新卒で入ったメンバー、中途で入ったメンバーがお互いを補うように能力を発揮し、かつ成長し、組織としてのアウトプットを最大化している状態は驚異的でした。
恐らくこんな会社はそうそう無いんじゃないかと思います。
いつどのタイミングでjoinしてもエキサイティングな会社というのが最大の魅力なのではないでしょうか。
じゃあなんで辞めるの?
DeNAという会社はどこを見ても超一流なエンジニアがいる環境です。
それは協力して仕事するという上ではこの上ない経験なのですが、見方を変えると自分の弱点を他のエンジニアがカバーしてくれるということになります。
ただ弱点というのは成長するチャンスでもあり、自分に足りないところを見極められるというメリットもあり、今後のキャリアを考える過程であえて弱点になるようなことを求められるような環境に身を置きたいと思うようになりました。
理由はこれだけではなく、もっともっとたくさんあるのですが、今回色んなタイミングが重なり退職することを選択しました。
次のお話
ありがたいことに次はもう決まっていて、間髪入れずに11月から新しい環境で仕事をすることになっています。
ryopeko先生の次回作にご期待ください。
改めてお礼
この4年半の間、接していただいた全ての方にお礼申し上げます。
これからも変わらぬお付き合いをしていただけると幸いです。
以下謎の余白と謎のリスト
Developers Summit 2014 で新卒エンジニア研修についてお話してきました #devsumi
2014/02/13 (木) に開催された Developers Summit (通称デブサミ) 2014 1日目で「新卒エンジニア研修でできることすべきこと」と題してお話してきました。
これはその記録です。
(わいふが名札書いてくれました)
はじめに
今回わざわざお時間を割いてお話を聞きにきてくださった方々、デブサミスタッフのみなさま、本当にありがとうございました。
今回のセッションは以下のような内容で話してきました。
一口に新卒エンジニア研修と言っても単に詰め込んで終わり、というのではあまりに勿体無いということを実際のDeNAでの新卒エンジニア研修の事例を紹介しつつお話します。エンジニアに継続的な成長を促すことや自立性を持たせることはとても大変なことです。しかし新卒エンジニア研修ではこの様なエンジニアの素地とも言える部分を育むにはうってつけの場です。
本講演ではDeNAが試行錯誤を繰り返し発展してきた大人数に対する新卒エンジニア研修をご紹介しますが、DeNAの研修は人数によらない研修内容となっているため、来年度の研修からすぐにでも使える内容となるはずです。
とても嬉しいことに私のセッションは満席というだけでなく、当日は立ち見の方もいらしていたという状態でした(感謝)。
このエントリーの最後にスライドを載せておきますのでおおまかな内容はそちらでもご覧いただけます。
このエントリーでは主にセッション後、色んな方から質問を受けたことの一部でセッション内でお伝えできなかったことを、多少補足する形で進めていきます。
質問と伝え忘れたこと
人に物事を教える時に教える側が優れたエンジニアでない場合はどうするべきですか?
これ実はものすごく重要なことです。そのくせ伝え忘れました、すいません。
これは教えられる側からすれば実はすごく瑣末な問題だと思っていて、なぜなら教えられる側は適切な答えやインプットを貰えれば良くて、それを得られる相手であれば誰でもいい訳です。この理屈は裏表が逆で正しく言い換えると、表立ってはスーパーなエンジニアに教えてもらいたいと言いつつも、それは適切な答えを得られるという裏付けがスーパーなエンジニアにはあるということだけだと思います。誰か、もしくは自分がスーパーだと思うラベルがついている人から教わればハズレな答えを掴ませられる確率が低いというものです。
であれば適切な答えを与えてあげればよくて、仮に現在自分で答えを持っていなかったとしても、「君のその考えはとても重要で是非とるべきアプローチなんだけど、今自分は適切な答えを持っていないんだ」と正直に伝えた上で、「ちょっと調べて答えを用意するから君も君なりに答えを導き出してみて」と言って自分は後ほどきちんと調べればいいだけです。そうして後日答え合わせをすると。
なんか一見頼りないことに思えますが、セッション中でもお話したとおり我々の知識技術領域は無限の幅と深さを持っているので、この様なシチュエーションは日々の業務では日常茶飯事だとも言えます。つまり日頃仕事をする上で大事なことを2人でロールプレイするという絶好のシチュエーションです。ここで下手に取り繕うと速攻で新卒氏にバレます。取り繕うというのにもそれなりの知識や経験が必要なんです。正直になるということが信頼関係の構築にも繋がります(でもちゃんと行動しないとダメですよ、行動しないでこういうことばかり言う人はただの無能です)。
また、自分がスーパーじゃないという実感があったとしても自分ネックで新卒氏彼らの天井を自分に合わせる必要はなく、時には自分自身が理想とするエンジニアを演じ、伝えるべきことを伝えるというがとても重要だと思います(acts as 自分がすごいと思っているエンジニア業)。
教える側が理想とするエンジニア像に達していないのであれば、その理想を新卒氏と一緒に指を指して目指せばいいのです。
どうやってレビューでの言動からやばそうなことを察知するのか
これも明示できていませんでした。
この質問は ask the speaker コーナーが終わった後に休憩室をふらふらしていて @igaiga555 さんと まつもとさん、ささださん とお話していたときに出た質問です。
これは色んなパターンがあるのですが、一つ言葉にしやすいものとしては「問題に対する解決案への論理がショートカットされているパターン」です。
例えば問題から結論には5ステップぐらいの論理展開が必要な問題があったとして、その説明が 1 → 2 → 5 と途中が飛んでいる場合です。
この原因もいくつかあって
- そもそも理解していなくてなんとなく正しい結論にたどり着いている
- 答えだけを周囲(同期や google 先生など)から得ている
どっちも良くないわけですが、この状態にあるかどうかを見極めるには飛んでいる中間を2分探索して質問を投げていくのが良いです。
そうすれば適切な理解の上結論に至っているかどうかがかなりの精度、かつ省エネで判定できます。
これらの質問はごく一部ですが、特に伝えておきたかったものとして補足させていただきました。
最後に
実はこれから書くことはデブサミのオーガナイザーである岩切さんにはお伝えしたのですが、ものすごく縁というものを感じたので感謝の意味も込めて書き留めておきます。
自分にとってデブサミは数年前に初参加したときに今までの自分の世界をひっくり返し、学ぶことの重要性と楽しさを教えてくれた、いわば今の自分の基礎を成すものです。
そんなデブサミでいつかセッションを持って、デブサミの窓を通して誰かにとって新しい価値を伝えることでデブサミに恩返しをしたいというのは大きな目標のひとつでした。
それが今回、岩切さんがオーガナイザーとしての最後のデブサミで、しかも自分が新卒にものを教え伝え、学ぶことという内容のセッションを持って目標を達したこと。
これものすごく出来過ぎて帰りの電車の中で気がついた時に思わず吹き出してしまいました。
なのでこの気持ちはしっかり書き留めておこうと思った次第です。
おまけ
今日のセッションで使ったスライドと、普段スライドを作る前に作成するアウトラインを残しておきます。
どなたかの参考になれば幸いです。
アウトライン
実際のスライドと内容とは多少ズレていますが伝えたいことはほぼ満たしています。
(いつもこの状態を作ってからスライドを書き起こしています)
- タイトル
- 自己紹介
- 新卒研修って何でしたっけ?
- 世にある新卒研修のイメージ
- 必要なことはこれとあれとそれとこれと…
- はわわ
- よし、終わり!突撃ー
- 各所「むりむりむりmばたり」
- 研修がー研修がー
- ぐぬぬ
- メンターの力量に依存してぎりぎりなんとかもしれないがジリ貧
- 弊社の場合もこれと似たようなことが起きたり起きる要素が揃ってる
- 今年度の新卒の特徴
- 未経験者 >>> 経験者
- 大人数 (今年度70名弱)
- 教えることたくさん
- もうほんと無限にある
- だけど教えるのムズすぎ時間無さすぎ人いない
- 無理
- やれる範囲でやりましょう
- 全然やれていない
- やる前から投げてる
- 現場のニーズの変化
- サーバーサイドだけやってればいいとかいう時代じゃない
- あれもこれもそれも
- 成長してくれない!
- まずは新卒にまつわる問題点を整理、解決策を考えてみた
- 技術レベルが求める水準に達していない
- いいから引き上げる
- 今まで棚上げしていたことをちゃんと教える
- ここでちゃんと教えないと新卒が現場出て死ぬ
- むしろこの辺身につけていないで現場に来られるとおれが死ぬ
- 教え方工夫して理解できるようになるまで諦めないで教える
- その結果自分が死ぬとしても教えなかったら結局死ぬんだからいいから教える
- 教えきれなかったとしてもその失敗は来年に生きるはず
- 研修でやってきた知識が現場で生きない
- 局所的な知識や技術じゃなくて汎用的なものをちゃんと教えましょう
- 技術や知識や問題領域は幅広な上に深くて流動的、しかもロールがある
- なのに局所的なことを教えるのは研修じゃない、研修担当のギャンブルだ
- 基本の基をしっかり
- 現場固有の事象を取り扱わない
- 現場ではやむを得ずこうなってますとかBKは絶対ダメ
- むしろ理想を刷り込む
- レガシーに浸る前に理想を刷り込む
- 現場で教える時間も暇もない
- 教えなくても勝手に学んでいけるような人材を育てましょう
- 問題を正しく捉え、立ち向かえる力を養う
- 目先の技術力より観察眼、応用力を養う
- 知識や技術は水準、汎用性、応用力で評価される
- 問題点と解決策を考えたらこれって新卒だけじゃなくて会社全体の課題なんですね、ということに気がついた
- 誰のための研修なんですか?
- ✕新卒のため
- ◯みんなのため
- 個別の事情に対応すればいい?
- 無理、変化しまくりだから
- 既存社員も停滞されてると困る
- 以上を踏まえて弊社での研修の流れ
- フェーズは4段階
- 簡単な座学
- サービス企画
- 設計(画面とかDBのおおまかなもの
- 実装
- 各フェーズではレビューがある
- レビューは1時間
- 各フェーズ大体 5〜7回ぐらい
- 各フェーズでstep1, step2と分かれている
- step2ほど詳細に踏み込んだレビューになる
- 新卒と研修講師の1対1
- 70名超の個別指導 (小学校1学年の3クラス分!!!)
- 講師陣
- 現場のエンジニア3名
- 今回の研修のために一時的に現場を離れて100%コミット
- 外部研修講師数名
- 卒業時期
- 早抜け方式
- 早い人は2ヶ月ぐらい
- 遅い人だと半年 (9月末で全員卒業
- 研修のゴール
- 正しく問題へ立ち向かえる
- 継続的に主体性を持って成長できる
- 変化に強い人材
- 研修の進捗と成長度合い
- 研修が進んでいくと個人の差が徐々に出てくる
- 経験者未経験者問わず
- 経験者であろうとも伸び率や未知の領域との向き合い方など
- 早めに気がつく
- 成長を促すために打てる手はなんでも打つべき
- 教え方を工夫しないといけないなら教え方を返る
- 強みを更に伸ばして弱点を克服させてあげるスタイル
- どうやって気がつくの?
- 計測計測ー
- 想像するよりまずは計測
- ウェッブサービスと同じやー
- 各フェーズ各stepにかかっている日数を記録
- 大体パターンが出てくる
- 進捗する人が増えてくると精度が高まる
- 高まるころにはもう手遅れ
- そこで技術テストをやってみた
- Perlの筆記テスト
- 新卒との会話
- フラッと研修部屋に遊びにいってどうでもいい話をする
- レビュー時のふとした発言を記録
- これ結構ばかにならなくて普段どういう考えをしているかが読み取れる
- こういう発言しちゃうようなのってもしかして着実性無いのでは?とか
- この前こういう短絡的な発言してきたけど今回はすごい論理的に組み立ててきたり説明するためのツールも工夫してきた
- すげえめっちょ成長しとるテンションあがる
- 気がついたらどうするの?
- 褒められるところはたくさん褒めてあげる
- 良くないところは改善を促す
- 促すことにより成長や進捗を加速させる
- 改善は最初は自力で
- 改善してこないようなら手助けしてあげる => フォローアップ
- フォローアップ
- 今年度最大の発明
- フォローアップとは
- 毎日 or 隔日で講師との 30 分間の 1 on 1
- プログラミングのハマりどころ解決
- 問題解決手法のトレーニング
- 議論のトレーニング
- 成長促進のための徹底した振り返り
- etc…
- 大事なこと
- 良い所を伸ばして良くないところを改善する
- ひとりひとり丁寧に
- 一筋縄ではいかないのでひたすら工夫
- 改善したらフォローアップは卒業
- 最終的に自信をつけさせる
- フォローアップビフォアアフター
- ビフォアー
- 暗闇の中ゴールの場所もわからないのに目隠し耳栓している状態
- 何がわからないかがわからない
- 何がわかったかわからない
- 何のために自分が今やっていることをやっているのかがわからない
- 敵の強さがわかんない
- Lvわからないのにバラモスと戦っている
- 倒せるかどうかもわからない
- 死んで気がつく
- アフター
- 本質を見抜く力
- 自分のたどってきた道のりを正しく把握している
- 間違った道に入ったことを検知できる
- ゴールまでの距離
- 敵の強さがわかる
- 敵を分断して戦える規模にしてから戦える
- 効果
- フォローアップを受けた人のほとんどが急激に成長
- 時間と人員が許すなら全員にやっても良かった
- ただ自分の弱い面と向き合い続けるってすごくしんどい
- 結局は本人の意志に頼るところ
- 無理強い良くない
- 今年度研修の総括
- 現場アンケートより
- 主体性向上
- 基礎的な技術力向上
- git, github ネイティブ
- 去年すごく苦労した
- 切り込み力
- 問題へ立ち向かい切り開いていくエピソード多数
- 所感
- アンケート通り
- サービスを作る楽しさをもっと教えたかった
- もっと自分で考えに考え抜いたものを形にすることもやってもよかった
- レビューコストが爆発するという問題点がある
- 研修とは別のアプローチが必要か
- 自身の力を伸ばすことを優先して新卒同士で相談、協力させることができなかった
- 実は何もできるようになりませんでした、というのを避けたかった
- まとめ
- 組織のニーズも大事だが、変化の激しい組織のニーズに応えるのは大変
- 応えると2年後には陳腐化してる恐れがある
- 基本的な技術力向上はとても役に立っている
- 新しい技術も本質的な知識が備わっているので吸収が早い
- 人にフォーカスすることにより人材の柔軟性を高めたら組織にフィットしやすくなった
- 組織の型にはめて人材を育成するより変化に強い
- 特に弊社のような事業領域が広く変化が激しいところには有効
スライド
自宅Ruby会議02が開催されました #jtrk02
わいふ実行委員長の突然のひとことがきっかけで自宅Ruby会議02が開催されました。
自宅Ruby会議02
開催日:2014年2月8日
開始時間:多分夜
場所:関口家の居間
BGM:Macで放置しっぱなしの艦これ
#jtrk02
— わいフォーッ‼︎@ヨルに近いアサー (@ryopekowife) 2014, 2月 8
ちなみに前回の自宅Ruby会議01も大雪の日に開催されました。
詳しくはこちら
東京Ruby会議10と自宅Ruby会議01に参加しました #tkrk10 - @ryopeko の何か
今回のタイムテーブルは以下のとおりでした。
(タイムテーブルかわいみだ)
ということで@ryopekoアイコンの歴史について発表しました。
わいふ実行委員長の基調講演スライドはこちら。
とても良い話だったのとわいふ氏描きおろしルビ子ちゃんが可愛かったです。
ということで今回もとてもいい会議でした。
みなさん気軽に開催できますのでオススメです。
ぶつかり稽古について一言言っておくか ( #cross2014 の話し)
コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 | CROSS 2014 で親方として登壇しました。
このイベントについては他の登壇者の方もエントリーを書いているので是非参照してみてください。
実際参加してみて良い事も悪い事も含めて色々気がついたので、今後もより良い企画になるように書き留めておきます。
ぶつかり稽古2014初場所に含まれた要素
大きく分けて以下があると思います。
- 知的エンターテイメント
- コードレビューの心構え、やり方
- ペアプロ(初回の延長線上 (秋のエンジニアぶつかり稽古 2013 - ペパボ技術基盤チーム | Doorkeeper)
知的エンターテイメントについては今回の初場所では一切ペアプロしていないし、コードレビュー vs. 修正 みたいなぶつかり合いも無いのでエンターテイメント要素としてはパネルディスカッションにあったと思います。
じゃあぶつかり稽古とはなんだったのか
上記であげた要素について順に考えてみます。
コードレビューとペアプロとしてのぶつかり稽古
まず一番最初に重要なことを伝えたいのは以下の画像についてです。
この画像はぶつかり稽古の例として持ちだされる画像ですが、コードレビューにしろペアプロにしろこんな風に酒飲んで笑いながら指差して罵詈雑言を浴びせ倒してドライバーが頭を抱えている様な状態はクソです。
こうなってしまっては絶対ダメです。
(画像は面白おかしく使ってください。というか @sora_h が撮った写真と @songmu さんがペンギンコラと合わせた会心のネタ画像なのでこうなってしまったからには使ってもらわないとおれが困る)。
ペアプロのアンチパターンとコードレビューのアンチパターンが合わさったとても良い画像なので、普段の皆様のやり取りをこの吹き出しに当てはめてみてしっくりくるようだったらやり方を改めてください(べんり)。
それと合わせてあんちぽさんが壇上で言っていた "今日のことを現場に持ち帰って色々考えてみてください" っていうのは言葉通り色々考えてみてください。
ちゃんと壇上で登壇者の皆さん全員が良いことたくさん言っているのでこういうわかりやすい画像に振り回されないできちんと自分の頭で考えて自身の現場に良い影響をもたらしましょう。
コードレビューディスカッションとしてのぶつかり稽古
ぶつかり稽古2014初場所のメインテーマとなった内容です。
わずか1時間という限られた時間の中でもたくさんのコードレビューがの観点がキーワードとして出てきました。
- 設計
- パフォーマンス
- レビュータイミング
- レビューやり取りの姿勢
- レビュー観点
- テスト
- 教育
- チームビルディング
- チーム外レビュアーにレビューしてもらうときどうすれば良いか
今回話題にあがってこなかっただけで、コードレビューに含まれる要素はこれら以外にもまだまだあると思います。
だからこと壇上で私が言ったように "空気を導入しない" ということを心がける必要があって、レビュイーはこのコードレビューで何をレビューして欲しいのか、レビュアーは何に対してレビューすべきか、というのを逐次整理しながらレビューを進める必要があります。
コードレビューを経験した人はわかると思いますが、コードレビューは容易に脱線します。
デプロイが直前に迫っていたとしても容易に脱線します。
なぜならレビュアー、レビュイー共にこれからデプロイするものをより良くするためのプロセスとしてコードレビューを行っているからです。
なのではてなでやっているようなコメントへのタグ付けはレビュアーからのメッセージとしてはひとつの方法だと思いますし、レビュイーとしてはレビューのやり取りで今回見て欲しいところからは脱線しそうだなーと思った時には "この内容については後ほど要点を整理するためにタスクを切って対応しますが、今回はこのままで行くことにします" などレビューの論点を明確にすることが必要です。
あと個人的に印象的だったテーマが "チーム外レビュアーにレビュー依頼するとき" というものです。
これについては色々思うところがあって、仕事でも実際に依頼したり依頼されたりというのをやったり見たりしている訳ですが、大体いくつかのパターンがありました。
- でかめの機能を丸っと依頼される
- 極々狭い特殊な専門性の高い部分の限定的なレビュー
- アーキテクチャ、設計のレビュー
一番あるのが "でかめの機能を丸っと依頼される" これ。
もうこれはどうしようもなくって、なんでかというとその機能をそのように実装して今実装しているのはどうしてで、それまでどういうアーキテクチャになっていてどういう設計、コーディング規約があるのかわからない状態でのレビューになることがほとんどです。
このパターンは上記の様なコンテキストを共有できていないので、往々にしてレビュアーは深くつっこめなくて、つっこんだとしても "歴史的経緯でほげほげ〜" となってしまうパターンが多いです。
(できてコードの見た目の話しとか名前の話し。(まあそれもコーディング規約がーとか歴史的経緯でーとか言われてレビューが空中分解して終わるか人が死ぬ))
下の2つの "極々狭い特殊な専門性の高い部分の限定的なレビュー", "アーキテクチャ、設計のレビュー" のパターンはコンテキストを限定しやすいのでうまくいくパターンが多いです。
というかコンテキストを限定しないと丸投げにならないレビューって依頼できないのでは。
なので個人的には外部レビュアーにレビュー依頼するときは出来る限りコンテキストを限定した内容に留めておくとうまくいくと思います。
今後の知的エンターテイメントとしてのぶつかり稽古
今後どの様にぶつかり稽古が発展していくかはわかりませんが、ペアプロを軸にしたぶつかり稽古として発展していくとしたときに気をつけないといけないことが2つあると感じました。
- リアルなペアプロをぶつかり稽古にすべきかどうか
- 見る側に何を持って帰ってもらうか
前者は突き詰めるとエンターテイメント性が無くなって "なるほど、こうやればいいのか" といういい話になります。
後者はエンターテイメント性を突き詰めてショーにしてしまうと何を持って帰ってもらうかどうかが曖昧になります。
私的にはどっちかに寄れ、という風には考えませんが、やるとしたらどっちもやってプロレス的にやる、というのがいいんじゃないでしょうか。
見る側もやる側も色んな前提条件を把握した上で実施する。
こうするとぶつかり稽古というよりは巡業でのショー取り組みに近くなってきてしまうのですが、よく考えてみて欲しい。
相撲の場合のぶつかり稽古って見てて楽しいか?
本来の相撲のぶつかり稽古って人と人がひたすらぶつかって投げ飛ばされて砂まみれ汗まみれになりながら稽古するやつですよ。
(ついでに言うとぶつかられる方は親方じゃなくて兄弟子だろって @songmu さんが言ってたの思い出した。親方が現役力士にぶつかられたら死んでしまう。)
ぶつかり稽古の本質とか良くわからないですが、きっと言葉で伝えられない、感じられないものをお互いがぶつかることでコミュニケーションするというものなんじゃないでしょうか。
でもそれなら我々はぶつかり稽古は見に来るんじゃなくて現場でやれって話しですね。
現場でやろう。
まとめ
まとまらない。
ぶつかり稽古、特に今回のぶつかり稽古2014初場所は見た目やタイトルばかり先行してネタにして終わるっていうことになりがちな気がしますが、ここまでつらつら書いた通り得られるものは山ほどあるし、持ち帰れるものは山ほどあります。
今後どう展開していくかは本当にやる側、求める側次第だとは思うけどちゃんと皆で良く考えてイベントを育てていけばすごいことになると思うのでネタにして終わらないで欲しいです。
最後に、今回機会を与えてくれた @studio3104 さん @kentaro さんはじめ登壇者の方々、CROSS2014 実行委員の方々、参加者の方々、本当にありがとうございました。
師弟登壇・新米サムライの集い 2013 で発表しました
2013/10/12にGREEさんで開催された "師弟登壇・新米サムライの集い 2013" で発表してきました。
今回は今年の春からフルコミットした2013年度の新卒エンジニア研修の総まとめについてトークしてきました。
構成としてはYAPC::Asiaで同じ研修担当のエンジニアが話した "大規模Perl初心者研修を支える技術" では語られなかった側面についてと、実際に研修を受けた新卒氏の2段構成となっておりました。
僕のトークはこちら
新卒氏のトークはこちら
当日は他社さんの研修内容もふんだんに披露されてとても勉強になりました。
特に新卒氏たちに浴びせる情報量やレベル、浴びせ方については各社とも特色が出ていて面白かったです。
この辺は会社の姿勢もあるんでしょうが、今回見聞きした感じでは研修担当になった方の個性が出ているという印象でした。
やはり学校の先生とかもそうだと思いますが、教え方が個人に依存してしまうのはしょうがないのかなあと思ってますが、教育指導要領とかあってもあんだけ先生によって差が出るから本当にしょうがないのかもしれませんね。
今年度の研修はやはり自分じゃないとできない側面っていうのは少なからずありました。
それは僕の発表でも何度も出てきた "人にフォーカスする" という面で大きく現れたと思っています。
正直今年度と同じ技術知識をインプットするというのは教えたものリスト、みたいなのがあれば来年度も教えられると思います。
ただ、なんでこのような知識が必要か、どういう心持ちで今後もこのような知識をインプットしていけばいいのか、などなど一言で言えないようなモヤッとした物事っていうのは教えている人の個性がモロに出ると思います。
実際今年度DeNAでは3人のエンジニアで講師陣として取り組んだわけですが、新卒氏に伝えたこのモヤッとした部分の内容や伝え方というのは、彼らがどの講師と接する機会が多かったかによって色んな色が出ていると思います。
研修に取り組み始めた当初はこの辺のことも統一するべきみたいな話もあったんですが、最終的には教える人によってある程度の側面ではバラつきが出るのは許容することになりました。
もちろん大枠としてこの様な人材を育成するという点はブレていません。
ブレないための今年度のしっかりとした目標があったからこそ安心して講師各人に裁量を持たせられたと思っています。
でも結果としては良い意味で色んなタイプのエンジニアが育成できたと思います。
ブレないところはブレず、ブレていいところは率先してブレさすということが暗黙の内にできたのは奇跡じゃなくそれだけ綿密なコミュニケーションを講師陣で取っていたからです。
毎日1時間の講師陣でのデイリーミーティングと徹底的に記録を取った手法は伊達では無いと思います。
我々講師陣は遠慮せずにぶつかるところはしっかりぶつかって、でもきちんと新卒氏の表面上ではない個性や成長度を見極めていたから今年度の研修ができたと考えています。
この辺の意思疎通は初めからうまくいっていた訳ではなく、フルコミットできる状況を利用してたくさん時間を重ねたからですね。
この様なことから教える人によってバラつきが出るのは個性として扱ってもいいと思ってます。
育成のための答えってひとつじゃないですし。
ただ、断言できることは "自分たちがサボったら新卒氏たちが死ぬ" という気持ちで取り組まなければならないということです。
彼らの今後の人生は自分たち次第で決まるんだと。
おこがましいことかもしれませんが、育成次第で人生って変わると思ってます。
まさに自分がそうでした。
彼らのことをたくさん知って、工夫してたくさんのことを伝えられたら伝えた分だけ彼らの今後が豊かになっていくという気持ちで取り組むのが重要だと思います。
ひとつ、今年度の研修としてやり残したことがあるとすれば、全社的にもっともっと新卒氏たちの成長にコミットして欲しいということを伝える業です。
今回、新卒エンジニア研修として僕らはきっかけを作っただけに過ぎず、新卒氏彼らの積み重ねというものはずーっと続くものです。
色んな熟練エンジニアの元についてたくさんのことを学んでいくことになります。
なので彼らの側にいる人達はこれからは彼らの成長を促していく必要があります。
この辺はペパボさんがとてもうまくやっている印象を受けたので大いに取り入れていくべきだと思います。
今回の発表が終わってからずっと "良い研修をやれる人" ってどんな人かなーと考えていたんですが、今のところ以下の様な要素がある気がします。
- 良い成長をしている人
- 良い成長をしている人が一定数周りにいる人
- 良いメンターに出会えた人
- 色んな事を客観視できる人
- 人の限界を決めつけない人
- うまくいかなかった経験がある人
今年は自分としては "良い研修をやれた" と思っています。
で、当てはまるのはどれかと言うと "良いメンターに出会えた人" だと思います。
どんなエピソードがあったかというt(省略されました、これ以降のコンテンツをご覧になるには課金してください)
研修っていうのは "ペイフォワード" ですね。
色んな人の積み重ねの上に今の世界があると思います。
なので享受している人は積み重ねに参加するともっともっと世界が加速すると思うのでオススメです!!
あーなんか最後取り留めのない感じになってしまいましたが、今年度の新卒エンジニア研修については語りたいことが多すぎますね。
なので話し聞きたい!!という人がいたらどんどん課金してコンテンツを引き出してもらえるといいと思います!!
(場があればもっと出していきたいですねえ)
アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)
- 作者: Dave H. Hoover,Adewale Oshineye,柴田芳樹
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/07/08
- メディア: 単行本(ソフトカバー)
- 購入: 12人 クリック: 221回
- この商品を含むブログ (50件) を見る