Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
不幸を再生産しないための設計に対する向き合い方
Search
MinoDriven
August 20, 2022
Programming
10
9.3k
不幸を再生産しないための設計に対する向き合い方
「オープンセミナー岡山2022」のイベント登壇で用いた資料です。
https://okayama.open-seminar.org/
MinoDriven
August 20, 2022
Tweet
Share
More Decks by MinoDriven
See All by MinoDriven
破壊せよ!データ破壊駆動で考えるドメインモデリング / data-destroy-driven
minodriven
17
4.8k
アーキテクチャレベルで考える開発生産性 / architecture-and-productivity
minodriven
22
11k
見えないものに着目すると上手くいく、モデリングの勘所 / invisible-driven-design
minodriven
23
6.8k
クソコード動画『カプセル化 Mk-II』 で考える 上手くカプセル化できない理由 / encapsulation2
minodriven
22
16k
技術的負債の怨霊と除霊方法 / ghosts-of-technical-debt
minodriven
11
4.2k
分岐を低減するinterface設計と発想の転換 / interface_design_idea.pdf
minodriven
18
6.7k
目的と抽象化の関係性から分かる、システムの設計精度を高める考え方 / purpose abstraction design
minodriven
22
8.9k
『良いコード/悪いコードで学ぶ設計入門』を一歩深める読み方 / deepen good code bad code
minodriven
18
7k
風刺動画「一枚岩モデル」で考える、DDDの境界付けられたコンテキスト / huge model vs bc
minodriven
19
39k
Other Decks in Programming
See All in Programming
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
3
770
Mermaid x AST x 生成AI = コードとドキュメントの完全同期への道
shibuyamizuho
1
270
わたしの星のままで一番星になる ~ 出産を機にSIerからEC事業会社に転職した話 ~
kimura_m_29
0
200
StarlingMonkeyを触ってみた話 - 2024冬
syumai
3
280
テストケースの名前はどうつけるべきか?
orgachem
PRO
0
160
毎日13時間もかかるバッチ処理をたった3日で60%短縮するためにやったこと
sho_ssk_
1
360
Haze - Real time background blurring
chrisbanes
1
520
PHPUnitしか使ってこなかった 一般PHPerがPestに乗り換えた実録
mashirou1234
0
330
テストコード書いてみませんか?
onopon
2
210
Go の GC の不得意な部分を克服したい
taiyow
3
840
GitHubで育つ コラボレーション文化 : ニフティでのインナーソース挑戦事例 - 2024-12-16 GitHub Universe 2024 Recap in ZOZO
niftycorp
PRO
0
120
【re:Growth 2024】 Aurora DSQL をちゃんと話します!
maroon1st
0
810
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
32
2.7k
Making the Leap to Tech Lead
cromwellryan
133
9k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
The World Runs on Bad Software
bkeepers
PRO
66
11k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
910
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Navigating Team Friction
lara
183
15k
Bash Introduction
62gerente
609
210k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
For a Future-Friendly Web
brad_frost
175
9.4k
Producing Creativity
orderedlist
PRO
342
39k
Transcript
不幸を再生産しないための 設計に対する向き合い方 2022/08/20 READYFOR株式会社 ミノ駆動
おしながき • 自己紹介 • 本日のお題 • 私の失敗経験 • 失敗経験と学びの活用 •
モデリングと認知科学 • クロージング
こんにちは、ミノ駆動です
ここで働いています
最近ニュースになった クラウドファンディング
『良いコード/悪いコードで学ぶ設計入 門』の著者。 発売3ヶ月で第6刷目の重版。発行部数 2万部達成。 技術書で1万部超えればベストセラーと のことですが、それも超えてまだまだ売 れています。
もうちょっと詳しい職歴とか ミノ駆動 @MinoDriven 電子機器メーカーや大手精密機器メーカー、そし てクラウドワークスを経て、2021年4月に READYFOR株式会社にジョイン。 アプリケーションアーキテクトとして、レガシーシス テムのリファクタリングや拡張性向上設計など、シ ステム設計に従事。 『良いコード/悪いコードで学ぶ設計入門』の他、
クソコード動画シリーズの作者。
本日のお題
設計しないと不幸になる
そして より良い設計アプローチをしないと 不幸になる
私と同じ不幸を 再生産してほしくない そんな思いを伝える内容です
僕が体験した「不幸」とは?
プロジェクト炎上
日常的なプロジェクト炎上 派遣さんも含めて40-50人の開発体制。 仕様書通りに動作するよう、実装だけをひたすら繰り返し。 設計はほとんどしていないに等しい状態。 開発中、バグが大量に出る。バグを直した影響で他の箇所にバグ が発生するのは茶飯事。
残業40-60時間は当たり前。 体力ミジンコの私、疲れ果てる。
PL「つらい残業を乗り切れるよう、 昼休みにバスケをやって体力をつけよう!」
書籍『リファクタリング』との出会い
運命を変えた本『リファクタリング』 何か打開策はないものかと職場の本棚を 漁っていたら書籍『リファクタリング』を偶然発 見。「コードが理解しやすくなる」「バグが少な くなる」の記述を見て衝撃を覚えました。 仕事中、製品コードを利用し、裏でコソコソリ ファクタリングひたすら練習(※もちろんコミッ トはしてません)。
設計があまりに面白かったので、『ドメイン駆動設計』や『レガシーコード改善 ガイド』など設計関連の書籍を買い漁り、買いすぎだと嫁に叱られつつも、さら に設計スキルを高めていきました。
リファクタリングプロジェクト事件
リファクタリングプロジェクトの発足 先のソフトウェア製品が致命的なバグを何度も再発させてしまい、 大問題に。 設計レベルの見直しが必要と判断され、リファクタリングプロジェク トが発足する流れへ。私もいの一番で立候補する。
私の失敗 「全部リファクタリングするんだ」と、リソース、 コスト無視で推し進めようとした。 ガッチガチの設計ガイドラインを策定し、「全 部この通りに設計し直せ」と、各モジュールの 要件やトレードオフも考えずに、無理に押し 通そうとした。
リファクタリングプロジェクトに人を取られ、ただでさえ開発の鈍 化が懸念される中、無理強いをさせられた側からは不満が噴 出。 「ミノ駆動は学者風情の理想論者」などと陰口を言われるのも当 然だった。
設計でのつまづき まとめ • 組織全体でほとんど設計されていなかったために、バグが大 量に埋め込まれる事態が日常化していた。 • コスト戦略をろくに考えず、全体をリファクタリングしようとした。 • 厳格な設計ガイドラインを無理強いし、無用にハードルを高め てしまった。
当時は何がまずかったのか いろいろ分かってなかった……
わからん殺し 「わからん殺し」とは、対戦ゲームにおいて、相手側が対策できていない戦法で 一方的になぶり殺す事の俗称。やられた側からすると「よくわからない内に倒さ れていた」感覚。 何か上手くいかないときは、課題や解決方法が認識できていないことが多い。 今ある知識だけでなんとかしようとすると上手くいかない。「セルフわからん殺 し」に陥っている。 様々なことを学び直すキッカケになりました。
学び直しで得た知識の例 • 書籍『ドメイン駆動設計』 ◦ システムで最も価値を付加すべき「コアドメイン」の概念を知ったこと で、設計コストの選択と集中を学んだ。 • 書籍『レガシーソフトウェア改善ガイド』 ◦ リファクタリング対象の選定には、価値、難度、リスクの3軸で評価する
ことを学んだ。 ◦ チームから合意を得るための交渉のしかたを学んだ。 ◦ ソフトランディングするための進め方を学んだ。 etc…
失敗経験と学びをどう活かしているか
認識の共有
課題感の共有 「巨大なRailsアプリに蓄積した負債を解消し、開発生産性を向上 したい」 この課題を解決することのみに注力する設計であって、他の機能 開発を妨げたり、いたずらにリソースを食い潰すような意図はない ことを強調。
解決手段の理由や背景を共有 RailsはActiveRecordが中心であるために、随所でDB知識と密 結合になる。 Railsアプリが巨大化してくると、Rails-wayのやり方では辛くなっ てくる。 ゆえに打開策として、DDDの考え方を取り入れる。DB知識と疎結 合にする、よりビジネスに追従容易なドメイン層を形成するため。
選択と集中、コスト戦略の共有 変更頻度の高いコアな機能に設計コストを集中する。 負債の酷くない箇所や、コアでない箇所は従来通りRails-wayで 良い。無理はしない。
その他認識共有 勉強会で設計知識を共有 メンバーとの課題感、設計に対する認識合わせ スモールステップで実施 小さな成功体験の積み重ねと共有
説明コストはかなりかかりましたが 設計の理解を得られ ソフトランディングに成功しました
やったことは チームビルディングそのものでした
チームビルディングなくして設計は上手くいかない 高い 開発生産性 設計 チームビルディング ここをないがしろにすると、2階にあ る設計に登れない! 技術的負債と設計は認知困難だ からこそ、意思共有は丁寧に!
設計も常に学びの日々です
モデリングと認知科学 モデリングは設計の要です。 物事をどう見るかで概念の認識が変わりモデルも変化します。 より本質をついた、高品質なモデリングをするには、概念をどう解 釈するかを深く知る必要があります。 そのため私は最近、認知科学や哲学を勉強しています。
アクチュアル(現働的) ヴァーチャル(潜在的) 「自転車に乗る人」と「自転車」の、 物理的存在に囚われがち。 存在の脱構築 人 vs 自転車といった区別なく、全てのもの が複雑に関係し合う次元として解釈。モデリ ングで役に立つ考え方。
『現代思想入門』著:千葉雅也、 2022年刊行、講談社
物理的存在としてモ デリング 利用者 User 利用者:モデルが1:1では 巨大化複雑化し、 使いにくいモデルになりがち
存在の脱構築 利用者 購入側 アカウント 個人 プロフィール 認証 認可 出品側 アカウント
会員特典設定 物理的存在から離れ、役に立つ目的単位で モデリングすると、1:Nの関係性になる(こと がとても多い)。
エヴァンス本 シェアパイの例 ブレイクスルー シェアパイ ローン出資 ローン調整 「シェアパイ」という概念を見出したことで、ローンの金額計算誤差 や特殊ケースに対応するための複雑なロジックが消え去った。顧客 にもわかりやすい概念として定着した。
「売買契約」という法的概念とすることで支払条件(支払期日など) の存在を認知できる。法的な有効性を発揮できるモデルとなる。 商品購入?? 法的な意味付け 商品購入 ID 購入日時 受取希望日 売買契約 ID
契約締結日時 引渡希望日 支払期日 決済方法
クロージング
誰しも仕事で辛い局面に 立たされたことがあるはず
不貞腐れたり 誰かを恨んだり 仕事を投げ出したくなったり…
私は様々な失敗経験をないがしろにせず その後の開発などに活かしてきました
これまでの失敗がなければ この本は完成しなかったでしょう
失敗を放っておいて イヤな記憶として こびりつかせておくよりも…
どうせなら成功のために 活用した方がスッキリしますよね
どうやったら失敗を 上手く活用できるのだろう?
【重要】 失敗の活用には知恵が要る 知恵がないと失敗のまま腐り 不幸を再生産する
書籍『リファクタリング』でバグを埋め込みやすい構造とそうでない構造を見分 ける観点を獲得し、原因不明だったバグ頻発の原因を知りました。 書籍『ドメイン駆動設計』でコアドメインの概念を知り、闇雲に設計するのではな く、コアに集中する重要性を学びました。 書籍『レガシーソフトウェア改善ガイド』で、組織で設計を推進する上での戦略 性を知り、軋轢を生まずに設計改善をソフトランディングするノウハウを獲得し ました。 認知科学関連の書籍からの学びが、モデリングの精度向上に寄与しつつあり ます。
知恵は失敗を宝に変える
本日このあとの登壇者の発表や 様々な技術書から学びを深め 失敗を宝に変えていこう