技術的負債の正体を知って向き合う

技術的負債の正体を知って向き合う  irof 

irof  • ふつうのプログラマ  • 個人事業主  • 開発全域の支援をしています  • #アイコンだけでも覚えてって下さい  •
関ジャバの中の人してます  ◦ 毎月イベントしてるのでぜひ。  ◦ https://kanjava.connpass.com 

技術的負債という言葉に向き合う  相手を知らないと戦えない 

技術的負債という言葉の出自  • Ward Cunningham（ウォードカニンガム）   ◦ Wikiの発明者、アジャイルソフトウェア開発宣言の著者   •
初出は1992年  ◦ 33歳  ◦ もうすぐ定年だね？  • リファクタリングを上司に説明するために採用したメタファ   ◦ 扱っていたシステムが金融系だったから採用された   ◦ もともと負債に馴染みがある文脈   • 一般的に「負債」にネガティブな印象を持ちがちだが、金融文脈ではポジティブな側面があり、元々のメタファの意図は後者だったりする。   • とはいえ「技術的負債」という言葉が広がったのは一般に認知されているネガティブさがあるが故だろうとか思ったりする。 

いろんな人がいろんなことを言っている例  • A Mess is not a Technical Debt. -
Uncle Bob  ◦ 散乱は負債ではない  • Technical Debt Quadrant - Martin Fowler  ◦ 技術的負債の四象限  • 怪獣大決戦  ◦ この手のはいろんな文脈でしょっちゅうやってるじゃれあいみたいなもの 

ざっくり: Uncle Bob  • 技術的負債と散乱（Mess）は別物である  • 技術的負債とは  ◦ 短期的に利益があるが、将来のリリースを遅らせる  ◦
クリーン  • 散乱とは  ◦ 常に損失となる、その瞬間からリリースを遅らせる  ◦ 怠惰の現れ 

ざっくり: Martin Fowler  • 設計の不備が負債かそうじゃないか考えることがそもそも間違っている  ◦ 慎重に考えた結果かどうかのほうが大事である  ◦ 技術的負債を二軸の四象限で扱うことで散乱も負債のメ
タファで扱える  • メタファは他人と意見交換しやすくするためのもの  

技術的負債の四象限: Martin Fowler 

技術的負債の四象限（和訳）: ぶりき 

二者の意見に対する私の理解  • 共通するのは「技術的負債」という言葉のままでは扱いづらいので分類しようとしている  • Uncle Bobは散乱を切り分けて、それをなくしてから技術的負債に向き合おうというアプローチ  • Martin
Fowlerはクラフトのすべてで負債のメタファは有効と見ていて、負債をカテゴライズしてそれぞれ戦っていこうというアプローチ  • どっちも有用なので状況に合いそうなら選ぶ 

技術的負債という言葉の変遷  • 金融文脈の現場で非開発者向けの使われたメタファ  ◦ 「技術的」はつかない模様  • 30年間さまざまな文脈で使用されてきた  ◦ 金融エキスパートでない人とは捉え方が違う  ◦
この過程で「技術的」がついた単語になった  • 現代では様々な解釈がある  ◦ XXXの技術的負債はYYYの技術的負債とは異なる 

補足: メタファ（比喩）  • 理解を助けるためのたとえ  • 使用者の意図していないメタファの側面が採用されることがある  ◦ 理解を助けることもあれば阻害することもある  •
メタファの時点で輪郭ははっきりしないもの  • 「そういうもの」として扱うのがポイント 

つまり技術的負債という言葉は  • 元々は金融文脈で非エンジニアに説明するためのもの  • 言葉単体では非常に曖昧なものになっている  • カテゴライズでも要素分解でも良いので役立つように調整する必要がある  • その方法として巨人たちの定義を使用してもいいし、しなくて
もいい  ◦ 曖昧なままでも改善に取り組めているなら十分 

メタファ活用のポイント  • メタファの有用な部分だけ扱う  ◦ 扱いやすい: 元本の返済と利息  ◦ 扱いにくい:
その他の負債に絡むあれこれ  • 扱いにくい部分で試行錯誤したところで、役立たないどころかミスリードまであるのがメタファ  • このメタファはあなたの直面している現実に有用でしょうか？ 

技術的負債は規約で制御できるか？ 

技術的負債と規約  「新たな負債を作らないようにしたい」は万人の求めるところだろう。  その方法として「コーディング規約を作る」とか「XXX標準を作る」とかが挙がることは多い。 

規約は暴走しがち  規約を作ると金科玉条のごとく「それを守ること」が正義になりがちです。  正義は暴走します。すくなくとも暴走するものとして扱う必要があります。 

規約と文書化のあるある  • 読まれないものを書いても意味はありません  • 文書化による弊害もいくらかあります  • たとえば、字面だけで運用できてしまう  ◦ 意図が欠落したり、書いていないことを類推したり  •
たとえば、書いた瞬間から劣化が始まる  ◦ いつの間にか賞味期限が切れてしまう  • たとえば、、、 

