こんにちは！ 新卒1年目、デザイナーのなっつです。 ウエディングパークに入社して2か月が経った今年の6月、ある案件が舞い込んできました。その名も「シャッフル座席システム化」。初めての案件がまさかビッグプロジェクトになるなんて…！ 今回は、そんな新卒の チャレンジ をご紹介します。 目次 そもそも「シャッフル座席」とは？ 開発について 注力したこと 初案件で苦労したこと システム化をしてみて そもそも「シャッフル座席」とは？ ウエディングパークは、2021年3月に本社オフィスをリニューアルしました（詳しくは こちら ）。オフィスの意義を「 未来を共創するコミュニティスペース 」と再定義し、座席のフリーアドレス制を導入しました。しかし、社員からは「どこに座るか迷ってしまう」「席が固定化されてしまう」という声があがっていました。そこでできた仕組みが 「 シャッフル座席」 です。朝出社したらくじを引き、決められたゾーンに座るというもの。当初はこちらを紙のくじを使ったアナログ形式で運用していました。 今回担当した案件は、こちらの制度をシステム化しよう！というものでした。 開発について このシャッフル座席システムですが、新卒研修の集大成として全員新卒1年目のメンバー（ディレクター・デザイナー・エンジニア）で開発することになったのです！サポートメンバーの先輩方に見ていただきながら、6/14のオリエンから8/5のリリースまで約1か月半かけて開発しました。 私はデザイナーですが、システムの 仕様詰め のフェーズに関わったり、デザイン後の コーディング も担当するなど、幅広く携わることができたなと感じています。 注力したこと ネーミング 初め、システム名は「シャッフル座席」のまま進めていましたが、「社員に愛され、たくさん呼んでもらえる名前がいいよね！」という気持ちから開発途中でネーミングを変更しました。チームで話し合い、決まった名前は 「HAPPY シャッフルン」 です！既に浸透していた「シャッフル」はそのまま、「シャッフルでルンルン」というコンセプトもあり、朝から社員の皆さんにワクワクを与えたいという思いからこのネーミングに決定しました。実際にお披露目後は皆さんにシャッフルンと呼んでいただき、システムに愛着を持っていただけていると思うと嬉しい気持ちでいっぱいです。 デザイン まず、システムやお披露目の場面で使用できるようなロゴを作成しました。 (1)ウエディングパークの行動規範TRUTH「幸せのための9つのピース」を9色で表現（詳しくは こちら ） (2)○△□の図形を人の個性と見立て、個性が集まることで「共創」すること  以上2点をベースにロゴが完成しました！コンセプトもセットで全社にお披露目した結果「ロゴ素敵だね！」と言ってもらえることが多く、改めてコンセプトを固めた甲斐があったなと感じています。   また、UIにも力を入れました。 シャッフルンはiPadを入口付近に設置し使用します。初めはフラットなデザインで進めていましたが、ボタンを押したくなるような、シャッフルンを触りたくなるようなUIにすべく、ボタン感を出したデザインに変更しました。押すとボタンが凹み、リアルにボタンを押しているような感覚になる仕組みもあり、社員にワクワクを与えられるUIになったと思います。 コーディング 今回は大きな開発となり、ほぼ初めての言語を使う場面もあったため、自分にとってチャレンジングな経験でした。そんなチャレンジを成功させるために大切だったのが、 人を巻き込む ことでした。先輩の時間を前日のうちに抑えて意識的に相談タイムを作ったり、いただいたコードレビューで少しでも理解に苦しんだ箇所はすぐZOOMを繋ぎ相談したり。コーディングは1度沼にはまるとなかなか出てこられないことが多いので、早い段階で客観的にコードを見ていただくことが大事だと実感しました。 初案件で苦労したこと その1. タスクの細分化 「デザインする」「コーディングする」という大きなタスクは分かっていても、その中のタスクを細分化できていませんでした。そのため、あとどれくらいで終わるかを把握できず、漠然とした不安に襲われたことがありました。そこからできるだけタスクを細分化することでマイルストーンを敷くことができました。不安が大きくなり集中できなくなる前に、やることを明確にするのが大事だと思います。 その2. 作成より修正に時間がかかる デザインでもコーディングでも、先輩にレビューをいただくフローがあります。皆さんから的確で全て取り込みたくなるようなアドバイスをいただけるので、その修正に時間がかかりました。気づけばスケジュールが押してしまうことも…。修正はより良いものを作るチャンスなので、色んなアドバイスを試すためにも修正の時間をしっかり設けるべきだなと感じました。 システム化をしてみて 同期でチームを組み開発する貴重な機会でした。新卒1年目のメンバーにこの案件を任せていただき、即戦力として期待されていることでモチベーション高く開発できました。 実際にリリースしてからは、 「シャッフルン、他社にも展開できるんじゃないかってぐらいの完成度で感動しました！」 「ものづくりで全社に貢献できるってとても素敵ですね！！」 「朝からドキドキしてオフィスに来るのが楽しみになりました。」 「シャッフルンのデザインが可愛らしくて、インテリアとしても良さげな感じ。」 など、多くの嬉しい反応をいただくことができました！全員が苦しみながらも一枚岩で進めることができたからこそ、最終的に良いものができたのだなと思います。社内を活性化するようなシステムを作ったという自信を忘れず、新卒1年目を走り抜けていきます！

こんにちは、エンジニアのみーやです。 今日は最近エンジニア組織で実施した、システムお問い合わせ対応の活性化施策である HIKESHI について紹介したいと思います。 結論から言うと、対応する人が偏っていたお問い合わせ対応をチーム戦にしてゲーム要素を取り入れてみたら、積極的に対応に入ってくれるメンバーが増えて盛り上がったし、対応のナレッジも溜まるようになって最高でした。 目次 問い合わせ対応とは 新施策 HIKESHI の誕生 HIKESHIでやったこと HIKESHIをやってみて 問い合わせ対応とは 通常業務とは別で突発的に発生するバグや障害の対応、または他部署からの仕様の質問やレポート数値調査、データ抽出依頼などの プログラム管理をしているエンジニアにしかできない対応全般 をシステムお問い合わせと呼んでいます。 対応の流れ まず、システムお問い合わせ対応がどういう流れで行われているのか、簡単に説明します。 ▼主な流れ 問い合わせ依頼先として活用しているメーリスにメールで問い合わせが送られてくる (slackの問い合わせ専用チャネルにくる場合もある) 来たメールの内容をエンジニアが確認し、対応する場合は自分が対応する旨を一次返信する(対応担当などは特になく、立候補で対応者が決まる) 対応者のエンジニアは依頼内容に応じて作業や調査を行い、結果をメールにて回答する（必要がある場合は回答の開示許可を上長に確認） 依頼者が回答を確認してOKであれば終了、必要があれば追加調査などを完了するまで行う 来るお問い合わせのジャンルはさまざまですが、サービスのエラー調査や仕様の質問、 データ抽出の依頼などが多く寄せられます。 中には、調査していく中で障害が発覚し対応に入ることもあるので、 お問い合わせ対応は サービスを運用していく上で欠かせない大切な業務 のうちの一つです。 依頼自体はいつどこから来るのか予想することはできず、依頼が来たタイミングで手が空いているエンジニアが対応に入ることになっています。 そこで課題になるのが以下です。 対応に時間がかかった場合、通常業務が遅延するリスクがある 対応方法がわからないメンバーは対応に立候補してこない この課題により、お問い合わせ対応に入るエンジニアが徐々に減り、かつ、年次が上のエンジニアが主に対応にあたるという状況が生まれていました。 いつの間にか、誰でも対応に入れるべきところが、仕様理解が幅広く、自分の業務の調整を適切に行えるスキルがないと対応に入るのは難しいという印象がついていたのです。 実際にメンバーに問い合わせ対応時の自信を聞いたところ、自信があると答えたメンバーは全体の半分にも満たない割合でした。（青と赤が自信があると答えたメンバーの割合です） 新施策 HIKESHI の誕生 そこで誕生したのがお問い合わせ対応をチームで行う HIKESHI でした。 HIKESHI実施の大きな狙いは以下の2点です。 お問い合わせ対応を一人でやるものから、チームでやるものに変換 対応に必要なスキルを学べる機会を作る 一人でやるものから、チームでやるものに変換 お問い合わせ対応 = 大変で時間がかかるもの というイメージができつつあったので チームで対応に入る環境を作って物理的なマンパワーを増やすとともに知らない情報をお互いに補い合うことで対応にかかる時間の短縮を狙いました。 3人よればなんとやら。 対応に必要なスキルを学べる機会を作る お問い合わせ対応はジャンルがさまざまで自分であらゆる対応パターンを検討して作業する特性から、 大変だけど大きく成長できるチャンスでもあった ので、その特性を利用して若手の成長機会に活用したいという気持ちもありました。 まずは若手も対応の渦中に入ってもらい、その中で先輩のスキルを盗みつつも自分で対応を行い、成功経験を積んでもらうことを狙いました。 HIKESHIでやったこと 若手エンジニアを中心に一緒に対応を行う3~4人のチームを編成 チーム対抗で切磋琢磨できる環境作り 毎月最多対応者を表彰 対応時の作業記録やナレッジを蓄積&共有 若手エンジニアを中心に一緒に対応を行う3~4人のチームを編成 1ヶ月クールでチームを編成して一緒に対応を行う仲間を決めました。 チームリーダーには一番社歴の浅いメンバーを抜擢し、積極的に対応の先導を切るスタイルを作り、他のメンバーはリーダーをサポートする形でチームが協力して対応に入れるようにしました。決まった仲間がいることで、質問できる環境が整うので若手がよりやりやすくなることを狙いました。 チーム対抗で切磋琢磨できる環境作り 1件対応するごとに対応者の所属チームに1ポイント付与される仕組みにし、総合ポイントを毎月チーム対抗で競争する仕組みにしました。 競争と協調 がカルチャーとして根付いている組織なので、競争効果は絶大です。 また、ゲーム要素が加わることで施策全体が活性化することも狙いました。（みんな大好きなマリオパーティーのパロディ風でポイントレースを行いました） 毎月最多対応者を表彰 チームの総合ポイントで優勝チームを決めていましたが、同時に一番多く対応に入ってくれたメンバーを表彰する個人賞も作りました。 個人賞があることでチームのポイント進捗が悪くても最後まで対応に入ることを諦めない意識を持ってもらうことを狙いました。 お問い合わせ対応は組織貢献の一つでもあるので、たくさん対応してくれたメンバーに感謝の気持ちを伝えたかった意味も強いです。 対応時の作業記録やナレッジを蓄積&共有 対応リストをスプレッドシートで作成し、概要やナレッジを蓄積できるようにしました。 今までも記録を残していた人はいましたが、改めてルールにしたことで、些細なことでも記録に残しておく意識を持ってもらうことを狙いました。 自分にとっては当たり前のことでも、他の誰かにとっては知らなかったこと、ナレッジになることはよくあることなのでできるだけ記録に残してもらいました。 リストの内容は運営メンバーが週一で全て内容を確認し、みんなに知っておいてもらいたいものはシステムのMTGで全体共有しました。 HIKESHIをやってみて HIKESHIを実施したことでお問い合わせ対応自体が活性化し、対応に入るメンバーの増加に繋がりました。 課題としてあげていた対応にかかる時間の調整や対応者の偏りは改善しつつあります。 実際にHIKESHI実施前後で対応に入る自信がアップしたメンバーが多くいたこともアンケート結果から見て取れました。（青と赤のメンバーの割合が大幅UP!） 何よりもお問い合わせ対応が楽しいものに変換され、より若手がリーダーシップを発揮したり、スキルの成長を実感できる環境を作り出せたことが良かったです。 運営を担当したメンバーも、組織課題に向き合う機会となり良い成果を出せたことで自信がつくきっかけになりました。 これからはHIKESHIの大事な文化は残しつつ、今の環境に合う形に変化させて続けていきたいです。 HIKESHI立ち上げの運営サイドのお話もしたいのですが、それはまたの機会にします。

