もう一度、事業を支えるシステムに。

by Tech Leverages

Slide 1

Slide 1 text

もう一度、事業を支えるシステムに。〜基幹システムの復活〜

Slide 2

Slide 2 text

Slide 3

Slide 3 text

レバテックについて

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

本題もう一度、事業を支えるシステムに。

Slide 8

Slide 8 text

Slide 9

Slide 9 text

|　© Leverages inc. 9 レバテックには長年事業を支えてきた営業支援システムがある導入営業支援システムくん

Slide 10

Slide 10 text

|　© Leverages inc. 10 時間が経つにつれ複雑性は増し、変更容易性は下がっていった導入機能追加！新事業でも使いたい！ Aシステムと連携して！

Slide 11

Slide 11 text

|　© Leverages inc. 11 このままでは事業の成長についていけない導入

Slide 12

Slide 12 text

|　© Leverages inc. 12 事業を支えることができない！

Slide 13

Slide 13 text

|　© Leverages inc. 13 なんとかして！

Slide 14

Slide 14 text

|　© Leverages inc. 14

Slide 15

Slide 15 text

|　© Leverages inc. 15 ドメインを絞って段階的にリプレースするのはどうだろう

Slide 16

Slide 16 text

|　© Leverages inc. 16 営業支援システムは複数事業にまたがる大きなシステムなので、丸ごとリプレースするには規模が大きすぎる。なぜドメインを絞るのか「ドメインを絞って」段階的にリプレースする A事業 B事業 C事業営業支援システムくん

Slide 17

Slide 17 text

|　© Leverages inc. 17 リプレース対象にする事業を決め、そこから対象にするドメインを決めるのが良さそう。どうやって規模を小さくするか「ドメインを絞って」段階的にリプレースする A事業 B事業 C事業好きな事業を選ぶんじゃ

Slide 18

Slide 18 text

|　© Leverages inc. 18 主力事業であり、変更容易性を上げられた時の価値が高い。対象事業はフリーランス事業に即決定「ドメインを絞って」段階的にリプレースするすんなり決定

Slide 19

Slide 19 text

|　© Leverages inc. 19 事業がどのようなドメインで構成されるのかわかっていない状態次に、対象ドメインを決めたいが・・・「ドメインを絞って」段階的にリプレースする

Slide 20

Slide 20 text

|　© Leverages inc. 20 ● 以下の理由から別アプローチを取ることにセオリーではイベントストーミングやコンテキストマッピングを経てドメインを分けるべき「ドメインを絞って」段階的にリプレースする

Slide 21

Slide 21 text

|　© Leverages inc. 21 ● 以下の理由から別アプローチを取ることに ○ 分業が進み全てを把握しているドメインエキスパートがいないセオリーではイベントストーミングやコンテキストマッピングを経てドメインを分けるべき「ドメインを絞って」段階的にリプレースする

Slide 22

Slide 22 text

|　© Leverages inc. 22 ● 以下の理由から別アプローチを取ることに ○ 分業が進み全てを把握しているドメインエキスパートがいない ○ 複数人を巻き込む必要がありコミュニケーションコストが高いセオリーではイベントストーミングやコンテキストマッピングを経てドメインを分けるべき「ドメインを絞って」段階的にリプレースする

Slide 23

Slide 23 text

|　© Leverages inc. 23 ● 以下の理由から別アプローチを取ることに ○ 分業が進み全てを把握しているドメインエキスパートがいない ○ 複数人を巻き込む必要がありコミュニケーションコストが高い ○ 関係者の時間を奪う割に求めるアウトプットが得られる保証がないセオリーではイベントストーミングやコンテキストマッピングを経てドメインを分けるべき「ドメインを絞って」段階的にリプレースする

Slide 24

Slide 24 text

|　© Leverages inc. 24 ● 以下の理由から別アプローチを取ることに ○ 分業が進み全てを把握しているドメインエキスパートがいない ○ 複数人を巻き込む必要がありコミュニケーションコストが高い ○ 関係者の時間を奪う割に求めるアウトプットが得られる保証がない ○ そういった不確実な活動に巻き込めるだけの信頼貯金がない ※他にもいくつか背景があったセオリーではイベントストーミングやコンテキストマッピングを経てドメインを分けるべき「ドメインを絞って」段階的にリプレースする

