Rails開発プロジェクトチームの
 始め方と入り方
 
 森 雅智 / @morimorihoge 2022/02/18 1
 銀座Rails #42
 ※スライドは発表後に #ginzarails で公開します 


About Me
 ● 森 雅智： @morimorihoge
 ● BPS株式会社でRailsの受託開発チームをやってたり、週1大学非常勤で Web開発を教えてたりします
 ● Ruby/Rails歴は11年くらい。Web開発は17年くらい
 ○ いわゆる受託業務アプリケーション開発屋です
 ● 銀座Rails#37より銀座Railsの運営を引き継いでいます
 About BPS & TechRacho
 ● Web受託開発の他、電子書籍製品・勤怠・入退室サービス
 ● TechRachoという自社技術Blogを運営しています
 ○ 平日毎日更新してます
 ○ https://techracho.bpsinc.jp/ ● お仕事相談、転職相談、TechRachoへのご意見など気軽にどうぞ
 ○ https://www.bpsinc.jp/ 2


導入編
 3


よくある光景
 新しくXXXというサービスを作ろう！予算も付けたぞ！ Y開発部長、後はよろしく！ 社長
 Y開発部長
 はい、分かりました（開発メンバーの稼働って空いてたっけ・・・

よくある光景
 5
 新しくXXXというサービスを作ろう！予算も付けたぞ！ Y開発部長、後はよろしく！ 社長
 Y開発部長
 はい、分かりました（開発メンバーの稼働って空いてたっけ・・・ （開発チームに）新規サービス立ち上げたいんだけど、手の空けられそう な人いる？ 開発チーム
 直近3ヶ月先までは現行サービスの追加開発で皆埋まっちゃってます ね。現行追加開発の方を止めて良ければ空けられますよ なるほど（ですよね～

よくある光景
 6
 新しくXXXというサービスを作ろう！予算も付けたぞ！ Y開発部長、後はよろしく！ 社長
 Y開発部長
 はい、分かりました（開発メンバーの稼働って空いてたっけ・・・ （開発チームに）新規サービス立ち上げたいんだけど、手の空けられそう な人いる？ 開発チーム
 直近3ヶ月先までは現行サービスの追加開発で皆埋まっちゃってます ね。現行追加開発の方を止めて良ければ空けられますよ Y開発部長
 なるほど（ですよね～ 社長、開発リソース的にいっぱいいっぱいなので、現行サービスの追加 開発を待ってもらうことはできますか？ 社長
 現行サービスはうちの稼ぎ頭だからそれは無理。なんとかして！

よくある光景
 7
 新しくXXXというサービスを作ろう！予算も付けたぞ！ Y開発部長、後はよろしく！ 社長
 Y開発部長
 はい、分かりました（開発メンバーの稼働って空いてたっけ・・・ （開発チームに）新規サービス立ち上げたいんだけど、手の空けられそう な人いる？ 開発チーム
 直近3ヶ月先までは現行サービスの追加開発で皆埋まっちゃってます ね。現行追加開発の方を止めて良ければ空けられますよ Y開発部長
 なるほど（ですよね～ 社長、開発リソース的にいっぱいいっぱいなので、現行サービスの追加 開発を待ってもらうことはできますか？ 社長
 現行サービスはうちの稼ぎ頭だからそれは無理。なんとかして！ ＼(^o^)／

開発メンバー圧倒的に足りない問題
 ● 「新しいこと」をやろうと思ったとき、社内にいるエンジニアは既存のプロジェ クトで手一杯になっていることが多い
 ● 他のプロジェクトの手を緩めることができない場合、企業として取り得る選 択肢は以下
 ○ 自社社員を育成する：時間がかかり、即効性がない 
 ○ 採用する：昨今では（特に無名）企業に取ってはかなり難しい 
 ○ 外注する：他のパートナー企業やフリーランス個人に依頼する 
 ○ その他にも、企業ごと開発会社を 買収するとかもあります
 8
 プロジェクトに時間制限がある場合には、実質外注が一番現実な選択肢 となる


開発外注を検討するときの不安
 ● そもそもどんな組み方ができるのか？
 ● 異なる文化のエンジニアを交えてちゃんと開発を回していけるのか？
 ● できあがったプロダクトはきちんと期待に添える機能・品質になるのか？
 ● 作ったは良いが、そのままベンダーロックインされて開発の主導権を持って行かれ ないか？
 ● 将来的に開発メンバーの追加・入れ替えがあってもきちんと運用できるか？
 9
 今日はこのあたりにどうやって折り合いを付けていくのか、という話を していきます


