【イベント主催レポート】 ITエンジニア共有会〜システムの技術的負債への立ち向かい方〜

f:id:pcads_media:20200908113348j:plain

こんにちは!TECH Street編集部です。
10月8日(木)に開催されたTECH Street主催、『ITエンジニア共有会~システムの技術的負債への立ち向かい方~』のイベントレポートをお届けいたします!

今回のイベント概要

エンジニアの皆さんは、「技術的負債」に1度は悩んだ経験があるのではないでしょうか…

今回は、国内BtoCサービスを展開する各社のエンジニアがどのように技術的負債に向き合い、工夫や管理をして解消しているのかをご紹介いたします。
登壇者の皆様は、こちら!

f:id:pcads_media:20201119182351p:plain

皆さんも、一度は耳にしたこのとのあるサービスなのではないかと思います:)

各社一体どんな工夫をしているのか…レポート前半では当日のトーク内容の紹介、後半ではイベント中に回答しきれなかったご質問への回答をしておりますのでぜひ最後までご覧ください!

 

『転職サービス「doda」技術負債への向き合い方』(中澤勝さん/パーソルキャリア株式会社)

パーソルキャリアの中澤さんからは、「doda(デューダ)」のサイト開発において自助・共助・公助したエピソードをお話しいただきました!

中澤さんによると、「doda」のサイトは求人数が競合他社の6~10倍ほどあるという特徴があるそうです。というのもの、【人材紹介】【求人案内】【転職フェア】など複数のサービスを1つのサイトで運営しているため掲載求人数が非常に多くなっているとのこと。
では、そんな「doda」でどのような技術的負債が生まれているのでしょうか?

一般的な転職フローに比べると、「doda」上では複数のサービスを1つのサイトで運営しているため、「どの求人から応募されたか」で①業務フロー②法律上の縛りがすべて異なるという特徴が。

この仕組みがゆえに、技術的負債がたまりやすい…!

f:id:pcads_media:20201119145849p:plain

いままで

・これらの負債は「ため込んでは刷新」を繰り返していた
・負債をためないことや日々の開発の中で返済ができなかった

こうなると、刷新しても増えていき、解消されない負債も増えてくる‥(老舗サイトあるある涙)

これらを解消するための工夫

・管理体制を変更:ベンダーの提案ベースから内製エンジニア管理へ
・内製エンジニアを増員:1名→12名に!

とはいえ課題は山積み…今回は「継続的なリファクタリング」を中心に具体的な改善策を共有していきます!

現状の課題

・開発者同士の連携が少ない・テストコードの導入コストが高い
→dodaになかったものは「共助」「自助」や「刷新」は行っていたものの、エンジニア同士の「共助」ができておらず、返済が間に合わない事態に。

解決のために:タスクフォースの立ち上げ

開発に関わるメンバーを集めて、開発環境の改善やリファクタリングの方法の共有を実施。ポイントはクラス図やソースコードを眺めながら実施したという点だそう!

f:id:pcads_media:20201119151543p:plain

いままでは内製エンジニアではなかったので、ソースコードを眺めながら‥ということはできなかったそうですが、みんなで眺めることを意識して進めたそうです。

効果があったこと

・デッドコードの削除:利用されなくなった分岐の削除を行った
・テストコード作成方法の共有:サンプルソースを作成し共有した
・風土づくり:テストを大事にする開発(Test-Daiji Development笑)

共助で変わったこと

・自助から共助へ:各種ベンダーがもっていたノウハウ・ツールの共有で生産性UP!
・公助を向上でより充実!:運用が回り始めた

このような施策を繰り返すことで、PDCAが上手く回るようになったとのこと◎

中澤さんの発表では「Test-Daiji Development」など、ちょいちょい視聴者の笑いを誘う箇所がありましたが、dodaのウラガワを赤裸々に語っていただきました!共助の関係をつくること」どのプロジェクトにも通ずることだなあ...と改めて。

 

『「負債」が負債へと変化する時~負債を残しつつ安全に開発する方法~』(阿久津岳志さん/株式会社タイミー)

株式会社タイミーの阿久津さんからは、タイミーリリースから今日にいたるまでの経験をもとに技術的負債への向き合い方をシェアしていただきました!

「タイミー」は、その日働きたい求職者と企業をマッチングする単発バイトのプラットフォーム。 

