Another works Developers Blog

<p>こんにちは、Tomです！</p>
<p>今回は弊社 <a href="https://anotherworks.co.jp/">Another works</a> と <a href="https://commmune.jp/">コミューン</a> さん2024/02/14(木)に共同開催したイベント、<a href="https://anotherworks.connpass.com/event/306056/">Developers Meetup エンジニア組織が考える採用戦略</a>のイベントレポートをお届けします！！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/3fd73809-d8de-431b-963b-f2aacad2256e/6cdee27831adcd0a76681a5b33ade0d9.png" alt="6cdee27831adcd0a76681a5b33ade0d9.png"></p>
<h2>■登壇内容</h2>
<ol>
<li>前原 夏樹 様（コミューン株式会社） / 採用組織の武器の見つけ方、作り方</li>
<li>塩原 基弘（株式会社Another works）/ 複業転職が採用のスタンダードになるかもしれない</li>
<li>上野 大貴 様（コミューン株式会社） / 選考プロセスを通じて会社の魅力を伝えきるテクニック</li>
<li>宮内 北斗（株式会社Another works） / Another worksがエンジニアイベントにハマる理由</li>
</ol>
<h2>前原 夏樹 様（コミューン株式会社） / 採用組織の武器の見つけ方、作り方</h2>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/5079e255-87fb-43f7-aed8-3b52de09ce10/1000007108.jpg" alt="1000007108.jpg"><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/72b8ba82-c993-4039-a5dd-25d8ed601403/1000007110.jpg" alt="1000007110.jpg"></p>
<h3>内容</h3>
<ul>
<li>採用組織の武器とは
<ul>
<li>採用活動における魅力づけのための道具</li>
</ul>
</li>
<li>求職者が見つからない原因
<ul>
<li>魅力を伝えきれていないから</li>
</ul>
</li>
<li>なにを武器とするか
<ul>
<li>やりがい
<ul>
<li>会社と自分の方向性の一致</li>
<li>企業のビジョン</li>
<li>エンジニアとしての課題の面白さ</li>
</ul>
</li>
<li>環境
<ul>
<li>開発者にとっての快適さ</li>
<li>組織文化</li>
<li>刺激を受けられる同僚</li>
</ul>
</li>
<li>待遇
<ul>
<li>会社が開発者に敬意を払い、価値を感じているか伝えるもの</li>
</ul>
</li>
</ul>
</li>
<li>もし武器が見つからなかったり、応募されなかったら
<ul>
<li>同じ課題感を持つ仲間を見つけて、経営層を巻き込んで武器をつくる</li>
</ul>
</li>
</ul>
<h3>レポート</h3>
<p>採用担当者が自社の「武器」を見つけ、いかにして採用に繋げるかに焦点を当てた登壇でした。<br>
採用活動における魅力づけの重要性、求職者に対して会社の独自性を伝えることの大切さを学ぶことができました。<br>
また応募がない、求職者が集まらなかった場合は経営課題として経営層を巻き込んで採用組織の「武器」を作るのは、企業の文化形成にもつながり良い採用戦略の強化へ繋がると感じました。</p>
<h2>塩原 基弘（株式会社Another works）/ 複業転職が採用のスタンダードになるかもしれない</h2>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/5e3eef5c-b288-4908-8f89-c76ba142dac0/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-03-0619.43.19.png" alt="スクリーンショット2024-03-0619.43.19.png"><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/2028541c-1109-43c0-be76-b97f86a8d331/1000007111.jpg" alt="1000007111.jpg"></p>
<h3>内容</h3>
<ul>
<li>採用側のメリット
<ul>
<li>転職潜在層へのアプローチが可能</li>
<li>カルチャーマッチの判断が容易</li>
<li>オンボーディングコストの削減</li>
<li>社内エンジニアとの連携がスムーズ</li>
</ul>
</li>
<li>採用側のデメリット
<ul>
<li>転職までのリードタイムが長い</li>
<li>外注費用が発生する</li>
<li>マネジメント負担がかかる</li>
<li>運用難易度が高い</li>
</ul>
</li>
<li>求職者のメリット
<ul>
<li>入社後のギャップが少ない</li>
<li>転職活動のコスト軽減</li>
</ul>
</li>
<li>求職者のデメリット
<ul>
<li>選択肢の限定</li>
<li>転職までに時間がかかる</li>
</ul>
</li>
<li>複業転職採用のやり方
<ul>
<li>カジュアル面談後の選考以外の選択肢としての複業などアプローチを広げる</li>
<li>実際の事例として
<ul>
<li>AIアドバイザーの複業転職事例</li>
<li>エンジニアの複業転職事例</li>
</ul>
</li>
</ul>
</li>
<li>エンジニアのキャリア形成と複業転職について</li>
</ul>
<h3>レポート</h3>
<p>複業転職は通常の転職と比べ時間がかかってしまいますが、会社の表面的な部分ではなく企業文化や入社後のギャップを減らすことができる良い転職方法だと感じました。<br>
転職までに時間がかかってしまうものの、自分が本当に良いと思った会社や、メンバー、プロジェクトの中で働けるというのは何にも変えられないものだと思います。</p>
<p>企業としても積極的に転職活動をしていない潜在層へリーチを拡大でき、より高度な人材へのアプローチすることで、広い範囲へ採用活動をかけられます。<br>
複業転職の実際の事例としての紹介もあり、そのメリットの説得力がありました。</p>
<h2>上野 大貴 様（コミューン株式会社） / 選考プロセスを通じて会社の魅力を伝えきるテクニック</h2>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/091cf5dc-483f-4fe2-a86f-db8aaf9b9038/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-03-0619.44.58.png" alt="スクリーンショット2024-03-0619.44.58.png"><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/5d1cd6a2-fa7c-458e-a0ba-fdee0f313c3b/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-03-0619.45.08.png" alt="スクリーンショット2024-03-0619.45.08.png"></p>
<h3>内容</h3>
<ul>
<li>前提として
<ul>
<li>コミューンの開発部門は「チームコミューン」というTeamValueの下、専門性を伸ばすマネジメント方針</li>
<li>採用選考フローの中で候補者と会話する機会が限られている</li>
</ul>
</li>
<li>ゴールキック（アトラクト）は決められるやつが決めるべき
<ul>
<li>訴求活動はエンジニアリングマネージャー、採用マネージャーの仕事と捉えられがち</li>
<li>面接も貴重な候補者との会話の機会なので、ちゃんと訴求したい</li>
<li>面接の中でも訴求することを意識する</li>
<li>HiringManager以外もやる。面接時にやる。</li>
</ul>
</li>
<li>採用選考は個人の利と会社の利のマッチングであることを忘れない
<ul>
<li>活躍の是非の見極め、候補者への訴求の両立</li>
<li>面接を「候補者の合否を判断するだけの作業」と捉えない</li>
</ul>
</li>
<li>面接の事前整理
<ul>
<li>スキルマップの利用</li>
<li>指向性マップの利用</li>
<li>組織に不足している領域について能力・思考を整理する</li>
<li>会社が欲しい能力・候補者の強みになる能力を照らし合わせる</li>
</ul>
</li>
<li>具体的に候補者を評価しながら訴求するには
<ul>
<li>候補者にとって有意義な面接づくりを意識する</li>
<li>「この会社ならエンジニアとしていい刺激をうけられそう」と思ってもらう</li>
</ul>
</li>
</ul>
<h3>レポート</h3>
<p>選考プロセスでのアトラクトをどのようにするか、組織がどのような人材を必要としているか、という話でした。<br>
技術面接をエンジニア同士の情報交換の場とし、候補者の技術ポテンシャルや関心のある領域を知ることでまず選考として要件が満たされ、情報交換を通して候補者としても学びの場となるはずです。<br>
転職活動という多忙なスケジュールをこなす中で、面接をする前とした後で自身の知識や心持ちが変わるような会社はとても印象が良いですね。</p>
<h2>宮内 北斗（株式会社Another works） / Another worksがエンジニアイベントにハマる理由</h2>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/792f07f4-bfaa-4b43-a24d-539d1ea28661/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-03-0619.46.33.png" alt="スクリーンショット2024-03-0619.46.33.png"><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/bc586d50-3a06-4313-b834-d900ab27bdce/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-03-0619.46.42.png" alt="スクリーンショット2024-03-0619.46.42.png"></p>
<h3>内容</h3>
<ul>
<li>これまでのエンジニアイベントの運営・登壇実績
<ul>
<li>開催累計２２回</li>
<li>累計集客１３００人</li>
<li>実際にエンジニア採用に繋がっている</li>
</ul>
</li>
<li>イベントの狙いと役割
<ul>
<li>勉強会を主催している会社としての認知</li>
<li>イケてる取り組みをしている会社としての認知</li>
</ul>
</li>
<li>エンジニアイベントがハマるチーム
<ul>
<li>チームや開発体制に自信がある</li>
<li>知名度があまりない</li>
<li>エンジニアメンバーを採用に巻き込める</li>
</ul>
</li>
<li>採用マーケとしてのイベント施策の役割
<ul>
<li>認知や興味を持ってもらう入口として</li>
<li>他の採用施策の受け皿として</li>
</ul>
</li>
<li>イベントを活用したい人のステップ
<ul>
<li>イベントに登壇する</li>
<li>イベント共催に乗っかってみる</li>
<li>イベントを共催する</li>
</ul>
</li>
</ul>
<h3>レポート</h3>
<p>本イベントはエンジニアイベントですが「エンジニアイベントを採用のためにやってます！」という面白い登壇でした。<br>
Another worksは2年ほど前に社内イベントとしてイベントを開催してから少しずつ開催規模を大きくしてきました。<br>
弊社は開発チーム・開発体制に自信があり、今では大きな採用戦略のひとつとなっております！<br>
イベントを採用戦略へ組み込みたい！登壇してみたい！共催したい！とことがありましたら、是非Another worksへお声がけください！</p>
<hr>
<h2>■パネルディスカッション</h2>
<p>今回は登壇者４名によるパネルディスカッションを開催しました！<br>
リアルタイムにオーディエンスの方々からの質問を広いつつ、それぞれ登壇者の意見・見解を聞くことができる貴重な時間でした！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/91365a8d-965a-48da-b9f9-b3f24092f827/PXL_20240125_113113590.jpg" alt="PXL_20240125_113113590.jpg"><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/8aa0eb2e-6e71-4867-ab82-0dc56c7cd84c/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882024-03-0619.48.20.png" alt="スクリーンショット2024-03-0619.48.20.png"></p>
<h2>■交流会</h2>
<p>オフラインイベントの良さは、セッションで気になったことを登壇者に直接その場で聴くことができることや、熱量が冷めないうちに交流会で議論できることにあるのではないでしょうか？</p>
<p>エンジニア採用に関する話題を中心に大変盛り上がりを見せておりました！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/d6dc7a77-d944-4f2e-ae13-f91500a62243/1000007138.jpg" alt="1000007138.jpg"></p>
<h2>■さいごに</h2>
<p>Another works では今後も学びと交流の場となるイベントを開催していく予定です！<br>
Connpassでグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！<br>
<a href="https://anotherworks.connpass.com/">Another works Connpass</a><br>
今回、オンライン・オフライン同時開催のイベントでした！<br>
オンラインの良さもありますが、オフライン参加できる方はぜひ会場の熱量を肌で感じていただきたいです！<br>
オフライン参加できる方はぜひ会場でお待ちしております！</p>
<p>コミューンのみなさん、ご参加いただいたみなさん、本当にありがとうございました！</p>


Another works × コミューン【Developers Meetup エンジニア組織が考える採用戦略】イベントレポート

