なぜ「継続的webサービス改善」が必要なのか
何年続くwebサービスを構築し、ユーザに価値を提供しつづけるため
開発を行うべきかどうかを判断する尺度=価値/コスト→
得られる価値を増大させる
費されるコストを減少させる
価値を増大させつつ、コストを減少させる
価値→
将来価値
割引現在価値
割引率
コスト→
複雑性の増大→テスト、リファクタリング、コードレビュー
環境の変化→データ量の増大、技術的環境
改善も投資であることを「意識」する
開発環境の改善
技術的負債と開発環境の改善
- その場凌ぎなコード
- TODO:あとで直す
- とりあえず動けばいいコード
- コピペ
- 脆弱性が公開されているライブラリを使ったコード
その爆発
- どう見ても必要ない処理のように見えるが、消してよいのか分からない
- どう見ても非効率なやりかたをしているが、直してよいのか分からない
- 担当者が変わったときにその都度、何のために必要だったのかを聞かなければならない
その改善
- CIの導入
- コードレビュー
- バージョン管理
- 開発環境の仮想化
- レガシーコード(テストのないコード)の継続的な改善
バージョンアップの必要性
- セキュリティ上、保証されない
- パフォーマンスや安定性が高い
- 新機能により生産性が上がる
パフォーマンスの改善
誰にとっての改善か
- コンテンツを発信する側
- コンテンツを閲覧する側
ApacheやらFlutentdやらでログを収集し、集約する(GrowthForecastによる可視化)
スプレッドシートに落としこんでもよい
インフラ構成管理の改善
インフラの技術的負債
- 集中管理されていない設定情報によるサーバごとでの微妙な仕様差
- すばやい変更手段を持たないことによるサーバ全台展開の手間
- うつりかわるハードウェア性能とそれを扱う運用の柔軟さがないことによるスペックアップの困難さ
- ルーチン化された作業が省力化されていないことによる運用のコスト
- 無秩序な監視システム運用によるサービスヘルスチェック品質の劣化
PuppetとかCobblerとかを使う
ビジネス視点の改善
サービス継続に収益は不可欠
KPI
リリース後の改善
コミュニケーションの量を増やす
朝会
定例会議
キープアップ会議
プロジェクトの相談会議
ただし、やるなら少人数かつ短時間でやるべき
GitHubのIssueを利用する
ふりかえり
