SIプロジェクトは案件ガチャか

SES案件はガチャらしい。

案件がガチャだなんてどれだけ運まかせなのだろうか。ガチャと言うからには、決まっているのはガチャを回して得られる対価以外は神のみぞ知るセカイと言うことなのだろう。本来の意味でのガチャは小銭を入れて回すが。

SIプロジェクトで誰がガチャにしているか

SESは業務委託であるから、SIプロジェクトも維持管理もほぼ、あらゆるITに関する契約を包含する。なぜかはわかると思うが、請負契約も準委任契約も業務を請け負うからである。請負契約以外は派遣契約である。

では、請負契約であるSIプロジェクトをガチャにしているのは誰だ、と疑問が生じる。

通常、契約を結ぶ権限を持つのは営業である。営業を置かない組織では管理職がそれを行うこともあるようだ。

いずれにしろ、契約を結ぶ権限を持つロールが案件を見積もり、交渉にあたる。それを担うはずの権限者に案件がガチャかどうかの目利きができないと言うことになる。

SIプロジェクトがガチャか判断するなら

 請け負うには『何を』請け負うか、知らなければならない。何に対して成果物を納める履行義務を負うのか明確でなければ請け負うことはできないのである。

受託する『予定』の案件の要件、諸条件、指定される適用技術などを理解しなければ、請け負えるかどうかを判断することはできない。

逆に言えば、請負契約にしろ、準委任契約にしろ、派遣契約でなければ見積もりができなければならないし、何を履行するか見積れているのであれば、見積もり前提条件が付されなければおかしい。

SIプロジェクトをガチャにしてしまうのは、

  • 成果物の定義をしていない
  • 見積もり前提条件が提供時間しか存在しない

かどうかで判断できる。

見積もり仕様を出せばガチャ度は下がる

 引き合いがあり、話を聞きに行く。QCDSのようなSI案件の諸情報を尋ねるだろう。さらに、案件に見合うエンジニアがいるならSI案件のどこを引き受けられるかスコープを詳細に尋ねるだろう。

こうしたヒヤリングは、委託元のSI案件の理解度、確度、客バカ度を見極めるのに役に立つ。

ヒヤリングで網羅的に、SI案件を請け負えるかどうかの観点で聞き始めると相手の本気どもわかる。

ここで相手が説明を嫌がる場合は、ガチャ度が高い。要件が曖昧、委託元の予算が少ない、工期があり得ないほど短い、など諸条件のどれかか複数に危うさが確実にある。

だから、説明を嫌がる。

そうしたSI案件は高い条件を出すかエンジニアのタイミングが合わなとしてやんわりと辞退することが望ましい。

受けるにしても、危うさは価格なり工期なりに超過して計上しておく。

委託元が必死に引き止める時もガチャ度が高い。過去に失敗しているか、委託元内で無理なコミットをしているかさせられているか、である。

そういったSI案件であれば、スコープを分解して、危うさを回避するか、他社を立て、恣意的にアンダーに入り、諸条件をてんこ盛りにして危うさを転化するのが望ましい。

何も好き好んで悪条件で請け負う必要はないのだから。

SIプロジェクトはガチャか

 結論は何を履行するか見積もりしていないから自らガチャにしているのではないか。

つまり、案件ガチャとかそもそもが馬鹿らしい話なのである。

 

 

FLAG. 7.0「Singing in the Rain」

FLAG. 7.0「Singing in the Rain」