攻めるための自動化、汎用化のすゝめ

2015/12/16
ベトナム出張中に90,000ドンでミネラルウォーターを購入した白浜(@pandamachine715)です。
GREE Platform 部でアプリケーションの利用促進機能(ポータルサイトや集客施策等)を開発する仕事をしています。
このエントリはGREE Advent Calendar 2015 16日目の記事です。

今回のテーマは「グリーを支える技術」ということで、本稿では「こんなコード前も書いたな〜」とか「この作業前やったな〜」といったもやもやを解決するためのアプローチとして自動化、汎用化について書いてみたいと思います。

自動化の動機付け

自動化の具体的な手法については既に先人達が素晴らしい記事を残していただいているので、今回はそもそもなぜ自動化をするのかという点を掘り下げてみます。

1.人力を信用しない

　毎日A、B、Cという batch を動かすというタスクがあったとしてそれを人が一つ一つ動かしていたらまー忘れたりミスったり病気になったり...
「そんなこと言われずとも cron 設定するよ」ってそれはまあそうですよね。
ただこういった分かりやすい例であれば割と簡単なのですが、
例えば
その日に開催予定のイベントをカレンダーを見て確認したり、同僚に口頭で確認したりといった作業をしているとします。この確認工数自体が無駄ということもありますが、確認漏れや聞き違い等で情報が欠落してしまい、思わぬ障害を招く可能性もあります。
そうなる前に毎朝チャットにその日のイベントを吐き出す bot(↓) がいてくれるとちょっと世界は良くなると思うのです。
毎朝その日のイベントを通知してくれるbot

毎朝その日のイベントを通知してくれる「Ohdan-kun」、hubot を用いて chatwork にメッセージを配信しています。

2.時短

　「とはいえ費用対効果でしょ？」はい、おっしゃる通りでございます。
「趣味だから」で片付けるというのも一つの手ではあるのですが、やはり作る以上は効果ないと寂しいですよね、趣味の時間だってもったいないですし。
でもそういう話は苦手と感じる方向けに、ちょっとずるいですが簡単な方法を。
それは「昨日と今日同じことしたから以降毎日やると仮定する」ことです。
具体的な例で言うと
その日のイベントを確認する作業(5分)を昨日して、今日もしようとしている場合

またその作業をしている人の人数もわかると単純に掛け算になるので、10人くらいが同じことをしていたとすると
はい、毎月25時間の工数削減が実現しました(ドヤァ)。

3.すげー感

　これ結構大事です。ピタゴ◯スイッチ的なものを見てワクワクしてしまう人って一定数いるというか少なくとも私はそうだったのでやはり bot が自分の仕事を代わりにしてくれた時の「おおっ!」はなかなか良いものです。
自分だけではなく周囲も楽になるような自動化であれば
「おおっ!」「ktkr!」「これが未来か...」
くらいの反響は当然返ってくるので(過大)すげー感は倍々で増えていきます。
はい、褒められるのはよいことです。
逆に褒めると自動化してくれます私は、単純です。

合わせ技

実は1,2はどちらも人月換算が割と簡単なので例えば2の計算で2人日/月と出てちょっと少ないかなーと感じても、1で月2回ぐらいオペミスあるからその対応工数を+１人日くらい足して
-3人日/月(+αで障害数も減らせる！)
みたいな表現をすると賛同を得やすいかもですね。

ちょっとした補足

見落とされがちなのがエンジニア以外のタスクの自動化について。
現実的に見て自動化能力はエンジニアのほうが高くなりがちです、どうしてもコードを書くことになるので。
結構信じられないようなことを手作業でやってたり、その作業コスト鑑みてその作業自体やめてしまったり何てこともあるので、 bot が動いてるのを実際にみせるというのはかなり有効な手段の一つと思います。

汎用化のすゝめ

「汎用化」と聞いてなかなかイメージのわかない方もいらっしゃるかと思いますが、ザックリ言うとDRYの法則を実現するために共通機能を切り出して横展する手法をさしています。具体例を示すと分かりやすいと思いますのでやってみます。

例題

運営しているWebサイトに

「毎日ログインしてくれたユーザにはアイテムと交換できるチケットを付与する」

機能を実装したい。

step1:因数分解

まず例題の機能を分割してみます。
次にこれらの構成要素を抽象化して
くらいまで分解してあげます。
ここではあえて抽象的な言葉を選んだほうがのちの汎用性が高くなるのでオススメです。
意味を広く取りすぎても後で「もう少し絞るか」という調整は可能です。

step2:イメージ

前節の「UserのActionに対してIncentiveを付与する」を見ていると、なんとなくですが function 名みたいなものが見えてくると思います。

これでなんとなくこの関数をログイン時に呼び出せばよさそうだなとイメージできるようになります。

step3:具体化

実は上記のイメージまでできてしまえば後は皆様が普段やっていることをすればいいだけだったりします。

注意点としては汎用的な名前を用いるので名前衝突が発生しやすい事です。例えばグリーでは 'action' は ethna に予約されているため action => mission とする必要がありました(MissionAPIとして様々な施策に横展されています)。

step4:横展

上記で作成した「毎日ログインしてくれたユーザにアイテムと交換できるチケットを付与する」機能。一見すると何の変哲もない機能追加ですが、例えば次のような施策をうつ際に違いが出てきます。

「アプリをインストールしたユーザにコインを付与する」

２度目なので手順は省きますがこれも「UserのActionに対してIncentiveを付与する」機能です。つまりstep3で作った関数が利用できるのです！

以降もこの共通関数を利用し実装工数を抑えることができるようになります。

まとめ

今回ご紹介した自動化、汎用化に欠かせないのがそのカルチャーを組織に浸透させることです。
正直な話、普段コードを書いているとどうしても目の前のコストに目が行きがちになります、「3ヶ月前のコードが他人のもの」にみえるように「3ヶ月後の工数は他人事」にみえてしまうからです。
ですのでまずは身の回りのことから始めて、小さくてもメリットを示すのが近道かと思います。「おおっ！」と感じてくれる仲間が増えてくれば次第に大きな範囲での改善が可能になってくるはずです。
自動化を通じて世界がより良くなることを願って結びとさせていただきます。

次回はいわなちゃんさんによるVarnishのお話です、お楽しみに！