mono(0w0)ログ

読んで、体験して、自分でやってみた記録

Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD! コラボカンファレンス に参加した

現場でDDDを取り入れて2年くらいになるので半分答え合わせ、半分もっといい方法がないかなという期待で参加しました。

基調講演 ドメイン駆動設計という設計スタイル

www.slideshare.net

増田 亨さんの基調講演。 自分がDDDを始めるきっかけになった方ですし、始めた時もメンバーにこの本の通りに作るからといって始めたくらい密かにお世話になった方です。

設計スタイル

ドメインオブジェクトに振り切った設計というのが印象的でした。 増田さんの本を参考にDDDを始めて、最も効果が大きかったのがここに現れています。 入出力を切り離すことで得られる恩恵はとても大きい。 クラス数はとても多くなるけれども一つのクラスはとても小さい。 循環的複雑度も最大で10くらい(Checkstyleで縛りいれた)になっている。 一つで何やっているかはとても良くわかるけど、全体として何やっているかを理解するのはちょっと手間。

  • 関心の分離
  • モジュール構造
    • トランザクションドメインオブジェクト
    • 手間をかけるので無駄なことをやっていると思われる
    • 大きなメリットを得られることを強調
  • 20:80のとらえ方
    • ドメインロジックの設計が80%に影響する
    • ビジネスルールに登場する値・種類に注目
    • 現場で戦いが起きる。負け戦だけど

ドメインロジックにフォーカス

この章で印象に残ったのは、「ユーザーは詳細な仕様に関心がない」ということ。 「そのために詳細仕様を補完し提案する。ユーザーからフィードバックをもらう。」の部分では首肯しまくり。

ちょうど最近、メンバーがシステムの挙動についてユーザーにヒアリングする場面があり、それはユーザーに聞くのではなく、「この仕様でいきますが問題ありませんか」という提案型に変えようとアドバイスしたばかり。聞いても明確な答え得られないから。 他にも「ビジネスエキスパートから出てこないことが、契約書、利用規約、業務規約などから読み取れる。」などのノウハウも。

  • ドメインの知識を学び続ける
    • 要求の意味が理解できる
    • 関係性や構造が見えてくる
    • 詳細仕様の補完力と提案力が増す
    • 時間とともに変化し続ける
  • ドメイン知識のコード表現を継続的な改善
    • fact、rule、goal
    • 独自の型を定義
      • 構造と秩序、バグ減らす
      • 名前がコードの意図を表現
    • 可読性の向上とコードの追跡しやすさ向上は実感しやすい
  • ドメインロジック → ビジネスロジック
  • ドメイン知識 → ビジネスルール
  • 学び方

現場での結果と考察

ここも首肯しきり。 個人的な実感としては、長い間トランザクションスクリプトに馴染み切った人ほど脱却に時間がかかる。最初に躓く。 一方、若い人は素直に受け入れる。でも、その先に完全に思考を切り替えて定着させられる人はまた一部。 長いことやっているのでこのメリットをどれくらい感じているかメンバーに聞いてみようと思った。

  • 考えて書く人
    • 伝わる
    • 入出力フォーカス設計スタイルは個人差
  • 書かない人
    • 言葉では無理
    • 全員に伝えるのは無理く
    • 相手の見たいものを見せる
  • パッケージ構造に意識が向けられたらレベルアップの証拠

この辺が放置気味なので今後の課題。

DDDのモデリングとは何なのか、そしてどうコードに落とすのか

little-hands.hatenablog.com

松岡 幸一郎さん

モデリングとは

  • モデル:文脈によって異なる
  • DDD reference参考
  • ドメインモデル
    • 問題解決のためのモデル
  • データモデル
    • 永続化のためのモデル

どうやってモデリングするのか

little-hands.hatenablog.com 参考サイトにも記載されていますが、個人的に「ユースケース記述」と「ルール・制約(=ドメイン知識)」を併用する設計の仕方はうちのチームにマッチしそうな気がします。 重厚なドキュメントになりすぎず、設計を議論できるものが記載されているのが良さそう。もっと詳細化が必要であればクラス図やシーケンス図として表現したり、そのままコードに落とし込んだりできそう。

モデルからどうコードに落とすか

形から入るの推奨。僕も以下を参考にしました。 github.com

  • 形から入る
    • 1ユースケースのお手本を用意しておく
    • イメージできてから横展開が楽
  • データモデルっぽいやつからリファクタリングしていく
    • ルールはどこに実装しているか
    • アプリケーション層にあるロジックをドメイン層に移す
  • コーディング ⇄ モデリング

QA

