効率化の誤解

目標設定の要諦

SESと呼ばれる派遣や準委任契約では、プロジェクトを完遂することが難しいとしている。これはゴールが未設定であったり、曖昧になってしまう場合が多くあるからである。ゴールの設定や未来像は非常に重要で、プロジェクトマネージャーなどリーダーが必ず持っておくべき指針である。

真のリーダー像

システム開発に参画するメンバーは一般的に経歴書やスキルシートによって決まる。プロジェクト経験数が多かったり、扱える言語が多かったりするだけでは、本当のスキルは推しはかれない。やはり、確認すべきは不測の事態が起きたときの対処方法を豊富に持つリーダーが必要となる。

アジャイルの本質

犬小屋を建てるときに設計書はいらないが、マンションを建てるには設計書がいる。アジャイル開発といっても、例えばマンションを設計図なしに建てるといったことを考えるとある程度は見通しや知見などを持つメンバーが方向性を決めていく必要がある。システム開発はその時その時の条件によっていい悪いの判断軸が変わる。さらに時間の経過でも判断軸が変化していくのである。

部分最適の罠

日本には「カイゼン」という高度経済成長期を支えた力強い言葉がある。しかし、時と状況によって判断軸が変わるソフトウェアという無形財産の前では、「善」に「改」めることができているのか、変化してしまう背景がある。職人気質である国民性も相まって、どうしても部分改善、部分最適を繰り返してしまうというプロジェクト現場が少なくない。

まとめ

システム運用や保守における部分最適は必ずしも全体最適になるわけではない。むしろ、この部分最適が全体を考えたときの労働生産性を下げていることすらある。小回りが利く人であればあるほど属人化してしまったりするため、誰が全体最適を見るのがベストなのか、改めて考える必要がある。

関連記事

DX前の業務整理

DX推進の落とし穴

多くの企業がDX推進を急ぐあまり、業務改善ツールやシステムの導入を最優先にしてしまう傾向がある。しかし、現状の業務プロセスを整理しないままツールを導入することは、非効率な作業をそのままデジタル化するだけに終わる危険性がある。DXの本質は単なるIT化ではなく、業務そのものの変革にある。

非効率のデジタル化の罠

いきなりツールを導入すると、既存の非効率な業務フローがそのままシステムに組み込まれてしまう。例えば、不要な承認プロセスや重複した作業がデジタル上で再現され、かえって業務が複雑化するケースも少なくない。また、現場の実態に合わないツールを選定してしまい、導入後に使われなくなるという失敗も頻発している。結果として、多大なコストと時間を費やしながら、期待した効果を得られないまま頓挫するプロジェクトが後を絶たない。

業務可視化から始めるDX

DXを成功させるためには、ツール導入の前に徹底した業務整理が不可欠である。まず、現在の業務フローを可視化し、各プロセスの目的と必要性を検証する。次に、重複作業や不要な承認ステップを洗い出し、業務そのものをシンプルにする。この段階で「なぜこの作業をしているのか」を問い直すことが重要である。形骸化したルールや慣習的に続けてきた作業を見直すことで、本当に必要な業務が明確になる。整理された業務プロセスに対して最適なツールを選定することで、初めてDXの効果を最大化できる。

業務整理の成果

業務整理を先行させることで、ツール導入の目的が明確になり、適切な選定が可能になる。整理された業務フローは現場の理解も得やすく、ツールの定着率も大幅に向上する。さらに、業務整理の過程で発見された課題は、DXだけでなく組織全体の改善にもつながる。属人化していた業務の標準化や、部門間の連携強化など、副次的な効果も期待できる。DXは一度きりのプロジェクトではなく、継続的な改善活動である。まず業務を整理し、その上でツールを活用するという順序を守ることが、持続可能なDX推進の鍵となる。

まとめ

DX成功の鍵は、ツール導入前の業務整理にある。非効率な業務をそのままデジタル化しても効果は得られない。まず業務フローを可視化し、不要なプロセスを排除してから最適なツールを選定することで、DXの本来の効果を発揮できる。

続きを見る >

ベトナムオフショア開発におけるブリッジエンジニアの重要性とその役割

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

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

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

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

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

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

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

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

結論

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

続きを見る >

思考と決断のPM力

PMの真価

スキルシート上にあるPMというのは、どういった開発言語や開発環境などを使ってきたかという内容であることが多く、SEの延長という意味合いが強く残っている。もし、期待するポジションが発想力や提案力にあるとすれば、姿勢をみることが大切となる。

従順の呪縛

就職氷河期と呼ばれる世代より上の年齢層では、常に従うことを幼少期から叩き込まれていると考えられる。日本では「禁止」か「許可」かを常に意識しながら仕事をしており、「許可されるまでは禁止されている」と考えているのではないかと推察される。

失敗からの成長

正しいか、間違っているか、の判断基準しか持ち合わせていない場合、何か問題が発生したときに時間を遡ってどこで判断を間違えたのかを追求する。それは大切なことであるが、実際のプロジェクトでは誤ったことを反省しつつ修正しながら進むことが大切である。

判断力の真髄

エンジニア出身のPM(開発プロジェクトのPM)だと、禁止か許可かというデジタルのような見方をしている人もいる。特に今日のシステムに関するプロジェクトでは、ゼロかイチだけでは判断できないような、ウエットでアナログな状況判断が必要となる。

まとめ

たとえ能力の高いPMだったとしても、仕事になると発想することや作ることの楽しみより、ミスによる懲罰を恐れたりするために、無難で当たり障りのない判断をしがちである。システムに関するプロジェクトがなかなか前へ進まない理由でもある。

続きを見る >