しるろぐ

いろいろ書きます。

#cross2013 で継続的サービス改善について話してきました

勉強会

エンジニアサポートCROSS 2013の「継続的サービス改善のゲンバのハナシ」というパネルディスカッションに参加してきました。

実はこういうイベントで話すのは初めてで、すごい緊張してしまい、質問に答えるだけでいっぱいいっぱいだったのですが、何かひとつでも参考になる話ができていれば嬉しいです。
セッションオーナーの@tagomorisさん、一緒に登壇した@kentaroさん、@oranieさん、@tokorotenさん、ご来場の皆様、ありがとうございました。

話した内容

質問は結構範囲が広かったので、簡単にまとめづらいですが、一言でいうと「ユーザをちゃんと見る」ということを中心に話していました。サービス改善に限らず、集団でプロジェクトを動かすと、政治的なしがらみとかいろいろ面倒なことがあると思います。そんな中でプロジェクトの方向を定める一番の指標はユーザです。ユーザに価値を提供できるか、ユーザの問題を解決できるか、ということを考えれば、自ずと改善マインドが育って、継続的なサービス改善につながるんじゃないかなと思います。

サービス改善と聞いて何を思い浮かべるか

そんなわけで、ぼくがサービス改善と聞いて最初にやるのは、ユーザ目線での不満の洗い出しと解消です。自分たちのサービスは自分たちが一番使っていると自慢できるぐらい使い倒して、元々そのサービスが提供したかった価値がきちんと提供できているかというのを確かめます。その上で、企画者が考えるユーザ体験と、実際のユーザ体験との差を埋めるようにサービスを改善していきます。もちろん、ユーザ体験が大幅に違う場合は企画自体の見直しも視野に入れます。

また、これは個人的な好みなのですが、とにかく早いサービスが好きなので、表示速度の改善は常にやります。どこが遅いのか調べていると、サービス全体を触ることになるので、不満の洗い出しにもちょうど良いです。

サービス状況の把握

ユーザを第一に考えるにはユーザの声を拾う必要があります。自分が不満に思うところを解消、というのはある程度は良いのですが、一定の改善ラインを超えるとあまり役に立たなくなります。

ぼくがやったことをあげると、ページ速度の改善については、それ専用の社内サービスみたいなものを立ち上げて、だれでも、すべてのサービスの表示速度・SQLの実行速度を確認できるようにしました。これは週に一度レポートメールを送るようにしています。「だれでも」というのが重要で、ページ速度の改善は理解されにくく、「そんなことしてる暇があったら新しい機能を」みたいな返答をされたときに突きつけるためです。二月ぐらいデータ取ると、このページが徐々に遅くなってるねーとか、この新しく入ったクエリ遅いねーとかいろいろな発見があって面白いです。

ユーザの声については、ソーシャルメディアや某巨大掲示板の発言をIRCに流すようにしました。昔はユーザの声を拾うにはユーザ座談会やアンケート、お問い合わせぐらいしかありませんでしたが、最近は便利ですね。リアルタイムに情報が流れてくるので、不具合の発見につながったり、ユーザからの良い評価でモチベーションがあがったりして大変よろしい。弊社はIRCがあるのでそれに流していますが、そういったコミュニケーションツールがない場合は、それ用の社内サービス作ったり、メールで社内orプロジェクト全員に送ると良いんじゃないかなと思います。こちらも、だれでも見れるというのが重要です。

エンジニアと営業企画との対立


まーこの通りなんですが、立場ごとに向いている方向が違うと、意見が対立してしまったりしますが、ユーザを中心に考えれば対立なんてしないんじゃないかなーという考えです。もちろん、ユーザのためになるから一週間かかる作業を今日中に作ってよ！みたいなことを言われたら突っぱねますが、そういった時間的、物理的な問題じゃない限り、「なぜこうしたいのか」「それはユーザにどんな価値を与えるか」ということをしっかり話せば、案外スムーズに話がまとまるもんです。
弊社の場合は、「残業ありきのスケジュールを切らない」というモットーがあって、時間的な問題はないです。技術的な問題については、コストに対して効果はどうか、ということが主な判断基準になります。
「そんなこと言ってもうちの部長は！」みたいな場合は、上に書いたとおり、ユーザの声を武器にしましょう。

ユーザからの無茶なお問い合わせ

とは言っても、ユーザの言うことを全部聞けってことではなくて、そこはサービスの目的であったり、全ユーザのことを考えて、判断をする必要があります。
@tokorotenさんがフォードの話を例に出していましたがその通りで、ユーザは自分で自分の要望を分かっていないことが多々あります。そんなときに、力を発揮するのがユーザビリティ調査であったり、データ分析です。

改善案の提案と評価

改善案があるけどそれを許してくれない場合はどうしたら良いかというと、ひたすら啓蒙活動をしつつ、裏で作っちゃう、というのが一番楽です。実際に動くものを作れるというのがエンジニアの強みなので、そこを最大限に生かしましょう。

ぼくの場合は、日報であったり社内ポータルにいろいろ書いたりしつつ、diffを差し出して、「こういう理由でこんな変更を入れたいです」と言っています。だた、セッション中に「理想郷だ」と言われた通り、弊社は結構エンジニア的には恵まれているほうで、自分の意見が通らないということがあまりなくて、ちょっとよく分からないです。

今のところ、そういうようなことはないですが、もし駄目だと言われたら、「何かあったら全部自分が責任追うので、せめてA/Bテストだけでも！」と頼み込んで結果が思わしくなかったら静かに会社を去る覚悟です。逆に言うと、改善する場合はそこまでの自信（とそれを裏付けるデータ）が必要なんじゃないかな。

という意見がありましたが、もちろん誰にも知らせず変更するのはダメ！絶対！

改善と失敗

というのはちょっと言い過ぎな感じはありますが、

失敗したところでやめてしまうから失敗になる。
成功するところまで続ければ、それは成功になる

という松下幸之助の名言がありますがそれと同じで、継続的にサービスを改善するということはそういうことです。PDCAサイクルを常に回すことで、改善し続けるというのが重要です。評価をどうするかという話については、いろいろあると思いますが、上に書いたとおり、ユーザの声であったり、アクセス解析や表示速度などのデータ分析です。

サービスの立ち上げと運用

ページ速度の分析サービスを作ったときに、ただ作るだけじゃ利用されないなと思って、レポートメールの送信日にあわせて「負荷分析ミーティング」というのを開催し始めました。毎週金曜に時間をとって、各プロジェクトから最低1名参加を義務づけた勉強会です。内容としてはレポートメールを見ながら、すべてのサービスについてどう対策を取るか話し合ったり、先週のアクションプランを実施してどう改善されたかというのを話し合う会です。
運用を考えた開発をしないと、ここで苦労することになるので、運用に優しい開発ができます。

まとめ

ということがうまく伝わったかは分かりませんが、聞いていただいた皆様ありがとうございました。
他の登壇者の方と比べると、言葉に詰まっていたりしてお聞き苦しいところがあったかもしれませんが、こんなことを言ってました。

togetterにセッション中の発言まとめを作りましたので参考にしてください。
CROSS2013 「継続的サービス改善のゲンバのハナシ」 #cross2013 #cross2013a

最後に、発表の機会をくださった@tagomorisさん、エンジニアサポートCROSS 2013 実行委員会の皆様、ありがとうございました。

おまけ