確定申告時期の苦労と、その時期にやっていること

この記事は弥生 Advent Calendar 2021 の15日目エントリーです。
弥生会計のエンジニアをしている竹山です。

今年も残すところ半月となり、2か月後には確定申告期間が始まります。
開発は繁忙期の最中ということで、その乗り越え方についてご紹介します。
(2021年5月13日(木)に開催された、もくテク「確定申告ソフトの開発舞台裏」でも発表しました)
もくテク「確定申告ソフトの開発舞台裏」を開催しました - 弥生開発者ブログ

会計ソフト開発の一年

弥生会計は、毎年秋ごろに新バージョンをリリース(今年は弥生会計 22)し、1月から始まる確定申告期間に合わせ「所得税確定申告モジュール」をリリースしています。

f:id:hiroaki_takeyama:20211214141847p:plain

大変なところ

メジャーバージョンと確定申告モジュールのリリース前に忙しい時期が生じますが、
特に確定申告モジュールの開発は、様々な要因があって、特に忙しくなります。

  • 所得税の確定申告期間はあらかじめ決まっているため、申告期間の開始に間に合うようリリースする必要があります。
  • 一方で、確定申告書などの様式、確定申告の手引き、e-Taxの仕様などが公開される時期もある程度決まっています。これらが公開されないと、開発を始めることができません。
  • したがって、様式や手引きの公開から確定申告期間までの限られた時間で、開発を行う必要があります。

f:id:hiroaki_takeyama:20211214142030p:plain

  • 改正の分量によっても対応の難易度が左右されます。昨年は様式や計算方法の変更が多く、対応が大変でした。帳票や手引きは、すべての情報が一気に公開されるわけではないため、帳票のイメージなど、断片的な情報から対応内容を予測し、期限に間に合うよう工夫しています。例えば昨年の様式変更では、扶養親族の記載欄に丸印を付ける条件が分からない状態からスタートしましたが、様々な情報源から推測して先行実装しました。

f:id:hiroaki_takeyama:20211213092927p:plain

  • また、技術面ではなく表現方法で悩む個所もあります。
    下図は昨年作成した「所得税確定申告に関するお知らせ」です。
    昨年は青色申告特別控除額の変更がありましたが、条件によって設定すべき金額が異なるため、 「過大申告・過少申告を生じさせない」ためにお知らせ表示することとしました。
    このような分かりやすさに関わる部分は、ユーザー対応を行うコールセンターとも連携して、表現方法を検討しています。

f:id:hiroaki_takeyama:20211214111737p:plain

どんなふうに乗り越えているか

年によって大小はありますが、毎年確定申告モジュールをリリースできているのは、以下の理由があります。

法令確認

日ごろから法令などの情報収集を行い、修正の必要性を早く把握できるようにしています。

  • 社内で法令調査を行い、共有会をしています。
  • チーム内では、法令改正情報をエンジニアが当番制でチェックしています。
  • e-Taxの仕様を確認したり、弥生の他製品ともで齟齬がないかを確認しています。

開発プロセス

手戻りを最小限にすることを意識した開発プロセス(U字プロセス)を採用しています。設計書、テストスクリプト、実装のレビューを徹底的にすることで、設計書やコードの状態が常に整備されているので、過去の資料の不整合が少なく、今回の対応に集中できます。
会計ソフトの場合、計算式の端数処理や桁数、0の場合に0と表示するかなど、細かな指定が残されていることがとても大事です。対応の際はこれらの指定を一つ一つを吟味して修正します。

やりがい

限られた時間の中で、必要とされる機能を正確に、かつ最大限わかりやすい形で提供するところにやりがいを感じます。日常の準備や改善が繁忙期に結果として表れるので、毎年新しい気付きを得ることができます。

会計ソフト開発全般については、昨年の記事をご参照ください。
tech.yayoi-kk.co.jp

まとめ

これまで継続して、毎年の期限に合わせてソフトウェアをリリースできていることは大変なことで、毎年プレッシャーもありますが、上記のような取り組みが重なって、安定して機能を提供することができていると思います。
今年分も使いやすい確定申告機能を提供できるよう、鋭意開発を進めていきます。

お知らせ

弥生では一緒に働く仲間を募集しています!
herp.careers

お客様サポートの裏側の話

この記事は弥生 Advent Calendar 2021 の14日目の記事です

