日々のこと

まいにちの暮らしをつれづれ書きます

TokyoGirls.rb Meetup vol.2に行ってきた！（後編）

勉強会 すきなこと おでかけ

女性も参加しやすい、けど女性限定ではないRuby勉強会、TokyoGirls.rb Meetup vol.2へ行ってきたレポ、やっと後編です。
年が明ける前にまとめておきたかったので、ぎりぎり間に合いました。

講演スライドまとめはこちら👇 blog.jnito.com

前編、中編はこちらの記事です。 hibinokoto.hatenadiary.jp hibinokoto.hatenadiary.jp

さて、本題です。

スポンサーLT：トレジャーデータ株式会社 さま

トレジャーデータのSREのrenee changさんのLTでした。
日本にきて3年目、はじめての日本語での登壇ということでした。チャレンジ、尊敬します。
SREについて、今年のはじめにデブサミでGoogleの方の講演を聞いて興味をもち、SREの本を読みたいと思っているところにこのLTでうれしかったです。
SREはエンジニア、専門職なのだなと感じました。
トレジャーデータでは、１つのチームが３つのタイムゾーンに分かれて働いているそうです。

規模

  • 30の内部サービス
  • AWSの複数のリージョン

  • 2000台以上のインスタンスを運用

  • SREチームは、社内向けのAPIを提供（環境の切り出しなど？）

  • 社外向けのリソースセットを提供している
    • Rubyで実装されたサービスもたくさんある

SREはなんの仕事をしているか？

4つの領域

  • Delivery
  • Observability
  • Resilience
  • Reliability

一番多いのは、SREはどのチームに連絡すればいいか把握している

  • ソフトウェアエンジニアである

Relicabilityとはなにか

システムに問題があってもすぐ正常に戻すことを目指している
各部品の信頼性をみている
全体の信頼性は、部品の信頼性を足し合わせたものより大きいものにしなければいけない
We are hiring !

いつもの開発のようにOSS開発をしよう / makicamel さん

makicamelさんのOSS開発に一歩踏み出したお話です。
「OSSってすごい人がすごい技術でやってる」「雲の上の活動」みたいな感覚でいたので、それを「自分でも少しやってみてもいい・・・かも・・・・？」と思わせてくれる内容でした。
しかも、私が1年前くらいにはまったdeviseとdevise_token_authのgemのIssueに対して修正のプルリクを出されていたので、個人的に身を乗り出してお話を聞いていました。
私もそこではまった！だけどそこから修正プルリクをだす動きをされるのがすごい！と思いました。
最後のほうで、「わからないことは知ればいい」「わからん、こわい、という漠然とした苦手意識がなくなる」というのがすごく響きました。
わからないことってすごくこわいけど、わからないことがわかる、というのでも一歩進歩ですし。
最後の方の「参考」のスライドが、OSS活動をはじめるときにすごく参考になりそうでした。

OSS活動

  • OSS活動はつよつよエンジニアがすることと思っていた
  • OSS活動はこわくない
  • OSS活動といつもの開発は似ている

メールの変更機能実装、変更時に確認メール送る機能の実装

  • devise

    • 認証の多機能gem
    • https://github.com/plataformatec/devise
    • 専用のカラムを追加、設定することですぐ使える
    • メールの変更確認は、deviceのconfirmableモジュールを使える

  • 実装したが、メールが送られない・・・

    • 再確認が必要かのフラグをみて必要なら送るようになっているが、常にフラグがfalseになってしまっている・・・

  • device_token_authも使われていた

  • もしかして、コントリビューションチャンス

    • マージされた！！！

このPRでやったこと

  • 調査・修正
  • 後方互換性の維持
    • 今までのdevise+devise_token_authではメールが送られない
    • 使ってる人は手元でパッチを当ててるはず
    • バージョンアップで挙動を変えるのはよくないので、デフォルトでは送らない・設定したら送るようにした
  • テストを書く
    • 環境構築やテスト方法は、CONTRIBUTING.mdにあることが多いので最初に目を通す
  • マージされる努力
    • 伝わるコミットを目指す（なぜをコミットの本文に書く）
    • わかりやすいPR（現状の実装と問題の発生理由など書く）

