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

2021/04/10開催　Developer eXperience Day 2021

「クソコード動画『Userクラス』で考える技術的負債解消の観点」の解説資料です。
https://dxd2021.cto-a.org/program/time-table/b-3

クソコード動画はこちら
https://twitter.com/MinoDriven/status/1380773721032433674

YouTubeライブのリンクはこちら
https://www.youtube.com/watch?v=ajPaGPdj6tU

Transcript

1. クソコード動画「Userクラス」 で考える 技術的負債解消の観点 Developer eXperience Day 2021 2021/04/10 READYFOR株式会社 ミノ駆動
2. この動画の解説資料です クソコード動画「Userクラス」 https://twitter.com/MinoDriven/status/1380773721032433674
3. レジュメ • 自己紹介 • 劇中の問題 • システムとは何か • 情報システム開発とモデリング • Userクラスが抱える問題 • モデリング　解決編 • モデリング発展議論 • まとめ • おまけ
4. 自己紹介
5. 自己紹介 ▪NECネットワーク・センサ㈱ ファームウェア開発 ▪キヤノン㈱ Windowsアプリ、組み込みアプリの開発や リファクタリング、リアーキ ▪㈱クラウドワークス 巨大Railsアプリのリファクタリング ▪READYFOR㈱ 2021年4月よりジョイン ミノ駆動 @MinoDriven リファクタリングや クソコード退治が大好きです
6. おさらい　劇中の問題
7. 問題①：必要とするデータが状況によって異なる
8. 問題②：制約（ルール）が異なる
9. 問題③：影響範囲の拡大
10. この手の技術的負債（というかもはや設計ミスに近い）は、 単にロジックを整理するだけのリファクタリングでは解決困 難。 そこで本発表では、Userクラスの負債解消に必要な観点を 解説します。
11. Userクラスの問題を紐解くには、そもそもシステムとは何か、我々 が何のためにシステム開発するのかを理解する必要があります。 少し長くなりますがお付き合い願います。
12. システムとは何か
13. 人の営みとシステム 世の中は様々な社会的活動から成り立っている。この社会的活動を、ここでは「人の営 み」と呼称する。そして人の営みは、太古の昔からシステムにより実行されている。 コミュニケーション 移動する 農作業 買い物
14. 太古の昔からシステム？？ そんな大昔からコンピューターなんか あったっけ？？？
15. システムの定義 (Wikipediaより引用) 相互に影響を及ぼしあう要素から構成される、まとまりや仕組み の全体。
16. システム例１：目的地への移動 二足歩行システム
17. システム例２：コミュニケーション 発声器官と聴覚器官による会話システム
18. システムを分かりやすく言うと 「人の営み」を遂行し、問題解決するための何らかの仕組みのこ と。 人体に備わる器官や臓器も立派なシステム。
19. 別のシステムへ代替される我々の営み 人類は様々な道具（システム）を発明、開発し、既存のシステムを代替してきた。 特にコンピュータによるものを情報システムと呼ぶ。 コミュニケーション 移動する 農作業 買い物 農具 飛行機 ネットショッピング SNS
20. 何のためにシステムを開発し、置き換えるのか？ 問題解決の効率化ため 代替・置換 二足歩行システム 航空機システム
21. 別に乗り物を使わなくても、やろうと思えば二足歩行だけでできる。 でもそれだとむちゃくちゃ大変… 遠い遠い場所へ、徒歩だけで 旅行できるものだろうか？ 全くできないわけではないだろ うが… 何のためにシステムを開発し、置き換えるのか？
22. 人手だと大変な部分を別システムに置き換えると、何倍も効率化できる。 テクノロジの本質は能力の拡大縮小。 代替・置換 二足歩行システム 航空機システム
23. システム設計者に求められること つまり、効率化するには、人の営み と、営みに伴う問題の理解が必須。 問題を理解できて、初めて効率的に 解決可能な仕組みを設計できる。 逆に問題を正しく理解していないと、 問題解決に貢献しないシステムが作 られてしまう。
24. 情報システム開発とモデリング
25. システムには、対応する人の営みがある。 ECサイトのシステム化対象の内訳には、様々な人の営みがある。 この内、利用者のシステム化を考えてみる。 利用者 注文 支払い 配送 在庫管理
26. 「利用者」の全てをシステム化すべきか？ ECサイトでは、利用者の「血圧」や「今まで喰ったパンの枚数」は必要？？ 利用者 配送先 クレカ情報 名前 電話番号 メアド 欲しいもの 購入履歴 今まで喰った パンの枚数 性別 年齢 身長 体重 血圧 体脂肪率 既往歴 鼻毛の本数 推しのアイドル
27. 利用者のあらゆる属性をシステム化したらキリがない！ 無限にある！！ 一部分しか必要ないはず。 ではその「一部分」とはどの範囲か？ システムの定義とシステム化の目的を振り返ってみる。
28. ECサイトでは、商品の売買に必要な要素があれば良い。 医療サービスでは、身体情報や健康状態の要素があれば良い。 何を解決したいかによって、システム化する部分が違う。 システムの定義：「人の営み」を遂行し、問題解決するための何らかの仕組み システム化の目的：問題解決の効率化 利用者 配送先 クレカ情報 名前 電話番号 メアド 欲しいもの 購入履歴 今まで喰った パンの枚数 性別 年齢 身長 体重 血圧 体脂肪率 既往歴 鼻毛の本数 推しのアイドル ECサイトでシステム化する部分 医療サービスでシステム化する部分
29. こうした関係概念を システム構成要素として表現し 整理していく 商品 購入履歴 注文日 支払い クレカ 注文金額
30. このような活動を モデリング という 商品 購入履歴 注文日 支払い クレカ 注文金額
31. モデルの定義 ドメイン駆動設計における定義を引用する。 モデル：ドメインの選択された側面を記述し、そのドメインに関連する問題を解決するた めに使用できる抽象化のシステム。 ドメイン：知識、影響力、または活動の範囲のこと。プログラムを適用する対象領域が、 そのソフトウェアのドメイン。 商品 購入履歴 注文日
32. モデルを分かりやすく言うと システム化対象の、人の営みに登場する概念を 抽象化したもの。 あくまで問題解決に貢献する部分だけを切り出 し、システムの役に立つよう似せて作ったもの。 サービスを「マクロなシステム」とすると、モデルは システムを構成する「ミクロなシステム」。マクロな システムは、モデル即ち小さなシステム群から構 成されると考えることができる。 システム モデル モデル モデル
33. 【注意】抽象化の意味 「抽象化」というと、犬と猫の共通要素から動 物を導き出す、クラス設計でいう汎化や抽象ク ラスをイメージするかも知れないが、違う。 膨大な具象パラメータの内、エッセンスだけを 抜き出して簡略化する、要約するの意味合い に近い。 配送先 名前 電話番号 メアド 購入履歴 性別 年齢 血圧
34. モデリングとは特化 ここまでのモデルの定義や特徴を整理すると、特定問題の解決に存在するものだから、 モデリングは概念の特化と言える。 登場概念は、特定の問題解決に貢献する側面のみを切り出しモデル化する。 概念の全ての側面ではない！特化した1側面だけだ、という点が肝要。
35. Userクラスが抱える問題
36. Userクラスをモデリングの観点と照らし合わせてみる 個人顧客と法人顧客の、関心事の異なる問 題をUserクラスで取り扱ってしまっている。つ まり、複数の問題解決のためにUserクラスが 流用されている構造。 特定の問題解決を意図した構造になっていな い。 個人でも法人でも、どうとでも解釈可能。「利 用者」のあらゆる側面を意味しているように見 えてしまっている。 結果、「利用者」に関係する様々な概念を内 包できてしまう。 Userクラス 顧客管理 クラス 法人管理 クラス 個人やろ！ 法人やろが 常考 ……
37. 結果どんな弊害が生じたか 一貫性のない 構造 SRP違反 巨大クラス化 密結合
38. Userクラスが抱える問題の本質 つまりUserクラスは、モデリングされているよ うで全然まともにモデリングされていない。 種類の異なる問題がシステム内に複数存在 することを認識できていない。 特定の問題解決のために、いち側面だけが 抽出されていない。 問題それぞれに対応する個別の解決システ ムとして分離されているべきものが、密結合 になってしまっている。 Userクラス 顧客管理 クラス 法人管理 クラス ウソや！ ワイら一生懸命設計 したんやぞ！！ そうやぞ！ 給料増やせや！ ……
39. モデリング　解決編
40. 問題それぞれに応じたモデリングをし直そう Userクラスが解決しようとしていた問題（関心事）を全て列挙しよう。 問題（関心事）それぞれ対応するモデルを設計し直そう。 そうして初めて、リファクタリングのゴールとなる、「あるべき設計」が見えてくる。 クソコード動画に登場したクラスたちも爆死せずに済む。
41. 関心の分離＆分割統治 関心の分離：関心事ごとに分離した構成要素でソフトウェアを構築する考え方。 分割統治：小さな問題に分割し、個別に解決する考え方。 基本的にはこの2つの考え方に基づいて、関心事それぞれに対応するモデリングをして いけば良い。 では関心事の違いとは？どの観点で分離すればいいのか？いくつかアプローチの仕方 がある。 関心事A 関心事B 関心事C
42. 主語クソデカ問題 名前は点ではなく範囲。 名前は、概念のある一点を指し示すの ではなく、範囲を示すもの。 従ってどうとでも解釈可能なガバガバな 名前を用いると広く様々な関心事を内包 したり、様々な概念と関連付いてしまう。 Userクラスはクソデカ主語の筆頭。
43. 名前設計 モデリングする上で名前の設計は超重要！ 具体的で意味範囲の狭い言葉を選ぶ。 ザルな解釈を許容しない、一意に意味を特定可能な、特化した名前を設計する。
44. 特化した名前を設計＆モデルを分割することで、各モデルの関連を最小限に抑えることが できる。
45. 動画中のUserクラスは少なくとも以下に分けられる 但しこれは完成形ではない。理由は後述。 個人 法人
46. ユースケース図のアクターをモデル化しない アクターはUserクラスと同様の性質を持つ。アクターをそのままモデル化すると、アクターのあら ゆる関心事、属性を吸収し、巨大化しがち。 ではどうするか？
47. システム上の表現に着目する 「利用者」という概念は、システム内でどう表現されている か？ 右はGithubのアカウント設定メニュー。極めて秀逸な例。 アカウント、プロフィール、表示テーマ、セキュリティ etc... 様々な関心事ごとに項目が分かれている。
48. つまり動画中のUserクラスは、少なくとも以下に分割されるものと考えられる。 （※実際にはサービスの関心事に応じたモデルがさらに作られる） 個人 アカウント 法人 アカウント そして各モデルに、関連する知識を集約し、カプセル化する。
49. 【！！】この資料で一番伝えたいこと【！！】 現実世界の物理的存在とシステム内のモデルは１：１になるとは限らない。むしろ１：Nの 関係になる可能性がある。たったひとつのモデルに統一せず、関心事に応じたモデルを それぞれ設計することが何よりも大事。 これを名目と現物の分離という（書籍「UMLモデリングの本質」より）。 現実世界の 利用者 個人 アカウント 法人 アカウント プロフィール システム内の モデル 支払い方法
50. モデリング発展議論 －価値本質とイノベーション－
51. はるか昔、人々は疫病の原因を「悪魔」とモデリングしていた。悪魔と呼称して、当時効 果的に対処できていたであろうか…？？ のちに、細菌の発見により対処方法が劇的に革新。
52. こういう雑な認識の人に、エヴァンゲリオンやガンダムのゲーム開発を任せられるだろう か？ 「エバンゲリオン？ああ、あのガンダムですよね？ロ ボットのやつ。」
53. 実際の開発で扱うビジネスはもっともっと複雑！ビジネスの深い理解なしに、問題の本 質に到達できるだろうか？ システム化対象の人の営みについて認識の解像度が低かったり、問題の本質を理解し ていないと、問題解決に正しく貢献するモデリングが難しくなってしまう。 「私、技術には興味ありますけど、ビジネスには興味ありませんから。仕様はビジネス側 で考えて下さい」このような考えを持っていると設計が瓦解し、顧客に訴求するシステム を作れなくなってしまう可能性が高くなる。 我々は「悪魔」とモデリングしてないだろうか？ 「細菌」を発見できているだろうか？
54. フォード氏「もし顧客に彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』 と答えていただろう」 手段に囚われず、「もっと速く移動したい」というニーズ、本質的問題に着目することでイ ノベーションが生まれる。 システム化対象の概念をそのままモデリングしていただけでは、イノベーションは生まれ ない。その概念は、実はただの手段では？と疑問を持つことが大事。 イノベーション
55. 秀逸な例①：Twitterのリツイート Twitterの最大の特徴と考えられるモデル、リツイート。 RTされたツイートが、フォロワーのタイムラインに表示される仕様。つまりリツイートは、 タイムラインの変換能力を有している。 これにより、良くも悪くも話題性の高いツイートが拡散される。 リツイート フォロー タイムライン ツイート ※このモデルは筆者の想像です
56. 秀逸な例②：リングフィットアドベンチャー プレイヤーのフィットネスで敵に攻撃する画期的なゲーム。 フィットスキルは、プレイヤーの運動動作を攻撃力に変換する能力を備えていると考えら れる。 リングコン 入力 ダメージ モンスター フィット スキル ※このモデルは筆者の想像です 攻撃範囲
57. 有益な変換能力を持つモデルの設計が鍵 この2例から分かるように、世の中の優れた情報システムは、有益な変換能力を有して いる。 コンピュータの本質は信号処理。信号処理を様々な演算そして変換に応用することで、 我々は恩恵を得ている。 優れた変換能力を内包したモデルを設計することが、イノベーションの鍵と考える。 概念の名前を表面的になぞらえるだけのモデリングでは、「リツイート」や「フィットスキ ル」といった画期的なモデルは決して生まれてこない。 なお、このようなモデルをドメイン駆動設計では深いモデルと呼ぶ。
58. ビジネス課題への深いアプローチは一石二鳥 モデリングするとき、ビジネス課題を深堀りし、理解の解像度を上げると、以下の利点が 得られる。 利点①：一貫性があり、疎結合高凝集なクラス設計に貢献するモデリングができる。技 術的負債を負わせない＆負債の解消に役立つ。 利点②：ビジネス課題の解決に大きく貢献するモデル設計に繋がる。サービス価値向上 が期待できる。 エンジニアリングとビジネスは近接しなければならない！
59. READYFORのチームビジョン「乳化」 READYFORでは「組織の中にエンジニアリングが自然に溶け込んでいる状態 」を「乳化」と呼称 し、イノベーションとパフォーマンスの最大化を目指している。 エンジニアリングとビジネスの近接を実現するコンセプト であり、あるべき設計や、問題解決に大 きく貢献する設計を推進していけると感じ、私は READYFORにジョインした。
60. まとめ • モデリングとは、特定の問題解決のために、物事の特定の側面を抽象化したもの である。 • Userクラスが負債化しやすいのは、まともにモデリングされていないのが原因。 • 現実世界の物理的存在とシステム内のモデルは1:Nの関係になる可能性がある。 • 一貫性があり、疎結合高凝集な設計に役立つモデリングをするには、システム化対 象の人の営みや、営みに伴う問題の理解が必須。 • 問題の深い理解は、品質面だけでなく、より有益なモデル設計に繋がり、システム 価値の向上を期待できる。
61. おまけ
62. 本を出版することに なりました
63. その名も
64. 悪魔の設計(仮)

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