こちらはマイネットエンターテイメント Advent Calendar 15日目の記事です。
本日はmasao-fukaseの担当です。
ゲーム運営の現場で毎月のイベント準備を行う定常作業。
これをプランナーが代行するためにマニュアルをつくったよ、というお話です。
それプランナーがやります
ことの発端はプロジェクトのディレクターからの一言でした。
「エンジニアの工数を削減するので、エンジニアの作業をプランナーに教えてください！」
実際にこんな言葉だったかは覚えていないですが、そんな意味の言葉でした。
詳しく聴くと
- エンジニアを生産的な作業にもっと割り振りたい
- そのために毎月行っている定常的なQA環境の構築をエンジニアからプランナーに移したい
- そのための作業マニュアルをつくってほしい
とのことでした。
工数が減ることは嬉しいので大歓迎。しかし職種の違うプランナーに任せて良い作業なのだろうか。
すこし不安が残るものの、ディレクターの考えには賛成なので私は作業マニュアルの作成にとりかかることにしました。
気をつけたこと
まずは自分が行っている定常作業の棚卸しを行います。
私が所属しているゲーム運営のプロジェクトで、エンジニアが行っている定常作業は以下のような作業でした。
- リリース用branchをつくる（本番リリース用のbranchを切って、そこにリリースするbranchをmergeする）
- ゲームに必要なDBのテーブルを作成する（シェルをたたいて、全部できているか確認する）
ざっくり大別してgit操作とmysqlの操作だけ。コードを書き換えるとかそんなことはしません。
こうしてみるとコマンドをひたすら叩くだけの作業であることがわかります。
（コードの書き換えがなくてホッとした）
では作業の全体を確認したあとで、ここからが本題です。
作業マニュアルをつくるにあたって、なにに気をつけるか。
いろいろ考えて私が気をつけたことは
- キーボードを捨てる
- 正解はつける
- 先にネタバラシ
の３つでした。
※ちなみに上記のmysqlとgit操作はプランナーにターミナルで実行してもらいます。
※クライアントを使うのもありですが、効率化が目的のため学習コストよりも習熟後の作業スピードを優先したためです。
キーボードを捨てる
ターミナルではコマンド操作ゆえ、オペレータの自由度が高くなります。
これがはじめて触る人となれば知らないうちに事故をおこす可能性が高くなることになりますし、なによりキーボードに触ること自体こわいはず。
それならキーボードに触らないようにすればいい…！
そう思って作業マニュアルでは事故防止と安心感を高めるために「コピー＆ペースト」による運用に徹底的に拘りました。
コピペならマウスだけ触れれば操作できるし、これからのスマホ世代にも対応できるので一石二鳥ですね。
できた実際の作業マニュアルをつかった定常作業はこんな流れです。
１、作業マニュアル（スプレッドシート）にイベントの仕様書のURLをコピペ
２、作業マニュアル上で環境を選択
３、作業マニュアルが環境にあったコマンドを自動生成
４、マニュアルのうえから順番にコマンドをコピペでターミナルで実行するだけ
これだけ。
これでプランナーはコピペと数クリックで何も考えずに定常作業を行えます。
自分が取るべき行動が常にコピペになることで、そもそもキーボードを触らせない。
Ctrlは使うかもしれないけれど、なんならマウスひとつですべてが完結可能です。
あまりターミナルを触らない人からすれば選択肢が絞られることで「わかりやすさ」「安心感」を得られます。
エンジニアにとっても行動を制限できることは「安心感」につながりますし、トラブルが発生しても把握スピードが増すメリットがあります。
正解をつける
とはいえ、作業を完璧に制限できてもいつもと違う挙動とは起こるものです。
環境要因や、知らぬ間に違うものをコピーしていた、そもそも座る席を間違えたなどなど…。
そんなときにエンジニアが望むことはただ一つ。「なにもせずにすぐ呼んで！」。これに尽きるでしょう。
じゃあどうやってそれに気づかせて呼んでもらうか。それが問題です。
そこで私は作業マニュアルにコマンド実行後にはこんな画面になるよ！と「正解」をのせました
「正解」はコマンド実行後のスクリーンショット。そこに見てほしいポイントを四角で囲ってはっただけ。
例えばmysqlのログインであれば「>mysql」を囲って「これが見えればOK」としました。
これならいつもと違うことが起こっても、オペレータ側で問題を検知できます。
また「正解」があることで、自分の作業が「正しかった」と感じてもらえます。
そうでないと不安を抱えたまま作業を行うことになるためよくありません。
不安は余計なことを考えさせ、ミスを誘発させる要因になるからです。
先にネタバラシ
これが一番気をつけたことです。
ターミナルって見た目でも難しそうと思われているので、慣れていない人にとっては恐怖の画面です。
たとえ正解がわかっていても、そのプロセスで赤い文字が見えただけでビクつく人はいるはず。
そこで説明文言には「いまからなにをするか」ではなく「なにがおこるか」も書きました。
例えば、show tableを実行して、ズラーッとテーブルが出てくるなら「ズラズラと表示されますが、問題ありません」と添える感じ。
自分の作業で何か起こったー！と思わせず、事前に伝えて安心させる作戦です。
えー、そんなところまで？ と思うかもしれません。
でもそれは慣れているから言えることなのです。
作業マニュアルをつかってもらって
他にもいろいろ気を使って作業マニュアルができまして、ディレクターに渡して試してもらいました。
俺「できました？」
デ「大丈夫ですよー」
あっさりとした軽い内容。
いやでもこれでいいのです。軽いということはつまり不安がないということなのだから。
実際に何も修正はありませんでした。
現在も作業マニュアルは使われていて、引き継ぎにも役に立ってくれそうです。よかったよかった。
人はわかりやすさじゃなくて安心感でうごく
まとめてみると気をつけていることは「安心感」だとじぶんでも気づきました。
これってとっても大事だと思います。
よく専門内容を伝えるときには「わかりやすく」が定番で言われます。
専門用語は噛み砕いてとか、丁寧に伝えようとか。
エンジニアは技術職なので、他職種に仕事内容を伝えようとするとこういったことを念頭においている方が多いんじゃないかと。
でも、わかったからといってできるとは限りません。
すべてがわかっても不安があると人は立ち止まります。
逆にわからないことだらけでも、大丈夫と思っている人は自分からまえに進みます。
安心だと思ってるからそれについていく。実際に作業マニュアルは安心感を与えられるから信頼を得ていると言いかえられます。
エンジニアとして説明が上手いことも大事ですが、安心感を感じてもらうための技術も必要ではないかなと思いました。
最後まで読んでいただきありがとうございます。
次回16回目はhashiさんがお送りします。
緊急対応のときとか、とくに安心感て求められるじゃん。