正しくつくるための設計を学ぶ_中間報告

Slide 1

Slide 1 text

2020/02/26(水) #learning_lunch_lt Jun Nakajima 正しいものを正しくつくる塾中間報告LT

Slide 2

Slide 2 text

ͳ͔͡· 5XJUUFSɿ!KOVBOL@ ˔ ओʹখചܥγεςϜͷडୗ։ൃΛ΍͍ͬͯ·͢ ˔ ܦྺ ˓ ҩྍػث'4&ʢυϥΠόʔΛѲΔਓʣ ˓ ˠ4&4 $"41/&5ͱ&YDFMͰઃܭॻΛগʑ ˓ ˠϋϯζϥϘ #BTI ˙ ϞϒϓϩɺϞϒϫʔΫɺ5%%ɺ%%%͕޷͖ͳਓͰ͢ ˙ ීஈ͸डୗ։ൃͰ3%3"࢖༻ͯ͠ͷཁ݅ఆٛ΍ΒɺϞσϦϯά΍Β ௅ઓ͍ͯ͠·͢ 2 まずは自己紹介

Slide 3

Slide 3 text

● そもそも何で入塾したのか ● 正しいものを正しくつくるための設計とは ● 入出力と計算判断、意図と実装詳細を分ける ● 型で仕様(ビジネスルール)を表す ● バリューチェーン、競争地位戦略からの動機づけどんなこと話すか

Slide 4

Slide 4 text

正しいものを正しくつくる塾とは

Slide 5

Slide 5 text

● 市谷さん、増田さんが主催するソフトウェア開発を「正しく」作ることにフォーカスした塾 ● プロダクトの仮説検証と設計の2つのコースがある ● 今回私は、正しくつくるための設計を学ぶコースに入塾しています正しいものを正しくつくる塾とは

Slide 6

Slide 6 text

● 技術的にリードをすることが辛みを感じていたこと ● オブジェクト指向って？変更に強い良い設計とは？という自分なりの解をちゃんと確立させたかった ● 設計界隈で有名な増田さんに会って、色んな考えを聞いてみたかった会議室の予約・利用状況を確認するプロダクトそもそも何で入塾したのか

Slide 7

Slide 7 text

● 正しいソフトウェアを設計することをテーマに ○ なぜ、発展性に焦点を当てるのか ○ どうやって、設計をしていくのか ● というのを各々の開発経験と紐付けていき、形式知→ 内面化をすることをやっていく ● 各々が考え、答えを出し、研鑽をしていく ● 塾は考えるきっかけと場を貰っているに過ぎない会議室の予約・利用状況を確認するプロダクト塾のスタイルとしては、大学のゼミ方式

Slide 8

Slide 8 text

● 設計能力は暗黙知である ○ 世の中にある形式知はごく一部に過ぎない ○ それらも自身のプロダクトに完璧に適用できない ○ 人々の形式知から自身の経験(暗黙知)と結びつけ、言語化し、実践や他者からのFBを得て暗黙知にする ■ これが塾でやること会議室の予約・利用状況を確認するプロダクト塾のスタイルとしては、大学のゼミ方式

Slide 9

Slide 9 text

会議室の予約・利用状況を確認するプロダクト塾で使う参考書

Slide 10

Slide 10 text

会議室の予約・利用状況を確認するプロダクト塾で使う参考書発展性という共通点を探し出し、自身の開発経験と紐付けていく

Slide 11

Slide 11 text

● ラーニングパターン ○ 学び方を話すための共通言語 40パターン ○ 設計を創造的に学ぶために、これらのパターンを使う会議室の予約・利用状況を確認するプロダクト塾ではラーニングパターンをとても意識している

Slide 12

Slide 12 text

塾ではラーニングパターンをとても意識している自分自身は、ここを重視している ● 特に重要視されているパターン

Slide 13

Slide 13 text

第3回まで受講を終えたので、自身の経験と紐付けながら発表をします

Slide 14

Slide 14 text

正しいものを正しくつくる設計とは

Slide 15

Slide 15 text

「変更を楽で安全にする」こと

Slide 16

Slide 16 text

