概要
2023年11月23日、私は技術的負債に向き合う Online Conference 」にて「走馬灯のIaCは考えておいて - Infrastructure as Codeの導入において技術的負債を考える」というテーマで登壇しました。このセッションでは、Infrastructure as Code(IaC)の実践方法と、技術的負債に対処する際の考慮点について深掘りしました。
資料
かなり概念系の資料になっているので実践編の登壇の登壇したいので誰か招待してくれ!!!この辺を先に整理しておかないと先の進化的アーキテクチャやA Philosophy of Software Designの話ができないので前提条件をまとめておきました。
技術的負債というメタファー に対する違和感
私は、技術的な負債についての一般的な表現に違和感を感じています。この点で、まつもとりーさんも技術的負債という表現に対して抵抗を感じていたようです。
M年N回目なんですけど、技術的負債という言語化にはずっと抵抗がありまして.......困ったな
— まつもとりー / Ryosuke Matsumoto (@matsumotory) 2023年11月21日
この言葉の「負債」という部分が、技術的な問題の本質や性質を正確に捉えていないと感じたため、私は「技術的な腐敗と発酵」という言葉に置き換えることにしました。
この新しいメタファーは、技術的問題が時間の経過とともに変化し、時には複雑化や悪化するプロセスをより的確に表現しています。例えば、「腐敗」は、問題が放置されることでシステムの健全性が低下する様子を示し、「発酵」は、初めは小さな問題が時間とともに変化し、場合によっては新たな価値を生み出す可能性があることを意味します。
この観点から、私は自身のプレゼンテーションや議論の中で、技術的な問題を扱う際にこれらの言葉を使用しました。
普通に元ネタがあります。
実生活の発酵と腐敗の違い
実生活における「発酵」と「腐敗」はどちらも微生物の作用による物質の変化プロセスであり、人間にとっての利益に基づいて定義されます。発酵は、生物の作用によって物質が変化し、人間にとって有益なものに変わるプロセスを指し、ヨーグルト、チーズ、醤油などが例として挙げられます。一方、腐敗は同じく微生物の作用による物質の変化ですが、不快な臭いや有害な物質が発生し、人間にとって有害とされるプロセスを指します。この考え方は、インフラの世界にも当てはまります。時間の経過とともに技術が進化し、新しい技術が古い技術に取って代わることが多い中で、長く使用され信頼性が高まった「枯れた技術」は発酵に、時代遅れとなりリスクを引き起こす技術は腐敗に例えられます。これにより、古い技術を見直し、必要に応じて新しい技術に移行するかの判断が容易になり、インフラの健全性と持続可能性を保つ上で重要な役割を果たします。
負債と言わないことが負債と向き合うこと
「負債と言わないことが負債と向き合うこと」という素晴らしい発表があった。メタファーの限界と実際の技術的課題への取り組みの重要性を改めて感じました。この発表は、言葉だけでなく、根本的な問題解決に焦点を当てることの大切さを示しています。私は向き合わずに逃げたので...。
確かに、メタファーは理解を深めるための一つの手段ですが、それにとどまらず、具体的な問題や課題に目を向け、解決策を見つけて実行することが不可欠です。この点において、私は自分の業務、特にSRE(Site Reliability Engineering)の領域において「トイル」という用語が使われていることに気づきました(これも状況を整理するためのメタファーではある)。
「トイル」とは、SREのコンテキストで使われる用語で、繰り返し行われる、自動化されていない、戦略的価値の低い作業を指します。この用語を用いることで、SREは単に作業を行うのではなく、その作業がなぜ存在し、どのように改善できるかを考えるように促されます。
このような言葉の使い方は、メタファーを超えて、実際の作業の性質や価値を正確に捉え、それに基づいて改善策を模索する手助けとなります。最終的には、このような言葉の使い方が、より効果的で生産的な仕事に取り組むことができます。
言葉は単なるコミュニケーションの道具ではなく、私たちの思考や行動に影響を与える強力なツールです。そのため、技術的な課題に取り組む際には、適切な用語を選び、それを戦略的に活用することが重要です。
何が技術的負債に変わるのか
技術的負債という言葉のメタファーとしての強さ。技術的負債に向き合う幾つかのヒントをいくつかいただいたので気になった人はぜひ、読んでみてほしい。
決定版・ゲームの神様 横井軍平のことばが気になったのでAmazonで調べたところ2023年11月21日現在では20000円だった。
ソフトウェアの内部品質に生じる様々な問題は組織設計にその原因があることも多い
良い内容だったので感想書く
異なる思想で書かれたコードの統一に動く -Terraformの場合-
良い内容だったので感想書く
技術的負債が生まれる背景を理解して,アーリーからレイター向けの根本的なアプローチを考える
良い内容だったので感想書く
参考資料
- Infrastructure as Code
- Infrastructure as Code 再考
- Infrastructure as Codeのこれまでとこれから/Infra Study Meetup #1
- わたしたちにIaCはまだ早かったのかもしれない
- The History of DevOps Reports
- Effective DevOps
- LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する
- 継続的デリバリーのソフトウェア工学:もっと早く、もっと良いソフトウェアを作るための秘訣
- メタファーとしての発酵
- Hashicorp Developer
- Chef Infra
- Ansible - Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy and maintain.
- aws-cdk - The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
- Pulumi - Infrastructure as Code in any programming language.
- dapr - Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.
- dagger - Application Delivery as Code that Runs Anywhere
- Infrastructure as Code, 3rd Edition
- Platform Engineering Meetup
- Backstage - Backstage is an open platform for building developer portals
- backstage.io
- What is platform engineering?
- DXを成功に導くクラウド活用推進ガイド CCoEベストプラクティス
- ウェブオペレーション―サイト運用管理の実践テクニック