codeclimateに指摘を受けた

  • 処理が似たコードブロックがある
  • 相談してよかった
    • 自分だけだったら、リファクタして終わりだったけど、moduleへ切り出しできた

いつもやってることと同じ、OSS開発でも特別ではない

違うこと

  • 英語
  • 相手が目の前にいないことが多い
    • 夜や休日にやってることが多い、時差
  • コードのコンテキストがわからない

OSS開発で特に大変だと思うこと

  • 継続して続けてこそ価値があるのではではなく自分のできるときにできるペースでやればいい

  • コンテキストがわからない

    • 継続的に関わっていないと大変なときもある（キャッチアップができない）
    • 転職したてのときも同じ、特別なことではない

  • わからないことがたくさんある

    • {むずかしいなにか} がわからない
    • やってるとわかるようになるのでたのしい

  • わからないなら知ればいい

絶対に手戻りしない！時短勤務ママエンジニアの、要件ヒアリング力 / ちょうかおり さん

時短勤務でお子さんがいてエンジニアをされてる、ちょうかおりさんの要件ヒアリングについてのお話。
私も6歳の子がいてエンジニアなので、すごく聞きたいお話でした。
エンジニアの仕事の本質は「問題の発見と解決」、そのために「背景を知る」ということが残りました。 また、「納期」とは、期待値のone ofでしかないんだということも。
懇親会でも少しお話できたのがとてもうれしかったです。ありがとうございました。

自己紹介

  • PHPでずっと書いてた
  • 時短で働いている
  • TECH*CAMP、TECH::EXPERTの事業
  • 社内のシステム開発をしている

「納期」まもれてますか？

  • 「背景を知る」
  • エンジニアの仕事の本質は？
  • 納期の正体は、期待値のひとつ（相手の都合）
  • 依頼者の理想を正しく把握すること

なぜ？を聞くこと

  • 日毎の入会者数データをCSVダウンロードできる機能が欲しい

    • 誰が使う？：社内の運用担当者
    • なんに使う？：月次でA社に報告している
    • A社はこの数字なにを使ってる？
      • なくても問題ないことが発覚、工数ゼロで解決

  • お客様からの書類の提出状況をシステムで管理したい

    • 誰が使う？：CSの担当者
    • 今はどうしてる？：スプレッドシートで管理
    • いつ使ってる？：「必要な書類を伝えるとき」「未提出の書類の回収依頼をするとき」
    • 突っ込んで聞く
      • 未提出の場合はどうしてる？：最終的には、全員分のもの回収したい
    • 最終的に作ったものは、当初の納期からは遅れたけど大満足、お客様の増加にも耐えられるようになった

コツ的なこと

  • 納期については一旦聞いておく
  • 背景や目的を聞き取りにくい時
    • いつ使ってます？今どうやってます？
  • 依頼にある要望は、実は氷山の一角である
  • 時間で解決する以外の選択肢もある
    • 目的を把握することで期待値の調整ができる

まとめ

  • エンジニアの仕事の本質は「問題の発見と解決」
  • そのために大事な心がけ「背景を知る」
  • 明日からできること「なぜ？を聞く」
  • 納期は理想の一要素に過ぎないので、恐れず期待値調整

質問

  • 今の問題はなんですか？は、自分が取り組むときに、腹落ちして取り組めるまでは聞いている

  • 念のためほしい機能を要件として入れてしまうことあるがどうしているか

    • ヒアリングしすぎると要望を引き出し過ぎてしまう
    • 一旦聞いて出すことはいいが、最初のリリースはここまで、様子を見てから再び依頼をしてくださいとハンドリング

  • 間に入っている人が強固にやってほしいとなっている場合、どうしているか

    • 背景を聞くことを心がけている
    • 間に入ってる人をすっとばせれば直接聞いてしまう
    • 聞けなければその人にステークホルダーになってもらって、責任持ってもらうように期待値調整する

