ビジネス考えてるかい？事業の持続的成長を促進させるシステム設計の考え方 / buisiness_purpose_system_design

by MinoDriven

Slide 1

Slide 1 text

ビジネス考えてるかい？事業の持続的成長を促進させるシステム設計の考え方 Jul 30, 2021 @ Developers Summit 2021 Summer READYFOR株式会社　仙塲大也（ミノ駆動）

Slide 2

Slide 2 text

アジェンダ ● 自己紹介 ● 持続的成長とソフトウェア品質特性 ● ビジネス理解の重要性に気付いた開発経験 ● 持続的成長の減衰とビジネス目的減衰 ● 目的駆動名前設計 ● 目的ベースのモデリング ● 機能性のイノベーション ● イノベーションを目指す組織のあり方 ● まとめ ● おまけ

Slide 3

Slide 3 text

自己紹介ミノ駆動 @MinoDriven 仙塲大也電子機器メーカーや大手精密機器メーカー、そしてクラウドワークスを経て、2021年4月に READYFORにジョイン。リファクタリングやドメインモデリングを主軸に、システム設計に従事。悪しき構造が招く凄惨な結末を風刺した「クソコード動画」シリーズの作者。Twitterに不定期で投稿しています。

Slide 4

Slide 4 text

ビジネス考えてますか？事業を考えてエンジニアリングしてますか？

Slide 5

Slide 5 text

「技術には興味があって楽しいよ。会社の事業の細かいことは良くわからないけど、仕様書さえあれば、その通りに実装してみせますよ」 …このような考えだと、システムの活力が減衰し、事業継続が困難な状況に陥るかも知れません。

Slide 6

Slide 6 text

本セッションで解説すること ● ITサービスを用いた事業を持続的に成長させていく上で、ソフトウェア品質が大きく影響する。 ● ソフトウェア品質向上には、ビジネスを理解した設計が必要。

Slide 7

Slide 7 text

ITサービス事業の持続的成長とはサービスが利益を生み出し続けること、かつ利益拡大を継続していくこと。身も蓋もなく言うとお金の話です。これは、短期的な話ではありません。長期的に成長を継続できるかどうかがです。

Slide 8

Slide 8 text

長期的にです（大事なので繰り返しました）

Slide 9

Slide 9 text

ITサービスの持続的成長にはソフトウェア品質特性が関係します

Slide 10

Slide 10 text

ソフトウェア品質特性(JIS X 25010:2013) 品質特性品質副特性機能適合性機能完全性、機能正確性、機能適切性性能効率性時間効率性、資源効率性、容量満足性互換性共存性、相互運用性使用性適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユーザーインターフェース快美性、アクセシビリティ信頼性成熟性、可用性、障害許容性、回復性セキュリティ機密性、インテグリティ、否認防止性、責任追跡性、真正性保守性モジュール性、再利用性、解析性、修正性、試験性移植性適応性、設置性、置換性

Slide 11

Slide 11 text

Slide 12

Slide 12 text

機能性と変更容易性品質特性説明機能適合性（以後「機能性」と呼びます）機能がニーズを満たす度合い。修正性（以後「変更容易性」と呼びます）既存品質を低下させずに、有効的、効率的にシステムを修正可能な度合い。

Slide 13

Slide 13 text

損益の観点から見ると品質特性損益への影響機能性利益の増加に貢献。プラス要素の強化。変更容易性開発コストの低減に貢献。マイナス要素の低減。

Slide 14

Slide 14 text

アーキテクチャとは特定のソフトウェア品質特性の促進を目的とした、システムの論理的構造。促進の意味するところ：放っておいても促され、影響を与え続けていくこと。たとえば交通の便が良いと街が発展したり、水はけが悪いと作物の育ちが悪くなるなど。

Slide 15

Slide 15 text

アーキテクチャ設計にビジネス知識が大きく貢献します

Slide 16

Slide 16 text

なぜ「ビジネス知識が大事」に行き着いたのか私の開発経験と直面してきた課題の振り返りをまじえて説明します

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

リファクタリングの限界リファクタリングは途中まで順調で、コードはまあまあ整理されました。しかし整理したクラスには、依然として意味のよく分からないロジックが混在しているものがありました。「特殊計算クラス…？仕様書に特殊計算なんてないぞ？お前は一体何をするクラスなんだ？お前の正体は一体なんなんだ…？」 WorkflowManager 特殊計算クラス PersonInfo

Slide 28

Slide 28 text

