開発費用値下げの危険性

IT報酬の実態

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

導入時の誤解

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

システムと医療

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

真のIT人材価値

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

まとめ

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

オフショア開発には、受託開発、ラボ開発、そして折衷型の3つの契約形態が存在します。それぞれの契約形態には特徴と課題がありますが、最終的にここで「折衷型」と述べているものに集約していく傾向があります。

受託開発契約とその特徴

受託開発契約は、成果物の納品を約束する契約形態です。この形態では、事前に成果物の定義を明確にし、それに基づいて開発を進めます。受託開発契約はソフトウェア開発においてシンプルな形態と言えますが、成果物の定義を明確にすることは容易ではありません。実際の開発作業では、概念上の定義と現実の制約との間で調整が必要となる場合があります。

ラボ開発契約とその特徴

ラボ開発契約は、クライアントが直接開発者に対して指示を出す契約形態です。クライアントは開発者を拘束し、その時間を購入します。この形態は、日本のSES契約に近いものですが、ラボ開発では開発者は非常駐となります。時間単位で開発者の貢献を購入するため、時間の品質によって成果物の品質が保証されるわけではありません。開発者によって同じ時間内でも成果物の差が生じることがあります。

折衷型契約の意義とその特徴

折衷型契約は受託開発契約とラボ開発契約の折衷案として採用されます。この契約形態では、成果物の定義を柔軟にし、一定の作業時間も確保しながら、基本的にボトムアップ型で開発を進めていきます。オフショア開発においては、ビジネスモデルやクライアントの要求を理解し、中核的な開発人材（例えば、ブリッジエンジニア）を確保することが重要です。中核的な人材はクライアントのビジネスについて深い洞察を持ち、長期的な関係を築くことができます。このような中核人材をラボ契約で時間拘束的に確保し、プロジェクトが大型化したときはスポットで追加の受託契約を行い、人を追加で確保するというものです。

折衷案に収斂していく実際のプロジェクト

受託開発としてスタートしたプロジェクトでも、ラボ開発としてスタートしたプロジェクトでも、ベトナムでのオフショア開発が成功し長く続いている案件は、最終的に折衷案に収斂していく傾向があるようです。多くの場合は海外開発拠点は、日本の開発プロジェクトの外付け工場という位置づけになりますので、クライアントのビジネスをよく知った開発者を確保しつつスケーラビリティを確保するという両方が求められることとなり、このような形に落ち着くのでしょう。

もしこの形をゴールとするのならば、下記の2点に注目するのが良いでしょう。

(a) 長期契約が必要なこと：クライアントのビジネスモデルや独自の用語を理解し、本当に重要な要素を把握するためには時間が必要です。クライアントのビジネスに寄り添いながら開発を行うためには、最低でも1年以上の長期契約が必要です。

(b) ブリッジエンジニアを始めとする中核的人材の確保が大切であること：中核的な開発人材は、クライアントのビジネスをよく理解し、ビジネスの要件に応じて開発を進めることができる人材です。彼らは長期的なパートナーシップを築き、クライアントのビジネス成果に貢献します。そのため、オフショア開発においては、ブリッジエンジニアなどの中核的な人材の確保が極めて重要です。

オフショア開発においては、契約形態の選択とビジネス戦略の統合が成功の鍵となります。ビジネスの長期的な視点と中核的な人材の確保を重視することで、効果的なオフショア開発を実現することができるでしょう。

開発の相場観

相場とは、一般的に市場で競争売買によって決まる商品の価格とされているが、ことシステム開発においては、相場というものが存在しない。

比較の難しさ

比較できる同じものであれば競争原理が働き相場が構築されるが、フルスクラッチされるシステム開発においては全く同じものができることはない。しかも、出来上がるものはパッケージシステムやSaaSの利用以外は、未来にしか完成しないので当然比較もできないものとなる。

将来要件判断

比較的ないからこそ、しっかりと吟味する必要があるが、吟味する材料や条件などは現時点で明確になるものが元となる。未来に発生する追加条件や変更される環境などはジャッジする時点にはすべて出そろわないという難しさがある。

変化への対応

システム開発は未来にどのような条件変更やルール変更が行われるかわからないものであるという認識を持つことが大切である。その上で最善のジャッジを行うべきである。その判断は過去を遡って正解か間違いかを評価すべきではない。

まとめ

日本では原点方式の人事評価が行われるため、イノベーションは起こりにくい本質的な問題がある。これを無視して「DXだ」といっている組織があるとすれば、それは本質を見誤っているといえる。