こんにちは。結婚指輪・婚約指輪の口コミサイト「Ringraph」でエンジニアをしているさー（ @__south__373 ）です。 以前こちらの記事で、全社エンジニア横断で行ったリモートワーク下でのコミュニケーション施策について紹介させていただきました。 全社エンジニア横断！リモートワーク下で行ったコミュニケーション施策 記事の最後に1ヶ月やってみてリニューアルと書いたのですが、 実際にどんな風にリニューアルしたのか、ご紹介したいと思います。 1ヶ月やってみての変更点 改善ポイントを受けて、いくつか運用を変更することにしました。 変更点1：トークすることをメインにせず、困っていることを気軽に相談できる場へ これまでは明確にトークテーマを設けて、集まってくれたメンバーでその内容についてディスカッションをしていました。 これはこれで、いろんな人の意見が聞けて新しい発見も生まれたのでよかったのですが、もっと些細な案件ベースの相談をする場所にしたかったという声や、実際に運営していて毎回トークテーマを決める手間だったり当日ファシをしなければいけない負担があったので、トークテーマを設けるトークメインのスタイルを辞めることにしました。 そこで、交流をする場というよりは、オフィスの拡張というイメージで困っていることについて気軽に相談できる場所へとリニューアルすることを決めました。 変更点2：Zoomではなく、Gatherを使用 ウエディングパークではリモートワークでの通話手段としてZoomをよく使用しており、WPhouseでもZoomを使用していました。 ただ、各自が気軽に相談できる場所にしたいというところを考えると、グループを分けて話す際にわざわざブレークアウトルームを立ち上げて移動する必要があるため適したツールであるとは言えませんでした。 そこで、クラスメソッドさんが紹介していたGatherというツールを使用してみることにしました。このツールは全員が一堂に会したり、近くにいる人だけで会話をしたりということが簡単に行えます。 レトロRPG風デザインのオンラインビデオ通話スペース『 Gather.Town 』で”出社して仕事＆気軽に雑談”を楽しく仮想体験！ https://dev.classmethod.jp/articles/gather-town-as-a-virtual-office/ また、このツールは社内では使用している事例がなかったため、 普段参加しないメンバーもこのツールへの興味からWPhouseへ参加してくれることも期待として持っていました。 変えてみた結果 よかったこと ■ 困っていることを気軽に相談できる場へしっかりアップデートされた 「ooさんにこのこと聞きたいんですけど、ちょっといいですか？」という会話が増え、いろんな場所で相談が同時に行えるようになりました。興味がある人は一緒についていって聞いたり、そうでない人は大部屋でディスカッションをしたり、できれば作業時間に当てたいけど会話は聞いておきたいという人は作業をしながら場に参加だけしていたり。各自で好きな時間の使い方ができるようになったと思います。 このこと聞いてみたいけど、わざわざ1対1でZoom繋ぐほどじゃないんだよな…みたいなことも消化できるので日々のモヤモヤをそのままにしないですむようになりました。 ■ 参加メンバーが増えた Gatherで使う部屋は自由にカスタマイズできるので、定期的にアップデートしたり、そのお知らせを聞いてから普段は来ない人が参加してくれたりと新しいツールを使うことによるメリットをしっかり享受できたと思います。 少なくとも全員が1回は参加しており、多い時はエンジニアメンバーの約7割が参加してくれました。 初めてGatherを使った時、こんな風にみんなで写真撮影しました笑 ■ WPhouseの時間でやりましょう！という会話が増えた 以前から、定例で議論しきれなかった内容を「続きはWPhouseで話しましょう」という流れは作れていたのですが、最近は環境構築や引き継ぎ作業など、WPhouseの時間で一緒にやっちゃいましょうという会話が増えました。 これによって、わざわざ新しくミーティングの時間を抑える必要がなくなりました。 さらに、環境構築などは一人だと詰まったり、ナレッジが属人化されてしまいがちですが、これをオープンな場で行うことによって、わかる人にすぐ相談できたり、自分のタスクじゃないけどナレッジとして知っておきたい人でも知れる機会ができたと思っています。 改善ポイント ■ それぞれの部屋の話題が一見わからない 各話題ごとに場所を移動して会話をするのですが、途中から来たメンバーからすると、それぞれの人がどんな話題について話しているのかわからないので、後から会話に入りにいくということがしづらい状況です。 お隣の会話も聞けるというのがメリットでもあるこの時間なので、何かしら改善をしたいと思っています。 今後の展望 WPhouseという取り組みですが、リモートワークで働く中でもエンジニア全員が気軽に集まれる場所としてだんだんと機能してきたように思います。 現在はチーフエンジニアが運営という形で行っていますが、文化として根付いて欲しいなと思っています。 最後に 今回は、全社エンジニア横断で行っている施策についてご紹介しました。 ウエディングパークでは、一緒に技術のウエディングパークを創っていただける仲間（エンジニア）を募集しています。 興味のある方はぜひ一度気軽にお話ができたら嬉しいです！ 株式会社ウエディングパークの会社情報 – Wantedly https://www.wantedly.com/companies/weddingpark

エンジニアの久保です。 ある日、GitLab CI を利用しているプジェクトで job を動かしたら以下のエラーで失敗するようになりました。 このときの対処方法をまとめました。 Running on runner via abcdef... Fetching changes... Reinitialized existing Git repository in /builds/example/example.com/.git/ error: RPC failed; curl 18 transfer closed with outstanding read data remaining fatal: the remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed ERROR: Job failed: exit code 1 こちらの記事を参考に git clone する際に depth を指定するようにしました。 Optimizing GitLab for large repositories 対応方法としては3つあります。 状況に応じていずれかの方法で対応すればよさそうです。 その1：GitLab Runner の設定を変更する GitLab Runner の設定を変更できる場合は、GitLab Runner の config.toml を次のように変更します。 concurrent = 4 [[runners]] url = "GITLAB_URL" token = "TOKEN" executor = "docker" builds_dir = "/builds" cache_dir = "/cache" environment = [ "GIT_DEPTH=10" ] [runners.docker] volumes = ["/builds:/builds", "/cache:/cache"] 具体的には、 [[runners]] セクションに以下を追加してください。 environment = [ "GIT_DEPTH=10" ] その2： .gitlab-ci.yml に設定する プロジェクトの .gitlab-ci-yml に環境変数として GIT_DEPTH を設定する方法です。 Runner Server の設定を変更できない場合や特定のプロジェクトだけ設定を変更したい場合はこちらの方法が良さそうです。 variables: GIT_DEPTH: 10 test: script: - ls -al その3：GitLab の CI/CD Settings で設定する GitLab の CI/CD Settings で設計可能な Variables で設定する方法です。 GitLab グループでまとめて設定したいが、Runner Server の設定を変更できない場合などで役立ちそうです。 変更結果 depth を指定した結果、これまでと同様に job を実行できるようになりました。 Running on runner via abcdef... Fetching changes with git depth set to 10... Reinitialized existing Git repository in /builds/example/example.com/.git/ 結果より、git depth が変更されていることを確認できます。

はじめに こんにちは。結婚指輪・婚約指輪の口コミサイト Ringraph でエンジニアをしているさー（ @__south__373 ）です。 ウエディングパークのエンジニアは様々な部署やチームに分かれています。 普段は一緒にお仕事をすることは少ないのですが、週に1回全員が集まって各チームが今どんなことをしているのかをキャッチアップする時間（以下、エンジニア定例）を設けています。 今年の4月からこのエンジニア定例の運営メンバーとなったので内容を変えてみたところ、以前よりもナレッジ共有が活発になったなーと思うので、どんなことを共有しているのか紹介したいと思います。 エンジニア定例のアジェンダ 今行っているアジェンダは全部で5つです。週に1回1時間で行っています。 1. 新卒コーナー 2. 全体共有 3. サイトの健康状態 4. チーム共有 5. LT 各コンテンツについてどんなことをしているのか紹介していきます。 新卒コーナー 新卒で入社したエンジニアに毎週の出来事を共有してもらっています。 今やっている仕事で学んだこと、困っていることを共有して先輩からアドバイスをもらったり、プライベートの興味関心をオープンにすることで先輩社員との距離を縮められたかなと思います。 全体共有 エンジニア全体に共有しておいた方が良いことや施策などを共有する場です。 参加できなかった人や後から見返したい人のために、内容やリンクを貼ってもらって情報をオープンにしています。 サイトの健康状態 各サイトで発生してしまった不具合や障害の内容を共有する場です。 どこで何が原因でその事象が発生したのかとナレッジを共有することで同じ不具合を出さないようにしたり、他のサービスではこんな対応を取ってますという情報をお互い得たりすることができています。 チーム共有 共有している内容は3種類 ・今進行している重要案件 ・今週のトピックス ・ナレッジシェア 重要案件をお互い把握することで、各チームの追っている目標が見えてくるので方針も把握しやすくなります。 また毎週リリースした内容を共有することで他のチームがやっている施策を横展することもできます。 ナレッジシェアでは最近開発中に気づいたことや個人的に取り組んでいることを共有しており、新しい知見を得ることができたり、逆に今困っていることを書いて知見のある人からアドバイスをいただけることもあります。 LT 毎週2-3人がLTをする時間を設けました。 マネージャーも含めて全員が発表することにしており、1.5ヶ月に1回ほどのペースで回しています。 準備の負担が大きくなって続かなくなってしまっては意味がないので、1人3分程度で最近の気付き・自慢・なんでもOK！としています。 ・今年の技術振り返り ・今やってる案件の話 ・エンジニア横断の取り組みまとめてみた ・コードレビューを依頼する、その前に ・社長室フォトレイトに移動して感じた「良い！」と思った取り組み etc. 新卒が定例に参加するようになったタイミングでは自己紹介LTに内容を切り替えました。 今のウエディングパークはリモートワークが主流となっていますので、なかなか顔を合わせることが少ないメンバーも多いです。なので、新しくジョインしてくれた新卒メンバーがこの環境下でもエンジニアチームに馴染めるように、また困ったときに誰に相談したらいいかわかるようにすることを目的としました。 スライドのテンプレートを用意して、このように可視化をしました。 その他内容以外で変えたところ 運営チームが司会をしているのですが、各チームのシェア内容やLTに対してなるべく1つは質問や反応を入れるように気をつけました。聞きたいことがある人はチャットで投げてくれるのでそれを拾って質問したり、個人的に気になったところを掘り下げていくことで、ただ一方通行の共有ではなく双方向からのやりとりが増えたと感じています。 やってみて 良かったところ ・LT実施することにより、定例中に発言するメンバーが増えた ・ナレッジシェアが習慣化し、アウトプットの質と量が上がった ・業務中心で全員が学びあっている ・司会が必ず反応を入れることにより和気藹々とした空気ができ、心理的安全性が上がった 改善できるところ ・司会が反応を増やしたものの、質問をしてくれるメンバーが少ない ・シェア内容を増やした結果、ミーティングが伸びがち おわりに この3ヶ月運用してきて、かなりシェアの内容が増えて共創できる時間をつくることができたのではと思っています。 改善できる部分はチームで話して内容反映していきますので、これからもバージョンアップしていきたいと思います。

