Gitコミット履歴が語るオフショア開発の実態

オフショア開発の真実 公開: 2026.03.31 更新: 2026.04.17
#オフショア開発 #品質管理 #ソフトウェア開発

システム改修を依頼された。日本のSIerがベトナムのオフショア企業に開発を委託しているシステムだ。ソースコードの現状を確認しようとGitHubのリポジトリを開き、Git Graphで表示したところ、首をかしげたくなるグラフが表示された。

3ヶ月前に作成されたfeatureブランチが、マージされることなく放置されている。しかも一つや二つではない。すべてのコミット履歴を出力し、AIを使って分析してみた。

放置されたブランチ

feature/fix-sslやfeature/update-upload-contact-typeといったブランチが、作成から3ヶ月以上経過してもマージされていない。さらに不可解なのは、これらのブランチにコミットされたものと同じ内容が、同じ日にdevelopブランチに直接コミットされていたことだ。

おそらく最初はfeatureブランチを作成しプルリクエストを出そうとした。しかし何らかの理由でプルリクエストが処理されず、同じコードをdevelopブランチに直接コミットすることで「解決」したのだろう。Gitの基本的な概念であるマージを理解していないか、適切に運用できていない。バージョン管理ツールが単なるファイル保管庫として使われている。

「fix」「update」だけのコミットメッセージ

初期のコミットメッセージは「fix」「update」だけ。何を修正したのか、何を更新したのかがまったくわからない。

クレームを入れて改善されたのが「Update formula for calculating success rate」のようなメッセージだ。しかしこれでも「計算式を更新した」という事実しか伝えておらず、なぜその更新が必要だったのかは読み取れない。

「update」で始まるメッセージの多さが問題だ。変更の本質を理解せずに、とりあえず動くようにコードを修正している可能性を示唆している。

3ヶ月続く修正の連鎖

ある機能に関する修正が3ヶ月にわたって続いていた。3月19日に「fix: revert logic」、5月21日、22日、6月10日、13日と同じ機能に対する修正が延々と続く。

拡張性を考慮しない実装の典型だ。最初の実装時に将来の変更を想定していないため、新しい要件が追加されるたびに既存コードに手を加え、それが新たな不具合を生む悪循環。実際、要件よりバグの方が多い状況だった。このプロジェクトは当初の納期から6ヶ月以上遅延していた。

コミット履歴は嘘をつかない

Gitのコミット履歴は開発チームの仕事ぶりを如実に物語る。隠しようのない事実の記録だ。

AIにコミットメッセージを分析させたところ、まるで開発工程を見てきたかのように実態を指摘した。プログラミングスキルの問題ではない。ソフトウェア開発プロセスへの理解不足、バージョン管理の重要性に対する認識の欠如、問題解決能力の不足。つまりエンジニアリングの本質が身についていない。

これらは経験によって培われるものだ。経験豊富なエンジニアなら最初から適切な設計を行い、問題が発生しても根本原因を分析して解決する。経験の浅いエンジニアは目の前の問題を取り除くことに終始し、問題を複雑化させる。

オフショア開発の売りである「若い人材」の強みは、AIに取って代わられつつある。AIはベテランエンジニアのコードを学習し、若い人材の柔軟性とベテランの経験を兼ね備え、感情がなく、疲れもストレスも感じない。多言語を理解するため言葉の壁もない。その上、圧倒的に安価だ。


オフショア開発シリーズ:

この記事をシェアする

関連記事