DevLOVE関西 「『Mackerel』のサービス開発の現場」での発表資料です。 https://devlove-kansai.doorkeeper.jp/events/32893

1. スタートアップこそ
巨人の肩に乗りまくれ！
∼Craful開発とMackerel∼
ギルドワークス株式会社
前川 博志 a.k.a @Posaune

2. 自己紹介
• 前川博志 a.k.a @Posaune
• もともと老舗メーカでWindowプログラマ
ギルドワークス株式会社所属ALMエンジニア
• Microsoft MVP for Visual Studio ALM
Visual Studio
and Development Technology

3. ALM #とは
• Application Lifecycle Management
• アプリケーションの一生を面倒見るお仕事
• どういう課題から、どういう要求が生まれて、
それをどう実現し、どう確認し、どう運用し、
どう役目を終わらせるか。
• （個人的解釈です）

4. アプリーケーションの輪 転生
※イメージです

5. ALMエンジニアとしての最近
• ギルドワークスの現場コーチ
• 飛び込みCIエンジニアとして主にiOS周りの
ビルド環境を整備
• CI Serviceにゾッコン中
http://www.slideshare.net/Posaune/jenkinsci-50411288

6. 開発者としての最近
• 現在、新規サービス立ちあげ案件3件に開発者
（兼 マネジメント or Scrum Master）として参画中
• JavaとSwift楽しいです。コンパイルできるって素
晴らしい。型って素晴らしい。
• どんなプロジェクトでも、ユーザに一歩踏み込んで
ディスカッションしています

7. 開発・現場での困り事は
なんでもギルドワークスへ！

8. さて、本題。

9. スタートアップこそ
巨人の肩に乗りまくれ！
∼Craful開発とMackerel∼

