00:06
はい、10月26日、水曜日ですね。中国は朝9時を回りました。
えー、ちょっと今日も今日もまた寝坊してしまったんですけど、さっそく始めていきたいと思います。
はい、おはようございまーす。ひめめのkeethことくわはらです。では本日も始めていきたいと思います。
えーと、今日はですね、引き続きですけども、昨日読んでいた、リリースから5年、Web フロントエンドの経年劣化と向き合うという記事です。
記事はスライドですね。はい、まあとある勉強会のスライドですけど、もう続きを読んでいこうと思います。
これの半分というか、ゲームツリーとこのスライドはですね、お二人の方がスライドを書かれていて、前半後半に分かれているんですけど、
今日はその後半の方をですね、デベロッパーエクスペリエンスの改善のところから入っていこうかなと思っています。
前半の方をですね、なんだっけ、Web とアプリ側の方のアーキテクトとかの、えーと、段階的に統合していくって話ですね。
そのままSPAじゃなくてMPAにしていくってところですね。
あとCDNの統合するって意味で、リアクトルーターを外したところとサーバーサイドレンダリングっていうところをやっていたっていうお話があって、結構面白かったですね。
あとリダックスも引き剥がしたって話なので、リアクトルーターとリダックスを引き剥がして、合計59.66KB、GZIPですね。
でも減ったっていうところが、これも大きかったってところですね。
あとはそのABテストのお話とかがあったりして。
まあ結構面白かったですね。そのリアクトルーター外しっていうところだけでもかなり大変だったんだろうなっていうのを予想はできますけども。
っていうお話がありましたっていうのが前半、機能パートですね。
じゃあ今日のパートです。後半は高見俊輔さんとかですかね。
デベロッパーエクスペリエンスの改善っていうところから今日入っていこうと思います。
はい。じゃあ行きましょう。
初めに話すことは話さないことのところからです。
アプリケーションの品質とフロントエンドの責務っていうところですね。
ユーザー体験、パフォーマンス、アクセシビリティ、UI、UX、etc.
あと開発体験、プロダクティビティ、コードの品質、etc.ですね。
時代によって変化し何もしなければ劣化していくっていうお話でした。
で、今日はその後半の方ですね。後半、後者の方、開発体験の方のお話をすると。
一応参考として別の記事かなが貼られてますね。
developerexperience.ioっていう。
developerexperience.ioっていうそもそもサイトがあるんですね。
そんなサイトがあったんですね。いやいや面白いわ。
で、それの中にプラクティスっていうページがあるのでそこから引用されてる感じですね。
Good Developer Experience、What is a Good Developer Experienceっていうセクションから取られたそうですね。
こんなんあったんや。全然知らなかった。これ次回以降読んでみたいですね。
すごいたくさんのナレッジが書かれてますね。
このdeveloperexperience.io今開いたんですけど、
ナレッジベースっていうキービジュアルがガーンと貼られててすごくいいなと思いましたので。
ここら辺の記事を確かにピックアップして読んでいくのも面白そうですね。
ちょっと技術というよりも、どちらかというとチーム開発みたいなところの話が多そうな気はしますけど。
まあいいや。これは次回以降いくつかピックアップしたんでいこうと思います。
03:03
じゃあ行きましょう。開発体験は良くない。
アメバニュースの場合ってところから入ります。
メンテナンスコストがまず高いというところでした。
実装における心理的安全性が低い。実装のハードルも高い。
つまり設計及び依存関係がやっぱりレガシーであり、静的な片付けもない。
さらにコードレビューの負荷が大きい。
テストコードがないしCIでのチェックがなされていない。
ビルドとデプロイの時間がかかる。
かなりカオスな感じですね。これ見ると。
課題その1。実装における心理的安全性が低い。
つまり実装のハードルが高いところですけど。
開発ガイドラインの作成を行いました。
UIコンポーネント、テストパフォーマンスなどに関して
リンターの運用の改善。
ハスキー使ったりリントステージ使ったり、
例えばスタイルリント使ったりとか。
色々なものを導入したというところですね。
これ結構大事ですよね。
意外と学生さんの方ってハスキー使ってないとか
リントステージ知らないみたいな方も結構いらっしゃるので。
この辺は結構知っておいていいなというライブラリですね。
Git運用するんだったらこの辺はほぼほぼマストと言っても
過言ではないでしょうと思います。
で、脱Gitサブモジュール。
なるほど、Gitサブモジュールを抜けたかったんですね。
まあまあ、一昔前結構皆さん使われてる印象ありまして
僕も何度か使いましたね、Gitサブモジュールは。
結構運用大変だったりするのであんまり好きではなかったんですけど。
あともう1個はTypeScript化をしたいねっていうところでした。
で、特にTypeScript化の実装方針のところがピックアップされてますね。
できるだけ厳密に片付けをしましょうと。
コンパイラーオプションのストリックオプションをtrueに。
これはそうだよね。
で、あと、
Add TypeScript ESLint スラッシュ ESLint プラグインの利用をしますと。
あと、TS Migrateは利用しないってことでした。
で、あとフェッチ回りなど重要なロジックを優先して対応します。
新規の開発では必ずTypeScriptで実装する。
はい、これは良い話ですね。
フェッチ回りのお話ですね。
APIリクエストとはレスポンスの型定義っていうのは
OpenAPIを元に生成してフェッチ回りをお片付け。
片付けをしたってことですね。
これは上手い言い方してますね。
一応こっちはGitHub.comの
ドローポールのOpenAPI TypeScriptっていうところの
コードを参考にしています。
これは現状だったんですかね。
入れたのかどうかわかんないですけど
っていうのが名前に載ってます。
で、CIDのチェックで
LintだったりTestだったり
パフォーマンスバジェットっていうところですね。
パフォーマンスバジェット
僕あんまりちゃんと見たことないんですけど
これまだリンク貼られてますね。
GitHub.comのAIスラッシュサイズリミットっていうところですね。
ようなリポジトリのリンクが貼られてるんで
興味ある人は見てみてくださいと思いました。
なんか気になるな。
あんまりちょっとやったことがなかったので
そもそもパフォーマンスバジェットっていう言葉そのものに
僕あんまり馴染みがないのでね。
やっぱり触れないといけないなと思いつつですけど。
あとストーリーブックですね。
プロレーグごとにちゃんと
プレビューを出すようにしたっていうことだそうです。
これも結構大きい話ですよね。
やっぱりストーリーブックがあるなしで
レビューしやすさって結構違うので。
さらにプロレーグごとのストーリーブックプレビューですけど
生化物をデプロイするCIワークフローというのも
ちゃんと作成したらしいですね。
生成したプレビューURLをコメントで通知するようにして
ローカルでのビルドを必要せず
ストーリーブックの実装を確認できる形にしたと。
06:00
はーはーそういう感じなんですね。
CI周りの方に組み込んだっていうことですね。
なるほど。
プロレークエストの時にディスクリプションに
各メンバープロレークエストを作る人が
ペッて貼るとかいうわけではないんですね。
この辺はさすがって感じました。
うちのチームはちょっとあれですね。
各実装担当者とあるコンポーネント実装者の人が
プロレークエスト作るときに
一緒にストーリーブックのURLですね。
ローカルホストコロンなんちゃらの
パスを指定するみたいなこともやったりしてますからね。
はい。
それはベタベタ書くわけではないってことですね。
なかなか参考になるなと思いました。
続いて課題その3。
ビルドとデプロイに時間がかかるところです。
ウェブパックのバージョンを更新したそうですね。
バージョン3からバージョン4に上げたと。
CIの移行。
ジェンキンス使ってたんですね。
ジェンキンスからサークルCIに移って
GitHub Actionsに移ったと。
バージョン8だったんですね。
すごいな。
歴史を感じますねこれは。
ウェブパックのバージョンの更新の話が取り上げられてて。
そもそもバージョン3ではストーリーブックが動作してないと。
そうなんや。知らんかった。
段階的にバージョン3からバージョン4への移行を目指していたと。
基本は公式のガイドですね。
webpack.js.orgのmigrate4っていうページがあるんで。
そのガイドに従ったところそうです。
結果として、いわゆるモードオプションですね。
Dev or Proのモードオプションの指定によって最適化を行われましたと。
プロダクションの場合で平均ビルド時間が約10秒ほど改善したと。
でかいですね。
beforeで35213ミリ秒なんで35秒ですね。
がafterで2518秒なんで25秒になったと。
それでもでかいっちゃでかいですね。
アプリケーションが大きいからかもしれないですけど。
それでもビルド時間10秒改善するって結構大きいですよね。
そもそも25秒もちょっとでかい気がしますけど。
CIの移行で続いてJenkins to GitHub Actionsです。
ノードバージョンをまず上げたと。
バージョン8からバージョン14まで。
各モジュールをキャッシュするようにしたことで
ビルドの実行速度が改善になりましたよ。
サークル試合もそもそもキャッシュ機構があったはずなんで
サークル試合上でやるだけでもだいぶ早くなったと思いますけど
さらにGitHub Actionsを使ったってところですね。
アプリケーションのビルドが約1分半ほど短縮したすごい体験ですね。
逆に言うとJenkinsってそんなに重かったんだなっていうところですかね。
キャッシュしなかったからかもしれないです。
毎回毎回全部インストールして全部ビルドしてってなるとそうかもしれない。
あとはコードですね。
コードベースでワークフロー管理できるようになった。
いわゆるYAMLですね。
を書いたってことだそうです。
いろいろ改善してまとめですね。
まとめ。
レガシーなアプリケーションの開発体験を
さまざまなアプローチで改善することができたよと。
サービスの安定リリースだったりリードタイプの改善に寄与することもできたよと。
さまざまなエコシステムに対する理解も深めることができましたよと。
何もしなければやっぱり劣化していく計画的なメンテナンスが必要だねって。
最後ですね。
刷新というようなアプリケーションの要件であって
プロダクトの性質に応じて柔軟にやっていきましょうというところが
その通りだという感じがしますけど。
というわけで以上で2つ目の方の記事ですね。
ディベロッパーエクスペリエンスの改善という話が終了で
09:01
このスライド全体としてリリースから5年ウェブフロントで経営の入れ方を向けよう
というところ自体が終了になるよというところでした。
やっぱりそういうドラスティックな変更のお話ってなかなか聞けないし
やっぱりその中で出てくる課題だったりとか技術的な問題点とか
課題点というのはすごく参考になるお話がたくさん多いので
貴重なお話を本当にありがとうございましたというところです。
本当は実際の話の場に聞いていたかった感じがしますね。
これ自体スライドなので勉強会そのものでしゃべられているので
そこの生の声をちょっと聞いてみたかった感は正直ありますけど
うちみたいにクライアントワークをやっている会社からすると
そういうドラスティックな挑戦とか今までのレガシーなものを置き換えるみたいな経験って
なかなかさせてもらうこともないので
すごくあれですね、なんか気になるというか
正直羨ましいなっていうことがちょいちょいあります。僕としても。
なかなかグロースをやったことがないので
こういうお話っていうのはすごく参考になるなと思いました。
じゃああと残り時間ですね。残り時間ちょっと短いん。
残り時間でですね、せっかくさっきリンク貼られていました。
そのデベロッパーエクスペリエンス.ioのところのプラクティスから
グッドデベロッパーエクスペリエンスっていうページがあるので
そこをちょっとささっと読んでいこうかなと思っています。
そんなに長くなさそうなので読んでいこうと思います。
グッドデベロッパーエクスペリエンスっていうお話ですね。
tldrからちょっと入っていこうと思いますが
まずtldrですね。開発者を幸せにすること
彼らを幸せにし続けることを忘れないくださいという
すごいお手紙的な一言から始まりましたね。
じゃあ行きます。What is a good developer experience?
良いデベロッパーエクスペリエンスとは何でしょうかというところですけど
デベロッパーエクスペリエンス。この記事ではDXを始めます。
DXは開発者があなたの製品を使っているとき
あるいはあなたの製品で作業しているときに感じる経験というのを表します。
それはポジティブな感情だけでなく
ネガティブな感情のパッケージでもあります。
多くの企業ではDXを扱うことは
ユーザーエクスペリエンス、UXをできるだけ良くすることの
二の次になりがちです。
まあ仕方ないと思いますけど。
このアプローチは残念なことに開発者もユーザーなのですよということです。
彼らはあなたの製品、フレームワーク、ツールなどを使って
何らかの使用経験を持っています。
この経験が良いものになるか悪いものになるかは
あなた次第です。
しかし彼らの満足度と幸福度というのが
あなたのプロジェクトの成功に不可欠であることも
忘れないでください。
開発者が幸せであれば長期的に
優れたソフトウェアが生まれます。
ポジティブな開発体験があれば
開発者は幸せで満足し
チームも足る可能性も低くなります。
私たちは優れたDXを次の四つの要素で定義していますよということです。
めちゃめちゃありがたい言葉をかけてくれますね。
僕らもユーザーの一人だよって。
なかなかそうですね。
開発者、実装の方は
そういう風に思ってもらえないことが圧倒的に多いですからね。
でも確かにこの言葉は
実装していても結構経験することはあるので
すごく嬉しいなと思いました。
その四つの要素の一つ目ですね。
まずは適合するアーキテクチャーですね。
12:00
フィッティングアーキテクチャーです。
シンプルなアーキテクチャーと
より複雑なアーキテクチャーの妥協点を見つけましょう。
シンプルだと後で苦痛が大きくなり
複雑だと今苦痛が大きくなると。
プロジェクトのチームの規模を考慮しましょう。
良いアーキテクチャーというのは壊れにくく
フィードバックループが短く
優れているということだそうです。
まず初期コストをどこまでかけられるかというのと
長期的なことを視点に
どこまでシンプルにするかというのは
結構難しい話ですけど
お金とリソースの話が出てくると思うので
あれですけど
あまりシンプルすぎると今後の
アーキテクチャー的には苦痛が大きくなるのは
確かにそうですよね。
大体アプリケーションはどんどんどんどん
大きくなっていくのはよくある話なので
あまりシンプルすぎるのも良くないよねというのは確かにありますね。
オーバースペックにするのは
時期少々な感じはありますので
この辺のバランスを取りましょうということだそうです。
続いて2つ目
グレートツールですね。
良い優れたツールを使いましょう。
可能な限り自動化をしましょう。
繰り返される作業は疲れるものです。
自動化することでチームは
アーキテクチャーを理解することができますよということですね。
優れたツールというか
自動化をしようという話ですね。
続いて3つ目の要素は
プロセスによるバックアップだそうです。
プロセスというのは
自動化されたチェックリストとして機能し
毎回行う必要のある一貫したステップというのを提供します。
プロセスを定義することで
チームの規律を守ることができます。
QA、デプロイメント、フィードバック
そしてあなたの会社が
十分な規模であればオンボーディングのために
プロセスというのを使いましょうと。
ラスト4つ目ですね。無毒なチーム文化
無毒
ノンポキシックチームと書いてあるから
確かに直訳するとそうですけど
読んでいこう。
会社の目的を明確にするということです。
お金を稼ぐことだけが目的であってはならない。
カルチャーそのものが
あなたが会社とチームにインストールできる
最も重要なブレインウェアですね。
脳の中で動くソフトウェアのことを
ブレインウェアというらしいです。
開発者が取るすべての決定というのは
インストールされたブレインウェアを通して
フィルタリングされます。
開発者が行うすべての決定というのは
インストールされたブレインウェアによってフィルタリングされ
もし彼らがブレインウェアに同意しないなら
それを無視するようになりますよということです。
これはなんか組織文化とか
チームビルディングとかの話に近い気がしますね。
その結果ブレインウェアというのが
確立されていくような気がするので
どうやってどのようなものを
インストールさせるかというところになるので
結果的にはその組織とチームとかの話だと
僕は感じました。
まあでもそれは本当に大事なことだと思いますのでね。
なかなかこれいいお話ですね。
開発者もちゃんと一つの人間であり
一つのシステムであるみたいな捉え方をしていて
なかなか興味深いなと思いましたね。
あとは
Why you might want the good developer experience
って書いてますからね。
あー違うわ。
優れたデベロッパーエクスペリエンスを求める理由ですね。
なんでっていうところなんですけど
っていうのがいくつかバーっと箇条書きしてあるので
あとダラダラ読んでいくと思います。
一つ目ですね。
良いDXを持つチームはやっぱり
生産性が高くいかない特徴がありますよということで
一つ目。インパクトの感覚です。
彼らは自分たちが単に
15:01
お金を稼いでいるのではないということを理解しています。
自分たちの仕事が重要であり
誰かの生活を向上させているということを理解している。
いわゆるやりがいというか
社会貢献みたいなところですね。
お金そのものではないけど
ちゃんとしたPがあるよっていうところですね。
これは確かに結構大事なことだと思います。
何のために開発しているかわからなくなったとき
開発者はすごいモチベーション下がりますから。
会社のためとか
お金のためってわかってもそのためだけに
行動をかける人って意外と少なかったりしますね。
技術大好きっ子で
技術ばっかり触れていればいいよ
っていう人は別かもしれないですけど
僕の経験上、意外とそういう人は
少ない感じがしますけどね。
続いて、大きな当事者意識と
責任感というところです。
成功に責任を持つチームのメンバー全員が
会社の成功に責任を感じて
いただければなりませんと。
これも結構大事なことかもしれないですね。
意思の統一じゃないですけど
統一することがマストというわけでもないが
やっぱり方向性と
モチベーション的なところが
一致していればやっぱり大きな割りが
ここは結構重要です。
あと、やっぱり責任感を
持ってもらえるかっていうのは
あんまり無理はしたくないですけど
やっぱり持ってほしいなっていうのが
マネジメントとかリーダーシップをしたことある人は
みんな思うと思うんですよ。
そういうチームであればあるほど
頼りがいもあるし
僕も僕で頑張ろうという気にはなるのでね。
責任感という言葉を
最近は扱いづらくなったというのは正直ありますけど。
続いて、共通の目標ですね。
コモンゴールというところです。
部門、そして会社全体と
共通の目標というのを
しっかり持って認識合わせしましょうというところだそうです。
これはもうそのまんまですね。
続いて、親しみやすさと誠実さです。
私たちはこれを
ヘイブロー文化と呼んでいます。
ブローってのはたぶん兄弟TVの
ブラザーの頭の文字三文字ですね。
ヘイブローカルチャーです。
私たちは大きな敬意を持って誠意を尽くす
ということを重視していますよと。
続いて、失敗を許容するという文化ですね。
開発者は勇気を出して
リスクを取るべきです。
しかしリスクは常に計算されたものであるべきで
開発者はすべての行動がどれだけのブームを引き起こすか
というのを意識しなければならないということだそうです。
ここも難しい観点ですね。
あんまりリスクを取りたくはないのも
事実としてありますけど
一方でやっぱりリスクを取らなければ
新しいものを生み出せないというのも事実としてあるので
そのリスクというのはどういうものかというのは
計算されてあるものがあるというのは
よくある話ですね。
ただそのリスクが計算されるべきというのは
いいんですけど、そのリスクによって
どうするかというのはそんなことはわかるわけないので
それを求めるというのも
なんかきついなと思います。
どういうリスクがあるかということの
影響範囲的なものは
ある程度考えられたほうがいいとは
もちろん思いますので、そういうお話かなとは
ちょっと感じました。
続いて、悪いDXを持つ
カルチャーの特徴という話です。
次は悪い面のほうですね。
一つ目は責任点からそうです。
チームメンバー仕事が
うまくいかないことを互いに非難し合うことが
あります。これは非常に
有害なことだがよくあることでもあります。
そうですよね。なんかあったり
うまくいかなかったとき、大体他者批判
しがちですよね。
18:01
よくあるのは、障害が
起きたときに犯人探しをするみたいなところですよね。
僕は犯人探し本当に嫌いで
結果的に最後の
実行したのが
このメンバーだったりするっていうのはあるかもしれないですけど
チームで起こしたことでしょって普通に
僕は思うんですけど。なのに
君が起こしたんだよって言うので君の評価が
下がったってなるのは僕は
ナンセンスだなって思いますけどね。
そういう話もよくあるなって思いました。
責任転換でもよくないよねってことですね。
続いて失敗した
ときのペナルティが大きいと。
これも悪いカルチャーですね。
例えば上司が期限に間に合わなければ
解雇もあり得るみたいなことを言った場合
ですね。なかなか
日本という国ではそんな簡単に
解雇できないように良くも悪くもなってるんで
この言い方はあれかもしれないですけど
日本だと結局言及しになりますよ
とかっていうのは全然ある話だと思いましたね。
こんなことを上司に言われたら
こんな上司の下で仕事したくないってなりますけどね。
続いて常にクランチタイムと
チームに負荷をかけると。
これはそのままだそうですね。この言葉通りで。
まあそれも確かに悪い文化ですね。
はいで続いて敵対心と
不確実性です。
チーム間の不健全な競争心。
例えばこの人は私より良い仕事をしたから昇進したんだ
みたいなところがある
っていうのが悪い文化ですよってことですね。
これもまた難しいですね。お前一人が
仕事したんじゃないよっていう話ではあるし
結局他の人たちの
いろんな協力のもと
ビジネスは成功しますし
プロジェクトも成功すると思っているので
その結果まあ例えばこの人が
コアな実装したとかすごく難しい
ところを担当したっていうのはもちろんあると思うんで
そういうところは評価されると思いますし
それはチームメンバーみんなが評価してくれると思うんで
結果的にちゃんとそういう人は昇進するとは思いますけどね。
だからそういう
良くない競争心を持つっていうのは
やっぱりよろしくないよねっていうのはありますね。
仲間っていうよりも単純に
ビジネスなライバルという
視点で一緒のチームで
仕事をするってことですからね。
良いライバルならいいんですけどこの視点はあんまり
よろしくないなと感じました。続いて
責任の規剥かってところですね。これラスト。
大企業では
誰も責任を取らないように感じることがあります。
こういうような勇気がいることです。
すみません失敗しましたという
勇気がやっぱり大事ですねと。責任を取ることは
やっぱり非常に重要だというお話ですね。
責任自体の規剥は
企業として本当にやばい
バッドケースなので
もしそういうことが起きているんだったら
手小入れをする必要があると思いますけど。
というところでこの記事自体は
あと終了ですね。あと他にいろんなところの
記事のリンクが貼られているので
それを見てみてくださいということでした。
一つ目グッドデベロッパーエクスペナンスですけど
そもそもこのデベロッパーエクスペナンス
代表の記事がサイトですね。
かなりたくさんの記事があるので
合計で今106個の記事があるんですけど
一個一個確かに短いので
一個一個パーッと見ていくのも
全然良さそうなと思いましたね。
一応カテゴリーとしては
いくつかあって
リサーチ&アナリシスト、ビルディングチームと
デベロップメント、あとローンチ
メンテナンス、あとフェーズアウト
フェーズアウトの記事があるんだ。へー面白い。
みたいなカテゴリーで分かれているので
でも興味のある方は見てみてください。
これもちょっと後ほどツイートしますね。
21:01
というところで30分ちょっと過ぎましたが
今日の朝方はこちらで以上にしたいと思います。
今日もご参加いただいた
3名の方、大変にありがとうございました。
また明日もゆるーく読んでいきたいと思いますので
最近はちょっと技術的なところばっかりだったので
そろそろチームビルディング的な話
僕は改めてまた読みたいな
という気はしますが
明日の僕が何を言うのか分からないので
確定はしないということだけ言っておきます。
というわけで
今日はこちらで終了したいと思います。
また水曜日、今日はいい週間中日ですね。
というところで
頑張っていけたらなと思います。
それでは終了します。お疲れ様でした。
