こんにちは、sugoです。 今回は、Laravelのクエリビルダの学習したいと思い、私が行った学習方法についてまとめたいと思います。 どのように学習しようかと考えた際に、ChatGPTを活用して学習を行いました。 SQL文は書けるが、Laravelのクエリビルダの理解があまりできていないという方に、少しでも参考になればと思います。 背景 まずは、なぜクエリビルダの学習をしようと思ったのか、その背景を説明します。 私は現在、PHPのフレームワークであるLaravelを使用しています。 しかし、Laravelでのデータ取得処理については、クエリビルダかEloquentかを選ぶ段階で、調べないと読み書きできないレベルでした。 そこで、Laravelでのデータ取得に関する処理をもっと理解し、学びを増やすため、私はこの学習を始め、今回の記事を書くことにしました。 また、近年ChatGPTが話題になっていることから、ChatGPTを活用して、何かしたいという考えから、ChatGPTを活用した学習をすることにしました。 学習方法 ChatGPTにSQL文を作成してもらい、そのSQL文をLaravelのクエリビルダに書き直していくという方法で学習を進めました。 以下が学習の流れです。 ChatGPTにいくつかの条件をつけたSQL文を作成してもらう。 そのSQL文をLaravelのクエリビルダに書きかえて、学習を進める。 Laravelのクエリビルダに関するドキュメントを参考にしながら、クエリビルダに書きかえていく。 デバッグを用いて、問題のSQL文と一致するか確認。 ChatGPTが作成したSQL文 顧客情報、注文情報、商品情報、支払い情報、および配送情報を含む5つのテーブルをJOINし、特定の条件で結果をフィルタリングします。さらに、サブクエリを使用して、特定の条件を持つ顧客の支払い総額を計算します。 SELECT c.customer_id, c.customer_name, o.order_id, o.order_date, p.product_name, p.product_price, s.payment_method, s.total_amount, d.shipping_address FROM customers c JOIN orders o ON c.customer_id = o.customer_id JOIN order_details od ON o.order_id = od.order_id JOIN products p ON od.product_id = p.product_id JOIN payments s ON o.order_id = s.order_id JOIN shipments d ON o.order_id = d.order_id WHERE c.customer_region = 'Asia' AND p.product_category = 'Electronics' AND o.order_date >= '2024-01-01' AND o.order_date <= '2024-05-01' AND s.total_amount > ( SELECT AVG(total_amount) FROM payments WHERE payment_method = 'Credit Card' ); クエリビルダに変換 上記で作成されたSQL文を、クエリビルダに変換すると以下のようになります。 Laravelのクエリビルダについてまとめられているサイトを参考に変換を行いました。 $paymentsAvg = DB::table('payments') ->where('payment_method', 'Credit Card') ->avg('total_amount'); $query = DB::table('customers as c') ->select( 'c.customer_id', 'c.customer_name', 'o.order_id', 'o.order_date', 'p.product_name', 'p.product_price', 's.payment_method', 's.total_amount', 'd.shipping_address' ) ->join('orders as o', 'c.customer_id', '=', 'o.customer_id') ->join('order_details as od', 'o.order_id', '=', 'od.order_id') ->join('products as p', 'od.product_id', '=', 'p.product_id') ->join('payments as s', 'o.order_id', '=', 's.order_id') ->join('shipments as d', 'o.order_id', '=', 'd.order_id') ->where('c.customer_region', 'Asia') ->where('p.product_category', 'Electronics') ->whereBetween('o.order_date', ['2024-01-01', '2024-05-01']) ->where('s.total_amount', '>', $paymentsAvg) ->get(); 変換後のクエリビルダが、ChatGPTに作成してもらったSQL文と同様か確認を行います。 ddRawSql メソッドを用いてデバッグを行い、実行されるSQL文を表示し確認を行います。 デバッグ結果は以下のようになりました。 select `c`.`customer_id`, `c`.`customer_name`, `o`.`order_id`, `o`.`order_date`, `p`.`product_name`, `p`.`product_price`, `s`.`payment_method`, `s`.`total_amount`, `d`.`shipping_address` from `customers` as `c` inner join `orders` as `o` on `c`.`customer_id` = `o`.`customer_id` inner join `order_details` as `od` on `o`.`order_id` = `od`.`order_id` inner join `products` as `p` on `od`.`product_id` = `p`.`product_id` inner join `payments` as `s` on `o`.`order_id` = `s`.`order_id` inner join `shipments` as `d` on `o`.`order_id` = `d`.`order_id` where `c`.`customer_region` = 'Asia' and `p`.`product_category` = 'Electronics' and `o`.`order_date` >= '2024-01-01' and `o`.`order_date` <= '2024-05-01' and `s`.`total_amount` > '1425.000000' このことから、作成したいSQL文と同じクエリビルダを作成できました。 以下からは、SQL文をクエリビルダに変換し、上記のクエリビルダに辿り着くまでの学びを挙げていきます。 エイリアスについて クエリビルダだとエイリアスの指定ができないと思っていたのですが、簡単に書けることを学びました。 カラム名 as エイリアスで書くだけで簡単だったので、今後クエリビルダを使う際は、エイリアスの利用も考えて使っていきたいと思います。 今回のSQLは、SELECT文やJOINすることが多かったので、かなり書く内容を減らすことができ重宝しました。 サブクエリについて 今回のSQLは、サブクエリを用いていたのですが、クエリビルダに変換する際は、一度サブクエリのSQLを実行し、取得した値を変数として渡して実行しました。 バックエンドで実行する際は、2回実行しても返す値は変わらないので、今回は2回に分けて実行しました。 いつもサブクエリが出るとあまり理解できていなかったのですが、今回のように2回に分けるイメージで考えると、簡単に理解できそうです。 whereでクロージャを用いれば以下のように一回で書くこともできます。 ->where('s.total_amount', '>', function ($query) { $query->selectRaw('AVG(total_amount)') ->from('payments') ->whereRaw('payment_method = "Credit Card"'); }) まとめ 今回はChatGPTを使ってLaravelのクエリビルダの学習を行いました。 実際にSQL文をクエリビルダに変換することで、いままでなんとなく書いていた部分の理解が深まりました。 またAIを活用することで、学習時間を大幅に短縮できました。 最後までお読みいただきありがとうございました。 The post Laravelのクエリビルダの勉強をするために、ChatGPTを使って学習してみた first appeared on Wedding Park CREATORS Blog .

初めまして！新卒1年目エンジニアのよこちです。 新卒研修にて自己紹介サイトを作る機会があったので、その際に使用した技術についてまとめてみました！   目次 自己紹介 自己紹介サイト Three.jsの基本的な使い方 立方体（3Dオブジェクト）の描画 DOM要素を3D空間に配置   自己紹介 新卒エンジニアとして4月に入社しました。 情報系出身ではありませんが、プログラミングスクールのメンターアルバイトをやりながら1年半ほどプログラミングを学んでいました！新しいことを学び始めるときに一番ワクワクする人間です。どうぞよろしくお願いいたします。 自己紹介サイト 新卒研修で作成した自己紹介サイトでは、サイト上に立方体を描画して、各面を押すと自分の趣味や学生時代の情報がモーダル表示されるような機能をつけました。この機能をつけようと思った理由としては、「自分の情報をたくさん伝えたい」、「情報過多は避けたい」という2つの思いがあり、自分の情報の詰まったものをユーザーが任意で開けられるようにしようと考えたからです。あと、「ごきげんよう」という番組のサイコロを転がすシーンが好きだったので、サイコロがよぎりました。   実際に表示させた3Dオブジェクト   使用したのは、手軽に3Dコンテンツを作成・表示・操作できるJavaScriptライブラリの Three.js です。 本投稿で紹介させていただくことは以下の通りです。 Three.jsの基本的な使い方 立方体（3Dオブジェクト）の描画 サイト内で3Dモデルなどを利用しようと考えている方の参考になれば嬉しいです。   Three.jsの基本的な使い方 導入 npmパッケージをinstallするか、以下のようにHTMLファイル内の <head></head> タグ内にCDNからのインポートを記述します。 <script type="importmap"> { "imports": { "three": "https://cdn.jsdelivr.net/npm/three@v0.149.0/build/three.module.js", "three/addons/": "https://cdn.jsdelivr.net/npm/three@v0.149.0/examples/jsm/" } } </script> 次に<body></body>タグ内に以下のように記述し、Three.jsを使える環境にしたら準備完了です。 <body> <div id="3d_space"></div> <script type="module"> import * as THREE from 'three'; </script> </body>   Three.jsでオブジェクトを描画させるには 大まかに以下の準備が必要です。 シーンの作成 3Dオブジェクトを表示するための空間を作成します  レンダラーの作成 WebGL（）をレンダリングするためのものです  カメラの作成 3D空間を見る視点を決めます メッシュの作成 自分の表示させたいオブジェクトを作成するために必要なものです  ライトの作成 シーンを照らすライトの位置や明るさの設定をします  アニメーションの設定 3Dオブジェクトをどのように動かすかを決めます 実際に立方体を表示させる過程で確認していきましょう。   立方体（3Dオブジェクト）の描画 シーンの作成 const scene = new THREE.Scene(); レンダラーの作成 レンダリング領域の大きさの他に背景の色なども設定できます。指定したDOM要素に対して子要素にcanvas領域を作成しレンダラーを追加します。 const renderer = new THREE.WebGLRenderer(); // レンダリングする領域の大きさを指定 renderer.setSize(window.innerWidth, window.innerHeight); // canvas領域にレンダラーを追加 document.getElementById('cube').appendChild(renderer.domElement); カメラの作成 今回はPerspectiveCameraを使用し、第1引数では視野角、第2引数では画面のアスペクト比を指定します。第3,4引数ではカメラから見て一定距離区間の間に存在するオブジェクトだけをレンダリングするクリッピング機能のためのプロパティに値を指定します。そしてposition.setではカメラの位置を定めます。 // カメラを作成 const camera = new THREE.PerspectiveCamera( 45, window.innerWidth / window.innerHeight, 1, 10000 ); // カメラの位置を指定 camera.position.set(0, 0, 2000); メッシュの作成 メッシュの作成にはジオメトリとマテリアルの作成が必要です。ジオメトリは立方体（BoxGeometory）を指定し大きさを決めます。マテリアルはジオメトリの表面の材質などを指定できます。これらを用いてメッシュを作成し、シーンに追加します。 // ジオメトリを作成 const geometry = new THREE.BoxGeometry(500, 500, 500); // マテリアルを作成 const material = new THREE.MeshStandardMaterial({ color: 0x0000ff }); // メッシュを作成 const box = new THREE.Mesh(geometry, material); // シーンに追加 scene.add(box); ライトの作成 今回はDirectionalLightで並行光源を再現し、引数で光の色や強さを指定できます。ライトの位置を指定してシーンに追加します。 // ライトを作成 const light = new THREE.DirectionalLight(0xffffff); // 光の強さを2倍にする light.intensity = 2; // ライトの位置を指定 light.position.set(1, 1, 1); // シーンに追加 scene.add(light); アニメーション requestAnimationFrameで画面のフレームが切り替わるたびにアニメーション関数（roll）を実行しスムーズなアニメーションを実現させます。アニメーション関数（roll）によりフレーム毎に3Dオブジェクトの位置とカメラの映像が変わるので、sceneとcameraのレンダリングを行います。 roll(); function roll() { requestAnimationFrame(roll); // 箱を回転させる box.rotation.x += 0.01; box.rotation.y += 0.01; // レンダリング renderer.render(scene, camera); }   以下が立方体を表示させるための全コードです。 <body> <div id="cube"></div> <script type="module"> import * as THREE from 'three'; // シーンの作成 const scene = new THREE.Scene(); //レンダラーの設定 const renderer = new THREE.WebGLRenderer(); renderer.setSize(window.innerWidth, window.innerHeight); document.getElementById('cube').appendChild(renderer.domElement); // カメラを作成 const camera = new THREE.PerspectiveCamera( 30, window.innerWidth / window.innerHeight, 1, 10000 ); camera.position.set(0, 0, 2000); // 立方体を作成 const geometry = new THREE.BoxGeometry(500, 500, 500); const material = new THREE.MeshStandardMaterial({ color: 0x0000ff }); const box = new THREE.Mesh(geometry, material); scene.add(box); const light = new THREE.DirectionalLight(0xffffff); light.intensity = 2; light.position.set(1, 1, 1); // シーンに追加 scene.add(light); renderer.render(scene, camera); roll(); function roll() { requestAnimationFrame(roll); // 箱を回転させる box.rotation.x += 0.01; box.rotation.y += 0.01; // レンダリング renderer.render(scene, camera); } </script> </body> 実行結果がこちらになります。 立方体の描画はこれにて完了です。 ですが、立方体の各面に対して文字やボタンなどが含まれるDOM要素を配置するには、上記の内容とは少し異なる手法が必要になります。以下の「DOM要素を3D空間に配置」でその方法を説明します。   DOM要素を3D空間に配置 DOM要素を配置するには以下のような準備が必要です。 シーンの作成 レンダラーの作成 カメラの作成 メッシュの作成 CSS3Dオブジェクトの作成 アニメーションの設定 Three.jsが用意してくれている立方体や球体の3Dオブジェクトを描画する時とほとんど準備するものは一緒です。しかし、レンダラーの作成とCSS3Dオブジェクトの作成に関しては3Dオブジェクトの描画とは異なるので説明させていただきます。   導入 3D空間に配置するDOM要素をHTML内で記述します。 また、CSS3DObjectとCSS3DRendererはDOM要素を操作する上で必要になるので<script></script>内に以下のように追記し、importします。 <body> <div id="sample"></div> <div id="domElement"> <div class="surface"> DOM要素 </div> </div> <script type="module"> import * as THREE from 'three'; import {CSS3DObject, CSS3DRenderer} from "three/addons/renderers/CSS3DRenderer.js"; // 追記 </script> </body> レンダラーの作成 WebGLRendererではなくCSS3DRendererからレンダラーを作成します。 import {CSS3DObject, CSS3DRenderer} from "three/addons/renderers/CSS3DRenderer.js"; ・・・ // CSS3DRendererからレンダラーを作成 const cssRenderer = new CSS3DRenderer(); cssRenderer.setSize(window.innerWidth, window.innerHeight); document.getElementById('sample').appendChild(cssRenderer.domElement); CSS3Dオブジェクトを作成 まず、HTML内に用意したDOM要素を変数に格納し、必要なCSSを付与します。CSSに関しては、CSSファイル内に記述していても問題ありません。DOM要素が格納された変数からCSS3Dオブジェクトを作成し、立方体の面の位置に来るように位置設定をします。そしてシーンに追加するのではなく立方体オブジェクトにCSS3Dオブジェクトを追加（add）することで立方体に対してアニメーションを付与した時に動きを同期してくれます。 const domElement = document.getElementById("domElement"); domElement.style.backgroundColor = 'rgba(0, 200, 255, 0.5)'; domElement.style.width = '500px'; domElement.style.height = '500px'; domElement.style.fontSize = '4vh'; domElement.style.border = 'solid'; domElement.style.textAlign = 'center'; d omElement.style.lineHeight = '500px'; // CSS3Dオブジェクトを作成 const cssObject = new CSS3DObject(domElement); // 立方体の面に配置 cssObject.position.set(0, 0, 250); // 立方体にオブジェクトを追加 box.add(cssObject); 以下がDOM要素を立方体の面に配置するための全コードです。 <body> <div id="sample"></div> <div id="domElement"> <div class="surface"> DOM要素 </div> </div> <script type="module"> import * as THREE from 'three'; import {CSS3DObject, CSS3DRenderer} from "three/addons/renderers/CSS3DRenderer.js"; // シーンの作成 const scene = new THREE.Scene(); // レンダラーの設定 const cssRenderer = new CSS3DRenderer(); cssRenderer.setSize(window.innerWidth, window.innerHeight); document.getElementById('sample').appendChild(cssRenderer.domElement); // カメラを作成 const camera = new THREE.PerspectiveCamera( 45, window.innerWidth / window.innerHeight, 1, 10000 ); camera.position.set(0, 0, 2000); // 立方体を作成 const geometry = new THREE.BoxGeometry(500, 500, 500); const material = new THREE.MeshStandardMaterial({ color: 0x0000ff }); const box = new THREE.Mesh(geometry, material); scene.add(box); 　　　　　　　　　　　　　　　　// DOM要素を取得しCSSを適応 const domElement = document.getElementById("domElement"); domElement.style.backgroundColor = 'rgba(0, 200, 255, 0.5)'; domElement.style.width = '500px'; domElement.style.height = '500px'; domElement.style.fontSize = '4vh'; domElement.style.border = 'solid'; domElement.style.textAlign = 'center'; domElement.style.lineHeight = '500px'; 　　　　　　　　　　　　　　　　　// CSS3Dオブジェクトを作成 const cssObject = new CSS3DObject(domElement); cssObject.position.set(0, 0, 250); box.add(cssObject); roll(); // アニメーションの設定 function roll() { requestAnimationFrame(roll); box.rotation.x += 0.01; box.rotation.y += 0.01; cssRenderer.render(scene, camera); } </script> </body> こちらが実行結果になります。CSS3DRendererでは3Dオブジェクトである立方体は可視化できませんが、立方体の動きに沿ってDOM要素が回転している状態です。 同じようなDOM要素を6つ用意して位置関係を考えながら同様の処理を施すと立方体が完成します！ おわりに 3Dオブジェクトを描画するためのライブラリThree.jsについて書かせていただきました。Three.jsを使えば、球体や多面体などのオブジェクトを比較的簡単に作成でき、サイト内を充実させることができます。ぜひ使ってみてください！ また、新しいライブラリに触れると簡単に開発の幅を広げられるなと感じました。とくにJavaScriptにはさまざまなライブラリが豊富にあるので自分に必要であるものを取捨選択しうまく活用していきたいなと思います。   The post Three.jsで3Dオブジェクトを描画してみた first appeared on Wedding Park CREATORS Blog .

