Developers Meetup 急成長ベンチャーが向き合う「開発生産性」参加レポート

これは何

こちらにオフラインで参加してきました。
LTで話されていた内容や所感をメモしていた内容とともにまとめています。

LT

「レガシーフロントエンドをリプレイスしたら開発生産性が向上しました」

Next.jsにリプレイスして得られたことについて、話されていました。
ルールとして定め、それを自動化していくことの大事さを改めて感じました。

• リプレイス前の課題
  • 開発環境のキャッチアップコストが高い
    • 環境が複数存在する
  • コミュニケーションコスト
    • OpenAPIなどがない
  • ディレクトリ構成
  • テストコードがないこと
• 向上させたこと
  • aspida × msw
    • aspida
      • 型安全なAPI開発ができる
    • msw
      • APIリクエストをインターセプトしてmockを返すライブラリ
      • これにより、APIがなくても開発ができた
  • 機能ごとにディレクトリを分ける(features)
    • スコープがわかりにくい
    • 移行戦略
      • ページごとの移行
        • Reactの実装箇所の多い箇所(移行コストの低い箇所から初めて、土壌を作る)
  • フロントエンドのテンプレート化
    • Hygenを利用
  • eslint
    • コーディング規約をルール化した
  • README、WIKIの充実
    • ドキュメントを読む時間を定期的に作る
      • 漏れに気づける
      • 新規参入者も、スムーズに開発を進められる

「創業5年目、組織変化と開発生産性向上の取り組み」

サービスが立ち上がってからおよそ5年、開発のプロセスをどのように改善してきたかについて話されていました。
今、何が成果を出す上で重要か、それを達成する上で、どのようにできることをどう考えるかという言葉が印象的でした。

• 生産性が高いとは
  • 少ないコストで大きな成果(コスト < 成果)
    • 成果: プロダクトが売れ続ける
  • ベロシティが一定である
    • 安定した価値提供
• 開発プロセスと技術の改善
  • リリース日が決まらない
    • ユーザー価値より、開発工数で考えてしまう
    • どう解決するか
      • 要件定義会
        • リファインメント前に実施する
          • 要求定義をもとに成果を最大化するためのhowを考える
      • Dailyリファインメント、プランニング
        • スプリントバックログのアイテムに対して実施
      • 見積もり精度の向上
        • 技術検証など行ったのち、見積もりを行う
      • 優先順位を上げづらい開発
        • 固定で時間を抑えて実施
  • SQLのテスト
    • DBに繋ぐテスト、繋がない単体テストに分ける
      • DB初期状態に戻す必要があるが、ライブラリの制約(TypeORM)により難しい
        • テスト実行のワーカー分DBを立ち上げる
          • jest の並列実行
  • ルールの自動化
• まとめ
  • 組織形態、規模でプロセスは改善し続ける
  • 技術的な改善は投資するとすると長く効果を発揮する

「開発生産性、上から見るか？下から見るか？」

認知科学の観点から、開発生産性について考える、興味深いアプローチ方法でした。
自分達が何気なくやっているような改善がしっかりとどういった効果をもたらすのかを言語化しており、とても参考になりました。

紹介されていたプログラマー脳は、自分も読もうと思います

• 課題
  • チームを横断したコミュニケーションコスト
  • 一人が扱えるコードの限界
    • コードを修正したときの影響範囲がデカくなる
    • 認知負荷が高い
• 認知負荷が高いをどう解決するか
  • 認知科学
  • 記憶の種類
    • 長期記憶(SSD)
    • 短期記憶(メモリ)
    • ワーキングメモリ
      • 脳が処理している間に覚えているもの
      • 考えている中で出てくるもの
        • 変数に何が入っている
        • どういった処理がされているのか
  • 認知負荷
    • 学習時、ワーキングメモリへの負荷が高すぎると効果的な学習ができない
      • 課題内在性負荷
        • ドメイン知識が非常に求められるもの
        • 覚えることが機能として多い
        • 扱いやすいサイズにする、小さくする
      • 課題外在性負荷
        • タスクの外部要因による難しさ
        • Rubyに慣れていない
        • コメントが陳腐化している
        • コードのフォーマットが整っていない
        • 極力小さくしたい
      • 学習関連負荷
        • タスクを遂行する上で必要な負荷
        • この負荷が高い状態にすることが望ましい
  • 認知科学もとに改善活動を体系化したい
    • 課題内在性負荷
      • 気になるコードをリファクタリングする
    • 課題外在性負荷
      • 自チーム意外のPRを見る
        • 長期記憶に留まる機会を増やす
      • 気になるコードをリファクタリングする
    • 学習関連負荷
      • テックな雑談をする
  • Four Key Metricsは、課題外性負荷の指標になる
• まとめ
  • Four Key Metricsで辛いを定量的に扱える
  • 課題の大きさからボトムアップ、トップダウンでできることを分ける

まとめ

事例をもとにした内容や、自分にない観点からのアプローチなどがあり、とても参考になりました。
成果のために自分ができることを考えるときに、こちらの内容を参考にしたり、取り入れたりしてみたいと思います。

また、オフラインの交流会もあり、スピーカーや参加者の方とコミュニケーションを取ることが出来たのは良かったです。
どんどん参加しよ