PHP8.1アップデートまでの道のり

こんにちは。コネヒトでバックエンドエンジニアをしております@homiTakahashiです。

今回は私たちの使用している言語PHPの8.1バージョンまでアップデートについて話していけたらと思います。

前提として私たちのアップデートしたいプロジェクトは以下のような環境です。

• PHP7.4
• フレームワークはCakePHP4.2
• dockerを使用
• BaseImageはalpine

そこでPHP8.1にする上でCakePHP4.2→4.3にバージョンを上げないといけないことが分かり段階を踏むように以下のように進めました。

作業手順

1. DockerImageを変更する

PHPのバージョンを指定し、dockerでコンテナが安定して起動するようにエラー文を読みながら対応していきます。alpineのバージョンは古いとPHP8.1に対応していないのでバージョンを上げる必要がありました。

FROM alpine:3.16
︙
RUN apk add --update-cache --no-cache \
    php81 \
    php81-dev~=8.1 \
︙

主に以下のようなミドルウェアのアップデートが必要になってくると思われます。

redis-3.1.1 \ → redis-5.3.6 \

2. テストコードからエラーや非推奨を対応していく

弊社はテストコードを導入していたため、CIなどで一旦全てのテストを回し一つずつエラーや非推奨を潰していきました。

例1)

PHPUnit\Framework\Exception: This test uses TestCase::prophesize(), but phpspec/prophecy is not installed. Please run "composer require --dev phpspec/prophecy".

prophesize はPHPUnit 10 でビルトインではなくなるため、ライブラリに phpspec/prophecy-phpunit を追加し、利用箇所で明示的にTraitを呼び出すように修正しました

composer require --dev phpspec/prophecy

※PHP8.1の非推奨はこちら

例2)

Deprecated Error: Return type of Frlnc\Slack\Http\SlackResponse::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice

外部ライブラリのfrlnc/php-slack を利用してSlack連携を行っていたのですが、frlnc/php-slack ではPHP8.1対応が行われていなかったので、ForkされているレポジトリをGitHub上で検索し、対応しているレポジトリを利用するように composer.json の記述を変更しました。

"repositories": [
      {
        "name":"frlnc/php-slack",
        "type":"vcs",
        "url": "https://github.com/deqngeorgiev/php-slack"
      }
    ],
"require": {
        "frlnc/php-slack": "dev-master",
}

3. 外部サービス周りの動作確認をする

テストコードでは拾いきれないSentryやPapertrailなどの外部サービスは手動で動作確認をしました。

4. リリースをする

リリースをしていく上で、弊社では影響範囲を少なくするようにカナリアリリースを使用しました。カナリアリリースとは、全ユーザーにいきなりリリースするのではなく1%~30%くらいまで様子を見ながら徐々にリリースしていく方法です。

このような手順をPHP8.0、CakePHP4.3、PHP8.1と3度繰り返しアップデート作業を行いました。

感想

大変だったこととしてはバージョンのアップデートをしてテストを回した際、かなりの量の非推奨エラーが出ていたことです。 それらを一つ一つ調査→修正→レビューを繰り返し行うとかなりの作業量になります。私たちチームは以下のように工夫することによって結果としてスムーズに取り組めたのかなと思っております。

• いきなりバージョンを8.1にするのではなくスコープを分けて小さく行う
• 非推奨対応はチームで分担して取り掛かる

またテストコードがあることで対応箇所が可視化できるので、テストコードの重要性も改めて気付きました。

次のステップとしてはPHP8.1の新機能を取り入れ、PHP8.2にアップデートしていきたいと思っております！！

関連記事

tech.connehito.com

tech.connehito.com

コネヒトでは一緒に働く仲間を募集しています！ そして興味持っていただけた方は気軽にご連絡ください！ https://www.wantedly.com/companies/connehito/projects

コネヒト株式会社は PHPerKaigi 2023 にシルバースポンサーとして参加しました！スポンサーブース準備と当日の様子をご紹介します！

こんにちは！@TOC です。

コネヒトはPHPerKaigi 2023にシルバースポンサーとして協賛しました。

PHPerKaigi はオフライン開催ということで弊社も久しぶりにスポンサーブース出しました。 本ブログではスポンサーブースの準備と当日の様子について、@TOC, @ryo がご紹介しようと思います！