スポンサーLT：株式会社万葉 さま

株式会社万葉様のゆりこさん（@yuriko12111）のLT。
2019年2月入社、仕事でrubyを使うのははじめてだったそうです。
このあとのKeynoteも万葉の大場さんでした。
万葉さん、憧れの会社さんのひとつです。
現場railsの書籍にもお世話になりました。

株式会社万葉について

  • 自社でサービス運用しているわけでなく、開発のお手伝いをしている
  • 株式会社レトリバと経営統合した（2019年7月）
  • これからもエンジニアリングパートナー事業を続ける
  • 11月から新宿三井ビルの36階（富士山見える！）
  • 万葉のモットーは、いいものをたのしく

Keynote：強いエンジニアという灯 / 大場寧子 さん

株式会社万葉の、大場さんのお話です。タイトルからして聞きたかったお話。
本当に聞くことができてよかった。
これから先、エンジニアとしてどこまで続けることができるんだろう、と不安にかられるときがあり、その気持ちに寄り添ってくれるようなお話でした。
ときどきこれから見返すことになりそうです。
成長のファクタのひとつで、「自分のやったことを評価する」というのは意外とやれていないので、やらなければ、と思いました。

自己紹介

強いITエンジニアへの道

強いエンジニアとは

  • 技術を使った問題解決がうまい
  • 折れない心でエンジニアリングができる
  • 骨太
  • 柔軟で広い

万葉の新人教育を見ていて、同じような取り組みをしてもスキルの伸びには個人差がある
スキルを早く伸ばすための要素とは？

自分の頭で考える

  • スクラッチでコードを考える
  • ぜひ自分のアプリを開発してみる

覚える

  • 覚えることは速さの根源
  • 調べる時間を短くして考える時間を増やす
  • 裏技
    • メソッド名など名前付の法則を覚える
    • 結果を覚えるのではなく、結果を生み出す法則を覚える
    • 法則を使えば、初見の既存コードからも既存機能を早く見つけ出せる
    • RubyやRailsの"気持ちがわかる"
    • 法則を意識してコードを書く！（さもないと、全部調べないとメンテができないコードになってしまう）

信念を積み上げる

  • プログラミングでは、物の挙動や性質を利用する
  • プログラミングでは、メソッドの挙動とか言語仕様を利用する
  • ものの性質や挙動をふわっと理解したまま、先に進んではいけない
  • ぐらぐらした土台の上に次の土台を積まない
  • 自分のやろうとしていることにも信念をもつ
  • 自分にできるかな、かけるかな、コードがかけるかな
    • こういう心配はする必要はない、あなたのコードは必ず動く！！！
  • 折れない心で、目の前のことを一歩一歩理解して進む
  • 目の前の現実に冷静に対処する

自分のやったことを評価する

成長速度に関わるキー・ファクター
効果的に経験を積める

  • 仕事をする
  • どうだったか評価する <- ココ！
  • 学ぶ

評価とは？

  • その仕事はうまくいったのか？
  • どんなところを失敗したか
  • 成功した形を覚える

失敗は最高の学習法だ

  • 予期せずうまくいかないことをここでは失敗と呼びます
  • 失敗は学びの宝庫
  • うまくいくとは、失敗の芽にうまく対応できること
  • 失敗の芽に気づかずにえた成功はラッキーパンチ
    • 成功の再現性がない
  • 失敗の芽を知っているから回避できる、うまくいく
  • 失敗の芽を蓄えることが強いエンジニア
  • たくさん失敗する
    • たくさん失敗するにはどんどんやる、むずかしいこともやってみる
    • 失敗できる環境に身を置く

