こんにちは。CTOのzoo（YOUTRUST/Twitter）です。 2023年4月3日から4月7日まで、『めざせChatGPTマスター』と題して5日間の社内ハッカソンを行いました。 最終日の発表会には、外部から審査員をお招きし、全社員の3分の1以上のメンバーが聞きにきてくれて、非常に盛り上がりました！！ この記事では、その様子を紹介したいと思います。 ちなみに、勢いで『めざせChatGPTマスター』と題したものの、実際にはOpenAIのAPIを用いたハッカソンです♪ ハッカソンの目的 世の中の多くの企業と同様に、AI系のツールを一人一人が使いこなせるようになることが重要であると考えており、全社員にAIラーニング費用の支給をしていたりします。 prtimes.jp そんなYOUTRUSTですが、今回のハッカソンでは次の2つを目的としました。 ChatGPT（OpenAI API）を利用した

「現代の経営においてデータの重要性が高まっている」といった言い方をよく耳にするようになった。たいていは、ビッグデータ分析とかデータ駆動経営といったバズワードの文脈なのだが、いつも残念な気持ちになる。それらが効果を上げるには「所与のデータ様式がまともであれば」という前提がありながら、それが語られることがまずないからだ。じっさいのところ、まともなデータ様式で運用されている業務システムなど稀で、それらのバズワードの有効性も「嘘ではないが、役立つ状況がほぼない」のが実情である。 当たり前の話だ。データの矛盾を認める、つまり正規化されていないデータがどんなに大量に存在しても、そこから導かれる分析結果はゴミでしかない。「ゴミからはゴミしか生み出されない(Garbage in, garbage out)」である。最新のデータ分析技術を用いても同じことで、とくにAIにそこらへんを期待するのは無理筋というも

Value Objectが盛り上がっているらしい。 Value Objectについて整理しよう - Software Transactional Memo Value Objectの説明に異論がないものの、主題はValue Object Obsessionのほうですよね。 こちらも聞いてみた。 fukabori.fm よい機会なので、よくわかっているつもりの、値オブジェクトというかドメイン固有型について再考してみよう。 それは値か属性か それはエンティティの全メンバーやデータベースの全列のために「顧客郵便番号」「送付先郵便番号」「事業所郵便番号」「契約日」などのクラス(メンバではなくクラス！)を定義して、immutableな振る舞いを強制する事を以てValue Objectであると言い張り、ドメイン知識の断片をそれぞれのクラスに書き散らして「高凝集になった」「型システムが守ってくれる」と喜

こんにちは！YOUTRUSTでエンジニアをやっているやまでぃ（YOUTRUST/Twitter)です！ 外は春の陽気が心地よく、部屋の中もそよ風が吹き抜けていてとても気持ちが良いです。 最近のYOUTRUST社の話なのですが、先日3年振りに全社合宿を湯河原で行いました。 現地集合現地解散とのことだったので、折角なので僕は家から片道90km6時間の道のりを自転車で往復しました。普段はオンラインで直接顔を見合わせない人達とも交流が持ててとても有意義な時間でした。 帰り道でぱしゃり。これの7倍くらい海が広がっていた。 さて今回の本記事ではスケーラブルなリスト取得ロジックについて書いていきます。 タイムラインの投稿やユーザー検索等、Webサービスでは何かとリソースのリストを取得する処理がありますよね。 「リスト取得なんて持ってくるだけじゃん？簡単じゃん？」かと思いきや、実はちゃんと気をつけて設計し

この文章は祈りです。 主にRuby on Railsアプリケーションを想定した話です。 Ruby on Railsアプリケーションでは、Fat Model問題という問題が起きることがあります。 ドメインオブジェクトが肥大化しメンテナンスしにくくなる問題です。 Fat Model問題に対応するためにサービスレイヤーを導入することがあります。 「ドメインモデル貧血症」と呼ばれているアンチパターンです。 ドメインモデル貧血症 ドメインのロジックをドメインオブジェクトの中に入れないという設計ルールに従っているのでしょう。その代わり、すべてのドメインロジックを含むサービスオブジェクト群が存在しているのです。 Fat Modelを恐れよ Fat Modelは「単一責任原則」を満たしていないモデルです。 単一責任原則 | プログラマが知るべき97のこと 1つのサブシステムやモジュール、クラス、関数などに

こんにちは。YOUTRUSTのCTOのzoo（@zoopon1986）です。エンジニアブログ始めます。 YOUTRUSTとエンジニア YOUTRUSTでは、「信頼される人が報われる転職市場に」というミッションを掲げ、キャリアの機会を広げる"キャリアSNS"や法人向けに副業・転職のスカウトサービス（CareerTechと呼んでます）を提供しています。 そのようなYOUTRUSTを開発しているエンジニアは、副業や業務委託の方を合わせて15名ほど。toCプロダクトをつくるSNS事業部と、toBのキャリア事業部に所属しているエンジニアはそれぞれの事業の目標達成に向けてプロダクト開発を行い、CTO室に所属しているエンジニアは共通基盤を担当しています。また、サービス提供に用いている技術は、AWS、Rails、React、Flutterなどです。 YOUTRUSTのエンジニアブログ 少しずつエンジニアの

