DevOpsエンジニアは、“実はきれい好き”──品質管理を進めるための挑戦

機能開発のような花形ではないかもしれませんが、基盤の開発や細かな改善の繰り返し、開発のための開発を通して、プロダクトを裏から支えられるところです。加えて、少しずつ数字を改善していくことが好きなんです。おそらくそういった「きれいにしていく作業」が自分の性に合っているのだと思います。

また、現在カオナビのE2Eテストのメイン担当として、本気でプロダクトと向き合い運用していけることに大きなやりがいを感じています。

もともと子供の頃からプログラミングに興味があり、将来の夢はプログラマーでした。当時、90年代前半はまだWindowsもない時代でしたが、小学生だった私はPCで遊ぶフリーソフトのゲームにハマっていて。

さらに、ドキュメントファイルで同封されていた開発後記を読んで「開発って楽しそうだな」とワクワクを感じたことを、今でも覚えています。

そうですね。家族も含め周りでやっている人は誰もいなかったです。その後、学生時代ではすでにWebサイトを作るなどプログラミングに触れたり、パソコン講習の講師をしたりと、さまざまな活動に取り組んできました。

そのため新卒で入社したスタートアップ企業では、すぐに即戦力としてさまざまな現場で活動をさせてもらえました。SESだったので、顧客企業に常駐し、機能開発をしながら開発を便利にするツール作成や、バグ管理・ソース管理・自動テストの導入、共通機能のライブラリ化などを手がけていましたね。

なかでも、ある大手EC企業のアーキテクトの部署から、社内の開発の部署に出向し、フレームワークの選定や社内の独自フレームワークの開発、テストの自動化、CIの導入などのサポートを経験できたことが今の業務に活きています。

その後、フリーランスとして活動をしてきましたが、やはりフリーランスの立場では活用や運用フェーズまで携わりにくいため、自社サービスを持つ会社を探していたんです。

自分がこれまで培ってきた品質管理のスキルを活かし、いろいろなことにチャレンジができると感じたからです。

そもそも私が会社を選ぶ上で重要視していたのが、プロダクト品質を高めようという意識を持ち合わせているか、という点でした。その背景には、今までSESやフリーランスとして働くなかで、システムが作りっぱなしのまま放置されている現場を幾度も見てきた経験があります。実際、品質改善を怠っている会社では、毎日のようにトラブルが発生するため生産性も低かったです。

一方で、そうした環境下で改善活動を務めてきた経験もありますが、改善には時間がかかり現場のストレスも大きいんです。また、会社の方針やフェーズによっては、「品質改善よりも、今は機能開発に力を入れたい」という状況も少なくないということもわかっていました。

カオナビの採用面接時にすでに自動化に取り組んでいることや、品質改善にも力を入れていこうとする意識が伝わってきたため、それが決め手となり入社を決意しました。

最初は不具合修正や本番環境のオペレーションを担当しました。その後、当社のE2Eテストに関して課題を感じていたので、その業務を一手に引き受ける形でE2Eテストの取り組みを始めたんです。そして、昨年の組織変更に伴いProductivityグループへ異動してからは、E2Eテストのメイン担当として生産性向上に取り組んでいます。

最終的には、開発チームがE2Eテストを作ったり、運用したりできる環境にしたいと思っています。それに向けて、今は我々のチームでE2Eのテストコードを書きながら、同時に開発チームが気軽にE2Eテストを運用できるようライブラリの整備を進めています。

今のままでは開発チームの負担が大きくなるからです。「カオナビ」にはたくさんの機能や画面がありますが、現在のユーザーインターフェースはあまりE2Eテストと親和性が高くありません。例えば一つのクリックで非同期にいくつもの項目が描画されるなどですね。すると、テストコードを書く場合は、クリックなどのアクションの後、一部項目が更新されるのかモーダルが追加表示されるのか、何がどうなれば次の画面操作が可能になるのか、そういった細かなUIの挙動すべてを把握しておかなければ、安定したテストを作ることができないのです。

当然、開発チームのエンジニアでも1つずつ調べていけばE2Eテストを書くことはできます。しかし、機能開発がメインのエンジニアが、“何をクリックしたら、何を待てばいいのか”をひとつずつ調べていくには時間がかかり過ぎてしまい現実的ではありませんよね。

それは我々のチームも同じで、やはり相当数の操作すべての細かなUI仕様を覚えておくことはできませんので、結局、画面操作を抽象化するライブラリが必要になるんです。このライブラリを使いやすく高品質に作っておけば、エンジニア誰もがE2Eテストを書けるようになると思います。

そうです。ほかにも、安定性の向上とメンテナンスコストの削減にも繋がります。もともとは毎月30～50件ほど、不安定によるテスト失敗が発生していたのですが、少しずつライブラリ化を進めることによって現在は月に0～数件程度まで減少できているという実績があります。

長く運用されているプロダクトなので、時には機能の奥深く、歴史的な経緯を含んだ複雑な仕様を知らなければ、気付くことのできないバグというのも発生します。

昔の事情を知っている人は限られていますし、その知識も人の入れ替わりによって薄れていってしまうので、この手の問題に対しては人間の「気をつけて確認する」では限界がでてきます。

これに対するソリューションとして自動テストは有効だと思うので、再発防止のテストを充実させてゆき、E2Eテストという面からプロダクトの品質向上に寄与していきたいと考えています。

今後さらにテストの数を増やしていくためにも、メンテナンスコストを抑えることは重要なのです。

グループとしては、例えばCIジョブの待ち時間を短縮したり、開発環境の使い勝手を向上したり、機能開発のための初期データの作成、業務フロー改善、手動運用作業の自動化、その他個々のチームでは手が出しづらい問題に対応したりするなど、やらなければならないことがたくさんあります。まずは、グループ内で費用対効果を判断しながら優先度をつけて順次対応していきたいと思っています。

また我々のような中間部署は、機能開発で利益を出しているわけではないため、“価値あるもの”や“使いやすいもの”を提供できているかどうか、より強く意識しなくてはならないと考えています。数値のモニタリングをしたり、他部署へのヒアリングをしたり、不具合対応後の振り返りミーティングに参加したりして、なにか問題点や改善できる点がないか積極的に集めにいくよう心がけています。

すでにE2Eテストの仕組みはでき上がったので、今はテストを書けるエンジニアを増やしていくフェーズです。対応できるメンバーを育成しながら、私自身は担当範囲をより広げていきたいと考えています。

例えば今、開発環境の整備をグループとして引き受けようといった話が出ています。それにはAWSなどの知識が必要になってくるんですが、私はSESやフリーランスで長く活動してきたので、権限的にAWSに触った経験が少なくあまり得意としていませんでした。これを機にAWSの知識を強化していきながら、他にも生産性向上の活動に必要な技術があればどんどん取り入れて、得意分野を広げていきたいです。

現在、E2Eテストの実装・画面操作のライブラリ化に苦労しているので、SRE活動とE2Eテストに興味のある方、ぜひ一緒に働きたいです。