もくテク「確定申告ソフトの開発舞台裏」を開催しました

こんにちは、カトです。
2021年5月13日(木)、もくテク「確定申告ソフトの開発舞台裏」を開催しました。

もくテクは、2016年に始まり2020年に中断、今回、オンライン開催でリニューアルして再始動しました。
f:id:yayoikato:20210517084207p:plain

今回のテーマ

確定申告ソフトの開発舞台裏
去る4月15日に申告期限を迎えた、今年2021年の確定申告。
今年の確定申告は要件が盛りだくさん。「会計ソフトの弥生」といわれる弥生をもってしても、多忙を極めました。
会計製品・サービスに関わる3人のプロジェクトメンバーが、開発時の苦労や工夫について、発表しました。

セッションの内容

定刻19:00。オンラインイベント司会が初めての弥生社員による、少し緊張気味のオープニングトークでスタートしました。
セッションは全部で3パートです。

1. 弥生会計で確定申告ができるようになるまでの裏話
トップバッターは、デスクトップ製品 弥生会計のエンジニアから。「今年の確定申告開発の苦労」をテーマに発表です。
今年の確定申告における変更点の数々、乗り越えた困難が目白押し、参加者から「エグい」とのコメントも…。
短期間でリリースまで進めたエンジニアの苦労話でもあり、会計ソフト開発のやりがいもわかる発表でした。

2. 火消しSEが弥生に転職する前と後
2番目は、クラウドサービスである弥生会計オンラインのQuality Leaderから。「チーム運営」をテーマに発表です。
開発プロセスや計画、設計がないと大変だという話がありました。 オンラインなので参加者の様子は見えませんが、「火消し」経験のある人が、きっと画面の前で大きくうなずいていたはずです。
スピード感を持った開発を進めるために、使っているテストマトリックスを改良してシェイプアップを図るという、今後の宣言もありました。

3. よいプロジェクトのためにやるべきたった1つのこと
最後は、クラウドサービスである弥生会計オンラインのTechnical Leaderから。「プロジェクト運営」をテーマに発表です。
令和元年確定申告対応における"しくじり"に対して、令和2年確定申告対応での改善でプロジェクトがどうなったのか。 開発中の不信感を解消され、納得感をもって安心して開発が進められるようになったことが、エピソードの対比でわかりやすく説明されていました。
「1人も欠かすことのできない大事なメンバーと仕事をしている」という、プロジェクトメンバー愛にあふれるあたたかいお話でした。

懇親?

リニューアル前

登壇者や弥生社員と参加者が、お菓子やドリンクを片手に自由に話をする懇親タイムを設けていました。
懇親タイムには、技術の話を深堀したり、登壇者がセッション時に紹介した趣味で盛り上がったり、会場の"ヤヨイヒロバ"をクローズする時間まで、いろんな話題が広がっていました。

f:id:yayoikato:20210515113426p:plainf:id:yayoikato:20210515113612p:plain
楽しい懇親タイム…ときには名刺交換することも…

リニューアル後

Zoomウェビナーを利用したオンライ開催で、運営・登壇者と参加者のコミュニケーションはZoomのチャット機能に限られてしまいました。
限られたコミュニケーション手段ではありましたが、感想やコメント、質問を送っていただくことができました。
Q&Aタイムで、感想やコメントを司会が読み上げたり、いただいた質問について登壇者が回答したりといったコミュニケーションになりました。

f:id:yayoikato:20210515115403p:plainf:id:yayoikato:20210515115417p:plainf:id:yayoikato:20210515115427p:plain
チャットでたくさんのコメントいただきました

オンラインでの双方向コミュニケーションは、運営の検討課題になりそうです。

御礼

リニューアルしてオンライン初開催となった もくテク にご参加いただいたみなさま、本当にありがとうございました。
運営の改善点は、ふりかえりをして次回に活かしていきます。
引き続き応援をよろしくお願いします。

次回のご案内

2021年6月17日(木)、新規開発における知見共有LTをテーマに開催します。
「会計ソフトだけではない弥生」の次世代プロダクト開発の中で得られた知見をお伝えします。

LT参加も募集しています。
ご自身や所属するチームの取り組みをお話ししてみませんか。ご応募お待ちしています!
mokuteku.connpass.com

部署の全体会でLTしました!

こんにちは、情報システム部の飯田です。

昨年のAdvent Calendarで私がコロナ禍に入社してからの話を投稿していました。そこで「情報システム部の全体会でLTをしました」と書いており、少し時間が経ってしまいましたが今回はこのことについて書いていきたいと思います!

とその前に、簡単に前回以降のお話

入社から11か月が経ち、来月でいよいよ1年になります。前回は組織についてはまだ見えていない部分も多いと書いていましたが、新年会などの全体イベントがあったり他チームとの関わりが増えてきたりして、だいぶ組織に馴染めたと感じています。

