オフショアでのシステム開発において不可欠な役割を担うITコミュニケーターは、その所属する企業によりプロジェクトの効率や成果に大きな影響を及ぼす可能性があります。この事実を知る人は少ないかもしれません。しかし、ITコミュニケーターは決して単なる通訳者ではなく、プロジェクトの全体的な流れを理解し、その中で意思疎通を効率的に行う役割を持っています。彼らは機械ではなく、感情や偏見を持つ人間であり、それぞれのプロジェクト状況に対する見解や判断には個々の視点や考え方が反映されることがあります。
目次 [非表示]
コミュニケーションロスの最小化
ITコミュニケーターが関わる情報の伝達での欠落を防ぐためには、対話を強化し続けることが重要となります。特にオフショア開発においては、オフショア先のプロジェクトマネージャーとのコミュニケーションの強化が必須と言えます。相互理解を深め、プロジェクト全体の理解を共有するため、定期的なミーティングや報告の他、プロジェクトの目標について明確に伝え、それを共有することも大切です。
また、専門的な懸念点や問題点に対してITコミュニケーターが完全に理解できなかった場合、コミュニケーションロスが生じる可能性があります。これを防ぐためには、ITコミュニケーターが適切なフィードバックや提案を行うことが求められます。その結果、問題点が早期に発見され、プロジェクト全体の効率性と成果に寄与します。
プロジェクトオーナーの役割や責任をITコミュニケーターが十分に理解しているか再確認することも効果的な手段となります。ITコミュニケーターがプロジェクトオーナーの役割や責任を理解していると、プロジェクト全体のバランスまで知ってもらうことができます。プロジェクトオーナーはシステムの開発側だけでなく、システムユーザーを含めた全体の利益を考慮して判断を下しているからです。
選べるオフショア開発の形態
オフショア開発の形態には、以下の3つが一般的です。
- 完全請負型（フルアウトソーシング）：プロジェクト全体をオフショア開発会社に委ねます。発注側は結果のみを見ます。
- スタッフオーガメンテーション（リソース提供型、ラボ型）：発注側が必要なスキルや人数を指定し、オフショア開発会社がそれに応じたメンバーを提供します。プロジェクト管理は発注側が担当します。
- 専門サービス提供型（Managed Services）：特定のサービスや機能をオフショア開発会社に任せます。発注側はそのサービスの品質や成果を評価します。
オフショア開発の形態を選ぶ際には、プロジェクトの要求や目標、そしてチームのスキルと経験を考慮することが重要です。ITコミュニケーターの役割は、これらの形態によって変わるかもしれませんが、いずれにしてもプロジェクト初期段階から参画させておくことが推奨されます。
ITコミュニケーターの所属は
「開発会社」or「ユーザー側（発注者）」
開発会社に所属するITコミュニケーターは、その会社の技術的な専門知識やプロジェクト管理方法に精通しています。彼らは開発者の視点からプロジェクトを理解し、技術的な課題を明確に伝える役割を果たします。一方、ユーザー側（システム発注者側）に所属するITコミュニケーターは、発注者のビジネス要件や利益を最優先に考慮します。彼らは、発注者の視点からプロジェクトを理解し、ビジネス要件を開発会社に明確に伝える役割を果たします。
ITコミュニケーターに幅広くビジネス面で動いてもらう場合は、自社のBA（ビジネスアナリスト）として、ITコミュニケーターを置いておくのもよいでしょう。
システムのブラックボックスができるわけ
システム発注者である依頼者は「言ったこと」をやってくれるのが一番いいのですが、開発者側から見れば将来のリスクと引き換えに「言ったこと」に対応せざるを得ない場面も多くあります。依頼者は、専門的なシステムのことが見えないことも多くありますので、開発者側の説明を正として聞くしかありません。しかし、専門家の言葉をそのまま鵜呑みにしているとブラックボックス部分が増えていき、最後に取り返しのつかない状況になることも考えられます。
しかも、これは一部ですでに起こっています。「2025年の崖」と言われる一つの原因です。
ブラックボックスでの作業が増えた結果、誰も手をつけられない状況のシステムが多く残ってしまっているのです。
すでにシステム会社の中でババ抜きが始まっているかもしれません。お金を出せば解決できる問題であればいいのですが、妥当な金額がいくらかさえ想像もできない状態であれば尚更です。逆に複雑性はなく定性化、定量化して説明できることに対しては、お金で解決が可能です。
日本人は数字に厳格であるため、定量化定性化できないものをジャッジするのは苦手とされており、特にシステム開発となると、完全なるITに対して無知の状態ではブラックボックスであるシステムに投資しようがないのです。
準委任契約やオンサイト（月々）の委任契約というのは、システム会社がリスクを回避するためのひとつです。開発会社が請け負うことができない、つまり責任を取れない状況になっている場合は作業を請け負う契約にしたいと考えます。ルーチンワークであれば問題なかったのですが、世はDXが叫ばれる時代です。もしお金を払って改善できるのであれば、吹っかけられた金額で責任を持ってくれるようであれば救いの神であるかもしれません。
オフショア開発というけれど
コミュニケーションのハブとなるITコミュニケーターを単なる翻訳者として参画させていると思わぬ落とし穴が待っています。金額だけなら、ということでオフショア開発を使うと言っても、円安が進んだ今、海外の企業も案件を選ぶ状況にあります。安いと思って見つけたオフショア開発の会社と一緒に開発を進めて失敗したという日本企業は数知れず。また、前述のブラックボックスは日本国内企業、ベトナム企業に関わらず発生します。
労働人口減少傾向にある日本で、もはや待ったなし！海外で作るか作らないかではなく、日本に技術者がいない以上、優秀なIT人材が豊富な海外企業とのパートナーシップを組んでいくという選択肢しかないのかもしれません。爆発寸前のシステムに立ち向かう勇者に出会うことを期待したいところです。
BA（ビジネスアナリスト）としてのITコミュニケーター
さて、オフショア開発会社と一緒にシステムをリプレイスするぞ、と意気込んでも言葉の壁があります。そこで、ITコミュニケーターが登場するわけですが、当然にシステム開発会社側にいます。コミュニケーションを司る重要なポジションすらも相手が持っています。システム開発の請負会社に所属するITコミュニケーターは当然ながら、開発会社の利益と目標に注力した上で、プロジェクトの成功を目指します。開発会社側のチームとコミュニケーションが密であり、開発プロセスや技術的な課題には詳しいといえます。
そこで、もしシステム発注者の利益と目標に注力し、プロジェクトの成功を目指すITコミュニケーターがビジネスサイドにいたらどうでしょうか。システム発注者側の要求やニーズに詳しく、発注者側のビジネス要件や利益を最優先に考慮し行動してくれます。
いざ、オフショア開発を始めよう。あるいは、これまで失敗ばかりしてきたプロジェクトオーナーがいれば、まずシステム開発の請負会社に所属するITコミュニケーターと、システム発注者側に所属するITコミュニケーターのスタンスの違いを知っておくことが重要です。
まとめ
ITコミュニケーターを開発会社に任せたままになっていませんか？
自社で翻訳者としてITコミュニケーターを持つというよりは、テスターやプロジェクト管理など、オフショア開発のベンダー管理者、つまりBA（ビジネスアナリスト）を置いておくことで、ベトナム開発企業の能力を100%引き出すことが可能になるかも知れません。
今回はITコミュニケーターをBAとして活躍させたほうがいい背景についてご紹介しました。
DXを進めるにあたってベトナム企業をどれだけうまく活用できるかが、生産性に大きな影響を与えるのではないでしょうか。
アタラキシアDX株式会社では、ITコミュニケーター（COMTOR）の派遣、育成、支援を行っています。
効率的なシステム開発や、あらゆる技術を利用した企業のDX化、新規事業におけるITのことなら何でもご相談ください！
