この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 35 週目の記事です！ 1 年間連続達成まで 残り 18 週 となりました！ ログラスのQAのコタツです。今年もよろしくお願いします（2024年スタートからもう3ヶ月過ぎましたが） この前、以下のイベントに登壇させて頂きました。人生初パネルディスカッションでした...わざわざご来場いただいた方、オンラインで見守ってくれた方、設営していただいたウィングアークさん、パネラーの方々、モデレーターの大平さん、ログラスのスタッフなどなど、関係者の皆さん本当にありがとうございました！ ATN#20　BtoBプロダクトQA集合　Loglass×WingArc1st×テストの街「葛飾」 (2024/02/15 19:00〜) 今回登壇させていただいたイベントはBtoBプロダクトのQAの面白さを語るというテー

Suno対抗のAI作曲サービスとして前評判の高かったUdioがパブリックベータとして一般公開されました。

claude.iconこれらのツイートは、先端的な開発プロジェクトにおいて「ガチでやる気パーソン(GYP)」の存在が非常に重要だという点で一致しています。

mtx2sさん・ログラス飯田さんと考える！コード品質が及ぼすビジネスへの影響 #コード品質_findy https://findy.connpass.com/event/313471/ 参考リンク アジリティを支える品質特性 https://speakerdeck.com/twada/agility-and-quality-characteristics-developers-summit-2021-summer 強くてニューゲームなプロダクト開発 https://speakerdeck.com/yoshikiiida/product-development-in-new-game-plus ログラスQAのミッション・ビジョン・バリューを策定しました（品質富士山について） https://note.com/k_kotatsu1992/n/nd639aa4b5692 ログラスを支える設計標準

Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に代数的データ型などの関数型のパラダイムを加えたよりタイプセーフな関数型DDDを紹介します。 本セッションではドメインモデリングによって発見したモデルやビジネスロジックをソフトウェアに反映する際により型を重視した設計を加えます。 型で表現する範囲が広がることでビジネスロジックをより明確にコードで表現できるようになります。 さらには型で表現されているためコンパイルフェーズで気付けるミスが増え、ソフトウェアの品質向上にもつながります。 関数型の考えをいれるといってもただ単にHaskellなどに代表される関

SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。

はじめに 勝丸と言います。ログラスのエンジニアが毎週記事を発信するLoglass Tech Blog Sprint 2周目に突入しました。前回は「心穏やかにDBバージョンアップ！ロジカルレプリケーションで安全にバージョンを切り戻せるようにした話」という記事を書きました。こちらもよろしくお願いします。普段はログラスの横串組織で活動しています。 この記事では「数年来の技術的負債を改修した話 - 2種類のORM並列状態からの脱却 -」というタイトルで、年末から年始にかけてやっていた作業について共有します。 この記事で得られること リファクタリングのやり方や考え方 リリースへの持っていき方 投資判断のタイミングや負債解消について 経緯 ログラスでは2種類のORMが存在していました。創業時にORMとしてExposedを採用したのですが、後に一部機能が足りないことが発覚し、別のORMを利用し始めました

そりゃ間違ってるんだけど、ではどうするべきなのかが見えてないなぁという話です。 事業が大きくなると組織という仕組みの重要性が上がる 同僚が何千人といたメガベンチャーから社員数20数人のスタートアップに転職してから1.5年経ちました。ここまでに自分が貢献した内容にはSREや医療情報技師としてのものも当然あるのですが、マネジメント経験のあるIndividual Contributorという立場から組織の成長や組織における連携について補足や関連情報を提供するということも意外とありました。例えば社内ブログや社内勉強会で触れたものには以下のようなものがあります： コーチング紹介 ヒューマンスキル紹介 爆速アウトプットを組織的に支える施策 事業の急成長における表側と裏側 稟議入門 こうした知識や観点を個々人が持つことは、ボトムアップと呼ばれる自発的な行動を支援する意味では大きな意味があります。そして少

子どものころは絵を描くのが好きだった。 学校の休み時間は、クラスメートはみな外にサッカーをしにいっていたが一人教室にのこってノートに漫画を描いている、そんな小学生だった。 自宅に戻っても、自室にこもってよく漫画を描いていた。 漫画と書くいっても、別に人を楽しませるために描いているわけではなかった。もちろん褒められると嬉しかったが、それが目的だったわけではなく、いま思えば、それは自分で自分を癒すかのような行為だった。自分を救うために絵を描いていた。 絵を描いているときは、それに夢中で没頭していて、ほかの何にも代えがたい時間を過ごすことが出来た。この時間が、どこか自分の救いになっていた。 中学二年生ぐらいになって思春期にさしかかった頃だろうか。教室で絵を描いていると浮いてしまうことに気づいて、恥ずかしくなって、描かなくなった。 それでもやっぱり絵を描いたりなにか作品を作ったりするのは好きだった

adventar.org この記事はジンジニアアドベントカレンダー25日目の記事です。 ジンジニアとそのコミュニティについて エンジニア出身の人事という説明が最もシンプルですが、最近はEMやDevRel文脈などもう少し広いバックグラウンドの人が界隈に集まっていると感じています。 私自身、これまでのキャリアで開発と人事と二足の草鞋を履いていたこともあり、いつのまにかジンジニアコミュニティに所属するようになっていました。 ジンジニアという言葉自体はもう少し前から存在していたようですが、コミュニティとして活動を開始したのは  @tbpgr さんが発起し2019年に開始したのが最初です。 tbpgr.hatenablog.com 特に人事面に関わると言うことで公開のイベントではなかなかお話しできないネタを相談したりすることができる場は非常に貴重な場となりました。 これまで不定期に開催する座談会がメ

