運用をいい感じにしてみんなで幸せに働きたい

この記事は「【その1】ドリコム Advent Calendar 2015 - Adventar」の１２日目の記事です。

１１日目はOhjiroさんの「情報優先度×光の意識で作るクエストバナー - Ohjiro」です。

*1

こんにちは。

餃子エンジニアの団長です。

社内ではネイティブアプリのサーバーサイドエンジニアをしてます。

１週間に１回くらいは餃子を食べないと体の調子がおかしくなります。

そんな私も新卒でドリコムに入社して３年半くらいが経過しました。

現在は某ネイティブアプリの開発・運用チームに所属しています。

このチームはスクラムの方法をとっていて、１スプリントを一週間としています。ストーリーという単位で業務を進めていきます。
スクラムに関して詳しくはぐぐってください＞＜

このアプリのリリース前の開発時から今日までこのチームにいるのですが、開発期間より運用期間が長くなってきたので、いいかんじに運用するための何か的な事例を紹介します。

A.「管理画面使いづらいよう…あとこういうデバッグ機能もほしいよう」
B.「改善したよん♪」

チーム内からはもちろん、カスタマーサポートの方からの改善要望などもあがってきます。
エンジニア内で積んでおいて、隙を見て対応することもあれば、管理画面改善やデバッグ機能追加のストーリーを立ててもらうこともあります。

作った機能は必ず要望をあげた人に確認してもらって、要望を満たせているか確認します。
まあこれはあたりまえですね。

A.「バナー作るの大変だよぉ…」
B.「自動バナー合成じゃ！」

事前に配信してある画像をどのように設定するかのデータを渡して、端末側で表示する機能。
最近できた機能の中でも最高にクールな機能だと思ってます。

定常的に開催されるイベントなどのバナーに対して使用しています。
イベントごとに設定データテンプレートがあり、設定もすぐ。
この機能ができてから間もないためまだあまり使用されていませんが、これでデザイナーさんの作業が少し減ると思います。

また、バナー合成以外にも定常的なイベントのお知らせはイベントのデータを使用して表示するということもしています。
あと新機能実装時には運用時にどうしたら事故りづらいか、どうしたら楽になるかも考えるようにしています。

A.「やばい、あの人今日休みじゃん」
B.「あ、それ自分もできるのでやります」

地味だけどこういうの大事ですよね。
自分ができるようになったら、それを他の人もできるようにしておくまでが一連だと思ってます。
万が一突然自分が休んでも大丈夫なようにしておくと自分もみんなも幸せになれます。

A.「意見出したいなぁ…でも言いづらいしいっか…」
B.「そんな君には振り返りKPTといきはかチケットだ！」

スプリントレビューのあとに今スプリントの振り返りをKPT形式で行っています。
業務面でもサービス面でもいろいろなKeep Problem Tryがあがってきます。
そこで出た意見をその場で次スプリントのストーリーにしたりする場合もあります。
スプリントレビュー後以外にも、イベントごとや機能実装ごと、職種ごとのKPTなどもあります。

あと「いきはかチケット」というものがあり、ここちょっとこうしたほうがいい、というユーザー視点からの意見を誰でも記載して、バージョンアップのタイミングなどでプロダクトオーナーが精査する
（いきはかは「粋なはからい」の略です。他のチームがやっていたものをマネしました）

意見あっても言えない…みたいな状況ができるだけ無いようにできるとハッピーですね。

A.「データ設定ミスが多いよぉ…気づけないよう…」
B.「よろしい、ならばチェッカー作成だ」

データが複雑化すると人間が読むものでない状態になるため、意図しないデータが設定されていてデータ作成者も気づかない、ということがまれにあります。
テスト時に気づくことがほとんどですが、ごくまれに本番にでてしまうことがあります。

ルール化できる部分はチェッカーを作ってまわすことで、事前にメールや管理画面でアラートを出すようにしています。

A.「sandboxではいっぱい更新したいよ！」
B.「jenkinsのこれつかってにゃ！」

ディレクターデザイナー誰でもjenkinsでぽちっとすることでsandbox環境のデータやリソース（画像・アニメーション・SEなど）の配信ができるようになっています。

あとみんなにgit使ってもらっています。本番で使用するデータ、リソースは全てgit管理です。

リソースはgitでcommit・push・mergeしてjenkins回せば端末で確認できるフローになっているため、エンジニアの手を介さずがしがし確認ができます。

データは本番反映時にはseedにしてあてていますが、sandbox環境ではseedを作る必要はないので、管理画面からエクセルをあげたらそいつが反映されるようになってます。
あとはこちらもjenkinsをぽちればアプリへのデータ配信がされて端末で確認ができるようになります。

リリース直後くらいはjenkinsも整備されておらず、毎度毎度手動でやっていた時期もあったような気がします。ｼﾝｼﾞﾗﾚﾅｲ!

A.「そろそろ冬のお祭りに行けるかどうか知りたいんだけど…」
B.「年末年始のスケジュールと体制決めるストーリー立ったよ！」

大型の休み前には、
・休み中にどういう施策があるか
・どういう作業が発生するか
・誰が出社するか、出社不要か
を決めます。

共有ドキュメントに日時別に施策、作業、担当、連絡先をまとめておきます。
これでその日に予定を入れて問題ないか、確認したいことは誰に聞けばいいかなどが分かります。

ちょうど先日、今年の年末年始体制まとめがされていました。

A.「ユーザーの気持ちを」
B.「みんなでわかろう！！！」

自分たちのサービスをユーザー視点から見るためのストーリーが定期的にたてられます。
・◯◯のクエストをクリアする
・新規キャラクターを◯体ゲットする
など。

ストーリー内には難易度が４種類あり、チームへのjoinタイミングやその人のユーザーレベルによって振り分けられます。

過去にあったストーリー（一部修正してあります）

POは、スタッフ80％以上が該当キャラを獲得していることを確認できる。これによりスタッフは、ユーザーの気持をある程度理解することができ、実装の過程で発生する様々な判断の精密性が増す。※対象キャラ：キャラA、キャラB、…キャラF　※赤組：４キャラ獲得 / 黄組：４キャラ獲得 / 青組：３キャラ獲得 / パープル組：２キャラ獲得

この80%を達成するとストーリーがDONEします。

赤がチーム歴が長い人、パープルが最近joinした人の組です。

定期的にユーザーレベルを確認され、上の組にあげられていきます。 

昔は達成率によってチーム歓迎会での会費が変動するという制度がありましたが今はないです…

みんなでおなじ視点を持つことは業務をスムーズにして、よりよい改善にもつながっていくためには必要だと思います。

最後に 

つらつらと書きましたが、運用とか改善ってこういう感じにちまちましたモノの積み重ねなのでうまく書けず…

新規開発が重視されたり人気が集まる傾向はよくあると思いますが、既存サービスを守っていくほうがえらいしすごいと個人的には思います。

運用を楽にしたり安定化させることは、ハッピーに仕事することにもいいサービスを提供することに繋がります。

エンジニアはチーム内の業務を大きく改善できる可能性が高いので引き続き意識していきたいです。

みんなでハッピーになりたいですね！！

この記事は「【その1】ドリコム Advent Calendar 2015 - Adventar」の１２日目の記事でした。

１３日目はyoumoriさんの「【CSS】レスポンシブWebページで装飾枠を適応させる方法と注意点 - Qiita」です！！

*1:いまのところ世の中でいちばんうまいとおもう餃子。おすすめの餃子屋さんあったら教えて下さい。