Tweet
Tweet

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

エンジニアの好奇心を満たす出会いが見つかる 「企業」と「個人」を繋ぐ技術イベント

Slide 3

Slide 3 text

10年分の負債を大規模リニューアル！ モノレポから抜け出した方法と ビジネスアプローチ

Slide 4

Slide 4 text

本日のアジェンダ 前半部：「典型的モノレポ」10年分の負債を改善！デグレの恐怖から抜け出す力を自分のモノに！ うるる / NJSSについて フルリニューアルを選択した意思決定の背景 一度失敗したリニューアルからどのように改善したのか、実例を元に解説 マイクロサービスの理想の粒度と、うるる社が考えるメリット/デメリット 今後解決させなければならないこと（技術的観点と理想の人材像について） 後半部：他職種や経営層とエンジニアを「うまくつなぐ」ためにエンジニアができること 当時の状況から振り返る組織課題について 優先順位の付け方や判断の軸、改善に向けたアプローチ方法 フルリニューアルを乗り越えた現場目線のケーススタディ4選

Slide 5

Slide 5 text

「典型的モノレポ」10年分の負債を改善！ デグレの恐怖から抜け出す力を自分のモノに！ 前半部

Slide 6

Slide 6 text

株式会社うるる NJSS事業本部 AI活用推進課 課長 栗原 史明 経歴 東京出身、1991年9月20日生まれ 2014年に株式会社パソナテックに新卒入社 SlerとしてBIツールの開発に従事し、北は石狩、南はベトナムと 転々 2018年に株式会社うるるに転職 入社以来、NJSS担当のサーバーサイドエンジニアとして従事 2021年10月にAIプロジェクトに参画し、2022年10月にはAI活用推 進課の課長に就任して今に至る

Slide 7

Slide 7 text

前半部でお話すること 導入までの過程で技術的にどのような背景・思考があったのかを ケーススタディ的な形でお話しします。 ※時間の都合で考え方の部分を中心に会話します。 具体的な技術など気になることが御座いましたらお気軽にご質問ください。 うるるが運営するWebサービス：NJSS 2021年に実施したフルリニューアルでモノリスからマイクロサービス化を実施

Slide 8

Slide 8 text

01: うるる / NJSSについて

Slide 9

Slide 9 text

株式会社うるるのご紹介

Slide 10

Slide 10 text

株式会社うるるのご紹介

Slide 11

Slide 11 text

入札情報速報サービス NJSS とは NJSSはSaaSモデル型の入札業務ワンストップサービス 入札市場は年間20兆円を超える安定性を誇る 全国8,300以上の官公庁・自治体などから公示される 入札情報を一括検索・管理・分析ができ、 入札参加プロセスの効率化・販路拡大を支援 クローラー（自動収集プログラム）で拾いきれない情報 は、クラウドワーカーが目視で情報収集しており、 精度の高い情報を網羅的に掲載していることが特徴

Slide 12

Slide 12 text

入札情報速報サービス NJSS とは 数百名規模のワーカーとクローラーを活用し入札・落札情報を収集 構築した独自のデータベースの検索サービスとして提供するビジネスモデル

Slide 13

Slide 13 text

02: フルリニューアルを選択した意思決定の背景

Slide 14

Slide 14 text

大黒柱のNJSSへも満足できるよう 様々な機能の提案がビジネスサイドから入ってくる 5ヵ年の中期経営計画への突入を控える ところが… 会社の更なる成長を目指し、 5ヵ年の中期経営計画に突入しようとしているフェーズ

Slide 15

Slide 15 text

当時のNJSSの状況 とっくにEOLを迎えていた CakePHP1.3での運用... テストコードの概念は 殆どない... 巨大なモノリポ設計により 1箇所の変更による影響範囲大... 循環的複雑度30超えの class は当たり前の Fat Model , Fat Controller... 機能追加どころの騒ぎではない…

Slide 16

Slide 16 text

なぜ、ここまで悪化してしまったのか この状況を打破するため中期経営計画にて次の成長を見据えた システム改善の投資が盛り込まれた 2008年のローンチ以降、 とにかく売ることを優先していた過去 お客様に満足していただく為、 新規機能開発を優先し、 リファクタリングが進まなかった 2017年までに2回ほどリニューアルを試たが、 SEOの下落や社内合意形成に至らず、 いずれも未完に終わる 過去の失敗から改善に踏み切れず、 NJSSの成長も鈍化

Slide 17

