イノベーションは単なる計画ではなく考え方そのもの
エンジニアリング文化に技術的俊敏性を組み込む
JimdoのCTOとして、私はこれまで、アプリケーションのイノベーションがしばしば「ひとつの大きなイベント」として語られるのを見てきました。たとえばデジタルトランスフォーメーションやクラウド移行のように、「一度やり切れば終わり」と考えられがちです。しかし実際には、アプリケーションのイノベーションは開始と終了があるプロジェクトではありません。エンジニアリング文化の中に組 み込むべき「基本的な考え方」です。
テックリーダーにとって本当の課題は、「新機能開発」と「保守」のどちらを選択することではありません。重要なのは、エンジニアリングのリソース（エネルギー）を継続的にどう配分、管理するかです。先日、CloudflareのフィールドCTOであるTrey Guinn氏と、彼らの番組「Beyond the App Stack」で対談した際も、このテーマについて議論しました。つまり、俊敏性を高めつつ、いかに安定性を犠牲にしないかという問題です。
私にとって、その答えはまず、整合性にあります。私は全員一致の合意にはあまり価値を見出していません。成長している企業においては、合意を得るのは非常に困難です。代わりに、私は、ボトムアップの実行と組み合わせたトップダウンの戦略を信頼しています。経営陣が「何を」「どこで」やるかを決め、エンジニアや部門責任者が「どうやるか」を決定します。この役割分担が明確であってこそ、アプリケーションのイノベーションが単なる技術の話ではなく、ビジネス成長の話として機能します。
保守とイノベーションのシーソーゲーム
状況を立て直すために、私たちは「安定性税」という考え方を導入しました。全体の60%のリソースを技術的負債の解消に使い、残りの40%をイノベーションに充てるというものです 。この数値自体に特別な意味があったわけではありませんが、コードの問題に足を引っ張られないための現実的な基準でした。
大切なのは、この比率をずっと固定することではなく、チームの「摩擦の大きさ」を見て調整することです。リリースが遅くなり、複雑さが増しているなら、技術的負債への投資を増やすべきです。私たちは3年間このルールを守り続けたことで、現在はイノベーションへの比率を高めることができています。現状では、イノベーションへの支出を増やしているものの、技術的負債を解決する取り組みはゼロにはできていません。60:40でも20:80でも原則は同じです。「過去の負債に向き合うことが、未来を守る」ために必要なのです。
レガシーシステムを手放す判断
技術責任者（CTO）にとって最も難しい判断の一つは、システムの老朽化（限界）を見極めることです。すべてを作り直したくなる誘惑は常にありますが、私の経験から言うと、こうした決断は技術的なストレスからではなく、ビジネス戦略に基づいてなされるべきです。
かつてJimdoは大きな転換点を迎えました。HTMLやCSSの知識が必要なDIY型のWebサイトビルダーから、Webサイトをユーザーに提供するWeb 2.0の時代へと移行したのです。このビジネスモデルの変化によって、既存のシステムはスピードを上げるどころか、むしろ足かせになりました。そこで 、Jimdo 2.0を再構築する専任チームを立ち上げました。
この経験は、現在の私の技術変革の見方（評価方法）が体系化される出来事でした。再構築は単に技術的負債を解決するだけでなく、ビジネス上の問題を解決しなければならないことを学びました。今では、技術責任者からアプリケーションイノベーションへの多額の投資を求められたときには、常に次の3つのシンプルな質問を問いかけるようにしています：
それによって、どのように高速化が実現できるのか？
それによって、どのように複雑性が軽減できるのか？
それによって、どのように製品の成約率が上がるのか？
この3つに明確に答えられ、かつ会社の戦略と一致していれば、投資を承認し、四半期単位で取り組みます。重要なのは説明責任です。単に予算を求めるのではなく、その投資がどのようにビジネス価値を生むのかを示す必要があります。
集中できる日を設けて、実験規模を拡大する
イノベーションには、試行錯誤を妨げな い仕組みが必要です。Jimdoでは、週に1日「集中日」を設けています。エンジニアはこの日を、ツールの調査をしたり、既存のコードの改善を試したり、技術トレンドを学んだりするための時間に充てます。
私はエンジニア出身として、「学び続けなければ時代に取り残される」と考えています。AIの台頭により、この考えはかつてないほど真実味を帯びています。AIはゲームチェンジャーとなり、エンジニアのコーディングを大幅に高速化するのに役立ちますが、十分に活かすには適切なガードレールが必要です。当社では、スタッフが新しいツールを調査し、業務の効率化を図るためのインセンティブを与えており、その投資はすでに実を結んでいます。
また、社内のコミュニケーションツールを使って、これらの調査結果を共有しています。全員が同じ目標に向かって連携し、お互いの取り組みを見える化することで、自然と足並みをそろえようとする良い緊張感が生まれます。
サンクコストの罠：2年間の失敗から学んだこと
アプリケーション革新の取り組みがすべて成功するわけではありません。私自身も、2年以上続いた非常に苦しいプロジェクトの失敗を経験しています。
問題は、市場の変化や会社の戦略転換によって、そのプロジェクトがビジネスに合わなくなってしまったこ とでした。結果として、中途半端な状態のまま維持するのに大きな負担がかかりました。この経験から学んだ重要な教訓は、「必ず作業をマイルストーンに分割して正しい方向に向かっていることを確認する」ということです。
車づくりで例えてみると、いきなり車を完成させるのではなく、まずスケートボード、次に自転車、そして車へと段階的に作っていきます。小さく、完結した形で価値を届けることで、戦略や市場の変化にも早い段階で柔軟に対応することができ、2年間の労力を無駄にすることなく、無駄な投資を防げます。俊敏性とは、単にスピードのことだけでなく、方向性が正しくないときに立ち止まれる力でもあります。
アプリのイノベーションは単なる計画ではなく考え方そのもの
これを正しく実現するための簡単な方法はありません。技術的負債の返済に必要なエンジニアリング能力を守るには、特に、新しい機能を投入し続けなければならないというプレッシャーがある場合、強いリーダーシップが必要です。
2026年版Cloudflareアプリイノベーションレポートが示すように、最も成功している企業は、長期的に大規模なアプリケーションイノベーションが必要であることを前提に計画を立てています。最新技術を一定で普遍的な資産として扱わず、絶え ず手入れが必要な、生命を持ったシステムとして考えています。
アプリケーションのイノベーションとは、改善に費やす時間を有効に活用することです。チームに学び続ける余裕を与え、ビジネス目標と整合した方向性を示し、技術的負債に向き合う規律を持つことで、単に製品を維持するだけでなく、競争力を生み出す原動力となるのです。
イノベーションを拡大する
真のアプリケーションのイノベーションとは、ゴールに到達することよりも、組織がデジタル資産を構築、保護、展開する方法を進化させることにあります。技術的な俊敏性を永続的なビジネスの強みに変えるには、厳格なセキュリティ基準を維持しながら、障壁を取り除く基盤が必要です。
Cloudflareの統合型アプリケーションセキュリティおよびパフォーマンスプラットフォームは、こうした進化を支えるために設計されています。多くの企業がレガシーシステムのモダナイズ、分散型アーキテクチャの最適化、AI活用への投資を進める中、Cloudflareは、イノベーションとレジリエンスのバランスを取る基盤を提供します。世界最高峰のパフォーマンス、深い可観測性、開発者指向のツールを単一のプログラム可能なレイヤーに統合することで、Cloudflareは複数ツールの運用負荷やコスト増加を抑えながら、エンジニアリングの時間を確保し 、イノベーションを加速できるよう支援します。
この記事は、技術関連の意思決定者に影響を及ぼす最新のトレンドとトピックについてお伝えするシリーズの一環です。
このトピックを深く掘りさげてみましょう。
企業がアプリスタックとプロセスをモダナイズする方法については、2026年版Cloudflareアプリイノベーションレポートをご覧ください。
著者
Felipe Furlan氏（@ffurlansilva）
Jimdo CTO
記事の要点
この記事では、以下のことがわかるようになります。
日々の保守業務とイノベーションの両立をどう図るか
いつ、再構築・リファクタリングを行い、技術的負債削減への投資を行うか
モダナイゼーション施策を評価するための基準