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

Slide 1

Slide 1 text

株式会社クリプラ岩崎匡寿 Rails Developer Meetup 2019 Day 2

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

岩崎匡寿（いわさきまさとし） • Rails 2.x系からRailsエンジニアやってます。 • 以前は10年弱フリーランスの Railsエンジニアやってました。 • 現在は株式会社クリプラで働いています。 • 旧社名：クリニカル・プラットフォーム株式会社

Slide 4

Slide 4 text

会社PR 株式会社クリプラはRails DM 2019のワインスポンサーです。

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

今日お話しすることサービス開発初期の「時間を金で買う」技術 Railsを利用している小規模チーム、かつサービスが初期段階にあるチーム向けに、サービスの機能追加・改善を優先するため、社内で説明が必要となる有償の開発ツール・サービスを、どういう観点で選び、導入していくかについて、個人や組織での経験を踏まえてお話しします。

Slide 7

Slide 7 text

発表の主な対象 • Railsで書かれていて、主に自社サービスのような継続的な開発が必要なサービスを担当しているチーム • かつ、会社自体もそれほど大きいわけでなく、サービス開発をするチームをサポートする別の開発チームがあるわけでもない状況 • 特にサービス本体が（もしくは会社も）始まったばっかりの状況

Slide 8

Slide 8 text

発表で取り扱わない対象・事項 • 大規模なチーム or 大きい会社の中での小規模チーム • もしかしたら役立つ要素はあるかもしれません • 個人でのサービス開発 • 予算制約が厳しくなければ参考になるところもあるかもしれません • 個々のサービスの詳細説明 • サービス間比較や事例のためにいくつか具体例を出す程度にとどめます • 各業界ごとに求められるコンプライアンス上の制限 • サービス選定に影響しますが業界それぞれであり、カバーしきれないため。 • 今回は自由にいろいろ選べる状況を想定。

Slide 9

Slide 9 text

※開発系サービス＝Rails開発していく上で、開発者や開発チームを対象とした様々なウェブサービス群（IaaSは除きます）

Slide 10

Slide 10 text

（たぶん）使っていないチームのほうが少数 • Rails開発の場合ソースコード管理はgitが標準。 • GitHubやGitLabの利用が多い印象。 • 他にも様々な有償のサービス・ツールを利用しているところが多いはず。 • CI • プロジェクト管理ツール • IDE（サブスクリプション型） • 監視 etc

Slide 11

Slide 11 text

サービス開発初期あるある • 人員は増やしたいけど簡単に増えない • 度重なる方針転換 • 少しでも早くより良いサービスを提供したいという焦り • とにかくやらなきゃいけないことが多数で手が回らないことばかりエンジニアは新機能の追加や既存機能の改修にフォーカスさせたい

Slide 12

Slide 12 text

金だけで解決できるものはあるか？有償の開発系サービスを利用してエンジニアが機能追加・改修に集中できる開発環境を作ることは金で解決できる（可能性がある） • 人員は増やしたいけど簡単に増えない • 度重なる方針転換 • 少しでも早くより良いサービスを提供したいという焦り • とにかくやらなきゃいけないことが多数で手が回らないことばかり最終的には金だが時間もかかるある意味新規サービスの宿命焦ってもどうにもならないのであきらめましょう開発系サービスで一定の範囲を省力化

Slide 13

Slide 13 text

開発系サービスで「時間を金で買う」場合の考え方チームのエンジニアが行っている、 • 顧客へのサービスという点において本質的ではないが、 • 開発を進めるうえで重要なタスク・要因を、 • SaaS（およびその中にいるプロ）にアウトソースすることで、開発チーム全体がサービス開発に集中できる「時間」を増やす

Slide 14

Slide 14 text

よくある開発系サービス導入の理由 • 社内に十分な知識やスキル、体制がない • 自社で構築するより各種コストが低い • 短期的に必要なもので、社内のリソースを使いたくない • チームの生産性を向上させる • 属人化を避けたい

