JASRAC許諾第9009285055Y45038号 JASRAC許諾第9009285050Y45038号 JASRAC許諾第9009285049Y43128号 許諾番号 ID000002929 ABJマークは、この電子書店・電子書籍配信サービスが、著作権者からコンテンツ使用許諾を得た正規版配信サービスであることを示す登録商標(登録番号 第6091713号)です。

株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。

ログラスのカスタマーサクセスチームでは全社一丸となったサクセス体制を構築するために様々な施策をやっているのですが、昨年から実施しているカスタマーサクセスインターン制度（以下、CSインターン制度）がかなり効果的に進んでいる実感を得てきたので、記事にしてみようと思います。 できるだけみなさんにわかりやすく書くように心がけますが、 ・カスタマーサクセスをミッションとして取り組んでいる ・顧客の声をプロダクト開発に取り込んでいきたい ・全社を巻き込んでカスタマーサクセス文化を強化していきたい ・BtoB SaaS未経験だが、どんなチームで仕事しているのか興味がある といった方の参考になれば幸いです。 ＊なお、取り組みは事業や組織の成長に合わせて随時アップデートされていきます。この記事は2022年1月時点での内容になります。 はじめたきっかけ昨年、GainsightのCEOであるニック・メータさんが

株式会社ログラスの松岡(@little_hand_s)です。 ドメイン層のオブジェクトを設計する際に、重要な基本方針があります。 ドメインモデルの知識を対応するオブジェクトに書く 常に正しいインスタンスしか存在させない この2つを守ると、非常に保守性の高いコードにすることができます。 以下、詳細に解説します。 ドメインモデルの知識を対応するオブジェクトに書く ドメイン知識(ルール/制約)を表現する実装を、ドメイン層のオブジェクトに寄せていきます。 この判断は、「ドメインモデル図に書かれた吹き出しの内容が、どの層で実装されているか」という基準に基づき行います。 この基準はコード設計の指針として非常に役立ちます。 設計の良し悪しというのはさまざまな基準があるため、レビューをしていてもいわゆる「俺の考えた最強の設計」同士が戦ってしまうことがあります。 しかし、「ドメイン知識はドメイン層に書く」と

結論はタイトル通りなのだが、本エントリではメルカリ退職→ログラス入社に至るまでの、自分自身の経験・心の動きを記しておきたい。自分は今現在38歳で、転職は4回目だ。しかし、転職は何歳になっても・何回目でも難しい。これから書くのは至って私的な内容ばかりで、あくまで1つの個別事例に過ぎない。それでもこのエントリが「一歩踏み出して自分のキャリアを変えたい」と考える方を、勇気づけられたら嬉しい。 メルカリでやった仕事① d-point連携入社後1年半くらい、検討すれどもリリースまで行かない経験が続いた。仮説検証・UXリサーチは上達したが、プロダクトマネージャなので何かをローンチしたい。 そんな折にドコモ社との提携PJが発表され、これはやるしかない！と思い、参加することに。大型提携で絶対にリリースしないといけないミッションなので、多少思い切った動きが出来そうなことにも惹かれた。とにかくお客さまが触るも

フロントエンドLT会 - vol.5　#frontendlt　の登壇資料です。 https://rakus.connpass.com/event/232039/ UI Testing Handbook https://storybook.js.org/tutorials/ui-testing-…

BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/

エンジニア組織30人の壁を超えるための 評価システムとマネジメントのスケール / Scaling evaluation system and management

