【コドモンの中の人 Vol.21】QAチーム立ち上げ！コドモンの品質を担うQAエンジニアのチャレンジがスタート

こんにちは！コドモン人事です。

インタビュー形式で、コドモンの中の人を紹介していく、この企画。シリーズ第21弾は、コドモン初のQAエンジニアとして、チーム立ち上げをしながら、コドモンの品質向上に奔走している水落さんです。

人がやらなくていいことは自動化しよう

---------どんなキャリアを歩んできたのですか？

まず、金属材料の研究を続けたくて大学院に入っていたのですが、実物をエンジニアリングするのは手間もお金もかかって難しいなと思っていたんです。

研究も思ったようにいかなかったし、このままこのデータだと「2年じゃ卒業できないね」というのが早々に確定していました。そこで気持ちが折れたというか、これ以上深めてもという感じで。しかも、扱っていたのは原子炉圧力容器の材料だったため、震災で国内新規の案件がなくなっていたことで親からも心配されていて、もういいか、と思ってサッとやめてしまいました。

なので、あまり新卒らしいことはしていなくて、第二新卒みたいな扱いで、小さいソフトウェアハウスに入社しました。開発は、大学の教養的にC言語触れたくらいの業務未経験者だったのですが、プログラミングは腕があればどこでも仕事できるし、食いっぱぐれないんじゃないかっていうちょっと甘い考えもありつつ、飛び込んでみたらなんとかなりましたね(笑)。

その会社で、プリント基板の製造データを補正するソフトを作っていたのがファーストキャリアなんですけど、その後、営業が足りないからという理由で、いきなり異動。営業をやることになったんです。2年近く営業をやっていたら、今度はサポートが足りないからという理由でそっちもやるように指示がきて、なかなか大変でした。

そんな状態で迎えた冬の賞与の面談で、当時の経営者から「あと、5年くらい営業を……」と言われて……。営業はやりたいことでもなかったし、最初の話とも違っていたので転職をすることにしました。

急いで転職活動した中で、一緒に仕事をしたいと思った相手がSESの会社の方だったので、そこに入社することに決めました。技術的に面白い会社も探していたけれど、ただ技術的に興味があるだけではなく、会社の将来の成長性を見ないといけないなと思いながら探していて。SESはいつまでも仕事があるので食いっぱぐれないなと思ったんですよね。

実際やっていたのも交通システムで、システムの基盤と言われる装置間通信の根っこの部分を作っていたんです。その次にやったのは係員向け処理機のシステムで、入場記録取り消すとか、券発行とか、開発に携わってました。

いずれもインフラに関わるものなので想像つくと思うんですけど、システムダウンしたら大変なことになるじゃないですか。前職は、二次請けだったんですけど、システムが落ちたら三日三晩張り付きで監視して、睡眠もろくに取れなかったりしていたんです。

SESは継続的に仕事があるけど、なかなかハードな仕事でしたね。

QAにつながる話でいうと、不具合のログってテキスト情報で出てくるんですけど、一個何なんGBにもなるんですよ。それだけ膨大なログの解析を、人力でやってると聞いて衝撃でした。なので「そんなの自動化しようよ」と提案して、自分で開発までして、2時間かかる解析を10秒にしました。もう、2年前くらいの話なのですが、今でも使ってもらえているらしいです。

その経験で、自分の中でも「人がやらなくて済むことはシステムにやらせよう」って考えを強く持つようになりました。そのあとに、係員向け処理機の案件を担当したのですが、顧客それぞれにローカライズしたシステムだったので、共通部分を修正するごとに全部テストが必要だとなりまして。

その結合試験は、すべて手作業で操作してチェックだったんです。これもまた驚きで……。

修正が入る度に、全部のお客様に対して手作業でテストしていて、これは地獄だって思いましたね。具体的にいうと、20件くらいのシナリオがあるんですが、1つのシナリオ操作だけで1件2時間かかる。終わった後、エビデンスとってデータの確認で1件5時間くらい。合計ざっと150時間。仕方ないから何人かで手分けして総当たりでやるしかないっていう感じで(笑)。

