2024-04-24

Autifyのコミュニティイベントで「Autify導入からこれまでの歩み」について登壇してきました！

QA Autify イベントレポート

こんにちは、QAチームの関井（@ysekii_）です。

今回は、3月27日に開催されたAutifyコミュニティイベントに参加・発表してきたので、そのレポートをお届けしたいと思います。

Autifyコミュニティイベントとは

オーティファイ株式会社が提供するノーコード自動テストプラットフォームのAutifyを利用している企業を対象にしたオフラインコミュニティイベントです。

昨年末にも開催されていたようで、今後も定期的に開催されるとのことでした。毎回トークテーマが変わるようですが、今回のトークテーマは、

「どのようにAutifyでテスト自動化を実現してきたか - Autify導入からこれまでの歩み -」

ということで、Autifyユーザー3社から、導入当初の目標や抱えていた課題に対してどのようにアプローチしてきたかなどをLT形式で発表されました。

タイムテーブル

19:00：イベント開始
19:00~19:10：オープニング（会場案内、イベント説明等）
19:10~19:20：ニーリー関井（LT 7~10分 Q&Aも含む）
19:20~19:30：株式会社レコチョク清崎さん（LT 7~10分 Q&Aも含む）
19:30~19:40：株式会社カインズ田村さん（LT 7~10分 Q&Aも含む）
19:40~20:30：交流会
20:30：クローズ

各社LT

トップバッターは自分に

実は、発表順は事前に伝えられておらず、当日会場に入ったタイミングで一番目の発表を言い渡されました笑（最初であれば流れを自由に作れるので、意外と楽だったりはします）

今回の発表タイトルは「Autify活用による高頻度リリースの実現」ということで、ニーリーでのAutifyの歴史を語りつつ、最終的には高頻度リリースに対して大きく貢献してもらったという内容でお話しました。

発表に10分フルに使ってしまいQ&Aの時間が残っていないかなと思ったのですが、スケジュールが前倒しで進んでいたこともあり、たくさんの質問をいただけました（司会の方に感謝！）

speakerdeck.com

株式会社レコチョク清崎さん

レコチョクの清崎さんの発表では、Autifyの利用に向いているテストと向いていないテストの整理をきちんとされているのが印象的でした。音楽や動画を扱っているサービス特有の、人の感性が求められる部分では手動でのテストが必要になるという点は納得感がありました。

株式会社カインズ田村さん

カインズ田村さんの発表では、テスト自動化の前に目的やスコープの整理をしっかりとされているのが印象的でした。当たり前のことかもしれませんが、施策の実施やツール導入の際には目的や想定される効果などを整理した上で実行することで、「やっぱり違った」みたいなことが減ると思うので、ちゃんと忘れないようにしたいですね。

また、両社に共通したこととして、スモールスタートでテスト自動化を行ったという点がありました。 Autifyを導入したタイミングではまだ私は入社していなかったため、ニーリーでの当時の状況はわかりませんが、ニーリーでも最初は担当者1人で細々とリグレッションテストの自動化を行っていたらしいので、そういう意味ではスモールスタートだったのかもしれません。成功するか失敗するか見えていない状況で、一気にテスト自動化を進めるというのはリスクも高いと思うので、スモールスタートで始めて、徐々に仲間を増やしたり、規模を大きくしていくのがいいのだろうと思います。

Autifyユーザーとの情報交換

LTのあとは交流会の時間がありました。参加されている方はみなさんAutifyユーザーなので、Autifyで困っていることなどを共有・議論したり、Autifyスタッフの方も参加されていたのでその場で要望を伝えたりと有意義に過ごすことができたと思います。

お話を伺っていると、どのくらいAutifyのシナリオを作ったらいいかという点は多くの企業が悩んでおり、ニーリーでも同様の課題感を持っています。各社状況が異なるので、一概にこのくらい作ったらいいという基準はないと思いますが、ニーリーとしてはインシデントに繋がりそうなバグは防げるくらいという基準を設定しています。これが正解かはわかりませんが、シナリオを作りすぎてもメンテナンスが大変になるため、自動テストの効果とメンテナンスコストのバランスを考えて基準を設定したらいいのではないかと考えています。

交流会の時間としては1時間弱くらいだったと思いますが、参加人数も多かったこと*1もあり、当日お話できなかった方も多くいたのが心残りでした。

参加してみての感想

コロナ禍以降、オフラインイベントが増えたこともありなかなかオフラインイベントに参加できていなかったのですが、今回久しぶりに参加してみてオフラインならではの良さを感じました。