本日の話の注意点
 ● 僕（morimorihoge）の経験や偏見に基づくバイアスが大いにかかっています（開発 会社サイドで10年以上）
 ● 発注側視点・開発側視点なるべくどちらの視点も話すつもりですが、普段は開発側 をやっているのでそちら寄りになっていると思います
 ● 得意な仕事の進め方は千差万別なので、あくまで一例としてお聞き下さい
 ● ぶっちゃけRailsに特化した話は少な目です 󰢛💦
 10


本日のシナリオの前提
 ● 発注元の会社をA社とする
 ● A社には少なくとも1人のエンジニアが在籍している
 ○ CTOとかエンジニアチームがある等はそれぞれケース分けします 
 ● プロジェクト着手（発注）時点で全仕様が確定しておらず、何らかのアジャイル的開 発手法によって開発を行う
 ○ いわゆる請負契約ではなく準委任契約を想定します 
 ● 発注先の開発会社をD社とする
 ● A社内での社内政治等による予期しない負の要素は考慮しない
 ● D社は請け負った業務をこなすための最大限の努力を行う善良さを持つ
 11


開発会社（フリーランス）との
 座組を考える
 12


A社が外注先を検討する前に明確にすること
 ● プロダクト（サービス）の責任者を決める
 ○ PdM（Product Manager）・ PO（Product Owner）他色々な名前の種類があるが、名前は問わない 
 ○ 事業部や部署名ではなく 、必ず担当者の名前で明確に文書化（記録）する こと
 ■ ※経験上ここで人の名前が出てこないプロジェクトは後になってから意思決定で揉めることが 多い
 ○ ビジネスサイドとの橋渡し・責任役でもあるので外注先に担当してもらうのは困難 
 ● 外注先を含めたプロジェクト体制図案を作成し、希望する役割・指揮系統構成を検 討する
 ○ 開発会社であるD社もA社がどのような座組を望んでいるかが知りたい 
 ○ 具体的な例は後述
 ● システムのどの程度まで外注先に触らせて良いのかを考えておく
 ○ 個人情報を扱う場合などに本番環境のアクセス権限を許すのであれば、NDA等契約内容にも影響 するはず
 ○ 別途インフラやSRE部門があって実運用に関する部分は自社で管理したい、など各々事情がある はず
 13
 発注元の立ち上げ


開発体制図例A: 開発・タスク管理を含むメインをA社が行う（1）
 ● A社から開発側の責任者（プロダクト責任者を兼任化）が高いコミット率で参加し、 開発進捗管理を行うPM役も出す（ほぼ内製開発）
 ○ ※開発側の責任者とは、技術選定やシステム品質面の決定に責任を持つエンジニア 
 ● 例
 ○ A社側でGitHub Issueにある程度詳細な仕様まで確定した内容を起票し、D社のエンジニアにIssue 単位で処理してもらう 
 ○ D社の作ったコードのソースコードレビューはA社で実施する 
 14


開発体制図例A: 開発・タスク管理を含むメインをA社が行う（1）
 ● 利点
 ○ D社は流れてくるIssueを処理すれば良い状態となるので、プロジェクト管理にかける工数が最 小化できる（Issue消化ソルジャーになればよい）
 ○ 外注依存度が低く、メンバー入れ替えに堅牢な体制が組める。フリーランスも入りやすい
 ● 欠点
 ○ A社からこの役割をしてくれるメンバーを出せるか問題（テックリード＋PM役ができる人は貴重 で、大抵手が空いていない）
 15


開発体制図例B: 大まかな機能設計はA社が行うが、そこから先は外注する（1）
 ● A社で大まかなレベルの機能要件や技術指定などを行うが、開発のタスク 化から先はD社が行う
 ● 例
 ○ A社側チームでXDやFigma等で作った紙芝居は作成するが、詳細仕様への落とし込み・ヒ アリングはD社が行う
 ○ D社の設計した内容をA社でレビューし、OKが出たらD社側でタスク化・開発する 
 ○ 大きな技術選択や重要な機能の仕様についてはA社のエンジニアもレビューに適宜参加 する
 16