<p>Another works でエンジニアをしているまっちと申します！</p>
<p>今回は、弊社 <strong><a href="https://anotherworks.co.jp/">Another works</a></strong> と <strong><a href="https://wantedlyinc.com/ja">ウォンテッドリー</a></strong> さんで2023/12/14(木)に共同開催したMeet up イベント、</p>
<p><a href="https://anotherworks.connpass.com/event/300288/">成長ベンチャーの開発生産性、なにやってる？ 【Developers Meetup】</a>の様子をお届けします！<br>
ウォンテッドリーさんのオフィスで開催された今回イベントには、オンラインとオフライン参加者合わせて40名程度の方に参加いただきました！</p>
<p>ウォンテッドリーさんの素敵な会場！<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/0b651753-0740-478b-8121-9e302da905d3/1000006955.jpg" alt="1000006955.jpg"><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/ae582312-f331-46a0-9dc6-2d59f042d619/1000006959.jpg" alt="1000006959.jpg"></p>
<h1>■ 開催の背景</h1>
<p>イベントのテーマは <strong>”成長ベンチャーの開発生産性”</strong> でした。</p>
<p>どの開発組織においても</p>
<ul>
<li>開発生産性の測定や向上に悩んでいる</li>
<li>メンバーが自主的に開発生産性の向上に向けて取り組む組織を作りたい</li>
<li>将来開発組織のマネジメントに興味がある</li>
</ul>
<p>このようなテーマは関心が高いものではないでしょうか？</p>
<p>そこで今回</p>
<ul>
<li><strong>2019年創業 “複業クラウド” を運営している Another works</strong></li>
<li><strong>2010年創業 “Wantedly Visit” をはじめ複数プロダクトを運営している ウォンテッドリーさん</strong></li>
</ul>
<p>それぞれ異なるフェーズとプロダクトを持つ2社でイベントを開催しました！</p>
<p>開発組織をより良くしたいと考える人にとって今回のイベントは、学びを持ち帰って現場に活かすことができる内容だったと思います！</p>
<p>参加されなかった方にも、当日の熱量を感じていただき、学びを共有できるようにイベントを振り返っていきます！</p>
<h1>■セッション内容</h1>
<ol>
<li><strong>要 徳幸 様（ウォンテッドリー株式会社）/ <a href="https://speakerdeck.com/baroqueworksdev/qi-ye-cheng-chang-noge-suteziniying-zita-sheng-chan-xing-nozui-shi-hua-zhan-lue">企業成長の各ステージに応じた生産性の最適化戦略</a></strong></li>
<li><strong>塩原 基弘（株式会社Another works） / <a href="https://drive.google.com/file/d/1wu37Am5KGM-DaiYQ7GN9LFxX4_mZqe1T/view">効果性と効率を意識した開発生産性の向上施策</a></strong></li>
<li><strong>市古 空 様（ウォンテッドリー株式会社） /  <a href="https://speakerdeck.com/igsr5/devops-guild">DevOps の社内浸透を目指してチームを立ち上げた話 / DevOps Guild</a></strong></li>
</ol>
<h2>1. 要 徳幸 様（ウォンテッドリー株式会社）/ <a href="https://speakerdeck.com/baroqueworksdev/qi-ye-cheng-chang-noge-suteziniying-zita-sheng-chan-xing-nozui-shi-hua-zhan-lue">企業成長の各ステージに応じた生産性の最適化戦略</a></h2>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/9dc2501c-9271-4151-a402-67219da99488/1000006973.jpg" alt="1000006973.jpg"></p>
<h3>◎内容</h3>
<p><strong>◯「開発」「生産性」とは？</strong></p>
<ul>
<li>みなさんの所属するチームの「開発」のスコープは？</li>
<li>生産性とは「Input &lt; Output」を成立させる活動</li>
<li>生産性には、変数が多々ある</li>
<li>事業モデル・企業ステージ・組織構成によって異なる</li>
</ul>
<p><strong>◯ ウォンテッドリーの取り組み</strong></p>
<ul>
<li>プロダクト開発の概観
<ul>
<li>開発組織が担当するのは「プロダクト開発」</li>
<li>市場リリースから収益化へのサイクル</li>
</ul>
</li>
<li>10年間の経験から明らかになった主要な課題
<ul>
<li>予想外の問い合わせ、バグ報告、インシデントの増加</li>
<li>負のスパイラルが発生する</li>
<li>短期集中型チームの課題と品質保証</li>
<li>10年分の Output が効率を下げてしまう状態に陥った</li>
</ul>
</li>
<li>最近の取り組みと進展
<ul>
<li>体制設計の見直しと品質向上チームの設置</li>
<li>品質向上と現開発チームの負担軽減</li>
</ul>
</li>
</ul>
<p><strong>◯ 企業ステージごとに変革しよう</strong></p>
<ul>
<li>ステージを超えて、時間差で影響を及ぼす</li>
<li>ステージごとに変革することが大事</li>
<li>開発だけではなく、全体の生産性から俯瞰的に探る</li>
</ul>
<h3>◎レポート</h3>
<p>ウォンテッドリーさん開発チームで実際に起きたインシデント対応などによる負の影響と、それに対する具体的な取り組みを紹介する話でした。</p>
<p>規模などは異なるかもしれないですが、Another works でもバグやインシデント対応により、本来やりたい新規の追加開発が思うようにできない苦しい時期がありました。</p>
<p>そのような時期はプロダクトロードマップに沿って予定通りの開発ができないです。また、思うようにやりたい開発ができないエンジニアにとってはモチベーションが低下することにもなりかねない原因にもなり得ます。</p>
<p>ベンチャー企業にとって多くないリソースをどの程度負債解消に投入すべきか、というのはどの開発チームにとっても悩ましいことだと思います。技術的負債に対してどう向き合っていくべきかを、フェーズごとに考えること大切であると、改めて実感しました。</p>
<h2>2. 塩原 基弘（株式会社Another works） / <a href="https://drive.google.com/file/d/1wu37Am5KGM-DaiYQ7GN9LFxX4_mZqe1T/view">効果性と効率を意識した開発生産性の向上施策</a></h2>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/142fb299-7326-487d-8ba4-4a7231621931/1000006974.jpg" alt="1000006974.jpg"></p>
<h3>◎内容</h3>
<p><strong>◯ 開発生産性と効果性と効率について</strong></p>
<ul>
<li>開発生産性とは？</li>
<li>開発プロセスについて</li>
<li>効果性と効率</li>
</ul>
<p><strong>◯ 効果性の向上に対する取り組み</strong></p>
<ul>
<li>プロダクトバックログを育てる会</li>
<li>15分リファインメント</li>
</ul>
<p><strong>◯ 効率の向上に対する取り組み</strong></p>
<ul>
<li>チームでタスク分解・見積もりを行う</li>
<li>チームでのタスク分解のやり方</li>
<li>ブランチ戦略の改善</li>
</ul>
<p><strong>◯ 開発生産性を支える組織的土台</strong></p>
<ul>
<li>自律型の組織を作るために</li>
</ul>
<h3>◎レポート</h3>
<p>”効果性”と”効率”という切り口で開発プロセスを見て、その”効果性”と”効率”を向上させることに対してどのようにアプローチを行なっているか、というお話。</p>
<p>“効果性”を上げるために行なっている毎日の「15分リファインメント」、”効率”を上げるための「チームでのタスク分解・見積もり」など具体的な取り組みが紹介されました。</p>
<p>このような取り組みは、持ち帰ってチームに還元しやすい内容だったのではないでしょうか？</p>
<p>「チームでのタスク分解・見積もり」は他のエンジニアの視点や知見が共有される場にもなっており、私としても好きな取り組みの一つです。</p>
<p>今後、その時々に合わせて改善施策を提案して行きたいです。</p>
<h2>3. 市古 空 様（ウォンテッドリー株式会社） /  <a href="https://speakerdeck.com/igsr5/devops-guild">DevOps の社内浸透を目指してチームを立ち上げた話 / DevOps Guild</a></h2>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/0dbcd4bd-8964-43fc-971f-1b3fab0beaee/1000006976.jpg" alt="1000006976.jpg"></p>
<h3>◎内容</h3>
<p><strong>◯ DevOps Guild とは</strong></p>
<ul>
<li>知見が広がり続ける状態を作り出すチーム</li>
</ul>
<p><strong>◯ 生産性への多面的なアプローチ</strong></p>
<ul>
<li>いろんな向きから生産性をみてみよう
<ul>
<li>↓ 上から見る（経営 → メンバー）</li>
<li>↑ 下から見る（部下 → マネージャー）</li>
<li>→ 横から見る（ビジネスチーム → 開発チーム）</li>
</ul>
</li>
<li>生産性が低いとどうなる？（一方向のみのアプローチでは限界がある）
<ul>
<li>日々の開発のアウトプットが減少</li>
<li>技術的負債の増加</li>
<li>仕事のモチベーションが低下</li>
</ul>
</li>
</ul>
<p><strong>◯ DevOps Guild の設立と今後</strong></p>
<ul>
<li>直近の課題：他のチームにも知見や習慣を広げたい</li>
<li>組織のサービスメッシュ的存在</li>
</ul>
<p><strong>◯ まとめ</strong></p>
<ul>
<li>生産性改善は多面的なアプローチが重要</li>
<li>組織のサービスメッシュを作って課題発見・知見共有の起点としていく</li>
</ul>
<h3>◎レポート</h3>
<p>生産性の向上へ多面的にアプローチする組織 ”DevOps Guild” の設立と今後のお話でした。</p>
<p>直近の課題としてお話をされていた「有用な知見が広がりずらい」ということは、Another works の開発チームでも感じることがある話題です。</p>
<p>複数チームを抱えるウォンテッドリーさん。チーム間の知見をうまく共有できる環境が整えば、それだけ働くエンジニアにとっては嬉しいことばかりだと思いました。</p>
<p>取り組みの一つとして、開発ドキュメンテーションの改善にフォーカスをしていくとのことでした。</p>
<p>その<a href="https://docs.wantedly.dev/">開発ドキュメンテーション</a>は公開されておりますので、是非みなさんもご覧ください！</p>
<h1>■交流会</h1>
<p>オフラインイベントの良さは、セッションで気になったことを登壇者に直接その場で聴くことができることや、熱量冷めないうちに交流会で出会った方同士で議論できることにあるのではないでしょうか？</p>
<p>開発生産性向上への取り組みや、開発組織課題に対する話題を中心に大変盛り上がりを見せておりました！<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/eb194493-948c-447d-b136-56d655d5ca0c/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-12-2519.17.36.png" alt="スクリーンショット2023-12-2519.17.36.png"></p>
<h1>■さいごに</h1>
<p>Another works では今後も学びと交流の場となるイベントを開催していく予定です！</p>
<p>Connpassでグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！</p>
<p><a href="https://anotherworks.connpass.com/">Another works Connpass</a></p>
<p>今回、オンライン・オフライン同時開催のイベントでした！</p>
<p>オンラインの良さもありますが、オフライン参加できる方はぜひ会場の熱量を肌で感じていただきたいです！</p>
<p>オフライン参加できる方はぜひ会場でお待ちしております！</p>
<p>私としても、他社開発チームの組織作りの取り組みや開発の進め方などは気になることが多いです！</p>
<p>ぜひ次回のイベントで熱く議論や意見交換しましょう！<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/05b6f982-8fba-4fa6-9b8e-673a0ba25a17/PXL_20231214_113558666.jpg" alt="PXL_20231214_113558666.jpg"></p>
<p>ウォンテッドリーのみなさん、ご参加いただいたみなさん、本当にありがとうございました！！</p>


Another works × ウォンテッドリー 成長ベンチャーの開発生産性、なにやってる？ 【Developers Meetup】

<h1>はじめに</h1>
<p>Another works CTOの塩原です。<br>
最近はエンジニア採用に力を入れているので、今回は弊社で実践しているユニークな採用手法「複業転職」についてご紹介させていただきます。</p>
<h1>複業転職とは</h1>
<p>複業転職は、正社員として入社する前に、業務委託契約を経て実際の業務に携わり、その後に正式な転職を行う方法です。一般的な転職フローと比べると期間は長くなりますが、コーディングテストや面接のプロセスが簡略化される傾向にあります。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/a2775c97-4322-4d95-b744-0041eb2e8b21/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-12-2515.45.40.png" alt="スクリーンショット2023-12-2515.45.40.png"></p>
<h1>複業転職のメリットとデメリット</h1>
<p>では複業転職がどういったメリット・もしくはデメリットがあるのか採用側の目線と求職者側の目線でそれぞれ整理をしていきます。</p>
<h2>採用側の視点</h2>
<p>複業転職は、特にエンジニアのような採用が難しい職種において、非常に適した手法です。<br>
または、人数を増やすだけでなく、カルチャーマッチを重視し、慎重に優秀な人材を選びたいという採用戦略に合致します。</p>
<p>ただし、即時の採用効果が期待できないため、急ぎで人員を確保する必要がある場合には不向きかもしれません。</p>
<table>
<thead>
<tr>
<th>メリット</th>
<th>デメリット</th>
</tr>
</thead>
<tbody>
<tr>
<td>転職潜在層へのアプローチが可能</td>
<td>転職までのリードタイムが長い</td>
</tr>
<tr>
<td>カルチャーマッチの判断が容易</td>
<td>外注費用が発生</td>
</tr>
<tr>
<td>オンボーディングコストの削減</td>
<td>マネジメント負担の増加</td>
</tr>
<tr>
<td>社内エンジニアとの連携がスムーズ</td>
<td>運用の複雑さ</td>
</tr>
</tbody>
</table>
<h2>求職者の視点</h2>
<p>求職者にとってのメリットとしては転職先の選択を失敗するリスクを減らすことができるという点があります。<br>
また面接を複数社受けたり、コーディングテストを受けたりなど従来の転職活動が苦手な方にとっても複業を通した付き合いの中でお互いを知ることができるため転職コストの低減となります。</p>
<p>一方で採用側と同様にすぐに転職したい場合は不向きです。<br>
また複業は一定の時間を取られることから複数の企業を同時並行で進めるのが難しいという特徴もあります。</p>
<table>
<thead>
<tr>
<th>メリット</th>
<th>デメリット</th>
</tr>
</thead>
<tbody>
<tr>
<td>入社後のギャップが少ない</td>
<td>選択肢の限定</td>
</tr>
<tr>
<td>転職活動のコスト低減</td>
<td>速やかな転職が困難</td>
</tr>
</tbody>
</table>
<h1>複業転職を活用した採用戦略</h1>
<p>通常の業務委託契約では転職につながることが少ないため、複業転職には独自のアプローチが必要です。<br>
複業転職では、業務の選定と定期的なコミュニケーションが成功の鍵となります。<br>
単純作業ではなく、複業者のスキルを活かす業務を選ぶことが重要です。</p>
<h2>割り当てる業務の種類</h2>
<p>業務は、定期的に正社員エンジニアとのコミュニケーションが発生するようなものを選びます。<br>
このような業務は、単純な作業ではなく、複業者のスキルと経験を活かすものであるべきです。<br>
業務内容を対話ベースで徐々に拡大していくと、複業者はよりやりがいを感じ、企業へのコミットメントも高まる傾向があります。</p>
<table>
<thead>
<tr>
<th>転職に繋がりやすい業務</th>
<th>転職に繋がりにくい業務</th>
<th>工夫が必要な業務</th>
</tr>
</thead>
<tbody>
<tr>
<td>アドバイザリー業務</td>
<td>単純なデータ入力</td>
<td>個人で完結するタスクの開発（技術負債の解消、UI修正など）</td>
</tr>
<tr>
<td>エンジニア研修の実施</td>
<td>デバッグ作業</td>
<td>自動テストの作成</td>
</tr>
<tr>
<td>チーム開発プロジェクトへの参加</td>
<td>-</td>
<td>CI（継続的インテグレーション）の改善</td>
</tr>
</tbody>
</table>
<p>特に工夫が必要な業務では、ペアプログラミングや同期コードレビュー、社内勉強会など、積極的なコミュニケーションを取る機会を設けることが、より効果的です。</p>
<h1>Another worksの事例</h1>
<h2>事例1: AIアドバイザーから正社員への転身</h2>
<blockquote>
<p><strong>💡ポイント:</strong> 受発注の関係を越え、相談内容を段階的に深めることで、双方が同じ目線に立てるようになります。</p>
</blockquote>
<p><strong>背景</strong></p>
<ul>
<li>AI技術を活用したプロダクトの改善が必要だが、社内には専門知識が不足している。</li>
<li>AIの影響力について不確実性があり、正社員として即時採用するのは困難。</li>
<li>そのため、社内でAIに関する知見を蓄積しつつ、プロトタイプ開発を行うために、AIアドバイザーとして複業人材を採用。</li>
</ul>
<p><strong>複業内容</strong></p>
<ul>
<li>週一回の壁打ちセッションと、Slackを介した定期的な相談。</li>
</ul>
<p><strong>転職への経過</strong></p>
<ul>
<li>最初はレコメンデーションシステムの導入から始め、使用可能なデータを基に、適切なライブラリや学習方法の相談に集中。</li>
<li>徐々にAIのプロダクトへの統合を進め、中長期的な戦略や概念的なアイデアへと話が広がる。</li>
<li>その過程で、AIエンジニアとして正社員への転職を望むアドバイザーが自ら名乗りを上げる。</li>
</ul>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/97ad74e7-cf03-4b56-b95a-45bd365d31f2/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-12-239.07.15.png" alt="スクリーンショット2023-12-239.07.15.png"></p>
<h2>事例2: カジュアル面談から複業を挟んで選考への以降を決める</h2>
<blockquote>
<p><strong>💡ポイント:</strong> 業務だけでなく、それ以外のコミュニケーションにも重点を置くことが重要。</p>
</blockquote>
<p><strong>背景</strong></p>
<ul>
<li>カジュアル面談で自社への興味を持った候補者がいたが、直ちに転職を予定していないため、一次面接には進めない。</li>
<li>複業を介して、カジュアル面談では伝えきれなかったチームの雰囲気や業務内容を理解してもらう。</li>
</ul>
<p><strong>複業内容</strong></p>
<ul>
<li>ロードマップには含まれていないが重要なリファクタリング、パフォーマンス改善、UI修正などのタスクをチケット化し、自由に選択してもらう。</li>
</ul>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/0f1a143c-293c-49c3-94a0-972cd8f439f4/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-12-2515.30.03.png" alt="スクリーンショット2023-12-2515.30.03.png"></p>
<p><strong>転職への経過</strong></p>
<ul>
<li>実際の業務体験を通じて、CTOとのランチやチームとの交流を深め、複業期間中に候補者の意向を高める。</li>
<li>Another worksのコードやプロダクトの良し悪しを包み隠さず示し、候補者が自社で果たせる役割の可能性を理解してもらう。</li>
</ul>
<h1>まとめ</h1>
<p>複業転職は、特にエンジニアやCXOクラスのような採用が難しい職種において、徐々にスタンダードな採用手法として認識されつつあります。この手法は、求職者にとっても非常に有効です。</p>
<p>現代の就労環境では、複数回の転職が一般的になりつつあります。<br>
しかし、従来の方法では、毎回複数の企業で面接を受け、新しい職場でいちからスタートするという重大な負担が伴います。<br>
複業転職は、このような負荷を軽減し、キャリアチェンジをよりスムーズで緩やかなものにします。<br>
実際の業務を経験することで、求職者は企業の文化や仕事内容を深く理解し、より確かな決断を下すことが可能になります。</p>
<p>この手法は、採用側と求職者双方にとって、新しい時代のニーズに適応した理想的な解決策となるでしょう。</p>
<h1>複業転職で採用したいなら「複業クラウド」で</h1>
<p>複業クラウドでは複業人材の採用はもちろんのこと、複業からの転職採用も行うことのプラットフォームです。</p>
<p><a href="https://cl.aw-anotherworks.com/">https://cl.aw-anotherworks.com/</a></p>


複業から転職へ！Another works エンジニア複業転職の極意