Slide 17 text

なぜ、ここまで悪化してしまったのか この状況を打破するため中期経営計画にて次の成長を見据えた システム改善の投資が盛り込まれた 2008年のローンチ以降、 とにかく売ることを優先していた過去 お客様に満足していただく為、 新規機能開発を優先し、 リファクタリングが進まなかった 2017年までに2回ほどリニューアルを試たが、 SEOの下落や社内合意形成に至らず、 いずれも未完に終わる 過去の失敗から改善に踏み切れず、 NJSSの成長も鈍化

Slide 18

Slide 18 text

なぜ、ここまで悪化してしまったのか この状況を打破するため中期経営計画にて次の成長を見据えた システム改善の投資が盛り込まれた 2008年のローンチ以降、 とにかく売ることを優先していた過去 お客様に満足していただく為、 新規機能開発を優先し、 リファクタリングが進まなかった 2017年までに2回ほどリニューアルを試たが、 SEOの下落や社内合意形成に至らず、 いずれも未完に終わる 過去の失敗から改善に踏み切れず、 NJSSの成長も鈍化

Slide 19

Slide 19 text

なぜ、ここまで悪化してしまったのか この状況を打破するため中期経営計画にて次の成長を見据えた システム改善の投資が盛り込まれた 2008年のローンチ以降、 とにかく売ることを優先していた過去 お客様に満足していただく為、 新規機能開発を優先し、 リファクタリングが進まなかった 2017年までに2回ほどリニューアルを試たが、 SEOの下落や社内合意形成に至らず、 いずれも未完に終わる 過去の失敗から改善に踏み切れず、 NJSSの成長も鈍化

Slide 20

Slide 20 text

なぜ、ここまで悪化してしまったのか この状況を打破するため中期経営計画にて次の成長を見据えた システム改善の投資が盛り込まれた 2008年のローンチ以降、 とにかく売ることを優先していた過去 お客様に満足していただく為、 新規機能開発を優先し、 リファクタリングが進まなかった 2017年までに2回ほどリニューアルを試たが、 SEOの下落や社内合意形成に至らず、 いずれも未完に終わる 過去の失敗から改善に踏み切れず、 NJSSの成長も鈍化

Slide 21

Slide 21 text

フルリニューアルを決断した理由 端的に言うと時間が掛かりすぎる為 コード/FW/インフラと あらゆる面がレガシー 故に、段階的な改善が困難 静的解析の結果、 負債の解消までに16年 しかし期限は2年 負債解消期間に比例して 膨れ上がる人件費 コスト 品質 納期

Slide 22

Slide 22 text

フルリニューアルでの技術的取り組み ・マイクロサービスアーキテクチャの導入 ・フロントエンド/サーバーサイド分離 ・オニオンアーキテクチャの導入 ・コンテナベースのアプリケーション設計 ・自動テストを記述する文化の醸成 ・CI/CDの導入によるデプロイ・テスト実行の自動化 ・Infrastructure as Code の導入 ・Solr on EC2だった検索エンジンをAmazon Elasticsearchに移行 ・他にもいろいろ… 設計を中心にインフラなど様々な取り組みを実施

Slide 23

Slide 23 text

フルリニューアルでの技術的取り組み ・マイクロサービスアーキテクチャの導入 ・フロントエンド/サーバーサイド分離 ・オニオンアーキテクチャの導入 ・コンテナベースのアプリケーション設計 ・自動テストを記述する文化の醸成 ・CI/CDの導入によるデプロイ・テスト実行の自動化 ・Infrastructure as Code の導入 ・Solr on EC2だった検索エンジンをAmazon Elasticsearchに移行 ・他にもいろいろ… 設計を中心にインフラなど様々な取り組みを実施

Slide 24

Slide 24 text

03: マイクロサービスの理想の粒度と、うるる社が考えるメリット/デメリット

Slide 25

Slide 25 text

マイクロサービスアーキテクチャとは ビジネス機能に合わせて小さなサービスに分割するアプローチ 2011年頃から提唱されたと言われており、近年ではよく聞く手法の1つ 機能A 機能B 機能C マイクロサービスA マイクロサービスB マイクロサービスC モノリシックアーキテクチャ（モノリス） 全ての機能群が1つのサービスに集結 マイクロサービスアーキテクチャ ビジネスに合わせて独立してサービスが動く サービス サービス

Slide 26

Slide 26 text

