プロマネブログ

とあるSIerでプロマネやっているオッサンです。主にシステム開発ネタや仕事ネタ、気になった三面記事ネタの解説なんかしてたりします。

「多重請負」が優秀なエンジニアを幸せにできるかもしれない

ビジネスモデルの違いはエンジニアの価値を毀損しない - プロマネブログ

 

前回記事に幾つか言及いただいた言を受けて、もうちょっとだけ書いてみます。

 

 

エンジニア価値のあれこれ

前回の話について、もう少しだけ整理してみます。

 

まさにこの、ユーザが必要とする価値と、ソフトウェア原価のと差異が、生み出したソフトウェアの価値です。 

 

元請けを主体に取り扱っているオッサンは、受託開発におけるシステムの付加価値を以下の様な式で見積もってます。

 

システム価値 = システム売上 ー システム原価 ・・・ ①

システム原価 = Σ(必要工数×人月単価) + インフラ費用 + 諸費用

 

上記の式から、エンジニアが生み出した価値(=システム価値)を高めるには

  • より高い需要を分析し、システム売上が高い案件を取ってくる
  • 開発効率を向上し、必要工数を下げれば下げるほど価値が上がる

という認識で考えます。

よりユーザがほしい物をより効率的な開発により、高い付加価値を創造できるという考えですね。

 

 

これに対し、「人月商売」と問題視されるパターンでは、以下の様な数式が成り立ってます。

 

売上 = 人月単価 × 請求工数 ・・・ ②

 

まあ、シンプルに人月単価に対し、需要工数を掛けて売上とする形です。

この場合、個々人の能力は無視して、人月単価の中に利益(=平均的なエンジニア価値)と原価(=給与や福利厚生費)などをまぶす形となるため、「能力を無視している」「エンジニアの価値を既存している」となるわけですね。

実際のところ、二次請け、三次請けとの間での契約の場合、このような形になってますね。。。

 

とまあ、同じ「人月を原価に使って商売している」という話ですが、①、②の両式では様相がかなり違う感じとなります。

※元記事のpaizaの話は、元請けの話なのに②の形で記載していたので、ツッコミをいれてました。

 

 

「多重請負」が問題解決の鍵を握っているんじゃあないだろうか

 

上記の②の式ですが、ずっと違和感に感じていたことがあります。

 

よく、多重請負構造なんて言われているSIerなんですけど、「請負」契約にて契約金額根拠で②式を使うのはおかしいよなあと思うわけです。

上記②は「成果物」ではなく「工数」がコスト根拠になっているわけで、「請負」ではなく、「SES(=準委任)契約」を表しています。

多重請負構造において、本来であれば、①に準拠した式が使われていいんじゃあないかなとつねづね思うわけです。

 

この裏についてはおぼろげながら把握しており、本来であれば請負なので成果物をベースに契約を結ぶべきなんですけど、ひょんな事で工数超過となってしまった場合の追加工数を元請けに請求できなくなってしまうとか、見積もりが甘かった場合の追加工数を元請けに請求しづらくなってしまうとか、諸事情があるわけで。

 

で、これは単にパートナーさんの問題だけではなく、元請け側の問題として、きちんと成果物定義ができておらず事前の成果物定義を合意が取りづらいとか、要件をがっちり固めきらず要件変更の可能性があるため成果物を固めたくないとか、もろもろの事情があるわけで。

 

つまり、多重「請負」構造といいつつも、まともに請負ができていないという現実が人月ベースの準委任契約式の契約を常態化させているんじゃあないだろうかって思うわけです。

 

 

思考実験的。もし、きちんと多重請負ができていれば。

 

二次請け、三次請けは元請けとの契約を「成果物価値」で結ぶ形となります。

例えば、元請けの要求に従ってソフトウェア2本納品して200万円、なんて契約を結ぶ形となります。

 

これを二次請け会社内の標準的なプログラマが1ヶ月かかって開発・テストすれば、実質人月単価は200万円の仕事をしたことになります。

 

二次請け会社内の優秀なプログラマが例えば1週間で開発・テストすれば、実質人月単価は800万の仕事をしたことになるわけですね。

※エンジニアの稼働率が下がってしまいますが。。。案件調整は必須ですね。

 

 

で、二次請け会社側ではきちんと実質単価を向上させたプログラマに対して、きちんと報酬を払うようにすれば良いわけで。

※例えば、実質単価の30%を給与にするとかできれば。。。

 

 

このように、きちんと「多重請負」が成り立つのであれば、プログラマのスキルを「人月単価」に反映させることが可能じゃあないかな、なんて思うわけです。

 

※このモデルだと、きちんと保守性などを定義しておかないととりあえず動くソフトが納品されて保守が大変になったりするので、きちんと最初に機能要件だけでなく、標準化や性能要件など含め非機能要件含めて成果物定義することが必須となる感じですね。

 

 

きちんと検証してないのでザルな極論ですが、一つの解にはなるんじゃないかなって思います。

 

まとめ

まあ、だらだらと書きましたが、オッサンの職場でこの二次請け、三次請けに関する人月の話は明確には解決出来ておりません。

色々な壁がおおすぎて、明確な解決策を実現できてないって感じです。

 

元請けのオッサンの会社内部でも、こういった成果をどのようにパートナーさんと共有すべきか、議論したりもしてます。

まあ、パートナーさんも含めて共存共栄の道は常に考え続けなければいけない話でしょう。

 

そんな状況で、せめてもの改善策として導入しているのが生産性向上による残業0調整。

同一契約金額でも、仕事の実働時間が短ければ短いほど、実質的な単価が上がるってもの。元契約金額には、ある程度残業代なども織り込まれているはずなので、残業0ならその分だけ単価が上がるって感じかなと。

 

ほんと、些細な話ですけどね。

 

 

以上