TokyoGirls.rb Meetup vol.2 に参加しました！
こんにちは！
今年の11月からiCAREにjoinしましたエンジニアのメグミです！
社員インタビューを見てくださった方はご存知だと思いますが、
まだエンジニアになりたてのほやほやで、日々勉強中です?
今回は、先日行われた、TokyoGirls.rb Meetup vol.2に参加した際の
レポートを書きたいと思います?♀️ イベントページはこちら
登壇された方々のLTについて簡単にまとめました?
Ruby on Rails最初の一歩
スピーカー：ただあきさん（Classi）
Rails初心者やチームに新人がいる方の参考になるようなポイントをわかりやすく発表しておられました。
- ドキュメントの読み方について
- 公式のドキュメントを読むだけで参考になることがたくさんある
- エイリアスがわかったりする
- サンプルコードがシンプルで参考になるものが多い
- PRの出し方やポイント
- 自分の気になる点については補足を書いたり、ピンポイントでコメントする
- 機能単位でPR出す（細かくコミットする）
- それでも差分が多いときは対応した箇所ごとに出す
事業知識を深掘りし、より人の役に立つサービスに改善する
スピーカー：Kubota Naoさん（エイチームフィナジー）
事業知識の深堀りをすることによって、理解する前と後とではサービスの品質向上や改善につながったというお話でした。
- 事業内容を理解していない場合のデータベースの設計
- 専門用語の変数名の命名がうまくできず、何を指しているのか不明
- 表示修正を行うたびに毎回多くの工数がかかる
- 属人化
- 事業知識を掘り下げた結果
- 現実で発生するような要望に沿ったデータの提供できるように
- サービスの改善提案ができるように
- チーム内のコミュニケーションコストが少なくなった
- 結果サービス品質の向上につながる
- 一つひとつの言葉の意味に疑問を持ち意味を調べる
- 普段使っている言葉も業界によっては違う解釈をすることもある
Rackミドルウェア入門のためのRackミドルウェア
スピーカー：塩井美咲さん（キャタル）
Rackミドルウェアを作成されたお話。
正直、まだ自分が未熟すぎて内容が理解できなかったです?
もう少し知識をつけて、改めてスライドを理解したいと思います?
エンジニアとチームを組んで見えないものをデザインする
スピーカー：羽野めぐみさん（デザイナー／キッチハイク）
今回唯一のデザイナーの方でした。
チームでプロダクトを作り上げていく中での大切なことについてのお話。
たしかにデザイナー目線とエンジニア目線では考えていることが全く違うなと思いました。
表面的な言葉にとらわれず、文脈を共有してお互いを知ることが大切なのだなと感じました?
プロジェクトマネジメント沼にようこそ
スピーカー：浪川舞さん（PeerQuest）
プロジェクトマネジメントについてのお話。
自分にはまだまだ先の話と思っていましたが、チームで開発するということについてとても参考になる内容だと感じました。
- プロジェクトマネジメントをやってみて
- 朝会の定期開催
- 温度感の共有
- 課題を顕在化させる
- 全員でとりくむ空気をつくる
- 進捗管理数値の分析
- 担当の明確化
- 進捗率ではなく作業効率を重視
- バーンダウンチャートを全員で共有（タスクの可視化）
- メンバーの顔を見る
- 何か抱えてそうな人には声をかける
- 辛そうな人は休ませる
- 朝会の定期開催
- 結果
- タスクの調整がしやすい
- 属人化がなくなった
- 問い合わせ対応スムーズに
- 大事にしていること
- セオリーの活用
- 数値の分析
- 人とのコミュニケーション
- 上下関係のない1on1（横や斜めの1on1）
- 上司の場合はいいところを見せたかったり、本音が言えない。
- 自分とメンバーの特性を知る
- ファシリテーション研修導入
- メンバーのモチベーション保つためには
- ビジネスのOKRを共有する
いつもの開発のようにOSS活動をしよう
スピーカー：makicamelさん（ITMONO）
私には程遠い話だろうなー?と思いながら聞いていましたが、
一連の流れは確かにいつもの開発と近いのかもしれないと感じました。
- 新しいプロジェクトに関わるときと同じ。わからないことは調べればいい。
- コンテキストがわからない場合は大変かも
- rails/railsのIssueとかPRを毎日見てみる
- 好きなリポジトリ見てみるのがおすすめ
絶対に手戻りしない！時短勤務ママエンジニアの、要件ヒアリング力
スピーカー：ちょうかおりさん（div）
エンジニアの仕事の本質は、問題の発見と解決であり、そのために背景を知ることの大切さについてのお話でした。
- 納期は期待値のひとつとして考える
- 背景を知ることが大切
- 理想を正しく把握すること
- なぜをきく（現状どうしてるとか）
- 納期も一応きく
- 依頼にある要望は氷山の一角かも
- 時間で解決する以外の方法がある
- ヒアリングしすぎて要望が増えた場合
- 最初のリリースで様子みてもらう
- マストじゃなければ様子みて改めて依頼してもらう
強いエンジニアという灯
スピーカー：大場寧子さん（万葉）
強いエンジニアとして居続けるためには、現場でエンジニアリングをし続ける必要がある。でも、色々な選択肢の中で強いエンジニアとは違うところにいる可能性もある。自分の大切にしたいものを信じていくことが大切と思ったお話でした。
- 強いエンジニアとは
- 技術を使った問題解決がうまい
- 折れない心
- 柔軟
- 骨太
- スキルを伸ばすための要素
- 自分の頭で考える
- スクラッチでコードが書ける
- 自分のアプリを開発する
- 覚える
- 覚えることは速さの根源
- 調べる時間を短く、考える時間を増やす
- メソッド名などの命名法則を考える
- 名前づけの法則がわかれば暗記しなくても推測できるようになる
- 信念を積み上げる
- 性質や挙動をふわっと理解ではだめ
- こう動くはずと信念を持つ
- 確信があれば的を絞って調べられる
- 自分のやったことを評価する
- 振り返りを行う
- うまくいったか
- 失敗したところを考える
- 成功した形を覚える
- 失敗の芽を蓄える
- 失敗したことがあると回避策が浮かぶ
- 回避できるようになるからうまくいく
- たくさん失敗できる環境に身を置こう
- うまくいっている状態をパターン認識
- うまくいっている状態と今の現実を比較する
- レビューのときに意識すること
- 書かれたコードに反応する
- 行、メソッド、クラスなどを失敗の芽を潰すようにみる
- 自分がうまくいくパターンと比較して違和感に気づく
- 書かれるべきコードに気づく
- 仕様や挙動の失敗の芽をさがす
- うまくいくパターンと比較して必要なコードが欠けていないかを見る
最後に
私の知識が浅く、わからない部分もありましたが、
技術的な話よりも開発していく上でのポイントや、
チームでの開発についてなどのお話も多かったので
とても勉強になりましたし、楽しめました！
最後に参加者全員で「はい、each✌️」で記念撮影して終了?
学習意欲が高まった勉強会でした??
