何が技術的負債に変わるのか

技術的負債に向き合う Online Conference

Nov 21st, 2023

Profile

songmu

id: Songmu (ソンムー)
Masayuki Matsuki / 松木雅幸
株式会社ヘンリー VP of Engineering
おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/
https://metacpan.org/author/SONGMU
好きな言語は、PerlとGoと中国語
3 Times ISUCON Winner Using Perl
入門監視付録C 執筆
「みんなのGo言語」共著者

Profile

songmu

id: Songmu (ソンムー)
♥
- OSS
- Blog / Twitter
- Agile
- Full Cycle Development

代表的なOSS

ghq (メンテナ)
blogsync (メンテナ)
ecschedule
tagpr
gocredits
prompter
etc.

経歴

~2010 英会話学校の営業やSIer等
2011 カヤックソーシャルゲームリードエンジニア
2014 株式会社はてなチーフエンジニア兼Mackerelプロダクトマネージャー
2019 Nature株式会社取締役CTO
2021 Launchable, Inc. Principal Software Engineer
2023 株式会社ヘンリー VP of Engineering

宣伝

リードストーリー

全部きちんとやれるほど人生は長くない

朝起きて、まずはストレッチ。軽く散歩してから家族の朝食を用意して、子供の学校のお見送り。家の掃除をした後に、業務開始。ランチ後に英語レッスン。夕方まで仕事。夕食の支度。夕食と家族団欒。夕食後にジムトレしてからゆっくり入浴。その後読書。スキンケアなど寝る準備を入念にした後、瞑想してから入眠。今日も良い一日だった。

→ 1日40時間くらい必要そう…？それに洗濯ができていませんね…。

常に最善手を指すことはできない

たとえ完全情報ゲームであったとしても
藤井聡太にも不可能である

すべてのことを理想的にできない苦しみと技術的負債

結局優先順位と重み付けをどう変化させていくか
何を「しっかりやるか」「適当に済ませるか」「やらないか」
それが人生の楽しさ

アジェンダ

技術的負債とは
なにが技術的負債に変わるのか
技術的負債に向き合う幾つかのヒント
積極的バージョンアップのススメ

技術的負債とは

強い言葉

あまりにも便利な言葉になってしまった
技術的負債で1500人集客できる

技術的負債という言葉の問題点

バズワード的である
- 解釈が幅があるため議論になるようでならない
開発の体験が悪いという個々の感情的な問題や状況を全て技術的負債という言葉に押し込めがち
- すべてが「技術的負債」になる

メタファーとしての技術的負債

アナロジーとして類似性を深堀りしすぎても仕方がない
- 過度に会計や経営との類似性を見出しても仕方がない
その他のメタファー
- 割れ窓
- code smell
- スパゲッティーコード
- etc.
様々なメタファーがあるが「技術的負債」が一番使われている
- 便利な「サンドバッグ」

脅し文句に使わない

そもそも解像度が低い言葉
立ち向かう時に使うのは良い

技術的負債とは

何らかの技術的な「借り入れ」
それが計画的か否か
- 多くは計画通りにいかない
  - 「ご利用は計画的に」？
- 知らないうちに掴まされていた借金も
返済・踏み倒す・不良債権化
- 不良債権化したものが着目される

技術的負債に向き合えるのは幸せ

多くのプロダクトはその前に消えてしまう
- そういうステージに到達したということ
押し付けられて理不尽を感じることもある
- せっかくの成長機会なのに逃げてしまうのは勿体ない
- とはいえどうにもならないことはありますね…

変化にどう適応していくかが大事

世界が変化し技術的負債が生まれる

なにが技術的負債に変わるのか

世界が変化し技術的負債が生まれる

「自分たちの技術的成長」

自分達が未熟であった
- 人間はいつだって未熟である
例: テストコード
コードを書いた人は偉い

「自分たちの事業成長」

ユーザー規模
コードの規模

