ソフトウェア開発の一側面：摩擦を減らし続ける

はじめに

お 姉 さ ん😇 nikkieです

学マスに持ってかれてないで、本日の一本。
「Refactoring -- Not on the backlog!」の感想を書いたのをきっかけに気づいたことを書き散らします。

目次

前提：「Refactoring -- Not on the backlog!」感想

Ron Jeffries氏はコードベースに茂みの例えを導入して、リファクタリングを後でまとめてやろうとせずに、現在の機能開発の中で関連する茂みに道を通そう（＝リファクタリングしよう）と説いています。
「この茂みは摩擦ととらえられるのでは」というのがこの記事を駆動している気付きです

摩擦を減らす

「(Software) Development with Agility」 （角谷さん）

こちらのスライドを思い出し。

チームの仕事の流れの"摩擦"を低減するための（略）

摩擦の例として挙がっているものの中に「コードベース」もありますね。

この発表「(Software) Development with Agility」は、（アジャイル開発なるものがあるわけではなく）ソフトウェア開発にアジリティが備わっているというとらえ方を説いています。
アジリティを備えたソフトウェア開発の一要素が摩擦を減らすということ。
開発（仕事）を流していくために、摩擦を減らしたいという理解です。

質の高いフィードバックを得るために生じる"摩擦"を減らす

『The Art of Agile Development, Second Edition』の「Zero Friction」

AoAD 2nd editionにゼロ摩擦とでも呼べる章があります。

この概念は衝撃でした。
ここで紹介されるプラクティスを取り入れていけば「1時間デプロイ」（機能開発からリリースまで1時間の意）ができそうに思われます。

• 1秒フィードバック（One-Second Feedback）
• 5分インテグレーション（Five-Minute Integration）

時間の短さに目を奪われますが、肝は摩擦が非常に小さい・ないことと私は捉えています。

新卒時代の言葉「庶務とは」

新卒で入った会社では、同期で庶務¹を持ち回りました。
この庶務をなぜやるのかという話で印象に残っている言葉があります。
それは、庶務はデコボコした道をならして平らにする活動ということ。

平らな道を進むことは簡単です。
一方、デコボコした道を進むのは、平らな道と比べて困難を伴います。
仕事をしていく中で、デコボコした道をならせるかが大事という話で、これは心の片隅に留まりました。

さて今回の摩擦の話ですが、庶務の本質と重なるように思われます。
デコボコした道とは、摩擦を無視できない状態。
そこから摩擦を減らしていくんだ！

コードベースにおける摩擦が、茂み

コードベースの茂みには、避ける（迂回する）という選択肢もありました。
道を通す（＝リファクタリングする）ことを後回しにするという選択肢です。

実装していて「コードベースのこの既存の実装、引っかかるなあ」という箇所が茂みと捉えています。
この引っかかり、摩擦っぽさがありますよね。

迂回せずに道を通し続けること、すなわち、摩擦を放置せず低減させ小さい状態に留めること。
私の中ではつながりました！

ただし、摩擦を減らすのが主目的ではない

ソフトウェア開発において摩擦を減らし続けるのが重要と理解しましたが、摩擦を減らすを主目的にしてしまう転倒には注意したいですね。
元はといえばソフトウェア開発をうまくやっていきたいわけで、うまくやるために必要な一要素が摩擦を減らす動き方という理解です。

ソフトウェア開発（やプロダクトをユーザに届ける）ことをやっていくなかで摩擦を認識するのだと思います。
開発して価値を届けるという活動が本丸であり、その副次的な活動として、気付いた摩擦は（後回しにせず）取り組む中で取り除く！
摩擦を減らすことだけに夢中になっては、ユーザにプロダクトを届けられませんからね（技術で殴って摩擦を減らすのが好きな自分への警句として）

終わりに

Ron Jeffries氏のリファクタリングについての記事をきっかけに、摩擦を取り除くと捉えられるという気付きを書きました。
プロダクトを届ける活動の中で気付いた摩擦は、取り除くのです！

ソフトウェア開発の一要素として考えてみましたが、生活の中でもこまめに摩擦を除いていくのが大事かもと思います（後回しにし続けて片付けが必要な部屋を見ながら）。
書き散らしたくなったら人生篇も書いてみます

---

1. スーパー大辞林より「いろいろな雑務。雑多な事務。」↩