チラ見せ♡ナイト＠大阪で行われた二次会の発表資料です。 多分1/4も話してないと思うので興味があればどうぞ。

2. だれ？
Keisuke Utsumi
KLab.inc
ApplicationEngineer
PHP , Unity(C#)
CrystalFantasia @ServerLeader

3. Agenda
まとめ
作る理由
作るタイミング
責務の分離
使ってもらうには

4. 前提
ここではjenkinsやslackといった既存ツールの活用
法ではなく、社内などで幅広く利用することを前
提とした内製ツールの作り方や広め方についてお
話します。
!
※時間の都合上、早口ですのでしっかりついて来る
か聞き流してください

5. まとめ

6. まとめ
あくまでもツール
プロダクトと同じレイヤーで考えない
ツールの作成の優先度はやや高め
一つ一つをシンプルに
高性能すぎるものは使われなくなっていく
情報は集積する
使ってもらわないと意味がない

7. 作る理由

8. 作る理由
面倒だから
ラクしたいから

9. これ、お願いね(*´∀｀*)
いつものアニメーションファイルの更新

10. 機嫌よく承り∼(*´∀｀*)
3分程度で終わるしまぁいいか

11. これ、お願いね(*´∀｀*)
すぐ出来るって言ってたよね？(*´∀｀*)

12. 大量に不定期に突如訪れる依頼
なめてんのかク⃝B⃝A!!!!!!!!!

13. この様にならないためにもツールを作ろう
簡単な作業でも塵積ですよ
頻繁なコンテキストスイッチは開発者の敵
しかも何故かいつも30分以内には欲しいそうです
⃝⃝して☆☆するだけの簡単なお仕事♪じゃねーから

14. 作るタイミング

15. 作るタイミング
早ければ早い方がいい
荒削りでも早い方がいい
セクション間のWAITが発生しているなら優先度はどんど
ん高める

16. 浮いた工数で巻き返せ
自動化ツールや簡易化ツール導入によって恩恵を受けるの
は全セクション
だからこそ荒くてもいち早く提供することがプロジェクト
の開発速度を左右する
ツール開発で使った時間は浮いた時間で巻き返す
回り道の方が早いこともいっぱいある

17. かける工数は2日間
最大のボトルネックになっている箇所だけをまず解決する
方向にする
見積もり2日でできないものは一旦別のアプローチを考え
る
2日以上かかってしまうものは根本的な問題があるor課題
分解がうまくできていない可能性を考える

18. 責務の分離

19. ツールとしての責務の切り分け方
なんでも出来るツールは結局何もできなくなる
ニッチなツールでいいじゃない!!!!
プロダクトとは別レイヤーで考える
プロダクトに依存したツールはプロダクトと共に寿命を迎
える

20. ユーザー責務の切り分け方
作った物は作者が意図通りかを確認する
色盲な僕にUIのカラー調整の確認させても答えがでない
作者がまず一人で実機やエンドユーザーの環境で確認でき
るものを作る
企画/UI/アニメーション/サウンド/プログラム全てに置い
て言えること
全体的なことはその後のデバッグフェーズでやればいい

21. ex)こんなツール
gitで管理されたpngやアニメーションをUnityの
AssetBundle形式に吐き出す「だけ」のツール
S3にjs/css/画像を「uploadだけ」するツール
設定データをsqliteに書き出す「だけ」のツール

22. 使ってもらうには

23. 統合管理環境を提供
この段階でやっとプロダクトと紐付ける
管理画面/CMSとか言われるやーつ
慣れたWebUIでブラウザから操作できる
該当操作以外を受け付けないつくり
説明なしでもわかるUIを心がける（ツールがシンプルなの
で容易に実現が可能

24. 情報分散を避ける
通知や情報の集積は必ず一箇所にまとめる
ツールへのキック等はCMSを通してログを取る
ブラウザだけでほぼ完結出来るようにする
ブラウザ→専用ツール→製作ツール→ブラウザとかやって
ると結構めんどくさい

25. 不要知識の排除
知識は多いに越したことはないが、無意味に習得させる
必要はない
専門知識がなくとも、デプロイやコンテンツ更新を安心し
て出来る環境を目標とする
属人化の排除(担当者の急な失踪にも対応可能!!!!

26. やってみて
アニメーション/サウンドなどのアプリ内リソースの確認
は作者が製作完了∼実機デバッグまで2分で出来るように
なった
サーバーへのuploadや、データの書き換え等の依頼は0に
安心して集中してプログラムを書くことが出来る環境に
作ったものをベースに社内共通のツールへ昇華

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

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