ばやしのブログ

アジャイルとかやる中で考えていることを書きます

しいたけさんの推進力が凄いから解説したい

うちのチームにはしいたけさんという人がいます。最近しいたけさんがチーム内でのチケット管理方法の改善を推進してくれたのですが、そこでの推進力が凄いので、私が観察したしいたけさんの圧倒的な推進力の秘密を解説します。(あくまで自分から見た面での解説です)


1. ずっとボールを持ち続ける

一般的には「ボールを持ち続ける」のは本人が動かないと物事が前に進まなくなるアンチパターンです。しかししいたけさんはボールを手放しません。大体の改善活動は、推進したいと思っている人以外はそもそも動かないので、ボールを持ち続けるのは全然悪いことじゃないなと感じました。

  • ゴールが決まるまで主体者を手放さない
  • 「何が次の一手か」を常に周囲に共有

ボールを手放さない(≒常に主体者である)ことで、どんどん改善活動が常に前進します。

ただしこれは後述する「反対意見や疑問が出たら誠実に対応する」行わない場合、独善的になってしまうので要注意です。


2. 最初に論点をまとめる

しいたけさんは物事を進める前に、興味や思いをある人を集めて、ショートMTGを開きます。ここで「みんな課題感持ってるよね?」「今それぞれが抱えている課題感はなにか?」あたりをざっと洗い出します。そして洗い出した後は、それを物事を前に進めていく中で解消していきます。ここで出た論点は、その後のTodoリストとして機能していて、なるほど論点をまとめることでその後の道筋が立てやすくなるんだなと学びました。


3. 宙に浮いたら前に進める

プロジェクトでは、優先度の違いやリソース不足でタスクが「宙に浮く」瞬間が必ず訪れます。

多くの人はここで 待ちに入りますが、しいたけさんは浮いたら動かすなーと思いました

  • 代替案を提案し、意思決定に加速
  • 必要なら自分で試作を作り、議論の材料を提示

改善活動が止まったなと思ったら、上記のような行動でどんどん前に進めていってます。

また、合意形成が必要なタイミングでSlackで「どう思います?」みたいなことを聞いても、全員が全員返事をしてくれるとは限らないですよね。忙しいから見逃しちゃったのか、単純に意見がないのか、言語化できないけどもやもやしてるのか、いろんな理由があるとは思いますが、返事が来ないことはよくあります。

こういう時しいたけさんは全員からの反応を待たずに進めてそうです(流石に誰からも反応が無い時はリマインドしてますけど)。これは物事が進まなくなるのを避ける良いムーブだなと思いました。またもやもやしている人も、進んでいる間に懸念を表明できるようになったり、ぼーっとしてる人も物事が前に進んでいく中で慌てだすので、実は反対意見を取りこぼすってのもないのかなとは思ってます。


4. 反対意見や疑問が出たら誠実に対応する

ここまでの記述で「しいたけさんワンマン感あるな」と感じたかもしれません。しかし実際に物事を前に進めている中でしいたけさんからワンマン感は感じませんでした。なんでだろうかと思うと、反対や疑問点が出てきた時は、きちんと時間をとって相対し、相手が納得できる状況になるまで話を進めているからかなと思いました。また反対意見や疑問を持つ人も、最初の論点をまとめる時に総論賛成はしてくれてたりするので、「一旦やってみて改善していきましょう」という結論になることが多いなと思いました。

ということで、しいたけさんの推進力解説でした。

私は「最初に論点をまとめる」とかは苦手なので真似していきたいと思います。

スクラムに入門したい方向けオススメ動画5選

どうも、ばやしです。

Scrum TokyoというYoutubeチャンネルではRegional Scrum Gaghering Tokyoをはじめとした様々なスクラムアジャイル、DevOpsのカンファレンスの講演動画が存在します(その数現時点で917本!)

www.youtube.com

あまりに多すぎるので、探す方も探しづらかろうということで、独断と偏見で動画をピックアップして紹介したいと思います。

今回はスクラム始めたばかりで、どうやったらうまくスクラムを実践できるんだろうと悩んでる方向けに動画を5つ紹介します。スクラムの単語は知っているくらいの方想定。

