見出し画像

【MIIDAS Tech LIVE #5】を開催しました

こんにちはミイダス Tech Officeです。
ミイダス株式会社のテックチームが直近で開発した機能を現場のエンジニアから共有する「MIIDAS Tech LIVE
第5回目の開催となる今回は2つのリリース情報をお届けしました。

採用マッチングサービス「ミイダス」は、独自の診断ツールで採用のミスマッチを減らす中途採用サービスです。メインの採用関連の機能に加え、診断や研修、組織サーベイの支援金の検索機能など、幅広い機能開発が行われています。

本記事ではそのイベントの内容を書き起こし記事としてご紹介させていただきます。ミイダスの最新開発情報をぜひご覧ください。


永留:皆さんこんにちは。始めさせていただきます。本日はご参加いただきまして誠にありがとうございます。司会を務めますミイダス株式会社の開発部テックオフィスの永留です。よろしくお願いします。MIIDAS Tech LIVEと銘打つこちらのイベントでは、MIIDAS Techチームが直近で開発した機能や情報について、現場のエンジニアから紹介を行う内容となっています。年に4回の開催を予定しており、実は昨年の3月が第1回で今回が第5回ということで、無事に1年間やってこれて、今2年目に入っている段階です。引き続き、皆さんのご興味のある情報をご提供できればと思っていますので、今回もどうぞよろしくお願いいたします。

Opening

永留:早速ですが、オープニングに入らせていただきます。まず、私たちミイダス株式会社のご紹介を少しさせていただければと思います。独自の診断ツールを用いて採用のミスマッチを減らす中途採用サービス、ミイダスの企画・運営をしています。コンピテンシー診断やバイアス診断ゲームといった診断ツールを活用して、転職ユーザー向けにはより自分にフィットした適切なオファーを、企業向けには診断結果を基にしたフィッティング人材分析というものにより、自社でより活躍しやすいハイパフォーマーの採用を可能にするツールとしてご提供しております。

サービスのローンチからは7年ほど経過しており、現在会社全体は600名ぐらいの規模感で、そのうち開発部と呼ばれる会社組織は95名ぐらいです。サービスのユーザーは現在100万人ほどで、企業様に関しては42万社ほどにご利用をいただいております。
もちろん採用マッチングの機能を主軸としてはいるんですが、組織サーベイの機能や採用以外の機能開発にも積極的に取り組んでいるような状態です。この3館クラブに関してのご説明をさせていただきます。ミイダスのテックチームが直近で開発した機能を現場のエンジニアから共有をさせていただくという内容です。
ドメインの採用関連の機能に加えて、診断や研修、組織サーベイ、例えば支援金の検索機能など、幅広い機能開発に関してお伝えします。本イベントが目的としては、私たちの取り組みを定期的に発信していくことで、皆さんにミイダスをより深く知ってもらい、もしその中でミイダスの開発に興味を持ってくださる方がいらっしゃれば、ぜひ何らかの形でご縁をいただければなと思っております。イベントの最後には採用に関するお知らせをもう少しさせていただければと思います。

続いてミイダスの主な技術スタックに関して簡単にご説明をさせていただきます。フロントエンドに関してはJavaScriptとTypeScriptで、フレームワークに関してはReactとNext.jsで、状態管理に関してはReduxを使用しています。バックエンドに関してはGoで開発を行っています。その他は細かくなってしまいますので詳細は省きますが、ご覧の技術を使用しています。
続いてミイダスの開発組織の体制に関して少しご紹介をさせていただきますと、まずミイダスの開発は大きく4つのグループに分けられます。1つ目がプロダクト開発グループです。ここがこのミイダスというサービスの開発をするグループで、大半のエンジニアの8割ぐらいのメンバーはここに所属をしています。
次に運用グループはミイダスの運用品質レポートやKPIレポート、検証や監視を対応しています。そして3つ目が開発人事グループで、みんなの開発者を専任で採用を行ったり、技術広報評価や制度設計などを担っています。
最後が開発システムグループで、PCやネットワークツールの管理などを行うのに加えて、社内のセールスチームが使う営業支援のシステム開発も行っています。それではメインとなるプロダクト開発グループの中身に関して、もう少しご説明をさせていただきますと、ミイダスの開発は大きく採用関連の機能開発を行うチーム、それ以外の採用以外の機能開発を行うチームで、最後に機能を問わずプロダクト全体の保守をやるチームで、大きくこの3つに分かれます。

