はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化

50代のおっさんエンジニアになってたので、雑に40代にやっておいてよかったことなどを振り返ってみた。思い出補正があるかもしれないので参考にしようとする人は注意。 運動習慣をつけた 資格学習を継続した 読書習慣を維持した 仕事と関係ない勉強を始めた IT勉強会コミュニティへの参加をやめた ブログを書き続けた 運動習慣をつけた 40歳になったころに人間ドックでメタボ判定を1度受けたことをきっかけに、運動をするようになった。現在も続けているので習慣化に成功しており、おおむね健康を維持できている。 ゴルフを含めてスポーツの趣味はない（今もない）。ゴルフは誘われるけど、興味がない（週末に会社の人と遊ぶような思考を持ち合わせていない） ダイエットするなら食事改善というのは理解しているけど難しそうなので、筋肉つけて代謝を高める方向性を選択 コロナ禍以前は会社帰りに福利厚生で安く使えるジムのプールで泳いで

はじめに 背景：クレジットカード不正検知システムとは 3日でDesign Doc 2本、ADR 5本を執筆 3週間で開発し、本番環境にリリース LLM活用による効率化のポイント 目的・要件の整理 要件を満たす技術的オプションの洗い出し・技術調査 PoC実装 ドキュメントの執筆・技術選定 本実装 学び おわりに はじめに 新規プロダクトやプロジェクトの立ち上げにおいて、どれだけ意思決定を明確化し、設計を固めることができるかは、後々の開発効率や品質に大きな影響を与えます。一方で、最初が肝心だからといって調査や設計に何か月も費やす余裕は、多くの企業にはありません。できる限り早く設計を確立し、実装を開始して価値を生み出すことが求められます。 LayerXのバクラク事業では、法人向けのクレジットカード「バクラクビジネスカード」を提供しています。サービス開始時から不正利用を検知する仕組みを導入していま

2024年11月、株式会社ログラスは、創業時から同社のエンジニア組織をリードしてきた坂本 龍太さんがCTOを退任すると発表。代わって、2022年に入社した伊藤 博志さんがCTOを引き継ぐこととなりました。 このCTO交代劇について、坂本さんは「胸を張ってCTOのバトンを渡せることを誇りに思います」と語っています。ログラスといえば、エンジニア組織の強さに定評のあるスタートアップであり、同氏はその組織作りに貢献。その一方で、2019年の創業当初から「いつか自分はCTOとして適任ではなくなる」という思いを持ち、次期CTOへの引き継ぎも見据えた組織づくりをしてきました。 新たなCTOを据えて、組織が新たなスタートを切ったこの時期に、CTOとしてのこれまでと、交代する際の苦労、これからの取り組みなどを語ってもらいました。 創業時のCTOとして作り上げてきたエンジニア組織 ――「『創業期のCTOとして

いきなりのお知らせですが, 私shinyorkeは年内で現職（某大手外資系ITコンサル企業*1）を退職します（本日12/13が最終出社でした）&来年から再びプロダクトを取り扱うベンチャー企業*2でエンジニアとして働くことになりました（まだ予定ですが）&その転職活動から爆誕したコンテンツがこの記事です. 現職の皆様, 本当にお世話になりました&次の働き先はもうすぐ決まる見込みです*3. 退職と転職の話は後日別のブログこちらのブログで語ることにしますが, 約3年ぶりの転職活動（40代になってから二回目）は本当に苦労しました. エンジニアの転職プロセスは色々ありますが, 通常の面接・選考(過去経歴, いくつかの質問の中で能力・カルチャーがフィットするか) 技術選考（プログラミングテスト, 応用的な技術課題の作成・提出, レビュー形式の技術面談など） 大雑把にこの2つに分かれるかと思います*4が,

Bill One Entry*1の秋山です。 本題へ入る前にお知らせです。12/23、TypeScript を活用した型安全なチーム開発をテーマにイベントを開催します。弊社社員のうち、TypeScript を日々の開発で活用しているメンバーが登壇します。ぜひお気軽にご参加ください。 sansan.connpass.com はじめに モジュラーモノリスとは 保守性が低いとビジネスに悪影響を与える 技術的負債と開発生産性 コード品質とビジネス影響 モジュール分割の方針 方針１：モジュールにDBテーブルを専有させる 補遺：モジュラーモノリスとNoSQL 方針２：モジュール内をレイヤードアーキテクチャとして構成する 方針３：ESLint ルールによって実現する TypeScript 開発にモジュラーモノリスを持ち込む ステップ１：単一のエイリアスを設定する ステップ２：ESLint ルールを設定す

