JGEEM

~モノタロウ式~ドメインモデリングとリアーキテクチャ Vol.2 (2024/12/11 19:00〜) ## 前回のイベントでは語れなかったモデリングやリファクタリングの具体的な進め方をお伝えします 前回のイベントではモデリングとアーキテクチャに触れ、AWSのソリューションアーキテクトである福井さん、金森さんをお招きして、開発メンバとのパネルトークを通じてモノタロウの取り組みをご紹介させていただきました。 今回は、当チームのモデリングやリファクタリングの具体的な進め方をさらに突っ込んでお伝えしつ...

遅まきながらこちらでも

本日開催です！

まだ多少の空きがございます
懇親会パートもありますので、弊社事例を肴に盛り上がりましょう

monotaro.connpass.com/event/331775/

オブジェクト指向のリ・オリエンテーション～歴史を振り返り、AI時代に向きなおる～ Object-Oriented Conference2024 基調講演(2024.3.24Sun)のスライドです。 オブジェクト指向という考え方がプログラミング言語Simula（Simula I：1962、 Simula67：1967）の影響のもとでAlan Kayによって1970年前後に生まれてから半世紀以上が過ぎた今、その歴史的な功罪を素直な目で振り返り（reflection）たい。そのうえで...

もはやリファレンスとして使えそう

とりあえずチームメンバ各位でどこまで話が通じるか確認して、落としどころを探るのに良い？
「OO」と意識しないために抜粋すべきか、、

“オブジェクト指向のリ・オリエンテーション～歴史を振り返り、AI時代に向きなおる～” htn.to/3prsr2hrWf

単体テストを書かない技術 #phpcon_odawara PHPカンファレンス小田原2024での発表資料です https://fortee.jp/phpconodawara-2024/proposal/4d39c7ef-058c-4648-b1d7-5510497e0d81

良い

"自分自身が何者であるかを熟知したコードを追及する"

コードの目的を突き詰めなければならないし、プロダクトへの理解とSRPに沿ったモジュール化となり、データ抽象と型検査でテストを置換していきたい

単体テストを書かない技術 #phpcon_odawara
htn.to/2e2Qt95p49

単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場 オブジェクトの広場をご覧の皆様ならば、SOLID原則は常識中の常識かもしれません。しかし、今回は、あえてSOLID原則の一つを考えてみたいと思います。

"単一責任の法則は、「クラスには一つのアクター」"に同意
ただ、アクターを「特定の目的を持ったシステム外のナニカ」と捉えると、単一責任≒ひとつのことをうまくやる≒クラスには一つの目的と捉えても良いのでは

“単一責任の原則（Single responsibility principle）…” htn.to/3VznN9AVLK

「会議で話されている内容と、ソースコードが全然違う」〜イオン発の“新ネットスーパー”リリース直前の1年間を語る｜イオンネクストCTOインタビュー ｜AEON TECH HUB イオンネクスト株式会社・CTO 樽石将人のインタビュー記事です。入社時にミッションとされた新ネットスーパー「Green Beans」は、期日通りのリリースが危ぶまれるほど問題が山積みだったと言います。プロジェクト立て直しのために目をつけたのは「現場」。樽石は何を変え、どう開発を進めたのでしょうか？リリース直前の1年を語ります。

今さら読んだが面白そうな（胃が痛くなりそうな）トライを続けてる
これだけの不確実性と向き合ってどうにか事業を回していく経験なんてそうそう得られないので、現場はめちゃ楽しそう(胃もすり減りそうだけど)

“「会議で話されている内容と、ソースコードが全然違う」…” htn.to/4vq27sDLsa

大規模なアジャイル開発の現場と技術負債 / Technical Debt

大規模なアジャイル開発というより、組織としての認知的不協和にどう取り組んだか？という話に見えた
そしてインフラチームの邪悪さが目を引く
必要なのは長老各位の意識改善とPFEだったということかな

“大規模なアジャイル開発の現場と技術負債 / Technical Debt” htn.to/3Qt4sZzLJh

ビジネスとコード品質の接合点 そしてコード品質がそこに及ぼす影響 / The Intersections of Business and Engineering, and The Impact of Code Quality There 2024-03-21 Findy TechBrew in 東京 https://findy.connpass.com/event/310772/