さらにその中で開発機能の単位ごとにチームが組閣されているというようなイメージです。採用以外の機能というところを少し補足させていただくと、例えば組織に調査を行うサーベイの機能や、企業が申請できる支援金や助成金を検索できる機能、育成や研修などの機能も一部ございます。これらがいわゆる採用以外と呼ばれる部分に当たる機能です。
以上が大まかなミイダスの開発組織の体制のご説明です。それでは、早速本日の発表に移っていきたいと思います。まず1つ目、既存サービスに画像アップロード機能を追加した次のリアルの話という内容で、先ほどお伝えしたミイダスの開発を行う中でも採用に関連する機能開発をするチームからKobayashiさんとOtaさんに発表をいただきます。それでは早速お願いしたいと思います。よろしくお願いします。

既存サービスに画像アップロード機能を追加した時のリアルな話

Kobayashi:よろしくお願いします。自己紹介から始めます。Kobayashiと申します。先程永留さんからお話があったリクルーティングチームのフロントエンジニアとして仕事をしています。経歴としては、受託開発や自社開発でバックエンド、フロントエンドを幅広く経験し、ミイダスに参加しました。好きな技術はFlutterやサーバーレスです。

今日のセッションでは、リクルーティングチームで担当したプロジェクトの話を、同じチームのOtaさんと二人で発表させていただきます。続いてOtaさんの自己紹介をお願いします。

Ota:Otaと申します。バックエンドを担当しています。以前はWebRTCというビデオチャットが流行り始めた時にそのサービスを立ち上げた経緯があります。その後、フリーランスになり、ミイダスのプロジェクトに参画しました。最近、千葉に引っ越しましたが、引っ越し直前に渋谷で美味しいコーヒーを見つけてしまい、毎月一回、片道2時間かけてコーヒーを飲みながら技術書を読んでいます。自己紹介は以上です。

Kobayashi:今回お話するのは画像アップロード機能についてですが、技術的なお話をする前に、簡単にプロジェクトの概要をご説明できればと思います。プロジェクトの背景として、ミイダスではマッチング項目が豊富で良いマッチングはできていましたが、求人情報に画像を掲載できていなかったという課題がありました。そこで、求職者が興味の有無や自分に合うかどうかをより行いやすい状態にして、求人への応募数の向上を目指し本プロジェクトが始まりました。
簡単に機能の概要を画面イメージで説明します。左側が企業側の採用担当者の画面で、画像を普通にアップロードして掲載する前に、SNSでよくあるような画像投稿のUIでズームしたりトリミング設定をして編集した状態で掲載ができるような機能になっています。また、1度アップロードした画像は使いまわせるようにトリミング前の画像も保持する仕様になっています。企業側で設定すると、右側の求職者画面のように求人情報に画像が掲載されるようになります。

次にミイダスの実際の開発の雰囲気を知っていただけたらと思います。開発期間は約2か月程度で、去年の10月ごろに企画とエンジニアで仕様を議論し、その後、テックリードと設計をしました。11月ごろに開発が本格的に進められ、画像アップロードのコア部分の開発は2週間程度でしたが、ミイダス自体が大きなサービスなので、付随する処理の実装に追加で開発がかかりました。リリース前には1週間程度テストチームの方とチェックして、年末にリリースされました。
開発体制は、バックエンド2名でデータベース設計や画像の取り扱いに関わる設計を行い、求人情報のデータ移行、API実装、バッチ作成などを担当しました。フロントエンドも2名で、画面に関わる開発全般を担当しました。デザインは求職者側と企業側それぞれ1名が担当しました。企画職の方が3名おり、競合のニーズ調査やプロダクトについての意思決定を担当されています。
リリース後の効果として、求人への応募率が前月比20%増加しました。他の改善施策も行っていたためその影響も含んでおり、完全に分離はできていない状態ですが、ポジティブな効果が出たと考えています。
ここからは既存サービスに画像アップロード機能を追加した際のリアルな話をできればと思います。技術的に尖った内容はそれほどありませんが、画像アップロード機能を1から作る機会はそう多くないと思いますので、総合的な内容を今回お話しできればと思います。
バックエンドがメインになるので、ここからはOtaさんとプロジェクトを振り返りながらお話させていただけたらと思いますので、Otaさんよろしくお願いします。初めに、画像処理のライブラリの選定について、どうやって決めていったかや、考慮したポイントがあれば教えていただけますか?

