背景 開発チームが抱えるよくある課題として システムが変化する一方でドキュメントは更新されず腐る メンバーの流入出によって口伝でかろうじて継承された知見も失われる 検索性が良くないと過去のドキュメントが気づかれず、同じような内容のドキュメントが新規量産される 後から参加したメンバーはどちらが正のドキュメントか分からず混乱する といったことが良くあります。 解決方法としては以下のように、GitHub＆ルールベースで管理するといった例があります。 future-architect.github.io また組織・システムが大きくなってくると認知負荷を低減するためにドメインで区切るような形でチームの分割が始まりますが、 異なるチームによってシステムが管理され、システムの依存関係を全て知っている人がいなくなる CxOレイヤが大規模イベント前に現状を把握したいときに都度時間がかかってしまう チームごと

ソフトウェアと経営マガジン第75回です。組織改革に取り組むにはまず正しい現状認識から、ということで今回と次回は課題のヒアリングと整理についての考え方を書いていこうと思います。前編では、まずヒアリングを重ねようということで、どのようにして課題をかき集めるか、それによって生み出すべきアウトプットとはなにか書いていこうと思います。 記事に対する疑問や感想、意見などXでのポストや記事へのコメントをいただければ、今後のコンテンツの改善に役立てさせていただきます、よろしくおねがいします。 前回の記事はこちら。 課題ヒアリングと分析改革の第一歩は自分自身の組織を正しく知ることだ。自身の組織を知る上では①課題②KPI構造③人を私は重視している。その上でまず知るべきは自身の組織の課題構造である。課題は点ではなく線、構造的なものであるという前提に立って、まずはこれらを収集・整理してみよう。 課題ヒアリングで求

私は今までのキャリアの中で、CTOのいない会社に3回入社してきました。うち2社はEMとして入社してVPoEになりました。そこでの反省はもちろんありますが、成果を出すことができました。そして1社は、なんと3週間で退職しました…。 OPENLOGI Advent Calendar 2023で今年は何を書くか考える中で、私のようにCTOがいない会社に何度も入社した経験があるEMはそうそういないのではないかと思いました。将来CTOのいない会社に入社するCTO・VPoE・EMといったマネジメント層の方に、私の経験から学んだことを参考にしていただければと思います。 ※OPENLOGIには現在CTOは在籍しております。 CTOのいない会社とは CTOのいない会社とは、エンジニア組織のトップであるCTO・VPoE・開発部長といった立場の人がいない、もしくは、トップはいるけれど何らかの理由（トップがエンジニ

この記事は 食べログアドベントカレンダー2023 の23日目の記事です🎅🎄 こんにちは。食べログシステム本部 技術部 仕入チームの@shohei-yです。 今回は、新規事業の「食べログ仕入」プロダクト開発において所謂「設計書」を書かない設計に挑戦して開発効率を向上させた話を書きます。 （結局「書くの？書かないの？どっちなんだい！」と感じた人は、ぜひ読み進めてください。） 所属している仕入チームについてはこちらの記事をご覧ください。 目次 なぜ設計書を書かない設計に挑戦したのか 設計書を書かないチーム 設計書を書かないことによる問題 1. チーム協力の課題 2. ソースコードの複雑化 3. チーム変動に関わる問題 設計工程導入のきっかけ 設計書を書かない挑戦の背景 設計書を書かない設計 フロントエンド・バックエンドのインターフェースの明確化 ソースコードのスリム化対策 設計のレビュー方法

こんなつぶやきをしたので、「モジュラーモノリス」について考える。特にモジュール性について考えてみる。 以下の主張は、実際のプロジェクト/プロダクトにとって最適かどうかは、具体的なビジネス要件、チームのスキルセット、運用上の制約など、多くの要因に依存する。アーキテクチャは常にトレードオフがあり、一つの解決策が全てのシナリオに適用できるわけではないので、その点を考慮して読んでほしい。 マイクロサービスではなくモジュラーモノリスを選択した場合には、しばしば以下の利点が強調される。 ネットワーク通信: モジュラーモノリスは、マイクロサービスと異なり、ネットワークを介した通信が発生しないため、ネットワーク遅延や断絶、通信エラーなどの問題が生じにくくなる データ整合性: 分散システムでは、データの整合性を保つために複雑なトランザクション管理やデータ同期が必要になるが、モジュラーモノリスでは同じデータベ

松尾研究室が2023年9~10月に東京大学サマースクールで開催した LLM 大規模言語モデル講座のコンテンツを無償公開しています。 本講座は約2,000名の受講者が参加し、全7回の講義を実施しました。 最終課題としてGPUを使ったコンペティションでは約800名が参加し熱戦を繰り広げました。 現在、講義のスライドのみ公開しております。 ダウンロードは利用規約を確認の上、下記からダウンロードをお願いいたします。 最終更新: 2024年2月10日 問題・フィードバック報告フォームはこちら 第1回：Overview of Language Models LLMの概要、今後の各回の講義の概要、および日本のLLM開発状況について 第2回：Prompting and Augmented Language Model 事前学習済みLLMを追加学習せずに活用する技術（プロンプティング、⽂脈内学習、Augme