見えにくいがクリティカルな影響を持つ「コード品質」をどう上げるか？を具体的なアプローチとともに言語化されている
いつもながら図が分かりやすい
理解容易性の指標に構造化を観点にできないものか、、

“ビジネスとコード品質の接合点 そしてコード品質がそこに及ぼ…” htn.to/3gN7wLWZgA

Deep Dive 大規模システムアーキテクチャ／開発組織エンジニアリング / Deep Dive Large-Scale System Architecture, Development Organization Engineering 学生向けのイベント技育祭2024にて、大規模システムにおけるアーキテクチャの触りをお話したものです。 ビギナー向けなのでそれほど深いお話はしておりません。 【アブストラクト】 本トークでは大規模システムアーキテクチャで考慮すべき事柄とそれを実現する技術スタックや運用システムを深堀りし、それらを実現するための組織の構築をアーキテクト視点でお話します。大規模システムならでは難解な課題とそれを乗り越え...

ページ数見たときはそっ閉じしようかと思ったけどめちゃ読みやすかった
メッセージングによる疎結合を広めるのに活用させていただきたい資料
そしてキューとストリームの使い分けはよくわかってなかったので嬉し

“Deep Dive 大規模システムアーキテクチャ／開発組織エ…” htn.to/N88avhQDvg

Software Designドメイン駆動設計に参加 - Qiita 前書き業後に以下のDDDイベントに参加してきた。その議事録とアウトプットとしてここに残す。https://softwaredesign.connpass.com/event/309841/画…

コアドメインの見つけ方が言語化されていて良い
コアドメイン特定→周囲との関係を図示も同意
「BAでの概念モデリングをAA層にてイベントソーシングで相似形に実装すること」を再読しながら噛み締めたい

“Software Designドメイン駆動設計に参加 - Qiita” htn.to/3br9AWdHxq

サーバーレスマイクロサービスを構築するための設計アプローチの比較 | Amazon Web Services AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。

この比較表は良いな
が、Lambda-lithの利点にある「凝縮度の向上」「メンテナンスの簡素化」は違和感
目的の異なる似た処理を集めてるように見えて、不幸の始まりを予感させる

“サーバーレスマイクロサービスを構築するための設計アプローチの比較 | Amazon Web Services” htn.to/2pkbA1moFf

スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ - / How to start Scrum that is not written in the Scrum Guide Scrum Fest Fukuoka 2024にて。 https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19555/5 プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monster.com/profile/ https://agile-monster.com/contact/

鳥獣戯画を見ると前職を思い出すな、、
はさておきフォーカスすべきはレビューとレトロスペクティブか
そうするとスプリントの切り方が重要になってくるんだろうな
ちょっと考え直してみよう

“スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムを…” htn.to/3SYyqXWHQG

でもやっと「あとで読む」が終わりそうだ！終わったらデータモデリングでドメインを駆動するぞ

そして文中で紹介されていたSoftware Design 2022年3月号の特集を意気揚々と見に行ったが、スクロールバーの小ささに「ごはん食べてからにしよ、、」とそっと閉じた

【翻訳】テスト駆動開発の定義 - t-wadaのブログ このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者 Kent Beck が TDD の定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投...

"設計せずにいきなりテストコードを書き始めることではない"
"リスト、レッド、グリーン、リファクタ"
テストリストとは対象の仕様だし、仕様を満たすにはどうしようか？を考えることが設計だと思ってる。広まれ！

“【翻訳】テスト駆動開発の定義 - t-wadaのブログ” htn.to/4wJRyEcBzu

胸が苦しくなる記事だな、、
「なぜできないのか？」の4つの内3つほど当てはまってる気がする。でも問題がはっきりしたか？
チーム内外のIFと計画をSMが巻き取って、開発チームとの間に溝があるからだ。きっと。
問題が分かれば対策できる。はず。

“アジャイル開発がうまくいっていない気がするとい…” htn.to/4f4mXQYLF3