<p>こんにちは！<br>
Another works で AIエンジニア、データサイエンティストをやっているノブです！</p>
<p>今回は、弊社 <strong><a href="https://anotherworks.co.jp/">Another works</a> と <a href="https://smarthr.co.jp/">SmartHR</a>さん、<a href="https://stmn.co.jp/">スタメン</a>さん</strong>の３社合同で 2023/9/28(木) に開催したLT×交流会 <a href="https://anotherworks.connpass.com/event/294517/">Developers Meetup 急成長ベンチャーが向き合う「開発生産性」</a> のイベントレポートをお届けします！</p>
<h1>■ イベントの概要</h1>
<p>Another worksでは、他社のチームの取り組みについて知りたい、他社のエンジニアと交流を持ちたいと考えている方々を対象に定期的にイベントを開催しています！</p>
<p>SmartHRさんとイベントを共同開催するのは三度目です。<br>
これまでは弊社 Anotherworks とSmartHRさんの共同開催だったのですが、今回はスタメンさんも加わり３社合同で、より豪華なイベントとなりました！<br>
今回も SmartHRさんのイベントスペースをお借りしてイベントを開催しました。いつも素敵なスペースを本当にありがとうございます！</p>
<p>今回は「<strong>開発生産性</strong>」という初めてのテーマでまさに急成長ベンチャーが直面するテーマだっただけに、どのようなイベントになるのか楽しみでした！</p>
<p>19:00 の開場から受付には人がたくさんいらっしゃり、結果オフライン・オンライン合わせて 60名近い方々にご参加いただきました！<br>
会場では多くの温かい拍手や熱い視線が、X（旧：Twitter）上でも #AwEngineerMeetup のハッシュタグで盛り上がり、オンライン・オフライン共に大盛況でした！</p>
<p>ご参加いただいた皆様ありがとうございました！！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/f738415d-b50b-46f9-a4fb-9c3b8a020f9e/1000006155.jpg" alt="1000006155.jpg"></p>
<h1>■ LT登壇内容</h1>
<ol>
<li>株式会社スタメン フロントエンドエンジニア　かみお <strong>「レガシーフロントエンドをリプレイスしたら開発生産性が向上しました」</strong></li>
<li>株式会社Another works CTO 塩原 基弘 <strong>「創業5年目、組織変化と開発生産性向上の取り組み」</strong></li>
<li>株式会社SmartHR プロダクトエンジニアグループ マネージャー <strong>「開発生産性、上から見るか？下から見るか？」</strong></li>
</ol>
<h2>1.「レガシーフロントエンドをリプレイスしたら開発生産性が向上しました」</h2>
<p>かみお 株式会社スタメン フロントエンドエンジニア / <a href="https://speakerdeck.com/kamio/regasihurontoendowo-ripureisusitara-kai-fa-sheng-chan-xing-gaxiang-shang-simasita">登壇資料</a><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/dd87d0bd-13bb-4afd-981d-a7e3202a2020/1000006151.jpg" alt="1000006151.jpg"></p>
<p>内容</p>
<ul>
<li>以下課題を抱えていた<br>
　- 複数の開発環境でキャッチアップコストが高い<br>
　- OpenAPI がなくコミュニケーションコストが高い<br>
　- ディレクトリ構成に統一感がない<br>
　- テストがほとんどない</li>
<li>開発生産性を向上させたこと５選<br>
　- aspida x msw を使ったスキーマ駆動開発<br>
　- featureディレクトリ<br>
　- hygenを使ったテンプレート化<br>
　- コード規約でなく lint で修正<br>
　- README や wiki の充実</li>
<li>設計/選定したものをどのように継続させていくかを考えることが大事</li>
</ul>
<p>ひとことレポート</p>
<p>ドキュメントの充実や統一感を持たせること、キャッチアップコストを下げることはまさに「急成長ベンチャー」において重要なことだなと感じました。<br>
オンボーディングをする側もされる側も、これは正社員・複業メンバー関係なく非常に有効的な取り組みだなと感じました！</p>
<h2>2.「創業5年目、組織変化と開発生産性向上の取り組み」</h2>
<p>塩原 基弘 株式会社Another works CTO / <a href="https://drive.google.com/file/d/10ic1SpiYctn1KEvqQPBYXmrdOaNScNta/view">登壇資料</a><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/a28340b7-41a4-49b7-bae0-4731be3eb0c3/IMG_8057.jpg" alt="IMG_8057.jpg"></p>
<p>内容</p>
<ul>
<li>生産性が高い状態とは「少ないコストで大きな成果を出す」こと</li>
<li>開発プロセスと技術の改善で、開発生産性を向上させる</li>
<li>抱えていた課題<br>
　- リリース日が間延びし続ける<br>
　- プランニングの時間が長くて、疲弊する<br>
　　- 時間を意識しすぎて、中途半端な状態で開発に取り掛かる<br>
　- ユーザー価値や課題、解決方法で䛿なく、どうコーディングするかに考えが寄ってしまう<br>
　- 機能担当者に属人化する</li>
<li>開発プロセスの改善<br>
　- 要件定義会<br>
　- Dailyリファインメント &amp; プランニング</li>
<li>技術的な取り組み<br>
　- SQLを使うテストにおいて worker分、DBを立ち上げてそれぞれで通信を行う<br>
　- ESLint によるルールの自動化</li>
<li>まとめ<br>
　- プロセスの改善は組織形態や規模などで常に変わり続けるので改善し続けることが大事<br>
　- 技術的な改善は、投資しておくと長く効果を発揮する<br>
　- 生産性を向上させるのは成果を最大化するための手段である</li>
</ul>
<p>ひとことレポート</p>
<p>生産性とは？という振り返りができ、改めて「生産性」という言葉の定義を理解することができました。<br>
特に懇親会では「要件定義会」と「Dailyリファインメント」について質問させることが多く、やはり良い取り組みだなぁと改めて実感することができました！</p>
<h2>3.「開発生産性、上から見るか？下から見るか？」</h2>
<p>すがわら まさのり 株式会社SmartHR プロダクトエンジニアグループ マネージャー / <a href="https://speakerdeck.com/sugamasao/development-productivity-and-cognitive-science">登壇資料</a><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/48a93ab5-c7ac-4dab-95dd-f114a946b769/1000006171.jpg" alt="1000006171.jpg"></p>
<p>内容</p>
<ul>
<li>認知負荷が高い<br>
　- チーム横断のコミュニケーションコストが高くなる<br>
　- 一人の人間が扱える限界を超える<br>
　- コードを修正した時の影響調査が膨大</li>
<li>認知負荷には３種類の負荷がある</li>
<li>取り組み例<br>
　- 自チーム以外の PRを見る<br>
　- 気になるコードをリファクタリングする<br>
　- テックな雑談をする</li>
<li>まとめ<br>
　- 課題の輪郭をうまく捉えると解消方法をより適切に検討できる<br>
　- 課題の大きさや難易度によってボトムアップとトップダウンを使い分けると良い</li>
</ul>
<p>ひとことレポート</p>
<p>認知科学の観点から「認知負荷が高い」状態への解決策を発表いただき非常に興味深かったです。<br>
認知負荷には３種類あり、それぞれどのように解決すべきかという切り口が大変勉強になりました！</p>
<h1>■ 交流会</h1>
<p>交流会は、LT登壇者と当日お越しいただいたオーディエンスの方々で行いました。<br>
LTの内容についての深掘りや考え、技術の話、それぞれのチームの取り組み… など様々な話題で大変盛り上がりました！<br>
「明日から取り入れてみます！」と今日の学びを早速活かす宣言をしてくれている方もおり、私たちも非常に嬉しい気持ちになりました！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/196d58d4-893e-45d9-930a-9d92f439be1d/1000006176.jpg" alt="1000006176.jpg"></p>
<h1>■ 最後に</h1>
<p>Another works では今後も学びと交流の場となるイベントを開催していく予定です！</p>
<p>Connpassでグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！</p>
<p><a href="https://anotherworks.connpass.com/">Another works Connpass</a></p>
<p>なお今回のイベントの感想など #AwEngineerMeetup のハッシュタグ付きでツイートをして盛り上げていただけると嬉しいです！</p>
<p>SmartHRの皆様、スタメンの皆様、ご参加いただいた皆様、本当にありがとうございました！！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/19a56688-36ec-449a-a274-8e9c9e25852f/PXL_20230928_114503737.jpg" alt="PXL_20230928_114503737.jpg"></p>


Another works × SmartHR x スタメン【Developers Meetup 急成長ベンチャーが向き合う「開発生産性」】イベントレポート

<p>Another works でエンジニアをしているまっちと申します！</p>
<p>今回は、弊社 <strong><a href="https://anotherworks.co.jp/">Another works</a></strong> と <strong><a href="https://jobs.freee.co.jp/">freee</a></strong> さんで2023/8/22(火)に共同開催したMeet up イベント、</p>
<p><strong><a href="https://anotherworks.connpass.com/event/291678/">freee × Aw プロダクトの成長を支える強いエンジニア組織のつくりかた</a></strong> の様子をお届けします！</p>
<p>freee さんの大崎にあるオフィスで開催された今回イベントには、オンラインとオフライン参加者合わせて<strong>90名程度</strong>の方に参加いただきました！</p>
<p>freee さんの素敵な会場には、開発組織を良くしていきたいと考える方たちがたくさん！<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/c8a0d71f-f9a5-4bec-b0ba-41d84b8c846e/1000005909(1).jpg" alt="1000005909(1).jpg"></p>
<h1>■ 開催の背景</h1>
<p>イベントのテーマは <strong>”プロダクトの成長を支える強いエンジニア組織のつくりかた”</strong> でした。</p>
<p>現在所属している開発組織に対して</p>
<ul>
<li><strong>組織の人数が増えてきて、漠然とした課題感がある</strong></li>
<li><strong>メンバーの主体性を発揮できるチームを作っていきたい</strong></li>
<li><strong>メンバーの成長を促すチーム作りをしたい</strong></li>
<li><strong>メンバーが意欲的に働くことができる環境を作りたい</strong></li>
</ul>
<p>などの課題を抱えている方も多いのではないでしょうか？</p>
<p><strong>どの開発組織も、似たような課題感を持っている</strong>と思います。</p>
<p>そこで今回</p>
<ul>
<li><strong>2019年創業 開発組織が10名程の Another works</strong></li>
<li><strong>2012年創業 開発組織が200名を超える freee さん</strong></li>
</ul>
<p>それぞれ異なるフェーズと開発組織を持つ2社がタッグを組みました。</p>
<p>異なる背景を持つ2社の経験から、</p>
<p>先述したような<strong>課題を解消するヒントとなる知見や経験を共有したい</strong>、そんな想いから今回のイベントを開催をする運びとなりました！</p>
<p>開発組織に対する課題感を持つ人にとって今回のイベントは、学びを持ち帰って現場に活かすことができる内容だったと思います！</p>
<p>参加されなかった方にも、当日の熱量を感じていただき、学びを共有できるようにイベントを振り返っていきます！</p>
<h1>■セッション内容</h1>
<ol>
<li>竹田 祥 様（freee 株式会社） / <a href="https://speakerdeck.com/freee/key-points-for-creating-a-development-organization">Engineerサクセスという組織を作って1年間やってみて感じた開発組織作りのポイント</a></li>
<li>塩原 基弘（株式会社Another works） / <a href="https://drive.google.com/file/d/1pUdW5lCP7R-x0QNb67WSksNbMTGY2D90/view">オーナーシップが生まれる組織の作り方</a></li>
<li>野本 篤則 様（freee 株式会社） / <a href="https://speakerdeck.com/freee/creating-an-organization-in-which-hr-and-engineers-collaborate-with-each-other">人事とエンジニアで協業しながら進める組織作りのポイント</a></li>
</ol>
<h2>1. 竹田 祥 様 / <strong><a href="https://speakerdeck.com/freee/key-points-for-creating-a-development-organization">Engineerサクセスという組織を作って1年間やってみて感じた開発組織作りのポイント</a></strong></h2>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/d01bce2b-1c79-4a5f-b7c4-2bcb18c1dbae/1000005912(1).jpg" alt="1000005912(1).jpg"></p>
<h3>◎内容</h3>
<p>◯<strong>プロダクト開発と組織作りは非常に良く似ている</strong></p>
<ul>
<li>ユーザ理解　調査・分析
<ul>
<li>ユーザ=エンジニア、チームメンバー、組織と考え、ユーザ理解に手を抜かない</li>
</ul>
</li>
<li>要求定義
<ul>
<li>本当に必要としているものは？逆に求めていないものは？、をユーザ理解をもとにしっかり仮説立てて考える</li>
</ul>
</li>
<li>設計・実装
<ul>
<li>スモールスタートする。プロダクトと同じで、実際にやってみないとわからないことが多い。</li>
</ul>
</li>
<li>評価
<ul>
<li>ユーザ理解と一緒で定量と定性、両面を使って評価する</li>
<li>評価をしっかり受け止め、しっかりアップデートする</li>
</ul>
</li>
<li>まとめ</li>
</ul>
<p>良いプロダクトを作れる集団は良い組織も作れるはず</p>
<p>◯<strong>データドリブンと人情ドリブンを行き来する</strong></p>
<ul>
<li>相手は人なので、定量、定性両方のバランスが大事</li>
</ul>
<p>◯<strong>楽なショートカットは基本ない</strong></p>
<ul>
<li>この部分もプロダクト開発と一緒。人、組織に真摯に向き合い続けるしかない</li>
<li>起点は「ユーザ理解　調査・分析」</li>
</ul>
<h3>◎レポート</h3>
<p>freee さんには ”開発組織を成功に導く” ための組織である ”Engineer サクセスチーム”があります。2022年7月に発足し、エンジニア組織を成功に導くために尽力してきた経験から得た知見をお話いただきました。<br>
Engineer サクセスチームは、ユーザーを成功に導く職種である ”カスタマーサクセス” を参考につくられたそうです。</p>
<p><strong>プロダクト開発の場面では一般的な考え方として「小さくはじめて少しずつ改善していく」というものがあります。その考え方を、組織で施策を実施するときにも適用できる</strong>、という話がありました。</p>
<p>この考え方は、組織の大小問わず、組織でなにか取り組みを行うときは常に気をつけたいことだと思います。</p>
<p>私も数百人を超える企業に所属していたので、人事施策など、組織に対する施策は最初から大きくなりがち、という話には納得です。</p>
<p>LTの冒頭、Engineer サクセスチームを立ち上げて「プロダクトマネージャーをやっていたときとは比にならないくらい人と組織に向き合った」という竹田さんの言葉が内容に説得力をもたらしていました。</p>
<h2>2. 塩原 基弘（株式会社Another works） / <a href="https://drive.google.com/file/d/1pUdW5lCP7R-x0QNb67WSksNbMTGY2D90/view">オーナーシップが生まれる組織の作り方</a></h2>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/006e2829-b4c1-457b-9351-2a53eaf290f6/1000005921(1).jpg" alt="1000005921(1).jpg"></p>
<h3>◎内容</h3>
<p>◯<strong>Another works での取り組み事例の紹介</strong></p>
<ul>
<li>徹底したドキュメント化</li>
<li>Sprint 振り返りレポート</li>
<li>毎週の「Sentryエラー監視対応会」、「npm ライブラリアップデート会」の実施</li>
<li>要件定義会</li>
<li>毎週 Sprint タスクとは別に、やりたいことを実施する時間を設ける（プロダクトの OSS化に近い取り組み）</li>
</ul>
<p>◯<strong>オーナーシップとは</strong></p>
<ul>
<li>一つのことに対してオーナーとしての意識を持つ</li>
<li>それぞれがオーナーシップを発揮できる場所を持つ</li>
<li>人数は関係ない：人数が少なくても意識しなければオーナーシップ精神は薄れる</li>
</ul>
<p>◯<strong>全体へのオーナーシップを育てる組織づくりの取り組み</strong></p>
<ul>
<li>採用にとにかく巻き込む：自分たちの仲間は自分たちが集める</li>
<li>全員で毎日QAを実施する：プロダクト全体を触る習慣をつける</li>
<li>役割を常に明確にする：MTG、イベントなど常に役割を明確にアサインする</li>
</ul>
<p>◯<strong>まとめ</strong></p>
<ul>
<li>オーナーシップと組織規模はあまり関係ない</li>
<li>オーナーシップ精神は伝染する</li>
</ul>
<h3>◎レポート</h3>
<p>Another works 開発チームでの、個々人がオーナーシップを発揮するための取り組みや仕組みづくりの紹介でした。</p>
<p>オーナーシップというワードに対して、「責任を持たされる」「主体性がないとできない」と感じて重圧に感じてしまう人もいると思います。しかし、オーナーシップを発揮できる場所があるということは、「そのとき」「その領域」で「その人」が主体的に働きかけることで輝ける機会にもなるはずです。</p>
<p><strong>Another works 開発チームにはそのようなオーナーシップ精神を促す文化があります。</strong></p>
<p>塩原の登壇内容にもあったようにオーナーシップ精神は伝染します。私自身オーナーシップを発揮出来る領域を増やしていき、オーナーシップ精神を伝染させる存在になっていきたいです。</p>
<h2>3. 野本 篤則 様（freee 株式会社） / <a href="https://speakerdeck.com/freee/creating-an-organization-in-which-hr-and-engineers-collaborate-with-each-other">人事とエンジニアで協業しながら進める組織作りのポイント</a></h2>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/8843dae0-6a9d-4d24-ac54-0fc93d0861e6/1000005926(1).jpg" alt="1000005926(1).jpg"></p>
<h3>◎内容抜粋</h3>
<p>◯ <strong>人事とエンジニアが一緒に eng サクセスチームを立ち上げた背景</strong></p>
<ul>
<li>
<p>eng サクセスチームとは？</p>
<p>開発メンバーの「成功」につながることだけを考え、実行し続ける専任チーム</p>
</li>
<li>
<p>会社組織全体が大きくなり開発側と人事側で協働して変化と課題に対応する必要がでてきた</p>
</li>
</ul>
<p>◯ <strong>組織作りでぶち当たった壁</strong></p>
<ul>
<li>何から手を付ければ良いか、わからない
<ul>
<li>課題仮説・優先順位が立てられず、悩み、迷った。</li>
<li>「成功」とは？</li>
<li>エンジニアのモチベーションや悩みや困りごとはなんだろう？</li>
</ul>
</li>
</ul>
<p>◯ <strong>どうやって向き合ってきたか</strong></p>
<ul>
<li>アクション：一次情報を徹底的に泥臭く収集した（ユーザ理解に徹した）</li>
<li>結果：開発現場の情報と組織データを組み合わせて、本質的な課題探求・実行・検証に繋げた</li>
</ul>
<p>◯ <strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong><strong>開発組織作りのポイントのまとめ</strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></strong></p>
<ul>
<li>一次情報を意識的に収集することが大事。筋の良い課題仮説に繋がっていく。</li>
<li>人事の持つ組織データをうまく活用することによって、客観的な仮説検証が可能となる。よい打ち手の立案〜改善サイクルに繋がっていく。</li>
<li>開発現場の定性情報（感性）と、組織・人材の定量情報（論理）を組み合わせて使うことが本質的な組織課題の探求と解決につながる。</li>
</ul>
<h3>◎レポート</h3>
<p>セッション１の竹田さんと共に “Engineer サクセスチーム” で人事の立場として活動してきた野本さん。</p>
<p>野本さんのLTは “Engineer サクセスチーム” 立ち上げの苦悩と具体的にどのようなことをしてきたのか、を紹介する内容でした。</p>
<p>エンジニア組織成功のために、当初なにをしたらいいのかわからない状況だったそうです。</p>
<p>まずは人と組織を理解するために、現場のエンジニアと愚直に1on1を実施したという話がありました。200名を超えるエンジニアがいる freee さん、愚直に泥臭く人と組織に向き合ってきたことが伺えます。</p>
<p>そして、<strong>「1on1で集めた定性的な情報」と「人事の持つ人材・組織の定量的な情報」を組み合わせて、本質的な課題を見つけ解決策を考える、というアプローチは freee さんならでは</strong>の取り組みだと感じました。</p>
<p>エンジニア組織を良くしていきたいと考えている方はもちろん、人事や組織開発に携わっている方であれば学びの多い内容でした！</p>
<h1>■交流会</h1>
<p>オフラインイベントの良さは、セッションで気になったことを登壇者に直接その場で聴くことができることや、熱量が冷めないうちに交流会で議論できることにあるのではないでしょうか？</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/f0a8a4b5-6d65-4841-8fcf-ef1174d86679/1000005933.jpg" alt="1000005933.jpg"></p>
<p>開発組織の話題を中心に非常に登壇者、オーディエンスともに大変盛り上がりました！</p>
<p>終了時間のアナウンス後も、その場を立ち去らない人もいるくらいに熱く語っている方もチラホラ（笑）</p>
<h1>■さいごに</h1>
<p>Another works では今後も学びと交流の場となるイベントを開催していく予定です！</p>
<p>Connpassでグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！</p>
<p><a href="https://anotherworks.connpass.com/">Another works Connpass</a></p>
<p>今回はオンライン・オフライン同時開催のイベントでした！</p>
<p><strong>オンラインの良さもありますが、オフライン参加できる方はぜひ会場の熱量を肌で感じていただきたいです！</strong><br>
オフライン参加できる方はぜひ会場でお待ちしております！</p>
<p>個人的に、他社開発チームの組織作りの取り組みや開発の進め方などは気になることが多いです！<br>
ぜひ次回のイベントで熱く議論や意見交換しましょう！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/e0990278-6adb-402a-93b3-bac0c6627755/IMG_0501.JPG.jpg" alt="IMG_0501.JPG.jpg"></p>
<p>freee のみなさん、ご参加いただいたみなさん、本当にありがとうございました！！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/186ed5ac-b9f6-4ff8-8ed9-b7c0c1178632/PXL_20230822_125815600(1)(1).jpg" alt="PXL_20230822_125815600(1)(1).jpg"></p>


