🎉

技術的妥協点を見つける〜クイック＆ダーティへのささやかな抵抗〜

2022/12/23に公開

ソフトウェア開発を仕事にしている多くの人が「技術的負債」に対峙しています。
先日、この技術的負債について、@mtx2sさんが『技術的負債は開発者体験を悪化させる』という大変素晴らしいスライドを公開されました。

twitterでも多くの方が取り上げられていて、内容について私が説明する必要はないでしょう。

私がこの記事を書こうと思ったのもこのスライドがきっかけです。というのも、私はソフトウェア開発をする中で、このスライドで紹介されていた「クイック＆ダーティ」と呼ばれる「意図的」で「無謀」な負債を残しがちだと思っています。
しかしながら、「クイック＆ダーティ」が生み出す状況の一つとして挙げられている「結果にも責任を持てない」については、ささやかですが抵抗したい気持ちがあり、記事にしようと思いました。

私のポジションの表明

「技術的負債」という単語は、まず、見た目のインパクトが大きいです。細かい意味がわからなくても、なんとなく、よくないものということはわかります。自分がそれを生み出しているかもしれないと気づくことは気持ちの良いものではないです。
負債を生んだ自分や、そういう体制にした組織を恨むこともあるでしょう。（私も昔そうでした。）
しかしながら、「技術的負債」という概念はソフトウェア開発に潜在的に含まれている問題を明らかにして、改善していく手法の一つとして大変優れていると私は思っています。
そして、今は、負債が生まれそうな時に、自分や組織を恨むのではなく、十分ではないかもしれませんが、精一杯の抵抗したいです。

いかなる理由があっても結果には責任を持ちたい

設計に割く時間は十分にない。という状況は、仕事でソフトウェア開発をしている人の多くが経験したことがあると思います。
とはいえ、結果には責任を持ちたいのが人情ではないでしょうか。私の経験上、どうすることができない制約があったとしても、時間がないことを理由に無責任なコードを書いているときほど辛いことはありません。もし、そんな状態が長く続いていれば私はプログラマを辞めていたかもしれません。
期日やスコープを変更する権限を持っている人（いわゆる、リーダーやオーナーとかマネージャーとかそういう立ち位置の人）は、それを行使して正常な状態を作るべきです。一方で、コードを書いてるプログラマは、自分が置かれている状況の中で最大限、結果に責任を持つ方法を考えるべきだとも思います。十分に時間があれば、疎結合でエレガントなコードをテストコードやドキュメントとともにコミットすることが責任を持つ行動の一つだと思いますが、時間がなくても責任を持つ方法はあると思います。
その方法は状況によりけりで一概には言えませんが、私は「妥協する」ことが多いです。

妥協するということについて

妥協という言葉は、責任を放棄したような文脈で使われることが多いですが、本来の意味は少し違います。秋田道夫さんの『自分に語りかけると時も敬語で』という本の中に、わかりやすい説明があるので、引用させてもらいます。

「妥協」という言葉は本来の意味は悪いものではありません。「妥当なところで双方が協調する（歩み寄る）」。つまりものごとのあるべき点をお互いに認め合う。それが本来の「妥協」です。
『自分に語りかける時も敬語で／秋田道夫』

他にいい言葉があればそれを使いたいのですが適当な言葉が見つからなかったので「妥協」します。

負債は返済する義務がある、妥協は点を残す義務がある

ソフトウェア開発における妥協とは、一言言えば、制約の中での最善の形を見つけて実装です。そして、妥協したところを文章で残すことだと私は考えています。
そもそも制約の中で最善の形を見つけることが難しいのですが、それを仕事にしているので、頑張りどころだと思っています。
文章で残す最も簡単な方法はコードにコメントとして残すことです。またGitHubなどのツールを使っていればissueとして残してもいいでしょう。Pull Requestに残してもいいですが、マージすると一つ奥まったところに移動してしまうのでどちらか選ぶのであればissueの方が良いと思っています。

何を残すのか

以下の３つを書くことが多いです

何を妥協したのか
どういう制約で妥協せざるを得なかったのか
制約がなければどうしたかったのか（理想の姿）

例えば、以下のようなissueを作って、そのissueへのリンクをコードにコメントします。

// テストコードを書くべきなのですが、CIでどうしても失敗してしまうので、今回は見送っています。
// 調べた感じライブラリのバグっぽいので、それが修正されればすんなり実装できるはず。（ライブラリへのissueへのリンク）

また、以下のようなコメントをコードに書くこともあります

// コンポーネントが巨大でまずは適切なサイズにリファクタリングしたいのですが、時間がかかるので一旦この方法で影響範囲を限定して機能を実装します。
// あまり綺麗なコードではないですが、意図しない不具合の発生リスクは小さいです。

言い訳をしたいわけではなくて、色々な制約の中でこの実装をコミットした経緯と背景、コンテキストを記録しておきたいです。

それは、負債に対応することじゃないのか？

部分的にはそうかもしれないです。ただ、時間軸としては、実際に負債を返済するのは、しばらく先のイメージです。一生返済しないかもしれません。
スライドで紹介されていたファウラーの４象限では、一時的に負債が発生するが、すぐに返済する場合に「意図的」で「慎重な」技術的負債だと分類されるので、そうではないです。
イメージとしては、「意図的で無謀」な「クイック＆ダーティ」と「意図的で慎重」な「実験や試行錯誤」の間にある境界をぼやけさせるようなイメージです。

まとめ

改めて秋田道夫さんの本から引用させてもらいます。

以前、とある勉強会で「仕事で妥協したことは、ありますか？」と聞かれたことがあります。質問された方は仕事の中で妥協を余儀なくされていて、納得がいかない状況にあるのだと感じつつ、「妥協は完成の父です」と答えました。
（中略）
ものごとのきっかけとなる「発明」が母なら、現実的な結果は「父」ではないかと。
（中略）
自分の意見がどのような「位置づけ」にあるのかを意識する。納得がいかない部分はごまかさないで記憶にとどめる。そういう捉え方が大事ではないでしょうか。
『自分に語りかける時も敬語で／秋田道夫』

諦めるのではなく、妥協点を探したり、何かしら抗うことで自分や組織を恨まずに「技術的負債」に対峙していきたいですね。