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

Slide 1

Slide 1 text

2020/05/25(月) #learning_lunch_lt Jun Nakajima 正しいものを正しくつくる塾最終報告

Slide 2

Slide 2 text

なかじま (Twitter：@jnuank_)  ● 経歴  ○ 医療機器FSE（ドライバーを握る人）  ○ →SES(C# ASP.NET とExcelで設計書を少々)  ○ →ハンズラボ(Bash・Python)  ■ モブプロ、モブワーク、TDD、DDDが好きな人です  ■ 普段は受託開発でRDRA使用しての要件定義やら、モデリングやら  挑戦しています  2 　恒例の自己紹介

Slide 3

Slide 3 text

● 2018年7月〜2020年2月まで ○ bashと素htmlでWebアプリ開発を外販 ● 2020年2月〜3月まで ○ Pythonで外販 ● 2020年4月から ○ 親会社の内製システム開発・運用。Python、Django、Vue.js 　最近の流れ

Slide 4

Slide 4 text

塾の参加前と参加後の差分

Slide 5

Slide 5 text

● 設計に関する実践的な学び（テクニックなど）が得られるのではないか ● 増田さんの設計論を生で聞いてみたいというミーハーな気持ちテクニックを学ぶことによって、 ● 要件→設計→実装が難なく出来るようになるのではないか ● コード上の名付けやクラスやメソッドの置き場所という意思決定がもっと素早くできるようになり、チームリードができるのではないか ● 設計の良し悪しを言葉で説明できるようになるのではないか　塾参加前（期待をしていたこと）

Slide 6

Slide 6 text

　塾参加後 ● 要件→設計→実装が難なく出来るようになるのではないか ○ これについては、まだまだ ● コード上の名付けやクラスやメソッドの置き場所という意思決定がもっと素早くできるようになり、チームリードができるのではないか ● 設計の良し悪しを言葉で説明できるようになるのではないか ○ 感覚でしか悪いとしか言えなかったコードに対して、入出力とビジネスロジックが結合しているなど、明言化できるようになってきた

Slide 7

Slide 7 text

塾で学んだことタイムライン

Slide 8

Slide 8 text

塾自体はJava(静的型付け) + DDD + 抽象データ型 + RDRA を使った考え方に振り切っている(もちろん、応用が利く部分はあった) ● 設計技術は暗黙知である(第1回) ● 変更を安全で楽にすることである(第1回) ● ソフトウェアの発展性に着目をする(第1回) ● 型を中心とした設計表現。関心の分離(第2回) ● ビジネスルール駆動の設計(第3〜4回) ● ドメインモデルを考えたあとで、入出力も分けていく(第5回) 　塾の講義タイムライン

Slide 9

Slide 9 text

● 設計技術はほとんど暗黙知（全てをWikiやマニュアル化は難しい） ○ だからこそ、自分の経験（暗黙知）を言語化して、フィードバックを得て内面化をする ○ 学び方の話はラーニング・パターンも参考にしている　設計技術は暗黙知である(第1回)

Slide 10

Slide 10 text

● 「正しいものを正しくつくる」＝変更を安全で楽にすること ● だからこそ、ソフトウェアの発展性(SAA)に注力をしたものづくりをする ○ 前向きな変更容易性 ○ 変更が起きやすい・起きにくい箇所を充分に検討し、整理した作り ○ 無駄になる早期の労力と後からの巨額な変更コストのバランスを取る ■ 「SAA 28.2.6 変更の対価を払う時期」 ○ DDD 第3部序章では、「使い込んだグローブ」と表現してる　変更を安全で楽にすることと、発展性(第1回)

Slide 11

Slide 11 text

● 発展性が劣化する要因として、関心の分離の失敗が挙げられる ● 入出力とビジネスルールの計算・判断を分離する ● 意図の表現と実装の詳細も分離する ○ 個人的には、この発想が無かったので目から鱗だった　型を中心とした設計表現と関心の分離(第2回)

Slide 12

Slide 12 text

● バリューチェーンと競争地位戦略、RDRAの話 ● プロダクトと取り巻く事業・市場に対して、どの部分に変更が入りやすいか、と考える1つの視点として使用していく ● RDRAを扱うことで、ステークホルダーの要求・要件と、そこに関連するビジネスルールを可視化していく　ビジネスルール駆動の設計(第3〜4回)

Slide 13

Slide 13 text

● 洗い出していったビジネスルールを型として表現する ○ 状態遷移や区分ごとの計算・判断ロジック（EnumとMap・Setなど) ○ このやり方は第4回の資料と、PSA の1〜4章にヒントが書かれている　ビジネスルール駆動の設計(第3〜4回)