RyuzeeさんのDeep Diveシリーズ

初っ端から動画単体じゃなくてすみません。 日本に数人しかいない(あってる?)Certified Scrum TrainerであるRyuzeeさんがスクラムの各種イベントやアイテムを懇切丁寧に解説してくれてます。これが無料で見れて良いのか。 初心者向けと言いつつその網羅性と言語化力から、中上級者の方も学びが多い動画です。

youtu.be

youtu.be

youtu.be

youtu.be

アジャイルつまみ食いしたい人向けの「アジャイルから学べること(私が学んだこと)」〜アジャイルに興味をもってもらう方法を添えて

スクラム実践してるんだけど、言われた通りやってるだけになってる気がする」みたいな方にオススメです。アジャイルの考え方を平易に説明しながら、仕事に役立つ考え方に落とし込んでくれています。別にスクラムやってない方にも仕事のためになる考え方が学べるのでオススメです。つまり全人類にオススメ。

youtu.be

プロダクトゴールとは?あるいはプロダクトのゴールを設定するには何が必要か?

プロダクトゴール立てるの難しいですよね。立ててみたけどあんまりしっくり来ない、みたいな方も多いはず。 この動画ではプロダクトゴールの必要性、良いプロダクトゴールとはなにか、プロダクトゴールをどうやって立てるのかあたりが詳細かつわかりやすくまとめられています。

youtu.be

スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい5個のコツ -

スクラム始めるのって簡単ですよね。でもスクラムガイド読んで入門本一冊くらい読んで始めてみても中々上手くいかない。 そういう方向けに、スクラムが上手くいくコツを教えてくれています。 この動画を見てコツを実践することで、上手くいくかもしれませんし、上手くいかないかもしれません(当たり前)

youtu.be

形だけスクラムから熱いスクラムチームに変貌したきっかけは内発的動機づけだった

最後にご紹介するのはプラクティスや考え方を紹介する動画というよりは、マネーフォワードさんでの実例を紹介してくれている動画です。 なんやかんや試してみるけど、ふとしたきっかけで道を開けたりする、みたいなリアル感がいいなと思いご紹介です。

youtu.be

以上、スクラムに入門したい方向けオススメ動画5選でした。 Scrum TokyoのYoutubeチャンネルでは、今後もスクラムアジャイル、DevOpsのカンファレンスの講演動画が続々とアップロードされていく予定ですので、チャンネル登録よろしくお願いします(宣伝)

目指せ銀の盾

自分がレトロスペクティブで最初はKPTをやるけどそのうちやらなくなる理由

どうも、ばやしです。

先日@ryuzeeさんがこんな記事書いてましたね。

www.ryuzee.com

記事の内容に関して同意しかないので、自分も最初はKPTをやるけどそのうちやらなくなる理由を書いていきます。

なおレトロスペクティブの手法はファシリテーターの振る舞いで効果効能が変わると思うので、ここから書く話はあくまで自分がファシリをする場合の話です。本記事内で登場する「KPTは」という表現は「(私がファシリする)KPTは」の短縮表現なのでご承知おきのほどお願いします。

KPTから始める理由

わかりやすいから

シンプルでいいですよね。ルールも簡単でレトロスペクティブのファシリをしたことない方でも取っ付きやすいです。また業務改善感が強いのがウケが良い理由のひとつだと感じています。業務中のMTGなんだから、業務が改善されるようなMTGをしようよという心理的な圧は多少なりともありますよね。 チームの雰囲気や周囲からの見る目が変わってくると、端から見ると遊んでいるようなレトロスペクティブの手法でも問題はないのですが、そういう土壌がない状況だとちゃんと振り返ってちゃんと改善していこうという雰囲気が強いKPTは馴染みやすいです。

端的で効果が出やすいから

KPTの良いところは、Keepで自分が良いと思っていることを表明し、Problemで問題だと思っていることを表明し、Tryで改善案を考えることです。はい、ルール説明でした。