こんにちは。弥生の後藤です。
SMARTという、銀行の明細や紙の領収書などの様々な「取引データ」を「会計データ」に変換する機能を開発しているチームでエンジニアをしています。

メインの仕事としてはSMARTの機能追加や改修をしているのですが、その他にもう1つ、お客様からのお問い合わせに関する調査を担当しています。
今日は、この調査担当にまつわる仕事についてお話しさせていただこうと思います。

どんなことをしているのか

弥生のコールセンターにお客様から製品についてお問い合わせのあった案件に関して、 コールセンターのご案内だけでは解決が難しい案件について調査を行っています。

調査担当者は各製品チームに数名存在し、SMARTチームには担当者が現在3人います。

メインの仕事はお客様からのSMARTに関するお問い合わせに関する調査ですが、その他に

  • 他チームや他社からの調査依頼対応
  • 他部署からのデータ抽出依頼対応
  • 本番環境のエラーログの定期的な監視

なども行っています。

調査の仕事は、お客様をなるべくお待たせすることのないよう、迅速に対応する必要があります。
一方でSMARTの開発業務も遅延することなく進めていかなければならないのが、調査担当の難しいところです。

工夫していること

SMARTの調査担当者とテクニカルリーダとで共有会を行っています。
目的は、調査対応の質の向上と効率化です。

共有会では、各メンバーが調査の過程で得た知見や効率の良い調査方法などを共有したり、解決できていない課題について相談したりしています。

共有会を始める前は、過去に類似事象がないお問い合わせの調査を行ったときに、その調査の過程で得た知見が調査担当者の中で閉じられてしまっていました。
共有をしあうことで、次に類似の事象が来た時に調査の勘所がわかるため、何も知らない状態に比べて効率よく調査ができるようになりました。

また、よくあるお問い合わせと調査内容をWikiにまとめて、新しくメンバーが入ってきたときに参考にできるようにしたり、 定期的に発生するデータ抽出依頼に対して、データ抽出の作業の一部を自動化するツールを用意したりしています。

調査担当になってよかったこと

時々事象が複雑で調査が難航することもあるのですが、原因が判明して事象が解決した瞬間はとてもうれしいです。

また、調査担当になる前と比べて、SMARTの様々な機能について理解が深まりました。
調査では、お客様が行った操作のヒアリング内容をもとに、ログの内容やデータベースのデータの状態を確認しつつ、原因を突き止めていきます。
その際、仕様を正確に把握していないと原因を突き止めることができません。
当初は自分が開発で担当したことのない機能については仕様の理解が浅かったのですが、調査担当として経験を積んでいくことで SMARTの1つ1つの機能や、機能と機能のつながりについて理解が深まっていきました。

おわりに

調査担当になって、お客様からのお問い合わせに触れる機会が格段に多くなりました。
この経験も踏まえて、お客様にとってより良い製品について今後さらに考えていきたいと思います。

お知らせ

弥生では一緒に働く仲間を募集しています! herp.careers

Jetpack Navigationを使った画面遷移でFragmentとステータスバーのThemeを制御する話し

弥生モバイルチームのtijinsです。

MisoaアプリNavigationコンポーネントを導入してActivityとFragmentが複雑に絡み合った状況を改善しようと思ったのですが、アプリのデザインがActivity毎のThemeで定義されていて、単純にNavigationを入れると見た目が変わってしまう問題に行き当たりました。 ThemeをFragment毎にすれば同じ見た目を実現できるはずなのですが、ThemeもStyleも全くワカランって感じで1ヶ月近く悩んでいたので、1ヶ月悩んだ結果を紹介します。

この記事の概要

このブログでは、以下の内容を説明していきます。

  • FragmentにThemeを適用する方法
  • ステータスバーの色をFragmentのThemeで制御する方法
  • ステータスバーの文字・アイコン色をFragmentのThemeで制御する方法

f:id:tijins:20211206142128g:plain

ThemeとStyle

背景色や文字サイズなど、アプリの見た目を一括して設定できる機能です。
デフォルトのプロジェクト構成ではres/theme.xmlに保存されています。
theme.xmlで定義したThemeをAndroidManifest.xml<application theme="{theme}"><activity theme="{theme}">に指定する事で、アプリ全体やActivity毎の見た目を設定可能です。
ただし、Fragment毎に指定する機能は提供されていませんでした。

