こんにちは！新卒1年目エンジニアのShiromaruです！ 入社から半年が経ち、本配属から3か月が経ちました。開発チームの一員として様々な業務に取り組む中で、技術的な「 ハードスキル 」はもちろん、それ以上に「 ソフトスキル 」の重要性を痛感しています。 今回は、私が実際に経験した失敗や学びから、プロジェクトを成功に導くために特に大切だと感じた4つのソフトスキルと具体的な実践でのポイントを紹介します！ 1. 手戻りを減らすためのコミュニケーション 開発を進める中で、設計の段階で詰めきれていなかった部分や、仕様が変更になった際の曖昧な部分は必ず出てきます。実際に、私はチームで認識を揃えないまま実装を進めてしまった結果、レビューの際に手戻りが発生し、予定より工数がかかり、開発を遅らせてしまうことがありました。 これを防ぐには、 早い段階で疑問点を解消し、チームで認識を合わせる ことが大切だと感じました。 実践する際のポイント : 疑問に思った時点で相談する : 実装が進めば進むほど、差し戻しによってかかるコストは増大してしまいます。少しでも疑問点が浮かんだ時点で、自己判断せずに早い段階でチームに相談することで、手戻りを未然に防ぐことができます。 スケルトンコードを用いる : 複雑な処理や設計の判断が必要な場合は、まずクラス構造を先に実装して、スケルトンコードをチームに共有します。スケルトンコードの実装により、具体的な処理の中身を作る前にフィードバックをもらえ、手戻りを大幅に削減できます。 2. スケジュールを正確に伝える 私は、配属のメインタスク以外にもサブタスクを抱えており、サブタスクにかかる時間を意識せず、チームに開発完了日を伝えてしまいました。結果、サブタスクに予想以上に時間がかかり、メインタスクの開発に遅れが発生してしまいました。 これを防ぐために、タスクにかかる「純粋な開発時間」だけでなく、 ミーティングやサブタスクにかかる時間も考慮してスケジュールを伝える ことが、チームからの信頼にもつながることを学びました。 実践する際のポイント : 1日の有効な作業時間を把握する : 勤務時間すべてが開発に使えるわけではありません。ミーティングや問い合わせ対応、サブタスクなどにどれほど時間がかかるのかをまず自分で把握し、作業に当てられる時間を見積ります。 すべてのタスクを洗い出す : メインタスクだけではなく、サブタスクにも工数が割かれてしまったので、どんなタスクが発生しているのか、やるべきことを具体的にリストアップをしておくと、スケジュールを正確に整理することができます。 3. プロジェクトを俯瞰して先回りのコミュニケーション 開発は一人で行うものではなく、チーム、時には他部署のメンバーと連携する必要があります。私は、連携すべきメンバーを把握しきれておらず、テストの依頼をテスト開始の直前に行ってしまい、先輩に無理なスケジュールでの依頼をしてしまいました。 この経験から、 プロジェクトの全体像を見通して事前に確認し、共有する力 が必要だと感じました。 実践する際のポイント : 業務に関係するメンバーを洗い出す : そのタスクに、誰が関わるのか、どんな確認が必要なのかを事前に洗い出します。 早めに相談する : 他メンバーが関わることがわかった時点で、関わるメンバーに、「〇〇の件で、来週までに××が必要になりそうなので、準備は可能でしょうか？」と、早めに声をかけ、事前共有すると依頼されたメンバーも余裕を持って対応することができます。 4. 徹底した振り返り 自分の担当案件に関して、工数の見積もり、実装するだけで終わりにしてしまっては、次の案件に活かすことができません。なぜを分析し、次に活かすための振り返りを行うことで、工数見積もりはもちろん業務の精度を高めることができます。 実践する際のポイント : 見積もりと実績の差異を数値化する : 見積もり時間と実際にかかった時間を比較し、どれくらいの差があったのかをパーセンテージで把握します。 差異の原因を深掘りする : 「なぜ見積もりと差が生まれたのか？」を、「調査が足りなかった」「他タスクに時間を取られた」といった具体的な原因にまで掘り下げます。 対策を立てる : 原因に対する具体的な対策を立て、次回の見積もりに反映します。 まとめ これらのソフトスキルは、日々の業務の中で意識し、実践と振り返りを繰り返すことで、着実に向上させることができると感じています。 技術的なスキル（ハードスキル）はもちろん大切ですが、それらを最大限に活かすためには、今回紹介したようなソフトスキルが不可欠だと学んだので、 これからも、これらの様々なスキルを磨き続けながら、より良いエンジニアを目指していきます！ The post 新卒1年目が本配属で学んだ「エンジニアとして大切だと考えるソフトスキル」 first appeared on Wedding Park CREATORS Blog .

こんにちは。TECH戦略室・SREエンジニアのヒエイです。 6月28日に行われたPHPカンファレンス2025で登壇をしてきました！ https://phpcon.php.gr.jp/2025/ そしてウエディングパークはゴールドスポンサーとしてブースを設置してきました。 当日の会場の様子をレポートしたいと思います！ 会場・ブースの様子 当日東京は34度近くに上がり日差しも強く、会場の熱気もあってとにかく暑く熱い1日でした。 スポンサーブース設置のために一足早く会場にIN。ブーススタッフメンバーと一緒に準備を開始しました。 #phpcon #phpcon2025 pic.twitter.com/rPLLamX77k — チャン (@zosokh) June 28, 2025 完成したブースがこちら。 本日はPHPカンファレンス！ ウエディングパークのブースでは #プチほめ展 を開催します！ 頑張っていること、ほめられたいことをぜひ書きに来てください #phpcon pic.twitter.com/85WlgDlKae — WeddingPark CREATORS (@WeddingParkTECH) June 28, 2025 ブース運営メンバーみんな。 ＼ ゴールドスポンサー紹介 ／ 株式会社ウエディングパーク さま のブース紹介です。 https://t.co/KAMUMfe39Q ひとこと：ブースではプチ褒め展開催中！ぜひご来場ください！ ぜひブースへお立ち寄りください！ #phpcon pic.twitter.com/uDTqZZBKHz — PHPカンファレンス2025 (@phpcon) June 28, 2025 ウエディングパークのブースでは、 #プチほめ展 を開催しました。 https://www.weddingpark.co.jp/news/2025/15493 カルチャーのひとつであり、カルチャーブック「 Wedding Park Ship 」に掲載されている「ほめよう。」を疑似体験できるブースを展開しました。 自分のエンジニアリングや頑張りでほめてほしいことをパネルに貼る 誰かの頑張りを読み、褒めるコメントを貼る ブース来場者のたくさんの「頑張り」「褒め」を集め、みんなに見てもらおうと開催しました。 ブースは大盛況！ カンファレンス終演間際、たくさんの「頑張り」「褒め」が集まったプチ褒め展のパネルはこのようになりました。 今回のPHPカンファレンスのブースは #プチほめ展 みんながほめ合う幸せの連鎖が見れたしウエディングパークのカルチャーも感じてもらえて企画者冥利につきました ご参加いただいた皆さまありがとうございました #phpcon pic.twitter.com/S7KjCtrqOw — akiko_suzuki@ウエディングパーク (@akk_szz) June 28, 2025 ブースにご来場いただいた200名以上の皆様、ありがとうございました！ 皆さんに貼っていただいたコメントは大きな一つの「木」のようになり、心なしか「ハート」にも見える心のこもった声の集まりです。 少し貼っていただいた「頑張り」「褒め」を紹介したいと思います。 「初めてのリーダー頑張ってます」「テストコード増やしました」 という頑張りに、「えらい！」「最高の行動！」などの「褒め」が。 「チームへのAI推進」「開発組織へのAI率先導入」「テスト運用頑張った」「PHP8に書き換え」 という頑張りに「えらい！」「今、大事なことだよね！」「すごい！」などの「褒め」コメント。 中には学生さんからの投稿も。「きっと合格できる！」と応援コメントも。 このブログを書きながら一つ一つの付箋を見ていますが、とても心が暖かくなります。 皆さんの頑張りに私も頑張ろ！とか、「褒め」や「応援」コメントに自分が褒めてもらったかのように嬉しくなります。 そして当日ブースで来場者の皆さんと話していて、いちエンジニアとして皆さんの開発・エンジニアリングの話を聞けたことがとても楽しかったです。 今どんなお仕事・開発をやっているんですか？ （書いていただいた頑張りに対して）これを一人で作られたんですか？ 素敵な応援コメントですね！ と短い時間での会話の中で、エンジニアトークやお仕事の取り組みを知る機会はとても勉強になった時間でもありました。 技術カンファレンスの中で、技術トークは嬉しいですね！ あらためて、沢山のお話を聞かせていただいた皆様、ありがとうございました！ 登壇 SREとプロダクト側エンジニアとで行っている、インフラ対応の共通基盤と組織取り組みについて話をしました。 沢山の方に見にきていただき感謝です。スタッフ皆さんも親切で何も不安なく発表をすることができました。すごく楽しかったです！ メンバーの登壇始まりました！ #phpcon #track2 pic.twitter.com/tv4XP9jUdV — WeddingPark CREATORS (@WeddingParkTECH) June 28, 2025 懇親会でも質問をいただいたり、登壇内容についてお話できたことも嬉しかったです。 実はSREとして活動をし始めてまだ一年も経っていない中で、このようにカンファレンスで登壇の機会をいただけた事自体がとても嬉しかったです。 もともとプロダクトエンジニアで、SREとしての活動に移った中で感じていたのが「プロダクトやSREとか枠組み関係なく、同じくサービスに貢献していきたい」という気持ちだったので、 今回話した共通基盤を用いて長期的に変化に強いプラットフォームから技術挑戦の幅を広げていきたい話を、今の段階でひとつ発信できて良かったです。 まだまだ変化の途上なので、今後活動をしていく中で沢山の挑戦は引き続き発信できるよう、邁進していきたいなと感じます！ 閉幕・まとめ 登壇者やスタッフ等も併せて1000人以上が来場されたカンファレンスでした。 あらためて、ウエディングパークのブースにお越しいただいた皆様、登壇を見にきていただいた皆様ありがとうございました！ とっっっても楽しかったです！ ブース運営を通して沢山のエンジニアの方とお話しできたことも、登壇内容について会話も深められたことも、カンファレンスの醍醐味にどっぷりつかれた機会でもありました。 また次のカンファレンスが楽しみです！ The post PHPカンファレンス2025で登壇、スポンサーブースレポート first appeared on Wedding Park CREATORS Blog .