Ota:先ほど冒頭で技術スタックの話がありましたが、バックエンドはGoで実装されています。Goで画像処理をする際のライブラリ選定についてご紹介したいと思います。これはバックエンドを二人で担当しており、もう一人がまとめたものを基にしています。実際には13個のライブラリを比較しましたが、今回は見やすくするために5件に絞って話を進めます。表の左側には私たちが検討した項目が書かれており、ライブラリごとに情報を並べて比較検討しました。その中で、GitHubでこのライブラリにどのようなIssueがあり、エラーで深刻な問題が多いライブラリは避けたいといった確認をしました。また、セキュリティの脆弱性の情報も確認しました。そして、機能として、リサイズとクロップの処理が十分に含まれているものを選択しました。

多機能なライブラリであるImageMagickは外部ライブラリが必要ですが、私たちの場合はインフラチームがサーバーの管理を行っているので、それも考慮しながら確認しました。他社事例も確認し、意外な盲点がないかを見ていきました。最終的には、標準のimageパッケージとgolang.org/x/image/draw という拡張パッケージを組み合わせて実現することになりました。まとめると、GitHubのIssueを参照しながら、パッケージの信頼性や安定性も確認し、要件を満たすかどうかを検討しました。また、画像処理に必要なライブラリや外部ライブラリが必要な点も考慮しながら、他社事例を参考に進めていきました。

Kobayashi:ありがとうございます。ライブラリ選定はなかなか難しいところがありますね。次のトピックとして、写真を扱うときEXIFという写真のメタデータの対応も必要になると思います。バックエンドでのその辺りの話を教えていただけますか。

Ota:先ほどお伝えしたimageパッケージという標準のライブラリではEXIFは読み落としてしまうため、別途EXIFを扱うライブラリを使いました。こちらは名前通りEXIFをシンプルに対応しているもので、非常にわかりやすくて扱いやすいです。Goを使っている方にお薦めできると思います。テストをするときには、私たちチームで開発しているので、テストデータを共有できると非常に便利です。recurser/exif-orientation-examples リポジトリが非常に便利だったので、そのサンプルデータを使わせていただきました。

Kobayashi:回転には様々なパターンがあり、このサンプルデータは非常に助かりました。また、画像をアップロードして保存する先のストレージについても教えていただけますか?

Ota:私たちのサービスはAWSを使って提供されています。AWSにはいくつかのストレージサービスがあり、EFSも候補に上がりましたが、S3を選択しました。これはCDNの設定が容易ためです。S3にはSDKを経由してアクセスしていて、速度はEFSほど速いわけではありませんが、必要十分だったのでS3を選んだという形になっています。

Kobayashi:ありがとうございます。続いて、次のトピックはセキュリティ上の考慮についてです。ファイルをアップロードするということになるので、セキュリティ観点が重要です。OWASPという団体が出しているチートシートがありますので、一般的な話で言うと、少なくともそれを押さえていれば基本的に問題ないと思います。ミイダスでもこのチートシートに書いてあるような観点でレビューされています。

ローカル開発環境も一般的な開発の場面では考慮しておくと良いポイントだと思います。ミイダスでは各個人の開発端末でこのサービスを動かすためのローカル開発環境がありますが、LocalStackを採用しているので、大きな問題は今回は特にありませんでした。AWSなどのインフラに依存する場合は、ローカル開発環境をどうするかという観点も必要になってくると思います。
画像のアップロード機能で非同期的な処理が行われたり、複数システムが連携しているため、全体を俯瞰するのが少し難しくなります。Otaさん、そういった課題に対してチームでの開発にあたって考慮したことを教えていただけますか?

Ota:ミイダス内では、このプロジェクトに限らずエンジニア向けのドキュメントを社内整備しています。画像アップロードのプロジェクトに関しても、テーブル設計やAPIのインタフェースの仕様、バッジが非同期で動く時の条件など、全体像を眺めるためのシーケンス図を整備しました。これは基本的に開発時に網羅するためですが、その後の保守時に他のエンジニアが理解しやすいようにするために役立ちました。特にシーケンス図は非常に役に立ちました。