こんにちは！さー（ @__south__373 ）です。 3/7〜9に開催されたPHPerKaigi2024に参加してきたので、その参加レポートです！ 初めてPHPerKaigiに参加をして、超楽しいイベントじゃん〜と思っていたところから早1年。 去年は当日スタッフとして参加をさせてもらいましたが、今年はスポンサー枠での登壇とブースでの参加！ いろんな変化があり今年も楽しかった！ 初めてのソロ登壇が決まるまで 大きなイベントでは複数人の登壇を１度だけしていた経験値の中で、スポンサーセッション登壇してみない！？と社内からお声がけをいただきました。 最近めっきり開発することが減っていた中で有益なことが話せるだろうか…と悩みながら年越し。 トークテーマを決めるミーティングでおそるおそる 私「育成の話しってどうですかね… 」 技術広報メンバー「いいじゃん！」 ということでトークテーマが決定しました。 PHPerに役立てばいいんだもんね！！と半ば自分に言い聞かせながら笑 弊社の登壇サポートは手厚い 技術広報メンバー主導でこんな流れで各フェーズでフィードバックをいただけます。 トークテーマ決定 概要作成 骨子作成 資料FIX 全社公開練習 資料FIXまでに社内のエンジニアに発表を聞いてもらってブラッシュアップ。最後には全社向けに発表練習し、話し方などもフィードバックをいただきました。 ありがたい〜 「こんなに具体的に育成の過程を話してもらえるのってなかなかないよね！」 「相互で振り返ってていいね！」 「こんなに色々やってたんだ！」 みたいな声をいただけて、自信がめきめきつきました。感謝。 ついに当日！ 今年は弊社から4人が登壇。ブースを出していたこともあり、たくさん応援に来てくれました！ 初めて紹介してもらえて思わずスクリーン見ちゃってる 育成の話、興味持ってもらえるかな…と心配していたのですが、たくさん聞きに来てくださって感動！ いっぱい！ 憧れていたAsk the Speakerでお話ししたり、懇親会で会話したり、Xでのコメントも盛り上がってて楽しすぎました。 登壇後には、資料の中で登場したふじしーからも連絡が届いていました。ありがとう〜！ お疲れ様でした！最高でした また本番に向けて伝え方ブラッシュアップしてましたね。。流石でした！ ぜひフィードバックもお待ちしてます！ https://fortee.jp/phperkaigi-2024/me/feedback/ced975e3-ba32-4306-8a31-44adde2e775b ブースも大盛況！ 今回は事前に参加メンバーで作戦会議！どんなグッズやコンテンツがあったらウエディングパークのこと知ってもらえそう？？とブレスト。 そこで決定したひとつが靴下！ 履いてきたよ！と見せてくださるのが嬉しすぎました！ みんながウエパ靴下履いてくれている！ #phperkaigi pic.twitter.com/Wtrmooyjuf — WeddingPark CREATORS (@WeddingParkTECH) March 9, 2024 パネルは5枚も用意していたのですが、弊社のオモシロ制度に投票してもらうのが楽しかったですね。 今年も盛り上がり要素がいっぱい 朝ごはんから、おやつ、お酒とずっとなにか食べ物が提供されていた〜！朝ごはんはドーナツいただきました 1Fの展示ルームに軽食がデプロイされました！ 皆さま、是非お立ち寄り下さい #phperkaigi pic.twitter.com/lVSAVyAL4s — PHPerKaigi 2024 @3/7-3/9 (@phperkaigi) March 9, 2024 phperチャレンジすると抽選参加できるやつ！ パンフレットやスポンサーからヒントもらってハッシュタグ探しをするの、宝探し感あって良き。 特賞カステラゲットしました！！！ カステラゲット！ #phperkaigi pic.twitter.com/VrjoANPWAs — さー (@__south__373) March 9, 2024 ことみんさん（ @kotomin_m ）が意気込んでいたネイルもバッチリやっていただきました！かわいい〜！ 元々のネイルの上からやってもらった！ #phperkaigi pic.twitter.com/6kYpvIpuMk — さー (@__south__373) March 9, 2024 今年もLTはライブ会場！これ好きなんだよな〜 最後に これだけの規模のカンファレンスを準備してくださったスタッフの皆様に感謝です！！ 毎年遊び心を加えてくるところが大好き！お疲れ様でした！ PHPerKaigi 2024、無事に終了しました！！ ご参加いただいた皆さま、ありがとうございました！！！ #phperkaigi pic.twitter.com/c043v2aS6v — PHPerKaigi 2024 @3/7-3/9 (@phperkaigi) March 9, 2024 The post PHPerKaigi2024で登壇してきました！ first appeared on Wedding Park CREATORS Blog .

こんにちは。ウエディングパークエンジニアのさー（ @__south__373 ）です。 PHPerKaigi2024にて、「はじめてのメンバー育成。マネージャーとメンバー視点で振り返る1年間」を発表させていただきました。 https://fortee.jp/phperkaigi-2024/proposal/ced975e3-ba32-4306-8a31-44adde2e775b 昨年は当日スタッフとして参加をしたのですが、 とっても楽しい時間だったので今年はスポンサーセッションでの登壇機会をいただいてありがたい限りです…！ さて、この記事では「はじめてのメンバー育成。マネージャーとメンバー視点で振り返る1年間」でお話しした中身というよりも、1年間の奮闘軌跡から振り返って、マネージャーとして大事だなと思うこと、オススメしたい施策について具体的にお伝えしたいと思います！ 一部テンプレートも公開してますので是非参考にしてみてください トークセッションについてはスライドを見ていただけると嬉しいです！ これが大事！ 最初に意識したいこと お互いのことを知る 相談しやすい環境を作る 仕事が進む中で意識したいこと 期待を明確に伝える 頑張りたいことの認識を合わせる 考え方を伝える 課題解決への並走 自分ひとりでなんとかしようとしない それぞれどういうこと？を紐解いていきます。 最初に意識したいこと 1. お互いのことを知る 最初が肝心！ということで、ここは外せないかなと。 仕事を任せていくうえで、どんなスキルセットなのかはもちろん重要ですが、どんな方なのかによってコミュニケーションの取り方も変わってきます。 相手のことを知るだけではなく、自分のことも開示していくことが必要だと思っています。 自己開示が苦手…という方もいると思いますが、そんな時にオススメなのが診断！ 弊社では面白い診断が世に出回るとすぐやる癖があるのですが、みんなの違いがわかりやすく言語化されるので結構助かります。 例えば… エニアグラム ストレングスファインダー モチベーションタイプ MBTI 最近はこんなフォーマットを埋めてきてもらって、お互いに共有する時間を最初に取っています。 ▼テンプレート https://docs.google.com/spreadsheets/d/1XijlF8-iBhD_vFSG0KLHYlBYnOlWm6SHZgC3a8TKCJI/edit#gid=330877079 2. 相談しやすい環境を作る コロナでハイブリッド勤務が急激に加速したと思いますが、弊社は週1回の出社が必須でそれ以外は自由となっています。 新しい環境に入ったとき、相談しやすい環境を作れているかは成長や成果に直結すると思いますので、ハイブリッドでも相談しやすい環境を意識的に作っています。 1on1で週に1回は必ず本人と対話する時間をとります。 Good・Motto・もやっとなどを共有してもらい、特にもやっとの解消には丁寧に時間を使います。 初めの頃は頻度高く、週3〜毎日開催していた時期もありました。 また、タイムリーな相談をしやすくするために専用のslackチャンネルを作成しています。 弊社ではマネージャーがミーティングをしている時間が多く（良いか悪いかはさておき）、「ちょっと今良いですか」が言いづらいこともあるかなと思っています。 なので、とても急ぎではないけれどちょっとわからないなとか確認したいかもということを投稿してもらうチャンネルを作っていて、確認できるタイミングで返答をするというようにしています。 マニュアルのURLを1本送れば済むような時もありますし、口頭での擦り合わせが必要そうだなと感じたらハドルを繋ぐといったように使い分けがしやすいです。 今のチームでは他にエンジニアがいないので1to1のslackになっていますが、チームメンバーが複数いる場合はみんなで情報交換し合う状況にできるとよさそうです。 仕事が進む中で必要になってくること 1. 期待を明確に伝える 期待が明確に伝わっていないと どこまでやるべきなんだろう？ 何を求められているんだろう？ と迷走させかねません。 また、たくさんのメッセージを伝えられても忘れてしまうものです。 ここテストに出るよ！ぐらい明確に伝えることと、覚えられるようにワンメッセージにすることを意識しています。 私の場合は会社の共通言語を使って、今月の期待を伝えているのと、目標設定で次の3ヶ月の期待も伝えています。 ”伝える”と”伝わる”は違うと思いますが、ポイントはメンバーが期待されていることを答えられるか（答えられてほしいな）。 伝えた期待に沿って日頃会話することも合わせて大事だろうなと思います。 2. 頑張りたいことの認識を合わせる 弊社では3ヶ月ごとに目標設定をおこなっています。 ある程度事業としての目標として決まっているものもありますが、各個人がどんなふうに成長していきたいのか、チャレンジポイントをどこに作りたいのかの目線合わせをしっかりやるようにしています。 フリーで考えてもらっても良いのですが、目線のすり合わせが大変だったりするので 3ヶ月後にどうなっていたくて、そのために何にチャレンジしたいからこの目標を目指したいという流れで考えられるようなシートを渡しています。 ポイントは「どうなっていたら大成功？」という問いにしていることと以前自分がもらった期待ポイントも含めて考えることです。 “どうなりたい”ってなかなか出てきづらかったりするので（私もそのタイプ）、”どうなっていたら大成功か”とちょっと言葉を変えるだけで印象変わるよなと。 また、自分目線とマネージャー目線両方を並べて考えていくことで、より認識が揃いやすくなるなと感じています。 ▼テンプレート https://docs.google.com/spreadsheets/d/1XijlF8-iBhD_vFSG0KLHYlBYnOlWm6SHZgC3a8TKCJI/edit#gid=1806059181 3. 考え方を伝える これは私の苦手分野なのですが 相談や質問を受けたとき、こうやればできるよ！って伝えてしまうことや、やっておいたよ！って言ってしまうことはありませんか？ 親切に見えて、実はその人の成長機会を奪っていることだよなと自分への戒めとして書いてます。 タイミングによってはもしかしたら、自ら手を動かしてぐっと引っ張りあげることも必要かもしれませんが、そうすることで本人の考える余白や成長のチャンスが失われていると思った時に、なぜそのアウトプットに行き着いたのかディスカッションをしたり、問いを投げながら一緒に進めることが大事だったりするのだと思います。 そうすることで次は自力でもう一歩進めたりと本人の力になっていきます。 4. 課題解決への並走 成長のサイクルを早くしていくには、PDCAをいかに早く回せるか。 人によって並走の度合いは変わると思いますが、まず課題に気づいているか、それが本質的な課題なのかを見極めるのは大きなポイントだなと思います。 そこがずれていると、一生懸命頑張っていても前に進んでいく感覚がなく達成感もなかなか生まれづらい。 なので、どういうアクションを取るのか以前に、何が課題なのかを見極める部分にはぐっと入ってもいいのではないかなと思います。 5. 自分ひとりでなんとかしようとしない 育成するとなった時、なんとなく自分がやらなければという縛りが課された気持ちになっていました。 でも、違うんです。 人は会社全体で育てていくもの。 チームメンバーを頼ったっていいし、隣の部署のエンジニアを頼ったっていい。 他にも、同じことでも1人だけから伝えられるのと、いろんな方からその人の言葉で伝えられるのとでは納得度や理解度に差が生まれていきます。 育てたい部分を得意な人に渡していくことで、掛け算で考え方を吸収して自分のものになっていきます。 例えば私が取り入れてみたのはもくもくtime。 それまでは不明なことがあってもメインの相談先が私しかなかったところに、 他のエンジニアも巻き込んで私以外のメンバーでもくもく作業をする時間を作りました。 そうすると、案件を進めていく中で知っておいた方が良さそうなことを事前にシェアしてくれたり、相談先が広がったりと良い変化が生まれました。 さいごに 無我夢中でいろんなことをやってきましたが、振り返ってまとめてみると自分の中での知見が形になってきているなという感覚を持てますね。 ぜひ皆さんが大事だと思うことも教えてください！ The post 「はじめてのメンバー育成。マネージャーとメンバー視点で振り返る1年間」を経て伝えたい大事なこと first appeared on Wedding Park CREATORS Blog .