こんにちは！ 新卒1年目エンジニアのyu-yaです！ （そんな私ももうすぐ2年目になります…はやい…） 先日、PlaywrightとMagicPodをGitHub Actionsに組み込む検証を行いました。 今回はその検証の紹介をしたいと思います。  1. GitHub Actions に組み込んだ背景 現在、私が携わっているサイトにおいて、E2Eテストの自動化ツールの導入を検討しています。 （導入に至る経緯や目的などはここではお話ししないので、別の機会でできればと思います） その際の運用方法（実行方法）の検証として、テスト実行をGitHub Actionsを用いて実行できるようにしました。 その際に学んだことをお伝えしたいと思います。 GitHub Actionsにて、PlaywrightやMagicPodの実行を検討されている方の、参考になれば幸いです。 2. CI/CDとは？ GitHub Actionsへの導入にあたって、そもそもCI/CDとはなにかわからなかったので、調べてみました。 CIは1種類で、CDは2種類存在しています。 CI（Continuous Integration / 継続的インテグレーション） ： コードのビルド、テストを自動で行う CD（Continuous Delivery / 継続的デリバリー） ：CIでの実行が終わったのち、いつでもデプロイができる状態にする。開発環境や本番環境へのデプロイは手動で行う CD（Continuous Deployment / 継続的デプロイメント） ：CIでの実行が終わったのち、自動で開発環境や本番環境にデプロイを行う 現代のアプリケーション開発において、複数の人が同時に複数機能の開発することが多くなってきています。また、リリース回数も増えてきている現代では、CI/CDを導入することは、より効率的にでき、ミスも減らせる有効な手段とされています。 3. 実際にやったこと まず、簡単にどんな要件を持って組み込む検証を行ったか説明したいと思います。 要件1：Playwright・MagicPodともに、GitHub ActionsのWorkflowの手動実行ができること 要件2：実行時にどのテストケースを実行するか選べること 実際に、PlaywrightとMagicPodをGitHub ActionsのWorkflowに組み込んでみたので、 その方法と、自分なりのポイントを書きたいと思います。 Playwright Step1 Playwrightのインストール ターミナルにて、下記コマンドを実行します。 npm init playwright@latest 実行するとターミナルにて下記4つを聞かれるので、答えます。 ・TypeScriptとJavaScriptのどちらを使うか ・テストファイルを配置するフォルダ名 （初期設定がtestsなので、とくに問題がなければそのままにする） ・GitHub Actions Workflowに追加するか （yesを選択すると、ymlファイルが自動で作成されます） ・Playwrightのブラウザをインストールするか （yesを選択すると、のちに実行する必要がある npx playwright install を実行する必要がなくなります。）   ↓実際に表示されるターミナル $ npm init playwright@latest > npx > create-playwright Getting started with writing end-to-end tests with Playwright: Initializing project in '.' Do you want to use TypeScript or JavaScript? · TypeScript Where to put your end-to-end tests? · tests Add a GitHub Actions workflow? (y/N) · true Install Playwright browsers (can be done manually via 'npx playwright install')? (Y/n) · true ※「 Playwrightのブラウザをインストールするか 」に対して、Noを選択した場合は、下記コマンドを実行します。 npx playwright install Step2 テストケースの作成 今回、ワークフローのテスト用に簡単なテストケースを3つ作成します。 以下のファイルを作成します。 ファイル名： tests/PlaywrightTest.spec.ts import { test, expect } from '@playwright/test'; test('テストケース1', async ({ page }) => { console.log("テストケース1"); }); test('テストケース2', async ({ page }) => { console.log("テストケース2"); }); test('テストケース3', async ({ page }) => { console.log("テストケース3"); }); Step3 ymlファイルを作成（または改修） ワークフロー実行用に、以下のファイルを作成します。 ファイル名： .github/workflows/playwright.yml name: Playwright Tests on: workflow_dispatch: inputs: test-case: description: 実行するテストケースを選んでください type: choice required: true default: "テストケース1" options: - "テストケース1" - "テストケース2" - "テストケース3" jobs: test: timeout-minutes: 60 runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: lts/* - name: Install dependencies run: npm ci - name: Install Playwright Browsers run: npx playwright install --with-deps - name: Run Playwright tests ${{ inputs.test-case }} # 選択したものを取得できる run: npx playwright test -g ${{ inputs.test-case }} - uses: actions/upload-artifact@v4 if: ${{ !cancelled() }} with: name: playwright-report path: playwright-report/ retention-days: 30 ポイント1. npx palywright install –with-deps について 　Playwrightとその依存関係を一緒にインストールしてくれるコマンドになっていて、このコマンド一つで実行環境が整います。 ポイント2. ymlファイルはインデントが重要 　インデントによって構造が決まります。インデントが合っていないとエラーになってしまうので気をつけましょう！ Step4 GitHub Actionsから実行する 実際にworkflowを起動して、テストが正しく実行できているか確認します。 今回のテストは、コンソール出力しているので、表示されているかを確認します。 MagicPod Step1 MagicPodのアクセストークンを取得 MagicPodにログイン → 右上のアイコン → システム連携 → APIトークンをコピー Step2 GitHubのシークレット環境変数にトークンを設定 セキュリティのため、GitHubのシークレット環境変数にAPIトークンを設定します。 GitHubリポジトリ → settings → Secrets and variables → Actions   → New repository secret から追加します。 Step3 シェルスクリプトの作成 リポジトリ配下に以下ファイルを作成します。 （のちに作成するymlファイルにて呼び出します。） ファイル名：run_magicpod_test.sh #!/bin/bash -e # (-eで、コマンドがエラーになった行で処理を終了させる) # magicpod-apiクライアントの最新版を現在のディレクトリにダウンロード・解凍 curl -L "https://app.magicpod.com/api/v1.0/magicpod-clients/api/${OS}/latest/" -H "Authorization: Token ${TEST_MAGICPOD_API_TOKEN}" --output ${FILENAME}.zip unzip -q ${FILENAME}.zip # MagicPodで使う各種環境変数を設定 export MAGICPOD_ORGANIZATION=${MAGICPOD_ORGANIZATION} export MAGICPOD_PROJECT=${MAGICPOD_PROJECT} # 一括実行設定番号を使ってテスト一括実行 # -n を入れることでテストの実行を終わる前にactionsの実行を終わらせられる。 ./magicpod-api-client batch-run -n -t ${TEST_MAGICPOD_API_TOKEN} -S ${TEST_SETTING_NUMBER} ポイント3. シェルスクリプトがうまく実行できない場合 ・変数の使用方法はあってますか？ シェルスクリプト内で変数を使うときは ${変数名}で使用できます。 （ymlファイルと異なるので注意） ・コマンドが合ってるかわからない… MagicPodのプロジェクトのトップページ → テスト一括実行 → 詳細 → 「テストを一括実行」の横の3つの縦点 → コマンドラインから実行 から、 複数のシチュエーションでの実行方法が記載されているので、うまく実行できない場合は、参考にすると良さそうです。 Step4 ymlファイルを作成 ワークフロー実行用に、以下のファイルを作成します。 name: MagicPod検証用ワークフロー on: workflow_dispatch: inputs: test-case: description: 実行する一括実行設定番号 type: choice required: true options: - "1" - "2" - "3" jobs: action: timeout-minutes: 10 name: magicpod verification runs-on: macos-latest # 今回はmacを指定 env: TEST_MAGICPOD_API_TOKEN: ${{secrets.<GitHubで設定したシークレット変数名>}} OS: mac # 今回はmacを指定 Windowsマシン上でのビルドの場合はwindows、Linuxはlinuxを指定 FILENAME: magicpod-api-client # 任意のファイル名を指定 MAGICPOD_ORGANIZATION: <MagicPod組織名> MAGICPOD_PROJECT: <MagicPodプロジェクト名> TEST_SETTING_NUMBER: ${{inputs.test-case}} steps: - name: Checkout uses: actions/checkout@v4 - name: Batch run test run: bash run_magicpod_test.sh # 先ほど作成したシェルスクリプト 参考： GitHub Actionsとの連携 – MagicPodヘルプセンター ポイント4. うまく実行できない場合 ・インデントはあってますか？ ymlファイルでは、インデントによって構造が決まるので、注意が必要です。 ・変数の使用方法は合っていますか？ ymlファイル内で変数を使うときは${{変数名}}で使用できます。 （shファイルとは異なるので注意） ポイント5. 実行されるテストが思っていたのと違う MagicPod側で一括実行の設定を行う必要があります。 プロジェクトのトップページ → テスト一括実行 → 詳細 → 実行対象 で 対象の一括実行設定番号で実行するテストケースを選択します。 ここの設定を行っていないと、テストが実行されないので注意します。 Step5 正しく実行されているか確認 ログにMagicPodの実行確認のためのURLが出力されるので、遷移して実行したいものが実行されているか確認します。     さいごに 今回は、GitHub ActionsのWorkflowsに組み込んでみました！ 意外と簡単にGitHub Actionsへの組み込みが可能だと思いますので、いつものフローに自動テストツールによる自動テストの実行を組み込んでみてはいかがでしょうか？   最後までご覧いただきありがとうございました！ The post PlaywrightとMagicPodをGitHub Actionsに組み込んでみた first appeared on Wedding Park CREATORS Blog .

こんにちは！ 新卒1年目エンジニアのshimatsuです！ 先日、同期のエンジニアメンバーで、弊社のメインサービスの仕様について勉強する場を設けました。 なぜこのような場を設けようと思ったのか、そして具体的にどのようなフローで進めていったのかをご紹介します！   1.勉強会の背景 弊社は数年前より、 「ウエパテックアカデミー」 というものを実施しております。 実施の意図は こちら をご覧ください！（最近は新卒入社のエンジニアが対象） 私たちも先日受講し、自社システムに関する知識レベルがどのくらいあるのか知ることができました。   私たち同期はそれぞれ違ったチームに配属しており、普段扱っている分野も違うため、自社サービスに関する知識もお互いバラバラでした。   知識に差があるからこそ、お互いに教え合う・学び合う習慣が作れたらいいなと思い、 まずは講義していただいた内容をさらに深掘りして学ぶことで、 「問題が解ける状態」から 「自分で教えられる状態」 や 「不具合などが発生した際に全員が同じラインで対応に向かえる状態」 を目指しました！   2.勉強会に至るまでのフロー 今回は弊社サイトのCV（コンバージョン）計測関連の知識を高めることを目標に置きました。 勉強会を開催するにあたり、まず自分が説明できる状態を目指して下記の順で学んで行きました。 ①CVから計測結果を表示するまでのフロー サイト上でコンバージョンが起こってから、そのデータがどのような形で送られ、どこに保存されているのか。 こちらに関しては、図式化されたものが共有されていたので、実際に送られているパラメータや保存されている中身を確認してみました。 計測結果の表示に関しては、即時に反映されるもの・一定時間経ってから反映されるものがあり、疑問に感じていましたが、フローを理解することで「なぜその時差が生じていたのか」知ることができました。 ②cookieについて CV周りを調べる上で、cookieについての理解が必要だとわかりました。 まず、インターネット上でcookie自体の理解を深めました。その上で、自社システム内ではどのようにカスタムされているのか調べていきました。 ここはドキュメントがあまり残っていなかったので、先輩社員に質問しながら理解を深め、その後自分でドキュメントにまとめて共有しました。   3.勉強会を終えて まず、「教える」まで自分で取り組んだことで、インプット・アウトプットができて理解がより深まりました。 また、ハンズオン形式で実際のサイトやデータベースを見ながら進めていたので、座学よりもイメージが付きやすかったのも良かったなと感じています。   同期にも感想を聞いてみましたが、 「活用事例や理由までしっかり説明してくれてとってもわかりやすかった」「一切触れていない状態から、基本の流れを一部知ることができた」 と良い反応をいただくこともできました。   また、アンケートを答えていただいた結果、CV計測関連の知識の理解度が上のグラフから下のグラフへ大きく変化しました！ まだ100％理解したとは言えない状態ですが、それでも良い進歩かなと思います。 そして、満足度としても平均4.8と良い機会を作れたのではないかなと感じています！   今回自社システムを学んだ中で、 仕様書・設計書・ドキュメント にたくさん助けられました。 プログラミングの悩みに関してはインターネット上に参考元がたくさんありますが、社外に発信できない自社システムの知識はどうしても属人化しやすい部分です。 ドキュメントなどに細部まで詳しく書かれていること、誰がみても理解しやすい内容であることで、ジョインしたばかりのメンバーでもキャッチアップがしやすくなります。 今後、新規でAPIなどを作成する際は、わかりやすいドキュメント化をより一層心がけようと思います！   最後までご覧いただき、ありがとうございました！！ The post 新卒1年目でメインサービスの仕様を勉強してみた！ first appeared on Wedding Park CREATORS Blog .

こんにちは！エンジニアのヒビキ( @hibiki_cube )です 12月22日(日)に大田区産業プラザPiOにて開催された PHPカンファレンス 2024 に参加してきましたので、その参加レポートを残しておきたいと思います！ 今回ウエディングパークはプラチナスポンサーとしてPHPカンファレンス 2024に協賛し、社員3名による登壇とブース出展を行いました！ スポンサー登壇 今回のPHPカンファレンス 2024での登壇うち2枠は公募、1枠はスポンサー登壇でした。 今回大変ありがたいことに「ぜひヒビキくんにスポンサー枠で登壇してほしい」とお声がけをいただき、初めて25分枠での登壇にチャレンジしました。   登壇のテーマとして、今回は「共創を加速するための若手の技術挑戦」を選びました。 今年の4月から共創事業の新規プロジェクトに携わる中でエンジニアとしてどう価値を発揮してきたのか、共創を加速させるという観点での具体的な経験なども踏まえながら発表させていただきました。 まだ企画が決まっていない段階からエンジニアがアサインされることでどんな価値が発揮できるのか、共創で生まれる力を最大限事業成長に繋げるために技術でどんなことができるのか、実際の経験も交えて自分なりの考えをお伝えしました。 発表の際にはパッと見た限りでも20名以上の方にご参加いただき、緊張はありつつも、大変励みになりました！ ご参加くださった皆様、ありがとうございました。 個人的にはウエディングパークのロゴを背に発表できたのがすごく嬉しかったです！！ プラチナスポンサー枠を勝ち取ってくださった広報の皆さんに大感謝です。 念願のプラチナスポンサー！後ろのパネルにロゴが出てるの嬉しい （ #phpcon のスポンサー枠は毎年激戦なのです。） https://t.co/4lvg1myOBk pic.twitter.com/B1xCYq7bYL — 瀬川由絵 @ウエディングパーク (@meijimumu) December 22, 2024 Twitterでもたくさんの反響をいただいており、大変嬉しかったです！ 納期と制約がある中で不確定部分にどう向き合うかはエンジニアの価値発揮ポイント、腕の見せどころだなと #WeddingPark #phpcon #track3 — りりほし (@_riri_hoshi) December 22, 2024 また、発表の際には弊社メンバーも応援に駆けつけてくれたりと、ウエディングパークのカルチャーを感じながらの発表でした。 共創事業に新卒2年目の春に抜擢、毎日苦労もしながらも楽しそうに開発していて、ディレクターとしても学ばせてもらうことたくさんあります #phpcon #track3 #weddingpark https://t.co/Mxj5Jf42Xv — きしもと (@kishimoto_wp) December 22, 2024 @hibiki_cube 応援 #WeddingPark #phpcon #track3 https://t.co/ShI0V7Qamu pic.twitter.com/5qhMFSxKsH — 瀬川由絵 @ウエディングパーク (@meijimumu) December 22, 2024 ヒビキ頑張れ！！ #phpcon #track3 — おのぽん (@onopon_engineer) December 22, 2024 同期！全力応援！ #phpcon #track3 #weddingpark pic.twitter.com/iBXphANw0Y — ぴろせ/ weddingpark (@_hrshr) December 22, 2024 ハンズオンありがとう！！わかりやすかった！！ #phpcon #track3 — date (@date_developer) December 22, 2024 公募での登壇 公募枠では おのぽんさん と あずめんさん が見事採択を獲得し、それぞれ25分枠で登壇！ お二方どちらの登壇も会場は超満員で、立ち見も出るほどでした！ おのぽんさん の発表のテーマはテストコード。 テストコードを書いたことのない人に向けて、自作のチュートリアルリポジトリ tc_practice を活用しながらテストコードを書けるようになるためのきっかけとなるような発表でした！ TC practice 〜初めてテストコードを書く人へ〜 onopon/tc_practice ご本人から登壇を終えてのコメントもいただいています。 お越しいただいた皆様ありがとうございました！ いつも登壇・発表する際、「15,6人くらい見に来てくださると嬉しいなぁ」くらいに思っているのですが、 蓋を開けてみると満員となっていて、聞きたくても入室できなかった人もちらほらいたとのことで驚きと嬉しさがありました。 発表後も、僕のことを追いかけて質問してくださる方がいらっしゃったり、ブースでお声がけいただいたり、いろんな方が僕の作ったtc_practiceを活用してくださろうとしている様子を見て、 発表してよかったなと改めて感じました。 今後もいろんなところで引き続き登壇していく所存ですので、皆様どうぞ応援のほどよろしくお願いいたします！ あずめんさん の発表のテーマはシステムの長期運用。 20年続いてきたウエディングパークのシステムをどのように守り、運営してきたのかアップデートなどの経験も踏まえたシステム長期運用のための知見や考え方の詰まった発表でした！ ご本人から登壇を終えてのコメントもいただいています。 PHPConferenceで初登壇させていただきましたが、 たくさんの方にきいていただき非常にうれしかったです。 非常にいい経験をさせていただきました！ 応援にかけつけてくれた社員のメンバーもたくさんいて、心強かったです！ 登壇後に直接ご質問いただいたり、懇親会では、レガシープロダクトのあるあるな悩みについて 濃密なご相談やディスカッションさせていただきました！ ブースでも、いろいろな方とお話もでき、今後の交流にもつながりそうでワクワクしてます！ ブースの様子 ブースではPHPカンファレンスでのウエディングパークの出展としては過去最多の250名を越える方にお立ち寄りいただくことができました。 ボードを使って投票をいただいた方には弊社キャラクターの「ウエパ」のグッズやオリジナルのハンカチなどをノベルティとしてお持ち帰りいただきました！ ご参加いただいた皆様、ありがとうございました！！ 懇親会 大盛り上がりの懇親会にも参加させていただきました！ オフラインのカンファレンスだからこそできる、自分が全く知らなかった情報との出会いや、逆にめちゃくちゃコアな技術の話がたくさんできてよかったです！ 新たな人とのつながりもできて、まさにオフラインで参加しているからこそのカンファレンスの良さを肌で感じる時間でした！ まとめ PHPカンファレンスへの参加は初めてでしたが、ここでしか得られない情報・人との出会いがたくさんあり、濃密な1日でした。 PHPコミュニティの発展とPHPを利用する企業の発展はどちらも欠かせない両輪だと感じているので、今後も積極的に情報発信などを続けていきたいと思います！！ The post PHPカンファレンス 2024で登壇してきました！ first appeared on Wedding Park CREATORS Blog .

  こんにちは！ 新卒1年目エンジニアのshimatsuです。   先日、サイバーエージェント・GitHub・スマートニュース・ウエディングパークの4社での女子エンジニアプライベートLT会を開催いたしました！ 今回はこちらのイベントのレポをお届けいたします！ 1. イベントの概要 元々10年ほど前に一部の社員同士で交流の機会が生まれたことがきっかけで、これまで何度かお互いのオフィスでのLT会を開催してきました。   今回のイベントでは各5分のLTで、技術の話や本の話、キャリアの話と、テーマを設けず思い思いに話題を持ち寄りました。 参加者の中には外国籍のエンジニアも多かったのですが、事前に資料に英訳を入れたり、リアルタイム翻訳のツールを使ったりと新たな試みも！   そして、今回の開催場所は品川にあるマイクロソフトのオフィスでした！ 慣れない場所にドキドキしつつも、部屋に入った途端見えたのは‥ たくさんのノベルティーと軽食がありました！ 緊張も解け、和やかな雰囲気でイベントがスタート！   2.発表内容 ・Sさん（GitHub）「本当にあった怖くないGitHub Actions」 普段何気なく使っていたGitHubのActionsについて、ワークフローやイベントのタイミングなどの作り方についてご紹介していただきました。   ・Iさん（サイバーエージェント）「『Web API設計実践入門』を読んでみた」 最近読んだお勧めの本をご紹介していただきました。 APIを設計する中で「仕様書・ドキュメント」が大切とのことで、たしかに普段の業務の中でも、ドキュメントが丁寧に書かれているものはキャッチアップまでが早いなと感じていたので、とても納得できる内容でした！   ・Lさん（スマートニュース）「Algorithms for News App Notification」 SAP通知のアルゴリズムをどのように設計するか、実際のスマートニュースの事例からご紹介していただきました。   ・Tさん（ウエディングパーク）「不具合調査と逆転裁判は似ていると思う」 不具合調査で大切なこととして、「焦らずに状況を把握する」「自分の中のバイアスを取り除く」など、ご自身の経験を踏まえてお話ししていただきました。 最近ハマっているゲームと結びつけてお話しされていて、聞いていてとても楽しく、かつタメになるお話でした！   ・Sさん（ウエディングパーク）「エンジニアスキルと生成AI」 ここ数年で活用されるようになった生成AIの便利さと、これまでのエンジニア人生で味わってきた苦悩がなくなってしまうことに違和感を覚えたSさん。これからのエンジニア像や評価の仕方についてお話ししていただきました！   ・Sさん（サイバーエージェント）「営業職から開発職へのキャリア変更してみて」 テクニカルセールスからエンジニアへのキャリアチェンジをしたSさん、技術書を読んで毎日勉強したり、「エンジニア楽しい！」と話される姿が印象的でした！   ・Yさん（スマートニュース） これまでのキャリアと、その中で「データサイエンス」に対する興味が高まっていったお話をしていただきました！   ・Dさん（GitHub）「GitHub Mobile code on the go」 GitHubにはmobile版もあるというのは初知りでした！mobileでもコードの入力ミスやコメント返信もできるそうで、非常に便利なサービスだと感じました！   ・Wさん（ウエディングパーク）「自己成長×事業成長を軸に若手の成長を支援する」 マネージャーとして、若手の育成に取り組んでいるWさん。いま会社が求めている人材に成長するために、さまざまな取り組みを実施されていて、他社の方も興味津々のご様子でした！   ・Sさん（サイバーエージェント）「生成AIの活用とその共有方法」 職種ごとにAIに対する意識が違うことから、なぜその違いが生まれているのか、課題を解決する方法などをお話ししていただきました！   ・Kさん（ウエディングパーク）「事業成長をリードするためにGitHub Copilotを導入してみたはなし」 所属チームのありたい姿から課題を見つけ、GitHub Copilotの導入を提案されたKさん。実際に使ってみて気付いたことや、上手に活用できるとこんなにコストを削減できる！というお話もあり、想定される削減コストについては会場に衝撃が走りました！！   ・Dさん（スマートニュース）「Migrating from Amazon LB to Envoy」 社内で利用していたAmazon LBからEnvoyに移行したお話で、それぞれのメリット・デメリットなどをお話ししていただきました！   ・Sさん（ウエディングパーク）「枠にとらわれず強みで描くキャリアビジョン」 入社当初感じていた不安をどう乗りこえ、そしてどのようなキャリアビジョンを見据えているのかというお話でした！   ・Kさん（サイバーエージェント）「Women Techmakers Ambassador」 Women Techmakersという、テクノロジー業界に関わっている女性をGoogleが支援するPJについて、そしてAmbassadorとしてどのような取り組みをされているのかお話ししていただきました。 この時の発表資料もAIに投げて作成されたそうで、生成AIのレベルにも驚かされました！   3.イベントを終えて 今回、生成AIの社内導入を企画している方々と繋がれたり、GitHubの活用事例を機に交流が生まれたりと、自社にいるだけでは気付けないエンジニアならではの社会視点を採り入れる良い機会となりました！ そして、みなさんそれぞれ違った領域で活躍されている中で共通して感じたのが「学び続けることの大切さ」と「技術・プロダクトへの愛」です。 そんなお話を聞いて、自分ももっと頑張ろう！という想いが湧き上がってきました！ とても素敵な機会をありがとうございました！ 次回の開催も楽しみです！ The post 4社で女子エンジニアプライベートLT会を開催しました！ first appeared on Wedding Park CREATORS Blog .

こんにちは！ 新卒1年目エンジニアのshimatsuです。   今回は、Udemyを使ってLaravelを一から学び直してみたので、その背景や学んだことをシェアしていきたいと思います！ 1.なぜLaravelを一から学び直したのか 弊社のサービスでは、バックエンドにPHP（Laravel）を使用しております。 5月ごろに実施された研修の中でPHP（Laravel）研修というものがあり、私はそこで初めてLaravelに触れました。 当時はがむしゃらに講義を聞いて、ハンズオンに取り組んでいましたが、「ただ言われた通りにコードを書く」ことしかできていませんでした。   そこから数か月が経ち、今では開発メンバーとしてお仕事をさせていただいているわけですが、研修当時に曖昧に理解したままで知識が止まってしまっており、既存のコードを読んで腹落ちさせるまでに時間がかかっていました。   そこで、実際に開発に携わるようになった今だからこそ、あらためて基礎知識を固めることで、より開発にかかるスピードや質を向上できるのではないかと考えました！ 2.なぜUdemyを使ったのか？ UdemyではLaravelはもちろん、幅広いジャンルの講義が公開されています。 そのため、今後継続的に学習を進めていくこと際に、その時その時のニーズにあった講義が受けられそうだと思ったのが理由でした。   今回受講させていただいた講義は、「【しっかり身につける】PHP基礎の学習後に見てほしいLaravel入門(Laravel11対応)」（講師：Kent Koyamaさん）です。 ハンズオン形式で学べましたし、自社のサービスもイメージしやすい内容でした！ 3.一から学び直してみての気付き 大きな気付きとして2つ挙げられます。   1つ目が、メソッドの多さです。 講義で挙げられていたメソッドだけでも非常に多く、知らないものも正直たくさんありました。 このメソッドをうまく活用することで、より読みやすいコードを書けるようになりそうだと感じました！   例えば、フォームの入力内容を確認するバリーデーションにおいては、メソッドを使用するだけで以下のようにコードを短縮することができます。 // バリデーションメソッドを使用しない場合 $lastName = $request->get('last_name); if(empty($lastName)){ $errors[] = '姓を入力してください'; } elseif(mb_strlen($lastName) > 10) { $errors[] = '姓は10文字以下で入力してください'; } // バリデーションメソッドを使用した場合 $validated = $request->validate([ 'last_name' => ['required', 'string', 'max:255'], ]); 例では姓のみの確認ですが、実際のサイト上では多くの入力項目があり、1つずつ get メソッドを使用していると膨大な量のコードになってしまいます。 そこで、1つのvalidateメソッドに集約することで、コードを短くかつ一目でわかりやすい状態にすることができます。 また、バリデーションルールとして、 required:必須項目であること 、 string:文字列であること 、などが既に用意されていることも便利なポイントです。 （詳しくバリデーションについて知りたい方は、 Laravel公式ドキュメント もしくは 日本語訳サイト をご覧ください）   2つ目が、Laravelの便利さです。 1つ目のメソッドのように、本当だったら長くなってしまうコードや自身でメソッドを作成する必要がある場合でも、すでにLaravel側で用意されているものを使って簡潔に書けるというのは非常に強みだと感じました。 一方で、この便利さに頼り切ってしまうと、表面的な理解で止まってしまうことも考えられます。   以前、既存のコードを横展して開発していた際に、コレクションメソッドの plunk（多次元配列にて、指定したキーによる絞り込みを行うもの） が使用されていたので、同じ機能であれば必要だろうと深く考えずに新規コードに取り入れてしまいました。 ですが、このメソッドの用途を理解していないがゆえに、コードレビュー時に質問に対して正しく答えられませんでした。   このように、便利さに頼りすぎず、「そのメソッドがどう動いているか」など、自分で理解を深めにいく必要があるなと感じました。 4.学び 入社半年がたったこのタイミングで基礎知識を固められたのは良かったなと思いますし、学ぶ環境が整っていることにも有難さを感じました。   今回一番の学びは 「基礎の大切さ」 です。 土壌がしっかりしていないと、どんなに大きな木を植えても成長は止まってしまいます。 エンジニアスキルも同様に、基本が染み付いているかどうかで成長速度・角度は変わってくると思います。 どうしても目の前のタスクに意識が傾いてしまいがちですが、 「常に学び続ける心」 や 「基本に立ち返ること」 は心の片隅でも良いので常に置いておこうと思いました！   最後までご覧いただき、ありがとうございました！ The post Laravelを一から学び直してみて気付いたこと first appeared on Wedding Park CREATORS Blog .

こんにちは！ 新卒1年目のエンジニア、shimatsuです。 今回は、分析ツールとしても有名なGA4（Googleアナリティクス 4）の探索機能について、特につまずきがちな 「セグメント」と「フィルタ」の使い分け を、サンプルデータを活用しながら勉強してみました！ GA4の探索機能をマスターしたいという方は、ぜひ一緒に手を動かしながら学んでみましょう！   1.セグメントとフィルタの機能概要 まずは、それぞれの機能の概要から理解していきます。   セグメント とは、特定の属性や条件をグループ分けする機能です。 たとえば、CV（コンバージョン）に至ったユーザーがどのページを見ていたのか調べたい場合、特定の地域のユーザーの行動を調べたい場合などに使用します。 セグメントの中にも 「カスタムセグメント」 といって、自身でカスタムできるものが3種類あります。 「ユーザーセグメント」「セッションセグメント」「イベントセグメント」 です。 順に説明していきます。   ユーザーセグメント とは、ユーザーの属性や行動に基づいてグループ分け、複数のセッションをまとめたものです。 たとえば、年齢、地域、CVをしたという条件に当てはまるユーザーを調べたい場合などに使用します。   セッションセグメント とは、一定の時間内にユーザーがサイトにアクセスし操作を行った一連のアクションの集まりで、GA4でセッションスタートイベントが開始されてから、離脱するまでになります。 たとえば、ページCで商品を購入したユーザーの セッション内でのデータ を調べたい場合などに使用します。   イベントセグメント とは、イベント単位の集まりです。 たとえば、ページCで商品を購入したユーザー そのイベント時のデータ を調べたい場合などに使用します。   図式化するとこのようなイメージです。 2.セグメントとフィルタの違い ここからは、セグメントとフィルタの違いについて理解を深めていきます。 ここでの「セグメント」と「フィルタ」は、探索モード内の枠で囲んだ箇所を指しています。   公式ページによると、セグメントとフィルタには、以下のような違いがあると言われています。   セグメント：条件付きのデータセットを表示するためのデータ探索に使用され、現在のデータ探索に適用される フィルタ：設定したユーザーのグループ、セッションのグループ、またはイベントのグループで、現在のデータ探索の中であればどのタブでも使用できる （参照元： https://support.google.com/analytics/answer/9328518?hl=ja&sjid=11465435555049086948-AP ）   一旦概要は理解できましたが、まだ活用イメージが湧きません… ここで、Googleが提供しているサンプルデータを使って、実際に手を動かしてみましょう！   3.活用イメージ 今回使用するサンプルデータは、Google ブランドの商品を販売する e コマースサイト、 Google Merchandise Store の ウェブデータ です。 URLから、デモアカウントへのアクセスとサイトへの遷移が可能です。 今回テーマを「子ども用のアパレルページの閲覧に関するデータ収集」として、セグメントとフィルタを実際に使ってみたいと思います。   STEP1.セグメントの設定 まずは、セグメント3種類を設定していきます。 3種類とも「子ども用のアパレルページ（=/shop/apparel/kids）」「ページの閲覧（=page_view）」という同じ条件を指定してみます。 STEP2.セグメントの比較 STEP1で設定したセグメントを実際に使用してみます。 行には「ページパスとスクリーンクラス」、値にはイベント数を入れてみます。 すると、3種類のセグメントは下記のようなデータになりました。   同じ条件をかけましたが、このように同じ集計結果にならないのはなぜでしょうか？ これは、先ほど述べた カスタムセグメントのスコープの違い に原因があります。   たとえば、イベントセグメントでは「子ども用のアパレルページ（=/shop/apparel/kids）でのページの閲覧（=page_view）」のイベント数のみが表示されています。 一方で、セッションセグメントでは、同じセッション内でスクロールなど他のイベントをした場合、他のページの閲覧をした場合にもイベント数が集計されてしまうので、イベントセグメントの集計数より大幅に数が増えています。 そして、ユーザーセグメントでは、複数のセッションをまとめているので、さらに集計数が増えているのです。   STEP3.フィルタの設定 次に、同じ条件をフィルタに設定してみます。 この場合も集計数が異なるようです。 これは、下記のような要因が考えられます。   ・適用されるタイミングの違い セグメントはデータが収集された後に適用されますが、フィルタはデータ収集時に適用されるため、フィルタが適用される前に収集されたデータがセグメントで評価されることがあります。   ・データのスコープ セグメントはユーザーやセッション、イベントのスコープに基づいていますが、フィルタは特定のビューやレポートに対して適用されるため、異なるスコープで集計されることがあります。   ・集計方法の違い セグメントはデータを分けて集計するため、特定の条件を満たす部分集合のみを見ますが、フィルタはデータ全体に対して適用されるため、結果として異なる数値になることがあります。   このように、機能の概要を理解した上で実際に手を動かしてみると、違いが見えてきたのではないでしょうか？   GA4で探索を行いたい場合は、 絞り込みたい条件を羅列してみて ・セグメントかフィルタかの判断 ・どのセグメントかの判断 が大切になります！ ぜひみなさんも活用してみてください！   最後までご覧いただき、ありがとうございました！！ The post GA4のセグメントとフィルタをマスターしよう！ first appeared on Wedding Park CREATORS Blog .

こんにちは。新卒1年目エンジニアのyokochiです。 本配属から3か月が経とうとしております。 その中で私は、本配属から2か月で、Wedding Parkのサービスにまつわる10機能をリリースすることができました。今回は10機能のスピードリリースに至るまでの、自身の中での スピードUPポイント や さらに伸ばせる と感じたことについて書かせていただきます。 目次 配属後の主な業務 業務の流れ スピードアップポイント さらに伸ばせるところ まとめ 配属後の主な業務 研修期間が終わり、新たなチームへの配属後に私が主に行っていた業務は 「開発が完了している案件をリリースまで運ぶこと」 でした。 そしてタイトルにも書かせていただいた「10機能のリリース」とは開発が完了している案件を10件リリースしたという意味合いになっております。 業務の流れ 基本的な業務の流れとしては以下のようになっております。 1. 仕様理解 開発されたものがどのような仕様に基づいて作成されたものなのかをキャッチアップする必要があるので、対象機能に対しての挙動や仕様などをはじめにキャッチアップします。 2. テスト観点の洗い出し 仕様上の挙動や分岐などを理解した上で、テストに必要な観点を洗い出します。 3. テスト仕様書の作成 テスト観点の洗い出しをもとにテスト仕様書を作成します。 4. テスト 仕様に基づいた正しい挙動が行われているかを確認します。 5. コード修正 テストで正しい挙動が行われていなかった場合、原因を解明し、修正箇所を特定します。コード修正を行い、再度テストを行い正しい挙動ができていることを確認します。 6. リリース テストにおいて不具合が発生しなければリリースします。 スピードUPポイント まず、スピード感を持ってリリースまで運ぶことを意識していた理由として、事業成果に貢献するために、チームミッションの達成にいち早く近づけることがありました。そのため、自身の業務のサイクルを早く回しスケジュールを巻きで進めていくことが理想でした。 実際に業務の中で、時間がかかると感じたのは以下の二つになります。 仕様理解/テスト観点の洗い出し 自身が調べた担当機能の仕様に抜け漏れがないかやテスト観点の網羅性が高いかどうかが不安で、かなり時間をかけて調べていました。 コード修正 テストを行うことで不具合を発見することはできましたが、コード修正をして再びテストを行うことでテストにかける時間が多くなっていました。 つまり、コード修正自体に時間がかかるというよりもコード修正による差し戻しの発生に時間を奪われると感じました。 これらのスピードを早めるために行ったポイントが下記になります。 対象機能の仕様に詳しいディレクターの方や開発されたエンジニアの方にお話しを伺う 最初は、仕様理解やテスト項目の洗い出しにおいて 「自分が認識している仕様やテスト観点は正しいのか？網羅性が高いのか？」 という気持ちが多くあったためのかなり工数を割いていたと感じています。 そこで、ある程度の理解ができた状態もしくは仕様理解に詰まっている段階で 対象機能の仕様に詳しいディレクター や 開発担当のエンジニア にお話しを伺いにいきました。これにより自身の認識に相違がないことを確認し、テスト観点で必要になりうる箇所をお聞きし網羅性の高いテストができるようになります。また、自分の認識が正しい場合は 自信を持って次のフェーズに移る ことができ、間違っている場合や考慮する点が足りない場合は 次に何をすべきかが明確 になります。不安感や悩んでいる時間から解放され、スピード感高く仕様理解やテスト項目の洗い出しをすることができました。 仕様理解やテスト仕様書作成の段階で不具合を早期発見する 開発完了後は下記の図のようなフローで進めており、テストを行った後に不具合を発見し、コード修正を施し、再度テストをしていました。一見テストの意義を果たしてはいるのですが、もっと早期に不具合を発見できていればテストを複数回行う必要もなくなる気がしました。 今回は、開発完了後にすぐにテストする流れではなく、私の仕様理解〜テスト仕様書作成までが設けられているので、その間で不具合を発見してコード修正をして、テスト仕様書に必要であれば反映させる方が効率的だと感じました。 そのため、以下のようなフローで進めるように途中で変更しリリースまで運びました。 実際に不具合がある前提で、仕様理解やテスト観点の洗い出しを行うことで、より注視して機能の挙動の確認を行ったり、ロジックの理解に努めたりして、仕様の理解が深まりました。 さらに伸ばせるところ 上記の業務や現在行っている開発業務の中でも、特にすぐに意識でき改善できると感じたのが下記になります。 コードレビュワーとのコミュニケーション 10機能のリリースでは、コード修正をする機会もありましたが差分としてはそこまで大きくありませんでした。ですが、差分が小さかったのにも関わらず自身の説明不足で本来不要であろうやりとりなどが増えてしまいコードレビューに時間がかかってしまったことがありました。そのほかにもコードレビューを充実させるためにより意識すべきだった点は下記のことだと考えております。 誰が見てもわかるMRを作成する レビュワーにMRを見ていただく時に、自分がなぜこのような修正を加えたのか、どのコードを参考に修正をしたのか、どのMRと関係があるのかなどを正確に説明する必要があります。これをすることでレビュワーに調べさせたり不要なやりとり回数をふやりたりしないようし、スムーズにレビューできます。 レスポンスはできる限り早く 当たり前ですが、レビュワーもレビュー以外のタスクが多く存在しているため、お忙しいです。 そんな中の自分のレビューを見てくださっているのでできる限り速いレスポンスにしてストレスをなくすことが大事だと感じました。 レビュワーから質問やご意見の意図を理解する レビュワーからいただく 「〇〇をこのように修正すればいいのでは？」 というご意見に対して 「そのように修正します！」 というだけでなく、なぜそのように修正した方が良いのかを考えて修正する必要があります。これを怠ると毎回同じようなご指摘をいただいて全く成長しないエンジニアになってしまいます。そして、 「本当に理解しているのかな？」 とレビュワーを不安にさせないように、 「確かに〇〇は△△なのでそのように修正した方がいいですね！」 というようにご指摘の意図を自分が理解していることをレビュワーに伝えるようなコメントをするのも大事です。 これらの点はこれからも意識的に行いストレスフリーなコードレビューを目指します！   まとめ 10機能のスピードリリースに至るまでに意識したことや伸ばせると感じたところについて書かせていただきました。 業務を加速させるためのスピードUPポイント 積極的に先輩方（担当案件に精通している方）にお話しを伺いにいく 不具合箇所の早期発見するために業務フローを修正 さらに伸ばせるところ コードレビュワーとの円滑なコミュニケーションを取れるようにする 上記のどの項目に関しても「 決して一人で仕事しているわけではない」 ということがわかる内容になっていることに気づきました。頼ることや思いやることを忘れないことが大事ですね！ 最後までご覧いただきありがとうございました！ The post 新卒が配属2か月で10機能をリリースできたワケ first appeared on Wedding Park CREATORS Blog .

こんにちは！新卒エンジニアのs0ush1nです。 入社してから半年が経ち、さまざまな業務を行う機会が増えました。 今回はその中でも担当することが多い、クエリをテーマにしてお伝えします。 これから社会人になる方や、初めて業務でデータベースを扱う方が、可読性が高くチーム開発でも使えるクエリを書けるようになることを目標にまとめます。 目次 クエリとは クエリの可読性について SELECT文を使ったクエリの作成例 UPDATE文を使ったクエリの作成例 まとめ クエリとは クエリはデータベースに取得、更新、削除、挿入するための命令を指し、この記事ではSQLを一括りにクエリと呼称します。 クエリの例 条件:usersテーブルにname,ageカラムが存在 SELECT name, age FROM users WHERE age > 30; 簡単な例ですが、以上のクエリを書くことで “usersテーブルからageが30以下のuserのnameとageを抽出” が可能です。 クエリの可読性について 個人開発でとにかく動作するクエリを書けばよい、という要件であればどのような書き方をしても構いません。 しかし、社内のチーム開発という環境では可読性が要求されるようになります。 ここには大きく二点の理由が存在しています。 「実行・実装者が異なる際のリスク低減」と「レビュワーへの配慮」です。 実行・実装者が異なる際のリスクの低減 クエリの可読性が低い状態で異なる実行者に依頼すると、以下のリスクが高まります。 意図していないDBで実行してしまった クエリの実行順序を間違えてしまった 抽出結果が要件通りにならなかった 実行内容によってはデータが消えたり上書きされてしまうリスク を防ぎ、 組織ごとに存在している規約を守りながらクエリを書いていきましょう。 レビュワーへの配慮 チーム開発の特徴として、コードレビューが存在します。 チームメンバーにコードを共有し、内容に問題がないかをクエリの実行前に確認してもらう工程のことで、可読性も求められました。 可読性を高めておくことで、適切なインデントや説明、不適切なカラム名を使用していた場合に気づきやすいというメリットが存在し、リスクの低減が可能です。 明快なコードでお互い快く確認し合える環境を作りましょう。 SELECT文を使ったクエリの作成例 それでは、例を見ていきながら可読性を高めるクエリについて説明していきます。 /* アクティブなユーザーを抽出 条件:  - testDB上で実行  - 18歳以上  - 2023年1月1日以降に登録  - ステータスが「active」 */ USE testDB; SELECT      id AS 'ユーザーID',                           name AS '名前',                               email AS 'メールアドレス',                     age AS '年齢',                                registration_date AS '登録日',                 status AS 'ステータス'                   FROM      users WHERE      age >= 18                                      AND registration_date >= '2023-01-01'          AND status = 'active' ; このクエリの可読性を高めているポイントとして、条件説明・DB指定・インデント・ASによる命名があります。 条件説明 実行内容のタイトル、条件をコメントアウトにまとめます。 これにより、SQLファイルの中身を確認するだけで内容が理解できること、その他のドキュメントを確認しなくてもやりたいことが見えている状態になるため全体的な可読性に繋がります。 DB指定 phpMyAdminのようなGUI環境で実行をする場合、DB内のクエリ入力欄に入力することにより明示しなくても実行がされてしまう場合があります。 実行者が異なる場合、どのDBで実行すべきクエリなのかが伝わっていない可能性があるため、これを回避するためにもDB指定を推奨します。 インデント 命令文やその他の指定単位で分けてインデントを行います。 細分化することで可読性が向上し、条件網羅漏れや確認ミスといったリスクの軽減に繋がります ASによる命名 直接的なクエリの可読性につながる訳ではありませんが、非エンジニアの方に共有するためのデータ抽出を行う場合はとくにカラム名ではなく一般名詞での命名が望ましいです。 user_typeといったカラム名が表に混じっていると、読みやすさに影響します。 1つのSELECT文で完結しているクエリのため元々ある程度可読性は高いですが、 可読性をより高める工夫をしておくことで 長いクエリを作成する際も可読性を損なわず作成できる ため常に意識して損はありません。 UPDATE文を使ったクエリの作成例 次は、データベースに変更を与えるUPDATE文のようなクエリの作成例です。 /* some_columnテーブルの全てのレコードのstatus_flagを1に更新する */ USE testDB; -- 更新前のフラグの状況を確認 SELECT      e.id,      e.status_flag, h.name FROM      example_table e INNER JOIN      hoge h ON      e.some_column = h.some_column ; -- 全てのレコードのstatus_flagを1に更新 UPDATE      example_table e SET      e.status_flag = 1 FROM      example_table e INNER JOIN      hoge h ON      e.some_column = h.some_column ; -- 更新後のフラグの状況を確認 -- フラグが全て1に変更されたかどうかを確認。 SELECT      e.id,      e.status_flag, h.name FROM      example_table e INNER JOIN      hoge h ON      e.some_column = h.some_column ; このクエリでは前述の条件説明、DB指定、インデントに加えてSELECT文の導入、エイリアス設定を行っています。 SELECT文の導入 “変更しようとしているカラムやテーブルが存在しているか？” “変更したカラムやテーブルを更新できているか？” ということを改めて確認するために変更の前後にSELECT文を設定します。 これにより実行者が具体的な内容を知らない場合にも変更を確認できるため、確実性を高めることが可能です。 エイリアス設定 エイリアスとは、テーブル名に別名をつけることで、1文字から設定することが可能です。 例ですが、user_attrebute_typeテーブルが存在した際にuとおいて、u.nameと表すこともできます。 まとめ 会社でクエリを扱う場合は、実行者が自分ではないことで理解しやすさ、ミスのなさが求められます。 そのため、私はクエリは手順書に近いのではないかと考えています。 まず明確さと一貫性が求められ、 他のメンバーが理解しやすいように記述することが重要で、チームで扱う以上後から読んだ人がその意図や内容を理解できなければなりません。 また、どちらも正確に取り組むことで誰でも同じ結果が得られることから再現性が必要な点も似ていると考えます。 ひとつのコードと扱うのではなく、手順書を正確に書く気持ちで可読性を高めミスの少ない運用を行えたら良いですね！ The post 新卒エンジニアが学んだ、翌日からできる可読性の高いクエリの作成 first appeared on Wedding Park CREATORS Blog .