Themeの指定

themeはAndroidManifest.xmlで指定しました。
<application>に指定するとアプリ全体の背景色や文字サイズに適用されます。
<activity>に指定するとActivityの背景色や文字サイズに適用されます。
Android5.0以上ではレイアウトXMLのViewGroupにも指定可能です。
<LinearLayout theme="{theme}"><ConstraintLayout theme="{theme}">のように指定するとViewGroup内が適用範囲になります。

Styleの指定

StyleはThemeの適用範囲を1つのViewに限定したものです。
定義はThemeと同じでtheme.xml<style>で行います。
レイアウトXMLで<TextView style="{style}">のように指定しします。
ViewGroupに適用しても、Themeと異なり内側の要素に継承されません。

FragmentにThemeを適用する

FragmentのThemeをxmlで指定する機能は提供されていない為コードから指定します。
Theme(Style)をコンストラクタで指定可能なThemedFragmentを作成しました。
onCreateView()でLayoutInflaterを差し替えています。

// テーマの指定が可能なFragment
abstract class ThemedFragment(@LayoutRes val layoutRes: Int, @StyleRes val styleRes: Int) : Fragment(layoutRes) {

    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
        // Themeを適用したContextを作る
        val themedContext = ContextThemeWrapper(context, styleRes)
        // Themeを適用したLayoutInflaterを作る
        val themedInflater = inflater.cloneInContext(themedContext)
        // レイアウトの生成に使用するinflaterを差し替える
        return super.onCreateView(themedInflater, container, savedInstanceState)
    }
}

// Fragment毎のレイアウトとThemeを指定する
class SampleFragment : ThemedFragment(R.layout.fragment_first, R.style.Theme_StyleSample_Red)
{
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        //  Fragment固有の処理
    }
}

※サンプルコードはandroidxのFragmentを継承しています。

ステータスバーの色をFragmentのThemeで指定する

FragmentにThemeを適用する事例はすぐに見つかったのですが、ステータスバーの色が変わらない事に気づきました。
LayoutInspectorで調べると、Fragmentの描画範囲にステータスバーが含まれていませんでした。

f:id:tijins:20211206112233p:plain
fitSystemWindow="false"の時

試行錯誤の結果、以下でステータスバーの色を変更できる事がわかりました。
システムが描画するステータスバーの色を透明にする事で、ディスプレイ全体に広がったFragmentの背景色が、ステータスバーの色として表示されるという仕組みです。

  1. Fragmentの描画範囲をディスプレイ全体まで広げる
  2. ActivityのThemeで、ステータスバーの色(android:statusBarColor)を、透明(@android:color/transparent)にする
  3. FragmentのThemeで、背景色(colorPrimaryDark)を、表示したいステータスバーの色にする
    f:id:tijins:20211206134733p:plain
    ステータスバーの背景色を設定する

※サンプルは、下記の組み合わせで確認しています。

ライブラリ パッケージ バージョン
AndroidX androidx.core:core-ktx 1.7.0
マテリアルデザイン com.google.android.material:material 1.4.0

Fragmentの描画範囲をディスプレイ全体に広げる

Activityのルート要素をFragmentContainerViewにします

Activityのレイアウト

activity_main.xml

<?xml version="1.0" encoding="utf-8"?>
<androidx.fragment.app.FragmentContainerView
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:id="@+id/nav_host"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:name="androidx.navigation.fragment.NavHostFragment"
    app:defaultNavHost="true"
    tools:context=".MainActivity"
    app:navGraph="@navigation/nav_graph"/>

Fragmentのレイアウト

Fragmentのルート要素をDrawerLayoutにしてfitSystemWindow="true"を指定します。
(ルート要素がConstraintLayoutやLinearLayoutだとステータスバーの背景色が変わりません)

fragment_first.xml

<?xml version="1.0" encoding="utf-8"?>
<androidx.drawerlayout.widget.DrawerLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    tools:context=".FirstFragment"
    android:fitsSystemWindows="true">

</androidx.drawerlayout.widget.DrawerLayout>

f:id:tijins:20211206112231p:plain
fisSystemWindow="true"の時

Activityのテーマで、ステータスバーの色を透明にする

