記事

要件定義のアプローチ

要件定義の基本

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

規模別の要件定義

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

要件定義の本質

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

対話型要件定義

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

まとめ

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

【東京】第2回 オフショア開発　定例勉強会 前の記事 技術的負債の返済方法 次の記事

関連記事

記事

SEのいうバッファとは

バッファの真意

見積りや作業スケジュールに際して、エンジニアやシステム会社から「バッファである」という回答を受けたことはないか。システム会社が言うバッファとは保険を意味していることがほとんどである。

不確実なバッファ

非エンジニアは見積りのバッファを聞いたときに、無駄なのではないかと感じる。「念のため」に必要なバッファは、裏を返すと知識がないから調べないと分からないので不安であるという意味である。知識があり、「念のため」が必要なければバッファはないと考えられる。

知識の不足

ほとんどのシステム構築プロジェクトは、バッファが多いほうが知識がないのに見積りが高くなるという矛盾が発生することになる。そう考えると「バッファ」とは「無駄」に聞こえるかもしれない。

本質のバッファ

さて、このバッファについて本来あるべき姿を説明する。本当にやってみなければ分からないといった高度な技術を使うときに、未知の領域に関するスケジュールの影響を勘案し、計画された期間のことをバッファと見るべきである。

まとめ

単なるシステム構築プロジェクトにおいて「無駄を削ればよい」というのは非エンジニアから見ると合理的でコストの軽減にもなる。しかし、研究開発分野において無駄を削ることは必ずしも合理的ではない。発想が乏しくなるからである。

続きを見る >
記事

DXが頓挫する企業の共通点

最初だけ盛り上がるDX

「うちもDXを進めよう」——経営層の一声でプロジェクトが立ち上がり、社内には期待感が広がる。新しいツールの選定やキックオフミーティングで現場も盛り上がり、変革の予感に胸が躍る。ところが半年も経たないうちに、プロジェクトは静かに失速する。担当者は日常業務に追われ、誰も進捗を確認しなくなる。この「最初だけ盛り上がって止まる」パターンは、中小企業のDX推進で最もよく見られる失敗例である。

中途半端になる本当の原因

DXが中途半端で終わる会社には、共通する構造的な問題がある。まず、推進の旗振り役が明確でないこと。経営層は「やれ」と言うだけで、現場に丸投げしてしまうケースが非常に多い。次に、成果指標が曖昧なまま走り出していること。「業務を効率化する」という漠然とした目標では、何をもって成功とするのか誰にもわからない。さらに、既存業務との優先順位が整理されていないため、忙しくなると真っ先にDXの取り組みが後回しにされる。つまり、ツールや技術の問題ではなく、体制と仕組みの欠如が根本原因なのである。

継続できる会社の共通点

一方で、DXを継続的に推進できている会社には明確な共通点がある。第一に、専任または兼任の推進リーダーを置き、経営層が定期的に進捗を確認する場を設けていること。月次のレビュー会議があるだけで、プロジェクトの優先度は格段に上がる。第二に、最初から大きな変革を狙わず、小さな成功体験を積み重ねる設計になっていること。たとえば、紙の申請書を一つデジタル化するだけでも、現場は「変わった」という実感を得られる。第三に、社員への教育と巻き込みを初期段階から計画に組み込んでいること。DXは一部の担当者だけで進めるものではなく、現場全体が「自分ごと」として関われる状態をつくることが、継続の最大の鍵となる。

脱却への三つの鍵

DXが中途半端で終わる状態から脱却するには、まず「なぜやるのか」を経営層自身の言葉で社内に伝えることが出発点である。ビジョンなき変革に人はついてこない。次に、三ヶ月単位の短期目標を設定し、達成・未達を可視化する仕組みを導入すべきである。ゴールが遠すぎると人は走り続けられないが、短いスパンで成果を確認できれば、モチベーションは維持される。そして最も重要なのは、外部の専門家を適切に活用することである。社内リソースだけで推進しようとすると、知見不足や属人化で必ず壁にぶつかる。伴走してくれるパートナーの存在が、DXの継続と成功を大きく左右するのである。

まとめ

DXが中途半端で終わる最大の原因は、技術力の不足ではなく、推進体制と継続の仕組みが整っていないことにある。専任リーダーの設置、短期目標による進捗の可視化、そして現場全体の巻き込み——この三つを押さえるだけで、止まっていたDXプロジェクトは再び動き出す。「何から手をつければいいかわからない」という場合は、まず自社の現状を客観的に見つめ直すことから始めるべきである。

続きを見る >
記事

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

導入の落とし穴

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

活きる業務

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

業務選定の失敗

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

選定フレームワーク

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

まとめ

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

続きを見る >