開発生産性の可視化サービスから何を見いだして何ができるのか、あるいはすべきで無いこと
目次 開発生産性を掘り下げるサービスたち 生産性 = 産出量 / 投入量 生産性を向上させる3側面による整理 ①メソッド（生産方式や業務処理方法） ②パフォーマンス（能率や業務実施効率） ③ユーティライゼーション（計画や活用のうまさ加減） (余談) SPACE フレームワークについて 生産性関連データの可視化で何を見いだせるのか アウトカムの厳密な可視化は難しい 機能としてはアウトプットの可視化に比重が寄る 生産性の可視化を必要としないこともある 可視化された情報から何ができるのか アクティビティ傾向の変化や異常の発見 意思決定における再現性の担保 説明責任における透明性の担保 総じて、すべきでは無いこと 速度と量の回し車にしない 意味を見いだせない指標を運用しない どうぞご健康で！ 開発生産性を掘り下げるサービスたち 開発に関わるインテリジェンスを提供する SaaS には国内では私が勤め
開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する
この記事は前作 開発生産性の可視化サービスから何を見いだして何ができるのか、あるいはすべきで無いこと に続き、開発生産性へのスタンスを整理したい2作目です。 効果・成果よりも効率を優先することは生産性か？ 開発生産性と言いながら単なるアクティビティの量や時間を見て効率改善を志してしまういくつかの状況、一部の風潮に対して疑問を呈したい。 例えば、PRやイシューの起票数などアウトプット量の高低に一喜一憂する 例えば、変更のリードタイムやデプロイ頻度の増進を過度に重視する 例えば、サイクルタイムの各時間を人間の努力のみで短縮しようとする それにも関わらず、開発がもたらしたユーザーへの効果やビジネス上の成果に無関心というのは順序おかしいよね、という話。 などと考えていたら開発生産性カンファレンス2024 - 登壇資料まとめ｜610を見る限り、近しい主旨の論説を散見するに至り、もしかしたら世間の議論
JavaScriptよ。文明を捨て、自然に還れ。
Web ナチュラリスト フィードを眺めていたら Alex Russell 氏の新作が投稿されていた。 The "Developer Experience" Bait-and-Switch | Infrequently Noted 本来の趣旨については原文を読んでもらえばいいし、下記はこれを読んだ上で普段の考えを踏まえて脳裏をよぎったポエムである。 我々は複雑性で仕事をしている 仕事をしている、もしくはそれでお金を稼いでいる。誰もが。 私は 2012 年頃から Web の、特に Web フロントエンドの複雑性に加担している自覚がある。 Web の専門性が高まることはその技術領域に深淵な価値があることを示唆し、それに携わることの価値を相対的に向上させることができる。 私の活動そのものは些細なものだが、かくして 2018 年現在の Web はかくも複雑になることに成功し、エンジニアリングの名の下
SSR と CDN ( Fastly ) とユーザー依存情報、その後
正式リリースに向けての開発で表面化した不都合 以前、アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離（新規開発のメモ書きシリーズ4）で紹介したように、SSR で生成した HTML を CDN ( Fastly ) でキャッシュできるように「ユーザー依存情報はクライアントサイドで非同期に取り扱うというアプローチ」をとっていました。それによって発生していた不都合と解決に関する追加情報です。 ユーザー依存情報が非同期でレイアウトされる問題 ユーザー依存情報が非同期で解決されるということは、そのような情報を扱うコンポーネントの矩形は Web ページが一度レンダリングされたあとにレイアウトされます。つまりこの記事でも紹介されたところの「ガタンッ」的なユーザー体験が生じます。 ログインと非ログインが、全く同じサイズの矩形を確保するようなビジュアルデザインになってい
アーキテクチャ編: SSR と CDN ( Fastly ) とユーザー依存情報の分離（新規開発のメモ書きシリーズ4）
新規開発のメモ書きのラスト シリーズだったはずなのに、色々あって前回のエントリから1ヶ月あきました。_:(´ཀ`」 ∠): 今回の話の中心は結果的に「Server Side Rendering との折り合いの付け方」と「Fastly を利用した動的コンテンツのキャッシュ戦略」です。 このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と webpack との距離感 コード設計編: context による縦軸分類とレイヤードアーキテクチャ まずは全体的なアーキテクチャ像 次の図はアーキテクチャの全体像です。クライアントサイド寄りの範囲を中心に書いているため、バックエンドな Microservice 群以降がおざなりな図ではありますがご容赦ください。 主要リソースは Fastly を通じ
コード設計編: context による縦軸分類とレイヤードアーキテクチャ（新規開発のメモ書きシリーズ3）
流行りの monorepo 風味と DDD 風味？ 今回はコードの設計について書き残します。主に JavaScript 界の話です。Web アプリケーション全体の設計は次回で、今回はコード面の設計に限定して書き留めています。プロダクト全体のアーキテクチャは次の記事で述べる予定ですが大雑把には、メディアっぽいサービスでありつつも SPA + SSR が許容される程度には要件定義の時点でコードの行数がかさむことが約束されたプロダクトです。 今回は大きく分けて下記について述べています ディレクトリ構造 オブジェクトの種類と責務 Flux 的なデータフロー あくまで風味なので今回、専門用語の意味ズレなどは優しくお願いします... このシリーズの他の記事はこちら。 技術要素編: web アプリが新陳代謝を続けるための依存関係の厳選 ビルド設定編: UA に応じた最適な JS バンドルの配信と web
Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc...
色々なパフォーマンス指標のこと 何かを評価するときには何らかの指標（メトリクス）を定めますが、何を指標として設定してどのように測るかというのは重要です。 いわゆる KPI もそうですが、扱っている商材やビジネスのステージ（フェーズ）によっても適切な指標は変わるかもしれません。色々な指標をよく理解して引き出しを広げておくことは、状況に合わせて適切な指標を選んで改善していく過程で役立ちます。 これまでのパフォーマンス指標 過去の Web パフォーマンス界隈はバックエンドから HTML ドキュメントを返却する際の所要時間や、Web ページロード時の各イベントの発火時間を計測する方法が多く見られました。 Backend Time Browser Event Based DOMContentLoaded Page load ( onload ) 近年は特に後者の、既定のイベント発火に依存していたクラ
SPA + サーバーサイドレンダリング、そのダルさに関する私見
いわゆる SPA + サーバーサイドレンダリングがダルい 唐突ですがおさらいです。 なぜサーバーサイドレンダリング（SSR）が嬉しいかと言えば 初期表示の Critical Rendering Path を短縮できる SEO における保守信仰にやさしい（） 古いブラウザ・低性能マシンにやさしい yahoo/fluxible による SPA + Server Rendering の概観 ::ハブろぐ であり、特に SPA + SSR の文脈においては Universal Architecture による SPA + SSR は、技術的には過渡期の歪なキメラっぽさが拭いきれませんが、昨今の Web フロントエンドにしては珍しくビジネス的な説得力があります。 SSR なのでSNSや検索からの流入による初期表示が速い SPA なので回遊時のページ遷移も速い SSR なので古いブラウザでも CSS
リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い！これこそ未来のワークスタイル！」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、本社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基本は Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長
Angularそっちのけで、Vue.jsについて所感
Vue.js 軽量でパワフルなデータバインディングMVVM, vue.jsで遊んでみた - mizchi's blog を読んで触発されたので、自分も外見的に良いなと思ったポイントだけ書き留めてみます。さすがに実戦投入できていないので、そのあたりの精度は悪しからず。 サンプルコードの雰囲気 サンプルコードとか自分でちょっと触ってみたときの感触からは、以下のポイントが気に入りました。data-bidingsとかは前提として便利です。はい。 覚え切れそうな分量のAPI Class: Vue - vue.js 脳みそちっちゃいので助かります。それに尽きる。 プロパティによる宣言っぽさ Angularだとイベントハンドラ類を書くにも、$scopeに都度ハンドラを仕込んでいくのがあまり好きでないです。工夫で回避できそうですが、与えられたスタートが下記のような状態であることには変わりません。 angu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
