QCDの死角

失敗の正体

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

エンジニアの真実

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

成功の境界

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

コスパの本質

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

まとめ

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

関連記事

野良アプリは排除すべきか?

「便利」の裏にある現場IT

シャドーITとは、企業の情報システム部門が認知・管理していない状態で、現場の判断によって導入・利用されるIT資源を指す。具体例としては、LINEやGoogleドライブ、Excelマクロなど、日常業務の中で自然発生的に使われるツールが挙げられる。これは企業としての統制外にある一方、現場の即応性や利便性を追求した工夫の結果でもあり、単なるルール違反と一括りにはできない。ゆえに、これを「排除すべき野良アプリ」として扱うことが妥当かどうか、慎重な見極めが必要である。

IT部門を飛び越える理由

現場がシャドーITを使う背景には、既存システムの使い勝手の悪さや、IT部門の対応の遅さといった事情がある。業務は待ってくれない以上、迅速な判断や情報共有のために、現場が自ら使いやすいツールを選ぶのは自然な流れである。たとえば、社内の共有フォルダではなくGoogleドライブを使ったり、煩雑な申請フローをExcelマクロで簡素化したりといった工夫は、業務効率の向上に寄与している。現場がスピードと柔軟性を求める限り、IT部門の枠組みに収まらないツール活用は今後も続くはずだ。

シャドーITのリスク

便利な一方で、シャドーITには深刻なリスクも存在する。まず、セキュリティが担保されていないツールの使用は、情報漏洩やマルウェア感染といったリスクを高める。また、IT部門の管理外にあるため、データの一元管理ができず、連携の取れないシステムが乱立することで、かえって非効率になることもある。最悪の場合、コンプライアンス違反や内部統制の崩壊を引き起こす可能性も否定できない。利便性の裏には常にリスクが潜んでいるという現実を直視する必要がある。

市民開発と再定義

ただし、シャドーITの存在は、現場が自らITを活用しようとする前向きな姿勢の表れでもある。近年ではDXの進展に伴い、「市民開発」や「ローコード開発」など、現場主導のIT活用が注目を集めている。従来は否定されてきたシャドーITも、企業変革の一端を担う可能性を秘めている。IT部門がすべてを統制するのではなく、現場と協力しつつガバナンスを効かせる視点に立てば、シャドーITは排除すべき“野良”ではなく、むしろ育てるべき“創造”として再定義できるはずだ。

まとめ

現場の柔軟性と全社最適を両立させるには、両者を理解した経営の舵取りが欠かせない。「排除」ではなく「共存」の設計に踏み出すことこそが、企業のDXを推進するための鍵となる。

続きを見る >

ローコードで失敗する企業

導入の落とし穴

ローコード開発は、プログラミング知識がなくても業務アプリを構築できる手法として注目を集めている。しかし、導入企業の多くが期待した成果を得られず、プロジェクトが頓挫するケースが後を絶たない。「簡単に作れる」という触れ込みを鵜呑みにし、適切な計画なく導入を進めた結果、かえって業務効率が低下する事態も発生している。失敗の原因は、ローコードの特性を正しく理解していないことにある。

活きる業務

ローコードが真価を発揮するのは、定型的な業務プロセスの自動化や、シンプルなデータ管理アプリの構築である。例えば、申請承認ワークフロー、在庫管理、顧客情報の一元管理といった業務では、短期間で実用的なシステムを構築できる。また、現場部門が主体となって改善を繰り返す必要がある業務にも適している。成功企業に共通するのは、最初から大規模なシステムを目指さず、小さな業務改善から着手している点である。スモールスタートで効果を検証し、段階的に適用範囲を広げることで、確実に成果を積み上げている。

業務選定の失敗

一方で、ローコードには明確な限界がある。複雑なビジネスロジックを含む基幹システム、大量データのリアルタイム処理、高度なセキュリティ要件が求められるシステムには不向きである。失敗企業の典型的なパターンは、これらの領域にローコードを適用しようとするケースである。開発途中で機能の限界に直面し、結局フルスクラッチでの再開発を余儀なくされることも少なくない。また、ベンダーロックインのリスクも見過ごせない。特定のプラットフォームに依存することで、将来的な拡張性や他システムとの連携に支障をきたす事例が増えている。業務特性を見極めずに導入を急ぐことが、失敗の最大の要因である。

選定フレームワーク

ローコード導入を成功させるには、業務の棚卸しと適性判断が不可欠である。まず、対象業務の複雑性、データ量、連携要件を可視化し、ローコードで対応可能な範囲を明確にする。次に、将来的な拡張性や保守運用の観点から、長期的なコストを試算することが重要である。短期的な開発コスト削減だけを見て判断すると、運用フェーズで想定外の負担が発生する。成功企業は、ローコードと従来型開発を適材適所で使い分けている。すべてをローコードで賄おうとせず、業務特性に応じた最適な開発手法を選択することが、DX推進における重要な判断軸となる。