10. ギルドワークスとスタートアップ
• これまで、ギルドワークスでは2つのスタートアップ
開発を支援してきました
• まごチャンネル (https://www.mago-ch.com/)
• Craful (http://www.craful.jp/)
• その中でも、本当に「スタートアップ」らしい
開発を行ったCrafulの舞台裏についてお話します

11. スタートアップの悩み

12. スタートアップのジレンマ
• スタートアップは、
余計なことをしている時間はない！！
• スタートアップは、
できる失敗は限られている！！

13. 余計なことをしている時間はない！
• スタートアップは、成功するまでに許された
期間は少ない
• 次の投資を得るために、目に見える成果を、
できるだけ早く得ることが重要
• 「製品をつくる」以外の事は、できるだけや
りたくない

14. 「余計なこと」の例
• ビルド・デプロイ・テスト
• メトリクス収集
• サーバ運用・監視

15. できる失敗は限られている！
• スタートアップが切り開く領域は、これまで
だれも挑戦したことのない分野が多い
• 今作っているものが本当に市場の評価に耐えうるかを、
全力で判断し、素早く方向転換
• 「市場の評価」は年々厳しくなる一方。使えない製品
をリリースしている余裕はない。

16. しないといけない「余計なこと」
• ビルド・デプロイ・テスト
頻繁なフィードバックを得るのに必須
• メトリクス収集
事実に基づくフィードバックが必要
• サーバ運用・監視
エラーをいち早く検知し、ユーザの離脱を防止

17. スタートアップのジレンマ
• 余裕が無い =
「製品をつくる」以外に中々気が回らない
• 失敗できない=
失敗をすばやく計測しリカバリする仕組みが必須
• ただでさえ時間がないのに、環境を入念に仕込んでおか
ないと、致命的な失敗をしてしまう

18. ジレンマを解消するには？
• 「余計なこと」をある程度肩代わりしてくれ
るようなサービス・ソフトを活用する
• 設定はできれば自動化、最低でもデフォルト
設定でそこそこ使えるような状態に
• 動き出せば、最小限のメンテンスで動いて欲
しい
Everything as a Service

19. Everything as a Service
• 何もかも、サービスに寄せよう
• 自分たちの技術力を過信しない
評判の良い環境・巨人の肩に乗る
• （ホントのスタートアップの規模だと、
サービスのほうが圧倒的にコスト安い）

20. ジレンマの解消のために
スタートアップでやったこと
∼Craful 開発を例に∼

21. Crafulについて

22. Crafulについて
• ハンドメイドのアイデアを集めて見つける
プラットフォーム（まずはiOSから）
• サービスの企画から、開発、リリースまでを
ギルドワークと共同で実施
• 今年起業の、バリバリスタートアップ

24. ビルド・デプロイの「余計」
• ビルドならJenkins！…ですら面倒
• サーバのデプロイも、手動とか無理！
• iOSアプリも、常に最新を！！確認したい！！

25. ビルド・デプロイを助ける
サービス
• ビルド：CircleCI
iOSビルド可能, 無料枠有り
• デプロイ：Heroku
環境構築不要、つくるときにはこれで充分、無料枠有り
• iOSデプロイ：DeployGate
CLIから完全に自動で配信可能、無料枠有り

26. 開発・確認のワークフロー
• サーバ側：
- master push時にHerokuでテスト・デプロイ
- ほとんど設定なし
• クライアント側：
- master pushでDeployGateの配信バージョン更新
- 常に最新のiOSビルドをクライアントと確認

27. メトリクス収集の「余計」
• 各画面における離脱率を見たい！けれど、、
• 開発中はページはコロコロ変わるし、細かい
メトリクス収集を入れるのは非常に面倒

28. メトリクス収集を助けるサービス
• グロースのための画面録画サービス、Repro
https://repro.io/
• ユーザー端末上での画面の動きを録画し、
動画でシミュレート表示
• ユーザの離脱原因やクラッシュ要因を、実際に目で見て確認で
きる
• ぶっちゃけ、スタートアップ早期だとわりと全部目を通せる量
のアクセスしかこない

29. 運用・監視の「余計」
• 当たり前だが、本番用サーバは必要。
だが、設定諸々は面倒だし、ミスを起こしや
すい
• サーバの監視はしておかないと、夜寝れない
よね？

30. 運用・監視を助けるサービス
• プログラム寄り
（アプリケーションプロファイル）
New Relic ！
• サーバ寄り
（マシンプロファイル）
Mackerel！

31. New Relic
• アプリケーションの各種メトリックスを
（ほぼほぼ）自動取得してくれるサービス
• 特に何も考えずに入れておくだけで、
パフォーマンスなどのメトリックスを出してく
れる

33. Mackerel
• はてな製のサーバ外形監視ツール。
• とにかく、導入障壁が低いのが嬉しい所
• パフォーマンス測定時に、 のエラーが
発生し、New Relicではさっぱり分からず、慌てて
外形監視ツールを探していた
• 特に嬉しかったところは・・・

34. 嬉しいポイント①
設定の簡便さ

35. Mackerelは設定簡単
• 設定が超簡便。他のフレームワークだと…

36. Mackerelは設定簡単
• Mackerelだと・・・
① rpmでインストールして、
② 起動して、
② 設定ファイルのコメントアウト外して、
③ おしまい！
• Postgres用の設定なり、Linux用の設定なりも一瞬でできる。
• 深夜一時から、原因不明のエラー救命に大急ぎで入れる、
なんて無茶な要請にも見事に答えてくれました！

37. 地味に嬉しい設定ファイル

38. 嬉しいポイント②
画面のユーザーフレンドリーさ

39. Nagios

40. Zabbix

41. Mackerel

42. 画面はバカにできない
• ぱっと見て使いたくなるか、使い続けようと
思うかはかなり大きい
• 画面操作を覚えている時間すらも「余計」
• マニュアル片手にしか使えないツールは、
根本的にスピード感合わない

43. その他嬉しいポイント
• アラート設定も楽ちん
（危ない時にメール送る、など）
• Agentと追加プラグインだけで、本当に
事が足りてしまう
• 開発者との距離が近い
（僕が京都にいるから、という意味ではなくて・・・）

44. まとめ

45. 巨人の肩に乗ろう！
• スタートアップでは、コアの価値を作ることに注力した
い
• とはいえ、コア以外の価値なしでは、サービスとして成
り立たない
• Everything as a Serviceの精神で、サービスを上手く使
おう
• 本来「アウトソース」とはこういう事なんじゃないの？

46. 仲間を募集中！！
http://guildworks.jp/contact/

47. Enjoy, Software Development !!