![](https://images.logmi.jp/media/article/331351/images/main_image_6b591c1ac9b2fd8d4da82a0cccfed54e8b9e39b6.jpg?w=600)
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
藤原大氏(以下、藤原):もう1個、たぶんこのイベントの事前準備でヒアリングをした時にお話ししてもらったネタで、すごく印象的でしたが、「テストを作成したあとにこういう型を作っていくのが大切」だというお話をされていました。これについてもうちょっと教えてもらえますか?
増原賢秀氏(以下、増原):型というより、テストをスケールするためには、「何をテストするんですっけ?」とか「どう作るんですっけ?」とか、そのあたりがある程度決まっていると、自分以外のQAもそうだし、開発者やBizDev、Bizの方が作ったり見たりする時に迷いがないかなというのがあります。そういうのを整備する必要がある、みたいな話でしたっけ?
藤原:そうですね。あとは「テストの自動化は後回しにしない」という話もされていましたね。
増原:そうですね。ちょうど今週も1個、僕が今mablを入れているプロジェクトで、ステージングにデプロイされて、mablがコケていて「対応します」と伝えました。そこからリリースができましたが、そういうのは事前に「mabl落ちたら教えてよ」というコミュニケーションのフローというか型なども決めとかなきゃいけませんし、周知などもしておかないといけません。
藤原:なるほど。確かにそうですよね。あとは「安定化にコストに割く」と言っていましたね。リグレッションテストができているという状態を目指して、先ほど話されていたみたいに、何をE2Eテストすべきかが決まっていて、デプロイ前にはもう終わっている状態を作る。こういう型を作るような話もされていました。
増原:これはそのサービスに求められるレベルにもよると思いますが、今担当しているプロジェクトで言えば、リリース前にそこが担保されていないとマズい認識なので、そこを整備しないといけません。
でも、プロジェクトの中でいくつかシナリオを用意して新規で追加しなきゃいけないようなこともあるわけです。そういう時にどういうテストを作るかというと、先ほど最初にテストを1個作った時の話で、それっぽいものはQAエンジニアも作れると思う。しかし、ビジネス的にそれでいいのかというインプットはBizの人は必要なので。じゃあテストを今後も足していく時に、それをいくつもインプットする必要があるよね、ということを決めておく必要があるということですかね。
藤原:ありがとうございます。とてもわかりやすいです。最後1つだけ聞いて、あとは質問の回答をしようと思っているんですが、ずばり今の立ち上げ時点で、テスト自動化による恩恵は何だと思いますか?
増原:今Ubieに来てmablの導入プロジェクト1ヶ月ちょいぐらいですけど、やはり効率的にチェックできるところです。
藤原:それがmablの仕事ですからね。
増原:そうですね。それが最大の恩恵な気がするなぁ。
藤原:逆にmablのようなツールが得意なことは、何だと思いますか?
増原:得意なのは、自動化周りをやったことある人ならわかると思いますが、画面を使って操作して、それを繰り返して実行できるというか。それをサーバー上でブラウザを並列して実行できるとか。mablのメリットはたぶんそこだと思います。一方で、ブラウザ操作周り以外のことはあまり得意じゃないので、「それ以外はそもそもやらせないようにしましょう」と思いますね。
あとやはりバリエーションをどう実装するかにもよるけれど、バリエーションのテストみたいなのはそもそもやらないほうがいいし、「ほかの方法で担保できるならそのほうがいいんじゃないの?」とも思います。
藤原:なるほど。ありがとうございます。とてもおもしろいですね。本当に「得意なことをやらせる。以上」っていう感じですね。増原さんは、もう割り切っているというか、わかりきっているという感じなんですよね。
増原:うーん。長く使っているからだと思いますが、あんまりそもそも期待とかないし(笑)。やはりmablの最大のメリットというか、僕が買っているところは、「安定した実行環境」と「簡単にテストが作れる作成環境」だと思っています。安定しているし、ChromeDriverのバージョンアップもしなくていいし、実行環境のメンテもしなくていいし、そのあたりかと。
藤原:なるほど。ちょっと時間もまだあるのでおうかがいしようかと思うんですけれども、1個目のコメントもおもしろいですね。「テスト自動化の立ち上げ、うまく動いてもらえるように伝えることは本当難しい」という方もいるんですが、テストの立ち上げを伝えるのはやはりやはり難しいですかね。
増原:自分はmablがあると何ができるかを知った状態で今やっているので、あまり躓いたというのは、今回の場合はないのかもしれないですが。確かに伝えるのは難しいかもしれない。でも、つらいことはつらいと言っちゃっていいんじゃないでしょうか?(笑)
藤原:確かに(笑)。
増原:絶対最初で成功するかというと、そうでもないと思うので。
藤原:そうですね。先ほどの話にちょっと戻りますが、スクラムのイベントで共有するとか本当に地道なところからやっていますもんね。BizDevを交えて何ができるか話すとか、できたことを話すとかタスク化するみたいな。けっこう地味な感じだと思いますけど、そういうのをコツコツやる感じなのかなという気もしますね。
増原:やり続けていれば、そのうち成功します。
藤原:ありがとうございます。「自動化して実行するテスト環境は、自動テスト専用環境ですか?」という質問です。
増原:現状の環境だとノーですね。開発者の動作確認も兼ねている場所なので、E2E用環境ではないです。
藤原:Devも使っている感じなんですね。
増原:なので、mabl内である程度環境、まあQA、ステージングみたいなプランを作って実行すると思いますが、QA環境のところは真っ赤っかみたいなところがあります。つまり、ずっと落ちているという状況が続くこともあります。
藤原:ありがとうございます。佐々木さんのところの自動化環境はどうでしたっけ?
佐々木邦彦 氏(以下、佐々木):僕はテスト、ステージジングと本番環境があって、ステージングはQAでも使って。
藤原:きっとmablとかも、ステージングに向けているということですよね。両者とも専用ではないんですよね。
増原:専用じゃないですね。
佐々木:専用じゃないですが、ログインユーザーとかはメアドの先頭に「E2E」とつけてわかりやすくするようにするような、ちょっとした工夫はしています。
藤原:ありがとうございます。もう1個似たような質問なんですけど、「バリエーションを増やすのはけっこう大変。例えば事前のデータ準備はどうやっていますか?」という内容です。
「例えばECシステムだと、本人確認済みユーザー、本人確認前ユーザー、ショップ開設済みユーザーとかバリエーションがありますよね」という具体的な話をされているんですが、事前にデータはどうされているんですか? 専用環境じゃないということもあると思いますけど、増原さんはいかがですか? 増原:今は事前にユーザーとかデータを準備しないシナリオしかないです(笑)。
藤原:しないシナリオね。
増原:ログインとかそういうことはしなくてもいいやつなんですけど、それって大変ですよねー。
藤原:そうですよ。たぶん毎回やらなきゃダメみたいな感じなんですよね。
増原:どこでの経験とは言いませんが、やはりデータの準備やマスター、本番から週1データシンクして育てたアカウントが飛ぶとか、そういうのもよくあると思うので(笑)。
藤原:確かに。あるあるですね(笑)。バリエーションは入力値の組み合わせやデータ、ユーザー権限とかだと思います。
増原:mablは作ったテストの数で課金は増えないので、mablだったらデータを作るシナリオを作ったほうがいいかもしれない。
藤原:そうですね。確かに、それをやられている方ももちろんいます。ただ、それでコケると全部落ちるという悩ましい問題もあります。
増原:それ前提だとね。
藤原:そうそう(笑)。だから1個ずつ作るのがやはり一番便利なんですけれど。佐々木さんはどうですか。アペルザの場合、まさにEコマースがあるので「本人確認済みユーザー」とか聞き覚えのある感じがするんですけれども、どうされています?
佐々木:ありますね。そこは手作業で作って、それをずっと使っています。幸いデータが飛んだとか前提条件が壊れたというのはなく、何年か使っている感じです。
藤原:アペルザの場合はアカウントを本当にうまく切り分けていますよね。
佐々木:そうですね。1つのテストに1つのユーザーというかたちで今作っています。
藤原:あとは新規作成系は毎回作っているし、既存のものであれば使い回せるし、きっとデータ作成まではまだ手を出していないですよね。
佐々木:そうですね。
藤原:ただ、今後そういうところもAPIとか使えるようになってきたので、たぶん運用編のところでお話ししてもらえるかなと思っています。
最後にもう1個質問です。「デスクトップアプリの活用で、開発者のローカルで実行できるように、開発者支援のニュアンスの強い自動テストの使い方をしていますか?」。これ「誰がやるねん?」みたいな感じですかね。増原さんはいかがですか。
増原:やはりQA環境やステージング環境は、少ないインテグレーション環境で、そこにデプロイされて、初めてテストがぶっ壊れているのがわかることはやはりつらいなと日々思っていて。やはり開発者の手元で実行してもらっています。でも、たぶんmablはそうしてもらうのが一番と思っていて、こういうローカル実行の環境も用意していると思うので、そちらを広めていきたいとは思っています。
関連タグ:
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.06
落合陽一氏や松尾豊氏の研究は社会に届いているか? ひろゆき氏が語るアカデミアの課題と展望
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10