エンジニアとして業務を行う上で意識しておきたいこと

準備編

やらないといけない作業を書き出し、工数を見積もる

• 箇条書きで書き出して、知見のある方と議論してみる

とにかく小さく始める

• どうすればシンプルになるのかを考える
• 広げすぎると工数がかかりすぎて、エンジニアの負担が増えるか開発が完了しない状態になる

問題・課題に取り組み際には、まずあるべき姿を考える

• ギャップアプローチ
  • 問題の発見
  • 問題を起こしている真の原因を見つける
  • 対策を考える
  • 解決する
• ポジティブアプローチ
  • 何を検討するのかテーマを明確にする
  • あるべき姿を定義する
  • あるべき姿の実現方法を考える

見積もり編（整備中）

求められているものを把握する

• 技術検討編
• 開発着手編

完璧を求めるのではなく、議論できる材料を用意する

コミュニケーション

進捗報告の粒度を細かくする

• タスクを「最低限動く状態」まで細分化することで報告で進み具合が可視化される（1週間ずっと「XXXの実装をしてます」だと伝わらない）
• 報告テンプレ
  • 昨日やったこと
  • 今日やること
  • 困っていること

質問は提案ベースで行う

• 丸投げすると相手はゼロから考える必要があり、大量のリソースを消費する必要がある
• 未完成であっても、形ができていればより具体的なアドバイスを受けることができ議論が有意義なものになる
• 無理矢理でも作る
• 「A機能のDB設計をどうすれば良いのかわからないのですが、どうしたら良いと思いますか？」から「良い例）A機能のDB設計について、XXという理由でXXな感じにすれば良いと思うのですがいかがでしょうか？」に質問を変える

共有する際は前提資料も一緒に添付する

• 質問や共有する場合は、前提資料や対象の資料のリンクを一緒に送ってあげると探す手間が省けるため相手のリソースを最小限に抑えることができます

開発編

不確定要素の強いタスク・待ち状態が発生するタスクから実行する

• 不確定要素を残していると終盤で大きめの手戻りが発生する可能性がある
• できることから先にすると待ち状態が発生するタスクに着手した際に、無駄な時間が発生する

プルリクは小さく作る

• 変更内容が多いと考慮することが多くなり必ず漏れが発生する
• スプリントごとに中間ブランチにマージする
• 運用手順
  • 中間ブランチを作成
  • エンティティなどの構造体だけのプルリクを作成（構造が変わると処理が変わる）
  • 具体的な処理を実装

まず動くものを作る

• 最初の段階では考慮漏れがあり、実装を進めていく中で考慮漏れに気づくことがある
  • 例）実はここも影響範囲だった、当初想定していた設計では実現できないかも？
• 早い段階で考慮漏れに気づくという

エンジニアにはコードベースで会話する

• 試作品などをプルリクに上げて、ファイルチェンジで会話する