開発体制図例B: 大まかな機能設計はA社が行うが、そこから先は外注する（2）
 ● 利点
 ○ A社側の負担が小さめでよく、要件整理に集中できる
 ○ A社で仕様面も把握できるので、将来自社での開発引き取り等の芽が残せる（ベン ダーロックイン度が低い）
 ● 欠点
 ○ D社のPM/上流SE役のスキルへの依存度が高く、単価も高くなりがち
 17


開発体制図例C: 開発に関する内容を全て外注する（1）
 ● 開発に関する要件整理からD社に依頼し、D社で完結する開発チームを構築す る
 ● 一例
 ○ D社側のPM/上流SEや開発責任者、場合によってはコンサルできるメンバーも含めてプロダク ト責任者と十分に対話し、要件定義を固めていく
 ○ 時にはXDやFigma紙芝居を作ってあーでもないこーでもないしたり
 ○ 時にはラピッドプロトタイピングを作ってみたり
 18


開発体制図例C: 開発に関する内容を全て外注する（2）
 ● 利点
 ○ 信頼でき、うまく連携できるパートナー開発会社が見つかれば、すべてうまく進む 
 ● 欠点
 ○ 開発や保守運用、ビジネス周りも含めたノウハウがD社に集約されてしまうので、謀反を起こされた り仲が悪くなると辛い（ベンダーロックイン） 
 ○ 請負形態でなく納品がない分、成果物管理を疎かにするとD社がいなくなったときに何も残らなかっ たということになりがち 
 ■ そうなったサービスの開発を拾い上げるのはとても大変（高コスト）or不可能なことも 
 19


開発体制によるトレードオフ
 A: 開発・タスク管理を含むメインをA社
 
 
 
 
 
 B: 大まかな機能設計までA社
 
 
 
 
 
 C: 開発に関する内容を全てD社に外注
 20
 発注側の負担増
 自社controllable
 ベンダーロックインリスク 
 単価増・柔軟さ減
 単純化しすぎという感じもあるが、経営層にざっくりリスクを伝 える面では多分間違ってはいない


Railsプロジェクトチーム
 発足時のポイント
 21


Rails開発プロジェクトチーム発足時のポイント
 ● なるべく早い段階でそのプロジェクトの文化的合意を構築する
 ● 始めの1週間くらいでベースとなるプロジェクト・インフラの初期構築を行う
 ● 開発チームキックオフを行う
 ● 最初の「小ゴール」を決めておく
 ● うまくプロジェクトが軌道に乗り始めたらあとは慣性が働くので、適宜調整しつつ やっていく
 22
 この一連のパートを僕は「整地」と呼んでいます


開発の文化的合意形成を行う
 ● PM担当者が明示的に決めておくと良いこと
 ○ プロジェクト管理の方法と ルール・使い方
 ■ ツールは何を使う？Issueは誰が作るか？優先度管理の手法は？Issueテンプレートはどうす る？
 ○ プロダクト責任者との コミュニケーション・記録方法 
 ■ 偉い人に限って電話とかを使ってくるケースもあるので、そういった場合に必ず文字でも共有 するなどのルールを決めておく 
 ■ 開発者に記録が残らない形での直接依頼・相談はやめてね 、とかは決めておきたい 
 ● 開発責任者が決めておくと良いこと
 ○ ソース・リリース管理周り 
 ■ PR作成のルール（粒度・description）、branch policy、開発・staging・本番環境の扱いとdeploy ポリシなど
 ○ 設計周り
 ■ 定番系Gemで使うのが決まっているものの 決め（認証系・非同期Job・セッション管理・テストフ レームワーク、Rubocop、etc.） 
 ■ 大きなレベルでの設計に関する 考え方（routingのnamespaceで機能を分けるとか、mountable engineに分解しようとかetc.） 
 23
 全部最初に決めなくても良いが、決めていくと開発における迷いがなくなるので進めやすくな る。「これを決めるのは後回しにしよう」というのも合意の一つ


「最初の1週間」は整地に徹する
 ● 最初期はPM/上流SE役、開発責任者が一番頑張るタイミング
 ● なにも準備されていないところに開発メンバーをフルで投入しても動け ない（球がない）ので、最初の1週間は整地期間として少数精鋭で動く 方がやりやすい
 ○ Rails newもされてない状態で何人もいても意味がない
 ● 開発の文化的合意形成で暖めておいた内容を元に整地し、キックオフ から各メンバーが動き出せる様に準備を進める
 24