こんにちは！新卒1年目エンジニアのshimatsuです！ 入社からはや半年が経とうとしており、本配属からはすでに3か月… ほぼ未経験の状態で入社した私が、この間どのような挑戦をしてきたのかお伝えします！ 同じような境遇の方や来年度エンジニアとして働く方にとって、少しでも原動力になれば幸いです。   1.知識がないなら量で攻めよ！ 前述の通り、私はほぼ未経験の状態で入社いたしました。 （具体的には、フロントエンド少々、バックエンドはまったくの未経験です！） そのため、エンジニアとして即戦力となれるのか不安が拭えないまま、研修期間を過ごしていました。 そこで、本配属直後に立てた目標が 「誰よりもリリースする」 こと。 まずは数多く経験して、自分の中の引き出しを増やそう作戦です。 もちろん、速ければ良いというわけではなく、「自分の書いたコードに魂を宿す（無意味なコピペはNG）」、「指摘に対してきちんと答えられる」といった丁寧さも兼ね備えた上での「量」を意識しました。（ 以前書いた記事 もぜひご覧ください！）   量をこなす上で意識したのは 「先回り」 です。 弊社の開発フロー上、上長の確認を待つ時間などが何度か生じてしまいます。 この隙間時間で、その先にやるであろう業務をできるところまで先にやろう！ということです。常に2、3歩先を見据えてタスクをこなす、マルチタスク方式で動いていました。 図式化するとこのようなイメージです。（白が確認タイム、色つきが自身のタスクです） このように 常に手を動かしている状態を作る ことで、リリースまでの時間を削減できました。   結果、3か月で12件のリリースをすることができました！ たくさんリリースすれば良いわけではありませんが、12件という数によって自身のスキルが高まったのは紛れもない事実です。 そして、開発サイクルを加速させることによって、チームの目標達成へも大きく貢献できました！   2.自分にできることはすべて巻き取る！ どうにかしてチームや会社に貢献したい！ という思いはある一方で、まだまだスキルは浅いという現状から、 チームのためになることだったら何でも巻き取っていこう！ という考えに至りました。 具体的には2つのことを実践していました。   1つは、企画や仕様など、 ディレクター周りのお仕事の巻き取り です。 エンジニアが上流から入ることでさまざまなメリットがありますが、 費用対効果や実際の工数をイメージできる というのを今回一番実感しました。 これによって、 企画の優先度やなぜ今やるべきかを根拠づけて説明できる 、開発着手時のキャッチアップ時間を短縮できるので 開発時間の削減 などのメリットを得られました。 また、上流段階のアクション1つ1つの重要性にも気付くことができ、 開発に着手する前にメンバー間で議論をして仕様や進め方の意識を統一する ことが大切だと学びました。 これによって、 より現実的かつスピード感を持って 企画からリリースまで走ることができたと感じています。   もう1つが、担当者が決まっていないような チーム対応の調査や分析に自ら手を挙げること です。 担当者や期日が明確でないからこそ、蔑ろにされてしまっていたタスクというのはどのチームにもあるかと思います。 ここが若手のチャンス！ これによってチームメンバーから感謝されることももちろん嬉しかったのですが、調査や分析にトライすることで何より自分の知識・スキルが向上していくのを実感できました。 こちらは実際に開発した案件の効果検証結果を所属部署へ展開したものですが、サーチコンソールやGA4を用いて分析し、狙っていた数値がしっかり獲れたことをお伝えすることができました。 そして、そこからさらなる課題点を挙げ、新たな施策へと展開するというPDCAのサイクルを生み出すことができています。   このように、 「先回りした行動」 と 「すべてを巻き取る意識」 でトライした結果、 「企画からリリースまで一人で進められる」 状態へと成長できました。 ただ、このような成長を遂げられたのは自分の行動だけではありません。 周囲から常に支えられ、チームとして行動していたからこその成長 でした。 あらためて自分は恵まれた環境にいるんだなぁと感じました。 このような環境にいられることに感謝しつつ、これからも精進し続けたい！と思った社会人6か月目のブログでした。   最後までご覧いただきありがとうございました！ みなさまの原動力の一部となれましたら幸いです！ The post ほぼ未経験の新卒が「企画からリリースまで一人で進められる」ようになるまで first appeared on Wedding Park CREATORS Blog .

