tobb422のブログ

スタートアップエンジニアの奔走

【レポート】開発戦略目線合わせ会を実施した

はじめに

現在、one visa というスタートアップでエンジニアをしています。
現在エンジニア5名で日々開発に取り組んでいるのですが、
開発戦略目線合わせ会というものを実施したので、その備忘録を書いておきます。

会の目的と概要

開発戦略目線合わせ会ってなんやねん
って感じかと思うのでざっくり説明します。

目的

会社の事業計画を考慮した上で、
今後(今回は1年先まで)の開発体制は、どういった状態であるか把握する
また、この会を通して、技術選定や日々の取り組みの指針を決める

概要

以下のようなアジェンダで取り組みました。

  • 自分たちが開発しているプロダクトの特徴を整理
    • ex:SaaSで、市場規模××、....etc
  • 会社の事業戦略を理解する(1年後まで)
  • そのために、どんな開発体制が必要かを考える
  • 必要な開発体制を実現するために必要な項目を洗い出す
  • 現在との差分から直近で取り組むべき内容を決める

以下、具体的にどんな話をしたかを書き留めておきます。

どんな開発体制が必要か

one visa の事業や今後の方針まで書いていると
令和になりそうなので(いま平成31年4月30日)省略します。

事業戦略から落とし込んでいくと、
事業拡大に合わせてチーム(数)が拡大したとしても、
スピード感を持って開発し続けていくこと
が最も重要な要素だということがわかりました。

当たり前だろと思われるかもしれませんが、
自分たちが目指している戦略から落とし込んで導き出したものなので、
メンバー全員が納得感をもっていて、なぜこれが必要なのかを説明できる状態になっていると思います。

開発体制を決めたことも重要なのですが、
それ以上に、
メンバー全員が納得感を持って、なぜこの開発体制が必要なのかを理解している状態
になっていることが非常に価値が有ることだと思っています。

必要な開発を実現するためには?

スピード感を持って開発し続けられる状態とはどんな状態でしょうか?
もう一つの目的である「日々の取り組みの指針」を定義していくことで深ぼることにしました。

そこで、
LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する
という書籍を参考に考えることにしました。
この書籍は、ハイパフォーマンス組織を実現するためには?という軸で様々な企業を分析した本で、
いろんな指標から、ローパフォーマンス組織とハイパフォーマンス組織の差分を考えることができます。

開発チームとしては、
ハイパフォーマンス組織 ≒ スピード感を持って開発し続けられる開発体制として、
深ぼっていくことにしました。

書籍では、以下4つを組織のパフォーマンスを測る指標として考えています。

  • デリバリのリードタイム
  • デプロイの頻度
  • サービスの復旧所要時間 
  • 変更失敗率

そこで、私達の開発チームでも
デリバリのリードタイムを短く, オンデマンドにデプロイが可能な仕組みづくり
を行っていくことが重要と定義しました。

まとめると以下です。
スピード感を持って開発し続けていくこと
1年後、要は、事業の拡大に合わせて、開発チーム(数)が拡大したとしても達成するためには、
デリバリのリードタイムを短く, オンデマンドにデプロイが可能な仕組みづくり
が必要であると判断しました。

f:id:tobb422:20190430225824p:plain
イメージ図
(上にいくほど、リードタイムが短い & デプロイ数が多いことを示しています)

現在との差分から直近で取り組むべき内容を決める

スピード感を持って開発し続けられる状態
ボトムダウンして、↓↓↓
デリバリのリードタイムを短く, オンデマンドにデプロイが可能な仕組みづくり
を直近の目標としたわけですが、もう少し深掘りしたいと思います。
上記を達成するための指標は、以下の2点です。

  • デリバリのリードタイムを短くする
  • オンデマンドにデプロイが可能な体制作り

■ デリバリのリードタイムを短くする

  • 要件定義・設計のしやすさ
  • コミュニケーションの質
    • 適切な権限委譲
    • 文化の醸成・価値観の共有
  • 実装速度
    • 変更の加えやすさ
      • コードの質
      • 疎結合なアプリケーション設計
      • テストの自動化
    • 個々人のスキルアップ

■ オンデマンドにデプロイ可能な体制

  • 職種の分割されていないチーム構成
  • 疎結合かつ凝集度の高いアーキテクチャ設計
  • CIの整備
  • デプロイの自動化・簡略化
  • インフラ環境のスケーラビリティ
  • モニタリング(プロアクティブな通知)

初めに比べて、だいぶ何をすべきかが見えてきたように思います。

既に施策になっているものを明文化

  • デザイン・フロント・バックエンドと職種を超えたアジャイルの実施
  • 変更のしやすさ・CIを意識したテストの自動化・TDDの促進
  • インフラ環境のスケーラビリティを考慮したコンテナ化の促進

上記に加えて、1年間で行っていくテーマ

  • 文化の醸成・価値観の共有
  • 疎結合かつ凝集度の高いアーキテクチャ設計・アプリケーション設計
  • テストの自動化・CIの整備

特に意識したい具体的な施策

  • テスト方針の明確化・カバレッジ向上
  • 設計の議論やコードの品質アップを狙った、専門チームでの取り組みの活性化
  • 事業戦略を意識したアーキテクチャ設計
  • (ワークレビューやペアプロによる個人のレベルアップ)
  • (マイクロサービス化に伴うCI/CDの整備)

まとめ

結果やることは、

  • テスト書く
  • 設計を大切に

といった具合に、結構当たり前なことになりました。
現在の開発チームでも、これらは日頃から意識して行っていることです。
もちろん、詳しく
テスト方針(単体テストカバレッジ率を◯◯にするなど)や
アプリ設計にレイヤードアーキテクチャを取り入れよう!など
より詳細な話をこれからしていく必要があるのですが、
今回はそれ以上、
事業戦略から落とし込んで、日々やることにWhyをもたせることができたこと
一番の収穫だと考えています。
(それに加えて、ある程度注力すべき方針が見えたことも収穫です!)

以前、開発思想を決めたりと、
価値観のすり合わせは日頃から行っている開発チームだと思うのですが、
今回の会では、
それらの価値観や普段の業務(特にリファクタ系やテスト系)が事業に直結していると再認識できる会になったのではないかと考えています。