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.9k
不幸を再生産しないための設計に対する向き合い方
「オープンセミナー岡山2022」のイベント登壇で用いた資料です。
https://okayama.open-seminar.org/
MinoDriven
August 20, 2022
Tweet
Share
More Decks by MinoDriven
See All by MinoDriven
目的で駆動する、AI時代のアーキテクチャ設計 / purpose-driven-architecture
minodriven
11
5.2k
MCPサーバー「モディフィウス」で変更容易性の向上をスケールする / modifius
minodriven
12
2.1k
AI時代に必須!状況言語化スキル / ai-context-verbalization
minodriven
3
910
エンジニアとして高みを目指す、 利益を生み出す設計の考え方 / design-for-profit
minodriven
27
14k
AI時代のドメイン駆動設計-DDD実践におけるAI活用のあり方 / ddd-in-ai-era
minodriven
26
12k
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
27
12k
ソフトウェア品質特性、意識してますか?AIの真の力を引き出す活用事例 / ai-and-software-quality
minodriven
22
9.3k
プロフェッショナルとしての成長「問題の深掘り」が導く真のスキルアップ / issue-analysis-and-skill-up
minodriven
8
2.5k
『改訂新版 良いコード/悪いコードで学ぶ設計入門』活用方法−爆速でスキルアップする!効果的な学習アプローチ / effective-learning-of-good-code
minodriven
34
7.6k
Other Decks in Programming
See All in Programming
AI 駆動開発ライフサイクル(AI-DLC):ソフトウェアエンジニアリングの再構築 / AI-DLC Introduction
kanamasa
11
6k
CSC307 Lecture 06
javiergs
PRO
0
670
0→1 フロントエンド開発 Tips🚀 #レバテックMeetup
bengo4com
0
530
2026年 エンジニアリング自己学習法
yumechi
0
120
今から始めるClaude Code超入門
448jp
3
2.5k
なぜSQLはAIぽく見えるのか/why does SQL look AI like
florets1
0
400
16年目のピクシブ百科事典を支える最新の技術基盤 / The Modern Tech Stack Powering Pixiv Encyclopedia in its 16th Year
ahuglajbclajep
5
940
20260127_試行錯誤の結晶を1冊に。著者が解説 先輩データサイエンティストからの指南書 / author's_commentary_ds_instructions_guide
nash_efp
0
750
dchart: charts from deck markup
ajstarks
3
970
プロダクトオーナーから見たSOC2 _SOC2ゆるミートアップ#2
kekekenta
0
150
AI Agent Tool のためのバックエンドアーキテクチャを考える #encraft
izumin5210
6
1.7k
Apache Iceberg V3 and migration to V3
tomtanaka
0
110
Featured
See All Featured
Darren the Foodie - Storyboard
khoart
PRO
2
2.3k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
2k
Fashionably flexible responsive web design (full day workshop)
malarkey
408
66k
Mobile First: as difficult as doing things right
swwweet
225
10k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
51
For a Future-Friendly Web
brad_frost
182
10k
The Language of Interfaces
destraynor
162
26k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
14k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.3k
Amusing Abliteration
ianozsvald
0
90
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
契約締結日時 引渡希望日 支払期日 決済方法
クロージング
誰しも仕事で辛い局面に 立たされたことがあるはず
不貞腐れたり 誰かを恨んだり 仕事を投げ出したくなったり…
私は様々な失敗経験をないがしろにせず その後の開発などに活かしてきました
これまでの失敗がなければ この本は完成しなかったでしょう
失敗を放っておいて イヤな記憶として こびりつかせておくよりも…
どうせなら成功のために 活用した方がスッキリしますよね
どうやったら失敗を 上手く活用できるのだろう?
【重要】 失敗の活用には知恵が要る 知恵がないと失敗のまま腐り 不幸を再生産する
書籍『リファクタリング』でバグを埋め込みやすい構造とそうでない構造を見分 ける観点を獲得し、原因不明だったバグ頻発の原因を知りました。 書籍『ドメイン駆動設計』でコアドメインの概念を知り、闇雲に設計するのではな く、コアに集中する重要性を学びました。 書籍『レガシーソフトウェア改善ガイド』で、組織で設計を推進する上での戦略 性を知り、軋轢を生まずに設計改善をソフトランディングするノウハウを獲得し ました。 認知科学関連の書籍からの学びが、モデリングの精度向上に寄与しつつあり ます。
知恵は失敗を宝に変える
本日このあとの登壇者の発表や 様々な技術書から学びを深め 失敗を宝に変えていこう