---

目次

---

PHPerKaigi とは

PHPerKaigi 2023 は2023年3月23日（木）〜3月25日（土）に開催されたイベントで、弊社はシルバースポンサーとして協賛させていただきました。

スポンサー紹介ページ

スポンサーブースを出して盛り上げよう！

最近はオフラインでの技術イベントも増えてきて、実際に足を運ぶと活気あるな〜って気持ちになりますね🙌

今回 PHPerKaigi もオフラインで行うということでスポンサーブースを出すことにチャレンジすることになりました。

Slack でのやりとり

とはいえ久しぶりのスポンサーブースということでどういう企画にするのがいいのか、をまずは話し合うことになりました。

案を出してみる

まずはみんなで案を出してみようということで、有志で集まった人たちで案だしをしました。

案出しした時の付箋

出した案の中から投票を行い、主に下記３つに票が集まりました。

1. 自社のプロダクトを知ってもらうためにママリドリルを解いてもらう
2. 自動テストどのくらいやってるか聞く
3. PHP のバージョンを聞く

PHP のバージョンは他のブースと被りそうだよね、といった会話もあり、自社プロダクトを知ってもらう企画を押し出す方向性をまずは考えてみました。

ママリドリルって何？

今回自社のプロダクトであるママリを知ってもらう企画としてママリドリルを提案しました。

ママリドリルは弊社のオンボーディングで使われており、ママリの「温かい」コミュニティを作るためのちょっとした仕掛けをクイズ形式で解いてもらい、自社のプロダクトの理解を深める取り組みです。

僕はこのママリドリルがすごい好きで、「ママリももちろんだけど、この取り組みをもっと知ってもらいたい！」という気持ちでいたので、採用されてワクワクでした。

やるならママリ色を全面に出そうと、めちゃめちゃ可愛いスライドを作って臨みました。

ママリドリル

肝心の中身は…また別の場所でもママリドリルを使ってママリを知ってもらう機会を作ろうと思うので、その時のお楽しみに…！

普段のシステム開発についても聞いてみた

ママリドリルだけだと一人一人のコミュニケーションは濃くできるけど、答える側のハードルも高いよね、と思ったので、ライトに答えることができる下記2つのアンケートも用意しました。

• どんなテストを書いてますか？
• どんなエラー監視をしていますか？

アンケート

このように厚くコミュニケーションが取れるコンテンツとライトに答えられるコンテンツの２パターンを用意する設計にしました。

より楽しく取り組むために

せっかく回答してくれたのに「ありがとうございました」だけで終わったらなんか寂しいので、コンテンツに参加してもらうとノベルティのチロルチョコをもらえるようにしました。

今回4種類のチロルチョコを用意していたので、

• ちょっと時間がかかるママリドリルを答えたら3個
• ライトに答えられるアンケートは1個

→どっちも答えると全種類制覇できます！

という流れを作ってどっちのコンテンツも楽しく取り組めるような形にしてみました。

（ただ、今回の反省点は全種類同じ味になってしまったことで少しがっかりさせてしまったところですね…次回はいろんな味を用意したい！）

ノベルティのママリちゃんチロルチョコ

改めて本物を当日見たら「いや、これは全部欲しいでしょ！」って気持ちになりました⤴️

こんな感じで準備を進めていて、絶対良いコンテンツができた！っていう気持ちと、実際楽しんでくれるのかな…っていう不安を抱えながら当日を迎えました。

当日はどんな感じだったか

当日は練馬の会場に9時に集合しスポンサーブースの設営をしていきました。コネヒトは机の後ろにコネヒト横断幕を置かせていただき目立ちまくってたような気がします笑。

準備完了！

周りのスポンサーの方達も設営の準備を進めていて久々のオフライン開催に熱気が高まっていくのを感じました…！！

PHPerKaigi が始まってからはたくさんの PHPer の方々がコネヒトのブースに来ていただき、ママリドリルやシステム開発のアンケートに答えていただきチロルチョコがどんどんはけていきました！

そして気になるアンケート結果はこちら！！

アンケート結果

監視もテストも日常的に行っている企業さんが多く印象的でした。

