松尾研究室では複数のLLMに関する開発プロジェクトを推進しており、一緒に働いてくれる仲間を募集しています!! LLM研究者（特任研究員・特任助教・特任講師） [1] 効率的なLLMの学習方法に関する研究 [2] LLMの動作原理の理解 [3] LLMの社会的リスクに関する研究開発 [4] その他LLMの高度化や応用に関する研究 など。詳細はこちら LLM開発エンジニア（東京大学学術専門職員） [1] LLMのフルスクラッチ構築（1B〜100B），継続学習 [2] LLMの社会的リスクに関する研究開発 [3] 外部知識や外部ツールとの融合（LLM Agent） など。詳細はこちら その他全ての募集求人はこちら

こちらの記事はカケハシ 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 =

記事のポイント 多くの組織が心理的安全性を「思いやり」や「いい人であること」と誤解しており、これがビジネスに悪影響を及ぼしている。 従業員が報復を恐れずに問題を指摘できる環境を作ること。これにより最高の業績とパフォーマン […] 記事のポイント 多くの組織が心理的安全性を「思いやり」や「いい人であること」と誤解しており、これがビジネスに悪影響を及ぼしている。 従業員が報復を恐れずに問題を指摘できる環境を作ること。これにより最高の業績とパフォーマンスが生まれる。 心理的安全性の概念を長年研究してきたエイミー・エドモンソン教授は、心理的安全性が「弱み」ではなく「武器」になると強調し、正しい理解と適用が必要であると説く。 雇用主は従業員の心理的安全性（psychological safety）を十分に理解できていない。そしてそれはビジネス上、極めて良くないことであると、専門家は警鐘を鳴らしている

本エントリはカケハシ Part 2 Advent Calendar 2023の13日目の記事です。 （Part 1もおもしろい記事がいっぱいあるので、ぜひご覧ください。） はじめに こんにちは。カケハシでソフトウェアエンジニアをしている平松です。 今年、新規プロダクト立ち上げの機会があり、その際に行ったフロントエンドの技術選定について紹介したいと思います。 フロントエンドの領域は選択肢が豊富で、変化のスピードも速いため、プロダクトの要件に適した技術を選ぶことはひとつの挑戦です。 実際、フロントエンド技術選定のヒント 【令和五年度版】のアドベントカレンダー記事を読んで、その難しさを改めて感じました。 今回の新規プロダクトは、ユーザがログインして利用するtoBの業務システムです。 私はカケハシでは2度目の新規プロダクト立ち上げですが、前回の経験を活かしつつ、新しいアプローチにも挑戦しています。

大変多く読んでいただいた「プログラミングというより物事が出来る思考法」というポストや、世界一流エンジニアの思考法の書籍で紹介した内容がある。 私の職場でも、ものすごく出来る人が「実践」しているところを何回も目撃しているので「実践編」として皆さんにシェアしようと思って今回のポストを書いてみた。 タイトルにもある通り、私はエンジニアだが、ビジネス書である書籍と書かれた多くの思考法と同じく、あまりエンジニアリングというものに関係ない要素であると感じている。 上記のポストや書籍でシェアした内容を端的に言うと「理解には時間がかかるがかける価値が十分あり、それによって自分が物事をコントロールしている感覚を身につけることが出来る」という自分の小さな発見だ。私がこのことを最初に発見したのは、新卒の出来る人々との出来事がきっかけだが、今回その小さな自分なりの発見を後押しするような出来事がいくつかあった。それ

Scala 3におけるデータ指向プログラミング（以下DOP）について深掘りする。久々にScalaの話題を取り上げるが、これはScala Advent Calendar 2023の14日目の内容でもある。 早速だけど、DOPの基本原則は意外とシンプルだ。 コード（動作）をデータから切り離す データを汎用的なデータ構造で表現する データをイミュータブル（不変）として扱う データスキーマをデータ表現から切り離す イミュータブルなデータは採用することは多いと思うが、これをそのまま実践している人はどのくらいいるだろうか。Scalaではクラス中心の関数型プログラミングが主流だと思うし、私もそうしている。 DOPの詳細は下記の本(以下DOP本)を参照してほしい。 データ指向プログラミング 作者:Yehonathan Sharvit翔泳社Amazon ちなみに留意すべき点がある。DOP本とJavaのPro

この記事は 株式会社ログラス Productチーム Advent Calendar 2023 13日目の記事です。 はじめに 〇〇を削除できるかどうかのビジネス処理、皆さんはどう実装していますか？ 同僚の話題になった記事でも削除の認可処理をどこに記述すべきか？は難しいと説明されています。今回はお題は認可っぽいもので書きますが広範に「削除ができるかどうか？」のビジネスロジックをドメイン層にどう閉じ込めるかの便利な実装パターンを紹介します。 削除処理のビジネスロジックの取り扱いは難しい 削除処理のビジネスロジックの実装はシンプルだけど更新処理や作成処理と比べて意外と難しいです。 それはなぜかというとドメインオブジェクト内の実装に削除処理を書くことができないからです。 例えば権限に管理者と一般ユーザーの二つの権限があるとします。