出張！Railsウォッチ
 in 銀座Rails#19
 森 雅智 / @morimorihoge 2020/03/19 1
 特集：～開発チームの冗長化について～


About Me
 ● 森 雅智： @morimorihoge
 ● BPS株式会社でRailsの受託開発チームをやってたり、週1大学非常勤で Web開発を教えてたりします
 ● Ruby/Rails歴は11年くらい。Web開発は17年くらい
 ● 銀座Ralis #10でActiveRecordでVIEWを使おうという話をしました
 About BPS & TechRacho
 ● Web受託開発や電子書籍製品開発をやっている会社です
 ● TechRachoという自社技術Blogを運営しています
 ○ 3年ほど前から平日毎日更新してます
 ○ https://techracho.bpsinc.jp/ ● お仕事相談、転職相談、TechRachoへのご意見など気軽にどうぞ
 ○ https://www.bpsinc.jp/ 2


Railsウォッチとは？
 技術ブログTechRachoで毎週連載しているRails / Ruby界隈を中 心とした雑多な情報を提供する技術雑談マガジン
 3


これまでの出張Railsウォッチのピックアップテーマ
 ● Rails6新機能特集
 ○ 銀座Rails#12: 複数DB対応
 ○ 銀座Rails#13: ActionText、Trix
 ○ 銀座Rails#14: ActionMailbox
 ● Railsアプリケーション開発に関する雑多なテーマ
 ○ 銀座Rails#15: production、development、staging環境につ いて
 ○ 銀座Rails#16: 機能開発の設計レビューについて
 ○ 銀座Rails#17: リソース管理スコープについて
 4
 ※過去のスライドはTechRachoにて公開しています。「TechRacho 銀座Rails」あたりで 検索するとヒットしますので興味のある方はどうぞ


開発チームの冗長化について
 5


例のアレの影響
 6
 ● 世間的に人が集まること自体が忌諱される状況に
 ● 仕事の進め方にも大きな影響が出ている
 ○ 突然のリモートワーク推進
 ○ 勉強会やカンファレンス イベントの中止・延期 
 ○ F2Fでの打ち合わせを禁止 するところも
 ○ 社内でも人数の多い会議や歓送迎会の中止 などなど
 ● 開発プロジェクトにも延期や中止などの影響が出始めている
 ● 現在進行系で日々状況が変わっているが、少なくとも現時点でいつ収束するのか の予測は立たない状況


Webエンジニアへの影響はどうか？
 ● 既にリモートワークやオンラインベースの業務の進め方に対応していた開発チーム では、他業種に比べると開発の面では大きな影響はない
 ○ F2Fを大事にしていたチームについては色々と試行錯誤の声が聞こえて来るが、ベストプラクティス の共有などもよく行われているので慣れていけば恐らく問題ない（１ヶ月くらいできっと慣れていきそ う）
 7


Webエンジニアへの影響はどうか？
 ● 既にリモートワークやオンラインベースの業務の進め方に対応していた開発チーム では、他業種に比べると開発の面では大きな影響はない
 ○ F2Fを大事にしていたチームについては色々と試行錯誤の声が聞こえて来るが、ベストプラクティス の共有などもよく行われているので慣れていけば恐らく問題ない（１ヶ月くらいできっと慣れていきそ う）
 8
 それって本当？


Webエンジニアへの影響はどうか？
 ● 既にリモートワークやオンラインベースの業務の進め方に対応していた開発チーム では、他業種に比べると開発の面では大きな影響はない
 ○ F2Fを大事にしていたチームについては色々と試行錯誤の声が聞こえて来るが、ベストプラクティス の共有などもよく行われているので慣れていけば恐らく問題ない（１ヶ月くらいできっと慣れていきそ う）
 9
 それって本当？
 ● もし仮に外出禁止や隔離措置が取られたとしたら？
 ● 確率は低いと言われているが、重症化して入院者が出たら？
 ● どうしても現地に行かないといけない仕事はどうなる？
 特に、スタートアップ等で少人数で運用しているチームの場合、
 そこまで「いざというときのための準備」がされていないことが多い


トラックナンバー（バス係数）を意識してみる
 ● プロジェクトメンバーのうち、もしトラック（バス）に轢かれた人がいた場合にプロジェ クトが継続できなくなる人数のこと
 ○ 仮に人命には影響がなくても、 一時的に一切の業務ができなくなってしまう可能性 はあり得る
 ● 1が最も脆弱で、ふとした要因でサービスやビジネスそのものが立ち行かなくなる危 険がある
 10


