記事

内製化の成功術

IT報酬の実態

海外と比べて日本のITエンジニアの報酬が低いという記事をよく目にする。それもそのはずで、ハイクラスIT人材は都合のいい「何でも屋」にはならないからである。

導入時の誤解

ユーザー企業やシステムのユーザーは、IT化を行うことで業務が減るという先入観を持っていることがある。システム導入を着手したときの目的を忘れて、その時、その場の課題を優先して都合よくITエンジニアを動かしてしまう。また動くITエンジニアもそこにいたりする。

システムと医療

たとえば、「お腹が痛い」と病院にいって「すぐに切開しよう」とはならないはずだ。このようにシステムにもその他にも色々な条件が絡まり合っている。システムは取り扱う情報量や関連する業務が多く導入に時間がかかる。時間がかかる結果、最初の導入目的を忘れてしまうのである。

真のIT人材価値

ハイクラスIT人材はユーザー側の状況と心理を配慮しつつ、現場のプログラマーの状況と心理を考慮して陣頭指揮できる人材といってもよいだろう。心理というのは物の言い方だけではなく、無形の財産を構築したり業務にフィットさせたりするので、プロジェクトの円滑さが変わるのだ。

まとめ

小手先だけでシステムに関するプロジェクトを推進しようとすると、「言われた通りにやった」という受動的な参加者が増えてしまう。情シスのSIer化を回避するにはITエンジニアを「何でも屋」にさせて疲弊させないことも大切である。開発チームの雰囲気作りも非常に効果がある。

予算ブレの原因 前の記事 生成AIは使えない？ 次の記事

関連記事

記事

ローコード開発とAI活用

AIとローコードの融合

ローコード開発プラットフォームの普及により、非エンジニアでもアプリケーション開発が可能になった現在、生成AIの活用が大きな注目を集めている。ChatGPTやCopilotなどのAIツールを組み合わせることで、開発スピードがさらに向上すると期待されているが、本当にすべてのローコード開発にAIが必要なのだろうか。コスト、品質、保守性など多角的な視点から、AI導入の真の価値を見極めることが、企業のDX戦略において極めて重要になっている。

コード生成の現実

生成AIによるコード生成は確かに魅力的だが、実際の品質には課題がある。AIが生成するコードは、単純な処理であれば高品質だが、複雑なビジネスロジックや例外処理が絡むと、不完全なコードが生成されることが少なくない。さらに深刻な問題は要件定義の壁である。AIは与えられたプロンプトに基づいてコードを生成するが、曖昧な要件や暗黙の前提条件を正確に理解することは困難である。結果として、開発者は生成されたコードを詳細に検証し、修正する必要があり、期待したほどの効率化が実現しないケースも多く見られる。

保守性のコスト

AIを活用したローコード開発において、最も見落とされがちなのが保守性の課題である。AI生成コードは、その時点では動作しても、後から読み解くことが困難な構造になっていることがある。変数名が不適切だったり、処理の意図が不明瞭だったりすると、半年後に修正が必要になった際、開発担当者が変わっていた場合、大きな手戻りが発生する。また、AIツールのバージョンアップや仕様変更により、過去に生成されたコードとの互換性が失われるリスクも存在する。初期開発のスピードを重視するあまり、長期的な運用コストが膨らんでしまっては本末転倒である。真のDX推進には、目先の効率化だけでなく、持続可能な開発体制の構築が不可欠なのである。

適切な見極め

ローコード開発におけるAI活用は、すべてのケースで必須というわけではない。定型的な画面開発や単純なCRUD操作など、パターン化された開発にはAIが有効だが、複雑なビジネスロジックや高度なセキュリティが要求される領域では、人間による丁寧な設計と実装が重要である。重要なのは、プロジェクトの性質、チームのスキルレベル、長期的な保守計画を考慮した上で、AIを活用すべき領域と従来手法を維持すべき領域を明確に区分することである。段階的にAIツールを導入し、効果を検証しながら適用範囲を拡大していく慎重なアプローチが、失敗リスクを最小限に抑え、真の生産性向上につながる。

まとめ

ローコード開発へのAI導入は、万能の解決策ではなく、適材適所で活用すべきツールである。コード生成の質、要件定義の難しさ、保守性の課題を十分に理解した上で、自社の開発体制に合った形でAIを取り入れることが成功の鍵となる。短期的な効率化だけでなく、長期的な運用まで見据えた戦略的な判断が求められている。