自分は2020年に初めてマネージャーという役割になってしばらくの間、メンバーに寄り添う意識が強くてあまり職責を果たせていなかったと思う。「今思うと」という話で当時はそう思っていなかったのが黒歴史と言える。過去の自分のことを思い出しながら、この「メンバー思い"風"マネージャー」だった自分に向けたフィードバックを雑に書いてみる。 お前は"メンバーを守ること"が目的になっていて、経営や他部署との対立構造を自ら作ってしまっている。 たとえば、ビジネス上満たしたいリリースターゲットを共有された時、メンバーの負荷を勝手に想像して初手で噛みついてしまっているな。マネージャーとしてきちんと"断る"ことも仕事といった感じで、どこか使命感に近い感覚を持っていないか。お前がやっていることは、結果として経営との接続どころかむしろ最初のブロッカーのような立ち振る舞いにしかなっていない。 人事制度の変更アナウンスに対

スキルも経験も積み重ねてきた人が抱きがちな悩みとして、「自分が意見を出すと毎回大きな反論なく通ってしまって不安になる」というのがある。 いわゆるリードができるレベルになると、他のメンバーより視野を広く持って色々なことに考慮した意見を出せるようになる。しかし実際には明確な答えは持っていなくて自信があるわけでもないこともある。 それなのに自分が言ったことがそのまま通ってしまう。発言すると、「たしかに」「そうですね」「いいと思います」みたいな雰囲気になって採用されていくのである。新しいサービスの設計方針の議論、コードレビューでのやりとり、チーム目標を決めるミーティング、さまざまなところでこういうことが起きる。 「本当にこれで大丈夫なのか」という不安も感じるし、「もしかしたら自分が発言することで他の人の意見をふさいでしまったり萎縮させてしまったりしてるんじゃないか」と心配になってくる。人によっては

これはなに？ こんにちは、DMM.comのミノ駆動です。 プラットフォーム開発本部 Developer Productivity Group 横断チームにて、 プラットフォームの設計品質向上に取り組んでいます。 さて、ネット上ではソフトウェア開発における「良いコードとは何か」をめぐって、 いろんな意見が交錯したり、 ときには激論を呼んだりします。 収拾がつかないこともしばしばです。 この記事は、良いコードを考えるうえでの要素を整理し、 建設的な議論を助けることを目的とします。 これはなに？ この記事の理解目標 良いコードをめぐる議論 議論1: 何をもって良いコードなのか 議論2: 良いコードはどうやったら書けるのか 議論3: 「綺麗なコード（良いコード） vs 動くコード」問題 議論改善のために提案します 提案1: ソフトウェア品質特性の観点でコードの良し悪しを判断しよう 提案2: 原理原

最近雑じゃなくなってきた気がするのでより雑めに垂れ流すことにする。 自分が苦手だと思い込んでいたことが、苦手とかそういう属性次元の話じゃなくて事前の準備が足りないだけということがある。 たとえば、自分は「メールが苦手でつい見逃しちゃうんですよね」と言っていたことがある。Slackだとすぐ反応できるのにメールだと億劫になってしまうのだ。 少し時間を取ってラベルを整理したりSlackに連携して流すようにしたりすることで解決した。苦手とかではなくて、単に工夫のひと手間をサボっていただけだった。 人前で話すのも苦手と言って避けていたことがある。 話すのがうまいように見える人にどうしてるか聞いて観察してみると、自分より入念に調べてフィードバックをもらって10倍リハーサルをしていた。苦手とかではなくて、単に補うための準備が足りていないだけだった。 懇親会でボッチになるのが苦手と言っていたことがある。話