こんにちは。エンジニアのなりです。 フォトウエディングの決め手が見つかるクチコミサイト「Photorait」 で開発を行っています。 私は、中長期的なキャリアとして、サービスの未来を考えて創るような、サービスの上流工程に携わるお仕事がしたいと思っています。 それを実現するためのスキルをつけたいという思いで、もともとPhotoraitチームで行っていた、サービスの未来を考えて創る会議（イノP会議）の運営メンバーに入れていただきました。   今回は、そんなイノP会議について、運営側としてどう関わったのかをご紹介します。 イノP会議とは イノP会議とは、チームの目指す目標を達成するために何をすべきか？をチーム全員で議論する会議です。 ウエディングパークでは、各チームがそれぞれのミッションを行う上で、最終的に到達したい状態を抽象的に設定した目標（ビジョン）を掲げており、それを「意義目標」と呼んでいます。 私が所属するPhotoraitチームの意義目標はこちらです。 フォトウエディングでブライダル業界をイノベーションし、 日本の結婚写真の価値水準をあげる これを設定してからは、意義目標を抱きながら仕事に取り組むことは出来ていたものの、具体的なアクションにまで落とすことが出来ていませんでした。 そこで立ち上がった会議が、「イノP会議」です。「イノ」ベーションを「P」hotoraitが起こす、そのために、 全員が 当事者意識 を持って、 自ら課題を発見 し、解決方法を議論することを目的とした会議が定期開催でスタートしました。   今までのイノP会議で取り扱ったテーマを少しご紹介します。 こんな取組みをやったら、イノベーションになるんじゃない？ フォトウエディングのオフシーズンをオンシーズンに変えるアイディアを考えよう！ 「クチコミ」でイノベーション出来るか！ コロナ後の結婚式・フォトウエディングはどうなる？ このように、目の前の業務ではなく、視点を未来に向けて答えの無い問いに、チームみんなでアイディアを出し合う時間をたくさん取ることが出来ました。 実際に、この場で出たアイディアから今後開発予定の案件が生まれています。 イノP会議の運営に携わったきっかけ 私は現在エンジニアとして日々Photoraitの開発運用業務に携わっていますが、中長期のキャリアビジョンとしては、エンジニアとして開発業務を行うだけでなく、サービス開発の上流工程にもっと参加して、ディレクション領域にも進んでいきたいと思っています。 イノP会議は、PhotoraitのWebディレクター職の社員が企画運営しておりました。 ですが、サービスの未来を考える会議を運営することが自分のキャリビジョンにとって学びが大きいはず！と思い、運営に携わりたいと昨年度末に声を上げて、4月から運営チームに加わりました。 運営チームにジョインして開催した会について 運営チームにジョインして開催した会について、少し詳しくご紹介しようと思います。 ▼テーマ コロナ後の結婚式・フォトウエディングはどうなる？ ▼開催頻度、所要時間 ３ヶ月に１回、２時間で実施 ▼ アジェンダ □事前準備 ①職種混合チームをつくる（営業・ディレクター・エンジニア・デザイナー） ②テーマについてディスカッションし意見をまとめてくる ＜具体的なトークテーマ＞ １．コロナ前後で変わった価値観、最近のトレンド、生活（結婚に関わること含め、私生活全般） ２．コロナ禍・後の結婚式はどうなる？ ３．コロナ禍・後のフォトウエディングはどう変わった？この先、どうなる？   □イノP会議当日 ①チームごとにプレゼン（発表＋質疑応答） ②職種ごとに別れてその場でディスカッションし意見をまとめる（営業チーム / ディレクター / エンジニア＋デザイナー） １．コロナ後に向けて何をするべき？ ２．フォトウエディングはどんな価値をカップルに提供できるのか？（具体的なアクション） ③チームごとにプレゼン（発表＋質疑応答） やってみて 運営に携わってみることで、いち参加者では知ることが出来なかった気づきがいくつかありました。 ・トークテーマを決めるのは、とっても難しい 参加者のときは与えてもらっていたトークテーマ。 でも運営側になってみると、チーム全員の時間をたくさんいただいて行うMTGなので、テーマ設定はとても重要で神経を使うものでした。 いつか話したいことは山ほどある、でも今話すべき最優先は何なのか。サービス全体を俯瞰してみた決断が必要でした。 ・思ってもなかった新鮮な意見が出る テーマを設定する上で、議論が膨らむか？どんな話が出るか？はある程度想像していましたが、当日会議を行ってみると、各チームによって、職種によって、出てくる意見は本当に様々で、ひとりでは辿り着けない思考に辿り着けるのを、とても強く感じました。 まとめ エンジニアのキャリアビジョンは様々あります。 エンジニアの中でも、技術を磨いて現場で活躍し続けるスペシャリストや、プロジェクト進行をマネジメントするポジション、エンジニアの経験を活かして別職種の領域にチャレンジすることもあると思います。 この仕事は〇〇の職種の仕事だから…と自分の領域を制限してしまうのは、自分の「好き」と出会うチャンスを狭めてしまうと私は考えています。 今後もエンジニアという職種に縛られず、何でもチャレンジしてみて、自分の「好き」や「得意」をたくさん見つけて行きたいと思います。

ウエディングパークでデザイナーをしています。内田（ @PANbooooo ）です。 先日、全社デザイナーの横断チームで「1DAYデザインスキルアップワーク」という合宿をリモートで行いました。 初めてワークの運営を担当したのですが、満足度の高い合宿になるよう準備をしっかりしてきたので、今回はその裏話と工夫したことについて紹介したいと思います。 ちなみにワークについては過去の「 デザイナーチームで1DAYスキルアップワークやってみた 」というブログで記述していますので、ご参照ください。 目次 ワークの概要について ワーク2ヶ月前：テーマ決め ワーク1ヶ月前：資料の作成 ワーク1週間前：告知/アンケートの作成 ワーク当日：合宿のタイムキーパー/発表のファシ ワーク後：振り返りの準備 ワークの概要について 今回は、他の企業のサービスやサイトのイケてるデザインを自社サービスに取り入れてみて、調査・分析し、そこから分かったことを発表しました。 ワーク2ヶ月前 やったこと ・ワークのテーマ決め ・デザインチームのメンバーへの発表 ・ワーク開催日の決定 ワークを進めるに当たり、大切なのがテーマです。テーマが決まらないと、メンバーはワークの準備も出来ません。そのためまずはテーマを考えました。 テーマについて テーマはある程度幅が広いものにしないと発表内容が被ってしまうため、「調査内容がイメージしやすいほどに狭く、でも人と被らないように広く」を心がけて決めました。また、当日の発表のオーディエンスを増えやしたいということもあり、会社やチームのスローガンとテーマを絡めることも意識していました。 チームへの発表 テーマが明確になったら、すぐにチームメンバーに発表しました。チームメンバーへの発表の際には、すぐにワークの準備に取り掛かれるように、「ワークの例」をこちらからいくつか提示しました。 作成した資料をチラ見せ ワーク1ヶ月前 やったこと ・資料の作成 脳内でシミュレーションをすると、思っている以上に使用する資料が多く、この時期は資料の作成に励みました。ちなみに、必要となる資料は以下になります。 ・チームメンバーに向けた、ワークについての説明資料 ・チームメンバーが作成する発表資料のテンプレート ・オーディエンスに向けた、ワークについての説明資料 同じ説明資料でも「チームメンバーに向けた」ものと「オーディエンスに向けた」ものと、少しニュアンスが変わるため、各々用意しました。 発表資料のテンプレートについては、限られた時間の中で全員が分析・調査にメンバーが集中するために、事前に、「入力すればいいだけのテンプレート」を用意しました。 作成した資料をチラ見せ ワーク1週間前 やったこと ・会社全体へのワークの発表会の告知 ・アンケートの作成 ワークの1週間前になると、デザインチームの取り組みをしっかりと会社全体に知ってもらうために、メールやslackを活用し、発表会の告知をしました。また、今後のデザインチームの取り組みのヒントとなるよう、参加者のみなさまへのアンケートも作成しました。 ワーク当日 やったこと ・ワークのタイムキーパー ・ワークの発表のファシリテーター デザインチームのメンバーと認識合わせをするために、まずはじめにワークの詳細について再度説明をしました。そして細かなルールの部分等を決めてから、各々調査・分析に入りました。 作業中は、発表会の一時間前や三時間前など決められた時間にコンスタントにslackで声がけをしたり、時々「zoomを繋げて進捗報告会をしましょう」など呼びかけることで、モチベーションをアップするたの工夫をしました。 また、発表会ではファシリテーターとして参加者の皆さんが安心して発表会を楽しめるよう、司会・進行を勤めました。 ワーク後 やったこと ・振り返りの準備 ワークが終わった翌日は、ワーク全体の振り返りをすべく、振り返りの準備をしました。また、ワーク後に参加者のみなさんからご回答頂いたアンケートをもとに、今後のデザインチームの取り組みについても話し合いました。 まとめ 初めての企画・運営ということで、「資料制作に時間を多くかけてしまった」や「全社への告知ももう少し早くしてもよかったなぁ」ともう少し工夫できたこともあれば、「ワークに集中して取り組める仕組みはできた！」と良かったところもありましたが、最終的にオーディエンスで参加してくださった皆様にも、デザインチームの皆様にも満足して頂いたワークになってよかったです。今回のワーク全体を通して、色々なことを学んだので、今後にも活かしていきたいと思います。

こんにちは。結婚指輪・婚約指輪の口コミサイト「 Ringraph 」でエンジニアをしているさー（ @__south__373 ）です。 以前こちらで紹介されていた FridayBash ですが、形を変え全社エンジニア横断で行ったので、やってみた所感をお伝えしたいと思います。 目次 FridayBashって？ 全社横断での実施背景 FridayBashと違うところ やってみて 1ヶ月やってみてリニューアル 最後に FridayBashって？ 詳しくはこちらの 記事 を読んでいただければと思いますが、下記のような取り組みをFridayBashと呼んでいます。   FridayBashとは ・ Zoomをつなぎながら雑談する会 ・ 毎週金曜日午後の業務中に1時間で実施 ・ エンジニア4人とデザイナー1人の5人で実施 ・ 話す内容は技術系の話であれば何でもOK (テックニュース、気になってる技術、サイト仕様、設計etc) ・ 基本業務をしながら参加を推奨 (開発などで忙しい人も参加してほしいため) ・ 金曜日なので、「今週もお疲れさまでした！」で締める   全社横断での実施背景 FridayBashは一部のチームで行っていたのですが、働き方がリモートワークへ変わり全社エンジニア間でも下記のような課題が上がっていました。 ・困りごとを気軽に相談できる場がない ・エンジニア同士の交流が減った これらの対応策としてFridayBashを全社エンジニア横断で実施するのはどうかという話になり、チーフエンジニアが主導で実施することが決まりました。 チーフエンジニアとは スキルだけでなくプロダクト理解も高いメンバーで、プロダクトごとに任命されています。主な仕事はリリース対応や障害対応ですが、今回全社エンジニア活性化を目的に、活動をすることになりました。   FridayBashと違うところ 4.5人での開催ではなく全社横断エンジニア間で開催することになったので、自由参加としました。 そのため、参加してもらいやすい空気作りと相談を持ち寄りやすい方法を考えてやり方を以下のように変更しました。 ・Clubhouseの流行に乗って、名前をWPhouseと名付けた ・チーフエンジニア4人がモデレーターとなり場をまわす ・話したい内容は自由に誰でも記載可能で、事前に1,2個トークテーマを決める ・自由参加 ・途中からでも興味ある内容であれば参加しやすいように、今話している内容をslackに投稿   やってみて 参加者からの声 開催してみた結果、参加者からはこんなお声をいただきました。 ・楽しく参加できた！ ・紹介してもらったツールが役に立った！ ・トークだけではなくハンズオンもやってみたい ・参加時間が固定だと参加しにくい よかったこと ■ チーム、部署を超えてエンジニア同士話す機会になった ウエディングパークにはいくつかのサービスがあり、エンジニアはそれぞれの事業へ配属されているため普段の業務で関わることが少なかったり、同じサービス内でもチームが分かれていると会話をする機会は少ないので、ラフに会話を交わすことができる時間を作ることができました。 特に入社して1年目のメンバーが毎回来てくれたので、新しい繋がりを作ることもできたのではと思います。 ■ 日々思ってたけど聞けてなかったことが聞けた、役に立った 開発で詰まった時に相談することはよくありますが、リモートワークが主体となったことにより、「こんなシーンでどうしてますか」といったような自力で解決出来ることだけどもっと良い方法があるのでは？という疑問を話すことが少なくなっていました。このようなテーマでいろんな人と意見交換をできたことはとても良い収穫だったと思います。 ■ 定例で議論しきれなかった内容をWPhouseに持っていくことができた WPhouse開催日に全社横断のエンジニア定例を行って開発進捗やナレッジ共有、困りごと相談をしたりしています。そこで話しきれなかった議題を「続きはWPhouseで！」と持っていくことができ、定例の時間を短縮しつつ議論が流れない仕組みができたことも良かったです。 改善ポイント ■ 参加メンバーが固定化 開催時間を固定していたこともあり、参加できる人が固定化されてしまっていました。相談することが特になかったり、通常業務の時間に当てたいという人もいるため、全員が参加するというのはなかなか難しく感じます。 ■ もっと些細な案件ベースの相談などがしたかった 気軽な相談をする場が欲しいという声があったにも関わらず、トークテーマが参加者側から出て来ませんでした。今回の開催方法では、トークテーマに対して参加した人全員で会話をするので、そんな規模感で相談に乗ってもらうことではないな…という気持ちもあったのではと思います。また、週に1度の開催だったので、他の日に相談したいことがあった場合その日まで待てないといったこともあったと思います。 1ヶ月やってみてリニューアル 1ヶ月間この形式で開催を続け、振り返った結果こんな声が上がってきました。 ・もっとラフに参加、相談できる会にしたい！ ・もくもく会みたいな感じで作業しながらでも参加しやすい会にしたい！ 改善ポイントも含め、WPhouseはリニューアルをして開催を続けています。 どのように変えたかはまた別の機会にお伝えできればと思います。   最後に 全社エンジニア横断で行っている施策についてご紹介しました！ リモートワークでコミュニケーションを活性化させていくことは常に課題としてあるかと思いますが、これからもブラッシュアップしていきたいと思います。

