受託仕事は間違っている

2021年4月8日木曜日

システム開発 システム業界問題 閑話

t f B! P L
 
ツイートにこんな意見が流れていたのを目にした。
 
 
 
私も以前から、ほぼ同じような事を考えていた。
 
正鵠を得ていると思う。
 
多重請負など元請けがプロで、同じプロの下請けに発注するケースは別だ。
 
しかし通常は発注社は別の業界の業者で、ITシステム開発では、発注社は素人である。
だから受託開発では必然的に「素人が玄人に発注する」体制になってしまう。
これでは体制的に初めから良い仕事ができない事になる。
これは愚痴や文句の類ではない。
 
正直、この話を愚痴や文句にしか聞こえない人には永遠に分からない話なので、そう言う人はここでこの文章を読むのを中断して欲しい。
 
問題は発注社側が「何をどのように要求すれば良いのか分からない」という事と「受託社側は発注者に従わなければならない」という問題である。
 
ITシステムの専門知識は受託社側が持っている。
しかし、対価を支払うのは発注者なので、意思決定権は発注者が持っている。
素人が権限を持ち、玄人の方が権限を持っていないわけだ。
 
データを一覧表示するにしても、今あるコンポーネントでどんな表示が可能で、どんな表示が不可能なのか。
その知識を認識していなければ、依頼を出すことすらできない。
その知識を受託者が発注者に全て伝えるのは通常は不可能だ。
情報量が多すぎて発注者が学習している時間が無い。
受託者も説明や資料を作る時間は取れない。
 
つまり発注できないという事だ。
 
私は以前から受託開発や受託ビジネスというものは、ビジネスのやり方として間違っていると思っていた。
 
失敗確率を減らすための施策は色々ある。
 
今有力なのはアジャイル開発の導入だろう。
開発の初期段階だけ反復開発をするウォーターフォールでも良い。
システムを細分化して開発するマイクロサービスなどの構成もある。
 
ただどれも根本的な解決にはなっていないように思える。
 
ITシステム開発に関して理想を言えば、発注者が自分でシステムの開発をやるのが一番良いと思う。
 
つまり発注しない。
 
理想から考えれば受託開発を利用しないのが正しいという事になる。
 
逆に受託開発を正しく利用しようとするなら、発注者が受託者と同じ専門知識を持っている事が望ましいという事になる。
 
ITシステム開発で言えば、発注者がシステム開発を内製しており、その仕事の一部を外注するというやり方が正しい。
 
これはあくまで理想論であり、現実的な話をしているわけではない。
もちろん理想を実現できる人はしたら良いと思う。
 
現実世界では、理想の少し手前の、少し劣った選択肢というのがありうるし、そこそこ使えるものだ。
 
そこを考えると、やはりアジャイル開発のように、発注者と受託者がお互いに試行錯誤しながら、何度も失敗を繰り返し反復開発するのが現実的な受託仕事のやり方になるだろう。
 
正直なところ、コストは結構無駄になる。
 
しかし、発注者と受託者がお互いの仕事の内容を知らないのだから、互いに学習コストがかかるのは避けられない。
 
結局、受託仕事というのはどちらにとっても、あまり効率の良い働き方ではないと言える。
 
最初は受託仕事でも良いが、しばらく経ったら発注者は内製化した方が良いし、受託者は自分の製品作って販売した方が良いと言う事になると思う。
 
結局、私の結論はいつも同じだ。

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