こちらの記事はカケハシ Advent Calendar 2023 Part2の24日目の記事になります。 adventar.org はじめに 反復的な開発は、変更容易性の高いソフトウェアが不可欠です。ソフトウェア開発の経験がある方なら、デリバリ後の洞察や市場環境の変化から、新しい機能の追加やアーキテクチャの進化の必要性に直面したことが一度はあるでしょう。 私自身、要求分析手法やSOLID原則等の技法を取り入れ、変更容易性に対応する多くのプロジェクトに参加しました。しかし、どれだけ優れた手法や技法を持っていても、変更が難しい要求が出てくることは避けられません。その際、「過去の出来事」を正確に記録していれば、後から見返して問題解決が容易だったと感じることがよくあります。 ドメイン駆動設計（DDD）では、「過去に起こった出来事」を表現するドメインモデルを「ドメインイベント」と呼びます。変更容易性

はじめにこれはEngineering Manager Advent Calendar 2023 25日目の記事です。 毎日良質な記事がアップされて、完全に俺得な一ヶ月でした。ご参加いただいたみなさんありがとうございます。 最終日の記事では、EM Advent Calendarを俯瞰しながら執筆している私のEMキャリアをふりかえり、結局のところEMとは何なのか、ということを考えてみます。 Advent CalendarにおけるEMの多様性と共通点LLM時代におけるEMという、実に2023年的な切り口から始まったこのAdvent Calendarには、実に多様なコンテンツが集まってきました。 新任EMの方の奮闘の記録、手を動かしてなんぼという考え方、スクラムとの接近、プロジェクトマネジメント的アプローチ、オブザーバビリティのEM業への援用、キャリア論・・・。 共通しているのは「マネジメント対象

最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから

※あと、鵜呑みにしないでください。他人の知識は情報なので実践・検証を踏まえないと自分の知識にならないので、今回は情報提供の一環ということでお願いします 時間とリソースは有限なので、選択と集中をどうするのかというテーマ。前回の記事もサブドメイン戦略の観点だったが、この記事はコアドメイン戦略に的を絞っている。 Nick Tuneさんの記事には、コアドメイン戦略のパターンが示されている。数が多いので重要そうなものだけをピックアップして紹介＆考察してみる。 Context Distillation(コンテキストの蒸留)According to this definition, a Core Domain is an area of the domain with the opportunity for high business differentiation. This represents a

DDD関連の記事を紹介してみたい。 今回は、Vladikkさんの2018年の記事。タイトルは「DDDの基本を再考する」だが、内容としては「サブドメインの分類方法」について述べられている。 今回はこの記事を要約してみよう。（日本語での要約の許可をVladikkさんからもらっています） ※あと、鵜呑みにしないでください。他人の知識は情報なので実践・検証を踏まえないと自分の知識にならないので、今回は情報提供の一環ということでお願いします 前段に書かれている内容は基本的なものだ。 ドメインが事業領域を意味する サブドメインはさらに細分化された事業領域 サブドメインには種類がある。 汎用サブドメイン 一般的な問題を解決することで、コアドメインと支援サブドメインをサポートする 支援サブドメイン コアドメインをサポートするためのサブドメイン コアドメイン 重要なビジネス価値を提供する。競争優位性を持つか

2023/12/20(水) https://findy.connpass.com/event/303813/

この記事は 株式会社ログラス Productチーム Advent Calendar 2023 18日目の記事です。 はじめに ログラスの龍島(@hryushm)です。 ソフトウェア開発において、「シフトレフト」すなわち開発の早い段階でテスト計画を立て、実施していくことが全体的なコスト削減や価値提供の早期化につながるとよく言われています。 この記事では、シフトレフトによってもたらされる効果をログラスでの実例を用いて紹介した上で、なぜ効果が出るのか？を「抽象度」というキーワードから紐解いてみようと思います。 本記事ではスクラム開発においてPBIを完了させる中でシフトレフトしていくことを念頭に書いていきますが、ソフトウェア開発の任意のタイミングにおいて適用できる概念だと考えています。 テスト設計を実装前にやることの有用性 まずシフトレフトによって何が起こるのか？を考えます。PBIに書かれた受け入