f:id:pcads_media:20201119151659p:plain
具体的に、タイミーでは技術的負債によって、
・開発速度が低下する
・不具合が生じる

といった問題が発生したそうです。では、その問題に対してどのように取り組んでいったのでしょうか?

開発速度が低下する問題について

より良いUI/UXを追求するため細かく、継続的なViewの改善が行われていた→デザイン上は些細な変更だとしても設計の都合上修正に想像以上の工数が発生…!

下記がタイミー内の「金額修正機能」の例。実際の労働時間が予定されていたものと異なる場合にワーカーが申請するための機能とのことですが、こちらはデザインの変更はされていますが、ビジネスロジックは変わっていません。 

f:id:pcads_media:20201119151743p:plain

このような変更を実施する際、MVVMで対応していた時代は、1画面につき1つのView Modelという方針で開発していたため、かなり変更が実行しにくかったそうです。

画面ごとにロジックを持つ構成となっていたため、1つの画面で行われていた処理がデザインの変更のために他画面で行われるようになると、ロジックまで修正を加える必要が出てきてしまっていた涙(Viewの変更のために、ロジックまで修正するのは大変…!)

複数の画面にまたがって処理が行われると、画面間の値の受け渡しがつらいですよね…。

↓そこで【対策】Fluxの導入

このような問題に対して、タイミーではFluxというアーキテクチャを導入、機能ごとでロジックを管理するかたちで問題に向き合うようになったそうです。そうすることで、

→画面が分割されようがロジックの変更は不要
→興津のStoreを1つ保持するだけで済むので複数の画面にまたがった処理も簡単!
開発速度もかなり改善!

不具合が発生する問題について

タイミーでは、負債による不具合を防ぐために下記2つの工夫を実施しているそう。

①適切な単位でモジュール分割を行う
 ・処理はclass内で閉じるように
 ・適切な単位にclassを切り分ける
・各機能をFrameworkに切り分ける

②手動でQAしにくい場所にはテストを徹底
・すべてをテストで担保できているわけではない
・手動でのQAが困難な箇所を中心にテストを描いている(起動周りの動作確認、配列の仲野要素のfilter/sort、各種状態)
・型もある種のテスト
・テストがあるとはいえ、読みやすいコードは常に意識

まとめ

タイミーが技術的負債に向き合ってきた方法をまとめると…
・適切な設計パターンを採用することで開発速度を向上することが出来た
・適切な単位でモジュール分割をすることで不具合を防いでいる
・手動でQAしにくい場所は徹底的にテストを書く

まだ技術負債はそこまで溜まっていないが、タイミーをより“イケてる”サービスにするために日々工夫を重ねているそうで非常に興味深い事例を共有していただきました。

まだ技術負債はそこまで溜まっていないという阿久津さんに対して、「羨ましい!」「そんなこと言ってみたい!」他の登壇者がチャット欄で盛り上がっているのが印象的でした笑

 

『負債に強いクリエイティブチームビルディング』(難波 啓司さん/POST URBAN.inc)

Post Urbanは自分たちだけでマップを作っていけるような、マップSNS。

f:id:pcads_media:20201119152112p:plain

難波さんは、エンジニア以外にもデザインや映像編集など、クリエイティブ領域全般をご経験されてきたバックグラウンドをお持ちとのこと。その経験を踏まえて、クリエイティブチームビルディングについてお話しいただきました!

スイスの機械式時計のようなコーディングを目指せ

「高価なものほど見えない部分で価値が決まる」ねじ開けないと見えないほど完璧に作りこまれているスイスの機械式時計のように、内側を完璧に作りこまれたコーディングを意識しているそう。

その中でも特に2つの作用を意識しているそうです。

f:id:pcads_media:20201119152155p:plain

特に、チームビルディングは直接的にそのタイミングでプロダクトに影響しなくても、後々開発にかかわったチームメンバーによってプロダクトビルディング的に世の中に出ていくことがあるので、重視しているとのこと。チームメンバーの技術レベルの平均値があがることも重要。

プロダクトビルディングとチームビルディングは車の両輪…!同時並行で意識する必要がある!とても大切なポイントですね。

すぐに導入できて長期的にも重要なシンタックスリファクタ

例えば、こんなことをチームで取り組んでいるとのこと。

f:id:pcads_media:20201119152444p:plain

もっと具体的には…

【例① 】冗長な名前を避ける
【例②】動詞を使い分ける