Railsプロジェクトで一部の人に偏りそうなもの
 ● 開発系
 ○ 難しい機能の設計や開発 タスク
 ○ コードレビューや本番リリース作業
 ● 運用系
 ○ リポジトリのmaster branchへのmerge / 本番deploy権限
 ○ 本番環境のAWSやGCPリソースを閲覧・更新する権限 
 ■ 構成にもよるが、一部の作業はPowerUserAccess権限だけだと実行できない（EC2インスタン スにIAM Roleを付与しようとしたらIAM Roleが参照できないとかがありがち） 
 ○ 連携サービスのアカウント、及び 通知メールの共有
 ■ クレジットカード課金失敗連絡を誰も見ていなかったらサービスが止まった、などはありがち 
 ○ credentials.ymlのRAILS_MASTER_KEY 
 ■ 頻繁に更新することはないが、たまに更新が必要になるため忘れやすい 
 ■ 連携サービスのAPIキーを再生成したりしたときに詰む可能性があるので注意 
 11


弊社（BPS株式会社）での対応例など
 ● 開発系
 ○ いざという時のために、普段開発には入らないがプロジェクトの情報だけは共有しておくメンバーを 1人以上予備アサイン しておく
 ○ 本番リリース作業などは手作業が必要なら手順化し、リポジトリWiki等にドキュメント化 
 ● 運用系
 ○ サービスやリソースアクセス用の アカウント情報は必ず2名以上が持つ ようにしておく（アカウント情 報ロスト対策としても有効） 
 ○ 障害対応の履歴や記録はなるべく 具体的なコマンド履歴やスクリーンショットレベルでチーム内に 共有しておき、いざというときに後から調べられるようにしておく 
 ■ 「どうやって障害と判断したのか 」「どうやって障害復旧を確認したのか 」は具体的な記録に残 しておくと、後から同じ作業を別の人が追いかけやすくなるので良いです 
 12


普段こんなかんじでやってます
 13
 ←これからやる作業の参考情報を共有 
 （将来振り返る時のためというのもある） 
 ←作業結果をスクショで貼ることで、もしおかしなことをし てたらきっと他の人も指摘してくれるはず 


とはいっても・・・
 ● 現状整備されたものがないので、これから作るにはリソースが足りなくて厳しい！
 ● 最小人数のエンジニアしかいないので、人的な余力がない！！
 ● 人を雇いたいけどいい人が見つからない！！！
 ● 上司にかけあってみたけど「現行リソースでなんとかしろ」と言われる
 14


まずはこれだけでもしておきたい
 ● まずは人的なSPOF（単一障害点）の洗い出しをする
 ○ 「リスクがあること」を可視化し、共有する のが大事
 ● 「もしこの人が突然作業できなくなったら・・・？」という前提で、ワーストケースのシ ナリオをいくつか描いてみる
 ● 描いたシナリオを、Product Ownerや偉い人（少なくとも何かあった時に責任が取れ る人）に共有し、どこまでならビジネス上許容できるのかを確認してもらう
 ● 許容できるレベルに達していないのであれば、時間なり予算をつけてもらってなん とか許容レベルまで持っていく
 15
 特に、障害対応関連の潜在リスク は開発チーム側にしかわからないものもあるので、開発サイドから Alertを上げていくのが良いと思います 


まとめ
 ● 開発プロジェクトチームにおいて、チーム自体の冗長化という視点で簡単にまとめ ました
 ● 普段一部のメンバーに負荷が偏ってしまっている状態を解きほぐすチャンスでもあ るので、世論に乗じて手を付けてみるのはありかもしれません
 ● 銀座Railsに参加している他の皆さんの開発チームも「こういうことやっているよ」み たいなことがあれば聞いてみたいです
 16


宣伝：週刊Railsウォッチ 公開つっつき会
 ● 毎月第一木曜日、社外の方も参加できる公開つっつき会を開 催してます（が、例のアレのため3月はお休み）
 ○ 次回Zoomでやるか検討中です
 
 ● TechRachoの週刊Railsウォッチの最新記事、または「週刊 Railsウォッチ公開つっつき会」でぐぐってご参加下さい！
 17


次回以降もブラッシュアップしていきます
 感想・リクエストなどあればTwitter
 #ginzarails
 @morimorihoge
 @hachi8833
 までお声かけください
 18