参加していただいた皆さんにはママリドリルを解いた後にママリのプロダクトやその工夫について話したり、他にもPHPの話や普段の開発の事について沢山コミュニケーションが取れて非常に有意義な時間となりました。

中には弊社のテックブログが参考になった、というお声もいただき、とても嬉しい限りでした。

参加していただいた皆様ありがとうございました！！

コネヒトの参加メンバーもブースの案内をしつつ、気になる登壇やLTに出向いて知識やノウハウを吸収させていただきました！

PHPerKaigiを終えて

ブース出展のノウハウがあまり無い中での手探りでの出展でしたが、参加していただいた PHPer の方達に楽しんでいただき大満足の1日でした!

これからも技術コミュニティへの貢献をしていき、盛り上げていきたいと思います！

PHPerKaigi 終了後にパシャリ！

GitHub ActionsからマニュアルトリガーでBitriseを動かす方法

はじめに

コネヒトでiOSエンジニアをやっているYoshitakaです。

先日、iOSアプリ開発のCI/CD環境を改善するため、これまで一部ローカルから実行していたfastlaneの処理をGitHub ActionsをトリガーにしてBitrise上で実行するように対応したので、一部内容を紹介したいと思います。

改善したこと

ママリのiOSアプリ開発では主にBitrise, fastlane（一部GitHub Actions）を使ってCI/CD環境を構築しております。

Bitrise(fastlane)で実行しているワークフローは以下の通りです。

• Testの実行
• App Distributionへの配布
• App Store Connectへのデプロイ
• Developer Accountへのデバイス追加

今回の改善ではこれまでローカルで実行していたデバイス追加のワークフローをGitHub ActionsでトリガーしてBitrise上で実行するように対応しました。

この対応によりローカル実行ではApple IDの認証で2FA認証を使っていましたが、Bitrise経由で実行することで推奨されているApp Store Connect API keyを使った認証に切り替えることができました。

やったこと

改善前はfastlaneをローカルから直接実行し対話型でデバイス名とUDIDを入力してデバイス追加をしていました。

  desc "Add test device and update provisioning profile"
  lane :add_device do
    name = UI.ask('Name of device:')
    udid = UI.ask('UDID of device:')
    register_devices(devices: {name => udid})

    match(type: "development", readonly: false, force: true)
  end

↓

これを GitHub Actions → Bitrise → fastlane と実行するようにします。

GitHub Actions → fastlane としても動くのですが、 App Store Connect API keyの情報は現状Bitriseでのみ使っており、一元化管理したいため今回はBitrise上で動かすようにしています。

GitHub Actions

GitHub Actionsのトリガー部分は、workflow_dispatchのinputsを設定することでデバイス名とUDIDを入力できるようにします。

こちらがGitHub ActionsからBitriseをマニュアルトリガーするworkflowです。

on:
  workflow_dispatch:
    inputs:
      device_name:
        description: input device name
        required: true
        type: string
      device_udid:
        description: input device udid
        required: true
        type: string

jobs:
  add_device:
    runs-on: ubuntu-latest
    steps:
    - name: Trigger Bitrise workflow
      env:
        bitrise_api_key: ${{ secrets.BITRISE_API_TOKEN }}
        bitrise_app_slug: "abc0123456789"
      run: |
        curl -H "Authorization: $bitrise_api_key" https://api.bitrise.io/v0.1/apps/$bitrise_app_slug/builds -d \
        '{
          "build_params":{
            "environments":[ 
                {
                    "mapped_to":"DEVICE_NAME",
                    "value":"${{ inputs.device_name }}", 
                    "is_expand":false
                }, 
                {
                    "mapped_to":"DEVICE_UDID",
                    "value":"${{ inputs.device_udid }}", 
                    "is_expand":false
                 }
            ],
            "workflow_id":"add_device"
          },
          "hook_info":{
            "type":"bitrise"
          }
        }'

BitriseのworkflowをGitHub ActionsからトリガーするためBitrise APIを使います。

devcenter.bitrise.io

手順は以下の通り

• Bitrise API Keyを発行してGitHubのSecretsに保存
• bitrise_api_key、bitrise_app_slug、workflow_idをcurlコマンドに追加
• inputsで入力した値はBitrise側で使えるようenvironmentsに追加

