BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Meetupでの技術的負債の取り組み

Meetupでの技術的負債の取り組み

ブックマーク

原文(投稿日:2017/08/24)へのリンク

継続的に製品の健全性を保つには定期的に一番影響のある技術的負債を優先順位付けして、それらを全体的に解消していくことだ。MeetupのCTOであるYvette Pasqua氏は、技術的負債に対する取り組み方を継続的に繰り返し適用することでより大きな成果を生み出すことを推奨している。最も影響の大きい負債から取り組み、その負債を解消したことで生まれる改善について伝える、というのが氏の主張だ。

氏はCraft 2017で、大規模に技術的負債解消に取り組むことについて話をした。InfoQはこのカンファレンスの内容をインタビューや記事で紹介している。

定量的に技術的負債を測ることについての講演の後、InfoQは、氏にインタビューして製品の健全性を改善すること、技術的負債解消から学んだこと、技術的負債の計測と低減のためにMeetupが使ったツール、製品の健全性を支援する文化を確立することについて話を聞いた。

InfoQ: 技術的負債は定量化できますか。

Yvette Pasqua: 私の調査と経験では、技術的な負債の定量化には多くの時間を費やすことをお勧めします。徹底的に仕事に取り組むなら、多くの時間がかかるでしょう。しかし、その努力は最終的には正確な成果にはなりません。というのは、技術的負債には多くの種別があり、そのほとんどは未定義で計量できる状態ではないからです。

私は講演でDoSomething.orgのCTOであるMatt Holford氏が書いたCan Technical Debt Be Quantifiedという素晴らしい記事に言及しました。氏はこの記事で技術的負債の定量化について書いており、"技術的負債は常に定量化可能というわけではない"、と書いています。動きの早い技術企業の場合、技術的負債を定量化しようとすることに大きな価値を見出せません。その代わりに、定期的に最も影響の大きい技術的負債を優先順位付けして、長期間に渡る技術的負債解消の動きの一つとその負債を解消するのが良いでしょう。したがって、私は、定量化よりも優先順位付けであり、最も優先度が高いものについて素早く行動を起こすのを推奨します。

InfoQ: カンファレンスでは継続的な製品の健全性について話ましたね。もう少し詳しく教えてください。

Pasqua:会社全体で足並みを揃える必要がありました。また、会社全体が技術と製品の負債に取り組むことに奮起するようにする必要がありました。とても大きな動きだったからです。成功するのはわかっていましたが、単なるエンジニアリングの動きではなく、技術的負債とは何なのか、解消するのがなぜ重要なのか、そして、大きな影響を生み出すための私たちの計画はどんなものかについて企業全体で足並みを揃える必要がありました。したがって、企業全体で話したり思い出したりするための、簡単で明確でポジティブな形のブランディングをしました。それが、製品の継続的な健全性(Continuous Product Health)です。簡単な定義は次のようなものです。"製品の機能だけでなくコードベース全体に対する継続的な注目"。製品の健全性は皆が求めるポジティブで明確なものです。特にエンジニアリングの外にいる人が製品の健全性について話してくれることが重要です。そうなると、彼らは製品の継続的な健全性に取り組む私たちが、企業全体の製品戦略や企業の目標達成のために時間を使っているということを常に想像してくれるようになります。

InfoQ: 製品の健全性をどのように改善しましたか。

Pasqua: 取り組んできた技術的負債のうち、最も大きな影響を及ぼしているものは次の通りです。

  • データセンターにある独自のRabbitMQサーバをAWS SQSを使うように変更しました。メッセージングソリューションの運用やメンテナンス、スケーリングにエンジニアリングの時間を使いたくなかったのです。Meetupの製品を私たちのミッションに近づけることに注力したかったのです。さまざまなマネージドなソリューションを探り、AWS SQSに移行することでエンジニアリングの生産性を手に入れ、システムがより単純になり、望ましい信頼性が手に入るという結論に至りました。今までのところ、この決断にはとても満足しています。
  • 巨大な一枚岩のコードベースに対する単体テストの網羅率を改善したいと考えていました。今までの網羅率はとても低かったのです。新しいコードや更新されたコードには全て単体テストを書くようにしました。これによって継続的配置が高速になると見込んでいました。可能な限りテストの土台を信頼したかったからです。テストの網羅率全体だけでなく、"アクティブなコード"として変更したものについては、100%のカバレッジに近づくことにも注力しました。 テストカバレッジの目標を設定し、Coverallsを使用してエンジニアの前で定期的にカバレッジメトリックを測定して取得し、カバレッジを大幅に向上させました。
  • 過去1年間に支払った技術的負債の最大の1つは、データセンターからクラウドへの移行でした。ここで話題になることはたくさんありますが、私たちを導いたアプローチの1つは、"そのまま持っていく"ことをせずに、クラウド移行直後から便益を享受できる点についてはマネージドサービスを使おうとしたことです。また、システムの多くの部分を状態を持たない"家畜の群れ"として移行し、インフラをコードとして構築した。状態を気にせずにシステムがダウンしたり、新しいインスタンスを自動でスケールできるようにするためです。システムから状態を持ち、手動の運用が必要な"ペット"の数を減らしました。