Kobayashi:一応ちょっと補足なんですけれども、ミイダスとしては開発スピードを重視していて、SIerレベルのようなきちんとしたドキュメントではないですが、社内Wikiにエンジニア同士が分かるレベルの情報を書いています。簡単なドキュメントですが、実装時や他のエンジニアに説明する時に役立ちました。ありがとうございました。時間になりましたので、その他のトピックにご興味のある方がいらしたらQ&Aなどでご質問をいただけたらと思います。以上になります。

永留:続いてプロダクト長チームの取り組みについての発表をさせていただきます。そもそもこのチームは何をしているのか、というところも発表の中に含まれていますので、早速進めたいと思います。それではYaoさん、よろしくお願いします。

プロダクト長チームの取り組みに関して

Yao:プロダクトチームの取り組みについて、Yaoから発表させていただきます。まず、自己紹介ですが、私はプロダクト長チームに所属しており、フロントエンドエンジニア兼開発管理を担当しています。ミイダスは2社目で、前職では10名程度のWEB制作会社で働き、スケジュール管理、ワイヤーフレーム作成、見積書や請求書の作成など様々な業務を経験し、同時にフロントエンド開発の経験を積みました。

ミイダスにジョインしてからは、フロントエンドの開発経験をより専門的に積み重ね、前職の経験を活かして施策の進行管理とフォローを担当しています。また、最近は子供と一緒にポケモンカードゲームに夢中で、一緒にデッキを作って楽しんでいます。
プロダクト長チームについてお話しします。現在、メンバーは3名で活動しており、全員がフロントエンドやバックエンドの業務を兼務しながらプロダクト長業務をこなしています。私は最近、実装はほとんど行っていませんが、フロントエンドの実装レビューに参加したり、プロダクト業務をメインに担当しています。
プロダクト長チームのミッションは、サービスとして最適な成果を出せるように開発計画を立て、各所からの施策を調整し、効率的に推進することです。言い換えると、新規開発や改善施策の受付窓口となり、施策が効率的にリリースできるように調整しています。具体的な業務内容については後ほど詳細に説明しますが、施策リストを運用して各施策の管理や開発着手までの進行、着手後のフォローを行い、組織全体の開発効率を向上させるための仕組み作りやプロセス改善を行っています。

プロダクト長という呼び名についてですが、これは施策の企画や予算管理を行うわけではなく、プロジェクトマネージャーやディレクターとは異なるため、適切な呼び名を模索した結果、プロダクト長チームという名前に落ち着きました。ミイダス内では、これを省略してP長と呼んでいます。

具体的な役割についてですが、この図を見ての通りではあるんですけど、プロダクト長は各チームの企画と開発の間に立ち、様々な調整管理を行っています。
企画から施策の依頼を受けたら着手順の整理や施策管理シートへの追加を行います。その後、開発に着手する前にリソース調整や施策の仕様チェック、他の施策との衝突がないかなどを確認します。
仕様チェックは、プロダクト長チーム内で施策のワイヤーフレームや資料を確認し、実際にシステムに組み込める内容か、仕様として曖昧な点がないかをチェックする作業です。不明点や改善点があれば、企画チームにフィードバックし、必要に応じて仕様を再検討してもらいます。これが完了したら、Redmineにチケットを作成し、各チームに開発着手の依頼を出します。
着手依頼を出す際は、ただ依頼を出すだけでなく、必要に応じてキックオフを設定し、施策の意図や内容を説明してもらい、企画と開発が認識を合わせた状態で着手できるようにします。これにより、企画と開発間の認識齟齬を防げています。

次に、施策リストについて紹介します。プロダクト長ではスプレッドシートで作られた施策リストを使用しており、各チームの施策を管理しています。このリストは各チームごとにレーンを分けて管理されており、どのチームが何の施策を開発しているか、これから着手する施策が何かが一目でわかるようになっています。各施策には、ステータス、着手順、ワイヤーフレームや資料へのリンク、企画担当者とのやり取りが行われているSlackへのリンク、プロダクトへの影響箇所などが記載されています。また、Redmineのチケット更新があるたびにBotがSlackに通知する仕組みを取り入れており、なるべくリアルタイムに更新できるよう通知を受け取ったらすぐにリストに反映しています。