開発チームキックオフMTG
 ● 参加者
 ○ プロダクト開発に関わる全員 が望ましい
 ● プロジェクト概要の共有
 ○ どんなシステムを作るのか、 見えている範囲での ゴールイメージを共有する
 ○ 発注元のビジネスや、対象システムを使ってどうやって収益を上げようとしているのか等、大まかな レベルでのビジネス背景を共有 する
 ■ ※必要なテストの粒度や要求品質などはこの辺りから読み取れることも多い 
 ● コミュニケーションチャネルの構築
 ○ SlackやGitHub、BacklogにJira、Redmineなど、情報共有のチャンネルやプロトコルを決める 
 ○ 電話はオススメできないが、どうしても必要なら開発会社側は誰か一人に窓口は集約する 
 ● 開発定例MTGの調整
 ○ 最初期は1週間に1回以上は定例を開催する 
 ○ A社・D社お互いのメンバーの顔を合わせて精神的距離を近くすると、色々と円滑に進めやすい 
 ■ ※適切な距離感を保てないと感じたら早めにテコ入れする 
 25
 キックオフ後、各自すぐに動けるタスクがある状態にするのがベスト
 例：整地済みリポジトリをcloneしてローカル環境を整える、など


最初の「小ゴール」を決めておく
 ● スクラムだとスプリントプランニングに相当する？
 ● ある程度できあがりが分かりやすいゴールを決めて走り始め、達した時点で振り返 りを行う
 ● 良かった点、うまくいかなかった点などを正直ベースで話し合い、このまま続けるの かも含めて2社間で合意形成を取る
 ● 最初の「小ゴール」のタイミングが最も不満を打ち明け易いので、ここまでは手を抜 かずに慎重に進めたい
 26


プロジェクト発足初期の動き
 27
 開発サイクルが一度順調に回れば、後はそのサイクルを同じように回していくことができるの で、最初の1サイクルを特に大事に回したい


Railsプロジェクトチーム
 メンバー入れ替え
 28


プロジェクトチームの出会いと別れ
 ● 現代ではエンジニア入れ替わり・新規追加が頻繁に行われる
 ● 開発メンバーが入れ替わってもプロジェクトの開発になるべく支障がないようにした い
 29


新規メンバー受け入れのポイント
 ● 既に回っている開発の流れにうまく乗れるようにチームがサポートする
 ○ ドキュメント整備、キックオフの実施など 
 ● サポートがそれほどなくても流れに乗れるように、普段から受け入れの整備をして おく
 ○ 秘伝のタレ的設定からの脱却 
 30


ドキュメントの整備
 ● 最新の開発情報に関するポインタ情報をWiki等にまとめておく
 ○ 開発に必要な各種アカウント情報 
 ○ リポジトリURLや、必要なら別途あるGoogle Drive等の開発リソースへのリンク 
 ○ チームメンバーが忙しくても、 最悪ここを見れば自分から把握しに行くことができる ようにしておく
 ● README.md（初期ローカル環境構築手順）のメンテナンス
 ○ 理想はリポジトリをcloneしてREADME.mdだけ読めばローカル環境が構築できて、テスト実行やロー カル動作確認ができること 
 ○ APIキー等リポジトリに置けない情報が必要な場合でも、 誰に聞けば分かるか が書かれていること
 31


キックオフの実施
 ● 途中参加メンバー向けのキックオフはとても大事
 ○ ドキュメントや必要アカウントの発行後、必ず行う 
 ● ビジネス背景を含めた「このシステムは何で、どんな価値を生んでいるのか」「全体 としてどんなシステムと連携しているのか」などが見えていると、ソースコードを追い かける時の助けにもなる
 ● 頻度が高くて毎回やるのは厳しいということであれば、動画に残す等でも良いかも しれない
 ○ 僕はキックオフのログを残しておいて再利用することが多いです 
 32


新規JOINメンバーに適したタスク
 ● README.mdにある環境構築手順のアップデート
 ○ ある意味これ以上このタスクに向いている人はいない 
 ○ 単純なタスクなので分からない時にも質問しやすい（確実にREADMEが間違ってるはず） 
 ● 変更差分が見ればすぐに分かる類いの修正
 ○ 文言修正や影響範囲の小さそうな見た目CSS修正 
 ● 運用サイドから上がってきたバグの再現性確認
 ○ 操作手順を再現する過程でシステムの動きを追うので理解を深めやすい 
 ○ 改修自体に手を付けられなくても、再現確認してもらえるだけで既存メンバーのサポートにはなる 
 ● 既存機能の微改修（カラム追加など）や独立性の高い新規機能開発
 ○ 既存機能を参考に書けたり、既存との副作用を気にしなくて実装できる機能は比較的着手しやすい 
 33
 なるべく短い期間で取り組めて、完了が明確なタスクが良い。 
 自分のPRがmergeされると精神的安心を得られるので、その辺りも気にするとなお良い 