こういった細かいことを一人一人に実施してもらうには、チームメンバーの「納得感」が必要。そのためには、その負債がどれだけのコストになっていくのかを正確に認識してもらうことが大切だそうです。

負債によるコストとは

①金銭的コスト技術的負債によって余分な人件費がかかり、中長期的に大きなコストになっていく

②ビジネスリスクプロダクトのスケールと共に変わりゆく技術要件が満たせなくなり、プロダクトの成長を止める要因となってしまう。

負債コストの全体のうち、平均で約40%が技術的負債によるコストであるというデータもあるそうです。それだけ大きなコストであることを、チームメンバーに理解してもらうことが大切…!

3種の負債

難波さんは、負債は下記の3種類にカテゴライズができると語ります。

①偶発的な負債
急速な市場の変化やバグ修正、人的な要因から生まれる負債。たとえばコロナの流行など、チームに依存せず、一定の割合で起こってしまう仕方ない負債。

②戦略的な負債
早急にプロダクトを展開するためのスピード重視戦略によって生まれる負債。例えばスタートアップ企業などによくあるそうですが、負債の発生リスクを理解したうえで、早急にプロダクトを市場に展開するためにあえてそのコードを書く、という戦略から生まれる負債のこと。

③技術不足による負債
それを負債だと認識できないままに実装してしまうこと。チームメンバーが良質なコードを見たことがないケースが多い。

③の場合は、はレビュアーやチームにこの負債を認識できるメンバーがいればすぐに解決が出来ますが、①②と向き合うためには、裁量権のあるメンバーが、計画的な経営ビジョン(負債の返済のタイミング)を持っている必要あり。

難波さんの発表資料、おしゃれすぎる!という第一印象はさておき、「細部にこだわる」「コーディングへの美意識」で負債コストを減らす、難波さんならではの視点だなあと感じました。Post Urbanアプリ、早速ダウンロードしてみたので使い込んでみます!


『脱モノリシックに向けたぐるなびの取り組み〜これからのぐるなびを支えるアーキテクチャについて考える〜』(滝口勇大さん/株式会社ぐるなび)

みなさん、レストランを探す際、ぐるなびを使った経験も多いのではないでしょうか!そんなぐるなびでは、どのような技術的負債への向き合い方をしているのでしょう、ワクワク!

滝口さんは、認証認可基盤の開発を経て、現在はTech Leadとしてぐるなびに掲載されている飲食店ページの開発を主にご担当されているそうです。Tech Leadは自プロダクトの技術リーダーとして最適な技術選択や方向性を示す役割だそう!

課題

ぐるなびにおける課題は、長年システムを運用してきた結果、スーパーモノリス化。このような状態だと、比較的小規模の開発でも様々なところに影響が出てしまうため、影響調査や回収箇所が増えて開発費が高額化してしまうそうです。また、それによって開発者が影響範囲の特定に疲弊していってしまうとのこと…

As is

現在のシステムにおける課題は下記3点。

①NAS密結合
NASには、プログラムのフレームワークやデータ連携用ファイル、SDK、共通ライブラリが配置されているが、これのせいでシステムをクラウド移行やコンテナ化が難しくなっている。

②サーバー相乗り問題
用途の異なるシステムやサービスが同じサーバーに乗っかってしまっている状態。これのせいでプログラム言語のバージョンアップがしたくても影響が大きすぎて難しく、結果いつまでも古い言語のバージョンのままとなっているものがいくつか存在してしまうそうです。

③カオスなデータ構造
ぐるなびの飲食店ページに表示されているラベルやバナーはだし分けをフラグで制御しているが、好き勝手に追加されすぎて手が付けられなくなったテーブルがいくつかあり、データ連携に使っているようなファイルが数100メガを超えているものも…。

To be

下記が現状検討している理想像。モノリスを分解、モノリスの連携はAPI経由にしぼり、データベースを単一のものにする構造とのことですが、この構造でもデメリットは想定できるそう。 

f:id:pcads_media:20201119152646p:plain

例えば真ん中のモノリスに変更がある場合他のモノリスもそれに追従していかなければいけない。また、各APIに認証認可の機能があるとすれば別のモノリスはAPIごとにその認証認可機能を実装しなければいけない。

そのためこの構成ではまだマイクロサービス化されたとはいえないため、さらに次の構成を検討する必要があるとのこと…

