Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

166179f92d3bf392db9c148c2b7e6f5a?s=47 Jun Nakajima
February 26, 2020

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

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

166179f92d3bf392db9c148c2b7e6f5a?s=128

Jun Nakajima

February 26, 2020
Tweet

More Decks by Jun Nakajima

Other Decks in Business

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

  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!