ブログに質問への回答を記載されております。 参考になります。

  • ORMはテーブルと一対一でない方がオススメ
  • モデリング時間は1時間くらい
    • 短いサイクルで繰り返す
  • 実践DDDに集約とトランザクションは切り離せないとある
  • 制約とかルールが明確なら値オブジェクト。無理に作る必要はない派
  • アプリケーション層の入り口でトランザクションはる
  • ユースケースでの記述とルール・制約は分ける
  • エンティティからリポジトリは使用しない方が良い(アプリケーション層からにした方がいいんではないかな)

現場でドメイン駆動設計を広げるには何をすれば良いか?

安西 剛さん

インプット < アウトプット

参加者にアウトプットさせるようファシリテートをされていました。 隣の人と「なぜ今日来たか」「つらみの共有」「今後どうしたいか」などを短い時間(30秒程度)で共有しました。

DDDの広げ方

前半は経歴(つらみ)のリアルなお話があり、そこからタイトルの通り段階的に個人・仲間・組織へDDDを広めていくやり方について聞くことができました。 今の自分の課題は「本当に共感して仲間になってくれる人」を見つけてその人を中心にして「組織へ広げていく」ことと感じました。

  • 誰もやってない
    • 黙ってやる
    • プロダクトコードで練習
  • 自分はやっている
    • 仲間を選択する
      • 共感する人
      • 話せばわかる人
      • わからない人は巻き込まない
  • 複数人でやっている
    • 理解を広げる、深める
      • 勉強会
      • 上司を味方に
      • 有識者に教えを請う
  • チームでやっている
    • いきなり全体でなく、チームを広げる
      • チームをのれん分け
      • 失敗しても影響がないところから
      • 組織の2割を目指す
  • 大きな絵を描く(戦略を作る)
  • 整理整頓する
    • 分ける
    • 名前をつける
  • 世界地図からつくる
  • クラスを作る
  • やり方・あり方の両方を意識する
  • 戦略と実装を行ったり来たりする

抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート

www.slideshare.net

ほげさん

導入

  • 初学者に優しくない
  • フレーズに抵抗
  • 「君のドメイン層からは業務を感じない」

笑ってはいけないかと思うのですが、そのフレーズ最高でした。

試行錯誤

ほぼ独力で試行錯誤の軌跡がすごい。

印象に残ったアプローチが「インプット → メソッド名 → アウトプットを意地でも埋める(void消す)」というもの。 名詞=クラス、動詞=メソッド名とするのはロバストネス分析かな。この辺は一つのノウハウになりそうな感じ。

  • 名詞を探す
    • データの箱になる
  • ドメイン層に集める
    • テストが辛い
  • 動詞を探す(voidを消す)
    • イン → メソッド名 → アウト
    • 意地でも埋める
    • やっと絵がそれらしくなる(ここまでに2年から2年半くらいかかっている)
    • returnするクラスが必要だ

ブレイクスルーの先へ

  • ドメインか否かの境界」と「ドメインの中の境界」を探す
  • ドメイン境界を決める
    • 業務を変えてないのにドメイン層を変更してるのはおかしい
    • ドメインが知るドメインを減らす
    • 変わりやすい方に向かって線を引かない
      • 依存性逆転の原則
  • クラスとER図の関係
    • クラスの方が頻繁に変更される
    • データベースは変更されにくい

おまけと今後やりたいこと

  • テストコード不要論
  • エラー設計
    • ビジネスエラーとシステムエラーを分けたい
    • 本気で実行時例外をなくす

エラー設計については色々悩んだところであるのでぜひ最終結果を見てみたい。

過去の失敗例から再考するモデル駆動設計

かとじゅんさん

とにかく「値オブジェクトの設計に注力」「ドメインオブジェクトに凝集させる」のアプローチ

軽量DDDでつまづいた

この中で印象に残ったのは「ユビキタス言語にない実装都合の用語で作られたオブジェクト」です。 おるわーって思っていました。

あとはRDRAは積んでいるのでしっかり読めってことですね。

  • 通訳が必要になった
  • エンティティ=データ
  • トランザクションスクリプト亜種
  • ドメインモデル貧血症
  • ユビキタス言語にない実装都合の用語で作られたオブジェクト
  • RDRAで分析
  • 値オブジェクトに注力
  • 要件と行ったり来たり
  • 値オブジェクトで扱えた方が表現力あがる
  • ファーストコレクションで意図を表現する
  • スケーラブルな設計
    • ドメイン上の値はプリミティブでない
      • 値の範囲、ルール、計算能力を持つ
    • 値オブジェクトは不変にすること
      • 予測可能な設計を作り出せる

集約の境界定義に試行錯誤

  • 全部集約
    • ルールと振る舞いが分離
  • 集約を1つに
    • 説明が難しいモデル
      • 実装も大きくなる
      • I/Oコストも大きい

