運用の昇華

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

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

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

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

品質の向上と言語の壁

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

品質と納期の重要性

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

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

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

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

危険な繁忙化

なぜか忙しくしているPMやリーダーとなるSEがいれば危険信号である。リーダーが忙しくなると全体的な最適化や効率的な運用ができていない可能性がある。結果として、無駄に費用がかかったり、技術的負債が大きくなったりする。

役割分担の歪み

システムのユーザー側から見ると、SEという見え方しかしないと思われるが、実際はシステムの運用や開発には細かな作業分担が発生する。この作業分担ができていない場合は窓口のSEが余計な作業を行っている可能性がある。役割分担の不均衡がもたらす忙しさではなく、まったく仕事としてやらなくてもよいような事に時間を使っていて忙しい場合がある。

プロセスの確立

たとえば、プログラムが解析できる人をリーダーとしてしまうと、開発者に手取り足取り指示をしてしまうことがある。もし、リーダーがプログラムレビューなどの作業や、開発者にプログラム上の細かな指示をしている場合は注意が必要である。何を基準にプログラムレビューや指示を行うのか、という仕事を見える化し、仕組化することがリーダーの務めである。

俯瞰的視点

木を見て森を見ずという言葉があるように、リーダーとなる人は指針を作ったりメンバーをプロジェクト成功へ導く役割がある。リーダーが開発メンバーと同じように木ばかりを見ているようであれば、森を見る人が非エンジニアであるユーザー側となってしまうことが考えられる。

まとめ

誰が森を見るのか、リーダーやPMが常に忙しそうにしている場合は、何に時間を使っているのか調査する必要がある。実はここがボトルネックになっていてプロジェクトの進行が思うようにいかなかったり、頻繁にリスケが発生していることも多くある。しかし、これは本人にヒアリングするだけでは表面化しないため、ユーザー側の担当者やプログラマーなどの周辺人員から浮き彫りにすることが望ましい。

素人仕様と開発遅延

なぜ、システム開発の進捗が悪いのか？
それは、ずばり素人が考えた仕様を開発者に伝えてしまうからである。
すべての原因ではないが、もしシステムのユーザー側の現場担当者や営業担当者がシステム仕様を決めている場合は、ほとんどの場合で満足のいくスピード感はだせていない。

潜む技術的負債

システム仕様さえ伝えていれば、きちんと動くものを作ってくれるので、あとはスピードを上げるだけ。と考えているようであれば、技術的負債が溜まっていることに気付けていない。非エンジニアが決して理解できない技術的負債の怖さは、開発スピードが遅いということだけではない。開発者側から見てシステムが複雑になっていて、メンテナンス性も低い状態になっている。

「できます」の罠

非エンジニアには技術的負債は見えないし説明もわからないことと思う。しかし、技術力でカバーしてくれているから、きちんと動いているのだと思っているなら、それは実は技術力ではない。
「技術的にはできます」このような言葉を聞いたことはないか？
システムエンジニアは「できない」と言えない。「できないことはない」ということが価値なので、素人が考えたシステム仕様でも、言われた通りに作ってしまう。

持続可能な開発へ

システムエンジニアから「技術的にはできます」を聞いたときは、いったん立ち止まるべきである。
エンジニアには、様々な影響範囲や未来のメンテナンス性への懸念などが見えている。これを必要以上のコストだと考えるのか、必要コストと考えるのかで、技術的負債は変わる。

まとめ

自分の理解の範囲でしか人間は発想しないので、システムのことを知らない非エンジニアは、システム仕様を考えるべきではないと言える。また逆に、システムにおいてはシステムエンジニアの方が発想の幅は広いが、業務に関する知識は乏しい。
システムをよく知り業務のこともわかるシステムエンジニアがシステム仕様を考えるべきだが、そんな万能な人は多くはない。だから、その間を取り持つ人間が重要なのである。