記事

フルスクラッチは体力

開発手法の選択

フルスクラッチかパッケージか、最近ではSaaSなどもシステム構築の検討に入る。実は開発手法やツールよりも、どのようなシステムで、どれくらいの規模のシステム開発会社が担当するかが重要である。

SESのリスク

人数が多い会社であればあるほど安心感があってよいと安易に考えることは適切ではない。なぜなら、SE派遣やSESと呼ばれる人月（人工）単位で売り上げの経つ会社には技術の総合力がないからである。

技術の総合力

技術の総合力とは、SE作業やプログラミング作業などの1人で対応できる技術力を差すのではなく、システム構築やシステムの運用全般における最適手段を考えることができる能力のことである。

表層の即効性

SE派遣やSESの付加価値はその人単体のプログラミング能力に偏るため、一見対応がよく、何も問題がないように思える。しかし、これが技術的負債を作ってしまうひとつの要因でもある。

まとめ

フルスクラッチを考えるなら、SESを中心としないシステム会社で且つ人数規模も多い方がよい。安価にフルスクラッチでシステムを構築してしまうと、メンテナンスや運用でしっぺ返しが待っている。時間が経つごとにシステム保守費用が高くなるのである。

運用の昇華 前の記事 賢いコスト削減 次の記事

関連記事

記事

内製化の成功術

IT報酬の実態

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

導入時の誤解

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

システムと医療

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

真のIT人材価値

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

まとめ

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

続きを見る >
記事

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

導入の落とし穴

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

活きる業務

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

業務選定の失敗

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

選定フレームワーク

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

まとめ

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

続きを見る >
記事

Power Appsで簡単に業務改善

システム開発の高コストと複雑化

多くの企業では、情報システム部門や外部システム会社にシステム開発を依頼すると、仕様確認が繰り返される。「この機能はどうするか？」「ステータスはこれで全てか？」など、質問が多く、時間とコストが増大。結果、システムは複雑化し、現場のニーズに即したシンプルな解決策から遠ざかる。

野良プログラムのリスク

システム開発の手間を避けるため、各部署でExcelマクロによる「野良プログラム」が横行する。これらは各人のPCに保存され、最新版の確認が困難になり、メンテナンスも不透明。担当者がいなくなるとブラックボックス化し、セキュリティリスクも増加。放置すれば、企業全体の業務効率が低下し、情報漏洩の危険もある。

Power Appsで迅速なシステム構築

こうした問題を解決するのが、MicrosoftのPower Appsだ。従来の複雑な開発プロセスを排除し、現場担当者が自らアプリを構築できる。ドラッグ＆ドロップで簡単に操作でき、セキュリティもMicrosoft標準に準拠。野良プログラムの乱立を防ぎ、システム管理とメンテナンスも容易になる。さらに、ユーザー自身がアプリを修正できるため、柔軟性も確保できる。

定量化困難な業務もデジタル化

業務のデジタル化は、数値で説明可能なタスクは簡単だが、現場には「説明しにくい」業務も多い。こうした業務は経験に依存しがちで、担当者に頼ることが多い。Power Appsは、このような曖昧な業務も迅速にアプリ化し、標準化と効率化を同時に実現する。

まとめ

Power Appsは、現場主導でアプリを作成・管理できる柔軟性を提供し、野良プログラムのリスクも解消する。複雑な開発プロセスを省き、数値化しにくい業務も効率的にデジタル化することができる。

続きを見る >