Another works × freee【DEVELOPER MEETUP! プロダクトの成長を支える強いエンジニア組織のつくりかた】イベントレポート

<p>こんにちは！<br>
Another works で AIエンジニア、データサイエンティストをやっているノブです！</p>
<p>今回は、弊社 <strong><a href="https://anotherworks.co.jp/">Another works</a> と <a href="https://smarthr.co.jp/">SmartHR</a></strong> さんで 2023/7/25(火) に開催したLT×交流会 <a href="https://anotherworks.connpass.com/event/288878/">顧客に価値を届けるプロダクト志向なエンジニアリング</a> のイベントレポートをお届けします！</p>
<h1>■ イベントの概要</h1>
<p>Another worksでは、他者のチームの取り組みについて知りたい、他社のエンジニアと交流を持ちたいと考えている方々を対象に定期的にイベントを開催しています！</p>
<p>SmartHRさんとオフラインでイベントを共催するのは二度目です。<br>
<a href="https://anotherworks.connpass.com/event/278310/">前回</a>同様、SmartHRさんのイベントスペースをお借りしてイベントを開催しました！（いつも素敵なスペースを本当にありがとうございます）</p>
<p>前回は「FRONT-END DEEP DIVE」とフロントエンドにフォーカスしたイベントだったのですが、今回は「<strong>エンジニアリング</strong>」とテーマを変えての開催に、どんなイベントになるのか楽しみな反面、緊張感もありました。</p>
<p>そんな不安を払拭するかのように 19:00 の開場から受付には人がたくさんいらっしゃり、結果オフライン・オンライン合わせて 60名を超える方にご参加いただきました！<br>
会場では多くの温かい拍手や熱い視線が、X（旧：Twitter）上でも #AwEngineerMeetup のハッシュタグで盛り上がり、オンライン・オフライン共に大盛況でした！</p>
<p>ご参加いただいた皆様ありがとうございました！！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/3b78addf-b92c-43d5-a99e-ac0a206163f9/F14HjMqaMAACeH-.jpeg" alt="F14HjMqaMAACeH-.jpeg"></p>
<h1>■ LT登壇内容</h1>
<ol>
<li>株式会社SmartHR プロダクトエンジニアグループ 高倉 拓也様 <strong>「スプリントゴールと仲良くしたい」</strong></li>
<li>株式会社Another works CTO 塩原 基弘 <strong>「エンジニアが要件定義に上手く絡むには」</strong></li>
<li>株式会社SmartHR プロダクトエンジニア 根岸 勇弥 <strong>「ミッションから紐解く、フィーチャーチームへの意識改革」</strong></li>
<li>株式会社Another works PdM 宮内 北斗 <strong>「エンジニアリングがどうプロダクトの企画に活きるのか」</strong></li>
</ol>
<h2>1.「スプリントゴールと仲良くしたい」</h2>
<p>高倉 拓也 株式会社SmartHR プロダクトエンジニアグループ / <a href="https://speakerdeck.com/tkkrtky/supurintogorutozhong-liang-kusitai">登壇資料</a><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/f64aecd4-4ce1-4433-ae4f-9c1470dbf9e7/part1.jpeg" alt="part1.jpeg"></p>
<p>内容</p>
<ul>
<li>LeSSを導入していると各チームで触る機能が異なり共通のスプリントゴールを設定するのが難しい</li>
<li>スプリントゴールが先にあって、それをもとにプロダクトバックログアイテムを選択する方法を１チームで試してみた</li>
<li>プランニングのタイミングで顧客価値を設定</li>
<li>得られた効果
<ul>
<li>コミュニケーションや意思決定の面で恩恵を受けることができた</li>
<li>顧客の価値について考える習慣ができた</li>
</ul>
</li>
</ul>
<p>ひとことレポート</p>
<p>チームの中で「共通の言葉」がある姿が、非常に良いなと感じました！<br>
細かな方向性の違いも「共通の言葉」によって正せそうですね。</p>
<h2>2.「エンジニアが要件定義に上手く絡むには」</h2>
<p>塩原 基弘 株式会社Another works CTO / <a href="https://drive.google.com/file/d/19S2UO-8usmiqndc-Oy9bEqb4z7bJ9gBg/view?usp=sharing">登壇資料</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/3e5e7293-1533-4436-b1ad-7d6d39ea3f0d/part2.jpeg" alt="part2.jpeg"></p>
<p>内容</p>
<ul>
<li>「要求定義」と「要件定義」
<ul>
<li>要求定義：誰のどの課題を解決するか（What）なぜその課題を解決するのか、課題であるのか？（Why）</li>
<li>要件定義：どういう手段で解決するのか？（How）</li>
</ul>
</li>
<li>要求定義が終わった段階で、それを元に要件定義書を Pdm・デザイナー・エンジニア含め４人くらいで同期的に作成する「要件定義会」を導入してみた
<ul>
<li>エンジニアの役割：課題解決手法の立案、コストの見積もり</li>
</ul>
</li>
<li>要件定義に積極的になるにはどうすれば良いか
<ul>
<li>意見を出すのが難しい時はピンポイントで考えてみる</li>
<li>定期的にサービスを触る癖をつける</li>
</ul>
</li>
</ul>
<p>ひとことレポート</p>
<p>「エンジニアのみなさん、要件定義は好きですか？」の問いから始まった本セッションでは、弊社チームの取り組みである「要件定義会」や「毎朝QA」が紹介され、改めてその開催意味を理解しながら聞いていました。<br>
それぞれの専門領域を活かして異なる提案が出てくる要件定義会は、施策の質・スピード共にアプローチできる良い方法だなと感じました！</p>
<h2>3.「ミッションから紐解く、フィーチャーチームへの意識改革」</h2>
<p>根岸 勇弥 株式会社SmartHR プロダクトエンジニア / <a href="https://speakerdeck.com/negi_andleek/mitusiyonkaraniu-jie-ku-huitiyatimuhenoyi-shi-gai-ge">登壇資料</a><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/eaf75e14-e925-4f02-a1e3-b7c71d1a6a7d/part3.jpeg" alt="part3.jpeg"></p>
<p>内容</p>
<ul>
<li>課題：組織の拡大に伴い分業化が進み、顧客価値を中心にチームで働くのが難しい</li>
<li>顧客中心の機能を実現する、安定した長期存続することを目的としたフィーチャーチーム誕生
<ul>
<li>フィーチャーリードを通じてプロダクトエンジニアも使用について考えるようになった</li>
<li>課題解決のために、第三の案を考えられるようになった</li>
</ul>
</li>
<li>チームとして、プロダクトに責任を持つことは大事</li>
<li>チームの意識・体質を改善するには時間がかかるが、良いプロダクトを作ろうという共通認識を持っているのは悪いことではない</li>
</ul>
<p>ひとことレポート</p>
<p>顧客価値に徹底したフィーチャーチームとても格好良いなと思いました！<br>
こういったチームを筆頭にメンバー全員が顧客価値志向なエンジニアになった時には色んな Howが出てきて楽しみだなと感じました！</p>
<h2>4.「エンジニアリングがどうプロダクトの企画に活きるのか」</h2>
<p>宮内 北斗 株式会社Another works PdM / <a href="https://drive.google.com/file/d/1ZkvglS4P0x4lPAz8-XI0xOGdw85skMqi/view?usp=sharing">登壇資料</a><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/fcec7c8f-889b-4470-b129-f2b7f5432c3a/part4.jpeg" alt="part4.jpeg"></p>
<p>内容</p>
<ul>
<li>元エンジニアが PdMをやってよかったと思ったこと
<ul>
<li>エンジニア、デザイナーとコミュニケーションが取りやすい</li>
<li>課題に対する解決策の具体性や実現性が高い</li>
</ul>
</li>
<li>エンジニアとして施策の価値向上に貢献できること
<ul>
<li>要件定義のブラッシュアップ
<ul>
<li>ユースケース漏れ許さないマン</li>
<li>そもそもマン（本当に必要か？）</li>
<li>シンプルis正義マン</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>ひとことレポート</p>
<p>エンジニア出身の PdM だからこそ思う、エンジニア知識があってよかったと思うこと、エンジニアに頼りたいことが聞けました！<br>
個人的には「ユースケース漏れ許さないマン」を尊敬しており、目指してみようと思いました！</p>
<h1>■ 交流会</h1>
<p>交流会は、LT登壇者と当日お越しいただいたオーディエンスの方々で行いました。<br>
LTの内容についての深掘りや考え、技術の話、それぞれのチームの取り組み… など様々な話題で大変盛り上がりました！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/498a611f-afb9-46c9-85ed-5a7f265b86f6/PXL_20230725_122252457.MP.jpg" alt="PXL_20230725_122252457.MP.jpg"></p>
<h1>■ 最後に</h1>
<p>Another works では今後も学びと交流の場となるイベントを開催していく予定です！</p>
<p>Connpassでグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！</p>
<p><a href="https://anotherworks.connpass.com/">Another works Connpass</a></p>
<p>なお今回のイベントの感想など #AwEngineerMeetup のハッシュタグ付きでツイートをして盛り上げていただけると嬉しいです！</p>
<p>SmartHRの皆様、ご参加いただいた皆様、本当にありがとうございました！！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/d2a0f35a-c394-4c7c-99ce-44a24007e91f/PXL_20230725_114625834.MP.jpg" alt="PXL_20230725_114625834.MP.jpg"></p>


Another works × SmartHR【顧客に価値を届けるプロダクト志向なエンジニアリング】イベントレポート

