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

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

Transcript

1. 2020/05/25(月) #learning_lunch_lt Jun Nakajima 正しいものを正しくつくる塾 最終報告
2. なかじま (Twitter：@jnuank_)
 • 経歴
 ◦ 医療機器FSE（ドライバーを握る人）
 ◦ →SES(C# ASP.NET とExcelで設計書を少々)
 ◦ →ハンズラボ(Bash・Python)
 ▪ モブプロ、モブワーク、TDD、DDDが好きな人です
 ▪ 普段は受託開発でRDRA使用しての要件定義やら、モデリングやら
 挑戦しています
 2 　恒例の自己紹介
3. • 2018年7月〜2020年2月まで ◦ bashと素htmlでWebアプリ開発を外販 • 2020年2月〜3月まで ◦ Pythonで外販 • 2020年4月から ◦ 親会社の内製システム開発・運用。Python、Django、Vue.js 　最近の流れ
4. 塾の参加前と参加後の差分
5. • 設計に関する実践的な学び（テクニックなど）が得られるのではないか • 増田さんの設計論を生で聞いてみたいというミーハーな気持ち テクニックを学ぶことによって、 • 要件→設計→実装が難なく出来るようになるのではないか • コード上の名付けやクラスやメソッドの置き場所という意思決定がもっと素早くで きるようになり、チームリードができるのではないか • 設計の良し悪しを言葉で説明できるようになるのではないか 　塾参加前（期待をしていたこと）
6. 　塾参加後 • 要件→設計→実装が難なく出来るようになるのではないか ◦ これについては、まだまだ • コード上の名付けやクラスやメソッドの置き場所という意思決定がもっと素早くで きるようになり、チームリードができるのではないか • 設計の良し悪しを言葉で説明できるようになるのではないか ◦ 感覚でしか悪いとしか言えなかったコードに対して、入出力とビジネスロ ジックが結合しているなど、明言化できるようになってきた
7. 塾で学んだことタイムライン
8. 塾自体はJava(静的型付け) + DDD + 抽象データ型 + RDRA を使った考え方に 振り切っている(もちろん、応用が利く部分はあった) • 設計技術は暗黙知である(第1回) • 変更を安全で楽にすることである(第1回) • ソフトウェアの発展性に着目をする(第1回) • 型を中心とした設計表現。関心の分離(第2回) • ビジネスルール駆動の設計(第3〜4回) • ドメインモデルを考えたあとで、入出力も分けていく(第5回) 　塾の講義タイムライン
9. • 設計技術はほとんど暗黙知（全てをWikiやマニュアル化は難しい） ◦ だからこそ、自分の経験（暗黙知）を言語化して、フィードバックを得て内面 化をする ◦ 学び方の話はラーニング・パターンも参考にしている 　設計技術は暗黙知である(第1回)
10. • 「正しいものを正しくつくる」＝変更を安全で楽にすること • だからこそ、ソフトウェアの発展性(SAA)に注力をした ものづくり をする ◦ 前向きな変更容易性 ◦ 変更が起きやすい・起きにくい箇所を充分に検討し、整理した作り ◦ 無駄になる早期の労力と後からの巨額な変更コストのバランスを取る ▪ 「SAA 28.2.6 変更の対価を払う時期」 ◦ DDD 第3部序章では、「使い込んだグローブ」と表現してる 　変更を安全で楽にすることと、発展性(第1回)
11. • 発展性が劣化する要因として、関心の分離の失敗が挙げられる • 入出力とビジネスルールの計算・判断を分離する • 意図の表現と実装の詳細も分離する ◦ 個人的には、この発想が無かったので目から鱗だった 　型を中心とした設計表現と関心の分離(第2回)
12. • バリューチェーンと競争地位戦略、RDRAの話 • プロダクトと取り巻く事業・市場に対して、どの部分に変更が入りやすいか、と考 える1つの視点として使用していく • RDRAを扱うことで、ステークホルダーの要求・要件と、そこに関連するビジネス ルールを可視化していく 　ビジネスルール駆動の設計(第3〜4回)
13. • 洗い出していったビジネスルールを型として表現する ◦ 状態遷移や区分ごとの計算・判断ロジック（EnumとMap・Setなど) ◦ このやり方は第4回の資料と、PSA の1〜4章にヒントが書かれている 　ビジネスルール駆動の設計(第3〜4回)
14. • テーブル設計はイベントソーシングの考え方(事実の記録かつイミュータブル) • ビジネスロジックの計算・判断とそれ以外(ユーザに見せる付加的情報など)に分 ける ◦ このやり方は第5回の資料と、PSA の6〜8章にヒントが書かれている 　入出力の扱い方(第5回)
15. 塾を通してのアウトプット
16. • 塾の第2回の関心の分離の4象限を意識し、3月に現場で実践 • 大した計算ルールは無かったが、入出力を分けることにより、他システムから 渡ってくるデータフォーマットが変わっても、難なく対応ができた ◦ その時、予想通り変更が来たので、「よし来たっ！」となった • その時の知見を社内でアウトプット ◦ CSV→スペース区切りに変換する処理でも、真面目に入出力とルールを分 離をしてみる - Qiita ◦ https://qiita.com/jnuank/items/bbd46f5868d2ca723aa6 　関心の分離の4象限を意識したコード
17. • 架空の会議室予約システムをお題として、Pythonでの実装を試している ◦ https://github.com/ModelingKai/meeting-room-python ◦ ドメインモデルをPythonのdataclassなどでどう表現するか ◦ ドメインモデル、ユースケース、業務フローなどはすべてPlantUMLでコミット する実験 ▪ 開発初期は良いが、最近はコード直してモデル直して〜に面倒くさい という重力が発生している 　関心の分離の4象限を意識したコード
18. • 4月より開始した、従業員が触るマスタ系の刷新PJについて ◦ 大きく感じるのは、クライアント（親会社）と自分たち開発者（子会社）の関係 性や関心事の違い 　要件定義時、バリューチェーンと競争地位を意識 子会社 親会社 小売業 SW製造 運用を提供 システム開発 年間保守費 開発費
19. • 4月より開始した、従業員が触るマスタ系の刷新PJについて ◦ レガシー技術や画面で、大幅に刷新して開発者やクライアントの運用コスト を下げたい子会社 　要件定義時、バリューチェーンと競争地位を意識 子会社 親会社
20. • 4月より開始した、従業員が触るマスタ系の刷新PJについて ◦ 親会社は小売りなので、販売・マーケに力を入れたい（どう売上確保する か） ▪ あまり売上に直結しない部分は「そこまで変えなくていい」 　要件定義時、バリューチェーンと競争地位を意識 子会社 親会社
21. • 塾の第3回で話したバリューチェーンや競争地位戦略に当てはめていくと ◦ 「販売・マーケ」に関わるシステムや部署については、クライアント側の意見 が相当強いため、ビジネスルールの変更可能性はよく検討しないといけな いと考えている ▪ 販売・マーケ達が考える地位戦略のポジション取りも重要 ◦ それ以外の部署については、（力をあまり入れてないので）開発者側の提 案が割と通りやすいのではと思う ▪ 逆に、「あまり変えてくれるな」とも言われる可能性はある 　要件定義時、バリューチェーンと競争地位を意識
22. • 今回のPJでやろうかと思ったけど、今回はやめた • メンバーへ教えるコストとメンテコストと、簡潔なマスタ画面なので • 代わりに、ユーザーストーリーマッピングで仕様を可視化してみている 　要件定義時の意識合わせでRDRAを使おうとして…
23. • 同じ画面に表示するものだが、入力や変更のタイミングが異なるタイミングがあ るものに関して、テーブルを分けてみた（基本情報、付加情報） ◦ 自然と基本情報の方は、Nullが入りにくいDB設計になってきた ▪ 完全に排除はできてはいない（元のデータの分析が必要） 　入出力に関する設計
24. • 鳥の眼と虫の眼という全体と細部を行き来するパターンがあるが、 これは個人だけではなくチームにも適用できるという気づき • メンバーのそれぞれの得意分野と関心事が違うため、各々が虫の眼で見ること によって、多面的な見方ができる(複眼的) • 逆に議論が煮詰まってきた場合はメンバー全員が 近視眼的(虫の眼)になっているので、 意識して俯瞰的(鳥の眼)になってみるなど 　ラーニング・パターンのチーム(勝手に)適用
25. • 要求や要件定義の中で開発スコープを決めていく、よくある行為 ◦ やる、やらないの線引をする ▪ これは、後の発展性を損なう行為だと感じるようになった ▪ SAA P.485 28.3.1 「発展性ニーズの特徴づけ」 • 延期になった、曖昧な仕様が今後変更対象となるのか評価する 項目がある • やらないものも「完全にやらないのか」「いつかやるのか」変更を 検討する時間は取った方が良いと感じた 　発展性のある設計活動についての意識
26. ここから発展性についての考察
27. 面倒くさい → 発展性を損なうサイン？
28. • 面倒くさい、というのはネガティブワードではあるけど、開発においてはすごく重 要な意味を持つ重力（または抵抗力）と考えている ◦ 面倒くさがった結果、場当たり的な修正で済ませようとする ▪ 更にコードが編集しづらくなって、レガシー化→発展性下がる • これらの面倒くさいを深堀りしていくと、なにかヒントが得られそう ◦ コードを直したら、ドキュメントも直すのが、面倒くさい ◦ コードを直して、デプロイするのが面倒くさい ◦ 仕様変更によってコードをあちこち直すのが面倒くさい 　面倒くさいの重力
29. • PSA 9章 P.276 ソースコードを第一級のドキュメントとして活用する ◦ Python + Djangoを使用しているので、DjangoのModelもしくは、データベー スからER図、DB定義書を自動生成するCI/CD導入を検討中 ◦ API定義書もSwaggerで生成することを検討 ◦ ビジネスルールを実装した箇所のテスト自動化 ◦ ドキュメント作成 → 開発 は、開発初期のステークホルダーとの意識合わ せには有効そうだが、開発中期〜リリース〜運用になったら、ソースコード を正とした仕組みを考えるよう動いていきたい 　面倒くさいを打破するために
30. 2020年12月の目標
31. • 開発の面倒くさいを極力排除できるような仕組み作りをすること ◦ コードからドキュメント自動生成 • コードの自己文書化 ◦ 関心の分離の4象限にある、意図の表明を意識 ◦ 複雑なビジネスルールをコードで表現できるようにすること • ほぼドキュメントレスにできるCCSR手法を試したい • TDDによるアプローチも設計の足がかりに使えそうなので、試していきたい 会議室の予約・利用状況を確認するプロダクト 　2020年12月の目標
32. • DDD（主専攻） ◦ あらためてブレイクスルーの部分発展性の部分 • SAA（副専攻） ◦ 28章の発展性 会議室の予約・利用状況を確認するプロダクト 　参考図書の深堀り
33. • 7つの視点と4つの観点でアーキテク チャを捉えた話が書かれている ❏ 28章:発展性パースペクティブ 会議室の予約・利用状況を確認するプロダクト 　発展性についての参考図書
34. • 型が唯一のモジュール構造と説いて いる ❏ 6章:抽象データ型 ❏ 11章:契約による設計 ❏ 22章:クラスの見つけ方 ❏ 28章:ソフトウェア構築仮定 会議室の予約・利用状況を確認するプロダクト 　発展性についての参考図書
35. • ドメイン駆動設計の原典 ❏ 8章:ブレイクスルー ❏ 9章:暗黙的な概念を明示的にする ❏ 10章:しなやかな設計 会議室の予約・利用状況を確認するプロダクト 　発展性についての参考図書
36. • SSA、OOSC、DDDなどを踏まえ、日 本の現場に合わせて書き起こされ た、より実践的な書籍 ❏ はじめに ❏ 9章 オブジェクト指向の開発プロセス 会議室の予約・利用状況を確認するプロダクト 　発展性についての参考図書
37. • 要求分析、要件定義をアイコンの繋 がりで表す手法RDRAについて書か れて書籍 ❏ 8章:RDRA活用のために 会議室の予約・利用状況を確認するプロダクト 　発展性についての参考図書
38. おわり Thank you!