bitrise_app_slugはBitriseの対象のAPPページのURLで確認できます。 /app/abc0123456789 ← app/から後の値

Bitrise API KeyはBitriseのProfile Settings→Security→Create tokenから発行できます。

workflow_idはbitrise.ymlに定義したworkflow名になります。

デバイス名とUDIDをBitrise側に渡してfastlaneで使う方法は、公式ドキュメントを参考にしました。

Bitrise

BitriseではFastfileに定義したデバイス追加のlane(add_device)を実行、結果をslack通知しています。

slack通知の細かい設定方法は公式ドキュメントを確認しても見つからずでしたが、 inputsの値を指定することでconfigが変わり通知内容をカスタマイズできました。configの値はBitriseのLogを見ることで確認できます。

  add_device:
    meta:
      bitrise.io:
        stack: osx-xcode-14.2.x-ventura
    steps:
    - activate-ssh-key@4:
        run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}'
    - git-clone@6: {}
    - cache-pull@2: {}
    - fastlane@2:
        title: fastlane add_device
        inputs:
        - lane: ios add_device
    - slack@3:
        title: Slack Notification
        is_always_run: true
        inputs:
        - webhook_url: $SLACK_WEBHOOK_URL
        - title: "Add Device"
        - message: "デバイスを追加しました"
        - message_on_error: "デバイス追加に失敗しました"
    description: fastlane add_device_via_github_actionsを実行するワークフロー

fastlane

GitHub Actionsで入力したデバイス名とUDIDはENV["DEVICE_NAME"],ENV["DEVICE_UDID"]とすることで取得できました。

  desc "Add test device and update provisioning profile"
  lane :add_device do
    app_store_connect_api_key(
      key_id: ENV["ASC_KEY_ID"],
      issuer_id: ENV["ASC_ISSUER_ID"],
      key_content: ENV["ASC_KEY_CONTENT"],
      in_house: false
    )
    register_devices(devices: {ENV["DEVICE_NAME"] => ENV["DEVICE_UDID"]})

    match(type: "development", force_for_new_devices: true)
  end

認証はApp Store Connect API keyで行うためapp_store_connect_api_keyを使います。

今回は既存でapp_store_connect_api_keyを使っていたので対応してませんが、 新しく追加する場合はApp Store ConsoleからAPI Keyを発行してBitrise側のSecretsに保存しておく必要があります。

保存した値はENV["ASC_KEY_ID"],ENV["ASC_ISSUER_ID"], ENV["ASC_KEY_CONTENT"]のような形で取得できるのでこれをfastlaneのapp_store_connect_api_keyに渡してあげることでAPI Keyでの認証が可能になります。

デバイスの追加はfastlaneのregister_devicesにデバイス名とUDIDを渡してあげることで実現できます。

またデバイス追加後のプロファイルの更新ではmatch(type: "development", force_for_new_devices: true)とオプションを追加することで不要な更新をしないようにしました。

docs.fastlane.tools

まとめ

今回は元々あったワークフローのトリガー部分を変更しただけの改善でしたが、Bitriseやfastlaneのドキュメントを読むと他にできることがたくさんあるようなので、引き続き開発業務と並行してCI/CD環境の改善にも力を入れていきたいと思います！

参考

docs.github.com

devcenter.bitrise.io

ママリ iOSアプリの2023年3月現在の開発環境

2023年3月現在のママリのiOSアプリは開発環境について紹介します。

言語

100% Swiftで、以前はObjective-Cのコードもありましたが、全てSwiftに書き換えました。

iOSのサポート範囲

iOS14以上としています。4/10以降は14.5以上に変更予定です。（iOS14.0~14.4でSwiftUIの挙動の違いがあるためサポート範囲外としました）

使っている主なフレームワークやライブラリ

主に以下のフレームワークやライブラリを利用しています。

• UIKit, SwiftUI
• RxSwift, Combine
• Realm
• Firebase

以前はUIKitとRxSwiftを使っていましたが、新しい画面についてはSwiftUIとCombineを使用する方針で開発しています。ただし、SwiftUIで実装する際に特殊な方法が必要であれば、新たな負債を作らないためにUIKitで実装する方針です。

