前置き
入社してから手をつけたことはいくつかありますが、その中からまずは一つの取り組みを紹介をします。
私は2023年7月に入社し、グローステクノロジー本部テクニカルオフィス所属となり、主に2つのプロダクトチームを見ています。
テクニカルオフィスは2022年10月に組成された組織ですが、プロダクト開発自体は外注しており、プロダクトマネジメント（プロジェクトマネジメント）する人たちだけで構成された組織でした。
そこに2023年5月、7月でソフトウェアエンジニアが参画し、プロダクト開発に関与し始めました。
直接的な関与のある2プロダクト以外にもプロダクトは存在しており、それらの情報も耳に入ってくるわけですが、それらのプロダクトに対しても「品質」の観点でまだまだやるべきことがあるのではないかと思い始めました。
そのため、まずは品質保証に対する現状把握が必要だと考えました。
では、現状を把握するためにはどのようにする必要があるのか、インシデント発生数だけでは不十分で、どういった内容のインシデントが多いのかまでは把握できる必要があるだろうと考えました。
幸いにも前職でインシデント対応に関しては諸々のルールがあり、自分の中にその知見があったため、まずはインシデントレベルの定義があると良いという考えに至りました。
また、セットでインシデント対応フローやポストモーテムを用意することで、インシデント発生時の対応速度の向上と、インシデントからの学習を活用した品質向上を図りました。
品質保証を重要視する理由
品質保証に最初に手をつけた理由について触れておきます。
プロダクトは基本的には如何にアウトカムを高めていくかが重要な観点となります。
しかし、ソフトウェア開発において品質保証の観点が抜け落ちていると、気づいた時には、、、というか残念な結果を持ってして、「あぁ...自分たちは失敗したのだ」と気づきます。
当然ですが、品質保証の活動だけをいくらやってもプロダクトの成功には近づきません。
しかし、一定以上の品質保証ができていなければ、確実に失敗には近づきます。
しかも、緩やかに緩やかに終焉に近づくので、普段から意識していなければ自分たちがどのくらい危険な状態かに気づくことができません。
そうしてある日突然大きなインシデントを起こし、品質保証の必要性に気付いたとき、とてつもないコストを払う必要があることを全員が理解します。
毎月利子分だけでも借金を返していれば借金は元金だけで済むのに、利子分すら払わなければ借金は元金の何倍にも膨らんでいることになるのは容易に想像できると思います。
もしかすると毎月毎月小さな障害という形で、支払督促が来ているのかもしれません。
しかし、その取り立てから自分たちの状況を理解できなければ、最終的には執行機関による強制執行が執り行われます。そうなってしまってはもはやできることはありません。
品質保証ができていればもっと長く成功できたかもしれないのに、できていなかったばかりに失敗するなどということはあってはいけません。
アウトカム、プロセス、ストラクチャーのそれぞれの品質に対して目を向けていくことは、ソフトウェア開発において欠かせないですし、ソフトウェアエンジニアとして責任を持って立ち向かうべきものです。
具体的にやったこと
- PagerDutyやATLASSIANを参考にSEVERITYのレベルを定義
- インシデント発生時のエスカレーション先の定義
- エスカレーションルートの定義
- インシデント発生時の初動の定義
- インシデント対応ログを記録するルールの整備
インシデントレベル
エスカレーション
インシデント対応ログ
やってみて
インシデントレベルごとにどのプロダクトでどれくらいのインシデントが発生しているかが可視化され、組織として内製外注関わらず全プロダクトに対して、品質保証に取り組む必要があるという共通認識を持つことができました。
これからやること
現状が可視化され、品質向上の必要性を理解したところで、そこから何をすれば良いのかがなければ品質向上は為されません。
組織として、開発に関する知見はこれから蓄積していくものでありますし、品質保証の観点においてもそれは同じです。
まず、初めの一歩として、品質保証のためにどういったことが必要なのかを定義した「品質保証チェックリスト」を作成し、全プロダクトにおいて品質保証のための取り組みが行われるような仕組みの整備を行っています。
品質保証チェックリストについては、運用に乗せたところなので、また後日記事にします。
Septeni Japanではソフトウェアエンジニア・インフラエンジニアを募集しています
興味を持っていただけた方は、下記からご応募ください。
まずはカジュアル面談でざっくばらんに会話させていただければと思います。
Discussion