転職したばかりのエンジニアが活躍するためにやったこと

勉強会の開催風景

こんにちは、2021年4月に40代で中途入社を果たしたエンジニアの okoshi です。

freeeでの働き方について興味のある方は是非ご一読ください。

中途で入社してはや4ヶ月経とうとしています。時間がたつのは早いものです。 とはいえ、まだまだ業務への慣れは感じないし、毎日のように業務の進め方や考え方に発見があります。

これまで何度か転職の経験があるのですが、転職した直後は毎回意識していることがあります。 それは“どうやったらすばやく活躍できるようになるのか”ということです。

これからfreeeに転職したいと思っている方、あるいはすでに就職することが決まっている方は是非参考にしていただきたいと思っています。

今回の転職は入社前からどうやって活躍するかをいつもより強く意識した転職になりました。 というのもこれまでの転職ではうまくいったこともあればそうでなかったこともあって、どのようなことが効いていたのかを思い返しても決定的な理由がわかならなったからです。

そのため、転職するに当たって仮説をたて確度の高そうな仮説の検証となるように行動してみました。

その仮説とはエンジニアの文化への順応を意識して行動できると活躍できるというものでした。 その他に思いついた仮説はいくつかありました。 しかし、年齢的に若かったことが作用しているとか検証が不可能なものであったり、例えば過去にSIerに所属していたときは指名で仕事が舞い込むことが多く、仕事内容の特性が強く作用していたことが明らかで、業務内容の違うfreeeでトライすることは現実的ではありませんでした。 あるときは、社内のエンジニアの文化を無視して、周りに自分のやりかたを押しつけ、それが孤立につながったことも過去に経験しました。

freeeのエンジニアの文化ってなんだろう

入社してみると様々な研修があり、これから起こることにワクワクしながらも“文化”の理解を意識し始めました。

  • 「どうやったらすばやく文化に触れられるか」
  • 「誰に聞けばわかるんだろう」

頭の中にはこららが渦巻いていたのですが、早々に”文化”の含まれたスライドに出会います。

それは“freeeエンジニア向け会社説明資料”です。Culture of Developers 開発文化というタイトルのページがあります。

  • 失敗して攻めよう
    • 学びのある失敗をして最速で成長しよう。学びのある失敗とはチームやプロダクトの成長につながる失敗。学びのある失敗をしていないのは挑戦が足りない。
  • 何でもやれる、何でもやる
    • チームで扱う課題について、特定の技術や領域に固執せずオールラウンドに取り組めているか。アプリもインフラも、サーバーサイドもフロントエンドも、早さも正確さも。
  • 必殺技
    • チームの中で自分が貢献できる特徴を理解して発揮しているか。また、その特徴を増やしていけるか。
  • カッとしてシュッとやる
    • 最低限はここまで、に満足せず自分がやりたいことを載せていけるか。システムのボトルネック、負債に対する怒りをプラスの方向に関心を持ち、解決できるか。
  • 世話を焼いていくスタイル
    • チーム内外問わず周囲を自分の知見で助けられているか。レビューしているか、システムor人間のアラートに疾風迅雷のごとく反応しているか。

「お、素直にこれをやってみよう」そう思いました。 こういう出会いは決して運ではなく、普段からアンテナを張っていなければないと思っているので、とてもうれしかったことを覚えています。

どんなことをしたのか

すぐにやれることをやる

入社してすぐは当然ながら業務知識はありません。しかし業務知識がなくても活躍することはできます。 ではどんなことをしたのかというと、自分の持つITスキルを以て開発環境の改善に努めました。

開発環境は運用がまわるようになると、改善が滞るのは経験上よくあると思っていたのと、エンジニアにはスピーディーな作業が求められているのはよくあることです。そのため改善の対応が後手に回っている可能性があります。 なぜ簡単なことが後手に回っているかというと問題は認識しているが、解決方法を調べる時間がないからという理由もまたよくあることです。 その中にはたまたま解決方法を知っているものがいくつかありました。 そして入社者オンボーディングとして実施しているタスクの隙間時間で、いくらかの開発環境の改善を進めました。カッとしてシュッとやるということですね。

幸い、これまでスクラムマスターを経験することが多かったので私の所属したチームでスクラムマスターを務めさせてもらうことにありました。 最近では社外のスクラムコーチにコーチングを仰ぎ、スクラムマスターとしての技量を伸ばしています。必殺技の体現です。

入社してすぐの方の特権と考えているものがあります。それは“失敗させてもらえやすい”ということです。 もちろん事業の継続に影響のあるような失敗はしないようにすることは強く意識しなくてはなりませんが、プログラムやアーキテクチャなど社内の実質的な標準があるかもしれないことや、実施している背景のわからないイベントに対してあえて自分のやりかたをぶつけてみました。 多くの場合失敗するのですが、その結果“なぜそうなっているのか”を理解することができました。 これは結構勇気のいる行動かもしれません。しかしその失敗は劇的な成長につながります。失敗して攻めようということですね。

自分の存在をアピールする

