事業グロース
マーケティングを伴う自社サービスにおいて、
FTPを使ってるところはほぼ皆無かと思いますが、
ごく稀に、コーポレートのような小規模サイトしかやったことのない状態だと健闘に乗ってしまうため
全力でやめたほうがいいという話をします。
① FTPはセキュリティが弱い
🔴 FTP/SFTPの具体的な問題点：
- 平文通信（FTP）
FTPは通信内容が暗号化されておらず、パスワードやユーザ情報が簡単に盗聴可能です。 - 攻撃対象が広い
FTPポート（通常21番）をインターネットに開けると、外部から攻撃のターゲットにされやすくなります。 - パスワード漏洩リスク
FTPではパスワード認証が一般的であり、安易なパスワード設定やパスワードの使い回しが横行します。 - 共有アカウントによる危険
SFTPであっても、アカウントを複数人で共有すると、不正アクセスや情報漏洩時の影響範囲が非常に大きくなります。 - 権限管理の甘さ
FTPでは細かなアクセス制御が難しく、「全部アップロード可能」という状態で運用されることが多いため、万が一の不正アクセス時にすべてのファイルがリスクにさらされます。
✅ Git・SSH・CI/CDの解決策：
- SSH公開鍵認証の採用
GitやSSHでは「公開鍵認証」が一般的で、パスワード漏洩リスクが大幅に低減されます。 - 通信の完全暗号化（SSH）
SSHを通じて通信がすべて暗号化されるため、盗聴による情報漏洩が事実上不可能になります。 - 権限の細かな管理
GitHubやGitLabなどのGitホスティングサービスでは、個人ごとに権限を細かく設定でき、悪意あるアクセスを未然に防げます。 - 不要なポート閉鎖による攻撃対象削減
SSH経由のデプロイで、不要なFTPポートを完全に閉じることができ、外部攻撃のリスクを低減できます。 - ログの明確な記録
GitとCI/CDは「誰が・いつ・何をしたか」全て記録され、疑わしい行動が発生した場合、迅速に追跡して対応できます。
② FTPは変更履歴が残らない
🔴 FTP/SFTPの具体的な問題点：
- ファイル管理が原始的
FTPでは最新のファイルを直接上書きするだけなので、以前のバージョンに戻すことが困難です。 - 変更履歴の欠如
誰が・いつ・どのファイルを変更したかが記録されず、障害発生時に問題の切り分けが困難になります。 - リグレッション（先祖返り）の発生
古いファイルを誤って新しいファイルの上にアップロードしてしまうと、システム全体が古い動作状態に戻ってしまいます。 - 障害復旧が困難
問題が発生した際、直前の安定版が分からないため、復旧作業が手探りになり、ダウンタイムが長期化する可能性があります。
✅ Git・SSH・CI/CDの解決策：
- Gitでのバージョン管理
Gitは変更履歴をすべて記録しているため、問題発生時には迅速に原因特定が可能です。 - 即座のロールバック
Gitでは、問題が発生した時にすぐに以前の安定した状態に戻せます。 - ブランチ管理
開発途中の機能を別ブランチに隔離できるため、安定版に不具合を持ち込むリスクを減らせます。 - CI/CDでの安定版保証
CI/CDを導入すると、常にテスト済みの安定版が本番環境へ反映されるため、リグレッションが起きることがほぼありません。
③ FTPはヒューマンエラーが多い
🔴 FTP/SFTPの具体的な問題点：
- 手動操作によるミス
フォルダ間違い・ファイル漏れ・アップロード忘れ・削除ミスが起こりがちです。 - 煩雑なファイル管理
複数の開発者が作業すると、どのファイルが最新版か分からなくなることがあります。 - 再現困難な環境構築
同じ環境を再現するのが困難で、担当者の記憶やメモに依存した運用が続きます。 - 精神的な負担の増加
手動作業は注意力が求められ、担当者の心理的負荷が高まり、疲労によるミスも増加します。
✅ Git・SSH・CI/CDの解決策：
- 自動化されたデプロイプロセス
CI/CDパイプラインがあれば、人間が行う操作を最小化でき、ヒューマンエラーを根本から防げます。 - 常に最新のファイルを自動判定
Gitが管理するため、最新のファイルが常に自動で判断され、漏れがありません。 - 誰でも再現可能な環境構築
CI/CDの設定をコード化（Infrastructure as Code）すれば、常に同一の環境を誰でも再現できます。 - 人的コスト・精神的負荷の削減
作業が自動化され、担当者の作業負担が激減し、本来の開発に集中できるようになります。
④ FTPは属人化が起こり可視化不足
🔴 FTP/SFTPの具体的な問題点：
- 担当者依存の運用
作業内容や接続情報が特定の担当者のみに依存し、その人が不在だとデプロイ作業が完全に停止します。 - 情報共有不足
担当者以外の人間が手順を理解することが困難で、組織としての知識共有が進みません。 - コードレビューの文化が育たない
他人がコードを確認する習慣がなく、コードの品質低下や一貫性のなさが発生します。 - 新規メンバー教育の困難さ
属人化が進むと、新しく参加したメンバーがすぐに開発に参加できません。
✅ Git・SSH・CI/CDの解決策：
- 手順や環境をコード化し共有
CI/CDやInfrastructure as Codeを活用することで、作業手順が誰でも分かるようにコードとして管理されます。 - プルリクエストによるコードレビューの徹底
チーム全員でコード品質をチェックできる文化が醸成されます。 - 作業履歴と環境の可視化
全ての作業内容がGitの履歴やCI/CDログとして可視化され、組織全体で情報を共有できます。 - 新規メンバー教育が容易
手順や設定がコードで明示されているため、新人でも容易に環境構築や運用手順を理解し、即戦力化が可能です。
従来のFTP/SFTP開発手法に潜むリスク
1. セキュリティ上の懸念: 従来のFTPは通信内容や認証情報が暗号化されないため、ネットワーク上で盗聴される危険性があります。例えばFTPではIDやパスワードが平文で送信されるため、不正アクセスや情報漏洩のリスクが高くなります。SFTPはSSH経由で暗号化されるとはいえ、共有アカウントやパスワード管理がずさんだと安全性が損なわれます。さらにFTPポート(21番等)をインターネットに開けておく必要がある場合、サーバーへの攻撃対象が増えることにもなります。
2. バージョン管理の欠如: FTPによる手動アップロードではコードの変更履歴が残りません。誰が・いつ・何を変更したか記録されず、チーム内で「いつの間にか動作がおかしいが原因が追えない」といった事態に陥りがちです。変更履歴がないために過去の状態に戻すことも容易ではなく、誤って古いファイルで新しい変更を上書きしてしまう「先祖返り」（リグレッション）のリスクもあります。実際、Gitを使わないFTP運用では「『誰が』『いつ』『何を変更したか』不明」になりがちで、共同開発では致命的な不便さを招きます。
3. ヒューマンエラーの頻発: 手作業によるサーバーへのファイル転送はミスが起こりがちです。例えば、複数のファイルをディレクトリ階層を跨いで更新する際、アップロード漏れが発生したり、間違ったディレクトリにファイルをアップしてしまったりすることがあります。特にWebサイト更新では、画像やスクリプトなど関連ファイルの点数が多い場合、どれをアップロード済みか把握しづらくなり、人的ミスによる不具合（サイトの一部が表示されない等）が生じやすいです。また、手動作業ゆえに誤ったファイルを本番環境に上書きしてしまう事故も起こり得ます。実際にFTPソフトで複数サイトを管理している際、別のサイトのフォルダに誤ってファイルをアップロードしてしまうケースも報告されています。こうしたヒューマンエラーは手順を慎重に確認することで多少減らせますが、人間の注意力には限界があり、**「仕組みで防ぐ」**アプローチが取られていない点がリスクです。
4. 属人化と可視性の低さ: FTPでのデプロイは特定の担当者の手作業に依存しがちです。サーバーへの接続情報や作業手順が個人の頭の中やローカル環境に留まり、プロジェクト全体から見えにくくなります。結果として「その担当者しか本番反映のやり方を知らない」「担当者が不在だとデプロイできない」といった属人化が発生します。属人化した環境ではコードレビューの文化も根付きにくく、変更内容が第三者にチェックされないまま本番反映されてしまいます。これでは品質保証のプロセスが不十分で、バグの混入やスタイルの不統一にもつながります。実際、コードレビューを取り入れていない組織では、バグの見落としや実装のばらつきが発生しやすく、システムが個人の知識に依存して「ブラックボックス化」してしまいます。一方、コードレビュー文化を取り入れると**「コードの品質が圧倒的に上がる」「社内でコードスタイルを統一しやすい」「属人的になりにくい」**などの効果が得られることが知られています。FTP運用にはそのようなチーム全体でコードをチェックし合う仕組みがなく、プロジェクトマネージャーから見ても各メンバーの作業状況や品質を把握しづらいという問題があります。
現代的なGit＋SSH＋CI/CD手法の具体的な利点
1. 厳密なバージョン管理と変更履歴の追跡: 現代的な開発ではGitによるバージョン管理が中心に据えられます。Gitを使うことで、すべての変更履歴がリポジトリに記録され、「誰が」「いつ」「何を」変更したかが一目瞭然です。過去の任意のバージョンに簡単に戻す（ロールバックする）ことも可能で、問題発生時には迅速に前の安定状態へ復元できます。例えばデプロイツールのCapistranoでは、デプロイ履歴をサーバー上に一定数保存し、その範囲内であれば任意の過去バージョンに即座に切り戻せます。Git管理下でのデプロイでは、最新の安定版コードだけが本番環境に反映されるため、前述の**「アップロード漏れ」や「先祖返り」のリスクを大幅に軽減**できます。実際、GitLab等のCI/CDと連携すれば最新バージョンが常に自動デプロイされるので、常にコードとサーバーの内容が同期し、アップし忘れや古いコードの混入といった事故を防げます。また、Gitによるプルリクエスト（Mergeリクエスト）を活用すれば、本番反映前に必ずコードレビューが挟まるため、バグや不適切な実装を事前に検出できます。このように、Gitを軸とした開発フローでは変更履歴の追跡とレビュー体制によって品質と信頼性が飛躍的に向上します。
2. 自動テストとCI（継続的インテグレーション）による品質保証: 現代的手法では、開発者がコードをリポジトリにプッシュするたびに自動でビルドやテストが走るCIパイプラインを構築できます。例えばGitHubにプッシュするとGitHub Actionsがテストスクリプトを実行したり、CircleCIがビルド・テストを行ったりする、といった具合です。これにより、人手に頼っていた動作確認を自動化し、「動くと思ってデプロイしたら本番でバグが噴出した」という事態を防ぎます。CIの導入によって、開発サイクルごとにユニットテストや統合テストが回るため、問題の検出が早期化し、バグの潜伏期間を短縮できます。実際、手動でのテストやリリース作業を自動化することで開発効率が向上し、コード品質が上がり、リリースのスピードも向上するとされています。開発者にとって煩雑だった反復的作業（ビルドやテスト）が自動化されるため、本来注力すべき機能開発や改善に集中できるというメリットもあります。さらに、継続的インテグレーションによりチーム全員の変更が頻繁に統合されることで、「自分の変更が他人の変更と統合したら動かない」といった統合作業上のバグも早期に発見でき、本番環境にリリースされる前に問題を潰し込むことができます。
3. 継続的デリバリー/デプロイ（CD）による自動化と高速なリリース: CIで品質を担保した後は、継続的デリバリー/デプロイ(CD) の仕組みにより、本番環境へのリリースまでを自動化できます。Gitのブランチ運用と組み合わせれば、ステージング環境で十分に動作確認した上で、メインブランチにマージするだけで本番環境に自動反映、といった運用も可能です。例えば、GitLab CI/CDとホスティングサービスを連携させれば、ステージング環境でテスト済みの最新コードがそのまま本番サーバーにデプロイされます。人手を介さず自動でデプロイされるため、従来のように担当者が深夜帯に待機して「よし、今からアップロード開始…」といった負担は不要になります。デプロイ作業にかかる時間や人的コストが大幅に削減され、リリースサイクルを格段に短縮できます。実際、CI/CDパイプラインを導入するとソフトウェアのデプロイに伴う反復作業の大部分が省力化され、リリースのたびの“お祭り”的な大イベントとそれに伴うリスクが減少します。日々少しずつデプロイする文化に移行すれば、不具合に気付いて解決するまでのスピードも向上し、結果として一度に大量の変更をリリースする場合より問題発生率を下げられるのです。また、自動デプロイ環境では事前に設定した手順通りに本番反映が行われるため、環境ごとの設定ミスや「手順漏れ」によるミスを防止できます。
4. セキュリティとアクセス管理の向上: Git＋SSHでのデプロイでは、パスワードではなく公開鍵認証を用いるのが一般的です。これにより、不正アクセスのリスクが下がり（秘密鍵を持つ認証済みのマシンだけがデプロイ可能）、パスワード漏洩による被害を防げます。また、CI/CD環境では人間が直接サーバーにログインして操作する機会が激減するため、内部不正やヒューマンエラーによる事故が起こりにくくなります。権限管理の面でも、Gitリポジトリのアクセス権限さえ適切に制御すれば、サーバーのFTPアカウントを開放せずに済みます。事実、Gitによるデプロイに切り替えることでFTPポートを閉じて運用でき、サーバーのセキュリティを高められるとの指摘もあります（Git経由ならSSHの既存ポートで完結するため）。さらに、デプロイ履歴やCIのログがすべて記録されるので、不審な変更があった場合も追跡可能です。これはセキュリティ監査上も大きなメリットで、「いつ誰がどのコードをデプロイしたか」を後から検証できるためインシデント対応がスムーズになります。
チーム開発と品質担保への影響
Webディレクター／プロジェクトマネージャー視点
非エンジニアであるWebディレクターやPMにとって、GitとCI/CDを取り入れる最大の利点はプロジェクトの「見える化」とリスク低減です。従来のFTP手動更新では、ある日サイトが不具合を起こしても「何が原因かわからない、担当者に聞かないと…」という状況に陥りがちでした。しかしGitで変更履歴が一元管理されていれば、どのリリースにどんな変更が含まれていたかを容易に把握できるため、問題の原因究明と対応が早まります。これは納期管理や品質管理の観点で非常に重要です。
また、自動デプロイの導入によってヒューマンエラーが減ることは、プロジェクト全体のリスク管理に直結します。例えば、「誤って本番環境にテスト中のファイルをアップしてサイトを停止させてしまった」ような最悪の事態を事前に防げるのです。CIによるテスト自動化で不具合の温床を事前に潰してリリースできる安心感は、ステークホルダーへの説明やクライアント対応でも強みとなるでしょう。さらに、デプロイの高速化はビジネス上のメリットも生みます。新機能のリリースや不具合修正を従来より素早く展開できるため、ユーザー満足度向上や機会損失の削減につながります（不具合を何日も放置しない、マーケットの変化にすぐ対応できる）。高品質なプロダクトを頻繁に想定通りリリースできる体制は、結果としてサービスの信頼性向上と競争力強化につながりますatlassian.com。
Webディレクター/PMにとって重要なのは、こうした最新手法がチームの生産性を飛躍的に高める点です。手作業のデプロイに比べてCI/CDは一度仕組みを構築してしまえば以後の反復作業コストが激減します。開発メンバーがデプロイ作業に煩わされず本来の開発業務に集中できるため、結果としてプロジェクト全体のスピードアップが期待できますqiita.com。実際、「人に依存したプロセス」から「自動化されたプロセス」へ切り替えることで、チームの生産性と士気が上がり、ビジネス要件の変化にも柔軟に対応できるようになるでしょう。
さらに、コードレビューやCIを通じて品質が数段階引き上げられるため、リリース後のトラブル対応に追われる時間が減ります。ディレクターにとっては、常に炎上対応に奔走する状態を脱し、計画通りに施策を展開しやすくなるという効果も見逃せません。総じて、Git＋CI/CDの採用は「開発チームの作業可視化」「ミスの予防」「迅速なリリース」「高品質の維持」に寄与し、プロジェクトマネジメントをより安定かつ効率的にする優れた手段だと言えます。
エンジニア視点
現役エンジニアの立場から見ると、Git・SSH・CI/CDを用いた手法は技術的な信頼性と開発体験(DevEx)の向上に大きく貢献します。まず、Gitによるブランチ運用とプルリクエストベースの開発フローにより、複数人で同時並行開発しても衝突が起きにくくなります。仮に同じファイルを編集してコンフリクトが発生しても、Gitが自動検出してマージ前に解決を促してくれるため、本番環境で知らぬ間に他人の変更を上書きしてしまうといった悲劇は起こりません。エンジニア同士でコードをレビューし合う文化が根付けば、コード品質が飛躍的に向上し、バグの早期発見やスタイル統一、スキル向上（他人のコードを見る学習効果）といった副次効果も得られます。結果として「動くけどメンテナンスしにくいコード」が蔓延することを防ぎ、長期的な開発効率も上がります。
また、自動化されたCI/CDパイプラインにより、エンジニアは手動デプロイの精神的プレッシャーから解放されます。例えば従来、本番反映のたびに「本当にこれで全ファイルアップロードできているか？ミスしていないか？」と神経を尖らせていたものが、CI/CDではボタン一つ（あるいはGitにマージするだけ）で完了します。決まったプロセスが毎回ブレなく実行される安心感があり、デプロイ作業によるストレスや深夜対応から解放されるでしょう。さらに、デプロイの失敗を自動で検知してロールバックする仕組みや、段階的リリース（カナリアリリースやブルーグリーンデプロイ）など高度なデプロイ戦略も取り入れやすくなり、サービス稼働率を保ちながら安全にリリースできます。例えばCapistranoやGitHub Actionsで自動デプロイを組めば、サーバー上で過去リリースとの切り替えもワンコマンドで行えるため、万一の不具合時にも迅速に復旧が可能です。
技術選定の面でも、Git＋CI/CDのワークフローは現代的な開発ツールとの親和性が高い点が魅力です。Issueトラッキングシステム（JiraやBacklogなど）とGitを連携させ、コミットメッセージに課題IDを入れるだけでチケットに変更履歴をリンクさせることもできます。テストフレームワークや静的解析ツールとCIを統合し、プルリク作成時に自動コードチェックを走らせる、といった高度な品質ゲートも容易に実装できます。こうした仕組みはエンジニア自身の作業を助け、「うっかりミスによるCI落ち」があれば本番前に気づけるなど、日常のデプロイミス撲滅に直結します。結果として開発者は安心してリファクタリングや機能追加に挑めるようになり、技術的負債の蓄積を防ぎやすくなります。
最後に、現代的手法への移行はエンジニアコミュニティでのベストプラクティスに乗ることでもあります。GitHubやGitLab上でのコラボレーション、CI/CDの導入は今やソフトウェア開発の標準であり、新人エンジニアの育成や他社との協業においても有利に働きます。エンジニアにとっては、自身の市場価値を高めるスキルセットを日々の業務で磨ける環境とも言えます。逆に旧来的なFTP手動運用に留まっていると、開発プロセス自体がボトルネックとなってサービス改善の速度で競合に劣後する恐れもあります。技術的観点から見ても、GitとCI/CDによる自動化・協調開発は、信頼性・効率・品質の面で従来手法に勝ることは明白であり、エンジニアリング組織として積極的に採用すべき手法だといえます。
まとめ
FTP/SFTPを使った従来型の開発・デプロイ手法と、GitやSSH、CI/CDを活用した現代的手法を比較すると、その差は歴然としています。前者は手軽さゆえに小規模な運用では一見便利ですが、セキュリティリスクやヒューマンエラー、属人化といった問題を常に孕んでいました。後者の手法は初期設定や学習コストこそあるものの、変更履歴の可視化、自動テストとデプロイによる品質保証、チーム全体の生産性向上といった恩恵をもたらし、結果としてプロジェクトの成功率を高めます。
WebディレクターやPMにとっては、現代的手法への移行がプロジェクト進行の「安心材料」となり、納期遵守や品質管理を強力に後押しするでしょう。エンジニアにとっても、煩雑な作業から解放され本来の開発業務に集中できるうえ、最新のDevOpsプラクティスを実践することで技術的成長にもつながります。チーム開発における継続的デリバリーと品質担保の重要性は年々高まっており、旧来のFTP手法に留まり続けることは中長期的に見てリスクでしかありません。もしまだFTPベースの運用を行っているのであれば、段階的にでもGitとCI/CDを導入し、開発フローの近代化を図ることが、組織と製品の健全な成長につながると言えるでしょう。
参考資料: 標準的な開発プロセスの改善による効果は各所で実証されており、たとえばGitLab社の調査ではCI/CD導入によりデプロイ頻度と品質が向上したケースが多数報告されています。また、Atlassian社も「継続的なパラダイムではリリースに伴うリスクが減少し、不具合の発見と解決が迅速化する」ことを指摘しています。今やGitとCI/CDは単なるツールではなく、競争力の源泉となる開発文化です。その優位性を正しく理解し、積極的に活用していくことが求められます。