そもそもチームメンバと良いと思ってること、悪いと思っていることをみんなで話し合うことって普段しないですよね。そんな状況でKPTをやってみると、みんなが何を良いと思い何に不満を感じていたのかがすぐわかります。しかもこれまでレトロスペクティブ的な活動をしていなかったチームの場合「みんな不満に思っていて改善はすぐできるもの」がたくさん出てくることが多いです。すぐできるんで改善はどんどん進みます。そういった表出させるだけですぐ解決する問題に取り組むには最適なフレームワークです。

じゃあなんでこのKPTをそのうちやらなくなるかと言うと以下の通りです。

そのうちやらなくなる理由

すぐ解決できる問題にしか強くない

KPTは表面的な問題に言及することは得意ですが、課題の真因に迫るのは苦手です。 目に付くゴミ拾い的側面が強いなと感じています。目に付くし拾うだけで片付けられる課題の改善には効果的な一方、こびりついた汚れや基礎工事から必要な課題には無力です。例えば自分たちの目標に振り返ってそもそも今の自分たちが向いている方向性は間違ってるよね?みたいな話は出て来づらいイメージです。

Problemばかりに目がいきがちだから

KPTはKeepもProblemも両方出すので、フレームワークとしての問題ではないと思うのですが、大体どのチームでやってもProblemばかりに目がいきます。 悪いところを直す方がわかりやすいからですかね?理由ははっきりしないのですが、だいたいProblemばかりに目がいき自分たちは問題ばかりであるという雰囲気が蔓延します。ポジティブなチームのほうが生産性が高い的な話がどっかにありましたし(雑)、私自身もポジティブなチームで働いている方が楽しいので、KPTの多用は避けるようにしています。

レトロスペクティブの手法はたくさんあってそれぞれ色んな効果効能があるから

前述の通りKPTは目に付くゴミ拾い的改善に効果がある一方、チームの目標に立ち戻る、チームをポジティブにする、深く考えないとたどり着けない問題にアプローチする、などの効果効能は薄いです。 逆に言うと上記のような効果効能が見込めるレトロスペクティブの手法は世の中に存在しますし、それ以外の効果効能が見込めるものもあります。 例えば私はチームに目標に立ち戻ってほしいなと思うときは帆船のふりかえりをやります。このようにその時のチームに対して適用したい効果効能を踏まえてレトロスペクティブの手法を使い分けています。チームの状況に応じてレトロスペクティブの手法を使い分けることに関しては小田中さんの資料が詳しいです。

speakerdeck.com

自分たちのプロセスを自分たちでどんどん変更していってほしいから

レトロスペクティブでは自分達のプロセスを検査適応します。その検査適応のやり方自体も検査適応してほしいと思っています。レトロスペクティブのやり方を複数実践することで、レトロスペクティブ=KPTのマインドから脱却して欲しいですし、自分たちがコントロールして良い範囲をどんどん広くしていってほしいという思いがあります。

というわけで自分が最初はKPTをやるけどそのうちやらなくなる理由でした。

最初にも書きましたが、ファシリによって出てくる内容は違うので今回の話はあくまで私がファシリするKPTの話であることをご留意ください。

あと「KPTを続けたくないんだけど他の手法が怖くて...」という方向けにKPTの次にやるレトロスペクティブの手法でハードル低そうなやつを以下に挙げておきます。

増やすこと、減らすこと、止めること、続けること、始めること、の5つを出す。 KPTと構造が似てるからハードル低いけど、表現の違いによって出てくるもの全然違うことが学べると思います。

付箋に話したいこと書いてランダムに引いてその話する。ルールが非常にシンプルだからハードルは低い。あとこんな話する必要ある?みたいな話でも深掘るとめっちゃ面白いトピックになるみたいな経験ができる。

以上です。

2024年を振り返る

どうも、ばやしです。

今年も振り返り記事書いていきます。

子どもが生まれる

11月の下旬に息子が生まれました。待望の第一子です。

はい可愛い。

現在は育休をいただいており育児にフルコミットしています。 夫婦二人でフルコミットしているとはいえ、新生児の育児は超大変ですね。 二人でやってもこんなに大変なのでこりゃあワンオペ育児はつらいよねという気持ちになりました。

