GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

なぜ受託開発は非効率になってしまうのかを考えてみた

受託開発が抱える本質的な非効率性に関する考察 - GeekFactoryを読んだ。

受託開発をやる以上は上記エントリで指摘している問題が出てくることが多いので留意したい、という注意喚起として読んだ。「本質的に非効率」の意味が「どうあがいても効率よくやれません、残念でした。」という風に読み取れるので、違和感を感じた方もいたのかもしれませんが、残念ながら効率を上げられる要素が少ないので効率性には限界があります。

というか、受託開発が非効率なのは製品をそのまま適用するのに比べたら当然なので、その非効率なポイントを議論して何を導きたいのだという気もする。出来合いのモノを使うかオリジナルを作るかの区別もつかない段階で効率以前の問題だろ、というちゃぶ台返しの極論を言ってみる。そこに端を発して、工数かけた方が儲かる単価商売の悲しい性で丸投げと縦割りが重なってしまい、ますます「どうしてこうなった」状態になっている気がする。

設計書はレシピのようなものだ。図面とは違う。図面を見れば、できあがるモノは予想できるし大きくはぶれないのでチェックポイントも限定的だ。「なんだこの建物は!」という話にはなりにくい。だが、レシピの場合は読み手によって意味合いが異なってくる。想像されうる結果が異なる。

エンドユーザーはレシピを読んでも何ができるのかわかるわけがない。口に入れないと正しく判断するのは困難になる。だからと言って、レシピはほどほどに「トマトソースのパスタ」って完成図だけ用意してひたすら料理作らせて「口に合わないから下げろ」というのは、とんでもない話だ。なので、効率を良くしたいなら選択肢を絞るしかなく「これしかできないので、これから選んで頂戴」と言うしかない。

こういった非効率性が別の非効率、いわゆる「車輪の再発明」を生んでしまっているのは否めない。ある意味不可避なのでは、という気もする。受託のような一品モノは担当者にスキルやノウハウが従属される。内部の業務改善的なノウハウは組織として活かせるだろうが、成果物を横串にして直接お金を稼げるサービス・機能を部品化して使う、というのが非常に難しい。これが「受託は商売として限界がある」と言われる所以のように思える。

受託開発は元々非効率ですので「用量用法を守って正しく見積もりを提示しプロジェクトを立ち上げましょう」というオチがつきました。

この辺を鑑みると、恐らく今後は「なんでもかんでも受託で食えない」→「人があぶれる」→「ある程度他業種や別の業界に技術者が流れる」→「そこで内製なり提携したサービスが事業化される」という流れが加速していくんじゃないのかなと思います。

SQLを学習できるWebサービスを作りました。