こんにちは！ 新卒3年目エンジニアのtakadaです。 MySQL8系よりJSON型に関連する新しい機能がいくつか追加されたので、 デモを通して説明しつつ、正規化表現と比較しながらどの場面で使えそうかを模索していきます。 目次 1. はじめに 2. MySQL8系の新しいJSON関連機能 3. 正規化されたDB設計とJSON型の比較 4. [おまけ] MySQL8系の機能を活用してパフォーマンスを考える 5. [おまけ] その他にMySQL8系で追加されたJSON関数 6. まとめ 1. はじめに 最初にも述べたように、MySQL8系ではJSON型に関連する新しい機能がいくつか追加され、より柔軟なデータ管理が可能となりました。 そこでリレーショナルデータベースにおける「正規化」に対して、MySQL8系のJSON型を活用することでどんなメリット・デメリットがあるかを示し、どの場面で使えそうかを模索していきたいなと思います。   2. MySQL8系の新しいJSON関連機能 2-1. 複数値 Index 複数値 Indexとは、JSONのカラムの中に、配列としてキー値が複数含まれている場合でも有効に機能できるINDEXです。 JSON型では直接INDEXを貼れないため、JSONから抜き出したデータでカラムを作成し、仮想的なINDEXとして用意することで解決していました。ただ、以前から速度があまり上がらないという問題があり、今回の 複数値 Indexの追加によって速度向上が見込めるようになりました。 2-2 新しいJSON関数 2-2-1 JSON_TABLE() JSONデータをテーブル形式に変換して返してくれる関数で、 この関数を用いて、別のテーブルとJOINできたりもするので便利な関数です。 2-2-2 MEMBER OF() MEMBER OF()とは、特定の値がJSON配列の中にデータとして存在するかを確認するために使用されます。 具体的なクエリ使用例は4章に記載します。 ※ まだまだありますが、今回は説明をする上で主に使用する関数を記載しております 他のJSON関数は5章にてtipsとして記載します。   3. 正規化されたDB設計とJSON型の比較 では、実際にMySQL8系にて追加されたJSON関連機能も使いつつ、 正規化されたDB設計とJSON型の比較を行ってみます！ 3-1 正規化されたDB設計の例 まずは、よくあるECサイトをイメージしてDB設計を考えてみます。 いろいろと必要なデータはありそうですが、一旦最低限の必要な情報として、 「顧客情報」・「注文情報」・「注文商品」の情報を元にそれぞれ別のテーブルに分割して 管理します。下記にクエリ文の例を記載しておきます。 顧客情報テーブル(test_customers) CREATE TABLE test_customers ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), email VARCHAR(100) ); 注文情報テーブル(test_orders) CREATE TABLE test_orders ( id INT AUTO_INCREMENT PRIMARY KEY, customer_id INT, order_date DATE, amount_total INT, FOREIGN KEY (customer_id) REFERENCES test_customers(id) ); 注文商品テーブル(test_order_items) CREATE TABLE test_order_items ( id INT AUTO_INCREMENT PRIMARY KEY, order_id INT, product_name VARCHAR(100), quantity INT, price INT, FOREIGN KEY (order_id) REFERENCES test_orders(id) ); 3-2 JSON型を用いた設計の例 次にJSON型を用いて、同様にショッピングアプリを想定した設計を行ってみます。 正規化されたテーブルに対して、JSON型を使用して同じデータをシンプルな1つのテーブルに統合してみます。 顧客情報テーブル CREATE TABLE test_customers ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), email VARCHAR(100), orders JSON -- JSON型を用いる ); 注文情報や商品情報をすべて`test_customers.orders`カラムにJSONの形式で格納する形にしてみました。 実際にデータをINSERTする場合は下記のようなクエリ文を用いて挿入します。 INSERT INTO test_customers (name, email, orders) VALUES ('SQL taro', 'sql_taro@example.com', '[ { "order_date": "2024-09-01", "amount_total": 350, "items": [ {"product_name": "chocolate", "quantity": 2, "price": 150}, {"product_name": "apple", "quantity": 1, "price": 200} ] } ]'); 3-3 データ抽出のクエリ文比較 3-3-1 正規化されたテーブルでのクエリ文 先ほど設計した内容を元に、顧客名や注文日などのデータを抽出してみる場合、 下記のようなクエリ文になります。 SELECT tc.name AS '顧客名', to.order_date AS '注文日', toi.product_name AS '製品名', toi.quantity AS '個数', toi.price AS '値段' FROM test_customers c JOIN test_orders o ON tc.id = to.customer_id JOIN test_order_items toi ON to.id = toi.order_id WHERE tc.id = 1; 3-3-2 JSONを用いたテーブルのクエリ文 (MySQL8系新機能活用) JSON型の場合、注文と商品情報を1つのクエリ文で取得できそうです。 また、MySQL8系の新しいJSON関連機能にて説明しましたJSON_TABLEを用いて、 クエリ文を記載してみます。 1. JSON形式からデータを取り出した場合 SELECT orders FROM test_customers tc; 抽出結果 ※ JSONデータが細かいので、一部切り取ってます。 2.  JSON_TABLEを用いてデータ抽出した場合 SELECT order_info.* FROM test_customers, JSON_TABLE(orders, '$[*]' COLUMNS ( order_date DATE PATH '$.order_date', amount_total INT PATH '$.amount_total', items JSON PATH '$.items' )) AS order_info; 抽出結果 3. 「3-3-1」と同様の内容を抽出する場合 SELECT name, order_info.* FROM test_customers, JSON_TABLE(orders, '$[*]' COLUMNS ( order_date DATE PATH '$.order_date', total_amount INT PATH '$.total_amount', items JSON PATH '$.items' )) AS order_info WHERE id = 1; 抽出結果 2・3を見てみるとわかるように、 JSON_TABLEを用いることでテーブルの形式に変換でき、 JSONの柔軟性を活かしつつも正規化されたテーブルと同様の形で抽出できそうです。 また、今回の正規化とJSONの比較という部分を考察すると、 JOINを使わなくなるのでテーブルとしてはシンプルになりますし、 JSONを用いることでデータの柔軟性は上がったのかなと思いつつも、 JOINするテーブルが多くなった時にデータの冗長性が問題となりそうな感じがしました。 4. [おまけ] MySQL8系の機能を活用してパフォーマンスを考える MySQL8系の新しいJSON関連機能の項目でも説明しました複数値 Indexを用いることで、パフォーマンス向上を図れます。 今回の記事ではパフォーマンス検証を行いませんが活用方法を下記に記載します。 「まずはテスト用のテーブルの作成とテストデータをINSERTする。」 -- JSON型の検証用テーブル作成 CREATE TABLE test_json ( id INT AUTO_INCREMENT PRIMARY KEY, info JSON -- JSON型を用いる ); -- テストデータをINSERT INSERT INTO test_json (info) VALUES ( '{ "name": "Taro", "age": 20, "address": [123456, 78910] }' ); 次に本題の複数値INDEXの貼り方を記載していきます。 「最初に複数値INDEXを貼ってない場合において、MySQL8.0.17から追加された MEMBER OFを使用して確認する。」 city:Tokyoの値を含むかデータを抽出 SELECT INFO FROM test_json WHERE 123456 MEMBER OF(info->'$.address'); 抽出結果 実行計画の確認 EXPLAIN SELECT INFO FROM test_json WHERE 123456 MEMBER OF(info->'$.address'); 抽出結果 もちろんINDEXを何も指定していないためtype ALLとなります。 では、実際に複数値INDEXを貼ってみます。 JSONのフィールドに対するINDEXを作成するには、 JSONの値を適切なデータ型にキャストする必要があります。 adressに対してINDEXを貼る ALTER TABLE test_json ADD INDEX idx_address( (CAST(info->'$.address' AS UNSIGNED ARRAY)) );  再度実行計画を確認 EXPLAIN SELECT INFO FROM test_json WHERE 123456 MEMBER OF(info->'$.address'); 抽出結果 上記のようにtype=ref, key=idx_addressとなり、 インデックスが効いていることを確認できました。 JSON形式のデータを使用する場合、複数値INDEXを用いてパフォーマンス向上 を考えられたら素敵ですね！   [参照URL] https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-multi-valued   5. [おまけ] その他にMySQL8系で追加されたJSON関数 最後にMySQL8系より追加されたJSON関数を下記のテストテーブルを用いて、 実際に具体例を挙げながら説明します。 -- テストテーブル作成 CREATE TABLE test_json ( id INT AUTO_INCREMENT PRIMARY KEY, info JSON ); -- テストデータ挿入 INSERT INTO test_json (info) VALUES ('{"name": "Taro", "hobbies": ["reading", "swimming"]}'), ('{"name": "Jiro", "hobbies": ["reading", "music", "running"]}'); ① JSON_OVERLAPS() 2つのJSONデータを比較して、データが重複しているかを確認します。 これは2つのJSONオブジェクトや配列に共通の要素がある場合にTRUE、共通の要素がない場合はFALSEを返します。 重複しているデータをチェック SELECT * FROM test_json WHERE JSON_OVERLAPS(info->'$.hobbies', '["swimming", "music"]'); 抽出結果 ② JSON_SCHEMA_VALID() MySQL8.0.17以降に使用できる関数で、 JSONデータが指定したJSONスキーマに適合しているかを検証します。 この関数はJSONデータがスキーマに準拠している場合はTRUE、準拠していない場合はFALSEを返します。 JSONデータが準拠しているか確認する。 SELECT id, JSON_SCHEMA_VALID('{ "type": "object", "properties": { "name": { "type": "string" }, "hobbies": { "type": "array" }, }, "required": ["name", "hobbies"] }', info) AS is_valid FROM test_json; 抽出結果 結果を見てわかりますように、どちらも準拠しているので「１」を返しています。 ③ JSON_VALUE() こちらはシンプルな関数で、JSONデータからスカラー値を抽出します。 特定のキーに対応する単一の値を取得するのに使用します。 nameカラムの値を取得する SELECT id, JSON_VALUE(info, '$.name') AS name FROM test_json; シンプルなだけに多くの場面で使用することがありそうなので、 覚えておくと良いかもしれないです！ 詳しくは下記URLにて、JSON関数の一覧が載っておりますので 興味があれば見ていただければと思います！ https://dev.mysql.com/doc/refman/8.0/ja/json-function-reference.html   6. まとめ 今回、JSONと正規化表現の比較をMySQL8系で新しく追加された機能を交えながら説明させていただききました。 紹介していく中で、JSON型・正規化のそれぞれでメリットデメリットがイメージできたかなと思います。 元々5.7系でもJSON型は使えましたが機能の追加によって、より汎用性が高まったかなとも思いますので、メリット・デメリットを考えながらも使用していくのが良いかなと思いました！最後まで見ていただきありがとうございました！   The post MySQL8系にて強化されたJSONを活用しながら正規化と比較していく first appeared on Wedding Park CREATORS Blog .

