目次 自己紹介 内定者時代にやっておけばよかったこと アウトプット（プログラミングに触れる） 読書 旅 最後に 自己紹介 こんにちは！新卒エンジニアのけんてぃです。 私は、授業でしかプログラミングに触れたことがないプログミング初心者です。 内定者時代は、技術書ばかり読みインプットばかり行っていて、 入社した当時は「プログラミング初心者でもなんとかなるだろうか」「本当にできるだろうか」など不安が多くありました。 今回は、エンジニア研修を通して得られた経験を元に、内定者時代に「やっておけばよかったこと3選」についてお伝えできればと思います。 　エンジニア研修の内容についてはこちらに書かれています 　 https://engineers.weddingpark.co.jp/after_engineer_training/ アウトプット（プログラミングに触れる） 　　理由：技術書などを読むよりも、実際にコードを書きながら、触れることでコードの 　　　　　文 法や機能がわかり頭に入るスピードが早いと実感し、個人開発のアウトプッ 　　　　　トを 学生のころにやっておくべきだと感じたからです。 　　　　　また、 設計方針やコーディング方法など、 技術的な幅を広げるためにチーム開 　　　　　発も経験しておけばよかったと感じたのも理由の１つです。 　　　　　ここでは、個人開発とチーム開発でやっておけば良かったことをご紹介いたし 　　　　　ま す。 個人開発をやってみる Laravelを使用しサイトの開発 GitHubに触れてみる My SQLの練習問題 を解く 上記以外の他の言語にも触れてみる チーム開発に参加してみる ハッカソンやエンジニアインターン エンジニアアルバイト 読書 　　理由：社会人になってから や自分が働く業界についてなど、 知らないことが多かった 　　　　　ため本を読み情報収集すれば良かったと感じたからです。 　　　　　また、色々な人の考え方や生き方を学ぶことで、更に視野が広がり企画を立て 　　　　　る 際に役立ったからです。 　　　　　ここでは、内定者のうちに読んでおけばよかった！と思ったおすすめの本をご 　　　　　紹介いたします。 入社1年目の教科書 新社会人としての心構えや考え方の面で基礎となる部分がわかりやすく書かれている 知らなかった社会人マナーを知ることができ、仕事における優先順位についても学ぶことができる 伝え方が9割 伝え方の技術やルールを学ぶことができる 伝え方以外にもライティングスキルアップにつながる情報がある ウェディングプランナーになりたいきみへ２〜最高の結婚式を創るために〜 ウエディングプランナーの方を中心に、さまざまな職種の方がどのような心情で結婚式準備やカップル様と関わっているのか現場の目線で細かく書かれている ウエディング業界の現場について知ることができる 旅に出る 　　　理由： 行ったことのない場所に足を運ぶ ことで、日常では出会えない人や聞いたこ 　　　　　　と がない話に巡りあえて、とても視野が広がった経験があり、時間が多くあ 　　　　　　る学 生時代にもっと旅をしとけばと感じたからです。 　　　　　　ここでは、私が実践して良かった旅の仕方についてご紹介します 今いる環境と違う環境に足を踏み入れ、交流する 普段当たり前だと思っていたことが、当たり前ではないと気づき、視野や引き出しが増える そのエリアの人と話し、考え方を学ぶことで、違った視点もあるんだという気づきと知識が身につく 最後に 内定者時代に「やっておけばよかったこと3選」について紹介してきました。 私は入社した当時は「プログラミング初心者でもなんとかなるだろうか」「本当にできるだろうか」などネガティブに思っていました。しかし、今は先輩方や同期にわからないところは聞き、粘り強く食らいつきポジティブに取り組んでいます。社会人になる前には、不安な部分がとても多いと思いますが、この記事を読み学生生活の時間を有効活用し、不安な部分を減らせれば幸いです！

こんにちは！新卒1年目エンジニアsugoです！ 新卒研修として行ったチーム研修にて、リーダーを経験しました。 そこで、リーダー経験を通して学んだことについてまとめていきたいと思います。 これからリーダーに挑戦する方に、少しでも参考になれば幸いです！ 目次  リーダーになった経緯 リーダーとして意識したこと 議事録の作成 役割分担、進捗管理 全体を見る まとめ リーダーになった経緯 私の性格は、自らけん引するというより、人見知りで周りに引っ張ってもらうタイプです。 人事研修の中でチームで意見を出し合い考えるものもあったのですが、発言があまりできず周りに頼っている状態でした。 そんな状態のまま人事研修が終わり、チーム開発を行う研修が始まりました。リーダーを決めることになったのですが、“普段あまり話していないメンバーの挑戦機会をつくる”ということで、私がリーダーを務めることになりました…！ リーダーとして意識したこと 最初はリーダーとして何をすれば良いのか分からず、特にリーダーらしい動きができませんでした。そこで、どのようなリーダーになりたいのかを考え、「メンバーが安心して作業に取り掛かれるリーダー」になろうと決めました。 ここでは、リーダーとして意識したことをいくつかピックアップしたいと思います。 議事録の作成 ミーティングの中で議事録を取ることから始めました。理由は、チームがどのような状況にあるのかを把握するためでした。 議事録には、ミーティングの日付やアジェンダ、各話題の時間、メンバーの担当タスクと進捗などを記録しました。ミーティングが始まる前にアジェンダをまとめることで、みんなが話す内容を理解した上でミーティングを進められました。さらに、各話題に対して目安の時間を設定することで、だらだらと話すことを避け、メリハリのある話し合いができました。特にアイデア出しの際にミーティングが停滞してしまったため、決めきれない場合は、予め設定した時間になったら次の話題に移る方法を取りました。時間の制約下で進行し、成果を出す重要性を学びました。 議事録により、前回のミーティング内容の振り返りや行き詰った際に議題に立ち返ることができ、集中して効率的なミーティングを行うことができました。 円滑な意思決定とタスクの進行でチーム全体の生産性も向上し、議事録作成は、ミーティングに不可欠なものだと学びました。また、自身が議事録を作成することで整理ができ、チームの状況をより深く把握できるようになりました。 役割分担、進捗管理 役割分担：タスクを明確に分担することで、重複や責任の曖昧さを避けることができ、メンバーは責任感を持ちながら自身のタスクに取り組むことができました。 進捗管理：個人の作業が増え、ミーティングをしない日も出てきたタイミングで、毎日直接集まれる時間を10分間取り、進捗共有を行うことをチームで決めました。進捗はどうか、期限内にやりきれるのか、などを伝えることで責任感が生まれ、相談やサポートもお互いにできる場になったと思います。 役割分担、進捗管理、チームの取り組みが効率的になりました。またタスクの明確な管理、チームメンバーの役割と責任の明確化、進捗の管理はチームにおいて必要なものだと感じました。 全体を俯瞰して見る 全体を俯瞰して見る視野の重要性を学びました。ある仕様を決める際に、チーム内でさまざまなアイデアが出され、絞り込めない状況に直面しました。多くの時間を費やしても問題が解決せず、日数が経過していきました。 そこで、先輩に相談し、「目的に立ち返り、最も目的に近い解決策を考える」というアドバイスをいただきました。このアドバイスに従い、チームメンバーと自分たちが実現したいことや、活用する人にどう思ってもらいたいのか目的に立ち返り、どの案が最も目的に合致しているかを考えました。 この経験から、開発やミーティングの進行中に、議論の焦点やゴールを見失ってしまうことがあることを認識しました。リーダーとしては、広い視野を持ち、ゴールから逸脱しないようにチームを導くことが重要だと学びました。 まとめ リーダー経験を振り返ると、発言する機会が増えたことで、少しずつ自信がつき発言への恐怖心もなくなり、自分から発言できるようになりました。 また、リーダーとしてチーム研修を経験することで、効率的なミーティングの実施やチーム全体の進行管理、目的に基づく意思決定の重要性を学びました。リーダーとしての役割を果たすためには、メンバーのサポートや全体の調整に加え、常にチームのゴールを意識して行動することが不可欠だと学びました。 この経験から、まずは自身に適したリーダー像を考えることが重要だと感じます。 私の場合は、「チームを引っ張るリーダー」を考えていたのですが、無理にそれを目指すと空回ることが多いことから、「周りをサポートできるリーダー」になろうと決めることができました。 この記事が少しでも役に立てると幸いです！

初めまして！新卒1年目エンジニアのなりりんと申します。 5月中旬をもって約1ヶ月に渡るエンジニア研修が一区切りしたので、個人的な振り返りと学びについてまとめていきたいと思います。 特に、「 エンジニアって研修で何をやっているの？ 」と疑問に思っている方にぜひ読んでいただきたいです！ 目次 自己紹介 実践研修の概要 MySQL研修 Laravel研修 テストコード研修 Go研修 まとめ 自己紹介 新卒エンジニアとして4月に入社しました。 同期エンジニアが私含め4人いる中、唯一の文系出身・女子エンジニアです！学生時代は２年半ほど、IT企業でHP開発のアルバイトをしながらプログラミングを学んでいました。 自称・ おしゃべりエンジニア です！！！ 実践研修の概要 入社して２週間は人事研修があり、その後から職種別研修がスタートしました。 エンジニアはWeb概論・エンジニアの心得について・設計についてなど座学で学ぶ研修と、 ウエディングパークで使う言語やツールについて実践形式で学ぶ研修に取り組みました。 どの研修も学びが多く、とても重要なものばかりなのですが、 ここでは特に印象に残った 実践形式の研修 について、いくつかピックアップして振り返っていこうと思います！ ■MySQL研修 MySQL経験：一通りのクエリは困らずに書ける程度 まず最初に取り組んだハンズオン形式の研修が、MySQLの講座でした。 最初は合間合間に説明を挟みつつ問題を解いていく形式でしたが、みんなの進みが良かったため、問題をひたすら解いていき疑問があれば都度質問するスタイルに変更していただきました。 2日間に渡る研修だったのですが、1日目は脳が沸騰しそうなほど疲れました・・・ 同期の実力もまだまだ未知で、経験はあるものの理解が追いつくか不安もありました。 「 切磋琢磨していこう！ 」という雰囲気もあるため自然と速さを競うような形式になり、焦りつつも問題を解き進めていました。 2日目には実際にウエディングパークで使われているDBを用いて、より実用的な問題にチャレンジしました。使ったことがない構文を使用する問題もありましたが、持ち前の経験を活かして解き方を導き出せた問題もあり、自信がつきました 結果、2日目には トップで問題を解き終えることができました ！ ■Laravel研修 Laravel経験：簡単な成果物を作った程度（PHPは日常的に書いていましたが、別のフレームワークを使っていました。） この研修では、「 10日間で自己紹介ページを作って発表する 」というミッションが与えられ、 「 データの保存or削除or編集処理いずれかをマストで実装する 」というルールのもと開発を行いました。 まずは、研修の一環として好きなものを自由に作らせていただける、というところにとてもワクワクしました テーマはフリーだったので、私は自己紹介サイトとしてクイズゲームを作成しました！ こだわりポイントはいくつかありますが、特に見た目にこだわりました！ 今までフロントエンドの開発経験があまりなく、HTMLやCSSを使って１から自分で組んだことがなかったため、あえてBootstrapなどを使わずに全てコーディングをしました。 フロントエンドのコーディングは少し敬遠していた部分もあったのですが、実際に書いてみるととても楽しくて、やはり 新しいことに挑戦するのはワクワクする！ と実感しました。 そのほかにもこだわりや学びはたくさんあるので、こちらの研修については後日別の記事で紹介したいと思います。 ■テストコード研修 テストコード経験：読んだことも書いたこともほぼなし テストコードとは、作成したロジックの整合性を担保するためのコードのこと。 そういった概念の部分から、詳しい書き方や考え方について学びました！ 説明をしていただいたあと実際に演習も行ったので、学んだことがダイレクトに頭に入ってきました。 何をテストしたいのか？そのために何がどうなることを確認できれば良いのか？を考えながら書くのはとても難しかったです。ですが、演習問題をクリアした時の達成感はひとしおでした エンジニアの心理的安全性を守るためにテストコードはとても重要なので、今後機会があればどんどん書いて、身につけていきたいと思います！ ■Go言語研修 Go言語経験：なし。名前は知ってる程度 オンライン学習サービスで一通り講座を受けたあと、実際に書いて動かしてみるという形式でした。 初めて触れる言語でしたが、PHPを長らく触ってきた身からすると戸惑う部分がたくさんありました。いくつか挙げると、 Go言語はコンパイル言語、PHPなどはスクリプト言語であり、そもそも書き方も読み方も全然違う 型に厳格であること（PHPはその辺りがかなり曖昧なので、きちんと宣言する！という習慣があまりついていませんでした。） スライス、ポインタなど知らない概念がたくさんあってよくわからない などがあります。 理解に苦しむこともありましたが、最終的にはコードを読んで何をしているか大体わかる程度まで理解することができました。 そしてここでも、 新しいことへの挑戦にワクワク しました！ こちらの研修についても、学んだことをさらに詳しく別の記事に書きたいと考えています！ まとめ 1ヶ月に渡るエンジニア研修。ピックアップして紹介してきましたが、まとめると、 自分で考えながらとにかく手を動かす研修が多かった →実践をすることでスキルの向上はもちろん、エンジニアとしての考え方を自然と学ぶことができました。 同期で教えあったり、先輩に質問することでより理解を深めることができた →先輩の時間をたくさんいただけるのは今のうちなので、不明点を解消しておくのはとても大切だと思いました。同期の間でも「切磋琢磨していこう！」という雰囲気がありつつ、わからないときはお互い助け合って乗り越えていったことで、より絆が深まった気がします。 学んだ部分や成長できた部分はたくさんありましたが、同時に課題も見えました。 ある先輩に「 自走力が高い 」というお言葉をいただいたのですが、これは私の長所でもありつつ、まだまだ巻き込み力が足りないということでもあると考えています。 そういった反省点もありつつ、総じて ワクワク！ が詰まった研修でした 残りの研修期間、そして配属後もどんどん成長していけるよう、もっともっと周りを巻き込みながら目の前のことに全力で取り組んでいきます！ 最後までお読みいただきありがとうございました！

