ITサービスの品質を向上させる「カオスエンジニアリング」

Pocket
LINEで送る
GREE にシェア
LinkedIn にシェア

こんにちわ。
 

過去にWEBシステムで数億円の売り上げを毎月叩き出していた、下駄です。
 

その会社は今現在、東証一部に上場して、そのシステムをまだ使って売り上げを立てていますが、利用頻度の高いWEBシステムを開発する時に、サービス品質について、すごく悩まされて、プログラミングテストについて、かなり学習したので、その時の思考をまとめておきたいと思います。
 

テストをしない有償WEBサービス

もともと、絵描きを目指していた下駄は、プログラミングは趣味で行っていた程度で、基礎はBasicというレベル。
 

インターネットでwebページを作りたいだけで、かじったレベルのPHPを使ってまさか自分が月額で、億単位の売り上げをあげるWEBサービスを作れるなんて、それまでは考えなかったんですが、
 

アイデアを実現して、成功することができる非常にいい経験をさせてもらいました。
 

でも、そんな素人の作ったシステムが、どの程度の品質を持っていたかと言うと、「品質皆無」です。
 

だって、テストしてないんだもん。
 

企業のwebサイトにjavascriptをSaas方式で提供する形だったので、1社毎に、納品チェックは手堅く行っていたんですが、
webサイトというカオスな空間における不具合は、その後のブラウザバージョンアップや、OSアップデートなどにより、思いも寄らない形で発生してきます。
 

未来の読めない不具合を担保することは、難しいのですが、複数のまったく違った先で動作する大元のライブラリシステムをアップデートする時に、これまで正常に動いていた状態を担保するという事も合わせて重要であることを、思い知らされました。
 

すでに納品して動作しているサイトが3000サイトを超えている状況だったため、1回のアップデートで全てのサイトが正常に動作しているという確認を人的に行うことはもはや不可能な状況だったため、
 

ひどい時は、アップデート直後に、多数の企業から、「動作していない」というお叱りの電話をもらって、すぐにでグレートしたという事も何度もありました。
 

そうした事を繰り返していき、ようやく社内でテストの重要性に気が付き始めたんですね。

品質管理部門の構築

会社の上部で考えた対策としては、開発部門に、WEBサービス構築から管理全般までを全て負わせるという事は、その会社の開発員が全体の社員数の10分の1程度しかいなかった事を考えると、とてつもない負荷になることは容易に想像できたため、
 

プログラマーというレベルでなくても、クオリティチェックぐらいはできる品質管理のエキスパート舞台を作ろうという事になりました。
 

ここから、会社組織の縦割り思考が生まれ始めたのは、後から考えると分かったため、個人的には非常にいい経験をさせてもらいましたね。(二度目)
 

もちろん、組織構造としては、分かるんですが、品質管理がプログラミングが理解できない素人部隊で構成されていたことが、失敗経験の第一歩でした。
 

チェックリストに基づいた、検証やテスト業務は、何の経験もない学生アルバイトでも十分にできるんですが、製品の品質を担保するレベルの検証リストを作ることは、やはり、プログラミングスキルを持っていて、ITレベルが高い技術者でないとなかなか難しいという事ですね。
 

安易に、するだけなら、検証専門の会社に外部委託したほうがよほど効率化良かったと、後から気がついたんですね。

他社がどのように品質テストをしているのかを知る

そこで、その会社のポジションであったCTOという立場を利用して、他社のCTOと会いまくって、話をして、他の会社では、どうやってこういう組織作りをしているか、製品クオリティを担保しているかを、情報収集しました。
 

おかげで、仲良く慣れた技術者仲間などもたくさんできて、個人的には非常にいい経験をさせてもらったんですが(三回目)、そこで衝撃の事実を知ることとなります。
 

どの会社も、全く同じ悩みを抱えている。
 

しかも、全ての会社が現在進行系!!
 

要するに、WEBサービスを主とするベンチャー企業で、品質管理が隅々まで行き届いている会社などは、ほぼないという事なんですね。
 

まあ、そんな事で安心しては行けないんですが、ここで僕が考えたのは、独自に品質管理の方式を作り出さなければいけないと、ココロに誓ったという事です。

結果的にプログラミングの向上に繋がる

まず、実際にそうしたサービスを作り出すプログラマーであった僕が考えたのは、それまでやっていなかったテストコードを大量に書いて、
それを自動実行させて、プログラムエラーを顧客からの連絡ではなく、自分たちがリリース前に見つけ出す事ができるというプログラミング開発を行うようにしました。
 

ここで、「カオスエンジニアリング」という言葉に出会い、あまり想定されない動作でも、エラーを見つけ出してそれを潰していくという、スタイルを身につける事ができました。
 

ここは、1度作ったwebサービスを検証するプログラミングをする為、プログラマーとしては、かなりクリエイティブ性を感じることができ、正直楽しい作業でもありました。
 

そして、その先に考えたことは、効率のいいプログラミングをするという事を考え、最初にプログラムする時に、どうすれば効率いいデバッグができるかという思考を持った状態で設計することができるようになったんですね。
 

これは、よく言われる言葉なのですが、実際に経験をしないと得られないスキルであるということも、こうした経験からよく理解することができ、
 

結果的に、自分のプログラミングスキルの向上につながったため、その後独立をして、自分でサービスを作り出すプログラマーとしての確率ができた大きな要因になりましたね。
 

カオスエンジニアリングを追求すると、プログラミングスキルは向上するという話でした。

Leave a Reply

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です