こんにちは。Google CloudでオブザーバビリティやSREを担当していたエンジニアです。明日でこう名乗るのは最後になります。明日、2024年10月31日付でGoogleを退職します。 pic.twitter.com/dS3WOVCQBj— Yoshi Yamaguchi (@ymotongpoo) 2024年10月30日 かしこまった挨拶 Googleに入社してから10年目までの話は次の記事で一旦まとめているので、改めて振り返ることはしません。 ymotongpoo.hatenablog.com 上の記事を書いたのは新型コロナ禍真っ只中で、カンファレンスなどもみなオンラインばかりで、人とのつながりがなかなか難しくなったころでした。その後、ワクチン開発や発症後の処置方法の確立、新型コロナウイルスの5類感染症への移行などがあり、オンラインからオフラインへの移行が再び起こりました。Goog

株式会社MonotaRO CTO 普川 泰如 慶應義塾大学環境情報学部卒業。SIer企業を経て2009年にオイシックス・ラ・大地に入社し、2016年にシステム副本部長に就任。2019年にモノタロウに参画。2021年1月にECシステムエンジニアリング部門長、2022年4月に執行役CTO/VPoEに就任。 X 多くの企業で、10年以上前に開発されたシステムが、事業拡大に伴い続々と限界を迎え、リアーキテクチャに取り組み始めています。 間接資材のネット販売ビジネスを展開するモノタロウ社もその1つです。約20年前の創業期から内製で開発してきたモノリシックなシステムは、事業成長とともに度重なる機能追加を経て、2015年頃にはコードの変更すら容易にできない状態に。一度はパッケージシステムの導入も試みますが、2022年頃から、再度内製開発による抜本的なリアーキテクチャに取り組んでいます。 今回のリアーキテ

来週で40歳にあるので30代の振り返りとしてこれを書く。 そんな30代を全力で走ってきた中で、これは30代でやってよかったな。 もっと早くやってもよかったな。というようなことを書く。 最初に行っとくと一般的にやったほうが良いということは基本的にやったほうがいい。 そういうのも含めて実際にやってみた経験も書く。 習慣を作れるようになる これは本当にやったほうがいい。 身につけるのであれば、早ければ早いほどほどいい。 もう少し具体的に話すと自分がやりたいことを実現していくためには習慣にできるとよい。 なんでも習慣にできると強くて、自分はどうやったら習慣になるんだろう？ってところを理解して上手くハックして習慣化していけると自分のやりたいことがどんどん実現できるようになる。 運動習慣 これも早ければ早いほど良いと思うが、朝か夜の散歩くらいからでもよいからやったほういい。 コロナ禍をきっかけに自分は