まとめ

  • PDR:Prep・Do・Review
  • 設計もFail Fast
  • コミュニティ活用

まとめ

  • 次やること
    • パッケージを意識する
    • ユースケース記述とドメイン知識(ルール・制約)の併記を試してみる
    • 「本当に共感して仲間になってくれる人」を見つけてその人を中心にして「組織へ広げていく」
    • RDRA読む
    • 「行ったり来たり」のサイクルを回す

子どものほめ方・叱り方を学ぶ

娘の幼稚園で日曜参観の後に講師の方をお招きして講演がありました。子育てに関わることで上手なほめ方・叱り方を教えていただきました。 正直、一緒に仕事する大人にも当てはまる、参考になるなあと思ったので記録しておきます。

講師は、女性ライフサイクル研究所 Felianの桑田 道子さん。

子どもは

  • たくさんのお世話と関心を必要とする
  • 好奇心が旺盛
  • できる以上のことに挑戦したがり失敗する
  • 何度も同じことを言ってきかせる必要がある
  • 子どもは自己主張をする

「子どもが子どもらしくあるだけで大人をイライラさせることはある」

人格の発達

エリクソンの発達段階。 小学校上がるまでに三段階、最終的に八段階の人格形成のステージがある。

  1. 基本的信頼
    • できたことを認める
    • アクナレッジ
  2. 自律性
    • 気持ちを受け止めて言葉にする
    • 感情と行動を区別する
    • 他者を認めつつ行動できるようになる
  3. 自発性

子どもの好奇心に全て完璧に答えないこと「なんで?」に対しては「なんでだと思う?」のように考えさせるように問い返すことも必要。

大人のすることは魅力的。能力の多寡は考えずにやりたい気持ちが湧く。

大人からすると同じことでも場面が違うと応用ができない。そのため何度同じことを言わせるの⁉︎となりやすい。

子供の自己主張を成長の階段を登る途中と考える。

上手な叱り方

「しつけ」とは「親の価値観を伝える」ことである。

大切な価値観と言われるとアジャイルマニフェストとかモダンアジャイルを思い浮かべてしまうw

  • みんなを喜ばす、尊重する
  • 安全であること、安全にすること
  • 挑戦・失敗・学習・再挑戦
  • 継続すること

自律性を育む

怒られるからダメという理解では、「他者コントロール」にとどまっている状態。

上手に自律性を身につけるために

  • 理由を尋ねる(問い詰め口調はNG)
  • 気持ちを受け止める
    • 子どもが気持ちを表現する機会
  • 行動の変化を促す
    • 次はどうできるかの相談
    • 注意したあとのフォロー

気持ちと行動の区別を教えることが自律性を育む

叱るコツ

  • 一度に1つだけ
  • 過去のことは持ち出さない
  • 行動について叱り、子ども自身を否定しない
  • 短く切り上げる
  • 「〜しない」よりも「〜する」言い方
  • 選択させる
  • たくさんほめる、すかさずほめる、うまく言っていることを見逃さない

まとめ

子育てには子育ての難しさが、エンジニアリングマネジメントにはエンジニアリングマネジメントの難しさがありますが、どちらも人に向きあってこそ成し得るものだなと再確認できた日でした。

やるべきことにフォーカスする エッセンシャル思考読んでみた

エッセンシャル思考 最少の時間で成果を最大にする

エッセンシャル思考 最少の時間で成果を最大にする

プロジェクトリーダーという役割柄、時間の使い方を見直す必要性は常々感じていました。 しかし、「時間が足りない」「分身できたらいいのに」という言い訳をしながら、力技で仕事を続けてしまう癖が抜けず、2015年から始まったプロジェクトで心身ともにかなりやられてしまいました。

2017年にアジャイルに触れてからは仕事だけでなく、家族との時間や個人的な時間の使い方も大切にしなければという思いが強くなってきたのもあり、「エッセンシャル思考」という言葉だけはどこかで聞いたことがあったので本を取ってみました。

一番刺さったのは、2章の 「選ぶ」ことを選ぶというもの。

こんな風に思える様になったのも、自分で選んだからだと感じています。

また、この本を読んでいる時にジャンプで見たハイキューの一コマもグッときました。

自分がコントロールできるものに集中することを意識することで日々の仕事への取り組み方が変わってきました。 やるべきことが無限に湧いてくる様に感じているかつての僕みたいな人に読んでもらいたいです。

以下、読書メモ。

エッセンシャル思考とは何か

1.エッセンシャル思考と非エッセンシャル思考

  • より少なく、より良く
  • 自分で優先順位を決めなければ、他人の言いなりになってしまう
  • 規律なき拡大は失敗への道
  • 最高の成果
    • 正しい理由(Why)
    • 正しいこと(What)
    • 正しい時期(When)

