だれ？

Keisuke Utsumi

KLab.inc

ApplicationEngineer

PHP , Unity(C#)

CrystalFantasia @ServerLeader

Agenda

まとめ

作る理由

作るタイミング

責務の分離

使ってもらうには

前提ここではjenkinsやslackといった既存ツールの活用法ではなく、社内などで幅広く利用することを前提とした内製ツールの作り方や広め方についてお話します。

!

※時間の都合上、早口ですのでしっかりついて来るか聞き流してください

まとめ

まとめあくまでもツール

プロダクトと同じレイヤーで考えない

ツールの作成の優先度はやや高め

一つ一つをシンプルに

高性能すぎるものは使われなくなっていく

情報は集積する

使ってもらわないと意味がない

作る理由

作る理由

面倒だから

ラクしたいから

これ、お願いね(*´∀｀*)

いつものアニメーションファイルの更新

機嫌よく承り～(*´∀｀*)

3分程度で終わるしまぁいいか

これ、お願いね(*´∀｀*)

すぐ出来るって言ってたよね？(*´∀｀*)

大量に不定期に突如訪れる依頼

なめてんのかク◯B◯A!!!!!!!!!

この様にならないためにもツールを作ろう

簡単な作業でも塵積ですよ

頻繁なコンテキストスイッチは開発者の敵

しかも何故かいつも30分以内には欲しいそうです

◯◯して☆☆するだけの簡単なお仕事♪じゃねーから

作るタイミング

作るタイミング

早ければ早い方がいい

荒削りでも早い方がいい

セクション間のWAITが発生しているなら優先度はどんどん高める

浮いた工数で巻き返せ

自動化ツールや簡易化ツール導入によって恩恵を受けるのは全セクション

だからこそ荒くてもいち早く提供することがプロジェクトの開発速度を左右する

ツール開発で使った時間は浮いた時間で巻き返す

回り道の方が早いこともいっぱいある

かける工数は2日間

最大のボトルネックになっている箇所だけをまず解決する方向にする

見積もり2日でできないものは一旦別のアプローチを考える

2日以上かかってしまうものは根本的な問題があるor課題分解がうまくできていない可能性を考える

責務の分離

ツールとしての責務の切り分け方

なんでも出来るツールは結局何もできなくなる

ニッチなツールでいいじゃない!!!!

プロダクトとは別レイヤーで考える

プロダクトに依存したツールはプロダクトと共に寿命を迎える

ユーザー責務の切り分け方作った物は作者が意図通りかを確認する

色盲な僕にUIのカラー調整の確認させても答えがでない

作者がまず一人で実機やエンドユーザーの環境で確認できるものを作る

企画/UI/アニメーション/サウンド/プログラム全てに置いて言えること

全体的なことはその後のデバッグフェーズでやればいい

ex)こんなツール

gitで管理されたpngやアニメーションをUnityのAssetBundle形式に吐き出す「だけ」のツール

S3にjs/css/画像を「uploadだけ」するツール

設定データをsqliteに書き出す「だけ」のツール

使ってもらうには

統合管理環境を提供この段階でやっとプロダクトと紐付ける

管理画面/CMSとか言われるやーつ

慣れたWebUIでブラウザから操作できる

該当操作以外を受け付けないつくり

説明なしでもわかるUIを心がける（ツールがシンプルなので容易に実現が可能

情報分散を避ける

通知や情報の集積は必ず一箇所にまとめる

ツールへのキック等はCMSを通してログを取る

ブラウザだけでほぼ完結出来るようにする

ブラウザ→専用ツール→製作ツール→ブラウザとかやってると結構めんどくさい

不要知識の排除

知識は多いに越したことはないが、無意味に習得させる必要はない

専門知識がなくとも、デプロイやコンテンツ更新を安心して出来る環境を目標とする

属人化の排除(担当者の急な失踪にも対応可能!!!!

やってみてアニメーション/サウンドなどのアプリ内リソースの確認は作者が製作完了～実機デバッグまで2分で出来るようになった

サーバーへのuploadや、データの書き換え等の依頼は0に

安心して集中してプログラムを書くことが出来る環境に

作ったものをベースに社内共通のツールへ昇華

やったね( ´∀｀)bｸﾞｯ!

ご清聴ありがとうございました