Slide 25

Slide 25 text

|　© Leverages inc. 25 事業のボトルネックにフォーカスする

Slide 26

Slide 26 text

|　© Leverages inc. 26 ● 制約理論において出てくる概念 ● ボトルネック（制約）を改善しない限り、全体のスループットは改善されないボトルネックとは事業のボトルネックにフォーカスする The Goal コミック版 https://www.diamond.co.jp/book/9784478039397.html

Slide 27

Slide 27 text

|　© Leverages inc. 27 フリーランス事業は人材数・案件数・マッチング効率の3つの要素で構成される事業のボトルネックにフォーカスする人材数案件数マッチング効率 ※正確には他要素もあるが割愛

Slide 28

Slide 28 text

|　© Leverages inc. 28 フリーランス事業は人材数・案件数・マッチング効率の3つの要素で構成される事業のボトルネックにフォーカスする人材数

Slide 29

Slide 29 text

|　© Leverages inc. 29 フリーランス事業は人材数・案件数・マッチング効率の3つの要素で構成される事業のボトルネックにフォーカスする案件数

Slide 30

Slide 30 text

|　© Leverages inc. 30 フリーランス事業は人材数・案件数・マッチング効率の3つの要素で構成される事業のボトルネックにフォーカスするマッチング効率

Slide 31

Slide 31 text

|　© Leverages inc. 31 案件数が少ない状況で、人材数を増やす施策を打つと？ボトルネックの例人材数案件数マッチング効率

Slide 32

Slide 32 text

|　© Leverages inc. 32 案件が見つからない人材が増えてしまう！ボトルネックの例人材数案件数マッチング効率＼案件ないよ〜／＼案件不足！／

Slide 33

Slide 33 text

|　© Leverages inc. 33 案件が見つからない人材が増えてしまう！ボトルネックの例人材数案件数マッチング効率＼案件ないよ〜／＼案件不足！／つまり、「案件数」がボトルネック！

Slide 34

Slide 34 text

|　© Leverages inc. 34 事業はボトルネックを改善したい改善するためのアクションが増えるシステムの変更も増えるので、変更容易性を上げる価値が高いなぜボトルネックにフォーカスするのか事業のボトルネックにフォーカスする

Slide 35

Slide 35 text

|　© Leverages inc. 35 対象ドメインは「案件」に決定事業のボトルネックにフォーカスする実際に、案件数がフリーランス事業のボトルネックになっていた。 ※なお、何が事業のボトルネックかは事業企画や経営レイヤーの方が元々把握してくれていました。

Slide 36

Slide 36 text

|　© Leverages inc. 36 注力すべきドメインを決めることができたぞ

Slide 37

Slide 37 text

|　© Leverages inc. 37 ドメインを絞って段階的にリプレースするのはどうだろう ※再掲

Slide 38

Slide 38 text

|　© Leverages inc. 38 ドメインを絞って段階的にリプレースするのはどうだろう

Slide 39

Slide 39 text

|　© Leverages inc. 39 なぜリプレースなのか

Slide 40

Slide 40 text

|　© Leverages inc. 40 目的はシステムの変更容易性を上げることなぜリプレースなのかだけど、そもそも何が変更容易性を下げているの？

Slide 41

Slide 41 text

|　© Leverages inc. 41 何が変更容易性を下げているのかなぜリプレースなのか関係者からのヒアリングや他社事例を踏まえ、変更容易性低下の原因はシステムを構成する3つの複雑さと、それを取り巻く環境が起因しているのではないかと考えました。

Slide 42

Slide 42 text

|　© Leverages inc. 42 システムを構成する3つの複雑さなぜリプレースなのか ● 本質的な複雑さ ● 偶有的な複雑さ ● 規模による複雑さ

Slide 43

Slide 43 text

|　© Leverages inc. 43 ● 対象とするドメイン知識の複雑さ本質的な複雑さなぜリプレースなのか

Slide 44

Slide 44 text

|　© Leverages inc. 44 ● 技術的要因による複雑さ ● 仕様（業務）とコードの乖離偶有的な複雑さなぜリプレースなのか

Slide 45

Slide 45 text

|　© Leverages inc. 45 ● 対象とするドメインの広さ、連携するシステムの数など規模による複雑さなぜリプレースなのか

Slide 46