こんにちは、技術広報の鈴木（ @akk_szz ）です。 ウエディングパークは、2024年3月7日（木）〜 3月9日（土）に開催される PHPerKaigi 2024 にシルバースポンサーとして協賛します！ セッションでは4名（スポンサーセッション1名、プロポーザル採択3名）のエンジニアが登壇するのでご紹介します。 PHPerKaigi 2024とは PHPerKaigiは、現在PHPを使用している、過去にPHPを使用していた、これからPHPを使いたいと思っているエンジニアが、技術的なノウハウを共有するためのイベントです。 日時：2024年3月7日（木）～ 3月9日（土） 会場：中野セントラルパークカンファレンス & ニコニコ生放送 対象：PHPエンジニアおよびWeb技術のエンジニア  主催：PHPerKaigi 2024 実行委員会 （実行委員長 長谷川智希 @tomzoh） 公式サイト： https://phperkaigi.jp/2024/ ウエディングパーク登壇者／登壇内容 ■スポンサーセッション タイトル： はじめてのメンバー育成。マネージャーとメンバー視点で振り返る1年間 登壇日時：2024年3月9日（土）14:05〜（20分） 場所：Track A 登壇者：イノベーション事業開発室　BTO・エンジニアリングマネージャー／ 永井美波（さー） 2018年、ウエディングパークに新卒入社。「Wedding Park 海外」での開発経験を経て、2021年1月からは「Ringraph」のチーフエンジニアとしてサイト全体の開発を担当。2023年1月からはマネージャーとして組織づくりにも取り組み、10月からはBTO※として全社エンジニアの組織づくりに奮闘中。 ※BTO…「Beyo-nd Technical Officer」の略称で、技術とデザインのウエディングパークを創り、デザイン経営を加速させるため、任期１年で経営チームのブレーンとして議論及び意思決定を行う役割のこと。　詳しく知りたい方は こちら＞＞ ■プロポーザル（登壇順） タイトル： php-src debug マニュアル 登壇日時：2024年3月8日（金）10:40〜（20分） 場所：Track A 登壇者：Photorait本部　エンジニア／ おのぽん  大規模ソーシャルゲームのサーバエンジニア、人工知能のコミュニケーションロボットのサーバ全般・Androidアプリ開発を経て2022年にウエディングパークに中途入社。サーバーサイドエンジニアとしてPhotorait全般の開発を担当。他部署のエンジニアともペアプロや講義を開くなど、全社のエンジニアのスキルアップを図っている。趣味は卓球。パラ選手のコーチとしても海外へ旅立つ機会が多い。   タイトル： その処理、LaravelのCollectionで上手くいきます！ 登壇日時：2024年3月8日（金）17:25〜（5分） 場所：Track A 登壇者：＋Creation本部　エンジニア／ ヒビキ 2023年、ウエディングパークに新卒入社。結婚式場向け公式サイト・LP作成ツール「Webつく」の開発を担当。Wedding Park主力商品のリニューアルプロジェクトでの開発に携わる。2024年からは新しい領域での価値創造に挑戦中。   タイトル： 保守開発メインでやってきたエンジニアが『リーダブルコード』を機能削除の観点から語る 登壇日時：2024年3月9日（土）13:30〜（20分） 場所：Track B 登壇者：＋Creation本部　カルチャー推進室　エンジニア／ ririhoshi ウエディングパークの新卒2年目エンジニア。SEO領域での開発を経験後、現在はWedding Park主力商品のリニューアルプロジェクトでリーダーを務めながら開発にも携わっている。またカルチャーの全社浸透・社外発信を行うカルチャー推進室も兼任。   ・・・ ブースや登壇などでお会いできることを、ウエディングパーク一同楽しみにしています！   PHPerkaigi 2023スポンサーをしたときの様子はこちら！ https://www.wantedly.com/companies/weddingpark/post_articles/493220   The post ウエディングパーク、「PHPerKaigi 2024」に協賛、4名が登壇します！ first appeared on Wedding Park CREATORS Blog .

こんにちは、おのぽんです。 大阪に行ったら食が止まらず1日6,7食くらい永遠と食べてました アメリカ1週間行くより全然増量して帰ってきました・・・痩せます。   さて、なぜ大阪に行ったかと言いますと、先日行われた PHPカンファレンス関西2024 に参加するためでした！！ 6年ぶりに行われた関西最大級のPHPカンファレンスということで、みんなのXでの熱も高まっていました！！ 僕も僭越ながらプロポーザルを採択いただきまして、登壇者として足を運ばせていただきました！！   というわけで、今回のブログは「PHPカンファレンス関西2024ってこんな会だったよ！楽しいからみんなも参加しようよ！！」ということをゆるーくお伝えできればと思います   とにかくホスピタリティの高さを感じました！！！ 気合い入れて オリジナル名札カードも作る NFCタグも仕込んですぐにXフォローしてもらえるようにする みたいな準備も念入りにして、大阪へレッツゴー！   ・・・と意気揚々としていたのですが、いざ会場につくと 「あ、スピーカーの方はこちらへどうぞー」と呼ばれた先にあったものは！！   立派なスピーカー用のネームカードと、僕のシールが・・・！   これには「他のご来場者のみなさまとシールを交換することで交流を計ってね」という想いが込められており、僕のような初参加の方でも楽しめる工夫が施されておりました、感動 （ほとんどオリジナル名札カードの出番はありませんでしたw）   そして他にもデコレーションシールが盛りだくさんで、この場でカードを作ってるだけで非常に楽しい時間を過ごしておりました   他にも、ネームカードの裏にはプログラムが印刷されていました。素晴らしい工夫   そしてそして、登壇者はもれなく限定パーカーももらえるのです！   ランチ時には   色んな方の登壇を聞いたり、スポンサーブースでお話を聞いてたらあっという間にお昼時間。 するとこんな投稿がリポストで回ってきました。 「大阪のお昼はどこに行く？？」 会場周辺のランチマップを作成しました！！ #phpkansai https://t.co/T3FDOo21n7 — PHPカンファレンス関西2024 (@phpcon_kansai) February 10, 2024 ありがたすぎる・・・！まさに至れり尽くせり 僕は13:00からの発表だったので、記事に書いてあるカフェラボという近場のお店でご飯を食べることに。 「もうすぐ発表だなぁ緊張するなぁ・・・」みたいなこともなく、普通にお腹すいて何なら「つぶつぶ苺みるく美味しそう。持ち帰りながら飲もう」と思いながらランチの時間に完食するなど   いよいよ僕の登壇！   「CodeRevieweeが求められること」と題しまして、発表させていただきました！ 何せ知り合いもいない状況でカンファレンスに1人で乗り込んだので、「見にきてくださる方いらっしゃるかな・・・」と発表開始直前まで緊張とは違うドキドキ感もありました。 が、結果としておよそ5,60名もの方々が傾聴してくださっていました、本当にありがとうございます   当日機材トラブルがあり、少し時間を押してしまったこと以外はスムーズに発表できたかなと思います。 （スタッフの皆様、次発表の方申し訳ございませんでした。。） Xの反応を見ていても、 実際のインタビューと分析で根拠があるの安心感ある KA法／KJ法でコードレビューについて分析していくのすごい レビューに関するインタビュー、分析おもしろい！ という反響もあり非常に嬉しかったです！ 中には、『「ピラフ奢ります！（僕のPHP Conference 2023での登壇）」の続きを聞きにきました』という方もいらっしゃり、驚きや嬉しさ、衝撃などなど色んなプラスの感情が僕の中でたくさん湧きました！ありがとうございます！！   こういったコメントや反響をいただけることは本当にありがたいですね。 他にも魅力的な登壇が裏番組でたくさんある中、僕の発表を聞きにきてくださった皆様、本当にありがとうございました！   発表も終わりいよいよLT&クロージングへ・・・   ラストはLT大会！！ ボクシングで使われそうなゴングが用意され、5分で強制終了という過酷な状況の中流れるようにLTが行われていきました！ どの発表も面白く、中には関西らしく（？）笑いを取ろうとして作ってる方もいて「こうやってスライドを展開していけば笑いが取れるのか！」と半ば勉強しながら拝聴させていただきました   LT大会も一通り終了し、クロージング中に発表された来場者数（スタッフ含む）はなんと 431名 ！！   6年ぶりの開催で431人も集めることもすごいと思いましたし、何よりこれだけ大人数を綺麗に捌き切った運営スタッフの皆様、本当にありがとうございます！   そしてはじまる懇親会   食欲お化けだった僕は気付けばご飯の写真だけ撮り納めてました笑 懇親会はビュッフェスタイルでしたが、とにかくおしゃれでどれをいただいても美味しかったです   懇親会にも本当に多くの方々が集まっておりました！ 一緒に話してくださる方々もたくさんいて、一人でも参加しやすい雰囲気でした！   交換したシールやXのFollowerの増減   最後に、PHPカンファレンス関西2024にて交換したシールを紹介いたします！ 16枚のシールをゲットし、24名の方からXにてフォローいただきました！ありがとうございます   カンファレンスを通じて考えていること   半ばPHP Confrence 2023の勢いでプロポーザルを応募し採択いただきましたが、数多くの出会いもあり、色んな方々の考え方や意見をお伺いでき本当に充実した1日でした。 スタッフの皆様、僕の発表を見にきてくださった皆様、お話してくださった皆様、本当にありがとうございます！！   このカンファレンス中にもどなたかがおっしゃっていたのですが、コミュニティというのは自然に発生することはなく、盛り上げ続けていかなければ継続することはないのだなと思いました。   とくに常日頃から業務で利用していくPHP言語だからこそ、熱い想いを持っている方や、もっと良くしていきたいという強い意志を持っている方が集まっていて非常に刺激を受けました。   エンジニアという職業をしていると、どうしてもPCとにらめっこしながら進める作業が多くなりますよね。 そのため外部の人との交流を無意識に遮断してしまったり、自分の興味の範囲でしか情報のインプットができないので、自分の考えや知見が凝り固まってしまうものだと思います（少なくとも僕はそんな状態です）。   しかしこういったカンファレンスに登壇したり色んな方々の発表を通じて、知らない世界を教えていただけます。 どのカンファレンスに足を運んでみても「行って良かったな」と思いますし、新しい知見を得るきっかけとなっています。   そんな魅力の多いカンファレンスは、なんと登壇すると参加費無料で参加できますし、色んな登壇者限定グッズもいただけちゃったりするのです！すごい！！   登壇資料の用意は大変です。しかし登壇を終えた時は必ず「発表して良かった」と思えますし、何より反響をいただけると嬉しいですし自信にもなります。 「登壇内容が思いつかない」という方もいらっしゃるのですが、僕も思いつきません。 ふと、今現場で起きていることの中で「あれ？」と疑問に思うことがあったらプロポーザルを出すチャンスかもしれません。 僕も今後もできる限り登壇してコミュニティを一緒に盛り上げていけたら嬉しいなと思います。 もし今回のブログを読んで、少しでも「楽しそう」と思ってくださった方がいらっしゃいましたら、まずはカンファレンスに参加してみませんか？   最後までお読みいただきありがとうございました！ The post PHPカンファレンス関西2024に参加して参りました！ first appeared on Wedding Park CREATORS Blog .

