Slide 1

Slide 1 text

不幸を再生産しないための 設計に対する向き合い方 2022/08/20 READYFOR株式会社 ミノ駆動

Slide 2

Slide 2 text

おしながき ● 自己紹介 ● 本日のお題 ● 私の失敗経験 ● 失敗経験と学びの活用 ● モデリングと認知科学 ● クロージング

Slide 3

Slide 3 text

こんにちは、ミノ駆動です

Slide 4

Slide 4 text

ここで働いています

Slide 5

Slide 5 text

最近ニュースになった クラウドファンディング

Slide 6

Slide 6 text

『良いコード/悪いコードで学ぶ設計入 門』の著者。 発売3ヶ月で第6刷目の重版。発行部数 2万部達成。 技術書で1万部超えればベストセラーと のことですが、それも超えてまだまだ売 れています。

Slide 7

Slide 7 text

もうちょっと詳しい職歴とか ミノ駆動 @MinoDriven 電子機器メーカーや大手精密機器メーカー、そし てクラウドワークスを経て、2021年4月に READYFOR株式会社にジョイン。 アプリケーションアーキテクトとして、レガシーシス テムのリファクタリングや拡張性向上設計など、シ ステム設計に従事。 『良いコード/悪いコードで学ぶ設計入門』の他、 クソコード動画シリーズの作者。

Slide 8

Slide 8 text

本日のお題

Slide 9

Slide 9 text

設計しないと不幸になる

Slide 10

Slide 10 text

そして より良い設計アプローチをしないと 不幸になる

Slide 11

Slide 11 text

私と同じ不幸を 再生産してほしくない そんな思いを伝える内容です

Slide 12

Slide 12 text

僕が体験した「不幸」とは?

Slide 13

Slide 13 text

プロジェクト炎上

Slide 14

Slide 14 text

日常的なプロジェクト炎上 派遣さんも含めて40-50人の開発体制。 仕様書通りに動作するよう、実装だけをひたすら繰り返し。 設計はほとんどしていないに等しい状態。 開発中、バグが大量に出る。バグを直した影響で他の箇所にバグ が発生するのは茶飯事。

Slide 15

Slide 15 text

残業40-60時間は当たり前。 体力ミジンコの私、疲れ果てる。

Slide 16

Slide 16 text

PL「つらい残業を乗り切れるよう、 昼休みにバスケをやって体力をつけよう!」

Slide 17

Slide 17 text

書籍『リファクタリング』との出会い

Slide 18

Slide 18 text

運命を変えた本『リファクタリング』 何か打開策はないものかと職場の本棚を 漁っていたら書籍『リファクタリング』を偶然発 見。「コードが理解しやすくなる」「バグが少な くなる」の記述を見て衝撃を覚えました。 仕事中、製品コードを利用し、裏でコソコソリ ファクタリングひたすら練習(※もちろんコミッ トはしてません)。

Slide 19

Slide 19 text

設計があまりに面白かったので、『ドメイン駆動設計』や『レガシーコード改善 ガイド』など設計関連の書籍を買い漁り、買いすぎだと嫁に叱られつつも、さら に設計スキルを高めていきました。

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

当時は何がまずかったのか いろいろ分かってなかった……

Slide 26

Slide 26 text

わからん殺し 「わからん殺し」とは、対戦ゲームにおいて、相手側が対策できていない戦法で 一方的になぶり殺す事の俗称。やられた側からすると「よくわからない内に倒さ れていた」感覚。 何か上手くいかないときは、課題や解決方法が認識できていないことが多い。 今ある知識だけでなんとかしようとすると上手くいかない。「セルフわからん殺 し」に陥っている。 様々なことを学び直すキッカケになりました。

Slide 27

Slide 27 text

学び直しで得た知識の例 ● 書籍『ドメイン駆動設計』 ○ システムで最も価値を付加すべき「コアドメイン」の概念を知ったこと で、設計コストの選択と集中を学んだ。 ● 書籍『レガシーソフトウェア改善ガイド』 ○ リファクタリング対象の選定には、価値、難度、リスクの3軸で評価する ことを学んだ。 ○ チームから合意を得るための交渉のしかたを学んだ。 ○ ソフトランディングするための進め方を学んだ。 etc…

Slide 28

Slide 28 text

失敗経験と学びをどう活かしているか