freeeの社員はエンジニアだけではありません。営業職、デザイナー、マーケター等様々です。そういった方々にも私の存在を認識してもらうと活躍の場を得られる可能性が高くなると思っています。 freeeでは入社すると、自己紹介を自分で動画に撮って社員にみてもらう週間があります。通常はスマートフォンで自撮りをするのですが上記のようなこともあり目立ちたかったので動画にテロップをつけたりBGMを付けるといったことをしてみました。

エンジニア向けには、自分が持っている知識を知ってもらうためにドキュメント化を進め、社内に浸透していないような技術に関する記事で反響がありました。

それ以外に自分のわからないことを一覧化しました。例えば Ruby はわかるが Go 言語についてはわからないといった感じです。自分の知らないことを共有するのはパーソナルブランドに傷がつきそうで少し恐れを感じる方は多いかもしれませんが、わからないことにはサポートしてもらえたり、あるいは逆に頼ってもらうことができるようになるので有用だと考えています。

社内に仲間を増やす

いかに自分の存在をアピールしたとはいえ、話したことのない人との交流には壁を感じるものです。 そこで私は、チームのメンバーに限らず、社内向けドキュメントの自分の記事に”いいね”やコメントをいただけた方の中から気になった方や、紹介された人と1on1を積極的に行いました。

それ以外に勉強会の開催も行いました。参加者を募ってそこでつながった人たちとは面識ができます。面識があると相談するときの話が早くなるといった効果が見込めます。

採用に貢献する

開発文化の何でもやれる、何でもやるというのは主にエンジニアリングに関することですが、それを拡大解釈してやれそうなものはやってみると考えていました。

そんな中、入社して2ヶ月経った頃採用イベントが行われるということで、参加させてもらいました。 採用は経営課題のため、会社に貢献できたと考えています。

それ以外に社外でのLTに積極的に参加し、freeeのアピールを行いました。 大きなイベントではQiitaのイベントでもLTをさせてもらいました。

後の人のために苦労したことを残す

入社してすぐは、わからないことが非常に多いと思います。 自分がわからないことはこれから入社する人も同じようにわからないはずだと考えました。 私が入社した後一ヶ月後にも、中途入社者がいることがわかっていたので私がわからなかったことを同じように困らないようにしておきたいと思いました。 そのため、困ったことやわからない言葉を一覧化して残しておきました。 これは世話を焼いていくスタイルを体現したものでもあります。

自社のプロダクトを知る

freee には比較的多くのプロダクトがあるためいきなりすべてを把握することはとても難しいと思います。

そうなると必要になったときどうしたらいいかわからなくなってしまうのでなんとかしたいと思いました。 困ったときに聞ける相手がだれかを知っておけばなんとかなりそうと想い、先輩社員にどういった社員がいるかを聞いて将来に備えました。 あるいは聞きそびれていたとしてもすぐに誰に聞けばわかりますか?と聞くようにしています。

これは今すぐ効果があるような行動ではありませんが、これから効いてくるはずです。

その他には、社外の利用者の動画を見るといったことも行いました。 社内から見るプロダクトはアーキテクチャであったり、プログラム、仕様等といったところがとても見やすいのですが、利用者がどう使っているかまでは見えません。

大変ありがたいことにfreeeのプロダクトは多くのユーザーにご利用いただいており、使い方の解説を動画サイトで公開されている方がいらっしゃいます。 利用者がどう使っているのかを手っ取り早く確認するためにこの動画サイトの動画が非常に役に立ちました。

これは先述の開発文化とは無関係ですが、ある程度の自社プロダクトの知識は必要だと思いますのであえて紹介させていただきました。

終わりに

最初は業務になれるためにまわりに合わせるという考え方もあります。しかし私の経験上成果を出せない状況がしばらく続き、人の意見を聞かないと動けない人という印象を周りに与えてしまう恐れがありパーソナルブランドを低下させてしまうのでやめたほうがいいと思っています。

特に気に入っているのは“失敗して攻めよう”です。これがないと素早い成長を阻害すると思うのです。 これがもし”失敗したら責めよう”だったとしたら新しい挑戦はしにくいし、心理的安全性もなくなり、組織は硬直化していくと思います。

こうしてやったことを振り返って思ったのは、何でもやれる、何でもやる世話を焼いていくスタイルに関しては十分にできているとはいえない状況であり、完全に文化に順応できたとはまだ言えないでしょう。 それでもLTに出ないかと言ってもらえたり、こういった記事を書かないかというお誘いをいただけるのは自分の行動に対する効果が現れ始めているからだと感じています。

freeeの開発文化の理解が深まり、いっしょに働きたい会社だと思っていただければ幸いです。

freeeアクセシビリティー・ガイドラインVer. 202107.0を公開しました

こんにちは、freeeのアクセシビリティー・ガイドラインおじさんの中根です。

先週末に外出したら夏が思いの外本気を出し始めていてすでに夏バテ気味の今日この頃、皆様いかがお過ごしでしょうか。

さて、今回もfreeeアクセシビリティー・ガイドラインの更新情報をお届けします。

と言いつつ、今回もあまり大きな変更はありません。

だから、というわけではありませんが、最後に近日開催予定のイベントのお知らせもありますので、最後までお付き合いください。