マイクロサービスアーキテクチャのメリット 1.ソースコードの影響範囲を限定できる 個々のシステムが独立している為、ソースコードも独立してデプロイが出来る 言語やフレームワークもそれぞれで選定が出来る 2.システムの稼働影響を限定できる 別サービスがダウンしても一方のサービスは影響無し、または影響を限定的に出来る 負荷がスパイクしてもマイクロサービス内でスケールがしやすい 影響範囲を限定するメリットを享受できる

Slide 27

Slide 27 text

マイクロサービスアーキテクチャのデメリット データ管理を中心に複雑化する 1.データ整合性担保の難易度が上がる 別のマイクロサービスの永続化層へのアクセスはAPI経由が原則 特にサービスを跨ったトランザクション処理の実装難易度は非常に高い 2.運用コストが上がりやすい システムが増える為、運用コストが上がる可能性がある 同様に監視対象も増える為、死活監視やログの管理が煩雑化しやすい

Slide 28

Slide 28 text

大半のシステムではマイクロサービスは必要ない？ 出典・引用： MicroservicePremium https://martinfowler.com/bliki/MicroservicePremium.html ・システムの複雑度が小さい段階で導入すると、 却って生産性を下げることに繋がる ・これはマイクロサービス特有の複雑性が 混入してしまうことによるもの ・モノリスでシンプルに保つことが出来るのであれば、 それが一番ベストな選択である マーティン・ファウラー氏は安易な適用を戒めている

Slide 29

Slide 29 text

どう考えるのが良いのか？

Slide 30

Slide 30 text

2つの軸で考える サービス特性とデータ特性から考えると良い

Slide 31

Slide 31 text

1. 「誰」が「何」をするためのサービスなのか 2. サービスは人と目的（やりたいこと/やるべきこと）が 合致することで成り立つ 3. モノリシックサービスは上記が混在しているので 紐解いてあげることが必要 4. 社内組織とマイクロサービスが連動していると効果性が高い サービス特性から考える マイクロサービスはビジネスに合わせたサービスの分割である 顧客管理 契約管理 入札情報登録 入札情報検索 ワーカー管理 報酬管理

Slide 32

Slide 32 text

1. サービスを分割した際の情報のやり取りを整理 2. サービス間のトランザクション処理はしんどいので慎重に判断 3. 結果整合性の担保までにどの程度の時間が許容されるか整理 4. 厳密なリアルタイムデータ同期を求める場合は分割は避ける データ特性から考える マイクロサービスは永続化層の分割でもある マイクロ サービスA マイクロ サービスB API経由でアクセス サービスを跨ぐ 永続化アクセスは アンチパターン

Slide 33

Slide 33 text

04: 一度失敗したリニューアルからどのように改善したのか、実例を元に解説

Slide 34

Slide 34 text

私たちも漠然としたイメージから始まった 導入した方が良さそう 背景 入札情報登録と閲覧のシステムは独立していても 動きそうという漠然としたイメージはあった 同じクラスにワーカー向けとユーザー向けで分岐するような 処理が入り乱れており、「責務を分割できれば楽なのに」という思い は常々あった NJSS

Slide 35

Slide 35 text

私たちも漠然としたイメージから始まった 導入した方が良さそう 背景 入札情報登録と閲覧のシステムは独立していても 動きそうという漠然としたイメージはあった 同じクラスにワーカー向けとユーザー向けで分岐するような 処理が入り乱れており、「責務を分割できれば楽なのに」という思い は常々あった NJSS この肌感は本当に正しいのか？ 当時のエンジニアメンバーと意見を交わしながら設計を描いていった

Slide 36

Slide 36 text

サービス特性から考える（1/4） NJSSは、入札情報を「クラウドワーカー」が「収集」し、 入札情報を「ユーザー」が「閲覧・検索・管理」出来るサービスである つまり収集と閲覧で明確にサービス特性が異なる為、独立して定義 【ワーカー向けドメイン】 入札情報の登録編集 入札情報の検索 クラウドワーカーの管理 【ユーザー向けドメイン】 入札情報の閲覧・管理・配信 競合企業の閲覧・分析 入札情報の検索 顧客/契約情報の管理 入札情報の自動収集(クローラ ー) モノリスから「ワーカー向け」と「ユーザー向け」に分割

Slide 37

Slide 37 text