ロジックの背景にあるビジネス知識を調査特殊計算クラスに関係のあるロジックや仕様、ビジネス要件を調査。以下の計算ロジックが含まれていることが分かりました。・商品の割引計算・商品の梱包サイズの計算特殊計算クラス商品の割引計算商品の梱包サイズ計算

Slide 29

Slide 29 text

あるべき設計構造「割引金額」クラス、「梱包サイズ」クラスに分解。分かりやすくなった上に、イビツさが解消されました。割引金額に依存していた他のクラスから、割引率を抽出することもできました。ビジネス背景の分析により、あるべき構造を設計できました。 WorkflowManager 特殊計算クラス割引率割引金額梱包サイズ割引率

Slide 30

Slide 30 text

ビジネス知識の重要性に気付いたエピソード　その２リファクタリングの費用対効果

Slide 31

Slide 31 text

リファクタリング推進時のコスト説明リファクタリングを推進したとき、コストの説明を追求されたことがありました。「コスト面でどんなメリットがあるのか」「投資に値するものなのか」「リファクタリングの箇所は妥当なのか」「もっと費用対効果が高い箇所はないのか」 etc… はじめ、上手く説明できませんでした。何のためにリファクタリングするのか整理することにしました。

Slide 32

Slide 32 text

リファクタリングは変更容易性を向上させる。変更容易性が向上すると将来の変更コストが低減する。将来あまり変更されない箇所をリファクタリングしても効果は薄い。将来頻繁に変更され続ける箇所ほど変更コスト低減効果が高い。

Slide 33

Slide 33 text

開発リソースは有限。無限にリファクタリングはできない。将来頻繁に変更されそうな箇所を狙ってリファクタリングする必要がある。頻繁に変更されそうな箇所はどこか？システムの主力となる部分ビジネス的な価値が高く競争優位性のある箇所

Slide 34

Slide 34 text

コアドメイン　利益の中心的源泉となるシステム化対象領域ドメインコアドメインシステム開発対象のビジネス領域ドメインの中で最も価値があり、利益の源泉で、競争優位性のある領域ドメイン駆動設計(DDD)ではビジネスの最重要領域をコアドメインと位置づけ、アドメインの価値が最大化するよう重点的に設計することを説いています。コスト戦略の整理を経て、コアドメインの概念を知るキッカケになりました。分かりやすく言うとサービスの一番のウリの部分

Slide 35

Slide 35 text

ビジネス知識の重要性に気付いたエピソード　その３機能性の損失

Slide 36

Slide 36 text

機能性

Slide 37

Slide 37 text

機能性とは機能がニーズに適合している度合いを示す品質特性。機能性が高いほど顧客ニーズを満足するものになり、顧客が対価を支払い、利益が向上します。ニーズの方向性とズレていたり、機能に不備があるものは機能性が低い。機能性の損失は顧客離れを引き起こし、利益が低下してしまいます。

Slide 38

Slide 38 text

特定状況で想定通りの動きにならないメカ制御停止中動作準備動作中停止準備停止中特定状況では想定の動きにならないあるメカ制御アプリの開発エピソードです。メカの状態をステートマシンとして設計。Stateパターンを用いて、各Stateクラスに状態ごとに対応するロジックをカプセル化しました。しかし、ある特定状況で上手く動作しないことがありました。

Slide 39

Slide 39 text

特定状況で想定通りの動きにならないメカ制御停止中動作準備動作中停止準備停止中しかし微妙にぎこちなさが残存なんとか仕様通りに動くよう無理矢理で不自然なロジックを実装なんとか仕様通りの動作になるよう、調整用の固定値を挿入したり、特殊なロジックを追加したり、だましだまし動かすようなことをしていました。しかしやはりどうしてもイビツさが解消できないケースが残存していました。

Slide 40

Slide 40 text

外部仕様には現れない、メカの内部挙動停止中動作準備動作中停止準備停止中あるビジネスニーズを満足するために一部特殊な動作をしているメカ部門に問い合わせたところ、外部仕様には現れない内部の特殊挙動がありました。その特殊挙動は、あるビジネスニーズに対応するものでした。

Slide 41

Slide 41 text

状態クラスの設計改善により機能性を満足停止中動作準備動作中停止準備α 停止中ビジネスニーズと内部挙動を考慮した状態クラスを再設計したところ、今度こそ仕様通りに動作するようになりました。なんとかだましだまし動かすためのいびつで不自然なロジックは不要になりました。停止準備β ビジネスニーズと内部挙動を考慮した状態クラスを再設計不自然なロジックが不要になった

Slide 42

Slide 42 text

