フェアリーデバイセズの労働サンプル

フェアリーデバイセズの労働サンプル

はじめに

 フェアリーデバイセズでエンジニアとして働いているm.katoです。
 主に音声認識、翻訳、音声合成などのクラウドAPIサービスmimiの開発に携わっています。
 サーバサイドのAPIをRustで書いたり、最近はサービス基盤のGKE移行に伴い、サーバの面倒を見たりもしています。
　
 本記事では、私のとある1日の働き方について紹介します。
 あくまである1社員の1日の働き方というサンプルに過ぎないものではありますが、当社のことを知っていただき、理解を深めていただく一助になれば幸いです。

午前の部

 6時起床。眠気をシャワーで吹き飛ばして、朝食。家の近所をちょっと散歩した後、就業7時。当社ではテレワークが認められており、曜日は自由。月火は自分の定めたテレワークデイということで、自宅での作業となります。

シャドウテスト

 この日は mimi のリリースを控えて、シャドウテストを実施しております。シャドウテストとは本番の横に次期環境を立てまして、リクエストを双方に流すことによって、本番相当の負荷をかけようというテストであります。mimi チームでは大きな変更点がある際にシャドウテストを行うことになっております。開発環境で十分に試験を行なったつもりでも、本番の負荷には耐えられない場合もあります。長時間稼働させることで思わぬトラブルが発生することもありますから、「本番と同等の負荷」を数日間かけることには大きな意味があります。今回は音声認識エンジンのラッパを変更したため、ゾンビプロセスが発生したり、処理速度が落ちないか、が確認の主眼になります。

 シャドウテストに合格した系はそのまま新規の環境として転用されます。「稼働実績がある」。これはITに限らず、エンジニアは全員好きな言葉でしょう。使うなら「稼働実績がある」ものを使いたい。リリース前に稼働実績を作ることができる。これもシャドウテストの大きな利点の一つです。

 当社ではシャドウテストを実施する際、新しい GKE クラスタを作成しています。これは当社独自のものではないと思いますが、いささか変わった手法かもしれません。おそらく、一般的には新しい namespace を作成して、そちらに新しい系を立てることが多いと思われます。新たな GKE クラスタを作成すると大掛かりな作業になりやすいですし、新しい GKE クラスタを維持する分のコストも増えます。namespace を作成する方が手軽で安上がりです。

 にも関わらず、当社で新しい GKE クラスタを作成しているのにはいくつか理由があります。まず、同じ GKE クラスタ内で namespace だけを変えた場合、pod は同じノード上にスケジューリングされることになります。オートパイロットモードを使用しているため、細かなノード管理もできません。高負荷環境ではリソースの取り合いが発生する可能性があり、シャドウテストによって本番に影響を及ぼしてしまう可能性があります。

 また、シャドウテストと新しい GKE クラスタへの遷移をセットにすることにはメリットもあります。GKE というか k8s は頻繁にバージョンアップが行われています。通常使用しているだけでも適切なバージョンへと自動的にアップデートは行われていきますが。知らぬうちに設定が増えたり減ったりもするため、定期的な確認は必須になります。シャドウテストは動作保証テストなわけですから、GKE の新バージョンの確認にもうってつけというわけです。

