忙しすぎるエンジニアのための開発環境リファクタリングガイドに参加してきました！

忙しすぎるエンジニアのための開発環境リファクタリングガイド

https://dev.classmethod.jp/news/devops-webinar/

11/7（火）にクラスメソッド株式会社が主催する、「忙しすぎるエンジニアのための開発環境リファクタリングガイド」のセミナーに参加してきました！

リファクタリング

リファクタリングとは

外部からみた動作を変更せずに既存のコード本体を再構築しその内部構造を置き換えるコーディング技術

その手段として

• Automation（自動化）
  • 反復的な手作業の排除
  • 再現性・正確性の向上
• Lean（リーン）
  • 継続的な改善を前提
  • 最小限の範囲から段階的に
• Measurement（測定）
  • 現状の状況把握・可視化
  • （詳細よりも大局を意識）

Automation

Automation（自動化）の定義

高度に自動化された手段によって、ひとの介入を最小限に抑えつつ手続き(プロセス)を操作または制御する技術‧方法‧システム

❌（スクリプトなどで）自動化すること

⭕️ 手動で作業を最小化すること

分かりやすそうな例

1. オンプレミス→クラウド

   メリット

   • APIによるリソースの調達や破棄それにかかる時間の削減
   • 責任共有モデルによるインフラ運⽤のアウトソース

   デメリット

   • クラウドの流儀にあわせた設計が求められる

2. Git + CI/CDの導⼊

   メリット

   • 集中型VCSのような排他コミットの脱却
   • 脱ビルド職⼈‧デプロイ職⼈
   • ⾃動的なテストの実⾏

   デメリット

   • 開発スタイルをGitを中⼼としたものに移⾏する必要

つまり

「手動で行う作業を最小化すること」によって...

• 人的要因による事故やミスを抑制→正確性‧再現性が向上
• 作業時間‧実行時間の短縮
• 作業手順の永続化 (属人スキルからの脱却)

Automation（とその考え方）によって

不要になるもの

• 生産性の低い作業のために必要な工数・時間
• 手続き上の非効率性
• 手作業のため発生する結果や品質のばらつき（作業者に依存する要素も）

もたらされるもの

• より価値を生む機能実装のための工数・時間
• （より自動化に適した）シンプルな手順・フロー
• より高度な信頼性と再実行性(再現性)

より端的に言えば、

つらいところ→解決策（ソリューション）

課題

やるべきところ‧できるところはもうやっているので、それ以上は...

• 手を付ける時間がない‧惜しい
• 実装時間を考えると結局手作業が早い
• 自動化することで抽象度があがる、メンテしづらくなる
• ツールの導入コスト (工数的‧費用的‧学習コスト) が割に合わない

ここからさらに自動化を進めるには？→Leanという概念の実践

Lean

Lean（リーン）の定義

• 継続的な改善に努める
• (その際の)失敗を受け入れる→「不具合の早期発見‧早期対処」

つまり

• 継続的な改善の実行が前提
• 大局的にみて「目的地」を設定
• 小規模のところから段階的に
  • 対象プロセス‧ステップ
  • 対象システム
  • 関わる組織‧メンバー人数
• 効果を見極め、「うまく行かないところ」は次で修正
• 既に改修したところも、効果が見込まれるなら「フェーズ 2」へ

例：クラウドジャーニー

クラウドへの移行

• 新規サービスの開発にあわせて
• 特定の機能セットから
• まず PoC‧検証環境を

…等々

いきなり大規模に導入せず段階を経て移行していくことが一般的なプラクティス

Blast Radius（不具合発生時の影響範囲）

他に影響の及ばないところを部分的に切り出して、他に影響が及ばないように小さく始める

切り出せない→タスクの密結合

→疎結合化できないか検討を

Lean→「継続的な改善に努める」

自動化して終わりではない

→「やっている時間が無い」からこそ持続可能な範囲で試行・遂行することが重要

分けて考える

機能的な仕組みによる機能の開発

本来人の手で行うべき機能を機械化(自動化)する

• 中〜大規模な機能開発
• 耐用年数も⻑くなる
• 他のシステムと同様の品質(信頼性)が求められる

自動化による手順の効率化

機会的手段に置き換えることで全体的な手順を効率化する

• 小規模
• 継続的な置き換えが前提
• 過度の作り込みよりスピード感が求められる

どちらの「自動化（Automation）」が求められているのかの見極めが必要！

Think big, act small

問題の重大性を覆い隠すようなスクリプトを書くことは、本当の問題を修正しないため中⻑期的には無駄であり、さらに潜在的には後にもっと問題を引き起こす要因となりえます。

• いま行っている「マニュアル作業」をそのまま自動化
  →その作業の本質が覆い隠される危険性
  • 自動化しようとしているその作業、最初は（本来は）ワークアラウンドのはずではなかったですか?
• 全体(big)をみた上で、なるべく局所（small）的な変更‧導入を心がけましょう

課題