会議室の予約・利用状況を確認するプロダクト変更を楽で安全にする 28章発展性パースペクティブ ● ソフトウェアの品質特性の中で、発展性に注目する

Slide 17

Slide 17 text

● ソフトウェアの品質特性の中で、発展性に注目する会議室の予約・利用状況を確認するプロダクト変更を楽で安全にするここは一旦、考慮しない

Slide 18

Slide 18 text

会議室の予約・利用状況を確認するプロダクト発展性とはなにか

Slide 19

Slide 19 text

会議室の予約・利用状況を確認するプロダクト発展性とはなにか

Slide 20

Slide 20 text

● システムは変更がある事が、唯一の不変である ● 前向きな変更容易性(保守性は後ろ向きな変更容易性) ● ソフトウェアの中にある概念を意味のある単位に分けること ○ 意味のある単位というワードは、DDD8章〜10章の所々に出てきてるので、おそらくこの辺りが重要会議室の予約・利用状況を確認するプロダクト発展性とはなにか（自分自身の理解）

Slide 21

Slide 21 text

● 自転車を組み立てます ● 好きなネジ、ナット、ワッシャーを使って組み立てられます！ ● 何か追加機能あったら、１から組み立ててね！会議室の予約・利用状況を確認するプロダクト現時点での自分の中にある保守性のイメージ

Slide 22

Slide 22 text

● サドル、ペダル、ブレーキ…と意味のあるパーツ（単位）に分けられている ● それぞれのパーツには、何の為にあるか（責務や振る舞い）が明確である ● 速く走りたければ、軽いものに変える会議室の予約・利用状況を確認するプロダクト現時点での自分の中にある発展性のイメージ

Slide 23

Slide 23 text

会議室の予約・利用状況を確認するプロダクトソフトウェア開発で起きる諸問題

Slide 24

Slide 24 text

● SESの現場でよく経験した ● 基本的に機能ごとに人をアサインし、結果的に車輪の再発明がいたるところで起きる ● 人の出入りや要件変更の時に対応しきれずに終わる ● 要件変更は大体、ルールに基づく ● 人の出入りに対応する為に、設計書を残せと言われ、実装の翻訳的な設計書が量産され、辛くなる会議室の予約・利用状況を確認するプロダクト機能一覧を元にした手続き的なモジュール分割

Slide 25

Slide 25 text

会議室の予約・利用状況を確認するプロダクト機能一覧を元にした分割失敗のイメージ

Slide 26

Slide 26 text

会議室の予約・利用状況を確認するプロダクトルールに焦点を合わせた場合

Slide 27

Slide 27 text