まぁでもそれを補ってあまり得るわが子の可愛さよ。自分のお気に入りの時間はミルクを飲ませたあとゲップさせるために縦抱っこをしている時間です。

育休をいただく

3ヶ月ほど育休をいただいております。 男性が3ヶ月も育休とるって世間的にはあんまり一般的じゃない気もするのですが、弊社は男性で育休を取るのが当たり前な雰囲気があり、私もありがたく取得させてもらいました。 上述の通り、新生児の育児は超大変なので奥さんの負担を軽減できて良かったというのと、あと育休取ると育児スキル獲得のスタートダッシュに失敗しなくて良いなと思いました。

夫婦ともに子育て経験がないので、最初の何もわからん状態で学習しながら子育てスキルを得ていくフェーズを夫婦二人で経験できています。 これが里帰り出産などになると、最初のスキルを得ていくフェーズを片方一人で過ごし、実家から返ってくるタイミングでは、スキルめっちゃある片方 and 経験値0のもう片方みたいな構図が生まれてしまいそうです。

この構図に陥った場合、この構図を理解し、スキルがある人がない側にオンボーディングなどを実施すれば良さそうですが、大事な赤ちゃんの世話なので失敗もそんな許容できないだろうし、そもそも余裕もないだろうし、結果として育児は奥さんがやるものみたいな構図が生まれそうです。そうなると片方は育児の負担が全部行ってしんどいし、もう片方はスキルがなくて育児怖いしで、お互い不幸になりそうですね。

こういう構図が生まれ得ることを育休取る前はあんまりわかってなかったのですが、結果として回避できて良かったなという感想です。

引っ越しをする

前まで東京の山手線沿いに住んでいたのですが、フルリモートだし子供も生まれるしというところでお家賃の低めな埼玉県の都市に引っ越しました。駅前もそれなりに繁華で国道沿いにいろんな店がある感じ、大学の時に住んでいた長野市を思い出して「俺が求めていた丁度よい繁華な街とはこれだったのかもしれない」と認識しました。

埼玉に引っ越したことで埼玉県民の県民性を肌で感じたり新鮮な日々を送っています。

埼玉に住んでわかったことは、翔んで埼玉は、翔んで千葉でも翔んで神奈川でもなく翔んで埼玉なんだよなという気持ち

— ばやし (@bayashimura.bsky.social) 2024年12月23日 20:25

車を買う

埼玉に引っ越したし子供も生まれるしということで車を購入しました。大学生の頃に教習所で免許を取得してから、ほとんど運転せずペーパードライバーとしてキャリアを積んできました。運転怖すぎて自動運転が普及するまで逃げ切る予定だったのですが残念ながら逃げ切れませんでした。

自分が下手くそであることを理解して

  • 小回りが聞くよう車体は小さめ
  • 安全装備がついてる
  • ぶつけてもショックが少ないように価格帯は低め
  • 子どもを乗り降りさせるだろうし電動スライドドアはほしい

みたいなことを考えていったら中古のNBOXになりました。 一番売れてるってことは一番良いってことだろう?(素人考え)

最近は車で角上魚類に行ってカニ仕入れたり、コストコに行ってカニ仕入れたりしています。

車好きの人にNBOX買いましたというと「賢い選択だね」という褒められてるんだか失望されてるんだかわからない反応をいただくというのが学びです。

仕事

去年と変わらずLinc'well株式会社で働いております。 入社して一年ほど経ちましたが、入社したときと気持ち変わらず楽しく働けております。 オンライン診療事業を支えるプロダクトを開発するチームのチームリーダーみたいなポジションで頑張ってました。これまで自分が関わってきたプロダクトの中ではコードの規模も事業規模も桁違いに大きく、多数のステークホルダーに向き合いつつ自走するチームを作るのは中々難しいところもありましたが、割とうまくいったような気がしています。 一定のレベルでの安定状態までは持っていけたので、ここからさらにグレートなチームになるために色々やりたいなーと思っていたのですが、今は子育てを頑張ります。 育休から戻ったら色々やっていきます。

登壇

今年はスクラムフェス大阪とXP祭りで登壇しました。

speakerdeck.com

speakerdeck.com