完了した施策については、シートの下部の方に完了レーンを用意しており、これまでリリースした施策も後から見返せるようにしつつ、基本的には現在動いている施策を見やすいように整理しています。また、頻度はそんなに多くはないですが、開発組織の体制変更などがあった場合は、それに合わせて施策リストの項目やフォーマットの見直しも実施しています。

最後になりますが、プロダクトチームで取り組んでいる課題改善の取り組みについても簡単に紹介させていただきます。プロダクト長では施策の管理だけでなく、開発プロセスで課題がありそうなところの改善にも取り組んでいます。今回、具体的に取り組んだ例として、P長スタンプの導入と運用を紹介させていただきます。
基本的に施策の着手前に他施策との衝突がないか、また手戻りが発生しないように仕様チェックをしてから開発着手するようにしているので、特にトラブルなどが発生せずにリリースまでいけることがほとんどです。しかし、中には開発中に何かしらの原因でリリース遅延が発生したり、仕様の見直しが発生して開発がストップしたりとトラブルが発生することがあります。
たくさんの施策が同時に動いているため、トラブルが発生すること自体は一定仕方がないと思いますが、そういった開発進行に関する重要なやり取りがプロダクト長の方に共有されずに対応が後手に回ってしまうケースがありました。そこで、この課題改善のためにP長スタンプという仕組みを導入しました。
P長スタンプとはSlackのカスタムスタンプで、リリース遅延や急な仕様変更など、開発進行に影響が出そうな決定や状況をSlack上で見かけたら、スタンプを押してもらうことで、プロジェクト長に通知が入り、すぐに検知できるようになる仕組みです。
このスタンプは誰でも押すことができ、ちょっとでも気になったら、一応プロダクト長に知らせておく程度の温度感で使ってもらっています。これを導入してから、施策の進行に影響が出そうな情報を素早くキャッチできるようになり、必要に応じてリソースの追加や調整を入れてリリース延期を回避するなど、早めに進行のフォローを入れられるようになり、その結果、効率よくリリースが行えるようになったと思います。
ちょっと簡単ではありましたが、プロダクトチームの取り組みについて発表させていただきました。今後も様々な新機能開発や改修が効率よくリリースできるように取り組んでいきたいと思います。ありがとうございました。

MIIDAS NEWS

本日の発表は以上となります。最後に「MIIDAS NEWS」として、直近であった開発部のニュースを6つご紹介し、クロージングに入ります。今日はこれら6つのニュースを紹介させていただきます。

まず1点目です。働く人ファーストアワード授賞式を開催しました。働く人ファーストアワードとは、多様な働き方や働く人の声を聞き、改善に努めることを第一にする企業を募り、その取り組みを紹介し、表彰することを目的としてミイダスと朝日新聞社が共同で開催しているアワードです。
昨年の8月から11月半ばまで募集期間中にエントリーされた企業から、2次選考のインタビューを経て、最終選考に残った審査員の審査を経て各賞を決定しました。ゴールド表彰を3社が受賞し、続いてシルバー7社、ブロンズ20社が選ばれ、働く人ファーストを推進する企業としてホワイトの43社が決定しました。授賞式では、ゴールドシルバーの受賞企業を招き、主催アワードの審査員によって働く人ファーストな取り組みを称え、プレゼンターとしてチョコレートプラネットさんに10社の表彰を行いました。受賞企業の取り組みを紹介したページがあるので、興味のある方はぜひご覧ください。

続いて2点目、t_wadaさんをお招きして社内勉強会を開催しました。今年の2月2日に和田さんを招いて開発部の社内勉強会を行い、質とスピードをテーマにしてミイダスの開発部とその他部署から93名が参加しました。当日のレポート記事があるので、内容に興味のある方はぜひご覧ください。定期的に外部の方を招いて勉強会を実施し、学びの機会を増やしていくための制度を充実させていきたいと考えています。

3点目は、読書会制度の開始についてです。先ほどの和田さんの勉強会で多くの書籍が紹介されたことも影響して、学びを支援する制度の一つとして読書会を実施しています。会社が負担し、9名がこの制度で読書会に参加しています。書籍のインプットとアウトプットをチーム内で行い、最終的には開発部全体にシェアするといった内容です。これも学習機会を増やしていく制度の一つとして始めたものです。