3. ● 名前 ○ 松岡 幸一郎 (@little_hand_s) ● 所属 ○ 株式会社ログラス 経営管理領域でDDDを実践中 ● 運営コミュニティ ○ DDD community jp主催 ○ Agile Developers Community主催 ● 発信 ○ 「ドメイン駆動設計サンプルコード＆FAQ」 「ドメイン駆動設計モデリング/実装ガイド」執筆 ○ 質問箱 (DDD関連の匿名質問受付) ○ DDD関連の技術ブログ ○ Youtube DDD解説動画チャンネル ● その他活動 ○ 企業様へのDDD導入/設計サポートなど 自己紹介 3 5. 雑談に関するスタンス ● 設立2年のBtoB SaaSのスタートアップで、 メンバー間のリレーション作りは重要課題 ● 良いプロダクトを作るための必要性 ○ ユーザーの声を吸い上げ、良いものを作るためには 同職種、異職種同士で協働することは必

この記事は前任 EM の yuya-takeyama の記事へのアンサーソングであり、 blog.yuyat.jp Engineering Manager Advent Calendar 2021 その2 2日目の記事として寄稿します。 qiita.com 背景 僕は引用記事の SRE チームの Software Enginner でした。ひょんなことから前任が別のミッションを担うことになり、このチームの後任としてどうか、となり 2021年10月より同チームの Engineering Manager をやっています。 以下、引用したりしなかったりしてこの2ヶ月の心境などを語っていきます。 Engineering Manager として置かれている状況 先ほど言った経緯に引き続き、情報的な話でいうと 自分含め7人のチーム もともと中途採用をしていた会社でもあり、自走可能なメンバーで構成されて

つい先日(2021/12/11)、歴史的にみてもトップレベルで深刻な脆弱性が発見されました。 自分が所属しているログラスでは同日 13:23 に該当ライブラリのアップデートを対応を終えました。 社内でインシデント起票してから1時間半ほどでの対応でした。 このスピードで対応できたのはひとえに全てのライブラリを ほぼ最新バージョンに保てているからです。 これは日頃のチームの成果であると思っています（もし今回のライブラリに関連するライブラリが古いままならパッチバージョンがうまく動かない可能性があった）。 この記事では改めて、ライブラリアップデートを行う理由と、チームで仕組みとして行っていくtipsを紹介していきます。 なぜ継続的にライブラリアップデートをする必要があるのか？ 継続的にライブラリアップデートを行う理由は2つあります。 迅速に脆弱性に対応するため ライブラリの新機能を使うため 順に説

本記事はドメイン駆動設計（ＤＤＤ） Advent Calendar 2021の13日目の記事です。 エンティティとイミュータブル性 オブジェクトをイミュータブル、つまり内部状態を変えない実装にすることで可読性やマルチスレッド対応性が向上することがあります。 エンティティはモデリング上の定義はミュータブルなものですが、実装方法をイミュータブルにすることは可能です。 (DDDでは、エンティティはミュータブルもしくはイミュータブル、値オブジェクトは必ずイミュータブルという定義です。詳しくはこちら) DDD基礎解説：Entity、ValueObjectってなんなんだ - little hands' lab 本記事ではエンティティをイミュータブルな実装にするサンプルコードと合わせて、イミュータブルにした場合の旨みを感じられるコードを紹介します。 イミュータブルなエンティティ実装の例 エンティティをイ

こんにちは、ログラスの飯田です。 この記事は Engineering Manager Advent Calendar 2021 の9日目の記事です。 1年のふりかえり1年前以下の記事を書きました。 この1年を振り返ってみると、 ・コードを書くこと8割 ・採用を中心とした組織的なこと2割 といった割合で結果としてはエンジニアリングに向き合えた1年だったかなと思っています。 とにかく手を動かしながらプロダクトを作っていくことに集中できたことは本当に取り組めてよかったです。 何よりほっとしたことは、「自分は2年現場から離れていても戻った時にはエンジニアとしてバリューを出せる」と思えたことです。これは私が転職の際に向き合わなければいけない最も大きな恐怖でした。 実際に1年の中でいくつか大きめの機能開発のリードを任せてもらえたことでそれは完全に払拭されました。 さて、ログラスは幸いにも採用が順調に進

PyCon JP 2021 発表資料です。

2. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会社)設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – EGセキュアソリューションズ株式会社取締役CTO https://www.eg-secure.co.jp/ –