こんにちは。前撮りなど結婚写真の撮影スタジオ・サロンを検索できる情報サイト「Photorait」のエンジニアリングマネージャーをしている武田( @takedajs )です。 弊社では、「エンジニアのやりがい」と「技術力」の向上を目的とした技術推進委員会という組織をEMとテックリードが中心となって運営しています。 一緒に運営してるテックリード二人の記事です。 「技術力×リーダーシップ」のテックリード。立ち上げから1年の振り返り | 株式会社ウエディングパーク’s Blog 今回は、技術推進委員会が始めた新たな取り組みである「ウエパテックアカデミー」を紹介します。 ウエパテックアカデミーの概要 ウエパテックアカデミーは「 エンジニアが技術と仕様を、切磋琢磨しながら学ぶ取り組み 」です。 技術と仕様からテーマを選び、テーマごとに以下の流れで実施します。 1. テーマに沿ったテスト問題をGoogleフォームで作成し、参加者が解答(30分) 2. 正解率が低い問題を中心に、別日にテックリードが解説会を開催(30分) 3. 同じテーマで別の問題を作り、全員に再テストを実施(20分) ※ そのほか  ・　全てZoomを繋ぎながら実施  ・　テスト問題はテーブル設計やシステムに関するお問い合わせ対応など    エンジニア向け  ・　参加者：全エンジニア、ディレクター(任意) 2021年4月から開始して、まずウエディングパークのサイト中でも歴史が深く仕様が複雑なものをテーマの候補に上げ、以下を実施しました。 第1回目：CV計測まわり 第2回目：クチコミ 切磋琢磨する環境を作るために、インセンティブも用意しました。 【テーマ毎】 優秀者1名：5000円までの好きな技術書1冊贈呈  ・　再テスト実施時の最高点の1名  ・　同点の場合は、1回目の点数が高い方 ※ 好きな技術書を購入できる制度は既にありその場合は会社の所有物ですが、ここで贈呈されたものに関しては、個人の所有物になります。 【半期毎】 優秀者1名：グリーンジャケット贈呈  ・ 技術推進委員会で議論し、テスト結果や取り組む姿勢などを考慮して決定 ※ インセンティブを検討していた時に、松山選手がマスターズを優勝されたため、活性化になると思いその流れに乗っかりました笑 実施し始めた理由 技術推進委員会の目的であるエンジニアのやりがいと技術力の向上を目指して、全エンジニアメンバーに対してアンケートをとったところ、以下2つを推進していく必要があることが分かりました。 ・ 開発の不安点をなくし、自走できるメンバーを増やす ・ 緊張感のある切磋琢磨できる環境を共に創っていく(共創) 実施する施策を検討した結果「ウエパテックアカデミー」を開催することにしました。 実施した感想 良い点 【理解が深まる仕組み】 参加者に取ったアンケートで「テスト→解説会→再テストのおかげで理解が深まった！」との回答を多く頂くことができました。 理解しづらい箇所の解説を行うことで理解が深まり、再テストの平均点も1回目のテストと比べて上がっています。 【参加者同士の教え合い】 以前からエンジニア同士が雑談できる会を毎週金曜日に実施しています。 テストがたまたま金曜日に実施していたのもあり、参加者同士で雑談会中に分からないことを教え合っていました。 一人で勉強するより理解するスピードが上がっていたと思います。 【ディレクターも参加】 エンジニアは全員参加でディレクターは任意参加でしたが、何名かのディレクターが参加してくれました。 エンジニア向けのテスト問題で難しかったと思いますが、理解したいと積極的に参加してくださって運営として嬉しかったです。 改善点 【テーマごとに運営担当を変更する】 テーマ決定、問題作成、テスト2回実施、解説会実施をやる必要があり、実施し始めということもあり技術推進委員会のメンバーでやりましたが、工数がかかります。 仕組みを作ることができたのと今後継続して続けていくためにも、テーマごとに運営担当を変更していく予定です。 【技術よりのテーマを取り上げる】 優先度などの観点でこれまでの2回とも仕様よりのテーマを取り上げて実施してきました。 技術の理解度を上げたいメンバーの声もあるので、今後はAWSやCI/CD周りの技術よりのテーマも取り上げる予定です。 最後に エンジニアが技術と仕様を、切磋琢磨しながら学ぶ取り組みについて紹介しました。 実施のフロー、学び合える環境、インセンティブなどが効果的に動き、理解を深めて最高点を穫ることに意欲的なメンバーも多く、良い取り組みになりました。 継続して実施し、更に効果的な取り組みになるようにブラッシュアップしていきます。

