クソコード動画「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株式会社
   ミノ駆動
   

   View Slide

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

   View Slide

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

   View Slide

4. 自己紹介
   

   View Slide

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

   View Slide

6. おさらい　劇中の問題
   

   View Slide

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

   View Slide

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

   View Slide

9. 問題③：影響範囲の拡大
   

   View Slide

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

    View Slide

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

    View Slide

12. システムとは何か
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

35. Userクラスが抱える問題
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

39. モデリング　解決編
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

61. おまけ
    

    View Slide

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

    View Slide

63. その名も
    

    View Slide

64. 悪魔の設計(仮)

    

    View Slide

65. 悪魔の設計（仮）

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

    View Slide