2016-08-12

ShouldBeeユーザー事例紹介 – 株式会社ギークフィード様

ShouldBeeユーザー事例紹介 – 株式会社ギークフィード様
ShouldBeeユーザーインタビュー - ギークフィード様

こんにちは。クラフトマンソフトウェアの竹原です。

今回は、ShouldBeeを初期の頃から熱烈に使って下さっている株式会社ギークフィード様に、ShouldBeeをどの様に活用して成果を上げられているか、お話を伺ってきました。

geekfeed_logo_0今回インタビューにご回答いただいたのは株式会社ギークフィードの以下のお二人です。

  • 代表取締役 内(うち)様
  • 開発部主任 向井様
  • (以下、敬称略)


    竹原) インタビューをさせて頂く竹原です。どうぞよろしくお願いいたします!

    どのような製品開発にShouldBeeを使っているか

    竹原) まず最初にお聞きしたいのですが、どのような製品の開発にShouldBeeを使っていますか?

    内 ) ギークフィードのメイン事業としてはシステム開発を中心にやっています。ウェブ系の受託開発に8割ぐらい、のこり2割は自社製品の開発でShouldBeeを利用しています。製品としてはYouWireという独自のサービスで、固定電話、携帯電話、050番号、会議での音声を録音してサーバで一元管理できるサービスをクラウドで提供しています。UIはウェブで(ブラウザ経由で)提供していて、録音は日時や電話番号、録音の長さなどで検索して再生できます。Androidアプリ版だと録音したときのGPS情報も記録されます。通信会社の楽天コミュニケーション様の通話録音サービスと連携し展開しています。コールセンターや保険の営業さん、オフィスなどでご利用頂いています。最終的にはテキスト解析してBIに活かせる機能を開発予定です。

    youwire_logo_w
    YouWire: http://www.youwire.jp/

    ShouldBee導入前の課題

    竹原) ShouldBeeの導入前は、品質向上についてどのようなことをしていましたか?

    向井) 開発者がテストケースをつくってテストを行っていました。人数が少ないので、どうしても開発者がテストケースを作らないとならなかった。設計から開発、テストケース作成とテスト実施まで開発者が行わなければならなかった。しかしテストまで行うと開発に時間がかかってしまうという課題がずっとありました。

    内 ) アナログなやり方で、単体テストは開発が終わった後に開発者本人に任せていたので、基準はまちまちでした。お客様への納品前には私が自ら受け入れテストを実施していました、納品責任があるので。やはり単体テストレベルでも甘い部分があり差し戻しが非常に多く、受け入れテストでも工数が想定以上にかかっていたという失敗がありました。特に自社の社員でなく、外注さんで多かったです。特にフリーのエンジニアさんは品質基準がバラバラで、企業に務めている方に比べて納品物の品質については低い傾向にありました。もちろん開発スピードが速いという強みがあったりもしますがトレードオフですね。

    竹原) (ShouldBeeの導入以前で)品質向上施策でうまくいっていたことは何ですか?

    内 ) 必然的に製品との接触機会が多くなるので、仕様について詳細に把握する機会になっていました。受け入れテストを自分達で行うと、納品後の1次回答ができるようになっていたりしていました。

    竹原) 開発作業に対してテスト作業にかかっていた割合はいかがでしたか?

    向井) テストに0.5から0.8人月かかっていました。開発者1人とすると5割〜8割ぐらいになります。

    竹原) それなりにボリュームありますね。
        品質向上への取り組みとして、導入前は0.5人月以上の時間がかかっていたということですが、以前からギークフィード様はかなりしっかりとしたテストをされているという印象があります。その頃の失敗したことやうまくいかなかったこと(テスト自体がうまくいかない、想定以上の期間がかかってしまったなど)はありますか?

    向井) 開発者とテスターを分けるのが難しかったので、開発者が自分でテストしていた。あまりよろしくない状態でした。既に何回かテストしていて自分が把握しているからここはOKと思ってしまいテストを省く。そうするとそこが知らないうちにバグっていたり。

    竹原) なるほど。開発者自身がテストを行うから、「だろう運転」でバグが発見できなかったりしていたんですね。

    向井) そうですね。でも、そういった内包的なバグはありつつも、テストはしっかりできていた。

    竹原) では元々テストのノウハウはしっかり蓄積されていたわけですね。

    向井) 納期の関係や認識の問題で何回もやってるから大丈夫と思った箇所があったり、テストの範囲が狭まってしまっていた。反面、人に伝えなくてもテストができたので素早さはありました。

    ShouldBeeを使い始めたきっかけは?

    内 ) コストの削減とリリースまでの期間の短縮をしたいと思っていたところ、ShouldBeeを見つけ、私が導入を決定しました。

    以前はどのような方法でテストを行っていたのか

    向井) エクセルでテストケースを作成して、それに○☓をつけていくといった形です。これの作成にかなり時間がかかっていた。テストは手動です。
    内 ) テストケースは納品物に含まれていることが多いので、自らが積極的に、というよりは作る必要があって作っていました。単体テストをする人が最初に(主観で)作ってテストしています。それに対して受け入れテストの時はテストケースは書かず、ひたすら人力で手動でやっていました。受け入れテストは基本的に正常系のみでモンキーテストに近い感じです。

    竹原) どれくらいのケースを作成されていましたか?(1ステップ1ケースとして)
    向井) 画面によって変わりますが、1画面あたりでおよそ100ケース前後ですね。

    導入前、ShouldBeeに期待していたこと

    竹原) 導入前に、ShouldBeeにはどんなことを期待していましたか?

    向井) 1番に期待していたことはテスト工数の削減です。課題として解決方法をずっと検討していた。

    竹原) 工数削減以外には?

    向井) 開発者以外のメンバーがテストを作成したり実施したりして、役割分担ができるようにという狙いがありました。

    竹原) その狙いはスピード面ですか?、コスト面ですか?

    向井) 両方ですが、どちらかというとコスト面が大きいです。人員が少ないので。

    内 ) テストをしてみると、同じフローを通すということがたくさんあります。1箇所を修正すると、過去に動いていたところが動かなくなるということも多々あって、それを探すためには毎回同じフローを通さなくてはならず莫大なコストがかかるのですが、(リグレッションは)結構な頻度で起こりえることなので、一度通したパターンは自動的に行うということで工数削減を期待していました。

    竹原) 工数削減以外には?

    内 ) スピード面、コスト面の両方ですね。連動していますし。

    竹原) 品質についてはどうでしょう?

    内 ) 人間が行う場合、修正依頼をチケットで出して、それに対して修正できているかどうかを手動で確認して判定していくのですが、過去には動いていたけども何かの修正後に動かなくなっているという意図していない箇所にバグが入っているケースもあり、それはたまたま見つかるというケースが殆んどでした。ShouldBeeを入れることによって過去に通っていたテストケースも自動的にテストがされて、デグレードと言われるものが撲滅できるのではないかと期待していました。

    テスト自動化に向けて、他のツールやサービスは検討されましたか?

    内 ) 深くは探していませんが、オープンソースでもSeleniumなどテストの自動化ツールが流行っていた時期でしたので幾つかのツールは知ってはいました。しかし、日本語でテストが書けるということから開発者以外でもテストが書けるという(コスト削減への)期待と、森さん、野澤さん(という優秀な人が)が作ったサービスだから効果が出るのだろうという期待もありました。

    導入に向けての準備について

    内 ) 九段下のコワーキングスペース(パートナー様オフィスの近く)で、社員だけでなくプロジェクトを一緒に進めるパートナーの人も一緒に使ってもらうために関係者を招いて、森さんと野澤さんに来ていただき使用前にデモンストレーションをしてもらいました。勉強会は2時間くらい。社員だけでなくパートナーの人にも受入れられやすいように勉強会を行い、「いいねー!」となってから導入をしました。

    向井) ShouldBeeはウェブベースと聞いていたので、環境などで特に準備したものはなかったですね。実際に使うためにサイトでチュートリアルを確認したり、簡単なプログラムのテストを作って試してみたりしていました。それと全社員が使えるようにと、周知と使い方の講座を社内でやっていました。

    ShouldBeeの使い方について

    竹原) 実際にShouldBeeのどのように使っていらっしゃいますか?

    内 ) メインは納品前のテストです。最終試験として。

    向井) ウェブシステムのマイページの開発をしていたので、ログインしてからそれぞれのメニューに飛んで一連の流れを一気につくってテストを流してってやってました。

    竹原) 使うタイミング(フェーズ)は?
    向井) (最終試験以外では)単体テストよりも結合テストで使っています。お客様に見せる前に内部で一連の流れで不具合が起きないかの確認に使っていました。

    ShouldBeeを使ってみての苦労はあったか?

    竹原) ShouldBee使ってみての苦労は?

    向井) 日本語でテストが書けるのですが、最初は開発者としてはプログラミング言語的なもので書けたほうがやりやすいと感じました。

    内 )(苦労ということではないんですが)ShouldBeeにエレメントを認識してもらうのに、開発段階でidを付与したりといったことに気を遣うようになり、より自動化がしやすくなりました。自然とプロトコル(コーディング規約の意味合い)が統一されるというか、社内での書き方がShouldBeeに読んでもらいやすいようにと意識するようになりました。

    最も苦労した点

    内 ) 日本語でテストが書けると言っても、ShouldBeeでエラーになっているのかプログラムのバグでエラーになっているのかが最初わからなくて、テストケースの文法のチェックをしたりして、ShouldBeeの使い方で、いろいろな使い方(テスト構文)がある反面、ちゃんとした使い方を覚えなければならないので、その点では苦労しましたが、オープンソースの製品より使いやすかったと思います。

    竹原) 日本語で書けること以外にやりやすい部分はどんなことがありますか?テスターさんがエレメントを特定させる部分でやりづらいとか?

    向井) 特に無かったです。

    期待していたことはどの程度達成できたか?

    内 ) 80%くらいですね。

    向井) はい、僕も80%くらいですね。ほぼ満足はしているので100%と言っても良いんですが、強いて言えば今後もっと便利になることを期待しているのが残りの20%です(笑)

        結合テストに関しては、かなり工数の削減や期間の短縮ができました。でも、人員の役割分担については社内事情もありあまりわけられなかったです。

    竹原) それなりの期待した効果と高い満足が得られているということですね!

    導入後の変化で予想外に得られた効果

    内 ) パートナーやお客様とのコラボレーションにおいて、新規案件でも既存案件でもこれまでは品質の担保をするのがなかなか難しい面がありましたが、ShouldBeeを使ってやってますと言う事で信頼を得ることが出来たと思います。一緒に確認できますし、どんなテストを行ってどういう結果が得られたかのエビデンスが全てスクリーンショットで残っているので、それらを共有できるというのが良いですね。

    向井) ソースコードも綺麗になりましたね。id振ったりしますし。(暗黙的に)ShouldBeeがコーディング規約になっているという効果ですかね。

    今後、期待するところは?

    内 ) テスト自体のアウトソースも含めて出来ると良いと思います。

    竹原) 実は今もお客様のオファーに応じてテストスクリプト開発はやらせていただいているんですが、今後はメニュー(表面に)に出して行こうと思います。

    向井) 対応ブラウザが限られているので、今後はWindows版SafariやMac版各種ブラウザ等、対応ブラウザが増えると良いですね。

    内 ) あとは、難しいのかもしれないですけど、ウェブ以外のアプリケーションについても強いニーズが有ると思います。例えばWindowsで動くクライアントアプリケーションとかだとWindowのハンドラー拾って自動で動かすとか。もしかしたら既にそういった製品があるのかもしれませんけど。

    竹原) そういった製品はありますね。他社ではあるのですが…

    内 ) あー、そうなんですね(笑)そういった意味ではShouldBeeを使わないパターンのテストのノウハウも紹介して頂けると嬉しいかな。

    竹原) 実はウェブではあるのですが、AndroidやiOSのブラウザでのテストもできる機能を試験的に搭載しています。ほぼ告知していないということもありますがあまり使われていなく、次期バージョンでは無くなる予定なんです。ShouldBee側の開発や保守のコストもかかるので、いったんPC向けの機能に集中しようということで。ただ、Windowsのネイティブアプリやスマホのネイティブアプリでもテストのニーズは高いことは知っているので、今後の開発における検討スコープには入っています。GoogleやAWSなどでAndroidの実機テストができるファームが整ってきているので。

    料金ついて

    竹原) 最後になりますが、料金ついてはどう思われますか?

    内 ) 比較対象がテスターの工数(コスト)になるのですが、ちゃんと使えば非常にリーズナブルな価格だと思います。1日人が稼働するとShouldBeeの月額より高いので。プロジェクトの規模が大きくなればなるほど効果は高いと思いますし、うちでは今後取り組む予定ではあるのですが、開発したものの納品後のサポートと機能追加開発を継続的にずっとやることが多いので、リリース後もずっと使い続けると良いと思っています。1回(テストスクリプトを)作ってしまえばずっと使い続けられるし、なにより受け入れテストが楽ですから。

    竹原) インタビューは以上になります。本日はお忙しいところお時間を頂きましてありがとうございました!今後のお役に立てるよう継続して研究やカイゼンに取り組んでいきますので、今後ともどうぞよろしくお願いいたします!

    ShouldBeeを試す
    テスト環境の準備不要!
    いますぐShouldBeeをお試し下さい。
    インストール不要。
    複数種類のブラウザ準備不要。
    テストは日本語だけでなく、英語でも書けます。

    私たちはより多くの方にShouldBeeの機能を体験して頂きたいと思っています。どうぞお気軽にお試し下さい。10日間無料で全てのブラウザでの機能をお試し頂けます。
    ShouldBeeを使ってみる