最終更新日: 2021年11月9日
2021年5月26日、第4回目となるAIQVE ONE主催のオンラインセミナー、QA Tech Nightを開催いたしました。この記事では、その中で行われた、株式会社ベリサーブ 研究企画開発部のサービス開発課 朱峰様、岩瀬様とのパネルディスカッション内容をお届けいたします。
＜関連記事＞
【QA Tech Nightレポート】テスト効率化ツール紹介（株式会社ベリサーブ 朱峰様）
【QA Tech Nightレポート】ソフトウェアテストの課題とテスト管理ツール（株式会社ベリサーブ 岩瀬様）
桑野（AIQVE ONE)：
パネルディスカッションのテーマなのですが、『ゲーム業界におけるソフトウェアテスト管理』としています。これはですね、当社AIQVE ONEでは品質分析やツールを駆使して、通常のゲームのテストも管理することで効率化していこうというのを掲げていまして、まさにこのQualityForward（クオリティフォワード）を使ったら、いろいろできるんじゃないかということで取り組まさせて頂いているんですけれども、ベースになっている考え方とか、ぶっちゃけそんなできてないでしょというところがあると思っています。
こんなこと話したいなというのを3つ用意してきました。
まず開発、これはゲームに限らないと思うんですが、開発のプロセスがカオスってるというところですね。
テストケースがなかったりプロセスが行ったり来たりしている中で、どうやってテストを管理していくのか、という話題が1つ。
2つ目に、一般的なPB曲線にもとづくテスト管理とゲーム業界に対する適用性。
3つ目に、ゲーム開発におけるバグ分析はどのくらい重要なのか。
僕ら、こういうことを目指して、提供しているお客様によってはできてなかったりするんですけど、それを見て貰ったときに、ベリサーブさんがゲーム以外のところで培ってきた経験から見るとどうなのか、というのを話していきたいなと思っております。
どれから行きますか？朱峰さん。
朱峰様(株式会社ベリサーブ）：
では、まずジャブってことで、基本的に今日はゲーム業界の人が多く来ているんでゲームに関する関心が高いと思うんですけれど、僕たちはいつもこうやっているよというところから、じゃあ違いってどうなの、というのを見ていけたらと思ったので、順番が前後しますがまず2つ目から。
まず、何の話をするかというとおもむろにPB曲線って言ってますが、聞きなれない言葉という方もいると思うので、岩瀬の発表でも触れていましたが、いろいろ出ている折れ線グラフです。これ今きれいなサンプルを出してくれましたが、実線・点線それぞれ全部で3色ずつのものがあるかなと思います。
まず右上から下がっている緑の線ですね、これがテストの消化状況と思っていただければと思います。最初たくさんテストがあって、これがだんだん消化されることで下がっていく線なんだな、と。
基本的に点線が計画で、実線が実績ですね。これは他の色の線も同じです。
なんでまず右から下に進んでいきます。
一方、青のセットに着目すると、これは欠陥の予測と実績ということで、見つかった実績、バグ、障害、言い方はプロジェクトによって様々だと思いますけれど、基本的にはゼロから始まって、だんだん右肩上がりになっていく線ですね。
これを追いかける形で今度はオレンジ、これはさっきと反対で修正されたバクですね。オレンジが青を超えることはないです。
青がまず上がって、オレンジ色が追いかけていくと。
これが開いていくと不幸なプロジェクトで、順調に追いかけて最後には全部合流するのが理想になります。
この3つです。テストの消化率。バグの出た数。そのバグのうち修正された数。この3つをプロットしてプロジェクトの状況を可視化して、ただ可視化するだけでは意味なくて、日々日々状況をみてなるべく早くアクションを打つために可視化しようということを目的にこのようなツールを使っています。
以上がPB曲線ということで、これを踏まえて、たとえばリスクを検知するとかアクションを打つとか口で言うのは簡単だけどさ、という感触を持たれるかもしれないので、
ちょっと具体的にたとえばPB曲線がこういう動きをしていたらこういうやばさがあるんじゃないの、というのを僕らから幾つか普段こういうのを見てます、というのを話して、それをゲームの文脈に少しずつ話を掘り下げていきたいと思います。
岩瀬様（株式会社ベリサーブ）：
この図自体は、その後にですね、型についてご紹介したいと思うんですけれど、もともとはモノイストで公開されている山浦さんのコラムをもとに作られています。そこに対しての対策っていうのをこちらで考えた資料ですね。
どんどん早速見ていきますかね。
朱峰様：
つまりは、これを私に読み解けと言うことですね。その問題を私に出したということですね。それでは私の解釈ということで、私もこれほぼ初見なんですけれど、ガチでやっていますが、まず緑の線をみると順調に下がっていますね。当初予定した計画通りにテストケースは、はけている、と。一方、青をみると、これが出たバグですね。
これには1つ難しい問題があって、そもそもバグの予測ってどう出すんだよというのがあるのですが、今この瞬間は忘れて頂いて、とにかく計画があります、と。それを大幅に超えている。バグは思った以上に出ている状況。割と1.7倍ぐらい出ている状況なのかな。
一方でオレンジ色の線をみると、バグはなんとかちょっとずつ修正はしているんだけれど、そもそもバグがいっぱい出ているのに対して、バグ修正は理想に追いついていないという状況が見えると思います。
テストは順調に進んでいるんだけれど、とにかくバグが出るし、バグの修正も追いつかないという、かなりやばい状況。もうちょっと早く気づけよ、という風に見えるので、私だったら「一旦手を止めませんか」「プログラムの作りというか設計ぐらいから見直しませんか」と言いたいところですね。
どうでしょう。
これで解釈合ってますか？
岩瀬様：
そうですね。これは『バグだらけ型』と言いまして、テストの品質は普通、プログラムの品質は低い。対策はテストをこのまま進めて、バグの傾向分析を行った上で、追加のテストを実施した方がいいんじゃないかということですね。
朱峰様：
確かに傾向分析は必要ですよね。たくさん出ているので。確かにたくさん出ているけれど、偏っている可能性もありますからね。私の言及不足ですみません。
岩瀬様：
『バグだらけ型』は、結構未熟の組織で頻発するパターンが多いです。
もう一問いいですか？
朱峰様：
なるほど、これはさっきとは打って変わってのグラフですね。
テストの進捗は芳しくない。
ほぼ横ばいなんでしょうね、きっと。
一方、バグの状況も計画に至っていないバグの実績も予測を下回っているし、
当然オレンジの線も下回っているというのが事実。
これは、バグに対して言及する前に、そもそもテストが進んでいないんですね。
テストが進んでいないんだからバグも見つからんでしょ、というのが当然の理論のように見えるので、おそらくテストのブロッカーが何かあって、1週間ぜんぜんテストできないとか、テストの実施に何か問題あって実行できないのかな、というのが読み取れます。
テストの実行環境とかテストの実施手順、大丈夫なの？とか。
作ったものをどう触ったらいいかわからない、開発とテストの分断みたいなのも、特に我々は第三者検証会社なので開発に十分コミットしてないというところもあり、そういった分断も読み取れるので、コミュニケーション改善みたいな話をした方がいいのかな、と思います。
岩瀬様：
まさしくですね。これは『停滞型』といいます。
コミュニケーション不足があるときに起こりやすく、特にテスト担当者の経験不足もあるので、ベテラン勢を数日張り付かせるとか、開発とテスト間の連絡役を配置するとか。
朱峰様：
慣れている人を入れるというのは確かにそうですね。
岩瀬様：
さっきのブロッキングがあってテストを実施できない、というのもある意味コミュニケーションができていなかったというのもありますよね。
もともとテストができない状況なのに、テストを開始しようとしたという。あるあるですよね。
桑野：
はいはい、こういうグラフをよく見ますね。
岩瀬様：
もう一問いきますか。これはどうでしょうか？
朱峰様：
なるほど。1つ目と3つ目のミックスのような。
テストの進捗は、さっきのほどじゃないけど芳しくないですね。
でも、バグ自体はそこそこ出ている。計画を大きく上回ってないけれど、ちょっと上回るぐらい出ている。
バグの修正は若干追い付いていない感はあるものの、とはいえそれなり頑張って消化している。
あんまりテストが進んでいないのに、それにしてはバグがでているところが結構あり、むしろやばい。
さっきはテストが進んでいないからバグがでていない、だったのが、
こっちはテストは芳しくないのに、それでもバグが出ている。
それがやばいという気がしなくもない。
さっきは開発止めてとか過激なこといいましたけれど、
むしろ、こっちはそれに相当するのかな。
桑野：
お医者さんみたいですね。
カルテから読み解くみたいな。
岩瀬様：
まさしく『深刻型』と呼ばれていて、さっきより危ない状況です。
現在のコードは破棄して、設計レビューの上、実装をやり直す必要があるんじゃないか。
無理矢理進めると寿命が短くなる可能性がある、と。
こんな感じで、進捗状況からいろいろな情報がみてとれるんですね。
桑野：
これ出典元は組み込みのやつなんですかね。
岩瀬様：
はい。検索して頂くと出てきます。
https://monoist.atmarkit.co.jp/mn/articles/1002/18/news101.html
https://monoist.atmarkit.co.jp/mn/articles/1003/19/news097.html
朱峰様：
モノイストというメディア自体、親はITmediaという超大型の有名なところのサブメディアでモノイストっていうのがあって、主に製造業とか組み込み開発向けのトピックを扱っているところになるはずです。
岩瀬様：
このようにPB曲線からいろいろな状況・リスクが把握できるので、第三者検証でも結構使うことが多いですね。
桑野：
ベリサーブさんの方で扱う商品とか製品の方でも、やっぱり似たような感じのものって見ますか。
岩瀬様：
見ますね。
桑野：
そうですか。QualityForwardがあると発見も早いですが、ない頃は誰かがエクセルで誰かが集計して、それをさらにデータ化しないと出てこなかったんですか。
岩瀬様：
そうですね。さきほど紹介した通り、課題でそれをまさしくやるのがテストリーダーで、毎日一生懸命集計してお客さんに見せる。多拠点になれば、それをマージしなくてはならない。
桑野：
テストリーダーがテストを管理せずにひたすら事務作業に入っちゃう悪循環というのは、ゲーム業界でもあるあるです。
品質のことは誰が考えているんですか？という状況になっちゃうんですよね。
朱峰様：
アクションを起こす起点になりえる人をなんとか事務から剥がしてというところがまず第一歩なんでしょうね。
桑野：
なるほど。これ面白いですね。これだけで1つのコーナーができるかもしれない。参考になります。
我々もそこを目指していて品質分析しましょうとお客さんに言うんですけれど、やっぱり似たような考えと思想で、そういった表を作ってます。今、お見せしていいですか？
朱峰様：
出るまでのつなぎに。
こういうグラフとかを出せても、そこからアクションを起こせないと意味がないというのが重要なポイントですね。
新任テストリーダーを育成する際は、今まさに私が急にやった問題集を研修で教えるというのもいいかもしれませんね。
桑野：
弊社もですね、品質分析というのをゲーム業界に広めていこうという取り組みでやっていて、今おっしゃっていただいた分析・可視化しましょうということなんですけれど、ランク別に不具合の状況をだしたり、テストケースに関しても予定数に対してどのくらいやっているかというの日々つけていきましょうというのをご提案しています。
やはりこの、先ほどのグラフほどではないのですけれど、予想のケース数に対してどのくらい終わっているかというのを出して、2週間で終わってないじゃないか、ということになる。昔はここが可視化されてなかったので「なんで終わってないんだよ！」と揉めてたんですけれど、たとえばここだと、未実装とBLOCKが多くてケースが先に進まないですよね、ということがあって、そういった問題や課題が出たときにどういう手を打つかというところまで提案させていただいております。
たとえば開発の方のミスが多いんじゃないですか、とか、バグがやたら多く出ているところは、ケースをそっちに集中的にみていきましょう、とか、そもそも未実装・BLOCKが多いのであれば、一回テスト止めて無駄な工数を割いてしまうので、まず実装していただいてそこからテストしましょう、というのを少しずつですけれどご提案することで、より効率的なテストができるんじゃないか、ということを目指してやってはいるものの…
ものの…なんですよね。
なかなか、そういう風にいかないことの方が多いのが、わりとゲーム業界あるあるなんですね。
前回、2回ぐらい前のテックナイトで弊社の花房が話させていただいて、今日はゲーム業界じゃない方もいらっしゃると思うので、どんな感じなのかなというのをお伝えしますと、ゲーム業界って、ゲーム業界に限らないのかもしれないですけれど、ギリギリまでいいものをつくろうとしてデザインがかわったり仕様が変わったり、一回ぶっ壊してもう一回作ろうというのをデバッグが入ってても発生したりすることがあります。
パブリッシャーと開発会社とテスト会社だけでなく、さらに権利元とかがいて、たとえば監修が入ったりするんですね。アニメとかだともう少しシャープにしなきゃだめだよとかバツが入ることがある。
テストとしてはできるのに、その素材が入ってなくて遅れたりとか、計画立てても計画通りいかなかったりとかそれ以外にもざっとあります。
基本はウォーターフォールで定義して設計して実装してテストしてという流れには沿っているものの、同じことをぐるぐる回していてどんどん遅れているというのがよく見受けられます。
こんな中で計画通りにあんなの使えないじゃないか、というのがあるので、どうしてもデスマーチとかになっちゃいます。ドキュメントの更新が追い付かないとか、そもそも仕様書がないとか、ソフトウェアとしての正しい制御なのかというのも分からなくなってしまうという状況なので、テストの考え方を入れると、どれが正解なのかわからなくなり、人が触ってとにかくバグを出すという属人性の高いフリーテスト、いわゆるユーザーレベルで触ってバグが出たら報告してっていうのがこれまでずっと長い間、最適化、効率化されていたという経緯があります。
特にコンシューマーゲームだと1日30人とか50人とか動いて一気にドーンとテストしてそれを何ヵ月も続けたりするので、管理はしているものの実際のやる人たちはひたすら触るというのをよくやっていましたが、スマートフォンとかウェブ側の方が入ってくることによって、ある程度テストを項目作ってやっていきましょう、みたいな文化が4～5年前から徐々に広がってきて、割と今ではゲーム業界でもテスト項目作ってちゃんとやっていきましょうという風になったんですね。
朱峰様：
文化が輸入されてきたみたいなことですね。
桑野：
はい、そうすると逆転現象が起きていて、すぐ触ればわかるバグがテスト項目をつぶすことに集中してしまって、「項目になかったので見ていません」みたいなことも起きている。
なので、2つの手法が入り混じって、さらに担当者さんの考え方も違うので、先ほどコンテクストの話もでましたけど、テスト管理の話の前に、背景や目線を合わせてからスタートしなければならないということを、我々が頑張って啓蒙していかなければならないかなと思っています。
こんな感じで、結局アルバイトをたくさん雇って触らせればできるんでしょ、という空気も若干ありつつ、ただ最近になってソフトウェアテストの意識が高い、それを実践投入されている会社さんもいくつかあります。そのあたり、ゲーム業界どんな感じで、やっているのか身にしみてわかっている仲間を召喚していいですか？
片岡さんいますか？
片岡（AIQVE ONE）：
はい、います。
桑野：
今、僕が言ったのってあってますか？
片岡：
もちろんです、その通りです。
桑野：
逆に、朱峰さん、岩瀬さんが今のゲーム業界の話を聞いて、いかがでしたか？
朱峰様：
まず、率直な意見は大変そうだな、なんですけれど、それは他人事っぽく聞こえるので、業界というか作っているものの性質はどうあれ、似た話はあるんでしょう、と。たとえば先ほど見せていただいた、きれいなウォータフォールがあるんだけれど、その下に現実があらわれる絵を共有していただいたんですけれど、多かれ少なかれああなっちゃってる、というのはどのプロダクトも、いわゆる組み込み系も製造系もそうだろうしエンタープライズ、業務システムでもあるのだろうと思います。
ただ、おそらく程度問題なんですよね。それがゲーム業界はもっとしんどそうで、どっからがっしゃんみたいなことが平気で起こるような印象をまず抱きました。
いくつかテスト管理の文脈として気になるところは、たとえば、さっき我々PB曲線、ある種理想的なというか、いくつのかパターンのPB曲線を出しましたけれど、あれっていくつか前提があって、基本的にテストケースって最初に全部設計できるんだ、と。それがだんだん下がっていく、そこの下がり具合で、いろいろアクションをとっていくんですけれど、かつ変更とか入ってくるんでしょう。ただ基本は1回は全部できる、ていうのが前提にあったのが、多分それが通用しないんだろうなというところがあるので、そこから考え直さないといけないんだろうな、という風に感じました。
で、もうちょっとしゃべっちゃいますけれど、素人目だったりいやいやって話もあるかもしれないんですけれど、聞いてて思ったのは、全部をやるのは無理でしょうと。なのでその場合、できるところからやるしかないと思うんですよね。
そのあとはできたものに対して新しいケース追加して、不確実性ですね、変化を受け入れていくというできるところからやっていくしかないんだろうと思いました。
変化を受け入れるというキーワードから私が連想したのはスクラムですね、アジャイル開発とセットで語られますけれど、スクラムって別にアジャイルじゃなくても使えるものだと思っていて、まあ予測できないものは諦めて、予測できる範囲で細かく区切ってインテグレーティブに段階的に実施しましょう、というのがスクラムの考え方なのかな、と。不確実性を受け入れて、そのために小さく小さく重ねるというアプローチですね。
全部を受け入れるのは無理なので小さなサイクル、たとえば基本的に一週間単位の活動にしましょう、と。一週間単位で出来る範囲でテスト設計して消化して分析して、次の1週間に向けて活動していくみたいな、そのように小さく区切ってやる。その中でテスト管理で有効なところを、たとえばQualityForwardみたいなツールをフルで活用するのはおそらく大変なので、必要なポイントだけ押さえてやっていくんだろうな、と想像しました。
桑野：
なるほど。わずかこの短い時間でコンサルしてもらったような、多分そうなんだろうな、と。片岡さん呼んで答え合わせてしてみましょう。実際片岡さん、今の予想ってあって、実際にやろうとしても開発体制とうちの考え方が合わないとか結構あったと思いますし、僕らもそこまで意識が高くなくて、昔のやり方を引きずっていて、流れてしまってとか、よくあると思うんですけれど、一番苦労したこととかあるあるとかありますか。
片岡：
そうですね。一番苦労というか可視化していきましょうというときに、やっぱり同じ目線でしゃべれるかというのが重要だと思っていて、こういったやり方がベストなんですよ、というのを伝えて理解してもらうのが苦労しますね。
そこを理解してもらえれば、こういう風にやればいいんじゃないか、とのってくれる人が多いんですけれど、そこを理解できないと、フリーデバック中心のやり方ということで、バグをいっぱい見つければ喜ぶという方向に変えざるを得ないみたいなそういうのが一番多いかな、というところと、
業務システムとかだとソフトウェアとしてちゃんとしているもの、安心感あるものを作っていくということになるかと思うんですけれど、ゲームの場合ってどうしても芸術品に近いのかなと思っていて、システムとしてしっかりしているのは当たり前なんですけれど、面白さだったり、人がウケるとか今流行はこれだというのを入れていくと、どうしてもぎりぎりまで企画を練るというところはあるのかなと思っているので、品質管理側としてはそういったところを理解した上で、面白いものを一緒に作っていく意識は必要かなと思っているんですね。そのあたりどっちをとるか、というのはあったりします。
朱峰様：
お客様に代わっていくためにも重要なのって、今がどういう状況なのかっていうのをお客さんの認識以上にはっきりさせて今ってこういう状況なんです、ていうのを知ってもらうところなのかなと思って。
さっきの桑野さんのスライドのなかで、もう1つすごく地味だけれど重要だと思ったのが、ブロックと未実装というのをしっかり可視化すること。なんとなくブロックしているんだろうなとか、なんとなく機能ができてないから進んでいないんだろうな、というのをなんとなくは分かっているんだけれど、でもそれをはっきり言わないと、ただ「なんでテスト遅れているんだよ」というのをただ怒られるっていう。
これだけのものができないから進んでいないんですよ、これは別にいい悪いとかじゃくて、事実としてこういう状況なんです、というのを数字を見てわかってもらって次の議論に進むのかな、と。
そのためにはバグの状況の分析とか、テストケースの分析は必要なのかな、と。
桑野：
まさにおっしゃる通りでございます。
まずスマートフォンとかになってからテストケースしっかり作ってやっていきましょう、というのが増えてきているので、要望もそうなんですけれど、実際に現場に入ると担当の方はそこまでの意識がなくて昔ながらのやり方だったりとか、現場のプログラマーさんとかは昔ながらの感覚でやってたりするので、「なんでこんなにバグ出ないんですか？」って初日に言われるんです。
でもケース消化してたら出るわけないじゃないですか、っていうのも分からないんです。
見ればわかるでしょ、バグ出てるじゃないですか、って。
でも僕らは、ただケースを順番に消化しています。なので、こっちは突っぱねても仕方ないので、粗々のバグはフリーデバックでちゃんと出して報告しつつもケースはちゃんと進捗させる、というのを融合させてやったりとか、そういうことをやったりします。
あと弊社の中にも、昔ながらの職人さん的なフリーデバックが得意な集団の、エキスパートチームというのがいまして、人より3倍ぐらいバグ出ししちゃう破格的にやっちゃう人も、そういう人たちは、そういう考えだし、でも僕らはテストケースをやらないといけないし、というのを社内でも水と油みたいな感じで考え方が違ったりする。
そこを社内でも融合しつつお客様にも提供するというのをやってるんですけれど、うまくいくこともあれば、なかなか難しいこともありますね。
朱峰様：
スクリプトテストとフリーデバックテスト－あえて探索的テストと呼んじゃいますけれど、併用します、と口でいうのは簡単ですけれど、分かってもらうのは大変ですよね。
桑野：
大変ですね。だいたいクレームっていうか、どうなってんの？とか。
頑張ってやっててもクレームとかあって実際方針変えて合わせたりします。
がっちり合うお客様もいるんですけれど、やっぱりお客様によっては途中で考え方を変えてやるっていう柔軟さも大事になってくると思いますね。
なんでそうなっているのかという背景を、ご説明する初出し資料があるんですけれど、
ゲーム業界って、担当者の方ってだいたい3属性あって、昔ながらずっとゲームデバックをされていて、コンシューマーゲーム出身とかでいわゆる人をばんと集めてやっているそういう考え方の人。
割とウェブとかスマホとかソーシャルゲームが流行りだしてからゲーム業界に入ってきた人、テストとかもともとやっていた方がゲームに入ってきてそれを浸透させて会社さんでいうとウェブ系だったりそういう系の会社さん、あとは真ん中で本当はやりたいんだけれど組織ができていない会社さんとかがいて。言葉も変わるんですよ、デバックだったりテストだったりQAだったり定義が変わってきちゃうので、間違った文章を使うとそれだけで嫌われるんですよ。
ベンチマーク企業は伏せてます。
このくらい、ずれるだけで変わってしまうので、営業のやり方や現場担当者の話し方も変えていかないと合わない、と。
それセットでうまくできたらいいな、っていうのを我々も頑張っているんですけれども。
今回テスト管理手法を、エクセルで頑張ってデータをとっていたのを、ベリサーブさんの仲間になったことで我々もQualityForwardを使わせていただくようになって、このゲーム業界にも便利なものをもっと作っていきたいと思って、実は片岡さん、今便利機能みたいなものを作っているんですよね。
片岡：
そうですね、作っているというか、今考えているものはあります。
QAツールとか自動化とかはあるんですが、可視化するものみたいなところは計画というか考えてはいます。
桑野：
なのでゲーム業界あわせた、全部使うのは無理だけど一部でも使ってカスタマイズしていこうという、まさにその考えで、考え方が合いそうなお客様からちょっとずつでも使っていけるようなものを今考えてやっていきたいなと思っています。
少しでも、これが広まってくれれば、皆さんが楽になることなんで、
宣伝になっちゃうんですけれど、ご協力してくれる会社さんいたら連絡ください。
では、最後に一言ずつ頂いて締めましょうか。
岩瀬様：
私、はじめての登壇だったんですが、非常に最初は緊張したんですが、ディスカッションは意外に楽しくお話できたので、またこういった機会があれば是非よろしくお願いします。
朱峰様：
はい、改めまして本日お時間いただきありがとうございました。
私は最初ちょっと宣伝して後半好きなようにしゃべっただけの人という印象をもったかもしれないんですが、その印象で全然OKなので、冒頭、紹介したものは興味があればお声掛けいただきたいですし、桑野さんがおっしゃったように会社の人としてもそうですけれど、業界全体としてテストの活動、品質保証の活動を効率化していくような、みさなんの仕事を助けていくようなツール、さっき3つ紹介しました。
これからもっと便利なものをどんどん既存ツールの機能アップもそうだし、新しいツールの企画もそうですし、そういったものをプロダクトマネージャーとしてやっていきたいと思いますので、是非みなさんのフィードバックとかも、もらいながら頑張って仕事していきたいと思います。今後ともどうぞよろしくお願い致します。今日はどうもありがとうございました。