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ヶ月で第６刷目の重版。発行部数
２万部達成。
技術書で１万部超えればベストセラーと
のことですが、それも超えてまだまだ売
れています。
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
利用者：モデルが１：１では
巨大化複雑化し、
使いにくいモデルになりがち
Slide 41
Slide 41 text
存在の脱構築
利用者
購入側
アカウント
個人
プロフィール
認証
認可
出品側
アカウント
会員特典設定
物理的存在から離れ、役に立つ目的単位で
モデリングすると、１：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
本日このあとの登壇者の発表や
様々な技術書から学びを深め
失敗を宝に変えていこう