技術的負債に立ち向かうための心構え

ある程度エンジニアを続けていると、技術的負債に出会うことありますよね？
むしろ1から新規でサービスを立ち上げる、ということをしない限りエンジニアは常に技術的負債との戦いです。

新規でサービス作りたいっていう人は多いと思いますが、それはやっぱり
「技術的負債が全くない状態で1からやってみたい」
ということでしょう。

確かに1からサービスをつくることは、そのエンジニアの技術力を遺憾なく発揮することができるだろうと思います。

でも最近思うことは技術的負債に出会ったときにどいういう行動がとれるか、ということがエンジニアとして技術力や成長に差が出てくる気がしてきました。

どうしようもないプログラムを前に、「なんじゃこりゃあぁぁ！！」と文句をいいつつも、しょうがないかと諦めて、同じ環境、同じ運用で、そのまま同じようにプログラムを追加し続けるか。
自分にどうにか改善できることはないかと、考えそれを実行に移せるか

この2つの差は大きい。

技術的負債を返済するには、それなりの技術力は必要

技術的負債の種類にもよりますが、返済するためにはそれなりの技術力が必要だと思うので、これを積極的に行えばスキルも身につくのではとおもいます。

それは よいコードを考える ことと、 今後のことを考えた上での仕事 をするようになるからです。

リファクタリングを通してよいコードを考える

コードが複雑化してしまっている場合は、メンテナンス性をあげるためにリファクタリングをします。
このリファクタリングは目的が「コードのメンテナンス性をあげて、綺麗に書くこと」なので、

「必然的にメンテナンス性の高いコードとは何か？」
「綺麗なコードとは何か？」
ということを考えることになります。

そうすることで、単純な機能開発よりも1歩進んだ考えをすることができるようになり、今後自然とよいコードが書けるようになることでしょう。

この先、このシステム開発に参加する人のことを考えられる

今まさに技術的負債を目の前に苦労をしているのであれば、
「これからは同じ苦しみを生まないようにする」と考えるはず。

まさか「今後来る人も同じ苦しみを味わえ！」なんていう体育会系の部活動精神ではないですよね？

苦しみの理由はいろいろあるかと思いますが、

書いた人でしか読み解けないコード
最新の状態になっていない、もしくは情報が足りないドキュメント
謎のインフラ設定

などがあると思います。

自分が苦労することろは、また別の人が入ってきたときに同じように苦労をすることになります。

こういったものは極力排除をするよう心がけることになることで、他人が読みやすいコードを書くようになるし、インフラの設定も何もない状態から他人に説明をできる状態にまで理解をすることができるようになるため、苦労はしますが自然とスキルレベルがあがっていきます。

いろんな会社の技術的負債

ここ最近技術的負債についての記事を良く見かけるような気がしてきました。

今は技術の進歩もビジネスのスピードも早いので、書いたコードがどんどん負債に。。。(TдT)
こうした世の中にある記事をみていると、技術的負債に関してはどんなすぐれたエンジニアがいるチームでも問題になりますね。

16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する

http://tech.gmo-media.jp/post/135898835279/16th-debt

GMOメディアさんの技術ブログの記事です。
このブログ内ではいわゆる技術的負債のことを「技術的負い目」と表現をしています。
（言い換えている理由はブログ内に書かれているので、そちらをご覧ください）

10年以上にわたる長期間の運用により、システムの老朽化、複雑なプログラム、不要な機能、定期的な障害、聖域となっている共通ライブラリ、謎の外部システムとの連携等々...様々な問題が発生していました。

それなりに規模の大きいシステムなので、これらを改善していくことは相当に骨が折れることだったことだったでしょう。（まだ改善できていない問題もあるようですが） 長年積み重ねてきてしまった技術的負債は結局地道に取り除いていくことしかできない 、、、と感じるブログです。

特にサーバ構成などのインフラ周りで設定に問題ある場合は、変更をするために既存のシステムを止める必要がでてきてしまったりするため準備やテストに時間がかかり精神的にも負担が大きい作業になります。

冒頭にも書きましたが、負い目も含めたシステムのライフサイクルをコントロールしていくべきです。具体的には、負い目を認識した時点でバックログとしてタスク管理を行い、定期的に負い目の棚卸を行っていくべきです。

ここに書かれているとおり、問題を認識した時点で改善の方法をあげていかないと、どんどん問題が大きくなり、後になればなるほど返済が困難になっていってしまいます。