特に、懇親会や交流会はオフラインでないと出来ないものだと思いますので、今後はつながりを作るためにも定期的にオフラインイベントに参加していきたいと思います。

*1:正確な人数は把握していませんが、30名くらいは参加されていたと思います

2024-04-16

CeleryのMessage Priorities機能を利用した処理遅延の低減

SRE Python Celery

こんにちは、SREチームの宮後(@miya10kei)です。
バイクに乗っていて気持ちが良い季節になってきましたね🌸

メッセージキューを利用した非同期タスクを扱っていて、誰しも優先度順にタスクを処理したいなと思ったことがあるのではないでしょうか？

今回はCeleryの機能を利用して実現することができたので紹介したいと思います。

Celeryってなに？

Celeryは分散メッセージキュー機能を提供するPythonベースのOSSです。
メッセージキューのBrokerとしてRedisやRabbitMQ、Amazon SQSなどを使用でき、分散環境での非同期タスクの実行を実現しています。

公式サイトを引用すると次の説明になりますね。

Celery is a simple, flexible, and reliable distributed system to process vast amounts of messages, while providing operations with the tools required to maintain such a system. It’s a task queue with focus on real-time processing, while also supporting task scheduling.
引用元：https://docs.celeryq.dev/en/stable/index.html#celery-distributed-task-queue

Celery自体はPythonで書かれていますが、他にもNode.jsやPHP向けのクライアントライブラリも提供されています。

Park DirectでのCeleryの使い方

Park Directでは非同期タスクの処理にCeleryを採用し次の構成で利用しています。

BrokerのバックエンドとしてElastiCache for Redisを使用しています。
Celery ClientとしてバックエンドのAPIとバッチからタスクを登録し、Celery Workerとして専用のECSタスクが処理をおこなう構成になっています。

課題

機能拡張とサービス成長に伴い、定期実行される処理や対象データが増加したことで短時間で大量のタスクがQueueに登録されはじめました。これにより、長い時は数時間単位でタスクが遅延してしまうこともあり事業に少なからず影響を及ぼしていました。

最初はECSタスクのオートスケーリングでスループットの改善を試みたものの、RDSの負荷を考慮するとスケールアウトにも限界があり別の対策を講じる必要がでてきました。

そこでタスクに優先度を設定する方法を検討し、CeleryのMessage Priorities機能を採用することにしました。

Message Priorities機能

それでは本題のMessage Priorities機能の話に移ります。

Celeryではタスクに対してPriorityを設定することで、処理順序を組み替える機能が提供されています。（Message Priorities機能）

この機能を利用するとPriority毎に独立したQueueが作成されます。 ClientはPriorityを指定してタスクを登録することで該当するQueueにタスクを積むことができます。WorkerはよりPriortyの高いQueueから優先してタスクを取得し処理がおこなわれるようになります。

ClientとWorkerのサンプル実装は次のようになります。

Worker

from celery import Celery

app = Celery("task", broker="redis://localhost/0")
app.conf.broker_transport_options = {
    "priority_steps": list(range(3)),  # priorityを3つに区切る設定
    "sep": ":",
    "queue_order_strategy": "priority",
}


@app.task
def hello(name: str):
    print(f"Hello ${name}")

Client

from task import hello

for i in range(10):
    hello.apply_async(kwargs={"name": "miya10kei(2)"}, priority=2)

for i in range(10):
    hello.apply_async(kwargs={"name": "miya10kei(1)"}, priority=1)

for i in range(10):
    hello.apply_async(kwargs={"name": "miya10kei(0)"}, priority=0)

これを実行すると次のような出力となりPriorityの小さいタスクが優先して処理されることが確認できます。

[2024-03-27 20:26:58,723: WARNING/ForkPoolWorker-1] Hello $miya10kei(2)
[2024-03-27 20:26:59,730: WARNING/ForkPoolWorker-1] Hello $miya10kei(2)
[2024-03-27 20:27:02,741: WARNING/ForkPoolWorker-1] Hello $miya10kei(0)
[2024-03-27 20:27:03,749: WARNING/ForkPoolWorker-1] Hello $miya10kei(0)
...
[2024-03-27 20:27:11,794: WARNING/ForkPoolWorker-1] Hello $miya10kei(0)
[2024-03-27 20:27:12,797: WARNING/ForkPoolWorker-1] Hello $miya10kei(1)
[2024-03-27 20:27:13,805: WARNING/ForkPoolWorker-1] Hello $miya10kei(1)
...
[2024-03-27 20:27:21,855: WARNING/ForkPoolWorker-1] Hello $miya10kei(1)
[2024-03-27 20:27:22,861: WARNING/ForkPoolWorker-1] Hello $miya10kei(2)
[2024-03-27 20:27:23,868: WARNING/ForkPoolWorker-1] Hello $miya10kei(2)
...
[2024-03-27 20:27:27,891: WARNING/ForkPoolWorker-1] Hello $miya10kei(2)