ガイドラインの文言を一部変更

以下の2つのガイドラインについて、文言を変更しました。

入力ディバイス:[MUST]キーボード・トラップの回避

変更前:
動画プレイヤーなど、特定のコンポーネントにフォーカスした状態から、Tabキー、矢印キー、Escキーで抜け出すことができるようにする。
変更後:
ページ中のあらゆるコンポーネントについて、Tabキー、矢印キー、Escキーなど簡単な操作でフォーカスを外すことができるようにする。

このガイドラインは、ページ中にあるコンポーネントに一度フォーカスすると、キーボードだけではそこからフォーカスを外せないというような状況を生まないように、という意図のものです。 このガイドラインの基になるWCAGの達成基準が考えられた頃には、Flashのコンテンツ、Javaアプレットなどがこういった問題を引き起こすことが多く、中でも動画や音声のプレイヤーが埋め込まれている場合によく見られる問題だったことから、このような記述にしていました。

しかし、最近は動画プレイヤーなどでそのような現象に遭遇することが随分と減った印象があります。 その代わりというわけでもないのでしょうが、何らかの機能を実現するためにJavaScriptで実装されているコンポーネントなどが、こういった問題を引き起こしているケースに出会うことが多くなってきているように思います。

そこで、必ずしも動画や音声プレイヤーに限った話ではないということを明確にする必要もあると考えて、このような変更をすることにしました。

動画プレイヤーなどを埋め込む場合にも引き続きこの点に注意する必要はありますので、「音声・映像コンテンツ」カテゴリーにある同じ内容のガイドラインには変更はありません。

なお、この変更に伴って、チェックID:0201の文言も修正しています。

ページ全体:[MUST] 画面方向を固定しない

変更前:
特定の画面方向(縦置き/横置き)での利用を強制しない。
変更後:
コンテンツの性質上必要不可欠な場合を除いて、特定の画面方向(縦置き/横置き)での利用を強制しない。

対応するWCAGの達成基準では例外を認めた上でAAになっているのに対して、freeeのガイドラインでは例外を認めず[MUST]になっていました。 WCAGに合わせて例外を認めることにしたのが、今回の変更です。

この検討の中で優先度についても検討しました。 その結果、どういった場合に許容される例外となるのかということについては、その都度丁寧な検討が必要だと思いますが、例外を認めた上であれば[MUST]のままで問題ないだろうという判断に至りました。

その他

変更内容が軽微だったためこのブログではお知らせしませんでしたが、Ver. 202106.0もリリースしています。

参考情報に掲載しているNVDAチートシートが配布元で更新されたことへの対応などをしています。

他にもいくつか細かな変更をしていますが、詳しくはリリース・ノートをご覧ください。

引き続きご意見などお待ちしています

今回の変更についても、それ以外の部分についても、ご意見やお気付きの点など、GitHubリポジトリーのIssuesやPull Requestsでお知らせください。

イベント開催のお知らせ

元々freeeアクセシビリティー・ガイドラインやチェックリストは社内で使うために作り始めたものですが、最近では社外でも活用してくださっているというケースが出てきました。 そこで、実際に活用してくださっている方にお話しを伺おうというイベントを企画しています。

  • 日時:2021年7月29日(木)19:00~21:00
  • 会場:オンライン
  • 参加費:無料

以下のページからお申し込みください:

https://connpass.com/event/218780

connpass.com

【freee x メルペイ】QA Tech Talk 〜リリースを早めるQA〜 に参加しました

こんにちは、2021年4月にfreeeに新卒で入社したberryです。

今年は5月末にほぼリモートの新卒研修が終わり、6月頭から新卒はそれぞれの部署に配属されていきました。私はQA配属となり、現在テスト技法やテスト自動化の勉強に勤しんでおります。

本記事では2021年6月23日にfreee株式会社と株式会社メルペイさん合同で開催されたイベント、【freee x メルペイ】QA Tech Talk 〜リリースを早めるQA〜について、理解のために各ディスカッションをまとめ、新人なりに考えた/感じたことを残したいと思います。

目次


上流工程で何をやってQAを早めているか

  • メルペイでは
    • 開発段階で開発チームと一緒に要件定義や開発の設計を考える
    • 外部パートナーと仕事をする際は企画段階から初期品質を作ったりしている
      • 開発前の意識のすり合わせなどにQAも入っていく
    • QAをしてバグを見つけるというより、発生する前に防ぐ
  • freeeでは
    • スクラム開発なのでスプリント(一週間)の初めにengとQAそれぞれ開発計画テスト計画を立てる
    • 実装が始まる時にリスク洗い出し会を行い、テスト項目について議論し、プロダクト&テストをそれぞれ作り始める
    • 実装し次第テストも順次行われるので実装が終わる頃にはQAも7~8割終わっている
    • 実装中にQAで仕様の抜け漏れなどを発見できると、本来なら間違ったまま進めて手戻りが発生していたところをカバーできることがある

まとめ

基本的に根本の部分であればあるほど間違った際に見直さなければならない範囲が広くなってしまうため、そういった部分はなるべく早めにテスト&開発側との議論を行う必要がある。と理解しました。

