Tweak

Author: kdmsnr

_posts/2025-11-18-FrictionlessForeword.md

@@ -26,11 +26,11 @@ tags: [article]
 
 <!-- They describe effective developer experience in terms of three elements: feedback loops, flow state, and cognitive load. We can only find out whether we are on the right path by getting rapid feedback. The longer the delay between that blue dot moving on my phone-map, the longer I walk in the wrong direction before realizing my mistake. If our feedback is rapid, we can remain in the second element, a flow state, where we can smoothly and rapidly get things done, improving our products and our motivation. Flow also depends on our ability to understand what we need to do, which means we must be wary of being overwhelmed by cognitive load, whether it comes in the form of poorly structured code, flaky tests, or interruptions that break our flow. -->
 
-彼らは効果的な開発者体験を3つの要素で表している。それは「フィードバックループ」「フロー状態」「認知的負荷」だ。正しい道を進んでいるかどうかを判断するには、迅速なフィードバックが不可欠だ。地図アプリで青い点が動く間隔が長ければ長いほど、間違った方向に進んでいると気づくまでの時間は長くなる。フィードバックが迅速であれば、第二の要素「フロー状態」を維持できる。これはスムーズかつ迅速に物事を成し遂げることができ、プロダクトやモチベーションを高めることのできる状態である。フロー状態を維持するには、自分が何をすべきかを理解する能力も重要である。つまり、構造化されていないコード、不完全なテスト、フローを中断させる妨害などで、「認知的負荷」が高まらないように注意を払う必要がある。
+彼らは効果的な開発者体験を3つの要素で表している。それは「フィードバックループ」「フロー状態」「認知的負荷」である。正しい道を進んでいるかどうかを判断するには、迅速なフィードバックが不可欠だ。地図アプリで青い点が動く間隔が長ければ長いほど、間違った方向に進んでいると気づくまでの時間は長くなる。フィードバックが迅速であれば、第二の要素「フロー状態」を維持できる。これはスムーズかつ迅速に物事を成し遂げることができ、プロダクトやモチベーションを高めることのできる状態だ。フロー状態を維持するには、自分が何をすべきかを理解する能力も重要である。つまり、構造化されていないコード、不完全なテスト、フローを中断させる妨害などで、「認知的負荷」が高まらないように注意を払う必要がある。
 
 <!-- Focusing on developer experience is about finding what gets in the way of these three elements. Improving developer experience leads to better outcomes for the business. Those lost hours wrangling with infrastructure is money wasted on developers' salary, and revenue lost because the software took longer to get into production. -->
 
-開発者体験の向上とは、これらの3つの要素の阻害要因を特定することである。開発者体験を改善すれば、ビジネスのアウトカムにつながる。インフラの整備に手間取った結果、開発者の人件費がムダになっただけでなく、ソフトウェアが本番投入されるまでの収益の損失にもつながったのである。
+開発者体験の向上とは、これらの3つの要素の阻害要因を特定することである。開発者体験を改善すれば、ビジネスのアウトカムにつながる。インフラの整備に手間取った結果、開発者の人件費がムダになっただけでなく、ソフトウェアが本番投入されるまでの収益の損失にもつながってしまった。
 
 <!-- The bulk of this book is how to develop a program to find these friction points, figuring out which bits are causing the most trouble - and fixing them. It involves metrics, but used to gain a greater understanding of developer experience. While commit frequency is a simple number that's easy to capture, it can only tell part of the story. Well-chosen developer surveys open up an oft-ignored perspective, interviewing developers adds vital context to the numbers. It's tricky to correlate these to the bottom line, but if we can, these metrics can guide us to a more effective operation. -->