2.選択

  • 選ぶ力を取り戻す。
  • 「選ぶ」ことを選ぶ。
  • 選ぶ能力は誰にも奪えない。ただ、本人が手放してしまうだけだ。

3.ノイズ

  • 大多数のものは無価値である。
  • 80対20の法則(パレートの法則
  • 決定的に重要なことだけをとる。

4.トレードオフ

  • 何かを選ぶことは、何かを捨てること。
  • トレードオフから目を背けても、トレードオフから逃れることはできない。
  • 何を捨て、何をとり、全力を注ぐか。

見極める技術

5.孤独

  • 考えるためのスペース・余裕をつくる。
  • 集中するためには、集中せざるを得ない状況に自分を置くしかない。
  • 本を読む時間をつくる。

6.洞察

  • 情報の本質をつかみとる。
  • ノイズの中のシグナルを探す。
  • 語られないことに耳を傾ける。
  • ジャーナリストの目
    • 日記をつける
    • 現場を見る
    • 普通を知り、逸脱を探す
    • 問題を明確にする

7.遊び

  • 内なる子供の声を聴く。遊びが不可欠・重要だと知る。
  • 遊びが大切な理由
    • 選択肢を広げてくれる
    • ストレスを軽減してくれる
    • 脳の高度な機能を活性化する
  • 遊びは本質を探求するのに役立つだけでなく、それ自体がどこまでも本質的である。

8.睡眠

  • 1時間の眠りが数時間分の成果を生む。
  • 自分自身という資産を守る。
  • 現在人の最優先課題は、優先順位づけの能力をキープすることだ。
  • 睡眠がそれを可能にする。

9.選抜

  • 最も厳しい基準で決める。
  • 90点ルールによって上位10%にだけイエスと言う。
  • 絶対にイエスだと言いきれないなら、それはすなわちノーである。

捨てる技術

10.目標

  • 最終形を明確にする。
  • 意味があり、心に残る本質目標。
  • 本質を見据えて生きる。

11.拒否

  • 断固として上手に断る。
  • 上手にノーという技術
    • 判断を関係性から切り離す
    • 直接的でない表現
    • トレードオフに目を向ける
    • 好印象よりも敬意を手に入れる
    • 曖昧なイエスはただの迷惑
    • エスということを焦るな、ノーということを渋るな
  • 断り方のレパートリー
    • とりあえず黙る
    • 代替案を出す
    • 予定を確認して折り返します
    • 自動返信メール
    • どの仕事を後回しにしますか
    • 冗談めかして断る
    • 肯定を使って否定する
    • 別の人を紹介する

12.キャンセル

  • 過去の損失を切り捨てる。
  • もしまだ投資していないとしたら、今この企画に投資するだろうか?
  • 途中で辞めることは難しい
    • 授かり効果(所有することで価値が上がると感じる心理的バイアス)
  • もったいないを克服する。
  • 逆プロトタイプ(やめてみたときの影響を検証する)

13.編集

  • 余剰を削り、本質を取り出す。
  • 編集の4原則
    • 削除する
    • 凝縮する
    • 修正する
    • 抑制する(手を出しすぎない)

14.線引

  • 境界を決めると自由になれる。
  • 境界を決めることで本当の力が発揮できる。
  • ノーと言わなくても良いようにあらかじめルールを設定する。

しくみ化の技術

15.バッファ

  • 最悪の事態を想定する。
  • 準備と計画に全力を注ぐ。
  • 見積もりは1.5倍で考える
  • リスクマネジメント戦略
    1. どのようなリスクがあるか?
    2. 最悪の場合、どのようなことになりうるか?
    3. 周囲の人への影響はどのようなものがあるか?
    4. そのリスクは自分(会社)にとってどの程度の経済的負担となるか?
    5. リスク軽減のために、どのような投資を行うべきか?
  • リスク軽減のための投資=バッファ

16.削減

  • 本当の障害(ボトルネック)を取り除く。
  • 仕事を減らし、成果を増やす。
  • 3つのコツ
    • 目指すことを明確にする
    • ボトルネックを特定する
    • 邪魔なものを取り除く

17.前進

  • 感情・モチベーション・認知を高める要素の中で最も重要なのは「進歩している手応え」である。
  • 「終わらせること」を始める。最小限の進歩を積み重ねる。
  • 「早く小さく」始める。
  • 進歩を目に見える形にする。

18.習慣

  • 本質的な行動を無意識化する。
  • 正しい習慣を通じて自然に達成する。
  • 重要なことをやるのが普通の状態。
  • 悪い癖を正しい習慣に変える方法
    • 行動を引き起こすトリガーを知る
    • 新しいトリガーを作る
    • 難しいことから手をつける
    • 曜日ごとにやることを変える
    • 習慣づくりはひとつずつ

19.集中

  • 「今、何が重要か」を考える
  • 集中の対象をひとつに決める
  • 未来を頭の中に抱えない
  • 優先順位をつける
  • マインドフルネス
  • タスクフォーカス
    • 自分がコントロールできるのは、自分の思考と行動だけ
    • 重要なのは常に「次自分にできる事とすべき事」

20.未来

  • 自分の中心にエッセンシャル思考を据える
  • 考え方が心の底までしみこんだとき、それは自分を内側から変える力となる
  • 本質を知り、本質を生きる
    • 迷わない
    • 流されない
    • 日々が楽しくなる

21.エッセンシャル思考のリーダーシップ

  • 少数のことをより良くやる
  • 正しい情報を正しい人に正しいタイミングで伝える
  • 意思決定のスピードと質を追求する
項目 エッセンシャル思考
方針 より少なく、より良く
人材 選別にこだわり、邪魔な人材は排除
戦略 何かひとつだけしかできないときに何をするか
タスク分担 メンバー特性と目標に適材適所
コミュニケーション 耳を傾け、本質を見抜く
部下育成 小さな進捗を重ねているか適切にチェック
成果 チームがまとまり、決めた方向で飛躍的な成果を上げる

自分の強みを活かすためにストレングス・ファインダーやってみた

職務経歴書やリーダー・マネジャーの自己開示資料に自分の強みや嗜好(指向?)みたいなものを書いておこうと考えていたのでやってみました。

結果は以下の5つ。

  1. 収集心:「戦略的思考力」
  2. 学習欲:「戦略的思考力」
  3. 達成欲:「実行力」
  4. 個別化:「人間関係構築力」
  5. 分析思考:「戦略的思考力」

思いのほかズバリと自分の傾向を言葉にして表現されて驚いた。 強みとして表明しやすくなるし、傾向を知ることで注意する点もわかって良い。 戦略的思考力が多いのでそういう役割とか向いてるのかも。

  • 情報やデータを重視し、収集・分析によって戦略を立て論理的・現実的な方法で問題・課題を解決に導きます。
  • メンバーの強みを活かし、チームや組織をつくり育てることで成果を出すことができます。
  • 継続的な学習を重視し、個人やチームの成長を促進し、組織を安定させること、拡大することに貢献できます。

わあ、優秀な人っぽいwww

以下、分析内容と感想メモ。

収集心

あなたは何らかの特定のグループ内で最も賢い人または最も博識な人として高く評価されたいと思っているかもしれません。

承認欲求が強い、かつ、他者と比較した評価に陥りやすいのは注意しておかないと病みやすい。自己肯定感を強めていきたい。

あなたは、 良質な本を読んだり、記事に夢中になったり、インターネットで情報を集めたりすることにより、日常生活の緊張、圧力、ストレスなどから逃避することができます。

ストレスが高まると漫画や小説を読む量が増えていた気はする。

生まれながらにして、あなたは、 物事を自分のペースでやるのが好きです。

嫁によく言われる。計画外や予想外のことを嫌う。

学習欲

あなたは学ぶことが大好きです。

最近、特にそう感じる。

自分に知る権利がある、あるいは知る必要があると思っていることを他の人があなたに伝え忘れたり、伝えることを拒否したりすると、動揺することがあります。

期待値のすり合わせが必要なんだろうなと思っています。役割に応じた責務と権限をきちんと整理したい派。自分がそうされたいので部下にもそう接していこう。

あなたの活発な精神は、毎日同じことを同じように行っているとうんざりしてくるのでしょう。

ルーチンワークは苦手。アイテム収集のため同じルートをひたすら周回するのに耐えられない。でも、程度によるかも。

グループの一員として仕事をすることを好みます。 興味のある活動や挑戦を行っているチームに惹かれます。

1人で黙々はあんまりやらない。同志がいると張り切る。外に目を向ける、人から学ぶことは大切。これを理解するまでにだいぶ時間かかったな。

達成欲

あなたは、 通常、自分自身を実務的で現実的であると考えています。

理想があって現実的な方法で解決したい。

あなたは、 所属しているチーム、クラス、またはワークグループが目標に到達するために長時間働くという評判を得ているでしょう。

長時間労働はやめたい。短い時間で確かな成果を出せるようにしたい。

どんなに今日は休もうと思っていたとしても、何も達成することなくその日が過ぎてしまうと、あなたにはわずかにでも満たされない思いが残るでしょう。 〜 達成欲の旺盛なあなたは、このわずかに満たされない気持ちとうまくつきあっていけるようにしなければなりません。

納得せざるを得ない。 小さな達成感を多頻度に得られるようにハードルを下げて習慣化するところからやろう。

あなたは職場のペースメーカーとなり、生産性のレベルを上げることができます。

やります。

個別化

あなたは、 困っている人を支援することで、大きな喜びを得ます。

そんな役割や組織で働きたいと強く思うようになった。

あなたはほかの人の強みをとても鋭く観察する人なので、ひとりひとりの最もよいところを引き出すことができます。

なかなか自分では自覚できない。メンバーの評価の時にその手の感想を言われたことがあったけど本人は全然わからない。雰囲気でやっている。

あなたは優秀なチーム作りの秘訣は、各自が得意なことを充分に発揮できるような、強みに基づく配役である、ということを本能的に知っています。

本能的に知っていたら過去の失敗はなかったかもねー。失敗したから本気で考える様になったのだけど。 ともあれ、やりたいことと強みが一致しているのは嬉しい。

分析思考

あなたは、 グループの計画に論理的な視点をもたらします。

ロジカルであることは重要だし好きですが、最近は感覚的なところもあるかな。

多くの場合、あなたは、 勝敗を決める何らかの特定の状況に対して、実践的で現実的な方法を取るようです。

実践的・現実的がまた出てきたので、絵に描いた餅は嫌いなんだろうな。形からでも役に立つHowに飛びつきやすい。

あなたは必ずしも他人のアイデアを壊したいわけではないのですが、彼らの理論が堅固であることを強く求めます。あなたは自分自身を、客観的で公平であると考えています。 あなたの分析結果を伝える時、できれば決して厳し過ぎないようにしましょう

新人の時に参加したプロジェクトの品質分析手法を徹底されていたので染み付いてしまってる感ある。強要されたことは他人に強要しやすいので気をつけよう。

あなたはデータを好みます。データは人々の考えに左右されず、ありのままだからです。

事象と推測と意見は分けてくださいとはよく言う。

Mix Leap Study #40 - Spring BootベースのDDDサンプル徹底解説! に参加した

以下、当日とったメモ。整理しきれていないけどこのままだといつまでも書けないと思ったのでそのまま。自分用に残す。

Mix Leap Studyについて

  • 情報共有を定期的に行う場
  • Yahoo社員・社会人・学生の交流

プラットフォームとサービスを支える設計

思いやりのある命名をしよう

  • エヴァンス本:諦める
  • 実践ドメイン駆動設計:
  • 命名にどれだけ時間使いますか?
    • 自分の書いたコードを理解できるようにするため
    • 他の人(未来の自分も)がコードを理解できるようにするため
  • 良い命名:仕様のどの部分を表現しているかわかりやすい
  • 下地
    • よく使われる命名を覚える
    • ルールを決める
  • アンチパターンの場合は、Howを考えて直す
  • コードとの距離が遠くなれば情報の鮮度が落ちる
    • 伝える方法は目的に応じて選択する

DDDサンプルのお話

  • 作った理由:コードが一番具体的、質問も具体的になる
  • 核心にある複雑さに立ち向かう
  • 設計の大原則:関心の分離・モジュール構造の工夫
  • 3つのキーワード
  • 要点を絞り込む
    • ビジネスルール:データモデルで頑張ろうは書いてない(エヴァンス本)
    • 計算モデル:
    • 型指向のプログラミング:
  • 関心の分離の工夫
    • 計算(ビジネスルール)を実行するモジュール群
    • データを入出力するモジュール群
    • この2つを徹底的に分ける
  • モジュール構造の工夫
  • サンプルは給与計算アプリケーション
    • 給与:Payroll
  • ドメイン
    • ビジネスルールの3要素
      • Fact:事実の表現
      • Rule:計算式、判定式
      • Goal:計算結果や判定結果を表現する型
    • 設計とやり方
      • modelパッケージ:計算モデル
      • typeパッケージ:モデルを表現するための基本部品のライブラリ
      • 型指向のプログラミング
        • GithabのWikiに記載してます
        • ドメイン駆動設計本格入門
        • 増田さんの本
      • Plain Old Java
        • ビーンバリデーションのアノテーションは積極的に使う
        • privateは省略する(意見が分かれるところ)
        • ライブラリも意見が割れる箇所
    • Jig
      • 作り始めた時はどのパッケージから作り始めたのかな?
        • 事実が先かな。行ったり来たり★
      • パッケージ間の依存関係を見て不自然さのところを是正していく
      • enumを可視化している
      • コレクションオブジェクトからlistを取り出して実装しているのはなぜか?
        • contractとアテンダンスを依存させたくなかった★
  • アプリケーション層
    • ビジネスルールの記述を独立させる
    • 理論的にはアプリケーション層はシンプルになる
    • 現実は複雑な記述が残りやすい
    • 要素分解
      • Factoryサービス:計算モデルのインスタンスを生成する:データソース層で事実を元に生成
      • Queryサービス:計算結果を返す:プレゼンテーション層へ
      • Operationサービス:計算結果を記録/通知する:データソース層へ
    • 複合サービス(要素サービスをDI)→要素サービス(repositoryをDI)
      • 複合はcoordinator:repositoryは見ない
    • QA
      • repository:周辺
      • 色々なサービスを組み合わせないと実現できないので複合にしている。要素で満たせるのであればおk
      • ゴールが次のファクトになることもある
      • 本当はcoordinatorとかQueryとかつけたくないので
      • コンストラクタが1つであればアノテーションを書かなくてもSpringが勝手にDIしてくれる
        • コンストラクタインジェクション以外を使わないでね@irofさん
        • autowired使うとユニットテストができない
      • データソースで組み立てるパターン、サービス層で組み立てるパターン色々ある
        • ダッシュボードを組み立てるのであればプレゼンテーション層でやる方がいい時も
  • データソース層とデータベース
    • 計算モデルとデータモデルのマッピング
    • 事実としてどのように記録する ことと 事実をどのようにして計算する かはそんなにインピーダンスミスマッチ無いよ
    • SELECTの実行=計算用のオブジェクト生成
    • 記録すべき事実を持ったオブジェクト=INSERTの実行
    • RDBの設計は特定のアプリケーションから独立させる
    • イミュータブルデータモデル:事実の履歴+最新状態
    • UPDATEは使わない
    • 川島さんのスライド
    • 制約指向:NOT NULL制約、外部キー制約
    • DBに日本語命名が良い
      • Mybatisの実装でas句を記載するとresultMapタグがなくなる★
    • QA
      • coordinatorがまとめて取得してという性能
      • データベースの箇所には大量データとの戦いがある
      • 業務に本当に必要なのか考える
  • プレゼンテーション層
    • 計算モデルのビュー
    • Spring MVC
      • Direct Field Access:WebDataBinder#initDirectFieldAccess()
        • Mybatisがgetter/setterを要求することはない(Springだけかな?)
    • Thymleaf
      • ドメインオブジェクトをプレゼンテーション層から使う
      • ドメインオブジェくとの変更がプレゼンテーション層に影響を与えるのは計算モデルのビューという考えからいうと良い依存と考える
    • QA
      • ロバストネス的な考えて行ったらコントローラーでユースケースを実現している
      • アクターが異なるのであればアプリケーションごと変えることもやった
      • APIコンポーザー:クライアントからのリッチな要求に対応する。ドメインを変換する層

JIG(治具)

  • ドキュメントは一時的に見るだけ
  • コードの設計によるためのツール
    • 意図を込めてコードを書いて、意図が表現されたドキュメントを見る
    • 設計・コード・ドキュメントのサイクルを回す
      • ドキュメント生成ツールではない。設計補助ツール
    • Not UML
      • ビジネスルールが際立つもの
      • 意図を込めたところを読み取る
    • 想定外の作りは歪に見えればいい
      • 見えるだけ
      • 頭の中と実装の乖離を可視化する
    • コードの理解をモデリングできれば
      • 分析設計ドキュメント

Scrum Fest Osaka 2019 2日目

とても素晴らしいフェスでした。 一夜明けても余韻が抜けません。 スピーカー、スポンサー、スタッフ、参加者、関わった皆さんに感謝したい。

Keynote

  • 基調『公』演 元気担当:及部さん、勇気担当:きょんさん
  • オープニングムービー、BGM生演奏、スピーカー登場時の演出あり、アンコールあり、エンドロールあり
    • きょんさんの登場時にTank!が流れたときはテンション上がった!
  • 頭おかしい(褒め言葉)
  • お二人の苦労と失敗のお話

元気担当:およべさん

普段登壇者が話さない氷山の下側のお話。 キラキラした部分を支えてきたのは行動の継続。カンバンを破壊されても一人カンバンを続けたり。 変えるのは他人ではなく自分自身。

このあたり昨年少しだけ読んだ「7つの習慣」に書かれている『インサイド・アウト』と同じだなーと感じました。 メンタルモデルを整えていくのはなかなか難しそうですが、同じ想いを持つチームでそれを実現できそうなイメージがします。 まさに「アンパンマンは、きみさ。」

勇気担当:きょんさん

今では想像できない残業まみれのきょんさんのお話。不確実性バー(太い)には笑いました。 諦めの蔓延は、僕にも経験があってあんまり積極的に諦めている認識はなく、只々それが普通のことになってしまっている状態かと思います。まずはそれが普通ではないことに気づくことが大切で、「前より全然良いじゃん!」ってとっても大切だなあと思います。

参加者へ「誰のために、何のために、どのようなチームで何をなすのか?」の問いかけがありました。 その場ではなんとか答えましたが、自分では答えることはできてもチームがそれに答えることができるのか?同じ想いを持てているのか?をふりかえるきっかけになった問いです。

最終的に変わったのは運命でなく自分自身というところが、およべさんのスライドと共通するところかなと感じました。 「なんのために生まれて なにをして生きるのか」

キーノートのタイトルは?

参加者が公演のタイトルを自由に決めて欲しいということで選んだのがこちら。

変わるのは自分自身だけど、チームに助けてもらっても良いじゃない。ジャムおじさんを探そう!

ランチタイム

美味しい!

会社組織を丸ごと心理的安全漬けにする方法

Tigerspike 根岸さんのお話。「カルチャードリブンな組織づくり」というテーマでした。 とても濃い内容で素晴らしかった。

WEDI

  • Wholeness:全体性
  • Environment:環境
  • Ddiversity:多様性
  • Issue Driven:イシュー中心

一番心に残ったのは、「戦略はカルチャーに食われる」というもの。 カルチャーを根づかせるためには、戦略よりも中心にカルチャーをおいて、投資と仕組みが必要。

スクラムチームは改善する問題を正しく選んでいますか?

www.ryuzee.com

儲けるために、成果にフォーカスする。

3つの要素すべて考える。いまどこに着目するのか? バランスをとる。

身も蓋もないお話ですが、やるんだよ!ってことですね。考えよう。

プロダクトマネージャーは、エンジニアリングマネージャーになれるのか

www.slideshare.net

エンジニア経験がないことが逆にメリットとなったことについてお話がありました。 エンジニアからの「なんでこうなっているの?」とエンジニア経験のないプロダクトマネージャーからの「なんでこうなっているの?」は違うと。 確かにw 言い方も良くないのかもしれませんが、チームメンバーが萎縮してるときあるわー。気をつけよ。

スクラムフレームワークを使用する具体的な方法。僕の場合。

bufferings.hatenablog.com

スライドの説明記事が公開されていました。

開発を進めるときのコアになる3つのマネージャーロール。

自分のチームをふりかえってみるとやっぱりロールをきちんと分ける必要があるなぁと痛感しました。 PJMに関するところは、ある程度分担できているけど僕一人でほぼ全部やってるんだもんなー。

まとめ

今日はずっとこんな感じです。

Scrum Fest Osaka 2019 1日目

参加しました。1日目で学んだことを活かして、なるべく時間かけずに気持ちを吐き出しておきます。 2日目になっちゃいましたけど。

アジャイルやりたい!」って言うてるニワカ(おっさん)が足掻いた結果

  • みうらさんとバックボーンが重なる部分が多いのでシンパシーを感じる
    • 僕もアジャイルに触れたのは36歳の時
    • トラディショナルな開発を経験してる

お堅い企業でスクラムチーム

  • 後でお話を聞いたらスピーカーの上司にあたる人がスクラム導入を推進していたそうです
  • 大企業から事例が出てくるのはとても良い
    • お世話になっています

"評価の魅せ方" 駆け出しマネージャー風 少し斜に構えて

  • 自分のチームで評価おざなりだったのは反省
  • ちゃんと評価されたいし、評価してあげたい
  • 成長のための評価と報酬のための評価を分けて考えよう

コミュ障仕事術 - Customer Interaction Patterns から学ぼう -

  • 過去を振り返るとできてなかったなーと思い当たることがいっぱい
    • すぐ返事する
    • できないと言う。ありのままを伝える
  • チームとしての信頼を貯める
    • POを助けたい。やっていき。

ラクティス厨から始めるアジャイル開発

2019/02/25 スライド追記

  • 原点ってツイートしてるけど原典でしたね
  • セッションに引き込まれる。凄い!
  • 個人的1日目ベストスピーカー

感謝のKPT 5000枚 -基盤チームのレトロスペクティブ-

完全にコレ

  • でも、なんかやれそう
  • 気持ちを吐き出す

説教「お前のそれ、スクラムじゃないから」

  • 描いたやつツイートするか悩んだけどやってよかった
  • 返信もらえて壁打ちしながら考察できた
  • 理想と現実のギャップを捉える
  • スクラムフレームワークに沿って何を大切にして、どうやって、何をなすのかを構築していく感じ
  • 深い

Networking Party!!!

  • 昨年のScrum Boot Camp OSAKAの同期に会えた
  • スピーカーの方にもお話伺えたり、感想を伝えたりできたのは良かった

まとめ

さあ、今から2日目。楽しみー。