ちなみに昨年末の時点では、本社への出社=チームメンバーと直接会ったのは3回だけでしたが、それが今年に入ってなんと!まだ3回のままです(笑)。あの後にまた緊急事態宣言が発令されてしまったので完全リモートワークを継続中なんですよね。ただ、近々2回ほど出社が決まっているので、久し振りの通勤を楽しみにしています。(あ、緊急事態宣言が明けたので出社勤務に戻るというわけではありません。私は引き続きリモートメインの働き方で行く予定です!)

きっかけ

それではLTの話に戻ります。私のいる新課金チームでは、主に弥生のオンラインサービスの契約に関する画面や裏でのバッチ処理の開発・運用・保守を行っています。同じチームのいっしーさんも過去に記事を書いているので興味のある方はぜひ読んでみて下さい。

私も最近は設計から保守まで幅広くやらせてもらっているのですが、その中でちょっと手間だなと思うことがあり、独自に改善策を調べたり試してみたりしていました。そしてそれをチーム会※で話してみたら思っていたよりも好評を頂けたようで、「今度の全体会で発表しようか!」という流れになったのです!

※週に数回チームで集まって、30分ほど仕事に関する共有や仕事とは関係のない雑談などをする会です。リモートワークでのコミュニケーションの場という役割もあります。

1回目:契約作成と画面キャプチャの自動化

実は上のような流れで既に2回LTを行っていまして、1回目が昨年の11月末の「契約作成と画面キャプチャの自動化」でした。

弥生にはマイポータルと呼ばれるアプリの利用や契約の管理などを行う画面があり、新課金チームではその中の一部の画面を開発しています。新課金のシステムをテストするにはマイポータルにログインして契約の作成や変更を行うのですが、これに結構な画面操作や情報入力が必要で手間となっていたのです。1件だけなら数分で終わりますが、パターンテストのために数十件作るとなるとそれだけで午前が終わってしまいます。

そこで使用したのが画面操作の自動化で有名なSeleniumです。画面のシナリオテストで使われることが多いツールですが、純粋にブラウザ操作をプログラミングすることによって任意の動作を行うことが可能です。手間のかかるアカウント登録や契約作成もボタン1つでできます。

f:id:tatsuki_iida:20210413151455p:plain
自動で作成された画面キャプチャ

もちろんシナリオテスト的な使い方も有用で、システムのデプロイ後にいつも行なっている画面やサービス起動の確認も、自動で操作して画面キャプチャ(エビデンス)まで撮ってくれます!画像ファイルがどんどん作成されていくのは見ていて楽しいです。

※SeleniumはHeadlessモードで動かしているので他の作業を邪魔することもありません。終了処理が不適切でSeleniumのプロセスが残り続けてPCが重くなったことはありますが(汗)

実際にこの後、大量のアカウントと契約が必要となるテストが行われ、作成したツールが役に立ちました!今は他のチームメンバーが汎用ツールを作成してくれたので、今後の新課金のテストはそちらを使って効率化されていくことでしょう。

2回目:アプリのデプロイ自動化

2回目は今年の2月末の「CodePipelineを用いたビルド・デプロイ自動化」でした。

f:id:tatsuki_iida:20210412150409p:plain




終わりません!!(笑)

今の新課金システムはデプロイを手作業で行っている部分があります。手順化はされているので誰でもできるようになってはいるのですが、これだけ手順が固まっているのであれば自動化したいと思うのがエンジニアです。

f:id:tatsuki_iida:20210412150202p:plain
AWS CodePipelineの画面

そこで現在考えているのがAWS Pipelineの導入です。LTでは自分で簡単なアプリを作って、それに対してボタン1つ(設定によってはこれすらも不要に!)でビルドとデプロイが完了するところを実演しました。

実際に新課金システムに導入するには、検討事項が色々あるのですぐにとは行きませんが、チームメンバーにもいいねと言ってもらえたので、これからインフラチームも巻き込んで導入に取り組んでいきます!もし導入できたらまた記事にしたいと思います。

色んな取り組みを広めていきたい!

こんな感じで私の取り組みや検討を情報システム部の全体会で発表してきました。このようなちょっとした取り組みや考えを気軽に話せる雰囲気があり、それが今回のように部署の共有に繋がって周囲から色んなフィードバックを貰うことができました。

ちなみに今回のLTもリモートで行ったのですが、私自身そんなにプレゼンに慣れているわけではないので結構緊張しました。昨年の転職活動でのリモート面接の時の緊張にも近かったでしょうか(笑)。聞き手の反応が分かりづらいのでなんとなく不安になるなど、リモートならではの難しさもあるんですよね。この辺は徐々に慣れていきたいと思います。