Slide 46 text

|　© Leverages inc. 46 ● 本質的な複雑さ ○ 対象とするドメイン知識の複雑さ ● 偶有的な複雑さ ○ 技術的要因による複雑さ ○ 仕様（業務）とコードの乖離 ● 規模による複雑さ ○ 対象とするドメインの広さ、連携するシステムの数など 3つの複雑さとそれを取り巻く環境が原因？なぜリプレースなのか

Slide 47

Slide 47 text

|　© Leverages inc. 47 環境要因と注力ポイントを分析するために、システム思考で考えてみることに。システム思考で考えるなぜリプレースなのか

Slide 48

Slide 48 text

|　© Leverages inc. 48 ● ある物事を構成する要素間の関係性に着目する考え方（超ざっくり） ● よくある例えが「生態系」 ○ 人間にとって害虫だからといって駆除してしまうと、巡り巡って生態系全体に影響を与えてしまうシステム思考とはなぜリプレースなのか

Slide 49

Slide 49 text

|　© Leverages inc. 49 結果！（全体像）なぜリプレースなのか

Slide 50

Slide 50 text

|　© Leverages inc. 50 結果！（抜粋）なぜリプレースなのか偶有的な複雑さ

Slide 51

Slide 51 text

|　© Leverages inc. 51 偶有的な複雑さは変更容易性を下げるなぜリプレースなのか偶有的な複雑さ変更容易性

Slide 52

Slide 52 text

|　© Leverages inc. 52 変更容易性が下がると、開発者体験が下がるなぜリプレースなのか偶有的な複雑さ変更容易性開発者体験

Slide 53

Slide 53 text

|　© Leverages inc. 53 開発者体験が下がるとエンジニアのモチベーションが下がるなぜリプレースなのか偶有的な複雑さ変更容易性開発者体験モチベーション

Slide 54

Slide 54 text

|　© Leverages inc. 54 モチベーションが下がると退職や異動によりリソースが減るなぜリプレースなのか偶有的な複雑さ変更容易性開発者体験モチベーションチームのリソース

Slide 55

Slide 55 text

|　© Leverages inc. 55 チームのリソースが減ると、余裕が無くなるなぜリプレースなのか偶有的な複雑さ変更容易性開発者体験モチベーションチームのリソース時間と心の余裕

Slide 56

Slide 56 text

|　© Leverages inc. 56 結果、偶有的な複雑さが増えるなぜリプレースなのか偶有的な複雑さ変更容易性開発者体験モチベーションチームのリソース時間と心の余裕

Slide 57

Slide 57 text

|　© Leverages inc. 57 ループを破壊すれば、突破口が開けるかも！なぜリプレースなのか偶有的な複雑さ変更容易性開発者体験モチベーションチームのリソース時間と心の余裕

Slide 58

Slide 58 text

|　© Leverages inc. 58 対象とするドメイン領域も決まったしリプレースで解決する問題の仮説も立てられたぞ

Slide 59

Slide 59 text

|　© Leverages inc. 59 あとは実行あるのみ！

Slide 60

Slide 60 text

|　© Leverages inc. 60 早速、リプレース実行予定メンバーに相談いざ、リプレース

Slide 61

Slide 61 text

|　© Leverages inc. 61 リプレースはうまくいくイメージがない

Slide 62

Slide 62 text

|　© Leverages inc. 62

Slide 63

Slide 63 text

|　© Leverages inc. 63 「リプレースはうまくいくイメージがない」理由いざ、リプレース社内では過去何度かリプレースが行われたけど、ちょっとコードが読みやすくなっただけで、本質的な複雑さは減っていないし、事業価値も出せていない。

Slide 64

Slide 64 text

|　© Leverages inc. 64 「リプレースはうまくいくイメージがない」理由いざ、リプレースそれにリプレースをやるとなると数ヶ月、あるいは年単位で事業開発ができなくなる。これは事業にとって嬉しくない。

Slide 65

Slide 65 text

|　© Leverages inc. 65 「リプレースはうまくいくイメージがない」理由いざ、リプレースリプレースをする前に事業の問題を理解して、その解決のためにリプレースをするべきじゃない？

Slide 66

Slide 66 text

|　© Leverages inc. 66 確かにそう

Slide 67

Slide 67 text

