相場の不在

内製化の壁

システムの内製化が重要ということは、どこでも聞くと思う。しかし、具体的に内製化していくための段取りを整理して教えてもらうのは難しいのかもしれない。業種業態によって様々なケースが存在するからである。内製化を成功させるには、単に技術的な知識だけでなく、組織全体での戦略的な取り組みが不可欠となる。

経営コミット

システム開発の内製化を行っていくには、まず経営層からのコミットメントが必要不可欠である。これが必要であるから諸外国ではCRO（Chief-Revenue-Officer）という部門を横断した権限を持つ人を据えている。その上で、まず内製化の目的を明確にする。おおむねコスト削減、スピード向上、ナレッジ蓄積などであろう。目的がきまると、企画、開発、保守、インフラなどのどの範囲で内製化するのが見えてくる。組織全体での合意形成が内製化成功の基盤となるのである。

失敗回避策

よく聞く失敗例では、権限のないIT戦略室、デジタル推進部などを作ってしまうことである。あるいは、適切な人員の配置や育成がなされないパターンも同様である。大きな権限を持つことになることを前提に考えると、実施するプロジェクトについても小さなプロジェクトにおいて実績を積み上げたほうがいいだろう。たとえば、小規模低リスクである業務改善ツール（例：Power AppsやExcelマクロ）から市民開発を実施していくなどを計画することをお勧めする。段階的なアプローチが組織の信頼獲得につながる。

仕組み化

小さなプロジェクトで実績を積むと、こなれてきてしまうため、やはり属人化の危険性が伴う。ここで、いかに永続的に考えることができるか、内製化のための仕組みを構築できるかは、システム開発経験者などの知見のある人も交えて人材育成に取り組むべきである。定期的な振り返り（レトロスペクティブ）やナレッジ共有会、現場からの改善提案を吸い上げる文化を育て、仕組化していく。持続可能な内製化には組織文化の変革が欠かせない。

まとめ

開発基盤とガバナンス整備、ソース管理やドキュメント管理などの定性的な内製化は簡単に作ることができる。しかし、そのマインドや仕組み、自然とDevOpsをはじめとしたPDCAサイクルにもっていくには、システム知見だけでも難しくある。持続的な内製化にたどり着くためには最初の企画や構成段階で知見をもつメンバーを入れておくのがよいだろう。

失敗の正体

システムの失敗は見えないことがある。ブラックボックスであるがゆえに隠せてしまうからである。失敗かどうかの線引きができないところがシステム構築プロジェクトの難しいところである。

エンジニアの真実

もしかしたら、エンジニアが都合の悪いことは隠していることがあるかもしれない。しかし、決めつけてしまうとエンジニアはへそを曲げてしまう可能性がある。隠しているつもりはなくても隠れていることもある。

成功の境界

失敗の線引きは、納期が遅れることであろうか。バグが多いということであろうか。実は、状況によって一概に言えないのである。QCDという言葉があるが、品質と費用と納期のバランスを上手にとったとしても成功か失敗か、すぐにはわからないのがシステムという無形物である。

コスパの本質

コスパという言葉があるが、かけるコストに対して、どれだけのパフォーマンスが出せるかが問題となる。システム開発では、コストからやりたいことを計算するのではなく、やりたいことを明確にしたうえで、コスト内でリッチ度合いを調節することが重要である。

まとめ

システム開発においては、失敗が見えにくいため、失敗しないように見えるのかもしれない。失敗しないことは、成功であるということでもない。時間が経つにつれて失敗を感じることもあり得るのである。

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

受託開発契約とその特徴

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

ラボ開発契約とその特徴

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

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

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

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

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

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

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

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

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