もくテク「エンジニア就活生必見! 新卒エンジニアってどうなの?」を開催しました

こんにちは、弥生の相澤です。
毎月恒例のもくテク開催報告です。

イベント概要

今回は就活生や学生に向けたイベントを開催しました。

今回のテーマは『エンジニア就活生必見! 新卒エンジニアってどうなの?』 今回のもくテクは、「弥生が気になっている」という就活生のための弥生開発本部紹介企画! このイベントでは弥生に新卒入社した2年目~5年目のメンバーが登壇し、研修や配属先、今任されている仕事について包み隠さずお話しさせていただきます! 採用選考には一切関係のないカジュアルな会なのでぜひ気軽に参加してください😼

前半にLTで弊社の新卒の経験をお伝えし、後半に参加者の方々から送っていただいた質問をパネルディスカッションで回答するという構成で進めました。

LTの内容

『開発本部紹介』 by 中山 健太

開発本部のリーダーが本部についてをご紹介しました。
組織の取り組みから、キャリアパス、成長支援についてなどを熱い思いとちょっとの笑いを交えてお話しました。
例えば、開発本部のキャリアパス例としてエンジニアからテックリード、プロジェクトマネージャー、品質リーダーなど様々なキャリアを選択できます。キャリアアップを支援するため、新卒の社員には入社直後プログラミング研修があったり、新卒・中途問わず入社後定期的に技術研修やマネジメント研修などを受ける機会があります。
他にも1on1という定期的に上司と1対1で話す時間や、本部全大会という本部員全員が集まる会で各チーム/人の取り組みをLTとして発表する時間があったりと、様々な取り組みによってエンジニアの活躍や成長が支えられています。

『研修って大変なの?新卒技術研修Q&A』 by 田邊 慎史

新卒2年目の社員が開発未経験だった過去の自分に向けて、研修を受けた経験や受ける際のポイントについてQ&A形式でお話しました。
弊社では最初から学ぶ前提で研修などの計画が組まれているため入社後からのスタートでも大丈夫なこと、講師や先輩など周囲のサポートを活かせることなどを発表しました。

『知識の無い新卒が新サービスを作るチームに参画できた物語』 by 増田

新卒3年目の社員が新サービスチームに参画したいという希望を伝えてからの経験についてお話しました。
希望通りのチームに参画してからは「複数人で実装したい」と仕事の進め方を提案したり、StorybookCodeceptJSなど弊社でまだ使っていなかった新しい技術を調査したりして新しいことに挑戦されています。

『開発未経験でもAPIを実装できる⁉️~弥生スポットライト賞を受賞するまでの取り組み~』 by 松坂 莉奈

入社直後は開発未経だった験新卒4年目の社員が、それから新卒2年目で社内賞を受賞するまでに至った経験についてお話ししました。
10個以上のAPIをGo言語で作成するために、
①まずは既にあるものを理解しようとする
②そこで出た疑問はすべて解消する
③やるべきことを明確にする
④自力で調べる力を身に着ける
というステップを踏んで腕を磨いていったことを発表しました。

『「上司」って激ムズ…!新卒4年目サブリーダーの葛藤と感謝』 by 野川

新卒5年目の社員が人事ライン(※)というチームのサブリーダーになった経験と、そこで気づいた上司として大切なポイントやチームメンバーの声をお話しました。
 ※開発本部では物を作るファンクションというチームと、勤怠管理・評価・メンタルケアなどの人を見る人事ラインというチームが存在します。今回は人事ラインチームのサブリーダーについての内容になります。
・完璧じゃなくていい
・信頼関係が何より大事
・部下の話を"聴く"
・Iメッセージで伝える
ということを意識してメンバーをサポートし、チームメンバーから「本音で話すことができ課題の解決に近づけた」「近い目標として自分のキャリアを考える際にも助けられている」という声をいただいています。

パネルディスカッションの内容

司会は開発本部紹介をしたリーダーが、パネラーは新卒2~5年目のLT登壇者と運営司会者が登壇しました。
ありがたいことに当日前や開催中も参加者の方からご質問をいただきました。
ここで本番で回答できなかった質問をこちらの記事で回答させていただこうと思います。

質問内容

エンジニア就活の時期感(インターン、ES、内々定)、持っておいた方がいい能力/資格/実績、就活始めるまでどういう心持で生活すればいいか

回答

エンジニア就活の時期感(インターン、ES、内々定)について

FY22については11月頃からエントリーを受けつけ、内々定は年明けくらいから出しています。
また、現状インターンは行っておりません。

持っておいた方がいい能力/資格/実績

能力、資格は特にありません。
実績は下記のとおりです。(※必須ではなく、あると歓迎、という意味合いです)
・自ら目標を立て、やり切った経験
・チームを巻き込み、成果をあげた経験
・社会に対して何かしら課題意識を持っており、貢献したいと思っている

就活始めるまでどういう心持で生活すればいいか

私個人の考えですが、勉強やサークル活動、バイトなど興味があることにどんどん打ち込めば良いと思います。
また、そうやって打ち込んできた事柄を周りの人に話したり何かにまとめたりして自分の言葉でたくさん伝えてみると、就活での引き出しが増えて、結果的に自分に合った会社が見つかると思います。