アプリ内でデータ永続化のためにRealmを利用していますが、ママリは基本的にWeb APIから情報を取得して表示することがメインであり、Realmは軽量な利用に留めています。

Firebaseは、分析、ABテスト、クラッシュ検知など多様な用途で使用しています。

アーキテクチャ

RxSwiftが主となっているため、MVVMになっています。 SwiftUI導入時にTCAも検討しましたが、特定のFrameworkに強い依存をしたくなかったのもあり、一旦見送っています。ただし、今後課題が出てきた場合は再考していく予定です。

Model部分を別モジュールとして切り分けています。これについて詳しくはこちらのブログをご覧ください。 tech.connehito.com

ツール

swift-formatやSwiftLintが開発中に自動で実行されるようにしています。

Renovateをつかってライブラリを定期的にアップデートする仕組みを導入しています。

iOSエンジニアの数は2名で、project fileでコンフリクトすることはあまりないためXcodeGenは導入していません。

デザイナーとのデザインのやりとりはFigmaをつかっています。

テスト

Quick/Nimbleを使ってユニットテストを書いています。

全てにテストを書いているわけではなく、APIの通信周りは必須、ViewModelやModelは推奨としています。

テスト時の依存性注入のためにDIのライブラリは導入していませんが、必要な箇所ではinitializerで注入しています。

CI/CD

CI/CDの実行環境としてはBitriseとGitHub Actionsを使っています。 Macでの実行が必要なケースはBitriseを使い、それ以外はGitHub Actionsを使うといった使い分けをしています。

テストの実行、AppDistributionでのアプリの配布、テスト端末の登録、App Storeへのアプリのアップロード、リリースノートの生成といったことを自動化しています。

今年度やった技術的改善

ママリの開発業務をやるだけでなく、技術的な改善にも一定の時間を使うようにしています。今年度は主に以下のようなことをやりました。

• Objective-Cのコードの撲滅
• Swift Concurrency導入
• 脱Rosetta2
• モジュール分割

技術的な改善の今後

今注力している技術的な改善はAPIKitの置き換えとAPI通信周りをRxSwift/CombineからSwift Concurrencyへの置き換えです。

その後やりたいこととしては、Swift Package Managerの導入や画面の一部をSwiftUIへのリプレース、起動周りのコードの改善などがあります。

最後に

コネヒトではママリの機能開発をしながらも技術的な改善を進める時間も一定確保しこのような改善を進めています。

コネヒトでの開発に興味を持っていただいた方はカジュアルにお話しましょう〜
TwitterのDMなどでも大丈夫ですので@yanamura_までお気軽にどうぞ
日本中の家族をITの力で笑顔にしたい、iOSエンジニア募集！ - コネヒト株式会社のモバイルエンジニアの採用 - Wantedly

コネヒトはPHPerKaigi 2023にシルバースポンサーとして協賛します！

こんにちは！高谷です。今回は弊社が協賛するPHPに関するイベントを紹介します。

PHPerKaigi 2023に協賛いたします

コネヒトではメインプロダクトである「ママリ」を始めとして開発のメイン言語としてPHPを活用しており、フレームワークとしてはCakePHPを採用しています（その他、技術スタックを知りたい場合はこちらをご覧ください）

その縁もあり、この度 PHPerKaigi 2023 にシルバースポンサーとして協賛させていただくこととなりました！

イベント概要

• 日時 2023年3月23日（木）〜3月25日（土）
• 場所 練馬区立区民・産業プラザ Coconeriホール および ニコニコ生放送
• 主催 PHPerKaigi 2023 実行委員会
• 公式HP https://phperkaigi.jp/2023/
• タイムテーブル https://fortee.jp/phperkaigi-2023/timetable

公式サイトからの引用になりますが、PHPerKaigiは

（ペチパーカイギ）は、PHPer、つまり、現在PHPを使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。 今年の開催はオフライン会場を軸としたオフライン・オンラインハイブリッド開催です。みなさんのご都合に合う参加方法をお選び頂けます。

となっており、いろんな方が楽しめる間口の広いPHPのイベントになっていそうです！今回ははじめてのハイブリッド開催なので、都合がつく方は両方で参加して楽しむこともできそうですね！

発表内容やタイムスケジュールを知りたい方はこちらをご覧ください！

