ビジネスの変革に貢献するデジタル化・DXのため、
ユーザー部門が上流工程をリードできる存在に

（公開日：2025年5月9日）

今、多くの企業がDXによるビジネス変革に取り組んでいます。よく言われているように、DXは単なる「デジタル化」ではなく、あなたのビジネスの変革、ビジネス戦略の実現に資するものでなくては意味がありません。しかし、現場の実情はどうでしょうか。

ここでは、デジタル化を進めるA社の例を取り上げます。A社では、DX戦略に基づいたシステム化を進めていました。しかし、開発段階ではシステム開発の進行の遅延や成果物の不備など様々な事故が多発して、現場の社員に大きな負荷がかかりました。そしてシステムが完成した後は、トラブルのたびにベンダーを呼んだり、ミスを誘発して損害が出たりするなど、変革以前の問題に悩まされました。
なぜ、このようなことが起こるのでしょうか。その要因は、ユーザー部門のシステム開発への関わり方にありました。ユーザー自らが業務要件を定義すべきであるという意識の欠如や、要件定義に関する知識不足などにより、ビジネス上のニーズをIT部門や委託先などのシステム開発者に適切に連携できていなかったのです。

多くの日本企業では、社内にIT人材が少なく、またその所属先はIT部門に集中している傾向があります。そのため、真にビジネスの変革や業務効率化に資するデジタル化を進めるためには、IT部門だけに任せるのではなく、ユーザー部門が積極的に取り組む必要があります。では、ユーザー部門がどのような知識やスキルを身につければよいのか、こちらのケーススタディを通してご紹介します。

背景と課題

A社では、ITを活用した業務改善や、DX推進に取り組んでいました。しかし、実際に必要なアプリやシステムを開発すると、うまく進めることができない、出来上がったシステムが担当者の想定していたもの異なっていた、などの課題が多発しました。

そのため、せっかく出来上がったシステムが十分に使われていない、トラブル対応に追われてしまう、ミスでお客様に迷惑をお掛けし、損害が発生するなどの問題が生じていました。その原因を探っていくと、システム開発の作業が、途中から開発を委託していたIT企業に丸投げになってしまっており、ビジネスのニーズを適切にシステムに落とし込めていなかったことが分かりました。

ユーザー部門社員にシステム開発、特に要件定義に関する知識が不足していたことで、自分たちの要件を正しくシステム開発者に伝えられず、結果としてシステム開発者との間で理解に齟齬や漏れがある状態で開発が進んでいたのです。

↑ページの先頭へ戻る

ユーザー部門がデジタル化をリードする存在になるための鍵

システム開発の知識が豊富なIT部門に任せるという選択肢もありますが、やはり実際の現場に一番詳しいのはユーザー部門です。また、IT部門がすべてのデジタル化に関わっていては、人手は足りず、スピーディな対応は難しくなります。
トレノケートでは、迅速なデジタル化・DXを進めるための「あるべき姿」として、ユーザー部門の社員が、自社のデジタル戦略を正しく理解し、IT企画や要件定義などの上流工程をリードできる状態を目指すことをA社に提案しました。

上流工程とは

システム開発において、要件定義や外部設計(仕様策定)を行うプロセスで、ユーザー部門・システム開発者間で認識の齟齬なくシステム開発を進めるために非常に重要です。

上流工程のプロセスの主導を担うのはユーザー部門、システム開発者のどちらの場合もあり、また、途中から共同で行う場合など様々です。しかし、いずれの場合も最終的にはユーザーのビジネスニーズがシステム開発者に伝わり、それがシステムとなっていきます。そのため、上記のうちどのようなアプローチをとった場合でも、最終的にはユーザー自身が自分たちのビジネスニーズをシステム開発者に伝え、さらにそれが正しく伝わっているかを確かめる責任があります。そのため、ユーザー部門が要件定義の方法やその必要性と重要性を理解し、主体的に要件定義に取り組むことが欠かせません。

また、システム開発を外部のベンダーに委託する場合には、「ベンダー選定」のプロセスが発生します。より良い、自分たちの開発に適したベンダーを選定して委託することは、システム開発に欠かせない第一歩です。この過程にユーザー部門が参画する際には、ベンダーに対する「RFI（情報提供依頼書）」、「RFP（提案依頼書）」が力を発揮します。

↑ページの先頭へ戻る

システム開発に関わるユーザー部門が身につけるべき知識とは

A社のユーザー部門の社員が上流工程をリードできるようになるため、トレノケートは、以下のコースを提供いたしました。

今までシステム開発について分からなかった社員の方が以下の状態になることを目指します。このようなスキルや知識を身につけることで、システム開発を依頼する際に、「こうしたい！」をITエンジニアに正しく伝え、また、システム開発を伴う業務改善やサービス開発をスムーズに進めることができるようになります。

• 開発の流れがわかりどこに関与しているかわかる
• 要件定義の進め方と注力すべきポイントわかる
• 自分たちのビジネス要件を正しくシステム開発者に伝えられるようになる
• システム開発者が作成した要求仕様のレビューができる
• 適切にRFI（情報提供依頼書）、RFP（提案依頼書）が書けるようになる

↑ページの先頭へ戻る

eラーニングと集合研修の併用メリット

ユーザー部門のための要件定義 では、参加者が同じ時間に集まり、講師が指導をしていく集合研修と、自身で学習を進めていくeラーニングを組み合わせたブレンデッド・ラーニングの形式となっています。
この形式のメリットは、以下の3点です。

• 前提知識の理解度を揃える
  社員の中でも、システム開発に関する知識の理解度は異なります。そのため、まずeラーニングで基礎的な知識を学習することで、集合研修開始時のレベル感を揃えることができます。
• 集合研修で実践的な演習に集中できる
  基礎知識にあたる部分を事前に学習しておくことで、集合研修では疑似体験やグループワークなど、実践的な経験を得るための演習に集中することができます。
  参考：学習効果を向上！反転学習
• 業務時間の圧迫を低減できる
  基礎知識の学習は自学自習とすることで、集合研修として必要な時間の削減につながります。そのため、業務から長期間離れることなくリスキリングを実現可能です。

↑ページの先頭へ戻る

研修の成果（受講者の声）

システム開発の一連の流れや注意点について学ぶことができました。システム構築をするには、いかに自分たちが今の業務の問題点や改善点を具体的に把握できているかが重要だと感じました。
要件定義で抜け漏れがあると、完成したシステムが思い通りに動作せず、問題を引き起こしてしまうということも理解しました。ベンダー側での作業も踏まえた全体の流れ・全体像を把握できてよかったです。

これまでも利用者の立場としてシステム開発に携わったことはあったのですが、重要なところはベンダーに委託するものだと考えていました。この研修を通して、DXはユーザー企業の知識や取り組みが重要であると意識が変わりました。もっと早くにこの研修で知識を学びたかったです！

要件定義に結び付けるための現状業務の理解と、課題・方針に照らした方向性を具体的に決めていくプロセスは、システム開発だけではなく、通常の業務でも役立つ思考法・プロセスと感じました。
物事の重要度をランク付けなどについても、どのような基準にしたら分類がしやすくなるかを学ぶことができました。

コースの詳細はこちら ▼

↑ページの先頭へ戻る