こんにちは。 Photorait エンジニアのヒエイです。 Photoraitでは Webつく というWebサイト作成ツールを提供しており、Reactを使用しています。 フロントエンドテストを導入した話を書きます。 前提 Photorait Webつく技術スタック React 16.13 TypeScript 3.9 Jest導入 方針 Jest 、 Enzyme を利用 Jest facebook社製のテスティングフレームワーク。 Enzyme Reactテストライブラリ・ユーティリティツール。 パッケージインストール npm install --save-dev jest @types/jest ts-jest enzyme enzyme-adapter-react-16 @types/enzyme @types/enzyme-adapter-react-16 初期設定 React・Typescriptで実行のための初期設定 tsconfig.jest.json Jest実行用に別で用意。アプリケーション用tsconfigを上書きさせる形にしました。以下はサンプルです。 { "extends": "./tsconfig.json", "compilerOptions": { "moduleResolution": "node", "allowJs": true, "noEmit": true, "strict": true, "jsx": "react", "baseUrl": ".", "paths": { "~/*": ["ソースのあるディレクトリ/*"], }, "lib": ["ES2019", "dom"], "module": "commonjs", "target": "ES2019", "resolveJsonModule": true }, "exclude": [ "node_modules" ] }   jest.config.js Jest用設定ファイルを用意 const { pathsToModuleNameMapper } = require('ts-jest/utils'); const { readFileSync } = require('fs'); const { parse } = require('jsonc-parser'); const { compilerOptions } = parse(readFileSync('./tsconfig.jest.json').toString()); const moduleNameMapper = pathsToModuleNameMapper(compilerOptions.paths, { prefix: '<rootDir>/' }); module.exports = { preset: 'ts-jest', globals: { 'ts-jest': { tsconfig: 'tsconfig.jest.json', diagnostics: false } }, roots: ["<rootDir>/ソースのあるパス"], transform: { "^.+\\.(ts|tsx)$": "ts-jest", }, transformIgnorePatterns: [ "/node_modules/*" ], testRegex: "(/__tests__/.*|\\.(test|spec))\\.(ts|tsx|js)$", testPathIgnorePatterns: [ "/node_modules/" ], moduleNameMapper, moduleFileExtensions: [ "ts", "tsx", "js", "json" ] 実行 package.json を修正 "scripts": { ・・・ "test": "jest" }, ・・・ 実行は以下 npm run test テストコード設置 テスト対象の簡単な入力フォームを用意しました。 import React, { FormEvent, useState } from 'react' import { Button, Form, Header, Input } from 'semantic-ui-react' type Props = { text: string postRequest: (formValue: string) => void } const FormComponent: React.FC<Props> = ({ text, postRequest }) => { const [formValue, setFormValue] = useState(text) const handleChange = (changeValue: string): void => { setFormValue(changeValue) } const handleSubmit = (e: FormEvent<HTMLFormElement>): void => { e.preventDefault() postRequest(formValue) } return ( <> <Header as="h2">サンプルフォーム</Header> <Form onSubmit={(e): void => handleSubmit(e)}> <label htmlFor="sample_text">テキスト</label> <Form.Field width={8}> <Input id="sample_text" type="text" name="sample_text" placeholder="テキストを入力" value={formValue} onChange={(e): void => handleChange(e.target.value)} /> </Form.Field> <Button> 送信 </Button> </Form> </> ) } export default FormComponent テキストボックスに入力した内容をform submitで送るコンポーネントです。 postRequest には送信メソッドを設定します。   jestテストコードを簡単には以下の形で用意します。 import React from 'react' import { mount, configure } from 'enzyme' import Adapter from 'enzyme-adapter-react-16' import FormComponent from '~/components/form' configure({ adapter: new Adapter() }) const formPostRequest = jest.fn() describe('sample form test', () => { test('form submit test', () => { const inputText = 'テキストテキストテキスト' const wrapper = mount( <FormComponent text="" postRequest={formPostRequest} /> ) wrapper .find('input') .find({ name: 'sample_text' }) .simulate('change', { target: { value: inputText } }) wrapper.find('form').simulate('submit') expect(formPostRequest).toHaveBeenCalledWith(inputText) }) })   解説 enzyme読み込み import React from 'react' import { mount, configure } from 'enzyme' import Adapter from 'enzyme-adapter-react-16' configure({ adapter: new Adapter() }) React 16 を利用する際の読み込みは こちら を参考   mock化 const formPostRequest = jest.fn() アタッチするpostリクエスト用関数をjestのmock関数で用意します。   Jestテスト const wrapper = mount( <FormCompornent text="" postRequest={formPostRequest} /> ) フォームコンポーネントを展開します。   const inputText = 'テキストテキストテキスト' wrapper .find('input') .find({ name: 'sample_text' }) .simulate('change', { target: { value: inputText } }) inputテキストボックスに文字列を入力しています。   wrapper.find('form').simulate('submit') expect(formPostRequest).toHaveBeenCalledWith(inputText) フォームをサブミットさせ、アタッチした formPostRequest 関数に入力した文字列通り渡ってくるかテストしています。   懸念点・要調査 React Hooksの状態をEnzyme側で取得ができず、状態テストを上手く行えないようでした。 状態変更後のエレメントの数の変化等でテストを入れる事にしています。 まとめ 簡潔にも汎用的にもテストを仕込めるのですごく便利でした。 次回は storybook とスナップショットテスト（ storyshot ）について触れたいと思います。    

こんにちは。エンジニアのなりです。 フォトウエディングの決め手が見つかるクチコミサイト「Photorait」 で開発を行っています。   Webサービス開発をする中で、新鮮な視点の意見を取り入れるために社内で始めた取り組みについてご紹介したいと思います。 その名も「ユーザー体験ワーク」。 内容を一言でいうと、社内の自分が普段携わっていないサービスを、実際にユーザーになりきって使ってみて感じたことを正直にフラットにシェアするというものです。   「ユーザー体験ワーク」を思いついた背景 ウエディングパークは、結婚関連のメディアを複数運営しており、それぞれに担当エンジニアが付いて運営をしています。 私は新卒入社をしてから半年前まで丸５年、結婚準備クチコミ情報サイト「Wedding Park」の開発を担当していました。 その後、半年前にフォトウエディングのクチコミサイト「Photorait」へ異動することが決まり、まずはサービス理解・業界理解をせねば！と、結婚式の前に結婚写真を撮影する「前撮り」を都内でする想定で「前撮り 都内」と検索ブラウザの検索フォームに入力し、前撮り探し中ユーザーになりきって撮影スタジオ探しをしてみました。 すると、「あれ？こんな条件で検索したいときってどこから探せばいいの？」「え！ここボタンだと思ったけどボタンじゃない！詳細みたかった…」など、多く気づきを得ることが出来ました。 どうしても毎日仕事で携わっているサービスは、違和感に気づく感覚が鈍ってしまうので、“普段別のサービスに携わる人の意見を定期的に聞くことができる仕組みを作っちゃおう！”と思いました。   「ユーザー体験ワーク」の目的 改めて、目的を整理します。 ①サービスの課題を新鮮な視点で発見するきっかけを作る ②担当サービス以外の理解を深め、掛け算を生む状態をつくる ①は背景で説明した内容です。 ②は、①の副産物的に生じるメリットであり、視野を広げるという点で重要なので、こちらも施策目的としてセットしたいと思います。   「ユーザー体験ワーク」の内容 今回は、フォトウエディングのクチコミサイト「Photorait」と結婚指輪・婚約指輪のクチコミサイト「Ringraph」のメンバーで相互にユーザー体験を行いました。   ①ペルソナを設定 ユーザーになりきって具体的に探してもらう必要があるので、居住地や嗜好などの設定を行いました。 ②お互いのメディアをつかってみる PhotoraitのメンバーはRingraphを使って指輪探し、RingraphのメンバーはPhotoraitを使ってスタジオ探しを行いました。 ③感想をシェア シェアした項目は以下に記載します。 検索ワード 使用した検索軸 検討したスタジオ/指輪ブランド 決定したスタジオ/指輪ブランド 決め手 使いやすかったポイント 伸びしろポイント   「ユーザー体験ワーク」をやってみての感想 リアルな意見を聞けて質問をその場で出来る この取り組みをして一番盛り上がるのは、感想シェアをしたあとの質問タイムです。 「知りたい情報がすぐに見つかってよかった」という意見に対して、「知りたいと思った情報ってどんなものか具体的に教えて！」という質問が出たりします。関係性を構築できている社内メンバーだからこそ、意見を何でも言い合えるのは大きなメリットでした。   担当サービス以外の理解が深まる 自分自身がユーザーになりきって使ってみることで一番感じたメリットはこれです。 自社のサービスなので、自分が開発担当でないサービスも知っているのは当然です。 ですが、ペルソナを設定して実際にユーザーとして指輪探しをしてみると、「知っている」と「使ったことある」の違いが大きいことに気づきます。 何か他サービスで新機能がリリースされたときに、ユーザーにとって何が便利になるのかが想像できるので、「へえ～！すごいな！おめでとう！」という感想で終わらず、自分の担当サービスへの水平展開がとても考えやすくなりました。   メンバー理解も深まる これは施策を始めた時点では想像していませんでしたが…メンバー理解が深まるきっかけにもなると思いました。 ペルソナを設定しているとはいえ、やはりその人自身の嗜好性や探し方の癖があります。 感想をシェアしてもらう中で、そんな一面が垣間見える場面があり、在宅勤務が増えた今、よい機会になっていると思います。   まとめ ユーザー視点を取り入れるための手軽にできる方法、いかがでしょうか？ 外部の方に実施いただくようなユーザー調査も、もちろん重要だと思います。 ですがお金も時間もかかるし、ぶっちゃけどうだった？というお話は引き出しきれないこともあるかなと思います。 その点、社内でやるのは、比較的簡単に初めて見ることができるのでオススメです。 今回は別サービスに携わるメディア運営メンバー同士でやった例をご紹介しましたが、バックオフィスの方や営業の方を巻き込むのも新しい発見があって面白いと思うので、最近ユーザー視点に立ちにくくなったなと思う方がいれば、ぜひ社内の方を巻き込んでみてください。

こんにちは。ウエディングパーク新卒3年目エンジニアのさー（ @__south__373 ）です。 先日所属チームが変わり、 Ringraph という結婚指輪・婚約指輪の口コミサイトを担当することになりました。 ディレクターから「とにかく速度改善をしたいんだ」という話を聞き、まずはサイト理解がてら全体の速度を把握できる仕組みをつくることにしたのでその内容を紹介したいと思います。 目次 作成イメージ どのページが遅いのかを把握できるダッシュボード どのフェーズに改善余地があるのかを把握できるダッシュボード リリースによって速度が落ちていないかを確認できるダッシュボード 最後に 作成イメージ 可視化したいポイントは3つありました。 どのページが遅いのかを把握できる どのフェーズに改善余地があるのかを把握できる 今後施策をリリースをした際、そのリリースによって速度が落ちていないかを確認できる Ringraphではサイトパフォーマンス監視にNew Relicが導入されているので、この3つを満たすダッシュボードをそれぞれ作成することにしました。   どのページが遅いのかを把握できるダッシュボード どのページがそもそも遅いのか全体感を把握したいと思い、Apdexで数値化することにしました。 Apdexとは Apdexは、ウェブアプリケーションやサービスのレスポンスタイムについて、ユーザー満足度を計測するための業界標準です。（ New Relic より引用）   Apdexは自分で閾値を設定でき、設定した閾値と応答時間から計算がされるもので、0~1の値で示されます。1に近いほど満足度が高く、0に近いほど満足度が低いです。 例えば閾値を1秒に設定すると、1秒以下で応答が返ってくれば満足、1秒〜4秒以下（閾値の4倍以下）は許容範囲、4秒〜は不満と判断され、Apdexが算出されます。 実行クエリ サーバーサイドのレスポンスとしては0.3秒以下を目指せると素敵なので、閾値を0.3に設定してそれぞれのページがどれほど解離があるかを数値化します。 -- 実際は改行なく実行する必要があります SELECT apdex(duration, t:0.3) FROM Transaction WHERE appName = `対象アプリ` AND name = `ウォッチしたいディレクトリ` SINCE 1 week ago 作成したダッシュボード ランキング検索TOPとクチコミ検索はまさかの0… これは改善のしがいがありますね！   どのフェーズに改善余地があるのかを把握できるダッシュボード 1つ目のダッシュボードでどのページが遅いかを把握することができました。 次に、速度が遅い場合サーバー側を改善すれば良いのか、JSやCSSを改善すれば良いのか、描画を改善すれば良いのかをわかるようにするために各指標を表示することにしました。各指標の数値と今後速度改善を行った際に視覚的にも変化がわかりやすいようにグラフも表示させてみます。 実行クエリ 各指標については ドキュメント に記載の通りですが、下記のようなクエリで抽出できます。 -- 実際は改行なく実行する必要があります SELECT average(webAppDuration) as 'serverside', -- サーバーサイドレスポンスタイム average(domProcessingDuration) as 'DCL', -- HTMLパース時間 average(pageRenderingDuration) as 'Load' -- 全ての画像・CSS・Javascriptのダウンロードと実行時間 FROM PageView WHERE appName = `対象アプリ` AND name = `ウォッチしたいディレクトリ` SINCE 1 week ago 数値表示 Chart typeをBillboardにすると数値として表示できます。 グラフ表示 表示したい期間の前に TIMESERIES をいれると、Chart typeでAreaを選択できるようになります。 作成したダッシュボード 検索系を比較した時、クチコミ検索が一番遅くサーバー側が改善できそうなこと、ランキング検索詳細やこだわり検索詳細では描画側に改善ポイントがありそうなことがわかりました。 リリースによって速度が落ちていないかを確認できるダッシュボード 1つ目のダッシュボードで使用したApdexをここでも使います。今回は変化をウォッチしたいので、現在の速度が理想の数値であると仮定してそれぞれのページごと閾値を設定し、数値が下がったページがあればすぐに気付けるようにします。 閾値の算出方法 それぞれのページでApdexが0.95となるように閾値を設定します。Apdexが0.95となる閾値はリクエストの90パーセンタイルのレスポンスタイムでわかるので、下記のクエリで算出できます。 -- 実際は改行なく実行する必要があります SELECT percentile(duration, 90) FROM Transaction WHERE appName = `対象アプリ` AND name = `ウォッチしたいディレクトリ` SINCE 1 week ago 実行クエリ ウォッチしたい各ページにおいて、Transaction（サーバーサイド）とPageView（ページ読み込み全体）のduration（レスポンスタイム）に対してApdexを設定しました。 -- 実際は改行なく実行する必要があります SELECT apdex(duration, t:1.1) FROM Transaction WHERE appName = `対象アプリ` AND name = `ウォッチしたいディレクトリ` SINCE 1 week ago 作成したダッシュボード 案件がリリースされるタイミングでウォッチしていき、例えば上の画像だと商品クチコミ一覧のスコアが下がっているので、何かのリリースでこのページの速度が下がっていることがわかります。 最後に 可視化することで全体感を把握でき、改善ポイントがわかりやすくなりました。今は毎週ダッシュボードを開いて数値を確認していますが、Apdexの値が下がったらslackに通知するようにすると手間が減って良いなと思うので、ウォッチする指標と合わせて改善していきます。 今後はこのダッシュボードをもとに速度改善の施策を行ったり、リリースによる速度低下をウォッチして対応していきたいと思います！

こんにちは。 Photorait エンジニアのヒエイです。 Photoraitのアプリケーションでは言語にPHPを採用しています。 去年 PHP8 のメジャーアップデートがあり、PhotoraitでもPHP8にバージョンアップを行いました。 今回はバージョンアップへ向けてやったことと、リリース後のパフォーマンス結果を書きます。 目次 前提 開発初期 開発環境作成と検証 リリースとパフォーマンス計測 まとめ 前提 PHPバージョン： 7.2 フレームワーク：CodeIgniter 3系 開発初期 開発サーバーを立てる前に、dockerでの PHP8のimage を使ってアプリケーション検証を行いました。 検証した内容は以下の事。 依存パッケージ検証 composerパッケージバージョンアップ バージョン依存により利用パッケージ差し替えなど PHP8にしたことによるエラー修正 パフォーマンス計測 エラー修正 8系にアップデートした事で発生したエラーや、テスト中に発見した既存バグ修正をただひたすら行いました。 noticeエラーがwarningになったり、undefinedエラーも多数発見され修正作業。 function内デフォルト引数 関数の引数にデフォルト値を設置する際、必須引数が後にある場合は非推奨になります。古いコードに少しあり修正をおこないました。 <?php 　　　function test($a = [], $b) {} // 非推奨 　　　function test($a, $b) {} // 変更 ?> PHP8非推奨リスト一覧 より implode構文エラー PHP7.4から非推奨 ではありましたが、8系はサポート終了しました。 // NG implode($array, ', '); // OK！ implode(', ', $array); 数値と文字列判定 数値と非数値文字列の比較判定が変わっています。 $condition = 0 // PHP7 $condition == '' // true // PHP8 $condition == '' // false   他8系にあたる変更点です。 非推奨 https://www.php.net/manual/ja/migration80.deprecated.php 下位互換性のない変更点 https://www.php.net/manual/ja/migration80.incompatible.php ローカル環境でパフォーマンス計測 opcacheと、PHP8新機能JITも有効にしレスポンス数値を確認しました。 opcache・jitの有効 zend_extension = opcache opcache.enable = 1 opcache.enable_cli = 1 opcache.jit = tracing opcache.jit_buffer_size = 128M   レスポンス数値集計はApache Benchを利用。 ab -n リクエスト数 -c 並列実行数 -l "https://local環境ドメイン.net/エンドポイント"   PHP7.2(キャッシュなし) PHP8.0.1(キャッシュなし) PHP8.0.1(opcache) PHP8.0.1(opcache・jit) Time taken for tests[sec] 3.556 4.779 1.193 1.146 Requests per second[#/sec] 14.06 10.46 41.92 43.63 Time per request[ms] 711.156 955.827 238.552 229.222 Time per request[ms] (across all concurrent requests) 71.116 95.583 23.855 22.922 上記は一部のページで行ったテスト結果です。 ローカル環境でのテストではありますが、opcacheとjitの効力ありパフォーマンス改善が見られました。 PHP7.2と8系のキャッシュ無しの場合は、若干PHP8が遅くなった印象。フレームワークやライブラリとの関連性もあるのでチューニング次第で変わりそうでした。 開発環境作成と検証 開発サーバーを立て、検証をスタートさせます。 サーバー立ち上げ時にPHP8の マイナーアップデート が随時リリースされ、採用バージョンも更新を行っていきました。 composerパッケージでも、バージョンアップ開発スタート時には8系に非対応だったものも随時アップデートがリリースされてゆくことも多かったです。 CodeigniterでのPHPunitジョイントツールの ci-phpunit-test もその１つでした。 New Relic Photoraitではサイトパフォーマンス監視にNew Relicを利用しています。 バージョンアップ対応途中、New RelicはまだPHP8対応されてない事が発覚。 開発陣で打ち合わせを重ね、New Relicを待たずバージョンアップリリースを先行しました。 PhotoraiチームはNew RelicのPHP8対応をとても心待ちにしております。 リリースとパフォーマンス計測 リリース後は Sentryの監視 を徹底。テストで発見できなかったエラーが幾つか上がりhotfixの修正対応を行いました。 落ち着いた後にパフォーマンス値集計。 opcache・jitの効力もあり、大幅なレスポンス数値の改善が見られました。 ※内容は一部です 対象パス PHP7と8の差分（ms） 改善% / -85 37.78% /studio/.*$ -628 46.90% /studio/.*/photo -317 39.82% /studio/.*/plan -452 41.39% /studio/.*/option -358 39.60% /studio/.*/privilege -238 45.59% /studio/.*/review$ -1208 72.73% /studio/.*/review/.* -1298 70.62% /studio/.*/kodawari/.* -323 47.99% /studio/.*/experience$ -477 48.08% /studio/.*/experience/.* -362 42.94% /studio/.*/photographer/.* -547 58.19% /studio/.*/dress$ -300 31.32% /studio/.*/dress/.* -295 33.41% /studio/.*/blog$ -432 54.00% /studio/.*/blog/.* -646 55.88% /search/area/.* -353 39.57% /search/kodawari_search.* -239 34.99% /search/kodawari_introduction/.* -180 30.35% /search/plan/result.* -301 37.25% /search/photographer.* -107 34.19% /search/resort$ -147 31.96% /search/resort\?.* -217 36.29% /search/photo/result.* -267 27.84% まとめ チューニングが施しきれていない部分もまだありますが、PHP8にして早速効果が出てきて嬉しいです。 またエラーが厳格化された事により古いコードの修正には手を焼きましたが、これからの開発では助かる事も多いと思います。 ぜひ、 新機能も 使いながら開発を楽しんでゆきたいです。  

こんにちは、インフラエンジニアの綿引です。 最近、弊社で WordPress を使用する案件があったのですが、WordPress だとどうしてもローカルストレージに書き込みを行うため、サーバ側の冗長化のため Amazon EFS を試してみました。 そこで今回は EFS の概要と作成方法からマウントまでについて記載したいと思います。 対象の方は以下のような方でしょうか。 AWS で WordPress を 運用している EC2 やコンテナ環境で共有ストレージを検討している オンプレだが AWS 環境で共有ストレージを検討している Amazon EFS とは Amazon EFS とは一言で表すと [共有ストレージサービス] です。 EFS は以下のような特徴があります。 OS から NFS マウントができる (NFSv4 プロトコル) 料金は実際に使用した分のみ発生 ファイルの追加・削除に合わせて自動で拡大・縮小 クラウドだけでなくオンプレでも使用できる [標準ストレージクラス] と [低頻度アクセスストレージクラス] の2つのストレージクラスを提供 [1ゾーンストレージ] という安価なストレージクラスが追加された 標準ストレージクラス と 低頻度アクセスストレージクラスは以下のような特徴があります。 標準ストレージクラス 普通にファイルを保存するとまずは標準ストレージに格納される 料金は使用したファイルシステムストレージ分のみ発生 ストレージ分の料金は低頻度アクセスストレージクラスより高い 低頻度アクセスストレージクラス ファイルを一定期間使用しないと低頻度アクセスストレージに自動で移行される 移行される期間は [ライフサイクル管理] にて指定できる 料金は使用したファイルシステムストレージ分と データ転送量の両方 に発生 ストレージ分の料金は標準ストレージクラスより安い 尚、ライフサイクル管理の期間は以下のように 7日・14日・30日・60日・90日 で選択することが可能です。 また 1ゾーンストレージ に関してですが、EFS は作成する際に [可用性と耐久性] の項目で [リージョン] か [One Zone] で選択できます。 この際 [One Zone] を選択することで、1ゾーンストレージを使用することができます。 内容は上記に記載の通りですが、保存が一つの AZ に絞られ冗長化が失われる代わりに [リージョン] の約半分の料金で使用することができます。 開発環境など冗長化よりコストを重視するような環境ではありですね。 料金体型 続いて料金体型に関して、以下にざっくりと一覧にしましたが細かいところは記載しておりませんので、詳細は 公式の料金ページ をご覧ください。 標準ストレージ (GB-月) 0.36USD 標準 – 低頻度アクセスストレージ (GB-月) 0.0272USD 1 ゾーンストレージ (GB-月) 0.192USD 1 ゾーン – 低頻度アクセスストレージ (GB-月) 0.0145USD 低頻度アクセスリクエスト (転送 GB あたり) 0.012USD プロビジョニングするスループット (MB/秒-月) 7.20USD   仮に50GBのストレージを EFS で用意したとすると、全て標準ストレージに保存しても約2,000円ぐらいでしょうか？ サーバ側とは別料金にはなりますが、そこまで高い感じではないですね。 EFS 作成からマウントまで 検証環境について 今回の検証環境は以下です。 コンピューティング : EC2 OS : Amazon Linux2 では早速 EFS を作成していきます。 セキュリティグループの作成 まずは EFS に設定するセキュリティグループを作成していきます。 作成するのは EC2 から EFS をマウントする用のセキュリティグループ です。 公式のユーザーガイド を参考にプロコトルには EFS の “2049” を、ソースには [EC2 に付与しているセキュリティグループ] を指定し、名前は適当に [security-efs] としました。 これでセキュリティグループの作成は完了です。 EFS の作成 次は EFS の作成を行います。 マネジメントコンソールから EFS のコンソールにアクセスし、 [ファイルシステムの作成] を選択します。 以下の項目を入力したら [作成] を選択します。 名前 : efs-test Virtual Private Cloud (VPC) : EC2 と同じ VPC 可用性と耐久性 : リージョン 上部で述べた [可用性と耐久性] ですが、今回は [リージョン] で作成していきます。 これで EFS のファイルシステムの作成が完了しました。 作成が完了すると先ほど指定した VPC に存在するサブネットに対して、各 AZ に [マウントターゲット] が作成されます。 確認方法は作成したファイルシステムを選択し、[ネットワーク] タブを選択すれば進捗が確認できます。 これは少し時間がかかるので、気長に待ちましょう。 このマウントターゲットが作成されればもう使用はできるのですが、セキュリティグループがデフォルトになっているので、先ほど作成した EFS 用のセキュリティグループに変更します。 [ネットワーク] タブ から画面右の [管理] を選択します。 するとマウントターゲットの現在の設定が出てくるので、[セキュリティグループ] を先ほど作成したものに変更し、最後に [保存] を選択します。 これで EFS の設定は完了です。 今回特にライフサイクル管理の設定は変更しませんが、実際に使用する際は [ 低頻度アクセスストレージクラス] を意識し、環境にあった 設定に変更しましょう。 最後に EC2 でマウントを行っていきます。 EC2 にて EFS をマウントする 早速マウントといきたいところですが、今回は EFS のマウントに伴い amazon-efs-utils ツール を使用します。 amazon-efs-utils はクライアント側にインストールする、EFS をマウントするためのツールで、TLS を介してのマウントや、 IAM を使用して認証させる際などもできます、 インストール方法はいくつかあり  yum や git clone などでできますが、今回は yum で実施します。 yum install amazon-efs-utils なお、各OSのインストール方法については 公式のユーザーガイド を参考にしていただくとよろしいかと思います。 次にマウントポイントに [/efs-test] というディレクトリを作成します。 mkdir -p /efs-test そして以下のコマンドで EFS をマウントします。 mount -t efs [ファイルシステムID] [マウントしたいディレクトリ] ※ 実際はこのようなコマンドです。 mount -t efs fs-6ddd7f4d /efs-test/ これで無事マウントができました。 df の結果見てみます。 df -h Filesystem Size Used Avail Use% Mounted on fs-6ddd7f4d.efs.ap-northeast-1.amazonaws.com:/ 8.0E 0 8.0E 0% /efs-test 問題なくマウントできているようですね。 fstab にも書いてみる fstab に記載する際は以下のような形です。 [ファイルシステムID] [マウントポイント] efs _netdev 0 0 ※ 実際はこのような記述です。 fs-6ddd7f4d /efs-test efs _netdev 0 0 なお、マウントのオプションは適当に入れたので、各環境で変更いただければと思います。 マウントオプションの詳細は github に記載されていましたので、詳細は github の Usage 部分  を参考にされると良いかと思います。 これで EFS の作成からマウントまでができました。 使用量なども EFS のコンソールから確認できて便利です。 最後に 今回は AWS EFS を作成してマウントする方法を検証しました。 WordPress の冗長化をどうしようか悩んでいた私にとっては非常にありがたいサービスです。 コンテナなど他にも用途がそこそこありそうなので、いろいろ使ってみようと思います。

ウエディングパークでデザイナーをしています。内田（ @PANbooooo ）です。 先月、デザイナーチームで最新のデザイン技術を学び、スキルアップや事業価値向上に向けてのフックにする「1DAYスキルアップワーク」を行いました。 今回はその内容について紹介したいと思います。 目次 1DAYスキルアップワークの内容 発表タイム 振り返り まとめ 1DAYスキルアップワークの内容 自社サービスに取り入れられそうなトレンドデザイン、ツール、コーディング技術などを実際に調査・検証し、発表しました。 検証した内容について 今回は、各々が普段から気になっているツール、コーディング技術、トレンドデザインという幅広い分野のなかで1つピックアップし、検証しました。 ・パララックスを使った表現を試してみた (Kさん) ・ニューモフィズムにチャレンジしてみた (Iさん) ・3Dイラストレーションにチャレンジ (Yさん) ・トレンドのコードフォーマッターについての調査 (Uさん) ・最新cssプロパティを試してみた (Nさん) ・Figmaを使ってみた (Sさん) etc タイムスケジュール ワークについての説明と確認 0.5h 検証タイム（ひとりひとりもくもくと進めていきます） 4.0h 発表タイム（デザイナーに限らず、誰でも参加OKでさまざまな部署・チームの方に向けて発表します） 1.0h 発表タイム 実際にどんなことを検証したのか、発表資料をいくつかピックアップしてチラッとお見せします。 ニューモフィズムにチャレンジしてみた (Iさん) 新しいデザインの手法として注目の「ニューモフィズム」を深く理解し、自社サービスに反映したらどうなるかを検証した発表でした。 前々から気になってはいましたが、「どう見せるのがいいのだろう・・・。」と思っていたため、すごく勉強になりました。 3Dイラストレーションにチャレンジ (Yさん) 「3Dイラストレーション」と聞くと、難しい印象で、mayaなどの使い慣れていないアプリケーションを習得する必要があると思っていましたが、Adobe Illustratorでもちゃんと再現できてびっくりしました！ぜひサービスに取り入れたいです！ トレンドのコードフォーマッターについての調査 (Uさん) この検証をきっかけに、チームのエンジニアに提案し、実行することが決定しました！ 実際にアクションに繋げることで、このスキルアップワークをやる意味がより強くなりますね。 振り返り 発表後はすぐにデザイナーチームでKPTを用いて振り返りを行いました。 良かった点 ■ 1日集中でアウトプットまで出来る 限られた時間の中でインプットからアウトプットまでできるため、集中して検証や発表資料の作成を一気に進めることができました。 また、事前に日程を決めておくことで、他のミーティングが入る可能性も低くなり、より集中できる環境を作ることができます。 ■ 他の部署・チームの方に発表することで、デザイナーチームのアピールにもなった 発表タイムでは他の部署・チームの方をオーディエンスとして招き、デザイナーチームの取り組みを知ってもらう機会となりました。 また、発表を通して会社全体のデザインに対する知識の底上げも出来たと思います。 改善点 ■ 検証タイムの途中で進捗共有や交流タイムがあっても良かった 今回は、11:30〜12:00の「スキルアップワークについての説明と確認」の時間にチーム全員顔を合わせただけで、検証タイム以降は発表タイムまで、途中チャットツールで連絡を取り合いながら、基本的にはひとりひとり作業を進めていました。 ですが、進捗共有や交流タイムなどを検証タイムに挟むことで、方向性が間違っていないかを確認できたり、悩んだ箇所について気軽に相談できたと思います。 ■ 非デザイナー向けに発表内容の工夫が必要 特にコーディング系の調査についての発表は、非デザイナーの方にとって難しい内容となってしまったかもしれません。限られた時間の中で、検証から発表資料作成までを行うため、難しいかもしれませんが、次回またコーディング系の調査について発表する際には、非デザイナーの方を考慮した分かりやすい発表ができると良いと思います。 やってみよう ■ テーマをもっと絞ったり、リクエスト制を導入してもいいかも 今回は、各々が気になったテーマを持ち寄って検証をしましたが、「デザイン系」や「cssプロパティ系」など、より狭いカテゴリ内で各々がテーマを見つけるのも、面白いと思います。また、「あの人にあのことを発表してほしい！」など、リクエスト制を導入しても良いと思います。 まとめ 自分がずっと興味を持っていたけれど、なかなか時間が取れなくて後回しにしていた気になるトレンドについて、短期集中で理解を深めることができ、スキルアップに繋がったと思います。 また、開催後も普段から「次回のスキルアップワークでこれをテーマにしよう！」と、ワークを意識した情報収集をすることで、自分自身のキャッチアップの視野が広くなった気がします。デザイナーのスキルアップにはおすすめの取り組みなので、ぜひやってみてください。

ウエディングパークでデザイナーをしています。内田（ @PANbooooo ）です。 今回はデザインチームで行なっているLT会について紹介したいと思います。 LT会について デザインチームでは毎週30分の定例の中で、事前に決めたテーマについて発表をするLT会を行なっており、LTを通して各チームの開発状況や良い取り組みなどをキャッチアップしています。 過去のテーマとしてはこんな感じです。 自己紹介 最近開発でチャレンジできたこと／しくじり 私のチーム共有 ちなみに前回のデザイナーLTの記事は こちら になります。 今回紹介するLTについて チーム全体のスキル平均やデザイナー各々の特性を知るため、また、プライベート面を含めた相互理解、デザイナーとしてどう成長していきたいかをお互いに知るために今回は各のデザイナーとしての「スキ・キライ・得意・苦手」と、プライベートにおける「スキ・キライ・得意・苦手」、そして直近の未来での自分の将来像を共有し合いました。 使用したスライドはこんな感じです。 スキルについての「スキ・キライ・得意・苦手」 プラーベートに関する「スキ・キライ・得意・苦手」 「スキ・キライ・得意・苦手」の共通点 自分の「スキ」の共通点や、「キライ」の共通点を改めて考えることで、自己分析にも繋がります。 理想の将来像について 自分が1年後、3年後、5年後にどのようなデザイナーになっていたいかを伝えることで、互いに成長を支えることに繋がります。 今回は、ウエディングパーク初の新卒デザイナー採用で入社した1名と、ディレクターからデザイナーへジョブチェンジした1名、計2名の資料を一部抜粋して紹介します。 新卒メンバー ジョブチェンジしたメンバー 今回のLTの振り返り 同じチームメンバーの「スキ・キライ・得意・苦手」はなかなか共有するタイミングもないし、分かっているようで分かっていなかったりしますよね。 今回、このLTを実践したことで、ひとりひとりのスキ・キライ・得意・苦手はもちろんのこと、チーム全体の苦手分野や得意分野も知ることができました。 参加したデザイナーメンバーの感想としてはこんな感じです。 チームメンバーの傾向が見えてとても面白かったです！共通している点と違っている点も分かり、お互いのことを知るきっかけになりました！ 皆さんの得意分野や苦手分野などを伺うことができ、共感や意外な一面を知ることができました！ みんなで一緒に気持ちよく働く上で、「相互理解」は欠かせないものだと思います。 今後もLTを通して、デザイナーチームの相互理解を深めていきたいと思います。

こんにちは。前撮りなど結婚写真の撮影スタジオ・サロンを検索できる情報サイト「Photorait」のエンジニアリングマネージャーをしている武田( @takedajs )です。 前回書いた記事では、エンジニアリングマネージャーの立場からリモートワークの「良い点」、「課題点」、「マネジメント」について書いて書きました。 エンジニアリングマネージャーが9ヶ月リモートワークして思ったこと | Wedding Park CREATORS Blog 今回は、リモートワークで働くエンジニアの悩みを解決する施策を実施しましたので紹介します。 リモートワークでの悩み 設計を考えたりコードを書いている時は、固まった時間集中して対応した方が効率が良いので、一部のエンジニアからはリモートワークの方が生産性が上がるという声を聞きます。 一方、以下のような悩みの声も聞きます。 ・ ちょっとした質問や相談をしにくいので、設計やサイトの仕様について一人で悩む時間が増えた ・ 自分や他の人が気になっている技術やテックニュースなどを話し合いたい このような悩みを解決するためにチームのエンジニアと話し合い、一部のエンジニア対象で実験的に施策を実施してみました。 実施した施策の内容 FridayBashという名前の雑談会を実施しました。 FridayBashとは ・ Zoomをつなぎながら雑談する会 ・ 毎週金曜日午後の業務中に1時間で実施 ・ エンジニア4人とデザイナー1人の5人で実施 ・ 話す内容は技術系の話であれば何でもOK (テックニュース、気になってる技術、サイト仕様、設計etc) ・ 基本業務をしながら参加を推奨 (開発などで忙しい人も参加してほしいため) ・ 金曜日なので、「今週もお疲れさまでした！」で締める お酒を飲みながらLT会などを行うことをビアバッシュ(BeerBash)と言いますが、業務中に実施するのでさすがにお酒は飲めないので、BeerのところをFridayに変えた名前をつけました笑 2ヶ月ほど実施したのですが、以下のようなトークテーマで盛り上がりました。 ・ オススメの技術系ポッドキャストの紹介 ・ 気になってるテックニュース ・ 最近読んで良かった本や雑誌の紹介 ・ みんなが考えてるエンジニアのキャリア ・ パフォーマンスが悪い箇所の改善方法を教えてほしい ・ コードレビューを出すときのMRのファイル数について ・ 最高のツールを見つけたので紹介したい etc 改めて話したテーマをまとめてみたのですが、こう見ると色々なことを話してますね笑 特に、「コードレビューを出すときのMRのファイル数」は色々な意見が出たので良い時間でした。 実施した感想 良い点 【技術の話に特化して雑談できる】 職種関係ないメンバーが集まって雑談する機会は多くあるのですが、そういった場では技術の話はなかなかできません。 エンジニア同士で話す何気ない技術の雑談が、開発の生産性向上や業務のモチベーションアップに繋がるなと改めて実感しました。 【業務をしながら参加できる】 業務中に行うこういった施策は、開発業務が忙しくて参加できなくなることがあります。 そのため、FridayBashでは業務しながら参加を推奨しており、その結果メンバーの出席率も高かったです。 【参加人数がちょうど良い】 エンジニアとデザイナーの合わせて5人で実施したのですが、話さない人が出ることもなく、テーマに対して全員が満遍なく発言できていたと思います。 多すぎると発言しない人が出たり、逆に少なすぎると会話が止まってしまうことがあると思うので、4~5人くらいで行うのが良さそうです。 　 懸念点 【話すテーマの枯渇】 始めて2ヶ月なので、今の所は毎回話すテーマがたくさんありました。 僕の方でテーマを多く用意したり、他メンバーからも積極的にテーマを募集することで、色々な話ができました。 ただ、今後続けていく上で話すテーマがなくなる可能性があるので、その時になったら対策を検討します。 最後に リモートワークで働くエンジニアの悩みを解決する施策についてご紹介しました。 一部のエンジニアが集まって実験的に実施したFridayBashですが、今後は少し内容を変えて会社の全エンジニア対象で実施することになりました。 今後も課題に対してまずスモールスタートで始めてみて、良い結果が出たら横展開するなどのトライアンドエラーを繰り返して、やりがいのあるエンジニア組織を作っていこうと思います。

ウエディングパークでデザイナーをしています。内田（ @PANbooooo ）です。 今回はデザインチームで行なっているLT会について紹介したいと思います。 LT会について デザインチームでは毎週30分の定例の中で、事前に決めたテーマについて発表をするLT会を行なっており、LTを通して各チームの開発状況や良い取り組みなどをキャッチアップしています。 過去のテーマとしてはこんな感じです。 自己紹介 最近開発でチャレンジできたこと／しくじり 私のチーム共有 今回紹介するLTについて 1年の始まりにぴったりな 「仕事面プライベート面において2020年頑張ったこと・2021年頑張ること」 をテーマにLTをしました。 今回は、デザイナー業務とチームづくりに注力した2名の資料を一部抜粋して紹介します。 山下 内田 今回のLTの振り返り 四半期などの振り返りをする機会はあると思いますが、1年全体を振り返る機会はなかなか無いと思います。 ですが、実際にこのように振り返ってみると、「自分自身がどんなところに躓いて、どんな学びを得たのか」や、「1年前と比べてどれだけ成長したか」や、「2021年はどんなところに注力するべきなのか」が明確になり、目標設定にも繋がると思いました。 また、参加したデザイナーメンバーの感想としてはこんな感じです。 先輩方が頑張ったことを聞いて刺激にもなりましたし、プライベートの話も聞けて楽しかったです。また自分のやってきたことを振り返るいい機会にもなりました。 仕事面だけではなくプライベートも発表してもらえたことで、親睦が深まったかなと思います。 プライベート面も伺うことができたのは人柄なども知ることに繋がり、非常によかったです。 デザインチームでは今後もLT会を進めていきます。またぜひこのブログでも発信していこうと思います！！ 引き続きよろしくお願いいたします。

こんにちは。前撮りなど結婚写真の撮影スタジオ・サロンを検索できる情報サイト「Photorait」のエンジニアリングマネージャーをしている武田( @takedajs )です。 これまで会社でリモートワークを経験したことがなかったのですが、今年の3月下旬ごろ会社全体でリモートワークになり、もう少しで9ヶ月が経ちます。弊社では、一日に出社できる人数の上限を決め、出社 or リモートを各自選べる運用を行ってます。私の場合は、数回だけ出社したのみであとは自宅で働いてます。 エンジニアとしてリモートワークは前からやってみたかったことの一つでしたが、いざ自分がやってみることで初めて知れたことがありました。 今回は、エンジニアリングマネージャーの立場からリモートワークの「 良い点 」、「 課題点 」、「 マネジメント 」について思ったことを書きました。 リモートワークの良い点 1. 会議室をおさえる必要がない マネージャー業務をしていく上で、様々なポジションの人達とMTGすることが多く、一日の半分以上がMTGの時もあります。 MTGを設定する頻度も多く、会議室が空いてる時間を探すことに時間がかかり、少しストレスを感じていました。 社内的にもリモートワークの方が多くなり、私も自宅にいるため会議室をおさえる必要がなくなり、MTG設定にかかる時間が大幅に削減されました。これに関しては、同じく喜んでるマネージャーの方も多いはずです。 2. 緊急対応も全く同じ環境で対応できる 自宅にPCを持ち帰り、帰宅後や休日に緊急対応を行うことがあったのですが、自宅とオフィスの環境が若干違うため、色々とスムーズにいかないことがありました。 今では、環境の違いがないので、以前に比べてスムーズに対応できています。 3. メンバーのモチベーションが上がる 開発者にとって、静かな環境で開発をした方がパフォーマンスが上がるので、リモートワークを選択できるのは、チームにとっても本人にとってもメリットがあります。 私と同じくリモートワークをしてみたいと考えてたメンバーは以前から一定以上いたため、当たり前ですが、そういったメンバーのモチベーションは上がっているなと感じてます。 リモートワークの課題点 1. 一体感を作りづらい チームの高い目標を達成するためには、チームで一体感を作り、高い熱量を持って取り組むことが大切です。 リモート環境でも一体感を作ることはできますが、やはり直接会った時の方が、強い一体感を作りやすいです。 ただ、リモート環境にあった一体感を作る取り組みを行うことで、この課題は取り除けるのではないかと思います。 同じチームのメンバーが、一体感を作る取り組みを紹介した記事を書いてくれてます。 インハウスエンジニアだからこその楽しさ | Wedding Park CREATORS Blog 2. 一度も会ったことがない人がいる 出社している時は、他部署で入社された方に直接合う機会があるので名前と顔が一致していたのですが、最近入社された方に関して言うとまだ会ったことがない方もいらっしゃるので、なかなか名前と顔が一致しない方がいます。 マネージャーとして他部署の方と連携することも多いので、より他部署の情報をキャッチアップしていく必要があるなと感じます。 3. 勤務時間の管理 オフィスではカードキーをドアにかざすことで自動的に勤怠時間を管理できていましたが、リモートワークでは「業務開始と終了のメール」と「勤怠管理ツール」で勤務時間を管理しています。 自動ではなく個人の責任の元に手動で対応してもらうので、対応を徹底してもらうためにマネージャーが細かくチェックする必要があり、その分が負担になっています。 リモートワークのマネジメント リモートワークのマネジメントには、「 メンバーの状況をキャッチアップ 」と「 繋がりを実感できる場所作り 」をより積極的に行う必要があると思いました。それぞれに対して実施して効果があるものを共有します。 【メンバーの状況をキャッチアップ】 1. 毎日の日報確認 弊社では業務終了のタイミングで全社員が入ってるメーリングリストに日報を送る文化があります。 日報のフォーマットは決まっておらず、今日やったこと、思ったこと、感謝したいこと、などみなそれぞれ自由に書いてます。 チームメンバーはもちろん、他部署の方の日報も可能な限り毎日見るようにしているのですが、書いてる内容や文章量から、「なるほど、〜の実装方法に今悩んでるのか〜」や「あれ？今日の日報の文章いつもと少し違うな〜、なにかあったのかな〜」などキャッチアップできるので、リモートワークになってより日報文化の良さを実感しました。 2. 他マネージャーと情報共有 これまで同じ部署のマネージャーとは週1回のMTGでメンバーの情報共有を行っていましたが、メンバーの状況のキャッチアップがしづらくなったので、現在は週3回のMTGで情報共有を行うようにしています。 リモートワークが開始になった4月からの数ヶ月間は毎日MTGを実施していました。 他マネージャーから自分のチームのメンバーについてのことを聞いたりなど、かなり密に情報の共有を行っているので、マネージャー同士の一体感はリモートワーク前と比べても強くなりました。 3. 週1の1on1実施 1on1はリモートワークになる前から実施していますが、毎日会っていた時は少しの変化が気づきやすかったのですが、リモートワークになってから気づきにくくなっているので、1on1でのコミュニケーションの重要度が増しています。 【繋がりを実感できる場所作り】 1. TSUNAGIBA(つなぎば)施策実施 周りに誰もいない中で家でもくもくと働いてるのがツライというメンバーの声があり、毎日部署内のマネージャーがZoom部屋を作成(30分~1時間)し、メンバーは好きに入って もくもく or 雑談しながら業務して良い、TSUNAGIBAという施策を実施しました。 平均的に毎回3~6人くらい集まってくれたので、一定の効果はあったのかなと思います。 ただ、誰もこない時もあるので、その時は1人Zoomで寂しく働いてました笑 2. 全体朝会、開発朝会、開発夕会実施 前から実施していましたが、リモートワークになってからも部署全体の朝会とチームの開発朝会と夕会をそれぞれ10分ずつ実施してます。 朝会は業務モードへ切り替えるのに効果的ですし、朝にみんなの表情を見れると今日も一日頑張るか！という気持ちにもなると思います。 一日ずっとMTGがない日もあるメンバーもいるので、10分と短いですが繋がりを実感するためにも大事な時間です。 3. 定期的にリアルで集まる フォトレイトチームではリモートワークになってから、感染予防対策を行いつつ1度だけ全メンバーオフィスに集まりました。 最近別部署から移動してきたメンバーも複数人いたため、同じチームになってから一度も会ったことがないメンバーも多かったのと、より一体感を作るために一度集まってみるかという話になりました。 当日は、フォトレイトの未来について熱く話し合ったり、各メンバーのことがより分かるコンテンツなどもあり、リアルに会うメリットを改めて実感しました。今後も定期的に集まりたいという声もあったため、定期的に実施を検討しています。 最後に エンジニアリングマネージャーの立場からリモートワークについて思ったことを書いてみました。 リモートでのマネジメントに関しては、上手くいったこともありますが、まだ上手くできていないことも多くあります。 私と同じくリモートでのマネジメントで悩んでいるマネージャーも多くいらっしゃると思うので、この記事が少しでも何かのご参考になれましたら嬉しいです。 ウエディングパークでは、一緒に技術のウエディングパークを創っていただける仲間(エンジニア)を募集しています。興味のある方はぜひ一度気軽にお話ができたら嬉しいです！ 株式会社ウエディングパークの会社情報 – Wantedly https://www.wantedly.com/companies/weddingpark

こんにちは。ウエディングパーク新卒６年目エンジニアの成田です。 今回は、最近改めて感じた「インハウスエンジニアだからこその楽しさ」について お話したいと思います。   私は、今年の10月に、携わるサービスが変わりました。 20年以上の歴史があるウエディングパークの開発を卒業し、現在6年目を迎えたフォトレイトというサービスの開発にジョインしました。 開発の傍ら、組織活性化チームにも所属をしてこの３ヶ月で様々な取り組みをし、それにより私自身のサービス開発に対する向き合い方も変わったので、それをご紹介したいと思います。 組織活性化について まず、組織活性化チームって？ Photoraitチームは、エンジニアだけでなく、デザイナー・ディレクター・営業のサービス運営に関わるメンバーが全員所属しているチームです。 オンライン上でのやり取りが増えた中でもコミュニケーションの温度を維持する チームの団結力を強める この２点を活動の目的と定めて、活動をスタートしました。 何をやったの？ ①新チーム決起会の企画運営 自分を含め新メンバーが数名加わったので、お互いを知り、意識を合わせる時間を設けました。 「実は私〇〇なんです（今の私）」「この３ヶ月これ頑張ります（未来の私）」を、それぞれのメンバーに出してもらい、誰の宣言なのか当てるクイズをチーム対抗戦で実施しました。 意外な過去の話や、力強い宣言を聞くことができ、気合の入る機会となりました。 ②月初会の企画運営 毎月のチーム目標を共有します。内容だけでなく、達成するために今月誰がどんなアクションをするかも共有します。 全職種が参加して行うので、営業メンバーの目標も把握できますし、逆にエンジニア側の目標も知ってもらう機会になっています。 活性化チームとは別で個人的に実施したことも ①毎週金曜日のありがとうタイム 金曜日の開発チーム定例MTGの時間に、その週にあった感謝している出来事を発表し合います。チャットではなく、顔を見ながらお伝えするのがポイントです！ 金曜の夕方に、たくさんのありがとうを言われると単純に嬉しいというのもありますし、チームメンバーの知らなかった活躍を知ることが出来るのも、この取組みの良いところです。 ②毎週のチーム定例MTGでの営業現場の声共有会 アポイントの録画や社内共有に承諾いただけたクライアントのオンライン営業の様子を見て、質問やコメントをし合う機会です。営業現場の声を聞くことは、サービス改善のアイディアを発見できたり、開発したサービスがどのように活用されているかを知ってモチベーションが上がったり、良いことばかりです。 何が良かったか 「開発のモチベーションがとっても上がった」 チームの結束力が上がり活発にコミュニケーションを取るようになったことで、仲間の活躍に刺激をもらい、日々の仕事により前向きに取り組める 営業現場の声を聞くことで、自分の作ってる機能やサービスが、誰に、どのように、役に立つのか、をよりリアルに想像することができるようになる 「納期までに完成させる」ではなく、「現場の困りごとを解決できる」というモチベーションでサービスを継続的に育てていく気持ちが生まれる 私自身、今までは「ユーザーに役立つ サービス をつくる」というところをゴールとして行動・思考していた場面が多かったように感じます。 それがこの３ヶ月で、「役に立つ 事業 をつくる」という視点に変わりました。 ユーザーだけでなく、サービスを活用いただけるクライアントの皆様や、売上を立ててくれる営業にとって、良いサービスは何か。それがどう社会に貢献できるのか。 そんな視点でものづくりが出来ることによって、開発へのモチーべションが向上したなと感じます。 最後に コロナの影響で、在宅勤務する方が増えたこの頃。私もそのひとりです。 ふと気づくと、今日誰とも話してない！？なんてことありませんか？ 以前に比べてさーっと時間が過ぎ、仕事への熱量が少し下がっているかも…というときは、コミュニケーションを見直してみると、何か良いことがあるかもしれません。   また、状況に合わせて柔軟に「飽きない」取り組みを続けていくことが重要だと思います。今後も、活性化を通じて仕事に対する目線が上がり相乗効果を生めるような取り組みをしていきたいと思います。