ユーザー規模の拡大

例
- 負荷分散
- データストアの分割
- 一部の巨大ユーザー

コードの規模が大きくなる

例: 一枚岩で良かったコードを分割せざるを得なくなる

「ビジネスの変化」

ビジネスルールの変化
事業方針の転換

ビジネスルールの変化の例

消費税
- 軽減税率
診療報酬改定 (2年に一度!)

事業方針の転換

ピボット
特定のユーザー向けの分岐コード

「技術の変遷」

老朽化
技術そのものの変遷
プラクティスの変遷

老朽化

バージョン問題

技術トレンドの変遷

例えば言語トレンドの変化
Perl今でも好きです
「JavaからRubyへ」
そしてJava復権

プラクティスの変遷

http / https
テキストプロトコル / バイナリプロトコル
データセンター内部は平文で良い / E2EE
静的型付けか動的型付けか
アジャイル開発

中間まとめ: 何が技術的負債に変わるのか

自分たちの技術的成長
自分たちの事業成長
- ユーザー規模
- コード規模
ビジネスの変化
- ルールの変更
- ピボット
技術の変遷
- 老朽化
- 技術トレンド
- プラクティスの変遷

技術的負債に向き合う幾つかのヒント

「解決したい課題は何なのか」

「イヤな感じ」を言語化する
周りに説明してちゃんと解決しに行く
勢いで解決してもよい
- 「カッとなって」

課題を認識しても解決できないこともある

レベルがそこに達していない
こういうときはストレス
- それもまた自分たちが未熟だから
課題認識しただけでも価値はある

"YAGNI, KISS"

You ain't gonna need it
- 機能は実際に必要となるまでは追加しない
Keep it simple stupid
- シンプルで愚鈍にする

やらなくてもいいことをやらない

DB分割に備えておく？
- そもそも分割が必要になるケースは稀
- ハードウェアの進化や成長のほうが速いことも
最初からコードを分割しすぎない
消費税がない時代に消費税をケアする必要はなかった
結果的に使わなかったコードは負債になる

「技術の螺旋」

その変化は不可逆な変化だとは限らない

CGIとサーバーレス

実は発想は同じ
- 1リクエストに対して一つのOSプロセスが起動する
メリット
- オンデマンドなリソースアロケーション
- ステートレス化によるプログラムの簡単化
コンテナ技術により復権した

「枯れた技術の水平思考」

「枯れて」安定した技術を活用する。

任天堂つながり

On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart I am a gamer.

岩田さん岩田聡はこんなことを話していた。

「巨人の肩に乗る」

定番、王道、トレンド
エコシステムの強さ
- 誰かが同じ問題を解いてくれている
現場のエンジニアもつぶしがきく
- あまりにも未来がない技術からはさすがに逃げたくなってしまう

標準的なプラクティスに投資する

テストコード
CI/CD
クラウドとIaC
監視・オブザーバビリティ
継続的バージョンアップ

ある程度やり方が定まっていることをちゃんとやるのはコスパが良い。

セオリーなのかワークアラウンドなのかには注意

裏技を避ける
例えば文字列結合などのベンチマーク記事
- 一番直感的な使い方を選ぶ
- 正常進化したら使われなくなるバッドハックを理解する

優れた技術も広く使われないと競争力を失ってしまう

KVSの例

KyotoTycoon
- memcachedプロトコル互換のKVS
- 永続化やレプリケーションが可能なのが良く、広告やソシャゲで使われていた(10年以上前)
- 作者の近年の新作: 2020-07-11 データベースライブラリTkrzwの初版リリース
mycached
- MySQLがmemcachedプロトコルを話せるようにする拡張

この頃はmemcachedプロトコルを話すKVSが良く作られた (サイボウズさんのyrmcdsとか)

mycachedの教訓話 (by kazuhoさん)

https://www.slideshare.net/kazuho/dena-8610364