XP祭りの方の資料はありがたいことに多くの人に見ていただけたみたいで、驕るわけではないのですが、自分の発表はそれなりに多くの人に読まれ得るものなのだなという気持ちになりました。 個人として有名人になりたいわけじゃないのですが、自分の知名度が上がることで会社の採用に効いたら嬉しいなという気持ちがある一方、生半可なこと書くと怖いことなりそうだなという気持ちもあります。 まぁ気にしすぎず、ただ色んな人が見る可能性があるということは忘れずにやっていきます。

以上2024年の振り返りでした。

スクラムフェス大阪2024のサテライト情報まとめ

上記ポストを見てスクラムフェス大阪2024のサテライト情報が静的な場所にまとまっているといいなと思ったのでまとめておきます(情報入り次第随時アップデート予定)

www.scrumosaka.org

ちなみに私も品川葛飾連合として大崎でサテライトやるのでみんな来てね。

品川/葛飾

場所: 品川産業支援交流施設 SHIP

URL: https://connpass.com/event/321514/

福岡

場所: GROWTH 1

URL: https://fukuoka-scrum.connpass.com/event/319581/

神奈川

場所: NE株式会社

URL: https://agile-kng.connpass.com/event/319649/

仙台

場所: トークネットホール仙台(仙台市民会館)

URL: https://suku3rum-sendai.connpass.com/event/320275/

備考: 「会議室2つ予約しているので現地で登壇できるようにする予定です。」とのことです。

Women in Agile Osaka

場所: 大阪の会場近隣

URL: https://wiaj.connpass.com/event/320665/

備考: 「大阪の会場近隣にもサテライト会場用意してまして、Women in Agile Osaka 参加者の方が入れるようにしたいと思います。Women in Agile Osaka はスクフェスの初日の昼にOSTしますー。」とのことです。

虎ノ門

場所: 虎ノ門ヒルズビジネスタワー

URL: https://ksg.connpass.com/event/317250/

三河

場所: CTC豊田オフィス

URL: https://connpass.com/event/320986/

栃木

場所:
 Day1:USSクリエイティブステーション宇都宮
 Day2:マロニエプラザ(宇都宮産業展示館)大会議室

URL:(サテライト個別の参加登録はやらないのでありません)

鹿児島

場所:リコーITソリューションズ株式会社 鹿児島事業所

URL:
 Day 1:https://kagoshima-scrum.connpass.com/event/321410/
 Day2:https://kagoshima-scrum.connpass.com/event/322022/

盛岡

場所:岩手県民情報交流センター(アイーナ) 7階 岩手県立大学アイーナキャンパス PC演習室

URL:https://morioka-scrum.connpass.com/event/321644/

スクフェス福岡2024に行ってきたよ

どうも、ばやしです。 表題の通りスクフェス福岡2024に行ってきたので感想を書きます

Growth 1がとても良い

今年は去年のesports Challenger's Parkから代わりGROWTH1という会場になりました。

www.fukuoka-fg.com

2階、3階でそれぞれトラックが行える丁度良い大きさの会場でした。

私は主に3階にいたのですが、3階に併設されていたバーカウンターがとても気に入りました。

せっかくなのでBar yashiというバーを開きまして、疲れたたがみさんにウーロン茶を出したり、えーちゃんの人生観を聞いたり、ひろみつさんの発表に出てこない話を聞いたりとバーテンダー役得の時間が過ごせました。 バーテンダーをやって思ったのですが、自分のオススメの酒や飯を他人に振る舞うことが好きかもしれない。

おおひらさんアクリルスタンド

おおひらさんのアクリルスタンドがとても活躍していましたね。 おおひらさんにイカを食べさせたり、おおひらさんと旅をしたりと面白くて微笑ましくてちょっぴり不気味な写真がXやDiscordに多数投稿されてふふっとなりました。 私が撮ったおおひらさん。

Discordでオンライン飲み会をしているおおひらさんに対して、おおひらさんアクリルスタンドを使って猫ミームをしたのは今思い出してもくすっとなります。 こんなにみんなにおもちゃにされながら、しょうがねぇなぁと笑うおおひらさんの懐の深さが際立つおおひらさんアクリルスタンド化でしたね。