この記事は Engineering Manager Advent Calendar 2023 19日目の記事です。 以前書いた記事が思いの外伸びてしまいびっくりしたのですが、以前の話題にも続く話を書こうと思います。 yo-iida.hatenablog.com ビジネスの成長に組織が追いつかない！を回避したい 私が初めてマネジメントにチャレンジした時感じた学びとして最も大きかったのがこの観点でした。 読んでくださっている方の中にも会社として成長を作り出したいのに舵を切ろうとしても組織がなかなかついてこないという悩みをもったマネージャーもいるかと思います。 いくつか要因がありますが、最も難しいのが「信頼されていない」という課題です。 （魅力的に伝える発信力などはスコープアウトします） ブレークダウンすると、「リーダーの言葉が形骸化している」や「リーダーの方針のもと頑張っても報われない」といっ

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

https://increments.connpass.com/event/300472/

Engineering Manager Advent Calendar 2023 7日目の記事です。 結論ファーストで書きます マネージャーは答えを持っていません。 大事なことなのでもう一度言います。 持っていません。 この問題ってそもそもなに？ 細かくみてみましょう。 マネージャーに全てを決められたくない マネージャーがHowまで決めてくるケースや、現場チームが決めたHowに対して口出ししてくるようなケースにおいて発生する事象です。 ものによってはWhyやWhatまで現場で考えたいんだ、というケースもあるかもしれません。 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023 - Speaker Deck こちらのスライドにあるような「私考える人」的な動きになっているマネー

最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います！ 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ

はじめに 本記事ではログラスにおけるスクラムマスターの考え方、そして専任化についての取り組みの現在地点をお伝えできればと思います。 なぜこのテーマを選んだか？というと、この1年を振り返る過程において、スクラムマスターという役割が改めて重要な役割を果たすのではないか？と考え、直近で専任スクラムマスターを置く取り組みを実施しておりました。 こちらの取り組みから、どんな仮説を立てたか？現在どんな状況か？などをまとめることで、同じくスクラムマスターの位置付けについて悩んでいる企業があれば参考にしていただけるのではないかと考えたためです。 この記事では私がエンジニアリングマネージャー（以下EM）として、スクラムマスターとEMの責務の切り分けをどうすればお互いがパフォームできる状況を作れるのか？という視点から話を進めていきます。 ログラスのスクラムについて ログラスでは創業時の1チームのスクラムチーム

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 15 週目の記事です！ 1 年間連続達成まで 残り 38 週 となりました！ はじめに ログラスでエンジニアをしているよしだといいます。SNSではお酒中心の生活を日々過ごしています。 いきなりですがみなさん、スプリントゴール立ててますか？立てていたら、ゴールの立て方で悩んでいたりしませんか？今回は私が所属しているチームでスプリントゴールに川柳を導入してみてスプリントゴールとしてより良いものが出来た話をしようと思います。 そもそもスプリントゴールとは 詳細に書くとそれだけで一つの記事になりますので、ここではスクラムガイドの中でのスプリントゴールの定義を転記します。 スプリントゴールはスプリントの唯⼀の⽬的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要と

この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 9 週目の記事です！ 1年間連続達成まで 残り 44 週 となりました！ はじめに こんにちは、株式会社ログラスでエンジニアの浅井（@mixplace）です。開発チームのいちメンバーとして、チームの開発生産性改善を行う傍ら、デザインシステムの構築に携わっています。 ログラスもプロダクトローンチをして 3 年が経ちました。日々新しい機能の追加や改修が入っていく中で、開発チームも増え、チーム内でアウトカムを出していくことが増えてまいりました。 機能が増え画面数も増えてくると、比例するように「UX負債」や「共通UIコンポーネントの技術的負債」も目に付くことが増えてくるようになります。 このような課題について、プロダクト全体の品質や一貫性担保する観点で「デザインシステム」を構築して運用していくことが

はじめに アジャイル開発では、技術やビジネスといった側面だけでなく、開発を担う人々の「人的側面」への取り組みが欠かせません。この記事では、その「人的側面」を強化する効果的なアプローチとして、「システムコーチング®」を紹介します。 特に「アジャイル・フルーエンシーモデル(アジャイルのプラクティスを包括的にまとめるモデル)」とシステムコーチングとの相互補完性に焦点をあて、ログラスの事例を交えて具体的な効果を探ります。システムコーチングを導入することで、チームや組織にどのようなインパクトがあるのか、そのポイントをお伝えします。 アジャイル開発とは アジャイル開発は、顧客の要求に迅速に対応するためのソフトウェア開発手法の総称です。短期間のイテレーションを通じて、開発チームは頻繁に製品のリリースを行い、顧客のフィードバックをすばやく取り入れることができます。 このアプローチはその柔軟性と迅速性により

🐳この記事は「ログラスサマーアドベントカレンダー2023」の29日目の記事です。明日は一人目のマーケ、盛川君です！ こんにちは、ログラスでデザインマネージャーをしている高瀬です。 この記事では、名前をつけないUXライティングのアプローチについて考察し、なぜ名前をつけない決断が必要なのかを記載していきたいと思います。 プロダクトが複雑になる問題昨今のデジタルプロダクトは時間の経過とともに成長していき、どんどん便利な機能がリリースされていきます。はじめはシンプルで使いやすかったけど気がつけば複雑になっていき「使いにくい…」となることも珍しくありません。 私が所属しているログラスは「BtoB」 で「経営管理」という領域のプロダクトを提供しているため、専門用語や複雑な業務フローを扱うことがよくあります。 例えば経営管理の業務ワードを軽くピックアップするとこんな感じのものがいくつも出てきます。 予