サービスの課題に向き合うやりがい！課題の改善を専任で取り組むチームで1年間やってきた5つのこと。

「課題に向き合うことってこんなにやりがいがあるんだな！」
今年はそう感じた一年でした。

みなさんのお仕事でも「これあったらいいな」「これ誰かやってくれないかな」「もっと効率良くできないかな」と感じることありますか？感じることはあると思うのですが、自分のお仕事と並行してやるのはなかなか難しいですよね。

Webサービスの開発でも様々な「改善したいこと」や「効率化したいこと」があるのですが、今回は課題の改善を専任で取り組む”カイゼンチーム”で一年通してやってきたことを書こうと思います。「開発・運用の改善を専任で行うチームがあることでどんなことができるのか」「他のチームはどんなことやっているのだろう？」が気になる方の参考になればと思います。

なぜ改善を専任で行うチームが必要だったか

まず、カイゼンチームができた背景について。

現在携わっているサービスはリリースから一年以上経過しており、今も新規ページの追加や機能追加・改修が積極的に行われています。

どんどん新しい機能や開発メンバーが増えていく中で、少しづつ「機能追加時に他機能がデグレする」「開発・運用をより効率的に回してリリースのサイクルを早くしたい」などの課題や改善点が出てくるようになりました。ただ、開発業務がある中でそれらと並行しながら進めるのは厳しい…。そんなときに新しくできたのがそれらを専任で行う”カイゼンチーム”です。

カイゼンチームで取り組んだ課題

カイゼンチームではサービスの開発・運用の中で発生する「バグ」「脆弱性」「自動テスト」「ログ」「パフォーマンス」の課題に対してメインで取り組むチームです。ここからは各分野の取り組みについて書いていきます。

1.本番障害・不具合

取り組み
・発生した本番障害の原因調査・対応・再発防止策の検討と実施

障害発生時は最優先タスクとして、障害調査から関係者への連絡、修正、リリースまでを迅速に行います。

不具合の原因だけでなく、”不具合が起きる原因となった仕組み”の部分まで突っ込んで考えるため、テストの方法やソースコードのレビュー方法、ドキュメントの見直しも行いました。

具体例
・PRテンプレートに実装観点やレビュー観点のチェックリストを追加。検証環境にPRを取り込む際はチェックするようにしてコードを基本的な品質以上に保つ
・結合テストはテスト観点（テストでどこを確認すべきか）を整理してから、テストケースの作成を行うようにする
・ChromeとSafariでjsの挙動が異なることが多々あるため、jsの実装を行なった場合は必ずSafariブラウザでも動作確認を行う

ここら辺は開発の進め方によって原因も対策も変わると思うので、こういったことに興味がある方とお話ししてみたい内容です。

本番障害の内容はスプレッドシートにまとめているのですが、それらを分析すると「こんなことで起きるの！？」なんて内容もあって結構面白いんですよね。原因調査をする中で”こういうときは不具合が起きやすい”ということも分かるようになってきているので、こういう勘所は今後の開発でも活かすことができると思います。

2.脆弱性

取り組み
・「脆弱性診断の方法」「結果の記録」「一定のリスクレベル以上のアラートが発生した際の対応フロー」を整理。脆弱性診断が初めての人でも自立して診断できるようにする。
・全画面に対して脆弱性診断を行い、現状を把握。各アラートについて緊急対応が必要かを判断するために内容の調査を実施。

今後
・脆弱性診断を定期的・自動で実施する基盤を検討中

課題として「脆弱性診断の実施フローが曖昧で、メンバーによって脆弱性診断の実施がされていない」がありました。そこで診断を含めた対応フローの見直しや現状のサービスにクリティカルな脆弱性が発生していないかを確認するために全画面に対して脆弱性診断を実施、各アラートについて調査を行いました。幸いクリティカルな脆弱性は発生していなかったので良かったです。

現在は毎リリースで各メンバーが「OWASP ZAP」を用いて診断を行うようにしています。ただ、”脆弱性の検知される頻度が低い”ことや”リリースまでの工数を短縮したい”ことから、現在は定期的・自動的に脆弱性診断を実行する基盤の構築を検討中です。一定のリスクレベル以上だったらメッセージツールで報告をする、ようなことを考えています。

良かったこと
・脆弱性診断を行うことでサービスの品質保証に繋がった
・これまで脆弱性診断を実施したことがない開発メンバーが多かったが自立して診断できる状態になり、脆弱性に触れる機会作りにもなった

良かったことは「サービスの品質保証」が最も大きいです。僕含め、脆弱性診断を開発メンバーが行う、ということが無かったので、今回の対応を経て、”脆弱性に対する心理的ハードルをグッと下げることができた”のも良かったと思います。

また、社内でもあまり脆弱性診断をチーム内で実施した事例が無かったらしく、他プロジェクトの脆弱性診断についての相談を受けることもあり、他プロジェクトにも少しだけ貢献できたことも良かったです。

脆弱性診断についてはできる限り本番環境と同じ環境で実施するのが良いと考えています。現在は各開発環境で脆弱性診断を行なっていますが、”開発環境のみで発生するアラートで対応が不要だった”というオチだったことも何回かありました。使用しているインフラによって事前連絡が必要なことがあるため要確認ですが、実施するのであれば可能な限り本番環境と同等の環境で診断するのが良いと思います。

3.自動テスト

取り組み
・E2E自動テストツールを用いた自動テストを導入