こんにちは、おのぽんです。 Tweets by onopon_engineer   最近ダイエットをしているのですが、甘いものが大好きなので常日頃食べたい気持ちはあるものです。 そんな中でも、脂質を抑えられるけど食べれるおやつはなんだろう？と考えてたどり着いたものは「カステラ」でした。 カステラは脂質は低い一方でタンパク質や炭水化物の含有量も一定あるので、腹持ちが良く、スポーツの補食としても採用されています。 昔からカステラも大好きだったので、それに気づいてからコンビニのカステラを買い漁るようになってしまいました笑   さて、私ごとではございますが、2024年2月10日（日）に開催されたPHP Conference 関西 2024にて、 CodeRevieweeが求められること と題し発表させていただきました。 https://fortee.jp/phpcon-kansai2024/proposal/1ece99f8-82c3-4a87-a684-6649350fdf74   2023年10月8日（日）に開催されたPHP Conference Japan 2023では「CodeReviewerが求められること」を発表させていただいたのですが、 嬉しいことに満員になるほど聴衆の方々がお集まりくださいました。 その時の発表内容をまとめた記事は こちら 。   今回の発表はその続編の内容となっております。 本記事では、「 今日からできる！Reviewerから求められるレビュー依頼術 」を紹介いたします。   Reviewee（=コードレビューを依頼する人）としての心構え Reviewerの気持ちを考えてPR（=Pull Request。Github上で修正や機能追加を提案できる機能のこと）を出す ことが必要です。 思いやりのないPRはチーム内での関係性の破綻を招いたり、結果的にレビューを出した人自身が傷つく恐れがあります。 では、Reviewerを思いやるためにはどうすれば良いでしょうか？ Reviewer（=コードレビューをする人）が求めているもの インタビューを行い、Reviewerの想いを集める Reviewerのことを理解するために、下記のインタビューを実行しました。 対象：20-30代の計10名の弊社のいろんな役職のPHPerエンジニア インタビュー時間：10分 内容：PRをReviewする際、 レビューをする時にどのような点・内容に意識を向けているか？ 指摘部分をコメントする際、気をつけている点はあるか？ レビューしていて大変だなと思う時は？ どのようなPRだと嬉しい？ どのようなPRだと見たくない？（テンションが下がる？） Reviewerのインサイトを探る 次に、KA法を使ってReviewerのインサイト（= 心の声）を探りました。 KA法とは 、 定性調査で明らかにした顧客の声や行動・体験などの「質的データ」を 分析・モデリングし、本質的なニーズやユーザーのインサイトを明らかにしていく手法のことです。   KA法ではKAカードというものを作成していきます。 KAカードには、出来事・心の声・価値の3種類があり、 出来事：インタビューでの発言内容 心の声：出来事から考え得る心の声（=インサイト） 価値：行動の背景にある価値 をそれぞれ記載します。   例を紹介します。 あるエンジニアとのインタビューの中で、 他の人から見てもわかりやすくなっているか。という点。（に気をつけてレビューをしている） という意見を伺いました。 こちらを出来事とし、心の声、価値をそれぞれ考えます。 心の声としては、 「可読性が気になる」 ことであると考えました。 また、この出来事の先にある価値は 「運用のしやすさ・属人化防止」 であると考えます。 これらをKAカードに落とし込むと下記のようになります。   KA法では、質問内容問わず得られた意見を全てカードに落とし込んでいき、心の声や価値を拾い上げます。 今回のインタビューをKAカードに落とし込むことで、実に140枚にも及ぶカードを作成することができました。   Reviewerの気持ちをグルーピングする 次にKJ法を利用して、先ほどのKAカードにより導き出した心の声や価値を見比べていき、似たような考えや感情をグルーピング、近しい考えを紐付けしていきます。 KJ法とは 、書き出した情報（ローデータ）の断片的な要素を関連づけて、 俯瞰しながらグループ化していく手法のことです。   KJ法を行ったところ、先ほどのKAカードは下記のようなグルーピングとなりました。 グループ名は、それぞれ プロダクトの質を向上させたい 迅速にレビューを終わらせたい レビューの質を向上させたい 組織を乱したくない 自他成長 としました。 これらをグルーピングしたグループ名でピックアップしてみると、Revieweeの想いは下記のようになります。 このうち、 「 RevieweeがReviewerの要望に応えることができるもの 」 という観点で見ていくと、 迅速にレビューを終わらせたい レビューの質を向上させたい の2つであれば応えることができそうであることがわかります。 一見矛盾したように見える要望 先の章で、RevieweeはReviewerの 迅速にレビューを終わらせたい レビューの質を向上させたい の要望に応えることができそうというお話をしました。 しかし、迅速なレビューとレビューの質の向上は一見矛盾したように見えます。 ここでそれぞれのKAカードの心の声を見ていくと 「迅速にレビューを終わらせたい」の心の声 レビューにかけるパワーを抑えたい 理解しやすいコードを読みたい レビューの回数を抑えたい 「レビューの質を向上させたい」の心の声 概要を書いて欲しい 意図を素早く理解したい より適切なレビューを届けたい ということが書かれていました。 このあたりからReviewerの気持ちを読み取っていくと、 Reviewerは基本忙しい ため 、あまり自身の作業を中断したくない Revieweeの考えを理解した上で レビューを施したい といったあたりがわかります。 Reviewerの求めるPRの出し方 Reviewerに求められているPRの出し方は意外とシンプルで、 忙しいReviewerでも手軽に見ることのできるような工夫を施す Reviewerに自分の考えや意図を伝える と言ったあたりを満たすことができれば、先ほどの矛盾してそうな要望のどちらにも応えることができそうです。   忙しいReviewerでも手軽に見ることのできるような工夫 僕のプロジェクトで行われている工夫の仕方を2つほど紹介いたします。 1PRあたりのファイル数を10程度に抑える Reviewerへのインタビューにより、1PRあたりのファイル数の多さの感じ方は下記の通りであるとわかりました。 1PRあたりにおけるファイル数が11~15あたりから、意見が分かれ始めました。 なので、1PRあたりのファイル数は10程度に抑えると良さそうです。 軽量なPRであることを伝える 僕のプロジェクトでは、レビューを依頼する際、SlackでgithubのURLを貼りながらReviewerへ声かけをしています。 その時によく見る声がけが、 どれくらい軽量であるか を伝える ex) 差分少ない です！レビューお願いしますmm 1行のみの修正 です！よろしくお願いします。 どれくらい軽い気持ちで見ることができるか を伝える ex) このPRは すぐ見れる かと思います。よろしくお願いします ◯◯な内容なので、 さくっと見れる かと思います。よろしくお願いいたします！ のようなものです。 こうした一言を書くことで、ReviewerがGithubのURLを開くハードルを低くすることができます。   Reviewerに自分の考えや意図を伝える方法 レビューを依頼する前に 自らPR内にコメントを残しておく 処理を簡単にする（一目で理解できるようなコードを書く） 事前にReviewerと実装方針のすり合わせを行う といった行動を取れば、Reviewerに対して自分の考えや意図を伝えることができそうです。 本記事はレビューの依頼方法に焦点を合わせているので、この中でも「レビューを依頼する前に自らPR内にコメントを残す」方法について触れていきます。 レビューを依頼する前に自らPR内にコメントを残すコメント例 コメント例①：第三者が見て疑問に思いそうなポイントには先回り 「なぜこのようなロジックになるのか」と質問されそうな点に対し、あらかじめ解答しておいたり、   理解に時間を要しそうなロジックには、図解するなどしておきレビュー時間の短縮を図っています。 コメント例②：Reviewerの質問内容が理解できない場合は素直に聞く 事前にコメントをしていると、そこから議論に発展することがあります。 その際発生した質問内容が仮に理解できなかった場合は、無理に解答しようとせず素直に補足内容を求めましょう。 そして、Reviewerの意図を理解してから解答することが良いと思います。 また補足内容の説明を受ける際は、チャット上でのやり取りだけでなく、オンライン通話や口頭で直接補足をいただいても良いです。   Reviewerの苦悩 Reviwerの想いでもう一つ大事な点として、 プロダクトの質を向上させたい 組織を乱したくない があります。 RevieweeはReviewerがいかにすごいことをやろうとしているかを理解しておくことも重要です。 こちらでも、それぞれのKAカードの心の声を見ていくと、 プロダクトの質を向上させたい コードの質を落としたくない 属人化を防ぎたい 運用に耐えうるコードになっていてほしい 組織を乱したくない Revieweeへの気遣い ギスギスしたくない 度重なる指摘コメントはReviweeの気が滅入ってしまう、Revieweeのことを傷つけてしまう恐れにつながります （人格否定、攻撃的なコメントは論外） と言ったことを考えながら、組織を乱さずにプロダクトの質を向上させることを考えています。 コメントをしなければプロダクトの質の改善につながらず、Revieweeを傷つけることもまたプロダクトの質の改善にはつながりません。 Reviewerはこういった苦悩を乗り越えながら、細心の注意を払いつつコメントをしております。 レビュー依頼の工夫点の1つとして、このようなReviewerの苦悩を理解し Reviewerにとってコメントしやすい状況を提供する ことができるコメント例も存在するので、最後に紹介しようと思います。 Reviewerにとってコメントしやすい状況となるコメント例 こちらはcronの設定のレビュー依頼を出したエンジニアのコメント例です。（オレンジ：Reviewee、グレー：Reviewer） 最初のタイミングで、Revieweeは 教えて欲しいというスタンス を取っています。これによりReviewerにとってコメントしやすい状況が生まれています。 また Revieweeが知りたがっている部分も明確 であるため、Reviewerも適切なコメントを残すことができ、レビューの質・速度の向上につなげることができます。   少しレビュー依頼とは異なりますが、Revieweeの行動も素晴らしいと考えます。 ここでは「cronを設定しなければならないということはわかっているものの、どのようなルールで設定すれば良いかはよくわかっていない」という状況です。 しかし、RevieweeはとりあえずPRを出すところまで作業を進め、PR上で質問することで設定方法を解決しようと試みています。 このように、レビュー依頼のタイミングで疑問点を聞くことで他エンジニア（≒Reviewer）の作業を中断する回数を減らすことができるため、 Reviewerから奪う時間を最小限に抑える ことにつながります。   今日からできる！Reviewerから求められるレビュー依頼術 さて、本記事のゴールは「今日からできる！Reviewerから求められるレビュー依頼術」を紹介することでした。 今までの流れを踏まえてまとめていきます。 Reviewerへインタビューを行い、その結果を分析することで、Reviewerの気持ちがわかりました。 Revieweeがレビューの依頼方法を工夫することで、Reviewerの下記の2つの要望を満たせることがわかりました。   ◯Reviewerが求めるレビュー依頼 ①気軽に見ることができるもの ②Revieweeの考えや意図が伝わるもの   これに対して様々なレビュー依頼やPRでのコメントの仕方を通して、どう言った点が良いかを本記事内で記述いたしました。 それこそがレビュー依頼術となります。（下記にまとめます。）   ◯レビュー依頼術 1PRあたりにおけるファイル数は10ファイル程度に抑える 軽量なレビューであることを伝える レビューを依頼する前に 自らPR内でコメントをつけておく 第三者が悩みそうな点は先回りしてコメント Reviewerにとって コメントしやすい状況を作る 迷ったり相談したい点もあらかじめコメントしておく 処理を簡単にする（一目で理解できるようなコードを書く） 事前にReviewerと実装方針のすり合わせを行う     いかがでしたでしょうか？ 今回はReviewerの気持ちを分析した上で、「今日からできる！Reviewerから求められるレビュー依頼術」を紹介させていただきました。 少しでもReviewee・Reviewer同士がお互いを理解し合いながら、プロダクトの質を改善していくことに繋がると嬉しいです！   本セッションの議論・質問はもちろん、 目標達成や事業の成長を一緒に感じたい チーム貢献 に尽力できて、またその成果も評価してほしい 自由に企画・提案 しながら社内にアクションを起こしたい という方がいらっしゃいましたら、是非一度弊社社員とお話させてください！   最後までお読みいただきありがとうございました！！ The post 今日からできる！Reviewerから求められるレビュー依頼術 first appeared on Wedding Park CREATORS Blog .

こんにちは。ウエディングパークエンジニアのさー（ @__south__373 ）です。 10月8日に PHP Conference Japan 2023 が開催されました！ ウエディングパークはスポンサーとして協賛しており、2名が登壇をしたので当日の様子をレポートしたいと思います。 その前に・・少し協賛の背景 ウエディングパークがPHP Conferenceに協賛をするのは2018年ぶり！ 弊社は「結婚を、もっと幸せにしよう。」を経営理念としている中で、ウエディングxデジタルの分野で様々な事業を展開しています。 多様な幸せを叶えるために、業界をもっともっと幸せにしていくために技術の力が必要です。 クリエイターとしては「技術とデザインのウエディングパークを創る」というスローガンを掲げており、実現に近づけるひとつのアクションとしてスポンサー活動や登壇を応援しています。 最近はカンファレンスのプロポーザル締め切り前に社内でアナウンスがされるようになり、投稿してみたい人が集まってワイワイ準備したりしています^^ 今回は ヒエイさん と おのぽんさん が見事採択！ 当日はおふたりの応援も兼ねてみんなでスポンサーブースに立ったりしました。 ではでは当日の様子！ 当日の朝会場に到着！リアルで開催されるのは4年ぶりだそう…コロナを越えて受け継がれていくカンファレンスってすごい…！ 会場の中にはスポンサーブースがたくさん！ 2018年ぶりの協賛ということで、ブースのグッズもリニューアルしました^^ ブースに来てくださった方にはルーレットを回していただき、ウエパちゃんグッズや技術書が当たる景品を準備！ ウエパちゃんを気に入ってくださり「ウエパちゃんポーチ当たれ〜〜〜」と願いながら回してくださる方もいました笑 カンファレンス側でスタンプラリーを用意してくださっており、ブースやセッションを聞きにいくことでスタンプを獲得！ 抽選でiPadやelePHPantのグッズなどが当たるものだったのですが残念ながら全部外れました！＞＜ ただいまスタンプラリーの抽選会を実施中です！ スタンプ6個につき1回抽選をできます！ ぜひおこしください！！ #phpcon pic.twitter.com/AmuIUZ5QZC — PHPカンファレンス2023 (@phpcon) October 8, 2023 いよいよ登壇の時間に 登壇はトラック1〜6まであるという大規模開催！ まずは、14:15〜おのぽんさんの「コードレビュワーが求められること」がスタート。 部屋がパンパンになる大盛況っぷり！ コードレビューワーってどんな風にレビューをしたら良いんだろうか？ということを、社内へのインタビューと分析から言語化しています。 これだけは写真撮って帰って！という言葉にみなさんが写真を撮ってくれていました^^ エンジニアであればコードレビューはつきものだと思うので、お互いに気持ちよく仕事ができるようにするためにも思いやりを持ってレビューができるように意識したいものです。 続いては、15:55〜ヒエイさんの「PhinxによるDBマイグレーションとサービス運用」。 大きい会場での登壇がとってもカッコよかった！ マイグレーションが導入されないまま運用されていた既存サービスにマイグレーションをどうやって導入するか、運用するかを考えたときにPhinxを活用してみたよという具体的事例。 Xでポストもされていましたが、マイグレーションのテストとしてマイグレーションの実行とロールバックができるかの確認を設定するのはなるほど〜〜〜と思いました！ 最後は懇親会 みんなで気持ちよく乾杯〜〜〜 PHPerKaigiで繋がれた方との再会があったり、新たにいろんな方と繋がることができたりで満足^^ 登壇をしたふたりが「楽しみにしてました」「質問が・・」という声かけをしていただいていたのが羨ましすぎて、次は絶対登壇を勝ち取るゾ！！！という気持ち。 2024年PHPカンファレンスラッシュということで、小田原とかも興味あるね！？という会話があったので会社のメンバーを連れて勢力拡大していきます！  