こんにちは！新卒3年目エンジニアのtakadaです。 本日はWedding Parkの一部サービスが5.7系だったのをMySQL8系にアップデートした際に知ったtipsを紹介します！ ① RANKが予約語に MySQL8系からRANKが新しく予約語になりました。 予約語とは、言語の仕様で使い方が決められている単語のことでDB名・カラム名・エイリアスなどにて、そのまま記載すると下記のようにエラーが生じてしまいます。 もし既存でRANKを使用しているテーブルなどがありましたら注意が必要ですね…! 解消するためには、バッククォートで囲む必要があります。 今回はよく使いそうなRANKに着目致しましたが、他にも8系から予約語として追加されたものが多くあります。 詳しくは下記のドキュメントよりご確認ください！ https://dev.mysql.com/doc/refman/8.0/ja/keywords.html ② ウィンドウ関数にRANK()・DENCE_RANK()が追加 RANKが予約語となった理由でもありますが、 MySQL8.0.2よりRANK()・DENCE_RANK()というウィンドウ関数が追加されました。 どちらも対象のカラムの中で何番目の値かを返すことができる関数ですが、 RANK()は同じ値があった際に次の順位の値を飛ばした値にするのに対して、DENSE_RANK()は連続した値を用いて順位付けをします。 実際に下記のようなテーブルを使って見ていきます。 それぞれの商品において、値段より順位付けをしたい場合にRANK()・DENSE_RANK()を使います。 クエリ結果を見て頂くとわかりますが、 値段が同じ場合において順位の違いがRANK()とDENSE_RANK()にはあります。 同じ順位のものが複数ある場合、その後の順位に影響が出るか出ないかの違いとなります。 この2つ以外にも順位付けに使用できるROW_NUMBER()がありますので次に説明します。 ③ ウィンドウ関数にROW_NUMBER()が追加 こちら同じく順位付けに使用できるROW_NUMBER()。 上記のようなテーブルがあり、それぞれの商品において値段の安い順に連番を振りたい。 その際、下記クエリ文のように ROW_NUMBER()を使用することでシンプルに記載することができる。 また、カテゴリー毎に連番を振ることも可能でありクエリ文を記載すると以下のようになる。 RANK()・DENSE_RANK()と違い、同率の順位があったとしても同じ順位として結果を返さないようになっております。partition byなどを上手く使いながら活用していきたいですね！ ④ DATE型 (DATETIME型)と文字列の比較方法の変更 MySQL8.0.16よりDATE型(DATETIME型)と文字列の比較方法が変更されました。 MySQL8.0.15以下の比較手順 ・比較する文字列をDATE or DATETIMEに変換して比較 ・変換ができない場合、DATEを文字列に変換して比較 MySQL8.0.16からの比較手順 ・文字列をDATE or DATETIME型に変換して比較 ・上記ができない場合エラーが発生 (具体的なエラー文を下記に記載) 今までは、DATEを文字列に変換して比較することで上手くいっていましたが 比較手順の変更により上記のクエリ文のようにエラーが生じてしまいます…! DATE型の条件を入れる際は、記載方法に注意しましょう！！ ⑤ GROUP BYによる暗黙のソートがされなくなる 今まではGROUP BYをすることで暗黙に一定の並び順でソートされてましたが、 ソートがされなくなります。 具体的に示すと下記クエリ文のようにgroup byでソートした場合、 今までであればidは昇順で出力されていたが暗黙にソートされなくなってしまいます。 もし既存のコードで、GROUP BYのソートに頼ってしまっているものがあれば注意が必要です！ (GROUP BYをした後にfirst()でデータを取得しているなどなど、、) もし順番を固定したい場合、ORDER BYで指定する必要があります。 ⑥ CHECK制約による不正データ防止 MySQL8.0.16からCHECK制約が導入されました。 この制約は、データをINSERT・UPDATEする際に予めCHECK制約にて設定した条件を満たすかを検証する。満たさない場合はエラーとなるといった制約です。 例えば以下のテーブルがあったとします。 ・上記テーブルにおいて、値段が1000円以上の商品が挿入されることを防ぐようにしたい ・そのために、下記のようなCHECK制約をいれる その後、1000円以上するデータをINSERTしようとすると、、、 データを弾いてくれます！ これがあることで、もしアプリケーション側でデータを弾くことができなかった場合においてもSQL側でデータを弾くことができます！ ⑦ WITH句が追加 WITH句はサブクエリと似ていますが、 実行結果を一時的に仮想的なテーブルとして作成し、それをメインテーブルで 使用することができるといったものです。 例えば、下記テーブルにおいて各カテゴリー毎の売り上げを出力したい場合 下記のように、サブクエリを用いて記載するよりも可読性が高くなっています。 サブクエリによってクエリ文が複雑になっている箇所に、ぜひ活用していきたいですね！ ⑧ カラム毎にJSON型を扱えるように テーブル作成時にデータ型をJSONと記載することで、非構造化データをカラム毎に扱うことができます。 ここでは、基本的なテーブル作成・挿入・更新について記載します。 まずテーブル作成時は下記のようにデータ型をJSONに指定。 次にデータを挿入します。 上記のようにjson型でデータが挿入できていることが確認できます。 キー名検索・更新したい際は下記のようなクエリ文を記載。 その他できることがたくさんありますので、興味があれば是非調べてみてください！JSON型が上手く活用できれば、不必要なリレーション定義などがなくなり様々な所で活用できそうです！ ⑨ デフォルトのログイン認証方式変更 MySQL8.0.4より、デフォルトのログイン認証方式が下記のように変更されました。 mysql_native_password ⇨ caching_sha2_password caching_sha2_passwordは、暗号方式SHA-256を使った認証方式でキャッシュを使用することで再認証を高速化できます。 何度もmysqlにログインする場合、嬉しいですね！ ただ、注意して欲しいのは、caching_sha2_passwordに対応してない 言語を使用するときです。 PHP7.2.4より前のバージョンにおいては、caching_sha2_passwordに対応していないため、認証方式を設定する必要があります。 下記はクエリ文による認証方式の確認と更新方法です。 ➉ 不可視プライマリーキー機能が追加 MySQL8.0.30より、不可視プライマリーキーという機能が導入されました。 不可視プライマリーキーの設定をしている場合、 主キーが必須となり、ない場合は見えないカラムとして自動的にAUTO_INCREMENTのPKカラムを追加してくれます。 設定方法の確認↓ ※ デフォルトは0になっています。 オンにする場合は、下記クエリ文実行 基本的に、設定がオンの場合はNOT NULL + UNIQUE KEYがカラムに存在しても(主キーとなれるようなデータ構造だとしても)エラーが生じます。 ※ SourceでOFF・ReplicaでONの場合はプライマリーキーなしでテーブルを作成してもReplicaでは設定されません！ 以上がMySQLを8系へバージョンアップ時に知った主なTipsとなります！ MySQL8系に関してシェアできるナレッジがまた出てきましたら、こちらのブログにて記載致します！ まだまだMySQL8系にて変更されたことが多くありますので、 是非是非調べてみてください〜！ The post MySQL8系におけるTips10！ first appeared on Wedding Park CREATORS Blog .