これまで何人も強いエンジニアと出会って、 「なんで自分はあの人と比べて何もできないんだ・・・。」と何度落ち込んだことか。 ただ、最近強いエンジニアの仕組みを理解してから落ち込むことは無くなった。 それについて書いていく。 （強いエンジニア達本人に聞いたわけではなく、観察してえられた個人の見解です） 気づき：強いエンジニアを見て落ち込む要因は2つありそう 1つは今の知識や技術力の差。 書くコードの違いだったり、成果物ができるまでの時間に差がありすぎたり、PRレビューで自分が思いもしなかったウルトラ解決策を何度も提示されて、自分の実力の無さを感じて落ち込む。 もう1つは新しいことを学ぶときの時間の差。 お互い知らない技術だったはずが、いつの間にか強いエンジニアはその技術に習熟(しているように見える)して、自分は理解不足で取り残されているという状況が発生しがち。 この時、自分には才能がないのかと

きっかけ blog.magnolia.tech id:magnoliak さんがおもしろそうな話をしていたので乗っかってみた。 きっかけとなったメタツイート すえなみさんがいい事言ってるとき、Twitterだと過去ログ掘るのが大変なのでブログに書いてほしいなって思ってます— 水殿 (@midono_ap1) 2022年1月31日 って言われたのでブログに書いとくことにする。 ブログ書くの何年ぶりだ… TL; DR まあ、言いたいことはだいたい以下のツイートにまとまっている。 「本来のビジネス要求に存在しなかった抽象を示す語彙」がまさにユビキタス言語の候補になるものだと思いますし、設計の醍醐味でもあると思うんですよね— やきにく (@a_suenami) 2022年2月12日 要求に存在しない抽象を定義して、さらにそれをコードとして表現しようとするのはすごく勇気がいる。ともすればYAGNI原

『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう

この記事は TDD Advent Calndar の 20 日目の記事です。1 日遅れました。すいません。 記事を書くことになったきっかけ こんなツイートをしたら 一周（？）まわって、TDDって一体何だったんだっけ？っていうのを考えている。— ベーシック焼肉 (@a_suenami) 2020年12月6日 見つかってしまいました！ その考えのアウトプットをお待ちしてます！whttps://t.co/fIFVAkuitQ— broccoli (@nihonbuson) 2020年12月6日 というわけで、最近考えてることを書きます。 何が開発を駆動するのか TDD は日本語では「テスト駆動開発」と呼ばれるが、私たちの開発はテスト以外にも多くのものによって駆動されていると思う。実際、TDD 以外にも XDD と呼ばれるもの（X には何らかの文字が入る）は数多くある。 テスト以外に開発を駆動する

２つの ”Entity” ある種の ORM では RDB のテーブルスキーマモデルとなるクラスのことをEntityと呼んでいます。例えば PHP のDoctrineや TypeScript のTypeORMなどがそうです。 そういった ORM を採用したプロジェクトで DDD に取り組むとき困るのが用語の衝突です。ORM の Entity は RDB のための定義を含むため当然 DDD の Entity とは異なるのですが、なにぶん同じ名前なので混同してしまいがちです。 本記事では両者を混同せず扱うための考え方をまとめます。 Entity の定義 まずは定義から確認します。 DDD での定義 エヴァンス本の日本語訳から引用します。 主として同一性によって定義されるオブジェクトはエンティティと呼ばれる Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edi

システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開

目次 目次 Finder Object とは 定義 モデル 検索条件 実装例 Finder Object 未使用の場合 Finder Object を利用した場合 最後に Finder Object とは DBへのクエリを担うクラス。 複雑なクエリを発行したい場合に使います。 似たような物として Query object があり、こちらは1つのscopeに対して1つの Query Object を作る実装になります。 昔は多用していたのですが、メンテナンスコストがかかるため現在はほとんど利用していません。 qiita.com 定義 まずは今回の検索に利用するモデルと検索条件を定義します。 モデル 施設 class Facility < ApplicationRecord belongs_to :prefecture has_many :facility_features, dependen

ここ数日、こまどさん（@koma_koma_d） が Twiter でクリストファー・アレグザンダーのパタン・ランゲージやそれを参考にしたデザインパターンやアジャイルプロセスなどについて話していて、それにつられて僕もいろいろ考えてみたりしたのでブログにまとめておこうと思う。 ちなみにこまどさんもブログにまとめられており、その記事がこちら。 ky-yk-d.hatenablog.com まあ、僕はあまり大それたことを言うつもりはないのだけど、全体と部分、分析と総合、デザインの民主化、遅延結合などをキーワードに思ったことを徒然なるままに書いていく。Twitterで述べたことをまとめておくかっていう程度のゆるい動機なので、ツイートの引用が多くなること、図を書いたり出典を丁寧に引用したりはできないかもしれないんだけど、そこはあらかじめご容赦願いたい。 パタン・ランゲージとは 読者にどの程度の知識を

