タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
こんにちは、開発チームのアーキテクトをやっている竹野（@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
Wantedly でバックエンドのテックリード的なやつをやってる @izumin5210 です。半年くらい前から取り組んでいた、UI デザインシステムの React 実装について紹介します。ソフトウェアの設計としても非常にエキサイティングだったので、ライブラリ作ったりするのが好きな人なども楽しんでもらえると思います。 TL;DRWantedly の UI デザインシステムは「WantedlyのUIをデザインする上での共通の考え方とツール＆アセット」でありエンジニアとデザイナが効率よくコミュニケーションするための共通言語となるデザインシステムを (Web) Frontend に持ち込む際は、単なるコンポーネントカタログではなく、システムが定義するものと同じレベルの抽象を持つライブラリ・フレームワークとして実装することで、より有効性を発揮するこの話が気になった（Web・モバイル問わず）フロント
こんにちは！ Wantedly で Web エンジニアをしている木村（@hachiblog）です。8月にβ版をリリースした、コンディション・マネジメントサービスのWantedly Pulseを開発しています。 Pulse は毎週の調子を記録する機能や、社内のメンバーを称賛できる機能を提供していますが、そのほとんどを Slack アプリ内で実現しています Pulse（パルス）/ チームの状態 Slackを通じてチームの価値観を浸透させ、メンバーの抱える課題や隠れた貢献を可視化。行動のベクトルを束ね、自律して同じ価値に向かうチームを生み出す、新しいモチベーション・マネージメントツールです。 Slackを通じてメンバーの抱えるモチベーションの課題や隠れた貢献を可視化。行動のベクトルを束ね、自律して同じ価値に向かうチームを生み出します。 ... その他にも Wantedly Visit で募集に応
Webアプリケーションでは、DOMの要素にイベントリスナ(イベントハンドラ)を取り付けることで、ユーザーによる様々な操作 (クリックなど) に応じて処理を行うことができます。 しかし、イベントリスナを登録しても、他のイベントリスナとの干渉によって意図した通りに発火しないことがあります。ここではその調査方法を紹介します。 前提知識: イベントバブリングイベントについては筆者の過去記事でも解説しましたが、あらためてここでも説明します。イベントバブリングを理解することが、イベントデバッグの近道だからです。 DOMにおいて、要素はネストすることによって木構造を形成します。ある要素(ターゲット要素)がクリックされるなどしてイベントが発生したとき、イベントはその要素自体だけではなく、その祖先要素にも送られます。これをイベントバブリングといいます。 イベントバブリングは2つの段階に分けられます。 Cap
この記事は夏のアドベントカレンダー4日目の記事です。 こんにちは。ウォンテッドリーのEnablingチームでバックエンドエンジニアをしている冨永(@kou_tominaga)です。技術の変化が激しい今キャッチアップだけでも大変です。私自身、情報収集の方法を常にアップデートしながら「変化に対応できるエンジニア」であり続けたいと思っています。本記事ではそんな私が日々実践している情報収集法とその考え方をお伝えします。取得する情報の選定やキャッチアップ方針に悩んでいる方にとって、情報収集の参考になれば幸いです。 はじめに 情報過多な時代においてなぜ情報収集が大切か 廃れないエンジニアでいるために必要な視点 Feedly（RSSリーダー）で「定点観測」する 技術ブログを継続的に追う意義 RSSリーダーを気軽に確認する方法や習慣 はてなブックマークで「世間の注目」を押さえる 社内Slackで「仲間経由
和田 卓人さん（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を実運用し、ルールの設計・運用・継続的改善を行ってきました。本
ある日、海外チームからバグの報告がありました。日付と曜日が対応していないというのです。 テスト環境でいくつか設定を変更して試したところ、OSのタイムゾーンをシンガポール標準時 (UTC+8) に変更したときに、曜日が2つずれることが確認できました。4/2は金曜日ですが、4/2が水曜日として表示されてしまっています。 原因調査この部分のソースコードはだいたい以下のようになっていました。Moment.jsというライブラリを使って日付と曜日を表示しています。 // TimelineItem.jsx // date は 2021-04-02 のような文字列 const DateBox = ({ date, showMonth }) => { const mDate = moment(date); const dateHuman = showMonth ? mDate.format("M.D") :
こんにちは。ウォンテッドリーの Enabling チームでバックエンドエンジニアをしている市古（@sora_ichigo_x）です。 現在、Enabling チームでは技術的な取り組みを社外にも発信すべく、メンバーが週替わりで技術ブログをリレー形式で執筆しています。前回は私、市古による「おすすめ Claude Code 設定・運用まとめ」でした。今回は Elasticsearch の話をします。 Elasticsearch は高度な検索と分析を実現する検索エンジンとして広く活用されています。 しかし、その仕組みをブラックボックスに感じているエンジニアは多いのではないでしょうか。 このブログでは Elasticsearch の全文検索に入門し、同義語検索のような応用的なユースケースの仕組みまで理解することを目指します。 なお、このブログは執筆時点（2025年6月17日）で最新である Elas
データベースのスキーマを変更するときは、スキーマの変更作業によってテーブルが長期間ロックされてしまわないように注意が必要です。 2019年にリリースされたPostgreSQL 12.0以降では、NOT NULLを安全に追加するためによりよいベストプラクティスができています。まだ知らない人もいるかもしれないので、ここで紹介します。 何が問題なのか?次のようなDDLコマンドを考えます。 -- posts.moderatedをNULL禁止にする ALTER TABLE posts ALTER COLUMN moderated SET NOT NULL;これはテーブルをACCESS EXCLUSIVEでロックしたままフルテーブルスキャンを行います。その間は他のトランザクションはこのテーブルに関する処理を進行できません。 テーブルが小さければこれで特に問題ありません。しかし、postsがそれなりに大
こんにちは、Wantedly People アプリの開発をしている竹野（Altech）です。今回は、Protocol Buffers についての記事になります。 Wantedly People では、2018年に Protocol Buffers （以下、Protobuf と呼ぶ）がとあるマイクロサービスに入って以降、何度か大規模に Protobuf を使った開発をしてきました。またその経験を通じて、Protobuf には単に「型がついて嬉しい」というだけではないパラダイム的な変化があることが分かってきました。 その知見を全社に展開するため、去年「Protobuf によるプロダクト開発速習会」という会を行いました。この記事の内容は、そこで話したことの前半「Protobuf を使うと開発がどう変わるのか？」になります。 なお、Protobuf にはバイナリフォーマットとしての役割とインターフ
こんにちは。ウォンテッドリーのEnablingチームでバックエンドエンジニアをしている小室(@nekorush14)です。現在、Enabling チームでは技術的な取り組みを社外にも発信すべく、メンバーが週替わりで技術ブログをリレー形式で執筆しています。前回は冨永さんによる「月次振り返りにかかる時間を大幅に短縮した方法」でした。今回はNotebookLMの話をします。 目次はじめに NotebookLMを活用して登壇資料を作成する 手持ちのドキュメントをソースにする Webページをソースにする Studioで理解を深める NotebookLMを活用した事後学習の機会を提供する スライドともにNotebookLMも共有する まとめ 参考 はじめにNotebookLMは、自身がアップロードしたドキュメント (Google Docs, PDF, Webページ等)をソースとして対話できる、Goog
目次はじめに なぜ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 のプロダクト開発を支える重要な概念のひとつである「Wantedly の UI デザインシステム」についての研修を、ソフトウェアエンジニアの @izumin5210 (筆者) とプロダクトデザイナーの @NishaMe で実施しました。 デザインの構造を正しく捉えることは、UI の実装を専門にしているかどうかを問わず、正しい実装 - 開発生産性が高く、ユーザにとっても使いやすい実装 - のための重要なポイントです。よってこの研修は「広義のフロントエンドエンジニア」、業務中に UI を実装することがある全てのエンジニアを対象としました。 Web フロントエンドエンジニアモバイルエンジニア専門ではないが
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の展開作業が不要になるほか、依存関係の
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: チームで見積もる 見積もりを成長の機会に変える おわりに 見積もりの定義まずは、このブログで扱う「見積もり」という言葉の定義を明確にしたいと思います。 開発における「見積もり」とは、プロジェクトを進める上で必要となる時間、コスト、そしてリソースを予測するプロセスです。これは、現時点で既にある情報や、潜在的なリスクを分析した結果に基づいて、将来の成果物や活動を定量的に予測することを指します。 この「見積もり」と混同されやすい言葉として、「ターゲット」と「コミットメント」があります。それぞれの言葉の定義もここで整理しておきましょう。 ターゲット: ビジネス要請や戦略的目標から設定される、理想的な目標日や目標値のこと
Wantedly の UI デザインシステムは「WantedlyのUIをデザインする上での共通の考え方とツール＆アセット」でありエンジニアとデザイナが効率よくコミュニケーションするための共通言語となる デザインシステムを (Web) Frontend に持ち込む際は、単なるコンポーネントカタログではなく、システムが定義するものと同じレベルの抽象を持つライブラリ・フレームワークとして実装することで、より有効性を発揮する Wantedly におけるデザインシステムは、「プロダクト・デバイスをまたいでも・誰がデザインしても体験やブランドとしての一貫性を保つ」「デザインの生産性を向上させ、デザイナ - エンジニア 間コミュニケーションを改善することで、ユーザに価値を届ける速度を向上させる」といった目的のために作られたものです。 より詳しくは、デザインシステムが加速させるプロダクト開発 / Desi
こんにちは。ウォンテッドリーの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はただの画面上の装飾のことではありません。対象となるユーザーが、どういった流れで画面内の情報を認知していくのか、ボタンを押したらどうなるのか、全体の体験をあらかじめ設計しておく必要があります。この分野は、「インタラクションデザイン」と呼ばれることもあります。 インタラクションデザイン 人
こんにちは。ウォンテッドリーでデータサイエンティストとして働いている市村（@chimuichimu1）です。この記事は Wantedly Advent Calendar 2024 の22日目の記事です。 私は普段業務で推薦システムの開発に携わっており、プロダクトを継続的かつ効率的に改善していくため、コードの内部品質が重要だと感じています。内部品質が保たれていないコードベースでは、機能追加や改善のスピードが落ちるだけでなく、バグの温床にもなります。 こうした内部品質を担保する１つの手段として、静的解析ツールの利用が考えられます。この記事では近年注目されている Python の静的解析ツールの Ruff について紹介したうえで、特にその高速性に焦点を当て、それがどう実現されているかについて深堀りしたいと思います。 Ruff とはRuff は Python 用の静的解析ツールであり、ソースコード
こんにちは、AI Enabling Squad の @fohte です。この記事は夏のアドベントカレンダー 23 日目の記事です。 ウォンテッドリーでは、開発時における生成 AI を活用してプロダクト開発の高速化を推し進めています。今回は、ウォンテッドリーのエンジニア全員が生成 AI を活用できるようになることを目指して社内で実施した「AI Enabling 会」について紹介します。この会は、エンジニア全員が生成 AI だけで 1 日開発するという取り組みです。 目次組織的な生成 AI 活用における課題 生成 AI だけで開発する AI Enabling 会 AI Enabling 会を実施して得られた結果と学び 最後に 余談 組織的な生成 AI 活用における課題ウォンテッドリーの開発組織では生成 AI 活用が個々に委ねられており、組織的な生産性向上に繋がっていない課題がありました。個人だ
Wantedlyでインターンをしている遠藤です。インターンのタスクとして「RustでProtocol BuffersからGraphQL BFFを自動生成する」という技術検証を行ったので、その知見を共有したいと思います。 今回の技術検証で作成したツールのソースコードはここにあります: EXPERIMENTAL] Generate GraphQL schema and gateway from Proto definitions. Licensed under either of Apache License, Version 2.0 or MIT license at your option. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in
はじめにこんにちは、Wantedly の 2021 年サマーインターンに参加した宮下と申します。今回のインターンでは三週間の間 DX (Developer Experience) チームに所属し、Wantedly のコードベースに Ruby の型チェッカーの導入を試みることをテーマにしていました。 インターンの前半では、様々な型チェッカーの性能を調べたり、それぞれの型チェッカーを実際に使ってみることで、開発効率を基準とした比較を行いました。インターンの後半では、現段階では一番実務に適しているだろうと判断した Sorbet に焦点を当て、Wantedly のいくつかのコードベースに実験的に Sorbet を導入した環境を作った型情報をつけていく作業をしていました。 本記事は、主にインターンの前半で調査した、型チェッカーの比較という部分に焦点を当て、文章の形にまとめたものになります。 Ruby
こんにちは。ウォンテッドリーでフロントエンド組織のリーダーをしている原 (@chloe463) です。 この記事では、数ヶ月前我々のプロダクトで起きていた不具合の原因と解決策について解説します。 大きく2つの問題が起きていましたが、一見すると無関係に見えた2つの不具合が、1つの重要な仕組みに起因するものでした。その発見が個人的にはアハ体験だったため、その発見の衝撃や喜びを共有したいと思います。 2025/07/08 追記 公開後に「Next.js には Version Skew を防ぐ機能がすでに含まれているため、他のところに原因があるのでは？」という指摘を頂きました。ありがとうございます。 自分の手元で新規の Next.js アプリケーションを立てて調べたところ、たしかにご指摘の通りでした。 したがって、多くの場合 Next.js を使ったアプリケーション開発において、Version S
1.チーム変革のステップと汎用的なアプローチ 1-1.初期の課題解決への取り組み 1-2.小さく始めて、確実に機能させる 1-3.「QAご意見箱」の設置と継続的な課題の吸い上げ 1-4.チームの成果を最大化する建設的なフィードバックを交わせる組織文化の醸成と「仕事の成果」への接続への取り組み 2.Wantedlyの価値観との接続 まとめ 1.チーム変革のステップと汎用的なアプローチ1-1.初期の課題解決への取り組み中途入社後は、まず既存メンバー2名と共にドメインのキャッチアップと業務プロセスの整備に注力しました。その後、テスト設計や実施に携わる中で、チームリードとしてDaily Standup（朝会）を通じ、タスク状況の把握・調整や、メンバーの困りごとの吸い上げと改善にも取り組みました。 初期段階では、費用対効果の高い課題を優先的に選び、迅速な実行と運用定着を重視しました。以下では、特に効
夏のアドベントカレンダー11日目は、ウォンテッドリーでアナリティクスエンジニアをしている木村（@akimu294231）より発信します！ 普段はBI Squadというチームの一員として、データ基盤の整備や各部門からの集計依頼対応に携わっています。日々ビジネスサイドやエンジニアと連携しながら、データを「使える形」に変換し、意思決定に活かしてもらうことが私たちの役割です。この記事では、アナリティクスエンジニアが直面する「曖昧な依頼」や「不確実なタスク」にどう向き合い、どのような考え方でタスクを設計・遂行しているかを紹介します。私自身が業務の中で感じていた課題や、実践しているアプローチも交えながら、チームとしてどのように成果に向き合っているかをお伝えできればと思います。 要求（Why）と要件（What）の整理集計や可視化を行う前に、まず依頼の背景を丁寧に確認しています。その背景とは、「なぜそのア
エンジニアリング界をリードする著名人が「いま話を聞きたい」開発者を直接指名し、日頃なかなか聞けない開発トピックについて語り尽くすオンライントークセッション「DevLounge.jp」。このイベントのオープニングを飾ったのは、Nature株式会社VPoEのSongmuこと松木雅幸氏と、ローンチャブル(Launchable）Co-CEOの川口耕介氏です。 Songmu氏は日本で、川口氏はアメリカ・カリフォルニアでそれぞれ活躍されています。セッションでは、お二人が感じるオープンソースソフトウェア(OSS)とSaaSの違いから、グローバル展開を目指す際の考えなどを語っていただきました。その一部をご紹介します。 Songmu(松木雅幸)Nature株式会社VPoE。大学で中国語と機械翻訳を学び、中国でIT分野での起業、語学学校でのシステム担当兼営業、印刷系SIerでの金融系Webシステムや物流システ
現代のビジネス環境におけるリーダーシップとマネジメントの重要性 リーダーシップとは マネジメントとは リーダーシップとマネジメントの違い リーダーシップとマネジメントの相互補完性 実務におけるリーダーシップとマネジメントの交差点 まとめ 現代のビジネス環境におけるリーダーシップとマネジメントの重要性VUCA（変動性・不確実性・複雑性・曖昧性）の時代と言われるように、今のビジネス環境は非常に複雑で変化に富んでいます。組織の中では新しい方向性が求められる一方で、確実な成果を出すための安定運営も同時に求められます。このような環境下で必要とされるのが、リーダーシップとマネジメントのバランスです。両者はしばしば混同されがちですが、実は役割も機能も異なります。 リーダーシップとはリーダーシップとは、組織やチームに方向性を示し、メンバーの内発的動機を引き出して共に進んでいく力のことです。その本質は、「な
こんにちは、ウォンテッドリー株式会社でインフラエンジニアをやっている @fohte です。 筆者はウォンテッドリーに join して 1 年が経過しようとしており、ようやくウォンテッドリーが採用しているアーキテクチャについて全貌が掴めてきました。そこで改めてウォンテッドリーの技術スタックを考え直してみると、ウォンテッドリーのバックエンド領域において利用している言語はなぜ採用されているのかが気になりました。今回はそれを読み解くべく、過去から現在までに利用されている言語の比率から、その背景と歴史を追っていきます。 ウォンテッドリーで採用している言語とアーキテクチャの歴史まずはじめに、ウォンテッドリーでは下図の技術およびアーキテクチャを選定しています。 (参考: 技術とアーキテクチャ - Wantedly Engineering Handbook) 本記事では、この図での "The System
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