また、この移行については私のブログにも書きました

InfoQ: 技術的負債に取り組むことからどのようなことを学びましたか。

Pasqua: 技術的負債に取り組む大きな動きの中で私たちが学んだことは以下の通りです。

  • 技術的負債に対する取り組み方を継続的に反復することでより大きな影響を与えることができます。製品市場にフィットするように製品を常に反復しているように、技術的負債に対する取り組み方も継続的に反復して、より効果的な結果を生み出す必要があります。最初は完全に成功するわけではありませんが、できるだけ早く作業し、インパクトを測定し、失敗して早く学び、反復を適用し続けます。
  • 特にエンジニアリングの外では、技術的負債の解消の影響について、コミュニケーションを重視する必要があります。負債の解消が製品戦略や企業の目標にどのように影響するかを明確に描き、常にこの絵と製品戦略や企業の目標が結びつくようにします。そうしないと、負債の返済に多くの時間が費やされるのを理解できないでしょう。
  • 最も影響のある負債の解消に最初に取り組み、低い影響の負債に低い労力で取り組むという共通の罠にはまらないようにすること。製品に反復的に取り組むのと同じように、ロードマップ上の重要な項目に優先順位をつけるという意識的な努力をしない限り、チームや個人は、多くの場合、計画や定義、実行が容易で、簡単に解消できるような影響の小さい作業に引き付けられてしまいます。エンジニアリングのリーダーシップチームとして、私たちは、製品の健全性についての項目の戦略的な優先順位付けに積極的に取り組む必要があることを学びました。数が多いが影響の小さい項目ではなく、少ないけれど、影響が大きい項目に取り組むためです。

InfoQ: 技術的負債の測定と解消にどのようなツールを使いますか。

Pasqua: 私たちは、企業の目標達成に必要なシステムおよびエンジニアリング文化のために確立した3つの設計指針を見て、技術的負債の削減を測定しています。この設計指針は次の観点で作られています。すなわち、システムのシンプルさ、プラットフォームの信頼性、スピードです。私たちはこれらをさまざまなメトリクスを経由して計測しています。例えば、次のようなメトリクスです。

  • チームが1日にプロダクション環境に投入したPRの数。2017年の目標は30%アップです。これが私たちのエンジニアリングのスピードを計測する主要な方法です。
  • スピード: エンジニアリングのツールとパイプラインの中でボトルネックとして認められるものを測定します。それらは、エンジニアが高速に製品を出荷するのを妨げます。例えば、ビルド時間、自動テストにかかる時間、デプロイにかかる時間、エンジニアが新しいフレームワークに慣れるための時間を計測し改善するプロジェクトを持っています。
  • 信頼性: 私たちは稼働時間を測定し、現在、5つの目標を持っています。また、PagerDutyを使用してシステム全体のページ数とシステムの特定の部分の数を測定し、それらを約30%削減することを目標にしています。
  • 単純さ: これが一番計測が難しいです。単純さの最も良い効果は意図しない結果がソフトウェアに生まれることが少なくなることです。私たちはエンジニアが重大なデグレードの解消に費やす週当たりの時間を計測しています。

InfoQ: 製品の健全性をサポートする文化を確立するためにあなたは何をしましたか。

Pasqua: 私たちが学んだことと、過去1年半にわたって学んだことの大部分は、製品の健全性に常に取り組むエンジニアリングと企業文化の変化に本当に貢献しました。正直なところ、私たちはまだ変化の途中です。製品の健全性とは何か、なぜ重要なのか、どのように取り組むかについて皆が足並みを揃えてスタートできたことが一番大きなことです。明確かつ非専門的な言葉でプロジェクトの背後にある’何を’と"なぜ"を伝えるようにしたことも含まれます。こうすることでプロジェクトの目標について認識を揃え、その目標が支援する製品/企業の目標の達成について足並みが揃い、どのようなエンジニアリングの文化(単純さ、信頼性、スピード)が影響を与えるかについて認識が揃います。最後の部分は重要です。というのは、私たちは、単純さ、信頼性、スピードにポジティブに影響を及ぼしている潜在的な項目の測定結果を見て、この3つに最も大きな影響を与えた項目に優先順位をつけたからです。実際に手を動かすエンジニアが望ましい文化的な変化を実践するようにの足並みを揃え、皆が同じ目標を目指すようにするのはとても重要でした。

 
 

Rate this Article

Adoption Stage
Style
 
 

この記事に星をつける

おすすめ度
スタイル

BT