こんにちは、トレタ VPoEの北川です。 今回は弊社でフロントエンドアプリケーションを新しく構築する際の開発環境として、何のライブラリを入れるかという開発環境初期セットを紹介しようと思います。 Web Framework / CSS Framework / Tesing Framework / Linter / Formatter、それぞれ定番で使うデファクトが大体ありましたが、近年では新しいライブラリも登場したので、2024年現在・最新版を、今回は直近で作られた実際のリポジトリを例にご紹介します。 今回紹介するリポジトリのアプリケーションはtoB向けの管理画面のアプリケーションで、特質した部分も特にない一般的なWebアプリケーションです。 それでは早速、package.jsonの内容はを見ていきましょう。 "dependencies": { "next": "14.2.13", "rea

実質的に何かの役割を担っている"自称"の状態と、組織図上にも表されるような自他ともに認める明確な責務を持つ状態とでは、あまり変化がないようで全然違うという話を雑に書いておきたい。 たとえば「ほぼマネージャーみたいなことをしてます」という状態と「マネージャーとしてやってます」という状態は、マインドも動き方もプレッシャーも実は全然違う。 同じように、「事業責任者みたいなもんですね」という状態から実際に事業責任者というタイトルがつくと、想像よりも周囲の期待や自分のスタンスの変化が大きい。 タイトルが大事というわけではないが、名付けがされると自他ともにそのタイトルに対する期待イメージがより明確になる。それに伴って自分の心持ちや考え方、行動が変わるのはもちろん、周囲の反応も変わる。たとえば実質技術責任者みたいな役割を担っていた人にCTOという名付けがされると、急に「CTOとしてどう考えているのか」と

「TypeScriptではじめる型システム」という記事をn月刊ラムダノートに寄稿しました。 新刊を発売しました "『n月刊ラムダノート』Vol.4 No.3（2024）発行のお知らせ https://t.co/PGppk1aRRA— lambdanote (@lambdanote) 2024年10月4日 どんな内容？ TypeScriptの極小サブセットに対する型検査器を書き、それを通して型システムを体感してみよう、という内容です。 詳しく言うと、boolean型とnumber型と関数型しかないTypeScriptサブセット言語がターゲットです。 型検査器の実装言語にもTypeScript（処理系はDeno）を使います。 TypeScriptづくしの一品です。 わかる人向けに言うと、「型システム入門」という本（通称TAPL）の単純型付きラムダ計算に相当する内容をTypeScriptで説明し

自分が動かせない前提条件と思い込んでいたことを、同僚氏の助言で実はコントロールできることに気づいて前に進められたということが何度もあった。 前提条件や制約だと決めつけてしまって問題を解決できないと思い込んでることあるよなという話を雑に書いておきたい。 特に陥りがちなのは、期限や人員、予算、規約、法律あたりだろうか。 たとえば「この日までにできないと失注と言われている」みたいな話も、先方と話すと代替案の提示で調整可能なこともある。 「今期の予算が取れない」といった話も、実は今後1年のROIを正しく理解してもらえれば変更しうることもある。 所属開発チームの中ではなかなか動かすのが難しい改修も、社全体での位置づけを説明して短期のプロジェクトチームを作ればできるかもしれない。 これらはただの例であって、それくらい考えるのは当たり前だろと思う人もいるかもしれないし、ただの社内のプロセスの問題ではと感

技術的負債をうまくマネジメントすることは重要です。なぜなら、持続可能な長期的な利益の確保こそが競争戦略における目標であり、技術的負債への対応力はその目標に近づくための重要な組織能力だからです。EMとして組織の成果の最大化を目指す上で避けては通れない課題です。また技術的負債への対応は、単に技術的な課題ではなくそれらを包含するプロダクトの課題です。どうやって解決するかだけでなく、なぜ、いつ、どのくらいやるべきかを、事業責任者などのステークホルダーと合意して初めて対応を進めることができます。こうした課題に対しては、多職種をつなぐメンタルモデルの構築、方向付け、ファシリテーションといったソフトスキルが必要になってきます。EMはエンジニアリングの視点とそうしたスキルを併せ持つことが期待される存在で、技術的負債への対応においても重要な役割を担うと考えています。本記事では、技術的負債をマネジメントする方

ありがたいことに年末にメルカリの小泉さんとランチをご一緒させてもらいました。 CTO(@yutadayo)が作成した過去の失敗スライドに、リプライをいただいのがきっかけだったのですが、長らく競合事業(現ラクマ)をやっていたこともあり、きちんとお話ししたことがなく、とても学びが深かったので、ご本人に許可をいただいて、メモした内容と学びをシェアさせていただきます。 なんでメルカリに？噂ではフリルにも入社してもらえる可能性もあったとか？2007年よりミクシィに入社し、2012年の退任までCFOを務めていた その後、1年以上は他の会社の社外取締役をしたりフリーランスをしていた フリルは2012年夏リリース、メルカリは2013年春リリース 小泉さんは2013年冬にメルカリ入社 フリルのことは入社前から知っていて、2012年冬のIVSでコミュニティファクトリーの松本さんに「フリル知ってる？紹介してよ」

日本のスタートアップや VC は、本気でホームランを狙っているのか？ 大半のプレイヤーがスモール IPO で満足しているのではないだろうか？ 日本のスタートアップ界隈は、皆、「１塁打」を狙いすぎだ。 起業家のビジョンも小さいし、投資家のレベルも低い。その上で、いやしくてつまらない「界隈意識」と、くだらない「同調圧力」によって、「仲良しこよし」で小さくまとまっている。その生ぬるさと閉塞感には、正直言って辟易している。 本来、スタートアップとは「100社に投資して、１社が大成功し、残り99社の失敗を補って余りあるほどのリターンを叩き出す」というゲームである。「ホームランを狙う」というのが、このゲームを支えるグランドルールだ。北米はもちろん、ヨーロッパ、南米、アジア圏においても「ホームランを狙う」ことこそがゲームを回し続けている。 唯一の例外が日本だ。ホームランを狙わずに、「仲良しこよし」で「１