続きを見る >
記事

開発の相場

相場の不在

フルスクラッチでのシステム開発に相場はない。相場とは商品が一般的に流通している商品など数が多い場合は、競争原理も働き、金額がある一定の範囲に収まってくるものである。

建築との差異

たとえば、一戸建て建築であれば、建物の規模と資材、それに加えて職人の人工で金額が決まる。フルスクラッチのシステム開発は、つまり極めて特殊な特注品を作るようなものであるため、システム開発に相場という概念が基本的にはないのである。

人件費の実態

システム（ソフトウェア）は一戸建てのように、基本的には材料費はかからない。システム開発の費用のほとんどは人件費である。大工職人の人工と同じように人月単価と呼ばれるSE1人が1ヶ月働く金額で相場を知ることができるのである。

工期の変動

建物を建てることと比べるとシステムやソフトウェアは無形の物となるため、1ヶ月の労働力を推し量ることは困難である。個人のプログラミングの早さによって、納期が早くなったり遅くなったりするのである。

まとめ

SEは過去のプロジェクト参画実績から、同じようなプロジェクトに何度も参画していれば手練れでスキルが高いと評価される。システムに関わる人材の評価が困難な点は、プロジェクトに参画する経験値と、本当の意味でのスキルが比例するわけではないことである。本当の意味でのスキルとはプロジェクトを成功させられるかどうかを指すのである。

続きを見る >
記事

従来開発 vs ローコード開発比較

基本概念

企業のデジタル化が加速する中、システム開発手法の選択は事業成功の鍵を握る重要な決断となっている。従来開発は、プログラマーがコードを一から書き上げる伝統的な手法で、高い技術力と豊富な経験が求められる。一方、ローコード開発は視覚的なインターフェースを活用し、最小限のコーディングでアプリケーションを構築する革新的なアプローチである。両者の特徴を正しく理解することで、プロジェクトに最適な選択が可能になる。

費用対効果

従来開発では高度なスキルを持つエンジニアの確保が必要で、人件費が開発コストの大部分を占める。特に大規模プロジェクトでは、設計から実装、テストまで長期間の人的リソースが必要となり、総コストは数千万円規模に達することも珍しくない。対してローコード開発は、専門知識が少ない人材でも短期間でアプリケーション構築が可能で、初期投資を大幅に削減できる。しかし、プラットフォームのライセンス費用や将来的なカスタマイズ制約を考慮すると、長期的なコスト効率は慎重に検討する必要がある。

開発速度

開発期間において両手法の差は歴然としている。従来開発では要件定義から本格運用まで数ヶ月から数年を要するケースが一般的で、複雑な機能実装には綿密な設計と段階的な開発が必要である。一方、ローコード開発は既存のテンプレートやコンポーネントを活用することで、数日から数週間での迅速なプロトタイプ作成が可能である。特にビジネスアプリケーションや内部管理システムでは、従来開発の10分の1以下の期間で実装できる場合もある。ただし、複雑なロジックや高度な機能が必要な場合は、結果的に従来開発と同等の期間を要することもあるため、プロジェクトの性質を見極めることが重要である。

品質と制約

システムの品質面では、それぞれ異なる特徴がある。従来開発は細部まで制御可能で、パフォーマンス最適化や独自機能の実装において高い品質を実現できる。セキュリティ要件が厳格なシステムや大量データ処理が必要な基幹システムでは、従来開発の柔軟性が威力を発揮する。ローコード開発は標準化されたコンポーネントを使用するため、一定の品質は保証されるが、プラットフォーム依存による制約がある。また、複雑な業務ロジックの実装や外部システムとの高度な連携において、期待する品質レベルに到達できない可能性もある。品質要件と開発リソースのバランスを慎重に評価することが成功の鍵となる。

まとめ

最適な開発手法の選択は、プロジェクトの目的、予算、期間、品質要件を総合的に評価して決定すべきである。ローコード開発は迅速性とコスト効率に優れ、内部業務システムや簡易的なWebアプリケーション開発に適している。従来開発は高い技術的要求や独自性が必要なシステムに最適である。重要なのは、どちらか一方に固執するのではなく、各プロジェクトの特性に応じて柔軟に選択することである。

続きを見る >