私がこれまで、SIerとして関わってきた開発プロジェクトは、お客様にとって挑戦的な要素が多く、「答えを見つける」よりも「答えを創り出す」要件の整理が多かった。結果、後にDX活動として社外から高い評価を受けた事例もあれば、反省すべき活動もあった。成功と失敗の両方を経験する中で、「何がプロジェクトの成否を分けたのか」を振り返ると、「ユーザー企業の人財」に依存する部分が大きいと感じている。
こう書くと、プロジェクトの失敗を顧客の力不足に押し付けているようにも受け取られかねないが、断じてそうではない。開発ベンダーとしての力量が及ばないケースも勿論ある。一方で、システム開発には「ユーザー企業が決断しないと、前に進めない」局面が度々訪れる。
本稿では自身の経験を振り返り、プロジェクトに暗雲が立ち込める直前の「兆候」を示していく。そのうえで、開発プロジェクト成功のためにユーザー企業内に求められるスキルセットを提案したい。本コラムの読者が、自社のシステムを構想する若手リーダーの方であれば、自身が身に付けるべきスキルの参考に、管理者の方であれば、育成プランの参考にして頂ければ幸いである。

要件定義工程でみられるプロジェクト失敗の兆候

システム開発プロジェクトの失敗（スケジュール遅延、コスト増、機能不全、等）の主な要因は、依然として要件定義工程にある。しかし、要件定義工程の段階で、失敗を予見することはなかなかできない。予算とゴールが決まっている中で、序盤からテコ入れの判断を下すことが難しいという側面もある。大抵は、ユーザーの最終確認段階やシステム稼働後に、じわじわと要件の不備やシステム品質の悪さに気が付くことになる。ただ、要件定義工程の段階で何らかの兆候は存在したはずである。
自身の経験からいくつか兆候を紹介する。要件定義段階で問題にするには、とるにたらないことに思うかもしれないが、意外に身近に起こっていることである。

兆候1：要件定義は開発ベンダーが行うものだという空気感

要件定義は本来、ユーザー企業と開発ベンダーが協力し、何を達成すべきかを共同で決定するプロセスである。しかし、この時点で開発ベンダーが全責任を負っているような雰囲気があることも少なくない。ユーザー企業と開発ベンダーは、受託の関係ではあるが、対等なパートナーとして同じシステムを創っていく「仲間」となることが望ましい。お金を出している「お客様」と「業者」のような空気感があると、開発ベンダーが粛々と要件定義を進め、期間内に終わったとしても、後々要件漏れが多く見つかる可能性が高い。

兆候2：自分ごととしての意識不足

業務視点での意見を反映するために、プロジェクトに業務部門のメンバーが参画することは重要だ。ただ、そうしたメンバーは、打合せに参加こそしているものの、どこか「他人ごとの意識」が抜けないことも多い。その結果、開発ベンダーが見栄えの良い分厚い成果物を作り上げるも、業務部門内でうまく周知ができず、何かと社内説明に開発ベンダーを呼ぶ状況が発生する。当然、部門内の理解も進まず、要件定義工程後も業務部門からの要求が続くことになる。

兆候3：パッケージ選定が先行、要求が曖昧

実業務の現場から、課題は挙がっているが記載レベルがバラバラで、目的や要求間の整合性も不明確だったり、矛盾していたりするのに、採用するパッケージだけは決まっている。そんな現場では、要件定義工程が「つじつまを合わせる作業」になる。結果的にシステムが稼働しても充分に性能を発揮できない。または使われなくなる。

兆候4：開発ベンダーは間違えないだろうという過度な信頼

ユーザー企業が開発ベンダーの成果物に積極的なフィードバックを提供せず、要件の正確性や整合性をきちんと確認できていないプロジェクトでは、テスト工程で「こんなイメージではなかった」と必ず問題が発覚する。成果物が「合っているだろう」との意識の下での確認と、「間違っていないか」と疑念の意識のもとでの確認はフィードバックの質が全く異なってくる。

兆候5：そもそも楽しくなさそう

投資をしてまで実現するモノ（システム）は、業務を変え、顧客を喜ばせ、社員を喜ばせるものでもある。それなのに、まだないものを想像して実現する工程を楽しむ雰囲気がなく、プレッシャーがチャレンジ精神を奪っている状況が伺える。そうした雰囲気のプロジェクトは往々にして、目的の達成よりも、プロジェクトを期間内、予算内に収めることに注力してしまう。

成功プロジェクトでユーザー企業に満たされていたもの

それでは逆に、要件定義工程やプロジェクト全体が成功と呼べるケースでは、ユーザー企業にどのようなスキルを持った人がいたのかを振り返ってみたい。すべてを兼ねそろえる人はなかなか居ないが、これらのスキルを持つ人の存在がプロジェクトを成功の鍵を握っていたように感じている。