次回のご案内

次回は『『100アカウントを見据えた』AWSマルチアカウント運用』というテーマで開催します。

今回のもくテクでは、弥生の実業務でも利用しているAWSマルチアカウントの運用方法をご紹介します。 1つのAWSアカウントに複数のサービスを入れてみたが「これで大丈夫かな?」「サービス増えたら破綻するのでは・・・?」と心配しているエンジニア向けに、シングルアカウントで発生する問題とマルチアカウント化することによる解決方法をお伝えする予定です。 マルチアカウント化にあたり個社ごとに検討しなければいけない課題についてもお伝えしますので、ぜひご参加ください!

AWSのアカウント運用についてがっつりお話しさせていただきます。
ご興味のある方はぜひご参加ください。

mokuteku.connpass.com

一緒に働く仲間を募集しています

www.yayoi-kk.co.jp

herp.careers

もくテク「freee×弥生!ユーザーの喜びの声を愛でる会」を開催しました

こんにちは、弥生のいっしーです。

すっかり春ですね。先週末は近所の公園で桜を愛でてきました。
リモートワークはついつい運動不足になりがちなので、季節を感じるイベントは心も身体もリフレッシュできておススメです。

実は3月は、お客さまの喜びの声を愛でる機会もありました。
こちらもとっっっても良かったので、当日の様子をご紹介します。

3月のもくテクは「freee×弥生!ユーザーの喜びの声を愛でる会」

今回はなんと、普段は競合として見られがちなfreee株式会社さんとのコラボイベントでした!

今回のイベントでは、freeeと弥生それぞれから会計ソフトの開発に携わるエンジニアが登壇し、お互いの会社や製品・サービスの開発についてトークします。
トークの中でユーザーの方からの「喜びの声」をご紹介し、会計をはじめとするバックオフィス業務向けのソフト開発の楽しさを全力でお伝えする予定です!
会社の壁を越えて開発の楽しさ、やりがいを分かち合うこの貴重な機会を、ぜひお見逃しなく!!

YouTube Liveでの限定生放送*1でしたが、多くの方にご視聴いただくことができました。

お互いを探り合う自己紹介

ゲストはfreeeの中部オフィスで開発本部長を務めていらっしゃるmoai(山崎)さん。弥生からはCTOの佐々木と弥生会計オンラインのテクニカルリーダーを務めている狩野が登壇しました。自己紹介の結果、狩野が実は転職活動時にfreeeさんも検討していたことや、moaiさんと佐々木には両社のカジュアル面談で会うことができることが判明。また、両社ともコロナ禍で一気にリモートワークが進んだ話を和気あいあいとしていました。

画面左上から時計回りにファシリテーターの佐々木(弥生)、moaiさん(freee)、狩野(弥生)

似ている部分、違う部分が見えてきた会社紹介

場も温まってきたところで両社の会社紹介です。
freeeさんも弥生も、スモールビジネスのバックオフィスを支えるプロダクトをリリースしているだけあり、ミッションは非常に似ていて共感できるものでした。「我々のお客さまはどんな人たちでどんな課題を抱えているのか?」という話題についても、お互いに頷くばかり。

両社ともスモールビジネスが世の中に良い影響を与える存在だと考えている点は共通していましたが、弥生は「事業コンシェルジュとして、事業のあらゆるフェーズで発生する困りごとを一緒に解決する」、freeeさんは「統合型経営プラットフォームを提供することで、だれもが自由に自立的に経営できる(経営のハードルを下げる)」というアプローチの違いを感じました。

弥生の会社紹介

freeeさんの会社紹介

ユーザーの喜びの声を愛でる

そして、いよいよ今回のメインパートです!
ここからは、お客さまからの喜びの声の多かった機能を開発したメンバーも参加してお話しいただきました。freeeさんからはfreee会計のマネージャーをしているnoripee(加藤)さん、弥生からは弥生会計デスクトップのテクニカルリーダーの寺﨑(柴犬)*2が登壇しました。

それぞれのプロダクトの機能やお客さまの喜びの声を聞きながら、

  • タグとか数年経つと管理が大変になりますよね
  • あー、これはかゆいところに手が届いていいですね
  • この機能、うちもやりたいとは思ってるんですけどできてないんですよ
  • リリースした機能が喜んでもらえると嬉しいですよね
  • お客さまの声はちょくちょくチェックしてます

といった開発者らしい意見交換をされていて、とても楽しそうでした。

freee

freeeさんからは「ワークフローの共有機能」「タグの非表示機能」「試算表・月次推移での検索条件の保存機能」の3つをご紹介いただきました。

タグの非表示機能

■ユーザーの喜びの声(一部抜粋)

  • ワークフローに共有機能が実装されてて地味にいいやん、って思った
  • 待ってました!!最高です!!
  • 検索条件の保存機能がイイね

弥生

弥生からは「前期データの参照機能」を紹介しました。

前期データの参照機能

■ユーザーの喜びの声(一部抜粋)

  • 前年度データの参照が楽になった。やるじゃん
  • かなり効率化です
  • 神実装

感想タイム