見た発表

スクフェスの学びにチームを惹き込め! 社内同時視聴会のすゝめ! speakerdeck.com

スクフェスで得た熱量をそのまま社内に持ち込んで辛い気持ちになった人は多いと思います。 しかも行動力のある人ほどそういう経験があるんじゃないかなと。 多分えーちゃんもそういう失敗を経験しつつ、それでも続けた上で社内をちょっとずつ巻き込んでいってる様子が伺えていい話だなーと思いました。

スクラムマスター不在でスクラムをやるのは(とても辛いので)やめておけ! speakerdeck.com

まずはナカミチさん発表上手いな!という感想。発表資料が華美で引き込まれる感じですよね。 内容的にはあるよなーあるある。という気持ちになりました。 果たしてスクラムというフレームワークに沿うことが良いことなのかなーとこういう系の発表を見ると思います。

『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜 speakerdeck.com

LeanとDevOpsの科学は読んだはずですが、もうFour Keysに興味なくなってるんか〜とか、コンフリクトする指標を組み込むことでFour Keysはグッドハートの法則に対抗していると思ってたけどやっぱ難しかったか〜という発見がありました。 bonotakeさんの発表は論文を当たって、それを論文を読まない人にもわかりやすく解説してくれるから好きです(告白)。

変化を巻き起こせ!「とある情シス子会社」で非公式ボトムアップのコミュニティを起点に共鳴する3人のストーリー confengine.com

そんな大したことやれてないんですよ、みたいな語り口でいやなんやそれ凄いなというエピソードがちょこちょこ出てくる発表でした。 今いるこの会社、もうちょっと良い感じになるといいけど、でもやっぱり好きだから転職っていうよりは非公式社内コミュニティで盛り上げていきたい、そのために色んな手打ってやっていくぞーという行動が素敵。 あとRSGTの時に聞けなかったtakaradaさんがメガテン好きかどうかが聞けたので良かったです。

組織変革の波に飲まれながら「何も分からん」期をちょっとだけ脱出したスクラム初心者の2年間 confengine.com

謎のAさんにサポートされてた時はスクラムを理解したと思ったら、自分がリードする立場になったらスクラム理解できてなかった話。 ボビンの論文じゃん。初学者の方が色んなとこに飛び込んで学びを得ていく話は何回聞いても良いですね。Aさんが一体誰だったのかが最後まで謎だったのも興味をそそられました(すっとぼけ)

小さな布石を置きつづける長期戦アジャイルはありうるのか? confengine.com

今更タイトル確認したけど「ありうるのか?」ってありえないと思っている人あそこにいなかったでしょ。大きな組織のカルチャーを変えていくって相当時間かかるし大変だからちょっとずつやっていかないとね、短期的な成果だけじゃなくて長期にも目を向けて、いつ効くかわからないちょっとした布石をめげずにどんどん置いていくんだよ、という内容でした。 実践者の頭取もちんもさんも話を聞いてて、良い意味で浮世離れしてるな〜と思いました。目先の利益とかにはあまりこだわらないけど、ちゃんとステークホルダーへの面通しをして、いざという時に話ができる状況にしてるところとかみんな憧れ凄腕サラリーマンって感じですね。昔のビッグコミックスピリッツに出てきそう。「そんな簡単に上手くいくわけないんだから期待なんかしてないですよ」的なことを頭取が言ってたのが印象的でした。

あとは当日はスタッフ業務の都合上見られなかったのですが、みつかわさんやひろみつさんの発表は是非見たいと思っているので、どっかで時間作ってみようっと。

以上、スクラムフェス福岡2024感想でした。

ドメインモデリングとマイクロサービスの研修に参加してきたよ

どうも、ばやしです。

2/27に行われたJoe Yoder : Domain modeling techniques for designing microservicesに参加してきたので、参加レポです。 なお私はDDDに詳しいわけでもなく、英語もおぼつかないので誤っている部分があるかもしれませんが、ご了承いただければと思います。

www.eventbrite.com

どんな研修だったの?