リモート開発チームで取り組んで成果がでた「コミュニケーションガイド」 | SHINGO IRIE 昨年の8月からランサーズでLLM Labsを立ち上げ、あたらしい開発チームで今年2月にオートロンをリリースした

朝会は互いを知る場にするか。よいな
今は進捗・予定を確認してぱっと解散してるな。。
でも朝よりも終業前のほうが良いか？チルアウトするためにも夕会（帰りの会）で雑談して明日への希望を胸に終業する的な

“リモート開発チームで取り組んで成果がでた「コミュニケ…”
htn.to/492WFbETGj

OKRの時期だし、初のスクラムチームだしどうしようかと思ってたんだけどチームストーリーっていいな
SMARTな目標を！的な圧と探索的な活動との間でどう戦おうか悩ましい

“チーム目標を定めるときにやったワークショップの紹介と実際に定めた目標を運用してみた感想” htn.to/2bysBbQLBH

モジュール化 | 神戸大学MBA 原　拓志現代の製品開発・生産のマネジメントにおいて、理解しておくべき概念の1つが「モジュール化」である。「モジュール化」とは、全体システムを、いくつかの下位システム（モジュール）にわけ、モジュール間のインターフェイスを標準化することによって、システム全体の構造を変革することなく、モジュールの取替や組換えによって、システムの機能を維持ないし変更できるようにする方法である。システムがハードウェアでもソ...

モジュール化についてとても端的に説明されている良い文章
こういう認識を基にどこまでやる？どうしたらいい？という議論に持ち込みたいのだけど、、
そもそも「設計」という行為について意見交換する土壌がないんだよな、、

“モジュール化 | 神戸大学MBA” htn.to/2baARXmkPi

開発生産性と探索型組織の作り方 / developer-productivity-20240126

良いスライドなのにブコメの少なさよ
言い尽くされてることだからかな？でも改めて探索型組織に必要なセルフマネジメントなどの要素を挙げてくれたのは嬉しい
が事業会社の業務システムの成長は、、と考えてしまう

“開発生産性と探索型組織の作り方 / developer-produc…” htn.to/2t72ptyrjD

しかもハッシュタグに対応してるじゃないすか

ちょうちょスプラッシュ？がなくなった！

あ、、スクラムの記事が非公開になってしもた
良い記事だったし感がおるきっかけになるからチームに展開したかったが、、残念

本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ

おもろかった
しかしほぼ絶望しかない、、
それだけ茨の道なのに都合よく無視されてるんだろな
ついでに言うとビジネス側と一緒にフィードバックを得て短いサイクルでリリースを重ねたいだけでスクラムじゃな文字数

“本に書いてあるスクラムと、お前らのいうスクラム開…” htn.to/3q6w8g7mtY

言うてフィードにまとめたら同じことができるのかな？

ウェビナー見てるんだが、#が機能しないここではワイワイしにくいな

マヌスも撃破！

カラミット狩った！！

よし、走るぞ！（宣言的

アジャイル開発の「人的側面」の課題を解決する「システムコーチング」

良さそうなツール？フレームワーク？な気はするので興味はあるが、もうちょっと情報がほしいな、、
プロセスを開発されている会社も紹介されているがユーザ登録しないと情報をくれない

“アジャイル開発の「人的側面」の課題を解決する「システムコーチング」　”
htn.to/3n9M3MJFnf

ハラスメントにならない、部下への厳しいフィードバックの伝え方　心理的安全性を高める「聴く」と「伝える」の使い分け 売り手市場の採用環境、働き手の多様化が進む今、ミドルマネジメントの変容が組織成長の要となっています。本イベントでは、個々を尊重しながら適切な指導を行い、部下を育成していくための職場コミュニケーションについて語られました。本記事では、エール株式会社 代表の櫻井将氏が、「聴く」と「伝える」の両立の仕方やコミュニケーションがうまくいく「聴く」コツについてお話しします。 #### 前回の記事はこちら

良いこと書いてる
「意識しないと常にジャッジしてる」はマジそれな
口を出したいタイプなので意見を求められてる場面と、ただ受け止める場面を切り替えたいけど、、
マネージャーとリーダーは別モノだよね

“ハラスメントにならない、部下への厳しいフィードバックの伝…”
htn.to/4a15YCUboK