クソコード動画「Userクラス」で考える技術的負債解消の観点

by MinoDriven

Slide 1

Slide 1 text

クソコード動画「Userクラス」で考える技術的負債解消の観点 Developer eXperience Day 2021 2021/04/10 READYFOR株式会社ミノ駆動

Slide 2

Slide 2 text

この動画の解説資料ですクソコード動画「Userクラス」 https://twitter.com/MinoDriven/status/1380773721032433674

Slide 3

Slide 3 text

レジュメ ● 自己紹介 ● 劇中の問題 ● システムとは何か ● 情報システム開発とモデリング ● Userクラスが抱える問題 ● モデリング　解決編 ● モデリング発展議論 ● まとめ ● おまけ

Slide 4

Slide 4 text

自己紹介

Slide 5

Slide 5 text

自己紹介 ■NECネットワーク・センサ㈱ファームウェア開発 ■キヤノン㈱ Windowsアプリ、組み込みアプリの開発やリファクタリング、リアーキ ■㈱クラウドワークス巨大Railsアプリのリファクタリング ■READYFOR㈱ 2021年4月よりジョインミノ駆動 @MinoDriven リファクタリングやクソコード退治が大好きです

Slide 6

Slide 6 text

おさらい　劇中の問題

Slide 7

Slide 7 text

問題①：必要とするデータが状況によって異なる

Slide 8

Slide 8 text

問題②：制約（ルール）が異なる

Slide 9

Slide 9 text

問題③：影響範囲の拡大

Slide 10

Slide 10 text

この手の技術的負債（というかもはや設計ミスに近い）は、単にロジックを整理するだけのリファクタリングでは解決困難。そこで本発表では、Userクラスの負債解消に必要な観点を解説します。

Slide 11

Slide 11 text

Userクラスの問題を紐解くには、そもそもシステムとは何か、我々が何のためにシステム開発するのかを理解する必要があります。少し長くなりますがお付き合い願います。

Slide 12

Slide 12 text

システムとは何か

Slide 13

Slide 13 text

人の営みとシステム世の中は様々な社会的活動から成り立っている。この社会的活動を、ここでは「人の営み」と呼称する。そして人の営みは、太古の昔からシステムにより実行されている。コミュニケーション移動する農作業買い物

Slide 14

Slide 14 text

太古の昔からシステム？？そんな大昔からコンピューターなんかあったっけ？？？

Slide 15

Slide 15 text

システムの定義 (Wikipediaより引用) 相互に影響を及ぼしあう要素から構成される、まとまりや仕組みの全体。

Slide 16

Slide 16 text

システム例１：目的地への移動二足歩行システム

Slide 17

Slide 17 text

システム例２：コミュニケーション発声器官と聴覚器官による会話システム

Slide 18

Slide 18 text

システムを分かりやすく言うと「人の営み」を遂行し、問題解決するための何らかの仕組みのこと。人体に備わる器官や臓器も立派なシステム。

Slide 19

Slide 19 text

別のシステムへ代替される我々の営み人類は様々な道具（システム）を発明、開発し、既存のシステムを代替してきた。特にコンピュータによるものを情報システムと呼ぶ。コミュニケーション移動する農作業買い物農具飛行機ネットショッピング SNS

Slide 20

Slide 20 text

何のためにシステムを開発し、置き換えるのか？問題解決の効率化ため代替・置換二足歩行システム航空機システム

Slide 21

Slide 21 text

別に乗り物を使わなくても、やろうと思えば二足歩行だけでできる。でもそれだとむちゃくちゃ大変… 遠い遠い場所へ、徒歩だけで旅行できるものだろうか？全くできないわけではないだろうが… 何のためにシステムを開発し、置き換えるのか？

Slide 22

Slide 22 text

人手だと大変な部分を別システムに置き換えると、何倍も効率化できる。テクノロジの本質は能力の拡大縮小。代替・置換二足歩行システム航空機システム

Slide 23

Slide 23 text

システム設計者に求められることつまり、効率化するには、人の営みと、営みに伴う問題の理解が必須。問題を理解できて、初めて効率的に解決可能な仕組みを設計できる。逆に問題を正しく理解していないと、問題解決に貢献しないシステムが作られてしまう。

Slide 24

Slide 24 text

情報システム開発とモデリング

Slide 25

