システム現状分析と再構築プラン

現状分析

• 古いシステムがありそちらはクローズをしたい
• 何かしらの追加をしたい時に時間がかかりすぎる
• サーバーダウンする

組織的な問題

• 経営者が開発に関与しすぎ
• システムの裏側の負債の問題について無視しすぎ
• 社員の業務生産性について目を背けすぎ

システム上の設計問題

• 運用効率の悪さ
• 自動化の未完成
• データモデリング
• Rubyパフォーマンスの悪さ
• AWSの設計の可用性の低さ
• コストの悪さ

SIerの方法だと

• ビッグバンリプレイス
  • Rails→他言語へのリプレイスして全部置き換え
• 言語の総置き換え

捨てた選択肢

• 細かい要望を止める
  • 窓口を減らし
  • 開発者の窓口をPMにしてもらう
    • PMから開発者へ相談をしてもらう
    • 営業やサポートはPMに介して開発者への要望をしてもらう
      • その間開発者は業務を効率化させる
      • システムの直し

実践するべきと判断したこと

• システム開発の主導
• 負債の返済
• 業務生産性を上げるための業務自動化

やること

• AWSサーバーを冗長化して可用性を上げる
  • EC2インスタンスを冗長化
    • オートスケーリンググループを作成してオートスケールする
    • 障害に備えてDR対策
      • フェイルオーバーの仕組み
        • アクティブ-パッシブの構成
        • 最小構成で置いておく
          • 稼働したら自動スケール
  • DBをレプリケーション
    • 読み取り専用と書き込み専用で分ける
    • マルチAZにする
  • サーバーをコンテナ化
    • EC2インスタンスからECSへの移行
    • デプロイはECRへDockerイメージを置く
  • コスト最適化のためのサーバーレス化
    • 管理者操作のDBはAuroraServerlessで局所的な使用方法にする
    • リザーブドインスタンスで1〜3年のEC2インスタンスの契約をする
      • コアドメインはEC2インスタンス
    • 送客ロジックをコンテナ化
      • Lambdaで運用15分稼働とコールドスタート
      • 分離したロジックの言語は自由にしてよい
      • Python ? Go ?
      • API化してAPI通信＋メッセージキュー
      • SQS,  RabbitMQ
    • キューイングシステムを再構築
    • 冪等性を確保
    • 状態管理テーブル
    • Gemでsidekiq-unique-jobs
  • 運用を効率化
    • サーバーのフルマネージド化
    • Aurora、ECS/Fargate、Lambda、DynamoDB
    • 可観測性
    • フルマネージドにするためEC2ストレージに直接吐いていたログを集約
    • Fluentd、CloudWatch
    • デプロイの自動化
    • CodePipeline？
    • Github Actions?
    • 日々の作業で非効率的な手動の作業を減らす
      • トイルの削減
      • バッチ化
      • スケジュールではなく分離していく
• パフォーマンスを測定してボトルネックを解消する
  • DataDogを使用して、クエリを特定
    • Explainなどでスロークエリを分析
  • gem BulletでN+1の発生しているActiveRecordを抽出
    • ActiveRecordが作るクエリを分析し、ボトルネックを探す
      • N+1修正をしてボトルネックを解消
• DB設計をしてデータモデルを再構築する
  • 負債によって一番開発効率が下がっている部分を特定
    • コアドメインのデータモデルを再構築する時間を取る

開発プロセスにこだわってしまう罠。それよりも組織を変える必要性

 開発プロセスにこだわりすぎて開発がうまく進まなかったという経験があり、一方でその後きたCTOによりCEOを開発会議から外し、開発チーム＋PdM(ビジネス層代表)と開発チームオンリーの会議の2つに分けて会議体を作ったことで見事ビジネスと開発を分けて疎結合にしたということがあり、なるほどと思ったことがある。

それまでは私が開発プロセスを何とかして上手く動かしたかったのだが、全然上手くいかず困ったので記録を残しておきたい。

開発プロセスは大きく分けるとアジャイルとウォーターフォールがある。

ウォーターフォールはSIerなどベンダー企業がユーザー企業から依頼を受けてシステム開発をする際にソフトウェアを工業製品に見立てて、製造業のプロセスをそのまま当てたことで始まったとされている（確かではない）。

それだと上手くいかないよねということで2000年代からアジャイル開発が考案されて、以降、シリコンバレーやWeb業界ではアジャイル開発が主流となっていた。その中でもXP開発やスクラム開発などあり、私が前いたベンチャーではスクラム開発を基に開発を進めていた。

スクラム開発はガチガチにやろうとすると開発が遅くなる。このスクラム開発をガチガチにやろうとし過ぎて、開発者たちからは反感をくらい、経営層の要望を上手く開発に落とし込むこともあまりうまくいかずにとても四苦八苦したと思っている。

ビジネスの要望ばかりを叶えようとしてシステムの重要な要件を満たせていないということがあり、ずっとその会社ではシステムの要件を満たせていなかった。そのため、技術的負債が溜まりに溜まっていた。

システムの重要な要件というのは、運用の自動化やしやすさ、パフォーマンス性、変更容易性、セキュリティ、コスト最適化、スケーラビリティ、信頼性など。

参考：AWS Well-Architected

ベンチャーの経営者はわがままである（『経済評論家の父から息子への手紙』著 山崎元）。

どこのベンチャーも多分そうで、相当ソフトウェア開発に力を入れている企業でなければ（個人的には、例えばLayerＸ、カミナシなど）、多分どんなベンチャーだって経営者は必死で企業を利益を立たせるために開発者にベンチャー精神を要求し、システムは崩壊している。

参考：開発者体験が良いイメージの企業

ビジネスと開発はある意味グラデーションのように仲介を挟まないと直接ビジネス要件を満たそうとしてえらいめにあう。あるいは開発組織が飲まれているのが実際だと思う。

参考：Cultural Capital Theory in Software Engineering

ベンチャー企業に入り開発プロセスを固めようとしても上手くいかず、CTOが入り、社長が会議に入らないようになってから開発が上手く回り始めたことも目にして、開発のプロセスにはこだわらず、組織構造を変える必要があると思った。

開発プロセスをこだわろうとしても多分ほぼ何も整っていないカオスなベンチャーでは無意味で、経営層に対等に話せる立場が必要、もしくは開発者たちが強くビジネスの要望に対してPdM、PMの意識を持って接することが大切だと思った。