紹介: 文書化する際に有効な属性  • 有効期限  ◦ 短めにして「有効期限の更新が行われないものは破棄する」くらいがちょうどいい  ◦ 更新めんどくさい？多すぎるんじゃないかなぁ  •
適用範囲  ◦ ブラックリストではなくホワイトリストで適用範囲を明示する  ◦ 書いていない範囲には適用されないようにする 

紹介: 自分のための規約作り原則  • 重要なものは規約を作りません。  • どっちでもいいものは規約を作り、それに従います。  • 必須なら規約ではなく強制する仕組みを検討します。  私がやる時の原則です。これも重要なのでどこかに刻んだりは
しないです。今回は紹介のために書きました。 

想定ツッコミ: 重要なものこそ必要では？  逆に感じる？たとえば命名規約なら……  重要な部分に規約を作るとしたら「コンテキストを理解し、統一感を持って命名しよう」になります。いらんよね？最もすべき「名前設計」をスポイルするようなルールは邪魔なだけだし。  規約は制限。
制限することで速度を上げられそうなら作る。私は「選択的思考停止」と呼んでる。 

自分（たち）のための規約  • 他者に守らせる規約と、自分が守る規約は性質が違う  • 自分で作るものは自分が早く走るために作る  • 道幅は広い方が速度も出しやすいし燃費もいいし事故も起こしにくい  ◦ 車運転する時に車幅ぴったりのガードレールの間を走り
たい？  ◦ イライラ棒か（もはや伝わらない 

問い: 技術的負債は規約で制御できるか？  • 効果がないとは言わないが全体のカバーはできない  • 効果的な領域、あまり有効出ない領域がある  • 規約で根絶は不可能なことだけはわかる  • （そんな話してないけど感じ取って） 

技術的負債解消に向けた取り組み 

ここでの負債メタファのスコープ  • メタファは扱う部分を強調しておくと混乱が低減できる  • 技術的負債に意識が向くのは利息に困った時  • なので「現在抱えている負債」に注目する  ◦ 扱いやすいのは「返済期日」と「利息」  ◦
あとは「元本」くらいかな  • 「借り入れ」とかは新たに背負う時の話 

返済期日を考える  • 返済しなければ倒産（致命的な状況が起こる）する期日があるか？  ◦ ないなら利息だけ考えればいい  • 期日には予定されたものと予定されていないものがある  ◦ サポート期限などは予定されているもの 
◦ 急に取り立てが発生するものもある 

利息を考える  • 利息の利率  ◦ 額面固定／単利／複利  • 利息の単位  ◦ 作業工数／認知負荷／...  •
利息の生じ方  ◦ 多くの活動／特定の活動  • ... 

利息: 利率複利  • 負債の存在があらたな負債を呼びこみ、元本も増えて利息も増えていくものがある  • 自己増殖型  • 散乱にはこの傾向のものが多い 
◦ 微妙なコードベースほど微妙なコードがそのままコピペされがちだし、一貫性のために微妙な設計を真似ることが推奨されたりもする 

利息: 単位認知負荷  • 「量が多い」だけでも利息がかかる  ◦ ちょっとした作業でかかる時間がかわらなくても頭の片隅で気にすることが増えている状態  • 作業工数以外の単位は蔑ろにされがち 
• 「特定の人しか対応できない」も利息がかかる負債  • 元本と単位が異なるのも特徴  ◦ 現金の利子がポイントでつく、みたいな？ 

技術的負債に対する4つのアプローチ  • A 返済しない  • B 少しずつ返す  • C 計画的に返す 
• D 借り換える 

(A)返済しない  • 期日がなく、利息が無視できるものは返済する必要はありません  ◦ 利息がないものは負債扱いしない  • そのままにしとこ  • やるべきことはいつだって与えられた時間と資金よりも多い
（アジャイルサムライ） 

(B)少しずつ返す  • リファクタリング、あるいはTidy（整頓）  ◦ Tidy First?（Kent Beck）  ◦ Tidy First?のススメ
- 日々常々も見て 

実践例1: 個人活動  • 毎日1コミット以上やる  ◦ 281日継続中（10/08現在）  ◦ 題材: JIG  ▪
2018-02-12生まれの生きたプロダクト  • Tidy First?を元日に読んで思い立った  • やってみたら色々あって色々ある 

実践例2: チーム活動（モブプロ）  • 気になったことを持ち寄って解消する会を定期開催  ◦ このチームでは「試そう会」と呼んでる  ◦ 具体的なコードベースで会話する場としての宣言  • 「解消のさせかたがわからない」とかにアプローチ 