QAの方たちは難しい仕様をどうやってカバーしているのか

  • メルペイでは
    • 大変で課題になっているが、オンボーディングの充実やメンターとの話し合いでキャッチアップしていく
      • QAが横断的に仕様を理解することによって上流の話し合いにも入っていける
      • eng側はどうしても各マイクロサービスを突き詰めることになり、他サービスとの連携時に齟齬が発生しやすいため、QAが架け橋となって課題やプロジェクトの状態を整理していく
  • freeeでは
    • メルペイさんとほぼ同様
    • サービス間の連携がある場面で、マイナス金額の考慮の仕方が違うことがレビューによって判明したため、横断的な視点を持てるQAの存在は重要

まとめ

開発時にバグが発生するのは、開発対象とそのプロダクト以外との繋ぎ込み部分になりやすい。そのためQAとしてプロダクトに関わる時は、それぞれのサービス同士の知る必要がある仕様を相互に把握できるように動けると良いと感じました。

先ほどメルペイさんの回答にあったQAのオンボーディングとはどのようなことをやっているか

  • メルペイでは
    • マイクロサービスを理解するために、自分の理解を他人に説明したり、処理の流れを説明したりなどして理解ができているかを確認しながら進める
    • 最近はテクニカルな部分も増えてきているため、一筋縄ではいかない場面も増え、難しい課題となっている

まとめ

他人に説明するという行為は理解度チェックにおいてとても強力な手段であり、かかる時間に見合った効果がありそうだと感じました。私も自分が理解できた!と思ったらその物事を説明させてもらう場を作ってみたいと思います。

また、現在私は毎日日報を書いており、得た知識を自分がどう咀嚼したかどうかを含めて先輩方の見えるところに投稿しています。私は内容に関してフィードバックや補足をもらったり、先輩方からは私がどの程度理解を進められているかを把握できるという利点があると考えています。

開発中のテストでどういうことをやってリリースを早めているか

  • メルペイでは
    • 開発段階からQAがspecを確認、把握して、テストを書いていく
    • テストを書くとき(一番プロダクトについて詳しいとき)にリグレッションテストを一緒に作る
    • postmanを利用していたが、自社作のAPIテスト用ツールを制作し、使っている
  • freeeでは
    • フィードバックを早くすること
    • 開発時にunitテストを書く文化があったり、ステージングデプロイ時にUIやAPIレベルのテストが走るなど、素早いリターンを意識している
    • 会計帳簿などのドメインとして重要な機能は確実にチェックするようにしている
    • 本当はもっと手前側(開発に近い側)でバグ等を拾っていきたい
    • 手前側でやる基盤やテストの書き方の浸透がまだまだなため、課題となっている

まとめ

フィードバックが早いとリリースが早くなる理由を考えました。最初の質問と同じく間違った前提をもとにコードを書いてしまう手戻りが防げることはもちろんですが、コードを書いた記憶が新しいうちにやり直しができることにもあると思います。私も1週間前に書いたはずのコードを覚えておらず、「この部分のコードがこの書き方でいい理由ってなんだっけ?」と思ってコードを追い直す作業をしなくて済みます。

またフィードバックの早さ以外での部分でも、QAとして目指していきたい理想的な動き方がまとまっていると感じました。

自動テストの実装はQAエンジニアが対応されているのでしょうか?

  • メルペイでは
    • APIテストはQA*1、unitやe2eはengが書いている
  • freeeでは
    • e2eはQA、unitやAPIテストはengが書いている
  • 普通はengが具体度の高い部分を担当して、QAが抽象度の高い部分を担当すると思ったが、何故逆なのか
    • e2eテストをxctest(swiftのテスト)などで書いているため、engが書きやすい
    • 開発とQAが同じ視点で話をしたいため、最終的にはxctestもQAが書きたい
    • QAと開発でラインを分けたくない => 全員品質

*1 配信においてunitテストはQAが書いていると解釈していましたが、後日確認を取ったところunitテストはengの方が書いているとのことでした。

まとめ

2社で完全に逆の結果となり興味深かったですが、使用する言語の面から考えると妥当だと感じました。特にUIテストは要素の指定方法なども手段が豊富なため、同じ言語でもテストの書き方は別物になると考えています。となるとやはりある一つの言語を使って10の作業をするのと、複数の言語で半分づつの作業をするのではやはり後者の方が難しいです。それによってQAとengで書くテストが分かれるのは仕方がないと思いましたが、e2eとunit&APIそれぞれのカバーしているシナリオはお互いに把握できるべきだと私は考えています。

マニュアルテスト、ユニットテスト、E2Eテストなどは(誰が)どういう割合で実施していますか?

  • メルペイでは
    • サービスによる
    • 各チームでどこをどうテストしていくかを考えて、スケジュールやタスク量をなどを鑑みてQAとengで作業量を割り振る
    • GOを使っているが、QAもengもテストを書けるので、柔軟に対応できる
  • freeeでは
    • マニュアルテストはQA
    • unitテストはeng
    • e2eテストはseqチーム

