ローコード開発≠安い

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

受託開発契約とその特徴

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

ラボ開発契約とその特徴

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

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

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

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

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

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

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

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

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

ゾンビファイル

今から十数年前に作られたExcelやAccessでのマクロプログラムが今もなお残り続けている。表計算ソフトと呼ばれるデータベースに似たツールを背景にユーザーインターフェースやロジックを付け足したものである。もはやゾンビファイルと言っても過言ではない。これらのシステムは当初の目的を果たしていても、時代の変化とともに保守性や拡張性に大きな課題を抱えるようになっている。

作成者不明問題

社内に残る通称「マクロ」は、今はいない人が作成していたり、一部の人が独自に作ったものであることが多くある。作った人がいる場合はまだしも、退職している場合はその中のプログラムも見ることができないので、いつ止まるか分からないシステムを業務の中心で使い続けていくことになる。このような状況では、エラーが発生した際の対処法が不明で、業務継続に深刻なリスクをもたらす可能性がある。

市民開発解決法

ブラックボックス化したマクロを情報システム部に解決をお願いするのではなく、市民開発にて解決するには多少のコツが必要になる。ポイントは完全にブラックボックス化している状態や、何から手を付けていいか分からない状態のマクロ群は、残念ながらまずは専門家に情報の整理を依頼することが必要になるだろう。自社だけでの解決を試みる前に、適切な専門知識を持つパートナーとの連携を検討することが成功への近道となる。

専門家活用法

専門家に依頼したほうがいい理由として、マクロファイルの解析だけを切り離した作業としてしまうと、その後の市民開発へ繋ぎにくくなるからである。マクロファイルのインプット／アウトプットを解析した上で、それをどのように今後の市民開発のベース作りに活かすのか。ITコンサルやシステム開発会社の腕の見せどころである。単純な解析作業ではなく、将来的な発展性を見据えた戦略的なアプローチが求められる領域といえるだろう。

まとめ

ExcelやAccessはMicrosoft社の製品であるので、そのままMicrosoft社が提供するPower PlatformやPower Appsへの移行がスマートである。間違ってもマクロをスクラッチ開発でのWebシステムに移管すべきではない。親和性の問題や閲覧性などに課題がのこることが多いようである。

投資と競争力

バックヤードのシステム開発は収益と直接結びつかないため、できるだけケチりたいものである。にもかかわらず、バックヤードのデジタル化には大きなコストがかかる。しかし、新しいインフラに適切な投資ができない企業は競争力を失うのである。

要件定義の罠

バックヤードのシステムをできるだけ安く抑えようと思うと、要求定義や要件定義をしっかり作って依頼すればよいと考えがちである。もちろん、間違ってはいないが、入り口が安くなるわりに、システム開発の途中で追加工数が発生してしまい、結果としてシステムが高くなってしまうのである。

未来志向の要求

システム開発の途中で追加予算がかかってしまうのは、最初の要求定義や要件定義のときに想定される未来が見えていないことが原因である。これを見通すには要求定義や要件定義を行う背景や、未来の目指すところまでをエンジニア出身のアナリストに情報共有しなければならない。

投資の真価

導入時の金額だけをケチることは、保守運用などのランニングコストに跳ね返ってきてしまい、システムの寿命が短くなる。そうならないために、第三者のIT業者やITコンサルタントを入れるほうがよいと言われている。うまくDX化できれば生産性が上がり、投資を大きく回収できる。ことIT投資については、竹槍戦か空中戦かくらいの違いを生んでしまうのである。

まとめ

システム設計やプログラミング作業と同じようにITコンサルタントも1人の能力に偏りがちである。それゆえ、PMOと呼ばれるチームを形成することで、集合知を活用して、さらに未来を予測できるような体制を構築することが望ましい。