Slide 14

Slide 14 text

● テーブル設計はイベントソーシングの考え方(事実の記録かつイミュータブル) ● ビジネスロジックの計算・判断とそれ以外(ユーザに見せる付加的情報など)に分ける ○ このやり方は第5回の資料と、PSA の6〜8章にヒントが書かれている　入出力の扱い方(第5回)

Slide 15

Slide 15 text

塾を通してのアウトプット

Slide 16

Slide 16 text

● 塾の第2回の関心の分離の4象限を意識し、3月に現場で実践 ● 大した計算ルールは無かったが、入出力を分けることにより、他システムから渡ってくるデータフォーマットが変わっても、難なく対応ができた ○ その時、予想通り変更が来たので、「よし来たっ！」となった ● その時の知見を社内でアウトプット ○ CSV→スペース区切りに変換する処理でも、真面目に入出力とルールを分離をしてみる - Qiita ○ https://qiita.com/jnuank/items/bbd46f5868d2ca723aa6 　関心の分離の4象限を意識したコード

Slide 17

Slide 17 text

● 架空の会議室予約システムをお題として、Pythonでの実装を試している ○ https://github.com/ModelingKai/meeting-room-python ○ ドメインモデルをPythonのdataclassなどでどう表現するか ○ ドメインモデル、ユースケース、業務フローなどはすべてPlantUMLでコミットする実験 ■ 開発初期は良いが、最近はコード直してモデル直して〜に面倒くさいという重力が発生している　関心の分離の4象限を意識したコード

Slide 18

Slide 18 text

● 4月より開始した、従業員が触るマスタ系の刷新PJについて ○ 大きく感じるのは、クライアント（親会社）と自分たち開発者（子会社）の関係性や関心事の違い　要件定義時、バリューチェーンと競争地位を意識子会社親会社小売業 SW製造運用を提供システム開発年間保守費開発費

Slide 19

Slide 19 text

● 4月より開始した、従業員が触るマスタ系の刷新PJについて ○ レガシー技術や画面で、大幅に刷新して開発者やクライアントの運用コストを下げたい子会社　要件定義時、バリューチェーンと競争地位を意識子会社親会社

Slide 20

Slide 20 text

● 4月より開始した、従業員が触るマスタ系の刷新PJについて ○ 親会社は小売りなので、販売・マーケに力を入れたい（どう売上確保するか） ■ あまり売上に直結しない部分は「そこまで変えなくていい」　要件定義時、バリューチェーンと競争地位を意識子会社親会社

Slide 21

Slide 21 text

● 塾の第3回で話したバリューチェーンや競争地位戦略に当てはめていくと ○ 「販売・マーケ」に関わるシステムや部署については、クライアント側の意見が相当強いため、ビジネスルールの変更可能性はよく検討しないといけないと考えている ■ 販売・マーケ達が考える地位戦略のポジション取りも重要 ○ それ以外の部署については、（力をあまり入れてないので）開発者側の提案が割と通りやすいのではと思う ■ 逆に、「あまり変えてくれるな」とも言われる可能性はある　要件定義時、バリューチェーンと競争地位を意識

Slide 22

Slide 22 text