タイムテーブル | PHPerKaigi 2023 #phperkaigi - fortee.jp

また、最新情報はTwitterで告知されるので PHPerKaigi 公式Twitterも要チェックです！

@phperkaigi

ブースも出します！

今年はコネヒトは企業ブースも出します！ 企画としては

1. あなたは何問正解できる!? ママリドリル

2. システム開発・運用に関するアンケート

を予定しております！ ママリドリルやアンケートにお答えいただくとノベルティのチロルチョコがもらえます！ 可愛いチロルチョコになっているので、ぜひぜひご参加ください🙌

場所は会場内の研修室2で開催しております。

チケット購入

こちらからチケット購入できますのでよければぜひ！

www.eventbrite.com

最後に

ここまで読んでくださった皆様、ありがとうございました。 そして、 PHPerチャレンジ中の皆様、お目当てのPHPerトークンはこちらです！

#connehito-techvision

それでは！

コネヒトではPHPerを積極採用中です！ご興味がある方は気軽にご連絡ください！

www.wantedly.com

ママリ抽選会の裏側 〜CakePHPで排他処理を使って実装してみた〜

こんにちは。ママリアプリ開発チームでエンジニアをしております高橋です。

今日は3月1日よりリリースされているママリ抽選会の実装についてお話ししていきます。

ママリ抽選会とは

ママリ抽選会

ママリポイントを使用して参加できる抽選会のことです。

ママリポイントとはアプリ内で回答をしたり、ベストアンサーをもらったりすると付与されるポイントのことです。ただ現状でポイントを使用する用途があまりなく、ユーザーからのたくさんのお声とコネヒトとしてポイントを活用してユーザーに感謝の気持ちを伝えたいという背景から今回の「ママリ抽選会」プロジェクトがスタートしました。

テーブル設計

まずは簡単にテーブル設計を説明します。

以下は今回新規で作成した抽選会に関わるデータベースのER図です。

抽選会データベースER図

前提として開催期間に対して賞品それぞれに最大在庫があります。

在庫管理をするだけなら履歴テーブルは必要なく商品テーブルの最大在庫数を減らしていくという方法もあります。

ですが以下の懸念点を考えて最大在庫は固定でデータベースに保存するようにしました。

• 本来の最大在庫がわからなくなる
• 抽選会の参加履歴画面などが仕様が出てきた時に対応できなくなる

テーブル設計についてはそこまで複雑なことはないので本題の内部の実装についてお話しして行きます。

排他処理

排他処理とは簡単に説明すると「ダブルブッキングしないように制御すること」です。

前提として履歴を登録する前に次の抽選処理が始めると残在庫に誤差が生まれてしまうので順番に抽選する必要があります。 そこで排他処理を利用して正しく処理できるようにしました。

今回はテーブル全体ではなく行に対してロックをかけて実現しました。

SQLでは排他処理はこのように書きます。idが1のデータのみ行ロックされています。

select *
from table_name
where id = 1
for update; // 行ロック

CakePHPでは以下のように書くことができます。念の為キャッシュ削除をすると安心です。

$table->find()
    ->modifier('SQL_NO_CACHE')
    ->epilog('FOR UPDATE')
    ->first(); // 行ロック

実装の流れは以下のようになっています。

$user = $this->ユーザーテーブル->get($id);
try {
    $connection->begin();　// トランザクション開始
    $lottery = $this->抽選会テーブル->find('active')
                　　　　->contain(['賞品テーブル'])
                　　　　->modifier('SQL_NO_CACHE')
                　　　　->epilog('FOR UPDATE')　// 行ロック
                　　　　　->first();
    // 参加資格があるかバリデーションをする
    // 抽選をする
    $connection->commit(); // トランザクション終了
} catch (Exception $e) {
    $connection->rollback();
    throw new InternalErrorException($e->getMessage());
}

よくある排他処理は複数のユーザーが同じデータを更新できないように制御していくイメージですが、今回に関しては抽選処理自体を止めたいので1番最初の抽選会テーブルのデータを取得するところでを制御する必要があります。

トランザクションを開始した後にselect文にfor updateを指定すると行ロックが発生し、この間は順番待ち状態になります。

トランザクション終了と共に解放され順番待ちしていた処理が開始する仕組みです。