下記が、次に検討される構成ですが、

f:id:pcads_media:20201119152734p:plain

 こちらの構成はいわゆる、「ゲートウェイパターン」と呼ばれるアーキテクチャパターン。ひとつひとつのモノリスをマイクロサービスとよばれる機能単位に分割することで、開発に疲弊しきった開発者を救うことに繋がるようです。

このパターンであれば、呼び出し側は既存システムを意識することなく利用することが出来ます! データベースはサービスの要求に応じたものを選択する形で対応するそうです。

プロジェクト実現に向けたAction(解決策)

では、上記をビジネス再度に提案し、実現するためにはどのように行動したのか…!

① 課題を明確化
現状開発のボトルネックは何か、このままではどうなってしまうのか、未来の話をすることで今のままで会社の課題が解決できるのかを問いかける。このままではコロナのような状況の中で、迅速な開発が出来ない、という提案も。

② エンジニア視点×ビジネス視点
エンジニアがチャレンジしたい気持ちも、ビジネスを継続していくことも大事。それらを並行してバランスよく検討することが重要。

③予算と実現性のバランス
予算は限られているので、お金をかけるだけの価値があるのかをいくつかパターンを用意して説明。費用対効果を打ち出す。
このような工夫ののち、ようやくプロジェクトとして動き出すことに! 

まとめ

間違った技術選択は、会社にとって負債でしかない!厳しい状況を乗り越えるためには、最適な技術選択が必要です。チーム力を強め、事業を理解し、プロダクトにとって最適な技術選択を行うことが大切。

技術リーダーでありながらもエンジニアリングの視点だけでなく、ビジネス視点をもってバランス良く開発をすすめていく視点、素敵すぎますね。。。よく使っているサービスのウラガワでどんな課題がありどう解決をしているのか、リアルな話を聞けて大変参考になりました!よりぐるなびさんが好きになりました。


まとめ

今回のイベントでは技術的負債について、各社からかなり具体的な課題および解決方法の事例を詳細にご共有いただきました!

エンジニアのみなさんにとっても今後に生かせるような気づきやひらめきがあったのではないかと思います♪ 

参加者コメント

f:id:pcads_media:20201119152813p:plain

参加者の方からはこんなコメントを頂きました♪

・共感することばかりで最高でした
・大事なテーマなのにあまり語られないので聞けてよかったです。
・会社毎に技術的負債の捉え方に特徴があって面白かった。 

集合写真

f:id:pcads_media:20201119152836p:plain

※顔出しOKな方と登壇者・運営のみ

参加者のみなさま、ご登壇いただいた中澤さん、阿久津さん、難波さん、滝口さん、Mitzさんありがとうございました!

このあとは、参加者からの27個のご質問に各社の方々に回答いただいた内容を共有いたします。

>>当日のQ&A集


 

参加者からのご質問

 

パーソルキャリア中澤さんへのご質問

 

(Q1)パーソルさん、グループ企業も多くてサービスも多いと思いますが、グループ間・サービス間での技術的連携ってありますか?

→技術連携というのは多くないですが、Persol Group Tech Conferenceとして
年一程度でエンジニアが集まるイベントを行い交流会はしています。

(Q2)エンジニア12名まで増やすって2年のうちにある一定の時期に一気に増やしたのか、それとも徐々に増やしたのか少し気になりました。(負債関係ないですが)

→徐々に増やした形です。一度の採用では2名や3名程度が多いです。

(Q3)doda、管理体制とか内製化とかって大変じゃなかったですか?社内での推進で一番の壁は何でしたか?(抵抗勢力は無かったですか?)

→抵抗勢力よりも「内製」という言葉の受け取り方が人によって異なっていることで、コミュニケーション齟齬が多く発生したのが一番の壁でした。

ある人は社内ベンダーのように思っていたり、ツール作る人だと思っていたり・・・
内製化する際は、「自分たちは〇〇する集団」というのをちゃんと内外に発信することが大事でした。

(Q4)キャリアカウンセラーとも連携して開発とかするんですか?

→弊社ではCA(キャリアアドバイザー)となりますが、そちらの代表者と連携することはもちろんあります。ユーザからの問い合わせなど、リアルな意見はCA側が持っていることも多いです。

(Q5)共助の時に1つのポイントかと思いますが、標準化ってどんな感じでしたか?