こんにちは、さー（ @__south__373 ）です。 2024年2月にTECH戦略室という全社横断でエンジニア組織の成長にコミットするチームを立ち上げました。 なぜこのようなチームを立ち上げたのか、この半年何をしていたのか記録がてら書いておきます。 技術とデザインのウエディングパーク 弊社は経営理念「結婚を、もっと幸せにしよう。」、ビジョン「21世紀を代表するブライダル会社を創る」を掲げ、ウエディング業界×インターネット・デジタル技術の領域で事業を展開してきました。 現在は会社のロードマップとして「技術とデザインのウエディングパーク」を掲げて奮闘しています。 立ち上げのきっかけは10X会議 10X会議とは、ビジョン実現に向けて、会社を10倍成長させる提案をマネージャーがチームを組んで行い、経営が決断をするというウエディングパーク独自の取り組みです。 会社を10倍する提案を！「10X会議オンライン」を開催しました！ 私のチームでは、技術とデザインのウエディングパーク実現へ加速させることで会社を10倍に成長させられると考え、提案を吟味しました。 少し歴史を遡ると、かつてはシステム本部という全社横断部署があり、全エンジニアが所属をしていましたが、事業の数が増えるに従ってエンジニアは各事業部に配属されていくようになりました。そのため、各事業部の方針に沿ったアクションスピードは上がったものの、全社で見たときに強化すべきポイントが明確でなかったり、投資を行うことがなかなかしづらい状況になっていました。 会社として「技術とデザインのウエディングパーク」へ加速をさせるためには、事業部単位ではなく横断的に組織をどう育てていくかを考える必要があると思い、全社横断でエンジニア組織の戦略を考え実行するTECH戦略室の提案を行いました。 昨年の10月からBTOとして、技術とデザインのウエディングパークを創るために活動をしてきましたが、メインミッションはRingraphという別の事業にあったためなかなかパワーをかけきれないと感じ、専任でのコミットをすべきだという思いもありました。 ウエディングパークに生まれた新しい役職「BTO」「BDO」って何？ 10X会議の後にBTOとしてもTECH戦略室をプッシュし、無 事に採用が決定。提案から約1ヶ月後、2024年2月にTECH戦略室を立ち上げることになりました。 半年の取り組み 立ち上げから半年の間、大きくは3つ取り組んできました。 エンジニア組織の指針・ロードマップ作成 育成体制の強化 開発生産性PJの立ち上げ 1. エンジニア組織の指針・ロードマップ作成 TECH戦略室が立ち上がる少し前に、「技術とデザインのウエディングパーク」とはどういう状態なのか、経営チームと解像度を上げる合宿を行いました。そこでの議論の結果、技術とデザインのウエディングパークとは クリエイターがデザイン思考x具現化力を武器に事業成長をリードすること であるとされました。 エンジニアとデザイナーが、物事の本質を捉えるデザイン思考とカタチにする具現化力を持って事業成長に貢献ではなく、その上段であるリードするという状態になれていることが必要だということです。 これを受けて、まず最初に事業成長をリードできるエンジニア組織になるための方針とロードマップを策定しました。 会社のビジョンから落とし込んだ上で、事業成長をリードできるエンジニア組織をどう目指すかを言語化していった形です。 TECH戦略室のメンバーでブレストをしながら、経営陣や他のエンジニアとの壁打ちも踏まえて3本の柱を仮策定し、その後エンジニア全員でワークを行って指針として磨き上げました。 最終的に出来上がったのが、ENGINEER LOAD STAR（エンスタ）です。 SOUZOU、Change Ready、X PROを共通言語として様々な取り組みを推進していくことになります。 出来上がるまでのプロセスや込めた想いはまた別のブログで綴ろうと思います。 2. 育成体制の強化 事業成長をリードするエンジニア組織を創っていくために、育成という要素は欠かせません。 これまでの組織体制ではエンジニアではない職種の方が上司になったり、自分のチームにはエンジニアが1人なんてこともありますが、若手のうちは特に先輩から技術や考え方を盗んだり、どういったスキルアップを目指していくのかを設計しながらミッションと紐づけていくことが重要だと思っています。 しっかりスキルアップをしていくこと、その再現性が作れる取り組みとして、育成メンター制度をスタートさせました。 他にも、若手を対象としたキャリアを考えるためのスキル可視化やGrowth Mapという成長プロセスを考える取り組み、中堅層を対象にしたキャリア面談など足元だけでなく2、3年先を見据えたアクションも増やしています。 3. 開発生産性PJの立ち上げ 弊社では現在、デザイン経営で成果を出すという戦略を取っています。開発をして世の中にリリースするだけではなく、その先の成果がしっかり出るまで繰り返し変化を加えていくことが重要です。 一発で100点を取るのではなく、社会と対話をしながら少しずつ100点に近づけていくイメージです。 そのためには、素早くサービスを世の中に届けられるということが価値になってきます。開発チームのパフォーマンスはなかなか数値にしづらいものですが、FourKeysやSPACEなど開発生産性の考え方が広まっているので弊社でも取り入れられそうだと考え企画提案を行いました。 7月から一部のチームにFindy Team+の導入をスタートしており、徐々に全社に展開していく予定です。 最後に 技術とデザインのウエディングパーク、つまりクリエイターが事業成長をリードするという状態はとてもレベルの高いことだと感じています。 ですが、デザイン経営でビジョン実現をさせるには欠かせない要素だと信じていますので必ず成し遂げたいと思っていますし、そのために奮闘をしています。 今回は概要をメインでまとめましたが、詳しい内容についても順次言語化していきたいと思います。 The post TECH戦略室を立ち上げて半年を振り返る first appeared on Wedding Park CREATORS Blog .

こんにちは！新卒エンジニアのshimatsuです！ 今回は、私が人生初の外部登壇をしたお話をお伝えしたいと思います。 最後に登壇資料も掲載しておりますので、ぜひご覧ください！   初登壇の舞台は 今回参加させていただいたのは、6月14日（金）に行われました “表参道ゆるmeet up” 。 表参道にオフィスを持つ、株式会社ウィルゲートさん、Sansan株式会社さん、そして弊社の3社で主催する、ゆるっと情報交換ができる場です。 実は登壇のお話をいただいたのは本番の1週間前で、絶賛研修中でしたのでタスク的に間に合うかという心配もありましたが、周りの方の支えもあって無事に発表準備が整いました。 ここからは、実際に発表した内容をエピソードも含めてお話します。   登壇で伝えたかったこと 私は大学でプログラミングをがっつりやっていたわけではなかったので、ほとんどスキル0からの入社。 当初エンジニアという職種に対して、「エンジニアって覚えることたくさんで大変だろうな」「8時間ずっとコード書いてるのかな」というイメージを抱いていました。 ですが、研修期間を通してそれはまったく違っていたのだと分かりました。   まず、「覚える」よりも「調べる」ことが大切だとわかりました。 もちろんすべての知識が頭に入っていたら理想ですが、そうもいかない程プログラミングの世界は広かったのです。 そして今の時代、調べたらわかってしまうことが意外と多いのです。これはプログラミングだけでなく、普段の生活でも感じることだと思います。 ささっと調べてコードを書けるのと、必死に覚えて自分の知識をもとにコードを書くのとでは、コスパが違いますね。 とくに新卒となるとその他のタスクもある中なので、コスパが良い動き方をするのが大切です。   また、調べた上で、わからなかったものを上司に質問するというのもとても大切です。 自分に寄り添ってくださるので、理解しやすいという利点もあります。 ですが、その先輩も時間が無限にあるわけではありません。自分でできる範囲を広げていくことが必要になってくるのです。   次に「コードに魂を宿す」ことが大切だとわかりました 。 先ほど調べるのが大切とお伝えしましたが、調べた先のコードをそのままコピペしていませんか？ 私は大学時代によくやってしまっていました。 ですが、コードの1行1単語をしっかり理解して、自分のコードに必要だと意志を持って参考にすることが大切なのです。 じゃないと、無駄なコードが増えてしまったり、レビュー時にコードを書いた考えを問われた際に答えられなかったり、と悪影響だらけです。   エンジニアは「考えて」コードを書いています。 そのため、コードを書く時間より考えている時間のほうが長かったのです。 （他職種のみなさま、手を動かしていなくても我々はしっかり仕事しているのです。むしろこれが本質の仕事で、サボっているわけではないですよ。）   これらを踏まえて、私はあることに気づきました。 「覚えることたくさん」「ずっとコード書いてる」このようなイメージは、AIでもできますよね。 私たち人間がやるべきなのは 「調べて、考えて、魂の宿ったコードを書くこと」 ではないでしょうか？ これに入社3か月で気付けたのは、とても良い環境で過ごせたからこそだなと感じています。 これから本配属となり、実務を経験していく中で、どんな状況においてもこの考えを常に心に置いておこうと思います。   最後までご覧いただき、ありがとうございました！ こちらが登壇資料です！みなさまの小さなお力になれましたら幸いです。 https://speakerdeck.com/shimatsu_wakana/xin-zu-enzinianibi-yao-nali   The post 新卒エンジニアが人生初登壇したお話 first appeared on Wedding Park CREATORS Blog .

こんにちは。新卒1年目エンジニアのyokochiです。 この記事では、研修期間中に経験した「調査・設計の前に開発をしてしまった」というしくじりについて書かせていただきます。この経験が誰かの参考になれば幸いです。 目次 しくじり概要 経緯 結果 学んだこと まとめ しくじり概要 私のしくじりは「調査・設計の前に開発をしてしまった」ことです。 研修中は以下のようなフローで案件をリリースまで進めることが求められていました 案件オリエンテーション 調査（影響範囲調査） 設計 設計レビュー 開発 コードレビュー （省略） リリース 案件オリエンテーションでディレクターから仕様を聞き、エンジニアがコード上で現在の仕様を調査し、改修内容に基づいて開発計画を設計書にまとめます。その後、先輩エンジニアによる設計レビューを経て開発に進みます。 このフローを理解していながら、私は開発を先行してしまいました。結果として、予定していたスケジュールから遅れ、苦労することになり、先輩の手を煩わせることにもなりました。 経緯 開発を先行した理由は以下の通りです 調査・設計の意義を感じる機会が少なかったこと 設計レビューに完璧な設計書を出したかったこと   調査・設計の意義を感じる機会が少なかったこと 以前の案件では、開発経験のある分野や影響範囲が小さい案件を担当していたため、調査・設計にあまり時間をかけずに開発を進めていました。正直なところ、「どうせコードを書けば分かることだ」という傲慢な考えを持っており、調査・設計の重要性を軽視してしまっていたのです。今思えば、とても危険な考え方でした。 設計レビューに完璧な設計書を出したかったこと 私は、細部まで記載された完璧な設計書を作成することが、レビュワーにとってもその後の開発にとっても最良だと考えていました。「完璧な設計書さえあれば、スムーズに開発できるはずだ」という思い込みもあり、細部まで詳細に記載された理想の設計書を作ろうと必死でした。結果的に、本来の目的を見失ってしまったのです。   結果 この行動による影響は以下の通りです 設計が終わらず、当初のレビュー日程を延期 開発もうまくいかず、調査・設計も疎かに   設計が終わらず、当初のレビュー日程を延期 開発に注力していたため、影響範囲調査などを後回しにしていました。また、未経験の技術の学習に時間がかかり、進捗が思うように出ませんでした。結果、レビュー日程の延期を余儀なくされました。 開発もうまくいかず、調査・設計も疎かに 開発と並行して設計書を作成しようとしたため、開発が進まなければ設計書も完成しないという状況に陥りました。最終的に、開発を中断して調査・設計に集中せざるを得なくなりました。   学んだこと この経験を踏まえ、これから案件に携わる時の心得は以下です。 調査・設計 → 開発 設計レビューは議論の場である コードの改修についてはコードレビューで議論   調査・設計 → 開発 このフローを軽視したことを深く反省しています。調査・設計の段階で十分な時間を取ることで、開発時の混乱や手戻りを大幅に減らせることを身をもって学びました。「急がば回れ」というのは、まさにこのことだったのだと痛感しています。 設計レビューは議論の場である 設計レビューの本質は、チームで知恵を出し合い、より良い設計を作り上げることだと理解しました。完璧を追求するあまり、議論の機会を失うことは本末転倒です。今では、疑問点や懸念事項を率直に共有し、先輩方の知見を積極的に採り入れることの重要性を強く感じています。 コードの改修についてはコードレビューで議論 設計書に凝りすぎて、本来のコードレビューの役割を奪ってしまっていたことに気づきました。設計書は全体の構造や流れを示すものであり、細かなコードの実装はコードレビューで議論すべきだったのです。この区別を理解できていなかった自分の未熟さを痛感しています。 まとめ この経験は、新人エンジニアとしての私に大きな気づきをもたらしました。プロセスの重要性、チームワークの大切さ、そして自分の未熟さを謙虚に受け止める必要性を学びました。今後は、この教訓を胸に刻み、より慎重かつ効率的に業務に取り組んでいきたいと思います。失敗を恐れずに、常に学び続ける姿勢を大切にしていきます。 The post 【新卒エンジニアしくじり話】調査・設計の前に開発をしてしまった失敗から学んだこと first appeared on Wedding Park CREATORS Blog .

