システム改善の進め方
この記事では具体的なテクニックや、技術的な各論の話ではなく、システム改善を進めていくための「手順」や「考慮すべき事項」について抽象的にまとめます。
今まで同種の事は仕事の場で実践してきていたのですが、あまりフレームワーク的なものに落とし込めてませんでした。今回とあるきっかけで自分なりに整理した内容を、こちらでも記載します。
大事なポイント
システム改善を進めるに際しては、必ず明確にしておかないといけない大事なポイントがいくつかあります。
これらの点が明確になっていないシステム改善作業は、実施をしてもあまり有意義な結果を生まない可能性があります。
・モチベーション
・インパクト
・エビデンス
・ゴール・スケジュール
・デザイン
以下では、ひとつずつ説明していきます。
モチベーション
なぜこの作業を実施するのか、の背景。
基本的に、システム改善をしたいという事は何かしらのシステム的課題を抱えているわけで、その課題を解消することが作業の目的となります。
なので、基本的には、抱えている課題を洗い出すことが作業になります。
・会社で定めた基準に満たない
・SLO/SLI を満たせない、等
・性能面の問題により障害が発生している
・バッチ処理が制限時間内に完了しない、等
・ビジネス上の課題に直面している
・顧客からのクレームが寄せられている
・潜在的な Churn 要因になっている、等
インパクト
この課題が残り続けていることで、システムやビジネスにとってどのような「悪影響」があるか。
もしくは、この課題が解決することで、システムやビジネスにとってどのような「良い事」があるか。
課題がビジネスやサービスに与えるインパクトが少ない、もしくは無い場合、そもそもシステム改善作業を行う必要が無い可能性もあるため、あらかじめ整理をします。
・e.g. DB 移行作業を進めるためには、特定のバッチの実行時間が ◯◯分以内である必要がある（これが達成できないと移行できない）
・e.g. 平均レスポンス速度を◯◯◯ミリ秒以下に抑えることで、売上を◯◯％向上することができる
概ね、「インパクトと」、後ほど説明する「スケジュール」を組み合わせて ４象限のマトリクス で優先度の判断をすることが現場では多い印象です。
端的に言うと、インパクトがあり、かつスケジュール期限が迫っている（その日までに対応しなければいけない）ものが最優先になり、プロジェクトの体制の組み方なども特別扱いとなることが多いです。
インパクトが無いものは、利害関係者との兼ね合いなどで対応しなければいけないものもありますが、そういったしがらみが無いものについては本来は対応不要なことも多いです。
エビデンス
システムの抱える具体的な問題点・課題を指します。
エビデンスは、定性的ではなく定量的である必要があり、推測ではなく再現性のある証拠・証跡が存在している必要があります。
システムに性能的な課題があるとして、どこに問題があるのか。端的には どこの部分の処理が遅いのか。
それはどのように特定・証明されるのか。再現条件はどのようなものか。等々。
問題点について曖昧にせず明確にするプロセスを踏むことで、改善箇所を明確にし、システム改善作業の効率性や成功確率を向上させることが目的です。
ローカルの環境で検証できるような課題の場合は、速度を測定するツールやプログラムを用いた「閉じた環境」での検証も可能と思われます。
ただ、多くの場合、実際のシステム上での稼働状況を元に特定をする、というのが現実的な手法になります。
エビデンスの特定のためには、たとえば以下のような情報が必要になります。
・ログ
・アクセスログ
・アプリケーションログ
・SlowQuery Log、等
・各種メトリクス
・HTTP ステータスコード
・レスポンスタイム
・トラフィック・データ量、等
・APM やプロファイラの分析結果
・e.g. Datadog / NewRelic 等を用いた分析
・負荷試験・性能試験の結果
なお、問題点を特定する際に、ソースコードの中身だけを静的レビューをして問題点を特定しようと思ってはいけません。
現代のシステムはとても複雑で、関連するシステムの数も多く、コンピューター上で起こってる事象や発生している課題を特定のソースコードのコードリーディングだけで判断することは基本的には難しいです。
どんな熟練のエンジニアであっても、 「職人の勘」 に頼ることは今の時代では非効率ですし、あてが外れることも多いです。ツールやログなどから分析したエビデンスをベースに、改善作業は実施するべきです。
ゴール・スケジュール
課題が、どのような基準をクリアすると達成したことになるか（ゴール）。
もしくは、いつまでに改善を達成しないといけないか（スケジュール）。
について定義します。
別の言い方をすると、作業の 「終わらせ方」 を定義する、という言い方ができると思います。
システム改善作業の「ゴール」もしくは「スケジュール」を曖昧なまま進めてしまうと、たとえば無限に作業が続いてしまい現場のメンバーが疲弊してしまいます。
もしくは、改善作業らしきものは実施してみたものの、その効果があったかどうか、意味があったかどうかも不明瞭なままプロジェクトが闇に葬られてしまいがちです。
ゴールの基準は、主観ではなく、定量的で観測可能な指標を定めることが望ましいです。
・e.g. ◯◯月までに処理時間を◯◯%短縮する
・e.g. HTTP ステータスの 504 エラーの発生率を◯◯%以下にするまで改善を続ける
ゴールを優先するか、スケジュールを優先するか、もしくは両方の達成が必要か、については、対応するシステム改善作業のおかれた状況により様々かなと思います。
もちろん「ゴール」も「スケジュール」も両方遵守しなければいけない状況が、最も達成難易度が高くなります。
デザイン
課題をどのように解消していくか、システムをどのように変えていくのか、その具体的な実施手段について整理します。
直すべき箇所が具体的に特定された後のプロセスとして実施をします。
表現方法として、Design Doc などの形で記述をしていく事が一般的な手法と思われます。
なお、「デザイン」は計画の最初期には定められないことが多いため、後述するような「改善のプロセス」を進めていく中で明確にしていく内容となると思います。
改善プロセス
上記のように、システム改善を行っていくための「ポイント」については説明させていただきました。
以降は、それらのポイントを明確にしていく手順、プロセスについて説明をします。
システム開発や改善のプロセスは「いかにして問題を解くか」という書籍でまとめられているフレームワークが、親和性もあり再利用性も高いので、ここではこちらを採用します。
「いかにして〜」の書籍で記載されている「問題をとく」プロセスは、以下のようなものです。
1. 問題を理解すること
2. 計画を立てること
3. 計画を実行すること
4. ふりかえってみること
問題を理解するためには、 「問題を正しく定義する（解決するべきゴールを明確にする）」 必要があります。その定義した「問題」が妥当なのかを判断する上でも、今起こっている事を 「正確に特定すること」 が必要です。
ここでは、上述の「いかにして問題を解くか」で例示されている４段階のプロセスを参考に、よりシステムの現場に最適化させ ６段階のプロセス に整理しなおした内容を共有します。
あわせて、表中に上述の「大事なポイント」の各項目について、どのタイミングで実施すべきかをプロットしています。
例として適切かどうかわからないですが、比較的わかりやすい例を以下に例示します。
- 課題: とあるサービスが重い
- 原因: 様々あるが、データベースへの接続処理（SQLの処理）に時間がかかっている
- LCP などの指標で画面の重さを測定
- APM などを用いてアプリケーション内の Time Spent を測定
- DB の処理時間が処理時間の中で支配的
- パフォーマンスが劣化しているタイミングで DB の CPU 負荷が高まりリソース枯渇している
- 解決の定義: いくつかの指標について改善が見られたら、解決・改善とみなす
- LCP、SlowQuery
- 解決策: 以下
- SQL チューニング
- インデックスの付与
- SQL の改修
- テーブル構造の改修
- 仕様として重たい SQL を発行しないように修正する
- etc
- 効果測定: 各種指標をもとに改善しているか否かを判断課題というのは一直線に解決することは少なく、課題を見つけ、解決するための方法を定義し、実際に試して試行錯誤をしていくプロセスを何度も何度も回す中で解決・改善するものです。
その事をまず認識する、というのがとても大事なポイントになると思います。
そしてこういった内容を一人の人が理解している、実践しているというだけでは弱いです。組織の中で多くの人が理解し納得し、実際に開発のプロセスの中に落とし込んでいく、そういった組織づくり・文化づくりも、実際のシステム改善のためには重要な要素になると思います。
そういった、組織への考え方の伝搬のために、ある程度フレームワーク化されている方がよろしかろう、という事で、我流でなんとなくまとめてみました。
この記事が気に入ったらサポートをしてみませんか？