システムを複雑にすべきでないという意志を持った人

現場のニーズと要望に対して、本当にシステムで対応すべきかを適切に判断できる人。発言者の声の大きさに捉われず、その要望の解決に対するインパクトや貢献度を正しく捉え、ときにはシステムに実装しない、または、業務を変えて対応するという判断を、現場の理解を得ながら解決することができていた。

タイムリーに経営層の判断を取り付けることができる人

要件整理を進める中で目的やスコープ、コストに関する予期しない課題や変更が発生することはありうる。その際、経営層とのタイムリーなコミュニケーションを取りつけることで、方向性やリスクを共有できる人は得難い存在である。彼らの存在により、最終的なプロジェクトの方向性や経営層の理解を確保することができた。

中長期視点でビジネスとシステムを考えることができる人

システムの稼働はゴールではなくスタートである。その後、システム稼働を安定させて業務に定着させ、当初の目的を達成できるかが問われる。その前提を理解して機能要否の意志決定ができる人がいると、事業環境の変化や利用実態に応じて成長するシステムを見据えたプロジェクト運営が可能になる。

社内から必要な情報を収集することができるネットワークを持った人

ユーザー企業側のプロジェクトリーダーが全ての業務に精通している必要はなく、重要なのは、適切なステークホルダーとコミュニケーションを取るネットワークを持っていることで適切な情報を収集できる人がいることである。これにより、具体的な要件定義を効果的に進行することができた。

現場の想いをどのように実現できるか真剣に考え、業務を変えようという意識を持った人

現業メンバーからは業務が変わることへの抵抗もあったが、現場との合意を取り付けられる人の存在は重要であった。その人には業務の知識もあったが、何よりも真剣に業務を良くしたいという熱意が感じられたことが現場と協力しあえる関係を築くことができた要因だと思う。

スキルアップのアプローチとは？

社内で不足する役割やスキルは、コストをかけて社外の人材を活用する方法もあるが、社外からの参画では業務の理解度や期間には制約があるため、根本的な解決策として、社内の人材との協業が必要になる。また、常に変化に対応できるように、継続的に体制を維持することが重要であることからも、社内での育成をお勧めしたい。と言っても、実はご紹介した役割やスキルはIT領域のテクニカルなスキルではなく、新しい事業領域に取り組む際に求められるビジネススキルと何も変わらない。ある目的を達成するために、社内リソースとパートナーを巻き込んで仕事に取り組む熱意と行動がどれだけあるか、というシンプルな話なのである。システム開発の要件定義に特化した話をすれば、ユーザー側での要件定義力の強化は近年の流れでもあることから、さまざまな書籍が発行されているので参考にされるとよいだろう。

• ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ
  https://www.ipa.go.jp/publish/tn20191220.html
• システムを「外注」するときに読む本
  https://www.diamond.co.jp/book/9784478065792.html
• システムを作らせる技術 エンジニアではないあなたへ
  https://bookplus.nikkei.com/atcl/catalog/2021/9784532323998/

また、環境面で述べれば、社内育成や開発ベンダー選定において以下を配慮してほしい。

社内育成

• 新たな取り組みに対するチャレンジを認め、プロジェクト経験を通じて学び続ける文化を醸成すること
• 社外コミュニティに積極的に参加し、社内では気が付くことができない新しい発見の場に飛び込むこと

開発ベンダー選定

• 御用聞きと言われるような何でも顧客の言うことに対応してくれる開発ベンダーではないこと（決して社内育成は進まない）
• システムが稼働して終わりではなく、ユーザー企業が成長するために何が必要か、表面だけでなく本音で向き合う関係と、さらにリスクを共有できる開発ベンダーと組むこと
  （参考） DX時代においてIT部門に求められる目利き力とは | 2023年 | DX時代のシステム導入最前線 | 野村総合研究所（NRI）

会社によっては、情報システム部門はシステムを運用する立場として、日々のエンハンスやトラブルに忙殺され、タスクをこなすことで精いっぱいというケースもあるかもしれない。そうしたときこそ、タスクをこなすという心構えではなく、管理部門として気構えを持って業務部門を変えていく、という心持ちが極めて大切だと感じる。

まとめ

これまで述べてきたように、プロジェクトの成否は開発ベンダーの力量だけでなく、ユーザー企業としてのスキルセットも重要な役割を担う。要件定義工程の段階で危険な兆候には気が付いてほしい。また、そうならないために、ユーザー企業として必要なスキルセットと環境を検討し、育成していくことが重要である。
デジタル人材の育成と言えばテクニカル面のスキルが着目されがちであるが、本当に重要なのは、ユーザー企業内の経営方針や現場の声から、実現すべきことを可視化する能力である。そうした役割を担う人財の育成こそ力を入れてほしい。

執筆者情報