概要 顧客にとって役に立つソフトウェアを開発するには、モデリングが重要だと言われています。モデリングによってソフトウェアの価値が高まると言われています。 モデリングとは一体何でしょうか。 単にUMLでクラス図を描くだけでしょうか。 本記事は、ドメインモデルの考え方についてなるべく容易に理解できるよう、ゲームを題材に解説を試みたものです。 留意 本記事では実在の製品を例に挙げて解説していますが、モデル図等はあくまで筆者の私見、個人的な推測であり、実際の製品開発で考案されたモデルとは異なるであろうことにご留意願います。 また、「ドメインモデル的な見方をすればこのようなモデルとなるのでは」と私個人が解釈した内容であることにもご留意願います。 ドメインモデルとは何か 「モデル」と言っても文脈により様々な解釈がありますが、本記事ではドメイン駆動設計に登場するドメインモデルに従います。ドメインモデルな

2020年1月に入社し、SWETの仕様分析サポートチームに加わったtakasek（@takasek）です。 仕様分析サポートチームでは、社内のプロダクト開発に対する形式手法の活用可能性を模索しています。当ブログでも、継続的に形式手法に関する情報発信をしています（形式手法 カテゴリーの記事一覧）。 この記事では、加入3か月を経てようやく形式手法の輪郭が掴めてきた私の視点から、学習前後での理解の変化について振り返ります。想定読者として学習前の私と近い属性——すなわちコンピュータサイエンスや数学の専門教育を受けておらず、主に現場での実務と自習に頼ってきたソフトウェアエンジニアを想定しています。 形式手法を学ぶ前の認識と疑問 ソフトウェアエンジニアとしての私の一番の興味関心は設計手法です。設計は、なんらかの解決したい問題に対して、ある一面を切り取った構造（モデル）を与え、そのモデルを解決の機構に落

ギルドワークスの代表を2020年6月でもって退任いたします。 2014年4月からつとめてきたギルドワークス社の代表を退任することにいたしました。丸6年のつとめとなります。 「自分の会社を退任するってどういうこと？」と思われる方もおられると思います。ギルドワークスは創業メンバーおよびその設立を後押しして下さった事業会社の出資によって成り立っています。ここまで会社の代表としてその任を果たして参りましたが、ギルドワークス自体は私の個人会社ということではありません。後任についても定めております。その周知については、ギルドワークスの会社サイトで案内します。 退任を決めた理由は、自分の時間の使い方、優先度を変えるためとなります。具体的には2つあります。一つは、家族に向けた時間の優先度を上げることです。私は2006年に転職のため大阪から東京に出てきました。15年近い歳月が流れたことになります。この間、家

チームのマネージャーが、自らの責務をジョブディスクリプションとして明文化することは難しい。職務内容や権限を、断片的にしか書けないかもしれない。もしそうなるなら、実務も断片的になっている可能性がある。 チームマネジメント（組織マネジメント）という活動は、個々のマネージャーの経験や関心によって、断片的になりやすいように感じている。断片的とは、マネジメント活動が、責務の一部の領域に偏ってしまっていたり、問題を検知してはじめてその領域がマネジメント範囲であることを知る、といった様子を指している。 このような状態になる背景は、マネージャーにとって、マネジメントが、日々の実務を通して蓄積された経験に基づく活動になっているからではないか。マネージャーは孤独だ。ひとりでその責務を担う。エンジニアとは違い、チームで協働するわけではない。だから、形式知として言語化されず、個人の経験として暗黙知にとどまる。その

2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ

エンジニアにLAPRASについての率直な意見を聞かせていただくインタビュー企画。第4弾はすえなみさんにお話を伺いました。 Twitterで発信した、ペアプロをしてもらう代わりに焼き肉をおごる企画「すえなみチャンス」が広まってコミュニティ化したすえなみさん。GitHubなどのアウトプット以外でエンジニアのスキル判定をするアイデアや、エンジニア採用に対して感じる違和感、そしてLAPRASに期待することについて焼き肉を食べながらお話いただきました。 《プロフィール》 すえなみさん(@a_suenami) サーバーサイドエンジニア、アーキテクト。大学在学中に新卒採用市場向けの人材サービスの立ち上げに参画した後、Webシステム開発会社、女性向けキュレーションプラットフォームMERYのサーバーサイドエンジニアなどを経て、独立。 これまでに飲食店予約管理システム、広告配信プラットフォーム、キュレーション