<p>こんにちは！Another works エンジニアのまっちです！</p>
<p>今回は、弊社 <strong><a href="https://anotherworks.co.jp/">Another works</a> と <a href="https://www.hrbrain.co.jp/about/">HRBrain</a></strong> さんで 2023/6/28(水) に開催したLT×交流会 <a href="https://anotherworks.connpass.com/event/285380/">プロダクト開発を支える技術</a> のイベントレポートをお届けします！</p>
<h1>■ イベントの概要</h1>
<p>今回は 3/30(木)に開催した <a href="https://anotherworks.connpass.com/event/276673/">Front-end Meetup 2023</a> に引き続き HRBrain さんオフィスをお借りして共催イベントを開催！</p>
<p>弊社イベントはこれまで、フロントエンドをテーマに数多く開催してきました。</p>
<p>今回は “プロダクト開発を支える技術” と、いつもと異なるテーマの開催だったのでドキドキでした！</p>
<p>そのようななか、オフライン、オンライン合わせて40名ほどの方にご参加いただきました！！</p>
<p>ありがとうございます！</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/1eedf2d8-3275-40ad-bf00-3a03fa00fe79/PXL_20230628_103202096.jpg" alt="PXL_20230628_103202096.jpg"></p>
<h1>■ LT登壇内容</h1>
<ol>
<li><strong><a href="https://twitter.com/bellwood4486">鈴木 善晴</a> 氏 株式会社HRBrain テックリード： 「マイクロサービスのローカル開発環境をTiltを使って2年運用して得た知見」</strong></li>
<li><strong><a href="https://twitter.com/MotohiroSiobara">塩原 基弘</a> 株式会社Another works 取締役CTO：「施策のPDCAを回すためのデータ分析基盤」</strong></li>
<li><strong><a href="https://twitter.com/ingtk8">稲垣 隆徳</a> 氏 株式会社HRBrain テックリード：「ChatGPTとPythonを用いた高速なデータ可視化プロトタイピング」</strong></li>
</ol>
<h2>1.「マイクロサービスのローカル開発環境をTiltを使って2年運用して得た知見」</h2>
<p><strong><a href="https://twitter.com/bellwood4486">鈴木 善晴</a> 株式会社HRBrain テックリード / <a href="https://speakerdeck.com/bellwood4486/maikurosahisunorokarukai-fa-huan-jing-wotiltwoshi-tute2nian-yun-yong-sitede-tazhi-jian">登壇資料</a></strong><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/3ac01b79-3fe6-42a2-8c27-3dc50bec4b49/PXL_20230628_104529498.jpg" alt="PXL_20230628_104529498.jpg"><br>
<strong>内容</strong></p>
<ul>
<li>Tiltベースの弊社の開発体験の紹介</li>
<li>Tilt導入の工夫や得られた知見</li>
</ul>
<p><strong>ひとことレポート</strong></p>
<p>Tilt を利用することにより、マイクロサービス構成を気にさせない開発体験はいいなと感じました！</p>
<p>開発環境改善は日々の業務をするなかで優先順位付けが難しくなかなか着手し辛い側面があります。</p>
<p>その文脈ででた話で、開発体験の悪さから生じる憤りをエネルギーに変換することを「怒り駆動開発」という言葉で表現されていて、個人的にツボでした。笑</p>
<p>HRBrain さんのサービスも開発チームも成長し続けるなかでの生の話が聞けて非常に学びあるお話でした！</p>
<h2>2.「施策のPDCAを回すためのデータ分析基盤」</h2>
<p><strong><a href="https://twitter.com/MotohiroSiobara">塩原 基弘</a> 株式会社Another works 取締役CTO / <a href="https://drive.google.com/file/d/10rXQj6jqELGQixIMAUSPjI6n1V51-z24/view">登壇資料</a></strong><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/3661c92f-0a59-4d8f-946b-a24e2d6b26f8/PXL_20230628_110608327.MP.jpg" alt="PXL_20230628_110608327.MP.jpg"></p>
<p><strong>内容</strong></p>
<ul>
<li>分析基盤の概要</li>
<li>ログデータを BigQuery に取り込む</li>
<li>分析用ログを Cloudwatch に吐き出す</li>
<li>まとめ
<ul>
<li>データの活用は後からでもできるけど、基盤の構築は早い方がいい</li>
<li>厳密であることはコミュニケーションをシンプルにする</li>
<li>厳密さを保ちつつ、コストを下げることはセットでやるべき</li>
</ul>
</li>
</ul>
<p><strong>ひとことレポート</strong></p>
<p>データ分析においてデータサイエンティスト、PdM、実装者と関係者が多い故にコミュニケーションが繁雑になってしまう。この現状に対して ALL TypeScript で対応しているなどの工夫の部分が「なるほど」と改めて勉強になりました！</p>
<h2>3.「ChatGPTとPythonを用いた高速なデータ可視化プロトタイピング」</h2>
<p><strong><a href="https://twitter.com/ingtk8">稲垣 隆徳</a> 株式会社HRBrain テックリード / <a href="https://speakerdeck.com/ingtk/chatgpttopythonwoyong-ita-gao-su-nadetake-shi-hua-purototaipingu">登壇資料</a></strong><br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/c0f257bc-a899-4c88-9250-c171d4cc1421/PXL_20230628_111936489.MP.jpg" alt="PXL_20230628_111936489.MP.jpg"><br>
<strong>内容</strong></p>
<ul>
<li>バックエンドエンジニアのプロトタイピングへの関わり方
<ul>
<li>なぜプロトタイピングをやるのか</li>
<li>プロトタイピングの課題</li>
</ul>
</li>
<li>データ可視化アプリケーションを爆速で作る</li>
</ul>
<p><strong>ひとことレポ</strong></p>
<p>最近弊社 Another works でも最近プロトタイピングを取り入れて開発をしていたのでタイムリーでした。実際に動くものを見せることでコミュニケーションが円滑になるという話は非常に納得でした！</p>
<p>あと個人的に “LLM アイデアソン” を実施したというのが非常にうらやましかったです。うちでもやりたい。。。</p>
<h1>■ 交流会</h1>
<p>交流会にはLT登壇者も参加しました。</p>
<p>LT内容についての話や、技術の深い話、普段の開発におけるあれこれ、など最後まで大変盛り上がり、話題の尽きない時間でした！<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/1ab56a86-21d7-4291-899a-bd7838bcac67/PXL_20230628_115818845.jpg" alt="PXL_20230628_115818845.jpg"></p>
<h1>■ さいごに</h1>
<p>Another works では今後も学びと交流の場となるイベントを開催していく予定です！</p>
<p>Connpassでグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！</p>
<p><a href="https://anotherworks.connpass.com/">Another works Connpass</a></p>
<p>なお今回のイベントの感想など <strong>#AwEngineerMeetup</strong> のハッシュタグ付きでツイートをして盛り上げていただけると嬉しいです！</p>
<p>HRBrain のみなさま、ご参加いただいたみなさまありがとうございました！<br>
<img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/bf64f452-ca3e-453e-b33d-08cbdcae37ec/PXL_20230628_113759123.MP(1).jpg" alt="PXL_20230628_113759123.MP(1).jpg"></p>


Another works × HRBrain 【プロダクト開発を支える技術】イベントレポート

<h2>■ はじめに</h2>
<p><code>&lt;div&gt;</code>などの<code>HTML</code>要素ごとに入れ子にしていいものと、入れ子にしてはいけないものがあることはご存知でしょうか？</p>
<p>最近ブラウザや<code>HTML</code>などの<code>Web標準に備わる技術</code>を学ぶなかで、<code>HTML</code>要素ごとの<code>入れ子ルール</code>がちゃんと定義されていることを知りました。</p>
<pre><code class="language-html:html">&lt;div&gt;ここに入れていいものと、入れてはダメなものがあるよ！&lt;/div&gt;
</code></pre>
<p>「じゃあ、そのルール破ったらどうなるねん」 という疑問からこの記事を書いています。</p>
<p>通常の<code>HTML</code>の例と私が普段利用している<code>Next.js</code>での例を用いて説明していきます。<br>
興味を持った方はぜひ最後まで読んでください。</p>
<h2>■ 入れ子ルールとは？</h2>
<p>この入れ子ルールのことを、<code>Content model</code>といいます。<br>
<code>HTML Standard</code>では<a href="https://html.spec.whatwg.org/multipage/dom.html#concept-element-content-model"><code>Content model</code></a>を</p>
<blockquote>
<p>A normative description of what content must be included as children and descendants of the element.<br>
要素の子や子孫としてどのような内容を含めなければならないかを規範的に記述したもの。</p>
</blockquote>
<p>と説明しています。</p>
<p>この<code>Content model</code>のルールは１つ１つの要素ごとに決められており、<code>HTML Standard</code>や<code>MDN</code>にも要素ごとのルールが記載されています。</p>
<p>そのルール付けは大きく</p>
<ul>
<li>コンテンツカテゴリーを基準にルール付けされている要素</li>
<li>複雑なルール付けがされている要素（コンテンツカテゴリーにくくられず）<br>
の２つに区分できそうです。</li>
</ul>
<p>※ コンテンツカテゴリーとは(MDNより)</p>
<blockquote>
<p>ほとんどの HTML 要素は 1 つ以上のコンテンツカテゴリーに属していて、カテゴリーごとに共通した特徴を持つ要素を分類しています。これは緩やかなグループ分けです（実際にはこれらのカテゴリーの要素間の関係を作成していません）。しかし、これらは、特にその複雑な詳細に遭遇したときに、カテゴリーの共有動作とその関連ルールを定義し記述するのに役立ちます。どのカテゴリーにも属さない要素も存在します。</p>
</blockquote>
<ul>
<li><a href="https://developer.mozilla.org/ja/docs/Web/HTML/Content_categories">MDN コンテンツカテゴリー</a></li>
<li><a href="https://html.spec.whatwg.org/multipage/dom.html#kinds-of-content">HTML Standard Kinds of content</a></li>
</ul>
<h3>◎ コンテンツカテゴリーを基準にルール付けされている要素</h3>
<p><code>HTML Standard</code>で<a href="https://html.spec.whatwg.org/multipage/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements"><code>&lt;h1~6&gt;</code>要素</a>の<code>Content model</code>を確認してみます。</p>
<p><code>&lt;h1~6&gt;</code>要素は非常にシンプルなルールとなっており、<a href="https://html.spec.whatwg.org/multipage/dom.html#content-categories"><code>７つのコンテンツカテゴリー</code></a>のうち<a href="https://html.spec.whatwg.org/multipage/dom.html#phrasing-content-2"><code>Phrasing content</code></a>のみを許容します。</p>
<p><img src="https://storage.googleapis.com/zenn-user-upload/e1eab097f490-20230708.png" alt=""></p>
<p>ただ、<code>&lt;h1~6&gt;</code>要素のように７つのコンテンツカテゴリーを基準にルール付けされているものは稀なようです。</p>
<h3>◎ 複雑にルール付けされている要素</h3>
<p><code>HTML Standard</code>で<a href="https://html.spec.whatwg.org/multipage/tables.html#the-table-element"><code>&lt;table&gt;</code>要素</a>の<code>Content model</code>を確認してみます。</p>
<p>なかなか複雑に書いてあるものの、<br>
<code>&lt;caption&gt;</code>, <code>&lt;colgroup&gt;</code>, <code>&lt;thead&gt;</code>,<code>&lt;tbody&gt;</code>, <code>&lt;tr&gt;</code>, <code>&lt;tfoot&gt;</code><br>
を入れ子にしていいようです。</p>
<blockquote>
<p>HTML Standard table<br>
<img src="https://storage.googleapis.com/zenn-user-upload/e723f61c3cd3-20230708.png" alt=""></p>
</blockquote>
<p><code>HTML Standard</code>よりは信憑性が落ちそうなものの、<code>MDN</code>でも確認できます。</p>
<blockquote>
<p><a href="https://developer.mozilla.org/ja/docs/Web/HTML/Element/table">MDN <code>&lt;table&gt;</code></a><br>
<img src="https://storage.googleapis.com/zenn-user-upload/50e37f077748-20230708.png" alt=""></p>
</blockquote>
<h2>■ 入れ子ルールをやぶるとどうなる？</h2>
<p>では、気になる<strong>入れ子ルールをやぶるとどうなる</strong>のでしょうか？</p>
<p>結論として、<strong>原則としてエラー補正はされずにそのままDOMツリーに追加される</strong>ようです。<br>
しかし、<strong>要素の種類によってはエラー補正がされてDOM構造が変換される</strong>ことがあります。</p>
<p>それでは、<br>
<strong>要素の種類によってはエラー補正がされてDOM構造が変換される</strong>ことを例を用いて解説していきます。</p>
<h3>◎ <code>&lt;table&gt;</code>要素で試してみる</h3>
<p>では、<code>&lt;table&gt;</code>内に<code>&lt;p&gt;</code>を入れてみます。<br>
先程確認したように<code>&lt;table&gt;</code>は<code>&lt;p&gt;</code>を入れ子に許容しません。</p>
<pre><code class="language-html:html">&lt;table&gt;
  &lt;tbody&gt;
     &lt;tr&gt;
      &lt;th&gt;見出しのセル&lt;/th&gt;
      &lt;td&gt;データのセル&lt;/td&gt;
    &lt;/tr&gt;
  &lt;/tbody&gt;
  &lt;!--    &lt;table&gt;タグの中に&lt;p&gt;タグはいれるのはルール違反だよ！--&gt;
  &lt;p&gt;Pテキストだよ&lt;/p&gt;
&lt;/table&gt;
</code></pre>
<blockquote>
<p>Google chrome で表示<br>
<img src="https://storage.googleapis.com/zenn-user-upload/57e7a52a7e7e-20230707.png" alt=""></p>
</blockquote>
<p>構文エラーとなり、このようにブラウザで解釈されて表示されていることがわかります。</p>
<pre><code class="language-html:html">&lt;p&gt;Pテキストだよ&lt;/p&gt;
&lt;table&gt;
  &lt;tbody&gt;
    &lt;tr&gt;
      &lt;th&gt;見出しのセル&lt;/th&gt;
      &lt;td&gt;データのセル&lt;/td&gt;
    &lt;/tr&gt;
  &lt;/tbody&gt;
&lt;/table&gt;
</code></pre>
<p><code>&lt;table&gt;</code>要素では、入れ子のルールをやぶると<br>
<strong>エラー補正がされてDOM構造が変換される</strong>ことが確認できました。</p>
<h3>◎ HTML 解釈の仕様ルール</h3>
<p>このように<code>DOM構造</code>が変換されるような<code>HTML</code>解釈の仕様ルールが定められているようです。<br>
<a href="https://html.spec.whatwg.org/multipage/parsing.html">https://html.spec.whatwg.org/multipage/parsing.html</a></p>
<p><code>&lt;table&gt;</code>要素の場合、不正な子孫要素が前に追い出される形になります。<br>
この、不正な子孫要素が前に追い出されるのは<a href="https://html.spec.whatwg.org/multipage/parsing.html#foster-parent"><code>foster parenting</code></a>というルールらしいです。</p>
<h2>■ Next.js で入れ子ルールをやぶるとどうなる？</h2>
<p>今度は<code>Next.js</code>で入れ子ルールをやぶってみます。<br>
先程の例と同じように<code>&lt;table&gt;</code>と<code>&lt;p&gt;</code>を例に試します。</p>
<pre><code class="language-json:package.json">// 動作確認実行環境
&quot;next&quot;: &quot;13.4.3&quot;,
&quot;react&quot;: &quot;18.2.0&quot;,
</code></pre>
<pre><code class="language-tsx:tsx">&lt;table&gt;
  &lt;tbody&gt;
     &lt;tr&gt;
      &lt;th&gt;見出しのセル&lt;/th&gt;
      &lt;td&gt;データのセル&lt;/td&gt;
    &lt;/tr&gt;
  &lt;/tbody&gt;
  {/* &lt;table&gt;タグの中に&lt;p&gt;タグはいれるのはルール違反だよ */}
  &lt;p&gt;Pテキストだよ&lt;/p&gt;
&lt;/table&gt;
</code></pre>
<p>すると<code>DOM構造</code>はマークアップしたものと変わらずに表示されるものの、エラーになりました。</p>
<p><img src="https://storage.googleapis.com/zenn-user-upload/a18731801bad-20230707.png" alt=""></p>
<pre><code class="language-bash:error">Unhandled Runtime Error
Error: Hydration failed because the initial UI does not match what was rendered on the server.
Warning: Expected server HTML to contain a matching &lt;p&gt; in &lt;table&gt;.