Slide 15

Slide 15 text

「時間を買う」アプローチでの達成事項 • 社内に十分な知識やスキル、体制がない • 自社で構築するより各種コストが低い • 短期的に必要なもので、社内のリソースを使いたくない • チームの生産性を向上させる • 属人化を避けたいあまり解決されない問題あくまで開発チームが自社のサービス開発に集中できる「時間」を増やし、スケールしやすい状況を整える。

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

５つのステップ 1. サービスを知る 2. コストとメリットを把握する 3. 正式導入の意思決定 4. 導入・運用

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

何事も情報収集から • 解決したい問題が自明なら能動的に検索すればいい。 • 自分が全く知らない分野のサービスなどは受動的に情報に触れる機会を増やす • SNSやニュースサイト • 勉強会やコミュニティに顔を出す • 企業が主催するセミナーに出るのも有効

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

検討すべき３つのコスト • 導入時のコスト • 運用時のコスト • 解約・変更時のコスト

Slide 22

Slide 22 text

導入時のコスト • 既存サービスから乗り換える場合 • サービスが変わると環境も変わるので、一定の作業が必要 • アカウントの権限設定 • チームの実情に合わない管理モデルだと導入を諦めたほうがいいことも • アカウント管理 • 外部のIDサービスを使うのか、サービスごとにアカウントを使うのか • SSO対応のプランはエンタープライズ的な位置づけでお値段高めのケースも

Slide 23

Slide 23 text

運用時のコスト • 料金体系を把握する • 従量制なのか、固定金額か。従量制ならどの数量が影響するのか • サービスのモニタリング方法 • どうやって監視をするか • 継続的に使い続けるための手間 • 導入してそのまま放置できるようなサービスは少ない

Slide 24

Slide 24 text

代表的な課金体系の⾧所・短所金額固定従量制（アカウント数）従量制（時間・データ量等）⾧所ランニングコストが読みやすい人数に応じた課金で無駄がない利用した分だけの課金なので利用料を最適化しやすい短所チームの規模に合わないと割高になりがちサービスが増えてくると合計金額が積みあがる最終的には使ってみないと金額が読めなかったり、変動要素が大きい

Slide 25

Slide 25 text

解約・変更時のコスト • ウェブサービスはアップデート頻度が高い • 料金プランの変更もよくあるので、プラン変更が可能かどうかを把握しておく • 年間契約は一見安いが… • 利用解除時の条件（キャンセルフィー）をよく確認しておく

Slide 26

Slide 26 text

ほんとに欲しいメリットが得られるか • トライアル期間中にある程度使い倒すのが望ましい • トライアル開始したらすぐに使ってみる • トライアル期間延⾧は対応してくれることも多い • 「使ってみたらイメージと違う」ことはよくある • サービスの機能不足、設計思想の違い • 想定していた料金プランより高いプランにせざるを得なかったり • データ量に応じた課金はかなり細かい計算が必要 • 運用が回らないような複雑なサービスだとあまり意味がない

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

まずは開発チームでの合意 • 導入の目的や期待するメリット・効果をチームメンバーと共有 • 開発者同士だと話が早い傾向がある（と思う） • この段階で見落としていたコストや追加のメリットなども把握できる • 運用できなければ意味がない • チームとして無理のなく運用できることが重要 • 場合によってはここで料金プランのグレードを上げるなどの判断が必要

Slide 29

Slide 29 text

たまにイベントで聞く話開発系サービス使いたいけど高い開発系サービス使いたいと社⾧に言ったけど、お金出してもらえなかった

Slide 30

Slide 30 text

開発チーム外との調整 • 開発系サービスは確かにそれなりの値段がする（ように見える）ので、社内で説明が求められるのは想像がつく。 • 一方で、ちゃんと開発系サービスを活用することで、チームのアウトプットを高めることが可能であり、自社サービスや会社にメリットがあるステークホルダーに説明をして理解を得る必要がある

