オフショア開発の現場で何が起きているのか - あるGitリポジトリの分析から

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

3ヶ月前に作成されたfeatureブランチが、マージされることなく放置されている。 しかも一つや二つではありません。 これは一体どういうことなのか。 プロジェクトの全体像を把握するため、すべてのコミット履歴を出力し、AIを使って分析してみることにしました。

その結果、オフショア開発の現場で実際に何が起きているのか、生々しい実態が浮かび上がってきたのです。

放置されたブランチが物語るもの

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

なぜこのような運用になっているのか。 コミット履歴を追っていくと、ある仮説が浮かび上がりました。 おそらく最初はfeatureブランチを作成し、プルリクエストを出すという正しい手順を踏もうとしたのでしょう。 しかし何らかの理由でプルリクエストが処理されず、結局は同じコードをdevelopブランチに直接コミットすることで「解決」したのです。

これはGitの基本的な概念であるマージを理解していないか、あるいは理解していても適切に運用できていないことを示しています。 バージョン管理ツールが単なるファイル保管庫として使われているのです。

コミットメッセージが語る開発の質

次に注目したのはコミットメッセージです。 初期のコミットメッセージは”fix”、“update”といった単語だけの非常にシンプルなものでした。 何を修正したのか、何を更新したのかがまったく分かりません。

途中でこのようなコミットメッセージでは何をしたのか分からないとクレームを入れて改善されたのが、 “Update formula for calculating success rate”、“Update logic find element on form”といったメッセージです。 これでも「計算式を更新した」「フォームの要素を見つけるロジックを更新した」という事実しか伝えておらず、 なぜその更新が必要だったのか、どのような問題を解決したのかは読み取れません。

さらに問題なのは、“Update”で始まるメッセージの多さです。 updateという言葉は「更新した」という事実を述べているだけで、具体的な情報を何も伝えていません。 これは開発者が変更の本質を理解せずに、とりあえず動くようにコードを修正している可能性を示唆しています。

3ヶ月続く修正の連鎖

もう一つ気になったのは、ある機能に関する修正が3ヶ月にわたって続いていたことです。 3月19日に”fix: revert logic”というコミットがあり、これは一度実装したロジックを元に戻したことを意味します。 その後、5月21日、5月22日、6月10日、6月13日と、同じ機能に対する修正が延々と続いています。

これは拡張性を考慮しない実装によく見られる典型例ではないでしょうか。 最初の実装時に将来の変更を想定していないため、新しい要件が追加されるたびに既存のコードに手を加え、 それが新たな不具合を生むという悪循環に陥っているのです。 実際、要件よりもバグの方が多いという笑えない状況でした。

実際、このプロジェクトは当初の納期から6ヶ月以上遅延しているとのことでした。

オフショア開発の現実

「若い優秀なエンジニアが豊富」「コスト削減が可能」といったオフショア開発の売り文句をよく耳にします。 確かにそれは一面の真実かもしれません。 しかし、若いということは経験が浅いということでもあります。

今回の分析で明らかになったのは、プログラミングスキルの問題ではありません。 むしろ問題なのは、ソフトウェア開発プロセスへの理解不足、 バージョン管理の重要性に対する認識の欠如、そして問題解決能力の不足です。

つまり、エンジニアリングの本質が身についていない、ということです。

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

おわりに

Gitのコミット履歴は、開発チームの仕事ぶりを如実に物語ります。 それは隠しようのない事実の記録です。 今回の分析を通じて見えてきたのは、オフショア開発における品質管理の難しさと、経験不足がもたらすリスクの大きさでした。

個人的な感想ですが、コミットメッセージからAIがまるで開発工程を見てきたかのように分析したことに驚きを感じ得ませんでした。 AIの優秀さとともに、コミットメッセージの重要さに改めて気づかされました。

ここで一つ、考えさせられることがあります。

情報技術は、労働集約型の情報処理を自動化するために発達してきました。 プログラミングやシステム開発もその最たる例です。 そして今、これまで自動化は不可能と言われていた工程の自動化を実現しつつあるのがAIです。

つまり、オフショア開発の売りである「若い人材」の強みは、AIに取って代わられつつあるのです。 なぜならAIはベテランエンジニアのコードを学習していますから、 若い人材の柔軟性とベテラン人材の経験という双方の強みを持ち、おまけに感情がなく、 身体を持たず、疲れもストレスも感じません。 人間の弱みがないのです。

おまけに多言語を理解するため、言葉の壁もありません。

その上、オフショアと比較しても、圧倒的に安価なのです！

もちろん、オフショア開発そのものを否定するつもりはありません。 優秀なオフショア開発チームも存在するでしょう。

しかし、現在のオフショア開発の多くが抱える問題は、日本側の管理者が設計能力を持たず、 オフショア側は詳細設計以降しか担当できないという構造的な欠陥にあります。 この状況で要件定義からデプロイまでを受託すれば、品質問題や納期遅延は必然的に発生します。

今後のシステム開発を考える際は、単純な人件費の比較だけでなく、開発プロセス全体の設計能力、 そして急速に進化するAI技術の活用も含めて、総合的に判断することが重要ではないでしょうか。