See more info here: https://nextjs.org/docs/messages/react-hydration-error
</code></pre>
<p><strong>エラー日本語訳</strong></p>
<blockquote>
<p>エラー：初期UIがサーバーでレンダリングされたものと一致しないため、Hydration に失敗しました。<br>
ワーニング：サーバーのHTMLは<code>&lt;table&gt;</code>内に<code>&lt;p&gt;</code>を含むことを期待しました。</p>
</blockquote>
<p>エラー文で案内されている、<a href="https://nextjs.org/docs/messages/react-hydration-error"><code>Next.js</code>のドキュメント</a>にも、エラー発生理由の説明として下記内容が記載されています。</p>
<blockquote>
<p>アプリケーションのレンダリング中に、事前レンダリングされた React ツリー (SSR/SSG) と、ブラウザーでの最初のレンダリング中にレンダリングされた React ツリーとの間に差異がありました。最初のレンダリングはReact の機能である Hydration と呼ばれます。</p>
</blockquote>
<p>これにより、React ツリーが DOM と同期しなくなり、予期しないコンテンツ属性が存在する可能性があります。</p>
<p><strong>ここから自己解釈</strong><br>
どうやら、<code>React</code>側ではマークアップのそのままを想定して <code>Hydration</code>しようとした。<br>
しかし、実際はブラウザで解釈された結果がそのマークアップと異なるため <code>Hydration</code>に失敗するようです。</p>
<p><strong>※Hydration, Hydrate とは</strong><br>
サーバー側で生成されたHTMLにJSの各ロジックを接続していくこと。<br>
つまり静的な状態のHTML要素にJSのイベントハンドラなど接続していき、動的ウェブページに変換していく処理のこと。<br>
クリックなどのイベントが発火されない静的な状態のUIをクリック可能な動的なUIにする処理。</p>
<p><code>SSR</code>や<code>Hydration</code>についても解説していますのでこちらの記事もよかったら読んでください。<br>
<a href="https://tech.anotherworks.co.jp/article/react-suspense-react18">今後の React ではどの範囲を Suspense で囲むかという設計が重要になってくる</a></p>
<h2>■ さいごに</h2>
<p>Web標準の技術を学ぶことの重要性を実感しているところです。<br>
深く学ぼうとするとやっぱり面白いです。</p>
<h4>参考資料</h4>
<ul>
<li><a href="https://html.spec.whatwg.org/multipage/">https://html.spec.whatwg.org/multipage/</a></li>
<li><a href="https://developer.mozilla.org/ja/docs/Web/HTML/Content_categories">https://developer.mozilla.org/ja/docs/Web/HTML/Content_categories</a></li>
<li><a href="https://zenn.dev/yusukehirao/articles/learn-new-html-elements">https://zenn.dev/yusukehirao/articles/learn-new-html-elements</a></li>
<li><a href="https://www.w3.org/TR/2011/WD-html5-20110113/parsing.htmlhttps://developer.mozilla.org/ja/docs/Web/HTML/Element/table">https://www.w3.org/TR/2011/WD-html5-20110113/parsing.htmlhttps://developer.mozilla.org/ja/docs/Web/HTML/Element/table</a></li>
<li><a href="https://webliker.info/html/46840/#toc_1">https://webliker.info/html/46840/#toc_1</a></li>
<li><a href="https://zenn.dev/onikun/articles/28fb8de056c89a">https://zenn.dev/onikun/articles/28fb8de056c89a</a></li>
<li><a href="https://nextjs.org/docs/messages/react-hydration-error">https://nextjs.org/docs/messages/react-hydration-error</a></li>
</ul>


【HTML】要素の入れ子ルールをやぶるとどうなるのか？

<p>こんにちは、はけまるです！</p>
<p>2023/06/22に弊社が主催した、豪華5社によるフロントエンドイベント「<strong><a href="https://anotherworks.connpass.com/event/285095/">Front-end Deep Dive Online</a></strong>」についてのレポートを書かせていただきます！</p>
<p>ご参加いただいた5社☆</p>
<ul>
<li>株式会社クラスメソッド</li>
<li>株式会社ゆめみ</li>
<li>株式会社SmartHR</li>
<li>株式会社HRBrain</li>
<li>株式会社Another works</li>
</ul>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/a1f7f4d1-9e46-43e4-ba53-b92c77410235/24a4bfb7671904855fa97ae3594dcfe3.png" alt="24a4bfb7671904855fa97ae3594dcfe3.png"></p>
<h1>目次</h1>
<ul>
<li>イベントの概要</li>
<li>LT登壇内容
<ol>
<li>「巨大tableのパフォーマンスを改善する」</li>
<li>「フロントエンド開発エクササイズ」</li>
<li>「改善活動に戦略と秩序を持たせる」</li>
<li>「HRBrainの生態系を支えるフロントエンドチームの取り組み」</li>
<li>「頑張りすぎない、開発生産性を上げるフロントエンドテスト戦略」</li>
</ol>
</li>
<li>おわりに</li>
</ul>
<h1>イベントの概要</h1>
<p>Another worksでは、技術力を磨きたい、あるいは他社のチームの取り組みについて知りたいと考えている方々向けに定期的にイベントを開催しています！</p>
<p>今回は、各社のCTOやテックリード、エンジニアリングマネジャー、フロントエンドエンジニアの方々に技術や生産性、チームの成長、実装時の考え方など様々なテーマで登壇いただきました！</p>
<p>参加人数は120名を超え、 <strong>#AwEngineerMeetup</strong> のハッシュタグでたくさんの方にTweetしていただけました！</p>
<h1>LT登壇内容</h1>
<ol>
<li>株式会社クラスメソッド 高橋 ゆうき様：<strong>「巨大tableのパフォーマンスを改善する」</strong></li>
<li>株式会社ゆめみ スー様：<strong>「フロントエンド開発エクササイズ」</strong></li>
<li>株式会社SmartHR 山本 裕太様：<strong>「改善活動に戦略と秩序を持たせる」</strong></li>
<li>株式会社HRBrain 山口 祐司様：<strong>「HRBrainの生態系を支えるフロントエンドチームの取り組み」</strong></li>
<li>株式会社Another works 塩原 基弘：<strong>「頑張りすぎない、開発生産性を上げるフロントエンドテスト戦略」</strong></li>
</ol>
<h2>1.「巨大tableのパフォーマンスを改善する」</h2>
<p>株式会社クラスメソッド <a href="https://twitter.com/hbsnow">高橋 ゆうき様</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/24088843-fe84-4dfe-b8ca-324c27cecf1e/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-07-0419.31.40.png" alt="スクリーンショット2023-07-0419.31.40.png"></p>
<h3>内容</h3>
<ul>
<li>巨大テーブルのパフォーマンス改善に立ち向かう</li>
<li>requestIdleCallbackにより、CPUに余裕があるときに順次表示するDeferコンポーネント</li>
<li>IntersectionObserverで最下部まで到達したら以降のコンテンツを読み込む</li>
<li>uiがブロックされるとき、useTransitionが使える</li>
</ul>
<p>サンプルサイトは<a href="https://hbsnow-sandbox.github.io/react-heavy-table/">こちら</a>！</p>
<h3>はけまるレポート</h3>
<p>requestIdleCallbackやIntersectionObserverは聞いたことはありましたが、実際に使ったことは初めてだったのでとても勉強になりました！<br>
「最初に思い浮かんだ方法が唯一の解決方法とは限らない」という考え方はプロダクト開発者としてとても大切にしていきたいです！</p>
<h2>2.「フロントエンド開発エクササイズ」」</h2>
<p>株式会社ゆめみ <a href="https://twitter.com/TakamasaSuzuki6">スー様</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/787100aa-58ad-45a5-934c-83a78031b52d/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-07-0320.20.45.png" alt="スクリーンショット2023-07-0320.20.45.png"></p>
<h3>内容</h3>
<ul>
<li>より良いコードを書くためのガイドラインをエクササイズ形式で伝授</li>
<li>エクササイズ項目はこちら！
<ul>
<li>classNameプロパティ禁止</li>
<li>optionalプロパティ禁止</li>
<li>プロパティは最大3つ</li>
<li>exportするものは全体でユニークな名前にする</li>
<li>スナップショットテストの導入役割ごとにファイルを分ける</li>
</ul>
</li>
</ul>
<h3>はけまるレポート</h3>
<p>すーさんの話す「じゃあやめましょう」がとても聞き心地がよく、癖になりました！笑<br>
特にoptionalプロパティを使いすぎると条件分岐が増えてつらい思いをしたことがあるので、共感しました。すぐに実践できる内容も多く、今後の実装時に意識していきたいと思います！</p>
<h2>3.「改善活動に戦略と秩序を持たせる」</h2>
<p>株式会社SmartHR <a href="https://twitter.com/YtYmmt">山本 裕太様</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/0a0def6b-94a0-4a5e-b07b-e83e546d8d59/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-07-0320.27.32.png" alt="スクリーンショット2023-07-0320.27.32.png"></p>
<h3>内容</h3>
<ul>
<li>フロントエンドエンジニアの横串チームにおける、改善活動の課題と、実際に行った施策のお話</li>
<li>大規模スクラム（LeSS）で開発する組織の中で、チーム外の活動に対し、いかにメンバーが戦略を理解し、活動を自分ごと化できるようにしていったかのアプローチを解説</li>
<li>「横串会」を改善するために実際にやったこと
<ul>
<li>目的の言語化</li>
<li>課題の発散から収束（洗い出し→現状理解→優先度づけ）</li>
<li>課題の可視化（zatsuバックログの作成）</li>
</ul>
</li>
</ul>
<h3>はけまるレポート</h3>
<p>サイドワーク的な側面と明確な行動目的、どちらも兼ね備えた「横串会」が、とても魅力的でした！<br>
サイドワーク的な側面が強すぎると、成果があまり出ないことが多く、やるからにはしっかり目的を持って行動することが大切だと再認識。<br>
フロントエンドやエンジニアはもちろん、様々な職種で使える考え方を学ぶことができ、とても有意義な内容でした！</p>
<h2>4.「HRBrainの生態系を支えるフロントエンドチームの取り組み」</h2>
<p>株式会社HRBrain <a href="https://twitter.com/yug1224">山口 祐司様</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/0a26e2fb-ed4a-4638-b52e-5c26b7747eba/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-07-0419.33.36.png" alt="スクリーンショット2023-07-0419.33.36.png"></p>
<h3>内容</h3>
<ul>
<li>マルチプロダクト×フロントエンドの不を改善する
<ul>
<li>デザインシステムとUIコンポーネントライブラリ</li>
</ul>
</li>
<li>活躍人材の再現性を高めるための改善
<ul>
<li>フロントエンドオフィスアワー</li>
<li>コミュニケーションの可視化</li>
</ul>
</li>
</ul>
<h3>はけまるレポート</h3>
<p>メンバーが活躍できるようにするために様々なアプローチがあることを知り、視野が広がりました！特にコミュニケーション量の可視化でこんなことがわかるのかと、とても驚きました。笑<br>
フロントエンドオフィスアワーで実施されていたTypeChallenge、昔ひとりで挑戦して数問で挫折したので、弊社メンバーでもやってみたいな〜</p>
<h2>5.「頑張りすぎない、開発生産性を上げるフロントエンドテスト戦略」</h2>
<p>株式会社Another works <a href="https://twitter.com/MotohiroSiobara">塩原 基弘</a></p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/112a2445-bced-4540-afec-cfe516b2ba7b/IMG_9111585945BA-1.jpeg" alt="IMG_9111585945BA-1.jpeg"></p>
<h3>内容</h3>
<ul>
<li>開発生産性を向上させるという目的でテストを書くことで安定性と開発の効率化を促す直近の取り組みについて</li>
<li>テストは小さく始める（あれもこれも手を出さない）</li>
<li>取り組み事例
<ul>
<li>playwrightを利用したクロスブラウザQAを動画で行う</li>
<li>PR差分に対してのカバレッジレポートを導入</li>
<li>バグが発生したときにみんなで集まって、テストを書く</li>
</ul>
</li>
</ul>
<h3>はけまるレポート</h3>
<p>テストはあと回しにしがちなので、最初は小さくはじめ、重要かつ簡単な部分から始めることで導入がよりしやすくなるというのはとても共感しました！<br>
また、複数の主要ブラウザをすべてQAするのは難しいので動画を取ってくれるplaywriteはとても便利ですね〜<br>
今後はテストをうまく使って楽をしていきたいと思います！</p>
<h1>LT後交流会</h1>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/88bfb9a0-d20b-4569-aeab-438bf08a4a59/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-07-0419.54.39.png" alt="スクリーンショット2023-07-0419.54.39.png"></p>
<p>LT後は登壇者のメンバーで意見交流会を実施！<br>
横串会やテストについてなど各社の開発体制によって様々な意見があり、とても勉強になりました〜！</p>
<h1>おわりに</h1>
<p>Another worksでは7月, 8月と毎月イベントを開催していく予定です！<br>
 <strong>#AwEngineerMeetup</strong> のハッシュタグ付きでツイートで一緒に盛り上げいただけると嬉しいです！<br>
<a href="https://anotherworks.connpass.com/">Connpass</a>でグループメンバーになっていただけると開催通知が送られますので、以下より是非グループメンバー登録をよろしくお願いします！</p>


2023/06/22 Front-end Deep Dive Online イベントレポート