Slide 31

Slide 31 text

代表的なステークホルダー • 決定権者（決裁権者） • この人がOKを出せば決定する、という人 • 開発チームのリーダーが決定権を持っていれば何の問題もない • 往々にしてコストとメリットのバランスについて数字が必要 • 経理担当 • 契約するサービスの目的や支払いタイミングなどの説明が必要 • 支払い手段や通貨についての説明と合意 • 税務的な調整（消費税のリバースチャージ方式とか）代表的な対応策は後述

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

導入時の注意事項 • サービス乗り換え時は特に入念な準備が必要 • アクセス権限の設定 • 管理者アカウント（特にオーナー権限）は常用しないなど • 導入直後には細々と問題が起きがち • 自社サービスの大きなリリースがあるときは避け、余裕を持つ • 芋づる式的に利用中のサービスについても権限や設定見直しが必要になることもある（例：Slack）

Slide 34

Slide 34 text

様々なモニタリングが必要 • アクセス数で金額が変動する場合などはモニタリング必須 • 通知や時系列のデータを追えるようにする • サービスアップデートに注意を払う • サービスのバージョンアップに追随しないといけないケースが多く、そのために一定のコストがかかる • プラン変動 • 料金プランが変わることもあり、たまに新たに出てきた安いプランのほうがチームの利用実態に即しているケースもある • 経費申請を考えると支払い方法や請求書を経理担当者に渡すなどの部分について要ルール化

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

代表的なステークホルダー（再掲） • 決定権者（決裁権者） • この人がOKを出せば決定する、という人 • 開発チームのリーダーが決定権を持っていれば何の問題もない • 往々にしてコストとメリットのバランスについて数字が必要 • 経理担当 • 契約するサービスの目的や支払いタイミングなどの説明が必要 • 支払い手段や通貨についての説明と合意 • 税務的な調整（消費税のリバースチャージ方式とか）

Slide 37

Slide 37 text

代表的な「No!」の理由 • 利用料が高い！ • 必要な理由を決裁権者に理解してもらえない。 • 内製ツールで回っているので必要性を感じてもらえない数字に落とし込むことで「No」が出づらい状況にする

Slide 38

Slide 38 text

基本的な方針 1. 「導入することによるメリット」を明確にし、 2. そこにかかるコストについて金額をつけていって、 3. 最終的にサービス導入のほうがメリットがあるように説明していく

Slide 39

Slide 39 text

Slide 40

Slide 40 text

開発系サービス導入の理由（再掲） • 社内に十分な知識やスキル、体制がない • 自社で構築するより各種コストが低い • 短期的に必要なもので、社内のリソースを使いたくない • チームの生産性を向上させる • 属人化を避けたいこれらの中から必要なものを組み合わせて説明

Slide 41

Slide 41 text

Slide 42

Slide 42 text

エンジニアの時給単価で考える • エンジニアの時給単価をベースに、自社内でやった場合にどれだけの金額になるかを比較する • 例 • 額面年収600万のエンジニアが月に８時間（１人日）稼働した場合のざっくりな時給計算 • 600 / 12 / 20（営業日ベース） = 2.5万円 • 2.5 / 8 = 3,125円/h • 同じサービスを社内で構築・運用して上記のエンジニアが月に合計1日分（8時間）を割いている状態で、これが月に1時間程度になる場合、25,000 – 3,125 = 21,875円以下のサービスなら導入するメリットのほうがコストを上回る。

Slide 43

Slide 43 text

作業時間数の割り出し方 • 正確に記録できていればいいが、ざっくりでも構わない • 日報をつけているチームであれば、後からおおよその時間を追うことが可能 • PR/MRでの経過日数などを見てもいいかもしれない • 細かく時間を取られる作業がもっとも読みづらい • そして着実にチームメンバーの時間を奪っていく怖い存在 • 予め注意して作業時間を計測するほうがいい

