Upgrade to Pro — share decks privately, control downloads, hide ads and more …

サービス開発初期の「時間を金で買う」技術

 サービス開発初期の「時間を金で買う」技術

ウェブサービスをゼロから開発して徐々に規模を大きくしていく過程では、CI環境の準備などサービス開発を続けていく上で開発チーム自身が準備をしなくてはいけないツール群が多くあります。これらの問題は多くのチームで共通にみられることから、世の中には様々なSaaSツールが用意されています。優れたサービスはそれなりの価格設定がされているものですが、場合によっては有料サービスを利用することにより、チームがサービス開発に集中できる時間を増やすという戦略も取ることができます。この発表では、私自身が仕事やプライベートで使っている開発支援系のツールに関する紹介と導入する場合の考え方や検討事項などについてお話します。

Masatoshi Iwasaki

March 23, 2019
Tweet

More Decks by Masatoshi Iwasaki

Other Decks in Technology

Transcript

  1. 岩崎 匡寿(いわさき まさとし) • Rails 2.x系からRailsエンジニア やってます。 • 以前は10年弱フリーランスの Railsエンジニアやってました。

    • 現在は株式会社クリプラで働い ています。 • 旧社名:クリニカル・プラット フォーム株式会社
  2. 発表で取り扱わない対象・事項 • 大規模なチーム or 大きい会社の中での小規模チーム • もしかしたら役立つ要素はあるかもしれません • 個人でのサービス開発 •

    予算制約が厳しくなければ参考になるところもあるかもしれません • 個々のサービスの詳細説明 • サービス間比較や事例のためにいくつか具体例を出す程度にとどめます • 各業界ごとに求められるコンプライアンス上の制限 • サービス選定に影響しますが業界それぞれであり、カバーしきれないため。 • 今回は自由にいろいろ選べる状況を想定。
  3. 金だけで解決できるものはあるか? 有償の開発系サービスを利用してエンジニアが機能追加・改修に 集中できる開発環境を作ることは金で解決できる(可能性がある) • 人員は増やしたいけど簡単に増えない • 度重なる方針転換 • 少しでも早くより良いサービスを提供したいという焦り •

    とにかくやらなきゃいけないことが多数で手が回らないことばかり 最終的には金だが時間もかかる ある意味新規サービスの宿命 焦ってもどうにもならないのであきらめましょう 開発系サービスで 一定の範囲を省力化
  4. 「時間を買う」アプローチでの 達成事項 • 社内に十分な知識やスキル、体制がない • 自社で構築するより各種コストが低い • 短期的に必要なもので、社内のリソースを使いたくない • チームの生産性を向上させる

    • 属人化を避けたい あまり解決されない問題 あくまで開発チームが自社のサービス開発に集中できる「時間」を 増やし、スケールしやすい状況を整える。
  5. 導入時のコスト • 既存サービスから乗り換える場合 • サービスが変わると環境も変わるので、一定の作業が必要 • アカウントの権限設定 • チームの実情に合わない管理モデルだと導入を諦めたほうがいいことも •

    アカウント管理 • 外部のIDサービスを使うのか、サービスごとにアカウントを使うのか • SSO対応のプランはエンタープライズ的な位置づけでお値段高めのケースも
  6. 代表的な課金体系の⾧所・短所 金額固定 従量制 (アカウント数) 従量制 (時間・データ量等) ⾧所 ランニングコストが読み やすい 人数に応じた課金で無駄がない

    利用した分だけの課金なので利 用料を最適化しやすい 短所 チームの規模に合わない と割高になりがち サービスが増えてくると合計 金額が積みあがる 最終的には使ってみないと金額 が読めなかったり、変動要素が 大きい
  7. ほんとに欲しいメリットが得られるか • トライアル期間中にある程度使い倒すのが望ましい • トライアル開始したらすぐに使ってみる • トライアル期間延⾧は対応してくれることも多い • 「使ってみたらイメージと違う」ことはよくある •

    サービスの機能不足、設計思想の違い • 想定していた料金プランより高いプランにせざるを得なかったり • データ量に応じた課金はかなり細かい計算が必要 • 運用が回らないような複雑なサービスだとあまり意味がない
  8. 代表的なステークホルダー • 決定権者(決裁権者) • この人がOKを出せば決定する、という人 • 開発チームのリーダーが決定権を持っていれば何の問題もない • 往々にしてコストとメリットのバランスについて数字が必要 •

    経理担当 • 契約するサービスの目的や支払いタイミングなどの説明が必要 • 支払い手段や通貨についての説明と合意 • 税務的な調整(消費税のリバースチャージ方式とか) 代表的な対応策は後述
  9. 導入時の注意事項 • サービス乗り換え時は特に入念な準備が必要 • アクセス権限の設定 • 管理者アカウント(特にオーナー権限)は常用しないなど • 導入直後には細々と問題が起きがち •

    自社サービスの大きなリリースがあるときは避け、余裕を持つ • 芋づる式的に利用中のサービスについても権限や設定見直しが必要になるこ ともある(例:Slack)
  10. 様々なモニタリングが必要 • アクセス数で金額が変動する場合などはモニタリング必須 • 通知や時系列のデータを追えるようにする • サービスアップデートに注意を払う • サービスのバージョンアップに追随しないといけないケースが多く、そのために一定のコスト がかかる

    • プラン変動 • 料金プランが変わることもあり、たまに新たに出てきた安いプランのほうがチームの利用実態 に即しているケースもある • 経費申請を考えると支払い方法や請求書を経理担当者に渡すなどの部分について要ルール化
  11. 代表的なステークホルダー(再掲) • 決定権者(決裁権者) • この人がOKを出せば決定する、という人 • 開発チームのリーダーが決定権を持っていれば何の問題もない • 往々にしてコストとメリットのバランスについて数字が必要 •

    経理担当 • 契約するサービスの目的や支払いタイミングなどの説明が必要 • 支払い手段や通貨についての説明と合意 • 税務的な調整(消費税のリバースチャージ方式とか)
  12. エンジニアの時給単価で考える • エンジニアの時給単価をベースに、自社内でやった場合にどれだけの金額になるか を比較する • 例 • 額面年収600万のエンジニアが月に8時間(1人日)稼働した場合のざっくりな時給計算 • 600

    / 12 / 20(営業日ベース) = 2.5万円 • 2.5 / 8 = 3,125円/h • 同じサービスを社内で構築・運用して上記のエンジニアが月に合計1日分(8時間)を割い ている状態で、これが月に1時間程度になる場合、25,000 – 3,125 = 21,875円以下のサービ スなら導入するメリットのほうがコストを上回る。
  13. ソースコード管理(SCM) • GitHub • 多くのOSSプロダクトがホスティングされており、業務とは関係なく使い慣れている開発者も 多い。 • GitLab • ソースコード管理だけでなく、プロジェクト管理やCI、リリースに関する機能も提供されてい

    る。 • どちらのサービスもアカウント数ベース課金 • Self-managedは小規模チームでは検討対象外のことが多い • 自前でgit用にサーバーを立てるという選択肢もあるが、サービス開発初期に有効な選 択肢かどうかは微妙
  14. CI • コンテナ上でテストを実行するサービスが主流 • 料金体系は様々 • GitLab: ソースコード管理サービスの一部として提供。アカウント数ベースの課 金。 •

    CircleCI: 利用するコンテナ数に応じた課金 • TravisCI: プランごとに利用可能なコンテナ数が決まっている月額課金 • Buildkite: アカウント数ベースの課金+自社AWSアカウント上での利用料金
  15. プロジェクト管理ツール • SCM付属の機能を利用(GitHub Project, GitLab) • Pivotal Tracker • メンバー数、プロジェクト数、ストレージ容量それぞれに制限がある料金プラン

    • BackLog • プレミアムプランより上はプロジェクト数、ユーザ数が無制限 • Redmine • 自前でサーバー用意か、ホスティングを利用するか
  16. パフォーマンスモニタリング(APM) • サービスによって課金体系が違う • NewRelic, DataDog(ホスト台数に比例) • SkyLight(月間リクエスト数に応じたプラン制) • 運用は目的を明確にしたほうがいい

    • パフォーマンスのボトルネック(N+1とか)を見つけるためか • リアルタイムでパフォーマンス劣化を検知するためか • インフラ側のサービス監視とも重複する
  17. コード品質管理 • RubocopやBrakemanなど各種OSSを組み合わせて計測してくれる • 自前でやろうとするとPRごとに差分を取得してチェックすることになり、それな りに手間がかかる • SideCI, CodeClimate •

    どちらもユーザー数ベース課金 • SideCIは国内サービスで日本語対応している上、国内開発者のお気持ちにフィッ トしている気がする
  18. いい会社があります!(PR) https://clipla.jp/recruit/ • 休日の勉強会参加は業務扱い(代休取得可能) • Rails DM / RubyKaigi 等は希望者全員参加(チケット費用・宿泊費・交通費支給)

    • 最大週4日リモート • 開発標準機はMacbook Pro 15inch 2018 メモリ32GB(色・キーボード選択可) • 積極的に開発系サービスを利用 ※2019/03/23時点