ここでもメルペイさんは誰が何を書くかを分けずにテストを実施しているというお話でした。個人的に感動したのは、「スケジュールやタスク量をなどを鑑みてQAとengで作業量を割り振る」という部分で、作業量のバランスが偏ってしまうことによるQA待ちや開発待ちという時間が発生しにくくなるのは画期的だと感じました。

上流や開発テスト自動化ができるQA人材を生み出すためのキャリアパスはどうなるのか

  • メルペイでは
    • 夢物語かもしれないが、全てをできるQAを育てようとしていて、あえてset(freeeのseq)チームを作っていない
  • freeeでは
    • seqは存在するが、組織としてのステップアップ的にはできる人から教わって全体に伝播するという流れの途中であり、全員が自動テストを書けるようになるための勉強中

まとめ

正社員として長い期間会社に貢献し、QAもテストコードをバリバリ書け、上流工程の話もでき、プロダクトを横断する知識があるという姿を目指すのは、やはり簡単には実現しないと思います。

一方で全プロダクトを横断する知識はなくともプロダクト群の基盤関係の整備を進めていくことによって、1プロダクトが外と通信を行う部分は基盤を経由することが多くなるはずなので、基盤周りとプロダクトに横断的な理解があるQAというのはステップアップの段階として目指せるのではないかと新人ながらに考えています。

リリースした後の改善活動はどうしてる?

  • メルペイでは
    • 自動化の部分
    • 新規でサービスを作るときはマニュアルテストになってしまうが、ファーストリリースの直後に頑張って自動化する
    • 後からもう一度テストして欲しい、となったときに16時間かかっていたマニュアルテストがサッと回せるようになった
  • freeeでは
    • バグを大事にしていて、再発しないように原因究明をして知見を蓄える
    • 会計帳簿や帳簿のまとまりなどは一朝一夕では身につかないため、税理士のPMの方からシナリオを作ってもらって質の良いテストを行なっている

まとめ

freeeでは税理士のPMがシナリオと作るという非常に幸運なケースだと思いました。しかし、他の分野でサービスを作っている企業にてドメイン知識を持った人材が社内で継続的に協力してくれるような状態を維持するのは簡単なことではないと感じました。採用活動の難しさの理由の一端を垣間見た気がします。

技術的負債に対してなにか取り組み等はされていますか?

  • メルペイでは
    • リリースを急がないといけない場合、負債を抱えた状態でもリリースしないといけないことがある
    • 負債が溜まってしまうと新しくリリースができなくなる
    • 負債を棚卸してどういう負債があるかを確認し、負債の再発防止方法を検討していった
  • freeeでは
    • 最初はバグが出てしまってPMの方が謝罪に行ったりすることもあった
    • バグの振り返り、言語化できていなかったが考慮が足りなさそうだと思っていたところを洗い出したりしていた
    • コードが書かれた年代に着目し、いつバグの元となるコードが入ったか、この年代の部分のコードは手をつけなくて大丈夫そうだ、というのをengと共に確認していった

まとめ

2社ともチーム内でバグや負債を一旦集めて分析するという工程が入っており、何かのきっかけで見直しをしようという動きがないとそもそも工数を取れないようなイメージを受けました。意識的に負債の棚卸しを出来ればいいなと思います。とはいえ纏まった工数を取るのも大変そうです。

使用性テストはいつどうやっているか

  • メルペイでは
    • ユーザビリティ専門の部署がやっている
  • freeeでは
    • ユーザビリティテストは普段のテストの中でやっている
    • アクセシビリティテストも時間が取れた時にガッとやっている

まとめ

メルペイさんではQAとユーザビリティは分けているという点が印象的でした。どんなサービスを作るかという点ではなく、サービスをどうやってより良くしていくかという点がQAの関わっていくポイントであると理解しました。

JSTQBやIVECなどの知識をQAにどう活かしているか

  • メルペイでは
    • 知識が馴染んでしまっていて活かせている事に気づいていないかもしれない
    • 採用などでは意識しない
  • freeeでは
    • プロダクトの知識やドメインの知識が重要

まとめ

資格の知識が馴染んでしまってそれを使っているかどうかわからない状態は、実務経験と知識が混ざり合うことで発生すると考えています。人によって適したやり方はあるはずですが、知識から入っていくという人もいると思っています。

QAが負荷試験や性能試験のテスト環境を準備するか

  • メルペイでは
    • SREチームが主体となってやっていく
    • セキュリティ面をfreee以上に重視しないといけないため、セキュリティチーム(freeeのpsirt)と一緒に考えていく
  • freeeでは
    • freeeプロジェクト管理立ち上げの時、eng, QA, SRE三位一体でやった(ガトリングを使った)

まとめ

負荷やセキュリティはドメインによってそれぞれ必要なボーダーが変わってくるため、全体を俯瞰する視点の必要性を感じました。

終わりに

今回、QA Tech Talk 〜リリースを早めるQA〜という形で配信を視聴しました。結果としてメルペイさんとfreeeそれぞれのQAの組織内での動き方を比較しながら考えることができ、とても勉強になりました。
末筆になりますが、このような機会を設けてくださったメルペイさんに心より感謝申し上げます。