「リリースの日までに、なんとかするぞ！」って力技な感じでした。

ただ、共通項目はあるし、動きは基本的には同じなので、他の仕事もしながら合間にツールを作って準備をして行ったんです。自動で操作し終わって、エビデンスを出し、比較するところまでをシステム化しました。そうすると、手作業では1件あたり7時間かかっていたものが1時間弱に縮まるし、ヒューマンエラーのやり直しもないんです。

これには結構な達成感があって、面白みを感じました。作業は機械にやらせてる間に人間は他のことできるし、結果だけ確認すれば効率も精度も上がるじゃん！と。

そしたら、ちゃんとQAやりたいなっていう思いが一気に強まったんです。

そんなことを考え出したときに、気づいたことがあって。交通システムって自動化されてて、毎日大量に人が移動しても成立していると思うんですけど、そういう自動化が遅れている業界ってあるんじゃないかなって。その中で、人手不足や業務量の多さに苦しんでるところがあれば、自動化によって手が回るようになった時にもっと品質が上がるようになるな、と。

ここ5 - 10年でWeb界隈はいきなり成長して、品質は担保されてない部分があるけどとりあえず動いてるっていう状況だと思っていて、そういう現場なら成長スピードも速いし、品質を高めてよりよくできると強く感じていたので、チャレンジしようと決めて転職に動きました。

---------コドモンに入社を決めた理由を教えてください。

「保育所が大変だ！」とっていう話っていろんなところから聞こえてくると思うんですけど、自分自身、結婚して甥っ子ができたっていうところで、保育に対する関心が一気に高まったんです。

たまたまなんですけど、転職を意識していた頃の七夕に、甥っ子が「先生にもっと遊んでほしい」と短冊に書いていたのを見て、やっぱり先生って忙しいのかなと思いました。妻の姉に聞いてみたら「めちゃくちゃ忙しそうだ」って言ってて。しかも自分たちは妻の姉と同じエリアに住んでいるので、将来自分たちの子どもも同じ思いをする可能性があると思ったら、他人ごとじゃないと思いました。

それで、業界×ITみたいな形で調べ始めて、コドモンに巡り合いました。他の会社も見たし、業界も調べましたけど、過去に営業やってた経験から「やっぱり本腰入れて取り組むならチャンピオンかパイオニアに入らないとダメだ！」と思ってて「この業界でやるならコドモンに入るしかない！入りたい！！ここで頑張りたいんだ！」って思いながら選考に臨んでました(笑)。

こうして無事にご縁をいただけてよかったです！

文化を作り、戦略を立ててコドモンの品質向上を

---------コドモンではどんなお仕事をされていますか？

QAチームを立ち上げるということで参画させてもらったので、一人目のメンバーとして、今はテストの自動化やテストの文化づくり、CI/CD環境づくり、品質基準づくりなど、色々やってます。

まず、テスト文化を根付かせる話からすると……テストしやすいとか、しにくいとか、するとかしないとか含めて、そういう文化がコドモンにはまだ足りなくて。

私の出身はSESだったから周りとのギャップがあるんですけど、SESでは納品の過程に絶対テストが入るんです。でも、スタートアップのWeb系自社プロダクトはそうじゃないと思ってます。今まで「作る」ってところに集中してきたと思うけど、ちゃんとテストして、ちゃんとした品質で提供しなきゃいけないって感覚が足りないので、それを根付かせないと！と思ってます。

コドモンってすでに数十万人規模で使われているサービスで、ここから数年の間に、おそらく数百万人が使うサービスになると思うんです。今までは作って、スピーディに世に出してきてしまったけど、これからはそれでなにか不具合が起こってしまったときの社会的インパクトが大きすぎますよね。

そういうことを起こさないためにテストが必要なので、今は新機能のテストをしたり、テストを根付かせるための動きとして「どうしたらテストがしやすくなるのか」という資料を作って共有したりしています。

今って、ある程度動いてるシステムの中で修正を加えたり、機能を追加したときに、既存の部分に影響が出るかどうかを把握し切れていないんですよね。だから、手を加えていない機能に影響がないことを把握するためだったり、影響を受けていても対応ができている状態にするために、事前にテストが必要なんです。

