「DXって？」　下請け技術者はどん詰まりの開発現場で要件定義の夢を見るか

以下は、8月に日経クロステックに掲載された記事の元原稿を校正したものになります。全二回の一回目分です。実際掲載された記事とは内容がたいぶ異なり、やや生々しい内容になっています。

●多重下請けの「彼」
「彼二つ下なんですよ」
ある時、一次請けの社員から若い技術者を紹介された。二十代後半だろうか、年齢が若い割には要件定義含む上流工程に精通しているとのことだった。
一次請けとは直接ユーザーとの契約を交わしているベンダーのことであり、二次請けの会社が各サブシステムを担当している。
これはある企業の基幹系再構築プロジェクトにおけるある日の会話である。

紹介された「彼」はさらに２つ下の人間なので四次請けということになる。
工程が始まる前に新しくアサインされたメンバーであり、彼が実際に要件定義をやることになるという話だった。
その現場はユーザーとベンダーの関係性があまりよくなく、ベンダーは完全に業者扱いを受けていた。またユーザーの一部担当者の恫喝まがいの言動がパワハラではないかというレベルであり、すでに数名の下請け技術者が心身に不調をきたし離脱している状態であったらしい。
そんな状態に放り込まれた彼はうまくやれたのだろうか？

上記は最近、IT業界で近しくお付き合いさせていただいている知り合いから聞いたエピソードである。

元々どんづまりの下請け構造の底辺でもがき続けた日々を過ごした経験を持つ私はこの話を聞いて胃のあたりが重くなった。
「何も変わっていないのかな」
私が抜け出したくても抜け出せない状態に陥って、精神的にも肉体的にもかなり厳しいダメージを受け続けたのはもう30年以上も前の話になる。
このあたりのは話は以前日経ｘTechに連載した「どんづまりから見上げた空 ～ 我がITサバイバル年代記」に詳しく書かせていただいた。お時間のある時にご一読いただけたらありがたい。
https://xtech.nikkei.com/atcl/nxt/info/18/00037/122700098/

いきなり知らない現場に放り込まれるはつらいものだ。
何階層めの下請けだろうがなんだろうが、とにかく「わからない」とは簡単にいえない。このあたりの事情は昔も今も変わらないようだ。自分の立ち位置がわからず、場合によっては実際のキャリア以上の内容で売り込まれたのかもしれないので「本当のこと」を口にしてはいけないかもしれないからだ。
当然、どのようなコミュニケーションをとってよいのかわからなくなる。
ここからは私の勝手な憶測であるが、彼は実はあんまり上流工程の経験がなかったのかもしれない。
「若いのに上流の経験が豊富・・・」少し盛ってるのでは？本当なら「彼」に対して失礼な話であるが・・・
一般的に綺麗に記入されたキャリアシートにはそれなりのキャリアが書いてあるものだ。しかし、実際に自分自身がキャリアを過大に粉飾された経験を持つ私には本当のところはどうなんだろう、という疑いを持ってしまう。

あとで聞いたところによると最近は世の中がうるさくなったので私の時代のようにキャリアシートに全く経験がない、うそのキャリアが書かれているようなことはなくなった？らしいが、本当のところはわからない。
昔のこととはいえ経験もないのに原発の制御システム開発の経験がある、と書かれて高く売られそうになった経験がある私には素直に信じることができない。（どうも歳をとってますますひねくれたのかもしれない）

少し脱線する。
下請け構造にて技術者のレベルを把握する際にキャリアシートを参考にすることになる。
ただこの内容を真に受けることこそ愚の骨頂はない。大体が綺麗にはまとめられている。経験システム、OS、使用言語、役割等が書かれているが、どの程度きちんとその仕事を全うできたのかよくわからない。

プロジェクトメンバー選定の際にはそんなシートを信用するより３０分面談して目をみて話をした方が早い。経験なんてなくたって本気でやる気があればまだなんとかなる。キャリアだけは重ねているもののなにもできず逃げることになれている下請け根性丸出しのベテランの始末が一番悪い。

では彼はどんな技術者だったのだろう。