● これもSESのg(ry ● Windows Formsで作られた社内マスタ画面とか、ほぼ画面とロジック密結合していて、辛かったよ… ● SQL ServerのConnection張るのベタ書きだったり ○ DBのテストとか辛いよ ● 何でもかんでも詰め込んだ神クラスとか ● 自身の設計に関する失敗については、下記も参照 https://speakerdeck.com/jnuank/moderingudeji-cun-sisutemufalseke-shi-hua-nilin-ndahua 会議室の予約・利用状況を確認するプロダクト関心の分離の失敗

Slide 28

Slide 28 text

● ユニケージ作法その三関数の使用は控えよ ○ 読みやすくする為に上から下に流れるコードを読ませる ○ →実装の詳細を使う側に読ませる時点で、意図と詳細が分離できていない ○ 意図と詳細を分離出来れば、呼び出し側は意図が明白なインターフェースを読むだけで済む ■ intやstringの内部実装は皆さん気にしないよね会議室の予約・利用状況を確認するプロダクト関心の分離の失敗(弊社ユニケージ製システムの場合)

Slide 29

Slide 29 text

会議室の予約・利用状況を確認するプロダクト関心の分離の失敗(弊社ユニケージ製システムの場合) indir=/INPUT; outdir=/OUTPUT today=$(date +%Y%m%d) yday=$(date +%Y%m%d -d"yesterday") # 本日までの実店舗・通販累積データの完成を待つ while sleep 60; do [ $today -lt $(date +%Y%m%d) ] && exit 1 [ ! -e REAL_URE_TOTAL.$today.sem ] && continue [ ! -e EC_URE_TOTAL.$today.sem ] && continue break done # 通販比率を計算する loopj num=1 $outdir/REAL_URE_TOTAL.$today ¥ $outdir/EC_URE_TOTAL.$today | # 1:品番 2:実店舗販売数 3:実店舗販売額 # # 4:通販販売数 5:通販販売額 # awk '{print $1,$2,$4,($4==0?0:$2/$4)}' | marume 4.2 ¥ > $outdir/URE_RATIO.$today # (出力:実店舗／通販比率) # 1:品番 2:実店舗販売数 3:通販販売数 4:実/通比率 ● 通販比率を計算するという意図が、コメントでしか表されていない ● 入出力が計算ロジックが密結合している ● 分離されてないと、テストがしづらい

Slide 30

Slide 30 text

関心の分離をする

Slide 31

Slide 31 text

会議室の予約・利用状況を確認するプロダクト関心の分離へのアプローチ

Slide 32

Slide 32 text

● 入出力（画面、DBなど）と計算・判断のロジックを分ける ● 意図と実装の詳細を分ける ○ 意図とは、アプリ独自の抽象データ型で表す ■ 金額型、数量型、業務日付型など ○ 実装の詳細は、組み込み型やライブラリを使った実装 ● LocalDate.now()は今日の日付を取得するの意図が明白 ○ 独自の抽象データ型でも、同じことをやる 4象限の関心の分離

Slide 33

Slide 33 text

● システム構成要素の責任を明確にする ○ ロジックの明確な置き場所を決めることにより、凝集性が高まってくる（ロジックの重複、断片化が減る） ○ 商品検索機能は、商品検索が責務と言うかもしれない ○ 商品検索は結果として実現する機能であり、それを構成するビジネスルール、入出力は別々の責務である ○ 入出力と密結合しているとテストがすごくしづらいなぜ分離をするのか

Slide 34

Slide 34 text

● 意図と実装の詳細の分離 ○ 入出力と計算・判断を分離できた場合、チーム開発であれば別々のエンジニアが担当することになる ○ 意図と実装の詳細が混在していると、コードの見通しが悪くなり、計算・判断のロジックを使う側は、どのように動くのか意図が分からず、コードを注意深く追わなければいけないなぜ分離をするのか

Slide 35

Slide 35 text

● 抽象データ型(ADT)＝クラス ● 例：金額型 ○ intなどで扱うとマイナスの数字まで扱えてしまう ○ マイナスを使わせないように、型でガードする ○ 値引きなどは？ ■ →それ専用の型を定義し、商品・総額の金額からのみ引かせないような操作（関数）を作る会議室の予約・利用状況を確認するプロダクト独自の抽象データ型の定義

Slide 36

Slide 36 text

Slide 37

Slide 37 text

例：金額計算と数量割引会議室の予約・利用状況を確認するプロダクト独自の抽象データ型の定義 Money amount(Money unitPrice, Quantity quantity) { if(quantity.isDiscountable) return discount(unitPrice, quantity) return unitPrice.multipy(quantity.value()) } 単価と数量を渡したら金額が返ってくるという意図割引可能な数量かどうか判断をするという意図数量を渡し、掛け算した結果を返すという意図

Slide 38

Slide 38 text

Slide 39

Slide 39 text

判断・計算≒ビジネスルール

Slide 40

Slide 40 text

ここに焦点を合わせる

Slide 41

Slide 41 text

会議室の予約・利用状況を確認するプロダクトビジネスルールは何処から生まれるのか事業を取り巻く環境から、事業(に含まれるプロダクト)の改善が生まれる事業の方針と決め事が変わる＝ビジネスルールが変わる

Slide 42

Slide 42 text

● バリューチェーン ● 競争地位戦略 ● バランススコアカード会議室の予約・利用状況を確認するプロダクトビジネスルール変更(ソフトウェア変更)の動機づけ

Slide 43

Slide 43 text

会議室の予約・利用状況を確認するプロダクトビジネスルール変更(ソフトウェア変更)の動機づけどの部分に重きを置くかで、ビジネスルールが変化する弊社（と親会社）の場合は、ここに注力？？

Slide 44

Slide 44 text

会議室の予約・利用状況を確認するプロダクトビジネスルール変更(ソフトウェア変更)の動機づけ ● これの面白いところは、客観的事実ではなく、企業がどこにポジショニングしているか弊社（と親会社）はここかなぁ？

Slide 45

Slide 45 text

● チャレンジャーであれば、機能差別化に注力する戦略 ○ ソフトウェアの機能・ルール追加が頻繁に起こり得る ● フォロワであれば、トップ企業たちの模倣を行う ○ その為、外界からの変更が起きやすい ○ 「◯◯さんのところみたいに作って〜」等など会議室の予約・利用状況を確認するプロダクトビジネスルール変更(ソフトウェア変更)の動機づけ

Slide 46

Slide 46 text

● ビジネスロジックのみをまとめる(=凝集性を高める) ○ UIやDBなどの入出力の関心事が混ざってしまうと、あっという間に見通しが悪くなる ○ Vue.jsやMySQLの文法が、ビジネスの計算判断と混ざってたら、見通し悪いですよね ○ 入出力と計算判断は分ける。そのうえで、意図と実装の詳細を分ける会議室の予約・利用状況を確認するプロダクト外から来る圧力に対応しやすくする為には

Slide 47

Slide 47 text

会議室の予約・利用状況を確認するプロダクトビジネスルールを表現するために

Slide 48

Slide 48 text

事業の周辺環境を捉え、ビジネスルール駆動でやるために

Slide 49

Slide 49 text

会議室の予約・利用状況を確認するプロダクトビジネスルール駆動とCCSR手法 CCSR : 継続的・並行的・段階的な品質改善

Slide 50

Slide 50 text

会議室の予約・利用状況を確認するプロダクトビジネスルール駆動とCCSR手法 CCSR : 継続的・並行的・段階的な品質改善・塾で提唱されている方法要件定義⇔実装に堺はなく、シームレスに繋がるやり方と認識

Slide 51

Slide 51 text

会議室の予約・利用状況を確認するプロダクトビジネスルール駆動とCCSR手法 ● 要件定義→実装というWF的思想ではなく、行ったり来たりする(並行的) ● 時間の経過と共に変化する環境を捉え、改善活動する(継続的)

Slide 52

Slide 52 text

● 顧客のニーズから生まれる要求、それに対してのビジネスルールをRDRAで捉える（要件定義） ○ RDRAでやる理由は俯瞰性が高く素早く定義できるから ■ 要件定義は2割くらい掴み、後の8割は実装で決める ● RDRAで捉えたビジネスルールを型で表す（仕様化） ● 仕様化で定義した型の内部実装、自動テストで動作検証（実装）会議室の予約・利用状況を確認するプロダクトビジネスルール駆動とCCSR手法

Slide 53

Slide 53 text

会議室の予約・利用状況を確認するプロダクトビジネスルール駆動とCCSR手法 CCSR : 継続的・並行的・段階的な品質改善ここがキモ

Slide 54

Slide 54 text

● WFの現場にいた自分からは、なかなか感覚が掴めなかったですが、要件定義は継続的に改善するもの ○ 一度決まったら終わり、ではない ○ 絶えず事業を取り巻く環境は変化するし、事業の一部であるプロダクトへの変更要求も変化する ○ ソフトウェアに最終形はない。最終形と思った時からソフトウェアの硬直化が始まる会議室の予約・利用状況を確認するプロダクト CCSR手法、双方向の改善

Slide 55

Slide 55 text

● 型の定義をすることによって、はじめて見えてくるものもある ○ 計算判断するロジックをどこに置くのか ○ あるルールを型として表現するのが難しい→色んな要素が混ざりあって表現が難しいのではないか？ ● そういった違和感から、コードをリファクタリングし、要件定義のモデルにフィードバックをする会議室の予約・利用状況を確認するプロダクト CCSR手法、双方向の改善

Slide 56

Slide 56 text

会議室の予約・利用状況を確認するプロダクト独自の抽象データ型の定義 Money amount(Money unitPrice, Quantity quantity) { if(quantity.isDiscountable) return discount(unitPrice, quantity) return unitPrice.multipy(quantity.value()) } 例：金額計算と数量割引 ● 果たして数量(Quantity)が一律的に割引判断していいのか？(ロジックの置き場への違和感、ぎこちなさ) ● 対象商品とか指定なくていいのか？そもそも合計金額◯千円〜割引とかは

Slide 57

Slide 57 text

● よく言葉を声に出したり、書いたりすることによって、違和感を覚えることがあると思います ○ 単語の使い方とか、「てにをは」が変とか ● 要件を型として表現するのも一緒だと感じています ○ クラス名、メソッド名、変数名に対する違和感 ○ この型にこんなデータや操作を持たせるという違和感 ○ このロジックが、全く関係ない引数をもらう違和感会議室の予約・利用状況を確認するプロダクト型に表すことによる違和感の発見

Slide 58

Slide 58 text

まとめ

Slide 59

Slide 59 text

● ソフトウェアの発展性とは、事業の改善活動によるルール変更に追従し、違和感を元にフィードバックができること ○ 事業改善は顧客のニーズや市場により動機づけられる ○ 自社の事業の強みや、地位戦略のポジショニングにより、方針と決め事も変わってくる ○ 形式知および、暗黙知になっているビジネスルールを抽象データ型としてソフトウェアの世界で表現する会議室の予約・利用状況を確認するプロダクト第3回までのまとめ

Slide 60

Slide 60 text

入塾 Before（入塾前に期待をしていたこと） ● 要件→設計→実装がシームレスに繋がることを経験できるのではないか ● 事業会社と子会社という分断をシームレスに繋ぐことが、設計の力でできるのではないか ● コード上の名付けやクラスやメソッドの置き場所という意思決定がもっと素早くできるようになる ○ 設計方面でチームリードができるのではないか

Slide 61

Slide 61 text

● 具体的なコードというよりも、もっと広い範囲での捉え方だった ● 特にバリューチェーンや競争地位戦略の視点から見たビジネスルールの動機づけの話は、とても為になり、その視点で話が出来るようになったのは大きな収穫 ● CCSR手法で要件→仕様→実装がシームレスに繋がる期待がある。それらすべて含めて設計会議室の予約・利用状況を確認するプロダクト入塾 After（実際、どうだったか）

Slide 62

Slide 62 text

残りの3回で、アーキテクチャや DB、WebAPI設計パターンを学ぶ予定

Slide 63

Slide 63 text

会議室の予約・利用状況を確認するプロダクトこんな卒業課題もやる予定

Slide 64

Slide 64 text

● 7つの視点と4つの観点でアーキテクチャを捉えた話が書かれている ❏ 28章:発展性パースペクティブ会議室の予約・利用状況を確認するプロダクト発展性についての参考図書

Slide 65

Slide 65 text

● 型が唯一のモジュール構造と説いている ❏ 6章:抽象データ型 ❏ 11章:契約による設計 ❏ 22章:クラスの見つけ方 ❏ 28章:ソフトウェア構築仮定会議室の予約・利用状況を確認するプロダクト発展性についての参考図書

Slide 66

Slide 66 text

● ドメイン駆動設計の原典 ❏ 8章:ブレイクスルー ❏ 9章:暗黙的な概念を明示的にする ❏ 10章:しなやかな設計会議室の予約・利用状況を確認するプロダクト発展性についての参考図書

Slide 67

Slide 67 text

● SSA、OOSC、DDDなどを踏まえ、日本の現場に合わせて書き起こされた、より実践的な書籍 ❏ はじめに ❏ 9章オブジェクト指向の開発プロセス会議室の予約・利用状況を確認するプロダクト発展性についての参考図書

Slide 68

Slide 68 text

● 要求分析、要件定義をアイコンの繋がりで表す手法RDRAについて書かれて書籍 ❏ 8章:RDRA活用のために会議室の予約・利用状況を確認するプロダクト発展性についての参考図書

Slide 69

Slide 69 text

おわり Thank you!