Slide 44

Slide 44 text

Slide 45

Slide 45 text

基本的でないアプローチ：採用コストと割り切る •「魅力的な労働・開発環境を作ることが結果的に採用コストを抑える」と説得。

Slide 46

Slide 46 text

昨今のエンジニア需給バランス • エンジニア不足は世界的に叫ばれている • 日本が単純に少子高齢化しているからというだけではない。 • 今後も給与水準は上昇し続け、さらに採用コストも上昇 • エージェントや求人媒体に支払う金額もかなりのものになる「普通それ使うよね」という開発系サービスを利用していないことが応募者の会社選定に大きく影響を与えることも。

Slide 47

Slide 47 text

開発系ツールは安い（採用コストと比べて） • エンジニア１人取るためにかなりの費用がかかる • 数百万はざらなので、開発ツールの費用なんか比べ物にならない • リファラル採用を進めたい企業が多いが、そのためにはサービスや開発体制が魅力的であることが重要現在のメンバーの労働環境を改善することは、将来のメンバー獲得にも直結して一石二鳥! ということをうまく言葉にして説得しましょう

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

Disclaimer • あくまで自分がRails開発でよく聞くものをまとめてあります • 自分で使ったことのないサービスもあるので、抜け漏れがあるかもしれません。 • 定番サービスも多く取り上げてますので、導入済みの場合は振り返り程度にとらえてください。

Slide 50

Slide 50 text

ソースコード管理（SCM） • GitHub • 多くのOSSプロダクトがホスティングされており、業務とは関係なく使い慣れている開発者も多い。 • GitLab • ソースコード管理だけでなく、プロジェクト管理やCI、リリースに関する機能も提供されている。 • どちらのサービスもアカウント数ベース課金 • Self-managedは小規模チームでは検討対象外のことが多い • 自前でgit用にサーバーを立てるという選択肢もあるが、サービス開発初期に有効な選択肢かどうかは微妙

Slide 51

Slide 51 text

CI • コンテナ上でテストを実行するサービスが主流 • 料金体系は様々 • GitLab: ソースコード管理サービスの一部として提供。アカウント数ベースの課金。 • CircleCI: 利用するコンテナ数に応じた課金 • TravisCI: プランごとに利用可能なコンテナ数が決まっている月額課金 • Buildkite: アカウント数ベースの課金＋自社AWSアカウント上での利用料金

Slide 52

Slide 52 text

Buildkiteの課金体系 • テスト実行インスタンスにエージェントを入れてテスト実行や結果の一元管理が可能 • テスト実行のインスタンスはAWS上でEC2等を利用可能。 • どれだけのインスタンスをどのくらいの時間使うかについての制限がない • 当然AWS使用料は別途かかる • 「月額プランでは夜間や休日分が遊んでいる」という見方ができる • テスト実行時間が⾧くなってくると、実行速度改善の観点で効果が高い。

Slide 53

Slide 53 text

プロジェクト管理ツール • SCM付属の機能を利用（GitHub Project, GitLab） • Pivotal Tracker • メンバー数、プロジェクト数、ストレージ容量それぞれに制限がある料金プラン • BackLog • プレミアムプランより上はプロジェクト数、ユーザ数が無制限 • Redmine • 自前でサーバー用意か、ホスティングを利用するか

Slide 54

Slide 54 text

バグ管理（BTS） • プロジェクト管理とBTSを別に分けるかどうか問題 • 個人的には最低限プロジェクトは分けたほうが運用がスムーズと考えている • 例：サポートの優先順位と開発の優先順位が異なる • サポートや企画もBTSを使う場合は日本語対応が重要（なことが多い） • 社内エンジニアの助けがなくても自走できるようにすることで、エンジニアの手間を減らす

Slide 55

Slide 55 text