参考資料

  1. オンボーディングとは何か?

    オンボーディングの達成度合いを図る目安として、各技術領域ごとに独自のKPIを立て、進捗確認をサーベイにて実施しています。リモートでのオンボーディングの状況を定量的に可視化することで、適切なサポートができるよう仕組み化しています。

    • 新しい分野への配属直後では、「各種スキルに対してどの程度の技量が求められているか」以前に「そもそも各種スキルは何があるのか」という段階である場合も多々あると思った。サーベイのコストを考えなければ、独自のKPIを立てて進捗確認を行うのはとても効果的だと感じた。
  2. Postmanについて

    • jenkinsのAPI単位バージョンのようなものだった
      • APIリクエストを送り、そのレスポンスの内容をテストでき、jenkins同様環境変数なども設定できる。
      • リクエストを投げ、そのレスポンスを次のAPIのリクエストに含めるなどの結合テストを行ったりもできる。
      • jenkinsのjob, SUITEのようにテスト、コレクションがある
  3. メルペイでのxcresult活用事例

    • メルペイではPRが出たときや夜間にCircleCIが起動し、テストの実行結果をTestRailで管理したい。
    • 実行されるXCUITest(スマホ用テスト)の結果をFastlane(Seleniumのスマホ版)のカスタムアクションでTestRailにAPIで連携したい。
    • テスト結果のResult Bundle(*.xcresultファイル)はXcode上で確認できるが、そのままでは人が読めない&機械的に読み取るのが難しい。
    • Appleが提供しているxcresulttoolを用いることによってxcresultファイルをjson等に変換し、集計できるようになる。
  4. メルペイ iOS にスナップショットテストを導入した話

    • iOSで画面のスナップショットをそのまま画像として比較することができる
  5. 自作ツールについて書かれている記事 APIテスト用のツールscenarigを実装した話のようです 記事内の自動化に対する考え方が興味深かったので抜粋します

    個人的に特に意識していること 早く確実に品質保証をするために、なるべく機械的にできるところは進んで自動化した方が良いと考えています。 自動化のサービスを適用できるなら検討します。ただフィットするケースが多くもないので、フィットしないなら自分で作る気持ちを持っています。 自動化するところに対しては、保守性をとても大事に考えています。 (よくある話ですが)繰り返し実施しないものは、無理に自動化しません。ただ、自動化にチャレンジすることでスキルアップに繋がる場合はチャレンジした方が良いと考えています。

    • 単純作業は機械にやらせる
    • 保守性が低いとメンテナンスコストだけかかってしまうテストが生まれてしまう
    • 繰り返し実施しないものでもスキルアップを意識してわざと書くというチャレンジは興味深かった

    • 元々内製ツールを用いたテスト時にジョブの実行結果を目視で確認していた

    • Assertを使ってテスト結果を確認するために内製ツールに機能を追加したい旨をエンジニアに相談し、実装してもらった
    • 結果、工数が2倍以上削減され、さらに目視による確認ミスもなくなった
    • と、目覚ましい効果があった模様

    個人的には「発想はあったが、エンジニアに依頼して頼るところはちゃんと頼る」という姿勢を見習いたいと思いました。仮に無理をして自力で全て実装できてもバグを埋め込む可能性は上がり、工数も余計に取ってしまうため、誰がやるといったスコープは意識したいです。

  6. 技術的負債への取り組み:より良いサービスを継続的に届けるための新しい習慣ができるまで

    • リリースラッシュによりリソースを割けず、マイクロサービスとして切り出すべき機能を既存のシステム上に実装し、技術的負債を追うことを選択したが、やはり後続のブロッカーや保守運用コストの増大を引き起こしてしまった
    • チーム内にあった「ヤバそう」という空気を実体化することを説明し、丁寧に振り返りを行った

      発生した障害の振り返り・共有 障害発生から解消までの対応率の数値化 暫定対応などチケットの対応率を数値化

    • 自動テストも作成し、デグレチェックにかかるコストを削減した

    • 結果、問題の発生に対して迅速に対応をし、チームとして再発防止策を考える風習が生まれ、数字にも現れた

    感想としては、問題に対するチームとしての向き合い方が改善されたように感じました。技術的負債の発生の原因を探るプロセスを共有したことによって開発メンバーも新たに発生したバグに対する向き合い方が変わったりなど、取り組める構造を作り出していくことがQAの役目なのかな、とも思いました。

  7. Cypress + TestRail による Frontend E2E テストの効率化について

    • Cypressというe2eテストのフレームワークをTestRailで集計する
    • 集計の行き着く先はTestRailが多い

「人事労務freee」のEC2→EKS移行で、大変だったことと良かったこと

freee Tech Night で司会をしていますのぶじゃすです。4月23日に配信した「freee Tech Night Online #10 〜人事労務freee、EKS移行」の様子をご紹介します。人事労務freeeのアプリケーションエンジニアhanakeとSREのnekottyoの二人に、移行の経緯、プロセス、導入後のメリットとデメリットについて語ってもらいました。

