好む振る舞い#

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

Soft Skills#

プロであれ#

• エンジニアである前に社会人。約束を守る・時間を守る・気持ちよく仕事をする
• 残業をしないしさせない。健康に、サステナブルに成果を出せる方法を考える
• プロダクトを良くすることにベストを尽くす
• フルサイクルでありたい。「自分の仕事じゃないから」とスルーせず、プログラミング以外も可能な限りなんでもやる
  • Miletos エンジニアマニフェスト

リモートワーク#

• 情報が然るべき方法で「公開・整理・配信」されている状態を目指す ref: 社内向け「透明ガイド」を公開します｜ sonopy@Ubie Discovery
  • フロー情報として作業は GitHub Issue に常に書き連ねる ref: Working Out Loud
  • ストック情報として知見や共有事項はドキュメント or Custom Linter に昇華する
  • コンテキストを追えるよう可能な限り参照を張る。「このタスクがなぜ必要になったのかわからない」という状況を作らない
• 基本非同期コミュニケーションとし、タイムゾーンを気にせず進められるようにする
• チーム API を定義し、自身のチーム・他チームが協調しやすい状況をつくる: 30 分で分かった気になるチームトポロジー | Ryuzee.com
• 地理的距離が離れているからこその雑談の時間を大事にする

ミーティング#

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

コミュニケーション#

• 結論から話す
• 文章は要点だけに絞り平易な言葉で
• 前提認識のすり合わせと、事実・主観・主張を明確にする
• 配慮はするが、遠慮はしない

Product Development#

Issue driven#

• 理想状態をまず定義する。制約やリスクと比較し最善を尽くす
• お客様への価値貢献を最優先する

チーム開発#

• HRT(謙虚・尊敬・信頼)を持って働く
• 検査・適応・透明性を大事にする ref: The Scrum Guide
• 人ではなく事に向かう 邪推をしない
• Fail Fast 早期に失敗できる状態を作る
• 集中状態にあるタスクがない場合、PR などのレビューを最優先タスクとする ref: コードレビューのスピード
• 「引き継ぎ」をなくすように働く 怪我や病気で自身が突然離脱しても業務が回る状態に保つ
  • 適切なドキュメンテーション、作業や残タスクの可視化
• 声を上げた人のフォロワーになる、リアクションをする ref: チームで仕事をするなら、リアクションし続けよ｜森 一貴（Mori Kazuki）
• この資料に記載していることをは自身のポリシーであり、違う意見があることは当たり前である

Ops#

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

Engineering#

開発#

• 全ての開発は理想のインターフェースから始める
• ロジックはテストを書く、書けないなら書けるように責務を分割する
  • バグの恒久対応はテストで表現する
• コーディングスタイル(インデントなど)のレビューは一切せず、linter や formatter に従う ref: Why Prettier? · Prettier
  • 人間のレビューを減らすために linter を積極的に整備する
• ビッグバンリリースはせずフィーチャートグルを利用する
• OSS やコミュニティに積極的に還元する

意思決定・技術選定#

• ADR(Architecture Decision Record)を積極的に書く
  • 理論的根拠に対する強固な共通の理解を作るため
  • できないこと（制約・リスク）を具体的に書き、許容できるかを判断できるようにするため
  • チーム開発における技術選定の進め方 - ROUTE06 Tech Blog
• 今しなくて良い意思決定は可能な限り遅延させ、情報を集め最適な選択肢を選べるようにする ref: リーン開発での『決定を遅らせる』がやっと理解できた話 - 無気力生活 (ノ ´ω ｀)ノ ~゜
• 社内フレームワークではなく主流な手段で解決し、キャッチアップと採用を容易にする
  • 主流な手段は世の中の情報量も多く、ChatGPT のような LLM を利用した問題解決も容易になる

Git, Commit, Pull Request#

• トランクベース開発やGitHub Flowを採用し、1 日に複数回以上デプロイを行う
• PR は誰がいつ見ても理解できるような粒度でコンテキストを記載する
• 想定される質問に対して全て置き回答してからレビューを依頼する
• commit は cherry-pick で価値を生む単位
• フィーチャーブランチに対する Force Push はコミットの整理のために活用するが、レビュー開始後は行わない
• コミットメッセージの言語は社内の公用語やプロダクトの利用ユーザーの言語に合わせる
  • 日本人向けのプロダクトにも関わらず英語で書くことに価値は低いと考える

SaaS#

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