minodrivenのブックマーク (37)

  • ミノ駆動さんに「なぜ負債解消にDDD?」と聞いたら、ソフトウェア開発の本質に気づかされた

    ミノ駆動さんに「なぜ負債解消にDDD?」と聞いたら、ソフトウェア開発の質に気づかされた 2024年1月15日 株式会社スタメン ミノ駆動(仙塲大也) 電子機器メーカーや大手精密機器メーカー、クラウドワークスを経て、2021年4月にREADYFORに入社。アーキテクチャの変更容易性や機能性を促進する設計構造を目指し、リファクタリングやドメインモデリングを主軸としたシステム設計に従事する。現在は、組織改善のためのエンゲージメントプラットフォーム「TUNAG」を擁するスタメンに在籍。ITエンジニア大賞2023技術書部門大賞を受賞した『良いコード/悪いコードで学ぶ設計入門』著者としても知られる。 X(@MinoDriven) note Qiita 株式会社スタメン・テックブログでの執筆記事 ドメイン駆動設計(以下、DDD)に注目が集まりだしてしばらく経ちますが、いまだに捉えづらさを感じている人

    ミノ駆動さんに「なぜ負債解消にDDD?」と聞いたら、ソフトウェア開発の本質に気づかされた
  • ドメイン駆動設計は何を解決する手法なのか - stmn tech blog

    こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG(ツナグ)の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継

    ドメイン駆動設計は何を解決する手法なのか - stmn tech blog
    minodriven
    minodriven 2023/09/27
    記事を書きました。「DDDってなんだろう?どう役立つんだろう?」と感じている方にオススメです。
  • フロー効率を重視して「2年半でエンジニア2名→35名」の急拡大組織で高い生産性を実現した話

    https://dev-productivity-con.findy-code.io/ 株式会社SODAのセッション資料です。

    フロー効率を重視して「2年半でエンジニア2名→35名」の急拡大組織で高い生産性を実現した話
  • なぜ雑談が重要か - stmn tech blog

    これはなに? こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 コミュニケーションには会議体やテキストベースなど様々な手段があります。 その中で雑談がなぜ重要であるかについて、私の考えを記したものです。 大事な前提 〜目的と手段の関係〜 人々の活動には目的があります。そして目的を満たすための手段を追い求めています(ここでいう手段とはシステムであったり情報であったり、「目的の役に立つもの」と考えてください)。 目的と手段の関係性を次の図で表現します。目的と手段それぞれの円の重なりが大きいほど、目的に対して相応しい手段である、ということをここでは表します。 この図を使った例を出します。 今の時期、だんだん暑くなってきましたね。「暑さを解消したい」という目的に対して、「扇風機を点ける」「エアコンを点ける」「かき氷をべる」「南極に送り込む」

    なぜ雑談が重要か - stmn tech blog
  • スタメンの技術的負債解消戦略 - stmn tech blog

    1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG(ツナグ)は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。来プロダクトチームはユーザーにとっての質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が

    スタメンの技術的負債解消戦略 - stmn tech blog
  • コドモンさんのミノ駆動本輪読会に呼ばれました - READYFOR Tech Blog

    こんちはー、リファクタリング大好きなミノ駆動です。 私は初級〜中級向けのソフトウェア設計入門書『良いコード/悪いコードで学ぶ設計入門』(通称「ミノ駆動」)を2022年4月に出版しました。 拙著はありがたいことに、さまざまな勉強会グループや企業さんでの輪読会で用いられていると聞きます。 この記事は、株式会社コドモン のエンジニアさんからお呼びを受けて輪読会に参加したレポートです。 召喚の儀(ことのはじまり) 「輪読会に召喚したい」的な雰囲気をTwitterで感知したので、私は次のようなツイートをしました。 僕は常にエゴサしているので、 #ミノ駆動 の輪読会などで僕を召喚したい場合は、僕の名でツイートしていただけると、予定等にもよりますが召喚に応じます。 (※DMは相互フォロワー以外解放していないため) https://t.co/ljv8KnxcI6— ミノ駆動 (@MinoDriven)

    コドモンさんのミノ駆動本輪読会に呼ばれました - READYFOR Tech Blog
  • 組織全体の設計推進には必ずチームビルディング! - READYFOR Tech Blog

    こんちはー、リファクタリング大好きな ミノ駆動 です。 書籍『良いコード/悪いコードで学ぶ設計入門』 の著者です。 READYFORでアプリケーションアーキテクトとして務めています。 この記事は、8/20(土)に開催された オープンセミナー岡山2022 の登壇レポートと、そこで発表した 設計とチームビルディングの関係 について、弊社での活動を解説するものです。 登壇発表の概要 この登壇では、 私が昔勤めていた会社での失敗経験と反省 が、現職READYFORでの設計業務に活かされている旨を発表しました。 speakerdeck.com www.youtube.com 発表にあるように、チームの合意やリソース戦略が不十分なまま大規模な設計変更を無理に進めると、反発や軋轢が生まれます。 そして組織全体での設計改善が困難になります。 そうした失敗経験を反省し、その後様々な技術書での学びから、課題と

    組織全体の設計推進には必ずチームビルディング! - READYFOR Tech Blog
  • 不幸を再生産しないための設計に対する向き合い方

    「オープンセミナー岡山2022」のイベント登壇で用いた資料です。 https://okayama.open-seminar.org/

    不幸を再生産しないための設計に対する向き合い方
  • 「混ぜるな危険」を推進する設計

    2022/06/30開催の、こちらのオンラインイベントで用いた登壇資料です。 BPStudy#178〜成長し続け、変更を楽に安全にできるソフトウェア設計とは https://bpstudy.connpass.com/event/250694/

    「混ぜるな危険」を推進する設計
  • 悪いコードをやっつけよう!『良いコード/悪いコードで学ぶ設計入門』を読んで - 虎の穴開発室ブログ

    こんにちは。虎の穴ラボのH.Kです。 5月の大型連休で社内の技術書購入を支援する制度を利用して購入した『良いコード/悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方』を読みました。 『良いコード/悪いコードで学ぶ設計入門』書影 とても良いでしたので、書の横断的な概要と、その中で良かったところや気になったところをご紹介していきます。 どんなか 基情報 私が感じた書の立ち位置 前提 設計とコーディングは不可分である 「悪いコード」=>「良いコード」の構成 サンプルコードはJava おすすめする読者層 著者について 構成について 1〜2章:チュートリアルステージ 3〜12章:編 13〜17章:やりこみ世界 良かったところ 平易な表現 サンプルコードが豊富 気になったところ 6章:Switch文の重複(Switch文からMapへの書き換え) まとめ P.S. どんな

    悪いコードをやっつけよう!『良いコード/悪いコードで学ぶ設計入門』を読んで - 虎の穴開発室ブログ
  • 良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方

    このの概要 「ITエンジニア大賞2023技術書部門で大賞受賞! 書は,より成長させやすいコードの書き方と設計を学ぶ入門書です。 システム開発では,ソフトウェアの変更が難しくなる事態が頻発します。コードの可読性が低く調査に時間がかかる,コードの影響範囲が不明で変更すると動かなくなる,新機能を追加したいがどこに実装すればいいかわからない……。 変更しづらいコードは,成長できないコードです。ビジネスの進化への追随や,機能の改善が難しくなります。 成長できないコードの問題を,設計で解決します。 こんな方におすすめ コードの設計スキルに興味がある人 日々,悪いコードと向き合っていて改善したい人 より良いコードを書きたい人 1 悪しき構造の弊害を知覚する 1.1 意味不明な命名 1.2 理解を困難にする条件分岐のネスト 1.3 さまざまな悪魔を招きやすいデータクラス 1.4 悪魔退治の基 2

    良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方
  • DDDの腐敗防止層を用いた変更容易性向上 - READYFOR Tech Blog

    こんにちは、リファクタリング大好きなミノ駆動です。 リファクタリングを主任務とするアプリケーションアーキテクトとして、弊社READYFORのエンジニアリングを推進しています。 ドメイン駆動設計に登場する 腐敗防止層 を用いたリファクタリングで、システムの変更容易性を向上したお話を解説します。 記事の概要 イビツな構造を隔離する腐敗防止層を用いて技術的負債を解消 ふたつの橋作戦でリファクタリングの安全性を向上 設計技術書 『良いコード/悪いコードで学ぶ設計入門』 出版のお知らせ 背景 弊社READYFORのシステムは、モノリシックなRuby on Railsのサービスとして実装されています。 システムが解決したいドメイン(業務活動)にはさまざまなセグメントがあり、その中に審査オペレーションがあります。 審査オペレーションとは、クラウドファンディング実行者さんが申し込みを提出してからプロジェ

    DDDの腐敗防止層を用いた変更容易性向上 - READYFOR Tech Blog
  • 『良いコード/悪いコードで学ぶ設計入門 』を出版します|ミノ駆動

    こんにちは、リファクタリングが大好きなミノ駆動です。 これは、私が執筆した『良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』について紹介する記事です。 2022年4月30日発売です(ほぼ同日に電子書籍版も出ます)。 AmazonなどECサイトで、すでに多くの予約が入っており、ヨドバシ.comでは一時期予約終了になったほどです。おかげさまで初版部数が2倍になりました。 ■どんな?皆さんはプログラミングでバグを埋め込みたいですか?ロジック修正が上手くいかず、ヒィヒィ言いながら長時間残業したいですか?イヤに決まってますよね。ところが現実には、 何度もバグを埋め込んでしまう ロジックを読み解くのに時間がかかる やっとロジック修正しても、全然違う箇所がバグ化してしまう ……ほとんど誰もが体験しているのではないでしょうか。 でも、こうした状況をなんとかしたいと思って

    『良いコード/悪いコードで学ぶ設計入門 』を出版します|ミノ駆動
  • 巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例

    こちらのイベントで発表した資料です。 『ドメイン駆動設計を導入するためにやったこと』 https://modeling-how-to-learn.connpass.com/event/229811/

    巨大レガシーシステムの戦略評価とリファクタリングにおけるDDDの活用事例
  • 技術的負債は開発者体験を悪化させる - mtx2s’s blog

    ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad

    技術的負債は開発者体験を悪化させる - mtx2s’s blog
  • エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita

    スクワッド体制における留意点として、「Spotifyは "Spotifyモデル "を使っていない [3]」で以下のように述べられているように、単に方法論を真似るのではく、自分の組織と向き合い、学習して、進化し続けることが大切であると思います。READYFORにおいても日々、組織体制について議論し、改善を進めています。 ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。 あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。 1-2. READYFORのスクワッド体制 READYFORの場合、どのようなスクワッド体制を敷いているか? ひと

    エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita
  • リファクタリング自爆奥義集 - Qiita

    こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、13日目の記事です。 これはなに? コードが複雑化し、技術的負債が蓄積していくと、コードの変更が難しくなり、開発生産性が低下していきます。技術的負債の解消にはリファクタリングが必要です。 しかし、リファクタリングの実施には数々の罠やハードルがあります。 下手すると逆に負債を作り込んでしまうといった、自爆技をやりかねません。 この記事は、リファクタリングのアンチパターンと、その対策をまとめたものです。 この記事のゴール リファクタリングには様々なアンチパターンがあることを知る。 アンチパターンにハマらないためのアプローチを知る。 リファクタリングの効果を高めるにあたり、何のために実施するのか意義を理解する。 前提知識 なぜ自爆技となるのか、自爆だと理解するのに必要な前提知識を挙げ

    リファクタリング自爆奥義集 - Qiita
  • 設計を歪める認知バイアス - Qiita

    こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに? ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的とします。 この記事のゴール 人間の判断を歪めてしまう心理効果「認知バイアス」の存在を知ること。 ソフトウェア設計も、認知バイアスの悪影響を受けてしまうこと。 認知バイアスに振り回されない設計アプローチを身につけること。 認知バイアスとは 先入観や思い込み、偏

    設計を歪める認知バイアス - Qiita
  • 伝えたい人に届ける技術記事の書き方 - Qiita

    こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、初日の記事です。 なにこれ? 苦労して執筆した技術記事は、伝えたい人にしっかり伝えたいですよね。 また、最後まで読んでもらいたいですよね。 一方で、構成などに課題があって、伝えたい人になかなか伝わらないことがあります。 この記事は、伝わる記事の書き方について、私の個人的なノウハウを書き記したものです。 これからアドベントカレンダーの記事を執筆される皆さんにとって、少しでもお役に立てられれば幸いです。 この記事のゴール 以下の理解を得ることをゴールとします。 以下2つの要件を踏まえた記事構成を心がけること。 構成要件①:技術を紹介する上で最低限説明の必要な内容を網羅すること。 特に課題をしっかり伝えること。 構成要件②:読み手が段階的に理解しやすい順番になっていること。 告知の仕

    伝えたい人に届ける技術記事の書き方 - Qiita
  • Kaigi on Rails 2021 オンラインブースで工夫したら結構集客できた話 - READYFOR Tech Blog

    こんにちは、リファクタリング大好きなミノ駆動です。 2021年10月22日、23日に開催されたKaigi on Rails 2021にて、弊社READYFORはGoldスポンサーとしてスポンサーブースに参画しました。 オンラインブースで来場者を呼び集めるために各社試行錯誤している中、弊社のブースにかなり来場者が集まったので、どのような工夫をしたのか記事に記していきます。 会場はオンライン コロナ感染の懸念から、Kaigi on Rails 2021はオンライン開催となりました。 企業ブースもオンライン会場サービスreBakoを用いたものになりました。 reBakoのオンラインイベント会場 会場にログインすると、参加者がアイコン表示されます。 reBakoは、アイコンを動かしてバーチャル会場を見て回ったり、席に着座すると同席者とビデオチャットできたり、近くに行くと聞き耳を立てることができま

    Kaigi on Rails 2021 オンラインブースで工夫したら結構集客できた話 - READYFOR Tech Blog