登壇者の写真
登壇者の写真

  • hanake: 写真左上

    • 人事労務freeeのアプリケーション開発担当。
    • 前職でdockerの使用経験あり。インフラの知識を持ちながら、スクラムマスターとしてプロジェクトをリード。
    • 今回は、アプリケーションエンジニア側からEKS移行にチャレンジした。
  • nekottyo (@nekottyo): 写真右上

    • 人事労務freee担当のSRE。AWS、EKS周りの管理がミッション。
    • Datadogでの監視も担当し、安定稼働のための開発を担っている。
  • のぶじゃす (@noblejasper): 写真右下

    • ラジオパーソナリティ、2017年に中途入社
    • mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee に。入社後はエンジニア→エンジニア採用担当→エンジニアと DevBranding を担当。
    • しゃべりたがり。声が大きい。

EKS移行の目的は、障害からの復旧を早めることと、属人的な運用から脱却すること

ご存じない人もいると思いますので、EKSについて簡単に説明してもらえますか。

hanake: はい。EKS (Amazon Elastic Kubernetes Service) は、AWSが提供するKubernetesのマネージドサービスです。主にコントロールプレイでの管理を行うことで、高い可用性を担保できます。Kubernetesの知識を持っていれば、EKSで一般的なWebサービスの本番運用は可能だと思います。

なぜ、人事労務freeeをEC2からEKSに移行したのですか?

hanake: 2つの理由があります。「障害からの回復時間」を早めたかったのが1つ目の理由です。従来は大量のnodeがLoad Blancerにひもづいている状態で、そのうちいくつかのnodeが落ちないことがあって、障害からの回復のためのデプロイに時間を要していました。KubernetesをEKSで運用すれば、明確なpod shutdownのルールが存在しているので、正しく落ちないなどの変な挙動をするnodeの影響を無くすことができると考えました。

2つ目の理由は、「属人化されたインフラ運用」を仕組み化したかったからです。特定の人物しか理解していない運用箇所があったので、EKSで管理をすることで仕組み化することを目指しました。AWSのマネジメントコンソールを活用して、問題が生じた場合は誰でも特定できるように変えたのです。具体的にはTerraformとHelm Chartで管理するように、nekottyoが整備してくれました。nekottyo、ありがとうございます!(笑)

既存のEC2環境のAPMデータをもとに、EKSの負荷試験を行った

移行準備での困難を淡々と語るnekottyoさん
移行準備での困難を淡々と語るnekottyoさん

EKSへの移行は、誰が発案されたのでしょうか?

hanake: アプリケーション側が発端ですね。何人かのエンジニアで集まって、「もっとイケてるインフラにしよう」と話し合って、SRE側を巻きこんだことからプロジェクトがスタートしました。

移行準備で特に大変だったことを教えてください。

nekottyo: EKSに移行するためにコンテナを準備して、dockerファイルを整理してリハーサルしたのですが、そのときはうまく動きませんでした。アプリケーションを動かすための環境変数を入れていなかったり、プリコンパイルされたJavaScriptやCSSが読めなくて、文字だけのhtmlが表示されたり。

やっと動くようになったら、今度はパフォーマンスの問題が発生しました。人事労務freeeでの移行プロジェクトは、新規にEKSを導入するのではなく、EC2から移行する作業でした。EC2 環境と同じ性能を出すことが求められるのですが、プロジェクトの初期においては、私たちに知見が足りなかったんだと思います。

既存のEC2環境のAPMデータをもとに、EKS環境のレイテンシなどの平均・最大を取得しながら負荷試験を行うことで、何とか同じパフォーマンスが出せるようになりました。色んなボトルネックが見つかり、リソースの再設定や、Kubernetesのパラメータの調整を行うことで改善を重ねましたね。

最も大きなボトルネックになったのは何ですか?

nekottyo: これ!という大きなものは無くて、細かい不具合が幾つか出ていた感じです。メトリックスを取ったり、アプリケーションの動きをAPMで追うことで特定していきました。1つを改善しても他のボトルネックが現れることも多く、問題を見つけては直す、の繰り返しでした。

DNSレベルでリクエストをEC2とEKSで分散。問題なく1日で移行作業を完了した

ヤバかったエピソードを笑顔で語るhanakeさん
ヤバかったエピソードを笑顔で語るhanakeさん

導入作業で最も大変だったことは何ですか?

hanake: 決まった時間・間隔で何らかのタスクを進める「CronJob」という機能があります。その中に「suspend」というパラメーターがあって、CronJobが動かない「true」のstatusでデプロイを進めていたのですが、何かのタイミングで「false」に切り替わったのです。夜中の12時に行うべきバッチが走ってしまった、というエピソードがあります(笑)。

それはヤバいですね!!

hanake: 検証環境だから問題は無かったのですが、ビックリしましたね。「startingDeadlineSeconds」を設定すれば回避できるのですが、当時はその知見がありませんでした。Kubernetesの「ハマりポイント」の一つに、順調にハマったという感じです(笑)。

nekottyo: 調べれば分かることなのですが、初めてだったので仕方が無いですね。

実際の導入作業自体はどうでしたか?

