私が開発者体験（DX：Developer eXperience）を大切にしたい理由
アイミツ開発チームでエンジニアリングをしている deliku です！
桜が満開になってきて、いよいよ春を感じられる季節になってきましたね！一方で気温の寒暖差が激しいので、体調を崩さないようにしていきましょう。
▶︎ 自己紹介
▶︎ 開発者体験とは？
Developer eXperience（開発体験） とは開発者が開発業務をしているときに経験する体験で、たとえば開発環境、組織、システム、そして評価体制が含まれます。
端的に言うと、ある物事を進める際に心地良く仕事をできていると感じることができるなら開発者体験は良いと考えられ、逆に開発を行うなかで不便を感じることがあるなら体験は良くないとなります。コードを書くことが日々のメイン業務のエンジニアの場合、快適にコーディングできているかは重要なポイントかなと思います。
ストレスなく作業できているか？
技術負債により改修コストの増加している
コードレビューに時間がかかっている
レガシーな環境で開発している
デプロイに時間がかかる
心理的な不安がないか？
CI/CD環境が整備されていない
コードレビュー文化がない
物事を進めることに対し、妨げる障壁が多くないか？
障害発生頻度が高く、修正コストがかかる
関係者が多くMTGが多いが、その割に進まない
etc…
▶︎ 開発者体験を向上することで得るものは？
下記の図に示す開発サイクルを高速で回すことができ、結果としてユーザへの価値提供を素早く訴求する近道となる（と私は考えています）。
なので、開発しやすい環境を自分たちで整備することはマストであり、それを維持するのは誰に言われるでもなく主体性をもって取り組んでいくこととして 自分ごと化 するのが良いと思います。
▶ システム部で取り組んでいること
▶ FindyTeamsの導入
生産性を可視化するために、Four Keys と呼ばれる概念を利用しています。Findy Teams で開発チーム単位で分析ができるように設定しており、チームや個人の振り返りに利用しています。
デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
変更のリードタイム - commit から本番環境稼働までの所要時間
変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
▶ MW / FW などの version up 対応
基本的に最新版に追従することで、セキュリティ対応 / パフォーマンスアップ / 新機能の恩恵を受けることができるので、サービスを安定運用するためにも継続的に行っていくべき作業と考えています。
▶ コードレビューしやすい文化の醸成
実装が完成してから Pull Request を作成すると、コード変更量が多くレビュワーが差分を読み解くのが大変なこと、実装方針が間違っていると作業の手戻りが発生したり、開発効率が悪いケースがでてきます。
なので、サクサクレビュー、サクサクマージできるように、タスクを小さく分解したり、指摘の温度感が伝わりやすいようにフォーマットを定めたりなど試行錯誤を行なっています。
▶ 爆速 CI/CD 環境を整備する
CI / CD に時間がかかっていると、mergeするまでに時間がかかり、
他の人がmergeすると、update branch をして最新のコードを取り込んでまたCIを実行して…と、これがチーム全員で発生していると、merge待ちに時間を費やすことになります…これは人によってはだいぶストレスに感じてしまいそうです…
直近にアイミツ開発チームのCIは7分ほど時間がかかっていましたが、チームメイトがジョブの分割やテストの並列実行を対応してくれて、2分程度に収まるようになりました。
▶︎ スクラム導入
不確実性に向き合うための how として、全ての開発チームで スクラムでの開発をおこなっています。
▶︎ テックコンパスの制定
行動指針に関する取り組みになります。ユニラボという同じ船に乗って、ビジョン達成を目指している仲間として、同じ方向をみているということは非常に大事かと思います。
▶ 【PR】ユニラボ に興味がある方へ
今回の記事を読んでユニラボに興味を持っていただけた方は、まずはカジュアル面談でざっくりお話させていただければと思います！
この記事が気に入ったらサポートをしてみませんか？