|　© Leverages inc. 67 過去、社内では仕様は基本そのままで技術刷新を目的にしたリプレースが行われてきましたが、それによって大きな事業価値を出せているとは言えない状況でした。いままでのリプレースは事業価値を出せていた？いざ、リプレース彼の主張はそういったリプレースに一石を投じるものです。

Slide 68

Slide 68 text

|　© Leverages inc. 68 ドメインを絞って段階的にリプレースする案は、観点が開発者に寄っている。反省いざ、リプレース事業価値が出るのはずっと先！

Slide 69

Slide 69 text

|　© Leverages inc. 69 方針転換

Slide 70

Slide 70 text

|　© Leverages inc. 70 新たな方針

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

|　© Leverages inc. 74 ● モダナイズしたいのは、偶有的な複雑さを中心とした負のループを破壊したいから。これは変わらない。 ● 今あるシステムに対してやるのは、事業貢献を止めないため。「今あるシステムをモダナイズする」とは新たな方針

Slide 75

Slide 75 text

|　© Leverages inc. 75 ● モダナイズしたいのは、偶有的な複雑さを中心とした負のループを破壊したいから。これは変わらない。 ● 今あるシステムに対してやるのは、事業貢献を止めないため。 ● リプレースにはある程度時間がかかる。それは、事業貢献を一時的に止めることを意味する。「今あるシステムをモダナイズする」とは新たな方針

Slide 76

Slide 76 text

|　© Leverages inc. 76 ● 技術刷新を目的としたリプレースはエンジニアにとっての価値であり、それが事業価値に繋がるのは間接的（これは事業にも依る） ● 間接的な価値を計測したり、効果を実感するのは難しい中長期的にプラスなら、事業貢献を止めるのもやむなし？新たな方針

Slide 77

Slide 77 text

|　© Leverages inc. 77 ● 技術刷新を目的としたリプレースはエンジニアにとっての価値であり、それが事業価値に繋がるのは間接的（これは事業にも依る） ● 間接的な価値を計測したり、効果を実感するのは難しい ● リプレースと事業貢献でチームを分ける選択肢もあるが、その場合リプレースチームの事業理解は深まり辛い中長期的にプラスなら、事業貢献を止めるのもやむなし？新たな方針

Slide 78

Slide 78 text

Slide 79

Slide 79 text

|　© Leverages inc. 79 ● 事業施策を行う中で少しずつモダナイズ ○ 具体的にはTwigテンプレートをReactにしている ● 部分的に変えていきたいので、そのための基盤だけは最初にガッと用意事業貢献は止めずに「ついでに」モダナイズ新たな方針

Slide 80

Slide 80 text

|　© Leverages inc. 80 ● 事業施策を行う中で少しずつモダナイズ ○ 具体的にはTwigテンプレートをReactにしている ● 部分的に変えていきたいので、そのための基盤だけは最初にガッと用意 ● 以降の進捗はゆっくりだが、Twigでは難しくともReactでは出来る事業価値が見つかれば一気にモダナイズを進める選択も取れると考えている事業貢献は止めずに「ついでに」モダナイズ新たな方針

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

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

|　© Leverages inc. 91 1. 事業の問題を理解する 2. 解決方法を考える 3. 制約が邪魔になる 4. 制約を無くすためにリプレースする 5. 事業の問題を解決する 6. 事業価値になるリプレースが事業価値になるまでの流れ新たな方針

Slide 92

Slide 92 text

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

Slide 96

Slide 96 text

Slide 97

Slide 97 text

Slide 98

Slide 98 text

Slide 99

Slide 99 text

|　© Leverages inc. 99 事業理解やコミュニティ作り案件ドメインチームでの取り組み現在の動きモデリング https://speakerdeck.com/leveragestech/autopututo-equals-autoka mudehanaishi-jie-dekai-fa-sheng-chan-xing-wokao-eru https://speakerdeck.com/leveragestech/moderingushi-jian-dejian-e ta-fen-xi-moderutoye-wu-moderunote-xing

Slide 100

Slide 100 text

|　© Leverages inc. 100 ● 活動を通して、事業との距離もグッと近づいた ○ 事業の経営報告会で案件ドメインチームがピックアップ！ ○ タスク化される前に雑相談がなされるなど変化がそして現在。事業理解とモダナイズに奮闘中現在の動き