サービス特性から考える（2/4） どちらも1,800万件（※当時）の入札情報のフリーワード検索を 高速にさばく必要があったことから検索のための中央集権的なサービスを構築 入札情報を「ワーカー＆ユーザー」が「高速に検索」出来るサービスを定義 【ワーカー向けドメイン】 入札情報の登録編集 入札情報の検索 クラウドワーカーの管理 【ユーザー向けドメイン】 入札情報の閲覧・管理・配信 競合企業の閲覧・分析 入札情報の検索 顧客/契約情報の管理 入札情報の自動収集(クローラ ー) 「ワーカー/ユーザー向け」から「検索」を分割 【検索ドメイン】 入札情報の高速な検索

Slide 38

Slide 38 text

サービス特性から考える（3/4） モノリス時代の名残でユーザー向けの機能に内包されていた、 契約情報を「うるるの営業」が「確認・管理」出来るサービスを分離 （※上記も明確にサービス特性が異なる） 【ワーカー向けドメイン】 入札情報の登録編集 入札情報の検索 クラウドワーカーの管理 【ユーザー向けドメイン】 入札情報の閲覧・管理・配信 競合企業の閲覧・分析 入札情報の検索 顧客/契約情報の管理 入札情報の自動収集(クローラ ー) 「ユーザー向け」から「契約管理」を分割 【検索ドメイン】 入札情報の高速な検索 【契約管理ドメイン】 契約情報の管理 営業情報の管理

Slide 39

Slide 39 text

サービス特性から考える（4/4） サービス特性上のマイクロサービス化の骨格が完成 続いてデータ特性上で問題がないかを確認する 【ワーカー向けドメイン】 入札情報の登録編集 クラウドワーカーの管理 【ユーザー向けドメイン】 入札情報の閲覧・管理・配信 競合企業の閲覧・分析 入札情報の自動収集(クローラー) サービス特性上の骨格が完成 【検索ドメイン】 入札情報の高速な検索 【契約管理ドメイン】 契約情報の管理 営業情報の管理

Slide 40

Slide 40 text

データ特性から考える（1/3） 各ドメインがそれぞれどのようなデータ依存関係にあるのかを整理 依存関係をもとに連携の部分で難易度が高いものが無いかをチェックしていく 【ワーカー向けドメイン】 入札情報の登録編集 クラウドワーカーの管理 【ユーザー向けドメイン】 入札情報の閲覧・管理・配信 競合企業の閲覧・分析 入札情報の自動収集(クローラ ー) データの依存関係を整理 【検索ドメイン】 入札情報の高速な検索 【契約管理ドメイン】 契約情報の管理 営業情報の管理

Slide 41

Slide 41 text

データ特性から考える（2/3） ワーカー向け・検索・ユーザー向けは入札情報のやり取りで依存 ただしデータの流れる方向は一方通行かつ、 厳密なリアルタイム性は求められなかったため分割による障壁は低いと判断 【ワーカー向けドメイン】 入札情報の登録編集 クラウドワーカーの管理 【ユーザー向けドメイン】 入札情報の閲覧・管理・配信 競合企業の閲覧・分析 入札情報の自動収集(クローラー) ワーカー向け・検索・ユーザー向けの要件整理 【検索ドメイン】 入札情報の高速な検索 【契約管理ドメイン】 契約情報の管理 営業情報の管理 入札情報のやり取りに依存 入札情報のやり取りに依存

Slide 42

Slide 42 text

データ特性から考える（3/3） ユーザー向けで収集したユーザー行動情報を契約管理に送信する部分で依存 こちらも一方通行連携かつ、デイリーレベルの連携要件だったため 分割に関する障壁は低いと判断 【ワーカー向けドメイン】 入札情報の登録編集 クラウドワーカーの管理 【ユーザー向けドメイン】 入札情報の閲覧・管理・配信 競合企業の閲覧・分析 入札情報の自動収集(クローラ ー) ユーザー向け・契約管理の要件整理 【検索ドメイン】 入札情報の高速な検索 【契約管理ドメイン】 契約情報の管理 営業情報の管理 行動データの やり取りに依存

Slide 43

Slide 43 text

こうして… モノリスだったNJSSは4つのマイクロサービスへ 契約管理、ユーザー向け、ワーカー向け、検索の４つのサービスドメインに分割 【契約管理ドメイン】 「セールス部門の為の契約情報管理サービ ス」 契約情報・セールス情報管理 【ユーザー向けドメイン】 「ユーザーの為の入札情報検索サービス」 入札情報の閲覧・検索 【ワーカー向けドメイン】 「ワーカーの為の入札情報登録サービス」 入札情報の収集・入力 【検索ドメイン】 「サービスの為の高速検索サービス」 入札情報の高速な検索 収集した入札情報を参照 入札情報を参照 顧客の行動データを連携 品質管理部門担当 セールス部門担当 セールス部門担当 担当なし