朝Lint活動で細かな技術的負債を返済する

http://techlife.cookpad.com/entry/2015/09/15/190000

CookpadさんのAndroidアプリ開発の話ですが、コンパイル時にlintの警告を出すようにして、その警告をチーム全体で定期的に消すようにすることでプログラムの品質を担保できているということです。

lint警告は出ていても一応プログラムは動きます、ただバグの温床となるのでもちろん消せるなら消したほうがよいです。
lint警告を出し始めた当初は、警告がですぎてログが見づらくなってしまう問題があったようなのですが、この見えづらいという状態を逆に解決するモチベーションにうまいこと変換をしていっていました。

Lint警告の表示そのものは有用なので外したくない、しかし普段邪魔になるのでなんとかしたい、他に良い方法はないか。この振り返り時点での細かな技術的負債に対する感情を整頓するとこのように分解できそうです。
（普段の開発の負担は増やしたくない、改善はしていきたいがモチベーションがあがらない、単発の大きな改善ではなく小さな改善を継続的にしたい、Lint警告は有用だが毎回出るのはイライラするので消し去りたい）

技術的負債に対して上手に向き合い、これは

定期的に時間をとることで問題が大きくならない
チーム全体で品質をあげる取り組みすることで、普段のプログラミングからその意識が芽生える

この2点でいい取り組みだなと思いました。

###【前編】CTO不在で、開発組織改善に着手！一休のエンジニアが語る苦悩の1年
http://tenshoku.mynavi.jp/it-engineer/knowhow/naoya_sushi/07

一休さんの古い開発体制改善していったのお話です。
これはどちらかといえば、開発体制を変えたことがメインになりますので、話としては比較的大きい話しですし、実際改善するにあたってかなりの長期間かかっています。

この辺の問題は単なるスキルの問題よりも、 文化的な問題 がかなり大きく、そのあたりで苦労をした内容も記事内にあります。

とにかく開発組織の改善で一番難しい問題は、技術的に何をどうやるかなんてことじゃなくって、変化を起こす時にそういう人と人の課題が噴出すること。（中略）みんな、新しいことはやりたいと思ってはいるけど、なかなか息が合わないっていうか。

「まあ、ダイエットはしたほうがいいよな...」と思いつつも目の前にあるケーキを食べてしまう。そんな感覚でしょうか。

技術的負債に立ち向かうための心構え

ようやく本題、技術的負債に立ち向かうための心構えです。

技術的負債はエンジニアのとにかくエンジニアのモチベーションエネルギーをどんどん吸い取っていってしまいます。
モチベーションがあがらないと技術力云々のとかいってられません。

そこで技術的負債に気持ちの面で負けないようにするための心構えを紹介します。

ここでは

技術的負債を生み出さないようにする心構え
技術的負債に出会ったときの心構え

を紹介します。

技術的負債を生み出さないようにする心構え

どうしたってコードを書けばいつかは負債になります。
でも少しでもその負債を作り出すのを減らそう、という考えをプラグラムの原則から引っ張ってきました。

YAGNI

You ain't gonna need it（機能は実際必要となるまで実装するな）、という意味。

「なんか後々必要になりそうだから」とか「これあったほうがいいよね」というのは、ほぼつくっても使われない、、、
どっちかというと、使い始めた時に「やっぱりこの機能も必要だった」というので別の機能追加をするパターンのほうが多いです。

ある程度未来を想定して設計をしておくこと自体は悪くない、というかむしろそうしないといけないと思います。
が、将来必要になりそうだから、という理由で機能開発まで進めてしまうのは一呼吸おいたほうがよいですね。

こうした機能は負債となってしまい、 余計なメンテナンスコスト をつくってしまう傾向にあります。

KISS

**Keep it simple, stupid（シンプルにしておけ、バカ）**という意味。

なかなか過激な言い方ではありますが、シンプルさは非常に重要。

もし複雑になってしまいそうであれば、

その処理は本当に必要か
もっと別のアプローチはないのか

というのを考える必要があります。

シンプルさを欠いたコードは他の人がみて処理が追えなくなってしまうため、 コードを書いた人がいなくなれば10中8、9負債 になります。

あなたが今書いている、そのコード。シンプルさは保たれていますか？

ボーイスカウトの原則

ボーイスカウトが山に来る前よりも、綺麗にして帰る行動にちなんだ規則。
コードの状態を自分が触るまえよりも、綺麗にしようという考え。

