見出し画像
Photo by poconen

「フロントエンドの技術的負債 みんなで学ぶ Lunch LT」に参加してきました。

小泉岳人

表記イベントに参加してきたので感想を記載します。

LT①『フロントエンド刷新をプロジェクトとして進める際に気をつけたいこと』


サイボウズの小林さんからのLTでした。Kintoneのフロントエンド刷新（React等の技術で刷新）の中での経験を話してくれました。詳細は「#フロリア」のハッシュタグで見るとサイボウズさんでの経験談が見れるそうです。
・本当にプロジェクトとしてやるのか考える。（フロリアではプロダクトの継続性を脅かしている状態だった）
・刷新プロジェクトだとスコープが不要に広がってしまうので、しっかりビジネスにあったゴールを考えることが重要。加えて、さらに価値観まで共有した (ゴールだけでは足りなかった)
・最強のアーキテクチャではなく変えやすいアーキテクチャを目指した(技術的な刷新はこれで最後でないので、変えることを前提とした。
　例：１つのMonorepoでなく、チーム単位でMonorepoを構成した。
・３チームに分かれて刷新PJTを進めたが各チームに明確な目的を設定した。安易な共通基盤チームを避けた。
・Why・代替案を記録する

⇒技術的負債に関する、テクニカルな話ではなく、目的・価値といった抽象的な理解から具体的なプロジェクトに落ちてて、腹落ちできる内容でした。価値観の話は会社の風土が反映されてて、とても意味を感じました。

LT②『大規模な技術的負債と現実的に向き合う〜巨大なSPAの技術的負債と向き合い続けるテクニック〜』

Chatworkの澁谷さんからのLTでした。
・チャットワークについては、強大なコードベース(Javascriptだけで16万行、CSSも１万７千行)、URL単位でアプリケーションとして分割されていない（１枚のページで全UIが動作している)、GUIアプリの特性に近い

・JQuery⇒React＋DDD⇒React＋Reduxと３世代にわたるアーキテクチャとなっている
・技術的負債は「アプリケーションのあるべき姿と現状の差分」と捉えている。負債はなくすものではなく、様々な要因を加味してコントロールしていくもの。技術的負債と付き合っていく事が重要。下記２点のテクニックがある

＜段階的に返済するテクニック＞
　・JQueryの世界とReactの世界を分離する(腐敗防止層を設け、古い子k－度を捨てやすくする)
　・JQuery製のUIとReact製のUIを混在させることで、段階的にUIごとにReact化を目指す。
・TypeScriptのStrictmodeを有効にする（jQuery時代のコードはany型を許容しているが、暗黙的なany型混入を防げるように考慮）
＜安全にリリースするテクニック＞
・負債の影響は積み重なって予期しない不具合として現れる。そのため、小さく失敗できる体制を作ることが重要
・リリースフローを整理。自分たちで先行的に触れるようにする
・コミットハッシュごとのスナップショットを生成し、指定したバージョンで現象確認できるようにする
・自前のリリースシステムで高速なリリース/切り戻しを実現する

⇒ リリースに関する整理は非常によいなと感じました。力を入れる所に対して重視している感じが伝わりました。

LT③『当事者不在でも変化してきたクラウドワークスのフロントエンド開発について』

　クラウドワークスの大山さんからのLTでした。技術要素や背景を理解できるメンバーの離脱等で当事者がいなくなった中でどのように過去のフロントエンドに立ち向かったかという説明でした。
　チームや組織でどう立ち向かっていくかという内容を説明いただきました。
・当初はRuby on Railsでフロントエンドを構築。React,Vue.js等の台頭の中でそちらの環境を構築。ただし時間がたって構築したフロント環境がメンテできなくなっていった。対応していくが何が正しいのか誰もわからなくなってきた。そのため、技術的負債解消チーム『ジャンヌ』を作って取り組み。社内外に取り組みをアピールしながらうまく進めていった

⇒こういった対応を発信しながら進めていくという事は他の会社さんの事例を見ても重要と感じました。

LT④『お客様とすすめるフロントエンドの技術支援』

スリーシェイクの佐藤さんからのLTでした。お客様の環境について技術的負債を解消していく事例について説明いただきました。
お客様はマルチページアプリケーションで、PythonのDjagoフレームワーク。生のJavaScriptでライブラリはjQueryやBootStrapを使って構築
・お客様はフロントは技術的に苦手。ただ技術力自体はある会社さんだった。
・そもそもの技術的負債を認識してもらい、既存の運用フローを壊さずに改善を心掛けた。（人間は知っている事しか知らない。知っている範囲で頑張るので、こういうのもあると、提示して気付きを与えることが重要)
・我々がいなくなっても作れることが重要（いくら優れたシステムでも運用できなければ負債。)

⇒ お客様の目的/背景に入り込みながら相手が知らない事を気付かせてあげるといった、プロダクト作成のコンサルと同じような話だなと感じました。

LT⑤『Findyのフロントエンド設計刷新を通して得られた技術的負債との向き合い方』

すみません・・・業務のため聞けませんでした。


感想

　全般的に昨日聞いた。リンケージ×セレスさんの講演とも被る内容が多く昨日の話を思い出しながら聴いてました。こういった話はHowの話だけでなく、もう少し大きな概念から整理・意識しないといけないなぁ。と考えながら聴いていました。そういう意味では私のような技術わかってない人間でもちゃんと概念理解しないといけない内容だし、知って使える内容だと思います。

　ありがとうございました。



この記事が気に入ったらサポートをしてみませんか？