記事

要件定義の問題点

はじめに

会社の雰囲気や要件定義の内容をみれば、おおよそそのプロジェクトが成功するか否かがわかる。うまくいかない場合のユーザー側とシステム会社側の原因の一例である。

・要件定義をシステム会社に任せてしまう
・元請けシステム会社が無理な要件でも受注する
・準委任契約の人材紹介会社がリスクなく利鞘を稼げる
・末端エンジニアの作業遂行以外の責任
・ユーザー側、発注側の担当者が保身する

今回はその背景を説明したい。

要件定義の丸投げ

要件定義をシステム会社に任せてしまう。
要件定義はシステム会社がユーザー企業をヒアリングして作るものではなく、ユーザーとシステム会社が議論を重ねることで答えを出していくものにしなくてはならない。ユーザーが目指すべき姿と、システム会社が実現すべき姿のすり合わせが重要である。

無理な受注

元請けシステム会社が無理な要件でも受注する。
無理な要件でも受注できるのは、発注側にもシステムの知識がないため、ゴールが曖昧なまま元請けシステム会社が請け負ってしまうからである。もし、発注側にITリテラシーがなければ、パワハラなども発生する可能性が高い。したがって、元請けシステム会社に精神的な課題を回避するため、要件定義を作る人でさえも二次受けシステム会社から集めてくることがある。

人材紹介会社の利益構造

準委任契約の人材紹介会社がリスクなく利鞘を稼げる。
システムの完成責任は負わず、作業だけ請け負うことになるため、人さえ集めてくれば、そこでリスクなく利鞘が稼げる。発注側のユーザー企業からすれば、契約は元請けシステム会社であるため、3次請け、4次請けを使おうが、完成さえすればいいと考えていることが多い。

エンジニアの責任範囲

末端エンジニアの作業遂行以外の責任。
末端のエンジニアには、クライアントとの調整や導入、一定品質や納期の遵守など、責任感や危機感がないこともある。プロジェクトの全貌が見えないことも原因である。また、言われたことをやるだけで報酬がそこそこあるのが、システムエンジニアの業界だったりするので、作業をした時間分だけ報酬を支払ってほしい、という話にもなる。

発注側の保身

ユーザー側、発注側の担当者が保身する。
システム開発がうまくいかなかったときに、発注側の担当者がシステム会社に責任を押し付けるといったことがある。これは信頼関係によるもので、共同でプロジェクトを成功させようという目標が作れなかった場合に発生する。システム会社を業者扱いして要件定義を丸投げしてしまわないようにしなければならない。

AIで何ができるのか 前の記事 開発費用値下げの危険性 次の記事

関連記事

記事

要件定義のアプローチ

要件定義の基本

すべてをシステムで解決してしまおうとする要件定義には注意が必要である。システムの成功の可否は要件定義にかかっていると言っても過言ではない。しかし、十分に要件定義の時間を使ったにも関わらず、ITプロジェクトが失敗することがある。

規模別の要件定義

システム構築の規模によって、要件定義の粒度が変わる。小さなITプロジェクトの場合は要件定義をせずにプロトタイプを作りながらシステム構築を進めるといった方法がある。これをアジャイル開発、プロトタイプ開発と呼ぶ。

要件定義の本質

要件定義の粒度は時間を掛ければ細かくなるわけではない。ユーザー側でも要件定義を進めるにつれて、想定している機能の矛盾点が出てくることがある。この矛盾点を解消していくこと自体を要件定義としてはならない。要件定義はあくまで本質的なコアとなる部分から膨らませることが重要である。

対話型要件定義

要件定義フェーズで失敗するパターンは、ユーザー側との対話ではなく、システム会社側がヒアリングに徹する場合である。ユーザー側はITを利用してどのようなことができるかを知らない可能性が高いため、システム専門家がそれを鵜呑みにした仕様で要件を固めてしまうと、製造工程で無駄な工数が発生し予算をオーバーしてしまうことがある。

まとめ

本質的な要件をコミュニケーションによって、はっきりさせていく作業こそが要件定義と言えるのである。さまざまな視点から何度も繰り返し要件をなぞることで粒度が落ちていき、適切な要件定義書となる。何でもかんでもシステム化せず、オペレーションとの関係性を見合わせながら進めることが望ましい。

続きを見る >
記事

DX前の業務整理

DX推進の落とし穴

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

非効率のデジタル化の罠

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

業務可視化から始めるDX

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

業務整理の成果

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

まとめ

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

続きを見る >
記事

製造業DX – IoT×ローコード活用法

IoT導入の新時代

製造業の現場では、人手不足や品質管理の課題が深刻化しているが、IoTとローコード技術の組み合わせが解決策として注目されている。従来のシステム開発には高額な費用と長期間を要していたが、ローコードプラットフォームを活用することで、現場の作業者でも直感的にIoTシステムを構築できるようになった。センサーからのデータ収集、機械の稼働状況監視、品質データの自動記録など、これまで手作業で行っていた業務を効率化できる。

ローコード開発の威力

ローコード開発プラットフォームは、プログラミング知識がなくても視覚的な操作でアプリケーションを作成できる革新的な技術である。製造現場の作業者が自分たちのニーズに合わせてリアルタイムでシステムをカスタマイズでき、IT部門への依存を大幅に減らせる。温度センサー、振動センサー、カメラなどのIoTデバイスと連携させることで、設備の予知保全や作業効率の向上を実現できる。従来の開発期間を3分の1に短縮し、コストも大幅に削減できるため、中小企業でも導入しやすくなっている。

成功事例と導入効果

実際の導入事例を見ると、ある自動車部品メーカーでは設備稼働率が15%向上し、品質不良率を30%削減できた。IoTセンサーで機械の振動や温度を常時監視し、異常を検知すると自動でアラートを発信するシステムを構築したのである。また、食品製造業では温度・湿度管理の自動化により、品質検査時間を50%短縮し、人的ミスによる製品廃棄を90%削減した。これらの成果は、現場作業者がローコードツールを使って自ら問題解決に取り組んだ結果であり、外部ベンダーに依存しない持続可能なDX推進を実現している。

未来の製造業像

IoT×ローコード技術は単なるデジタル化を超えて、製造業の競争力を根本的に変革する力を持っている。現場の知見を活かしたシステム構築により、真に使えるDXソリューションが生まれ、継続的な改善サイクルが確立される。今後はAI技術との融合により、さらに高度な予測分析や自動最適化が可能になるだろう。重要なのは小さく始めて段階的に拡張していくアプローチである。まずは一つの工程から始めて成功体験を積み重ね、徐々に全社規模へ展開していくことで、確実にDX効果を実感できる。変化に対応できる柔軟な組織作りこそが成功の鍵となる。

まとめ

IoT×ローコード技術は、製造業DXの民主化を実現する画期的なソリューションである。プログラミング不要で現場主導のシステム構築が可能になり、短期間・低コストでの導入を実現できる。成功事例が示すように、設備稼働率向上、品質改善、作業効率化など具体的な成果が期待できる。重要なのは小さく始めて段階的に拡張するアプローチであり、現場の知見を活かした持続可能なDX推進が可能になる。

続きを見る >