こんにちは。 Photorait エンジニアのヒエイです。 6月22日に行われたPHPカンファレンス福岡2024に参加・登壇してきました！ https://phpcon.fukuoka.jp/2024/ 本記事は参加と登壇レポになります。 福岡ではじめての技術カンファレンス参加 福岡には遊びに来たことはありましたが、はじめて福岡での技術カンファレンス参加、そして登壇するのでとてもワクワクしていました。 写真は会場のファッションビル福岡 受付を済ませ、ネームカードをもらいます。 イン！ #phpconfuk pic.twitter.com/q0fyHgyevJ — チャン (@zosokh) June 22, 2024 ネームカードには技術スキル・自己紹介のシールをペタペタ。参加者は皆さん思い思いのネームカードに仕上げていました。 セッションが行われるホールを下見。 Fusicホール ホライズンテクノロジーホール アンカンファレンス用のホールやスポンサーブースもたくさんの人が賑わっていて、PHPカンファレンスにある「お祭り感」が朝から感じられました。 登壇時間は15:55からですので、沢山のセッションを聞きながら楽しみたいと思います。 聞いたセッション 並行処理を学びGuzzleと仲良くなる by しまぶ https://fortee.jp/phpcon-fukuoka-2024/proposal/51673a42-739c-4509-8c9c-fe5976c33403 プロジェクトマネジメントとは？　経験から学ぶ視野と視座 by なおと https://fortee.jp/phpcon-fukuoka-2024/proposal/eb2e25af-3437-4a7f-9cee-a0f67d112bd5 10社以上のCTO/技術顧問を経験して見えた、技術組織に起こる課題と対策 by 大谷 祐司 https://fortee.jp/phpcon-fukuoka-2024/proposal/bdf2f1de-82f0-4468-989a-cb1fb70263c1 なぜキャッシュメモリは速いのか by 長谷川智希 https://fortee.jp/phpcon-fukuoka-2024/proposal/d0cb4940-cdf5-4f8b-912e-6a6823c584af 書き込み処理をスケールさせるために必要な非同期処理の基本と考え方 by 曽根 壮大 https://fortee.jp/phpcon-fukuoka-2024/proposal/c0e780cd-3949-4b0c-bf57-3f6395e9a779 リモートワーク時代の守護神：PHP開発者のためのセキュリティ強化術 by P山 https://fortee.jp/phpcon-fukuoka-2024/proposal/a07193dd-19f1-453b-b607-11bb8b625306 WebサイトのXSS脆弱性絶対転がす ―Content Security Policyのすすめ― by 小川 https://fortee.jp/phpcon-fukuoka-2024/proposal/b0fba8ae-1264-4533-b2dc-4ffc03f738f4 約半年かけてPHP5.6からPHP7.4までバージョンアップした苦労と工夫 by けちーん https://fortee.jp/phpcon-fukuoka-2024/proposal/83f31e89-1286-4d6a-b015-c46382a6b14e PHPでデータベースを作ってみた by 富所　亮 https://fortee.jp/phpcon-fukuoka-2024/proposal/0ef7de0b-4b2b-4b04-bde5-94fc5b43b868 設計の考え方 – インターフェースと腐敗防止層編 by おかしょい／岡田 正平 https://fortee.jp/phpcon-fukuoka-2024/proposal/25f1e7b5-937f-4de9-a6de-b78fc9efd71c PdMから見た「スーパーエンジニア」の思考と行動 by 今福 正雲 https://fortee.jp/phpcon-fukuoka-2024/proposal/bc249ebb-72ad-49d3-b506-d75108626d09  【超特急】「SQLアンチパターン」 総おさらいLT 【5分で25個】 by つざき https://fortee.jp/phpcon-fukuoka-2024/proposal/9bd3b229-ee21-4e5d-9420-328279b1d615 FuelPHPからLaravel移行が遂に終わった！最初にやっておきたかったこと５選 by 桝井裕哉 https://fortee.jp/phpcon-fukuoka-2024/proposal/4677c8c1-3f72-4d08-abb7-c292d85dfc35 ゼロから始める型安全なGraphQL開発 with Laravel + Lighthouse + TypeScript by シャチ子 https://fortee.jp/phpcon-fukuoka-2024/proposal/cda42888-d1fc-44db-a315-4efe46bd73c8 凝集性から考えるLaravelのmiddleware、routingに書くか？ Policyに書くか？ by NobleNomad https://fortee.jp/phpcon-fukuoka-2024/proposal/8c783420-ecec-48b2-8f1e-830ee3766117 倒して、倒して、倒しまくれ！―PHP＆Laravelのバージョンアップの戦い― by ことみん https://fortee.jp/phpcon-fukuoka-2024/proposal/00be89ee-922c-43a1-bdcf-71bcda01c4c6 どのセッションも勉強になることが多く、発表スタイルもバラエティ豊かで楽しく聞いていました。 セキュリティやリプレイス・設計の話が多かった気がします。セキュリティは昨今の攻撃ニュースでもありますようにサービス運営エンジニアとして一層引き締まる気持ちを持っていましたし、リプレイスは私自身の登壇テーマとリンクする内容でもありました。 1セッション自体が短いので多くのセッションを聞く事ができました。セッション間の転換時間がほぼ0なので他セッションやタイムテーブルに気を逸らす事なく次セッションに集中できるところが新鮮でした。1日でこんなに沢山の情報インプットできたのはとても嬉しかったです。 登壇 Photoraitで取り組んでいる、システムリプレイスの話をしました。提案から設計の話、リプレイスの効果についてまとめました。 https://fortee.jp/phpcon-fukuoka-2024/proposal/61dbecde-03f0-44a1-bf70-63564d2dfcd8 沢山の人に見に来ていただき、スタッフさんも親切にサポートしていただき、楽しみながら発表を終えることができました。 チャン @zosokh さんのトークがはじまっています #phpconfuk #hall_fu https://t.co/HixA732pib pic.twitter.com/w5teeFcOQc — PHPカンファレンス福岡 公式 (@phpcon_fukuoka) June 22, 2024 写真は発表直前のステージから見た会場です。 ask the spekerでも質問していただきありがとうございました。 ＼CホールにてAsk the speaker 開催中 ／ おかしょいさん @okashoi と、02さん @tadsan と、チャンさん @zosokh と、sora さん @_fs0414 と、とうださん @picopico_dev と、Kanon さん @samurai_se に質問したい方はCホールへ 珈琲片手に、お気軽にお越しください #phpconfuk pic.twitter.com/KFEBskbbqZ — PHPカンファレンス福岡 公式 (@phpcon_fukuoka) June 22, 2024 ask the speakerを経ての補足 いただいた質問： 資料内の、新・旧基盤での工数見積もりはどのように作成しましたか？ A： このグラフは非常に作成は難しかった部分ですが、 旧基盤は存在するアプリケーション上で工数見積もり 新基盤はまだアプリケーション無い状態だったのであくまでも見積もりですが、他にも同じようなシステム構造でアプリケーションを立ち上げた基盤があったので、そのシステム上での開発経験から工数を割り出し という形で答えさせていただきました。結果的に提案時と同じような工数差になったのは良かったと思っていますが、ここまで分かりやすくリードタイムに差が出てくるとは最初思っていませんでした。全面リファクタリングやテストコード整備にから、やはり開発効率化される事はあるんですね。 質問いただきありがとうございました！ 閉幕 PHPカンファレンス福岡すごく楽しかった！ 聞きに来ていただいた方、運営スタッフ皆様、びきニキさん、ありがとうございました！ #phpconfuk pic.twitter.com/GvlBRSU47Z — チャン (@zosokh) June 22, 2024 300名近くが参加したカンファレンスだったとのことで、非常に熱量が高く、温かい空気の流れるワイワイしたお祭りでした。中でも印象的だったのが、PHPカンファレンス福岡に初参加勢が私以外にも多く、カンファレンスへの興味が沢山寄せられている事やベテラン勢から新たな参加者へ興味を引き寄せあっている事が良いなと感じました。このブログも新たな関心を少しでも作れたら嬉しいです。 また来年もあるなら是非出たいです！皆さんお疲れ様でした！発表も聞きに来ていただきありがとうございました！ さいごに、福岡の食 串にぐるぐる巻いたパリパリ鶏皮、うどん、ごまさば、博多ラーメン、全部が美味しすぎました。むしろ美味すぎて、びっくりしました。またいきたいです！ 昼に食べたうどん #phpconfuk pic.twitter.com/U5zUxOT6Eb — チャン (@zosokh) June 22, 2024 The post PHPカンファレンス福岡2024に登壇してきました first appeared on Wedding Park CREATORS Blog .

こんにちは！新卒エンジニアのs0ush1nです。 現在は研修期間として、社内の理解から使用する技術のハンズオン、実践的な開発作業まで多岐に渡り学んでいる最中です。 現在さまざまなことに取り組める機会をいただいている中で、 今回は「 何を取り組めばいいのか迷ってしまった自分が、守破離の考え方をとりこんで方向性を見つめ直し取り組むまでの記録 」 についてお伝えしたいと思います。   学生の方や、現在進行で研修を受けている他の新卒一年目の方に向けて「入社してすぐの期間は何をすればいいんだろうか？」と悩まれている方への参考になれば幸いです。   目次 研修期間の取り組み 焦りからの乱れ 先輩社員に教えていただいた”守破離” 型を守ることの大切さ 今やるべきことは何なのか まとめ・今後の目標 研修期間の取り組み 入社して1か月近くは人事研修から始まり、社内の概要から業界の知識、仕事の流れについて知る機会をいただきました。 その後の2か月は職種別の研修となり、エンジニアは2か月間で基礎とOJTに取り組み、リリースにも関与できる機会があります。 カリキュラムとしては日々のインプットに加えて、随時行われるチーム型の研修や日々の取り組みで表彰や優勝者を決めるものがあり競い合いつつお互いを知り、能力を高めていく環境として取り組んでいきました。   焦りからの乱れ 取り組みを進める中で必ずしもうまくいくというわけではなく、表彰されないことが続いたり、自分が研修の中の取り組みで力になれないという期間が続きました。 さまざまな研修を経て会社貢献を意識する中で、”とにかく実績を作り早く1円以上の価値を生み出したい”という思いがある中、もどかしい日も多々ありました。 何よりも表彰されることが価値だ！と考えたときはとにかく発展したことにトライしてみたり、何よりも期待を裏切らないように頑張ろう！と考えたときは自分の体力の限界までひたすら作業をしてみたりと、自分なりの取り組みを重視した期間があり、私は明確に焦ってしまいました。 そんな取り組みを重ねても表彰に至れず「何をしても私はうまくいかないのかもしれない」と考えが乱れる期間もありました。   先輩社員に教えていただいた”守破離” 暗中模索になっていた時、先輩社員に 「成果と目標のギャップがあったとき、メンタルの保ち方や考え方で大事なスタンスは何か？」 というテーマで相談したことがありました。 そこで得られた回答として、一番印象に残った言葉が” 守破離 ”です。 守破離とは、以下の意味があります。 剣道や茶道などで、修業における段階を示したもの。「守」は、師や流派の教え、型、技を忠実に守り、確実に身につける段階。「破」は、他の師や流派の教えについても考え、よいものを取り入れ、心技を発展させる段階。「離」は、一つの流派から離れ、独自の新しいものを生み出し確立させる段階。   出典：デジタル大辞泉（小学館）   転じて、ビジネスでもこの言葉は扱われています。 「守」は会社のルールを覚え業務に取り組むこと、 「破」は業務をよりよくしていくこと、 「離」は自分から新しいものを提案することとされ、 それぞれのプロセスを踏んでいくことに置き換えられます。 今自分が迷っていることは、方向性が確立していないものであり基盤を固めずに発展したことに挑戦しているからこそ、漠然とした不安を抱えているのではないか？と提言していただくことで立ち位置が理解できました。   型を守ることの大切さ 型があることのメリットとして、やることがはっきりしています。 これらに取り組み、覚えることが正しいことであり、会社の戦力として早く能力を高められ、 何のために我々は働いているのか知り会社の理念やビジョンを理解することにも繋がります。 何をすべきかを理解せずに発展的なことに取り組んでも、会社とは異なる方向性の努力であればもちろん評価されません。 （これを”型無し”と呼ぶそうです。) 与えられたことに意図を理解して取り組み、型を守ることでステップアップができるのではないかと感じました。 私も五月中盤からは表彰第一！ではなく型を守る意識に変わり、 今自分に求められていることにしっかりパフォーマンスを出した結果、OJTにて月間5件のリリースに関与し、部署内表彰のルーキー賞をいただきました。 積極的な取り組みと発信量・基盤固めの取り組みなどを評価していただきました！   今やるべきことは何なのか・今後の目標 今後も守破離のマインドを意識し、やるべきことを守り、自分だからこそできる型破りで存在感と成果を出していきたいと思います。 私の場合は新卒でもためらわず手を挙げる意識で、毎日話を聞いて質問をしたりすることを+αとして取り組みたいです。 焦らずに力をつけ、自分の色も出していくことが今やるべきことではないかと感じています。   まとめ やりたいことが漠然としていたものの、守破離を知り方針が決まったた今やることも明確になった 発展的な内容がうまくいかないときでも、できていることに目を向けられるようになった 研修期間は新入社員が組織の文化や価値観を理解し、仕事における期待や役割を明確に把握する期間である。目標を理解し、行動を逆算して基礎を固めることで今後の仕事により力を入れて成果を出していける 自分が焦らず成長するために、守破離という言葉を意識した！ 最後に 以上、新入社員の研修期間の取り組みや表彰いただくまでの紆余曲折について紹介しました。 楽しいことも悔しいこともある中で、社会の一員として挑戦できているという経験は貴重なものです！ 研修期間のリアルが少しでもお伝えできましたら幸いです。   The post 新卒研修で守破離の言葉を意識したら、不安が払拭されて部署内表彰に至った話 first appeared on Wedding Park CREATORS Blog .