→既にダメなコードがある状態からの標準化でした。
そのため単純な規約を作っても、既存ソースを参考にされた瞬間破綻するというジレンマがありました。だからこそ共助の打ち合わせ内ではサンプルソースを提示することを行いました。規約よりもサンプルを真似するならこのソースから!というのを連携することを大切にしました。

(Q6)デッドコードの削除の効果は体験したことがあります。クローンコードの削除も効果が大きかったのですが、クローンコードはないのでしょうか?

→ありました。消せるものは消しましたが、フィジビリでやめてもいいようにクローンコードを作ることが多いため、今現状もクローンコードが増えたりしております。
こういったものを作りっぱなしではなく削除していくように共助内で対応しております。

(Q7)テストを大事にする風土づくりとしてどういう施策を行ったかお聞きしたいです。

→redmineのようなチケットで対応状況を週次で記載してもらい、その中でいいコードがコミットされたら全体周知するようにしました。

 

タイミー阿久津さんへのご質問

 

(Q8)タイミーさんは何名くらいのエンジニアが在籍してるんですか?

→15名前後です。

(Q9)タイミーさん、まだ新しい企業・サービスですよね。って事は、開発環境とか採用したフレームワークってイマドキなものですか?レガシー的なものってないですよね?

→現時点では比較的新しいフレームワークを利用して開発する事ができています。しかし、SwiftUIなど最新のフレームワークの利用は出来ていないので、どのように移行していくか日々検討しています。日進月歩で新しいものが登場してくるソフトウェア開発はとても難しいですね・・。頑張ります。頑張っていきましょう!

(Q10)Ship するのは first code じゃなく Second や Third なり練られたモノにしなさいってことでしょうか?

→『first codeをリリース(ship)するということは、負債を抱えると言うこと。つまり、リリース時から全てのサービスは負債を抱えている状態である。』ということだと僕なりに認識しています。

そのため、負債がゼロなサービスはこの世にないので、継続的に負債を解消していくことが何より大切なのだと思います。

(Q11)アーキテクチャ変更するのって簡単にできました?(サービスすでに完全展開中ですよね?)

→新規開発する機能から順番に新しいアーキテクチャを採用していきました。古くからある機能に関しては基本的に既存のアーキテクチャを維持していますが、大きな機能改善がある場合は思い切ってその箇所のアーキテクチャも思い切って刷新しています。基本的に、機能単位でのリアーキテクチャになりますので、あまり難易度は高くありませんでした。

 

POST URBAN難波さんへのご質問

 

(Q12)ポストアーバンさんはAndroid版を出す予定ないのでしょうか?

→実はステルスですでにリリース済みでして、一応ダウンロードできる状態です!

(Q13)コーディングへの美意識、大事ですよね!!それを大事にするきっかけってなんですか?過去にコード的負債で痛い目を見たから?とか

→過去にインターンなどで携わってきたコードと、オープンソースなどのコードを見比べて、どれだけ可読性が大切かというのを勉強していきました。

また、自社のコードだと言えど将来的に「なぜその機能を追加したのか、なぜここに関数を切り出したのか」などの経緯を知らないエンジニアに引き継ぐと考えると、
ある意味内部のコードもオープンソースと同じ程にコメントなどが大切だと痛感していきました。

(Q14)細部が大事!を実践するのに、社内での標準化ドキュメントって工夫されている事ありますか?

→基本的にはレビュアーがコーダーの意図をコメントで把握できるかどうかを基準にして、レビューフローを妥協しないようにしてもらっています。

完全に標準化することは目指しておらず、whyがしっかり書かれていて意図が伝わるかどうかを大切にしてます。

(Q15)find, fetch, getの使い分けは何かを参考にして決定した感じですか?それとも、独自に定義しましたか? (とても参考になりました)

→動詞が雑に使われる最大の要因は、英単語として本来ある動詞ごとの微妙なニュアンスの違いを把握できていないことにあると思っています。

なのでネイティブの人が書いているコードを眺めると結構しっかり使い分けられていることが分かります。

(Q16)命名は大事だと思いますが、どれくらいの時間までかけますか?議論が白熱しすぎてやりすぎだと思ったことがあり。。

→違和感があればすぐにIssueにしてしまいます。反対意見が出たらそれはそれでOpenなイシューとして残しておいて、そこに負債らしきコードがあることを忘れないことが大切だと思います。

