継続的Webサービス改善ガイド

第1章 なぜ「継続的Webサービス改善」が必要なのか~変化に対応し,10年後も生き残るWebサービスのために

この記事を読むのに必要な時間:およそ 5 分

ファイナンス用語で考える

以上のことを,別の観点からも検討してみましょう。

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章では,技術的な話から少し目先を変えて,マネージャという立場でどのように上記した問題に対応し,改善を行っていけるかについて述べます。

著者プロフィール

栗林健太郎(くりばやしけんたろう)

(株)paperboy&co.

URL:http://kentarok.org/
Twitter:@kentaro
Github:kentaro