はじめに こんにちは！2023年1月に中途入社した Photorait エンジニアのnamiheiです。 前職とは真逆の環境に飛びこんでから早三か月が経とうとしています。 入社を考えている人や、似たような境遇の方の参考に少しでもなったら嬉しいです。 目次 自己紹介 ウエパ入社に至るまでの遍歴 入社を決めた理由(なぜウエパなのか) 実際に入社してみて 苦戦していること 変わったこと 今後やっていきたいこと 最後に ■自己紹介 # 前職エンジニア(5年目) #文系_経営学部出身 #元書道部 #元バドミントン部 #人見知り #人と話すのは好き #狭く深くタイプ #大人数より少人数が好き #マルチタスク苦手 #韓国ドラマ好き  #カラオケ好き #結構ミーハー #言語化苦手 #人を頼るの苦手  #緊張しい #負けず嫌い #細かい作業好き WP入社に至るまでの遍歴 2018年に4年制大学の経営学部を卒業し、技術派遣を主に行っているIT企業にSEとして新卒入社。 IT知識ほぼゼロの状態だったため、一から教えてもらったり勉強しながら必死に覚える。 　↓ 少しずつ理解できることが増えてきたのものの、伸び悩んでいたタイミングで大きめのプロジェクトを任される。 (2年目～3年目くらいの時) 　↓ 当時のスキルレベルはかなり低かったが、人手が足りず自分がやるしかない状況に追い込まれ、それを乗り越えたことでようやく成長を実感。 　↓ もっとできるようになりたいとモチベーションが上がったタイミングでプロジェクトが落ち着き、人も増えたことで仕事が急激に減ってしまった。 請負だったので何かを企画したり挑戦する機会もなく、数年間をだらだらと過ごしてしまった。 　↓ 気づけば成長するどころか何においても衰えを感じ、このまま20代を終えるのは嫌だなと思うようになる。 　↓ まずは職場の環境を変えたいと上に働きかけてみたりしたものの、あまり状況が変わらなかったため、コロナが少し落ち着いたタイミングで一念発起して転職活動を開始。 　↓ 何社か面接を受けて内定をいただいたものの、あまり現状と変わらない気がして全て お断りする。 　↓ エンジニアを続けるか否かでも悩みはじめてしまい、どうしたものかと思っていた時にウエディングパークに出会う。 　↓ 現在に至る。 入社を決めた理由(なぜウエパなのか) ・内定をいただけるまでに面談と面接が合わせて5回もあり、しっかり人を見ているということを感じた。 ・現状のスキルよりも成長意欲や挑戦する気持ちを大事にしてくれる会社であるということを知った。 ・面談や面接を通じて社長含め５名の方とお話させていただき、皆さんが口をそろえて「ウエパはとにかく人が良い…!」とおっしゃっていた。 （ 入社前は、そうは言っても一部の人のことを言っているのだろうなぁと思ってしまっていた部分が少なからずありましたが、、、「ウエパはとにかく人が良い…！」by namihei ) ・ここなら技術面だけでなく、人としても成長できそうだと感じた。 ・上流から下流まで経験できる自社サービスに魅力を感じた。 ・「結婚を、もっと幸せにしよう。」という理念に共感した。 ・もともとブライダル業界に興味があったので、ブライダルに携わりながらもエンジニアとして今までの経験も活かせるところにとても魅力を感じた。 この会社で働いてみたい！と心から思えた会社はウエディングパークが初めてでした。 ■実際に入社してみて とてもやりがいをもって楽しく働くことができている反面、 私にとっては苦手の連続でもあり、毎日が自分との闘いです。 苦戦していること ＜アウトプット＞ 私は自分の考えや想いを整理して発信していくことに対してかなりの苦手意識があるのですが、 ウエディングパークに入社してからはアウトプットの連続で、MTGなどでコメントを求められた時も言いたいことがまとまらずグダグダになってしまい毎回落ち込んでいます。 ですが、できないなりにもアウトプットしていく中で考えが整理されることがあったり、理解できていないことに気づけたり、良いことしかないなーと感じる日々でもあります。 ＜挑戦＞ ウエディングパークは失敗を恐れず挑戦する気持ちをとても大事にしているので、私も入社したからには色々と挑戦、経験していこう！と思いつつ、挑戦するにも何を、、？どうすれば、、？と早々悩んでしまいました。 ですが、入社して間もないタイミングで、各部署ごとに立候補or推薦で選ばれたメンバーが全社の前で今挑戦していることや挑戦してきたことについて発表する「挑戦発表会」というものがあり、 これは挑戦する良いチャンスだと思い勇気を出して登壇を立候補し、ありがたいことに登壇メンバーにも選んでいただくことができました。 当日はとても緊張し、手を挙げたことを後悔しそうになりましたが、挑戦しようとする気持ちが大事で、失敗しても、上手に話せなくても良いと言って背中を押し、応援してくれた方々がいてくれたおかげでなんとか乗り越えることができました。 つたない私の発表でも、とても良かった、勇気をもらったと沢山の方が声をかけてくれて、一歩踏み出して良かったなと心から思うことができました。 また、挑戦の大小に関わらず、自分にとっての挑戦を日々積み重ねていくことが大事だということにも気づくことができました。 ＜タスク管理＞ エンジニア業務以外にもやること、やりたいことが沢山あって、時間が足りない！と思うことが増えました。 最初のうちは特に、自分がそのタスクをこなすのにどれだけ工数がかかるのかが見えないので、スケジュールを立てても思い通りに進まないことも多かったり、優先順位が付けられずとても苦戦しました。（今もまだ苦戦中です） ですが、ウエディングパークにはそのマルチタスクをこなしてきている先輩が沢山いるので、お話を聞いて色々と参考にさせていただきながら、改善に向けて自分に合った方法を模索しているところです。 ＜技術面＞ 前職ではコードレビューがほとんどなく何となくでソースコードを書いてしまっていたところがあったので、 初めてコードレビューを出した際は沢山のご指摘をいただきました…。 命名規則や、マジックナンバーになっていないかなど、基本的な部分も意識せずにここまで来てしまったので、案件のたびに沢山の学びがあります。 指摘してもらえることのありがたみをとても感じると同時に、基本的なところから学びなおさないとだなぁと反省しました。 周りには質問すると嫌な顔せずとても丁寧に教えてくれる方しかいないので、安心して聞けるのも本当にありがたいです。 変わったこと 一番は、気持ちの変化だと思います。 入社前は仕事に対するモチベーションが全く上がらず、余裕があるうちに勉強しようと思いつつも続いて３日、そんな自分に嫌気がさす、という負のループに陥ることがしばしばありました。 ですがウエディングパークに入社してからは、 目標に向かって頑張っている方、他部署の応援サイトを善意でサクッと作ってしまう方、何かを指摘する時に「でもここは良かったよ！」という言い方が自然とできる方、何事もポジティブに捉えてくれる方など、素敵な方が沢山いて、私も頑張りたい！こういう大人になりたい！と感じる機会が沢山あり、３か月を振り返ってみても、モチベーションが上がることはあっても下がることはなかったなと感じています。 また、なによりもそんな素敵な方々と働けることを誇りに、とても幸せに感じています。 今後やっていきたいこと ・まとめサイト的なものを作る（技術面に限らず、知らない用語が会議で出てくると話についていけず、後から調べたり聞いたりしてようやく理解するということが多かったので、後から入社してきた方が少しでも楽になるよう、ここを見ておけばある程度ついていける！という情報をまとめたい） ・基本を学びなおして、土台を固める。 ・会社やチームに貢献するためにも、まずは自分の強みや弱みを理解し、足りないところを補えるような存在を目指す 最後に どこに自分の身を置くかで人生が変わるということをよく耳にしますが、本当にその通りだなと日々実感しており、環境を変えることは勇気のいることでしたが一歩踏み出して本当に良かったと心から思っています。 苦手と向き合うのは正直大変ですが、３か月後、半年後の自分が今より成長しているように、経験や失敗から得た学びを活かしながら少しずつでも乗り越えていきたいなと思っています。 最後までお読みいただきありがとうございました！

はじめに こんにちは!新卒1年目エンジニアのtakadaです！ もうすぐでエンジニアとして1年が経つので、僕が1年間通してやって良かった事を振り返りたいと思います！振り返ってみるとやって良かったと思う事がたくさんありましたので、その中でも「これは重要だったな！」と思う事を9個上げてみたいと思います。そしてこれから働く新卒エンジニアの方々に1つでも参考になれば幸いです。 普段の業務編 まず、普段の業務でやって良かった事を挙げていきたいと思います！ ① タスク管理の徹底をしたこと 1つ目は、 「タスク管理の徹底をした事」 です！ 僕は、普段仕事をする上で毎朝上記のようなシートに以下の順番でタスクを洗い出しています。 ① 今日MUSTでやる1日の目標を洗い出す ② オレンジ色の箇所に午前と午後のミーティングの時間を書き出す ③ 午前と午後の作業時間を把握した上で、午前にやるべき事・午後にやるべき事を書く ※ これにプラスして、 数分でできるタスクはすぐにやること・出現したタスクはすぐに書くこと を意識するようにしております。 この方法でタスク管理をすることで、「タスクが増えてもあまり混乱せず業務に取り組めてるな！」と思いますし、「今日どれくらい作業時間取れそう？」と聞かれたとしても自分の状況を明確に伝えられてチームの人とも連携が取れやすかったなと感じています。 また、午前と午後の作業時間でどれぐらいのタスクをこなせたのかや作業時間に対して「午前中はバッファを入れてこれぐらいできるだろう」などと考えることで工数見積もりのトレーニングをする気持ちで取り組んでいます。 入社当時は先輩方にお聞きして自分なりに試行錯誤した結果、今のタスク管理があるイメージなので、色々な人にお聞きして自分に合ったタスク管理方法を見つけるのも良いのかなと思います！ ②自分を知ろうとしたこと 2つ目は「 自分を知ろうとしたこと」 です。 「自分がどういう性格で何が得意・不得意で何が好き・嫌いなのか？」などを知ることで、「それを活かすためには何を学んだ方が良いのかやどんな仕事が向いていそうなのか？」など、エンジニアとしての方向性を知ることができ、右往左往して迷ってる自分にとってすごくよかったと思います！ その自分を知ろうと思ってしていた事は下記2つです ・ エニアグラム (ウエディングパークに入社して取り組んでいたもの) ・ ストレングスファインダー  (有料だけどすごくおすすめなもの) ※ 僕のストレングスファインダー エニアグラムも良いですが、ストレングスファインダーは特に良かったです！自分がどういう資質があり、それを伸ばすにはどのようなことをしたら良いか書いてあるため、他の人にない強みを知れた気がします。 また、先輩や同期などとのコミュニケーションがきっかけで知ることも多かったです。 例えば、「理解しきろうとする姿勢があるよね」や「探究心あるね」と言われることが多くて「人より探究心が強いのかな？」と思ったり、「結構先のことまで考えてるよね」や「視野広いのかもね」と言われてストレングスファインダーを見ると「未来志向」が強いことを知れたりなど。業務の中で、他の人から言われる言葉は、今考えるとすごく大切な意見だったなと感じています。そのような意見には耳を傾けて聞いてみるとすごく良いのかなと思います！ ③ 振り返りをすること 3つ目は、 「振り返りをすること」 です。 新卒研修時からチーム配属後の現在まで、先輩エンジニアやマネージャーとの1on1が週に一度入っていました。ここで現時点で悩んでいることや不安を解消してました。無いと困るぐらい本当に有り難い時間となっています 個人的には、現在悩んでいること・不安なことだけでなくて 不安になりそうなこと・今後悩みになるかもしれない早いタイミングで相談する事も大事だなと思います。 「来週からこのタスクが入ってくるかも、ちょっとMTG多いかも。」など。 僕はこれが10月ぐらいの段階でできておらず、タスクが溢れる一歩手前の遅いタイミングで相談する形になり、対応が遅れてしまっていました….。また、チームでの会話が増えると連携がしやすくなると感じていますので、 1on1 がない方は提案してみるのも良いかもしれません！ また個人的にも1週間の振り返りをするようにしております。 方法は こちら の記事を参考にしています。 本当は、1日毎に振り返るのが1番良いのですが時間がなく、僕はできなかったので週毎にやるようにしています！記事にもありますが、大きく分けて下記の4つを書いています。 ・ ポジティブな内容3つ ・ 1週間後に達成できていたいこと ・ ネガティブな内容3つ ・ 特に解決したいと感じる課題への対処法 個人的な振り返りもしないと、同じ失敗を繰り返してしまうことがありましたのでこちらも結構やって良かったと感じています。 技術寄りのやって良かったこと編 ④ 学ぼうとする姿勢を常に持ったこと 4つ目は、 「学ぼうとする姿勢を常に持ったこと」 です！ 常に学ぼうという姿勢を持つように意識する中でも、「興味がある所から拾っていく」のがすごく大事だなと思います！業務をしてる中でも分からない言葉や仕組み、処理が溢れるようにあって、全部に手をつけようとしたら多分混乱しますし、実際僕はたまに混乱します。それでも、興味がある事から拾って理解していくことで、あるタイミングで点と点が繋がって理解が深まるんだとわかりました。 あとは、技術書を読んだのも良かったです！ 本を読む習慣がなかったので、活字はすごい苦手ですが読むようにしています。技術書から学べることはすごく多いので、これからもちょっとずつ興味がある分野を読み進めていきたいと思います。 下記の2冊は1年目で本当に読んで良かったと思います。 ① この1冊で全部わかる web技術の基本 ②  リーダブルコード ①は図がすごく丁寧で右に説明文、左に図という構成なので分かりやすくwebの基本を体系的に学べるのがすごく良かったです。読書が苦手でwebの基本すら無いに等しかった僕でもスラスラ読めました！今でも、開発をしていく上で土台になっているなと感じています。 ②はとても有名な本ですが、有名なだけあってやっぱり読んで良かったです。学生の時に買って満足してた本だったのですが、試しに読んでみるとすごく面白かったです。読みやすいコードをすごく実践的に教えてくれるので、案件中に本を参考にリファクタリングを実践していました。 ⑤ 毎日15分の情報キャッチアップ 5つ目は、 「毎日15分の情報キャッチアップ」 です。 これは10月ぐらいから続けてるのですが、すごくやって良かったと思えています！ 僕は、情報のキャッチアップするツールとして Zenn とか Qiita を使っています。 業務前・業務の合間に見ているのですが、僕は分からないことを調べたりしているといつの間にか違う記事を見ていることがあるので、必ず15分と時間の制限をかけて読むようにしています。 これをやるようにしてから、技術・知識の幅が広がってエンジニア定例や案件の中で「ここの単語・記述、記事で見たな、聞いたな。」となり、「もっと調べてみよう！」と思えて調査して理解が深まっていくなどのケースが結構ありました。全く知らない言葉よりも、ちょっと馴染みある言葉の方が調査しやすかったりするのかなと思います。単純に「知ってる」の幅が広がるだけでもやって損はなかったのかなと思います！ ⑥ 学ぶ際にプロセスも意識したこと 6つ目は 「学ぶ際にプロセスも意識したこと」 です！ 新卒研修のチーム開発が始まったぐらいから上記の画像の項目をもとに書いてました！ 各項目の意図は下記みたいな感じです。 [各項目の意図] 質問内容と解決方法：質問したことに対しての解決方法を適切なタイミングで振り返れる。忘れるのが減少しました。 学び：学んだことを言語化することで理解が定着しました。 エラー・分からない原因：原因を言語化して後に勉強するようにしていました。同じような質問をせずに済んだ気がします。 解決までのプロセス ：エラーを解決する力をつけるためです。エラーが起きた時に「とりあえず先輩がしていた方法をやろう」となりましたし、実際に解決できるエラーも増えたと思います。 特にこの「解決までのプロセス」はやって良かったなと思っています。「ここでdd()使うんだ！」「こういう時、開発ツールのネットワーク見るんだ！」や「調査するときこの記事見てるんだ！」など、意識するだけで学べることが多かったです！プロセスの項目を増やした後は、プロセスまで意識して見れるようになりましたし、エラーは開発してればいくらでも発生するのでそのエラーを解決するプロセスを学べたのはすごく今も活かされてると感じます。 今は、上記画像の新卒研修時みたいに細かくとってはいないのですが「分からないけど今聞く内容じゃないし、ちょっと聞く時間ないな。」というものを忘れないようにメモをしておいて、後ほど調査したり先輩に聞いたりするように使っています！僕は金曜日の業務前の時間をその疑問解消をするための時間に使うようにしています！けど分からない内容によっては早く聞いたほうが良いので、そこの判別は気をつけた方が良いなと感じています。あと、シートに書くことで満足してしまうので一定の時間を押さえて調べたりするのに使い、時間があればすぐに聞いちゃう方が良いのかなとも感じています。 僕は結構マメかもしれないですがシートに書かずとも結論、エラーを解決するプロセスまで意識して見ることができればそれでも全然よいと思います。 ⑦ 15分調査して分からなかったらすぐ聞くこと 7つ目は 「 15分調査して分からなかったらすぐ聞くこと」 です！ 正直まだ遅くなっちゃったりしてできない時があるのですが、今でも意識して業務に取り組むようにしています。 チーム開発研修でエラーとか仕様が分からなくなってしまった時に、沢山調査して3時間経ち、けど先輩にご相談したら10分足らずで解決しましたという事が結構ありました….! 先輩に聞くのは時間を取ってしまい申し訳ないなと思うことが多かったのですが、それよりも全体の進捗が遅れる方が周りにすごく悪い影響になってしまったりするので、すぐに聞くことが大事だなと新卒研修を通して思いました！しかし、すぐに聞きすぎるのも調査する力がつかなくなってしまうので、「時間を決めて調査してみる！15分経ってみて分からなかったらすぐに聞く！」みたいなモチベーションがすごく大事だなと感じました。 ⑧ 仕様オリエンは判定者みたいな気持ちで！ 8つ目は、 「仕様オリエンは判定者みたいな気持ちで！」 です！ ウエディングパークですと下記のリリースフローになっており、案件の最初に仕様のオリエンがあります。 仕様のオリエンでは、テスト観点を洗い出したり、エンジニアの視点から仕様に対してご質問したりするなど仕様に対してディレクターさんと認識の擦り合わせをします！ディレクターさんに「こんな感じの作ってください！」と言われ「はい！わかりました！」と言われた通りに作るようにしておりました。けど、「なぜこんな仕様なんだろう？」や「これだと少し実装が複雑になるかも….。」と思い、後に聞いてみて仕様変更があり、設計からやり直しみたいなケースもありました！ そのため、オリエン前に予め資料を確認して疑問点を洗い出しておくこと、仕様に対しても実装が複雑になりそうだったら提案してみるのもすごく良いと思います。けど仕様オリエンだけで全部疑問点が解決しました！ということは無いと思うので、適宜疑問に思ったことは聞いてみて、認識すり合わせた状態で実装に移る事がすごく理想だと感じています！ ⑨実装の認識のすり合わせを徹底すること 9つ目は、 「実装の認識の擦り合わせを徹底すること」 です。 こう思いましたのは、実装してコードレビューをして頂く段階で失敗したことが関わっています！ (1回目のコードレビュー) 「ここの実装こうした方が良いかもね！」 ↓ 「承知しました！このロジックならいけそうかも….！この実装方針で実装してみよう！」 (2回目のコードレビューにて、、) 「それだと〇〇になっちゃうからこういう実装の方が良いかも！」 ↓ 「1回目のレビューからの修正箇所が多く、実装し直しに時間がかかってしまう…。」 こんな感じで、レビューの出戻りで無駄になってしまう時間が発生してしまい、 それによって見積もったレビュー修正の工数から大きくずれてしまってスケジュール変更をする必要が出てくるなどが生じてしまいました。 改めて、実装に時間がかかりそう、もしくは時間がかかってきたら実装する前や途中に実装方針を相談する！認識を揃える！ そうすることで、実装の出戻りは少なくなり無駄な時間を無くす事ができると思います！ 僕も今後意識して、開発だけでなく色々なところで認識をすり合わせることを意識していきたいと思います！ 1年を終えて〜 1年で、新卒研修での初チーム開発でプロフっちょ開発！Wedding Parkサイトで初案件リリース、Wedding Parkやサイト内新コンテンツ「ムビレポ」の管理画面開発など、いくつかのチームで様々な開発を担当しました。色々と経験させて頂きすごく学びになりましたし、沢山のご質問を丁寧に成長できるように回答してくださった先輩方には感謝しかありません！悔いなく締めくくって2年目もエンジニアとして頑張ります！ ※ 僕は結構マメに取り組むタイプですので、もしかしたらこの方法は合わない！こっちの方が良い！という事があるかもしれませんが、この記事を読んで少しでも業務に取り組む上で参考になれば嬉しいです！