課題が「機能追加・改修のリリース時に他画面・機能でデグレが発生する」でした。
手を入れた画面や機能はテストを行っているため問題無いが、変更したコードが想定していなかった機能にも影響があり、リリース後に本番障害として発覚する、というものです。

取り組みとして、プロジェクトで行っていた「単体・結合・総合テスト」工程の見直しは勿論ですが、合わせてE2E自動テストツールを用いた自動テストを導入しました。

このツールはリグレッションテストとして活用しています。機能改修を行ったタイミングでテストツールを流して、想定している箇所以外で失敗が起きていないかの確認をリリース前に実施しています。（想定している箇所：機能改修によって画面上に変更がある場合は作成したテストシナリオと異なる挙動になるためテスト上は失敗になる）

テストシナリオの作成については他サービスにもツールの導入を行っていたチームと連携を取りながら進めました。「テストを行う目的」「サービスにおける重要な機能」「どのようなテストを行うのか」とテストツールが可能なテスト方法をすり合わせながら行いました。

良かったこと
・サービスの品質保証に繋がった
・画面確認時の工数短縮

現在は「毎リリース前のリグレッションテスト」に加えて「定期的・自動でテストツールを実行。テスト結果をメッセージツールで通知」するようにしています。そこで想定外の失敗が発生している場合は他チームの改修によってデグレが起きている可能性があるため確認する、という対応フローです。人力で行うと数時間かかるテストを自動で実施してくれるのはかなり安心感があります。

加えて「影響は無いと思うけど念の為確認しておきたい」レベルの動作確認時にも使用しています。「どこの画面を誰がするの？」ということも、とりあえずテストツールを流しておけば良いので、その分の工数短縮にもなっています。

一方、課題として「テストシナリオ作成・管理にコストがかなりかかる」があります。

機能改修時は「内容に合わせたテストシナリオの更新」が必要であり、新規画面追加時は「新しくテストシナリオに追加するか否かの検討」が必要になります（1テストシナリオを増やすとその分管理コストが増えるため安易に増やすという決断ができない）。導入の際は「テストツールの作成・管理ができるリソースを確保できるかどうか」をしっかり検討するのが良いと思います。

4.エラーログの解消

取り組み
・対応方針の作成
・対応の優先度付け
・ログ実装方針の作成

コイツが最も厄介な課題です。

エラーログの発生時にメッセージツールで通知を行なっているのですが、通知が多すぎて狼少年化。発生している事象に対して緊急対応が必要か否を判断できないということが問題としてあります。また、これらのエラーログ数を減らすための調査を開発メンバーの手が空いたタイミングで実施しているため、発生数に調査が追いつかない、という問題がありました。

そこでまず、現状発生しているログの件数を把握、その上でどのようにログを潰していくのかの対応方針を作成しました。「売上に直結するようなサービスにとっての重要画面で発生しているログを優先的に対応する」という対応方針の元、ログに対して優先度付けを実施&対応。また、これから実装されるログがこのような状態にならないように、ログ実装方針を改めて作成しました。

改善されてはいるものの、まだまだ発生件数は多いため、引き続き対応していく課題です。

5.パフォーマンス

取り組み
・フロントエンドはLightHouse、サーバーサイドはdatadogAPMを用いて改善を実施
・ミドルウェアはApacheBenchを用いて改善を実施

以前は開発フロー内で各ツールを使用し、基準値を超えた劣化が無いかのチェックのみを行っていましたが、チームが出来てからは「計測→改善点をリストアップ→改善を実施→検証…」のサイクルを「開発とは別で」回しています。

実施は始まったばかりなのでこれからが楽しみな分野です。

さいごに 課題に向き合う"やりがい"と"難しさ"

カイゼンチームは初め、僕一人から始まりました。

メンバー：「これはカイゼンチームで対応する内容ですね〜」
僕：（´-`）.｡oO（チームと言っても実質一人だからなぁ…）

と心の中で何度も思ったことを今でも覚えています。本番障害の対応が重なった時は結構大変でした。今はメンバーも増えて各分野に対してカイゼンを進めている状況です。

カイゼンチームでの取り組みを通して、課題に向き合うことの”やりがい”と”難しさ”を身を持って経験しました。

課題に対して、背景を理解する・深掘りする・他の視点から考えることを通して、「本当に原因はそれか？」「別の視点から考えるとどうだ？」「必要なものはそれか？」と自身に問いかけながら深く潜り、これだ！と握った改善案を導入し、検証を行い、再び課題に向き合う…ことを通して一つ一つ課題を解決していくことで達成感を得られました。（ここら辺はエンジニアとしてのやりがいを感じることにも通じます。）

一方で、改善策を導入する際、ただ「やってください」だと受け入れてもらえず、「このような問題があって、これが必要なので、こうします」という所まできっちり伝えないと人は動いてくれない、ということを感じました。そのために課題に対するベストな改善案を誰が見ても分かりやすく伝える必要があります。”お願いされたからやる”ではなく、”必要だと理解しているからやる”ことが最もパフォーマンスが発揮できる状態だと考えているからです。

また、開発チームとの信頼関係は何より必要だと思いました。嫌いな人の言うことは頭ではどれだけ必要だと分かっていても受け入れられないと思います。メンバーとのコミュニケーションは最も重要であり、やるべきことだと思います。人と接することが好きな僕にとっては向いているポジションだと感じています。

来年以降も引き続き課題に立ち向かっていこうと思います！
それでは！