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

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

Transcript

1. 株式会社クリプラ 岩崎 匡寿 Rails Developer Meetup 2019 Day 2
3. 岩崎 匡寿（いわさき まさとし） • Rails 2.x系からRailsエンジニア やってます。 • 以前は10年弱フリーランスの Railsエンジニアやってました。 • 現在は株式会社クリプラで働い ています。 • 旧社名：クリニカル・プラット フォーム株式会社
4. 会社PR 株式会社クリプラはRails DM 2019のワインスポンサーです。
6. 今日お話しすること サービス開発初期の 「時間を金で買う」 技術 Railsを利用している小規模チーム、かつ サービスが初期段階にあるチーム向けに、 サービスの機能追加・改善を優先するため、 社内で説明が必要となる有償の開発ツー ル・サービスを、 どういう観点で選び、導入していくかに ついて、 個人や組織での経験を踏まえて お話しします。
7. 発表の主な対象 • Railsで書かれていて、主に自社サービスのような継続的な開発が必要 なサービスを担当しているチーム • かつ、会社自体もそれほど大きいわけでなく、サービス開発をする チームをサポートする別の開発チームがあるわけでもない状況 • 特にサービス本体が（もしくは会社も）始まったばっかりの状況
8. 発表で取り扱わない対象・事項 • 大規模なチーム or 大きい会社の中での小規模チーム • もしかしたら役立つ要素はあるかもしれません • 個人でのサービス開発 • 予算制約が厳しくなければ参考になるところもあるかもしれません • 個々のサービスの詳細説明 • サービス間比較や事例のためにいくつか具体例を出す程度にとどめます • 各業界ごとに求められるコンプライアンス上の制限 • サービス選定に影響しますが業界それぞれであり、カバーしきれないため。 • 今回は自由にいろいろ選べる状況を想定。
9. ※開発系サービス＝Rails開発していく上で、開発者や開発チームを対象と した様々なウェブサービス群（IaaSは除きます）
10. （たぶん） 使っていないチームのほうが少数 • Rails開発の場合ソースコード管理はgitが標準。 • GitHubやGitLabの利用が多い印象。 • 他にも様々な有償のサービス・ツールを利用しているところが多いはず。 • CI • プロジェクト管理ツール • IDE（サブスクリプション型） • 監視 etc
11. サービス開発初期あるある • 人員は増やしたいけど簡単に増えない • 度重なる方針転換 • 少しでも早くより良いサービスを提供したいという焦り • とにかくやらなきゃいけないことが多数で手が回らないことばかり エンジニアは新機能の追加や既存機能の改修にフォーカスさせたい
12. 金だけで解決できるものはあるか？ 有償の開発系サービスを利用してエンジニアが機能追加・改修に 集中できる開発環境を作ることは金で解決できる（可能性がある） • 人員は増やしたいけど簡単に増えない • 度重なる方針転換 • 少しでも早くより良いサービスを提供したいという焦り • とにかくやらなきゃいけないことが多数で手が回らないことばかり 最終的には金だが時間もかかる ある意味新規サービスの宿命 焦ってもどうにもならないのであきらめましょう 開発系サービスで 一定の範囲を省力化
13. 開発系サービスで 「時間を金で買う」場合の考え方 チームのエンジニアが行っている、 • 顧客へのサービスという点において本質的ではないが、 • 開発を進めるうえで重要なタスク・要因を、 • SaaS（およびその中にいるプロ）にアウトソースすることで、 開発チーム全体がサービス開発に集中できる「時間」を増やす
14. よくある開発系サービス導入の理由 • 社内に十分な知識やスキル、体制がない • 自社で構築するより各種コストが低い • 短期的に必要なもので、社内のリソースを使いたくない • チームの生産性を向上させる • 属人化を避けたい
15. 「時間を買う」アプローチでの 達成事項 • 社内に十分な知識やスキル、体制がない • 自社で構築するより各種コストが低い • 短期的に必要なもので、社内のリソースを使いたくない • チームの生産性を向上させる • 属人化を避けたい あまり解決されない問題 あくまで開発チームが自社のサービス開発に集中できる「時間」を 増やし、スケールしやすい状況を整える。
17. ５つのステップ 1. サービスを知る 2. コストとメリットを把握する 3. 正式導入の意思決定 4. 導入・運用
19. 何事も情報収集から • 解決したい問題が自明なら能動的に検索すればいい。 • 自分が全く知らない分野のサービスなどは受動的に情報に触れる機会を増 やす • SNSやニュースサイト • 勉強会やコミュニティに顔を出す • 企業が主催するセミナーに出るのも有効
21. 検討すべき３つのコスト • 導入時のコスト • 運用時のコスト • 解約・変更時のコスト
22. 導入時のコスト • 既存サービスから乗り換える場合 • サービスが変わると環境も変わるので、一定の作業が必要 • アカウントの権限設定 • チームの実情に合わない管理モデルだと導入を諦めたほうがいいことも • アカウント管理 • 外部のIDサービスを使うのか、サービスごとにアカウントを使うのか • SSO対応のプランはエンタープライズ的な位置づけでお値段高めのケースも
23. 運用時のコスト • 料金体系を把握する • 従量制なのか、固定金額か。従量制ならどの数量が影響するのか • サービスのモニタリング方法 • どうやって監視をするか • 継続的に使い続けるための手間 • 導入してそのまま放置できるようなサービスは少ない
24. 代表的な課金体系の⾧所・短所 金額固定 従量制 （アカウント数） 従量制 （時間・データ量等） ⾧所 ランニングコストが読み やすい 人数に応じた課金で無駄がない 利用した分だけの課金なので利 用料を最適化しやすい 短所 チームの規模に合わない と割高になりがち サービスが増えてくると合計 金額が積みあがる 最終的には使ってみないと金額 が読めなかったり、変動要素が 大きい
25. 解約・変更時のコスト • ウェブサービスはアップデート頻度が高い • 料金プランの変更もよくあるので、プラン変更が可能かどうかを把握しておく • 年間契約は一見安いが… • 利用解除時の条件（キャンセルフィー）をよく確認しておく
26. ほんとに欲しいメリットが得られるか • トライアル期間中にある程度使い倒すのが望ましい • トライアル開始したらすぐに使ってみる • トライアル期間延⾧は対応してくれることも多い • 「使ってみたらイメージと違う」ことはよくある • サービスの機能不足、設計思想の違い • 想定していた料金プランより高いプランにせざるを得なかったり • データ量に応じた課金はかなり細かい計算が必要 • 運用が回らないような複雑なサービスだとあまり意味がない
28. まずは開発チームでの合意 • 導入の目的や期待するメリット・効果をチームメンバーと共有 • 開発者同士だと話が早い傾向がある（と思う） • この段階で見落としていたコストや追加のメリットなども把握できる • 運用できなければ意味がない • チームとして無理のなく運用できることが重要 • 場合によってはここで料金プランのグレードを上げるなどの判断が必要
29. たまにイベントで聞く話 開発系サービス 使いたいけど高い 開発系サービス使いたいと社⾧に言っ たけど、お金出してもらえなかった
30. 開発チーム外との調整 • 開発系サービスは確かにそれなりの値段がする（ように見える）ので、社内で 説明が求められるのは想像がつく。 • 一方で、ちゃんと開発系サービスを活用することで、チームのアウトプットを 高めることが可能であり、自社サービスや会社にメリットがある ステークホルダーに説明をして理解を得る必要がある
31. 代表的なステークホルダー • 決定権者（決裁権者） • この人がOKを出せば決定する、という人 • 開発チームのリーダーが決定権を持っていれば何の問題もない • 往々にしてコストとメリットのバランスについて数字が必要 • 経理担当 • 契約するサービスの目的や支払いタイミングなどの説明が必要 • 支払い手段や通貨についての説明と合意 • 税務的な調整（消費税のリバースチャージ方式とか） 代表的な対応策は後述
33. 導入時の注意事項 • サービス乗り換え時は特に入念な準備が必要 • アクセス権限の設定 • 管理者アカウント（特にオーナー権限）は常用しないなど • 導入直後には細々と問題が起きがち • 自社サービスの大きなリリースがあるときは避け、余裕を持つ • 芋づる式的に利用中のサービスについても権限や設定見直しが必要になるこ ともある（例：Slack）
34. 様々なモニタリングが必要 • アクセス数で金額が変動する場合などはモニタリング必須 • 通知や時系列のデータを追えるようにする • サービスアップデートに注意を払う • サービスのバージョンアップに追随しないといけないケースが多く、そのために一定のコスト がかかる • プラン変動 • 料金プランが変わることもあり、たまに新たに出てきた安いプランのほうがチームの利用実態 に即しているケースもある • 経費申請を考えると支払い方法や請求書を経理担当者に渡すなどの部分について要ルール化
36. 代表的なステークホルダー（再掲） • 決定権者（決裁権者） • この人がOKを出せば決定する、という人 • 開発チームのリーダーが決定権を持っていれば何の問題もない • 往々にしてコストとメリットのバランスについて数字が必要 • 経理担当 • 契約するサービスの目的や支払いタイミングなどの説明が必要 • 支払い手段や通貨についての説明と合意 • 税務的な調整（消費税のリバースチャージ方式とか）
37. 代表的な「No!」の理由 • 利用料が高い！ • 必要な理由を決裁権者に理解してもらえない。 • 内製ツールで回っているので必要性を感じてもらえない 数字に落とし込むことで「No」が出づらい状況にする
38. 基本的な方針 1. 「導入することによるメリット」を明確にし、 2. そこにかかるコストについて金額をつけていって、 3. 最終的にサービス導入のほうがメリットがあるよ うに説明していく
39. 基本的な方針 1. 「導入することによるメリット」を明確にし、 2. そこにかかるコストについて金額をつけていって、 3. 最終的にサービス導入のほうがメリットがあるよ うに説明していく
40. 開発系サービス導入の理由（再掲） • 社内に十分な知識やスキル、体制がない • 自社で構築するより各種コストが低い • 短期的に必要なもので、社内のリソースを使いたくない • チームの生産性を向上させる • 属人化を避けたい これらの中から必要なものを組み合わせて説明
41. 基本的な方針 1. 「導入することによるメリット」を明確にし、 2. そこにかかるコストについて金額をつけていって、 3. 最終的にサービス導入のほうがメリットがあるよ うに説明していく
42. エンジニアの時給単価で考える • エンジニアの時給単価をベースに、自社内でやった場合にどれだけの金額になるか を比較する • 例 • 額面年収600万のエンジニアが月に８時間（１人日）稼働した場合のざっくりな時給計算 • 600 / 12 / 20（営業日ベース） = 2.5万円 • 2.5 / 8 = 3,125円/h • 同じサービスを社内で構築・運用して上記のエンジニアが月に合計1日分（8時間）を割い ている状態で、これが月に1時間程度になる場合、25,000 – 3,125 = 21,875円以下のサービ スなら導入するメリットのほうがコストを上回る。
43. 作業時間数の割り出し方 • 正確に記録できていればいいが、ざっくりでも構わない • 日報をつけているチームであれば、後からおおよその時間を追うことが可能 • PR/MRでの経過日数などを見てもいいかもしれない • 細かく時間を取られる作業がもっとも読みづらい • そして着実にチームメンバーの時間を奪っていく怖い存在 • 予め注意して作業時間を計測するほうがいい
44. 基本的な方針 1. 「導入することによるメリット」を明確にし、 2. そこにかかるコストについて金額をつけていって、 3. 最終的にサービス導入のほうがメリットがあるよ うに説明していく
45. 基本的でないアプローチ： 採用コストと割り切る •「魅力的な労働・開発環境を作ることが結果的に採 用コストを抑える」と説得。
46. 昨今のエンジニア需給バランス • エンジニア不足は世界的に叫ばれている • 日本が単純に少子高齢化しているからというだけではない。 • 今後も給与水準は上昇し続け、さらに採用コストも上昇 • エージェントや求人媒体に支払う金額もかなりのものになる 「普通それ使うよね」という開発系サービスを利用していない ことが応募者の会社選定に大きく影響を与えることも。
47. 開発系ツールは安い （採用コストと比べて） • エンジニア１人取るためにかなりの費用がかかる • 数百万はざらなので、開発ツールの費用なんか比べ物にならない • リファラル採用を進めたい企業が多いが、そのためにはサービスや開発体 制が魅力的であることが重要 現在のメンバーの労働環境を改善することは、 将来のメンバー獲得にも直結して一石二鳥! ということをうまく言葉にして説得しましょう
49. Disclaimer • あくまで自分がRails開発でよく聞くものをまとめてあります • 自分で使ったことのないサービスもあるので、抜け漏れがあるかもしれま せん。 • 定番サービスも多く取り上げてますので、導入済みの場合は振り返り程度 にとらえてください。
50. ソースコード管理（SCM） • GitHub • 多くのOSSプロダクトがホスティングされており、業務とは関係なく使い慣れている開発者も 多い。 • GitLab • ソースコード管理だけでなく、プロジェクト管理やCI、リリースに関する機能も提供されてい る。 • どちらのサービスもアカウント数ベース課金 • Self-managedは小規模チームでは検討対象外のことが多い • 自前でgit用にサーバーを立てるという選択肢もあるが、サービス開発初期に有効な選 択肢かどうかは微妙
51. CI • コンテナ上でテストを実行するサービスが主流 • 料金体系は様々 • GitLab: ソースコード管理サービスの一部として提供。アカウント数ベースの課 金。 • CircleCI: 利用するコンテナ数に応じた課金 • TravisCI: プランごとに利用可能なコンテナ数が決まっている月額課金 • Buildkite: アカウント数ベースの課金＋自社AWSアカウント上での利用料金
52. Buildkiteの課金体系 • テスト実行インスタンスにエージェントを入れてテスト実行や結果の一元 管理が可能 • テスト実行のインスタンスはAWS上でEC2等を利用可能。 • どれだけのインスタンスをどのくらいの時間使うかについての制限がない • 当然AWS使用料は別途かかる • 「月額プランでは夜間や休日分が遊んでいる」という見方ができる • テスト実行時間が⾧くなってくると、実行速度改善の観点で効果が高い。
53. プロジェクト管理ツール • SCM付属の機能を利用（GitHub Project, GitLab） • Pivotal Tracker • メンバー数、プロジェクト数、ストレージ容量それぞれに制限がある料金プラン • BackLog • プレミアムプランより上はプロジェクト数、ユーザ数が無制限 • Redmine • 自前でサーバー用意か、ホスティングを利用するか
54. バグ管理（BTS） • プロジェクト管理とBTSを別に分けるかどうか問題 • 個人的には最低限プロジェクトは分けたほうが運用がスムーズと考えている • 例：サポートの優先順位と開発の優先順位が異なる • サポートや企画もBTSを使う場合は日本語対応が重要（なことが多い） • 社内エンジニアの助けがなくても自走できるようにすることで、エンジニアの手 間を減らす
55. IDE • JetBrainsの製品は現在サブスクリプションベースが主流 • Rubymineは高機能なIDE • 静的解析機能が強力なので、非Railsエンジニア（フロントエンド等）が一部の ソースコードを追うときに役立つ。 • DataGrip（SQL用ツール）相当の機能もあり、SQLクエリを書きたいときにも便 利。 • 極めなくても使える便利機能で時間効率が上がるなら検討を。
56. パフォーマンスモニタリング（APM） • サービスによって課金体系が違う • NewRelic, DataDog（ホスト台数に比例） • SkyLight（月間リクエスト数に応じたプラン制） • 運用は目的を明確にしたほうがいい • パフォーマンスのボトルネック（N+1とか）を見つけるためか • リアルタイムでパフォーマンス劣化を検知するためか • インフラ側のサービス監視とも重複する
57. テストカバレッジ取得 • SimpleCovの結果をCI上で都度確認するだけならCIの設定でも十分だが、時系列的 な変化を追いづらい • CIでファイルをアップするだけにしてもYAMLいじってる時間が無駄と感じたら検討の価 値あり • Coveralls: リポジトリ数ベースの月額プラン • CodeCov: リポジトリ数ベースの従量制と見せつつ、一定数ごとのプラン制限 • CodeClimate（後述）も対応している
58. コード品質管理 • RubocopやBrakemanなど各種OSSを組み合わせて計測してくれる • 自前でやろうとするとPRごとに差分を取得してチェックすることになり、それな りに手間がかかる • SideCI, CodeClimate • どちらもユーザー数ベース課金 • SideCIは国内サービスで日本語対応している上、国内開発者のお気持ちにフィッ トしている気がする
59. Gem更新 • 継続的に更新されるサービスであれば、やむを得ない事情がない限りはgemのバー ジョンロックをしないほうが結果的にサービスの寿命が延びる • 自動でgem更新されるのが望ましい • Dependabot（リポジトリ数ベースのプラン制） • PRベースで更新を出してくれる • GitHub Marketplaceで契約できるので請求一元化が可能 • Ruby以外の言語にも対応 • Deppbotは2018末でサービス終了した模様
60. （備考）IDaaSやSSOについて • IDaaSやSSOはいろいろコストがかかる • サービスによって対応しているIDaaSがあったりなかったり • SSO対応は企業しか欲しがらないので、enterprise plan扱いでお値段も enterpriseなことが多い • ただし、後から入れるよりは最初から入れるほうがいいのでいずれ必要になるな ら最初から検討するのが良い。
62. 攻めの開発サービス導入を • 適切な開発サービス導入は開発チームが自分たちのサービス開発に集中で きる時間を増やすことができる • 一方で、導入にコストがかかる可能性もあり、導入前に見極めが必要 • 決裁権者との調整はエンジニアにとって不得手かもしれないが、チームの 開発環境を整えることは現在のメンバーだけでなく将来のメンバー獲得に もつながる • 定番サービスは比較的簡単に導入ができることが多い
63. しかし、 • なかなか開発系サービス導入についてチームメンバーの関心が得られない • 決裁権者が合理的でない理由で導入を認めてくれない • 自分自身、快適な環境で働きたいのに…. どうしてもそういうこともある。 そんなときは….
64. いい会社があります！（PR） https://clipla.jp/recruit/ • 休日の勉強会参加は業務扱い（代休取得可能） • Rails DM / RubyKaigi 等は希望者全員参加（チケット費用・宿泊費・交通費支給） • 最大週４日リモート • 開発標準機はMacbook Pro 15inch 2018 メモリ32GB（色・キーボード選択可） • 積極的に開発系サービスを利用 ※2019/03/23時点