職業としてソフトウェアエンジニアをやってきてわかってきたこと

今までのソフトウェアエンジニアとして拙い経験からわかってきたことリストです。 思いついたものを箇条書きで書いています。 その考えに共感するきっかけとなったリンクあるいは参考になるリンクがある場合はそちらも併せて貼っています。

  • デプロイ回数を増やすことはいいことがたくさんある

NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話 - Uzabase for Engineers

  • 採用で妥協しない方がよい

最近だとback checkというリファレンスチェックサービスを使う会社さんも増えてきたように思います。

リファレンスチェックは、書類選考や面接だけでは分からない採用候補者の経歴や実績に関する情報を、候補者の上司や同僚といった一緒に働いた経験のある第三者から取得することができるサービスです。候補者をよく知る他者からの評価のため、より客観的な視点を含めて採用候補者の適性やチームとの相性を判断することができるようになります。

back check（バックチェック） | 実施数No.1のリファレンスチェックサービス

  • DX Criteriaはやった方がよい

年に2回程度、チームビルディングをする機会などにやると足並み揃えやすいんじゃないかなと思ったりしてます。 DX Criteria (v202104)

  • イミュータブルにできるものはイミュータブルにしておくとよい

ECRリポジトリのタグ〜アプリケーションコードもイミュータブルにできるところはしておくとバグを減らせることが多いです。

テックリードというと技術選定や専門性を求められる意思決定に責任を持つ、チームメンバーの技術的な底上げに寄与するというイメージがありますが 会社の方針や会社のフェーズ感によってはピープルマネジメントを求められることもあると思います。

  • テストコードをちゃんと書くとよい

バージョンアップしやすいように、リファクタリングしたときに壊れたことを安全に検知できるように。

  • E2Eテストという単語は文脈によって意味が大きく異なるので注意する

Autify、cypress、Ruby on Railsでいう（System Spec）など様々な文脈でE2Eという言葉が使われている。 今議論しているEnd-to-Endはどこからどこまでなのか意識すること。

  • ライブラリの採用は作者の思想に協調できるかが大事である

36. [後編] You have commit bit! w/ songmu | fukabori.fm

  • チーム開発におけるコミュニケーションや部署間の調整はコミュニケーションパスを意識するとよい

組織におけるコミュニケーションパスの問題 - セカイノカタチ

  • ステージング環境は多くの場合不要かもしれない

毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba

  • フィーチャートグルを活用するとよい

新機能をリリースするときにビッグバンリリースをしない。 フィーチャートグルを活用することで段階的にリリースを実施する。

  • 絶対見積もりをしない

納品のない受託開発を詳しく知る - SonicGarden 株式会社ソニックガーデン

不安とストレスから解放される見積りとスケジュール方法 - Qiita

  • チームメンバーを信頼、尊敬し、謙虚に振る舞うとよい

『Team Geek』を読んだメモ - Qiita

  • 転職市場での自分の立ち位置を定期的に確認するとよい

  • 何も設定してないけどデフォルトでそこそこ動くツールは普及する

例: VS Code、Next.js

  • DBに対するイレギュラーなオペレーション操作もバージョン管理するとよい

GitHub issue上で実行予定のコマンドおよびSQLをレビューしない。リポジトリにスクリプトをコミットし、レビューを通す。

  • 本番環境をカジュアルに直接操作しないようにするとよい

Zero Touch Productionとは何か | Taichi Nakashima

  • チームで開発から運用までの全ての工程を担当できると効率がよい

例: 「You Build It, You Run It」、「Full Cycle Developer」

  • 技術は手段であってもいいし、目的であってもいい

他にもたくさんありそうですが、疲れたので 今回はこのぐらいにしておきますﾉｼ