イベントの最後に、登壇者から今回の感想をいただきました。

  • 普段の業務だとどうしても競合他社という目線で見てしまうが、今回はその目線抜きのポジティブな感じで、お互いの良いところやお客さまの反応について話せたのがよかった
  • 業界を盛り上げていく良きライバルとして、切磋琢磨しながらこれからも一緒に頑張っていけたらと思った
  • ユーザーさんの利用率や声を知れるのはやはり楽しいし嬉しい
  • お客さまにいいものだと思ってもらうだけでなく、自分たち自身もこれはいいものなんだと言える機能開発をしていきたい

みなさん、いい笑顔!

freeeさん、今回は本当にありがとうございました!
また機会があればぜひコラボさせてください!

次回のご案内

さて、次回は「エンジニア就活生必見! 新卒エンジニアってどうなの?」というテーマで開催します。
就活シーズンに入り、進路に悩まれている方も多いのではないでしょうか?
このイベントでは弥生に新卒入社した2年目~5年目のメンバーが登壇し、研修や配属先、今任されている仕事について包み隠さずお話しします! 選考とは関係ありませんので、弥生の新卒エンジニアの生の声を聞きに、ぜひお気軽にご参加ください。

mokuteku.connpass.com

一緒に働く仲間を募集しています

弥生ではスモールビジネスを一緒に盛り上げていってくれる仲間を募集しています! herp.careers

*1:今回の配信は公開する予定はありません。

*2:「あ、どうも。こんな姿で失礼します」と登場した柴犬に、会場が笑いに包まれたのはここだけの話。

もくテク「弥生って、実は機械学習もやってるんです!」を開催しました!

こんにちは。弥生でエンジニアをしている、たけです。

2022年2月17日(木)に毎月恒例のもくテクを開催しました。
このブログではすっかりお馴染みになってきたもくテクですが、あらためてご説明すると以下のような楽しい技術勉強会です!

弥生株式会社が運営する勉強会です。
Azure, AWS, デスクトップアプリ, UXなどなど 木曜日の夜に、みんなで楽しくIT技術について語り合いませんか?

それでは、2月のもくテクの開催報告をしたいと思います!
特別なお知らせもありますので、ぜひ最後まで読んでいただけると嬉しいです。

2月のテーマは「弥生って、実は機械学習もやってるんです!」

イベントページはこちら(※開催は終了) mokuteku.connpass.com

実は、そうなんです!
弥生が提供するサービスには機械学習を用いた機能があり、その機能は自社で研究開発を行っています。

2月のイベントでは、機械学習を用いた機能の仕組みや、研究開発、運用の方法など裏側をたっぷりご紹介しました。

セッションの内容

1. 弥生の機械学習を使っているサービスの紹介! by 白井

最初の発表は白井さん。弥生の機械学習を使っているサービス、「YAYOI SMART CONNECT」をご紹介しました。
「YAYOI SMART CONNECT」はあらゆる取引を会計製品に取り込むサービスです。
取引データを仕訳データ化する際に使っている推論エンジンに、機械学習が用いられています。
推論エンジン・APIの仕組みからチームの体制まで、今回のイベントの他の発表への理解が深まる内容の発表でした。

2. 弥生の研究開発いいところ by 土田

続いて、土田さんから推論エンジンの研究開発はどのように行っているのかという観点で発表しました。
これまでの研究開発の成果として、多段階のルールと推論を組み合わせた推論ロジックの実現、ベイズ推定からニューラルネットワークへの移行をご紹介しました。
研究開発のフロー図もお見せし、「弥生の研究開発いいところ」=「研究開発が設計、開発、リリース、運用・保守、次の研究開発に結びついていること」をお伝えしました。

3. 精度だけじゃない!推論システム運用のための取り組み by 鍋谷

最後は新卒3年目の鍋谷さんの発表です。
弥生で推論チームに配属されてから機械学習について学んだ鍋谷さん。
①基礎知識の習得、②実装の仕組みの理解、③実務で使用する分野の詳細な理解という3つの「学びのステップ」を設けて勉強してきたことをお話ししました。
続いて、実用化に至るAIプロジェクトが少ないこと、弥生で実用化できていることへの考察を発表し、運用コストを上回る提供価値の重要性をお伝えしました。

2月のもくテクの開発報告は以上です!
私も弥生で製品の開発を行っていますが、推論エンジンの研究開発の難しさやおもしろさが伝わってきて、とてもよい刺激を受けました。

お知らせ(次回予告)

次回2022年3月17日(木)のもくテクは、初のコラボレーション企画!
なんとお相手は「会計」という領域でしのぎを削っている、freee株式会社さんです!

テーマは「freee×弥生!ユーザーの喜びの声を愛でる会」。
イベントではそれぞれの製品・サービスのユーザーの方からの「喜びの声」をご紹介し、バックオフィス業務向けのソフト開発の楽しさをお伝えします!

お申し込みは以下のconnpassのページから可能です。
mokuteku.connpass.com

どんなイベントになるのか、とても楽しみです。
スペシャルなイベントになると思いますので、ぜひみなさまもお見逃しなく!!

お知らせ

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

Misoca の PDFテスト

こんにちは、弥生の日高 @hidakatsuya です。普段は クラウド見積・納品・請求書サービス「Misoca」 の開発に携わっています。