こんにちは！エンジニアのヒビキ( @hibiki_cube )です。 最近技術調査をする機会があり、その一環でiPhone / iPad向けにARアプリを開発してみました。 せっかく色々知識をつけることができたので、誰かのお役に立てればいいなと思いつつ開発の一連の流れをまとめておこうと思います。 できるだけ最近の技術や書き方を使って開発するようにしたので、新しく開発するときでも参考にしやすいのではないかと思います。 今回の記事ではプロジェクトを作った後、画面をタッチして自分で用意した3Dモデルを表示できるアプリを作ってみます。 目次 環境を準備する プロジェクトを作る 自分の3Dモデルを表示する タップした場所にモデルを表示する 画面のタップで処理を実行する AR空間の座標を取得する モデルを表示する まとめ 環境を準備する まずは開発のための環境から用意していきます。 例外もありますが、基本的にiPhoneアプリの開発はMacで行います。 それ以外にも専用のアプリのインストールなど必要な準備があるので、まずは環境から準備していきます。 iPhone / iPad向けにアプリを開発するには最低限以下の環境が必要です。 Mac Xcode（IDE） 快適に開発をするにはmacOSとXcodeは最新のものが使えると良いです。 また、AR機能のデバッグはシミュレーターではできないのでAR機能に対応する実機もあるとさらに便利です。 その場合の環境は以下の通りです。 最新のmacOSに対応しているMac 最新のXcode A9以降のチップを搭載したiPhoneまたはiPad 2015年以降に発売されたiPhone 2017年以降に発売されたiPad miniまたは2015年以降に発売されたiPadシリーズ Appleが提供しているAR開発用のフレームワークであるARKitはA9以降のチップが動作要件なので、このような条件をつけています。 周辺環境の高度な認識など、よりリッチな体験を実現したい場合はLiDARセンサーを搭載したデバイスの利用をお勧めします。 なお、この記事では以下の環境を前提としています。 MacBook Pro (16インチ, 2021), Apple M1 Maxチップ macOS Sonoma 14.5 Xcode 15.4 iPhone SE (第 3 世代) iOS 17.1.2 プロジェクトを作る まずはアプリを開発する場所となるプロジェクトを用意します。 Xcodeを起動して 「Create New Project」 を選んで新しくプロジェクトを作ります。 プロジェクトのテンプレートを選ぶ画面が出てくるので、プラットフォームは「iOS」のままで 「Augmented Reality App」 を選んで 「Next」 をクリックします。 これによってXcodeがARアプリ用の基本的なコードを準備してくれます。 次にChoose options for your new projectというモーダルが出てくるので、 「Product Name」 , 「Team」 , 「Organization Identifier」 をそれぞれ入力し、 「Next」 をクリックします。 そのあとはプロジェクトを保存する場所を選択するよう促されるので、任意の場所を選びます。 このような画面が出たらプロジェクトの作成は完了です。 このままアプリをビルドして実行すると、以下のように一番近くの平面上にグレーの立方体が表示されるようになります。 デフォルトのままでも、立方体の表面の写り込みに実際の景色が反映されていたり、立方体の影が実際の机にも反映されていたりします。 自分の3Dモデルを表示する プロジェクトのデフォルトのサンプルコードでは立方体が表示されるようになっていますが、これを任意の3Dモデルに置き換えてみます。 まずは使うモデルを用意する必要があります。 Blenderのような3Dモデリングのソフトや、Appleが無料で提供しているReality Composer Proなどを使ってUSDZ形式のモデルを用意してこのプロジェクトに追加しておきます。 今回は社内にあった公式キャラクターの「ウエパ」のぬいぐるみを3Dスキャンしてモデルを用意しました。 まずはこのモデルを読み込む処理から書いていきます。 ARViewContainer の中で定義されている makeUIView メソッドの中にある以下の処理を // Create a cube model let mesh = MeshResource.generateBox(size: 0.1, cornerRadius: 0.005) let material = SimpleMaterial(color: .gray, roughness: 0.15, isMetallic: true) let model = ModelEntity(mesh: mesh, materials: [material]) model.transform.translation.y = 0.05 次のように書き換えます。 // Load my model let model = try! ModelEntity.loadModel(named: "wepa") なお、このコードで "wepa" としている部分は自分が使うモデルのファイル名に合わせて適宜変更してください。 この時点でのコードはこんな感じになります。 この ModelEntity.loadModel() メソッドは指定した3Dモデルを読み込む関数で、もしモデルが見つからないとエラーになってしまいます。 ただ、今回は動的にモデルを取得したりするわけではなく常に自分が用意したモデルを読み込むので、冒頭に try! とつけてエラーになったときの処理を省略しています。 この状態でアプリをビルドして実行すると、このように自分で用意したモデルが表示されるようになります。 タップした場所にモデルを表示する このままのAR体験も悪くはありませんが、まだまだ改善の余地があります。 例えば、今のままだと3Dモデルは認識された平面のどこかに自動的に表示されるようになっています。 自分の思った場所に配置できるわけではないので少し不便です。 この問題を解決すべく、画面をタップしたらその位置に3Dモデルが表示されるようにしてみます。 なお、今回の例では特にコードの分割などは行わず1つのファイルにギュギュッとまとめて書いています。 通常であれば機能ごとに分割したり関数にまとめたりするのですが、今回はしていませんのでご注意ください。 画面のタップで処理を実行する 画面をタップしたらその位置に3Dモデルが表示される の動作を実現するには、まずは画面タップに応じて処理を実行できる必要があります。 Swift UIでタップ操作を扱うには、Viewの .onTapGesture() メソッドを使います。 このメソッドのクロージャの中でさまざまな処理を行うことで、ユーザーはタップで画面を操作できるようになります。 ここでいう”View”は今回の例では ARViewContainer が該当するので、コードは以下のようになります。 var body: some View { ARViewContainer(arView: arView) .edgesIgnoringSafeArea(.all) .onTapGesture(coordinateSpace: .global) { location in // ここに色々処理を書く } } このあとの処理で画面上のタップした位置の座標が必要なので、そのための書き方をしています。 .onTapGesture(coordinateSpace: .global) { location in  とすることで、画面の原点からの座標を location という名前の引数として取得しています。 ちなみにこのときの”原点”は画面の左上です。 AR空間の座標を取得する 先ほどの処理で取得した「タップした位置の座標」は2次元の座標なので、そこにそのまま3Dモデルを配置することはできません。 なので次はこの2D座標の情報をもとに、AR空間の3D座標を取得します。 このような処理を実現するには、 ARView の makeRaycastQuery() メソッドを使います。 このメソッドを使うと、画面上の指定した点からAR空間の中に擬似的にレーザー光線を飛ばします。 その光線が床やテーブルなどの平面に当たると、その位置の3D座標を取得することができます。 これを実際にコードに落とし込んでみると、以下のようになります。 ARViewContainer(arView: arView) .edgesIgnoringSafeArea(.all) .onTapGesture(coordinateSpace: .global) { location in guard let query = arView.makeRaycastQuery( from: location, allowing: .estimatedPlane, alignment: .horizontal ) else { return } guard let result = arView.session.raycast(query).first else { return } } まず19~23行目で擬似的なレーザー光線の飛ばし方を指定しています。 この場合だと、発射地点を先ほど取得した「タップした位置の座標」にし、さらに水平な面だけを検出するように絞り込みをしています。 次の25行目では実際に平面との当たり判定を行なって、結果の3D座標を取得しています。 モデルを表示する 最後に、3Dモデルを配置する処理です。 この部分はこれ以前に使っていたコードが流用できそうです。 ARViewContainer(arView: arView) .edgesIgnoringSafeArea(.all) .onTapGesture(coordinateSpace: .global) { location in guard let query = arView.makeRaycastQuery( from: location, allowing: .estimatedPlane, alignment: .horizontal ) else { return } guard let result = arView.session.raycast(query).first else { return } let model = try! ModelEntity.loadModel(named: "wepa") let anchor = AnchorEntity(world: result.worldTransform) anchor.addChild(model) arView.scene.addAnchor(anchor) } 中盤で登場した ModelEntity.loadModel() メソッドで3Dモデルを読み込んだあと、先ほどの処理で得られた3D座標の位置にモデルを配置しています。 ここまでのコードに加えて、不要な部分の整理やエラーの解消なども行うと、最終的なコードはこのようになります。 コード全文はこちらをクリック // // ContentView.swift // Demo // // Created by ヒビキ on 2024/06/17. // import SwiftUI import RealityKit struct ContentView : View { let arView = ARView(frame: .zero) var body: some View { ARViewContainer(arView: arView) .edgesIgnoringSafeArea(.all) .onTapGesture(coordinateSpace: .global) { location in guard let query = arView.makeRaycastQuery( from: location, allowing: .estimatedPlane, alignment: .horizontal ) else { return } guard let result = arView.session.raycast(query).first else { return } let model = try! ModelEntity.loadModel(named: "wepa") let anchor = AnchorEntity(world: result.worldTransform) anchor.addChild(model) arView.scene.addAnchor(anchor) } } } struct ARViewContainer: UIViewRepresentable { private(set) var arView: ARView func makeUIView(context: Context) -> ARView { return arView } func updateUIView(_ uiView: ARView, context: Context) {} } #Preview { ContentView() } なお、AppDelegate.swiftはテンプレートで生成されたものをそのまま使っています。 この状態でアプリをビルド&実行すると、このようにタップした位置に3Dモデルが表示されるようになりました。 document.createElement('video'); https://engineers.weddingpark.co.jp/wp-content/uploads/2024/06/iphone-tapToPlaceRe.mp4 まとめ テンプレートのコードをベースに、ステップバイステップでSwift UIとRealityKitでARアプリを作ってみました。 タップした位置を判定する処理などもシンプルに実装したので、うまく伝わっているといいなと思います。 今回の技術検証によって、ネイティブアプリの開発の一連の流れからARアプリ特有のノウハウまで、さまざまな知見を得ることができました。 空間コンピューティングは今後ますます盛り上がっていく分野だと思うので、今後もキャッチアップを続けていきたいと思います。 お読みくださったみなさんも、ぜひARアプリの開発に挑戦してみてください！ The post Swift UIとRealityKitでARアプリを作ってみた first appeared on Wedding Park CREATORS Blog .

こんにちは。sugoです。 今回は、Laravelクエリビルダの学習 第二弾となります。 前回はChatGPTにSQLを出してもらい、クエリビルダに変換し学習を行いました。 Laravelのクエリビルダの勉強をするために、ChatGPTを使って学習してみた より数をこなし、理解を深めるために、MySQLの新卒研修に使っているSQLをクエリビルダに変換してみました。 Laravelのクエリビルダの学習を行っている方に、少しでも参考になればと思います。 背景 まずは、なぜ今回の記事を書こうかと思ったかを説明します。 私は現在、PHPのフレームワークであるLaravelを使用しています。 しかし、Laravelでのデータ取得処理については、クエリビルダかEloquentかを選ぶ段階で、調べないと読み書きできないレベルでした。 そこで、前回の記事にて、ChatGPTを活用して、基礎的な部分の学習を行いました。 今回は、基礎を固めて実践できるように、LaravelでMySQLの問題を解いたときのことを記事にしました。 学習の進め方 ウエディングパークでは新卒研修で、DBとは何かから始まり、実際にSQL文を読み書きして学んでいくMySQL研修があります。 研修の中で、さまざまなSQL文が問題として用意されているので、そのSQLをクエリビルダに変換し、学習を行うことにしました。 なので、今回の記事はSQL文をどんどんクエリビルダに変換していきたいと思います。 問題1 「食品テーブルの食品タイプIDが3の食品タイプ名, 食品名の一覧」 SELECT ft.name, f.name FROM foods f INNER JOIN food_types ft ON f.food_type_id = ft.id WHERE f.food_type_id = 3; SQLをクエリビルダに変換します。 DB::table('foods as f') ->select('ft.name as food_type_name', 'f.name as food_name') ->join('food_types as ft', 'f.food_type_id', '=', 'ft.id') ->where('f.food_type_id', 3) ->get(); join句はjoinメソッドを用いて、where句は、whereメソッドを使います。 クエリビルダに変換する際に、AS句を設け、二つの結果が返ってくるようにしています。 問題2 「値段が300以上の食品をもつ食品タイプIDと食品タイプ名の一覧」 SELECT ft.id, ft.name FROM foods f INNER JOIN food_types ft ON f.food_type_id = ft.id WHERE f.price >= 300; SQLをクエリビルダに変換します。 DB::table('foods as f') ->select( 'ft.id', 'ft.name', ) ->join('food_types as ft', 'f.food_type_id', '=', 'ft.id') ->where('f.price', '>=', 300) ->get(); join句とwhere句は問題1と同様に、joinメソッド、whereメソッドを使います。 比較演算子が = ではなく、 >= なので第二引数に比較演算子を指定しています。 問題3 「食品テーブルの食品の金額を食品タイプごとに合計して、1000円以上になる食品タイプ名を抽出」 SELECT ft.name, SUM(f.price) FROM foods f INNER JOIN food_types ft ON ft.id = f.food_type_id GROUP BY food_type_id HAVING SUM(f.price) >= 1000; SQLをクエリビルダに変換します。 DB::table('foods as f') ->select('ft.name') ->selectRaw('SUM(f.price)') ->join('food_types as ft', 'ft.id', '=', 'f.food_type_id') ->groupBy('food_type_id') ->havingRaw('SUM(f.price) >= 1000') ->get(); クエリビルダでSUMを取得する際は、selectRawメソッドを使いました。selectRawメソッドは、素のSQL式を挿入できます。 グループ化を行うGROUP BY、条件を絞り込むHAVINGは、groupByメソッドとhavingメソッドを使います。 今回havingは、SUMのデータで条件を絞り込むため、havingRawメソッドを使い、素のSQL式を挿入しました。 問題4 「買いものリストの個数が最も多い食品IDを抽出」 SELECT food_id AS '食品ID' FROM shoppings WHERE number = ( SELECT MAX(number) FROM shoppings ); SQLをクエリビルダに変換します。 DB::table('shoppings') ->select('food_id AS 食品ID') ->where('number', '=', function ($query) { $query->selectRaw('MAX(number)') ->from('shoppings'); }) ->get(); where句にサブクエリが必要なので、クロージャを用いています。 クロージャ内で、MAXの値を求めるために、selectRawを用いて、素のSQL式でMAXを挿入します。 問題5 「2022年5月11日時点で賞味期限が切れているものがない食品タイプを抽出」 SELECT ft.name AS '食品タイプ名' FROM food_types ft LEFT JOIN ( SELECT food_type_id FROM foods WHERE expire_date < '2022-05-11' ) sub ON sub.food_type_id = ft.id WHERE sub.food_type_id IS NULL; SQLをクエリビルダに変換します。 $sub = DB::table('foods') ->select('food_type_id') ->where('expire_date', '<', '2022-05-11'); DB::table('food_types as ft') ->select('ft.name AS 食品タイプ名') ->leftJoinSub($sub, 'sub', function (\Illuminate\Database\Query\JoinClause $join) { $join->on('sub.food_type_id', '=', 'ft.id'); }) ->whereNull('sub.food_type_id') ->get(); LEFT JOINでサブクエリを実行するために、サブクエリのビルダーを代入する。 leftJoinSubメソッドを使い、第一引数にサブクエリのビルダーを指定し、第二引数にエイリアスを指定します。 where句のIS NULLは、whereNullメソッドを使います。 まとめ 今回は新卒研修のMySQLのSQLを、Laravelのクエリビルダに変換し学習を行いました。 基礎的なメソッドや、初めて使うメソッドがあったりと書きながら知識を深めることができました。 クエリビルダのメソッドは、他にもさまざまなものがあるため、その内容についても学習をしていきたいと思います。 最後までお読みいただきありがとうございました。 The post 新卒向けMySQL研修で使ったSQLをLaravelのクエリビルダに変換する first appeared on Wedding Park CREATORS Blog .