うまくいっている状態をパターン認識

  • うまくいっている状態は、綺麗な部屋みたいなもの
    • 何かがおかしいことに気付きやすい
  • 何事も大まかなパターンを覚えていると活用できる
    • コードがうまくいっているとき
    • チームがうまくいっているとき
  • うまくいっている状態をパターンとして覚えておいて、今の現実と比べる
  • これは、コードレビューの時に重宝する
コードレビューのアプローチ

  • 書かれたコードに反応していく

    • 失敗の芽を潰すように見ていく
    • コードの全体像を脳内のうまくいくパターンと比較して、違和感があるところの改善を考える

  • 書かれるべきコードがないことに気づく（これ難しそう）

    • 仕様や挙動の失敗の芽を潰すように見ていく
    • 課題に対して思い浮かべる「うまくいくパターン」とコードを比較して、パターンにはあるのにコードにはない部分を見つける

強いエンジニアという灯（あかり）

灯に向かって進んでいくけれど仕事の選択肢はいろいろある

  • 大場さんの場合

    • ずっとコードを書いていくために会社を作った
    • マネージメントができないと会社がうまく回らないので、マネジメント
    • 経営者っぽくなってきた
    • 組織を整えるのは、オブジェクト構造を整えるのと同じように楽しい

  • 強いエンジニアを目指す旅の途中で出会うもの

    • エンジニアリングで何を実現したいのかが気になってくる
      • プロダクトオーナー、事業を立ち上げる、コンサル UX
      • UI/UX、デザイナ
    • チームが生き生きと働けるか
      • コミュニケーション、マネージメント、チーム開発、組織の仕組みづくり
    • エンジニアを育てたくなってくる
      • 教育、採用、本、教材
    • 育児や介護、趣味のための仕事量の調整
      • 現場を去るかも

  • 強いエンジニアであり続けるためには、現場でエンジニアリングをし続ける必要がある

  • 気がついたら、強いエンジニアと違うところを旅することになるかも

  • 強いエンジニアという灯の周りでいろいろな活動をしていく

  • 灯はこころの中にある！

質問

  • 大場さんにとって強いエンジニアとは誰か？

    • インフラが苦手なので、全編的にできる人
    • matzさん、松田明さん

  • 失敗の芽を忘れないためには？

    • 繰り返しやることを忘れない
    • 自分が何かをして失敗した、と思うとき
    • コードレビューがキー
      • 自分のエリアのコードレビューをすると記憶の定着のために良いのかも

  • コードを書いてるとマネージャーになってしまうのはなぜ？

    • 一つには、コードを書いている人がみんなマネージャーになるわけではない
    • マネージャーの素質があると、圧力が増えるのかも
    • コードを書くこととマネージメントは通じる
      • 問題解決のレイヤを変えているだけ、コードを書いてうまくいったときと同じ

  • 今までの経験の中で、成長したなというエンジニアいたら教えてください

    • 素人で入ってきて、半年でチーム内のエース級の頼れる存在に
    • 伸びる人は半年、1年で伸びる
    • 3年くらいするといい感じになるイメージ

懇親会

アンチボッチ対策万全の懇親会、人見知りの私に本当にありがたかったです。
テーブルが4つに分けられ、初めて買ったRubyの本でテーブルを選びました。（私はきりんの本）
Rubyをはじめてまだそんなにたってない方や、ずっとエンジニアとして働いてきた女性の先輩など、お話しすることができてうれしかったです。
また違う機会にお会いして近況をお話できたらうれしいな、と思います。

さいごに

このMeetupは今回2回目の開催でした。
私は、今年の8月にはじめて転職したのですが、1回目に登壇された@katorieさんのこの資料を見てこの会社への転職の背中を押されたところがあり、とても参加したかった会でした。
ためになるお話もたくさん聞くことができたので、行くまではちょっと緊張していたのですが、本当に行ってよかったです！

最後に記念撮影。
運営いただいた方々、登壇された方、懇親会でお話したみなさんに、ありがとうございました！
f:id:nobu09:20191230105115j:plain