こんにちは、技術広報の鈴木（ @akk_szz ）です。 ウエディングパークは、2023年3月23日（木）〜 3月25日（土）に開催される PHPerKaigi 2023 にシルバースポンサーとして協賛しています。 また、3月23日に開催される前夜祭セッションでは「技術負債とプロジェクトと私たち」というトークテーマで3名のエンジニアが登壇します。 PHPerKaigiとは PHPerKaigi（ペチパーカイギ）は、PHPer、つまり、現在PHPを使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。 出典： PHPerKaigi 2023 協賛背景 当社は、経営理念に「結婚を、もっと幸せにしよう。」、ビジョンに「21世紀を代表するブライダル会社を創る」を掲げ、1999年の創業以来、ウエディング×デジタル技術活用の領域で様々な事業を展開してきました。 ウエディングパークでは、その長い歴史の中でPHPを活用してきており、現在提供しているサービスのほとんどでPHPを活用しています。 つまり、私たちウエディングパークにはPHPが不可欠で、エンジニアの多くがPHPerです。 また、ウエディングパークのクリエイターは「技術とデザインのウエディングパークを創る」というスローガンを掲げています。 「多様化」が顕在化している今、一人ひとりの幸せの価値観を尊重し、その価値観に寄り添ったサービス、求められるサービスをつくり、事業を展開できる会社になっていく… その実現のためには、“もっと”テクノロジーの力が必要なのです。 PHPerKaigiの協賛を通じて、エンジニアとして活躍し続けたい方を応援し、PHPコミュニティへの貢献、「ウエディング業界×テクノロジー」の発展にも貢献していきたいと考え、協賛することを決めました。 登壇概要 テーマ ： 技術負債とプロジェクトと私たち 日時 ：2023年3月23日（木）18:15〜（20分） 概要説明 サービス運用者の皆さん、技術負債解消に向き合えていますか？ 機能拡張に対して技術負債がネックになり開発効率が落ちることに、何度も頭を悩ませた事があるのではないでしょうか。 ローンチして8年のフォトウエディング・前撮りの日本最大級のクチコミサイト「Photorait」では、サービスを更に拡大するべく新機能の開発を行いながら、長い年月の中で生まれたレガシーなシステムや非効率な運用フローなど、技術負債への課題解消も並行して行っています。 本セッションでは、新たな機能開発を止めずに並行して行っている負債解消への取り組みと、事業メンバーへの理解促進、そして今後の開発サイクル加速のために実施していることを発表します。 ＜登壇者プロフィール＞ Photorait本部 エンジニアリングマネージャー／ 武田 翔平（takedajs） 2014年、ウエディングパークに新卒入社。「Photorait」の立ち上げ時から参加し開発全般を担当。「Wedding Park」ではSEO開発、パフォーマンス・チューニング、Golang検証導入を担当。2018年からはPhotoraitのエンジニアリングマネージャーとして組織作りにも取り組んでいる。2021年10月から半年の育休を取得し、現在は仕事と育児の両立に絶賛奮闘中。 Photorait本部 チーフエンジニア／ 日江井 風人（ヒエイ） ソーシャルゲーム、ニュースメディアの開発運用を経て2019年ウエディングパーク中途入社。サーバーサイドエンジニアとしてPhotorait全般の開発を担当。過去にはPHPerKaigi、PHP Conferenceにて監視体制やPHPバージョンアップについて登壇を行う。趣味は野球観戦。二児の父。 Photorait本部 エンジニア／ 小野澤 清人（おのぽん） 大規模ソーシャルゲームのサーバエンジニア、人工知能のコミュニケーションロボットのサーバ全般・Androidアプリ開発を経て2022年にウエディングパークに中途入社。サーバーサイドエンジニアとしてPhotorait全般の開発を担当。他部署のエンジニアともペアプロや講義を開くなど、全社のエンジニアのスキルアップを図っている。趣味は卓球。パラ選手のコーチとしても海外へ旅立つ機会が多い。 前夜祭セッション裏話 前夜祭セッションについて、実は、それぞれがPHPerKaigiのプロポーザルにチャレンジし、落選したメンバーです…！ ウエディングパークには「挑戦」や「挑戦を応援する」という文化があり、チャレンジしたメンバーに登壇機会をつくりたい！と、スポンサーセッションを設けることになりました。 改めて「チーム」での登壇として進化させ、今回の前夜祭セッションに登壇予定です！ （ちなみにセッションテーマのタイトルは、ブレストの際に、伝えたいことは「サービス拡充と技術負債解消の両立」と「チーム」。「PHPの歴史は1994年スタート。同じ頃にヒットしていた『部屋とYシャツと私』という曲からもじる？」という“おのぽん”のアイデアで決まりました。） セッションをお聞きいただけたら幸いです。 WPHPerKaigiを開催します！ 勝手にスピンオフ企画！ウエディングパークPHPerによる「WPHPerKaigi（ウェチパーカイギ）」を4月18日に開催します。 こちらへのご参加もお待ちしております！ WPHPerKaigi詳細・申し込み

こんにちは、おのぽんです。 Tweets by onopon_engineer   徐々に桜も咲き始め、春を感じ始めましたね。 僕もだんだん薄着になっていったりと、服装にも変化が出始めました。   さて、この度弊社のエンジニア向けに実践的な内容のテストコード研修を行うこととなりました。 そして、その テストコード研修の練習用リポジトリ「tc_practice」をオープンソースとして公開 することとなりました！ https://github.com/onopon/tc_practice   本リポジトリは「テストコードはなんとなく知っているけど、どのように書いていけばいいかがわからない」という方向けの内容となっています。   また、リポジトリ内でdockerを利用しますが、dockerの知識がなくても、テストコードの練習を始めることのできるスクリプトを用意してあります。     実装ページは、ページにアクセスすると下記のログイン画面が出てきて、ログインするとマイページが表示されるという非常にシンプルなものとなっております。     しかし、この実装にはロジックやテストコードが至らない点がいくつかあります。 それらを問題集として ANSWERME.md にまとめました。   問題は全部で10問あり、問題を進めるにつれ、難易度が少しずつ上がっていきます。 本問題を全てこなせると、下記の理解が深まります。 テストケースの考え方、テストコードを書く上でのポイント 与えられたロジックからテストケースを書く方法 与えられたテストケースからロジックを書く方法 仕様書からロジック・テストケースを書く方法 また問題を解き進める際、ロジックとテストを交互に眺めて実装していくこととなるので、実際のプロジェクトでの開発の仕方と似た動きが自然と身につくかと思います。 回答例は answerブランチ  に用意していますので、ぜひご自身の勉強や講習会の題材としてお役立てください！   開発背景 テストコードに触れたことのない新入社員が僕と同じPhotorait本部に配属されました。 Photorait本部では、開発時のテストコードの追加に力を入れている真っ只中です。 そのため、その社員の方にも書いてもらうべく、テストコードの研修を行うことを決めました。   すると、その研修実施を聞きつけた他部署のエンジニア数名より「私もその研修に参加したいです」という嬉しいお声をいただきました。 もともと弊プロジェクトの新入社員向けに資料など準備していましたが、説明内容はテストコードの概要がメインとなっていたため、「需要があるのであればみんなにも参加してもらおう」と考え、その研修をオープン会議にしました。   そして、実に10名以上のエンジニアより参加したいとの声があがり、研修中も質問が飛び交いながらとても楽しく開催することができました。   テストコードの研修でいただいた反響や、これをきっかけに作成したアンケートの集計結果を元に、もっと実践的な内容でテストコードの研修を行うことを決めました。   この研修で活用しようと思い開発したリポジトリが、 tc_practice です。       もうすぐ新年度が始まり、新卒や新入社員がたくさん会社に入社することと思います。 そんな中、僕は新卒研修としてテストコードの研修を担当することとなりました。 ちょうどtc_practiceを開発したので、早速こちらを利用しながら研修を進めていく予定です^^     —     今回は、テストコード研修のためのリポジトリをオープンソースとして公開させていただいたお話と背景をまとめてみました。   弊社では、引き続き一緒に働いていただけるエンジニアを募集しております！ tc_practiceのお話はもちろん、 目標達成や事業の成長を一緒に感じたい チーム貢献 に尽力できて、またその成果も評価してほしい 自由に企画・提案 しながら社内にアクションを起こしたい という方がいらっしゃいましたら、是非一度弊社社員とお話させてください！ 最後までお読みいただきありがとうございました！！