リモートワークで他チームやメンバーの状況が見えづらくなっている部分もありますが、これからも色んなことをやってみたいと思います。(そしてそれに触発されて他の方も発表して、このブログに投稿してもらえないかな?)それではまた!

私たちと一緒に会社を盛り上げてくれる人を募集しています! www.yayoi-kk.co.jp

JaSST'21 Tokyoに参加して、テスト技法の必要性を考察してみた

こんにちは、カトです。
2021年3月15日~16日に開催されたJaSST'21 Tokyoに参加してきました。

私が参加したセッションはこちらです。

セッション番号 タイトル
A0) オープニングセッション
A1)基調講演 Being Agile about Architecture
B2)テクノロジーセッション JSTQB AL テスト自動化エンジニア
シラバスの概要&見どころ!
F3)チュートリアル1 価値につながる要件・仕様からテストを考える
F5)チュートリアル2 JSTQB Advanced Level テストアナリストのシラバスでテストプロセスとテスト技法を学ぼう
F6)基調講演/招待講演者チュートリアル QA2AQ – Being Agile at Quality: Values, Practices, and Patterns
D8)一般公募セッション 仕様整理のためのテスト設計入門
A9)招待講演 パターンQA2AQによるアジャイル品質のマインド、体制、プロセス、技術


F5とD8で、テスト技法に関するセッションを聴講し、テスト技法の必要性を再認識しました。
そこで、「テストケースとセットで、テスト技法を残した場合とテスト技法を残さなかった場合に、どんな差が生まれるのか」をテーマにして、社内でQAエンジニア向けに共有会を実施しました。

共有内容

ワークショップで使われたカレンダーの仕様がわかりやすかったので、「カレンダーの色分け」を例に考えていきます。 f:id:yayoikato:20210329122538p:plain
カレンダーの日付を確認して、表示色が仕様通りかを確認するテストケースを作成していきます。

テストケースを作成する

今回は、テスト技法としてデシジョンテーブルを使います。

テスト技法とテストケースをセットで残した場合

f:id:yayoikato:20210329122643p:plain
これを見た人の反応はどうなるでしょうか?
きっと、テストケースを確認しやすいと感じるはずです。

テスト技法とテストケースをセットで残さなかった場合

f:id:yayoikato:20210329122707p:plain
これを見た人の反応はどうなるでしょうか?
f:id:yayoikato:20210329122732p:plain
「そんなおかしなことをするなんて、ありえない」と思いますか?
この例では、テスト対象が慣れ親しんだカレンダーで仕様も複雑ではないので、そのように思うかもしれません。
しかし、実際に業務で扱う仕様は複雑で入り組んでいるので、予定外なテストケースを追加してしまう可能性もあるのです。

翌年のケースにメンテナンスする

無事に2021年対応のテストが完了したら、2022年対応に向けてメンテナンスをしていきます。

テスト技法とテストケースをセットで残した場合

デシジョンテーブルに変更はありません。
デシジョンテーブルをみながら、テストケースを修正していきます。
f:id:yayoikato:20210329122821p:plain
はい。スムーズです。

テスト技法とテストケースをセットで残さなかった場合

f:id:yayoikato:20210329122847p:plain
混沌としてきました。

仕様追加が発生する

カレンダーの仕様としては違和感があるかもしれませんが、色分けを追加することにします。
製品・サービスの開発現場では、新規開発だけではなく、追加開発することが多いので、例題として対応してみます。
f:id:yayoikato:20210329122904p:plain

テスト技法とテストケースをセットで残した場合

水曜日の確認のため、デシジョンテーブルを更新します。
デシジョンテーブルに合わせて、テストケースも更新します。
f:id:yayoikato:20210329122923p:plain
迷うことなく、追加に対応できました。

テスト技法とテストケースをセットで残さなかった場合

f:id:yayoikato:20210326110255p:plain
翌年に変更した時点で、何をテストしたいのかわからなくなってしまっています。
何をテストしたいのかわからない状態のテストケースに対して、仕様追加に合わせたテストケースを追加することが難しくなってしまいました。

結論:テスト技法とテストケースはセットで残す

レビューイにとってのメリット:
テスト技法を成果物として残すことで、レビューイである初回の作成者の思考整理だけではなく、メンテナンス実施者にとっても迷いがなくなります。

レビューアにとってのメリット:
レビューアは、テストケース1つずつを見なくてもテスト技法を見ることでテストケースの過不足を確認できるようになります。

テスト技法を共有し受け継ぐことは、レビューイにもレビューアにも効果があります。

JaSSTに参加し、さらにJaSSTの学びを社内のQAエンジニアと共有することで、テスト技法の必要性を再認識する機会になりました。
場面にあったテスト技法を使うことは、テスト工程だけではなく、仕様検討や設計の際にも有効になる手段です。

私は、QAエンジニアが製品開発のすべての工程でテスト技法を使いながら関わっていけるチームをつくっていきます。