そういった意味で、文化づくりに向けた課題感としては、それぞれ個人の持ってるテスト観が違うのをなんとかしないといけないですね。一般的に、単体試験・結合試験・総合試験とかあるけど、どこ見るのっていう着眼点も人によるし。テスト依頼受けたものを確認するけど、ワンパス通すものだったり、ぽちぽち押すものだったり、色々まちまちなんですよね。

だから、テスト文化を作るのは基準作づくりでもあるわけです。その「テスト基準」が、いずれ「品質基準」というものにもつながってくるんです。

なので、認識を揃えて文化を根付かせながら、入社時点から手をつけ始めているブラウザ操作を自動でやってくれるテストツールを作ったり、テストの戦略を作ったり、同時進行でしています。

ソースがコミットされたタイミングでやるテストとか、デプロイ・リリース前にやるテストとか、ずっと動かしておくテストとか、テストを分類して、どのくらいのステージでボリュームでやってどのくらいの時間で終わるかとか、とにかく決めることが多いんですけど(笑)。

何個か会社を経験した中で、今までのテストは戦略立ててやってなかったのが課題だなと感じています。どうしても「仕様書にあるからやる」というレベルだった。そうではなくて「品質を上げる」という主体的にアプローチするためには、テストにも戦略が必要なんです。

あとは、CI/CD環境の構築っていうのがあって、技術者でも分かったり分かんなかったりするものなんですけど、CIっていうのは作ってる途中でテストをまわしてコミットして、ぐるぐる・ぐるぐるループさせてどんどんインテグレートさせていく枠組みのことです。
CDっていうのはコミットを契機にしてテストを動かし、デプロイ、リリースまで自動でやる枠組みのことです。

これまでは、作って、ソースをコミットするところでブチっと切れていて、あまりテストもされてなくって、それをいざリリースするぞってなったら人力で適用していました。それをもっと自動化して、作る人は作ることに集中してもらいたいなと。デプロイ、リリースするときも人の手が入ると失敗することがあるので、そこも自動化して確実なものをリリースできる仕組みを作ろうとしてます。

最後が、性能評価をして品質基準を作ることです。ボタンを押して何秒以内にレスポンス返ってくるとか、使いやすさでボタンの位置が変じゃないかとか。UI/UXの要素も入ってくるし、まだ数値化できるできないがあるので難しいんですけど、品質基準なのでバグ混入率とかも、CI/CDの枠組みができたらもっと数値化して出せるようになるかなと。

なので、そこでまた指標化したり……何年かかけて取り組んでいくことだと思ってます。

---------実現に向けたイメージや取り組みは会社として進んでますか？

そうですね。ちょうど会社としても、組織の再編があってアーキテクチャチームができたので、あたらめてCI/CD環境を見直すきっかけが着実にできていると思います。

なので、そこに向けて人手が欲しいという感じですね。面白いしワクワクするけど、今のままだとどうしよう！どうしよう！！という感じもすごいするので。

評価されにくい仕事だからこそ誇りを持って！

---------お仕事する上で大事にしていることは？

個人的に大事にしていることは「もらった時間の2割で8割作ること」です。

ガリガリコード書くっていうよりも、構成を8割方作れば自ずとソースが書けるんです。2割の時間で作っていれば、大失敗をしていてもそれを捨てられるんです。ブラッシュアップするほうが時間かかるので「2割の時間で8割作ってる」と思ってたら精神負荷も減るし、後に引っ張ると夏休みの宿題みたいになるし、クオリティも100点に届かないので心がけるようにしています。

---------コドモンを通じてどんなことをしていきたいですか？

小池さんが言ってるような、コドモンを中心にしたエコシステムを作るのは面白いと思ってます。

だからこそ、プラットフォーマーになるにあたっては、より品質が必要になる。一回でも信用を失うようなことがあったらおしまいなので、そこはちゃんとしなきゃいけないってみんなわかってると思うし、それをちゃんとできる会社だと思っているので、そこを大事にしつつ、コドモンを中心としたエコシステムを作って、こそだて環境が便利になればいいなと思います。