タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
こんにちは、開発チームのアーキテクトをやっている竹野（@Altech）です。先日、新人研修でソフトウェアの設計について話す機会がありました。 ソフトウェアの設計というのは関連する領域が広いため、どうしても断片的な理解になりがちです。そこで、早い段階で全体像を感じてもらうために、ソフトウェア設計の Why と How と What を1時間でまとめて話すというちょっと意欲的なコンセプトで研修を行いました。今回は、その内容を記事にしました。 この研修のねらいはじめにソフトウェアの設計について書かれた情報は世の中に多いですが、その情報の多くは How であり、それだけを読んで適切に使うことが難しいと感じています。その直接的な理由は、How に対しての What、How / What に対しての Why が語られることが少ないからです。 ただ、How だけを知っていると、それは本当に問題を解決して
YAMLは「便利なJSON」として使われることが多い一方、その複雑性から落とし穴も多く、しばしば批判の対象になります。 なぜYAMLはそこまで複雑なのでしょうか? その背景のひとつは、本来のYAMLがJSONとは大きく異なる目的意識で作られているからです。 本稿ではYAML specに従う形でYAMLのコンセプトを解説することを目指します。残念ながら、ここに書かれているYAMLの思想は実際には実用されているとは言い難いですし、これらの背景を理解しても「YAMLは複雑だ」という事実がひっくり返ることはないでしょう。それでも、YAMLの複雑さの源泉を体系的に理解し、YAMLとほどほどの距離感で付き合う助けにはなるのではないかと思います。 この記事ではこういう話をしますYAMLはJSONとは独立に、異なる目的で生まれた野心的な仕様であるアンカーやタグなどの強力な構文は、これらの目的を満たすために
こんにちは。ウォンテッドリーで Enabling チームでバックエンドエンジニアをしている市古（@sora_ichigo_x）です。 現在、Enablingチームでは技術的な取り組みを社外にも発信すべく、メンバーが週替わりで技術ブログをリレー形式で執筆しています。前回は冨永さんによる「Pocket終了に備えてObsidian Web Clipperに移行した話」でした。今回は、実践 Claude Code の話をしたいと思います。 先日、Anthropic から Claude 4 がリリースされ、それに合わせて Claude Code の一般提供が始まりました。これまで研究プレビューだった期間を経て、誰でも利用できるようになっています。本記事には Claude Code を知らない方向けの解説も含みますが、実際の設定・運用がすぐに知りたい方は読み飛ばしてください。 Claude Code
JavaScript: 所望のイベントリスナの発火を妨げているイベントリスナを特定する | Wantedly Engineer Blog
Webアプリケーションでは、DOMの要素にイベントリスナ(イベントハンドラ)を取り付けることで、ユーザーによる様々な操作 (クリックなど) に応じて処理を行うことができます。 しかし、イベントリスナを登録しても、他のイベントリスナとの干渉によって意図した通りに発火しないことがあります。ここではその調査方法を紹介します。 前提知識: イベントバブリングイベントについては筆者の過去記事でも解説しましたが、あらためてここでも説明します。イベントバブリングを理解することが、イベントデバッグの近道だからです。 DOMにおいて、要素はネストすることによって木構造を形成します。ある要素(ターゲット要素)がクリックされるなどしてイベントが発生したとき、イベントはその要素自体だけではなく、その祖先要素にも送られます。これをイベントバブリングといいます。 イベントバブリングは2つの段階に分けられます。 Cap
この記事は夏のアドベントカレンダー4日目の記事です。 こんにちは。ウォンテッドリーのEnablingチームでバックエンドエンジニアをしている冨永(@kou_tominaga)です。技術の変化が激しい今キャッチアップだけでも大変です。私自身、情報収集の方法を常にアップデートしながら「変化に対応できるエンジニア」であり続けたいと思っています。本記事ではそんな私が日々実践している情報収集法とその考え方をお伝えします。取得する情報の選定やキャッチアップ方針に悩んでいる方にとって、情報収集の参考になれば幸いです。 はじめに 情報過多な時代においてなぜ情報収集が大切か 廃れないエンジニアでいるために必要な視点 Feedly（RSSリーダー）で「定点観測」する 技術ブログを継続的に追う意義 RSSリーダーを気軽に確認する方法や習慣 はてなブックマークで「世間の注目」を押さえる 社内Slackで「仲間経由
和田 卓人さん（t_wadaさん）に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」を社内で講演いただきました！ | Wantedly Engineer Blog
和田 卓人さん（t_wadaさん）に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」を社内で講演いただきました！ こんにちは、ウォンテッドリーDev Branch VPoE 室長の髙橋です。 ウォンテッドリーの開発組織であるDev Branchでは、外部から有識者を招いて勉強会を開催したり、技術顧問として知見を取り入れるなど、プロダクト開発により強い組織となるためにさまざまな施策を行っています。 今回、「テスト書いてないとかお前それ @t_wada の前でも同じ事言えんの」 でおなじみのt_wadaさん（和田 卓人さん、以下和田さん）に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」をウォンテッドリー向けにカスタマイズして講演いただきました。 このストーリーでは、今回の講演の経緯から社内の反応・Q&Aまで、講演に関する詳細をご紹介いたします。 社内講演のきっ
Rails 7.0ではフロントエンドサポートが刷新されます。新たなライブラリが多数導入され、選択肢が増えるため、「Rails公式のものを選べばOK」という戦略が通用しなくなります。 本稿では、Railsでフロントエンドを書くための選択肢について、その歴史と実装を踏まえて比較検討します。 結論から言うと(まだアルファ版なので今後も状況が変わる可能性はありますが、) 新規アプリケーションではSprocketsの役割は無くなりそうです。新しいライブラリとして Propshaft, importmap-rails, jsbundling-rails, cssbundling-rails が登場し、主要な選択肢として以下が提供されます。 (各ライブラリの詳細については後述します) Propshaft + importmap-railsデフォルトの選択肢。Node.jsが不要。トランスパイルを含め、複
日付や時刻データの扱いについてまとめたスライド「日付時刻A to Z」を作ったので公開します。 これは何？「日付と時刻」を正しく扱うために、日付/時刻にまつわる諸概念やありがちな間違いを紹介したスライドです。このスライドは大きく3つのパートに分かれています: 第1部「日付編」§1 天体の周期§2 暦§3 紀元と通日第2部「時刻編」§4 時間と分§5 秒§6 相対性理論第3部「コンピューティング編」§7 文字列表現§8 数値表現§9 時刻同期第1部と第2部では、「日付」や「時刻」の概念を定めるのに必要な知識を整理します。第3部ではその日付時刻をコンピューターで扱うときに特有の事情を補足しています。 このスライドが作られた経緯ウォンテッドリー社内では毎週1回お昼の時間に任意で集まって技術の話をする "Tech Lunch" というイベントがあります。テーマは自由で、社内でやったことの紹介やアナ
こんにちは。ウォンテッドリーのInfra Squadでエンジニアをしている笠井（@takayukikasai）です。 昨今サービス事業者を狙った様々なセキュリティ脅威が増加しています。DoS/DDoS攻撃やスクレイピングによる情報収集、Webアプリケーションの脆弱性を狙った攻撃など攻撃手法は多様化・高度化しています。IPアドレスベースのアクセスブロックなど静的情報を用いた防御だけでは工夫を凝らした攻撃に対応しきれず、サービスの可用性・信頼性を守ることが困難になってきています。このため、常に変化する状況に対応するための動的な防御が重要です。 AWS WAFはマネージドサービスとして既存のALB/CloudFrontに比較的容易に適用できますが、効果を出す運用設計は別の難易度があります。ウォンテッドリーでは約2年前からAWS WAFを実運用し、ルールの設計・運用・継続的改善を行ってきました。本
2025年から Elasticsearch に入門して、同義語検索を理解する | Wantedly Engineer Blog
こんにちは。ウォンテッドリーの Enabling チームでバックエンドエンジニアをしている市古（@sora_ichigo_x）です。 現在、Enabling チームでは技術的な取り組みを社外にも発信すべく、メンバーが週替わりで技術ブログをリレー形式で執筆しています。前回は私、市古による「おすすめ Claude Code 設定・運用まとめ」でした。今回は Elasticsearch の話をします。 Elasticsearch は高度な検索と分析を実現する検索エンジンとして広く活用されています。 しかし、その仕組みをブラックボックスに感じているエンジニアは多いのではないでしょうか。 このブログでは Elasticsearch の全文検索に入門し、同義語検索のような応用的なユースケースの仕組みまで理解することを目指します。 なお、このブログは執筆時点（2025年6月17日）で最新である Elas
令和最新版: PostgreSQLの安全なSET NOT NULL | Wantedly Engineer Blog
データベースのスキーマを変更するときは、スキーマの変更作業によってテーブルが長期間ロックされてしまわないように注意が必要です。 2019年にリリースされたPostgreSQL 12.0以降では、NOT NULLを安全に追加するためによりよいベストプラクティスができています。まだ知らない人もいるかもしれないので、ここで紹介します。 何が問題なのか?次のようなDDLコマンドを考えます。 -- posts.moderatedをNULL禁止にする ALTER TABLE posts ALTER COLUMN moderated SET NOT NULL;これはテーブルをACCESS EXCLUSIVEでロックしたままフルテーブルスキャンを行います。その間は他のトランザクションはこのテーブルに関する処理を進行できません。 テーブルが小さければこれで特に問題ありません。しかし、postsがそれなりに大
こんにちは。ウォンテッドリーのEnablingチームでバックエンドエンジニアをしている小室(@nekorush14)です。現在、Enabling チームでは技術的な取り組みを社外にも発信すべく、メンバーが週替わりで技術ブログをリレー形式で執筆しています。前回は冨永さんによる「月次振り返りにかかる時間を大幅に短縮した方法」でした。今回はNotebookLMの話をします。 はじめに NotebookLMを活用して登壇資料を作成する 手持ちのドキュメントをソースにする Webページをソースにする Studioで理解を深める NotebookLMを活用した事後学習の機会を提供する スライドともにNotebookLMも共有する まとめ 参考 はじめにNotebookLMは、自身がアップロードしたドキュメント (Google Docs, PDF, Webページ等)をソースとして対話できる、Google
「直近バイアス」からの脱却。NotebookLMを使った客観的フィードバック術！ | Wantedly Engineer Blog
はじめに なぜNotebookLMなのか？ 「客観性」を生む理由 評価・振り返りにおける3つのメリット NotebookLM活用事例 1. マネージャーとしての評価業務への活用 2. 個人の振り返りへの活用 生成AIツールを組み合わせて適材適所で使い分け 生成AIツールのパイプライン 生成AIツールの使い分け まとめ：生成AIと共に成長する組織 はじめにこんにちは、ウォンテッドリー CTOの安間です。 自分自身の分析やメンバーへの評価を客観的に振り返ることができていますか？半期や期末の評価、あるいは日々の自己学習において、「なんとなく頑張った気はするけど、具体的に何がどう成長したのか説明しづらい」「直近の成功体験や失敗体験に評価が引っ張られてしまう」といった経験はないでしょうか。 こうした認知バイアスは、振り返りにおいて大きな課題だと私は考えています。この記事では、私自身が評価や自己の振り
新しく Wantedly の開発チームに参加する人向けのドキュメント集です。社内のエンジニアが知るべき情報のうち外部にも公開できる情報を体系的にまとめたものです。 入社前後のフルタイムの社員が一番の想定読者です。ハンドブックの内容はインターンや採用選考を受けている人にも役に立つことを期待しています。また、PDF 形式の電子書籍およびオンラインドキュメントとして広く一般公開しています。1 年に 1 度、物理書籍としても印刷し社内外に配布します。
こんにちは！ウォンテッドリーのVisit Client Growth Squadに所属している佐藤です。今回は、スケジュール遅延に対して制約のあるプロジェクトにおいて、3点見積もりを活用して計画通りに進捗した経験と、その手法についてご紹介します。 なぜ高精度な見積もりが必要だったのか 3点見積もりというアプローチ 3点見積もりとパーセント確度によるリスク管理術 ステップ1：見積もりの精度を高めるためのタスク分解 ステップ2：未来を「範囲」で捉え、期待値を算出する ステップ3：見積もりの「ブレ」をリスクとして計画に組み込む まとめ なぜ高精度な見積もりが必要だったのか見積もり精度の不足は、現代のソフトウェア開発プロジェクトにおける遅延リスクの主要な原因の1つです。機能要件の詳細化、品質基準の遵守、そしてステークホルダーからの納期プレッシャーなど、多様な制約が求められる環境において、この問題は
ノンデザイナーズ・Wantedly デザインシステム完全理解ペーパー | Wantedly Engineer Blog
Wantedly では新卒含む新入社員向けに研修を毎年実施しています。これは「新入社員向け」といいつつ既存の社員も自由に参加できるものです。今年はこの研修のフォーマットを借りて、Wantedly のプロダクト開発を支える重要な概念のひとつである「Wantedly の UI デザインシステム」についての研修を、ソフトウェアエンジニアの @izumin5210 (筆者) とプロダクトデザイナーの @NishaMe で実施しました。 デザインの構造を正しく捉えることは、UI の実装を専門にしているかどうかを問わず、正しい実装 - 開発生産性が高く、ユーザにとっても使いやすい実装 - のための重要なポイントです。よってこの研修は「広義のフロントエンドエンジニア」、業務中に UI を実装することがある全てのエンジニアを対象としました。 Web フロントエンドエンジニアモバイルエンジニア専門ではないが
hi18n (i18nライブラリ) の紹介 (1) 設計思想と基本方針 | Wantedly Engineer Blog
hi18nとはhi18n は現在Wantedlyで開発中の、TypeScript/JavaScript向け翻訳テキスト管理ライブラリ (i18nライブラリの一種) です。 本記事ではhi18nの重要な設計上の判断やその背景について説明します。 GitHub - wantedly/hi18n: message internationalization meets immutability and type-safety Installation: npm install @hi18n/core @hi18n/react-context @hi18n/react npm install -D @hi18n/cli # Or: yarn add @hi18n/core @hi18n/react-context @hi18n/react yarn add -D @hi18n/cli Put the
こんにちは。ウォンテッドリーの Enabling チームでバックエンドエンジニアをしている市古（@sora_ichigo_x）です。 現在、Enabling チームでは技術的な取り組みを社外にも発信すべく、メンバーが週替わりで技術ブログをリレー形式で執筆しています。前回は小室さんによる「【入社エントリー】なぜSIer出身者がウォンテッドリーへ転職したのか」でした。今回は私が日頃から仕事で大事にしている段取りの話をします。 はじめにこの機能をまるっと任せたい / この課題をなんとかしてほしい エンジニアとして経験を積んでいくと、ある時から「この機能をまるっと任せたい」「この課題をなんとかしてほしい」といった、粒度の大きな仕事を任される機会が多くなります。実装方針やタスクの切り方、スケジュールの立て方まで自分で考える必要があり、責任と裁量の両方を担うことになります。しかしその自由度ゆえに「どう
こんにちは。ウォンテッドリーの Enabling チームでバックエンドエンジニアをしている市古（@sora_ichigo_x）です。 最近はハードスキル寄りのブログが多かったので、今回はソフトスキルの話をしようと思います。 はじめに 「いいアイデアだと思ったのに、なぜ通らないのか？」 アンチパターン 最初から「これ一択」で話し始める 一択の提案は不安を呼び込む その提案は本当に比較できているか アイデア自体には価値がある 一択ではなく、選択肢を見せる 「他には？」を先回りする 「AではなくBがいい」と言えるか 結論を急がず、分岐を見せる 具体例：次の四半期の開発計画を立てる 最初に思いついた「これ一択」 一択では質問に答えられない 分岐を用意してみる 最初に思いついた最適解を否定する必要はない テーマを意識する おわりに はじめに「いいアイデアだと思ったのに、なぜ通らないのか？」自分なりに
JavaScriptでは任意の値を例外としてthrowすることができますが、実際にはErrorのインスタンスをthrowするのが慣例です。 エラーの原因をより正確に説明したいときはErrorを継承するのが望ましいですが、単に継承するのではなく以下のように書くのがオススメです。 class MyError extends Error { static { this.prototype.name = "MyError"; } }その背景について以下で説明します。テーマは以下の3つです。 nameプロパティcaptureStackTracecauseプロパティnameを正しくセットするNode.jsでエラーを表示させると、クラス名が正しく表示されます。 > throw new (class C extends Error {})() Uncaught C [Error]ここで出力されている "C
現在WantedlyではNode.jsのパッケージ管理にyarn v1を使っています。現在私は開発者体験の改善を目指してyarn v2への移行を検討しているのですが、その過程でyarn v2が誤解されがちだと感じるようになりました。そこで社内への情報提供も兼ねて、いくつか誤解されがちだと思われる点を紹介したいと思います。 (わかりやすさのためにyarn v2と呼んでいますが、 yarn v3以降も含みます。これらはメジャーバージョンアップではあるもののyarn v1→v2のようにアーキテクチャが刷新されるわけではないからです) ポイント1: yarnをv2にするのにPnPは必須ではないyarn PnPはyarn v2の目玉機能で、パッケージをnode_modules以下に展開せずに仮想化してロードできるようにするというものです。node_modulesの展開作業が不要になるほか、依存関係の
実践 Node.js Native ESM — Wantedlyでのアプリケーション移行事例 | Wantedly Engineer Blog
Wantedlyではこのたび、フロントエンドアプリケーションのひとつをNative ESM化しました。本記事ではNative ESM化の必要性と、必要な作業について説明します。 この記事の概要Node.jsにはNative ESMというモードがある。Native ESMはまだ普及していないが、ライブラリ側の更新が進み、移行が必要になりつつある。Native ESMをめぐる状況は (この記事の長さからわかるように) 色々複雑で、概念をちゃんと説明するだけでも大変。Native ESMへの移行にあたってはさまざまな困難が待ち受けている。Native ESMとは歴史的経緯から、JavaScriptには複数のモジュールシステムがあります。そのうちNode.js周辺でよく使われるのはCommonJS ModulesとES Modulesです。 CommonJS Modules (CJS) は実質的に
見積もりの定義 知見1：見積もりの目的によってやり方を変える 意思決定のための見積もりの場合 計画・実行のための見積もりの場合 知見2: 信頼性の期待値をコントロールする 知見3: チームで見積もる 見積もりを成長の機会に変える おわりに 見積もりの定義まずは、このブログで扱う「見積もり」という言葉の定義を明確にしたいと思います。 開発における「見積もり」とは、プロジェクトを進める上で必要となる時間、コスト、そしてリソースを予測するプロセスです。これは、現時点で既にある情報や、潜在的なリスクを分析した結果に基づいて、将来の成果物や活動を定量的に予測することを指します。 この「見積もり」と混同されやすい言葉として、「ターゲット」と「コミットメント」があります。それぞれの言葉の定義もここで整理しておきましょう。 ターゲット: ビジネス要請や戦略的目標から設定される、理想的な目標日や目標値のこと
Pocket終了に備えてObsidian Web Clipperに移行した話 | Wantedly Engineer Blog
こんにちは。ウォンテッドリーのEnablingチームでバックエンドエンジニアをしている冨永(@kou_tominaga)です。Enablingチームでは技術的な取り組みを社外にも発信すべく、メンバーが週替わりで技術ブログをリレー形式で執筆しています。前回は市古さんによる「BigQuery × GitHubで始める行動量の可視化【AI導入後の変化をラフに捉えるために】」 でした。今回は「Pocket終了に備えてObsidian Web Clipperに移行した話」についてです。 Mozilla社が提供していた「あとで読む」サービスPocketが2025年7月8日で終了します。技術記事やインスピレーションになる投稿を日々集めておりPocketの終了は大きな痛手でした。 そこで代替ツールを検討した結果「Obsidian Web Clipper」に移行することを決めました。本記事では私がなぜObs
Wantedlyでプロダクトデザイナーをしているkanon(@prgbunbun)です！Wantedlyで行われている夏のアドベントカレンダー12日目の記事として、誰でも作れてしまう時代だからこそ、非デザイナーの方にも知っておいてほしいデザインの話をしていこうと思います。 生成AIの発達によって、誰でもソフトウェア開発ができるようになりました。知識や経験がない状態でも、生成AIと共にプロダクトを作り上げ、稼ぎを出す人も出てきましたね。 しかし、ソフトウェア開発でまだまだ欠かせないのが、UIデザインです。UIはただの画面上の装飾のことではありません。対象となるユーザーが、どういった流れで画面内の情報を認知していくのか、ボタンを押したらどうなるのか、全体の体験をあらかじめ設計しておく必要があります。この分野は、「インタラクションデザイン」と呼ばれることもあります。 インタラクションデザイン 人
Wantedly の UI デザインシステムは「WantedlyのUIをデザインする上での共通の考え方とツール＆アセット」でありエンジニアとデザイナが効率よくコミュニケーションするための共通言語となる デザインシステムを (Web) Frontend に持ち込む際は、単なるコンポーネントカタログではなく、システムが定義するものと同じレベルの抽象を持つライブラリ・フレームワークとして実装することで、より有効性を発揮する Wantedly におけるデザインシステムは、「プロダクト・デバイスをまたいでも・誰がデザインしても体験やブランドとしての一貫性を保つ」「デザインの生産性を向上させ、デザイナ - エンジニア 間コミュニケーションを改善することで、ユーザに価値を届ける速度を向上させる」といった目的のために作られたものです。 より詳しくは、デザインシステムが加速させるプロダクト開発 / Desi
Claude Code の Agent Skills を活用してリポジトリのオンボーディングを効率化する | Wantedly Engineer Blog
こんにちは。ウォンテッドリーでバックエンドエンジニアをしている小室 (@nekorush14) です。今回は、Claude Code の Agent Skills を活用してリポジトリのオンボーディングを効率化する取り組みについて紹介します。 先日、日々の業務改善や効率化につながる課題の解決がテーマの社内AIハッカソンが開催されました。私は自分自身が入社した時につまずいた「ドキュメントを読んでも全体像がつかめない」や「環境構築で謎のエラーが出る」などのオンボーディングに関する課題の解決に取り組みました。 その中で、Claude Code のコンテキストとしてリポジトリの「手がかり」と「地図」、そして「手順」を持たせ、リポジトリに慣れていないエンジニアが自走可能な仕組みの構築を目指しました。 目次はじめに Agent Skills を活用する リポジトリの概要をナレッジとして埋め込む サービ
開発組織の全員が Devin と Cursor を活用するための取り組み | Wantedly Engineer Blog
組織的な生成 AI 活用における課題 生成 AI だけで開発する AI Enabling 会 AI Enabling 会を実施して得られた結果と学び 最後に 余談 組織的な生成 AI 活用における課題ウォンテッドリーの開発組織では生成 AI 活用が個々に委ねられており、組織的な生産性向上に繋がっていない課題がありました。個人だけでなくエンジニア全員が活用できるようにするために、開発組織全体で生成 AI 活用を推進する AI Enabling Squad というチームが 2025 年 5 月に発足しました。 AI Enabling Squad では、「開発組織が生成 AI を活用し、プロダクトをより高速に開発可能にする」というミッションを掲げて日々活動しています。具体的には次のような取り組みをしています。 Cursor や Devin といったコーディングエージェント系のツールや ChatG
こんにちは。ウォンテッドリーでデータサイエンティストとして働いている市村（@chimuichimu1）です。この記事は Wantedly Advent Calendar 2024 の22日目の記事です。 私は普段業務で推薦システムの開発に携わっており、プロダクトを継続的かつ効率的に改善していくため、コードの内部品質が重要だと感じています。内部品質が保たれていないコードベースでは、機能追加や改善のスピードが落ちるだけでなく、バグの温床にもなります。 こうした内部品質を担保する１つの手段として、静的解析ツールの利用が考えられます。この記事では近年注目されている Python の静的解析ツールの Ruff について紹介したうえで、特にその高速性に焦点を当て、それがどう実現されているかについて深堀りしたいと思います。 Ruff とはRuff は Python 用の静的解析ツールであり、ソースコード
Next.js アプリケーションの version skew 問題に向き合う | Wantedly Engineer Blog
こんにちは。ウォンテッドリーでフロントエンド組織のリーダーをしている原 (@chloe463) です。 この記事では、数ヶ月前我々のプロダクトで起きていた不具合の原因と解決策について解説します。 大きく2つの問題が起きていましたが、一見すると無関係に見えた2つの不具合が、1つの重要な仕組みに起因するものでした。その発見が個人的にはアハ体験だったため、その発見の衝撃や喜びを共有したいと思います。 2025/07/08 追記 公開後に「Next.js には Version Skew を防ぐ機能がすでに含まれているため、他のところに原因があるのでは？」という指摘を頂きました。ありがとうございます。 自分の手元で新規の Next.js アプリケーションを立てて調べたところ、たしかにご指摘の通りでした。 したがって、多くの場合 Next.js を使ったアプリケーション開発において、Version S
3ヶ月でチームは変わる。Wantedly QAが示した『小さく始めて、確実に機能させる』組織変革の具体例 | Wantedly Engineer Blog
こんにちは、QAエンジニアの青柳です。 この記事はウォンテッドリー・アドベントカレンダー2025夏の10日目の記事です。 本記事では、私が中途入社したQA Squad（品質保証チーム）において、約3ヶ月という短期間でどのように課題を特定し、チームの協力のもとで非効率なプロセスを改善し、自律的なチームへと変革を進めてきたかをお話します。 特に、「既存のチーム文化や意思決定プロセスを尊重しながら、いかに加速させるか」というテーマに対し、どのように考え、具体的にどんな実践を行ったのかに焦点を当てています。 この取り組みはQA Squadにとどまらず、組織全体への波及効果を意識して進めてきました。そのため、QAに限らずどのチームでも応用しやすいよう、技術論にとどまらず、チーム変革に役立つ汎用的なアプローチを中心にご紹介します。 1.チーム変革のステップと汎用的なアプローチ 1-1.初期の課題解決へ
はじめにこんにちは、Wantedly の 2021 年サマーインターンに参加した宮下と申します。今回のインターンでは三週間の間 DX (Developer Experience) チームに所属し、Wantedly のコードベースに Ruby の型チェッカーの導入を試みることをテーマにしていました。 インターンの前半では、様々な型チェッカーの性能を調べたり、それぞれの型チェッカーを実際に使ってみることで、開発効率を基準とした比較を行いました。インターンの後半では、現段階では一番実務に適しているだろうと判断した Sorbet に焦点を当て、Wantedly のいくつかのコードベースに実験的に Sorbet を導入した環境を作った型情報をつけていく作業をしていました。 本記事は、主にインターンの前半で調査した、型チェッカーの比較という部分に焦点を当て、文章の形にまとめたものになります。 Ruby
夏のアドベントカレンダー11日目は、ウォンテッドリーでアナリティクスエンジニアをしている木村（@akimu294231）より発信します！ 普段はBI Squadというチームの一員として、データ基盤の整備や各部門からの集計依頼対応に携わっています。日々ビジネスサイドやエンジニアと連携しながら、データを「使える形」に変換し、意思決定に活かしてもらうことが私たちの役割です。この記事では、アナリティクスエンジニアが直面する「曖昧な依頼」や「不確実なタスク」にどう向き合い、どのような考え方でタスクを設計・遂行しているかを紹介します。私自身が業務の中で感じていた課題や、実践しているアプローチも交えながら、チームとしてどのように成果に向き合っているかをお伝えできればと思います。 要求（Why）と要件（What）の整理集計や可視化を行う前に、まず依頼の背景を丁寧に確認しています。その背景とは、「なぜそのア
OSSか、それともSaaSか。グローバルを見据えたプロダクト開発へ向けて | DevLounge.jp Opening Session レポート | Wantedly, Inc.
エンジニアリング界をリードする著名人が「いま話を聞きたい」開発者を直接指名し、日頃なかなか聞けない開発トピックについて語り尽くすオンライントークセッション「DevLounge.jp」。このイベントのオープニングを飾ったのは、Nature株式会社VPoEのSongmuこと松木雅幸氏と、ローンチャブル(Launchable）Co-CEOの川口耕介氏です。 Songmu氏は日本で、川口氏はアメリカ・カリフォルニアでそれぞれ活躍されています。セッションでは、お二人が感じるオープンソースソフトウェア(OSS)とSaaSの違いから、グローバル展開を目指す際の考えなどを語っていただきました。その一部をご紹介します。 Songmu(松木雅幸)Nature株式会社VPoE。大学で中国語と機械翻訳を学び、中国でIT分野での起業、語学学校でのシステム担当兼営業、印刷系SIerでの金融系Webシステムや物流システ
現代のビジネス環境におけるリーダーシップとマネジメントの重要性 リーダーシップとは マネジメントとは リーダーシップとマネジメントの違い リーダーシップとマネジメントの相互補完性 実務におけるリーダーシップとマネジメントの交差点 まとめ 現代のビジネス環境におけるリーダーシップとマネジメントの重要性VUCA（変動性・不確実性・複雑性・曖昧性）の時代と言われるように、今のビジネス環境は非常に複雑で変化に富んでいます。組織の中では新しい方向性が求められる一方で、確実な成果を出すための安定運営も同時に求められます。このような環境下で必要とされるのが、リーダーシップとマネジメントのバランスです。両者はしばしば混同されがちですが、実は役割も機能も異なります。 リーダーシップとはリーダーシップとは、組織やチームに方向性を示し、メンバーの内発的動機を引き出して共に進んでいく力のことです。その本質は、「な
記事のゴール 導入背景 PCセットアップの悩み dotfilesという解決策 chezmoiの特徴と選定理由 dotfiles managerの比較検討 chezmoiの特徴 初期セットアップコマンド 運用フロー 運用Tips 設定漏れ防止 テンプレート化と環境変数管理 トラブルと改善 まとめ 記事のゴール本記事ではdotfilesとは何か、管理しない場合の問題、chezmoiの特徴や選定理由、1年間運用して分かったメリット、実際の運用フロー、トラブルとその改善策を実体験をもとにまとめています。dotfiles管理に興味はあるものの手を出せずにいた方が、導入から運用までの具体的イメージを持ち、次回以降のPCセットアップを数十分で完了できる再現性の高い環境構築ができるようになることを目指しています。 導入背景PCセットアップの悩み私はこれまでMacを買い替えたり業務用PCが支給された際に開発
ウォンテッドリーのバックエンド領域を支える言語の歴史を読み解く | Wantedly Engineer Blog
こんにちは、ウォンテッドリー株式会社でインフラエンジニアをやっている @fohte です。 筆者はウォンテッドリーに join して 1 年が経過しようとしており、ようやくウォンテッドリーが採用しているアーキテクチャについて全貌が掴めてきました。そこで改めてウォンテッドリーの技術スタックを考え直してみると、ウォンテッドリーのバックエンド領域において利用している言語はなぜ採用されているのかが気になりました。今回はそれを読み解くべく、過去から現在までに利用されている言語の比率から、その背景と歴史を追っていきます。 ウォンテッドリーで採用している言語とアーキテクチャの歴史まずはじめに、ウォンテッドリーでは下図の技術およびアーキテクチャを選定しています。 (参考: 技術とアーキテクチャ - Wantedly Engineering Handbook) 本記事では、この図での "The System
本記事は Wantedly 21新卒 Advent Calendar の17日目の記事です。本記事では、いくつかの言語の型システムに実装されている様々な機能を紹介するとともに、それが型推論の実現性に与える影響について述べます。 最近静的型付き言語が盛り上がりを見せ、動的型付き言語の筆頭格だった Ruby もバージョン 3.0 で型解析ツールを導入するまでに至った一因には、きっと型推論の有用性が知られるようになったことが挙げられることでしょう。C言語で、関数ポインタを含んだ複雑なプロトタイプ宣言を書いている時ほどストレスを感じる時間はないし、かと言って Ruby on Rails で書かれたバックエンドを弄っている時に、型チェッカがあれば自明に発見できたであろうエラーでインシデントを起こすほど悲しいことはありません。プログラマが型を書かなくても静的な型チェックの恩恵を受けられる型推論の、何と
1on1は「報告」ではなく「自分への投資」である。成長を最大化するための対話ハック | Wantedly Engineer Blog
こんにちは、QA Squad の青柳です。 日々の業務に追われていると、週次の1on1がつい「タスクの進捗を共有して終わるだけの時間」になってはいないでしょうか。私自身も以前は、1on1を受動的な報告の場として捉えていました。しかし、1on1を自分自身の成長のために「使い倒す」という意識に変えたところ、上長との期待値のズレが激減し、迷いなく仕事を進められるようになりました。本記事では、1on1を能動的な成果創出の場へとアップデートするための具体的な実践法を共有します。 目次1on1の再定義 : 上長を「最強の支援者」にする 実践1 : 能力開発と期待値の調整 実践2 : 性格特性を活用したコミュニケーションの最適化 実践3 : 組織視点での「限界」の打破 視点の拡張 : 多角的な気づきを得る「斜めの1on1」 まとめ 1on1の再定義 : 上長を「最強の支援者」にする1on1には、情報の同
競技プログラミングには概念を知っておかないと解きようがない、いわゆる覚えゲーのような問題が存在します。典型的な例が 10^9+7 といった素数で割った余りを求めろといったもので、普段業務で日常的に素数で割った余りを求めている人でもなければ、割り算がしたければフェルマーの小定理や拡張ユークリッドの互除法を使えば良いと直ぐには思い付けないのではないでしょうか。 最小共通祖先も覚えゲーで必要な概念の一種と言えます。これは読んで字のごとく、与えられた根付き木の下で2頂点に共通する祖先のうち、最も根から遠い頂点を指す概念で、例えば木の2頂点が与えられて、頂点間の経路について何かを求めろといった問題で威力を発揮することが多いです。これを用いて解ける例を挙げるとすると次の問題でしょうか。 https://atcoder.jp/contests/abc014/tasks/abc014_4 最小共通祖先を求
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア設計の Why & What & How | Wantedly Engineer Blog
「YAMLの本来の使い方」を仕様から読み取ってみる | Wantedly Engineer Blog
おすすめ Claude Code 設定・運用まとめ | Wantedly Engineer Blog
ソフトウェアエンジニアが実践する情報収集術 | Wantedly Engineer Blog
Rails 7.0でアセットパイプラインはどう変わるか | Wantedly Engineer Blog
発表資料「日付時刻A to Z」を公開しました | Wantedly Engineer Blog
AWS WAF実運用で学んだルール設計・運用・改善のコツ | Wantedly Engineer Blog
NotebookLMを活用して登壇資料を作成した話 | Wantedly Engineer Blog
Wantedly Engineering Handbook
3点見積もりで実現する、遅延しないプロジェクト計画術 | Wantedly Engineer Blog
なぜ、仕事が大きくなると手が止まるのか | Wantedly Engineer Blog
自分なりの最適解で終わらせず、提案できるエンジニアになる | Wantedly Engineer Blog
JavaScriptのカスタムエラーはこれでOK | Wantedly Engineer Blog
yarn v2にまつわる誤解 | Wantedly Engineer Blog
見積もりで悩まないための３つの知見 | Wantedly Engineer Blog
誰でも作れてしまう時代に知っておきたいデザインの話 | Wantedly Design
Web アプリのデザインシステムライブラリ | Wantedly Engineering Handbook
Ruff はなぜ速いのか？ | Wantedly Engineer Blog
Ruby の型チェッカーの比較 | Wantedly Engineer Blog
不確実な依頼を着実に前に進めるタスク設計の考え方 | Wantedly Engineer Blog
成果が止まるチームに足りないのは「Why」か 「How」か | Wantedly Engineer Blog
chezmoiでdotfilesを1年間運用した知見について | Wantedly Engineer Blog
計算機に推論できる型、できない型 | Wantedly Engineer Blog
最小共通祖先を求めるアルゴリズムの形式検証 | Wantedly Engineer Blog
blog.livedoor.jp/sfujioka1
monox.hateblo.jp
www.aranciarossa.work
suijun-hibisukusu.hatenablog.com
hamster-sauna-games.com
trivia-and-know-how-notes.com