PHPカンファレンス 2024｜共創を加速するための若手の技術挑戦

PHPカンファレンス 2024｜共創を加速するための若手の技術挑戦

PHPカンファレンス 2024におけるセッション「共創を加速するための若手の技術挑戦」の資料です。

概要：
みなさんは「共創」という言葉にどんなイメージを持っていますか？
誰かと共に、手を取り合いより大きな力で新しい価値を創り出すこと。
ウエディングパークではこの共創を拡大し、価値創造を進めています。
このトークでは、若手エンジニアである私が、共創プロジェクトの一員として働く中で何を考え、どんな取り組みを行ってきたのかお伝えします。
共創の力をいかに発揮するか、共創の難しさをどう乗り越えるのか。
エンジニアとしてこれらの課題に技術で答えを出してきた経験をもとに、
技術を武器に、事業貢献を加速するためのヒントをお届けします。

このトークで得られること
・共創におけるエンジニアの動き方
・技術を武器にした事業貢献事例
・技術挑戦・技術導入のためのヒント

こんな人におすすめ
・チームで活躍したい若手、若手に活躍してもらいたい人
・共創に興味がある人
・技術による価値創造や課題解決をしたい人

Transcript

1. 共創を加速するための 若手の技術挑戦 ©WEDDING PARK CO., LTD. ヒビキ
2. ヒビキ @hibiki_cube 株式会社ウエディングパーク +Creation本部 / 共創事業 - エンジニア 元気いっぱい2年目 今年の4月から現在のプロダクトにJoin #Apple #ベンチプレスは65kg #RAV4 #VRChat 自己紹介 2
3. ウエディングの各領域に特化した 専門メディアを開発・運営 海外・リゾートウエディングのクチコミ情報サイト 結婚準備クチコミ情報サイト 婚約・結婚指輪のクチコミ情報サイト 結婚衣装選びのクチコミ情報サイト フォトウエディング・前撮りのクチコミ情報サイト ウエディングパークから来ました 3
4. スライド公開のご案内 WeddingPark CREATORS @WeddingParkTECH 4
5. 実況や質問、ご感想のツイートもお待ちしております！ 5 #phpcon #track3
6. ウエディングパークの理念・ビジョン 6
7. 今日お伝えしたいこと 7
8. 今日お伝えしたいこと 共創によるものづくりで エンジニアが どう価値を発揮するか 8
9. そもそも共創とは 9
10. そもそも共創とは 10
11. ヒビキ @hibiki_cube 株式会社ウエディングパーク +Creation本部 / 共創事業 - エンジニア 元気いっぱい2年目 今年の4月から現在のプロダクトにJoin #Apple #筋トレ #RAV4 #VRChat 自己紹介 11
12. 結婚・結婚式は、人生や人と人との関わりにおいて大切な節目。だからこそ、デザイン経営的視点が必要。 式場・カップル、それらをとりまく“社会の視点”から、全社員がつねに問い続けて、 世の中にとって必要とされる結婚・結婚式のありかたを考え、カタチにしていこうとしています。 デザイン思考 デザイン経営 社会のニーズを掴む「視点」 社会のニーズから考える「発想」 これらの思考法を事業運営に取り入れる 共創で推進するデザイン経営 12
13. 共創の具体例 13
14. 共創の具体例 14
15. 結婚式費用の透明化の必要性 15
16. 業界課題を共に解決していく 婚礼業界大手 テイクアンドギヴ・ニーズ社 16
17. 結婚式場が提供するデータをもとに費用シミュレーションができる 17
18. 共創による価値創造の成果 18
19. 今日お伝えしたいこと（改めて） 共創によるものづくりで エンジニアが どう価値を発揮するか 19
20. 共創によるものづくりで エンジニアが どう価値を発揮するか を、自分の経験から 今日お伝えしたいこと（改めて） 20
21. いま携わっている プロジェクトについて 21
22. 今携わっているプロジェクト mieruuparkに続く 共創事業の次なる共創PJ 22
23. 今携わっているプロジェクト 共創での成果を出せた 今だからこそ出来る新しい事 23
24. 今携わっているプロジェクト 24 業界他社
25. プロジェクトのはじまり 25
26. プロジェクトのはじまり 2024年春 26
27. プロジェクトのはじまり 新機能開発 全力！🔥 27
28. プロジェクトのはじまり 新機能開発 全力！🔥 新しい共創PJの 立ち上げ時期の エンジニアに抜擢 28
29. プロジェクトの状況 業界の〇〇という課題に こうアプローチしたい というのは 決まっていたが……… 29
30. 業界の〇〇という課題に こうアプローチしたい プロジェクトの状況 これから企画を生み出す 仕様はもちろんまだ無い 30
31. プロジェクトに求められること 31
32. プロジェクトに求められること • 共創パートナー企業での利用を想定 → プロトタイプだとしても一定のクオリティが求められる • ある一定の時期までに開発完了→導入をする必要がある • 少数精鋭のチームで成果を出し切る 32
33. 新規の共創プロジェクトであるが故の難しさ これを叶えたい 33
34. 新規の共創プロジェクトであるが故の難しさ これを叶えたい この見せ方良さそう 34
35. 新規の共創プロジェクトであるが故の難しさ これを叶えたい この見せ方良さそう このインサイトが あるはず 35
36. 新規の共創プロジェクトであるが故の難しさ これを叶えたい この見せ方良さそう こんな使い方が できた方が活用しやすい このインサイトが あるはず 36
37. 新規の共創プロジェクトであるが故の難しさ これを叶えたい こんな機能いいかも この見せ方良さそう こんな使い方が できた方が活用しやすい このインサイトが あるはず 37
38. 新規の共創プロジェクトであるが故の難しさ これを叶えたい こんな機能いいかも この見せ方良さそう こんな使い方が できた方が活用しやすい この課題も一緒に 解決できないか このインサイトが あるはず 38
39. 新規の共創プロジェクトであるが故の難しさ これを叶えたい こんな機能いいかも この見せ方良さそう こんな使い方が できた方が活用しやすい この課題も一緒に 解決できないか このインサイトが あるはず 「じゃあこれでやってみましょう」 となるまでには時間を要する 39
40. 新規の共創プロジェクトであるが故の難しさ これを叶えたい こんな機能いいかも この見せ方良さそう こんな使い方が できた方が活用しやすい この課題も一緒に 解決できないか このインサイトが あるはず 「じゃあこれでやってみましょう」 となるまでには時間を要する ⇅ ある一定の時期までに開発・導入する 40
41. エンジニアとしての想い 簡単では無い状況の中でも 着実に成果を出すために、 技術で解決策を提示できる エンジニアでありたい 41
42. 考えたエンジニアとして出すべき価値 企画が決まったら最速で カタチにできるように 今のうちから準備をしておこう！ 42
43. 実際にやったこと 43
44. 企画確定前に行った取り組み 仕様変更に 強くする 工夫 × 2つ 人的リソースを 無駄なく使う 工夫 × 1つ 44
45. 企画確定前に行った取り組み 仕様変更に 強くする 工夫 × 2つ 人的リソースを 無駄なく使う 工夫 × 1つ 45
46. 仕様変更に強くする 新しい開発フローの 提案・トライアル 46
47. 新しい開発フローの提案・トライアル • 具体的な機能などはこれから決まっていく • 双方の希望やアイデアもたくさんある • 実際に触ってみてはじめて気付くことも多い • → 一度決まったように思えたことでも変化しやすい 47
48. 新しい開発フローの提案・トライアル • 具体的な機能などはこれから決まっていく • 双方の希望やアイデアもたくさんある • 実際に触ってみてはじめて気付くことも多い • → 一度決まったように思えたことでも変化しやすい ◦ むしろ、変えやすいことが事業にとって大きな力になる 48
49. 弊社の他プロダクトはウォーターフォール型の開発 ウォーターフォール 49 • 管理はしやすいが、仕様変更には弱い • スタートからゴールまで比較的時間がかかる • 作るものの詳細が確定している必要がある
50. 新しい開発フローの提案・トライアル プロトアジャイル 50 このプロジェクトのために 新しくオリジナルで考案
51. 新しい開発フローの提案・トライアル プロトアジャイル ウォーターフォール 51
52. 新しい開発フローの提案・トライアル プロトアジャイル ウォーターフォール 52
53. 新しい開発フローの提案・トライアル プロトアジャイル • なるべく細かく、小さく早く作っていく → 変えやすい • 動くものがあり、チームがそれに触れる機会も増える • まず作ってみて、確かめて、それを仕様に還元する 53
54. プロトアジャイルのよかったところ • 新しい開発フローではありつつも、スムーズに導入できた • 小さくても動くものがすぐ出来ることで、アイデアに繋がった 54
55. プロトアジャイルのその後 • 企画の根本が大きく変わったりすると対応しきれない部分も • 本格的な開発のフェーズでは時間の都合もあり ウォーターフォール開発に近いやり方をとった • 不確かなものを作っていくための工夫として今後のナレッジに 55
56. 仕様変更に強くする インフラ構成の検討 56
57. 既存プロダクトとは異なるインフラ構成の検討 • 既存プロダクトではEC2やECS Fargateを利用 • 実績はある反面、構成の検討や準備・運用の工数が懸念 • 投資フェーズではなるべくコストは抑えたい 57
58. Amplifyを採用する挑戦 • フロントエンドのインタラクション重視の初期検証にマッチ • 環境の構築から、デプロイ・運用まで手軽にできるメリット • 圧倒的なコストパフォーマンスの高さ AWS Amplify 58
59. ブランチ 環境 機能A 確認用環境 機能AのFB修正 確認用環境 機能B 確認用環境 機能Cの途中経過 確認用環境 ……… Amplifyの特徴の1つ 59
60. Amplifyの採用結果 • 企画検討中の期間を使ってインフラとしてどうか検証 • ブランチ毎の環境がある恩恵が想像以上にあった ◦ コードレビューの際にレビュワーが手軽に動作を見れる ◦ チーム内で変更前後の把握や比較がしやすい ◦ 頻繁に変更がある中でも、 共創パートナーへスムーズに共有が行えた 60
61. 企画確定前に行った取り組み 仕様変更に 強くする 工夫 × 2つ 人的リソースを 無駄なく使う 工夫 × 1つ 61
62. 人的リソースを 無駄なく使うための 技術選定 62
63. フレームワークの選定 • 最低限のデザイナー, エンジニア。少しも無駄にしたくない • それぞれの担当範囲をできるだけ広げておきたい ◦ 兼務の都合もあり、全員ずっと時間を取れるとは限らない エンジニア デザイナー エンジニア デザイナー 63
64. フレームワークの選定基準 • 小さく早く開発できるもの ◦ 必要なものが揃っている ◦ より少ないコードでシンプルに記述できる • 追加の学習コストが少ない → 既存の知識を活用できるもの • デザイナー, エンジニアどちらでも触れる部分を増やせるもの 64
65. 選ばれたのはSvelteでした • 設定した基準をどれも高いレベルで実現できる • 新しいものを作るタイミングだからこそ技術挑戦のチャンス 65
66. 既存の知識を活用できる @if($user->isLoggedIn) <p>{{ $user->name }}さん、こんにちは </p> <ul> @foreach($user->todos as $todo) <li>{{ $todo }}</li> @endforeach </ul> @else <p>ログインしてください </p> <a href="{{ route('login') }}"> ログイン </a> @endif {#if user.isLoggedIn} <p>{user.name}さん、こんにちは </p> <ul> {#each user.todos as todo} <li>{todo}</li> {/each} </ul> {:else} <p>ログインしてください </p> <a href="/login"> ログイン </a> {/if} 66
67. 選ばれたのはSvelteでした <script lang='ts'> let count = $state(2); </script> <button onclick={() => count--}>-</button> <p>{count}</p> <button onclick={() => count++}>+</button> <style lang="scss"> p { color: red; } </style> • 必要なものが揃っている ◦ 必要十分な状態管理 ◦ Scoped Style ◦ SSR / SPA / ISR ◦ アニメーション 67
68. Svelteの採用結果 • ハンズオンの場を用意するなど、丁寧に導入した • 目指していたプロダクト導入時期までに無事に開発完了 • デザイナーとエンジニアがタスク状況に応じて 適宜互いのタスクを巻き取りあうのがやりやすかった 68
69. 最後に： 共創を加速する中での エンジニアの価値発揮 69
70. 共創を加速する中でのエンジニアの価値発揮 • 共創 & 新規だからこそ、変化のしやすさが価値になる気づき ◦ その土台を技術挑戦を通して提供し、価値を発揮できた • 制約がある中でも、持てる力を最大限発揮できる環境を作れた ◦ mieruuparkよりもさらに短期間で初期開発を完了できた • 結果として、実際に使った方からもいい反応を得られている 70
71. 採用情報 “クリエイターがデザイン思考×具現化力を武器に事業成長をリードする” 技術とデザインのウエディングパークを一緒に創りませんか？ テックブログ 71