Slide 25 text

システムには、対応する人の営みがある。 ECサイトのシステム化対象の内訳には、様々な人の営みがある。この内、利用者のシステム化を考えてみる。利用者注文支払い配送在庫管理

Slide 26

Slide 26 text

「利用者」の全てをシステム化すべきか？ ECサイトでは、利用者の「血圧」や「今まで喰ったパンの枚数」は必要？？利用者配送先クレカ情報名前電話番号メアド欲しいもの購入履歴今まで喰ったパンの枚数性別年齢身長体重血圧体脂肪率既往歴鼻毛の本数推しのアイドル

Slide 27

Slide 27 text

利用者のあらゆる属性をシステム化したらキリがない！無限にある！！一部分しか必要ないはず。ではその「一部分」とはどの範囲か？システムの定義とシステム化の目的を振り返ってみる。

Slide 28

Slide 28 text

ECサイトでは、商品の売買に必要な要素があれば良い。医療サービスでは、身体情報や健康状態の要素があれば良い。何を解決したいかによって、システム化する部分が違う。システムの定義：「人の営み」を遂行し、問題解決するための何らかの仕組みシステム化の目的：問題解決の効率化利用者配送先クレカ情報名前電話番号メアド欲しいもの購入履歴今まで喰ったパンの枚数性別年齢身長体重血圧体脂肪率既往歴鼻毛の本数推しのアイドル ECサイトでシステム化する部分医療サービスでシステム化する部分

Slide 29

Slide 29 text

こうした関係概念をシステム構成要素として表現し整理していく商品購入履歴注文日支払いクレカ注文金額

Slide 30

Slide 30 text

このような活動をモデリングという商品購入履歴注文日支払いクレカ注文金額

Slide 31

Slide 31 text

モデルの定義ドメイン駆動設計における定義を引用する。モデル：ドメインの選択された側面を記述し、そのドメインに関連する問題を解決するために使用できる抽象化のシステム。ドメイン：知識、影響力、または活動の範囲のこと。プログラムを適用する対象領域が、そのソフトウェアのドメイン。商品購入履歴注文日

Slide 32

Slide 32 text

モデルを分かりやすく言うとシステム化対象の、人の営みに登場する概念を抽象化したもの。あくまで問題解決に貢献する部分だけを切り出し、システムの役に立つよう似せて作ったもの。サービスを「マクロなシステム」とすると、モデルはシステムを構成する「ミクロなシステム」。マクロなシステムは、モデル即ち小さなシステム群から構成されると考えることができる。システムモデルモデルモデル

Slide 33

Slide 33 text

【注意】抽象化の意味「抽象化」というと、犬と猫の共通要素から動物を導き出す、クラス設計でいう汎化や抽象クラスをイメージするかも知れないが、違う。膨大な具象パラメータの内、エッセンスだけを抜き出して簡略化する、要約するの意味合いに近い。配送先名前電話番号メアド購入履歴性別年齢血圧

Slide 34

Slide 34 text

モデリングとは特化ここまでのモデルの定義や特徴を整理すると、特定問題の解決に存在するものだから、モデリングは概念の特化と言える。登場概念は、特定の問題解決に貢献する側面のみを切り出しモデル化する。概念の全ての側面ではない！特化した1側面だけだ、という点が肝要。

Slide 35

Slide 35 text

Userクラスが抱える問題

Slide 36

Slide 36 text

Userクラスをモデリングの観点と照らし合わせてみる個人顧客と法人顧客の、関心事の異なる問題をUserクラスで取り扱ってしまっている。つまり、複数の問題解決のためにUserクラスが流用されている構造。特定の問題解決を意図した構造になっていない。個人でも法人でも、どうとでも解釈可能。「利用者」のあらゆる側面を意味しているように見えてしまっている。結果、「利用者」に関係する様々な概念を内包できてしまう。 Userクラス顧客管理クラス法人管理クラス個人やろ！法人やろが常考 ……

Slide 37

Slide 37 text

結果どんな弊害が生じたか一貫性のない構造 SRP違反巨大クラス化密結合

Slide 38

Slide 38 text