こんにちは、おのぽんです。 Tweets by onopon_engineer 最近Twitterを始めました。 ちょっとずつエンジニアリング的なことも呟いていこうと思います。   さて、弊社には、勤続年数や結婚記念日を祝うなどと言った 独自の福利厚生 が数多く存在しております。 そして、それらは対象となる月のnヶ月前や当月に通知され、労務の方々が期日になったらご入金していただけるという流れになっています。 そんな素晴らしい取り組みですが、課題を感じる部分も多々ありました。 例えば、特殊な入金の発生する福利厚生の場合、 社員が入社したら、SmartHRの社員情報を更新 独特な福利厚生の管理のために、SmartHRとは別にスプレッドシートを用意 スプレッドシートの値を見て、nヶ月前か当月に通知する社員を洗い出す 該当者に対し、通知を行う 期日になったらご入金 というフローで該当者へ通知・ご入金を行います。 そして、このフローを担当する方を見てみると、 担当社員による手入力 担当社員による手入力 担当社員による目視 担当社員によるホスピタリティ 担当社員による作業 と、労務の方のマンパワーにより成り立っていることがわかりました。いつもありがとうございます・・・！   弊社の労務の方は、何かと人力で頑張ってくださっていることが多く、少しでも軽減できたらいいなぁという思いが高まり、弊社の WP HACK DAY という1日で行うハッカソンにて同じチームの方と、福利厚生通知システムを開発しました。 1日でプロトタイプを実装する その後できるだけ簡単な形で運用に乗せたい という状況だったので、GoogleAppScript(以下GAS）やSlackAPIを活用して比較的ライトになるよう心がけました。 実際の成果物 準備 社員データ 弊社ではSmartHRを利用して社員データを管理しているため、それらをcsvでダウンロードし、スプレッドシートにimportしておきます。 福利厚生データ 弊社は福利厚生が増えやすいので、福利厚生のデータをスプレッドシートで管理しておき、福利厚生が増えたら記載していける状況としました！ ※ 画像はダミーデータです。   条件には、入籍日といったSmartHRから取得できるものはそのまま書き、勤続日数など細かな計算が必要なものは別シートで書いて利用できる状況としております。   チェックが実行されると 上記の福利厚生一覧のデータを元に、 A-C列：社員名や社員番号 D列：通知対象かどうか E列：通知したかどうか F列：入金したかどうか G列：福利厚生の開始年月 が記載されたシートが自動生成され、該当者には◯がつけられます。     上記の◯がついていて、かつ「通知したかどうか」「入金したかどうか」のいずれかにチェックのついていない方が「通知しないといけない方」として、Slackにリマインドされます。   全ての福利厚生を1枚のシートで管理することも考えましたが、 管理者の方もこのシートを見て確認したい GASを組む際にそっちの方が実装が早くできそう と判断し、福利厚生ごとにシートが自動生成される方針としました。   実際の通知の様子 このような投稿がGASによる定期実行で投稿されます^^   ペアプロにて活躍した若手エンジニアはこの方！ 今回は、 ウーマンデブサミ でもファシリテーターを行っていた新卒1年目の野村さんです！ ペアプロは初めてとのことでしたが、HACK DAY当日から実際にシステムの運用に乗せるまでの間、とても頑張って実装してくれました！ ありがとう！！   実際に運用を頑張ってくださっていた労務の方の声 下記のメッセージをいただきました！ 実際に喜んでくださる姿を見ると、とても嬉しいですね！ 管理やアラートが多い上に、手作業（人力）で管理している部分が多かった総務労務に救いの手を差し伸べていただきありがとうございました；；♡ たくさんヒアリングしていただき、今後のことまで考えたシステムをご作成いただき、大感謝です。 完成版をご共有いただいた時は、ふたりの技術の力と心配りに終始感動でした。 今回は労務の方のお仕事を少し減らすことに成功しました。   Before After 社員が入社したら、SmartHRの社員情報を更新 担当社員の方による手入力 担当社員の方による手入力 独特な福利厚生の管理のために、SmartHRとは別にスプレッドシートを用意 担当社員の方による手入力 担当社員の方により SmartHRのデータをimport/exportしていただくようになったので、手間が省けるように スプレッドシートの値を見て、nヶ月前か当月に通知する社員を洗い出す 担当社員による目視 システム化 該当者に対し、通知を行う 担当社員によるホスピタリティ 担当社員によるホスピタリティ 期日になったらご入金 担当社員による作業 担当社員による作業 Before/Afterを並べてみるとほんのわずかなところではありますが、実務に携わっていた方のお気持ちをお伺いすると、わずかな日数の取り組みでも力になることができたのではないかと思います！ 引き続き部署内外関係なくさまざまな取り組みをしていこうと思います。 最後までお読みいただきありがとうございました！

この記事は Engineering Manager Advent Calendar 2022 の23日目の記事です。 こんにちは。フォトウエディング・前撮りのクチコミ情報サイト「Photorait (フォトレイト)」のエンジニアリングマネージャーをしている武田( @takedajs )です。 新たに加わってくれたメンバーのパフォーマンスを最大化させるために、Photoraitのオンボーディングでは 「自走して開発できるための知識共有」「組織カルチャーの理解」「社内での人間関係構築」 に関する取り組みを行っています。 出社とリモートのハイブリッドな働き方をしているため、新しく入るメンバーは特にコミュニケーションを課題に感じやすいこともあり、オンボーディングでは「組織カルチャーの理解」と「社内での人間関係構築」に関する取り組みがより重要になっています。 弊社では組織カルチャーを推進するための社内交流を推奨していて、社内交流を促進する制度が多くあります。 制度は覚えやすく社内で共通言語として語られるように特徴的なネーミングになっていたり、専用のロゴを作成しているものもあります。 今回は「組織カルチャーの理解」と「社内での人間関係構築」に関する取り組みとして、私のチームでエンジニアのオンボーディング時にフル活用してる社内交流制度 「カフェテリア」「けっせつ10」「コーシー」 についてご紹介します。 制度その①：カフェテリア 直属の上司以外の様々なマネージャーと1on1ができる制度 ・相談者側は他部門マネージャーの話を聞いてみたい！と思っても、時間を抑えてまで…？とためらってしまう ・マネージャー側は悩むメンバーがいるならサポートしたいと思っている 仕事の進め方やキャリアなどの悩みを自部署以外のマネージャーにも相談できる場所をつくり、メンバーがアドバイスをもらいながら心身共にまっすぐに仕事に取り組める環境をつくる ①各マネージャーが書いたカフェテリア実施一覧シートから話を聞きに行きたいマネージャーを選ぶ(こんな感じでみなさん自由に書いてます〜！) ②マネージャーが設定してるスケジュールに参加 制度その②：コーシー カフェでのコーヒーブレイク代を支給する制度 ・1グループ2〜4人 ・1回30分 ・1回につき1人500円支給(月2回まで利用可能) 制度名は「コーヒー」と開催推奨人数の「4」をかけており、ロゴは、コースターをモチーフに、カフェで一緒に過ごす温かい時間を表現 リモートワークになり社内コミュニケーションが減少 リアルな場での社内コミュニケーションを気軽に取るきっかけとして利用し、組織カルチャーに触れる機会を増やしてタテ・ヨコ・ナナメの関係性を深める オフィスやSlackでメンバーを募り、コーシー実施の様子を専用Slackチャンネルで実施報告 制度その③：けっせつ10 入社3年以内の社員が企画者（結節点）となり、交流会(会食)を開催する制度 ・入社年次(◯年目)を足して10になる２~４人のメンバーで構成 　(入社６年目以上はワイルドカード扱い) ・必ず２部署以上で組み合わせる ・3ヶ月に1度利用でき、会社から会食費用が出る ・リアルもしくはオンラインで実施(2022年12月現在) ロゴは、エネルギーと推進力を連想させる「風車」をモチーフにしたデザイン。4色の羽（参加最大人数）で構成し、チーム感を感じるロゴに仕上げた。また、全体のフォルムは本制度のポイントである漢字の「十」、そして「プラスマーク」にもなっている 他部署の人を誘うきっかけがほしい 入社間もない社員を中心に部署の垣根を超えた自発的な交流を促し、スムーズな業務進行や社員の相互理解、社風理解をサポート 入社年次を足して10になる人を探して会食実施後、Workplaceに開催を報告 私(EM)の関わり方 新しく入社された方に「社内交流制度があるので利用してください〜」と伝えて終わりではなく、制度の利用促進と利用効果の最大化のために以下のようなことを実施しています。 ①目標として設定 3ヶ月ごとに定量定性目標を設定していますが、入社してすぐの目標設定では社内交流制度の活用についての目標を設定してもらってます。「組織カルチャーの理解」と「社内での人間関係構築」が大切であるという考えをすり合わせ、制度の利用や利用を通しての学びをしっかり評価します。 ②結節点として人をつなげる 社内交流制度が多くあるといっても入社したばかりの会社で話したことない人に声をかけるハードルは高いと思うので、私が結節点となって色んな方とつなげていきます。 ただ、社内交流を積極的にする組織カルチャーなので、最初の数人をつなげば、つないだ方が別の誰かをつないでくれたりします。(これは本当にありがてえ〜！) ③1on1での会話 社内交流制度を利用して会話した内容で学びがあったこと、気付き、疑問に思ったことなどを1on1で教えてもらいます。教えてもらったことに関して深ぼって会話をすることで、組織カルチャーの理解度向上につなげています。 最後に 私のチームでエンジニアのオンボーディングでフル活用している社内交流制度についてご紹介しました。 こういった制度がなくても社内交流をすることができる環境ではありますが、制度があることで社内の共通言語となり声をかけるハードルがぐっと下がります。 また、覚えやすいネーミングや利用のしやすさから、毎日のようにどこかしらから「コーシー利用しました〜！」や「けっせつ10行ってきました〜！」などの声が聞こえ、みんな制度を積極的に活用しています。 エンジニアのオンボーディングについてはまだまだ改善の余地があるので、今後も試行錯誤しながら改善していきたいと思います。

こんにちは。新卒４年目エンジニアのソガヤです。 エンジニア組織活性化の社内取り組み施策「テック新聞」についてご紹介します。 テック新聞とは、エンジニアと全社のつながりをより強化するために生まれた エンジニア版社内報 のようなものです。 目次 背景 テック新聞の内容 テック新聞をやってみて 背景 テック新聞が生まれたきっかけは、エンジニアマネージャーから「技術職と全社のつながりを強化してほしい」というミッションを与えられたことでした。エンジニアから全社向けの活性化施策は前例が無かったので何から手をつけようか悩んだ記憶があります。。 そこで、まずは現状のエンジニア組織の課題を洗い出すために、エンジニアだけでなく社内の営業職や企画職（以下：非エンジニア）の方にもヒアリングを行いました。 ヒアリングを行なった結果さまざまな課題が見えてきましたが、その中でも （非エンジニア）エンジニアの業務内容が分からない （エンジニア）業務内容が伝えづらい という声が多くありました。 弊社では、案件のリリースや営業の売上げ目標達成といったトピックスを全社で共有する社内SNSツールがあるのですが、 エンジニアが具体的に何をしているのかが分かりづらい・伝わりづらいといった課題がありました。 また全社的に見るとエンジニアはあまり表に出ない（出たがらない？）という事もあり、 エンジニアの内なる熱い想いが伝わっていない！もっと知ってほしい！と思い 「テック新聞」 を提案しました。 テック新聞の内容 記事はCanvaで作成し、Google Sitesで展開。 内容はエンジニアの業務内容に関わるものですが、非エンジニアでも分かるような内容を意識して編集しています。 次に各コンテンツについて説明します。 カバーモデル テック新聞の表紙モデルとして毎月一人にフォーカスし、業務内容からプライベートな部分も紹介。 他部署の気になる人を紹介することで非エンジニアとの会話のきっかけ作りもしています。 リリース特集 1ヶ月間でリリースされた案件から２〜３個ピックアップし、担当エンジニアが 開発で苦戦したこと、こだわったポイント を紹介。 ここで、前述した社内SNSでは書ききれない想いを語っていただいています。 その他 エンジニアイベント（ WP HACK DAY など）の紹介や、長期PJの特集、社員から募った知りたいことなど 非エンジニアにも楽しんでもらえるような内容を毎月考えています。 テック新聞をやってみて 毎月編集をするのは正直大変ですが、編集をすることで自分自身も他部署のエンジニアの取り組みや、他チームのプロジェクトの内容をキャッチアップできて非常に有意義でした。 また、毎月読んでもらった方にアンケートも実施し、満足度や改善要望を受け付けています。読んでいただいている方々からの満足度は非常に高く、毎月発刊を楽しみにしてくださっている方も多くいます。 今後も非エンジニアにも技術的な分野もキャッチアップしてもらうことで、全社のITリテラシーを高め、『技術とデザインのウエディングパーク』をより加速させていければと思います！

こんにちは。エンジニアのあずめんです。 弊社は、 「ウエディングパーク的『デザイン経営』」 を掲げています。 このデザイン経営を実現するために、エンジニアチームでも、 プロダクトの運用スピードを上げもっと価値創造できる集団になる 技術の深堀りをしてもっとエンジニアがもっとワクワクできる環境をつくる この二つを実現したいと考え、 エンジニアチームで所属部署を問わない横断のプロジェクトを始めることが決まりました。 エンジニア横断のプロジェクト そのプロジェクトを、 TAKIBI プロジェクト と名付けました。 このTAKIBI プロジェクトは、 プロダクト改善サイクルづくり AWS／インフラを理解、運用できるようになる この二つを、エンジニア横断で推進するプロジェクトです。 TAKIBIと名付けたのは、 プロダクトやシステムをリリースして終わりではなく、よりよくしていきたい。そのような想いを何と例えるかと考えてひらめいた「焚火」。 焚き火は、火起こしして終わりでなく、長く燃え続けるためには薪をくべたり、風や雨にさらされないように、面倒を見てあげる必要がある。 システムをつくり、育てていくことに似ているかもしれない。 エンジニアみんなで焚き火を囲むように、協力して高め合いたい。 こういった想いを込めたからです。 本記事では、私も推進の一員として進めた 「AWS／インフラを理解、運用できるようになる」 ために実施した施策について紹介します。 AWS／インフラを理解、運用できるようになる 参加者を募り、そのメンバーが、 システムがどのようなAWSサービスを利用しているか どういう思想でその設定をしているか を知ってもらうためには、まず、AWSに触れてもらいながら、理解を深めていくことが一番だと考えました。 そこで、EC2やRDSなどのサービスを設定しながら、 弊社で利用しているフレームワークのLaravelアプリケーションが開発できる状態のシステムを構築するまで、 ハンズオン形式で触りながら理解を深めていただきました。 ハンズオンはZoomで講師の画面を共有しながら実施し、わからないことは都度質問できるような形式で行いました。 また、ただ構築するだけでは、AWS公式のものも含めたくさん教材はありますので、社内でやる意義を持たせるため、 弊社の実際に運用しているサービスではどう設定しているかなど紹介したりして、 AWS初学者じゃなくても学びがあるようなハンズオンを心掛けました。 AWSハンズオンのために、どのような構成で、何に注目して紹介するかなど講師メンバーですり合わせ、準備を進め、 1時間のハンズオンを4回～5回で実施しました。 ハンズオンで学ぶAWSサービスは下記のような簡単な構成で、それぞれの役割などを紹介したり、 弊社で実際運用しているサービスではどのような意図や設定がしているかなども紹介しました。 AWSハンズオンを通じて AWSハンズオンを終えて、参加者にアンケート回答をいただいたのですが、非常に満足度の高いものとなりました。 このAWSハンズオンをきっかけに、AWSに興味を持って、勉強しはじめてくれた方も参加者の中にいました。 未知のものを一人で学習するハードルというのは高いですが、それを教えあって学ぶことでそのハードルが少し下げられたのではないでしょうか。 また、アプリケーションが動いているその周辺で実際にどのようなサービスがどのような役割で利用しているかが知ることができたといった感想などももらえ、 学びの大きいハンズオンになったのかと確信を持っております。 TAKIBIプロジェクトは、このAWSハンズオンだけではありません。 引き続き、弊社のエンジニアが技術にワクワクし、成し遂げたいことを実現できるように、全員で歩みを進めてまいります。

こんにちは、エンジニアのみーや（ @miiya387 ）です。 今回は先日開催された「 WP HACK DAY 」の第4回でチームで取り組んだ内容のレポートをしようと思います。 チームメンバー全員で終始楽しく取り組んだので、当日の様子からエンジニアの雰囲気などが伝わったら嬉しいです。 また、解決する手段としてSlackワークフローやGoogle Apps Script(以下: GAS), Redmine APIなどを活用したので、Slackワークフローを用いて資料の作成や通知周りを一本化したいと思っている方の参考にもなればと思います。 目次 WP HACK DAYについて 当日の様子 成果物 まとめ WP HACK DAYについて WP HACK DAYは、ウエディングパークエンジニアチームの技術力向上と一体感醸成のための1dayハッカソンです。 今回実施した第4回目では 「 業務課題を解決するプロダクト開発 」 をテーマに3人1チームのチーム開発形式で実施しました！ 取り上げた課題 私たちのチームが取り上げた課題は「 障害対応時にやることが多く複雑 」ということです。 システム障害が発生した際に、対応者が行うことがたくさんあること、さらに行う順番や方法が複雑化してきていることが課題でした。もう少し掘り下げると、障害対応の中でも対応に入る前に行う「一次報告」に時間と手間がかかってしまうことが課題でした。 障害対応は、復旧までの時間をいかに短くできるかが重要で、時間との勝負な作業である一方で復旧対応以外のタスクに手間がかかってしまうことに着目し、一次報告をする作業を簡潔にすることで本質的な復旧作業に割ける時間を増やそうと考えました。 設定したゴール 3人で話し合う中で、対応に慣れているメンバーもいれば、初めてのメンバーもいることや、エンジニアメンバー以外が一次報告を担当することもあることに気づきました。 課題や実際に使っていただく状況も考慮した上で、「 誰でも簡単に障害対応の一次報告までを行える機能 」を作ることに決めました。 取り組む内容が決まったところで、話し合った課題や要件、実装方法などをシートにまとめ、当日の役割分担やスケジュールを事前に決めておきました。   当日の様子 今回実装する機能のフロー図と当日のタイムスケジュールは以下のようになっています。     当日は事前に設計しておいた実装方法で実際に機能を作成するところから始まります。 3人のチームなので作業を分担して効率よく進めても良かったのですが、チームになったメンバーが普段一緒に開発をする機会の少ない組み合わせだったので、あえてすべての作業を3人一緒に行うことにしました。一緒に実装することで、ワイワイ話し合いながら楽しく実装すること、実装がうまく行った時の達成感などを共有したかったからです。 実際に一つの画面を3人で囲みながらの開発は、WP HACK DAYならではの贅沢なモブプロ時間になりました。       成果物 今回作成したものは以下の5つです。 Slackのワークフロー/Webhook URL（手動作成） 障害対応した内容が一覧表示されるスプレッドシート（手動作成/GASを書くのはここです） Googleドキュメント（GASで作成） RedmineのISSUE（GAS上でRedmine APIを使って作成） メール（GASでGmail送信） Slackワークフローの作成 作成手順は 公式 に載っている通りです。 今回は一覧管理するスプレッドシートと連携してワークフロー申請時にスプレッドシートに入力した内容が出力されるようにしました。 スプレッドシート側にGASの設定をし、Slackのワークフローで入力された内容をもとに、以下の作成をします。 Googleドキュメント RedmineのISSUE 作成された2つをもとにスプレッドシートの行を再度更新して情報を補足します。 最後に作成した2つのURLと一緒に、調査・対応開始の報告としてメールとSlackに通知が来るようにしました。Slackへの通知は incoming Webhook を利用して行いました。     これで、一次報告者はSlackの指定のチャネルからワークフローを出すだけで必要な資料や通知が済まされる状態になりました。今までは手作業ですべて行なっていたので時間にすると15分ほどかかっていた作業が2分ほどで完了する改善となりました。 今回作成したGASの中身は以下になります。対象のスプレッドシートに行が追加されたタイミング（変更）をトリガーに動作するように設定して使っています。 // メディア別関係者アドレス一覧 const mailLists = { "メディア1": ['test1@gmail.com', 'test2@gmail.com'], "メディア2": ['test3@gmail.com', 'test4@gmail.com'], "メディア3": ['test5@gmail.com', 'test6@gmail.com'], } function main() { let data = formatData(); // RedmineのISSUEがすでにある場合は何もしない if (data['ticketUrl']) { return } let {document, docUrl} = createDoc(data); let {ticketId, ticketUrl} = createTicket(data, docUrl); // スプレッドシートのデータ整形 let ss = SpreadsheetApp.getActiveSpreadsheet(); let sheet = ss.getSheetByName('障害管理一覧'); // 報告書URL追加 sheet.getRange(data['target'], 9).setFormula('=HYPERLINK("' + docUrl + '","' + data['title'] + '")'); // チケットURL追加 sheet.getRange(data['target'], 10).setFormula('=HYPERLINK("' + ticketUrl + '","' + ticketUrl + '")'); // 報告者名整形 sheet.getRange(data['target'], 3).setValue(data['name']); // No追加 sheet.getRange(data['target'], 1).setValue('=ROW()-4'); // タイトルを更新 document.setName('【#' + ticketId + '】' + data['title']); // メール通知 sendGmail(data, docUrl, ticketUrl); // slack通知 post_slack(data, docUrl, ticketUrl); } /** * データ整形 */ function formatData() { // シートから題名取得 let ss = SpreadsheetApp.getActiveSpreadsheet(); let sheet = ss.getSheetByName('障害管理一覧'); let lastRow = sheet.getLastRow(); // 最終行 let response = []; // 対象行 response['target'] = lastRow; // 報告者 const realName = sheet.getRange(lastRow, 3).getValue() response['name'] = realName.replace(/^.*-/, ''); // 発見者 response['discoverer'] = sheet.getRange(lastRow, 7).getValue() // 報告Q response['quarter'] = sheet.getRange(lastRow, 2).getValue(); // メールアドレス response['email'] = sheet.getRange(lastRow, 4).getValue(); // 報告日 response['date'] = sheet.getRange(lastRow, 6).getValue(); // メディア response['media'] = sheet.getRange(lastRow, 8).getValue(); // 題名 response['title'] = sheet.getRange(lastRow, 9).getValue(); // チケット response['ticketUrl'] = sheet.getRange(lastRow, 10).getValue(); return response; } /** * 報告書作成 */ function createDoc(data) { let fileName = '【#チケット番号】障害報告書'; // コピー元となるドキュメントファイルのID // IDはドキュメントを開いたときのURLから取得可能 // 例：https://docs.google.com/document/d/AAAAAA/edit // この場合は"AAAAAA"がID let fileId = 'AAAAAA'; // ファイル名が全角で打てないので全角変換 // ファイル名を全角にする必要がなければ削除 fileName = fileName.replace(/[A-Za-z0-9]/g, function(s) { return String.fromCharCode(s.charCodeAt(0) + 0xFEE0); }); // コピー元のファイルを開く let f = DriveApp.getFileById(fileId); let folder = f.getParents().next(); // 格納先ディレクトリがあるか（Q） const targetQFolder = data['quarter'].replace(' ', ''); let quaterFolder = folder.getFoldersByName(targetQFolder); if (! quaterFolder.hasNext()) { // ない場合は作成する quaterFolder = folder.createFolder(targetQFolder); } else { quaterFolder = quaterFolder.next(); } // 格納先ディレクトリがあるか（月） let targetMonthFolder = Utilities.formatDate(data['date'], "JST", "M月"); let monthFolder = quaterFolder.getFoldersByName(targetMonthFolder); if (! monthFolder.hasNext()) { // ない場合は作成する monthFolder = quaterFolder.createFolder(targetMonthFolder); } else { monthFolder = monthFolder.next(); } // コピーを作成。作成したコピーを参照。 f = f.makeCopy(fileName, monthFolder); // コピー後のファイルの中身を書き換える // ドキュメントの中身を取得 let body = DocumentApp.openById(f.getId()).getBody(); // 報告日 body.replaceText('報告日：yyyy年MM月dd日', '報告日：' + Utilities.formatDate(data['date'], "JST", "yyyy年MM月dd日")); // メディア body.replaceText('所　属：メディア1', '所　属：' + data['media']); // 氏名 body.replaceText('氏　名：担当者名を記載', '氏　名：' + data['name']); // 題名 body.replaceText('XXXXXXXXXXX障害', data['title']); return {document: f, docUrl: f.getUrl()}; } /** * チケット作成 */ function createTicket(data, url) { // チケット内容 const payload = { "issue": { "project_id": "XXX", "subject": data['title'], "custom_field_values": { "20": data['quarter'], "56": data['discoverer'], "22": Utilities.formatDate(data['date'], "JST", "yyyy-MM-dd"), "23": data['media'], "55": url } } }; let redmine_url = 'https://{所有グループのRedmineURL}/issues.json'; let api_key = 'abcdefg'; // RedmineのAPI key を入力 let headers = { 'X-Redmine-API-Key': api_key, 'Content-Type': 'application/json', }; let options = { 'method': 'POST', 'contentType': 'application/json', 'headers': headers, 'payload': JSON.stringify(payload), }; let response = UrlFetchApp.fetch(redmine_url, options); let id = JSON.parse(response).issue.id; return { ticketId: id, ticketUrl: 'https://{所有グループのRedmineURL}/issues/' + id }; } /** * 関係者に一次報告メール送信 */ function sendGmail(data, docUrl, ticketUrl) { const recipient = mailLists[data['media']].join(','); const subject = '【障害報告】' + data['media'] + '_' + data['title']; const body = '障害が発覚したので調査・対応を始めます。\n\n障害報告書: ' + docUrl + '\nチケット: ' + ticketUrl; const options = { name: data['name'], from: 'test_user@gmail.com' // fromアドレス入力 }; GmailApp.sendEmail(recipient, subject, body, options); } /** * チャネルに一次報告チャット送信 */ function post_slack(data, docUrl, ticketUrl) { // SlackのWebhookURL const slack_webhook_url = ''; // webhook url入力 // SlackのWebhook URLに投稿するデータをまとめる const json = { 'username': '障害報告', 'icon_emoji': ':smiley:', 'text': '<!here>障害が発覚したので調査・対応を始めます。\n\n報告者: ' + data['name'] + '\nメディア: ' + data['media'] + '\n題名: ' + data['title'] + '\n報告書: ' + docUrl + '\nチケット: ' + ticketUrl }; // SlackのWebhook URLに送信するデータをJSONに変換する const payload = JSON.stringify(json); // UrlFetchAppで使用するメソッドやコンテントタイプを指定 const options = { 'method': 'post', 'contentType': 'application/json', 'payload': payload }; // Slackに送信 UrlFetchApp.fetch(slack_webhook_url, options); } まとめ 今回は、先日開催された「WP HACK DAY」の第4回にチームで行った取り組みを紹介させていただきました。普段一緒に開発をする機会の少ないメンバーとの開発はとても楽しく、1日という短い時間であっても互いに学び合える時間となりました。 今回作成した機能は現段階ではプロトタイプレベルなので、これから本運用で日々の障害対応時に使えるように調整していこうと思います。  

こんにちは。フォトウエディング・前撮りのクチコミ情報サイト「Photorait (フォトレイト)」のエンジニアリングマネージャーをしている武田( @takedajs )です。 弊社ではエンジニアの「やりがい」と「技術力」の向上を目的とした技術推進委員会という組織をエンジニアリングマネージャーとテックリードが中心となって運営しています。 今回は技術推進委員会が運営している 「WP HACK DAY」 の第4回目を開催したので紹介します！ 目次 WP HACK DAY とは？ 前回(WP HACK DAY #3)との変更点 当日の様子 参加者からのフィードバック 最後に WP HACK DAY とは？ 第1回目テーマ Slackを活用して、社内の誰かの仕事を便利にする仕組みをつくる！ 第2回目テーマ 開発の課題解決やタスクの効率化、技術検証など、やりたいけど出来ていないこと 第3回目テーマ 業務課題を解決するプロダクト開発 今回実施した第4回目では、前回の参加者からのフィードバックをもとに引き続き 「業務課題を解決するプロダクト開発」 をテーマに実施しました！ WP HACK DAY #4のルール ・ 参加者：エンジニア(今回は2部署のエンジニアが参加) ・ 3人1チームで1日(約7時間)で取り組み、夕方に成果発表会(デモ実施必須)を実施 ・ 普段業務で関わらないメンバーの組み合わせで運営がチーム決め ・ 事前に当日開発するものを検討し、実装可能か調査 ・ プロトタイプ以上のものを開発 ・ 参加方法はオンライン&オフラインどちらでも可(オフライン推奨) 前回(WP HACK DAY #3)との変更点 運営の振り返りや参加者のフィードバックなどをもとに前回から何点か運用を変更しました。 【運営メンバーの増員(1人→3人)】 運用を1人で全てやっていたため運営タスクが多く、入社数ヶ月の 中途の方 と今年入社の 新卒の方 に運営メンバーに入って頂きました！圧倒的感謝！ 【参加者全員で一箇所に固まって開発】 チーム毎でバラバラに開発していたため一体感に課題があったので、全チーム固まって開発してもらいました。 【開発したプロトタイプを会社のテックブログ公開を必須】 社内だけの公開だともったいないクオリティで社外向けに発信もした方が良いという声があったので必須にしました。 【デザイナーメンバーの参加】 次回からデザイナーメンバーにもハッカソンに参加してもらえることになったので、雰囲気を体感してもらうために、ランチ、成果発表会、懇親会に参加してもらいました。 当日の様子 全体のスケジュール 開会式(9:30-9:40) 前回と同様に各々チーム毎にZoom背景画像を作成してくれましたー！ 普段の業務でもみんなよくZoom背景画像を作成してるので、さくっと作成！ 午前の開発(9:40-12:00) 2つの島を使ってみんなで固まって開発しました！ ハッカソンの熱気を味わってもらえるように、次回から参加するデザイナーの方たちも同じ島で業務をしてもらいました！ ランチタイム(12:00-13:00) ハッカソン恒例のピザを大量に頼み、みんなでワイワイ食べました！ ※ 定期的な換気や一定距離を保ちながら実施しました。 午後の開発、発表資料作成(13:00-17:00) 1台のPCで開発し、3人でワイワイモブプロ中のチーム！ 僕のチームでは社内制度の コーシー を利用して休憩がてらみんなで を飲みに行きました！ ※ コーシー ： オフィス出社時の社内コミュニケーション活性化を目的に、カフェでのコーヒーブレイク代を支給する制度 チームの発表準備などで忙しそうでしたが、ナイスカメラ目線！感謝！ 成果発表会(17:00-18:00) 全社向けに成果発表会の開催を告知し、エンジニア以外の方も視聴者として参加して頂きました！ Zoomチャットも大盛りあがりです！発表後は発表会参加者にアンケートを取り、優勝チームを決定しました！ 発表されたプロトタイプ ・Garoonの予定確認と予定を抑えるslackコマンド ・TeamSpiritの残業申請自動化 ・障害報告の自動化 ・各種期限のリマインドbot ・経営本部の作業の効率化 ・社内トピックスのリアクション上位通知bot 懇親会(18:00-18:30) ハッカソン中は切磋琢磨し合ったライバル同士ですが、最後はみんなで労をねぎらい合いました！ ※ 定期的な換気や一定距離を保ちながら実施しました。 参加者からのフィードバック 次回のイベントを更に良いものにするべく、参加者に匿名アンケートを回答してもらいました！ 厳しめに回答してほしい旨を伝えましたが、それでも全体の満足度(5点満点)平均点は4.57点だったので、一定の成果が出たイベントだったかなと思います。 以下、いただいたフィードバックです。 良かった点 みんなで開発やコミュニケーションを積極的に行い、ワイワイガヤガヤな環境を作れた。 普段一緒に業務をしない方たちと交流できたので楽しかった。 モブプロやペアプロしながら開発ができたので、先輩の開発プロセスを学べた。 改善点 当日までに何を実装するかや実装できるかの調査をする必要があり、事前準備に時間がかかってしまった。 チーム内でスキルの差があり、実装するものを検討する際に開発したいプロトタイプのレベル感に差があった。 オフィスで一箇所に集まって開発していたので少し騒がしかったかもしれないので、オフィス以外のスペースを借りで実施しても良かった。 最後に ウエディングパークエンジニアチームの一体感作りとエンジニアのスキルを高めるための1dayハッカソン(WP HACK DAY)の第4回目について紹介しました。 次回からは今までメインで運営をしてきた僕がサポートにまわり、新しい運営メンバーの方たちがメイン担当になります。 また、エンジニアだけではなくデザイナーの方たちも参加予定なので、これまでと違ったハッカソンイベントになりそうで今から楽しみです！

こんにちは。結婚指輪・婚約指輪のクチコミサイト「Ringraph」でエンジニアをしているさー（ @__south__373 ）です。先日、Four Keysを計測することで技術的なチャレンジがしやすい環境をつくりたいという提案をしました。 詳細はこちらをご覧ください。 Four Keysを計測することで技術的なチャレンジがしやすい環境をつくる 提案から2ヶ月半ほどかけて計測の仕組みが整ってきたので紹介したいと思います。 Four Keysって何？ Four Keysを計測しようとなった背景については前の記事をご覧いただければと思いますが、Four Keysについて引用しておきます。 Four Keysとは DevOps Research and Assessment（DORA） チームが実施した 6 年間の研究から確立された、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標です。 ・デプロイ頻度 ・変更のリードタイム ・変更障害率 ・サービス復元時間 （ 前回の記事 より引用） 計測するまでの流れ Four Keysの計測ができるようになるまで、以下の流れで進めていきました。 それぞれ詳しく見ていきたいと思います。 まず各指標の定義を決める データ収集の方法を決める データ収集のシステム構築 ダッシュボード化 まず各指標の定義を決める Four Keysでは4つの指標が示されていますが、具体的な定義についてはウエディングパークに合う形にしたいと思い、定義の認識を揃えるところから始めました。事前に各自で指標の理解を深め、自分なりに定義を考えて持ち寄ってから一つに絞っていきました。 ＜Four Keysについて情報をインプット＞ ＜自分なりに良いと思った定義を持ち寄ってディスカッション＞   決めた定義は以下の通りです。 リードタイム featureブランチのfirst commit時間〜masterにマージされた時間 ※土日祝除く デプロイ頻度 masterにマージされた回数 ※リポジトリごとそれぞれカウント ※SQL実行も1回とみなす 平均修復時間 障害発見から復旧までの平均時間 変更失敗率 施策数に対する障害発生率 ※エンジニア施策もチケットに起こして対応する ※簡単なテキスト文言修正なども含める ※過去の案件は過去の障害率を更新する   定義を決める際に気をつけたのは、今の開発フローを変えずにできるかどうか。開発環境を改善するための取り組みなので、計測をするために負担が増えてしまっては元も子もないからです。結果として、新しい作業をほとんど増やすことなく全ての指標を集計できる形になりました。 データ収集の方法を決める 手動で集めることももちろんできましたが、今回はAWSのOpenSearchを使ってデータ保存と可視化をすることにしました。OpenSearchを選んだ背景は以下の通りです。 今後負担を増やさずに運用できる 必要なデータさえ入れておけば、可視化の形は後からいくらでも変更できる 他の部署にも簡単に横展開できる この施策も技術挑戦にしてしまう←ここ重要 他のサービスと比較検証したわけではないのですが、この施策が始まることが決まった月に入社されたエンジニアメンバーから提案があり、彼に知見があることからプロトタイプとして即決定しました。 データ収集のシステム構築 コミットデータをGitHubとGitLabから送信するバッチと、不具合報告データをスプレッドシートから送信するGASを作成しました。 ほとんどマスクしてしまっていますが、1行が1施策データ・1報告データのように保存されます。 Hotfixを考慮する必要があることや、本番環境にマージされるPRに複数の案件が混ざる場合に各案件のfirst commitを取得する必要がある部分で苦戦しました。 ダッシュボード化 OpenSearchではVisualizeページで様々な可視化方法が選択できます。今回は主にVertical BarとTSVBを使用して可視化しました。 Visualizeページで作成したグラフを組み合わせることでダッシュボードを作成することができます。1ページで4つの指標を全て可視化することができました。 おわりに 可視化をしてみて、事業ごとに傾向が違っておりそれぞれの課題が見えてきそうです。6月に提案したものが、ようやくスタート地点まできました。ここから課題設定→改善施策実施→振り返りのサイクルを繰り返すことで、技術的なチャレンジがしやすい組織に近づけていけたら良いなと思います。

こんにちは、エンジニアのみーや（ @miiya387 ）です。 Reactのフレームワーク「Next.js」への入門として、公式チュートリアルを何回かに分けてまとめていきます。 今回は、5. Dynamic Routes と 6. API Routesについてまとめていきます。 それ以前の章を知りたい方は各章に過去記事のリンクを付けておりますのでそちらからご覧ください。 Create a Next.js App Navigate Between Pages Assets, Metadata, and CSS Pre-rendering and Data Fetching Dynamic Routes API Routes Deploying Your Next.js App やってみる 5. Dynamic Routes 前回までは、getStaticPropsを利用して外部データを取得し、インデックスページの描画を行っていました。 今回はDynamic Routesを使って、ブログページへのパスを動的に作成していきます。 Implement getStaticPaths まず初めに、以前作成したpages/posts/first-post.jsは不要になるのでここで削除しておきましょう。 次に、pages/posts 配下に [id].js ファイルを作成します。 []で動的に指定するパラメータ名を囲むことで、リクエストされたURLに応じて動的にページが返されるようになります。これが Dynamic Routes です。 import Layout from '../../components/layout'; export default function Post() { return <Layout>...</Layout>; } 次に、lib/posts.js に以下を追加します。 getAllPostIdsはposts配下のファイル名(.mdを除く)一覧を返す関数です。 返却データにはオブジェクトでキーにidを持つデータが含まれている必要があります。（ファイル名にidを使用しているため） export function getAllPostIds() { const fileNames = fs.readdirSync(postsDirectory); // Returns an array that looks like this: // [ // { // params: { // id: 'ssg-ssr' // } // }, // { // params: { // id: 'pre-rendering' // } // } // ] return fileNames.map((fileName) => { return { params: { id: fileName.replace(/\.md$/, ''), }, }; }); } 追加した関数を page/posts/[id].js 内でimportして使用します。 import Layout from '../../components/layout' import { getAllPostIds } from '../../lib/posts' export async function getStaticPaths() { const paths = getAllPostIds() return { paths, fallback: false } } export default function Post() { return <Layout>...</Layout> } 次に、指定されたidでブログをレンダリングできるようにします。 lib/posts.js ファイルの末尾に次を追記します。getPostDataは、ブログのデータをidを元に返す関数です。 export function getPostData(id) { const fullPath = path.join(postsDirectory, `${id}.md`); const fileContents = fs.readFileSync(fullPath, 'utf8'); // Use gray-matter to parse the post metadata section const matterResult = matter(fileContents); // Combine the data with the id return { id, ...matterResult.data, }; } 次に、[id].jsのimport文を書き換え、getStaticPropsを追加します。 // import { getAllPostIds } from '../../lib/posts' import { getAllPostIds, getPostData } from '../../lib/posts'; export async function getStaticPaths() { const paths = getAllPostIds() return { paths, fallback: false } } export async function getStaticProps({ params }) { const postData = getPostData(params.id) return { props: { postData } } } これにより、getStaticPropsがブログデータをgetPostDataから受け取ってpropsとして返すようになります。 そして、Post関数を以下のように書き換えます。 export default function Post({ postData }) { return ( <Layout> {postData.title} <br /> {postData.id} <br /> {postData.date} </Layout> ); } これで各ブログページにアクセスしたらページが見れるようになるはずです。 しかし、私の場合は以下のエラーが発生しました。 gray-matterがなぜかCan’t resolve になっています。今までは何も起きていなかったのですが、エラーが出てしまったので改めてインストールしてサーバーを再起動します。 $ npm install gray-matter $ npm run dev 見れるようになりました。 http://localhost:3000/posts/ssg-ssr http://localhost:3000/posts/pre-rendering バッチリDynamic Routesでのページ描画ができていますね！ 試しに posts配下に test.md を新規で作成してアクセスできるかも試してみましたが、しっかり表示されました。 http://localhost:3000/posts/test しかし、まだブログのマークダウンコンテンツの描画ができていないようなので対応しましょう。 Render Markdown マークダウンコンテンツを描画するために以下のライブラリをインストールします。 npm install remark remark-html lib/posts.js にimport文を追加します。 import { remark } from 'remark'; import html from 'remark-html'; そして、getPostDataを以下のように書き換えます。 export async function getPostData(id) { const fullPath = path.join(postsDirectory, `${id}.md`); const fileContents = fs.readFileSync(fullPath, 'utf8'); // Use gray-matter to parse the post metadata section const matterResult = matter(fileContents); // Use remark to convert markdown into HTML string const processedContent = await remark() .use(html) .process(matterResult.content); const contentHtml = processedContent.toString(); // Combine the data with the id and contentHtml return { id, contentHtml, ...matterResult.data, }; } remarkをawaitで実行できるようにgetPostData自体をasyncに変更しています。 また、[id].js内のgetPostDataの呼び出しもawaitに変更しておきましょう。 export async function getStaticProps({ params }) { const postData = await getPostData(params.id) return { props: { postData } } } さらに、[id].jsのPost関数を以下の内容に更新します。 export default function Post({ postData }) { return ( <Layout> {postData.title} <br /> {postData.id} <br /> {postData.date} <br /> <div dangerouslySetInnerHTML={{ __html: postData.contentHtml }} /> </Layout> ); } 再度、各ブログページへアクセスするとマークダウンのコンテンツが表示されるようになりました。 dangerouslySetInnerHTMLでcontentHtmlをレンダリングすることでHTMLが生成できます。 http://localhost:3000/posts/ssg-ssr http://localhost:3000/posts/pre-rendering チュートリアルでは、ここからさらにページ表示の改善を行なっていますが、Dynamic Routesについてはここまでで十分理解できたので、本記事では割愛して次の章に進みます。 6. API Routes Creating API Routes API Routes を使うことで、Next.js内にAPIエンドポイントを作成することができます。 Create a simple API endpoint pages配下に api ディレクトリを作成し、hello.jsファイルを作成します。 export default function handler(req, res) { res.status(200).json({ text: 'Hello' }); } http://localhost:3000/api/hello  にアクセスすると指定したレスポンスが表示されました。 Next.js内でバックエンドの実装も可能になるのでとても便利ですね！ 実際のAPIは別にあるとしても、バックエンドの実装を待たずにフロントエンドの実装を進めていきたい場面などではテストAPIの用意もNext.jsなら容易にできそうでとても助かりそうです！ まとめ 今回はNex.jsの公式チュートリアルをもとにDynamic Routes と API Routesについて触れてみました。 ファイル名を[]で囲むだけで動的ルートが適用できるのはとても簡単で便利でしたね！ Next.jsは標準で用意されている機能だけで十分開発を進められる印象が強いです。 ここまでのソースは github に上げたので興味のある方はぜひ一緒にNext.jsと仲良くなっていきましょう！ 次回は最後の章である「Deploying Your Next.js App」をやってみます。

こんにちは。 Photorait エンジニアのヒエイです。 先日開催したWP HACK DAYにてAWS Amplifyを使ったサイトツールを作りました。 （HACK DAYの様子はこちら→ WP HACK DAY#3 ） AWS Amplifyでの開発環境作成からデプロイまでのフローを紹介します。 AWS Amplify AWS Amplify（以下Amplify）はAWS社が提供するウェブアプリケーション作成・公開できるサービスです。 https://aws.amazon.com/jp/amplify/ HACK DAY当日に初めて触りましたが、開発環境作成からデプロイとサイトとして公開まですごく簡単に行えました。 目次 Amplifyで作ったページ Reactアプリケーションを作成 GitHubリポジトリ作成 Amplifyプロジェクト立ち上げ デプロイされたサイトを確認 ローカル開発 デプロイ まとめ Amplifyで作ったページ Slackに通知したい事項をサイト上で登録できるページを作りました。 Amplifyでのサイトから入稿し、GraphQL APIを使ってDynamoDBにデータを保存します。 ※Slackへの通知は別システムにてDynamoDBデータにアクセスして通知をさせています。Lambdaで定期実行のスクリプトを用意しましたが今回はこのシステムについては触れません。 Reactアプリケーションを作成 以下コマンドでReactアプリケーションをインストールします。 npx create-react-app hackdayapp cd hackdayapp npm start http://localhost:3000 でローカルブラウザでページが表示される事を確認。 GitHubリポジトリ作成 GitHubにて新しいリポジトリを作成し、先ほど作ったReactアプリケーションのソースをpushします。 ※ create-react-app したプロジェクトにはあらかじめ .git ディレクトリがあるので、 git init 前に削除してください。 git init git remote add origin git@github.com:username/リポジトリ.git git add . git commit -m 'init commit' git push origin master Amplifyプロジェクト立ち上げ AWSの管理コンソールから検索窓でAmplifyを検索し、Amplifyコンソールを開きます。 Amplify Hosting から 「使用を開始する」 をクリック。 レジストリのサービスから、 GitHub を選択して 「続行」 をクリック。 リポジトリブランチの追加画面に遷移します。 View GitHub permissions で自身のGitHubアカウントとの認証を行います。 認証後、リポジトリを選択できるようになるので先ほど作成したGitHubリポジトリを選択します。ブランチはメインブランチとし、 「次へ」 をクリック。 構築設定の構成 はそのままの状態で 「次へ」 。確認画面で 保存してデプロイ をクリック。 無事、アプリケーションがデプロイを開始します。 デプロイ中・・・。 デプロイされたサイトを確認 https://master.アプリ名.amplifyapp.com/ を確認。 先ほどlocalhostで見たページが反映されています。デプロイされました！ 今後、GitHub連携時に設定したブランチ（例ではmasterブランチ）にpushなりマージされると自動でこの環境にデプロイされます。素晴らしい！ ローカル開発 立ち上げたAmplifyプロジェクトとローカルの開発環境を紐付けます。 開発はローカル環境で行い、localhostで挙動確認をし、仕上がったらGitHubにpushを経て自動でデプロイされる流れにします。 Amplify CLIをインストールと設定 npm install -g @aws-amplify/cli amplify configure amplify configure を打つと対話式のAmplify設定に移ります。 Enter を押す。 リージョンは ap-northeast-1 を選択 IAMユーザーの作成。ユーザー名を決める。 ブラウザが立ち上がるので ユーザー詳細の設定 はそのまま 「次へ」。 アクセス許可は AdministratorAccess-Amplify を選択。 タグはそのままの状態で確認画面へ行き、 ユーザー作成 をクリック。 アクセスキーID と シークレットアクセスキー をメモ。 コマンドラインに戻り Enter。 accessKeyId 、 secretAccessKey を求められるので入力。 ローカルのAWS Profile設定をし完了。 Amplifyコンソールの アプリ設定 > 全般 から アプリケーション ARN の /以降をコピー 以下コマンドを打つ。 amplify init --appId コピーしたID 再び対話式の設定が始まるので、デフォルトの状態でEnterもしくはYesを入力し、AWS Profileを求められたらローカルのAWS Profileを選択し設定完了。 認証の作成 ここからはAWS社が用意しているチュートリアルに沿ってやりました。 https://aws.amazon.com/jp/getting-started/hands-on/build-react-app-amplify-graphql/module-three/ # Amplifyライブラリインストール npm install aws-amplify @aws-amplify/ui-react@1.2.25 # 認証サービス作成 amplify add auth # 認証サービスをデプロイ amplify push --y これでAmazon Cognitoの認証環境が立ち上がった形になります。 jsxファイルに以下のコードを追加。 src/index.jsx import Amplify from 'aws-amplify'; import config from './aws-exports'; Amplify.configure(config); src/App.jsx （書き換え） import React from 'react'; import logo from './logo.svg'; import './App.css'; import { withAuthenticator, AmplifySignOut } from '@aws-amplify/ui-react' function App() { return ( <div className="App"> <header> <img src={logo} className="App-logo" alt="logo" /> <h1>We now have Auth!</h1> </header> <AmplifySignOut /> </div> ); } export default withAuthenticator(App); これで npm start すると おおお、、すげー。しっかりアカウント作成からログインも出来ます！ APIとDatabase作成とアプリ連携 こちらもチュートリアルに沿います。 https://aws.amazon.com/jp/getting-started/hands-on/build-react-app-amplify-graphql/module-four/ APIとDB追加。 amplify add api GraphQLのスキーマ追加。 amplify/backend/api/hackdayapp/schema.graphql type Hackday @model { id: ID! text: String! slack_channel: String! } APIデプロイ。 amplify push --y これでGraphQL APIとDynamoDBが立ち上がりました。 ではアプリケーションコードを修正します。チュートリアルのソースを参考に作ってみます。 src/App.jsx （書き換え） import React, { useState, useEffect } from 'react'; import './App.css'; import { withAuthenticator, AmplifySignOut } from '@aws-amplify/ui-react' import { API } from 'aws-amplify'; import { listHackdays } from './graphql/queries'; import { createHackday, deleteHackday } from './graphql/mutations'; const initialFormState = { text: '', slack_channel: '' } function App() { const [lists, setLists] = useState([]); const [formData, setFormData] = useState(initialFormState); useEffect(() => { const getList = async () => { const apiData = await API.graphql({ query: listHackdays }); setLists(apiData.data.listHackdays.items); } getList(); }, []); const createItem = async () => { if (!formData.text || !formData.slack_channel) return; const ret = await API.graphql({ query: createHackday, variables: { input: formData } }); const data = { id: ret.data.createHackday.id, text: ret.data.createHackday.text, slack_channel: ret.data.createHackday.slack_channel, } setLists([ ...lists, data ]); setFormData(initialFormState); } const deleteItem = async ({ id }) => { const newItemsArray = lists.filter(item => item.id !== id); setLists(newItemsArray); await API.graphql({ query: deleteHackday, variables: { input: { id } }}); } return ( <div className="App"> <h1>アナウンス一覧</h1> <input onChange={e => setFormData({ ...formData, 'text': e.target.value})} placeholder="投稿文" value={formData.text} /> <input onChange={e => setFormData({ ...formData, 'slack_channel': e.target.value})} placeholder="投稿チャンネル" value={formData.slack_channel} /> <button onClick={createItem}>登録</button> <div style={{marginBottom: 30}}> { lists.map(item => ( <div key={item.id}> <p>{item.text}</p> <p>{item.slack_channel}</p> <button onClick={() => deleteItem(item)}>削除</button> </div> )) } </div> <AmplifySignOut /> </div> ); } export default withAuthenticator(App);   npm start してみましょう。 良い感じですね！ 投稿・削除できました。 デプロイ ローカルでの挙動確認ができたので、ソースをpushしてAmplifyのライブ環境に反映してみましょう。 git add. git commit -m '投稿ページ作成' git push origin master ソースがGitHubにpushされました。 デプロイ失敗 自動でデプロイが走りますが、フロントのビルドでエラーになりました。 Module not found: Error: Can’t resolve ‘./aws-exports’ aws-exports が無いとのこと。ローカルではありますが、gitignoreしているのでAmplifyのデプロイ時に作成する工程が必要とのこと。 https://aws.amazon.com/jp/blogs/news/complete-guide-to-full-stack-ci-cd-workflows-with-aws-amplify/ https://github.com/aws-amplify/amplify-cli/issues/6117 https://yasutomo.hatenablog.com/entry/2021/05/21/004601 https://tech.takarocks.com/2022/01/08/solve-aws-amplify-react-backend-build-error/ 「ビルドの設定」 > amplify.yml を編集。 amplifyPush --simple を追加。 「ビルドの設定」 > Build image settings でライブパッケージに Amplify CLI latest を追加。 上記の対応をして再デプロイ。 エラーも無く無事にデプロイされました！ まとめ いかがでしたでしょうか。 簡単にwebサービスをデプロイできるAmplify、とても便利でした！ またAmplify Studioの方ではFigmaを使ってUI部分を作成→react jsxでダウンロードしてソースに取り込めるそうで、ますます簡単に素敵なサイトを公開できそうです。 今後も要チェックだと感じました。 さいごに amplify delete で作成した環境を削除できます。 検証後の削除も簡単ですね！

こんにちは、エンジニアのしげです。 先日新サービスのリリースをしたのですが、その開発では実装前にコーディングルールを決めてから着手するという初の試みに挑戦しました。 今回はその成果について紹介しようと思います！ 経緯 コーディングルールを制定した経緯ですが、以前 新規開発をする際に開発ルールを決めてから着手した と紹介しました。 この時は大まかなルールを決めることで、根本の実装方針をチームで揃えることができ、一定の成果を得ることができていました。 しかしコーディングレベルの粒度においては、同じ処理でも開発者によって実装が異なること、言語化できていない実装方針がありコードレビューのコミュニケーションコストが高いなどの課題はありました。 今回開発したサービスも前回同様複数人でのチーム開発のため、これらの課題は同様に起きうると考えました。 また現時点ではコードレビューは僕が担当していますが、担当が変わったりした場合などに品質が一定でなくなることも考えられるため、コーディングルールを制定するに至りました。 作成方法 プロジェクトがスタートした当初、開発メンバーは僕1人だったため僕が大枠を作成しておき、他のメンバーが参画した後読み合わせをし修正や補足をするという流れで進めました。 僕自身、今までコーディングルールを決めた経験がなかったためどういったフォーマットで作るかは迷ったのですが、 Laravelベストプラクティス を参考にさせていただき、文字だけでなく例をつけるようにしました！ ルールを作るにあたって、他サービスのPRを全て見返しどのような指摘をしていたかをリスト化しました。リスト化したものから汎用性のあるものを抽出し、PHP/Laravel/JSの項目に分けてそれぞれ作成しました。 大体1日で500行くらいのものを作ることができました。 ↑作成したコーディングルールの一部 成果 一番大きな成果は以前の開発に比べコードレビューでの指摘が減ったことです。もしコーディングルールに沿っていないものがあっても、従来だとサジェストを使ってこのように修正してください、とコメントしていたものがドキュメントを貼るだけでよくなったため、やり取りが簡単になりました。ルールに載っていない指摘があった場合も、これは追加しておきましょうというようなコミュニケーションもあり、チーム全体で常に意識することができていたと思います。 まとめ コードレビューでのやり取りが減ったりコードの品質が保たれたりと、とても良いアクションだったと思います！ 運用のハードルが高くないか懸念していましたが、使う中で改善することもできますし、まずは簡単なものでも作ってみることが大事だと感じました！今回作ったものは汎用的なものなので、また新規立ち上げの開発があった際は横展して使っていこうと思います！

こんにちは、おのぽんです。 季節がだんだんと秋が近づき、涼しくなって来ましたが皆様いかがお過ごしでしょうか？ Photoraitチームのエンジニアとして採用いただき、最近ようやく試用期間を抜け出しました！ 今回は、この間に僕が感じたことやチャレンジしたことについてお話できればと思います。   目次 入社して感じたこと 良い点 僕の感じる課題点 チャレンジしたこと おのぽんの部屋開設 人工知能を活用したクチコミ審査補助ツールの提案 人工知能のナレッジ共有 入社して感じたこと 良い点 中途の方にも丁寧な入社後オリエン 僕の中のイメージでは、中途採用 = 即戦力 くらいの感じで考えてたので、「入社して3日目くらいからチュートリアル的な案件をこなして徐々に慣れていく」くらいの肌感でいました。 一方で弊社は中途の方に対してもオリエンが手厚く、少なくとも1週間くらいの間は入社後説明の時間が設けられ、各部署のマネージャーや社長とお話する機会を設けていただけました。 おかげさまで新卒の頃の当時の気持ちや感覚が蘇り、非常にフレッシュな気分になりました。 また、ウエディングパークの全貌を把握できたので非常に良い取り組みだなと感じました！ありがとうございます。   社内の風通しがすごく良い まず1つすごいなと感じた点として、社内の風通しがとても良く、誰がどんなことを頑張ってるかが大変わかりやすいです。 また部署ごとに定例の会議だったり、何かしらのナレッジ共有をオープンにしてるので、いつでも気軽に顔を出すことができます。 入社後のオリエンに加え、具体的にどのような取り組みを行っているのかがわかり、非常に良い取り組みだなと思いました！ 弊社ではcybozuを利用してスケジュール管理をしていますが、どの社員さんのスケジュールを覗いても、ほぼ「非公開のスケジュールがない」ことも驚きを隠せません。 みんな優しい とにかくみなさん優しいです！先にも書いた通り、社内が非常にクリアなこともあり、チーム内はもちろん他部署の方々も非常にフレンドリーに接してくださいます。 お弁当を買って1人で食べようとしていたら、面識のない他部署の方々から「良かったら一緒にご飯食べないですか？」とお声がけいただき非常にびっくりかつ嬉しい経験もありました！ 個人の成果はとにかく褒め、取り組みはチーム一丸となって 個人の成果はどんな小さなことでもとにかく褒めていただけます！ 何より否定されることがほとんどありません。（少なくとも今の所ありません笑） どんな小さなことであっても成果や頑張りはチーム内などで共有があり、その度にみんなが褒めてくれるので、単純な僕としては非常にやる気がでます笑 また、何か取り組むときは「一緒にやるから声かけてね！」とチームの方が言ってくださるので、スムーズに作業を進めやすいです！ 僕の感じる課題点 良いこともありますが、当然課題と感じる点もございます。 個人の中に存在するエンジニアとしての気持ちとチームとしての気持ちの向きを揃えたい 気持ちの向きを揃えたいというのは、開発における挑戦と安心を両立させていきたいということです。 下記の図のような状況が気持ちの向きが揃っていない状況です。 個人をチームの一員として考えると、「サービスをどんどん盛り上げていきたい！いろんな改善や開発をしていこう！！」という前向きな気持ちが大きいです。 しかし、個人をエンジニアとしてみると「開発や改修を進めたいけど、どこでバグが起きるかわからない。リファクタリングしたいけど、影響範囲がわからないから悩んでる・・・」みたいな状況も感じ取れます。 このように、切り口によって気持ちの向きが異なると、葛藤が発生してしまい、新しいアクションがしづらい状況となってしまいます。 僕が入社した一番の目的は、まずはこの点の改善かなと思ってます。入社前より、弊社のエンジニアとのカジュアル面談を綿密に行うことで、この辺りはすでに感じておりました。 また、僕は親友によるリファラル入社なのですが、その方伝いにも似たようなお話や現状を伺っていたので、まずはこの辺りを改善し、下記の状況を作っていきたいです。 先にも記述した通り、弊社の皆様優しいので、何かしらの信念を持って行動すれば共感していただけます。 このような素晴らしい人格をお持ちの方が多い会社なので、なんとしてでもこの辺りを解決していきたいですね。 チャレンジしたこと おのぽんの部屋開設 ひょんなことから、弊社のエンジニアがFat Controllerに悩んでいることを知り、ペアプロをやることになったことがありました。 このタイミングで、僕が経験・学んできたことを共有しながら1つのコードをリファクタしていっていたのですが、当事者のエンジニアは学ぶことが多かったらしく「ひょっとしたらこういった知識を知りたい若手のエンジニアは他にもいるのだろうか？」と感じました。 また、先にも記述した自身の感じる課題点を解消したいという気持ちと、もっと他に取り組むべきことがあるのであれば率先して解決していきたいという気持ちもあり、部署内外問わず色々なエンジニアと交流したいなと思っておりました。 この自然に発生した取り組みが弊社技術推進委員会の目に止まり、「ぜひ今後もやって欲しい」というお言葉をいただいたので、下記図のような「おのぽんの部屋」という誰でも参加していただける交流スペース（会議枠）を社内で公式に作ることができました！ 「おのぽんの部屋やろう！」というお話から、わずか2営業日で公開、そして翌週には実施というスピード感のある動きができたことも大変感謝しております。 参考までに僕の技術stackですが、 #php, #ruby, #python, #kotlin, #java, #CSS, #javascript, #unittest, #Bootstrap, #jQuery, #line_bot, #line_notify, #MySQL, #Cache, #Redis, #AWS, #terraform, #docker, #jenkins, #CircleCI, #GithubActions, #Git, #Github, #vim, #コンフリクト, #リファクタリング, #コードリーディング, #テーブル設計, #テーブルの正規化, #ペアプロ, #DeepLearning, #スクラム開発 と、色んなことに幅広く取り組んだ経験があります。 この辺りの経験のなかで、興味のありそうなことに引っかかる方がいらっしゃればいいなぁというお気持ちでした！ 実際にやってみた結果 エンジニア 7名 デザイナー 1名 ディレクター 1名 の方にご訪問いただけました！すごい！！ 実施内容としては、 テストコードの導入方法や考え方 エンジニアの市場価値について セッションを使うとき・使うべきでないとき 信頼してもらえるエンジニアになるためには（新卒1年目） 働き方やコミュニケーションの取り方（新卒2年目） ペアプロ 人工知能の導入に関するお話 と、多岐に渡る技術のお話・実践、中には人生相談のようなものもありました！笑 「おのぽんの部屋」を開催することで、さまざまなエンジニアの方と交流も深められましたし、少しずつ僕のナレッジも還元することができていて、非常に喜ばしい状況になっているかと思います^^ 人工知能を活用したクチコミ審査補助ツールの提案 Photoraitでは、ユーザよりご記載いただいたクチコミを公開しておりますが、毎回必ずクチコミの審査を行うフローがあります。審査のルールは数多くあるようで、中でも記載カテゴリの誤り（例えば、衣装にまつわるコメント欄の内容がコスパ欄に書くべき内容になってしまっていたり）による差し戻しが多いというお話を雑談ベースで聞いてました。 クチコミも数万件あるとのことだったので、「じゃあ人工知能モデル作って学習させてクチコミのカテゴリ分類器を作ってみよう」とプロトタイプを作ってみました。       構想から作成まで1週間くらいで開発し、精度87%くらいの分類器ができあがりました。 試しにプロトタイプを作ったというところなので、精度が93,4%になったら、ユーザさんのクチコミを手助けできるツールとして本格実装できそうです！ 営業やディレクターに向けた人工知能のナレッジ共有 先のプロトタイプのお話をしたところ、人工知能ってどんなものなのかを知らなさそうな方が多い印象を受けました。 業界に何かしらのイノベーションを起こすのに、新しい技術はつきものだと考えます。 どの技術においても、一体何ができるものなのか、どういうものなのかわからない。 わからないから提案できない。使えない。そもそも使おうという発想に至らない。 このような状況は非常にもったいないと考えます。 なので、これを機に、まずは人工知能というものがどんなものなのかを知っていただこうと考え、人工知能ナレッジ共有をしました。 実施後内容 座学を紹介しつつ、双子の芸能人を交互に見せながら見分けていただきながら、人工知能（今回はその中でもDeepLearning）の一般的な学習・テスト方法を疑似体験の場を作り、非エンジニアの方でも理解が深めやすい工夫・取り組みをしました。 反響 わかりやすかった 人工知能との心の距離が縮まった 人工知能の認識の違いに気づけた これからも職種の違いによる知らないをなくし、知ることを当たり前にしていきたい Photoraitでも今後活用していきたい と言った感想をいただきました！ 早速チーム内のディレクターより「こういうことDeepLearningを使ってできない？」というご提案もいただけ、早速ネクストアクションにつながっております！ もちろんご提案の場は「おのぽんの部屋」でした！ 他にも色んな取り組みやチャレンジをこの3ヶ月の間に行うことができ、会社の方針に馴染みながらやりたいことを自由にできていて毎日楽しく働いております！ 弊社では、一緒に働いていただけるエンジニアも募集しております！ 新しい環境でエンジニアとしてさまざまな技術に取り組んでいきたいという気持ちはもちろん 目標達成や事業の成長を一緒に感じたい チーム貢献 に尽力できて、またその成果も評価してほしい 自由に企画・提案 しながら社内にアクションを起こしたい という方がいらっしゃいましたら、是非一度弊社社員とお話させてください！ 最後までお読みいただきありがとうございました！！

こんにちは。新卒1年目エンジニアのririです。 この記事では、5月から約2ヶ月間取り組んだ新卒合同開発の設計・開発フェーズについてお話しします。新卒合同開発については、 企画・仕様フェーズについて書いた記事 で触れているので、今回は割愛します。同じように設計・開発に取り組む方々の参考になれば幸いです。 目次 設計で学んだこと 開発で学んだこと 成長ポイント まとめ 設計で学んだこと 仕様書の内容をどのように実現するか？という詳細設計を、システム設計書に落とし込みました。 1. 設計書づくり 設計書を作成するにあたり、どのような項目・粒度で書くべきか迷いました。今回は新規開発ということもあり開発する画面の数が多かったため、特に説明のしやすさ・理解のしやすさを重視して資料作成しました。盛り込んだのは以下の項目です。 機能： 機能の名称と説明 画面 ：その画面のURL 開発内容 ：実装手順を大まかに示す 仕様・実装方針 ：開発内容の詳細手順や実装方法、処理条件など 画面イメージ ：画面のプロトタイプを表示（同じ資料内で説明を完結させる） また、テーブル設計書にはテーブル・カラム名を記した表だけでなく、ER図も入れました。今回は同期のエンジニアと2人で開発を行ったため、実装方針や処理の流れを確認する度に設計書を参照する機会が多く、最初にこだわって作成してよかったです。 mermaid.js (Copyright (c) 2014 – 2022 Knut Sveidqvist)を使って作成したER図 2. ユーザーにとって良い設計になっているか？ 最初の設計レビューでは、 ユーザーが違和感なく使える想定の設計になっているか？ を考慮しきれておらず、ご指摘いただきました。ページ遷移するのも何らかの処理を行うのも、ユーザーのアクションが起点になります。予想を裏切るようなページ遷移・処理は避け、ユーザーが快適にサービスを使えるように設計する必要性を学びました。この経験から、 単に仕様を実現するのではなく、仕様をユーザーが使いやすい形に落とし込む ことも設計の役割だと気づきました。 3. 開発タスクの網羅性 設計時、開発のためのタスク洗い出しが不十分だったことは、大きな反省点の１つです。そのため工数見積りが正確ではなく、開発スケジュールを都度修正しながら進めることになりました。この部分は経験を重ねることで学習していく部分でもあると思うので、もし私が開発前に戻ったら以下の工夫を行いたいです。 まず大まかな設計書でエンジニア同士の 認識を合わせる 担当している 開発箇所のタスク(実装完了までやるべきこと)を洗い出す 2が妥当かどうか、 先輩エンジニアに壁打ちをお願い する バリデーションや入力条件が複雑な部分は、プログラム構造設計まで考えてみる  4に関しても、 迷ったら先輩エンジニアに相談 する （先輩エンジニアに相談中） 開発で学んだこと 私は社員が自分のプロフィールを編集することができるプロフィール編集画面のフロントエンド・バックエンドを担当しました。 1. 条件の複雑さ 編集画面を開発するにあたり、条件の考慮とそれに対応する処理を考えることが一番厄介でした。開発を進める中で考えながら実装していったため、仕様の確認漏れも多々あり、テストで修正が入る事態となりました。仕様または設計を決める段階でバリデーション項目や複雑な入力・処理条件をしっかり検討するべきだと実感しました。 2. UI・UXとのバッティング せっかく上流工程から共同しているのに、デザインと処理のすり合わせを積極的に行えていなかったことが反省点としてあります。その結果、実装中にデザイナーと相談しながら開発することとなり、検討漏れによって後々意図しない挙動に悩まされました。 デザインのプロトタイプが完成した時点でエンジニアは実装イメージを持ち、それがデザイナーの意図と合っているか議論 するべきだと学びました。 成長ポイント 1. コードを広い視点で見つめ直す バグ発生→修正→動作確認→また違う部分でバグ発生 、ということが3回ほどありました・・・。修正箇所が判明した時、まずは該当コードを変えることで影響範囲はないか？をじっくり考えることが必要だと思いました。影響範囲に応じて再テストする項目も変わります。その部分だけを直し、その部分だけをテストする、だけでは良くないと実感しました。 実は今でも自分が開発したシステムを触るときドキドキするし、想定しない動作をする瞬間が結構トラウマです。逆に言えば、設計においても開発においても「一度冷静になって影響範囲を考えるべき」という経験則ができました。 2. 実際に使う人がいる、運用され続ける、というプレッシャー 今まで数百人規模で使われることを想定したシステムを作ったことがなかったため、実際に使う人がいる…という緊張感は開発後半になるにつれ高まっていきました。 自分の開発箇所は自分が責任を持ってクオリティを担保する 、という意識を持って開発できた点では、非常に成長できたと思います！ 現在は「使いやすい！」「見るの楽しい！」と言ったお声を社員の方々からいただき、加えて社内コミュニケーションの広がりも感じており、非常に嬉しいです！ 3. 報告・連携・相談の大切さ 今回の新卒合同開発を通して、より良いものを作るには報告・連携・相談が必要不可欠であることを実感しました。先輩方からアドバイスいただき、進捗報告頻度や相談事の共有方法などを改善したことで、問題が起こったときも冷静に対処することができました。 その結果、お互いがピンチのときに役割を分担して巻き取るなど、立ち回りの面で非常に成長できたと思います。 まとめ 企画から開発まで、自由度が高い分難しさはあったのですが、非常に学びが多く、とても楽しい研修でした！ 新卒合同開発研修を用意・サポートしていただいた先輩の記事 も公開されておりますので、こちらもぜひ読んでみてください！ 難しいことも、不安も、 仲間や先輩方のおかげでなんとか乗り越え、社内サービスとして無事リリース することができ、感無量です！また、新卒クリエイターチームで一つのものを作り上げたことは、自分の誇れる経験となりました！ これからの実案件でも、研修で学んだことを活かして精進していきます！

こんにちは。新卒１年目エンジニアのtakadaです。 4月に新卒として入社してから約4ヶ月間の研修があり、 その中で5月末から7月末までの約2ヶ月間を チーム開発研修 として取り組みました。 チーム開発研修では、企画から仕様、設計、開発、リリースまでを一気通貫して同期のエンジニア・デザイナーと取り組んでいきました。 この記事では、初のチーム開発を終えて設計と開発で学んだことを主にお話ししていきたいと思います。 企画〜仕様までの学びを同期のエンジニアが こちら に書いてくれています。気になる方はぜひご覧ください。 目次 チーム開発概要 設計 開発 まとめ 1. チーム開発概要 改めて、チーム開発でどのような事に取り組んできたのかを簡単にお話し致します！ チーム開発では僕を含めて エンジニア2人 と デザイナー1人 の計3人で進めていきました。 そしてそのチーム開発の内容は、 「googleスライドで管理されていた社員プロフィール情報のシステム化」 です 取り組んだ背景として、社員のプロフィールがgoogleスライドで管理されていた事から、読み込むのに時間が掛かることや見たい社員のプロフィールまでたどり着くのに部署ごとに管理をしているため一苦労であるという課題がありました…。 システム化することでこれらの課題を解決し、それに加えて社員のプロフィール検索機能を実装するなど、 「心の距離を近づけるツール」 をコンセプトにチーム開発に取り組んでいきました！ サービス名は「プロフっちょ」！僕たちが小中学生のときに流行ったプロフ帳が由来です。プロフ帳を交換したり、友達が書いてくれたプロフィールを読んだりという楽しさを、このサービスでも感じて欲しいという思いを込めています。 2. 設計 では、早速ではありますが「プロフっちょ」の開発に入る上で重要な 設計 で学んだことを3つお話ししたいと思います！ ① 役割分担は慎重に！タスクからしっかり見極める！ まず1つ目は、 「役割分担は慎重に！タスクからしっかり見極める！」 です。 今回の設計において、主に取り組んだことはテーブル設計とページ遷移の際のフローチャート、システム構成図の3つでした。 エンジニアとして僕含めて2人いる中で、 「テーブル設計」 と 「ページ遷移の際のフローチャートとシステム構成図」 の2つに役割分担をして取り組んでいきました。僕が担当したのは後者です。 しかし、「テーブル設計」という開発において土台となる箇所を把握し切ることができなかったために後々の開発でエンジニア同士の認識がずれるなどの問題が生じてしまいました。 そのため、 「テーブル設計」などの重要なタスク に関しては、2人で作成をするか認識をすり合わせるために積極的にコミュニケーションを取ることを心がけるなど、MUSTのタスクに対してどのようなアプローチを取るべきなのかを見極めることが重要であることを学びました！ ② 設計レビューのイメージは関門より議論！ 2つ目は、 「設計レビューのイメージは関門より議論」 です！ 前提として弊社は、設計から開発に入るためには設計書の作成を行い、設計レビューを先輩にして頂いて OK をもらう必要があります。 そんな中で、僕自身が早く開発に入りたいという気持ちが強くあったために 「質の良い設計書を作る！」 というよりは 「設計レビューを通す！」 という方に気持ちが向いてしまっていました…。 開発をスムーズにできるようにするためには、設計書の作成をより入念にする必要があります。そのため、設計レビューをして頂く際はレビューを通すというよりも設計書のレビュワーと密にコミュニケーションをとり、 「開発をスムーズにできる最高の設計書を作る！」 という方向に気持ちが向いていなければなりません。 それを理解できていなかったために、設計レビューのレビュワーから OK を頂いて開発に入った際に同期のエンジニア同士で設計に認識のズレなどがあり躓いてしまう事が多々ありました。 この経験から上記の図のように設計レビューではレビュワーと「戦う」というイメージよりも 「最高の設計書を作る」 ために「議論」するイメージを持つ必要であるということを学ぶ事ができました。 ③ 工数見積もりはより具体的に！！ 最後は「工数見積もり」に関してです！実はこの工数見積もりが今回僕が1番躓いてしまった箇所となっております。 設計書作成において開発をするために 「どのような実装をするべきか？」 などの実装方法を同期のエンジニアと考えて作成していきました。 その実装方法から工数の見積もりをしていきましたが、その実装方法の粒度が開発をスムーズにできる段階まで細かくできていなかったために開発に入った際に全く工数の通りにいかないといった問題が生じてしまいました…。 また、具体的な実装方法が分かったとしても自分の「過信」や「早く終わらせなきゃ」という気持ちから時間の見積もりを思ったよりも短くしてしまっていました。そして、実際に開発に入った際に工数の通りに行かず、遅れてしまうと言うことに繋がってしまいました。 時間の見積りに対して遅れてしまうことは、チームメンバーだけでなくサポートして下さっている周りの先輩社員にも影響が出てしまいます。今回のチーム開発から視野を広く持ちながら 自分の力量を把握して 時間の見積もりをする重要性を学ぶことができました。 3. 開発 次に開発について学んだ事を3つお話し致します。 ① 15分考えて分からなかったら即相談！！ まず一つ目は 「15分考えて分からなかったら即相談」 です。 設計書の作成が終わって開発に入った際に、エラーが発生したり上手く実装できなかったりするなど、壁にぶつかることが多々ありました。 開発をしていればこれらの事象は必ず起こり得ることですが、それに対してのアプローチ方法がすごく重要であることを今回のチーム開発研修で学ぶ事ができました。 言葉の通りですが、開発で躓いた際は15分などの時間を決めて調査を行い、解決できない場合はすぐに先輩に質問する事が重要です。 時間を決めないと、沼にハマって1人で考え過ぎてしまい時間を無駄にしてしまいます。チームで開発を行なっているため、時間を無駄にしてしまうとチームにも迷惑をかけてしまいます。 しかし、すぐに質問をしようとすると先輩の時間を無駄に奪ってしまう可能性や調べて解決する力もつきません。そのため、15分は必ず考えることが重要です。そして、15分以上は自分の時間を無駄にしてしまう可能性があるため、すぐに質問する事が重要であるということを学ぶことができました。 この方法はGoogleでも採用されているルールでもあるので、興味がある方は是非調べて頂けたらと思います！ ②  チームを考えて判断・行動をする。 2つ目は、 「チームを考えて判断・行動をする。」 です！ 一見当たり前の事ですが、実際に開発に入ってみるとチームを考えた行動ができてない事が多くありました…。 その大きな原因は、今までチームで考えてきた企画や仕様、設計と違って開発は担当部分が決まれば個人で行うようになるためだと考えられます。 開発の前半で、僕の担当部分の開発が予定よりかなり遅れている状況になる事がありました。その際にチームに助けを求める事を遠慮してできず、1人で巻き返そうとしてしまい、辛く感じてしまう事が多々ありました。 もちろん、1人で巻き返そうという気持ちや努力はすごく重要ですが、チームに助けてもらう事でより早く効率的に巻き返す事ができる可能性もあります。そのため、 チームのために 助けを求めることも必要であると学ぶ事ができました。 またその逆も然りで、自分自身の開発が予定より進んでいたり、スケジュールに余裕があったりする場合はチームのタスクを自ら進んで巻き取ることも重要です。 そのためには、自分の担当部分の開発進捗だけでなくチーム全体の進捗状況を把握するなど視野を広く保つ必要があります。チーム開発ならではの経験であり、とても良い学びになりました。 ③ コンセプトを常に考えて開発する！ 最後の3つ目は 「コンセプトを常に考えて開発する！」 です。 今回のチーム開発では、「心の距離を近づけるツール」というコンセプトを元に 「googleスライドで管理されていた社員プロフィール情報のシステム化」 に取り組んでいきました。 しかし、企画〜リリースまでの約2ヶ月間という長い期間でコンセプトを忘れてしまいそうになる時がありました。企画〜リリースをするにあたって優先順位などを決めて行動するなど何かを判断する場面が必ず多く訪れると思います。 特に開発においては、進捗状況によって 「どの機能を削除するか？」「どの機能を優先的に開発するべきか？」 を判断する場面が必ず出てくると思います。実際に今回の開発でもこのような場面が多々出てきました。 その際に 「心の距離を近づけるツール」 というコンセプトを軸に考えることで「MUSTで開発する機能」と「+αで開発する機能」に分けて優先順位を立てることができ、開発する意義からブレずにリリースまでする事ができました。 チーム開発当初はコンセプトがそこまで重要である事を理解できていませんでしたが、チーム開発を経験してコンセプトを常に考えて取り組む重要性を学ぶ事ができました。 4. まとめ 初のチーム開発を企画からリリースまでを一気通貫して取り組んだことによって、学生時代に行なってきた個人開発では経験できない多くの事を経験する事ができました。 特に企画書・設計書の作成などに関しては、初めて取り組んだということもあって不安ではありましたが同期のメンバーと試行錯誤しながらも完成させる事ができ、大きな自信になる事ができました。 チーム開発研修が終わって本格的に業務に取り組み始めていますが、チーム開発での経験がすごく活きていると実感しており「やって良かった！」と感じております。。今回のチーム開発での経験を大きな自信にして、これから多くの事に挑戦していきたいと思います。最後まで見て頂きありがとうございました