はじめに．．．

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

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

今回はその背景を説明したいと思います。

要件定義をシステム会社に任せてしまう

要件定義をシステム会社に任せきりにしてしまうことは、プロジェクトの根幹を揺るがす重大な問題です。要件定義は単にシステム会社がユーザー企業からヒアリングした内容を文書化するだけではなく、両者が協力して創り上げていくべき重要なプロセスです。ユーザー企業が目指す理想的な姿と、システム会社が技術的に実現可能な範囲を丁寧にすり合わせることが不可欠です。

この過程では、ユーザー企業の業務プロセスや課題を深く理解し、それらをシステムによってどのように解決・改善できるかを議論する必要があります。同時に、システム会社は最新の技術動向や業界のベストプラクティスを踏まえた提案を行い、ユーザー企業の視野を広げる役割も担います。

要件定義を疎かにすると、プロジェクトの後半で大幅な仕様変更や追加開発が必要となり、コストと時間の無駄が生じる可能性が高くなります。また、ユーザーのニーズを十分に満たせないシステムが完成してしまうリスクもあります。したがって、両者が対等な立場で、オープンかつ建設的な対話を重ねることが、成功への鍵となります。

元請けシステム会社が無理な要件でも受注する

元請けシステム会社が無理な要件でも受注してしまう背景には、複雑な問題が潜んでいます。多くの場合、発注側にもシステム開発に関する十分な知識や経験がないため、プロジェクトのゴールが曖昧なまま進行してしまいます。このような状況下で、元請けシステム会社は競合他社との競争や売上目標の達成圧力から、リスクを十分に評価せずに受注してしまうことがあります。

さらに深刻な問題として、発注側のITリテラシーの低さが、不適切なコミュニケーションやパワーハラスメントを引き起こす可能性があります。システムの専門知識がない発注側担当者が、無理難題を押し付けたり、技術的制約を無視した要求をしたりすることで、プロジェクトの健全な進行が阻害されることもあります。

こうした状況を回避するため、元請けシステム会社は時として、要件定義を行う人材さえも二次受けシステム会社から集めてくることがあります。これにより、直接的な精神的負担や責任を軽減しようとしますが、本質的な問題解決にはつながりません。むしろ、コミュニケーションの複雑化や責任の所在の不明確化を招き、プロジェクト全体の質の低下につながる可能性があります。

準委任契約の人材紹介会社がリスクなく利鞘を稼げる

準委任契約を活用する人材紹介会社の存在は、システム開発業界の構造的な問題を浮き彫りにしています。この契約形態では、システムの完成責任を負わず、単に作業を請け負うだけで済むため、人材を供給さえすれば比較的リスクの少ない利益を得ることができます。

しかし、この仕組みは品質管理や責任の所在を不明確にし、プロジェクト全体の効率を低下させる要因となっています。発注側のユーザー企業からすれば、契約の相手は元請けシステム会社であるため、3次請け、4次請けの存在やその品質について深く考慮することはありません。システムが完成さえすれば良いという短絡的な考えに陥りやすいのです。

この構造は、技術者の育成や技術力の向上にも悪影響を及ぼします。短期的な人材の需給調整に終始し、長期的な視点での人材育成やスキル向上の機会が失われがちです。また、多重下請け構造によるコストの上昇は、最終的にユーザー企業の負担増加につながります。

末端エンジニアの作業遂行以外の責任

システム開発プロジェクトにおいて、末端のエンジニアの責任意識の欠如は深刻な問題です。多くの場合、彼らはクライアントとの直接的な調整や、システム導入後のフォローアップに関与する機会が少なく、プロジェクト全体の成功に対する当事者意識が薄れがちです。また、一定の品質確保や納期遵守といったプロジェクト管理の重要性を十分に理解していないことも多々あります。

この背景には、プロジェクトの全体像が見えないという構造的な問題があります。多重下請け構造の中で、末端エンジニアは自分の担当部分のみに集中し、システム全体の中での位置づけや重要性を把握できていないことがあります。そのため、自分の作業が遅れた場合の影響や、品質が低下した際のリスクを正確に認識できていないのです。

さらに、システムエンジニアの業界では、「言われたことをやるだけで、それなりの報酬が得られる」という認識が一部に存在します。これは、時間単位での報酬体系が一般的であることも影響しています。結果として、「作業した時間分だけ報酬を支払ってほしい」という考え方が生まれ、成果物の質や価値よりも、投入時間を重視する風潮を助長しています。

ユーザー側、発注側の担当者が保身する

システム開発プロジェクトが失敗した際、発注側の担当者がシステム会社に責任を押し付けるという事態が少なからず発生しています。この背景には、両者の信頼関係の欠如と、共同でプロジェクトを成功させるという目標設定の失敗があります。

多くの場合、発注側担当者は自社内での立場や評価を守るために、外部のシステム会社を「スケープゴート」として利用しようとします。これは短期的には担当者個人を守ることになりますが、長期的には組織全体の学習機会を失い、同様の失敗を繰り返す原因となります。

また、システム会社を単なる「業者」として扱い、要件定義を丸投げしてしまうケースも多々あります。これは発注側の責任放棄であり、プロジェクトの成功を危うくする行為です。真の意味でのパートナーシップを築き、互いの強みを活かしながらプロジェクトを進めていく姿勢が不可欠です。

発注側担当者には、自社のビジネス目標とITシステムの関係を明確に理解し、システム会社と建設的な対話を行う能力が求められます。同時に、失敗を恐れず、問題点を率直に共有し、共に解決策を見出す勇気も必要です。

まとめ

ユーザー担当者も本業を抱えていることが多く、システムに精通するシステム会社側はしっかりと要件定義の道筋をリードしていくことが大切ではないでしょうか。

要件定義は、ユーザーが主体的に作るものではなく、システム会社がヒアリングして作るものでもありません。議論によって共に作り上げて実装フェーズへ移すべきです。アタラキシアDXは、そこをどのように融合させるのか、PMOという言葉で表現しています。

アタラキシアDXでは、情報システム部以外からの依頼を受けることが多いです。
相談を受けるときにユーザー側の本気度を見極めています。しかし、もしかすると本気でなければ、このブログにたどり着いていないのかもしれませんね。