Userクラスが抱える問題の本質つまりUserクラスは、モデリングされているようで全然まともにモデリングされていない。種類の異なる問題がシステム内に複数存在することを認識できていない。特定の問題解決のために、いち側面だけが抽出されていない。問題それぞれに対応する個別の解決システムとして分離されているべきものが、密結合になってしまっている。 Userクラス顧客管理クラス法人管理クラスウソや！ワイら一生懸命設計したんやぞ！！そうやぞ！給料増やせや！ ……

Slide 39

Slide 39 text

モデリング　解決編

Slide 40

Slide 40 text

問題それぞれに応じたモデリングをし直そう Userクラスが解決しようとしていた問題（関心事）を全て列挙しよう。問題（関心事）それぞれ対応するモデルを設計し直そう。そうして初めて、リファクタリングのゴールとなる、「あるべき設計」が見えてくる。クソコード動画に登場したクラスたちも爆死せずに済む。

Slide 41

Slide 41 text

関心の分離＆分割統治関心の分離：関心事ごとに分離した構成要素でソフトウェアを構築する考え方。分割統治：小さな問題に分割し、個別に解決する考え方。基本的にはこの2つの考え方に基づいて、関心事それぞれに対応するモデリングをしていけば良い。では関心事の違いとは？どの観点で分離すればいいのか？いくつかアプローチの仕方がある。関心事A 関心事B 関心事C

Slide 42

Slide 42 text

主語クソデカ問題名前は点ではなく範囲。名前は、概念のある一点を指し示すのではなく、範囲を示すもの。従ってどうとでも解釈可能なガバガバな名前を用いると広く様々な関心事を内包したり、様々な概念と関連付いてしまう。 Userクラスはクソデカ主語の筆頭。

Slide 43

Slide 43 text

名前設計モデリングする上で名前の設計は超重要！具体的で意味範囲の狭い言葉を選ぶ。ザルな解釈を許容しない、一意に意味を特定可能な、特化した名前を設計する。

Slide 44

Slide 44 text

特化した名前を設計＆モデルを分割することで、各モデルの関連を最小限に抑えることができる。

Slide 45

Slide 45 text

動画中のUserクラスは少なくとも以下に分けられる但しこれは完成形ではない。理由は後述。個人法人

Slide 46

Slide 46 text

ユースケース図のアクターをモデル化しないアクターはUserクラスと同様の性質を持つ。アクターをそのままモデル化すると、アクターのあらゆる関心事、属性を吸収し、巨大化しがち。ではどうするか？

Slide 47

Slide 47 text

システム上の表現に着目する「利用者」という概念は、システム内でどう表現されているか？右はGithubのアカウント設定メニュー。極めて秀逸な例。アカウント、プロフィール、表示テーマ、セキュリティ etc... 様々な関心事ごとに項目が分かれている。

Slide 48

Slide 48 text

つまり動画中のUserクラスは、少なくとも以下に分割されるものと考えられる。（※実際にはサービスの関心事に応じたモデルがさらに作られる）個人アカウント法人アカウントそして各モデルに、関連する知識を集約し、カプセル化する。

Slide 49

Slide 49 text

【！！】この資料で一番伝えたいこと【！！】現実世界の物理的存在とシステム内のモデルは１：１になるとは限らない。むしろ１：Nの関係になる可能性がある。たったひとつのモデルに統一せず、関心事に応じたモデルをそれぞれ設計することが何よりも大事。これを名目と現物の分離という（書籍「UMLモデリングの本質」より）。現実世界の利用者個人アカウント法人アカウントプロフィールシステム内のモデル支払い方法

Slide 50

Slide 50 text

モデリング発展議論－価値本質とイノベーション－

Slide 51

Slide 51 text

はるか昔、人々は疫病の原因を「悪魔」とモデリングしていた。悪魔と呼称して、当時効果的に対処できていたであろうか…？？のちに、細菌の発見により対処方法が劇的に革新。

Slide 52

Slide 52 text

こういう雑な認識の人に、エヴァンゲリオンやガンダムのゲーム開発を任せられるだろうか？「エバンゲリオン？ああ、あのガンダムですよね？ロボットのやつ。」

Slide 53

Slide 53 text

実際の開発で扱うビジネスはもっともっと複雑！ビジネスの深い理解なしに、問題の本質に到達できるだろうか？システム化対象の人の営みについて認識の解像度が低かったり、問題の本質を理解していないと、問題解決に正しく貢献するモデリングが難しくなってしまう。「私、技術には興味ありますけど、ビジネスには興味ありませんから。仕様はビジネス側で考えて下さい」このような考えを持っていると設計が瓦解し、顧客に訴求するシステムを作れなくなってしまう可能性が高くなる。我々は「悪魔」とモデリングしてないだろうか？「細菌」を発見できているだろうか？