普段から意識するポイント
 ● 平易に書かれたテストコードを読めば何をやっているのか分かるような機能のド キュメント化は不要
 ○ むしろメンテされないドキュメントが増えてしまうことでノイズになる可能性すらある 
 ● テストコードを見ても「なぜ？」が分からない仕様にはコメントが欲しい
 ○ 僕はソースコメント派ですが、PRやcommit commentでも（プロジェクトルールに従う 
 ● 使われなくなったコードの削除
 ○ 純粋にノイズにしかならないので、なるべく気が付いたら殺していきたい 
 ● CIや各種環境で発生するwarningログ対策
 ○ 経緯をしらないと放置して良いのかまずいのか判断が付きにくいので迷う 
 34


色々やってもうまくいかなかったら？
 ● チームのhateが積み上がってギスギスしないうちに損切りを考えるべき
 ○ 契約解除できるのが外注の最大のメリット
 ○ 即戦力想定で2ヶ月経っても開発の輪に入れない場合、テコ入れが必要（私見です
 ● 実力のあるなしということもあるが、単にやり方のウマが合わないことで実力を 発揮できないという事もある
 ○ 開発会社・フリーランス側も「自分達が一番うまくアウトプットできる条件」を事前にもっとアピー ルすべき
 35


その他よもやま話
 36


特にモデルA（ほぼ内製開発）の場合の注意
 A社が直接D社開発メンバー（業務に対する裁量権なし）に指揮命令する形になると偽装 請負になってしまう
 Agile Japan 2021の発表を解説したPublickeyの記事がとても分かりやすいので必読
 * https://www.publickey1.jp/blog/21/agile_japan_2021.html
 注意していれば概ね大丈夫そうではあるが、リリース対応などで時間を決めて待機を依 頼する場合などに直接指示するとまずそう
 ※D社側の案件担当者を明らかにしておき、常時担当者には話が通せているようにすべ き
 37
 依頼の仕方に注意！


モデルC（ほぼ丸投げ）の他のやり方
 ● 0->1の完全新規開発の場合、要件定義・基本設計あたりまでを準委任契約で進 め、開発は請負契約で進めるという手もある（結構メジャーです）
 ○ 発注側：準委任契約の完成しないリスクを回避 できる
 ○ 受注側：全請負の想定外のオーバー稼働による原価割れを回避 できる
 ● 要件定義が終わったタイミングで他社と相見積もりを取ることも可能
 ○ 他社からも同程度の価格で見積が出てくる保証はないですが・・・ 
 ● 請負契約になる分、途中からの仕様変更は追加開発扱いで別料金になるデメリッ トもあります（料金内でやってくれるかは相手次第）
 38
 契約形態や座組の調整は最初にしくじると後から修正するのが難しい ので、事前に自社の望んでい る動き方になるのかを十分に検討したい 


自社開発（内製）>>>>>>SIer/開発会社（外注）？
 ● 自社に当該サービスに愛を持ってくれる優秀なエンジニアが十分に確保できる なら圧倒的に内製が良いが、世の中そう都合良くはない
 ○ プロジェクトの失敗リスク
 ○ 欲しい時に十分な数のエンジニアはいない（特にスタートアップ）
 ● 働き方として「自分は開発だけやりたい」というタイプの人もいる
 ○ 僕は同じプロジェクトにずっとじっとしていられないタイプ
 ● 勉強会とかに全く出てこない「すごいエンジニア」も沢山います
 ○ 全然しらない会社で突然そういう人と仕事できたりすると楽しい
 ● フリーランスが最高？
 39
 価値観は人それぞれ。他人の評価に惑わされすぎず自分の価値観で判断したい 


まとめ
 ● 受託ソルジャーとしてやってきた経験から、様々な外注との組み方を紹介しました
 ● 発注側サイドの方も、開発会社（フリーランス）サイドの方も何かの参考になれば幸 いです
 ● うちはこんな感じでうまくやってるよ！みたいな話、あればぜひ色々教えて下さい （Twitter/懇親会等
 ● 銀座Railsの発表者も随時募集してます！！！
 40