面倒臭いオブジェクト詰め替え オニオンアーキテクチャ、クリーンアーキテクチャなどの階層化されたアーキテクチャを使用する際、レイヤーの境界でオブジェクトの値を詰め替える必要性が発生します。 オブジェクトを詰め替えることでレイヤーの依存関係を断ち切り、一度書いた後の保守性を高めることに大きく貢献するのですが、筆者の観測範囲では単調作業に感じるせいかかなり嫌われる傾向があるように感じます。 そして、そのような詰替を嫌うばかりにオブジェクト詰め替えをやめてしまうこともありますが、それは非常にもったいないことです！！ なぜなら、「初期実装の数分の重要性 <<<< その後の保守性の重要性」だからです。 なので、できればきちんと詰め替えしてレイヤーの依存関係を保って欲しい、ということで、そのために詰め替えが超簡単にできる方法をご紹介します。 まずはデモご覧ください。 class Entity( val

現場に戻ることを決めたのはエンジニアとしての自信を取り戻すため ――まずは現在のお仕事について教えてください。 今は経営管理クラウド「Loglass」を提供する株式会社ログラスでソフトウェアエンジニアとして機能開発をしています。ログラスではフロントエンドもサーバーサイドも関係なく、全員がフルスタックで開発しています。それぞれ得意な分野とそうでない分野はありつつ、クロスファンクショナルなチームでスケールさせたいと思っています。ここから組織を大きくしていくために、採用や制度設計など、開発以外の議論にも積極的に入りながら働いています。 株式会社ログラス ソフトウェアエンジニア 飯田意己氏 ――ログラスには2020年10月にジョインされたと伺いました。その前はクラウドワークスで執行役員をされていたそうですね。 はい。クラウドワークスには、もともと現場のエンジニアとして入社して、新規事業の立ち上げに

山型なスキルをもったメンバーがあつまる山型クロスファンクショナルチームを作りデリバリスピードを安定させるというテーマのスライドです。 XP祭り2021での発表資料です。 山型クロスファンクショナルチームは造語ですが、定義としては「スペシャリティをもちつつ周辺分野でも基本的な価値を発揮できるメンバ…

採用（あるいは、仲間集め）の課題は尽きないもの。組織の規模感ごとに悩みもさまざま起きますが、中でも「初期フェーズ」においては、その後のカルチャーや成長角度も占う大切な時期です。SaaSスタートアップであれば必須の「開発環境」を整備するために、各社頭をひねっています。 CFOや経営企画向けのプランニング・クラウド「Loglass」を開発・提供するログラスでは、CTOの坂本龍太さんが採用にも強くコミットし、成長を支えます。 創業して2年2ヶ月あまりで、正社員は内定者を含め19名、副業人材も合わせると40名を超える規模に拡大。そのうち、エンジニアは正社員9名、合計で20名以上を占めるといいます。さらに正社員エンジニアは7名がリファラル採用で加入しました。 坂本さんはビズリーチで「初の新卒社員」としてキャリアを始め、SaaSビジネスを経験。「将来、自分が起業するならSaaS事業だ」という思いを胸に

Tebiki 社の CTO をしている渋谷です（会社名が変わりました）。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は「スタートアップでも AeyeScan を使えば、継続的に脆弱性を診断できるようになるよ」という話について書いてみたいと思います。 （※近年特に注目されている SaaS などの Web アプリケーションに対する脆弱性診断の話です） スタートアップでもセキュリティは最重要スタートアップではとにかくサービスの PMF を目指すことを優先すべきで多少の脆弱性は後でどうにかすればよい、という意見をたまに見かけます。BtoB 向けの SaaS スタートアップを3年間やってきた一人としては、それは全くの嘘で、やはりセキュリティが最も重要だと考えています。 なぜなら「情報漏えいは会社の倒産リスクに直結する」からです。 仮に脆弱性を突かれて情報が