hanake: 割と順調に進んだと思います。すごく慎重に作業しましたので。route53 の weighted recordという機能を用いて、DNSレベルでリクエストをEC2とEKSで分散しました。最初は1%をEKSに流して、99%をEC2に流す仕組みをつくって、そこから徐々に、5%→10%→50%→100%と上げていったのです。何か起こったら作業を止めるフローを確立していたので、ドキドキはしましたが、1日で問題なく移行が完了。ユーザー側から見ると、何一つ挙動は変わらないので、クレームなども一切ありませんでした。

デプロイが圧倒的に安定するように。監視の一元管理を可能にした

それはすごいですね!移行の結果として、当初の課題は達成できましたか?

hanake: 解決できた部分は多かったですね。1つ目の課題「nodeがうまく落ちなくて、障害対策に時間が掛かる」については、podを落としてrolling updateをすることで解決しました。Kubernetesでは詳しい設定を行えば、スムーズに処理を行えます。変なnodeがあっても落とせる仕組みがあるので、デプロイは圧倒的に安定しましたね。

2つ目の課題「属人化されたインフラ運用」については、ほぼ全ての運用をTerraformとHelmfileで管理することで、誰がコードを見ても分かるようになりました。

nekottyo: 今回移行したのは「人事労務freee」ですが、ウチの会社はそれ以外にもEC2でサービスを運用しています。今後、移行が発生したときにスムーズに進められるようにHelm Chartを整備しています。アプリケーション開発側でこれらのツールを活用してもらうことで、異なるサービス間でも品質が統一される仕組みをつくれました。

実運用のフェーズに入って改めて感じた、EKSのメリットは何ですか?

hanake: やはり障害の回復が早くなったことでしょうか。スケールイン、スケールアウトの速度が全然違います。以前はnodeの立ち上がりに5-10分掛かっていたのですが、Kubernetesではpodでの管理になって、かなりスケールが速くなりました。1-2分くらいです。たとえば、給与計算は処理のタイミングが集中して多くのpodを要求する状態になるのですが、一気にさばけるようになりました。

nekottyo: 監視ツールも併せて移行することで、運用を強化できました。EC2のときは、Kibana、Mackerelといった複数のSaaSを使用していたのですが、EKS移行に併せてDatadogにまとめました。以前はオペレーションも煩雑で、学習コストも掛かっていたのですが、概ね解消できましたね。現在は、ログもメトリックスもAPMの状況も、ダッシュボードを見れば全て把握できます。不具合があればアラートが上がる仕組みも導入することで、障害対応も効率化できました。

EKS導入のデメリットは学習コストと、デプロイ時のコンフリクト

逆にEKS導入のデメリットはありますか?

hanake: アプリケーション側としては、現状では学習コストが高いです。Kubernetesは抽象化が進んでいるので、何か作業をする際にも、ある程度の知識が必要になります。

たとえば、アプリケーションはコンテナで動いているのですが、Kubernetesではコンテナはpodという単位で管理されていて、podが載っているnodeはAWS管理なんですよ。ですので、nodeのスケーリングなのか、podのスケーリングなのか、判断する知識が必要になります。どこで何を管轄しているのかを把握できないと、扱うのは難しいかもしれません。

nekottyo: これまでは、新しいサービスはEKS側でつくって、デプロイは内製のGitOpsのスクリプトを用いるという形でした。運用手法としては、変更をしたいPRにコメントを打って、そのコメントにフックしてデプロイを促す仕組みを取っていました。

ただ、人事労務freeeは、関わるエンジニアも多く、プロダクトの規模も大きいのが特徴で、この仕組みがうまく機能しませんでした。同一リソースに対して複数PRからデプロイをすると、 PR単位で内容がコンフリクトする問題が起こったり、管理対象が多いので1デプロイあたりの時間が掛かるようになったのです。

そこで、Argo CDというOSSの活用を検証しています。別のプロダクトでは、Argo CDで運用がスムーズになったので。

hanake: Argo CDを入れると、めちゃくちゃ楽ですね!

最後に、EKSの導入を検討している方に向けて、教訓もしくはアドバイスをお願いします!

hanake: まずは、導入や移行の目的を明確にするのが大切だと思います。準備に手間も掛かりますし、導入作業も大変です。コンテナでスケーリングするアプリをつくりたいなら、ECSという選択肢もあります。なぜEKSなのか?どういったメリットを生み出したいのか?意識すると良いと思います。

nekottyo: hanakeさんに同感です。1クラスタで小さいプロダクトを運用したいケースならKubernetesを使う必要は無いと思います。スケールメリットを受けたい、ログ周りをキレイにしたいなどユースケースを想定して、ECSだと手間が掛かるのでしたら、Kubernetesへの移行を考えるのが良いのではないでしょうか。

イベントの本編はここまでです。この後は「アフタートーク」でより深い技術談議が繰り広げられました。

▶freee Tech Night 次回は5月28日に

「freee Tech Night Online #11 脆弱なサービスを守れ!hardening研修」を開催!

freee Tech Night 次回告知アイキャッチ画像
freee社内で実施したセキュリティ研修を公開!

freee-tech-night.connpass.com

▶今回のイベントのアーカイブ(録画)

youtu.be