モデリングと機能性ビジネス理解が不十分だと、モデル設計に不備が生じ、機能性を発揮できなくなることを学びました。天動説では天体の挙動を上手く説明できません。地球平面説では遠くのものが沈んで見えるなどの事象を上手く説明できません。同様に、ビジネス理解が未熟な状態で考え出されたモデルは、課題を上手く解決できず、機能性に不備が生じます。機能性の不備をなんとか解消しようとすると、なぜそうなるのか説明のつかない意味不明なロジックを実装しかねないことを学びました。

Slide 43

Slide 43 text

私の開発経験と学び　まとめエピソード品質特性学びあるべき設計構造変更容易性ビジネス知識のおかげであるべき構造を設計できた。リファクタリングの費用対効果変更容易性対象ビジネスの中心的価値の模索が、費用対効果の高いリファクタリングスコープの策定に役立った。機能性の損失機能性背景のビジネスニーズを知ることで正しい状態モデルを設計でき、機能性の満足に貢献した。

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

認知の歪みと意味不明なロジックレガシーコードが書かれてしまう開発では、目的の減衰が起こりやすくなっています。ビジネス目的がろくに伝わらず、単に仕様書だけが渡され、仕様を満たすように実装するだけになりがちです。すると、私が経験してきたように、ビジネス目的を喪失した、技術駆動なクラス名や意味不明なロジックになります。変更容易性が低下します。 WorkflowManager 特殊計算クラス PersonInfo

Slide 54

Slide 54 text

裏に複数の概念が隠れていた事例商品取引履歴注文おすすめ商品予約巨大でイビツな商品クラスがありました。何に使われているのか目的を探り、正体を暴き出したら、実は4つの概念がキメラになったクラスでした。「おすすめ商品」が概念としてカスッているだけで、全く「商品」にそぐわない概念が他に隠れていたのです。

Slide 55

Slide 55 text

悪魔は正体を隠しているはるか昔、人々は疫病の原因を悪魔のシワザと考えていました。悪魔と呼称して、当時効果的に対処できていたでしょうか…？？のちに、細菌の発見により対処方法が劇的に革新されました。変更容易性や機能性を貶めるロジックは、悪魔のようなものです。私が設計やリファクタリングするとき、ソースコードに常にこう問いかけています。

Slide 56

Slide 56 text

お前の正体はなんだ？

Slide 57

Slide 57 text

アンカリング効果に振り回されずに正体を見破るアンカリング効果：最初に提示された情報が基準となってしまい、その後の判断を歪めてしまう認知バイアス。システム開発では、既存のクラス名やメソッド名が基準となってしまって、判断を歪めている事象となって現れています。レガシーコードが書かれてしまう現場では本当に多くて、ほとんど誰もがアンカリング効果から逃れられない状態に陥っています。病原菌が原因なのに、「悪魔が…」「いや、ですから悪魔クラスが…」「ビョウゲンキンってなんだか分かんないけど、とにかく悪魔クラスがですね(怒)」こういうコミュニケーションがシステム開発では本当に多いです。

Slide 58

Slide 58 text

アンカリング効果に振り回されずに正体を見破る一見妥当そうに見えるクラス名やメソッド名、ロジックであっても、一切信用しないようにしています。また、自分の認知が歪んでいる可能性もあるので、自分が書いたコードに対しても「お前の正体はなんだ？」と問いかけるようにしています。既存の構造や名前を完全に頭から消し飛ばして、ゼロベースで「あるべき」を追求することで、より精度の高い設計やリファクタリングを実施できます。そして正体を暴くにあたって、さらに有用な考え方があります。それが…

Slide 59

Slide 59 text

目的駆動名前設計 (Purpose Driven Name Design)

Slide 60

Slide 60 text

目的駆動名前設計とは私が勝手に提唱した名前の設計方法です。（DDDの設計思想由来の名前設計）（そもそもオブジェクト指向のObjectが「目的」を意味し、「目的指向」なのではという説もあり）プログラミングでは「良い名付けをしよう」とよく言われてはいます。しかし可読性だけで話が止まっていたり、良い名前を付けたと思っても、名前が仇になってクラス構造がイビツになることに疑問を覚え、発案しました。システム上のビジネス目的の減衰防止、さらには目的促進を目指した名前設計の考え方です。

Slide 61

Slide 61 text

目的駆動名前設計とは ● 設計要件 ○ ビジネス目的を表現した名前であること。 ○ 目的特化の名前であること。 ○ 可能な限り意味範囲が狭く、ザルで曖昧な解釈を許容しない具体的な名前であること。 ● メリット ○ ビジネス目的の減衰防止 ○ 変更容易性向上 ○ 機能性向上 ○ 機能の発展性（イノベーション）への寄与

