開発プロセスの4割がテスト！

弊社のサービスを導入しようと思ったきっかけは何でしょうか。

小野様例えば、リリースの少し前にエンジニアが夜遅くまで残って、違うブラウザをいくつも並べ、全く同じ画面を見てテスト結果表に一つ一つ〇×を付けていたのですが、これは健全じゃないと思っていました。

画面の目視確認で膨大な時間をかけていたと。

小野様チェックは長時間になればなるほど集中力が落ちる。でも品質を担保する為には、集中力を高めていかなければならない。
日中は、お客様や社内からの問い合わせを受けるなど、人との接点が多いので、チェックに集中できる時間は朝や夜の残業時間にどんどんずれ込んでいく、残業が続くと疲れてくる…、そこを何とかしたいと思っていました。

藤平様そういった状況で、テストを全部消化しきれないなどの問題もありました。

どれくらいの時間をテストに割いていましたか？

小野様全体の開発開始から終了までの構成の中だと、だいたい4割ぐらいテストしていました。

4割・・・！多いですね！医療業界と考えても、若干多いかと思います。

小野様働いているエンジニアも、何かあったときの影響が大きいということを理解しています。忙しいながらも、テストに時間をかけているのです。

藤平様医療系の計算処理には非常に複雑な式もあり、ものによってはテスト出来る人が限られることもあるため、テストに時間はかけています。

小野様お客様は、経営支援システムが出した結果に基づいて経営判断をします。ですので、システムが間違った結果を出さないよう、しっかりテストしていたということですね。

ウェブレッジを選んだのは、実現したいことを正確に汲み取ってくれて、一緒に歩むイメージができたから

弊社を選んでいただいたポイントは何でしょうか。

藤平様いくつか相見積を取ったのですが、弊社でやりたいと思っていたことを正確に汲み取ってくれて、具体的な実現方法を提示してくれたのは御社だけでした。本当に私が伝えた通りの提案内容が出てきたので、うれしかったです。細かい要件調整で小回りが効くところも印象が良かったです。

弊社が「お客様の業務にあわせたサービス」を売りにしているので、うまくマッチしたのかなと。

藤平様そうですね。やりたいことは固まっていたので、こちらのやりたいことをベースに、プラスアルファのご提案を頂ける「仲間」を見つけた感じでした。

小野様一緒の歩幅で共に歩くような感じですね。

導入時、懸念点はありましたか？

藤平様自動テストは実施していた事があるのですが、その時はうまく運用を継続する事ができませんでした。理由は、テストスクリプトのメンテナンスなど、運用に手間がかかりすぎて維持できなくなったためで、その結果いつの間にか使われなくなっていました。
今回については、なるべく運用コストを低くすること、実際のエンジニアに「使ってみよう」と思ってもらえること、を第一に考えました。

人的作業を自動化することで、一定の品質を保ちやすくなった！

導入後はいかがでしょうか。

藤平様今回、ボタンを押せば改修の影響範囲が見える仕組みを提供できました。開発が一通り終わったらボタンを押す。これで、想定していなかった影響範囲を見ることができます。自分が想定していない挙動が差分として出現したら、そこは何かしら見えていない部分があった、もしくはデグレード、要するに不具合です。そうやって影響範囲を可視化した後調査し、品質を高めていくという運用ですね。

今までは、想定通りの画面系動作が出来ているのかを人力で見ていました。人がやっているので、その時の忙しさや気持ちに左右される部分もありました。
でも機械がやると、そういうばらつきがなくなり、一定の品質を保ちやすくなったかと思います。

やり方としては今まで手動でやっていたことと同じですが、手動時代と比べると多分ここまで完璧にやれていなかったのではないかと思います。

品質を守るために頑張るエンジニアを守り、支援したい

今後に対するご要望はありますか？

小野様まず今回は、意図しない影響を検出したかった。副次的効果で、集中力の落ちた状態でのテストをしなくなれば最高だと思っています。今後エンジニアを支援するという活動の基礎が、この第一フェーズでできたと思っています。

第二フェーズは個別支援です。
我々のチームは、バグが多いけど作るのは早い人とか、バグは少ないけど細かい所が気になって先になかなか進めない人とか、色々な個性が集まってチームができています。このチームに対して規定やルールといった枠組みを作ってはめ込むのではなく、開発者別にアドバイスをしていきたい、その材料としての可視化を進めていきたいですね。
もう一つは、今回自動化したシステムテストを含めて、第三者の目で定期健診を行うことも考えていました。

少しでも自動化などで工数を減らすのが弊社のお手伝いできるところですね。

藤平様自動化は良いことが多いと思っています。効果としての数字は、まだ走り始めたばかりなので正確には見えていませんが、運用が回れば、これまでのテスト工数を半減できる見込みです。機械的に細かくチェックできるようにもなったので、精度も高くなる、うまく運用が回れば高い効果が出ることは確信しています。
また、今回はキーワード駆動型でご提案いただきましたが、使い方を覚えてしまえばエンジニアでなくてもできるので人件費を低く抑えることもできると思っています。
この辺を提案いただいたのが助かりました。

あと、連休中に自動テストを仕込んでおけば、その時間も使ってテストができるっていうメリットもありますね。

小野様夜帰る前に実行、そして翌朝来たら結果が出ている。

他の現場の方の反応はどうでしたか？

小野様運用が変わるという話をした時、現場から抵抗などあったのでは？

藤平様仕組みを作るところは私が行い、開発者は出来上がった仕組みを使う、の前提だったので特にありませんでした。
導入するにあたって、開発者に負担はかけないという進め方だったので、それが良かったのかもしれません。

テストは専門会社へ。エンジニアが疲弊する今こそ、テスト自動化を勧めたい

今後弊社に求めることはありますか？

小野様我々はサービスについては専門だと思っていますが、テスト専門ではありません。
御社がテスト専門なら、そこはお願いしてみようと。「餅は餅屋」の考え方ですね。そしてテストの専門性の高い会社であり続けていただければ、我々サービス提供者との接点はあると思っています。

ただ、やれる範囲は自分でやりたいっていうのが我々の考え方です。うまく歩幅をあわせて歩いていただけるところを期待しています。

最後に、導入を検討されている方へ一言お願いします。

小野様開発スピードを重要視する中で、アジャイルとしてのスクラム開発を採用している企業様が増えていると思っています。現場はどうでしょうか、責任感とスキルの高いエンジニアが疲弊している状態になりがちだと私は思っています。
そのような状況でも、サービスインを早めたいという思いがあるのであれば、自動化していったほうが私は良いと思っています。
最初から全てを自動化する目標を立てず、必要なところ、やれる所から進められるパートナーを探しているのであれば、相談してみてはいかがでしょうか。

そのような企業様は是非ですね。本日は貴重なお話をいただき、ありがとうございました！