開発の視点から考える運用ファースト

いまや開発（development）と運用（operation）は切り離せない存在です。「DevOps」というワードとともに開発、運用のプロセスをいかに効率化するか、ということが多くの場で議論されてきました。開発プロセスをよりよく設計し、運用サイクルをより多く回すことは結果的に企業の競争力を高めることに結びつきます。さらに最近では開発、運用にビジネスの観点を加えた「BizDevOps」という動きも出てきています。

ビジネスプロセスやマーケティングプロセス、開発プロセスのそれぞれが成熟し始めている今、これらをより結びつけるのが、当社がスローガンとして掲げている「運用ファースト」だと私は感じています。本コラムではいち開発者である私が開発者視点で「運用ファースト」がなぜ大事なのかをお伝えしたいと思います。

開発の視点から言えば、運用において重要なのは技術的負債をできる限り残さないことです。

技術的負債とは主にWebサイトのソースコードが最適化されておらず、簡単な修正をしようにも、あちこちに手を入れる必要があったり、意図しないところに影響が及んでしまうような状態を指します。技術的負債は多くの場合、スケジュールを優先したことにより、理想的ではないコードが含まれてしまい、それが改善されない状態が積み重なることによって生まれるものと捉えられています。では最初から完璧なコードを書いておけば負債は生まれないのかというと、実はそうとも言い切れません。

プロジェクト開始時に開発者があえて分かりにくいコードを書いたり古いライブラリを使用する、ということはほとんどありませんが、開発当初はスタンダードであり最適だと考えていたライブラリやフレームワークでも、人や業界の変化、テクノロジーの進歩などさまざまな要因によって最適でなくなることがあります。結果として開発当初の最適と、現在の最適とのギャップが技術的負債となることもありえます。

先に述べた通り、負債が積み重なったWebサイトでは、小さな更新であっても大きなコストが必要になり、運用の足をひっぱります。逆に言えば技術的負債のないWebサイトは更新がしやすく、企画から公開までを素早く行えるため、運用のサイクルをより素早く、より多く回すことができるようになります。そのためにも、日々の運用の中で負債になりそうな部分を潰しておくことが大切です。もちろん技術的負債を作らないことが結果として利益につながる、ということは言うまでもありません。

「運用を第一に考える」ということは「最初から運用を考慮して設計すること」だけではありません。もちろん修正、変更しやすい設計をすることは望ましいことですが、思いもよらない変更が必要になるケースも多々発生しますし、世の中がアップデートされれば、ユーザーがWebサイトに期待する価値や体験も当然変わってきます。それに応えるためには、運用フェーズであろうと、部分的に設計をし直すということはあってしかるべきだと考えています。

私が考える「運用ファースト」とは「運用しやすい状態を作ること」です。では運用しやすい状態とは何でしょうか。2つ例を挙げてみます。

当然のことながら運用を長く続けるほど、コンテンツは増え、Webサイトはどんどん大きくなっていきます。コンテンツが増えるということは、修正の際に考慮すべき対象が増えるということです。

もちろん一部の変更がサイトに与える影響範囲を小さく保てていれば、それで十分かもしれませんが、求められる要件はさまざまで時には複雑になることもあります。そのため、意図しない影響が出ないように注意するだけではなく、万が一影響が出たときにそのまま公開してしまわないよう、すぐに気が付ける仕組みを作ることが重要になってきます。

DevOpsにおいては、継続的インテグレーション（Continuous Integration、CI）という名前で多くの手法、知見が紹介されています。

いくつかのCMSではHTMLコードを含めて入力できるものもありますが、これは「データ」と「コード」をまとめて一つのものとして扱っている状態です。しかし、CMSは本来コンテンツを管理するためのものであり、コードを含めてコンテンツとして扱うことは目的から逸れてしまいます。

例えば、JamstackではヘッドレスCMSなどを用いてデータを入力、保管し、HTMLなどのコードは別の場所で管理する、というように使い分けをしています。データとコードの依存関係を断ち切り、分けて管理しておくことで柔軟な変更を可能にします。別のCMSに乗り換えたい場合は、コードはそのままでデータだけを移行することができますし、Webサイトの見た目だけをリニューアルをしたい場合は、データはそのままにコードを変更するだけで済みます。

ちなみに「依存関係を減らす」ということは、プログラミングにおいてもベストプラクティスとされていますが、Jamstackは開発プロセスにおけるベストプラクティスをより上流工程にも適用したよい事例であると思います。

先に挙げた仕組みづくりは、いずれも容易なものではありません。運用を考慮した開発環境を用意したり、自動テストを作るだけでも相応のコストがかかります。しかし、このような仕組みがあるのとないのとでは、開発組織のパフォーマンスに圧倒的な差が生まれるということが「LeanとDevOpsの科学」という書籍で紹介されています。

同書では、開発組織のパフォーマンスは「デリバリのリードタイム」「デプロイの頻度」「サービス復旧の所要時間」「変更失敗率」の4つの指標をもって計測できると言及しており、さらに開発組織のパフォーマンスは企業の業績と結びついている、ということを科学的に証明しています。

先に挙げた4つの指標は言い換えれば「スピード」と「品質」の2つに大別できます。当社はこれまで「Web標準準拠」「アクセシビリティ対応」「マルチスクリーン・デザイン」「表示パフォーマンス」の4つを当たり前の「品質」としてご提供してきました。しかし今後は品質だけでなく「スピード」の部分についても焦点をあてていかなければなりません。運用ファーストであるために「ファスト（fast）」な運用ができる仕組みづくりに取り組んでいきたいと思います。