Slide 1

Slide 1 text

技術的負債

Slide 2

Slide 2 text

「技術的負債」の初出 ウォード・カニンガム • アジャイルエバンジェリストで5本の指に入る 1992年 • アジャイルがまだ少数プロジェクトで試されていたころ

Slide 3

Slide 3 text

技術者は昔から知っていたんですよね こういうの とにかくめ んどくさい 汚いコート度書く のは早いけど後 ですごい苦労す る ライブラリのバー ジョンアップを後 でまとめてやろう とすると大変苦労 する シンプルな構造 を考えて整理して から書き始めな いとかえって時間 がかかる

Slide 4

Slide 4 text

上司や顧客視点だと そういうことすると、めんど くさいんでスケジュール遅 らせてください プログラ マー あほか。そんな もんやるな。 上司、顧 客

Slide 5

Slide 5 text

アジャイルの宣伝手法 プログラマー プロジェクトマネージャー ユーザーの偉い人 アジャイル エバンジェリスト おまえらはいなくなれ

Slide 6

Slide 6 text

技術者にとっての技術的負債 以上 名前がつくと説明しやすくていいよね なかなか周りにわかってもらえなかった 知ってた なんか世の中の理解が ここで止まってるんですけど

Slide 7

Slide 7 text

経営者にとっての負債 • 頑張って無借金経営をやっている会社もあり ますが、半分よりは少ない • 適切な経営をするには、必要な時に必要な 資金が必要 必要な時は必要

Slide 8

Slide 8 text

経営者にとっての負債 • 負債の額に比例して、定期的に利子を出費 しなくてはならない • つまり負債の額に比例して売上上げても利 益が減る でも増やしたくない

Slide 9

Slide 9 text

経営者にとっての負債 • 戦略的に成長するための業務は、上げた利 益を使って行うことができる。 • つまり負債が多ければ多いほど、成長のた めにできることが減る。 多すぎると打てる手が減る

Slide 10

Slide 10 text

経営者にとっての負債 • 現在存在するどんな問題も解決するためのコストは ゼロとなる。 • 何も解決できない。 • このまま負債が増えていくのを見ていることしかでき ない。 増えすぎると首が回らなくなる

Slide 11

Slide 11 text

技術者にとっての技術的負債 • 完全に存在しないって所はまずない • 必要な時は必要と理解して技術的負債は増やす。 • 動かすことが難しい納期 • 経営的に必要な時期に必要な機能を用意する必 要がある 必要な時は必要

Slide 12

Slide 12 text

技術者にとっての技術的負債 • 技術的負債に比例して何をするにもコストが 上がる • つまり技術的負債に比例して常に実装でき る機能が減る でも増やしたくない

Slide 13

Slide 13 text

技術者にとっての技術的負債 • 当然だが、必要な機能を実装するにはコスト が必要 • つまり技術的負債が多ければ多いほど、実 装できる機能は減ったまま 多すぎると打てる手が減る

Slide 14

Slide 14 text

技術者にとっての技術的負債 • 現在存在するどんな問題も解決するために莫大なコストがかかる。 • 日本の銀行なんかは一行修正するために2か月かかるとかいう 噂ですね。 • 動いているコードを治すことは禁止。 • このまま技術的負債が増えていくのを見ていることしかできない。 増えすぎると首が回らなくなる

Slide 15

Slide 15 text

技術者にとっての技術的負債の苦しさ 戦略的投資に使える予 算がゼロなのと同じ 何をやろうとし ても非現実的 な見積もりを 出すしかない。

Slide 16

Slide 16 text

技術的負債 を増やして納 期を短縮して 喜んでいる 借金を増や して現金が 増えたと喜 んでいる 借金を売り上 げに計上して る?

Slide 17

Slide 17 text

どこまで目指すか 明確にできない理由がな ければゼロをめざします

Slide 18

Slide 18 text

ゼロってどこ? たとえ話なんで、負債と違うところもある。 負債はゼロ以下には ならない 技術的負債のゼロは どこか決まっていない

Slide 19

Slide 19 text

どの辺を目指す? 人類の最先端を目指すとすごいコストが GAFAMあたりを目指す? •規模が大きい会社がピンとこなければ ThrouwWorks,37signalsなども。 GAFAMの8年前くらいを目指すのがコスト パフォーマンス的にいいのではないかと。 •日本語資料がそろっていて、読めば学べる環境。

Slide 20

Slide 20 text

具体的に8年前はどんな感じ 自動化は完全に終わったという話も •AWSが一日に何個もリリースしている。 •Googleのサービスは常にA/Bテストを数十個動かしているという。 •定期的にデータセンターをわざと止めてみて復旧スクリプトの動作確認。 リファクタリング •完全なDRY(同じコードは絶対に二度書かない) •Clean Architecture •商品コンセプトが変わろうが、使うライブラリを差し替えようが、業界の業務の体系が激変しようが、いつでも最適なアーキ テクチャにリファクタリングできる。 自動テスト •階層化されている •最下層はカバレッジ90%以上 目指しましょう。

Slide 21

Slide 21 text

私が目指している技術者像 お客さんがやヴィジョナリィが突然何かを 言ってきたとき,もちろん無理なことは無理 というのが技術者の責務ですが、できるだ け多くの場合に「いいですよ」と簡単に言え る。そのための準備を常に整えておく。