Misoca には、作成した請求書などの帳票を PDF としてダウンロードするだけでなく、PDF の内容を印刷したり、郵送したり、FAX として送信するなど、PDF が関連する機能が多くあります。そして、毎日非常に多くの PDF が Misoca 上で生成されています。

今回は、そんな Misoca の PDF をどのようにテストしているのかについてまとめたいと思います。

Misoca の PDF

本題に入る前に、Misoca で扱っている PDF についてもう少しだけ説明しておきます。

  • 請求書・納品書・見積書・注文書・注文請書・検収書・領収書の7種類の PDF がある
  • 請求書・納品書・見積書は複数のテンプレートを提供している
  • 執筆時点で、請求書には14種類、見積書・納品書にはそれぞれ2種類のテンプレートがある

また、2020年以降での PDF に関するリリース(ある程度の規模の機能追加や変更)回数を集計したところ、24回のリリースを実施していました。月に平均2回程度、PDF に関するリリースをしていたということになります。

Misoca の PDFテスト

これだけの種類の PDF をこの頻度で安全にリリースするためには、自動テストの仕組みは不可欠です。Misoca でも、CI として PDF 生成の結果を自動テストする環境を整えています。

  • テストケースごとに生成した「実際の PDF」と「期待するPDF」と比較し、一致しない場合は失敗として差分結果も出力する
  • 帳票の種別ごと、テンプレートごとに 8~25 のテストケースがあり、合計で 482 ケースある
  • それなりに重いので、リリーステスト*1pdf_spec_*ブランチの push 時にテストを実行する

これら一連のテストを Misoca チームでは「PDF spec」と呼称しています。

PDF spec

PDF spec は、他のテスト同様に RSpec で動作します。テストコードは spec/pdf/ に配置し、あくまで Misoca の spec の一部に過ぎません。PDFの比較には、diff-pdf を使い、PDF ファイルを直接比較することでテストします。

構成と実装

請求書のスタンダードテンプレートの spec を例に詳細を説明します。

Rails.root/
 ├── app/
 :
 ├── spec/
      ├── pdf/
      :    ├── invoice/STANDARD/
           :    ├── expected
                │    ├── general_usage.pdf
                │    ├── max_input.pdf
                │    :
                └── pdf_spec.rb

pdf_spec.rb がテスト本体で、expected/ 配下の general_usage.pdf などがテストケースの「期待するPDF」です。

pdf_spec.rb は、実際とは少し異なりますが、概ね次のような実装になっています。

RSpec.describe Invoice, type: :pdf do
  include_context 'pdf spec'

  it_behaves_like 'pdf spec: general usage'
  it_behaves_like 'pdf spec: max input'
  ...
end

「期待するPDF」との比較テストは include_context 'pdf spec' の中で行なわれます。

it { expect(subject).to match_pdf(expected_pdf_path, output_diff: diff_pdf_path) }

match_pdf で PDF の比較が行われ、一致しない場合はテストは失敗します。

この時、後述のオプションを指定すると、diff_pdf_path で指定したパスに差分のPDFが出力されます。差分は、次のように変更箇所がハイライトされた普通の PDF ファイルとして出力されます。これは diff-pdf の機能です。

f:id:hidakatsuya:20220222115124p:plain
領収書PDFのタイトルのフォントサイズを大きくした場合の差分PDF

なお、この match_pdf Matcher は、筆者作の pdf_matcher-testing gem で定義されています。*2

PDF spec の機能と bin/pdf_spec コマンド

前述の通り、PDF spec は RSpec の example の一部に過ぎないため、bin/rspec spec/pdf/invoice/STANDARD で実行することができますが、手元での開発時は専用のコマンド bin/pdf_spec を使って実行します。

以下は bin/pdf_spec の実際のコマンドヘルプです。

$ bin/pdf_spec
Usage: pdf_spec [OPTIONS] specpath

OPTIONS:
  --verbose          テスト結果の差分PDFと結果PDFを tmp/pdf_spec/ に出力する
  --update_expected  期待PDF(expected.pdf)を結果PDFで更新する。差分PDFも出力する

  詳細は spec/support/shared_context/pdf/pdf_spec_shared_context.rb のコメントを参照
  その他、rspecコマンドに渡す任意のオプションを指定できます

specpath:
  spec/pdf/ 配下の spec ファイルを指定します

Examples:
  $ bin/pdf_spec --verbose spec/pdf/invoice/STANDARD
  $ bin/pdf_spec --update_expected -fd -e "min input" spec/pdf/invoice/STANDARD ...

上記の通り、このコマンドは、単に PDF spec を簡単に実行するだけではなく、PDF の変更を行う際の PDF spec に伴う開発フローを助ける役割も担っています。

PDF に差分が生じていないかを確認する

まず、単に spec を実行すると、PDF を比較し差分が生じていないか(壊していないか)を確認できます。

$ bin/pdf_spec spec/pdf/invoice/

PDF の結果と差分が意図したものか確認する

そして、--verbose オプションを指定することで、テストケースの実際の PDF と期待する PDF との差分(あれば)を tmp/pdf_spec/ に出力して、PDF への変更内容が期待通りかを確認することができます。