theme.xml
android:statusBarColor@android:color/transparentを指定します

    <style name="Theme.StyleSample" parent="Theme.MaterialComponents.Light.NoActionBar">
        <item name="android:statusBarColor">@android:color/transparent</item>
    </style>

Fragmentのテーマでステータスバーの背景色を指定する

colorPrimaryDarkでステータスバーの背景色を指定します

    <style name="Theme.StyleSample.Red">
        <!-- ActionBarの色-->
        <item name="colorPrimary">@color/red</item>
        <!-- ステータスバーの色  -->
        <item name="colorPrimaryDark">@color/red_status_bar</item>
    </style>

ステータスバーの文字を黒色にする

ステータスバーの背景色は変更できたのですが、今度はandroid:windowLightStatusBar="true"が反映されない事に気づきました。
android:windowLightStatusBar="true"はステータスバーの背景色が明るい色のときに使用するもので、ステータスバー上の文字やアイコンが黒色になります。

こちらもxmlでは指定できない為、Fragmentが遷移した際のイベントで、コードから動的に変更する事にしました。

Style値の取得

xmlで指定された値(true/false)をコードから取得するUtilityを作成しました。

object StyleUtil {
    fun getWindowLightStatusBar(context: Context, @StyleRes styleRes: Int?): Boolean {
        val themedContext = if (styleRes != null) {
            ContextThemeWrapper(context, styleRes)
        } else {
            context
        }
        val typedArray = themedContext.theme.obtainStyledAttributes(
                intArrayOf(android.R.attr.windowLightStatusBar)
        )
        val isLight = typedArray.getBoolean(0, false)
        typedArray.recycle()
        return isLight
    }

context.theme.obtainStyledAttributes()を使用すると、themeに指定されているstyleの値を取得可能です。

windowLightStatusBarの動的な変更

childFragmentManager.addOnBackStackChangedListener{}のイベントでFragmentに指定されたstyleを取得して、ステータスバー文字色を変更します。
findNavController().addOnDestinationChangedListener{}のイベントを使用したくなるところですが、DestinationChangedイベントが発生した時点では、まだ遷移先のFragmentが生成されていない為、スタイルを取得できません。

class MainActivity : AppCompatActivity(R.layout.activity_main) {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val navHost = supportFragmentManager.findFragmentById(R.id.nav_host)!!
        navHost.childFragmentManager.addOnBackStackChangedListener {
            val currentFragment = navHost.childFragmentManager.fragments.firstOrNull()
            val isLight = StyleUtil.getWindowLightStatusBar(
                    this,
                    (currentFragment as? ThemedFragment)?.styleRes
            )
            setLightStatusBar(isLight)
        }
    }

    private fun setLightStatusBar(isLight: Boolean) {
        if (isLight) {
            window.decorView.systemUiVisibility =
                    window.decorView.systemUiVisibility or View.SYSTEM_UI_FLAG_LIGHT_STATUS_BAR
        } else {
            window.decorView.systemUiVisibility =
                    window.decorView.systemUiVisibility and View.SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.inv()
        }
    }
}

サンプルコード

https://github.com/tijins/ThemedFragment

まとめ

この記事は弥生アドベントカレンダー2021の13日目です。
ActivityとFragmentが複雑に絡み合ったアプリをリファクタリングにしてスッキリした新年を迎えたいですね。

お知らせ

弥生のモバイルチームでは、Android、iOSのエンジニアを募集中です!! herp.careers herp.careers

技術勉強会の企画を立てよう!(初心者編)

この記事は弥生 Advent Calendar 2021の9日目エントリーです。

<登場人物>
 もくにゃん木曜日にテクノロジーを語ろうとすると現れるねこ
 あいざわ:リモートワーク中によくPCの接続が切れるエンジニア


<2021/10/14(木)>

 あ~もくテクが今月(10月)も無事に終わった~
 もくテク?
 毎月木曜日に開催している弥生主催の技術イベントだよ~

mokuteku.connpass.com

 隙宣伝にゃん
 それはさておき…

 再来月(12月)のもくテクの企画が決まらない!

 来月(11月)は決まってるのかにゃん?
 11月は大丈夫!いつも大体こんなサイクルで企画運営しているのです

 にゃるほど
 だから12月の企画を検討してるんだけど、オンラインで再開から早半年、ネタ切れしました
 もうちょっと頑張るにゃん
 毎月開催 意外大変也
 今まではどんな風に決めてたにゃん
 運営メンバーで集まって決めてたんだけど…毎月ともなるとマンネリ化してきて…

 仕方ない…もくにゃんが企画のコツを伝授するにゃん
 やった~!

 ネタがないって言っても、社内の話は日々色々聞いてるにゃんね?
 色んなチームが日々施策を打ちながら開発して、それを社員総会や全体会で共有してるからね
 それをストックして企画にすればいいにゃん

