思考と決断のPM力

危険な繁忙化

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

役割分担の歪み

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

プロセスの確立

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

俯瞰的視点

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

まとめ

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

DX化の現状

多くの企業でExcel業務のDX化が話題になっている。「Excelは古い」「すぐにシステム化すべき」という声も聞かれるが、本当にすべてのExcel業務をDX化すべきなのだろうか。実は、やみくもなDX化は逆効果になることも少なくない。Excel業務のDX化には正しい順序と判断基準が必要である。本記事では、DX化の利点を理解しながら、適切なアプローチについて考えていく。

DX化の利点

Excel業務をDX化することで得られる利点は確かに多数ある。まず、データの一元管理により情報の正確性が向上し、複数人での同時編集や更新作業がスムーズになる。次に、自動化による作業時間の大幅な削減が可能である。手作業で行っていた集計や転記作業から解放されることで、より付加価値の高い業務に時間を使えるようになる。さらに、データ分析の高度化により、経営判断のスピードと精度が向上する。これらの利点は、企業の競争力強化に直結する重要な要素である。

DX化の落とし穴

しかし、DX化を急ぐあまり失敗するケースも多く見られる。業務フローが整理されていない状態でシステムを導入すると、非効率な業務がそのままシステム化されてしまう。また、現場の声を聞かずにツールを選定すると、使いにくいシステムが現場に定着せず、結局Excelに戻ってしまうこともある。さらに、すべてを一度に変えようとすると、従業員の負担が大きくなり、業務が混乱する。投資したコストに見合う効果が得られず、DX化自体が目的化してしまう危険性もある。適切な準備なしのDX化は、かえって生産性を下げる結果を招くのである。

正しい進め方

Excel業務のDX化を成功させるには、段階的なアプローチが不可欠である。まず、現状の業務フローを可視化し、本当に必要な作業とムダな作業を明確に区別する。次に、Excelで十分な業務と、システム化すべき業務を見極めることが重要である。すべてをシステム化する必要はない。その上で、優先順位をつけて小さく始め、効果を確認しながら展開していく。従業員のITリテラシーに応じた教育も並行して行うことで、スムーズな移行が実現する。DX化は手段であり目的ではない。自社の状況に合わせた最適な方法を選ぶことが、真の業務改善につながるのである。

まとめ

Excel業務のDX化は、正しく進めれば大きな効果をもたらすが、順序を誤ると逆効果になる。利点を理解しつつ、自社の状況を冷静に分析し、段階的に進めることが成功の鍵である。やみくもなシステム化ではなく、業務改善を第一に考えた戦略的なアプローチを取るべきである。

オフショア開発の新たな展開とブリッジエンジニアの必要性

現在、日本企業がベトナムを含む海外の開発会社と協力してオフショア開発を行う流れが増えています。過去10年間で、ベトナム自体が珍しい存在ではなくなり、海外の開発会社がプロジェクトに参加するのは当たり前の状況となりました。 しかし、この状況下で単に「人件費の安いベトナム」に発注するというコストダウンの視点では、現在の状況には適していないのが実情です。 もしコストカットが目的であれば、システム開発ではなく、比較的単純で反復的な業務を対象とするBPOを検討すべきです。

言語と文化の壁を乗り越えるブリッジエンジニアの役割

それでは、BPOではないシステム開発においてはどのようなアプローチが求められるのでしょうか？その答えは、ブリッジエンジニアを用意することです。ブリッジエンジニアは、日本語とベトナム語の両方を使いこなせるソフトウェアエンジニアであり、コミュニケーターとも称されます。彼らは言葉の問題だけでなく、仕事のやり方や文化の違いによる課題をブリッジする必要があります。

例えば、日本のソフトウェア開発では受託開発が一般的であり、開発プロジェクトの進捗管理においては報連相が重視されます。また、ボトムアップ型のアプローチが好まれ、開発現場の個々の創意工夫や意見が重要視されます。しかし、ベトナムにおける受託開発は成果物の完成を約束する契約であり（日本の受託開発も契約上はこうなのですが）、成果物の進捗について日本の発注元から頻繁に報告を求められることに対してベトナムの開発者は反発を感じることがあります。また、指示命令がはっきりしているベトナムの組織では、開発現場において意見を求めつつも、その結果に責任を開発現場に求める日本のマネジメントスタイルは、無責任に映ることもあるかもしれません。

ブリッジエンジニアの役割とスキル要件

こうした課題を乗り越えるためには、ブリッジエンジニアの存在が不可欠です。彼らは単なる言語の通訳だけでなく、両国の開発文化の違いを理解し、適切なコミュニケーションを取る能力を持っています。ブリッジエンジニアは、日本のソフトウェア開発の特徴や要件を正確に把握し、ベトナムの開発者に伝えることで、円滑な連携を実現します。彼らは言葉や文化の壁を乗り越え、双方の開発チームを結びつけ、プロジェクトの成果を最大化する役割を果たすのです。

ブリッジエンジニアには、ソフトウェア開発の知識や技術力に加えて、優れたコミュニケーション能力や対人スキルが求められます。彼らは単に言葉を通訳するだけでなく、双方の文化や仕事のやり方を理解し、適切な形で情報を伝える必要があります。また、柔軟性と問題解決能力も重要です。彼らは状況に応じて適切な対応を取り、課題を解決するための努力を惜しまない必要があります。

結論

ベトナムオフショア開発において、ブリッジエンジニアは非常に重要な存在です。彼らの存在は単なるコストダウンだけでなく、効果的なシステム開発を実現するために不可欠です。ただし、ブリッジエンジニアの人件費は安くなく、市場には数が限られています。多くの日系開発企業が、優れたブリッジエンジニアを最重要の人的資源として確保しているためです。そのため、ベトナムオフショア開発は必ずしも安価ではありません。ブリッジエンジニアの重要性を理解し、適切な人材を配置することで、プロジェクトの成功につなげることが求められます。