$ bin/pdf_spec --verbose spec/pdf/invoice/

期待する PDF の内容を更新する

最後に、意図通りの変更ができていることを確認したら、--update_expected オプションを指定し、期待するPDFを変更後の内容で更新することができます。更新された「期待するPDF」を push して一連の実装は完了となります。

$ bin/pdf_spec --update_expected spec/pdf/invoice/

なお、このコマンドの実装は非常にシンプルなものとなっています。以下は bin/pdf_spec の一部です。

for arg in "$@"; do
  case $arg in
    "--verbose"|"--update_expected")
    mode=${arg#--}
    ;;

    *)
    args+=("$arg")
    ;;
  esac
done

if [[ ${#args[@]} -eq 0 ]]; then
  exit_with_usage
fi

PDF_SPEC=$mode bin/rspec "${args[@]}"

実は、 verboseupdate_expected などの機能は、spec 側で PDF_SPEC 環境変数の値を読み取って実現しています。そのため、bin/pdf_spec は、--verbose などのオプションを解釈して、PDF_SPEC 環境変数に適切な値をセットし、bin/rspec を実行しているだけです。

これまでの改善・工夫

最後にこれまで行なってきた改善や工夫をいくつか紹介します。

PDF spec のテストケースが多過ぎてテストが遅く、テストケースのメンテも大変

当初、請求書だけでテストケースは 2000 を超えていました。網羅性が高く安心感はありますが、通常のビルドで実行するには、あまりにも実行時間もリソースも占有しすぎていました。

これは、シンプルに「テストケースを減らす」ことで改善した形ですが、まず「PDF spec の責務」を定義することから始めました。

  • 関心のあるもの
    • PDFの表示が意図したものか
    • 表示がくずれていないか、表示されるべきところに正しく表示されているか
  • 関心のないもの
    • PDFを出力する過程や出力した後での状態の変化
    • 例えば、金額の計算結果の確認は PDF spec の責務ではない

そして、この責務に則り、PDF spec (PDF そのものの比較) でカバーすべきものと、PDF 生成の実装 (PDF生成の過程のロジックなど) の spec でカバーすべきものへ整理することで、PDF spec のテストケースを全種類で 480程度に圧縮しました。

目視では判別できない差分でテストが失敗する

稀に、差分の PDF をみても差分を確認できないケースが発生したことがありました。この手のビジュアルリグレッションテストではよくあるやつですね。

これは、diff-pdf の v0.4v0.5 で追加された --channel-tolerance--dpi オプションを使って、検知する差分の閾値を調整することで解決できます。

おわりに

今回は、Misoca の PDF を支える PDF spec について書きました。

PDF に問題があった場合の影響は大きく多岐に渡ります。PDF spec の整備によって、常に一定の PDF の品質が担保されことにより、PDF の変更に対しての心理的な安心感も確保されたことは非常に大きいと思います。

一方で、現在の仕組みは、CI だけでなく、手元でも手軽に実行でき非常に便利な反面、大量のPDFファイル(期待するPDF)をリポジトリに保存している*3 点や、通常の spec に比べるとどうしても重く遅い処理のため、CI 全体の時間・リソースを少なからず圧迫してしまっている点など、課題点も多く残るのが現状です。

今後も、reg-suit の導入など、より良い環境を模索していきたいと思っています。

お知らせ

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

herp.careers

*1:Misoca では基本的に毎日午前午後の2回リリースします。

*2:その他関連するものとして、PDFの比較を行う pdf_matcher gem や GitHub Actions で diff-pdf をインストールする setup-diff-pdf action などもあります。

*3:Git LFS として扱っています。

もくテク「新年の抱負を語ろう!LT」を開催しました

こんにちは、情シスエンジニアの飯田です。

寒さの厳しい時期になりましたね。私の部屋はロフト付きのため天井が高く、エアコンの暖房が上に流れてしまうため冬の寒さが課題だったのですが、今年から電気毛布とフットウォーマーを導入してリモートワーク環境が快適になりました。電気代も安いみたいなので嬉しいです。

さて今回は、先日1月20日(木)に開催したもくテクの報告記事となります。
イベントページはこちら(開催は終了しています)。

mokuteku.connpass.com

テーマは「新年の抱負を語ろう!LT」

2022年最初の開催ということで、テーマは新年らしく今年の抱負についてです!
デスクトップ・クラウドアプリ開発に新規サービス開発、情シス、QAと様々なチームのエンジニアに登壇いただき、新年の抱負を発表してもらいました。

技術の話がメインになると思いきや、仕事に関することからプライベートのことまで様々な抱負や目標が語られましたので、カテゴリー分けしてご紹介したいと思います。

仕事で成果を出すぞ!

最初は仕事に関するものです。各チームで今年の開発スケジュールや山場が見えているので、そこで成果を出せるよう勉強を頑張りたいという発表がありました。

この目標に対する手段として挙げられるのが資格の取得で、情報処理技術者試験やAWS認定、さらには弥生らしく簿記を目指している方もいました。資格の勉強は知識の体系的な習得や整理に役立ち、見事合格できれば自信にも繋がるので、有効な方法だと思います。

趣味にも力を入れるぞ!

仕事も大切ですが、プライベートを充実させることも重要です。ということで積読を消化したり自作のアプリを作成したりと趣味に関する抱負もありました。

弥生の開発本部ではリモートワークがすっかり定着しており、通勤がなくなって自由に使える時間が増えたという人も多いと思います。コロナ禍という厳しい状況が続いていますが、その中でも楽しめる趣味があると生活も充実しますね。

生活習慣を変えるぞ!

仕事や趣味を問わず、それぞれ達成したい目標のために生活習慣を変えようという人もいました。エンジニアらしく自分で情報収集アプリを作ってチェックする習慣を身につけたり、ダイエットのために運動を始めたりと、こちらも手段は様々です。

そういえば弥生では2022年1月からフレックスタイム制が導入されました。リモートワークによって働く場所が選択できるようになり、フレックスによって働く時間にも自由度が生まれました。これを活かして家事や育児を頑張るという社員もおり、従来よりもより働きやすい環境になることが期待されます。

仕事に遊びごころを!

ちょっと変わった抱負もありました。ITエンジニアといえば設計書や手順書が欠かせませんが、お堅い文章ばかりなので時候の挨拶や超感覚的な表現を取り入れてほっこりしようという、遊びごころ満載の内容でした。正確さの求められるドキュメントで超感覚的とはこれ如何に?と思いましたが、発表では次のような例がありました。

  • 野山がサクラ色に染まり始める今日この頃、初期設定入力の画面設計です。
  • おいおい、あと何回させるつもりだ?とあきれる程、Windows Updateします。

なるほど、このような表現があると気持ちも和みそうですね!…あ、レビュアーさん、この人のドキュメントのレビューは念入りにお願いします(笑)

今年ももくテクを盛り上げていきます!

最後にもくテク運営の抱負を簡単に書きたいと思います。

もくテクは昨年5月にオンライン形式に変えて再開し、これまでで9回実施してきました。今年もトレンドの技術や話題を取り入れ、もくテクを盛り上げていきたいと思いますので、今後もよろしくお願いいたします!

え、私自身の抱負は何かって?…そろそろクロージングのお時間ですので今回はこの辺にしておきたいと思います(逃走)

次回のご案内

次回の開催は2月17日(木)で、「弥生って、実は機械学習もやってるんです!」がテーマです。

弥生が提供するサービスには機械学習を用いた機能があり、自社で研究開発を行っています。
どのような仕組みなのか、研究開発はどうやっているのか、運用はどうしているかなどの裏側について紹介しますので、機械学習に興味のある方はぜひご参加ください!

mokuteku.connpass.com

採用について

弥生では、幅広いポジションでいっしょに働く仲間を募集しています!
ポジション等の詳細については以下のサイトをご覧ください。

herp.careers

Dockerの有償プランを契約して運用するまでの話

こんにちは。弥生の内山です。
みなさまご存知の通り、2022年1月31日以降、一定以上の規模の組織でDocker Desktopを利用するには有償プランの契約が必要となります。

www.docker.com

弥生では、検討の結果、Dockerを利用する開発者全員分のライセンスを購入し運用することにしました。
しかし、実際に有償プランを使おう!となったとき、具体的に何をしたらよいのかという情報がWeb上にほとんど見つからず、手探りで作業を進めることになりました。
現時点で、ようやく運用の形が見えてきたため、この記事では契約から運用までの具体的な考慮ポイントをご紹介したいと思います。
無償利用の猶予期間終了が迫っている中、有償プランの利用について困っている方の助けになれば幸いです。

(なお、この記事は2022/01/20時点で弥生内で検討・試行した内容に基づいて作成したものであり、Docker社の提供するサービスについて正確な情報を提供することを目的としたものではありません。契約を行われる際は十分な調査を行った上でご判断ください)

なぜ有償プランを契約するのか

Docker Desktopが使いたい

有償プランを契約する目的は、開発メンバーがDocker Desktopを使えるようにすること、ほぼそれだけです。
「Docker Desktopを利用せず、無償で利用できるツールの範囲でDockerを使い続ければよいのでは?」という考え方もあります。
実際、Web上にはDocker Desktopを使わずにDockerを使い続けるための手順が多数見つかります。
そのようにして有償プランを契約せずにDockerを利用し続けるという選択はありだと思います。
ですが、我々は有償プランを契約してDocker Desktopを利用した方がよいと考えました。
理由は以下です。

Dockerまわりのセットアップやトラブルシュートが簡単であるため

Docker Desktopは、それをインストールするだけで、Dockerの利用に必要なセットアップがほとんど完了します。
また、GUIのツール上から、稼働中のコンテナやpullしたイメージを管理できるため、DockerのCUI操作に不慣れなメンバーでもトラブルシュートが比較的容易です。
実際の開発チームでは、スキルや経験が様々なメンバーが参加しているため、簡単にセットアップやトラブルシュートが可能であるというメリットは大きいと考えます。

Windowsコンテナを利用したい場合、Docker Desktopがないと厳しそうであるため

弥生の新規プロダクトの開発では、Windowsコンテナを利用して機能を実装する可能性があります。
Windows 10/11にてWindowsコンテナを利用する場合、Microsoft公式の手順では、Docker Desktopをインストールする方法が案内されています
Web上を探せば、Docker Desktopを利用せずにWindowsコンテナを利用する手順も見つかりはするのですが、多少複雑な手順となりますし、またいつまでもその手順が有効とは限りません。
前述の理由と近いですが、開発メンバーがトラブル無く開発を続けられることを重視するならば、やはり公式の手順通り、Docker DesktopをインストールしてWindowsコンテナを利用した方がよいと考えました。

契約・運用のポイント

プラン選択は"Team"プランがよさそう

2022年1月現在、Dockerの有償プランには、"Pro"、"Team"、"Business"という3つのプランがあります。
どのプランでもDocker Desktopは利用できるため、一番安い"Pro"プランを選択したくなるのですが、企業で利用する場合、"Team"プランを選択するのが現実的だと考えています。

www.docker.com

企業でソフトウェアライセンスを管理・運用する場合、「必要な分を一括で購入し、必要なメンバーに付与し、不要なメンバーからは回収する」というようなオペレーションができないと、管理が面倒すぎて運用が難しいと思います。
"Pro"プランは、個人の商用開発をターゲットとしているためか、Docker ID(=ユーザーアカウント)のそれぞれにおいて支払情報(クレカ)を紐付けて支払いを行うような設計になっているようです。
5人以下程度の組織ならばどうにか運用できるかもしれませんが、それ以上となると管理は難しいでしょう。
"Team"プランであれば、"Seats"という形でライセンスがプールされ、個別のメンバーに着脱を行うことができるため、数十人規模での運用に耐えうると思います。

f:id:ucho_yayoi:20220120201731p:plain
"Team"プランでは利用しているSeatsが表示される。Seatsの増減も可能。

”Business"プランは、SSO機能などがあるようなので、より大規模な組織での運用に適しているのではないかと思います。
ただし、"Team"プランと比較して価格が跳ね上がることと、我々としてはそこまで高度な機能を必要としていないことから、候補としてあまり検討を行いませんでした。"Business"プランは日本の代理店での取り扱いを行っているので、興味のある方はお問い合わせをしてみるとよいかもしれません。

メンバーには業務用アカウントを取得してもらう

"Team"プランでは、Organizationというグループのようなものを作成し、そこにメンバーを招待して追加していきます(追加されるとSeatsが消費されます)。
招待を行う際、Docker IDまたはメールアドレスを指定して招待を送るのですが、我々はここで社用のメールアドレス宛てに招待を送り、その社用メールアドレスを使ってDocker IDを作成してもらう運用としました。
理由は以下です。

ライセンスの利用者を明確にするため

メールアドレスを指定して招待を行うと、そのメールアドレスを紐付けたDocker IDでなければ招待元のOrganizationに参加することができないようです。
このことを利用し、招待は社用メールアドレスに対してのみ行うようにすることによって、社内の開発メンバーだけが確実に会社のOrganizationに参加するようにしました。

f:id:ucho_yayoi:20220120200954p:plain
招待されたときのDocker ID作成画面には招待を受け取ったメールアドレスを入力する欄がある

個人利用と業務利用を分けるため

個人用のDocker IDを会社のOrganizationに追加してしまうと、個人でDockerを利用している際に、誤ってOrganization内のリポジトリへの出し入れを行ってしまい、セキュリティリスクにつながる恐れがあるのではないかと考えました。
個人用と業務用のDocker IDを別にすることによって、上記のようなリスクをあらかじめ軽減できるのではないかと思います。

台帳でアカウントを管理する

せっかく社用のメールアドレスを指定して招待を行ったものの、Organizationに追加されたDocker IDに紐付いているメールアドレスを見ることはできません。見ることができるのはID文字列とプロフィールのFull Nameだけです。
そのため、「誰のIDか識別できるようにするために、ID文字列やプロフィールに本名を入れるようにしよう!」などとしたくなるのですが、ID文字列とプロフィールは公開情報となるため、本名をインターネットに公開したくないメンバーに対してそのようなことを強要するべきではないと思います…。 そこで我々は、招待したメンバーから実際に作成したID文字列を教えてもらい、それを氏名やメールアドレスと合わせてスプレッドシートで台帳管理するという、アナログな解決策を採ることにしました。
ただ、結局は退社したメンバーをOrganizationから削除するなどの棚卸し作業が必要になるため、どのみち台帳管理のようなことは必要になると思います。
(もしかしたら"Business"プランでSSOを利用すれば、認証サーバー側でIDを無効化するだけでOK、となるのかもしれませんが、詳細はわかりません…)

おわりに

Dockerの有償プランを具体的にどのように運用していくかをご紹介しました。
このような有償ライセンスは、ライセンス費用そのものに加えて、運用のコストがかかるのがつらいところです。
みなさまも、運用上の工夫ポイントなどがありましたら、ぜひ共有いただけるとうれしいです。

お知らせ

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

2021年に出会った障害と2022年の目標

こんにちは、カトです。弥生でQAエンジニアをしています。

2022年、新しい年になりました。目標を立てる人も多いですね。 目標は「SMARTゴールで設定」、「モチベーションがあがる目標」が良いと言います。しかし、現状を正しく認識しないと、適切な目標を立てることはできません。 ということで、私が2021年に出会った障害をふりかえり、同じことを繰り返さないように目標を立てていきます。

弥生開発者ブログを参考に、ふりかえっていきます。

障害ふりかえりに向き合う

「カレンダーがケーキに見える」

カレンダーとケーキを誤認?
安心してください。障害票のタイトルではありません。

製品・サービスの画面に、日付を指定するためのカレンダーアイコンがあります。カレンダーアイコンをクリックすることにより、カレンダーを表示し日付を選択する仕組みです。
今回の対象は、"あの"カレンダーアイコンです。

テストをしているとき、システムごとにカレンダーのアイコンが異なっていることに気がつきました。
ログを確認したところ、カレンダーアイコンを使っている1つのシステムで、カレンダーアイコンを「マンスリーカレンダー」の絵から「日めくりカレンダー」の絵に変更していました。
その変更ログに残されていたのが「カレンダーがケーキに見えるため、アイコンを変更」というメッセージでした。

なぜサービスごとにカレンダーのアイコンが異なってしまったのか、障害ふりかえりをしました。

「類似機能なのに、処理結果がちょっと違う」

似ているだけではダメ?
追加機能開発において、「既存の処理と同じように」動作するように実装することがあります。
まるっきり同じ処理であれば、コードを複製するのではなく、同じ処理を呼び出すことで対応できますが、何をどの順序で呼び出すのか?流用できるところと流用できないところはどこなのか?の見極めをしなければなりません。
闇雲なコピー&ペーストでもいけないし、安易な呼び出しでもいけません。

テスト作成時、既存の処理のテストケースを見て、入力と出力が同じ結果になるようなテストパターンを検討しました。
しかし、過去に作成していた既存の処理でのテストには漏れがありました。そのテストが漏れていたパターンにおいて、既存機能と追加機能で、同じ入力をしても出力が異なってしまうという事態が発覚しました。

なぜ予定していた記述型テストで障害検出することができなかったのか、障害ふりかえりをしました。

 運用開始後、境界値が「こんにちは」

境界値 隠れ身の術?
設計書に書いていない境界値があることは承知しています。「設計書に書いていないからテストしない」ではなく、「設計書に書かれていない情報を引き出して明確にする」ことが、テストの活動の一つだとも思っています。
境界値テストのイメージ
2値を選択するか、3値を選択するかという内容は、今回は割愛します。

今回の対象は、画面入力した文言に対し、内部でIDを採番してデータを持つ機能です。 IDの最小値は1。最大値は、手動でテストできない数となっていました。
最大値で登録できることの確認はコードレビュー・単体テストにて実施しました。手動テストでは、1つめの登録、2つめの登録を確認しました。
他のテストにおいても登録をしているため、テスト期間中に少なくても10回の登録は実施しています。
これで、この登録におけるテストに漏れはないと思っていました。

ところが…

突然、なにか出てきた!
しばらくすると、テスト環境で、「入力した文言ではなく、IDが表示される」という事象が発生しました。 テストをしたはずなのに、なぜ?と思いながら障害票を起票、エンジニアに調査をしてもらいました。

調査結果は、「IDを金額と同じような3桁区切りの情報として扱ってしまっている箇所があった。IDが1000以上の場合に、区切りなしの値と区切りありの値が不一致とみなされ、IDに紐づく文言ではなく、IDそのものを表示してしまっていた」ということでした。

なぜ予定していたテストで検出できなかったのか、障害ふりかえりをしました。

 ふりかえりをまとめる

「どのチームが作った」「その時、誰が担当していた」という情報は、弥生の製品・サービスを使っているお客さまにとっては関係のないことです。
チーム弥生として、お客さまには、「かんたん・あんしん・たよれる。」を提供し続けなければいけません。

ふりかえりから、2022年の目標

2021年の障害ふりかえりに向き合ってきました。
「ふりかえりは大事」であることは理解していますが、真剣に向き合うのは、大変です。

ふりかえりから、2022年の目標は、

製品・サービスの、現在を見る/過去を見る/周囲を見る


とします。

まだ、この記事の中で、私の目標は、SMARTゴールである、Specific(具体性)、Measurable(測定可能)、Achievable(達成可能)、Relevant(関連性)、Time-based(期限)は明確になっていません。
これは、また次の機会としましょう。
この目標を達成するためにやるべきことを落とし込んでいけば、SMARTゴールになっていくはずです。
目標のためにやるべきことを具体的にし、現実的に実践が可能なのかどうかを考えて、製品開発に取り組んでいきます。

さいごに

弥生の開発メンバーはどんな目標を立てているのでしょうか?
2022年最初のもくテクは、1月20日に開催です。テーマは、「新年の抱負を語ろう!LT」
さまざまな分野やキャリアのエンジニアの目標を聞いて、自分の目標をブラッシュアップしていける機会になります。
ぜひご参加ください。 mokuteku.connpass.com

弥生では、「かんたん・あんしん・たよれる。」を実現するために、一緒に、弥生の製品・サービスの品質を追求するメンバーを募集しています。
herp.careers