知り合いは要件定義フェーズの途中からこのプロジェクトに関わったらしい。すぐに話をしてみたかったらしいが、入った時にはすでに雲行きが怪しく現場が浮きあしだっていたのですぐに時間はとれなかったようだ。
落ち着いた時点で彼に聞いてみたらしい。
「なんか変だったし、とてもうまくいかないとは思っていたけど、周りもそんな感じだったので同じようなやりかたをしてしまった」とのことだった。うまくいかなくても割り切ってしばらくユーザーの恫喝まがいの叱責に耐えていれば時間が解決してくれる（はず）とでも思ったのかもしれない。彼はすぐに離脱してしまったとのことだった。要件定義フェーズはすぐに暗礁に乗り上げてしまったという。

下請けの彼らには完成責任はない。時間を稼いで逃げる、それはそれでありの考え方だ。
こういった場合、契約形態がどうであろうと一次請けのみが完成責任を負わされることになる。
二次請け以下は完成責任を負う必要がない。表現は悪いが、技術者は逃げきれればOKだし、会社としてもリスクが少なく利ザヤを稼げる二次請け、三次請けの方がおいしい、ということになる。

●ベンダー多重下請け構造の根の深さ
多重下請け構造はこのIT業界だけの専売特許ではないようだ。
悪しき習慣のように言われることが多いが、この多重下請けはあまりに根深く強固な構造になっており、どうやら携わっている多く人の生活を支えている産業基盤になっているようだ。

ある時、このビジネス（SESというらしい）で儲けている会社経営をしている知り合いと久々にお互いの近況報告をした際に、私の近況について話したところ、
「まだそんなことやってるんですか？」と少し呆れられた。
私は年食っているが半分プータロー、半分現場に出てコンサルや技術者みたいなことをやっている。
「人を現場に放り込めば儲かりますよ。」
「自分で動かなくちゃならないなんて大変でしょう？早く現場なんてあがって人を遣う商売に替えた方がいいですよ」との暖かい？アドバイスをもらった。
「もし本当にやる気があれば紹介しますよ」とも言われた。
この魅力的な「悪魔のささやき」に少し心が動いたのは紛れもない事実だ。
どんな商売でも同じで失敗すれば目もあてられないが、ちょっとでも成功すればもしかしたらいい目をみられるかもしれない・・・
でも、どうなんだろう、これからの残された人生に私が新たにやることなんだろうか。そもそも私に向いているのだろうか・・・・
一度やるとやめられない、とも聞いたことがあるし・・・

他人がやっていることを非難するつもりはない。ただ今のところ（多分これからも）私がそれをやることはないし、たぶんやってもうまくいかないだろう。
（こんな考えをもっているのでいつまでたっても金持ちになれないのもまた事実か・・・）
これだけの強固な産業構造ができあがっており、儲けている人が一定数いるとなると、識者がいくら理想論を振りかざしても簡単になくなるものではない。ならばあるものはあるものとしてどうするかを考えるのみだ。

もし本当に社会としてなくしていくのならユーザーが内製化へのかじを本格的に切るなりのなんらかの抜本的な産業構造の変化が必要だろう。そのためには法改正が必要かもしれない。経済界の若返りも急務だろう。ただそれはまだまだ先の話だ。

もしどこかの開発現場で様々な下請け技術者に出会ったら、三次、四次請けの彼らが当たり前に最前線に立って開発しているという紛れもない事実を前提に物事を考えるべきだ。現実を直視して対応をしていくということだ。
私だったら、階層に関係なくまず人として付き合う。まずそこから始めることにしている。そして彼らのキャリアに少しでもプラスになるようなやり方を教えて、一緒にやっていく、これしかない。

彼らには間違っても自分のスキルにプラスにならないその場しのぎの逃げの姿勢をとれば将来自分の身に返ってくることはきちんとわかってもらいたいものだ。