OSSのKVSはこの後Redisがメジャーになった。memcachedは今でも使われている

定番も安定とは言えない

Perl
Apache
jQuery

変化は必ず起こる。(全然廃れない技術を2つも作ったLinusは"ちょっと"すごい)

「レガシーに敬意を払う」

COBOLを作った人を知っていますか？

グレース・ホッパー (1906-1992)

Grace Hopper Celebration of Women in Computing
- World's largest gathering of women and non-binary technologists
- 1994 - current

「バグ」という言葉を広めた人としても知られる

グレース・ホッパープログラミングの女王

「バグ」を発見した私の娘

中間まとめ: 技術的負債に対する幾つかのヒント

解決したい課題はなんなのか
YAGNI, KISS
技術の螺旋
枯れた技術の水平活用
巨人に肩に乗る
レガシーに敬意を払う

積極的バージョンアップのススメ

昔は踏み倒すのが当たり前だった

ツールチェインの未成熟
依存管理の困難さ
各ソフトウェアのリリースサイクルが不安定
バージョンを上げると壊れるリスクが大きかった
- 互換性の担保が難しい
バージョンアップは「できれば避けたい」

バージョンアップを怠ると簡単に負債化する

「老朽化」
放置すればするほどバージョンアップが困難になる
- しかしいつかはやらないといけない
最悪ビルドできなくなる
- 古いバージョンがもはや存在しない
- 依存関係を再現できない
セキュリティfixが当てられない
ライブラリ類が新しい言語バージョンじゃないと使えない

継続的バージョンアップは今やお得である

新しい機能を使える
パフォーマンスアップ
- フリーランチ

リスクも少なくなった

バージョニングと互換性の維持に関するコンセンサス形成
テストとCIによるチェック
→ 壊れにくくなった

支援ツールの充実

renovate, dependabot は素晴らしい
依存更新管理を自動的にマネジメント
Dockerイメージなどのミドルウェアも更新提案してくれる

定常的な開発フローに組み込む

ギリギリまでバージョンアップしないのではなく継続的に積極的にバージョンアップする
- そっちのほうが省力だしお得である
例えるならマンションの修繕積立金
- ちなみに、修繕引当金は会計上「負債」扱い
イージーに対処できる技術的負債

しかし: バージョンアップ多すぎ問題

言語処理系
ライブラリ
コンテナのベースイメージ
コンテナ実行基盤
ミドルウェア類
etc. etc.

バージョンアップ多すぎ問題への対処法

チーム内で更新ポリシーを決める
バージョンアップが必要なものを減らす
- クラウドやSaaSを使う
安定しているものを使う
- 枯れた技術

余談: OSSとSaaS

OSSは実はダウンロード型ソフトウェアと同じ課題を抱えている

SaaSのメリット
- 最新版1バージョンだけメンテナンスすれば良い
- どの機能が使われているかの調査や統計を取るのが容易
  - 機能廃止のジャッジがやりやすい
- ビジネスとしてデザイナーが雇える
そのメリットの逆がOSSのデメリットである
- OSSに必要以上に厳しい要求をしないほうがお互いのため
- 例えば複数バージョンのメンテナンスを要求するなど

まとめ

技術的負債とは
なにが技術的負債に変わるのか
技術的負債に向き合う幾つかのヒント
積極的バージョンアップのススメ

宣伝

ヘンリーではエンジニアを募集しています！
- 医療DXスタートアップ
  - エンジニア20人程度
  - 電子カルテ・レセプトコンピューターSaaS
- Kotlin / TypeScript
カジュアル面談も歓迎です

https://jobs.henry-app.jp/

宣伝2

OSS活動を支援してくれると嬉しいです。

GitHub Sponsor
- https://github.com/sponsors/Songmu
ghq handbook
- https://leanpub.com/ghq-handbook
- https://zenn.dev/songmu/books/ghq-handbook