まとめ

ローコードは万能ではない。定型業務や小規模アプリには有効だが、複雑な基幹システムには不向きである。成功の鍵は、業務特性を正しく見極め、適切な領域に適用すること。導入前の計画策定と、段階的なアプローチが失敗を防ぐ最善策である。ツールの特性を理解し、戦略的に活用することでDX推進を加速させよう。

続きを見る >

日本の技術人材不足とオフショア開発

セクション1: 日本のソフトウェア開発人材不足の背景

日本のソフトウェア開発業界は50年以上の歴史を持ち、多くの経験豊富なエンジニアが存在します。しかし、現在の日本では開発人材の不足が深刻な問題となっています。この人材不足は、企業が即戦力となるエンジニアを安価で求めるという要望に由来しています。そのため、日本の人材不足はしばしば「即戦力を安く求める欲求」として揶揄されることもありますが、この言い方には一面の真実も含まれています。企業が効率的な開発を行うためには、即戦力のエンジニアが必要なのは当然のことです。

また、この人材不足の問題は、単に日本だけに限ったものではありません。他の海外でも同様の人材不足が起きています。したがって、オフショア開発を検討する際には、都合の良い人材を海外で見つけることができるという考え方は一部正解であり、一部誤解とも言えます。

セクション2: 日本とベトナムのエンジニアの特徴

日本のエンジニアは、特にWeb関連のエンジニアにおいては、1990年代からのキャリアを持つベテランが多く存在します。そのため、文字コードやバイナリ、組み込み技術など、古いOSや低レベルの知識を必要とする開発においては、日本の技術者は強みを持っています。一方、新しいフレームワークや概念の習得には、国民性よりも年齢が影響を与える傾向があります。そのため、ベトナムのエンジニアは若さを活かして新しい技術を素早く学ぶことが得意と言えます。

また、コンピューター業界においては、上流と下流、低レベルと高レベルといった言葉が中立的に使われますが、この意味において日本は低レベル開発に向いており、ベトナムは高レベル開発に向いていると言えます。そのため、バランスの取れたオフショア開発を行うためには、日本のエンジニアのジェネラリスト的な能力とベトナムのエンジニアのスペシャリスト的な能力を組み合わせることが重要です。

セクション3: 日本とベトナムの開発手法の違い

日本のソフトウェア開発では、納期を守るためにウォーターフォール型の開発手法が主流です。アジャイル開発が概念的には取り入れられつつありますが、完全にアジャイルな開発プロセスを採用しているケースはまだまれです。一方、ベトナムのソフトウェア開発は、日本の開発手法と大きく異なるわけではありません。基本的には納期を守るためのウォーターフォール型の手法が一般的ですが、OSSの影響を受けて開発手法が変化しつつあります。

日本の開発現場と比較して、ベトナムの開発手法の利点は、新しいフレームワークや技術の習得において素早い反応性を持つことです。ベトナムのエンジニアは若く、学習意欲が高いため、最新の技術に対する理解が早く、柔軟に対応できるという特徴があります。ただし、ベトナムの開発現場においては、アジャイル開発の完全な導入はまだ一般的ではないことに注意が必要です。

セクション4: 言語の壁以外の考慮すべきポイント

ベトナムのエンジニアを活用する際に言語の壁を乗り越えるためには、円滑なコミュニケーションを図ることが重要です。英語がビジネスコミュニケーションの共通語となっているため、日本の企業がベトナムのエンジニアとのコミュニケーションを円滑に行うためには、英語教育の強化や翻訳ツールの活用などが有効です。また、文化やコミュニケーションスタイルの違いも考慮すべきポイントです。異なる文化背景を持つエンジニア同士が協力する場合、相手の文化に対する理解や尊重が求められます。

セクション5: 成功へのカギはバランスと柔軟性

ベトナムでのソフトウェア開発のオフショアを成功させるためには、日本とベトナムのエンジニアの特長を組み合わせることが重要です。日本のエンジニアはジェネラリストとして幅広い知識と経験を持っており、プロジェクト全体の管理や技術的な統括を担当することが得意です。一方、ベトナムのエンジニアはスペシャリストとして特定の技術に精通しており、新しい技術の習得にも素早く対応できます。

オフショア開発においては、開発現場のバランスと柔軟性が求められます。例えば、日本のエンジニアがジェネラリストとしてプロジェクトを牽引し、ベトナムのエンジニアがスペシャリストとして特定の技術領域を担当する役割分担が効果的です。また、現代的な開発手法を用いることも重要です。ウォーターフォール型の手法に加えてアジャイル開発の一部を取り入れるなど、柔軟に適切な手法を選択することが目的達成(コストダウン実現)へのカギとなります。

続きを見る >