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

正しいものを正しく作る塾の、「正しくつくるための設計を学ぶ」コースで学んで、自分なりに言語化した内容を、社内で報告LTしたものです
塾で使った資料から引用し、その中で自分の言葉を書き込んだりしています

Transcript

1. 2020/02/26(水) #learning_lunch_lt Jun Nakajima 正しいものを正しくつくる塾 中間報告LT
2. ͳ͔͡· 5XJUUFSɿ!KOVBOL@ ˔ ओʹখചܥγεςϜͷडୗ։ൃΛ΍͍ͬͯ·͢ ˔ ܦྺ ˓ ҩྍػث'4&ʢυϥΠόʔΛѲΔਓʣ ˓ ˠ4&4 $
   "41/&5
   ͱ&YDFMͰઃܭॻΛগʑ ˓ ˠϋϯζϥϘ #BTI ˙ ϞϒϓϩɺϞϒϫʔΫɺ5%%ɺ%%%͕޷͖ͳਓͰ͢ ˙ ීஈ͸डୗ։ൃͰ3%3"࢖༻ͯ͠ͷཁ݅ఆٛ΍ΒɺϞσϦϯά΍Β ௅ઓ͍ͯ͠·͢ 2 まずは自己紹介
3. • そもそも何で入塾したのか • 正しいものを正しくつくるための設計とは • 入出力と計算判断、意図と実装詳細を分ける • 型で仕様(ビジネスルール)を表す • バリューチェーン、競争地位戦略からの動機づけ どんなこと話すか
4. 正しいものを正しくつくる塾とは
5. • 市谷さん、増田さんが主催するソフトウェア開発を「正し く」作ることにフォーカスした塾 • プロダクトの仮説検証と設計の2つのコースがある • 今回私は、正しくつくるための設計を学ぶコースに入塾し ています 正しいものを正しくつくる塾とは
6. • 技術的にリードをすることが辛みを感じていたこと • オブジェクト指向って？ 変更に強い良い設計とは？ という自分なりの解をちゃんと確立させたかった • 設計界隈で有名な増田さんに会って、色んな考えを聞 いてみたかった 会議室の予約・利用状況を確認するプロダクト そもそも何で入塾したのか
7. • 正しいソフトウェアを設計することをテーマに ◦ なぜ、発展性に焦点を当てるのか ◦ どうやって、設計をしていくのか • というのを各々の開発経験と紐付けていき、形式知→ 内面化をすることをやっていく • 各々が考え、答えを出し、研鑽をしていく • 塾は考えるきっかけと場を貰っているに過ぎない 会議室の予約・利用状況を確認するプロダクト 塾のスタイルとしては、大学のゼミ方式
8. • 設計能力は暗黙知である ◦ 世の中にある形式知はごく一部に過ぎない ◦ それらも自身のプロダクトに完璧に適用できない ◦ 人々の形式知から自身の経験(暗黙知)と結びつけ、 言語化し、実践や他者からのFBを得て暗黙知にする ▪ これが塾でやること 会議室の予約・利用状況を確認するプロダクト 塾のスタイルとしては、大学のゼミ方式
9. 会議室の予約・利用状況を確認するプロダクト 塾で使う参考書
10. 会議室の予約・利用状況を確認するプロダクト 塾で使う参考書 発展性という共通点を探し出し、 自身の開発経験と紐付けていく
11. • ラーニングパターン ◦ 学び方を話すための共 通言語 40パターン ◦ 設計を創造的に学ぶた めに、これらのパター ンを使う 会議室の予約・利用状況を確認するプロダクト 塾ではラーニングパターンをとても意識している
12. 塾ではラーニングパターンをとても意識している 自分自身は、ここを重視している • 特に重要視されているパターン
13. 第3回まで受講を終えたので、 自身の経験と紐付けながら発表をします
14. 正しいものを正しくつくる設計とは
15. 「変更を楽で安全にする」こと
16. 会議室の予約・利用状況を確認するプロダクト 変更を楽で安全にする 28章 発展性パースペクティブ • ソフトウェアの品質特性の中で、発展性に注目する
17. • ソフトウェアの品質特性の中で、発展性に注目する 会議室の予約・利用状況を確認するプロダクト 変更を楽で安全にする ここは一旦、考慮しない
18. 会議室の予約・利用状況を確認するプロダクト 発展性とはなにか
19. 会議室の予約・利用状況を確認するプロダクト 発展性とはなにか
20. • システムは変更がある事が、唯一の不変である • 前向きな変更容易性(保守性は後ろ向きな変更容易性) • ソフトウェアの中にある概念を意味のある単位に分け ること ◦ 意味のある単位というワードは、DDD8章〜10章の 所々に出てきてるので、おそらくこの辺りが重要 会議室の予約・利用状況を確認するプロダクト 発展性とはなにか（自分自身の理解）
21. • 自転車を組み立てます • 好きなネジ、ナット、ワッシャーを使って組み立てら れます！ • 何か追加機能あったら、１から組み立ててね！ 会議室の予約・利用状況を確認するプロダクト 現時点での自分の中にある保守性のイメージ
22. • サドル、ペダル、ブレーキ…と 意味のあるパーツ（単位）に分 けられている • それぞれのパーツには、何の為 にあるか（責務や振る舞い）が 明確である • 速く走りたければ、軽いものに 変える 会議室の予約・利用状況を確認するプロダクト 現時点での自分の中にある発展性のイメージ
23. 会議室の予約・利用状況を確認するプロダクト ソフトウェア開発で起きる諸問題
24. • SESの現場でよく経験した • 基本的に機能ごとに人をアサインし、結果的に車輪の 再発明がいたるところで起きる • 人の出入りや要件変更の時に対応しきれずに終わる • 要件変更は大体、ルールに基づく • 人の出入りに対応する為に、設計書を残せと言われ、 実装の翻訳的な設計書が量産され、辛くなる 会議室の予約・利用状況を確認するプロダクト 機能一覧を元にした手続き的なモジュール分割
25. 会議室の予約・利用状況を確認するプロダクト 機能一覧を元にした分割失敗のイメージ
26. 会議室の予約・利用状況を確認するプロダクト ルールに焦点を合わせた場合
27. • これもSESのg(ry • Windows Formsで作られた社内マスタ画面とか、ほぼ画 面とロジック密結合していて、辛かったよ… • SQL ServerのConnection張るのベタ書きだったり ◦ DBのテストとか辛いよ • 何でもかんでも詰め込んだ神クラスとか • 自身の設計に関する失敗については、下記も参照 https://speakerdeck.com/jnuank/moderingudeji-cun-sisutemufalseke-shi-hua-nilin-ndahua 会議室の予約・利用状況を確認するプロダクト 関心の分離の失敗
28. • ユニケージ作法その三 関数の使用は控えよ ◦ 読みやすくする為に上から下に流れるコードを読ませる ◦ →実装の詳細を使う側に読ませる時点で、意図と詳細が 分離できていない ◦ 意図と詳細を分離出来れば、呼び出し側は意図が明白な インターフェースを読むだけで済む ▪ intやstringの内部実装は皆さん気にしないよね 会議室の予約・利用状況を確認するプロダクト 関心の分離の失敗(弊社ユニケージ製システムの場合)
29. 会議室の予約・利用状況を確認するプロダクト 関心の分離の失敗(弊社ユニケージ製システムの場合) 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:実/通比率 • 通販比率を計算すると いう意図が、コメント でしか表されていない • 入出力が計算ロジック が密結合している • 分離されてないと、テ ストがしづらい
30. 関心の分離をする
31. 会議室の予約・利用状況を確認するプロダクト 関心の分離へのアプローチ
32. • 入出力（画面、DBなど）と計算・判断のロジックを分ける • 意図と実装の詳細を分ける ◦ 意図とは、アプリ独自の抽象データ型で表す ▪ 金額型、数量型、業務日付型など ◦ 実装の詳細は、組み込み型やライブラリを使った実装 • LocalDate.now()は今日の日付を取得するの意図が明白 ◦ 独自の抽象データ型でも、同じことをやる 4象限の関心の分離
33. • システム構成要素の責任を明確にする ◦ ロジックの明確な置き場所を決めることにより、凝集 性が高まってくる（ロジックの重複、断片化が減る） ◦ 商品検索機能は、商品検索が責務と言うかもしれない ◦ 商品検索は結果として実現する機能であり、それを構 成するビジネスルール、入出力は別々の責務である ◦ 入出力と密結合しているとテストがすごくしづらい なぜ分離をするのか
34. • 意図と実装の詳細の分離 ◦ 入出力と計算・判断を分離できた場合、チーム開発で あれば別々のエンジニアが担当することになる ◦ 意図と実装の詳細が混在していると、コードの見通し が悪くなり、計算・判断のロジックを使う側は、どの ように動くのか意図が分からず、コードを注意深く追 わなければいけない なぜ分離をするのか
35. • 抽象データ型(ADT)＝クラス • 例：金額型 ◦ intなどで扱うとマイナスの数字まで扱えてしまう ◦ マイナスを使わせないように、型でガードする ◦ 値引きなどは？ ▪ →それ専用の型を定義し、商品・総額の金額か らのみ引かせないような操作（関数）を作る 会議室の予約・利用状況を確認するプロダクト 独自の抽象データ型の定義
36. 会議室の予約・利用状況を確認するプロダクト 独自の抽象データ型の定義 Money amount(Money unitPrice, Quantity quantity) { if(quantity.isDiscountable) return discount(unitPrice, quantity) return unitPrice.multipy(quantity.value()) } 例：金額計算と数量割引
37. 例：金額計算と数量割引 会議室の予約・利用状況を確認するプロダクト 独自の抽象データ型の定義 Money amount(Money unitPrice, Quantity quantity) { if(quantity.isDiscountable) return discount(unitPrice, quantity) return unitPrice.multipy(quantity.value()) } 単価と数量を渡したら金額 が返ってくるという意図 割引可能な数量かどうか 判断をするという意図 数量を渡し、掛け算した結 果を返すという意図
38. 例：金額計算と数量割引 会議室の予約・利用状況を確認するプロダクト 独自の抽象データ型の定義 Money amount(Money unitPrice, Quantity quantity) { if(quantity.isDiscountable) return discount(unitPrice, quantity) return unitPrice.multipy(quantity.value()) } 単価と数量を渡したら金額 が返ってくるという意図 割引可能な数量かどうか 判断をするという意図 数量を渡し、掛け算した結 果を返すという意図
39. 判断・計算≒ビジネスルール
40. ここに焦点を合わせる
41. 会議室の予約・利用状況を確認するプロダクト ビジネスルールは何処から生まれるのか 事業を取り巻く環境から、 事業(に含まれるプロダクト)の改善が生まれる 事業の方針と決め事が変わる ＝ビジネスルールが変わる
42. • バリューチェーン • 競争地位戦略 • バランススコアカード 会議室の予約・利用状況を確認するプロダクト ビジネスルール変更(ソフトウェア変更)の動機づけ
43. 会議室の予約・利用状況を確認するプロダクト ビジネスルール変更(ソフトウェア変更)の動機づけ どの部分に重きを置くかで、ビジネ スルールが変化する 弊社（と親会社）の場合は、 ここに注力？？
44. 会議室の予約・利用状況を確認するプロダクト ビジネスルール変更(ソフトウェア変更)の動機づけ • これの面白いところは、客観的事実ではなく、企業がど こにポジショニングしているか 弊社（と親会社）は ここかなぁ？
45. • チャレンジャーであれば、機能差別化に注力する戦略 ◦ ソフトウェアの機能・ルール追加が頻繁に起こり得る • フォロワであれば、トップ企業たちの模倣を行う ◦ その為、外界からの変更が起きやすい ◦ 「◯◯さんのところみたいに作って〜」等など 会議室の予約・利用状況を確認するプロダクト ビジネスルール変更(ソフトウェア変更)の動機づけ
46. • ビジネスロジックのみをまとめる(=凝集性を高める) ◦ UIやDBなどの入出力の関心事が混ざってしまうと、あ っという間に見通しが悪くなる ◦ Vue.jsやMySQLの文法が、ビジネスの計算判断と混ざっ てたら、見通し悪いですよね ◦ 入出力と計算判断は分ける。そのうえで、意図と実装 の詳細を分ける 会議室の予約・利用状況を確認するプロダクト 外から来る圧力に対応しやすくする為には
47. 会議室の予約・利用状況を確認するプロダクト ビジネスルールを表現するために
48. 事業の周辺環境を捉え、 ビジネスルール駆動でやるために
49. 会議室の予約・利用状況を確認するプロダクト ビジネスルール駆動とCCSR手法 CCSR : 継続的・並行的・段階的な品質改善
50. 会議室の予約・利用状況を確認するプロダクト ビジネスルール駆動とCCSR手法 CCSR : 継続的・並行的・段階的な品質改善 ・塾で提唱されている方法 要件定義⇔実装に堺はなく、シー ムレスに繋がるやり方と認識
51. 会議室の予約・利用状況を確認するプロダクト ビジネスルール駆動とCCSR手法 • 要件定義→実装というWF的思想ではなく、行ったり来た りする(並行的) • 時間の経過と共に変化する環境を捉え、改善活動する(継 続的)
52. • 顧客のニーズから生まれる要求、それに対してのビジネス ルールをRDRAで捉える（要件定義） ◦ RDRAでやる理由は俯瞰性が高く素早く定義できるから ▪ 要件定義は2割くらい掴み、後の8割は実装で決め る • RDRAで捉えたビジネスルールを型で表す（仕様化） • 仕様化で定義した型の内部実装、自動テストで動作検証 （実装） 会議室の予約・利用状況を確認するプロダクト ビジネスルール駆動とCCSR手法
53. 会議室の予約・利用状況を確認するプロダクト ビジネスルール駆動とCCSR手法 CCSR : 継続的・並行的・段階的な品質改善 ここがキモ
54. • WFの現場にいた自分からは、なかなか感覚が掴めなかっ たですが、要件定義は継続的に改善するもの ◦ 一度決まったら終わり、ではない ◦ 絶えず事業を取り巻く環境は変化するし、事業の一部 であるプロダクトへの変更要求も変化する ◦ ソフトウェアに最終形はない。最終形と思った時から ソフトウェアの硬直化が始まる 会議室の予約・利用状況を確認するプロダクト CCSR手法、双方向の改善
55. • 型の定義をすることによって、はじめて見えてくるもの もある ◦ 計算判断するロジックをどこに置くのか ◦ あるルールを型として表現するのが難しい→色んな要 素が混ざりあって表現が難しいのではないか？ • そういった違和感から、コードをリファクタリングし、 要件定義のモデルにフィードバックをする 会議室の予約・利用状況を確認するプロダクト CCSR手法、双方向の改善
56. 会議室の予約・利用状況を確認するプロダクト 独自の抽象データ型の定義 Money amount(Money unitPrice, Quantity quantity) { if(quantity.isDiscountable) return discount(unitPrice, quantity) return unitPrice.multipy(quantity.value()) } 例：金額計算と数量割引 • 果たして数量(Quantity)が 一律的に割引判断してい いのか？(ロジックの置き 場への違和感、ぎこちな さ) • 対象商品とか指定なくて いいのか？そもそも合計 金額◯千円〜割引とかは
57. • よく言葉を声に出したり、書いたりすることによって、 違和感を覚えることがあると思います ◦ 単語の使い方とか、「てにをは」が変とか • 要件を型として表現するのも一緒だと感じています ◦ クラス名、メソッド名、変数名に対する違和感 ◦ この型にこんなデータや操作を持たせるという違和感 ◦ このロジックが、全く関係ない引数をもらう違和感 会議室の予約・利用状況を確認するプロダクト 型に表すことによる違和感の発見
58. まとめ
59. • ソフトウェアの発展性とは、事業の改善活動によるルール 変更に追従し、違和感を元にフィードバックができること ◦ 事業改善は顧客のニーズや市場により動機づけられる ◦ 自社の事業の強みや、地位戦略のポジショニングによ り、方針と決め事も変わってくる ◦ 形式知および、暗黙知になっているビジネスルールを 抽象データ型としてソフトウェアの世界で表現する 会議室の予約・利用状況を確認するプロダクト 第3回までのまとめ
60. 入塾 Before（入塾前に期待をしていたこと） • 要件→設計→実装 がシームレスに繋がることを経験で きるのではないか • 事業会社と子会社という分断をシームレスに繋ぐこと が、設計の力でできるのではないか • コード上の名付けやクラスやメソッドの置き場所とい う意思決定がもっと素早くできるようになる ◦ 設計方面でチームリードができるのではないか
61. • 具体的なコードというよりも、もっと広い範囲での捉 え方だった • 特にバリューチェーンや競争地位戦略の視点から見た ビジネスルールの動機づけの話は、とても為になり、 その視点で話が出来るようになったのは大きな収穫 • CCSR手法で要件→仕様→実装がシームレスに繋がる期 待がある。それらすべて含めて設計 会議室の予約・利用状況を確認するプロダクト 入塾 After（実際、どうだったか）
62. 残りの3回で、アーキテクチャや DB、WebAPI設計パターンを学ぶ予定
63. 会議室の予約・利用状況を確認するプロダクト こんな卒業課題もやる予定
64. • 7つの視点と4つの観点でアーキテ クチャを捉えた話が書かれている ❏ 28章:発展性パースペクティブ 会議室の予約・利用状況を確認するプロダクト 発展性についての参考図書
65. • 型が唯一のモジュール構造と説い ている ❏ 6章:抽象データ型 ❏ 11章:契約による設計 ❏ 22章:クラスの見つけ方 ❏ 28章:ソフトウェア構築仮定 会議室の予約・利用状況を確認するプロダクト 発展性についての参考図書
66. • ドメイン駆動設計の原典 ❏ 8章:ブレイクスルー ❏ 9章:暗黙的な概念を明示的にする ❏ 10章:しなやかな設計 会議室の予約・利用状況を確認するプロダクト 発展性についての参考図書
67. • SSA、OOSC、DDDなどを踏まえ、 日本の現場に合わせて書き起こさ れた、より実践的な書籍 ❏ はじめに ❏ 9章 オブジェクト指向の開発プロ セス 会議室の予約・利用状況を確認するプロダクト 発展性についての参考図書
68. • 要求分析、要件定義をアイコンの 繋がりで表す手法RDRAについて書 かれて書籍 ❏ 8章:RDRA活用のために 会議室の予約・利用状況を確認するプロダクト 発展性についての参考図書
69. おわり Thank you!