相互レビュー

 シャドウテストの状況確認が終わったら、今度はアサインされたプルリクのレビューをします。現場によってレビュー専門の人がいたり、上長がレビューするルールになっている会社もあると思いますが、当社は基本的にコードは相互レビューということになっています。主たる理由はベンチャー企業であり、自社内開発だから、ということになるかと思います。自社内開発であるため、誰もが設計、実装、保守までできなくてはならない。誰かの書いたコードをいずれ自分が機能追加したり、バグ修正したりすることも出てくる。突然のパスを投げられる前にちゃんと知っておかないといけないし、他人事ではいられないのだから気になる部分はレビュー段階で修正してもらう、ということになってきます。

 できるだけ全てのコードを知っておくことが望ましい、というのは結構なハードルに思えるかもしれませんが。初学者にも優しい環境だ、とも言えるかもしれません。私はもともと組込畑の人間で、バイクのECUやぱちんこ制御を書いていた関係で、アセンブラとC、C++が主体でした。その後にPHPなども触りましたが、経歴としてはスマートポインタがないバージョンのC++が一番長い状態でした。RustやGoは趣味的に開発をしていた程度で、業務でメインに使ったことはありませんでした。

 ところが、入社後はRustのレビューや機能修正の業務が来たおかげで、既存のコードをお手本に仕事をすることができました。基本的にはテストコードで動作保証は取れているのが前提ですし、Rustは比較的読みやすい言語です。言語そのものに不慣れなところがあってもロジックや設計の部分は確認することも可能でした。当社は現状かなりRustを推しているため、Rustに触れないことは難しいですが、詳しい人やお手本となるリポジトリが多いため、初学者の方でもソフトランディングしやすい職場ではないかと思います。

 この日はYewというフロントエンドcrateのレビュー依頼があったため、まずは書き方を調べるところから仕事が始まりました。入社から数年経っても新しいことばかり、日々勉強の毎日です。人にもよると思いますが。複数のタスクがある時、私は並行して行うことが多いです。特に作業日数が具体的に読めない時は両方を頭出し程度はやっておきます。少しやってみると必要な時間がなんとなく見えてくるため、タスクの優先順位と合わせて勘案することができるからです。この日はキリのよいところまで見たら、レビューは切り上げ。続きはまた明日、ということでお昼休憩です。

午後

自動同時通訳

 当社では現在、総務省から委託を受けた自動同時通訳のお仕事があります。ざっくり言いますと、音声認識と翻訳をシームレスにつなげて、自然な形で通訳結果を提供するというサービスです。同種のサービスが世界各国、色んな会社さんから提供されているのはご存知かと思いますが。いかにして精度と速度を上げ、コストを下げるか。世界中で競争しているわけです。

 この三つのうち、精度を上げるという部分は製造元が他社のため、私には制御の難しい部分です。ただ、速度とコストについては工夫の余地があります。当社の利用している音声認識は処理を行うたびにメモリにキャッシュを貯め込みます。同じ環境の音をキャッシュするほど、その環境の音源の認識速度は向上します。コスト面でも、例えば、SPOT 設定を使用するとコストは大幅に下げられますが、単純に導入すると接続中の切断が増え、エラー率が向上します。グレースフルシャットダウンをきちんと設計し、スケールできるように整える、など設計の余地があります。

 設計の詳細については守秘義務があるため触れることはできませんが、エンジン特性とユースケースを考慮した設計、実装、デバッグなど、諸々の作業に従事して午後は終了しました。

終業

 この日は開始が早かったため、16時終了。入浴後、家族で食事を取って、フリータイム。

 当社には年1回のフジノーベル賞という試みがあります。当社の社長は「藤野真人」と言いまして、藤野さんが賞を与えるから「フジノーベル賞」。勤務時間外に当社の製品である mimi や THINKLET を利用してアプリやサービスを作った社員に、面白ければ社長が自ら自腹で褒賞を出そう、というイベントです。最近では役員や部長なども褒賞を出してくれていたりします。不定期開催ですが、私の知っている限りは毎年欠かさず開催されています。これまでは「感情認識を使った、演技判定ゲーム」や「箱型 THINKLET を使った監視カメラ」なんておもしろアプリが大賞を獲得しています。

 私はぼちぼちエントリしたりしなかったりなのですが、正式な受賞は一度もありません。なんだかんだ仕事が忙しい時期ですと、残業もあります。同時期にフジノーベル賞が被ると手が出せないということもあります。ただ、景品が年々豪華になっているのを感じているため、本腰入れてやってみようかな、と思い始めております。開催が告知されてからだと手につかないなら、事前に準備をしておくしかない。というわけで、お気に入りの VTuber の配信を流しながら夜の個人開発へ。

〆

 ということで、サンプルとして私の一日を紹介してみました。ちなみに、私は当社ではかなりの朝型。会社には午後から出社する人もいます。おかげさまで、会社のMTGは午後に設定されることが多いです。夜型の人も安心してご連絡ください。