Slide 54

Slide 54 text

フォード氏「もし顧客に彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう」手段に囚われず、「もっと速く移動したい」というニーズ、本質的問題に着目することでイノベーションが生まれる。システム化対象の概念をそのままモデリングしていただけでは、イノベーションは生まれない。その概念は、実はただの手段では？と疑問を持つことが大事。イノベーション

Slide 55

Slide 55 text

秀逸な例①：Twitterのリツイート Twitterの最大の特徴と考えられるモデル、リツイート。 RTされたツイートが、フォロワーのタイムラインに表示される仕様。つまりリツイートは、タイムラインの変換能力を有している。これにより、良くも悪くも話題性の高いツイートが拡散される。リツイートフォロータイムラインツイート ※このモデルは筆者の想像です

Slide 56

Slide 56 text

秀逸な例②：リングフィットアドベンチャープレイヤーのフィットネスで敵に攻撃する画期的なゲーム。フィットスキルは、プレイヤーの運動動作を攻撃力に変換する能力を備えていると考えられる。リングコン入力ダメージモンスターフィットスキル ※このモデルは筆者の想像です攻撃範囲

Slide 57

Slide 57 text

有益な変換能力を持つモデルの設計が鍵この2例から分かるように、世の中の優れた情報システムは、有益な変換能力を有している。コンピュータの本質は信号処理。信号処理を様々な演算そして変換に応用することで、我々は恩恵を得ている。優れた変換能力を内包したモデルを設計することが、イノベーションの鍵と考える。概念の名前を表面的になぞらえるだけのモデリングでは、「リツイート」や「フィットスキル」といった画期的なモデルは決して生まれてこない。なお、このようなモデルをドメイン駆動設計では深いモデルと呼ぶ。

Slide 58

Slide 58 text

ビジネス課題への深いアプローチは一石二鳥モデリングするとき、ビジネス課題を深堀りし、理解の解像度を上げると、以下の利点が得られる。利点①：一貫性があり、疎結合高凝集なクラス設計に貢献するモデリングができる。技術的負債を負わせない＆負債の解消に役立つ。利点②：ビジネス課題の解決に大きく貢献するモデル設計に繋がる。サービス価値向上が期待できる。エンジニアリングとビジネスは近接しなければならない！

Slide 59

Slide 59 text

READYFORのチームビジョン「乳化」 READYFORでは「組織の中にエンジニアリングが自然に溶け込んでいる状態」を「乳化」と呼称し、イノベーションとパフォーマンスの最大化を目指している。エンジニアリングとビジネスの近接を実現するコンセプトであり、あるべき設計や、問題解決に大きく貢献する設計を推進していけると感じ、私は READYFORにジョインした。

Slide 60

Slide 60 text

まとめ ● モデリングとは、特定の問題解決のために、物事の特定の側面を抽象化したものである。 ● Userクラスが負債化しやすいのは、まともにモデリングされていないのが原因。 ● 現実世界の物理的存在とシステム内のモデルは1:Nの関係になる可能性がある。 ● 一貫性があり、疎結合高凝集な設計に役立つモデリングをするには、システム化対象の人の営みや、営みに伴う問題の理解が必須。 ● 問題の深い理解は、品質面だけでなく、より有益なモデル設計に繋がり、システム価値の向上を期待できる。

Slide 61

Slide 61 text

おまけ

Slide 62

Slide 62 text

本を出版することになりました

Slide 63

Slide 63 text

その名も

Slide 64

Slide 64 text

悪魔の設計(仮) 

Slide 65

Slide 65 text

悪魔の設計（仮）  クソコードアンチパターン駆動の設計技術書です。良くない実装はどんな問題を引き起こすか、問題を解決するにはどんな設計が必要かを解説します。ソフトウェア開発に潜む悪魔を退治する設計本です。設計を知らない、または設計に興味はあるけどよく分からない、何を学んでよいか分からない初心者が主な対象です。初級から中級へハシゴをかけることを主眼としています。㈱技術評論社より、 2021年全国出版予定。