Park Directでの使い方

Park Directでは以下の3種類のPriorityを使用できるようにしました。

Priority	説明
High (priority=0)	緊急度の高いタスク例：問い合わせに対する返信メールを送信するタスクなど
Middle (priority=1)	High/Lowでないタスク
Low (priority=2)	短時間に大量に発生する可能性のあるタスク例：一括処理系のタスクなど

※ 現状はMiddleとLowの2種類のみを使用しており、Middleについては許容可能な遅延の範囲で運用できています。
※ Highは今後より優先して処理したいタスクが発生した場合に備えて用意しました。

また、DefaultのPriorityをpriority=1にすることでdelayメソッドでタスクを登録した場合にMiddleの優先度が設定されるようにしています。

設定方法は以下になります。

from celery import Celery

app = Celery("task", broker="redis://localhost/0")
app.conf.broker_transport_options = {
    "priority_steps": list(range(3)),
    "sep": ":",
    "queue_order_strategy": "priority",
}
app.conf.task_default_priority = 1  # Default Priorityの設定

※ Client側のタスク登録時のpriority指定はapply_asyncメソッドでのみ可能です。そのため、delayメソッドを使用している箇所の修正を最小限にしたい場合はおすすめです！

まとめ

最後にこの機能を導入した事による効果をお伝えして終わります。

導入前は数時間単位で遅延が発生することがありましたが、導入後はMiddleのタスクの遅延を数秒単位まで抑えることができ、十分に許容できるレベルまで改善されました。

Priority毎のタスクの処理件数とQueue内の滞留時間（上：Middle、下：Low）

同じ悩みを持ったことがある方は是非導入を検討してみてください！

2024-04-10

モビリティSaaSの会社って何？ニーリーで1年半長期インターン生として働いてみて【長期インターン体験記】

インターンサクセスエンジニアリング

はじめに

こんにちは！サクセスエンジニアリングチームインターンの齋藤仁です。🙇‍♂️

今回の記事は、私がニーリーでの1年半のインターンとしての就業を終えるため、インターン体験記を書かせていただきます。

自己紹介☘️

大学４年生
専攻は英語英米文学
プログラミング歴は３年弱
2022年10月にニーリー入社

インターンをすることになった経緯🚗

大学3年生の2022年夏、エンジニアとして就職活動を控えていたものの、学生同士や個人での開発でしかプログラミング経験がなく自信がなかった私は、エンジニアとして就業する経験を積みたいと思いWantedlyで会社を探す中でニーリーに初めて出会いました。

ニーリーはPark DirectというモビリティSaaSを提供する企業ですが、それまでモビリティSaaSについての知見は全く持っていませんでした。しかしその業界シェアの高さから考えられる社会的インパクトに加え、会社が拡大中で過渡期の状況であることにとても興味を惹きつけられ、CTOの三宅さんに仕事をお願いしたいと直接言われたことで、この会社で頑張りたいと思い入社を決めました。

実際の業務💻

私はインターン生としてサクセスエンジニアリングチーム（当時はEUCチームという名前でした）に配属になり、以下の業務を主に担当しました。

Amazon Connectを使用したコンタクトセンターの開発・運用📞
社内ツールの開発・運用💬
ホームページとLPの開発・運用🌐

サクセスエンジニアリングチームに関しては、弊社のnoteをご覧ください！（ぜひスキもお願いします❤️‍🔥）

note.nealle.com

Amazon Connectを使用したコンタクトセンターの開発・運用📞

インターンの中で私が一番時間をかけて、最もサクセスエンジニアリングチームで先頭に立って進めることができた業務がAmazon Connectを使用したコンタクトセンターの開発・運用でした。Amazon ConnectとはAWSが提供するクラウド型コンタクトセンターサービスで、駐車場を借りている人・貸している人からの電話を受けたり、反対にニーリーから電話をかけたりする業務を一括で担っています。