概要 今回のWP HACK DAYのテーマは「ビジョン実現につながるもの」でした。 「21世紀を代表するブライダル会社を創る」の実現に近づけるようなものとはどんなものか、準備期間とWP HACK DAY当日で発案から開発まで取り組みました。 今回我々のチームはビジョンから発想を広げ、社員同士をマッチングするガチャを開発しました！ この記事では、本チームの開発について記載していきます。 WP HACK DAY #6全体の詳細については こちらの記事 をご覧ください。 社内ハッカソン「WP HACK DAY #6」を開催しました！ WP HACK DAYまでのタイムライン 前日までの準備 WP HACK DAYでは開催までの間も準備期間が設けられているのですが、週1時間までの作業およびミーティング時間という制約のもとで準備を進めました。 テーマからどのようなことにアプローチするか検討 「ビジョン実現につながるもの」というお題に対して、どのようなアプローチができるか。 アプローチする題材から課題解決方法を議論 いくつかアプローチしたい題材についてどのように課題解決するか議論しました。ここでは、1日の作業時間で実際に実現可能かも併せて検討しました。 本記事で後ほど紹介する題材に決定し、より具体的な手段について作業準備 アニメーションデザインの作成 画面モック 機能ロジックのアルゴリズム 作業環境のサーバの接続権限設定 当日のタイムスケジュール 9:00-9:30 チームごとに今日の流れを確認 9:30-9:40 開会式 9:40-12:00 開発 12:00-13:00 ランチタイム 13:00-17:00 開発、発表資料作成 17:00-18:00 成果発表会 18:00-18:30 懇親会 選んだ題材とその理由 今回のWP HACK DAYのテーマは「ビジョン実現につながるもの」でした。 まずはビジョン実現するために何が必要かをチームで話し合い、 「１人ではビジョンを達成することはできないので、WP社員の結束力を高めることが必要不可欠！」 「結束力を高めるためにもっと結節点を増やしたい！」 という結論に至りました。 けっせつ10とは   けっせつ10（けっせつてん）とは、ウエディングパークの社内制度の1つです。 新入社員（新卒中途問わず）が普段あまり関わりのない社員とより交流を深めるためにランチや会食ができる制度で、一定額までは会社が費用を負担します。 「けっせつ10」という名前にもある通り、「10」がこの制度の鍵になります。 けっせつ10は社員同士なら誰とでも食事に行けるわけではなく、一定のルールがあります。 グループを作るにはメンバーの入社年次を足して10になるようにする必要がある 最低2部署以上の組み合わせである必要がある メンバーは2～4人 けっせつ10についてのより詳しい情報は弊社の プレスリリース をご確認ください。 新入社員のアイディアから生まれた新制度！入社年次が合計「10年」の社員を集めて開く交流会「けっせつ10（てん）」を発表 けっせつ10の課題 けっせつ10は社員同士の結束を高めるにはうってつけの制度なのですが、場合によっては 「誰を誘おう…まだあまり話したことがないのに急に誘ったらびっくりされるかな…」 と考えすぎた結果使わずに終わってしまった…。なんてことも。 また、けっせつ10は新入社員が社内の人間関係を構築しやすくなる反面、ルールに沿ったメンバー決めが簡単ではない課題もありました。 そこで、適当にメンバーを提案してくれるツールがあればもっと気軽に誘えるようになるのでは？と考えました。 そのような考えから、我々のチームはこれらのけっせつ10の課題を解決するツールを開発することにしました。 チーム体制 チーム名は、安直ではありますが、それぞれのイニシャルと、甘いもの好きの共通点で、「バキバキ！糖分MOKA」と名付けました。お腹空きますね。 担当： M: マッチングロジックの開発を担当。Laravelのバックエンド開発に挑戦。 O: 主にデザインページモックとコーディング、アニメーションを担当。アニメーション作成に挑戦。 K: Laravelでフロントエンド側の開発に挑戦。 A: メンバーの製作物の結合と、当日のメンバーのフォロー、発表資料を隙間時間で作成して、チーム全体の開発時間の確保。 当日のチーム開発の進め方 それぞれの役割の認識合わせ デザイン、バックエンド、フロントエンド、プロジェクトマネジメントで分担しました。 それぞれのメンバーがあまり経験したことのないことに挑戦しました。 環境整備 「シャッフルン」というフリーアドレスの座席エリアを自動で選んでくれる社内サービスの環境で社員名簿を保持しているため、その環境を活用しました。（シャッフルンは現在休止中） 各々開発→都度マージ 同じテーブルで島をつくり会話をしやすい状態にし、 各々自分の担当箇所の開発を進める→分からないところなどがあれば質問、相談→ある程度完了したらマージ という流れの繰り返しで進めていきました。 制作物紹介 今回のWP HACK DAYで我々は、 ドキドキ♡マッチングガチャ を開発しました！ 「ドキドキ♡マッチングガチャ」は、けっせつ10のメンバー決めの際の誘いづらさや、ルールに沿ったメンバー決めの難しさなどの課題を解決する社内Webサービスです。 「 サイゼリヤ1000円ガチャ 」に着想を得たツールで、自分自身と開催人数を入力するだけで自動でメンバーが選出されます。 動作の様子 部署を選択 自分の名前と開催人数を選択 ガチャのアニメーション マッチング結果 ※WCはワイルドカードで、6年目以上のメンバー 展望 当日の開発だけで完璧なものができたわけではなく、今後より改善できる点もいくつかありました。 今回はプロトタイピングのため、既存の開発環境上で開発をすすめていました。そのため、開発環境のデータが古いことに起因する課題がありました。 具体的には、新入社員の情報が取得できなかったり、入社月を考慮できておらず勤続年数に誤りが発生する不具合などが既存システムにあることも当日判明しました。 また、更なる利便性向上として、ガチャの結果画面にメンバーのアイコンを表示する機能や、ガチャの結果をSlackなどに簡単にシェアできる機能も検討しています。 WP HACK DAYを通しての学びや感想 M： 新卒として入社して初めてのWP HACK DAYで、初めて1からプロダクトを作る経験ができ多くの学びがあったと同時に、終わるのがあっという間なとても楽しいひと時でした。Laravelでの開発の基本やデータベースの扱いなど、今後の業務でも必要になる知識と経験をかなり身につけることができました。その後の業務でもWP HACK DAYでの学びが役立っています！ K： あまり経験のないLaravelでの開発かつ、限られた時間の中で一から成果物を作るという経験を今までしたことがなかったので、普段の業務での開発とはまた違って新鮮な気持ちで取り組むことができました。 正直私は他のメンバーに頼りっきりになってしまいましたが、自分の技術レベルを認識、痛感することもできてモチベーションの上がるとても良い経験になりました！次回のWP HACK DAYではもっと活躍できるよう成長していければと思います！ A： 今回のチーム構成において、私以外が本イベントには初参加で勝手がわからない状態でした。当日の温度感や、やることの規模感など、このメンバーで分担してできるものかもみんなで考え、準備や当日の作業のリードとフォローに回り、チームでの開発を円滑にするサポートに努めました。発表ぎりぎりまで開発するこのスリルと、普段一緒に案件にアサインされない開発メンバーと協力する新鮮さと楽しさは、まさにお祭りでした。 終わりに 今回のWP HACK DAYを通じて部署を超えた開発に挑戦することができました！これをきっかけに、今後も部署を超えた挑戦を加速させ 「技術とデザインのウエディングパーク」そしてその先の「21世紀を代表するブライダル会社を創る」のビジョン実現に向けて全社一丸となって進んでいきます！

こんにちは！新卒2年目エンジニアのtakadaです。 本日は先日開催されたWP HACK DAY  #6 で 僕たちのチームが 作成したものについてご紹介をできればと思います！ 目次 背景と概要 View Transitions APIとは 実装内容 まとめ   1. 背景と概要 WP HACK DAYとは社内のエンジニアがテーマに沿って1日でプロトタイプの開発を行い、発表まで行うイベントです。 そして今回開催されたWP HACK DAY #6のテーマは 「ビジョン実現につながるもの」 です！ 弊社のビジョンである「21世紀を代表するブライダル会社を創る」につながるようなプロダクトの開発をチームで考えていきました。僕たちのチームでは、「結婚式場探しでウエディングパークのサービスを使う時に、もっと心が動く体験ができたらビジョンに近づけそうだよね！」と議論する中でまとまっていきました。 そのため、 「ふたりに、心が動く体験を。」をテーマに、 サイトのUIを改善することでユーザー体験の向上を図り、もっと心の動く瞬間を作れるような開発をしようとなりました！ そこで登場したのが View Transitions API です！   2. View Transitions APIとは？ WP HACK DAY開催の目的の1つとして 「技術挑戦の機会づく り」 というものがあります。 UI改善をするのであれば、チーム内のエンジニア間で前々から気になっていた 「View Transitions API」 を使用して技術挑戦をしてみよう！となりました。 View Transitions APIとは、今年3月にChrome111とEdge111でリリースされた 「画面の更新前後の異なるDOM要素間のトランジションを簡単なCSSとJavaScriptで実現するAPI」です。 ※引用元：https://zenn.dev/yhatt/articles/cfa6c78fabc8fa これまで画面遷移に対するアニメーションは実現可能ではありましたが、更新前後のページ間でJavaScript/CSSで表示位置を計算する必要があるなど、とても実装することが大変でした。 しかしView Transitions APIを用いることで、非常にシンプルなJavaScript/CSSで実装することができます！ 現時点ではSPA向けのAPIが安定版となっており、MPA向けのAPIは実験的に提供されている段階ですので、今後に期待する部分でもあります！ 3. 実装した内容 今回はウエディングパークサイトにView Transitions APIを使用してUI改善を図っていきました！ 下記動画は一部ではありますが、実装したものとなっております。 (開発環境のみの実装のため、本番環境での実装は行なっておりません。)   document.createElement('video'); https://engineers.weddingpark.co.jp/wp-content/uploads/2023/09/viewTransitionApi.mp4 見て分かります通り、ページ遷移をする際に横にスライドして遷移していることがわかります。 使用したコードの量も わずか数十行 で、とてもシンプルに実装することができました！ 今回は横スライドやフェードアウト、縦スライドなど様々なアニメーションに挑戦をさせて頂きました。 その他にも要素を回転させながら遷移させるなど、たくさんのアニメーションを実装することができるので是非挑戦してみてください！ また、今回同じチームの新卒1年目のデザイナーがサイトのUIを改善する施策を自ら考えて実装をしてくれました！行った内容としては、トップの画面に桜を散らせるアニメーション、カルーセルの要素のうち、メインで表示している1つを拡大するアニメーションの実装などです！ 「HTML & CSSに対する経験をもっと積みたい！技術挑戦してみたい！」 と自ら手を挙げてくれて技術挑戦をしてくれましたが、それをできるWP HACK DAYは「とても良いイベントだな！」と感じた瞬間でした。   4. まとめ 今回、View Transitions APIを実際に使用してみましたが、 「こんな簡単にアニメーションが付けれるんだ！」と感動するぐらいとてもシンプルに実装をすることができました！ ただMPA向けのAPIが実験的に提供がされているという事やリリースが最近という事もあって、まだまだ記事が少なく仕組みの理解及び不具合に対する原因追求に思ったよりも時間がかかってしまいました！ 今後MPA向けのAPIが正式にリリースされる事で、記事の量が増えることに期待しつつ、本番導入も是非視野に入れていきたいですね！ 次はWP HACK DAY #7ということで、#6よりもさらに技術挑戦できるようにしていきたいなと思います！      

こんにちは、おのぽんです。 Tweets by onopon_engineer     急に寒くなり、夏が一瞬でいなくなったように感じます。じめっとした暑さも嫌ですが、突然寒くなるのもびっくりしてしまいますね。   さて、私ごとではございますが、2023年10月8日（日）に開催されたPHP Conference Japan 2023にて、 コードレビュワーが求められること改め CodeReviewerが求められること と題し発表させていただきました。 https://fortee.jp/phpcon-2023/proposal/25891e6c-7762-47b5-8cb3-e3db7f056abc   レビューに関する考え方は一度社内でdocbaseを活用して発信したところ、ありがたいことに多くの反響をいただきました。 また嬉しいことに、他部署のディレクターがその記事を読んで他のエンジニアに伝えてくださるといったアクションもありました。 PHP Conference Japan 2023では、そんな考えを共有すべく、Revieweeの気持ちや考えを実際に分析していきつつ、どのような観点でレビューを進めると良いかを考察していきました。 本記事では、その時の発表で皆様にお伝えした「 今日からできる！Revieweeから求められるコードレビュー術 」を紹介いたします。   なぜコードレビューを行うのか コードレビューをなぜ行うのかを考えます。 作ろうとしているものが合っているかを確認するため コードの質を担保するため 属人化を防ぐため 知識共有や認識合わせのため チーム内のスキルアップのため コードレビューの目的は様々であるため、一概に「どのようなレビューが正解である」と定めることはできません。   Reviewee（=コードレビューを依頼する人）が求めているもの 次に、Revieweeが求めているコードレビューを考えてみましょう。 みんなはどんなことを考えながら他エンジニアにレビューを依頼しますか？Revieweeの気持ちになって考えてみましょう。 もっといい書き方があるか教えてほしい コード設計や方針を理解してもらいたい 思想や方向性を共有・議論したい 想定外の影響範囲がないか確認してもらいたい 可読性を担保できているかどうか客観的に判断してもらいたい このように、Revieweeは色んな思いや考えを持っています。 それらの思いや考えを尊重しながらコードレビューを行うためには、どのようなことに注意することが良いのでしょうか。 インタビューを行い、Revieweeの想いを集める まずはいろんなエンジニアのRevieweeとしての想いを知るために、下記のインタビューを実行しました。 対象：20-30代の計10名の弊社のいろんな役職のPHPerエンジニア インタビュー時間：10分 内容：Reviewを依頼する際、 どのようなレビューを求めるか？ レビューを出す際に意識していることは？ どんなコメントが残ってると嬉しい？ こんなレビューが助かった こんなレビューは嫌だった Revieweeのインサイトを探る 次に、KA法を使ってRevieweeのインサイト（= 心の声）を探りました。 KA法とは 、 定性調査で明らかにした顧客の声や行動・体験などの「質的データ」を 分析・モデリングし、本質的なニーズやユーザーのインサイトを明らかにしていく手法のことです。   KA法ではKAカードというものを作成していきます。 KAカードには、出来事・心の声・価値の3種類があり、 出来事：インタビューでの発言内容 心の声：出来事から考え得る心の声（=インサイト） 価値：行動の背景にある価値 をそれぞれ記載します。   例を紹介します。 あるエンジニアとのインタビューの中で、 「これもいいと思うけど、こういう書き方もできるよ」みたいな+αを教えてもらえると嬉しい。 という意見を伺いました。 こちらを出来事とし、心の声、価値をそれぞれ考えます。 心の声としては、 「 良い実装を知りたい 」 ことであると考えました。 また、この出来事の先にある価値は 「Revieweeのスキルアップにつながる」 ことだと考えます。 これらをKAカードに落とし込むと下記のようになります。   KA法では、質問内容問わず得られた意見を全てカードに落とし込んでいき、心の声や価値を拾い上げます。 今回のインタビューをKAカードに落とし込むことで、実に100枚にも及ぶカードを作成することができました。 Revieweeの気持ちをグルーピングする 次にKJ法を利用して、先ほどのKAカードにより導き出した心の声や価値を見比べていき、似たような考えや感情をグルーピング、近しい考えを紐付けしていきます。 KJ法とは 、書き出した情報（ローデータ）の断片的な要素を関連づけて、 俯瞰しながらグループ化していく手法のことです。   KJ法を行ったところ、先ほどのKAカードは下記のようなグルーピングとなりました。 グループ名は、それぞれ 楽しく働きたい 気づきや学びが欲しい 実装や意図を理解して欲しい 自信を持ちたい Reviewerへの心遣い 利用ユーザに早く価値を届けたい 属人化を防ぎたい としました。 これらをグルーピングしたグループ名でピックアップしてみると、Revieweeの想いは下記のようになります。 このうち、 「 ReviewerがRevieweeの要望に応えることができるもの 」 という観点で考えると、 気づきや学びが欲しい 実装や意図を理解して欲しい 自信を持ちたい の3つが、RevieweeがReviewerに求めることであると捉えることができます。   Revieweeが求めているレビュー例 先の章で、RevieweeはReviewerに対して、 気づきや学びが欲しい 実装や意図を（Reviewerに)理解して欲しい 自信を持ちたい といったことを求めていることがわかりました。 本章では、僕の現場でのコードレビューを例にあげ、どのようなレビューであればRevieweeの気持ちを汲み取ったレビューを行えるかを紹介していきます。 気づきや学び・実装や意図を理解していることを伝えるレビュー こちらのReviewerは、 実装や意図を理解した上で、 ブラッシュアップ（学び）のための コメントを記載 物腰柔らかい口調 Revieweeの修正後、感謝を伝える といったコメントをしています。   これは、 ・PHP特有のメソッドや、ロジックの代替案は気づきや学びとして伝えられるので、 気づきや学びを与えることができている ・また、 実装や意図を理解していなければ、 気づきや学びのコメントができない ので、 実装や意図を理解している と言える であると考えられます。 ナイスレビューですね！   このように、気づきや学び、実装や意図の理解などは何となく想像しやすいかな？と思います。 では、自信につながるレビューとは一体どんなものでしょうか？   自信につながるレビュー どういったレビューを行うと、Revieweeは自信につながるのでしょうか？ それは、先ほど行ったKAカードの中にヒントが潜んでいます。 先ほど「自信を持ちたい」にカテゴライズしたKAカードの一部を下記に取り上げてみます。 これらの心の声をみると、 安心感 や 褒めてもらいたい といった欲求を満たすことができれば、自信を持つことができると言えそうです。 また、レビューの場では満たすことはできませんが、 自分が作ったものを使ってもらえると嬉しい という声も上がっていました。 確かにReviewerが別のタイミングで、以前レビューしてもらったコード（機能）を使ってくれていたら嬉しいですよね！   それでは、安心感が増すレビューや、褒めるレビューを見ていきます。   安心感が増すレビュー 例1) こちらは、僕（=onopon)がRevieweeの様子です。 一通りレビューをした上でわからなかった点を質問していただけているので、 実装や意図を理解しようとしてくれている ように感じます。 そして、補足説明に 納得した上でLGTM（=LookGoodToMeの意。レビューOKを表します）とコメントしてくださっています。 ただLGTMをもらうより安心感があり、自信にも繋がるレビューとなっているのではないでしょうか？   例2) こちらでは、登場人物全員Reviewerです。 書かれたコードを読んで理解したことをそのまま書いているだけですが、 他の人のレビューの手助けになる可能性があります。 また、 実装や意図を理解できていないと書けないコメントを書く ことで、Revieweeに「ちゃんと読んでるよ！」ということを伝えることができます。 2人目のReviewerも僕のコメントを読んで理解した旨を被せて伝えているだけなのですが、 ただコメントを残すだけでもRevieweeにとっては安心に繋がる コメントとなり得ます。   例3) 「LGTMです！」や「 です！」のようなコメントだけでは、 「Reviewerが本当に読んだのかどうか」までを伝えることはできず 、Revieweeの 安心感に繋げることができません。 修正範囲がある程度のファイル数に及ぶものであれば、 そのファイルの構成 ロジックを読んだからこそ書けるようなコメント を添える のようなコメントをすることで、Revieweeに安心感を与えることができます。   褒めるレビュー 例1) 補足コメントへのリアクションは「読んでもらえている」という安心感につながりますね。 ただ褒めるだけ でも、Revieweeにとって 自信に繋がりますし、 のような 肯定的なリアクション もGoodです 例2) この例では、ReviewerはRevieweeに対して「ピラフを奢りたくなるほど感謝している」という喜びが表現されていますw このように感謝の気持ちと共に どれくらい喜んでいるのかを大げさに伝える と 、 Revieweeは「修正の方向性は間違えてなかった」と感じ自信を持つことができます。 また、2件目のコメントのように 手法やプロセスを褒める のも良い手法です！ 今日からできる！Revieweeから求められるコードレビュー術   さて、本記事のゴールは「今日からできる！Revieweeから求められるコードレビュー術」を紹介することでした。 今までの流れを踏まえてまとめていきます。 Revieweeは下記の3つを求めていることがインタビュー結果を分析することで見えてきました。   ◯Revieweeが求めるレビュー ①気づきや学びを与えることができているか ②実装や意図を理解しているように見せられているか ③Revieweeに自信を持たせることができているか 　→ 安心したい というインサイト   これに対して様々なレビューを通して、どう言った点が良いかを本記事内で記述いたしました。 それこそがコードレビュー術となります。（下記にまとめます。）   ◯コードレビュー術 代替案を伝えるコメント は 、①②を満たせる わからない点は質問する ことで、②を満たそうとする姿勢を伝えることができる ロジックを読んだからこそ書けるコメント は②を満たすことができる 何かしらを 褒めるだけ でも③を満たすことができる それがプロセスや手法であっても良い 肯定的なリアクションスタンプ は安心につながり、③を促す 感謝の気持ちを伝える上での 大げさな感情表現 は③を満たすことができる     いかがでしたでしょうか？ 今回は、Revieweeの気持ちを分析した上で、「今日からできる！Revieweeから求められるコードレビュー術」を紹介させていただきました。 少しでも誰かのレビューの質の向上に繋がると嬉しいです！ 書いてて思いましたが、Reviewerから求められるPR作成術も気になりますね （余力があればまとめます笑）   最後までお読みいただきありがとうございました！！

