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

Developers Summit 2021 Summer (2021/07/30)の登壇資料です。
https://event.shoeisha.jp/devsumi/20210730/session/3249/

Transcript

1. ビジネス考えてるかい？ 事業の持続的成長を促進させる システム設計の考え方 Jul 30, 2021 @ Developers Summit 2021 Summer READYFOR株式会社　仙塲 大也（ミノ駆動）
2. アジェンダ • 自己紹介 • 持続的成長とソフトウェア品質特性 • ビジネス理解の重要性に気付いた開発経験 • 持続的成長の減衰とビジネス目的減衰 • 目的駆動名前設計 • 目的ベースのモデリング • 機能性のイノベーション • イノベーションを目指す組織のあり方 • まとめ • おまけ
3. 自己紹介 ミノ駆動 @MinoDriven 仙塲 大也 電子機器メーカーや大手精密機器メーカー、そし てクラウドワークスを経て、2021年4月に READYFORにジョイン。 リファクタリングやドメインモデリングを主軸に、シ ステム設計に従事。 悪しき構造が招く凄惨な結末を風刺した「クソコー ド動画」シリーズの作者。Twitterに不定期で投稿 しています。
4. ビジネス考えてますか？ 事業を考えてエンジニアリングしてますか？
5. 「技術には興味があって楽しいよ。会社の事業の細かいことは良 くわからないけど、仕様書さえあれば、その通りに実装してみせま すよ」 …このような考えだと、システムの活力が減衰し、事業継続が困難 な状況に陥るかも知れません。
6. 本セッションで解説すること • ITサービスを用いた事業を持続的に成長させていく上で、ソフ トウェア品質が大きく影響する。 • ソフトウェア品質向上には、ビジネスを理解した設計が必要。
7. ITサービス事業の持続的成長とは サービスが利益を生み出し続けること、かつ利益拡大を継続していくこと。 身も蓋もなく言うとお金の話です。 これは、短期的な話ではありません。 長期的に成長を継続できるかどうかが です。
8. 長期的にです （大事なので繰り返しました）
9. ITサービスの持続的成長には ソフトウェア品質特性が関係します
10. ソフトウェア品質特性(JIS X 25010:2013) 品質特性 品質副特性 機能適合性 機能完全性、機能正確性、機能適切性 性能効率性 時間効率性、資源効率性、容量満足性 互換性 共存性、相互運用性 使用性 適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユーザーインター フェース快美性、アクセシビリティ 信頼性 成熟性、可用性、障害許容性、回復性 セキュリティ 機密性、インテグリティ、否認防止性、責任追跡性、真正性 保守性 モジュール性、再利用性、解析性、修正性、試験性 移植性 適応性、設置性、置換性
11. ソフトウェア品質特性(JIS X 25010:2013) 品質特性 品質副特性 機能適合性 機能完全性、機能正確性、機能適切性 性能効率性 時間効率性、資源効率性、容量満足性 互換性 共存性、相互運用性 使用性 適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユーザーインター フェース快美性、アクセシビリティ 信頼性 成熟性、可用性、障害許容性、回復性 セキュリティ 機密性、インテグリティ、否認防止性、責任追跡性、真正性 保守性 モジュール性、再利用性、解析性、 修正性、試験性 移植性 適応性、設置性、置換性 機能適合性（機能性）、修正性（変更容易性） が本セッションに関係します。
12. 機能性と変更容易性 品質特性 説明 機能適合性 （以後「機能性」と呼びます） 機能がニーズを満たす度合い。 修正性 （以後「変更容易性」と呼びます） 既存品質を低下させずに、有効的、効率的に システムを修正可能な度合い。
13. 損益の観点から見ると 品質特性 損益への影響 機能性 利益の増加に貢献。プラス要素の強化。 変更容易性 開発コストの低減に貢献。マイナス要素の低減。
14. アーキテクチャとは 特定のソフトウェア品質特性の促進を目的とした、システムの論理的構造。 促進の意味するところ： 放っておいても促され、影響を与え続けていくこと。たとえば交通の便が良いと街が発展 したり、水はけが悪いと作物の育ちが悪くなるなど。
15. アーキテクチャ設計に ビジネス知識が大きく貢献します
16. なぜ「ビジネス知識が大事」に行き着いたのか 私の開発経験と 直面してきた課題の振り返りをまじえて 説明します
17. 変更容易性、機能性 の順で説明します
18. 変更容易性
19. 変更容易性とは 開発コストの継続的な低減に貢献する品質特性。 この品質をおろそかにすると、コード理解困難、エンバグ頻発。変更の時間的コストやエ ンジニアの精神エネルギーコストが著しく増大。 バケツの底に穴が空いた状態に。サービスがせっかく利益を生んでも、かさんだ開発コ ストのために利益が薄くなる。下手すると赤字化。 サービスの維持はなんとかできても新機能の実装が困難に。事業の持続的成長が果た せなくなります。
20. ビジネス知識の重要性に気付くより前 私が設計の門を叩いたエピソード
21. レガシーコードとの遭遇
22. レガシーコードによる疲弊 あるシステム開発において、レガシーコード（保守や変更が困難な、変更容易性の 低いコード）に苦しめられたことがありました。 何か変更するとすぐバグ化。そして長時間労働の慢性化。 「なぜこれほどバグが頻発するのだろう」 「何が原因なのだろうか」 当時は何がマズいのか分からず、悩む日々が続きました。 ところがある日、転機が訪れます。
23. 書籍「リファクタリング」との出会い
24. 運命の書籍「リファクタリング」 私が設計の道を志すキッカケになった、私の運命を変え た本。 職場の本棚を漁っていたとき、偶然手にしました。 「コードが理解しやすくなる」 「バグが少なくなる」 の記述を目にしたとき、「これだ！」と衝撃をおぼえまし た。
25. リファクタリングの練習と設計スキル向上 プロダクションコードを使ってリファクタリング。 練習用のブランチを切って、裏でコソコソひたすらリファクタリングの練習を積み重 ねました。 プロダクションコードは複雑怪奇。実践レベルの設計スキルを磨くのにうってつけ。 コードが整理されていく有様があまりに面白くて、レガシーコード改善ガイドやドメイ ン駆動設計など設計技術書を買い漁っては実験する日々。 このとき最も設計スキルが伸びました。
26. ビジネス知識の重要性に気付いた エピソード　その１ あるべき設計構造
27. リファクタリングの限界 リファクタリングは途中まで順調で、コードはまあ まあ整理されました。 しかし整理したクラスには、依然として意味のよく 分からないロジックが混在しているものがありまし た。 「特殊計算クラス…？仕様書に特殊計算なんてな いぞ？お前は一体何をするクラスなんだ？お前 の正体は一体なんなんだ…？」 WorkflowManager 特殊計算クラス PersonInfo
28. ロジックの背景にあるビジネス知識を調査 特殊計算クラスに関係のあるロジックや仕様、ビジネス要件を調査。 以下の計算ロジックが含まれていることが分かりました。 ・商品の割引計算 ・商品の梱包サイズの計算 特殊計算クラス 商品の割引計算 商品の梱包サイズ計算
29. あるべき設計構造 「割引金額」クラス、「梱包サイズ」クラスに分解。 分かりやすくなった上に、イビツさが解消されました。 割引金額に依存していた他のクラスから、割引率を抽出することもできました。 ビジネス背景の分析により、あるべき構造を設計できました。 WorkflowManager 特殊計算クラス 割引率 割引金額 梱包サイズ 割引率
30. ビジネス知識の重要性に気付いた エピソード　その２ リファクタリングの費用対効果
31. リファクタリング推進時のコスト説明 リファクタリングを推進したとき、コストの説明を追求されたことがありました。 「コスト面でどんなメリットがあるのか」 「投資に値するものなのか」 「リファクタリングの箇所は妥当なのか」 「もっと費用対効果が高い箇所はないのか」 etc… はじめ、上手く説明できませんでした。 何のためにリファクタリングするのか整理することにしました。
32. リファクタリングは変更容易性を向上させる。 変更容易性が向上すると 将来の変更コストが低減する。 将来あまり変更されない箇所をリファクタリングしても 効果は薄い。 将来頻繁に変更され続ける箇所ほど 変更コスト低減効果が高い。
33. 開発リソースは有限。 無限にリファクタリングはできない。 将来頻繁に変更されそうな箇所を狙って リファクタリングする必要がある。 頻繁に変更されそうな箇所はどこか？ システムの主力となる部分 ビジネス的な価値が高く 競争優位性のある箇所
34. コアドメイン　利益の中心的源泉となるシステム化対象領域 ドメイン コアドメイン システム開発対象の ビジネス領域 ドメインの中で最も価値があ り、利益の源泉で、競争優 位性のある領域 ドメイン駆動設計(DDD)ではビジネスの最重要領域をコアドメインと位置づけ、アドメイ ンの価値が最大化するよう重点的に設計することを説いています。 コスト戦略の整理を経て、コアドメインの概念を知るキッカケになりました。 分かりやすく言うとサー ビスの一番のウリの部分
35. ビジネス知識の重要性に気付いた エピソード　その３ 機能性の損失
36. 機能性
37. 機能性とは 機能がニーズに適合している度合いを示す品質特性。 機能性が高いほど顧客ニーズを満足するものになり、顧客が対価を支払い、利益が向 上します。 ニーズの方向性とズレていたり、機能に不備があるものは機能性が低い。機能性の損 失は顧客離れを引き起こし、利益が低下してしまいます。
38. 特定状況で想定通りの動きにならないメカ制御 停止中 動作準備 動作中 停止準備 停止中 特定状況では 想定の動きに ならない あるメカ制御アプリの開発エピソードです。 メカの状態をステートマシンとして設計。Stateパターンを用いて、各Stateクラスに状態 ごとに対応するロジックをカプセル化しました。 しかし、ある特定状況で上手く動作しないことがありました。
39. 特定状況で想定通りの動きにならないメカ制御 停止中 動作準備 動作中 停止準備 停止中 しかし微妙にぎこ ちなさが残存 なんとか仕様通りに動くよう 無理矢理で不自然な ロジックを実装 なんとか仕様通りの動作になるよう、調整用の固定値を挿入したり、特殊なロジックを 追加したり、だましだまし動かすようなことをしていました。 しかしやはりどうしてもイビツさが解消できないケースが残存していました。
40. 外部仕様には現れない、メカの内部挙動 停止中 動作準備 動作中 停止準備 停止中 あるビジネスニーズを満足するために 一部特殊な動作をしている メカ部門に問い合わせたところ、外部仕様には現れない内部の特殊挙動がありまし た。その特殊挙動は、あるビジネスニーズに対応するものでした。
41. 状態クラスの設計改善により機能性を満足 停止中 動作準備 動作中 停止準備α 停止中 ビジネスニーズと内部挙動を考慮した状態クラスを再設計したところ、今度こそ仕 様通りに動作するようになりました。 なんとかだましだまし動かすためのいびつで不自然なロジックは不要になりまし た。 停止準備β ビジネスニーズと内部挙動を考 慮した状態クラスを再設計 不自然なロジックが 不要になった
42. モデリングと機能性 ビジネス理解が不十分だと、モデル設計に不備が生じ、機能性を発揮できなくなることを 学びました。 天動説では天体の挙動を上手く説明できません。 地球平面説では遠くのものが沈んで見えるなどの事象を上手く説明できません。 同様に、ビジネス理解が未熟な状態で考え出されたモデルは、課題を上手く解決でき ず、機能性に不備が生じます。 機能性の不備をなんとか解消しようとすると、なぜそうなるのか説明のつかない意味不 明なロジックを実装しかねないことを学びました。
43. 私の開発経験と学び　まとめ エピソード 品質特性 学び あるべき設計構造 変更容易性 ビジネス知識のおかげであるべき構造を設 計できた。 リファクタリングの 費用対効果 変更容易性 対象ビジネスの中心的価値の模索が、費 用対効果の高いリファクタリングスコープの 策定に役立った。 機能性の損失 機能性 背景のビジネスニーズを知ることで正しい 状態モデルを設計でき、機能性の満足に 貢献した。
44. 経験と学びから得たこと 本セッションで最も伝えたいこと
45. 事業の持続的成長の減衰は すなわち ビジネス目的の減衰
46. 私の開発経験と学び　振り返り エピソード 品質特性 学び あるべき設計構造 変更容易性 ビジネス知識のおかげであるべき構造を設 計できた。 リファクタリングの 費用対効果 変更容易性 対象ビジネスの中心的価値の模索が、費 用対効果の高いリファクタリングスコープの 策定に役立った。 機能性の損失 機能性 背景のビジネスニーズを知ることで正しい 状態モデルを設計でき、機能性の満足に 貢献した。 ビジネス目的（なぜ目的なのかは後述）を喪失していたら、これらの課題を解決できず、 持続的成長性に禍根を残す結果になっていたかもしれません。
47. ビジネス目的は様々な要因で減衰する
48. ビジネス目的は様々な要因で減衰する ビジネス 要求 ビジネス 要件 仕様 設計 実装 特にスタートアップ時は市場動 向や要求が不鮮明、 目的の解像度が悪い 要件に落とし込んだ段階で目 的が減衰する場合あり 仕様は目的達成の手段に過ぎな いので、目的を喪失しやすい 仕様を満たすためだけの、機械仕 掛けなロジックが書かれる
49. システムからのビジネス目的の減衰を いかに抑止し続けるか フレッシュなビジネス目的を システムにいかに適用し続けるか 事業の持続的成長において重要です
50. ビジネス目的の減衰を防ぎ ビジネス目的を推進する テクニック
51. 認知の歪み
52. 私たちはシステム化対象のビジネス概念を 正確に認知できていないことがままあります
53. 認知の歪みと意味不明なロジック レガシーコードが書かれてしまう開発では、目的の減衰が起こりやすくなっていま す。 ビジネス目的がろくに伝わらず、単に仕様書だけが渡され、仕様を満たすように実装 するだけになりがちです。 すると、私が経験してきたように、ビジネス目的を喪失した、技術駆動なクラス名や 意味不明なロジックになります。変更容易性が低下します。 WorkflowManager 特殊計算クラス PersonInfo
54. 裏に複数の概念が隠れていた事例 商品 取引履歴 注文 おすすめ商品 予約 巨大でイビツな商品クラスがありました。何に使われているのか目的を探り、正体を 暴き出したら、実は4つの概念がキメラになったクラスでした。 「おすすめ商品」が概念としてカスッているだけで、全く「商品」にそぐわない概念が 他に隠れていたのです。
55. 悪魔は正体を隠している はるか昔、人々は疫病の原因を悪魔のシワザと考えていました。悪魔と呼称し て、当時効果的に対処できていたでしょうか…？？のちに、細菌の発見により対 処方法が劇的に革新されました。 変更容易性や機能性を貶めるロジックは、悪魔のようなものです。 私が設計やリファクタリングするとき、ソースコードに常にこう問いかけています。
56. お前の正体はなんだ？
57. アンカリング効果に振り回されずに正体を見破る アンカリング効果： 最初に提示された情報が基準となってしまい、その後の判断を歪めてしまう認知バイア ス。 システム開発では、既存のクラス名やメソッド名が基準となってしまって、判断を歪めて いる事象となって現れています。 レガシーコードが書かれてしまう現場では本当に多くて、ほとんど誰もがアンカリング効 果から逃れられない状態に陥っています。 病原菌が原因なのに、「悪魔が…」「いや、ですから悪魔クラスが…」「ビョウゲンキンって なんだか分かんないけど、とにかく悪魔クラスがですね(怒)」こういうコミュニケーション がシステム開発では本当に多いです。
58. アンカリング効果に振り回されずに正体を見破る 一見妥当そうに見えるクラス名やメソッド名、ロジックであっても、一切信用しないように しています。 また、自分の認知が歪んでいる可能性もあるので、自分が書いたコードに対しても「お 前の正体はなんだ？」と問いかけるようにしています。 既存の構造や名前を完全に頭から消し飛ばして、ゼロベースで「あるべき」を追求する ことで、より精度の高い設計やリファクタリングを実施できます。 そして正体を暴くにあたって、さらに有用な考え方があります。それが…
59. 目的駆動名前設計 (Purpose Driven Name Design)
60. 目的駆動名前設計とは 私が勝手に提唱した名前の設計方法です。 （DDDの設計思想由来の名前設計） （そもそもオブジェクト指向のObjectが「目的」を意味し、「目的指向」なのではという 説もあり） プログラミングでは「良い名付けをしよう」とよく言われてはいます。 しかし可読性だけで話が止まっていたり、良い名前を付けたと思っても、名前が仇に なってクラス構造がイビツになることに疑問を覚え、発案しました。 システム上のビジネス目的の減衰防止、さらには目的促進を目指した名前設計の考 え方です。
61. 目的駆動名前設計とは • 設計要件 ◦ ビジネス目的を表現した名前であること。 ◦ 目的特化の名前であること。 ◦ 可能な限り意味範囲が狭く、ザルで曖昧な解釈を許容しない具体的な名 前であること。 • メリット ◦ ビジネス目的の減衰防止 ◦ 変更容易性向上 ◦ 機能性向上 ◦ 機能の発展性（イノベーション）への寄与
62. 「商品」は「売る目的」を表現していそうですが、特化してはいません。意味範囲が 広くて曖昧です。 「在庫品」「注文品」「発送品」など、より目的特化な名前を設計します。
63. 存在ベース、物ベースの命名やモデリングは上手く働かない ユーザー、金額、住所など、単に存在しているだけの、物をベースとした命名やモデリ ングは、どういった用途に対応するものなのか目的を喪失しやすい。 多くの場合は多目的に使われて混乱したり、用途不明で混乱したり、ときには巨大クラ ス化します。物ベースで目的不明なクラスを何と呼ぶかというと… 存在、物ベース 目的ベース ユーザー アカウント、プロフィール、職務経歴 名前 アカウント名、表示名、本名 金額 請求金額、原価、延滞料金、配送補償金額 住所 配送元、配送先、勤務先、本籍地
64. 目的不明オブジェクト (Unknown Purpose Object)
65. 目的不明オブジェクト（UPO）とは 私が勝手に提唱した概念です。 その名の通り目的のよくわからない、または多目的で使わ れているクラスをUPOと呼ぶことにします。 UPOに遭遇すると誘拐されて怪しい金属片を体内に埋め込 まれたり記憶を消されたりはしませんが、混乱することには 違いありません。 ただちに目的を分析し、目的ごとのクラスにリファクタリング することをオススメします。
66. 目的達成手段としてのモデル
67. 物としてモデリングすると低凝集に陥りがち 現実世界のモノを単にモデル化すると、モノの属性、つまりデータを格納するだけの モデルやクラスとして設計されがちです。 ロジックを持たずデータ保持だけするクラスをデータクラスと呼びます。データクラス があると、データを操作するロジックは別のクラスに実装され低凝集構造になりま す。低凝集は変更容易性低下を招きます。
68. モデルは物ではなく、目的達成の手段 モデルは、ひとつひとつが課題解決の仕組み を持った、ミクロなコンピュータです。それが 集まってシステムになります。 判断し、情報加工する手段をモデルは備えま す。 モデルを「特定目的達成の手段」と解釈すれ ば、データとデータを操作するロジックが凝集 し、変更容易性は向上します。 システム モデル (手段) モデル (手段) モデル (手段)
69. 目的駆動名前設計の練習
70. 「商品購入」 これの正体、真の姿ってわかります？
71. 売買契約の締結
72. 多くのECサイトやフリマサービスの利用規約では、商品購入操作を売買契約の締結 と定義付けています。法的な意味を持つようになり、重みが全く違ってきますね。 「購入」モデルではなく、「売買契約」モデルとなると、支払条件など契約上の属性が 必要になります。 もし、こうした法的な側面がシステム化されていないとどうなるでしょう？ 売り手と買い手になんらかのトラブルが発生した際、法的な有効性を発揮できず、ト ラブルを上手く解決できないシステムになってしまう可能性があります。機能性が損 失してしまいます。 機能性を上手く発揮するには、ビジネス概念の正体や、裏に隠れた重大な目的を見 破る必要があります。
73. 機能性のイノベーション
74. 機能性 0 ここまでの解説は、機能性の低減 をいかに防ぐか、という内容でし た。
75. 機能性 0 ここからは、機能性をさらに高めて イノベーションへ向かわせるお話を します。
76. 目的ベースのモデリングと 発展性
77. 物ベースモデリングと抽象化 サバ サンマ どう抽象化しますか？
78. 物ベースモデリングと抽象化 サバ サンマ 魚類
79. 物ベースモデリングと抽象化 サバ サンマ 豚 魚類 じゃあ豚が追加されたら？
80. 物ベースモデリングと抽象化 サバ サンマ 豚 魚類 動物 哺乳類 物ベースだと、抽象化ではなく単なる分類になりがち
81. モデルは「目的達成の手段」だと 述べました 「目的達成の手段」の観点で見ると 今までにない発展性が生まれます
82. 目的達成手段としてのモデルと抽象化 サバ サンマ 豚 栄養摂取手段 栄養摂取手段の目的を据えて抽象化すると、他の手段も考えられる
83. 目的達成手段としてのモデルと抽象化 サバ サンマ 豚 栄養摂取手段 「食べる」以外の手段も考えられる。 目的達成手段としてモデリング、そして抽象化すると、手段に発展性が生まれる 加工食品 点滴 胃ろう
84. 目的達成手段のイノベーション史：移動手段 二足歩行 馬車 鉄道 移動手段 自動車 飛行機 ？？？ 次はどうイノベートされ るのだろう？？
85. 目的達成手段のイノベーション史：運搬手段 手 手押し車 鉄道 運搬手段 トラック ドローン ？？？ 次はどうイノベートされ るのだろう？？
86. ソフトウェアイノベーションの例 BBS メール ブログ 情報拡散手段 SNS Twitterの リツイート ？？？ リツイートは、良くも悪くも話題性のあるツイートを爆発的に拡散する仕組み。 こうした本質を解決するモデルを、ドメイン駆動設計では深いモデルと呼びます。 深いモデルは機能性の革新に大きく貢献します。 私は深いモデルを発明、発見してイノベーションに貢献したいです。
87. 目的推進し イノベーションを目指す 組織のあり方
88. 真のビジネス目的を探し当てるのは至難の業 ビジネス理解 市場反応 顧客の声 仕様変更 リリース フィードバック 「顧客は自分がほしいものを知らない」と言われるように、真のビジネス目的 を探し当てるのは至難の業です。 このフィードバックサイクルを回して少しずつビジネス理解の解像度が向上 し、その先にやっと見えてくるものです。
89. ビジネス部門とエンジニアリング部門の分断 分 断 ビジネス部門とエンジニアリング部門がキッチリ分かれていると、ビジネス目的がエン ジニアリング部門に伝達しにくくなり、目的減衰が発生します。事業の持続的成長を 果たしていく上で課題となります。そこで…
90. 乳化
91. READYFORのチームビジョン「乳化」 組織の中にエンジニアリングが自然に溶け込んでいる状態、エンジニアリングとビジネスの近 接を実現するコンセプトが「乳化」。 フレッシュなビジネス知識を常にエンジニアリングへフィードバックし続けています。 ビジネス目的と一貫性のある設計を策定し、事業の持続的成長へつなげることを目指していま す。
92. 皆さんはこれから どう取り組みますか？
93. 考えてみよう システム開発する上で、目的減衰を防ぎ、目的推進する方法は他にないで しょうか？ 本セッションで紹介した手法は、あくまで手段の一部に過ぎません。 皆さんもいろいろ考えてみましょう。 事業の持続的成長の鍵が見つかるかも知れません。
94. まとめ
95. まとめ • ITサービスの持続的成長にはソフトウェア品質特性（変更容易性、機能性）が 関係する • 品質特性を促進するアーキテクチャ設計には、ビジネス知識が大きく貢献す る • 事業の持続的成長の減衰とは、すなわちビジネス目的の減衰 • 目的減衰防止と目的推進には様々な方法が考えられる ◦ 目的駆動名前設計と目的ベースのモデリングは、変更容易性と機能性 向上に貢献する ◦ 目的ベースのモデリングはイノベーションの可能性を秘めている ◦ READYFORでは「乳化」によりビジネスとエンジニアリングの近接を図っ ている
96. おまけ
97. 本を出版することになりました
98. アンチパターン駆動の設計技術書を出版します 悪しきコード、悪しき構造がどんな弊害をもたらすのか、そして解決にはどんな設 計構造に落とし込めば良いのかについて書いた本です。 サンプルコードを大量に用意しています。理論だけに終わらず、具体的なコードと してどうなれば良いのかを分かりやすく網羅している構成です。 本セッションで取り上げたビジネス目的周りについても、さらに詳細に解説してい ます。 技術評論社様より、年末年始ごろ全国出版予定です。
99. 私もはじめはレガシーコードを書いていました。でも何年もかけて設計を学び、咀 嚼し、仕事に活かしてここまで来ました。 この本には、私のこれまでの学び、皆さんに活かしてほしい知見が詰まっていま す。 是非お手に取っていただけると嬉しいです。
100. 私たちはやれる、必ずやれる みんなで事業を成長させていきましょう
101. ご清聴ありがとうございました