例:

 たしかに
 日々の積み重ねが大事にゃん
 でも今は何も残してないからストックがない…
 そういう時は社内で面白いネタを持っていそうな方に頼ったり、社内で募集するにゃん

例:

※CTL=Chief Technical Lead
参考記事:10年先の未来に向けて──弥生の開発プロジェクトを成功に導く“CTL”の役割|弥生株式会社

 た、頼れる~~!!
 あとは頑張るにゃん
 はい!

.
.
.
<1週間後>

 もくにゃん~!12月の企画が決まったよ~!
 よかったにゃん
 よ~しこの調子で先の企画もガンガン決めてくぞ~!
にゃ~ん


宣伝

① 弥生はもくテク運営の他にも自主的に参加できる社内活動があり、どこも活発に活動しています。
社内活動が好きな人は覗いてみてください!
herp.careers

② 記事の中でもくにゃんとあいざわが企画したイベントは、12/16(木)に開催します。
初学者~ベテランまで幅広い登壇者がAWSの話をします。
興味がある方は参加してみてください!
mokuteku.connpass.com

AWS Route53の加重ルーティング機能で本番インフラを無停止・段階的にECS環境に移行する

弥生 Advent Calendar 2021 6日目の記事です。

システム開発部Misocaチームエンジニアの mizukmb です。

クラウド請求書作成ソフトであるMisocaのインフラはサービス稼動開始からつい最近までAWS EC2を使ってアプリケーションを運用していましたが、この度Dockerコンテナ管理サービスであるECSに移行し、この移行作業がほぼ完了致しました 🎉

ECS移行に際しては長い時間をかけて準備や検証を行っており、開発者ブログで紹介したいネタがいくつかあるのですが、今回は実際にEC2で稼動するappサーバを無停止且つ段階的にECSに移行した方法について紹介したいと思います。

ECS移行前の状態と作業の概要

移行前のMisocaアプリケーションのインフラは複数台のEC2インスタンス上で稼動しており、各EC2インスタンスへのリクエスト振り分けはALBを使って制御していました。ドメインとALBの紐付けはRoute53のエイリアスレコードを利用しています。

移行後はEC2インスタンスが複数のECSタスクに、ALBもEC2用からECS用の新規ALBリソースに置き換わります。この移行作業の準備としてMisocaアプリケーションのコンテナ化やECSサービス・タスク定義の作成、ECS用のALBの用意を事前に行いました。

移行作業は以下の点を重視し、これらが実現できる方法について調べました。

  • サービスの停止時間を作らずに移行作業ができる
  • 一気にECS環境に切り替えるのではなく、カナリアリリースのように段階的にECS環境を本番に投入して負荷状況等を監視したい
  • 段階的に投入する事でECSもしっかり本番環境でサービスが提供できているという安心感を得たい 1
  • 万が一ECS起因の障害が発生したとしても影響を最小限にしつつ素早くロールバックできるようにしたい

こちらについてAWS Japan ソリューションアーキテクトの方に技術相談をしたところ、Route53の加重ルーティング (Weighted routing) 機能について教えていただきました。 2

Route53加重ルーティング機能について

正確な機能紹介についてはAWSドキュメントを読む事が最も良いので、ここではざっくりとした紹介をします。

Route53の加重ルーティング機能は、同一レコード名で登録し、重み (Weight) を各レコードで設定する事でその重みに応じた割合でリクエストを振り分けることができます。振り分け方法はラウンドロビン方式です。また、片方の重みを0にする事で設定したレコードへリクエストが振り分けられなくなり、もう片方のレコードに全てのリクエストが振り分けられるようになります。

例えば、 hoge.example.com への振り分けを EC2:ECS=30:70 としたい場合は以下のように重みを設定しそれぞれレコード登録します。

レコード名 ルーティングポリシー 重み ルーティング先
hoge.example.com 加重 30 EC2用のALBドメイン
hoge.example.com 加重 70 ECS用のALBドメイン

