記事

開発の相場

相場の不在

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

建築との差異

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

人件費の実態

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

工期の変動

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

まとめ

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

リーダーの多忙による弊害 前の記事 SEのいうバッファとは 次の記事

関連記事

記事

ノーコード・ローコード比較

新たな開発手法

近年、ビジネスのデジタル化が加速する中で、ノーコード・ローコードツールが注目を集めている。従来のシステム開発では専門的なプログラミング知識が必須だったが、これらのツールを使えば、非エンジニアでも直感的な操作でアプリケーションやWebサイトを構築できる。開発期間の短縮やコスト削減が可能になることから、スタートアップから大企業まで幅広く導入が進んでいる。

主要ツール

ノーコードツールの代表例としては、Webサイト構築に強いBubbleやWebflow、業務アプリ開発に適したKintoneやAppSheet、自動化に特化したZapierなどがある。Bubbleは柔軟性が高く複雑な機能も実装可能だが、学習コストはやや高めである。Webflowはデザイン性に優れ、マーケティングサイトに最適だ。Kintoneはデータベース管理に優れ、日本企業での導入実績が豊富で、承認フローなど日本の業務習慣に対応している。一方、ローコードツールではMicrosoft Power AppsがOffice 365との連携に強く、OutSystemsは大規模エンタープライズ向けで基幹システム開発にも対応可能である。料金体系も月額制からユーザー課金制まで多様で、自社の規模に合わせた選択ができる。

両者の違い

ノーコードとローコードの最大の違いは、カスタマイズ性と技術的な介入度である。ノーコードは完全にコード記述なしで開発できる反面、複雑な要件には対応しきれない場合がある。ローコードは基本的な部分は視覚的に構築しつつ、必要に応じてコードを追加できるため、より高度な機能実装が可能だ。選択時のポイントは、開発したいシステムの複雑さ、既存システムとの連携要件、将来的な拡張性、そして社内の技術リソースである。シンプルな業務アプリならノーコード、基幹システム連携が必要ならローコードが適している。

導入のポイント

ノーコード・ローコードツールの導入を成功させるには、いくつかの注意点がある。まず、無料プランで試用し、実際の業務フローに合うか検証することが重要だ。また、ベンダーロックインのリスクを考慮し、データのエクスポート機能やAPI連携の可否を確認すべきである。セキュリティ要件も見逃せない。特に顧客情報を扱う場合は、各ツールのセキュリティ認証やデータ保存場所を確認する必要がある。さらに、導入後の運用体制も計画的に整備し、社内でのツール活用スキルを育成することが、長期的な成功につながる。

まとめ

ノーコード・ローコードツールは、企業のDX推進を加速させる強力な手段である。適切なツールを選定し、自社の課題に合わせて活用することで、開発コストを抑えながらスピーディーにシステムを構築できる。まずは小規模なプロジェクトから始め、成功体験を積み重ねながら展開していくことを勧める。デジタル化の第一歩として、ぜひ検討すべきだろう。

続きを見る >
記事

業務可視化によるDX推進

真の業務改善への道筋

いきなり顕在化しているアナログをデジタル化するだけでは業務改善とは言えない。真の業務改善を実現するためには、表面的な問題解決ではなく、根本的な業務の見直しが必要である。業務を可視化して正しい業務分析を行うためには、ある程度のステップを踏む必要がある。単純なデジタル化は一時的な効率化にとどまり、長期的な競争力向上には繋がらない。

目的とゴール設定

まず、目的とゴールを明確にする必要がある。なぜ業務分析をするのか、何を達成したいのかを明文化することが重要である。例えば、「手戻りを3割減らす」「問い合わせ対応時間を半分にする」「余剰コストを1千万円削減する」などの具体的な数値目標を設定する。曖昧な目標設定では、後の分析や改善施策の効果測定が困難になってしまう。定量的で測定可能な目標を立てることで、分析の方向性が明確になり、成果を客観的に評価できるようになる。

業務の可視化技法

現在の作業タスクのすべてをまずは網羅的に洗い出して、分類を行う。複数担当者で付箋にタスクを書き出し、重要度マトリクスや緊急度マトリクスで整理する方法が非常に有効である。また、必ず用意しておきたいのが、業務フロー図と業務の分担表である。誰が、いつ、どこで、何をしているかを図式化することで、無駄や重複、ボトルネックが浮き彫りになる。このプロセスにより、今まで見えなかった非効率な作業や不要なプロセスを発見できるのである。

根本原因の探求

課題の本質がまとまったら、重要な事項と緊急の事項などを切り分けて、本質的ではない事項は思い切って削除や軽減を検討する。また、抽出した課題は小さな原因に分解していき、根本原因を探る（要因分析）。リソースが限られる場合には、ABC分析（例えば顧客ランク別）で、重要顧客に注力できるよう業務配分や訪問頻度などを見直す。定量データや日報などのログ、クレームデータの活用も効果的である。AIで課題を解決するより前に、膨大な過去データをAIに処理させるのも良いだろう。

まとめ

定量化・定性化できれば、効果検証につなげる改善策と実行計画を策定する。正しい業務分析とは、単なるデジタル化ではなく明確な目的に基づいて、ボトルネックを可視化し、データと構造化された分析を行うことなのである。継続的な改善こそが真のDXを実現する。

続きを見る >
記事

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

導入の落とし穴

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

活きる業務

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

業務選定の失敗

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

選定フレームワーク

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

まとめ

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

続きを見る >