特集のはじめに
本特集は「継続的Webサービス改善」と題し、Webサービスの継続的な改善について、そもそもそれがなぜ必要なのか、どのような改善が必要なのか、それをどう実践していくのかという3点について、特集執筆陣が勤務するpaperboy&co.（以下、ペパボ）での実際の取り組みを題材に解説していきます。
Webサービスを改善するには、技術的な取り組みはもちろん、開発投資とそのリターンという経営的な観点、チームビルディングなどの開発プロセス、ビジネスメトリクスへの注視など、考慮するべきことがたくさんあります。多様な職種からなる執筆陣による本特集は、きっと読者のみなさんのお役に立てることと確信します。
10年という節目
ペパボは今年で設立10周年を迎えました。10年前のことを思い出してみましょう。当時、インターネットはブログブームにわき、いろいろなブログサービスがローンチされました。少しあとのWeb 2.0ブームを経て、ブログに限らない多種多様なコンシューマ向けWebサービスが当たり前になる少し前、といった時代です。
当時あったWebサービスのうち、今も生き残っているものもあれば、すでに消えてしまったものもたくさんあります。ペパボで言えば、レンタルサーバを提供するロリポップ！や、ドメイン取得サービスのムームードメインといったWebサービスが、この10年間を通してユーザに価値を提供し続けてきました。一方で、いったんローンチしたものの、そのあとの事情の変化により閉鎖を余儀なくされたものもあります。
この10年の間に、インターネットを含む世の中はもちろん、技術的環境も大きく変わりました。いったい何が、成功したサービスと失敗したサービスの運命を分けたのでしょうか。
継続的改善の必要性
10年続いたWebサービスは、それぞれのWebサービスとしての魅力や、ローンチされたときの運が向いていたといった理由によって、長きにわたる運営が可能であった面はあるでしょう。それはそれで非常に重要なことです。しかし、いずれのWebサービスも、ローンチ時からそのままの状態におかれているということはあり得ないでしょう。その間に継続的な改善を行ってきたからこそ、現在があるのは確かです。
すでに10年を迎えたWebサービスも、これから10年を迎えるWebサービスも、今後も継続して運営し、ユーザに価値を提供し続けることを目指すからには、継続的な改善を続けていく必要があります。
Webサービス運用のファイナンス
そもそも、なぜWebサービスを継続的に改善する必要があるのでしょうか。Webサービス開発にかかるコストと、それがもたらすだろう価値について検討することを通して、考えていきましょう。
開発コストと価値
Webサービス開発にかかるコスト・価値を大別すると、「初期開発コスト・価値」と「運用コスト・価値」とを考えることができます。
初期開発コストとは、Webサービスの企画立案・設計・実装・ローンチといった、新サービスの計画から、実際にユーザのもとへ届く初めの一歩までにかかる、一連のプロセスにおけるコストです。
一方で運用コストとは、いったんローンチされたWebサービスが、変化していく社会情勢において継続的にユーザに価値を提供し続け、さらにはそのもたらす価値を増大するために行う施策にかかるコストです。
開発コストと価値の方程式
さて、上記のように分解したそれぞれのコストと、それがもたらすだろう価値について、『コード・シンプリシティ』（注1）に登場する簡単な方程式を導きの糸に、考えてみましょう。
コストと価値の定義
まず、コストとそれがもたらすだろう価値とを、初期開発と運用における上記の分解に基づいて示すと、次のような簡単な式として表せます。
- コスト＝初期開発コスト＋運用コスト
- 価値＝現在の価値＋将来の価値
開発判断の尺度
このとき、コストとそれがもたらすだろう価値を勘案し、開発を行うべきかどうかを判断する尺度（desirability）を次のように表現します。
- 開発を行うべきかどうかを判断する尺度
- ＝価値／コスト
- ＝（ 現在の価値＋将来の価値）／（初期開発コスト＋運用コスト）
開発を行うべきかどうかを判断する尺度は、
- 開発がもたらすだろう価値に比例する
- 開発にかかるコストに反比例する
ものとして、この方程式により表現されます。これは読者のみなさんの経験上からも、納得のいくものではないでしょうか。種々の案件について、そこから得られるだろう価値が高ければ高いほど開発を進める判断を行いやすい一方で、それにかかるコストを勘案して最終的な判断を下すことを、開発の現場において日々行っているはずです。
方程式を展開する
さて、ここでWebサービスのライフサイクルを通して流れる時間について、もう少し深く考えてみましょう。この時間には、初期開発にかかる時間と、Webサービスを運用していく時間とが考えられます。
長期に運用されるサービスに当てはめる
世の中にはいろいろなWebサービスがあります。一時的な用途のために開発されるものもあれば、長期的な運営を目指して開発されるものもあります。ここで、その時間がある程度以上の長さ（たとえば冒頭で述べた10年のような）であることを前提にすると、一般には初期開発コスト・価値は、長く続くそのあとの運用フェーズでのそれと比較すると、無視し得るほど小さいものとなります。
すなわち、先ほどの方程式は次のように簡略化できます。
- 開発を行うべきかどうかを判断する尺度
- ＝将来の価値／運用コスト
この式の意味するところとはつまり、ある程度の長期間を前提とするWebサービスの場合、初期開発コスト・価値よりもむしろ、運用フェーズにおけるコスト・価値こそが、Webサービスのライフサイクル全体を通して見た場合の開発判断を左右する要素になるということです。
長期に運用されるサービスの開発判断
開発を行うべきかどうかを判断する尺度を増大させる方法として、次の3つが論理的に導かれます。
- a．得られる価値を増大させる
- b．費されるコストを減少させる
- c．価値を増大させつつ、コストを減少させる
このうちのcを実現できるとすればそれに越したことはないでしょう。とはいえ、両方をいっぺんに実現することは困難ですので、本特集では主にbに焦点を合わせ、いかに運用のコストを改善していくか、どのように効率良くWebサービスの開発を行っていくかを考えていきます。
ちなみに、aのいかに価値を増大させるかについては、WEB+DB PRESS Vol.73の特集1「たのしい開発実況中継」がおおいに参考になるでしょう。ぜひお読みください。
ファイナンス用語で考える
以上のことを、別の観点からも検討してみましょう。
1年後に100万円を得られるとして、少し減ってもよいので今すぐに得たいという場合、あなたはいくらまでなら減ってもよいと考えますか？
現時点でお金に困っておらず、減るぐらいなら100万円を確実に得られる1年後まで待つという人もいれば、少しぐらい減ってもよいのでいますぐにでもいくらかのお金がほしいという人もいるでしょう。
将来価値と割引率
1年後に得られる100万円を現時点で得る場合に、95万円なら納得できるという場合、
- 1年後の100万円を「将来価値」
- 現時点での95万円を「割引現在価値」
- 差額の5万円、つまり100万円に対する5％を「割引率」
と言います。将来における貨幣価値が一定であることを前提とすると、この割引率の算出は、将来がどれだけ不確実であるかに依存します。わかりやすく極端に言うと、今食べるものに困っている人は、飢えて死んでいるかもしれない1年後に100万円もらうことよりも、今空腹を満たすための1万円をすら選ぶことがあり得る、ということです。
Webサービス運用のファイナンス
この話をWebサービスに当てはめてみましょう。我々は、Webサービスを営利事業として運営しているからには、利潤を得る必要があります。そのためにいろいろと頭を使って、できるだけ儲かるために種々の施策を日々実施しているわけです。
短期的な視野は価値を減損する
さてここで重要なのは、その「利潤」をいつ計上するかという問題です。経営状態が悪化して資金繰りがショート気味であれば、とにかく今すぐにお金を捻出しなければならないでしょう。その場合、先の用語で言えば「割引率」をふだんより高く設定してでも、利潤を得る必要があります。そこまで極端でなくとも、短期的な業績を上げることを求められている場合、意思決定プロセスが似たような状況に置かれることは明白です。
Webサービスの開発判断における重要な要因は、先述したとおり、それがもたらし得る価値と、それにかかるコストです。一般にWebサービスの開発コストは、放っておくと常に増大していきます。サービスを構成するコードの量は増え、そのシステムは複雑化し、開発人員の増加に伴って人件費やコミュニケーション面でのコストが増加していくからです。
そのような状況下において、コストの増大を食い止めるための施策を打たなければ、いくらがんばって新規性の高いアイデア＝高い価値をユーザにもたらすことができたとしても、コストがそれを食いつぶしてしまうでしょう。
将来価値を毀損しないために
なぜそうなってしまうのでしょうか。それは将来の不確実性についての見当が歪んでいるからです。先ほど例に挙げた食うや食わずの人と同じで、現状に対する判断が将来の不確実性の前に圧倒されて、本来ならば得られただろう将来価値を毀損（きそん）してしまっているわけです。
長く運営することを前提とするWebサービスの場合、これはたいへんな問題です。
開発コストを縮減する
このような事態を防ぐにはどうしたらよいのでしょうか。次の2つがあり得ます。
- a．将来の不確実性をできるだけ縮減する
- b．将来価値を毀損しないために、開発コストを継続的に縮減する
aについては、昨今話題になっている「リーンスタートアップ」が解決のための参考になるでしょう。WEB+DB PRESS Vol.68の特別企画「［速習］リーンスタートアップ」をぜひお読みください。リーンスタートアップの話題は多岐にわたりますが、その本質は、短いタイムスパンでフィードバックサイクルを回すことにより、aの問題、つまり将来が不確実であるという問題の解決をはかることです。
本特集ではbの解決について具体的に取り扱います。つまり、割引率を適正な状態に保ち、その認識に基づいて改善への投資を行い、開発コストを縮減することで、将来価値の毀損をできるだけ防ぐための手立てを探っていこうという試みを紹介します。
なぜWebサービスの開発コストは増大し続けるのか
先に「一般にWebサービスの開発コストは、放っておくと常に増大していきます」と述べました。読者の多くにも納得いただける経験則であると思います。では、なぜそのようなことが起こるのでしょうか。以降では、
という2つの軸に沿って、それぞれについてどのように対処していくべきかの総論を述べます。
「複雑性の増大」への対応
コードの複雑性
Webサービスの開発当初は小規模だったコードベースが、ローンチ後のたびかさなる機能開発を経て、巨大なものに成長していくのは自然なことです。Webサービスの主要な成り立ちがソースコードによるものであるからには、まさにそのことによってユーザに提供する価値を増大し続けることができるのですから。
そのようにして成長したソースコードは、一方で、開発者に対しては「複雑性の増大」として重くのしかかってくることになります。新しい機能を追加しようにも、どこを改修するべきかを把握するのに時間がかかる、改修するべき個所や改修の影響範囲が大き過ぎるといった問題が現れてきます。
コードの複雑性への対応
そこで、ユーザへの価値提供を維持・増大させつつ、開発コストの削減をも実現するための具体的な手法として、たとえば、
といった種々のプラクティスが提唱・実践されているわけです。このうち、テストやリファクタリングについては第2章で詳述します。
システムの複雑性
機能開発の進展に伴って増大する複雑性は、コードのみには限りません。ユーザに利便を提供したり再訪率を高めたりするためにメールを送りたい、アクティビティをリアルタイムに通知するような機能を追加したいといった要求に応えていくと、それに伴って専用のサーバを設置したり、新たな技術を導入したりと、システム構成が複雑になっていきます。
また、サービスの成長とともに、負荷をさばくためにサーバ数を増やしたり、一部の処理を非同期化してWebサーバとは別のサーバで処理したりするなど、ハードウェア的にもシステム構成が複雑化します。時間が経つにつれ、システム複雑化の要因となる新機能の追加、ハードウェアの劣化や故障によるリプレース、新しいハードウェアの導入など、複雑化の度合いは増す一方です。
システムの複雑性への対応
何も対処しないでいると、その複雑性が徐々に足枷となって、開発コストの増大や、ひどくするとサービス障害につながるなどの問題を引き起こします。
第4章ではインフラの観点から、この問題への対応策について具体的な取り組みをもとに解説します。
プロセスの複雑性
Webサービスが成長し、提供し得る価値をさらに増大させていくには、エンジニアやデザイナなどの開発者に限らず、ディレクター、マーケター、カスタマサポート、セールスといったより広範なヒューマンリソースが必要になってきます。現実のサービス運営においては、たとえばさらに総務や法務といったバックオフィスとも連携しますし、必要な人を集めるためには人事と協働することも必要です。
プロセスの複雑性への対応
そのような多様な人々による協働がWebサービスの成長を支えるのは間違いないことである一方で、関わる人数が多くなればなるほど、それらの人々の間でのコミュニケーションコストの増大や、リリースプロセスの煩雑化、評価制度設計の難しさなど、問題も増えてきます。
第5章では、技術的な話から少し目先を変えて、マネージャという立場でどのように上記した問題に対応し、改善を行っていけるかについて述べます。
「環境の変化」への対応
データ量の増大
開発コストの変化は、複雑性の増大のみによって決定されるわけではありません。時間が経過し、Webサービスが成長するのに伴い、アクセスしてくるユーザはどんどん増え、扱うべきデータ量は加速度的に膨れ上がります。アクセスログやデータベースに格納するユーザデータの増大がその典型です。
そのこと自体は、サービスの成長を直接的に示すものですから歓迎すべきことです。しかし、それが開発コストに響いてくるような事態をもたらすことは避けなければなりません。
データ量の増大への対応
どれだけ多くのユーザが殺到しても、どれだけ多くのデータがデータベースに保存されてもさばけるように、システムを保つ必要があります。もしそうでなければ、せっかくの機会に恵まれたとしてもユーザを逃がすことになり、そもそも価値を提供できなくなってしまうでしょう。
第3章では、いかにしてパフォーマンスを改善するか、また、継続的に施策を打っていくためにはどうしたらよいかについて解説します。
技術的環境の変化
ローンチ当初はピカピカの最新鋭だった技術も、時を経るに従ってコモディティ化したり、劣化したり、あるいは、もっと優れた技術が登場してお払い箱になってしまったりということは、変化の激しいWebサービス業界においてはよくあることです。
OSSの運用コスト
高度にOSS（Open Source Software）を利用しプロダクトを開発することの多いこの業界では、OSSとの付き合い方もよく考える必要があります。たしかにOSSのライブラリやフレームワークは、製品の購入代金という意味においては「無料」ですが、ここでも先の分類に従って、運用におけるコストを考慮する必要があります。
たとえばRubyは、「2013年6月より先は、1.8.7はあらゆるサポート対象外」とされています。そのときまでのいつの時点かで、コストをかけてバージョンアップをしなければなりません。ほかの言語やフレームワーク、ミドルウェアなどでも、期間の長短こそあれ同様でしょう。
これは考えてみれば当然のことです。OSSは「無料」で利用できるとはいえ、その開発やサポートにはコストがかかっているわけです。我々がその恩恵を享受するその時点では、我々にとってはコストがかからないとはいえ、時間が経つにつれ、バージョンアップや新しいフレームワークやライブラリへの置き換えコストを払うことは当然のことでしょう。もちろん、保守やサポートに対してディストリビュータにコストを払うという方法も可能ではあります。
技術的環境の変化への対応
たとえばRailsを中心としたエコシステムの恩恵を受けながら開発をしていると、ライブラリの流行り廃りが激しく、また、常にRailsのバージョンアップに追従していかないと、新しく登場する便利なライブラリを使うことができません。そのため、それを使えさえすればすぐに済む開発を、自分たちのコストでやらなければならないということが往々にしてあります[2]。
このような技術的環境の変化に伴う開発コストの増大可能性に対応するために、ふたたび第2章がお役に立てることでしょう。
本章のまとめ
改善も投資であることを意識する
これから本特集が具体的に紹介していく改善も、機能開発などと同様に、それ自体が組織のリソースを使って行われるからには、投資の一貫であることを強く意識する必要があります。ただやみくもに、なんとなく駄目そうだから、改善が必要そうだからなどといった理由でコストをかけ、また、その結果としてさしたる成果を上げられないということは、許されることではないでしょう。
まず、本章で述べたとおり、サービス改善をなぜ行わなければならないのかについて、しっかりとした認識を持つことが必要です。開発者であるか否かを問わず、そのような認識に基づいて、効率良く成果を挙げるために力を尽くすべきでしょう。そして、期限を決めて取り組み、その成果について論理的、具体的に評価を行いましょう。
「複雑性の増大」と「環境の変化」に対応する
複雑性の増大と環境の変化は、Webサービスにとっては、いわば自然の摂理のようなものです。一定以上の規模と、長い将来にわたっての成長を目指すWebサービスは、どのようなものであってもその法則から逃れることはできません。
そのような中で我々ができるのは、その現実を認め、よく対処し、あるときには逆にうまく活かしてチャンスとし、サービスのより良い成長を促進していくことです。複雑性の増大とは、その良い面を見れば、コードベースやシステム、組織の拡大により、やれることの幅がどんどん広がっていくということです。環境の変化にうまく適応できれば、より良いサービスを継続的に提供し続けられるでしょう。
次の10年のための改善
限られた時間の中で価値を提供することを目的としたWebサービスならともかく、できるだけ長い間、ユーザに価値を提供し、そのことで利潤を生み続けることを目的とするサービスを提供するためには、継続的な改善を行うことが必要です。
すでに10年目を迎えたサービスにとっても、今まさにローンチされんとするサービスにとっても、将来は同じように不確実です。だからといって不確実性に過度に惑わされ、結果として将来価値を毀損することなく、自サービスの将来を、ひいてはユーザの将来、インターネットの将来を良くするために、一歩ずつ確実に歩んでいきましょう。
次の10年を我々の手でより良いものにするためにも、Webサービスの改善に自信を持って取り組んでいこうではありませんか。
本特集の構成
以降に続く本特集の各章について、ここで簡単に紹介しておきます。
第2章「開発環境の改善」では、「技術的負債」の返済という観点から、開発環境の改善や仕様化テストの導入などを通して、コストを縮減し、より良いWebサービスを提供するための具体的な方法を紹介します（2/18公開）。
第3章「パフォーマンスの改善」では、Webサービスのパフォーマンスを視覚化し、改善への効果的なアプローチを採ることで、パフォーマンス面においてユーザへのより良い価値提供を継続するための方法を紹介します（2/19公開）。
第4章「インフラ構成管理の改善」では、ユーザへの継続的な価値提供を支えるインフラ面からのサービス改善について、これまでの歴史的経緯をたどりつつ、実際に取り組んできた内容を具体的に紹介します（2/20公開）。
第5章「ビジネス視点の改善」では、Webサービスを改善するにあたって、ビジネス的・マネージャ的な観点から、より良い施策の実行やチームビルディングが欠かせないことを、具体例とともに紹介します（2/21公開）。