Slide 44

Slide 44 text

現在の技術環境 各マイクロサービスで採択した 技術が気になる方は 是非こちらにアクセス！ ※本日は時間の都合で割愛 https://blog.uluru.biz/6 719/

Slide 45

Slide 45 text

リニューアル後、どうなったのか 16年分の技術的負債を86%削減 ※44,456 hr -> 6,206 hr ※CodeClimate計測 複雑化しているロジックは一部残ったものの、大幅な削減を達成 積極的な改善・バージョンアップが加速 一方で実施した改善ノウハウを後続サービスに活かすという動きも サービスの稼働継続性が上がった ユーザー向けサービスが一時的に不安定になっても、 ワーカーは安定して入札情報登録を継続出来る環境を作ることができた（逆も然り）

Slide 46

Slide 46 text

05: 今後解決させなければならないこと（技術的観点と理想の人材像について）

Slide 47

Slide 47 text

今後解決していかなければならないこと 運用・コスト面の課題 システムが増えたためインフラコストが増えてしまった（ダイエット中…） マイクロサービス間での属人化が進行しやすく配置転換の容易性が下がってしまった 技術面の課題 サービスを横断的に見る場合、ドメイン知識だけでなく技術言語知識も必要になる （＝属人化をより進めてしまっている要因の１つ）

Slide 48

Slide 48 text

プロダクトが抱える課題を技術で解決出来る人材 技術は課題解決の手段の１つであり、 マイクロサービスアーキテクチャもその手段の1つに過ぎません。 機能開発のその先にある、「どんな課題を解決したいのか」 「どんな価値を創造したいのか」を考えることが大切です。 プロダクト課題の解決・価値の創造のために 技術的観点で実現できるカード多く出せる人が 今後もビジネス層に求められていく人材かと思います。 今後求められていく人材とは

Slide 49

Slide 49 text

まとめ 1. マイクロサービスアーキテクチャは銀の弾丸ではない 2. NJSSではサービス特性とデータ特性でマイクロサービス化を 検討 3. サービス改善の容易性や耐障害性のメリットを享受できた 4. コストや運用面に課題があるため継続的に改善中 技術を理解した上でプロダクトの課題解決/価値創造に 繋げることが出来るのか正しく判断できることが大事！

Slide 50

Slide 50 text

他職種や経営層とエンジニアを 「うまくつなぐ」ためにエンジニアができること 後半部

Slide 51

Slide 51 text

株式会社うるる NJSS事業本部 プロダクトソリューション課 課長 森山 宏啓 経歴 1984年生まれの38歳 新卒で中小SIerに入社し、プログラマーとして従事 その後、創業期ベンチャー、医療介護向け事業会社にてエンジニ アを軸に、バックオフィス・セールス・事業責任者を経験 2019年に株式会社うるるへジョインし、現在はエンジアリングマ ネージャーとして従事

Slide 52

Slide 52 text

後半部でお話しすること 経営層・他部署との連携の取り組み 営業ドリブンで成長した組織におけるプロダクト開発 うるる初の大規模リニューアルプロジェクト EM/PMとしてプロジェクト推進

Slide 53

Slide 53 text

01: 当時の状況から振り返る組織課題について

Slide 54

Slide 54 text

エンジニアチームは6名のみ うち半数以上が1年以内のジョイン 2019年の状況（森山の入社当初） 技術的負債を多く抱えたシステム サブシステムの 先行リニューアル進行中 SYSTE M TIMING TEAM 中期経営計画発表直前 システム投資計画への言及 複数プロジェクト推進の為、採用が急務

Slide 55

Slide 55 text

エンジニアチームは6名のみ うち半数以上が1年以内のジョイン 2019年の状況（森山の入社当初） SYSTE M TIMING TEAM 中期経営計画発表直前 システム投資計画への言及 複数プロジェクト推進の為、採用が急務 技術的負債を多く抱えたシステム サブシステムの 先行リニューアル進行中

Slide 56

Slide 56 text