実践例3: チーム活動（個々人）  • 20%ルールのように正式なチーム活動として宣言  ◦ このチームでは「ログボ回収」とか呼んでる  ◦ リファクタリングはボーナスらしい  • Tidyを意識しないと重く捉えがち 
◦ 「片手間でできる程度のことをやる」のメタファとして「ログインボーナス」を採用 

やってみるのが大事だと思ってる  やらないことはうまくならないです。  「がんばらずに続ける」「継続は絶対的な力」とか13年前の私も言ってた。 

(C)計画的に返す  • ……できんの？  • 「定期的に計画を立てて返済する」  ◦ 払えてるのは元本じゃなく溜まった利息では？  • 貯まる構造の方にアプローチしたい気持ちが強いです  •
なので「大規模リファクタリングで解消」にはネガティブな反応をしがちな私。  ◦ 有効な場面や必要な状況は理解できる  ◦ ファーストチョイスにはしない 

パターン1: 事前に計画をたてて返す  • これができるのは「意図的＆慎重」ゾーンだけ  • あまり「技術的負債」と呼ばれない気がする  ◦ シンプルに「後続タスク」とかで扱われている  • （個人的には負債のメタファが十全に力を発揮できるのはこ
の領域だと思ってる） 

パターン2: 見つけ次第計画をたてて返す  • 本来は「不注意＆慎重」ゾーン  • だけど「見なかったことにした」ものに向き合う時にこれをやりがち  ◦ 問題の性質が違うものをまとめて扱うと刺さらない  ◦
利息だけ払うことになる  • 問題と解決には基質特異性がある 

(D)借り換える  • 元のを捨ててより期日が遠かったり利息が低いものに置き換える活動  • レガシーシステムのリプレースはこれ  ◦ 元本が消えるわけではないのが重要  • リファクタリングの延長にあるようで、全然違う力学で動く 
• 負債の性質によっては同じ負債を抱えた新しいものが爆誕します 

借り換えの有効性  • 借り換え（一本化を含む）によって利息が減らせる部分は案外ある  ◦ 負債のメタファよくできてんなぁ  • その気になれば自転車操業も可能 

四象限の活用イメージ  • 分類して、領域ごとに対応を検討する。  • あらかじめ対処できそうなのは無鉄砲サイド 

フェーズごとにできること  • 計画や開発中にできることは増加量を減らす利息を軽減するくらいで減らす活動はしづらい  • 日常が大事  フェーズできること計画返済計画を立てて借り入れる
開発中返済しやすいものや利息の少ない選択肢をとる日常斧を研ぐ／負債や利息を感知する／元本を返済する／ ...

日常＝(B)少しずつ返す重視  • 最も目立つ負債（無鉄砲＆不注意、散乱）を扱うもの  ◦ 「今ある負債」の分析で必要スキルがわかる  ◦ 計画や開発中の取り組みは効果範囲が限定的  • 負債を負債と認識できないと抗いようもない 
◦ 感度を上げて鈍らせない活動をする  • 体質改善なしに負債をなくしてもすぐ再生する  ◦ 負債を生み出す構造が負債 

紹介: ボーイスカウトルール  ソフトウェア開発に持ち込んだのはClean Code（2008, Uncle Bob）らしい。  時間の経過とともにコードがよい方向に向かっていく。そんな光景を想像できますか？これ以外のやり方が専門家にふさわしいものだと思いますか？改善を続けていくことこそが、プロ意識の本質の一部だと思いませんか？ 
圧が強い。 

AIは技術的負債を過去のものにするか  （主題ではないのでだいぶ浅いです）  

AIによる技術的負債の解消  AIでの開発が現実となり、今後も容易になるのはほぼ確約されている。それに乗っかって複雑化したら完全に作り直すことで「負債の蓄積はない」が実現できる。  そういう道が開ける可能性はあることは否定しないし、それなりに高い確度もあるとは思う。  けどまぁまだ違うかなって思ってるレイトマジョリティな私です。 

実践例: AIのリファクタリング活用  同じリファクタリングを3系統で投げ、出来上がったのをざっとみて、筋の良いものを採用する。  こういう投機的な使い方は有効です。  打率は2割程度で、どれも採用しないとかもよくある。投げてる間は拘束されてるわけでもないし、そもそもの期待値が低いので十分かなって感触。 

まとめ 

まとめ: 技術的負債解消に向けた取り組み  • メタファを上手く使うと正体が照らし出せる  ◦ 役立つようにメタファを調整する  • 放置していると利息で身動きがとれなくなる  • 利息を減らすには
地道&継続が現在も有力  • 「リファクタリング」で動きづらいならTidyがいい塩梅  ◦ Tidyからはじめよう  ……そんなこと言ってたっけ？ 

技術的負債の正体を知って向き合う

技術的負債の正体を知って向き合う

More Decks by irof

Other Decks in Programming

Featured

Transcript