ドメインモデリングを中心にドメイン駆動設計(以下DDD)の概念を学びつつ、それがどうマイクロサービスに役立つのかを学ぶ研修でした。 具体的にピザ屋のシステムや、交通違反システムを例に挙げてDDDの概念を理解しつつ、ワークショップではクレジットカードシステムを題材にイベントストーミングやマイクロサービスアーキテクチャ設計などを行いました。

全編英語だったのですが

  1. 英語で講義
  2. 日本人同士で日本語でワークショップ

を繰り返すというスタイルであったり、講義資料が日本語に訳されていたりと、英語がそこまで得意ではない私でも割と理解できました。 また講師のJoe Yoderがめちゃめちゃ優しくて、自分の拙い英語を使っても大丈夫そうな雰囲気が全体的に漂っていてました。ほんと助かる。

具体的に研修の中で出てきたことは以下の通りです

一日の研修としては大ボリュームですね。 英語のリスニングということもあり、研修参加者の多くは夕方には脳みそが悲鳴をあげていました。

講義で概念を学ぶ際に具体的な例が出てくるので「集約完全に理解した!」となり、その後のワークショップで「集約ってなんだ...なんもわからん...」ってなる理解のジェットコースターが楽しかったです。

以下印象的だった学びをつらつらと書いていきます。

DDDの目標は関係者達の共有されたメンタルモデルを作ることにある

Joe曰くドメインモデリングだけでは開発チームはドメインエキスパートの話す言葉をコードに翻訳するだけになります。そうではなく共有されたメンタルモデルがあって、それをドメインエキスパートも開発チームもステークホルダーも、そしてソースコードもそこを参照する形にするのがDDDの目標だそうです。

自分としてはこの説明はわかりやすく、だから一緒にイベントストーミングしたり同じユビキタス言語を作るんだね、と今までバラバラに認識していたDDDの構成要素が自分の中でつながった気がします。

ユビキタス言語はユニバーサル言語ではない

異なる境界づけられたコンテキストの中で、同じ単語が異なる意味で出てくることはおかしいことではありません。 あるサブドメインで出てくる◯◯という単語と他のサブドメインで出てくる同じ〇〇という単語は、共通の属性を持つかも知れませんが異なる属性も持つでしょう。例えば顧客を考えます。注文のコンテキストと配送のコンテキストで顧客は違った属性を持ちます。こういった場合、コンテキストを横断した顧客というエンタープライズモデル(大きいモデルという意?)を作るのではなく、コンテキストが異なると属性が異なることを理解して、それぞれ独立した存在として定義します。

(今まとめていて思ったのだけど、コンテキストが異なって出てくる同じ単語にできるだけ違う名付けをした方が良かったりするのかな。例えば注文コンテキストの顧客に注文主って名付けるとか。いやでも同じ単語が使われていることで同じ存在であることも表せるからいいのかな。わからん)

マイクロサービスのガイドとなる原則 IDEALS

オブジェクト指向設計の5つの原則、SOLIDのようにマイクロサービスにも5つの原則があります。それがIDEALSです。

  • Interface segregation: インターフェイス分離
  • Deployability (is on you): デプロイ容易性
  • Event-driven: イベント駆動
  • Availability over consistency: 整合性よりも可用性
  • Loose coupling: 疎結合
  • Single responsibility: 単一責任

ググったらこんな記事も出てきたので参考までに置いておきます。 www.infoq.com

研修の中でマイクロサービスのアーキテクチャを考えるワークショップがあったのですが、自分たちが考えたアーキテクチャのどの部分がIDEALSのどれを満たしているかを質問されてあんまりIDEALSを意識して検討できていなかったことに気が付きました。今後実践する際には、この5つの原則を頭の片隅に入れながら検討すると良さそうです。

以上、Joe Yoder : Domain modeling techniques for designing microservices 研修参加レポでした。 実務ではDDDもマイクロサービスも遠い存在なのですが、研修の最後に言っていた「DDDを使用するかどうか、またはマイクロサービスを作成しているかどうかに関わらず、ビジネス機能またはドメインを中心にモデル化する、集約などの概念を使ってドメインをモデル化することは有用である」という言葉を胸に実践していければと思います。