電話をかけてきた人がいくつかのステップを踏んでオペレーターにつながるまでの流れを”フロー”として管理しているのですが、そのフローの新規開発や既存フローの編集を主に担当していました。今年は架電側の業務にも多く携わり、フローの開発だけでなくBaseMachinaを利用して開発以外のメンバーも任意のタイミングで架電できるように業務の引き継ぎなどを行いました。顧客とニーリーを繋げる窓口としてサービス全体に響いてしまう箇所なので、そこでシステムに詳しい人間になって、実際にサービスを使うビジネス側の部署の方々と会話を重ねて運用ができたことはとても印象的です。

社内ツールの開発・運用💬

ビジネス側の方が使う社内ツールの開発と運用にも多く携わり、その中でも特に印象深いのはAmazon Connectで構築したコールセンターに待ち顧客が発生している場合にLambdaを用いてSlackに通知するツールの開発です。入社してまだ2ヶ月ほどでしたが、ビジネス側の方々と議論をさせてもらったり、SREチームの方にAWSのサポートをしてもらいながら開発を行いました。

現在も運用しており、自分の開発したツールが業務効率化に直接寄与できたことを、社内懇親会などで直接お話を伺った際に実感し、非常に嬉しかったです。また、チームとしてビジネス側の課題を吸い上げ、それを技術領域に捉われることなくエンジニアリングで解決していくという、サービスのグロースを地道に達成していく経験を積めてとてもよかったです。

ホームページとLPの開発・運用🌐