4点目、技術書典の第16回にゴールドスポンサーとして参加が決定しました。ミイダスは毎年ゴールドスポンサーとして参加しており、昨年は初めてオフラインでブース出展し、書籍を頒布しました。写真は昨年の様子ですが、今年もサイエンスチームが執筆した書籍を無料で頒布する予定です。オフラインイベントは5月26日に開催され、書籍の電子版も無料でダウンロードできるようになります。興味のある方はぜひ会場にお越しいただき、紙の本をプレゼントできればと思います。

続いて、Go Conference 2024にゴールドスポンサーとして参加が決定いたしました。技術書典と同じくGo Conferenceにも毎年参加をさせていただいておりますが、昨年度と2023年に関してはスポンサープランの抽選で、シルバースポンサーでの参加でしたが、今年は見事当選を果たし、ゴールドスポンサーとして参加させていただけることになりました。
今年はオフラインでの開催もされますので、スポンサーブースの出展とスポンサーセッションという形で20分のセッションの登壇も予定しております。オフライン会場でのイベント開催は6月8日月曜日となっております。ご都合がつく方はぜひご参加いただければと思います。

前回の12月のMIIDAS Tech LIVEのイベントから今回まで、以下5つの記事がリリースされております。まずは、リモートHQ様の導入事例記事でミイダスをご紹介いただきました。開発部ではリモートHQと呼ばれるフルリモートをやるにあたって必要な備品を会社負担でレンタルできるようなサービスを福利厚生として導入しております。

次に、VPoE小林のインタビュー記事が公開されました。大切なのは形にこだわらないこと、ミイダスの進化を支える内製開発組織の新たな挑戦ということで、ミイダスの記事ではなくミイダスを取り上げていただいた外部記事のご紹介になっております。外部のメディア様に小林のインタビュー記事が公開されていますので、ご興味ある方はぜひご覧いただければと思います。

3つ目は、長期的な視点で挑むアーキテクチャの再設計と最適化への挑戦というもので、社内で進んでいるM2プロジェクトというものがありまして、中身はアーキテクチャの再設計と最適化という内容です。この内容に関してCTO磯崎と宮本の2名にインタビューを行っておりますので、こちらもぜひご覧ください。

4つ目は、ミイダス社内勉強会レポートです。t-wadaさんに質とスピードというタイトルで社内講演をしていただいたイベントのレポート記事となっております。こちらもぜひご覧ください。

最後に、セキュリティのスキル知識を競う大会、セキュリティCTFでミイダスが2連覇を達成しました。ミイダスは、パーソルグループの一員として、パーソルホールディングス主催のセキュリティCTFというイベントに参加しました。昨年度私たちミイダス株式会社のインフラチームの酒井が優勝しました。今年も開催されて、そちらで2年連続を果たしたという内容です。イベント自体が何かというところから、実際の中身まで細かく、主催者の方と今回優勝した酒井の2名にインタビューをしていますので、こちらもぜひご覧いただければと思います。

次に、現在募集している採用ポジションについてお知らせします。正社員でバックエンドエンジニア、フロントエンドエンジニア、システム運用チームのリーダーポジションを募集しています。業務委託では、バックエンドエンジニアとフロントエンドエンジニアも募集中です。今回の発表を聞いてミイダスに少し興味がわいた方や、話を聞いてみたい方は採用ページからご連絡いただければと思います。
以上で、第5回ミイダステックライブを終了いたします。お越しいただいた皆様、誠にありがとうございました。次回は6月に開催を予定しておりますので、皆様の再度のご参加を心よりお待ちしております。本日はご参加いただき、ありがとうございました。

ミイダス Techについて

ミイダスでは、定期的に技術イベントを開催しています。connpassやYouTubeチャンネルでミイダスのメンバーになった方には、最新の開催情報やアーカイブの公開情報が届きますのでぜひご登録をお願いいたします。
イベントページ:https://miidas-tech.connpass.com/
Twitter:https://twitter.com/miidas_tech

この記事が参加している募集

イベントレポ

この記事が気に入ったらサポートをしてみませんか?