●ユーザーとベンダーの関係性
開発プロジェクトにおけるユーザーとベンダーの関係性は、そもそもの企業としての関係性、他プロジェクトとの兼ね合いに大きく左右される。初めての関係であってもRFPから回答書提出の時点で大枠は決まってしまう。遅くてもプロジェクト開始時点で固定される。
つまり良好な関係を築いて開発プロジェクトを成功に導くためには「最初が肝心」ということになる。
よくユーザーの「丸投げ」、ベンダーに対する「業者扱い」が問題になる。
そういった問題は後から修正しようとしてもなかなかうまくいくものではない。
プロジェクト開始時の関係性は最後までそのままだ。変わることはほとんどない。
契約形態においても「準委任契約」と「請負契約」の境界は曖昧である。つまり関係性によってはベンダーが最終的になんとかするしかないということだ。
そんな有様だと、ユーザーから二次、三次請けの下請け技術者に対してパワハラまがいの恫喝があっても一次請けのベンダーは黙認し、結果的に見殺しにしてしまうことになる。

●ユーザーの主体性のなさ
要件定義に話を戻そう。要件定義はユーザーがやるもの、少なくてもユーザ主導でやるべきである、という考え方がある。
私も全くの同意見だ。
要件とは「実現すべき姿」であり、要件定義とはそれを明らかにする作業だ。
（みなみに要求とは「目指すべき姿」であり、要求分析、定義とはそれを明らかにする作業になる。詳しくは次回）
当然「目指すべき姿」「実現すべき姿」なんてユーザーしかわからないし、必然的にユーザーが自分のこととして実施すべきである。

しかし、実際のところはどうなのだろうか。先進ユーザー企業を除き、まだまだ相変わらずの丸投げがほとんどなのではないか。
例えば家を建てる際に要望を伝えればハウスメーカーが仕様化してくれるのと同じような感覚で、金を払っているのだからプロが形にしてくれるはず、という考えをもっている人も多いように思える。
（実は私はあながちこの考えは間違いとはいえないのではないかと思っている）
ユーザーの中には相変わらずのベンダーを業者扱いしていうことを聞かせるようなこともまだまだあるようだ。
そういった状態だとたとえ準委任契約であっても請負契約同様に成果物の完成責任を求めてくる。
また残念なことにそんな状態を当たり前のように受け入れてしまうベンダーがいるのも事実である。

丸投げ、業者扱いするようなユーザーには特徴があると思っている。
かなり偏った考えかもしれないのであくまで参考レベルとして読んでほしい。
そういったユーザーの特徴としては社内でおそらく減点主義がはびこっていることだ。オフィスに行くとすぐにわかる。雰囲気が暗い。社員の目が死んでいる。笑顔がない。
社内でもパワハラまがいが当たり前なのだろう。そして社内のうっぷんをベンダーにぶつけることになる。
システム担当は、とにかくうまくいかなくなりそうになると責任を回避するために「自分はきちんとベンダーマネジメントしているのにベンダーがダメなのでうまくいかない」という方向に話をもっていく。これは担当個人の問題というよりユーザーの企業風土、文化の問題なので根深い。

おそらくそう簡単には変わるものではない。これも下請け構造同様にあるものはあるものとしてどうするかを考えるのみだ。

さてこんな状況で要件定義をどうやってやればよいのだろうか？
最後にもう一度整理してみよう。

・当たり前ではあるが、システム開発プロジェクトにおいては一般的に「要件定義」という工程があり、当然なんらかの成果物作成が必要である。

・ユーザーの主体性が弱い。
・ユーザーとベンダーの契約は準委任契約のはずなのだが、よくある話としてユーザーによっては（特に大手に多い）は契約形態なんてそっちのけで完成責任を求めてくることが多い。ユーザーとベンダーの関係がややいびつである。
・もちろんベンダー側が毅然とした態度をとって拒否すればよいのでが、ほとんどの場合そんな度胸はなく、なし崩しにやらざるをえない状況に追い込まれる。
・さらに実際の作業は一次請けのベンダーがやるのではなく下の階層（三次、四次請け）のベンダーに所属する下請けの技術者がやることになる。

要件定義を成功に導くためには、コミュニケーションの密度を上げるしかない。たとえ今希薄であろうとも少しでも接点をつくる。それが大事だ。
次回詳しく私なりの見解を書かせていただく。