入社してすぐは、ホームページとLPの開発や運用に携わっていました。その中でも入社して5ヶ月ほどで、管理を委託していたコーポレートサイト(https://nealle.com/)を内製化するプロジェクトに携わったことはとても印象的な業務です。

移管の準備から委託先のエンジニアの方と会話しながら実際にサイトを移管し、さらには存在しなかったSTG環境の構築まで携わり、とても多くの経験を積むことができました。学生の開発では経験できない、社外との連携が必要で、会社全体に影響するプロジェクトで、さらに納期があるなどの条件でお仕事ができたのは貴重な経験でした。また、私主導でサイトのコンテンツ更新のシステムも変更することになり、エンジニアを介さずに広報チームが任意のタイミングでサイトを編集できるようになり業務効率化にもつながりました。

働いてみて得た、大事にしたい考え方

私がニーリーで働いて得た、大事にしたい考え方は以下の３つです。

顧客が欲しいものを作らないこと
チームでアウトプットを出すこと
一歩先・次に何が起こるか考えること

顧客が欲しいものを作らないこと🙅‍♂️

これは前述した、入って2ヶ月ほどで社内ツールを開発することになった時のことですが、私はビジネス側の方とのミーティングの時に「こんな機能が欲しくて」「Slackのここにボタンが欲しくて」という話ばかりを聞いてそれを愚直に実装しようとしていました。

そんなことを実装できるわけもなく時間ばかりが過ぎていた頃、CTOの三宅さんに「顧客が欲しいものを作らないこと」と話をいただきました。これは「顧客が欲しいものを作ること」を目的にするのではなく、「顧客の課題を解決すること」を目的にしなさいという話でした。その時に言われたのは、「顧客の欲しいものを作るのがエンジニアではなく、顧客が抱えている課題を解決するために僕らのエンジニアリングのスキルや知識を持って、一番スマートな方法で課題の解決策を提示するのがプロフェッショナルとしてのエンジニアだよ」と言われたことを強く覚えています。

その時から私は「ものづくりをする」人がエンジニアではなく、「エンジニアリングスキルを持って（スマートな解決策のためには使わなくたっていい）課題の解決をする」人がエンジニアなんだと思うようになり、これは私の根幹になる考え方になりました。

チームでアウトプットを出すこと🤝

これは私が所属するサクセスエンジニアリングチームの一員として、さらにニーリーの一員として働く中で感じたこととして、ニーリーには、常に相手にリスペクトの心を持っているけど、仕事に熱量を持っていて、言うべきことはしっかり言う。そんな方が多い気がしました。その根幹にあるのは、私たち一人一人がニーリーという会社で一丸となって事業の成長に繋がっているという意識ではないかと思いました。

チームリーダーである中村さんは、チームに対して「僕から何か言ってそれをそのまま実行したり、アサインしたタスクをそのまま何も考えずに取り組むのではなく、一緒に議論して、一緒に考えて欲しい」とよく話をしています。これが私にとってはすごくありがたく、このおかげでインターン生ながらもチームで同じ目線に立ってタスクの進め方やそもそもタスクをやる意義について意見を常に挙げ続けることができました。さらにはタスクの進め方や詰まってしまった時の相談もチームでアウトプットを出すために必要なことだと感じるようになり、その重要性を強く意識するようになりました。

一歩先・次に何が起こるか考えること🧐

これは私が仕事している中で感じていて、今でも足りないなと日々思い続けていることです。それは、「一歩先・次に何が起こるか考えること」。例えば、誰かにメッセージを送るにしても送られた相手はどう思うだろうか？そういったことを考えることです。中村さんは「相手に何かを伝えるということは、相手に何かアクションを起こしてもらいたいとき。じゃあ相手がそのアクションを迷わず起こしてくれるようにどう導けるかというものを考える必要があって、そうなると自分のアクションについて考える必要がある」という話をしていただきました。

レビューをお願いする時にも、じゃあこの人はこの後何をするだろうか？何か足りない情報があって質問してくるだろうか？という考えをいつも巡らせ、相手の立場に立って考えてみることの重要さや、コミュニケーションの取り方を改めて考える機会になりました。これは自分が作業する際にも同様で、常にタスクを分解して、何が終わっていて、終わっていなくて、次に何をする必要があるのか、そんな頭の使い方を少しづつできるようになりました。

最後に🙇‍♂️

ニーリーでは、事業の成長に繋がることをとにかくやっていました。そんな環境では、自分のやっていることや自分にできることが事業に繋がっていると思える瞬間が多くありました。とても楽しかったです。

私を採用してくれて、たくさんの学びを得ることができたこの会社には恩しかありません。ニーリーでインターンをしなければ、ニーリーで働く方々から数々の言葉をもらうことも、自分がどんなエンジニアで、どんな人間でいたいのかをここまで考えることもできなかったと思います。

またどこかで何か一緒にやりたいです。1年半もの間、大変お世話になりました。次のステージでも頑張ります💪

ニーリーのことが気になったらぜひカジュアル面談へ〜！サクセスエンジニアリングチームでぜひ事業成長をエンジニアリングで加速させていきましょう❤️‍🔥

herp.careers

2024-04-01

pull requestを利用したいい感じのECS feature環境管理方法を考えた

SRE インフラ AWS

はじめに

SREチームの大木です。スノボの季節がもう終わりかけており、さみしい限りです。

feature staging環境*( 以下 feature環境 )自体のライフサイクルや管理をどうするか問題、なかなかどこも苦労していると思いますが、その中で今回それなりにいい感じの回答を出せたと思うので共有したいと思います。

*呼び方はpre-staging環境、pull request環境、テスト環境などいろいろありそうですが、私たちはfeature環境と呼んでいます。

どこが「いい感じ」なのかというと、PRのラベル付与によって環境の生成/削除を制御できる点です。PR画面上で楽々とfeature環境の管理ができたり、PR一覧からどのブランチでfeature環境が立っているかが分かりやすくなります。

feature環境について

feature環境を当社のプロダクトであるPark Directの開発にも導入しました。各開発者の作業ブランチのコードを、そのままアプリケーションとしてインフラにデプロイすることができるアレです。

Park DirectのアプリケーションはECS serviceで動作しており、Dockerfileやタスク定義ファイルもアプリケーションのリポジトリに格納されていたので、それらをfeature環境でも使用することにしました。

作成はGitHub ActionsをトリガーとしてCloudFormationを用いて行い、作成されるリソースとしてはECS task定義、ECS serviceのほか、ALB target group ( ALB 自体は共有 ) 、その他リソース(後述)があります。

独自ドメインも払い出されるため、そのドメインを使用して他の開発者や非エンジニアもスムーズに確認と検証ができるようになります。

また、通常ではdevelopのDBにそのまま繋いでいるのですが、ECSタスク定義をよしなに書き換えることにより、別のDBに接続することも可能です。

環境の作成方法

この辺が工夫したポイントです。

feature環境はpull request単位で立ち上げる必要がありますが、全てのpull requestで等しく環境が欲しいわけでもなく、またpr自体は長期間オープンにされ続けることもあるので、pull requestのライフサイクルとfeature環境を一緒にするのは難しいものがありました。

そこで、pull requestのラベル付与/剥奪をトリガーにfeature環境作成/削除を行うことにしました。冒頭でも触れたとおり、PR画面上で管理ができるのが嬉しいポイントです。

また、feature環境はFargate Spotを採用することによりコスト圧縮も行っています。

しかし、長時間処理の検証で使いたいなど、サービスの停止が許容できない環境もあるので、付与するラベルによりFargate or Fargate Spotどちらを使用するのか選べるようになっています。

ラベルを付与することで環境が立ち上がる。-ha を付与すると通常のFargateで起動

GitHub Actionsを使用している場合に限りますが、feature環境をpull request のラベルで管理するのは操作もしやすくカスタマイズ性も高いのでオススメです。

また、21時に定期的にfeature環境用ラベルを削除する処理も実装し、feature環境の立ち上げっぱなしを防止しています。

技術的なお話

feature環境の1単位としては以下を作成する必要があります。

独自ドメイン用のRoute53 record
ALB target group
ECS各種 ( ECS service, ECS task definition)
CloudWatch Event rule

ALB自体はfeature環境用を1台用意し、そのALBのリスナールール上でhost名を確認することによってどのfeature環境へアクセスするかを振り分けています。これにより、1本のALBで複数のfeature環境を管理することができます。

(優先度の重複が認められないので、pull request 番号を使用しています。pull request単位で立ち上がるので重複の心配がなく幸せです)

実際の構築の流れは以下の感じです。

pull requestにラベルが付与される
ラベルの追加 ( or ラベルが追加されたprにpushがあった時) をトリガーでGitHub Actions workflowが発火
ALB listener ruleのpriorityなどの動的な値をパラメータとして、CloudFormation stack作成

作成時のworkflow job発火条件はこんな感じ

    if: >

      (github.event.label.name == '[feature] backend' && github.event.action == 'labeled')

      ||

      (github.event.label.name == '[feature] backend-ha' && github.event.action == 'labeled')

      ||

      (

        (

          contains(github.event.pull_request.labels.*.name, '[feature] backend') 

          || contains(github.event.pull_request.labels.*.name, '[feature] backend-ha')

        )

        && github.event.action == 'synchronize'

      )

CloudFormation stack名をブランチ名とすることで、どのブランチの環境なのかが明確だったり、更新や削除の際にもブランチ名からCloudFormation stackを引っ張ってくれば良いので幸せです。

  delete_resources:

    name: Delete resources

    runs-on: ubuntu-22.04

    if: >

      (

        (github.event.label.name == '[feature] backend' || github.event.label.name == '[feature] backend-ha' )

        && github.event.action == 'unlabeled'

      )

      || (

        github.event.action == 'closed' 

          && (

            contains(github.event.pull_request.labels.*.name, '[feature] backend') 

            || contains(github.event.pull_request.labels.*.name, '[feature] backend-ha')

          )

      )

    permissions:

      contents: read

      id-token: write

    timeout-minutes: 5

    steps:

      - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4.0.0 commit hash

      - name: Configure AWS Credentials

        uses: aws-actions/configure-aws-credentials@8c3f20df09ac63af7b3ae3d7c91f105f857d8497 # v4.0.0 commit hash

        with:

          role-to-assume: ${{ env.AWS_ASSUME_ROLE }}

          aws-region: ${{ env.AWS_REGION }}

      - uses: ./.github/actions/set-env-variables

      - name: delete stacks

        run:

          aws cloudformation delete-stack --stack-name "pd-backend-feat-${{env.task_id}}"

このように、『各環境とCloudFormation stackが1:1で紐づいて管理ができる』ところがGitHub Actions上で動的に環境を作成/削除する際にとても親和性がよかったです。

また、CloudFormationを使用することによりECS関連以外のリソースも作成することができます。アプリケーションの都合上本来であれば1 feature環境につき1 Lambda を用意しなければいけない仕様でした。各環境固有の値はEventで渡せるようにコードを直した feature環境用 lambda を用意し、CloudFormation でEventBridge ruleを作成することで実現しました。このように ECS 以外のリソースも柔軟に作成することができるのは amazon-ecs-deploy-task-definition や ecspresso などにはない利点なのかなと思います。

終わりに

当時は弊社の他の場所でCloudFormationを使用したことがなかったので採用は迷ったのですが、feature環境の構築というごく一部で、且つ管理対象リソースも少ないことから得られるメリットの方が大きいと判断し採用しました。結果としては、CloudFormation template自体はほとんど変更されることもなく ( = CloudFormationのメンテナンスコストを払うことなく ) 、恩恵だけを得ることができているので採用してよかったです。また、ラベルでの管理も「このブランチの環境は立っているのかどうか」がすぐ分かり、また簡単に管理ができるのでとても使用感が良いです。

想像以上に使用されたのでfeature環境のコスト削減に取り組む必要があり、夜間停止を導入することになったのですが、その際も「n時以降自動でラベルを剥奪」という workflow を組むことで簡単に対応することができました。 feature環境を管理するにあたって「pull requestのラベルをトリガーとした環境の操作」だったり「CloudFormationを用いた環境の管理」を選択したことでだいぶ幸せになれました。おすすめです。

そして、9月ぐらいからfeature環境を導入したのですが、9月から12月までの数ヶ月間で実に200近くのfeature環境が使用されていました。確実な需要を元に環境を整備しましたが、実際にこうやって使用されているのは嬉しい限りです。

2024-03-26

ニーリーのテックブログを始めました！

組織・文化

こんにちは、株式会社ニーリーでプラットフォームグループのマネージャーをしている菊地(@_tinoji)です。

この度、ニーリーでテックブログを始めることにしました。記念すべき1本目の記事ということで、今後の投稿のハードルを下げるという大義名分のもと、テックブログを始めるまでの思い出話でも書いてみようと思います。

ニーリーって？

いきなり知らない会社の昔話を始められるのもアレだと思うので、簡単に会社の紹介をさせてください。

ニーリーは2013年に創業され、インキュベーション事業を始め様々な事業を展開したのち、2019年にPark Direct(パークダイレクト)という月極駐車場SaaSをローンチします。これが今の我々の主力プロダクトになっています。

賃貸住宅を検索できるようなサービスと似たUIですが、「契約までオンラインで完結」できるというのが推しポイントです。通常2週間程度かかると言われている月極駐車場の契約が平均2日で完了します。僕も最近知ったのですが、最速で24分という記録があるらしいです。

「駐車場」と聞くと一見地味に聞こえてしまうと思いますが、我々がターゲットとする月極駐車場は約3,000万台あると言われており、市場規模としては約3兆円にも登る巨大なマーケットです。2023年にはシリーズAの資金調達が完了して累計調達額は58億円となりました。

さらに、駐車場を起点として様々なビジネスの展開を見据えており、その大きな一歩として2023年10月にEV充電サービスを提供開始しました。 prtimes.jp

EV充電のみならず、駐車場や車両のデータを活用して「モビリティプラットフォーム」を構築すべく新規事業の可能性を模索しています。どうでしょうエンジニアの皆さん、「日本で最も駐車場データを保有する会社になる」と聞くとワクワクしてきませんか？

一見地味に聞こえる駐車場ビジネスがいかに可能性に満ちた領域なのかについては、以下のnote記事に詳しく書いてあるのでぜひ一度読んでみてほしいです。 note.nealle.com

ニーリーのエンジニア組織

前置きが長くなってしまうのですが、ニーリーのエンジニア組織も個人的にかなりユニークだと思うのですこしだけ紹介させてください。

なにがユニークかというと「スタートアップっぽくない」ことだと思っています。
スタートアップという温度の高い業界にいながら、どこか冷静で自分たちを客観視している。開発をするときも決してノリで作らず、まず課題を正しく把握して必要十分な設計を考える。そんな人たちが集まっています。

自分もそんなところに惹かれて入社を決めたのですが、後々「投資家の方からもスタートアップっぽくないって言われるよ」とCEOから聞きました。エンジニア組織だけでなく会社全体の文化として根付いてるということだと思います。

ここまで根付いたカルチャーなのでそれっぽいキーワードとして決めてみようということで、今では「熱量と冷静さの共存」と呼んでいます。これ以外にも2つキーワードが生まれました。

残り2つも含めてCTOがnote記事を書いているので、こちらもぜひ読んでみてください。 note.nealle.com

テックブログどころじゃない期

さて、自分はPark Directがリリースされてから2年後の2021年11月にニーリーに入社したのですが、当時はまだエンジニアの社員は2人で、当然テックブログのテの字も出るような状況ではありませんでした。

翌年新しくできたSREチームに所属し、バックエンドのインフラをAWS Elastic BeanstalkからAmazon ECSへリプレイスする比較的大きなプロジェクトを実施したのですが、色んなことにハマり、様々な工夫を行う中で「こういうのブログに書けたら、多少なりとも誰かのためになりますよねー」という会話を何度もしたことを覚えています。

その瞬間は、手が空いたらQiitaに書きましょう！と盛り上がったりするのですが、忙しいのでなかなか手を付けられず、「まぁどこまで業務のことを公開していいか分からないしな・・・」と心の中で言い訳をして、いつの間にか何を書こうとしていたかも忘れていきます。

知名度に悩んだ期

時を同じくして、エンジニア組織を拡大すべく採用を積極的に行っていたんですが、一番困ったことはそもそも候補者の方に会ってもらえないことでした。採用媒体でスカウトを打ってもカジュアル面談に結びつかない、そんな日々が続き、よくCTOの三宅さんに愚痴ってました。

note.nealle.com

菊地くんは口癖のように「知名度がないだけで、話す機会さえあればいい会社だと思ってくれるんすよ！」と言っています（笑）。

まずはCompany Deckでしょ期

知名度がないのはその通りな一方で、仮に興味を持っていただきニーリーについてググってくれたとしてもエンジニア関連の情報が何も出てこない、というのは致命的な課題でした。

さすがに何か作ろうという話になり、テックブログも候補には挙がったのですが、まだ継続する組織的な体力が全然なかったですし、なにより第一はCompany Deckでしょという結論になりました。採用ページのトップからご覧いただけます。 jobs.nealle.com

Company Deckだけではなく、利用技術などが分かるエンジニア向けの資料も必要だよねということで、エンジニア向けのRecruiting Deckも作りました。(Recruiting Deckという名前は僕しか使っておらず、社内では開発Deckと呼ばれています(笑))

noteで手応え感じた期

これで多少なりともどんな会社なのか、エンジニア組織がどんな体制でどんな言語を使っているのか、ぐらいは分かるようになったのですが、さすがにスライド数枚でカルチャーを伝えられているとは感じられず、長めの文章を公開したくなってきました。

よし今こそテックブログ！・・・とはならず、ちょうど会社全体で開始していたnoteにエンジニアも寄稿していくことになりました。

note.nealle.com

入社エントリをはじめ、チーム紹介、事例紹介 etc... といった内容で、高頻度とは言えませんが毎月コンスタントに記事を出し続けています。

特に2023年の年末にはかなり高い目標を設定し、カルチャーを伝えるための気合の入った記事を6本公開しました。たった6本ではありますが、エンジニアだけでなく広報、CTO、CHROと多段でレビューを行い質を高めようとしたため、本当に本当に大変なプロジェクトでした。

JIRAのチケットだけではスケジュールが把握できなくなり、スプシで管理してました

そこまで労力をかけただけあり、初めて明確な反響が得られました。Xで有名な方がポストしてくれたり、はてブのホッテントリ入りしたり、なんと「note読んでカジュ面応募しました！」という方まで現れました。広報のメンバーがXで記事がシェアされる度にSlackに投稿して、みんなでうおおお！とか言って盛り上がっていました。モメンタムってやつですね(適当)

今ならテックブログやれるでしょ期

「これができたなら何でもできる気がしてきた」と言っていますが、まさにこれが「今ならテックブログやれるかも」と感じたときでした。おそらくそれを見越して、年末にはすでにCTOがテックブログ開設に向けて動いていました。↑の年末の挨拶をした同じ日にテックブログ検討のミーティングが入っていました(笑)

副業でエンジニア採用のサポートをしてくれていた僕の知り合いが媒体選定などを主導してくれて、1月には概ねはてなブログで運営する方針が決まりました。 2月に会社全体で大きな体制変更があったのもあり、1ヶ月ほど怠けてしまったのですが、今こうやって開設することができました。正直少し感動しています。

社会の解像度を上げる

これはニーリーが会社として掲げているミッションです。

めまぐるしく変化していく世の中で

正確に問題を捉え、

たくさんの選択肢から最適な答えを見つける。

テクノロジーを通じて、

数多の選択肢が見える社会を実現する。

どこかの誰かが最適な答えを見つけるための選択肢。そんなテックブログにしたいと思います。お楽しみに。

Autifyコミュニティイベントとは

タイムテーブル

各社LT

トップバッターは自分に

株式会社レコチョク 清崎さん

株式会社カインズ 田村さん

Autifyユーザーとの情報交換

参加してみての感想

Celeryってなに？

Park DirectでのCeleryの使い方

課題

Message Priorities機能

Park Directでの使い方

まとめ

はじめに

自己紹介☘️

インターンをすることになった経緯🚗

実際の業務💻

Amazon Connectを使用したコンタクトセンターの開発・運用📞

社内ツールの開発・運用💬

ホームページとLPの開発・運用🌐

働いてみて得た、大事にしたい考え方

顧客が欲しいものを作らないこと🙅‍♂️

チームでアウトプットを出すこと🤝

一歩先・次に何が起こるか考えること🧐

最後に🙇‍♂️

はじめに

feature環境について

環境の作成方法

技術的なお話

終わりに

ニーリーって？

ニーリーのエンジニア組織

テックブログどころじゃない期

知名度に悩んだ期

まずはCompany Deckでしょ期

noteで手応え感じた期

今ならテックブログやれるでしょ期

社会の解像度を上げる

株式会社レコチョク清崎さん

株式会社カインズ田村さん