この重みを変更する事でリクエストの振り分ける割合を柔軟に設定が可能になります。

f:id:mizukmb:20211118152712p:plain

無停止・段階的に移行するための作戦

行う事はシンプルで、加重ルーティングで設定する各レコードの重みを編集して少しずつ EC2:ECS=100:0 な状態から EC2:ECS=0:100 にすれば作業は完了します。

MisocaチームではインフラをTerraformで管理しているので、Route53レコードの設定や重みの変更はTerraformコードを修正し、プルリクエストの作成とコードレビューを経て terraform apply を実行し適用するという流れでした。

重みの変更によるアプリケーションの停止時間は発生しないので、この値が間違っていないか十分注意していれば簡単に無停止・段階的な移行が可能になります。

実際の移行作業ですが、最初は EC2:ECS=95:5 の割合から始めて、1〜2日様子を見てECS側の重みを増やして EC2:ECS=70:30 にする。さらに様子を見てECS側の重みを増やして…といった作業を繰り返していき、約1週間程かけて EC2:ECS=0:100 な状態に移行し、サービスの稼動に影響が無い事を確認できました。

おわりに

MisocaのアプリケーションインフラのEC2からECSへの移行にRoute53の加重ルーティング機能を活用した話を書きました。

ECS移行に関する知見についてはまだまだあるので、できる限り開発者ブログで紹介したいと考えています。

弥生 Advent Calendar 2021 では弥生のエンジニアが様々な内容で記事を公開しますのでぜひ他の記事もチェックしてみてください!

採用

積極採用活動中です!!

herp.careers

付録:最初に考えてた作戦内容と却下理由

ALBのリスナールールではリクエストを転送するターゲットグループの重み付けができるため、最初はALBのレイヤで無停止・段階的な移行を進めるつもりでいました。

しかしながら、ECS環境のデプロイはCodeDeployのBlue/Greenデプロイメント機能を使っている関係からこの案は技術的に不可能である事がわかりました。理由ですが、CodeDeploy Blue/Greenデプロイメント機能を実行するとCodeDeploy内部でリスナールールに紐付くターゲットグループをBlueからGreenに付け替えるといった事を行っており、実質リスナールールの転送先はECSに固定されてしまうためです。

CodeDeploy Blue/Greenデプロイメント機能を使わなければこの案で進められますが、これのためにBlue/Greenデプロイを止めるのは割に合わないと判断したため却下となりました。


  1. もちろんステージング環境で検証していますが、やはり本番となると怖いものは怖いので安心感が欲しいのです

  2. 弥生ではAWS Japan ソリューションアーキテクトの方と定例会を行っており、AWSに関する技術相談がカジュアルにできる場が設けられています

システム横断プロジェクトの品質計画

こんにちは、カトです。弥生でQAエンジニアをしています。この記事は弥生 Advent Calendar 2021の5日目エントリーです。

結論

弥生は、昨年2020年に記帳代行支援サービスを開始しました。
記帳代行支援サービスは、複数のシステム・複数のソフトウェアで構成されるサービスです。
弥生ではシステム横断プロジェクトと呼ぶことが多い、シームレスなサービスの裏側のおはなしです。

私は、QAエンジニアとして、記帳代行支援サービスに関わりました。 「かんたん、あんしん、たよれる。」の裏側では、複数のシステム・複数のソフトウェアから成り立つサービスの品質をどのように見ていくのか、何をやって何をやらないのかを決める必要がありました。

そこで、各テストフェーズでどのようなテストをすべきかをまとめました。それがこちらです。 f:id:yayoikato:20211111155539p:plain 改めてまとめたものをみると、難しいことは何も言っていないように思えます。
しかし、これを作成するまでに、いろんなことがありました。

f:id:yayoikato:20211129220845p:plainf:id:yayoikato:20211129220910p:plainf:id:yayoikato:20211129221331p:plain:w120
本当に、いろんなことがありました……?

背景

U字プロセス

