🚲

好む振る舞い

💡

この資料は、宮城広隆が自身が働く上で良しとする振る舞いを言語化しまとめています。 他の方に強制するものではなく、宮城と働くイメージをしやすくする用途を想定しています。

Soft Skills

リモートワーク

  • 情報が然るべき方法で「公開・整理・配信」されている状態を目指す ref: 社内向け「透明ガイド」を公開します|sonopy@Ubie Discovery
    • フロー情報として作業はSlackに常に書き連ねる
    • ストック情報として知見や共有事項はドキュメント or Custom Linter(ex: sider)に昇華する
    • 意思決定は後から見返せる状態で公開する
  • 基本非同期コミュニケーションとし、タイムゾーンを気にせず進められるようにする

ミーティング

  • Google流、会議をより効率的にする秘訣とルール
    • 可能な限り短時間にする
    • 情報共有ではなく意思決定の場とする
    • 24時間前までに資料を用意し共有、認識合わせが済んだらすぐ本題に入る
  • 顔を出す。所作や表情によって相手に与える情報量を増やす

コミュニケーション

  • 結論から話す
  • 文章は要点だけに絞り平易な言葉で
  • 事実と主観を明確にし発言する ファクトベースで話す
  • 相談する際は「自分だったらこうする」ようなたたき台を用意しておく

Product Development

Issue driven

  • 理想から逆算する
  • ユーザーファースト
  • 短期的な解決で全体が損なわれるならやらない

チーム開発

  • HRT
  • 検査・適応・透明性 ref: The Scrum Guide
  • Fail Fast
  • 集中状態にあるタスクがない場合、PRなどのレビューを最優先タスクとする ref: コードレビューのスピード
  • トラック係数を上げる 個人に依存せずチームに依存する
  • 前にことを進めようとしている人のフォロワーになる
    • チームメンバーの課題提起がスルーされないように、可能な限り反応する
    • メンバーの仕事を褒める みんなえらい
  • 「自分ごと」の範囲を広げ、相手の立場を理解することに努める
  • この資料に記載していることをは自身のポリシーであり、違う意見があることを理解し受け入れる

Ops

  • You build it, You run it. ref: A Conversation with Werner Vogels
  • ランタイムやライブラリのアップデートが苦しくならないように投資する
  • トイルは山積みになり続けることが多いが、レバレッジが効く順序を検討し技術で解決していく

Engineering

開発

  • 全ての命名を考え抜く naming-cheatsheet
  • エッジケースを全て試す
  • ロジックはテストを書く、書けないなら書けるように責務を分割する
    • バグの恒久対応はテストで表現する
  • 社内フレームワークではなく主流な手段で解決し、キャッチアップと採用を容易にする
  • コーディングスタイル(インデントなど)のレビューは一切せず、linterやeditorconfigに従う
  • ビッグバンリリースはせずフィーチャートグルを利用する
  • OSSやコミュニティに積極的に還元する

Git, Commit, Pull Request

  • PRは誰がいつ見ても理解できるような粒度でコンテキストを記載する
  • 想定される質問に対して全て置き回答してからレビューを依頼する
  • commitはcherry-pickで価値を生む単位

Rails

SaaS

  • ビジネスのコアではない部分についてはコードを書く前にSaaSでの解決を検討する 車輪の再発明はしない
  • 価値が説明できるのであれば有料でも導入できるよう交渉する