これでどんなにリクエストが集中しても安全に順番に処理できます。

最後に

私は入社後大きな新機能実装は初めてだったので、テーブル設計、API設計、API実装、テストコード、レビューを一貫してやることができてとてもいい学びになりました。

設計をしていく上で難しいのが変更のしやすさだったり、どれだけ先を見通すかはすごく悩むポイントでした。

またチーム開発をしていく上で実装に入る前にモデリングだったり、設計の認識を合わせるということが大切だなと思いました。

色々大変なことはありましたが、新機能をリリースできたことはとても嬉しく思います。自分の中ではかなり大きな経験だったので次に活かしていきたいです！

【秘話】ママリ抽選会のリリース🎉までにデザイナーがやってきたこと↓

note.com

コネヒトでは一緒に働く仲間を募集しています！ そして興味持っていただけた方は気軽にご連絡ください！ https://www.wantedly.com/companies/connehito/projects

カオナビさんと合同LT勉強会を開催しました！

こんにちは。2017年11月にAndroidエンジニアとしてjoinした@katsutomuです。

2023/2/16に株式会社カオナビの皆様と、オフラインの合同LT勉強会を開催しました！

経緯

昨年、コネヒト主催の勉強会に遊びにきてくれた、カオナビの富所さんに「所属してるエンジニアに刺激のあるイベントをやりたい」とお声がけして開催に至りました。

• 登壇をして、その場でFBや反応をもらえること
• 改まった場ではわからない、社外のリアルな声を聞くこと

この２つを刺激としてインプットし、成長につなげる場を作ることを目指し、まずはクローズドに交流&LT会を実施することになりました。*1

イベントの内容&趣旨

何度かカオナビさんと打ち合わせをさせていただき、以下の内容となりました。

1. 全員自己紹介タイム
2. 懇親会
3. LT大会

当日の進行はカオナビさんにお任せして、弊社としては非常に助かりました。ありがとうございます！

会場

今回は、カオナビさんのオフィスに遊びに行かせてもらいました。 東京タワーが見える素敵なイベントスペースで、心地よく交流とLTの時間を過ごせました！

交流会

エンジニア業務のお話だけでなく、採用の取り組みであったり、組織カルチャーの話など、社内のコミュニティだけでは得られない、貴重な話ができました。

LT枠

当日の飛び入りも含め、合計8名の発表が行われ、大いに盛り上がりました。

発表内容も、エンジニアリングな内容や、プロジェクト管理のツールの話や、インディー開発など多岐に渡り、どの発表からも刺激をもらいました。

実施後のアンケート

実施後に、参加した弊社メンバーにアンケートを実施しました。 結果として狙っていた、登壇でその場でFBや反応をもらう、 改まった場では得られない社外のリアルな声を聞くという点は、叶えられたかと思っています

アンケート結果

今回のイベントに期待してたこと（抜粋）

• 他社のエンジニアと接点を持つ
• 社外のエンジニアとの交流。社外LTの雰囲気が把握できる。
• 自分でLTを発表すること
• 社外にいるエンジニアの人とざっくばらんに技術的な話を楽しくしたい

定量評価

具体的なお声（抜粋）

• 時間があれば飛び込みでもLTできる雰囲気がいいなと思いました。
• 色々なテーマのLTがあって面白かった反面、テーマを絞ったLTもいいなーと思いました
• 久々にリアルでエンジニアと話せたし、境遇似た人との会話は自分も楽しく周りも楽しんでいたように見えたのでよかった
• クローズドな交流会だと色々とぶっちゃけた話ができるのがとても良かったです。

まとめ

クローズドなイベント開催がひさびさなこともあり、盛り上がるか心配していましたが、大盛況で終えることができました。関わってくれたみなさんのお陰です。本当にありがとうございます！

オンライン勉強会が主流になり失われていた、リアルな交流ができたと思っています。特にエンジニアになって2~3年の若手メンバーだと、経験する機会が少ない文化だと思いますが、得られることも多いので、今後も継続して開催していきたいと思います。興味のある方は、ぜひお声がけください！

*1:コネヒトにはインプットとアウトプットを支援する制度があります：https://tech-vision.connehito.com/program/smile.html