● 今回のPJでやろうかと思ったけど、今回はやめた ● メンバーへ教えるコストとメンテコストと、簡潔なマスタ画面なので ● 代わりに、ユーザーストーリーマッピングで仕様を可視化してみている　要件定義時の意識合わせでRDRAを使おうとして…

Slide 23

Slide 23 text

● 同じ画面に表示するものだが、入力や変更のタイミングが異なるタイミングがあるものに関して、テーブルを分けてみた（基本情報、付加情報） ○ 自然と基本情報の方は、Nullが入りにくいDB設計になってきた ■ 完全に排除はできてはいない（元のデータの分析が必要）　入出力に関する設計

Slide 24

Slide 24 text

● 鳥の眼と虫の眼という全体と細部を行き来するパターンがあるが、これは個人だけではなくチームにも適用できるという気づき ● メンバーのそれぞれの得意分野と関心事が違うため、各々が虫の眼で見ることによって、多面的な見方ができる(複眼的) ● 逆に議論が煮詰まってきた場合はメンバー全員が近視眼的(虫の眼)になっているので、意識して俯瞰的(鳥の眼)になってみるなど　ラーニング・パターンのチーム(勝手に)適用

Slide 25

Slide 25 text

● 要求や要件定義の中で開発スコープを決めていく、よくある行為 ○ やる、やらないの線引をする ■ これは、後の発展性を損なう行為だと感じるようになった ■ SAA P.485 28.3.1 「発展性ニーズの特徴づけ」 ● 延期になった、曖昧な仕様が今後変更対象となるのか評価する項目がある ● やらないものも「完全にやらないのか」「いつかやるのか」変更を検討する時間は取った方が良いと感じた　発展性のある設計活動についての意識

Slide 26

Slide 26 text

ここから発展性についての考察

Slide 27

Slide 27 text

面倒くさい → 発展性を損なうサイン？

Slide 28

Slide 28 text

● 面倒くさい、というのはネガティブワードではあるけど、開発においてはすごく重要な意味を持つ重力（または抵抗力）と考えている ○ 面倒くさがった結果、場当たり的な修正で済ませようとする ■ 更にコードが編集しづらくなって、レガシー化→発展性下がる ● これらの面倒くさいを深堀りしていくと、なにかヒントが得られそう ○ コードを直したら、ドキュメントも直すのが、面倒くさい ○ コードを直して、デプロイするのが面倒くさい ○ 仕様変更によってコードをあちこち直すのが面倒くさい　面倒くさいの重力

Slide 29

Slide 29 text

● PSA 9章 P.276 ソースコードを第一級のドキュメントとして活用する ○ Python + Djangoを使用しているので、DjangoのModelもしくは、データベースからER図、DB定義書を自動生成するCI/CD導入を検討中 ○ API定義書もSwaggerで生成することを検討 ○ ビジネスルールを実装した箇所のテスト自動化 ○ ドキュメント作成 → 開発は、開発初期のステークホルダーとの意識合わせには有効そうだが、開発中期〜リリース〜運用になったら、ソースコードを正とした仕組みを考えるよう動いていきたい　面倒くさいを打破するために

Slide 30

Slide 30 text

2020年12月の目標

Slide 31

Slide 31 text

● 開発の面倒くさいを極力排除できるような仕組み作りをすること ○ コードからドキュメント自動生成 ● コードの自己文書化 ○ 関心の分離の4象限にある、意図の表明を意識 ○ 複雑なビジネスルールをコードで表現できるようにすること ● ほぼドキュメントレスにできるCCSR手法を試したい ● TDDによるアプローチも設計の足がかりに使えそうなので、試していきたい会議室の予約・利用状況を確認するプロダクト　2020年12月の目標

Slide 32

Slide 32 text

● DDD（主専攻） ○ あらためてブレイクスルーの部分発展性の部分 ● SAA（副専攻） ○ 28章の発展性会議室の予約・利用状況を確認するプロダクト　参考図書の深堀り

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

おわり Thank you!