<h2>■ はじめに</h2>
<p>複数の<code>DOM</code>要素を参照するために<code>useRef</code>を何回も利用したくなる場面がありました。<br>
そのときに、<code>ref callback function</code>というものを利用していい感じに実装できたので、その備忘録と知識の深掘りです。</p>
<p><a href="https://react.dev/reference/react-dom/components/common#ref-callback">https://react.dev/reference/react-dom/components/common#ref-callback</a></p>
<h3>◎ やりたかったこと</h3>
<p>やりたかったこととしては、<br>
件数が可変のリストのアイテム要素を指定して、その要素までスクロールして、フォーカスを当てるという動作です。</p>
<p>ヘッダーの数値ボタンをクリックしてその数値のアイテムまでスクロール+フォーカスさせる感じ<br>
<img src="https://storage.googleapis.com/zenn-user-upload/3d42b89f4b74-20230702.gif" alt=""><br>
この要件を満たすために、事前にリストの件数を知らない状態で実装しなければいけません。</p>
<p>今回はこちらの <code>React 公式</code>のサンプルコードを参考にしています。<br>
<a href="https://react.dev/learn/manipulating-the-dom-with-refs#how-to-manage-a-list-of-refs-using-a-ref-callback">https://react.dev/learn/manipulating-the-dom-with-refs#how-to-manage-a-list-of-refs-using-a-ref-callback</a></p>
<p>サンプルを実装しながら解説していきます。<br>
リポジトリはこちら（汚いコメントなども残ってますが、よろしければ見てみてください）<br>
<a href="https://github.com/TomoyukiMatsuda/React-pra/blob/master/otamesiproject/src/pages/multiple-use-ref-scroll/index.tsx">https://github.com/TomoyukiMatsuda/React-pra/blob/master/otamesiproject/src/pages/multiple-use-ref-scroll/index.tsx</a></p>
<h2>■ <code>ref callback function</code>とは？</h2>
<p>まず<code>ref callback function</code>とは<br>
<code>div</code>等要素の<code>ref属性</code>に<code>refオブジェクト</code>ではなく、関数を渡したときのものです。</p>
<pre><code class="language-tsx">&lt;div ref={(node: HTMLDivElement | null) =&gt; console.log(&quot;div ref callback node&quot;, node)} /&gt;
</code></pre>
<h3>◎ <code>ref callback function</code>が呼び出されるタイミングと渡される引数</h3>
<p><code>ref callback function</code>は呼び出されるタイミングにより、渡される引数が異なります。</p>
<p><a href="https://react.dev/reference/react-dom/components/common#ref-callback">React 公式</a>と実際の動作を確認した限り下記のようになるようです。</p>
<ul>
<li><strong>DOM要素が画面に表示されたとき<code>Node</code>を引数として呼び出し</strong></li>
<li><strong>DOM要素が画面から削除されたとき<code>null</code>を引数として呼び出し</strong></li>
<li><strong>再レンダリングされたとき（※<code>ref callback function</code>が異なる参照を持つ場合）</strong>
<ol>
<li>前の参照をもつ関数に対して<code>null</code>を引数として呼び出される</li>
<li>次の新しいの参照をもつ関数に対して<code>Node</code>を引数として呼び出される</li>
</ol>
</li>
</ul>
<p>※<code>div</code> を例にとると DOM要素=<code>div</code>要素, <code>Node</code>=<code>HTMLDivElement</code>と読み替えることができます</p>
<h4>◯再レンダリングされたときは<code>ref callback function</code>が異なる参照を持つ場合のみ呼び出される</h4>
<p>つまり、<br>
次の例だと再レンダリングのたびに<code>ref callback function</code>が呼び出されます。<br>
これは、再レンダリング時に毎回関数が生成されて異なる参照先を保持する関数を渡しているためです。</p>
<pre><code class="language-tsx">&lt;div ref={(node: HTMLDivElement | null) =&gt; console.log(&quot;div ref callback node&quot;, node)} /&gt;
</code></pre>
<p>再レンダリングのたびにコンソールが吐かれており、<br>
<strong>１回目</strong></p>
<blockquote>
<p>DOM要素が画面に表示されたとき<code>Node</code>を引数として呼び出し</p>
</blockquote>
<p><strong>2回目, 3回目</strong></p>
<blockquote>
<p><strong>再レンダリングされたとき（※<code>ref callback function</code>が異なる参照を持つ場合）</strong></p>
<ol>
<li>前の参照をもつ関数に対して<code>null</code>を引数として呼び出される</li>
<li>次の新しいの参照をもつ関数に対して<code>Node</code>を引数として呼び出される</li>
</ol>
</blockquote>
<p>のタイミングで呼び出されています。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/1ef2d768ff1d-20230702.png" alt=""></p>
<p>次の例だと再レンダリング時には<code>ref callback function</code>呼び出されません。<br>
これは、関数をメモ化することにより、異なる参照先になることを防いでいるためです。</p>
<pre><code class="language-tsx">const refCallbackFn = useCallback(
    (node: HTMLDivElement | null) =&gt; console.log(&quot;div ref callback node&quot;, node),
    []
  );
  
// ...
&lt;div ref={refCallbackFn} /&gt;
</code></pre>
<p>再レンダリング時にはコンソールを吐かず、</p>
<blockquote>
<p>DOM要素が画面に表示されたとき<code>Node</code>を引数として呼び出し</p>
</blockquote>
<p>のタイミングだけで呼び出されています。<br>
<img src="https://storage.googleapis.com/zenn-user-upload/e1077791c8fb-20230702.png" alt=""></p>
<h2>■ 実装していく</h2>
<h3>◎ リストアイテム要素を参照するための<code>RefObject</code> を作成</h3>
<p>まずは、リストアイテム要素を参照するための<code>RefObject</code>を定義します。<br>
ここの<code>key</code>にリストアイテムのIDが入り、対象の<code>HTMLLIElement</code>を<code>value</code>に持ちます。</p>
<pre><code class="language-tsx">const listItemRefs = useRef&lt;{
    [key in number]: HTMLLIElement;
  }&gt;({});
</code></pre>
<p>こんな形で持たせる。</p>
<pre><code class="language-tsx">console.log(&quot;listItemRefs&quot;, listItemRefs.current);
</code></pre>
<p><img src="https://storage.googleapis.com/zenn-user-upload/6ee6160b5103-20230702.png" alt=""></p>
<h3>◎ リストアイテム要素を取得して ref にセットする</h3>
<p><code>ref callback function</code>に渡す関数を作成して、配列の要素に値の１つとしてもたせます。<br>
この関数で対象のリストアイテム要素の<code>Node</code>を受け取り、セットしていきます。</p>
<p><code>node</code>が<code>null</code>で取得される場合に<code>delete listItemRefs.current[id];</code>としているのは、<br>
参照不要になった値を<code>listItemRefs</code>(<code>RefObject</code>)に保持するのを防ぐためにおこなう処理です。</p>
<pre><code class="language-tsx">/**
 * refCallbackFunction を持つ形に配列を整形
 * useMemo でメモ化しつつ、refCallbackFunction を配列要素の値として持たせることで
 * 関数の参照先が意図せず変更されることを防いでいる
 */
const convertedList = useMemo(
  () =&gt;
    list.map((v) =&gt; ({
      id: v.id,
      refCallbackFunction: (node: HTMLLIElement | null) =&gt; {
        if (node !== null &amp;&amp; listItemRefs.current[v.id] === undefined) {
          // node が null でなく、かつ、ref が未登録の場合
          listItemRefs.current[v.id] = node;
        } else {
          // node が null の場合は、対象の node を管理する必要がなくなるため削除
          delete listItemRefs.current[v.id];
        }
      },
    })),
  [list]
);
</code></pre>
<p><code>Node</code>を取得するために配列に持たせた関数を<code>ref</code>にコールバック関数として渡します。</p>
<pre><code class="language-tsx">{convertedList?.map((v) =&gt; (
  &lt;li key={v.id} ref={v.refCallbackFunction} tabIndex={0}&gt;
    {v.id}
  &lt;/li&gt;
))}
</code></pre>
<h3>◎ ボタンをクリックしたときに対象のリストアイテム要素を参照して、イベントを発火する</h3>
<p>クリックしたときに、<code>id</code>から<code>listItemRefs</code>(<code>RefObject</code>)の値である<code>HTMLLIElement</code>が取得できるので、その<code>HTMLLIElement</code>に対して<br>
実行したい処理であるスクロールイベントとフォーカスイベントを発火させます。</p>
<pre><code class="language-tsx">const handleClickHeaderItem = useCallback((id: number) =&gt; {
  // id から 対象の ref を取得
  const itemRef = listItemRefs.current[id];
  itemRef?.scrollIntoView({
    behavior: &quot;smooth&quot;,
    block: &quot;center&quot;,
  });
  itemRef?.focus();
}, []);
</code></pre>
<p><code>handleClickHeaderItem</code>をヘッダーのボタンにセットする</p>
<pre><code class="language-tsx">{/* ヘッダー */}
&lt;header&gt;
 {list?.map((v) =&gt; (
    &lt;button key={v.id} onClick={() =&gt; handleClickHeaderItem(v.id)}&gt;
      {v.id}
    &lt;/button&gt;
  ))}
&lt;/header&gt;
</code></pre>
<h4>コードの全体像</h4>
<pre><code class="language-tsx">function Component({ list }: { list: { id: number }[] }) {
  // Mapped Types で型定義した RefObject を作成
  const listItemRefs = useRef&lt;{
    [key in number]: HTMLLIElement;
  }&gt;({});

  /**
   * refCallbackFunction を持つ形に配列を整形
   * useMemo でメモ化しつつ、refCallbackFunction を配列要素の値として持たせることで
   * 関数の参照先が意図せず変更されることを防いでいる
   */
  const convertedList = useMemo(
    () =&gt;
      list.map((v) =&gt; ({
        id: v.id,
        refCallbackFunction: (node: HTMLLIElement | null) =&gt; {
          if (node !== null &amp;&amp; listItemRefs.current[v.id] === undefined) {
            // node が null でなく、かつ、ref が未登録の場合
            listItemRefs.current[v.id] = node;
          } else {
            // node が null の場合は、対象の node を管理する必要がなくなるため削除
            delete listItemRefs.current[v.id];
          }
        },
      })),
    [list]
  );

  const handleClickHeaderItem = useCallback((id: number) =&gt; {
    // id から 対象の ref を取得
    const itemRef = listItemRefs.current[id];
    itemRef?.scrollIntoView({
      behavior: &quot;smooth&quot;,
      block: &quot;center&quot;,
    });
    itemRef?.focus();
  }, []);

  return (
    &lt;div&gt;
      {/* ヘッダー */}
      &lt;header&gt;
        {list?.map((v) =&gt; (
          &lt;button key={v.id} onClick={() =&gt; handleClickHeaderItem(v.id)}&gt;
            {v.id}
          &lt;/button&gt;
        ))}
      &lt;/header&gt;

      {/* リスト */}
      &lt;ul&gt;
        {convertedList?.map((v) =&gt; (
          &lt;li key={v.id} ref={v.refCallbackFunction} tabIndex={0}&gt;
            {v.id}
          &lt;/li&gt;
        ))}
      &lt;/ul&gt;
    &lt;/div&gt;
  );
}
</code></pre>
<h2>■ アンチパターン（よろしくない実装）</h2>
<h3>◎ ループ処理内で<code>useRef</code>をおこなうパターン</h3>
<p>リストをもとに<code>map</code>のなかで<code>useRef</code>を実行したくなります。<br>
しかし、当然ながら<code>React hooks</code>のルールに反するので怒られます。</p>
<pre><code class="language-tsx">const convertedList = list.map((item) =&gt; ({
    id: item.id,
    ref: useRef(null),
  }));
</code></pre>
<pre><code class="language-txt">React Hook &quot;useRef&quot; cannot be called inside a callback.
React Hooks must be called in a React function component or a custom React Hook function.
(react-hooks/rules-of-hooks)
</code></pre>
<p><a href="https://react.dev/warnings/invalid-hook-call-warning">https://react.dev/warnings/invalid-hook-call-warning</a></p>
<p><code>createRef</code>という関数を利用してもできそうではあるものの、<code>createRef</code>はクラスコンポーネントでの利用を前提としており、関数コンポーネントでの利用はよくなさそうです。</p>
<pre><code class="language-tsx">// 関数コンポーネントでの利用はよくない
const convertedList = list.map((item) =&gt; ({
    id: item.id,
    ref: createRef&lt;HTMLLIElement&gt;(),
  }));