こんにちは。新卒エンジニアのけんてぃです。 7月に技術推進委員会が運営している「WP HACK DAY」の第6回目に参加しました！ 今回は、新卒エンジニアが「WP HACK DAY」を通して学んだことを紹介します。 目次 1.　WP HACK DAYについて 2.　 WP HACK DAY での初挑戦 3.　 先輩方に WP HACK DAYについてインタビュー 4.　 最後に 1. WP HACK DAYについて 当社はビジョンに「21世紀を代表するブライダル会社を創る」、ロードマップに「技術とデザインのウエディングパークを創る」を掲げています。それらを実現していくために 「クリエイターの一体感作り」 と 「技術挑戦の機会作り」 を目的としてWP HACK DAYを開催しています。 (引用： https://engineers.weddingpark.co.jp/wp-hack-day_6/ ) ※過去の WP HACK DAY の取り組みは こちら から見ることができます！！ 2. WP HACK DAY での初挑戦 ペアプログラミング 私自身入社して初めてのチーム開発だったため、先輩エンジニアとペアを組む ペアプログラミングをしながら理解する方向で開発しました。 実際にペアプログラミングをやってみて ペアプログラミング自体も初めての経験でしたが、 先輩エンジニアと一緒に開 発することで、開発まで一連の流れを理解しながら進めることができまし た。 どこが理解できていないのか、どういう処理が必要なのかなどがわかり、と ても良い経験をすることができました。   3.　先輩方にWP HACK DAYについてインタビュー   先輩方が 「WP HACK DAY」 開発中に意識したことについて WP HACK DAYでは、プロトタイプ以上のものを作成するルールがあります。プロトタイプ以上のものを作成するには、スピードが重要です。どのように開発するのが近道なのか？を意識しながら実装しました。特に、実装中に「こういう実装がかっこいい」や「こういう思想でプログラムは書くべき」などの自身の考えはノイズとなることが多いので、「プロトタイプ以上のものを作成する」というところだけを意識し、それ以外は後回しにするよう専念しました。（時間が余ったらリファクタリングするなど） 今回のWP HACK DAYのテーマが「 ビジョン実現につながるもの」 だったので、僕たちのアクション・アウトプットが、 そこに しっかりつながるのか、を考えていました。   「WP HACK DAY」での開発中のコミュニケーションで大切にしていること 相談する場合は、自身の状況をできるだけ細かく伝える 自分自身に起きていることを相手がどれだけ理解できるかで、その後の解決 策の話し合いの具体性が変わります。中途半端にしか状況を伝えられない と、 質疑応答が多くなってしまったり、方向性の異なる解決策を提示された りと、想定外の時間の浪費につながってしまいかねません。どんなにスキル の 高い人と同じチームであったとしても、中途半端なコミュニケーションは 上記のような状況を発生しかねないので、細かな情報共有を心がけていま す。 相談や質問に回答する時は、小学生に教えるつもりでコミュニケーションを取る 自分の知っている知識を相手が全て知っているとは限らないので、足並みを揃えたり、相手のおかれている状況を正しくかつ迅速に理解するためにも、 わかりやすい言葉を使うよう心がけています。 役割を考えるようにしている 開発全体のタスクの中で、自分が期待されていること、メンバーに期待されていること/していること。そこを考えながら、任せられるところはしっかり 任せ、信頼することを意識したコミュニケーションをとることが多いです。   4.　最後に 「WP HACK DAY」を通して、開発に対する理解を深めるとともに、先輩方の開発を近くで見ることで、たくさんの学びを得ることができました。 普段あまり関わることのない先輩とチームを組み開発することで、新たな気づきや開発中での考え方を お聞きすることができ、自身の成長に繋げることができました！！ 運営メンバーの皆様、同じチームメンバーの皆様本当にありがとうございました！

初めまして。結婚指輪・婚約指輪のクチコミサイト 「Ringraph」 でエンジニアをしているふじしーと申します。 この記事は先日社内で開催された 「WP HACK DAY」 での開発内容や、エンジニア、デザイナー横断での開発での学びを共有できればと思います。   目次 課題 作成内容 開発での学び 最後に   1.課題 社内ハッカソン、WP HACK DAYでは「クリエイターの一体感作り」と「技術挑戦の機会作り」を目的とし、毎回テーマを変えながらデザイナーエンジニア横断で4人1チームのチーム開発を行います。 第6回目のテーマは 「ビジョン実現につながるもの」   ウエディングパークでは 「21世紀を代表するブライダル会社を創る」 というビジョンを掲げています。     またビジョンとは別に、ビジョン実現に向けどんな組織でありたいか、どんな未来を創っていきたいのか、部署や部門単位で認識を合わせるために 「ありたい姿」 を定めています。 例:弊社サービスRingraphのありたい姿 これをチームで決めることで共通認識を得られたり、組織としての一体感が増します。   しかし共通認識として持っていても、実際にそのありたい姿に対してアクションできているのか。アクションできていたとしても、それがビジョン実現に近づいているのかはなかなか感覚では分かりずらいという問題がありました。   そこで実際にそれぞれの部門や部署でありたい姿になるためにアクションしたことを投稿する仕組みを作成しました。   2.作成内容 ウエディングパークではプロフっちょという各部門ごとに社員のプロフィールが見れる社内ページがあります。この部門ごとのページにありたい姿の投稿フォームを追加しました。 プロフっちょの一覧ページ   入力ページ   ありたい姿やそのために実施したアクションも入力できます   実際にアクション投稿数が多くなると… 投稿後の画面   さきほどはピンクの坂道だったものが、緑の坂道が増えていますね！ アクションが増えれば、坂を登っていけるような仕様にしました。このように、ありたい姿になるためのアクションによってビジョン実現へ近づいていくことを表現しています。   また他部署がどのようなアクションを行っているか、その進捗も確認できます。 部署は違えど全社ビジョンの実現を全員で目指している感覚が得られるような仕組みにしました。   3.開発での学び 今回、エンジニア、デザイナーそれぞれ４人とも技術挑戦をするというテーマもありました。 デザイナーがエンジニアとハンズオンでLaravelを触ったり、逆にエンジニア側がデザイナー領域であるSaaSを触ったり。 日々の業務では触れる機会のないお互いの領域を学び合うことができたのは今後の業務にも活きそうです。 実際に対面で開発することによる学びが沢山あり、非常に勉強になりました。   また当日7時間という時間で作り切る中で、途中想定していた全ての機能を入れることは難しくなりました。 しかしチームで話し合って機能を削ったり、代案を考えたりして調整することでなんとか形にして間に合わせることができました。 改めてチーム開発では密な会話が大切だと実感しました。 この規模、かつ短い時間だったのでかなり密な会話が可能でしたが、より大きなチーム開発でも意識していく必要があると思いました。   4.最後に 皆さんも目標を作ったり、宣言をしたりすることがあると思います。 でも実際は宣言だけで終わってしまったり… 今自分が目標に対してどのくらいの進捗なのか分からなかったりします。 特に数字など分かりやすい指標がない目標は難しいと感じています。そこでこのような仕組みを作成してみました。   もちろん今回の仕組み作りで、アクションの投稿数がたくさん集まる=ビジョン実現 とは必ずしもならないと思います。 ですが進捗を追ったり積み上げが見える仕組みを作ることで、アクションが活発になったり、意欲が湧くと思います。 また宣言して終わりでなく、目標を意識する時間が増えます。 一人一人の小さな行動が変わることによってより目標に近づきやすくすることができるのかなと、今回の施策を通して感じました。  

こんにちは！ウエディングドレス選びがもっと楽しくなるクチコミサイト「 Wedding Park DRESS 」のデザイナーをしています、かおりん（ @PANbooooo ）と、新卒1年目エンジニアのなりりんです（過去に書いた記事は こちら ）！ 先日行われた社内ハッカソンイベント「WP HACK DAY」にて、私たちのチームは、「クリエイターの頑張りを視覚化するクリエイティブ」を作成しました。今回はそのクリエイティブを作る過程での学び等をご紹介したいと思います。 WP HACK DAYとは？ 当社が掲げている「21世紀を代表するブライダル会社を創る」というビジョンと、「技術とデザインのウエディングパークを創る」というロードマップを実現してくために、「クリエイターの一体感作り」と「技術挑戦の機会作り」を目的として開催している社内イベントとなります。 WP HACK DAYについての詳しい内容については こちらのブログ を参照ください。 今回は「ビジョン実現につながるもの」をテーマに、触れたことのない技術を持ち寄りながら、限られた時間の中でクリエイティブを作成しました。 課題の洗い出しと解決方法について まずはビジョンをもとに、普段の業務や仕事を進める上で感じる課題についてをブレストしていきました。 洗い出しした課題は「サービスに関わること」「仕事に関わること」「職場に関わること」と、大きく３つにカテゴリー分けすることが出来ました。 次に、ひとつひとつの課題に対して、「どうなって欲しいのか / どうしたいのか」をもとに、その解決方法を丁寧に考えていきました。解決方法は、各々の出来る / 出来ないなどのスキル面に縛られずに自由に考えるようにしました。 全ての課題に対する解決方法を考えたのち、今回のイベントでは「クリエイターの頑張りを他職種に伝わるようにする」を、クリエイティブの力で解決したいこととして選びました。 この背景には、「ビジョンにある“21世紀を代表する”を叶えるためには、今後求められるものは“技術力”と“デザイン力”であり、この技術力とデザイン力はクリエイターのみならず、非クリエイターを含めた全社に知ってもらう必要がある」と考えたからです。 実際に作ったクリエイティブについて 作成したクリエイティブは以下になります。 タイトル画面になります。コーポレートキャラクターを用いることで、ふと見た時に癒される画面デザインにしました。 当社のロゴに用いられているハートがコーポレートカラーで塗られていくことで、「クリエイターの今日の頑張り度」を表現した画面になります。1日のコミット数やコメント数などに対してある程度の目標数を設定し、それを100%としています。 上記の頑張り度の詳細画面になります。GitのMR数やリリース数、コミット数などが表示され、数字でもクリエイターの仕事ぶりを知ることが出来ます。 対応内容の詳細 【エンジニア側】 ・GitLabからマージリクエスト数、コミット数などを取得 ・デザインへの埋め込み 【デザイナー側】 ・画面のデザインと実装 ・css3アニメーションの実装 大変だったこと 【エンジニア側】 ・GitLab APIを使用した実装 GitLab上のマージリクエスト数やコミット数などを取得するために、GitLab APIを使用しました。 私はGitLab APIを扱うのが初めてだったので、最初は同じチームの先輩に教えてもらいながら仕組みを理解するところから始めました。 GitLab APIでは、パラメータを渡すことでデータを受け取ることが出来ますが、どのパラメータを渡せば欲しいデータを取ることができるかを考えるのが難しく感じました。ドキュメントを読み込み、色々なパターンで試しながら実装を進めていきました。 【デザイナー側】 ・調べながら進めたcss3アニメーション 今回はJSを利用せずにcssのみでアニメーションを実装することにしました。css3アニメーションは業務の中で使用することも無かったため、未経験に近い状態でした。そのため、自分が作りたいものに近い情報を探す「検索力」が肝となりました。「css3アニメーション 波」と検索すると、いろんな参考サイトが表示されますが、なかなか表現したいアニメーションが出て来ず、様々なワードで検索をしたり、普段よく見るコーディングナレッジのまとめサイトなどを参考に進めていきました。 こだわったこと 【エンジニア側】 ・表示速度を意識！ APIでデータを取得して画面上に埋め込む際、データを取得し終えてからページを表示させると読み込みに時間がかかってしまい、UXが悪くなってしまうと考えました。 そこで、非同期通信でJSON形式でデータを取得し、JavaScriptを用いて画面上に埋め込む、という実装方法を採用しました。 ただ、APIを呼び出してからデータが返ってくるまでに時間がかかってしまう時もあったので、取得時の速度も改善できるとより良いと思いました！また機会があれば挑戦してみたいと思います。 【デザイナー側】 ・画面の中でキャラクターを生かす！ 解決方法を考えるミーティングの中で出た「キャラクターを飼いたい！」という意見が忘れられず、サイネージの中に、キャラクターの寝ている姿や喜んでいる表情などを盛り込むことで、キャラクターが画面の中で生きている感じを演出しました。「ランチ時間にはご飯を食べて欲しい」や「マージ数が増えたらおやつをあげたい！」などの意見も出てきましたが、限られた時間の中では詳細を詰めることが難しく・・・涙。こちらはまた次回のHACKDAYでカタチにできればと思いました！ まとめ 今回は短時間で、ビジョンから自分たちが課題と感じていることを見つけること、そしてそれをカタチにすることを進めてきましたが、技術を軸にビジョンと向き合う時間はなかなか無かったため、新しい気づきを得た貴重な時間となりました。 デモ画面作成においても、自分自身の苦手としていた技術や興味があったけどなかなか手を出せずにいた技術を触るきっかけとなり、エンジニア及びデザイナーにとって成長に繋がる時間となりました。 作成したデモ画面を発表時にお披露目すると、「かわいい！」や「おもしろい！」などの声をいただき、とても嬉しかったです。 もう少し企画の部分からブラッシュアップをし直して、いつかは実際に取り入れたいと思います。

初めまして。 入社6ヶ月目の新卒デザイナーぴろせです。 今回は先日開催された「 WP HACK DAY 」の第6回でチームで取り組んだ内容のレポートをしようと思います。 ウエディングパークの日報文化や社内の雰囲気や当日の雰囲気、新卒デザイナーが先輩エンジニアに混ざって感じた等身大の想いが伝わったら嬉しいです。   また、GmailとSlackを連携するにあたり Slack API やLambda, Gmail API などを活用したので、ユーザーのアクションをトリガーとしてメールのデータを取得したいと 思っている方の参考にもなればと思います。   目次 1.WP HACK DAYと取り上げた課題 2.成果物 3.当日の様子 4.最後に   1.WP HACK DAYと取り上げた課題 WP HACK DAYは、ウエディングパークのエンジニア・デザイナーの技術力向上と一体感醸成のための1dayハッカソンです。 今回実施した第6回目では「ビジョン実現につながるもの」をテーマに4人1チームのチーム開発形式で実施しました！ (弊社のビジョン＝「21世紀を代表するブライダル会社を創る」） 詳しいルールなどは別途発信している WP HACK DAY 第6回の記事 をご覧ください。   取り上げた課題 ビジョン達成に向けて常に走り続けているウエディングパークは、確実に日々成長していますが、社員一人ひとりが成長を実感しながら進むことができているのかはわかりません。 3ヶ月毎に振り返り面談がありますが、より高い山を目指していくためにもっと長い目で過去を振り返って自分の成長や現在地を把握することが重要だと思います。 そこで、私たちのチームでは日報に目をつけました。   ウエディングパークには日報文化があり、毎日社員がその日にあったことを日報で振り返り、Gmailで 全社員に発信しています。 ただの業務振り返りではなくそこから自分が学んだこと・今後の宣言を記述して、それが毎日社員間で読まれていて「昨日の日報アツかったね」「その話、日報にも書いてたよね」なんて会話が当たり前のようにされており、ウエディングパークにとっては日報は社内のコミュニケーションツールの1つなのです。   毎日送信している日報は、過去を振り返るにはぴったりです。 しかし、過去を振り返るには手間が多くハードルが高いです。もっと、気楽に振り返ることができればきっかけを提供するだけで日報を使って過去の自分を振り返ることができるはずと考えました。   設定したゴール 社内での連絡はSlackを使っているので、Slack内で日報を振り返るきっかけを与えられる仕組みを作ることをゴールに、HACK DAYではプロトタイプを作成しました。 ↓　課題・戦略・戦術のまとめ ※Collaさんとは…Slackに導入できるアプリ ︎   2.成果物 HACK DAYを経て出来上がったものはこちらです。( るっくばっ君とやりとりをしながら進んでいくので順を追ってご説明します。) ①Slack内で「るっくばっ君」というアプリから「過去の日報を見ないか」という趣旨のメッセージが送られてきます。 ②下部にある緑の「ちょうだい！」ボタンを押すと該当者の数年前の日報をランダムで表示してくれます。( 一番最後のURLにアクセスするとGmailにとんで日報への返信を見ることができます。) ③その後間髪入れずにるっくばっ君からコメントがきます。   るっくばっ君のコンセプト 今回、登録されたある程度性格を作ったアプリから一定期間で「過去の日報見てみない？」と提案される形式にしました。 デフォルトの「Slack bot」という名前で送信しても問題はないのですが、それだとなんだか愛着が湧かず面白みもありません。 「いかに振り返ってみようかな」と思ってもらうかが重要なので、キャラクター性のあるアカウント名と名前を採用しました。   まず、名前は「るっくばっ君」。 HACK DAYまでの準備期間メンバーから「look back nippo!」というワードがでて、「るっくばっ君」可愛いじゃんとあっさり決まりました。 また、るっくばっ君のアイコンは鳩にしました。 鳩は伝書鳩や鳩時計のイメージがあり、「ある一定の期間を経てメッセージを届けてくれる」というコンセプトにぴったりだと感じたからです。 さらに、るっくばっ君からメッセージが送られてきた時に 「ちょうだい!!」ボタンを押してもらうためにUXライティングに挑戦しました 。 ↓押してもらう前の呼びかけセリフ(4パターン) ↓日報送信後のセリフ(4パターン) UXライティングにおいては、下記の4点を意識しました。 ・短く簡潔にする(多くても5行) 　→長すぎると読む気がなくなってしまうため ・視認性を高める(定期的に改行) 　→ダラダラと1文を続けるとPC画面だと読みにくいため ・一貫性を保ち過剰な敬語にしない 　→鳩というコンセプトに対しての一貫性と言葉遣いで親近感を感じてもらう ・ポジティブな表現にする 　→朝に送られる設定だったので、少しでも気持ちが前向きになる表現を選択 3.当日の様子 当日は1日(約7時間)の間でプロトタイプが完成できるようにメンバー全員で手を動かしました。 HACK DAYの中でそれぞれが技術挑戦することは必須になりますのでメンバー4人全員が今までやったことがない領域にチャレンジしました。 ↓チームメンバーの挑戦領域 この1日で成果物で記述したるっくばっ君の仕組みを作り上げましたが、仕組みを図解したものがこちらです。 Lambda で定期的に S lack apiを使ってるっくばっ君として社員にメッセージを送信します。「ちょうだい!!」ボタンが押されたらLambda ・Gmail API を介して該当社員の過去の日報データを参照、そのデータを再びるっくばっ君として送信します。   プロトタイプ作成にあたり、社員はSlackで送信されることを想定せず日々日報の送信を送っているので、Slackで送信するにあたっての整形やデータの取得、認証まわり、いかにこのサービスを使いたいと思わせるかの工夫がメンバーにとっての壁になりました。   メンバーそれぞれの苦戦ポイントはこちら↓   4.最後に 今回、私は新卒として・チーム内唯一のデザイナーとして参加しました。 HACK DAYは技術挑戦を目的に行われておりますが、日々業務がある中で「新しい技術に挑戦してみよう」という機会がなかなかないのでとても良い取り組みだと感じました。 また、エンジニアの先輩に囲まれて参加したのだから、もっとエンジニアの領域に挑戦してみればよかったと悔いが残ります。 もちろんデザイナーとしてやったことがなかった技術領域に挑戦できた良い機会はありましたが、周りの環境を存分に活かした動きがもっとできたように思うので、次回はぜひまだ触ったことのないJSやコードに触れてみたいと思います。

こんにちは。フォトウエディング・前撮りのクチコミ情報サイト「 Photorait(フォトレイト) 」のエンジニアリングマネージャーをしている武田( @takedajs )です。 当社では経営とクリエイターの結節点となる動きをする技術推進委員会という組織をエンジニアリングマネージャーが中心となって運営しています。 今回は技術推進委員会が運営しているクリエイターの社内ハッカソンイベント 「WP HACK DAY」 の第6回目を開催したので紹介します！ 目次 WP HACK DAY とは？ 前回(WP HACK DAY #5)との変更点 当日の様子 参加者からのフィードバック 最後に WP HACK DAY とは？ 当社はビジョンに「21世紀を代表するブライダル会社を創る」、ロードマップに「技術とデザインのウエディングパークを創る」を掲げています。それらを実現していくために 「クリエイターの一体感作り」 と 「技術挑戦の機会作り」 を目的としてWP HACK DAYを開催しています。 これまで以下のテーマに沿ったものを開発してきました。 第1回目テーマ Slackを活用して、社内の誰かの仕事を便利にする仕組みをつくる！ 第2回目テーマ 開発の課題解決やタスクの効率化、技術検証など、やりたいけど出来ていないこと 第3回目テーマ 業務課題を解決するプロダクト開発 第4回目テーマ 業務課題を解決するプロダクト開発 第5回目テーマ 日々のお仕事がちょっぴり楽しくなる何か 今回実施した第6回目では、ビジョン実現を加速させるために 「ビジョン実現につながるもの」 をテーマに実施しました！ WP HACK DAY #6のルール ・ 参加者：全社クリエイター(エンジニア・デザイナー) ・ 4人1チームで1日(約7時間)で取り組み、夕方に成果発表会(デモ実施必須)を実施 ・ 普段業務で関わらないメンバーの組み合わせで運営がチーム決め ・ 事前に当日開発するものを検討し、実装可能か調査(MTGも含め週1時間のみ) ・ 当日はプロトタイプ以上のものを開発 (後日、本番導入まで実施予定) ・ 参加方法はオンライン&オフラインどちらでも可(オフライン推奨) 前回(WP HACK DAY #5)との変更点 運営の振り返りや参加者のフィードバックをもとに前回から何点か運用を変更しました。 【メインビジュアル&Tシャツ作成】 新たに運営に新卒1年目のデザイナーが加わりました。目的の1つであるクリエイターの一体感をより強化していきたいと考え、メインビジュアルをもとにTシャツを作成しました！ 【社内告知の強化】 開発したものを発表する成果発表会にクリエイター以外の方がもっと参加してほしいという参加者の声が多くありました。チームごとの意気込み動画や過去に成果発表会に参加してくださった方のインタビュー動画などを撮影し、開催の2週間以上前からほぼ毎日全社Slackチャンネルに投稿！ 【技術挑戦が必須】 テーマに沿って開発するだけではなく、技術挑戦する機会にもしてほしかったので、今回から1人最低1つ以上の技術挑戦を必須にしました！ 当日の様子 全体のスケジュール 開会式(9:30-9:40) 午前の開発(9:40-12:00) ランチタイム(12:00-13:00) 午後の開発、発表資料作成(13:00-17:00) 成果発表会(17:00-18:00) クリエイター以外の方も数十名オンラインで参加してくださいました！ 発表されたプロトタイプ ・アニメーションを使ってユーザー体験向上 ・るっくばっ君 ・ドキドキマッチングガチャ ・出社管理表運用の自動化 ・社内サイネージでクリエイターの活動を伝える！ ・KICOCA〜あなたの声、聞こか？〜 ・輝きウエパーソンエールズ ・プロフっちょにありたい姿を見える化 ・音声領域プロトタイプ 懇親会(18:00-18:30) ※任意参加 参加者からのフィードバック 次回のイベントをより良い機会にするために、参加者に匿名アンケートを回答してもらいました！ ※ 全体の満足度平均4点(5点満点) 良かった点 触れたことがない技術に挑戦できた。週1時間のルールがあり事前の準備がほぼできなかったので当日不安もあったが、お互いの力を合わせて開発できた。 人数が増えても一貫してモノづくりを楽しむ雰囲気、モノづくりを通して会社に貢献する意欲を高める時間を過ごせた。Tシャツでの一体感も最高で、クリエイター以外の参加者も多くて嬉しかった。 シンプルに楽しかったし、エンジニアとチームを組むことで、エンジニアが普段どんなことをしてるのかを知れる機会になった。 改善点 アイデアや技術調査に関しては週に１時間を守って作業できた。しかし当日の週だけ、実装できるかの確認のために３時間ほどかけてしまった。 参加人数が多くなってきたので、オフィスをうるさくしてしまっているのではないか少し心配。オフィス以外で場所を借りて実施を検討してはどうか。 本番導入することをルールにすると、思い切った技術挑戦することができない。アイデアも社内向けのものが多くなってしまう。 最後に クリエイターの一体感作りと技術挑戦の機会作りを目的としたWP HACK DAYの第6回目について紹介しました。 運営の振り返りや参加者のFBからより良いイベントになるために次回やるべきことが見えてきたので、更にワクワクするイベントを開催したいと思います！

こんにちは。 Photorait エンジニアのヒエイです。 octocovをGitHub Actionsで使ってテストカバレッジを監視している話をします。 octocov https://github.com/k1LoW/octocov テストカバレッジ値やテストコード実行時間を管理できるツールです。特徴的なのがメトリクス一覧やラベルバッジ作成を行えるだけでなく、Github上だけで監視ツールとして完結できるところが便利だと感じています。 octocovはGithub Actionsと連携することで、テストカバレッジ情報の生成を行えます。 Pull requestとoctocov Github Actionsでテストを実行し、テストカバレッジ値をPull Request（以下PR）で表示することができます。 以下例では、PHPUnitを実行してPRにテストカバレッジを表示させます。 まずアプリケーションに .octocov.yml ファイルを用意します。 coverage: paths: - coverage.xml codeToTestRatio: code: - 'app/**/*.php' test: - 'tests/**/*Test.php' testExecutionTime: if: true diff: datastores: - artifact://${GITHUB_REPOSITORY} comment: if: is_pull_request report: if: is_default_branch datastores: - artifact://${GITHUB_REPOSITORY} Github Actions用のworkflowファイルはこちら。 # .github/workflows/phpunit.yml name: phpunit on: pull_request: jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: exec phpunit run: vendor/bin/phpunit --coverage-clover coverage.xml - name: Run octocov uses: k1LoW/octocov-action@v0 octocovでサポートされているカバレッジフォーマットは以下に載っています。 https://github.com/k1LoW/octocov#supported-coverage-report-formats PHPUnitではcloverでカバレッジレポートを作成できるので  --coverage-clover coverage.xml としています。 この状態でPRを作るとこうなります。   さらに .octocov.yml ファイルに以下を追加します。 body: if: is_pull_request とするとPRのメインコメントエリアにカバレッジ情報をコメントしてくれます。   また、 summary: if: true を追加すると、GitHub Actionsのワークフローjob内にコメントをしてくれます。   このように、例えばコードレビュワーに対してもテストカバレッジ値の変化を見せた上でレビューしてもらうことができるのです。 Centralモード さらに便利なのが、Centralモード https://github.com/k1LoW/octocov#central-mode リンク先の画像の解説がわかりやすいですが、 例えばカバレッジ監視する A・B・C のリポジトリに対して、 central という別リポジトリを設けたとします。 その central リポジトリが、 A・B・C のカバレッジ値を集計して監視させることができます。 集計先は central リポジトリ側で行うこともできますし、S3やBigQueryなどに置いて別ツールを立てて管理することもできます。 Photoraitでは central リポジトリ自身を集計先として使っていますので、そのベーシックなやり方を紹介します。 やり方はすごく簡単。 https://github.com/k1LoW/octocovs-template このテンプレートから Create new repository してCentralモードとして稼働させるリポジトリを立ち上げます。 central リポジトリの .octocov.yml ファイルを central: reports: datastores: - artifact://集計したいリポジトリA - artifact://集計したいリポジトリB - artifact://集計したいリポジトC badges: datastores: - local://badges push: enable: true の形で記述し、コミット・プッシュをするだけです。 Github Actionsのワークフローが動き、Readmeファイルが以下のように表示されます。 あれ、、、バッジが表示されてるはずの画像が表示されていませんね・・・ こちらは調べたところ、 central リポジトリがprivateリポジトリだとこうなってしまうようです。ここは対応されるのを待ちましょう。。。 こちらは 修正アップデート されていました！大変有難いです！   バッジは、 badgesディレクトリ 以下に生成されたバッジがコミットされています。素晴らしいですね。 このバッジを集計対象のリポジトリに貼ることができますね。    こんな感じで各リポジトリでバッジを表示できます。 利用してみて 私たちも最近使い始めたばかりですが、とても便利で、簡単で、カバレッジ値監視が嬉しいです。 ぜひ読んだ方も試してみてください。

こんにちは、おのぽんです。 Tweets by onopon_engineer   最近暑さが続き、僕もついにハンディファンを購入しました。 みなさまいかがお過ごしですか？？   さて、今回は僕の在籍するプロジェクトでの「CodeIgniterのテストコードでattributeを活用してみたお話」を綴っていこうかと思います。 CodeIgniterは、現在僕の所属するプロジェクトで利用しているPHPのフレームワークで、attributeはPHP8.0より利用可能となった機能です。 今回はそんなattributeをテストコードの中で活用してみたお話となります！ （文章多めとなってしまいますが、ぜひお付き合いくださいmm）   現状 弊プロジェクトで書いているテストコードには、テストケース毎にテストデータを該当のテーブルにinsertすることがあります。 それらのデータはテストケース終了（=tearDown）時に対象のテーブルをtruncateしています。     課題 tearDown 時でtableのtruncateを明示しないといけず、忘れてしまうと全然違うテストケースのテスト実行に影響を及ぼしてしまう 可能性があります。 （例えば、単体でテストを実行すると通るのに、全体で実行するとなぜか通らなくなるみたいな状況が起こり得てしまう状況です）   実現したかったこと tableのtruncateを明示せずとも、tearDown時に勝手に綺麗になっていて欲しい と思いました。 例えば、LaravelのテストコードにはRefreshDatabaseのような機能があるのですが、CodeIgniterでは（というよりも弊プロジェクトでは）利用できない状況でした。 ※ RefreshDatabase を使うと、テストケース開始（ = setUp）時にtransactionを貼り、tearDown時にrollbackしてくれるので、truncateなどの明示をすることなくtableをクリーンな状況にしてくれます。便利。 弊社でもRefreshDatabaseのような状況を実現すべく早速実装に踏み込んでみました！     思い通りに行かなかった点 が、一筋縄ではいかない点がちらほら。。   ロジックによってmasterやslaveにアクセスしてしまう transactionはcommitされなければ、新たにDBにconnectionを作ってもデータを見つけることはできません。 そのため、masterやslaveなどDBのconnectionが複数発生するロジックのテストケースでは実現できませんでした。   Controllerのテストだと同一のconnectionが利用できない 先ほどと事象は異なるものの、似たような状況が発生してしまい実現できませんでした。 擬似requestを送ってControllerの挙動を確認するようなテストを書いているのですが、擬似requestを送る前にテストデータを用意しようとすると、 テストデータを用意した際のDBへのconnection 擬似requestによりアクセスを試みるDBへのconnection が異なってしまい、用意したテストデータがcontroller側で見つからないという状況となってしまいました。   ここでattributeの出番 ここで本題です。たまにイレギュラーで思い通りにいかないケースもあるものの、少なくともmodelやlibraryのテストケースではほとんど正常にtransactionによるデータの消去を行うことができました。   なので、イレギュラーとしてtransactionを組めないものに関してはattributeを付与し、transaction処理を行わないようにする実装を行いました。 そもそもattributeとは attributeとは、PHP8.0より利用可能となった機能で、Javaのannotationのようなものです。 https://www.php.net/manual/ja/language.attributes.overview.php   なぜattributeを選定したのか？ 使ったことのない機能を触ってみたい という思いもありましたが、attributeを利用することで、 不要なロジックを抑えることができる と感じたためです。 コードを書く上で、本質的なことを伝える以外のことがたくさんかかれてしまっていると、「結局このコードは何をやっているのか」みたいなあたりが見えづらくなってしまいます。 テストコードのように、準備や後処理が必要となる場ではこれらの問題が出やすいので、今回のattributeのように「付与されてれば◯◯な状態になる」ということを簡単に明示できるのは可読性や運用に優れているように感じたため、選定しました。   今回の登場クラスとロジック WithoutRollback クラス attributeです。このattributeを付加したメソッドはロールバックをしない（=setUp時にtransactionを組まない）状態になるようロジックを組みます。 #[Attribute(Attribute::TARGET_CLASS | Attribute::TARGET_FUNCTION | Attribute::TARGET_METHOD | Attribute::IS_REPEATABLE)] class WithoutRollback { } attributeとしての宣言なので、メソッドなどは特に持たせておりません。   TruncateTables クラス こちらもattributeです。このattributeを付加したメソッドはtearDown時に指定されたtablesのtruncateを行います。 #[Attribute(Attribute::TARGET_CLASS | Attribute::TARGET_FUNCTION | Attribute::TARGET_METHOD | Attribute::IS_REPEATABLE)] class TruncateTables { function __construct($tables){ } } こちらもattributeの宣言ではありますが、WithoutRollbackと異なる点として、コンストラクタの宣言をしております。 これは、TruncateTablesのattribute付加時に「どのtablesをtruncateするか」を一緒に宣言できるようにするためです。   AttributeUtil クラス traitです。ExampleTestクラスで呼び出して、attributeが付加しているかなどのチェックを行うための実装を行っています。 trait AttributeUtil { /** * @param string $attributeClass * return array */ protected function getAttributes($attributeClass) { $cls = new ReflectionClass($this::class); $clsAttributes = $cls->getAttributes($attributeClass); $handleMethod = $cls->getMethod($this->getName()); $methodAttributes = $handleMethod->getAttributes($attributeClass); return array_merge($clsAttributes, $methodAttributes); } /** * @return bool */ protected function withoutRollback() { return (!empty($this->getAttributes(WithoutRollback::class))); } /** * @return array */ protected function getTruncateTables() { $attributes = $this->getAttributes(TruncateTables::class); if (count($attributes) == 0) return []; $tables = []; foreach($attributes as $attr) { $tables = array_merge($attr->getArguments(), $tables); } return $tables; } } getAttributes($attributeClass) 今回のattribute取得を行うための、根幹となるメソッドです。 クラスやメソッドに付与されたattributeを取得することができます。 $attributeClass の文字列を付与することで、attributeの実態を含む配列が返ってきます。 ここで返り値を配列とすることで、後にTruncateTablesのattributeに付与されたtable名を取得できるようになります。 余談ではありますが、このメソッドはsetUpやtearDownで利用されることを想定して組んでますが、 $handleMethod で利用している $this->getName() ではテストケース名が返ってきます。（setUpやtearDownという名前は返ってこない） そのため、テストケースのどこでgetAttributesメソッドを叩いても、期待したattributeを取得することができます。 withoutRollback() WithoutRollback attributeが付与されているかどうかを確認するためのメソッドです。   getTruncateTables() truncate対象のテーブル名を配列で取得できます。 TruncateTables attribute付与時に指定したtable名をここで全て取得できます。   ExampleTest クラス setUpでtransactionを組み、tearDownでrollbackする実装の書かれたテストクラスです。 ブログでの説明上、主にこのクラス上で今回の実装をご説明いたします。 class ExampleTest extends TestCase { use AttributeUtil; public function setUp() : void { parent::setUp(); if ($this->withoutRollback()) return; // ---- ① $this->db->trans_begin(); } public function tearDown() : void { foreach($this->getTruncateTables() as $table) {　　// ---- ② $this->db->truncate($table); } $this->db->trans_rollback(); parent::tearDown(); } public function testFirst() // ---- ③ { // ... } #[WithoutRollback] #[TruncateTables('users', 'roles')] public function testSecond() // ---- ④ { // ... } } 下記に、今回のポイントを絞って記載します。   if ($this->withoutRollback()) return; // ---- ① もし withoutRollback() がtrueの場合は、この時点でsetUpを終わらせます。 これにより、transactionを貼らない状況を作ることができます。   foreach($this->getTruncateTables() as $table) {　　// ---- ② TruncateTables attributeの付与がある場合、table名を取得でき、tearDownのタイミングで各tableをtruncateします。 attributeが付与されていない場合は、 getTruncateTables() の中身が空配列なのでtruncateは実行されません。   public function testFirst() // ---- ③ testFirst() には特に何のattributeもついていないため、setUp時に trans_begin() が実行されます。 tearDown時でのtruncateメソッドは呼ばれず、 trans_rollback() が実行されたタイミングで、testFirst() ロジック内でinsertされたデータは全てflushされます。   public function testSecond() // ---- ④ testSecond() には WithoutRollbackとTruncateTables attributeが付与されています。 そのため、testSecond()が実行される前の①でのwithoutRollback()はtrueとなるため、transactionは貼られません。 tearDown時で利用したtableのデータのtruncateを行いたいので、TruncateTablesによりtablesを明示します。 今回の例では、users、rolesの2つのテーブルが、truncate対象のテーブルとなります。   WithoutRollback, TruncateTablesのattributeを分けている理由 今回、attributeの役割を WithoutRollback: rollbackをしたくない時に付与する TruncateTables: truncate対象のtableを明示する のような形で役割を分けています。 もしここで、 #[WithoutRollback('users')] のように書けば、役割を統一することもできるようになるかとも思いますし、実装を悩んだところはあります。   しかし、今回controllerのように 全てのテストケースでロールバックを対象外にしたい truncateするtableは各々変えたい みたいな状況が起こりうる状況だったので、attributeの役割を分けてしまい、クラスにもattributeを付けられるようにすることで解決することを決めました。   下記に例を記載します。 #[WithoutRollback] class ExampleTest2 extends TestCase { // ... #[TruncateTables('users')] public function testFirst() { // ... } #[TruncateTables('roles')] public function testSecond() { // ... } }   例えば、ExampleTest2はclassそのものに WithoutRollback attributeが付与されています。 そのため、ExampleTest2の全テストケースでtransactionが貼られなくなります。 しかし、testFirstやtestSecondではそれぞれtearDown時でtruncateを明示しなければなりません。 今回の例では、testFirstではusersを、testSecondではrolesをtruncate対象とできております。   attributeの役割を分けることで、このようなattributeの付与の方法にアレンジを効かせられる状況を作りました。     いかがでしたでしょうか？ 今回は、Codeigniterで書かれたテストケースにattributeを活用してみた事例を紹介させていただきました。 弊社では、引き続き一緒に働いていただけるエンジニアを募集しております！ attributeの活用事例の議論はもちろん、 目標達成や事業の成長を一緒に感じたい チーム貢献 に尽力できて、またその成果も評価してほしい 自由に企画・提案 しながら社内にアクションを起こしたい という方がいらっしゃいましたら、是非一度弊社社員とお話させてください！ 最後までお読みいただきありがとうございました！！

こんにちは。ウエディングドレスのクチコミサイト「Wedding Park DRESS」のチーフエンジニアをしているたかしま（ @_at_tech ）です。 最近はオーディション番組から誕生した推しのグループがデビューして嬉しい日々です 今回はある案件でグラフを表示するためのライブラリ Chart.js Charts.css を検討・活用したので、そこで知ったことをまとめてみようと思います。 サイト内でグラフの表示を考えている方の参考になれば嬉しいです。 Chart.js https://www.chartjs.org/ https://www.chartjs.org/docs/latest/ 概要 JavaScriptでグラフ（チャート）を描画するためのライブラリ MITライセンスのため自由に扱うことができる 公式サイトによると「JavaScript向けチャートライブラリの中で一番人気」 特徴 様々なグラフ をきれいに描画することができる 比較的ドキュメントが充実している カスタムプラグイン を利用してカスタマイズすることができる グラフが <canvas></canvas> として描画されるので、CSSを使った細かいデザイン調整ができなかった（もう一方のCharts.cssはここが得意） 基本的な 記述形式（ドーナッツチャート） プログラム <div> <canvas id="myChart"></canvas> </div> <script src="https://cdn.jsdelivr.net/npm/chart.js"></script> <script> const ctx = document.getElementById('myChart'); new Chart(ctx, { type: 'doughnut', data: { labels: ['Red', 'Blue', 'Yellow', 'Green', 'Purple', 'Orange'], datasets: [{ label: '# of Votes', data: [12, 19, 3, 5, 2, 3], borderWidth: 1 }] }, options: { scales: { y: { beginAtZero: true } } } }); </script> グラフ 設定したオプション・プラグインなど カスタマイズするためのオプションは公式ドキュメントに記載されていますが、 思っていたより探すのに時間がかかってしまったので、つかったものを記載しておきます。 凡例の非表示 Chart.overrides['doughnut'].plugins.legend.display = false; ... new Chart(ctx, { tooltipの非表示 オンマウスした時に表示されるこれを非表示にします。 options: { ... plugins: { tooltip: { enabled: false, }, } } グラフの値を表示 以下のプラグインを使うことで、グラフ状に値を表示することができます。 chartjs-plugin-datalabels hover時の動きをなくす オンマウスしたときに色が濃くなったりするのをなくします。（tooltipはこれでも消えます） これはオプションではなく、cssで対象のグラフのクラスに以下を指定しました。 pointer-events: none; Charts.css https://chartscss.org/ 概要 CSSでグラフを描画するためのライブラリ MITライセンスのため自由に扱うことができる 公式サイトによると「従来のJSチャートライブラリをCSSフレームワークで置き換える」 特徴 現時点で正式対応しているのは棒／面／線グラフのみ Chart.jsに比べてドキュメントが少なかった グラフを <table></table> で表現するのでCSSをつかったデザイン調整ができる 基本的な 記述形式 HTML <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/charts.css/dist/charts.min.css"> <table id="bar-example-1" class="charts-css bar"> <caption> Bar Example #1 </caption> <tbody> <tr> <td style="--size: 0.2;"></td> </tr> <tr> <td style="--size: 0.4;"></td> </tr> <tr> <td style="--size: 0.6;"></td> </tr> <tr> <td style="--size: 0.8;"></td> </tr> <tr> <td style="--size: 1;"></td> </tr> </tbody> </table> CSS body { display: flex; justify-content: center; align-items: center; height: 100vh; margin: 0; } #bar-example-1 { height: 200px; max-width: 300px; margin: 0 auto; } グラフ HTML要素にclassを付与してCSSをあてることで、かなり自由度高くデザインをカスタマイズできます！ おわりに グラフを描画するためのライブラリ Chart.js, Charts.cssについて書いてみました。 わたしは、サイトに合うデザインのグラフをつくりたかったので、 棒グラフはCharts.cssでつくり、ドーナッツチャートはCharts.cssで正式版がなかったためChart.jsをつかいました。 それぞれの良さを活かしながら、活用していけたらと思います！

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