こちらの記事は カケハシ Advent Calendar 2023 の 16日目の記事になります。 概要 こんにちは。AI在庫管理の開発チームでSWEをしている小室です。 私は普段ドメイン駆動設計(以下、DDD)を意識しながら開発することが多く、実践を重ねるほどDDDの素晴らしさを実感しております。 最近異動してきたAI在庫管理の開発チームでは、現状はあまりDDDを意識して開発を進めていないのですが、プロダクトが対象としている世界が非常に複雑であることと、今まさに多くの法人様に利用していただけるようになったうれしい悲鳴として成長痛を感じ始めており、ドメイン駆動設計を何かのヒントとしてプロダクトによる価値提供速度を加速できればと考えています。 しかしながら、ドメイン駆動設計は独自の価値観や学習コストの高さから、まだ取り組んだことのないメンバーとしては大きな不安を感じる部分があると思います。

皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 本記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの

ChatWork Advent Calendar 2017の10日目の記事です。 こんにちは。かとじゅん([Twitter:@j5ik2o]) です。 何を書こうかと悩んだのですが、社内で意見を聞いたところ、やはりDDD関連がよいとなりました。 Scalaコードでわかった気になるDDD この記事も、もう四年前ですっかり古くなりました。最近どういう観点で実践しているかまとめてみます。(DDD初級者という方は、まず上の記事を読むことをお勧めします) DDDを実践するにあたっての個人的な問題点は2つあります。ひとつは、「いきなりドメインモデルを作ることができない」という問題。もうひとつは、ドメインモデルを作り上げても実装コードに役に立つ振る舞いが思いつかず、いわゆる「ドメインモデル貧血症*1」になりやすいという問題です。このような問題は、僕がコミュニティで関わった多くのエンジニアから耳にします。

この記事は アイスタイル Advent Calendar 2023 12日目の記事です。 はじめに みなさんこんにちは。 アイスタイルのバックエンドサービスを担当しているkuriyamayです。 アドベントカレンダーへの参加もお馴染みとなりました。 過去の記事はこちらです。 2020年 kubernetes(k8s)を構築してデプロイやスケールで遊んでみた 2021年 Java SE 11(Java Silver)を受験した話 2022年 curry化と部分適用をJavaで curry化と部分適用をJavaで ~命名編~ 2023年はCQRSとEventSourcingについて書いていこうと思います。 CQRS / EventSourcing CQRSとは CQRS（Command Query Responsibility Segregation）は2010年にGreg Youngさんによ

チームで仕事するとき、みんなもう少し自分の存在、自分のリアクションがチームに与える影響を自覚した方がいい。 例えばミーティングでブレストしているとき、議論が前に進むのは、あるときふと場に出されたアイデアに対して、誰かが"それいいですね"って言った瞬間である。アイデアを出したとき、その人にはふつう、確信なんてほとんどない。僕なんか自分の意見に自信なんかなくて(大体みんなそうなのだ)、言ってみて、まわりの反応を見て、あ、なんか良さそうだ…と思ったときにやっと前に進むことができる。みんな、自信なんてないのだ。だからアイデアは、場に出されたときはまだ、波際の砂のお城のようにやわらかである。 しかし、あるアイデアに対して、それいいね、と声をもらったとき。いい顔が見えたとき。姿勢が前のめりになってくるとき。そのときとあるアイデアは、はじめて光るのだ、形になる可能性を見せるのだ。 * 逆に言えば、議論に

本記事は READYFOR 株式会社の READYFOR Advent Calendar 2023 の [15日目] です。 ※ 本記事の内容は所属会社の公式発表・見解を示すものではありません。 ■ 「言葉集め会」とは？ 弊社 READYFOR では2年ほど前より DDD に関する取り組みを行っています。 「言葉集め会」とは、そんな弊社にて実施した コンテキストマップの作成や精度向上 を主目的とした 『ドメインエキスパートの皆さんを招待し、仕事で使う「言葉」とその関係性を改めて見出してみる』イベント です。 同僚の方が前職の体験を元に考案したもので、準備を除き全体でおよそ4時間という少し長丁場のプラクティスとなります。 その経験について本日はお話をさせて頂きます。 ■「言葉集め会」で期待できること 「言葉集め会」を実施することで、以下の効果を期待することができます。 エンジニア目線 自社の

noteではかなりざっくりした話を書く。 今回は「開発はどこから始めればよいか」に対するアプローチについて。 開発プロセスの開始点についての質問は一般的であり、特に要件が不明確な場合には、次のような手法を採用することが多い。 ツールの選択は多岐にわたるが、必要に応じて適切なものを選ぶことが重要である。 イベントストーミング ユーザーストーリーマッピング リレーションシップ駆動要件分析(RDRA) ドメインモデルの設計と実装に入る前に、システムの全体像を把握した上で、少なくともユーザーストーリと概念モデルを定義しておくことが重要である。 テスト駆動開発（TDD）のアプローチでは、ユーザーストーリーを基に最初にテストを記述する。例えば、「オークションに最高額で入札する」というユーザーストーリーがある場合、以下のようにメソッド呼び出し部分を想起しながらテストを作る。 auction, err =