オフショア開発の変遷と現状

オフショア開発のコストダウン目的

オフショア開発における主要な目的は、プロジェクトの総コストを削減するために人件費を削減することです。日本の開発者の人件費が高いため、ベトナムの開発者と置き換えることで財務的なコストダウンを実現してきました。ただし、外国に発注するということは、品質の低さと言葉の壁という2つの問題がつねにつきまといます。

内部コストと労働者の負担

人件費の削減は財務上のコストダウン効果を直接的に実現しますが、品質の低さや言葉の壁といった問題は現場の労働時間や精神的な負担として現れる内部コストです。これらの内部コストは労働者に転嫁され、営業側が値引きを行い開発現場の労働に影響を与える仕組みとなっています。オフショア開発に対する開発現場からの評判の悪さは、このような直接的な感覚から生じていると考えられます。

品質の向上と言語の壁

品質の低さや言葉の壁は改善の兆しを見せています。20年前と比較すると、通信手段や開発ツールが進歩しました。チャットやビデオ会議、画面共有などの技術が利用できるようになりました。また、クラウドやソースコードの共有などの管理システムも進化しました。言語の壁も同様で、ベトナムにおける日本語の理解力や日本人における英語の能力は向上しています。さらに、機械翻訳の進歩により、外国語を交えながら技術的な会話が容易になりました。

品質と納期の重要性

オフショア開発において品質と納期は重要な要素です。納期を守り、仕様を満たすことが最終的な評価基準となります。優れた開発チームやツールの活用は重要ですが、納期の達成と仕様の達成が果たされなければ、プロジェクトは失敗となります。

新たなオフショア開発の戦略

オフショア開発におけるコストダウンの戦略は、技術の進歩を活用する方向に進んでいます。開発手法として、ウォーターフォール型ではなくジャイルやOSS的な手法を導入することが求められています。また、国際的な標準的なツールやバージョン管理などの利用も重要です。さらに、コミュニケーションの円滑化も不可欠です。言葉の問題だけでなく、コミュニケーションの円滑化は人間によって担保されます。

オフショア開発の変遷において、品質やコミュニケーションの改善は見られますが、人件費の差によるコストダウンは限界に近づいています。技術の進歩を取り入れた新たな戦略の導入により、より効果的なオフショア開発を実現することができるでしょう。

関連記事

生成AIは使えない?

思い通りにならない理由

生成AIを導入したのに思ったような結果が得られない――そんな経験をしたことがある人も多いだろう。AIは進化を続けているが、それを使いこなす側にも試行錯誤が求められている。特に企業においては、社内情報を整理すればするほど目的の答えに辿り着けなくなる「RAGの沼」にハマることがある。多くの企業が生成AIを武器にしようとしているが、その真価を引き出すには、正しい導入と運用が欠かせない。

RAGとは何か

RAG(Retrieval-Augmented Generation)は、「検索」「拡張」「生成」の頭文字を取った技術であり、生成AIに独自情報を与えることで回答の精度を上げる手法である。インターネット上の情報だけでなく、社内マニュアルや業務データなどを取り込むことで、より業務に即した回答が可能になる。ただし、期待する結果が得られない場合、その原因は提供リソースの質や構造にある可能性が高い。

ChatGPT以外の選択肢

現在、生成AIとして多くの大規模言語モデル(LLM)が存在する。OpenAIのChatGPTをはじめ、AnthropicのClaude、GoogleのGemini、MetaのLLaMA、Mistral、Cohere、さらにAlibabaやBaiduといった中国系ベンダーもある。それぞれに強みがあり、RAGに適したモデルも存在する。たとえばCohereのCommand R+やMistralのMixtralなどが代表的だ。目的に応じてLLMを選び、最適な環境を整えることが重要である。

社内AIを成功させるには

セキュリティ上の理由から、社内情報をインターネットに出せない企業も少なくない。その場合、オンプレミス環境(社内ローカル)に生成AIを構築する選択肢がある。たとえばTinyLLaMAやPhi-2のような軽量モデルから、Nous HermesやMixtralなどの対話・RAG対応モデルまで選択肢は豊富だ。これらを活用すれば、外部にデータを出さずともAIの恩恵を享受できる。必要なのは、自社の目的と環境に適した判断力である。

まとめ

生成AIはあくまで「道具」にすぎない。導入しただけで目的が自動的に達成されるわけではない。課題を定義し、適切な情報を整備し、それを使いこなす力が必要だ。RAGがうまくいかないと感じたら、その原因はリソースや設計のミスマッチにあるかもしれない。

続きを見る >

運用の昇華

開発現場の想定外

基幹システムの開発現場では、最初に想定した仕様とは異なる業務フローが後から発覚することが多い。

マネジメントの試金石

後から発覚した業務フローは、すでに構築が進んでいるシステムに組み込むことが難しいため、どのように対応するかがプロジェクトマネージャーの腕の見せ所である。

プロジェクトの舵取り

プロジェクトマネージャーとは何かと問われたときに、一言で言い表すならば、不測の事態にどのように対応できるか、ということではないかと考える。プロジェクトが何の問題もなく、完遂できることは少ない。したがって、イレギュラーケースが発生した時にどのような手立てを打てるか、迅速に行動できるかがプロジェクトマネージャーのレベルとなる。

パートナーシップの重要性

プロジェクトマネージャーがシステムの完成しか考えていなければ、途中から発覚した仕様は「運用でカバーせよ」とユーザー側に責任を押し付けてしまうことがある。しかし、より良いシステムを目指す、パートナーとしてであればこの回答は好ましくない。

まとめ

どのような事象がきっかけで、途中で使用漏れが発覚したのか、プロジェクトの進行状況を見ながら、ひも解くことが重要である。運用でカバーというユーザー側だけにだけ負担をさせるのではなく、運用をカバーするようなシステムを構築できるのが理想である。

続きを見る >

内製化の成功術

IT報酬の実態

海外と比べて日本のITエンジニアの報酬が低いという記事をよく目にする。それもそのはずで、ハイクラスIT人材は都合のいい「何でも屋」にはならないからである。

導入時の誤解

ユーザー企業やシステムのユーザーは、IT化を行うことで業務が減るという先入観を持っていることがある。システム導入を着手したときの目的を忘れて、その時、その場の課題を優先して都合よくITエンジニアを動かしてしまう。また動くITエンジニアもそこにいたりする。

システムと医療

たとえば、「お腹が痛い」と病院にいって「すぐに切開しよう」とはならないはずだ。このようにシステムにもその他にも色々な条件が絡まり合っている。システムは取り扱う情報量や関連する業務が多く導入に時間がかかる。時間がかかる結果、最初の導入目的を忘れてしまうのである。

真のIT人材価値

ハイクラスIT人材はユーザー側の状況と心理を配慮しつつ、現場のプログラマーの状況と心理を考慮して陣頭指揮できる人材といってもよいだろう。心理というのは物の言い方だけではなく、無形の財産を構築したり業務にフィットさせたりするので、プロジェクトの円滑さが変わるのだ。

まとめ

小手先だけでシステムに関するプロジェクトを推進しようとすると、「言われた通りにやった」という受動的な参加者が増えてしまう。情シスのSIer化を回避するにはITエンジニアを「何でも屋」にさせて疲弊させないことも大切である。開発チームの雰囲気作りも非常に効果がある。

続きを見る >