2019年の状況（森山の入社当初） SYSTE M TIMING TEAM 中期経営計画発表直前 システム投資計画への言及 複数プロジェクト推進の為、採用が急務 エンジニアチームは6名のみ うち半数以上が1年以内のジョイン 技術的負債を多く抱えたシステム サブシステムの 先行リニューアル進行中

Slide 57

Slide 57 text

02: 優先順位の付け方や判断の軸、改善に向けたアプローチ方法

Slide 58

Slide 58 text

"つなぐ"連携としてのアプローチ 1. 目的のすり合わせ 2. 各部署の代表者との週次MTGとファシリテーション 3. 是々非々なコミュニケーションスタンス 4.開発チーム内でのコミュニケーション

Slide 59

Slide 59 text

03: フルリニューアルを乗り越えた現場目線のケーススタディ4選

Slide 60

Slide 60 text

インセプションデッキを作成し目的のすり合わせを行った 目的のすり合わせ 背景： 過去にリニューアルプロジェクトが頓挫したことや、組織として大規模プロジェクト推 進経験 の不足がある中で、中期経営計画でのフルリニューアルのコミットメントを行っていた 課題： ・大規模プロジェクトに対する漠然とした不安 ・プロジェクトが進む中で判断を迷わなくさせるための道標が必要

Slide 61

Slide 61 text

開発チームを中心にインセプションデッキを作成 各部署の代表者のレビューを通じ合意形成を行った 目的のすり合わせ

Slide 62

Slide 62 text

週次定例を設定し、自らファシリテーションを行った 各部署の代表者との週次Mtgとファシリテーショ ン 背景： 個別のプロジェクトに関して、部署をまたぐ連携の場がそもそもなかった 課題： プロジェクトに対する経営層・セールス・開発チームの相互理解が不足していた 「これ気になっているけど聞いていいのかな？」が発生していた

Slide 63

Slide 63 text

1. 課題・疑問・提案・共有を目的とした週次定例を設定 2. 議論のログを蓄積し、立ち返りができる状態を担保 3. ファシリテーションとしてルールの周知徹底 原則スキップNG、予定のバッティングはリスケ対応 ボール持ちの明確化と期日設定、翌週進捗確認 議題が無くてもオープンクエスチョンで課題の種の探索 各部署の代表者との週次Mtgとファシリテーション

Slide 64

Slide 64 text

各組織の代表でありつつも、目的に照らした意思決定の推進 是々非々なコミュニケーションスタンス 背景： 開発組織のマネジメント層が不在であった事から、 営業組織と開発組織の上下構造ができており、社内受託構造に陥っていた 課題： 対等な組織としての議論が行われにくかった 相互に考えを理解し、全体感を持った意思決定になりにくかった

Slide 65

Slide 65 text

定例Mtg内では、各議題に対して各部署の考えや見解を 出し切った状態にして、目的に照らし合わせた意思決定を行うようにした 是々非々なコミュニケーションスタンス TIPS1 TIPS2 開発組織の代表として開発側の意見を押し通すのではなく、 PJの目的や事業の方向性に照らし合わせ、 他組織の代表と協調し、意思決定の合意形成を目指した

Slide 66

Slide 66 text

定例Mtgの議論内容は基本的にはオープンに伝える 開発チーム内でのコミュニケーション 背景： メンバーからするとPMは開発の意見を通してきてくれるという暗黙の期待がある一方で、 是々非々で方針決定を行うため、必ずしも全てが開発チームの思い通りにはならない 課題： 意思決定に対する不透明さが出てしまうことがある 不透明さが「〇〇は開発を分かってくれない」という組織間の分断につながる懸念

Slide 67

Slide 67 text

開発チーム内でのコミュニケーション TIPS1 TIPS2 意思決定の背景を共有し、他者の価値観を理解することにも繋げた 人事情報やインサイダー情報など機微な情報以外は積極的に開発チームに共有 意思決定の経緯も極力公開することで、不透明感を可能な限り無くす

Slide 68

Slide 68 text

その結果どうなったのか？

Slide 69

Slide 69 text

リリース前には他部署の協力を得ることができ、 「バグ出し祭り」と銘打ち、事業部全体での最終テストを 開催し、品質向上につなげることができた その結果 大規模リニューアルの達成！

Slide 70

Slide 70 text

04:Appendix

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

採用情報 エンジニア採用サイト https://engineer.uluru.biz/ うるるではエンジニアを募集中！ カジュアル面談からでもOK！ 是非、ご興味あれば、 この後のアンケートにて 「面談を希望する」 へご回答くださいませ。