Automation ≠ 省略化 = 信頼性の向上

信頼性が上がれば、運用コストが下がり、結果として余裕が生まれる

どこから着手すれば？その効果は？→**Measurement（計測性）**の重要性

Measurement

計測（Measurement）の目的

• 現状の把握、ならびにリファクタリング可能‧必要な場所の特定
• リファクタリングによる効果の測定
• リファクタリングによる影響の検知

計測（Measure）= 記録（Record）

いま（現状）がどうであるかを正しく理解・把握するための行動

計測しないと…

• 今がどうなっているかわからない
• →過去と差もわからない、将来も予測できない

Measurement（計測）すべきもの

システム

• アプリケーションの挙動

  →APM（Application Performance Management）

• インフラ/システムの挙動

  →システム監視（CPU/メモリ/システムログ etc…）

• 実行環境の挙動の監視（異常の発生→即時アラート）

それ以外

• Code
• Review
• Build
• Test
• Deploy

SDOパフォーマンス指標（DORAメトリック）

種類	指標	説明
速度	Lead Time for changes	コードのcommitからデプロイまでにかかった時間
速度	Deployment Frequency	どのくらいの頻度でエンドユーザ向けのデプロイをしているか
安定性	Change failure rate	デプロイが原因で発生した障害（Change failure）の発生率
安定性	Time to restore service	Change failureからの復帰に要した時間

計測（Measure）≠ 監視（Monitor）

監視（Monitor）：目的を持って閾値を設定、超過/下回ったら警報

計測（Measure）：「今がどうであるか」の測定

具体的な解決策について

5W1H

What：開発環境のリファクタリング

Where：Measurementで把握し決定

When：ツールや自動化で代替し、捻出した時間を利用

Who：

How：Leanの考え方でAutomation

Who（誰が）

選択肢

1. 現場主導・ボトムアップ
2. 組織主導・トップダウン
3. 専任組織

現場からのボトムアップが有効かつ効果的

継続利用・中期的検証の観点

トップダウンを行う場合：

有志による自発的な発展が期待できるところから

より現場に即したところで行うことが理想的

How（どのようにして）

Automationの候補（リファクタリング視点）

積極的

• SaaS（Software-as-a-Service）
• マネージドサービス（クラウドプラットフォーム提供）

次点

• OSS+既利用インフラ
• ノーコード・ローコード開発

条件付き（小規模）

• チーム内の標準言語・環境による開発

SaaS・マネージドサービス推奨

SaaS を使えば数分で動く仕組みが手に入り、しかも始めたタイミングからドキュメントなども手に入ります。

本来やりたいこと「以外」にリソースを割く必要がない

• 「Out-of-the-box」ですぐ使える
  • ドキュメントも揃っている
• インフラも運用も込み
  • メンテナンスや障害対応に工数を割かなくて良い
• ツール側で勝手に進化
  • 意図しない進化のリスクも
• 「継続的な見直し」がしやすい
  • 利用契約（OpEx）が多い
  • 買い切り（CapEX）ではない

（もちろん）自作やOSSが適したところも

気をつけたいこと：

• メンテナンス耐性
  • ドキュメントの用意・整備
  • バージョンアップ
  • 制作者以外はメンテできない、などとならないように
• メンテナンス負荷
  • 動かなくなった時の対応工数
  • 業務に対してどのくらいクリティカルか？

具体的なSaaSソリューション

Snyk：コード品質向上によるセキュリティの確保

脆弱性を作り込まないコーディング環境の実現

• SAST (コードの静的解析)

  • IaC にも対応

  • コードレビューコスト削減

  • IDE連携

    開発しながら学習効果

• SCA (使用OSSのチェック)

  • Log4jのようなOSS由来の脆弱性にいち早く対処
  • コンテナにも対応

• レポート機能も充実

New Relic：開発者目線の可観測性プラットフォーム

「良質のアプリケーション」を作るためのモニタリングツール

• ビジネスメトリクスやアプリケーションの性能を可視化
• インフラの監視機能も充実
• 開発コラボレーションツールCodeStream を内包
• Root Cause Analysis
• ログ分析や脆弱性管理機能も

可観測性（Observability）

システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度です

Terraform：業界標準‧横断型 IaC フレームワーク

GUIベースの構築手順から脱却 GitOps実現の第一歩目

• 構築手順をコードがすれば...
  • 改修や横展開もスムーズ
  • SASTによるチェックが可能
  • ディザスタリカバリにも効果大
• 非常に多くの製品に対応
  • AWS, Google Cloud,New Relic, Mackerel ...

まとめ

SDLCで「継続的」に組まれている以上、 開発環境は「アプリケーション」の大切な構成要素
開発環境のリファクタリングを進めるには:

• 『Automation』を適切に順次導入
• 実施においては『Lean』の概念を念頭に
• 計画と効果測定のために『Measurement』を
• 効果を最大限に発揮させるためには『Share』と『Culture』も必要