</code></pre>
<p><a href="https://react.dev/reference/react/createRef">https://react.dev/reference/react/createRef</a></p>
<h3>◎ 親要素から子要素を参照するパターン</h3>
<p>次に親要素への 1 つの ref を取得して、子要素を参照するやり方が考えられます。<br>
しかし、この方法ではDOM構造が変更されると正常に動作しない可能性があり、推奨されていません。</p>
<pre><code class="language-tsx">const ulRef = useRef&lt;HTMLUListElement&gt;(null);
const handleClickHeaderItem = useCallback((id: number) =&gt; {
  // 親要素から子要素をidで取得する
  const itemRef: HTMLLIElement | null | undefined =
    ulRef.current?.querySelector(&quot;#id&quot; + id.toString());
  itemRef?.scrollIntoView({
    behavior: &quot;smooth&quot;,
    block: &quot;center&quot;,
  });
  itemRef?.focus();
}, []);

// ...
&lt;Ul ref={ulRef}&gt;
  {list?.map((v) =&gt;
    hideItemIds.includes(v.id) ? null : (
      &lt;Li
        key={v.id}
	id={&quot;id&quot; + v.id.toString()} // id を付与
	...
</code></pre>
<h2>■ さいごに</h2>
<p>最後までお読みいただきありがとうございました！</p>
<h4>参考</h4>
<ul>
<li><a href="https://react.dev/learn/manipulating-the-dom-with-refs#how-to-manage-a-list-of-refs-using-a-ref-callback">https://react.dev/learn/manipulating-the-dom-with-refs#how-to-manage-a-list-of-refs-using-a-ref-callback</a></li>
<li><a href="https://react.dev/reference/react/createRef">https://react.dev/reference/react/createRef</a></li>
<li><a href="https://react.dev/warnings/invalid-hook-call-warning">https://react.dev/warnings/invalid-hook-call-warning</a></li>
</ul>


【React】複数 useRef を使いたくなったときは ref callback function を使おう

<h1>■ はじめに</h1>
<p>理解深掘りのため、<br>
今更ながらブラウザのデータ保管機能 <code>Cookie</code>, <code>SessionStorage</code>, <code>LocalStorage</code>, <code>IndexedDB</code> を比較しながら解説してます！</p>
<h1>■ 比較表（ざっくり）</h1>
<table>
<thead>
<tr>
<th></th>
<th>Cookie</th>
<th>SessionStorage</th>
<th>LocalStorage</th>
<th>IndexedDB</th>
</tr>
</thead>
<tbody>
<tr>
<td>データの生存期間</td>
<td>セッションの終了まで（※ただし期限の指定も可能）</td>
<td>タブ/ウィンドウが開いている間</td>
<td>手動で消去するまで</td>
<td>手動で消去するまで</td>
</tr>
<tr>
<td>データ保存可能容量</td>
<td>約4KB</td>
<td>5MB程（ブラウザにより異なる）</td>
<td>5MB程（ブラウザにより異なる）</td>
<td>ブラウザによる制限なし（ディスク容量に基づく）</td>
</tr>
<tr>
<td>データアクセス可能領域</td>
<td>サーバー＆クライアント</td>
<td>クライアントのみ</td>
<td>クライアントのみ</td>
<td>クライアントのみ</td>
</tr>
<tr>
<td>データ形式</td>
<td>文字列のみ</td>
<td>任意のデータ形式（主に文字列）</td>
<td>任意のデータ形式（主に文字列）</td>
<td>任意のデータ形式（構造化されたデータも含む）</td>
</tr>
<tr>
<td>通信</td>
<td>HTTPリクエストごとに送信</td>
<td>送信しない</td>
<td>送信しない</td>
<td>送信しない</td>
</tr>
<tr>
<td>主な利用用途</td>
<td>セッション管理、個別ユーザーの追跡</td>
<td>ページ間で一時的なデータの共有</td>
<td>長期間保持すべきデータの保存</td>
<td>大量かつ複雑なデータの長期保存、オフライン対応アプリケーション</td>
</tr>
</tbody>
</table>
<h1>■ Cookie</h1>
<p>HTTPを介してサーバーとクライアント間で少量のデータを共有するための機能のことです。<br>
WebサイトはCookieを利用してユーザーを識別し、その設定を保存します。</p>
<h3>◎データの生存期間</h3>
<p>セッションクッキーと永続クッキーの2種類が存在します。</p>
<h4>セッションクッキー</h4>
<p>セッションクッキーはブラウザが閉じられると自動的に削除され、主にユーザーがログイン状態を維持するためなどに使用されます。</p>
<h4>永続クッキー</h4>
<p>永続クッキーは設定した期間が経過するまでブラウザに保存され、その期間は数日から数年まで様々。<br>
永続クッキーは、ユーザーのサイト訪問の頻度、利用状況の追跡、サイトのカスタマイズ（例えば、テーマの設定やユーザー設定の保存）などに使用されます。</p>
<h3>◎データ容量</h3>
<p>１つのCookieにつき約4KBしか保存できない</p>
<h3>◎データのアクセス可能領域</h3>
<p>サーバーサイドとクライアントサイドの両方からアクセス可能</p>
<h3>◎データの保存形式</h3>
<p>文字列形式でデータを保存</p>
<h3>◎主な利用用途</h3>
<p>セッション管理、ユーザーの個人設定の保存、閲覧行動の追跡などで利用される。</p>
<h4>利用されているサービス具体例： Amazon</h4>
<p>ログイン状態やショッピングカートの内容を保存するためにCookieを使用しているようです。<br>
これにより、ユーザーがページを移動、ブラウザを閉じて後で再度開いたときでも、自分が選んだ商品がショッピングカートに残っていることが保証されている。</p>
<h1>■ SessionStorage</h1>
<p>一時的なデータ保存用途に適したWeb Storage APIの一部。<br>
ブラウザタブやウィンドウが閉じられると自動的に削除される。リロード時は生き残ります。</p>
<h3>◎データの生存期間</h3>
<p>ブラウザセッション中のみ生存します。ブラウザを閉じるとデータは削除される。<br>
リロード時は保持されます。</p>
<h3>◎データ容量</h3>
<p>一般的に5MBから10MBのデータを保存できる（ブラウザにより異なる）</p>
<h3>◎データのアクセス可能領域</h3>
<p>クライアントサイド（JavaScript）からのみアクセス可能</p>
<h3>◎データの保存形式</h3>
<p>文字列形式でデータを保存する</p>
<h3>◎主な利用用途</h3>
<p>一時的な情報の保存、例えばフォームの入力途中の状態や、ショッピングカートの中身など</p>
<h4>利用されているサービス具体例： Googleマップ</h4>
<p>一つのタブで特定の場所を検索し、別のタブで別の場所を検索した場合、それぞれの検索結果はタブ間で混在しません。<br>
この挙動はユーザーが複数のタブでGoogleマップを開いた場合、それぞれのタブはそれぞれのセッションデータを持つためです。</p>
<p>これは、SessionStorageが各タブやウィンドウに対して独立してデータを保存する仕様により実現されています。</p>
<h1>■ LocalStorage</h1>
<p>永続的なデータ保存用途に適したWeb Storage APIの一部です。手動で削除するまで永続的に保存されます。</p>
<h3>◎データの生存期間</h3>
<p>手動で削除するまで永続的に保存される</p>
<h5>手動で削除</h5>
<ul>
<li>アプリケーション側で何かしらのトリガーで削除されるようにプログラムした場合</li>
<li>ユーザーがブラウザのキャッシュを削除したり、devtools などで削除した場合</li>
</ul>
<h3>◎データ容量</h3>
<p>一般的に5MBから10MBのデータを保存できる（ブラウザにより異なる）</p>
<h3>◎データのアクセス可能領域</h3>
<p>クライアントサイド（JavaScript）からのみアクセス可能</p>
<h3>◎データの保存形式</h3>
<p>文字列形式でデータを保存</p>
<h3>◎主な利用用途</h3>
<p>ブラウザを閉じてもデータが残るため、永続的なデータの保存に適しています。</p>
<h4>利用されているサービス具体例： Twitter</h4>
<p>Twitterでは、ダークモードやライトモードといったユーザーのインターフェース設定をLocalStorageに保存しているようです。<br>
これにより、ユーザーがTwitterを再訪したときに、前回選んだ設定が引き継がれるようになっている。</p>
<h1>■ IndexedDB</h1>
<p>ブラウザ内に構造化されたデータを保存するための高度なWeb API。<br>
複雑なデータ型を扱い、トランザクションもサポートします。<br>
データの読み書きは非同期的（ノンブロッキング）に行われ、大量のデータを扱う際でもUIのパフォーマンスを維持できるようです。</p>
<h3>◎データの生存期間</h3>
<p>手動で削除するまで永続的に保存される</p>
<h5>手動で削除</h5>
<ul>
<li>アプリケーション側で何かしらのトリガーで削除されるようにプログラムした場合</li>
<li>ユーザーがブラウザのキャッシュを削除したり、devtools などで削除した場合</li>
</ul>
<h3>◎データ容量</h3>
<p>ブラウザによりますが、一般的に数十から数百MBのデータを保存可能</p>
<h3>◎データのアクセス可能領域</h3>
<p>クライアントサイド（JavaScript）からのみアクセス可能</p>
<h3>◎データの保存形式</h3>
<p>複雑なデータ型（文字列、数値、日付、配列、オブジェクトなど）を保存可能</p>
<h3>◎主な利用用途</h3>
<p>オフライン対応のWebアプリケーション、大量のデータをローカルにキャッシュする用途など。</p>
<h4>利用されているサービス具体例： Googleドキュメント</h4>
<p>Googleドキュメントは、ユーザーがオフラインでも作業を続けられるよう、作業中のドキュメントをIndexedDBに保存しているようです。<br>
これにより、ユーザーが一時的にオフラインになっても作業の進行が失われることはありません。<br>
そして再びオンラインになったときに、オフライン中に作業した内容が自動的にクラウドに同期されています。</p>
<h1>■ 扱う上での注意点、考慮すべき点</h1>
<h3>◎ セキュアな情報を保存しない</h3>
<p><code>Cookie</code>, <code>SessionStorage</code>, <code>LocalStorage</code>, <code>IndexedDB</code>にパスワードや個人情報などの敏感なデータを直接保存することは避けるべきです。<br>
基本的にデータをブラウザ内に保存するため、ユーザー自身やそのブラウザを操作する他のウェブサイトからアクセスが可能なためです。</p>
<h4>懸念されるセキュリティリスク</h4>
<p>下記、セキュリティリスクがあるようです。</p>
<p>※そこまで調べられていないかつ、冗長になるため詳細の説明は省きます</p>
<ul>
<li><a href="https://developer.mozilla.org/ja/docs/Glossary/Cross-site_scripting">Cross-site scripting (クロスサイトスクリプティング)</a></li>
<li><a href="https://developer.mozilla.org/ja/docs/Glossary/CSRF">CSRF (クロスサイトリクエストフォージェリー、Cross-Site Request Forgery)</a></li>
<li><a href="https://www.google.com/search?q=%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%8F%E3%82%A4%E3%82%B8%E3%83%A3%E3%83%83%E3%82%AF&amp;oq=%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%8F%E3%82%A4%E3%82%B8%E3%83%A3%E3%83%83%E3%82%AF&amp;gs_lcrp=EgZjaHJvbWUyBggAEEUYOdIBBzIxM2owajeoAgCwAgA&amp;sourceid=chrome&amp;ie=UTF-8">セッションハイジャック</a></li>
<li><a href="https://developer.mozilla.org/ja/docs/Web/Security/Same-origin_policy">同一オリジンポリシー</a>の限界</li>
</ul>
<h3>◎ 保存可能容量に制限がある</h3>
<p>一般的には、Cookieは約4KB、SessionStorageとLocalStorageは5MBから10MB、IndexedDBは数十から数百MBを保存できます。<br>
ただ、ブラウザやユーザーの設定により、これらの制限は変動する可能性があるため注意が必要です。</p>
<h3>◎ データの持続性の考慮</h3>
<p><code>Cookie</code>, <code>SessionStorage</code>, <code>LocalStorage</code>, <code>IndexedDB</code>それぞれにデータが削除されるトリガーの考慮が必要です。</p>
<p>また、LocalStorageとIndexedDBに保存したデータは、ユーザーが手動で削除しない限り永続的に存在します。<br>
一方で、ユーザーがデータを予期せず削除したり、ブラウザのデータ消去機能を使った場合にデータが失われる可能性もあります。</p>
<h1>■ さいごに</h1>
<p>最後までお読みいただきありがとうございました！</p>
<p>今回紹介したもののなかでは、<code>LocalStorage</code>しか利用してきませんでした。<br>
今後はセキュリティリスクや、データの容量、データ生存期間を考慮した上で最適なものを選んで実装していきたいです。</p>
<h3>参考にさせていただいたもの</h3>
<ul>
<li><a href="https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API">https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API</a></li>
<li><a href="https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies">https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies</a></li>
<li><a href="https://developer.mozilla.org/ja/docs/Web/API/Document/cookie">https://developer.mozilla.org/ja/docs/Web/API/Document/cookie</a></li>
<li><a href="https://developer.mozilla.org/ja/docs/Web/API/Storage_API">https://developer.mozilla.org/ja/docs/Web/API/Storage_API</a></li>
<li><a href="https://web.dev/storage-for-the-web/">https://web.dev/storage-for-the-web/</a></li>
<li><a href="https://web.dev/indexeddb/">https://web.dev/indexeddb/</a></li>
<li><a href="https://www.youtube.com/watch?v=GihQAC1I39Q">https://www.youtube.com/watch?v=GihQAC1I39Q</a></li>
<li><a href="https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851">https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851</a></li>
<li><a href="https://qiita.com/niihara_megumu/items/be693500d42088027547">https://qiita.com/niihara_megumu/items/be693500d42088027547</a></li>
<li><a href="https://ja.javascript.info/localstorage">https://ja.javascript.info/localstorage</a></li>
<li><a href="https://ja.javascript.info/cookie">https://ja.javascript.info/cookie</a></li>
<li><a href="https://zenn.dev/shimotaroo/articles/4650c0ad73b08a">https://zenn.dev/shimotaroo/articles/4650c0ad73b08a</a></li>
</ul>


ブラウザ標準のデータ保管機能まとめ：Cookie / SessionStorage / LocalStorage / IndexedDB

<p>こんにちは、Another worksのCTO、塩原です。</p>
<p>最近、Another worksではフロントエンドのテスト作成を始める動きがあり、私たちも徐々にテストを書き始めています。<br>
LT会も毎月開催する中で、せっかくなのでそこで話した内容の一部を記事にして公開することにしました。</p>
<h1>今回の目的</h1>
<p>まだテストがほとんど書かれていない状況ですので、まずは「テストを書く」こと自体を習慣化したいと考えています。その一環として、カバレッジレポートが作成できると、テストが増えていく過程を可視化するための一つの指標となり、レビュワーがどれだけテストを網羅して書けているかの確認にも活用できると思います。</p>
<p>ただし、全体のカバレッジレポートだけでは、まだテスト自体をほとんど書いていない現状では、PRを作成する際に新たに書かれたテストを可視化するのが難しいと感じています。そこで、提出するPRの差分がどれだけテストを含んでいるかを可視化するため、新たな取り組みを始めました。</p>
<h1>使用技術</h1>
<ul>
<li>jest &quot;^29.5.0&quot;</li>
<li>@testing-library/react &quot;^14.0.0&quot;</li>
</ul>
<h1>やらなければならないこと</h1>
<p>やらなければならないことは主に二つです。</p>
<ul>
<li>特定のファイルに対するカバレッジレポートを出力すること</li>
<li>生成したカバレッジレポートをPRのコメントとして投稿すること</li>
</ul>
<h1>特定のファイルに対するカバレッジレポートの出力</h1>
<p>まず、jestのカバレッジレポートで特定のファイルに対して出力する方法ですが、以下の公式ドキュメントに方法が記載されています。<br>
https://jestjs.io/ja/docs/cli#--collectcoveragefromglob</p>
<pre><code>$ jest &quot;--coverage&quot; &quot;--collectCoverageFrom=${file_path1}|${file_path2}&quot;
</code></pre>
<p>&quot;|&quot;で区切ることで、複数のファイルに対するカバレッジレポートを一度に出力することが可能です。</p>
<h1>GitHubのPR差分に対して実行する</h1>
<p>GitHubのPR差分を取得するためには、<code>git diff</code>を使用します。ファイルは先ほどのglobパターンに適応するために&quot;|&quot;で区切る必要があります。また、当社ではモノレポを採用しているため、&quot;fc_client_web&quot;というプロジェクトのディレクトリ名を削除しています。</p>
<pre><code>- name: coverage-report
        id: coverage-report
        run: |
          change_files=($(git diff --name-only origin/${GITHUB_BASE_REF}...origin/${GITHUB_HEAD_REF} | grep -E '^fc_client_web/src/.*\.ts(x)?$'))
          for i in &quot;${!change_files[@]}&quot;; do
            change_files[$i]=${change_files[$i]//fc_client_web\//}
          done
          IFS=&quot;|&quot;;files=&quot;${change_files[*]}&quot;;unset IFS;
          npm run unit -- --coverage --collectCoverageFrom=$files --coverageReporters=json-summary
</code></pre>
<h1>生成したカバレッジレポートをPRのコメントとして投稿すること</h1>
<p>カバレッジレポートの生成までは上記で行うことができました。<br>
最後にPRコメントに投稿する方法ですが、<br>
<code>--coverageReporters=json-summary</code> こちらのオプションを付与することで、json形式でレポートの結果を吐き出してくれるのでそのjsonをmarkdownに加工してPRコメントに投稿することができます</p>
<pre><code>- name: Post jest coverage comments
        uses: actions/github-script@v6
        env:
          GH_TOKEN: ${{ github.token }}
          COMMENT: ${{ steps.coverage-report.outputs.GITHUB_ENV }}
        with:
          script: |
            const fs = require('fs')
            const data = JSON.parse(fs.readFileSync('./fc_client_web/coverage/coverage-summary.json', 'utf8'))
            let mdTable = &quot;| File Path | Lines % | Functions % | Statements % | Branches % |\n| --- | --- | --- | --- | --- |\n&quot;;

            for (const path in data) {
                const coverage = data[path];
                mdTable += `| ${path.replace('/home/runner/work/FC_Cloud/FC_Cloud/fc_client_web/', '')} | ${coverage.lines?.pct || 0} | ${coverage.functions?.pct || 0} | ${coverage.statements?.pct || 0} | ${coverage.branches?.pct || 0} |\n`;
            }
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: mdTable
            })
</code></pre>
<p>結果としてはこのようにPRコメントに差分のあるファイルだけがカバレッジレポートとして表示されます。</p>
<p><img src="https://storage.googleapis.com/p_6370f30cc5584de95b79f07e/52e7bf7f-c3dc-4d7d-a7e1-899244ec1afd/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-06-2613.27.48.png" alt="スクリーンショット2023-06-2613.27.48.png"></p>
<h1>まとめ</h1>
<p>カバレッジレポートはあくまでも数値指標の一つでしかないですが、<br>
テストを書く際のモチベーションとしても機能すればと思いこの仕組みを取り入れてみました。<br>
テストについてはまたどこかで記事にできればと思います。</p>


Recent Articles

Another works × コミューン【Developers Meetup エンジニア組織が考える採用戦略】イベントレポート

Another works × ウォンテッドリー成長ベンチャーの開発生産性、なにやってる？【Developers Meetup】

複業から転職へ！Another works エンジニア複業転職の極意

Another works × SmartHR x スタメン【Developers Meetup 急成長ベンチャーが向き合う「開発生産性」】イベントレポート

Another works × freee【DEVELOPER MEETUP! プロダクトの成長を支える強いエンジニア組織のつくりかた】イベントレポート

Another works × SmartHR【顧客に価値を届けるプロダクト志向なエンジニアリング】イベントレポート

Another works × HRBrain 【プロダクト開発を支える技術】イベントレポート

【HTML】要素の入れ子ルールをやぶるとどうなるのか？

2023/06/22 Front-end Deep Dive Online イベントレポート

【React】複数 useRef を使いたくなったときは ref callback function を使おう

ブラウザ標準のデータ保管機能まとめ：Cookie / SessionStorage / LocalStorage / IndexedDB

Github PRの差分ファイルに対してだけカバレッジレポートを自動で出力してみる

Recent Articles

Another works × コミューン【Developers Meetup エンジニア組織が考える採用戦略】イベントレポート

Another works × ウォンテッドリー 成長ベンチャーの開発生産性、なにやってる？ 【Developers Meetup】

複業から転職へ！Another works エンジニア複業転職の極意

Another works × SmartHR x スタメン【Developers Meetup 急成長ベンチャーが向き合う「開発生産性」】イベントレポート

Another works × freee【DEVELOPER MEETUP! プロダクトの成長を支える強いエンジニア組織のつくりかた】イベントレポート

Another works × SmartHR【顧客に価値を届けるプロダクト志向なエンジニアリング】イベントレポート

Another works × HRBrain 【プロダクト開発を支える技術】イベントレポート

【HTML】要素の入れ子ルールをやぶるとどうなるのか？

2023/06/22 Front-end Deep Dive Online イベントレポート

【React】複数 useRef を使いたくなったときは ref callback function を使おう

ブラウザ標準のデータ保管機能まとめ：Cookie / SessionStorage / LocalStorage / IndexedDB

Github PRの差分ファイルに対してだけカバレッジレポートを自動で出力してみる

Another works × ウォンテッドリー成長ベンチャーの開発生産性、なにやってる？【Developers Meetup】