「オープンセミナー岡山2022」のイベント登壇で用いた資料です。 https://okayama.open-seminar.org/
不幸を再生産しないための設計に対する向き合い方2022/08/20READYFOR株式会社ミノ駆動
View Slide
おしながき● 自己紹介● 本日のお題● 私の失敗経験● 失敗経験と学びの活用● モデリングと認知科学● クロージング
こんにちは、ミノ駆動です
ここで働いています
最近ニュースになったクラウドファンディング
『良いコード／悪いコードで学ぶ設計入門』の著者。発売3ヶ月で第６刷目の重版。発行部数２万部達成。技術書で１万部超えればベストセラーとのことですが、それも超えてまだまだ売れています。
もうちょっと詳しい職歴とかミノ駆動@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利用者：モデルが１：１では巨大化複雑化し、使いにくいモデルになりがち
存在の脱構築利用者購入側アカウント個人プロフィール認証認可出品側アカウント会員特典設定物理的存在から離れ、役に立つ目的単位でモデリングすると、１：Nの関係性になる（ことがとても多い）。
エヴァンス本 シェアパイの例ブレイクスルー シェアパイローン出資ローン調整「シェアパイ」という概念を見出したことで、ローンの金額計算誤差や特殊ケースに対応するための複雑なロジックが消え去った。顧客にもわかりやすい概念として定着した。
「売買契約」という法的概念とすることで支払条件（支払期日など）の存在を認知できる。法的な有効性を発揮できるモデルとなる。商品購入？？法的な意味付け商品購入ID購入日時受取希望日売買契約ID契約締結日時引渡希望日支払期日決済方法
クロージング
誰しも仕事で辛い局面に立たされたことがあるはず
不貞腐れたり誰かを恨んだり仕事を投げ出したくなったり…
私は様々な失敗経験をないがしろにせずその後の開発などに活かしてきました
これまでの失敗がなければこの本は完成しなかったでしょう
失敗を放っておいてイヤな記憶としてこびりつかせておくよりも…
どうせなら成功のために活用した方がスッキリしますよね
どうやったら失敗を上手く活用できるのだろう？
【重要】失敗の活用には知恵が要る知恵がないと失敗のまま腐り不幸を再生産する
書籍『リファクタリング』でバグを埋め込みやすい構造とそうでない構造を見分ける観点を獲得し、原因不明だったバグ頻発の原因を知りました。書籍『ドメイン駆動設計』でコアドメインの概念を知り、闇雲に設計するのではなく、コアに集中する重要性を学びました。書籍『レガシーソフトウェア改善ガイド』で、組織で設計を推進する上での戦略性を知り、軋轢を生まずに設計改善をソフトランディングするノウハウを獲得しました。認知科学関連の書籍からの学びが、モデリングの精度向上に寄与しつつあります。
知恵は失敗を宝に変える
本日このあとの登壇者の発表や様々な技術書から学びを深め失敗を宝に変えていこう
minodriven
stanby_inc
loic425
pospome
hazumirr
antonicg
ivargrimstad
lhespanha
lanberb
kazuhitoyokoi
kizuku_miyagi
beenos
taowata
myddelton
mongodb
holman
caitiem20
quramy
brettharned
stephaniewalter
zakiwarfel
orderedlist
morganepeng
tanoku
garrettdimon