IDE • JetBrainsの製品は現在サブスクリプションベースが主流 • Rubymineは高機能なIDE • 静的解析機能が強力なので、非Railsエンジニア（フロントエンド等）が一部のソースコードを追うときに役立つ。 • DataGrip（SQL用ツール）相当の機能もあり、SQLクエリを書きたいときにも便利。 • 極めなくても使える便利機能で時間効率が上がるなら検討を。

Slide 56

Slide 56 text

パフォーマンスモニタリング（APM） • サービスによって課金体系が違う • NewRelic, DataDog（ホスト台数に比例） • SkyLight（月間リクエスト数に応じたプラン制） • 運用は目的を明確にしたほうがいい • パフォーマンスのボトルネック（N+1とか）を見つけるためか • リアルタイムでパフォーマンス劣化を検知するためか • インフラ側のサービス監視とも重複する

Slide 57

Slide 57 text

テストカバレッジ取得 • SimpleCovの結果をCI上で都度確認するだけならCIの設定でも十分だが、時系列的な変化を追いづらい • CIでファイルをアップするだけにしてもYAMLいじってる時間が無駄と感じたら検討の価値あり • Coveralls: リポジトリ数ベースの月額プラン • CodeCov: リポジトリ数ベースの従量制と見せつつ、一定数ごとのプラン制限 • CodeClimate（後述）も対応している

Slide 58

Slide 58 text

コード品質管理 • RubocopやBrakemanなど各種OSSを組み合わせて計測してくれる • 自前でやろうとするとPRごとに差分を取得してチェックすることになり、それなりに手間がかかる • SideCI, CodeClimate • どちらもユーザー数ベース課金 • SideCIは国内サービスで日本語対応している上、国内開発者のお気持ちにフィットしている気がする

Slide 59

Slide 59 text

Gem更新 • 継続的に更新されるサービスであれば、やむを得ない事情がない限りはgemのバージョンロックをしないほうが結果的にサービスの寿命が延びる • 自動でgem更新されるのが望ましい • Dependabot（リポジトリ数ベースのプラン制） • PRベースで更新を出してくれる • GitHub Marketplaceで契約できるので請求一元化が可能 • Ruby以外の言語にも対応 • Deppbotは2018末でサービス終了した模様

Slide 60

Slide 60 text

（備考）IDaaSやSSOについて • IDaaSやSSOはいろいろコストがかかる • サービスによって対応しているIDaaSがあったりなかったり • SSO対応は企業しか欲しがらないので、enterprise plan扱いでお値段も enterpriseなことが多い • ただし、後から入れるよりは最初から入れるほうがいいのでいずれ必要になるなら最初から検討するのが良い。

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

攻めの開発サービス導入を • 適切な開発サービス導入は開発チームが自分たちのサービス開発に集中できる時間を増やすことができる • 一方で、導入にコストがかかる可能性もあり、導入前に見極めが必要 • 決裁権者との調整はエンジニアにとって不得手かもしれないが、チームの開発環境を整えることは現在のメンバーだけでなく将来のメンバー獲得にもつながる • 定番サービスは比較的簡単に導入ができることが多い

Slide 63

Slide 63 text

しかし、 • なかなか開発系サービス導入についてチームメンバーの関心が得られない • 決裁権者が合理的でない理由で導入を認めてくれない • 自分自身、快適な環境で働きたいのに…. どうしてもそういうこともある。そんなときは….

Slide 64

Slide 64 text

いい会社があります！（PR） https://clipla.jp/recruit/ • 休日の勉強会参加は業務扱い（代休取得可能） • Rails DM / RubyKaigi 等は希望者全員参加（チケット費用・宿泊費・交通費支給） • 最大週４日リモート • 開発標準機はMacbook Pro 15inch 2018 メモリ32GB（色・キーボード選択可） • 積極的に開発系サービスを利用 ※2019/03/23時点

Slide 65

Slide 65 text

No content