Slide 29

Slide 29 text

認識の共有

Slide 30

Slide 30 text

課題感の共有 「巨大なRailsアプリに蓄積した負債を解消し、開発生産性を向上 したい」 この課題を解決することのみに注力する設計であって、他の機能 開発を妨げたり、いたずらにリソースを食い潰すような意図はない ことを強調。

Slide 31

Slide 31 text

解決手段の理由や背景を共有 RailsはActiveRecordが中心であるために、随所でDB知識と密 結合になる。 Railsアプリが巨大化してくると、Rails-wayのやり方では辛くなっ てくる。 ゆえに打開策として、DDDの考え方を取り入れる。DB知識と疎結 合にする、よりビジネスに追従容易なドメイン層を形成するため。

Slide 32

Slide 32 text

選択と集中、コスト戦略の共有 変更頻度の高いコアな機能に設計コストを集中する。 負債の酷くない箇所や、コアでない箇所は従来通りRails-wayで 良い。無理はしない。

Slide 33

Slide 33 text

その他認識共有 勉強会で設計知識を共有 メンバーとの課題感、設計に対する認識合わせ スモールステップで実施 小さな成功体験の積み重ねと共有

Slide 34

Slide 34 text

説明コストはかなりかかりましたが 設計の理解を得られ ソフトランディングに成功しました

Slide 35

Slide 35 text

やったことは チームビルディングそのものでした

Slide 36

Slide 36 text

チームビルディングなくして設計は上手くいかない 高い 開発生産性 設計 チームビルディング ここをないがしろにすると、2階にあ る設計に登れない! 技術的負債と設計は認知困難だ からこそ、意思共有は丁寧に!

Slide 37

Slide 37 text

設計も常に学びの日々です

Slide 38

Slide 38 text

モデリングと認知科学 モデリングは設計の要です。 物事をどう見るかで概念の認識が変わりモデルも変化します。 より本質をついた、高品質なモデリングをするには、概念をどう解 釈するかを深く知る必要があります。 そのため私は最近、認知科学や哲学を勉強しています。

Slide 39

Slide 39 text

アクチュアル(現働的) ヴァーチャル(潜在的) 「自転車に乗る人」と「自転車」の、 物理的存在に囚われがち。 存在の脱構築 人 vs 自転車といった区別なく、全てのもの が複雑に関係し合う次元として解釈。モデリ ングで役に立つ考え方。 『現代思想入門』著:千葉雅也、 2022年刊行、講談社

Slide 40

Slide 40 text

物理的存在としてモ デリング 利用者 User 利用者:モデルが1:1では 巨大化複雑化し、 使いにくいモデルになりがち

Slide 41

Slide 41 text

存在の脱構築 利用者 購入側 アカウント 個人 プロフィール 認証 認可 出品側 アカウント 会員特典設定 物理的存在から離れ、役に立つ目的単位で モデリングすると、1:Nの関係性になる(こと がとても多い)。

Slide 42

Slide 42 text

エヴァンス本 シェアパイの例 ブレイクスルー シェアパイ ローン出資 ローン調整 「シェアパイ」という概念を見出したことで、ローンの金額計算誤差 や特殊ケースに対応するための複雑なロジックが消え去った。顧客 にもわかりやすい概念として定着した。

Slide 43

Slide 43 text

「売買契約」という法的概念とすることで支払条件(支払期日など) の存在を認知できる。法的な有効性を発揮できるモデルとなる。 商品購入?? 法的な意味付け 商品購入 ID 購入日時 受取希望日 売買契約 ID 契約締結日時 引渡希望日 支払期日 決済方法

Slide 44

Slide 44 text

クロージング

Slide 45

Slide 45 text

誰しも仕事で辛い局面に 立たされたことがあるはず

Slide 46

Slide 46 text

不貞腐れたり 誰かを恨んだり 仕事を投げ出したくなったり…

Slide 47

Slide 47 text

私は様々な失敗経験をないがしろにせず その後の開発などに活かしてきました

Slide 48

Slide 48 text

これまでの失敗がなければ この本は完成しなかったでしょう

Slide 49

Slide 49 text

失敗を放っておいて イヤな記憶として こびりつかせておくよりも…

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

本日このあとの登壇者の発表や 様々な技術書から学びを深め 失敗を宝に変えていこう