プロジェクトマネージャーの独り言「受注側の責務と発注側の責務」

IT業界で18年。
SIerでPMをやってきた経験から、PMとして考えている事を語っていきます。
今日も独り言です。

cocoaの騒動、同じIT業界に身を置く者として、残念でならない。あのような多重下請構造は、日本のIT業界では当たり前だから驚かないが、どうしてこんなにも酷いことになってしまったのか。

多重下請構造によるシステム開発では、関係する企業は発注側と受注側の関係性ができている。この時現場で起こるのは各社間での責任範囲の境界を決めること。

しかし、全てにおいて責任範囲を明確に分けられるかというと実際にはそうもいかず、このような不具合が発生すると、それは受注側の瑕疵だとか、いやいや発注側の問題だとかというやり取りが始まる。

それはビジネスとして契約している以上は仕方ないことなので良いが、この時、発注側がどうこの問題を捉えているかが重要なのだと、いつも思う。

受注側が契約の内容を満たす物を納品することは、当然の責務であるのは間違いない。ここが責務を全うすることが最重要ではあるのだが、その責務を全うしなければならない末端の企業や開発者には十分な予算も期間もまわらず、低予算・短期間での開発を強いられることが多々あることも事実。
だから、発注側もマージンを取っている分はしっかり仕事しなきゃいけない。

発注側は発注側としての責務は何であると考えているのか、そこを意識しているのだろうか。

多重下請構造の場合、発注側は受注側でもある事が多く、発注側として発注先の納品物を評価し、今度は受注側として発注元に納品しなくてはならない。この時、発注先の納品物が受注した契約を十分に満たす品質であることを担保することが受注側でもある発注側の責務であると僕は考えている。

この考え方には異を唱える発注側の人多いだろうと思うし、
実際にこのような考え方を話すと「それは受注側の責任だから、発注側としてはそこまで気にしていられない。気にする必要はない。」という反応をされる事が多い。

だけど、納品した物の品質が悪かった時に、発注先の問題、責任であるとするような発注側の考え方、正直嫌いなのです。

受注側でもある発注側が、受注側として品質を担保したうえで納品するには、それ相応のテスト、検品をしなくてはいけない。
だから発注側としてもコストかかるし、大変なのだけど、これは責務だと思う。

cocoaのケースでも、この発注側によるテスト、検品がどこかの階層で正しく機能していれば、未然に今回のような不具合は防げていたかもしれないのではと思う。

大元の発注元は、エンドユーザーに提供するシステム、アプリ、サービスの品質（機能や安全性など総合的に）を担保する責務がある。
その元請けは発注元に対して納品物の品質を担保する責務がある。
その下請はその発注元に対して納品物の品質を担保する責務がある。
さらにその下請は・・・と、その責務の連鎖は末端まで続く。
その責務の連鎖は途切れてはいけない。
それが途切れると今回のcocoaのような事態になるのではないだろうか。

これは綺麗事であって、もしかしたら現実ではなり得ないことかもしれないけれど、
発注側も受注側も、それぞれが己の責務が何かを改めて考えて欲しいな。
そして責務を全うしよう。

僕自身も己の責務が何かを見つめ直し、責務を全うできるよう努力しないといけないな。