1つ機能を追加するたびに、1つ負債を返すようにしていけば、大きな問題にはならない、、、はず。

DRY

**Don't Repeat Yourself（同じことは繰り返すな）**という意味。
Railsの基本理念として紹介されているので、プログラムの原則の中でも比較的有名な規則かと思います。

おそらくこの考えはプログラマーは初期の頃から持っているイメージなので説明の必要はないかな。
似たような処理を見つけたら、積極的にまとめていきましょう。( ･ㅂ･)و

技術的負債に出会ったときの心構え

技術的負債に出会い、
「よっしゃ、俺がなんとかしちゃる！」
と思ってもどうにもくじけてしまうことがあるかもしれません。

そんなときに役立つであろうこころ構えです。
ここはちなみにプログラマーの原則ではなく、僕のオリジナル。

最高を目指すな、最善をつくせ

最高の状態を目指すことは非常にすばらしいことです。
でもスポーツ選手が、いきなりオリンピックで金メダルを取ることが無理なように物事には順序があります。

最高の状態だけをみて現状に絶望せず、HTMLタグのインデントを直すだけでもいいので、まずはできることから一歩ずつ現状を解消していきましょう！！！

小さいことでもやり続けていれば、そういうことをするのが普通の雰囲気 なっていくはずです。

たいてい技術的負債は、「まあ、いっか、、、」っていう雰囲気で積み重なっていってしまうものが多いと思ってます。
ベーシックでもかつては、サービスはとりあえず動いているので、大量のエラーログを放置している状態がありました。

それは別にサボっていたわけでもなく、なんか全体的にそういうことをやる雰囲気になっていなかった、というのが大きいと思っています。

それでも今ではエラーログを通知する仕組みを導入したりして、完璧になくすという状態にまではいかないまでもエラーログと向き合うという状態になっています。

誰も恨むな

どうしようのないプログラムに出会ったとき、そして当時そのコードを書いた人がすでにいないとき、なんだか自分だけが苦労をしているみたいで怒りが湧いてきます。(#ﾟДﾟ)ｺﾞﾙｧ!!

でもプログラマーをやっていればわかるのですが、常に最高のコードを書くなんていうの無理です。

「運用を続けていく中で仕様変更があった」
「とにかく最速で作る必要があった」

などなど、そのコードを書いた歴史的背景は必ずあります。その時はそれが最善のコードだったはず。

なので、「このク◯コードが！！」と怒りをぶつける、前にそのコードが生まれた時のプログラマーの気持ちになってみましょう。「このプログラムが生まれたときは、まだこのやり方が主流だったんだよな」とか「ここはとにかく急いでつくっていたんだろうな」ときっと心穏やかになるかとおもいます。

少し話がずれますが、こうした当時のプログラマーの気持ちをコメントに残しておくというのも非常にいいなと思います。

思いを込めたコメント例
よくわかんないけど、メインスレッドで呼び出したら、クラッシュしなくなった。
このコメントを見ると、エンジニアのレベル感も伝わるし、修正しても良いのだなとわかるので、原因がわかる人は修正することができます。

http://qiita.com/koitaro/items/c3720d9c3ac1e7b0590f#コメントは綺麗に書こうとするな思いを込めろ
より

このク◯コードに対して似たような考え方で、すごくいいことをツイートしている方がいましたので、そちらも引用しますね。

美しくないコードをuncodeとかクソースなどと呼ぶ人もいるようですが、これらの言葉は開発者を傷つけるので、最近アプレッソでは、あまり美しくないコードを「ひよコード」、美しくない箇所は「ここがピヨピヨしてる」と表現するようにしています。未熟だけど伸び代はあることを意味しています。
https://twitter.com/lalha2/status/220828104971657216?ref_src=twsrc%5Etfw

技術的負債は今もあなたのそばに・・・

技術的負債は避けて通れない問題。

これからもずっとついて回ることになるので、ただ不満を言うだけにしないでスキルアップのいいチャンスだと思い積極的に技術的負債を返却していくことで、いいエンジニアリングライフを送れるかも？？

ただそれを前提とするには技術的負債を返却してくれるエンジニアをきちんと評価してくれる環境である、というのも重要な要素だと思います。

株式会社ベーシックでは、そんな技術的負債の問題を積極的に解決をしてくれるエンジニアさんを募集しています。