developers summit 2022 メモ

世界の一流エンジニアの思考法を日々体験しているのでデブサミでこっそりシェアする話 (牛尾 剛さん)

米 MS の優秀なエンジニアの習慣をシェア

推測する習慣

いきなり色々調べるのではなく、推測をしている コードベースに触れたことが無いが、ログやクエリを1回だけ見ると解決してしまう

理解に時間をかける

システムが複雑で、チームに入ってまともな成果を出すには1年かかる
自分はシェア用の動画を1回みてもわからないので諦めてしまっていた。
優秀な人は、すごく頭の良い人に見えるが、難しいものを理解するために何回も動画をみている。

時間のマネジメント

自分の時間を4時間くらいブロックする。みんなやっている
どんなチャットも無視
22:00 には寝る

リソース不足時のマネージャーからのアドバイス

メンバーの状況を把握しているマネージャー
OSS で企業としてコアなメンテナンスをしていた時、Go で Memory Leak の対応。
Go はわからないけどベストエンジニアを紹介する。-> 「全く同じ環境を作りましょう」
また、OSS の issue をあげた人に協力を仰ぎなさい。
お客さんに聞くのかという驚きはあったが、意欲的に協力してくれた
一緒にデバッグしてもらえて、ほとんど解決した。

リモートゆえのミスコミュニケーション

レビュー指摘通りにやっても自分の環境では動かない 相手の環境では動く なので噛み合わなかった。 画面共有で解決した。

PR がコメント or ファイルサイズが大きくなる場合はミスコミュニケーションのサイン -> よくわからない?

米国で働くチャレンジ

自分は優れていないと思っているが、受けないと受からない。運もあるのでトライすべき。 https://simplearchitect.hatenablog.com/entry/2020/04/23/075627

自分の好きな働き方を決めるコツ~自分の得意なこと・やりたいことでキャリアを築くには~ (椎野 磨美 さん)

計画的偶発性理論

個人のキャリアの 8 割は、偶然の出来事によって決定される

  • 予期せぬ出来事がキャリアを左右する
  • 偶然の出来事が起きたとき、行動や努力で新たなキャリアにつながる
  • 何か起きるのを待つのではなく、意図的に行動することでチャンスが増える

以下の行動特性を持っている人に起こりやすい

  • 好奇心
    • 新しいものに出会う機会を増やす
  • 持続性
    • さまざまなものに興味を持ち、試してみたもののなかで、楽しい・勉強になるものを継続する
  • 楽観性
    • 新しい機会は必ず実現する、可能になるとポジティブに考える
  • 柔軟性
    • こだわりを捨て、信念、概念、態度、行動を変える
  • 冒険心
    • 結果が不確実でも、リスクを取って行動を起こす

リーンな開発を目指す第一歩 ~マイクロサービス化と GitHub Actions を活用したデプロイ改善~(川村 亮清さん、宮田 周さん)

リーンな開発を目指している。デプロイ頻度と開発リードタイムを短くしたい。
現在は競合が多く、リリースの調整が大変。
また、リリースプロセスが複雑。

ビックバンリライト … 全て置き換え
ストストラングラーパターン … 小さい単位

サービス間の非同期なメッセージング基盤
データ同期基盤

image

image

Kafka … メッセージングサービス。AWS MSK で提供されている debezium … CDC = データベースの変更を検知してメッセージを発行する

image

GitLab 社で学んだ最高の働き方 (伊藤 俊廷さん、佐々木 直晴さん)

Gitlab は、世界最大のフルリモート企業。非同期のコミュニケーションを重要視している。

MTG 運営

同期コミュニケーション(=MTG)はキックオフなどのマイルストーンのみ。
MTG 招待されても、イシューやチャット、ドキュメントなどの 非同期の手段が取れないか考えて提案する
-> これはあまりできてないかも

Agenda

アジェンダは先に記載する。
アジェンダのテンプレートがある。 1on1 用と一般用。Google Document を使用している。
メモや議事録は役職に関係なく 全員で取れるだけ同じノートに取る 質問も書いておくとあとで触れてもらえるので思いついたら書く

実践するなら

  • MTG セット時と同時に、必ず空のコンフルドキュメントを貼るようにする
    • 後から URL を追加されると、複数に散らばる可能性がある
  • アジェンダのテンプレートを作る。他の人のテンプレを真似して、組織でアップデートしていく

オンボーディング

ドキュメンテーションを重んじ、1 ヶ月先までオンボーディングを定義している
https://about.gitlab.com/handbook/people-group/general-onboarding/

社内のドキュメントをほとんど公開している

交流

Coffee Chat (=雑談タイム) で雑談する時間は大事にしている

1on1/評価

  • 週 1 回 1 時間

  • 雑談が明示的に1つの議題

  • お互いの趣味や、自国の文化、プライベート

  • 仕事にかかわるなんでも相談

  • 他のメンバーの成果をいつでも推薦できる制度があり、認定されると $1000 もらえる

    • 認定基準は、Job Description を超え、他のチームの範囲まで協力したこと
  • #thanks チャネルでちょっとしたことの感謝を伝える場所を用意する

実践するなら

  • #thanks チャネルはすぐにでもできそう
  • 1on1 で議題を事前にセットするのはやってもらえてないので依頼してみる

チャットツール

・Slack を 90 日で削除するポリシー (!?)
-> 消える前に公開 Issue に残す。 RevComm でも Slack, Asana, Github, Confluence に散らばりすぎているかもしれないが、消してしまう運用は強力。手段として覚えておく。

  • Group Direct message は禁止で、一時的な channel を作る
  • email は外部とのやりとりを考えると完全に無くせない

オンライン会議ツール

使い分けると効率が落ちる ので、Zoom を原則利用。推奨設定は Handbook に記載。

カメラはデフォルトでオン

  • 情報量が増える
  • アイスブレイクになる
  • リモート反対派に口実を与えない

実践するなら

  • 録画を可能にするために Zoom / Meet 全員有料化はお金がかかりすぎるので、統一によるメリットをそこまで感じないかも
  • カメラオフの人は割といるので、デフォルトでオンにしてみてもいいかも。
    • この辺り、化粧する、しないなど、身だしなみを考える必要が出てくる。ややセンシティブな話題だが、議論する価値はありそう

コメントを残す

あなたのメールアドレスは公開されません。必須項目には印がついています *

© 2022 Be full stack | WordPress Theme: Annina Free by CrestaProject.