弥生の製品開発の多くは、開発プロセスとしてU字プロセスを取り入れています。
(参考:エンジニア採用|採用情報|弥生株式会社f:id:yayoikato:20211129090958p:plain
このU字プロセスは、弥生入社時に導入研修で学びます。日々の業務でもプロセスに準拠しているかどうかを判断基準としています。
弥生のエンジニアには浸透しているプロセスです。

f:id:yayoikato:20211129222805p:plain:w200
「いつもの感じでよろしく」で、だいたい伝わる

システム横断プロジェクトで発生したこと

記帳代行支援サービスにおいても、「いつもの感じでよろしく」で済むものだと思っていました。
ところが、「そっちのシステムでテストしてると思ったからこっちでは見てないよ」「そっちでもやってるの?こっちのシステムでテスト終わってるよ」などなど、いろいろなトラブルが発生します。

特に、問題になったのが2点。

  • システム間のインターフェース誤りにより、統合テスト開始直後にテストが中断してしまう
    結合テストでは、単一のサービスを対象にしたを実施するため、連結するサービスはダミーシステムを使ってテストしています。 このため、個別のシステムとしては動作していても、いざ連結してみると想定していた挙動にならないことが発生し、テストを中断せざるを得ないことがありました。

  • 準備や設定が複雑なシステムを除外して、システムテストを実施してしまう
    システムテストは最終テストフェーズであり、リリース間近におこなうため、期日に追われています。 設定が複雑だったり、準備工数がかかったりする手順は、前フェーズでテストしているはずだから大丈夫だと思って省略させてしまいがちでした。 省略に根拠がないので、システムテストが貧弱になっていきました。

これらの問題を解決しなければいけません。

奮闘

文章にしてみた

どのフェーズのテストで何をしなければいけないのか、品質計画として文章化していきました。

f:id:yayoikato:20211129225201p:plain:w300f:id:yayoikato:20211129225209p:plain:w300
一生懸命つくった品質計画書のイメージ

確認が必要なときには、集まってミーティングをしました。
フェーズごとに実施するテスト内容を品質計画で明示する前と明示した後で比較すると、各段に認識齟齬がなくなりました。
しかし、品質計画として書いてあるから全員が熟読している、というわけではありません。途中参加で読めていない人もいるし、読んだけれど忘れてしまったという人もいます。
そのつど確認をしていましたが、もう少しよりどころになるようなものが必要だと思うようになりました。

図にしてみた

「よりどころになり、これを見れば責任者に細かく確認をとらなくても安心して確認できるようなものがほしい」と思ってつくったのが冒頭の図です。
もう一度貼っておきます。
f:id:yayoikato:20211111155539p:plain この図をつくって共有したところ、記帳代行支援サービスに関係するメンバーそれぞれがこの図を見ながら会話ができるようになりました。

問題になっていた2点に対しては、このような変化がありました。

  • システム間のインターフェース誤りにより、統合テスト開始直後にテストが中断してしまっていた
    Aさん:「統合テストの前に連携テストする必要がある。いつ頃テストできそう?」
    Bさん:「〇月×日にテストアップ可能になる予定。」
    Aさん:「両システムがテストアップして、連携テスト後に、統合テスト開始ですね。」
    ⇒システム間のインターフェースに着目した連携テストを実施することで、統合テスト開始直後の中断がなくなりました。

  • 準備や設定が複雑なシステムを除外して、システムテストを実施してしまっていた
    Aさん:「心配だから統合テストで2つ先のシステムまで確認しておく?」
    Bさん:「対象のシステムと直接連携していないシステムは、統合テストの確認対象じゃないよ。」
    Cさん:「システムテストで確実に実施するよう申し伝えておこう。」
    ⇒システムテスト内容が明確になり、最終フェーズとして有効なテストができるようになりました。

結果

「記帳代行支援サービスのテスト、どう考えればよいの?」というときに、よりどころになる図ができました。
そして、この品質計画の図は、記帳代行支援サービス以外でも複数のシステム・複数のソフトウェアから成り立つサービスでのテストを考えるときに使える内容になっています。

私は、2019年から記帳代行支援サービスに関わり、2020年にサービスの開始、2021年には記帳代行支援サービスのバージョンアップに立ち会いました。
まだまだ記帳代行支援サービスは進化していきます。しかし、私がQAエンジニアとして記帳代行支援サービスに関わるのはここまで。

私は、QAエンジニアとして別のサービスに参画し始めました。記帳代行支援サービスでつくった品質計画の図をさらに進化させ、今以上に弥生の資産となる品質計画をつくっていきます。



お知らせ

弥生では「弥生会計」に限らず、さまざまな製品・サービスに関わることができます。
一緒に、弥生の製品・サービスの品質を追求してみませんか?

herp.careers

テクニカルリーダーになってシステムの解像度が上がった話

この記事は弥生 Advent Calendar 2021の2日目の記事です

自己紹介

弥生の白井と申します。SMARTの推論という機械学習機能のテクニカルリーダーを担当しています。

家では1歳の息子を溺愛しています!!

テクニカルリーダーについて

入社してから今までエンジニアとして働いていたのですが、今年10月から初めてテクニカルリーダーをやることになりました。

弥生のテクニカルリーダーの役割には、開発計画の立案と実行、プログラム品質の管理(レビュー)、エンジニアのチーミング、適用技術の決定などがあります。

役割に伴う責任が大きくなる分、必要な権限も与えられます。今回はその与えられた権限によって見える世界が広がったという話です

f:id:yayoi_shirai:20211115140340p:plain
広がる・・・世界が・・・

与えられた権限について

前提として、SMARTはAzureのApp ServiceというWebアプリ用のPaaSで動いています。App ServiceはOSをLinuxに指定することもでき、推論エンジンはLinuxのApp Serviceで動いています。

(ちなみに弥生の他のサービスではAWSを使用しているものもあります)

AzureはAzureポータルという管理画面(AWSだとAWSマネジメントコンソール)があるのですが、開発環境であっても一般のエンジニアにはAzureポータルへのアクセス権がありませんでした(ここはチームによって運用は異なるかもしれません)

テクニカルリーダーになることでAzureポータルへのアクセス権が与えられ、他にも監視系サービスのアクセス権など様々な権限が与えられます。

テクニカルリーダーの権限で見えた世界

テクニカルリーダーの権限でシステムの裏側を見ることで、システムのアーキテクチャをより深く理解できるようになりました。

例えばアプリケーションログを確認することによって、Webアプリがデプロイ後にどのように動いているかを知ることができました。

デプロイ直後のアプリケーションログを確認すると、LinuxのApp Serviceでは裏側でLinuxのDockerコンテナを作成し、そこにデプロイされたWebアプリをのせて動かしていることがわかりました。

他にもLogic Appsで定期実行スケジューラを組んで運用していたり、アプリケーションログをログ可視化用のElasticsearchに転送するために、一時的にBlobストレージに保存している処理などを目で見て確認することができました。

システムへの解像度が上がることでレベルが上がった気がする

システムのアーキテクチャの理解が深まったことで、システムへの解像度が一段と上がったような気もします。

例えば本番環境で謎の事象が発生した時でも、どこを調べればいいのかある程度検討がつくようになり、調査の目処が立てやすくなりました。 以前は闇雲にありとあらゆるログを確認してエラーが出ていないか調査していましたが、全体像を理解して調査ポイントを絞り込むことで、不必要な調査に時間をかけてしまうことが減りました。

他にも少し難しい事象を再現したり新しい機能を試すときに、モックを作ってささっと検証する、といったことがスムーズにできるようになりしました。

作業がうまくいったとき、自分のエンジニアとしてのレベルが上がった気がする!なんて思ったりしました。

f:id:yayoi_shirai:20211115140534p:plain
レベルアップ!!!

エンジニアがシステムのアーキテクチャを理解できるようになるために

私は権限を手に入れたことでシステムのアーキテクチャをより理解できましたが、本来これはエンジニアだった時に理解したかったな~とも思いました。

よくよく設計書を見ると書いてあることだったりするのですが、目で見て確認できるかできないかは理解度に大きく影響すると感じました。セキュリティの都合上全てのエンジニアがAzureポータルを見れるようにすることは難しいのですが、なんとかならないものかと悩んでいます。

今後は他のエンジニアにもうまく伝えられる方法がないか考えていきたいと思います!

宣伝!!来年2月に推論チームでもくテクやります!!

mokuteku.connpass.com

弥生は月に1度、木曜日に技術イベント「もくテク」を開催しています (現在はリモートイベントで開催しています)

イベントページはまだ出来ていませんが、来年2月に推論(機械学習)がテーマの会を企画しています!

機械学習のサービス運用に興味のある方、弥生の研究開発に興味のある方など、誰でも大歓迎です!ぜひお気軽にお越しください!!!

弥生では一緒に働く仲間を募集しています。

herp.careers