Slide 62

Slide 62 text

「商品」は「売る目的」を表現していそうですが、特化してはいません。意味範囲が広くて曖昧です。「在庫品」「注文品」「発送品」など、より目的特化な名前を設計します。

Slide 63

Slide 63 text

存在ベース、物ベースの命名やモデリングは上手く働かないユーザー、金額、住所など、単に存在しているだけの、物をベースとした命名やモデリングは、どういった用途に対応するものなのか目的を喪失しやすい。多くの場合は多目的に使われて混乱したり、用途不明で混乱したり、ときには巨大クラス化します。物ベースで目的不明なクラスを何と呼ぶかというと… 存在、物ベース目的ベースユーザーアカウント、プロフィール、職務経歴名前アカウント名、表示名、本名金額請求金額、原価、延滞料金、配送補償金額住所配送元、配送先、勤務先、本籍地

Slide 64

Slide 64 text

目的不明オブジェクト (Unknown Purpose Object)

Slide 65

Slide 65 text

目的不明オブジェクト（UPO）とは私が勝手に提唱した概念です。その名の通り目的のよくわからない、または多目的で使われているクラスをUPOと呼ぶことにします。 UPOに遭遇すると誘拐されて怪しい金属片を体内に埋め込まれたり記憶を消されたりはしませんが、混乱することには違いありません。ただちに目的を分析し、目的ごとのクラスにリファクタリングすることをオススメします。

Slide 66

Slide 66 text

目的達成手段としてのモデル

Slide 67

Slide 67 text

物としてモデリングすると低凝集に陥りがち現実世界のモノを単にモデル化すると、モノの属性、つまりデータを格納するだけのモデルやクラスとして設計されがちです。ロジックを持たずデータ保持だけするクラスをデータクラスと呼びます。データクラスがあると、データを操作するロジックは別のクラスに実装され低凝集構造になります。低凝集は変更容易性低下を招きます。

Slide 68

Slide 68 text

モデルは物ではなく、目的達成の手段モデルは、ひとつひとつが課題解決の仕組みを持った、ミクロなコンピュータです。それが集まってシステムになります。判断し、情報加工する手段をモデルは備えます。モデルを「特定目的達成の手段」と解釈すれば、データとデータを操作するロジックが凝集し、変更容易性は向上します。システムモデル (手段) モデル (手段) モデル (手段)

Slide 69

Slide 69 text

目的駆動名前設計の練習

Slide 70

Slide 70 text

「商品購入」これの正体、真の姿ってわかります？

Slide 71

Slide 71 text

売買契約の締結

Slide 72

Slide 72 text

多くのECサイトやフリマサービスの利用規約では、商品購入操作を売買契約の締結と定義付けています。法的な意味を持つようになり、重みが全く違ってきますね。「購入」モデルではなく、「売買契約」モデルとなると、支払条件など契約上の属性が必要になります。もし、こうした法的な側面がシステム化されていないとどうなるでしょう？売り手と買い手になんらかのトラブルが発生した際、法的な有効性を発揮できず、トラブルを上手く解決できないシステムになってしまう可能性があります。機能性が損失してしまいます。機能性を上手く発揮するには、ビジネス概念の正体や、裏に隠れた重大な目的を見破る必要があります。

Slide 73

Slide 73 text

機能性のイノベーション

Slide 74

Slide 74 text

機能性 0 ここまでの解説は、機能性の低減をいかに防ぐか、という内容でした。

Slide 75

Slide 75 text

機能性 0 ここからは、機能性をさらに高めてイノベーションへ向かわせるお話をします。

Slide 76

Slide 76 text

目的ベースのモデリングと発展性

Slide 77

Slide 77 text

物ベースモデリングと抽象化サバサンマどう抽象化しますか？

Slide 78

Slide 78 text

物ベースモデリングと抽象化サバサンマ魚類

Slide 79

Slide 79 text

物ベースモデリングと抽象化サバサンマ豚魚類じゃあ豚が追加されたら？

Slide 80

Slide 80 text

物ベースモデリングと抽象化サバサンマ豚魚類動物哺乳類物ベースだと、抽象化ではなく単なる分類になりがち

Slide 81

Slide 81 text

モデルは「目的達成の手段」だと述べました「目的達成の手段」の観点で見ると今までにない発展性が生まれます

Slide 82

Slide 82 text

目的達成手段としてのモデルと抽象化サバサンマ豚栄養摂取手段栄養摂取手段の目的を据えて抽象化すると、他の手段も考えられる

Slide 83