(Q17)負債をコストで表現して教育する、よいですね。このアイデアはエンジニアサイドからですか?それとも経営側でしょうか?

→自分の中では経営的な視座を高める上で出てきたアイデアだと思ってます。
多くのエンジニアにとって、普段目の前のタスクを作業している際にこういった中長期的な視点を持つのはかなり困難なので、たまにでもそこの視点を思い返す大切さを伝えたいですね。

(Q18)負債への意識もコードへの美意識も、すべてチームビルディング教育の一環に入れてる感じですか?(すばらしい)

→はい。
チームビルディングはマイナスの強制力(「こうしないと怒られる」とか)ではなく、プラスの自発性(「いけてるコード書きたい」とか)を伸ばしていくようにしましょう!

(Q19)技術顧問を雇った上で、どのように顧問の方を利用するかも大事な気がしますが、何かおすすめの方法はありますか?

→まさに、めちゃくちゃ大切です。技術顧問もピンキリなので自分から彼らの知識を引き出しにいきましょう。
とにかく、今まで見てきた悪いコードと良いコードを全て教えてください!くらいにことを言ってしまって良いと思います。

 

ぐるなび滝口さんへのご質問

 

(Q20)ぐるなび、お世話になってます!グルメ検索サイトとしては老舗ですよね!最近はライバルサービスも多いと思いますが、他サービスを調査して参考にして大幅にサイト改修、なんてことありますか?(ぐるなびはずっとサイトイメージが良い意味で変わっていないイメージなので)

→ぐるなびをご利用いただきありがとうございます。ぐるなびでは、日々ユーザリサーチや定量的な分析を実施の上で、各プロダクトをどう進化させていくかを検討し、開発を進めています。
その結果、他社サービスに近い機能開発になることもございます。日々ユーザーと向き合い、全社でより良いサービス提供に努めています。

(Q21)モノリスって表現、社内エンジニアでも普通にそう言ってるんですか?

→はい。モノリス(モノリシックアーキテクチャ)に関しては、社内でも共通言語です。

(Q22)トランザクション管理はオーケストレーションですか? それともコレオグラフィですか?

→ぐるなびはさまざまなサービスが稼働していますが、その多くはオーケストレーションです

(Q23)マイクロサービス化に当たってトランザクションの制御がとても難しいと思います(誰がどこまでロールバックするの?) 何か障害になった例があれがお願いします。

→障害事例については社外秘情報を含むためご紹介が難しいのですが、おっしゃる通りで難しいところだと認識しています。マイクロサービス化することで障害ポイントが増えるため、モニタリングの仕組み(ログ監視、メトリック監視、そもそものシステム全体の監視)は検討しているところです。

(Q24)ぐるなびさんはどのくらいのスケジュール感と人数体制でこのプロジェクトを実施する予定ですか?

→全体的なスケジュールだと年単位ですが、マイクロサービス単位でリリースをすることで可能な限りサービスへの影響を抑えながら進めております。人員もそれに合わせて内製化を進めてアサインをしている状況です。

(Q25)NAS!!!クラウドじゃないんすね!!クラウド化の予定は?

→古くからのこるサービスは、NASを使ったアーキテクチャで構成されておりAWSにマイグレーションするサービスは、NASのようなファイルベースのストレージを採用せず構成されています。
下記ではその1例について詳しく掲載しております。
https://developers.gnavi.co.jp/entry/uds/

(Q26)最適な技術選択を行うためにはどんな技術があるかを知る必要があります。それに対してはどのようなアプローチや行動をされましたでしょうか?

→MeetupやWebinarへの参加が多いと思います。AWSやGCPなどクラウドサービスは、各社と連携しながら新しい情報のキャッチアップをしています。またキャッチアップした情報は定期的に社内の勉強会などでナレッジシェアを行っています。

(Q27)サービス分割するに当たって最重要ポイントはなんですか?モノリスを分割する単位を間違えると劣化する可能性もあると思います。

→目的はビジネスのアジリティ向上です。開発効率を上げること、保守性の高い環境を整えることが重要と捉えています。マイクロサービスアーキテクチャにより、複雑さがましてしまい逆に性能が下がってしまったり、開発効率が下がってしまっては意味がないです。ビジネスロジックを理解し、適切な分割を行う事が大事だと考えています。

 質問は以上となります。また次回以降のイベントもお楽しみに。