Slide 83 text

目的達成手段としてのモデルと抽象化サバサンマ豚栄養摂取手段「食べる」以外の手段も考えられる。目的達成手段としてモデリング、そして抽象化すると、手段に発展性が生まれる加工食品点滴胃ろう

Slide 84

Slide 84 text

目的達成手段のイノベーション史：移動手段二足歩行馬車鉄道移動手段自動車飛行機？？？次はどうイノベートされるのだろう？？

Slide 85

Slide 85 text

目的達成手段のイノベーション史：運搬手段手手押し車鉄道運搬手段トラックドローン？？？次はどうイノベートされるのだろう？？

Slide 86

Slide 86 text

ソフトウェアイノベーションの例 BBS メールブログ情報拡散手段 SNS Twitterのリツイート？？？リツイートは、良くも悪くも話題性のあるツイートを爆発的に拡散する仕組み。こうした本質を解決するモデルを、ドメイン駆動設計では深いモデルと呼びます。深いモデルは機能性の革新に大きく貢献します。私は深いモデルを発明、発見してイノベーションに貢献したいです。

Slide 87

Slide 87 text

目的推進しイノベーションを目指す組織のあり方

Slide 88

Slide 88 text

真のビジネス目的を探し当てるのは至難の業ビジネス理解市場反応顧客の声仕様変更リリースフィードバック「顧客は自分がほしいものを知らない」と言われるように、真のビジネス目的を探し当てるのは至難の業です。このフィードバックサイクルを回して少しずつビジネス理解の解像度が向上し、その先にやっと見えてくるものです。

Slide 89

Slide 89 text

ビジネス部門とエンジニアリング部門の分断分断ビジネス部門とエンジニアリング部門がキッチリ分かれていると、ビジネス目的がエンジニアリング部門に伝達しにくくなり、目的減衰が発生します。事業の持続的成長を果たしていく上で課題となります。そこで…

Slide 90

Slide 90 text

乳化

Slide 91

Slide 91 text

READYFORのチームビジョン「乳化」組織の中にエンジニアリングが自然に溶け込んでいる状態、エンジニアリングとビジネスの近接を実現するコンセプトが「乳化」。フレッシュなビジネス知識を常にエンジニアリングへフィードバックし続けています。ビジネス目的と一貫性のある設計を策定し、事業の持続的成長へつなげることを目指しています。

Slide 92

Slide 92 text

皆さんはこれからどう取り組みますか？

Slide 93

Slide 93 text

考えてみようシステム開発する上で、目的減衰を防ぎ、目的推進する方法は他にないでしょうか？本セッションで紹介した手法は、あくまで手段の一部に過ぎません。皆さんもいろいろ考えてみましょう。事業の持続的成長の鍵が見つかるかも知れません。

Slide 94

Slide 94 text

まとめ

Slide 95

Slide 95 text

まとめ ● ITサービスの持続的成長にはソフトウェア品質特性（変更容易性、機能性）が関係する ● 品質特性を促進するアーキテクチャ設計には、ビジネス知識が大きく貢献する ● 事業の持続的成長の減衰とは、すなわちビジネス目的の減衰 ● 目的減衰防止と目的推進には様々な方法が考えられる ○ 目的駆動名前設計と目的ベースのモデリングは、変更容易性と機能性向上に貢献する ○ 目的ベースのモデリングはイノベーションの可能性を秘めている ○ READYFORでは「乳化」によりビジネスとエンジニアリングの近接を図っている

Slide 96

Slide 96 text

おまけ

Slide 97

Slide 97 text

本を出版することになりました

Slide 98

Slide 98 text

アンチパターン駆動の設計技術書を出版します悪しきコード、悪しき構造がどんな弊害をもたらすのか、そして解決にはどんな設計構造に落とし込めば良いのかについて書いた本です。サンプルコードを大量に用意しています。理論だけに終わらず、具体的なコードとしてどうなれば良いのかを分かりやすく網羅している構成です。本セッションで取り上げたビジネス目的周りについても、さらに詳細に解説しています。技術評論社様より、年末年始ごろ全国出版予定です。

Slide 99

Slide 99 text

私もはじめはレガシーコードを書いていました。でも何年もかけて設計を学び、咀嚼し、仕事に活かしてここまで来ました。この本には、私のこれまでの学び、皆さんに活かしてほしい知見が詰まっています。是非お手に取っていただけると嬉しいです。

Slide 100

Slide 100 text

私たちはやれる、必ずやれるみんなで事業を成長させていきましょう

Slide 101

Slide 101 text

ご清聴ありがとうございました