内製と外注の基本理解
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラノムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の大島里、賑やかし役の辰巳です。よろしくお願いします。
さて今回のタイトルなんですが、内政か外中か、その判断をこう分けようというタイトルになっています。
昨今、AIの発達が目覚ましい中、ある程度のことをコードが書かない人でも作れるような時代になってきている中で、改めてプラノムザでは内政とか外中とかどうやって切り分けていくのかなということを、
ちょっと鴨志田個人的にも気になりまして、島田さん、辰巳さんにぶつけてみようという回になっております。
まず内政か外中かっていうところを、とても基本的なことだと思うんですけども、辰巳さんこれでお説明していただいてもよろしいですか。
それぞれの定義的な意味ということですね。
そうですね。
内政かは自社でエンジニアをこさえるっていう意味だなというふうに思っていて、そこの手法という点では正社員で雇ってもいいと思いますし、
フリーランスをいくつか抱えても全然ありなのかなと思っています。ただちゃんと出社させたりだとか、
あとはちゃんと上司になる人がいたりして、統制の効く体制、チーム編成というのを行っているというのが多分大前提かなというふうに思っています。
なので何もしなくてもランニングで費用が発生する状態っていうのが多分言い換えるとそれに近いのかなというふうに思っています。
外中に関しては逆に言うと、抑えようと思えばいつでも費用を抑えてあり、最悪ストップをかけられる状態でして、
じゃあどういう形でそれを実現するかという話で言うと、先ほどフリーランスという話もありましたけれども、
まるっとやりたいことだけ伝えて、実際にアプローチとか納品物の保証みたいなところは任せるっていうような形から始まり、
それが個人だけではなく我々のような受託開発の企業であったり、あるいはSES、過去のエピソードでも
SESと受託開発の違いみたいなところをいろいろ話したと思うんですけれども、そのSESに完全に委託をする。
でもSESになってくるとちょっと内製と外注の間、中間みたいなところももしかしたらあると思うんですけれども、
完全に外注っていうふうになってくると、うちみたいな、いわゆるベンダーですよね、開発ベンダーにまるっと委託するみたいなところになってくるんじゃないかなというふうに思いますよ。
ありがとうございます。市松根の意識でお方相互ないという感じですかね。
そうですね。指揮命令系統の話になるのかな。さっき上司がいてっていう話をしてましたけど、それがあるのが内製だと思うんだよね。
契約形態はいろいろとあると思うんだけど、誰かの指示に従って作ってたら内製じゃないですかね。
なるほど。
だけどその辺は任せるんで、ちゃんと成果物だけいいものを出してもらえば、やり方は任せるっていうのは外注なのかな。
そうですね。やりたいことだけ伝えて出てくるのを待つというとちょっと言い方悪いかもしれないですけど、一緒に考えながら作るっていうところですかね。
ありがとうございます。プラムザでは昔内製もしていた、今は外注もして、どちらも経験があるという認識なんですけど、
内製と外注のメリット・デメリット
島田さんからざっくりそれぞれのメリット・デメリット、他の回でも話していることかもしれないんですけれども、改めてお伺いできると嬉しいですが、お願いしてもよろしいでしょうか。
そういう意味では、今回の話は基本的にはユーザー企業、開発会社じゃない企業の話がメインだと思うんだけども、
開発会社も内製している会社と外注に任せる会社は2つあると思うんだよね。
うちは基本的に100%内製でずっとやってきたんだけど、最近は内製率がかなり下がっていて、多分90%以上が外注になってるかなという形になってますね。
内製は辛いのはやっぱり人件費ですよね。
先ほど辰巳さんが言っていたラーニングコースというところですかね。
そうだね。仕事がなくても人件費がかかってくるっていうのがあるんで、それが非常に辛いところだね。
雇用してしまうとなかなか仕事がなくてもチーム解散できないっていうのがあるので、
そうすると一生懸命ですね、その人たちを食べ捨てるために仕事を取ってこなきゃいけないと。
その辺のあれは知識感といいますか、シビアな感覚は非常に激しいものがあるので、
外注の方はその辺は仕事があったらチームを組むっていう感じなんで、
気楽っていうか、気楽は気楽ですね。
お話聞いていて、まず一つ明確というと僕が勝手に思った判断基準かもしれないですけど、
組織規模とか資金力っていうのは結構重要なんじゃないかなと思っていましたね。
例えば内製化って我々が話している通り、毎月お金がかかってくるわけですし、
いればいるほどかさむじゃないですか。
それに関しては吹いて飛ぶような会社では実現できないのかなと思っていて、
やっぱり中小企業の生き残る戦略っていう風になってくると基本的にやっぱり外注になってくるんじゃないっていうのはちょっと思ったりしました。
それはどうかわかんないけどね。
本当ですか。
10年前はうちの内製技術が高かったけど、
確かにそういうの。
今の方が売り上げが上がってるからな。
それはそうなんだけど、あとはやっぱり何を目的にするかっていうのがあって、
やっぱりチームをずっと抱えていて、ノウハウを社内に蓄積しておきたいっていうのがあると内製の方が良かったりするよね。
確かに。
でもそれで言うと、我々途中から外注に変えるようなスタンスを取ってますけど、
それでもノウハウが蓄積できてないかっていうとそうではない気がしております。
そこはちょっとプラムザは特殊ですよ。
元々発想は内製でやろうっていう発想から来ていたんだけど、
判断基準と企業の相談
外注を合わせてチーム組もうって話になって、
それから外注ばっかり集めてやってるんだけど、
チームっていう意味ではチームなんでね。
頻繁にその辺のフレア捕まえてきてチーム組んだわけじゃないので、
常に同じメンバーでやってますからね。
そういうことですね。
雇用携帯は正社員じゃないけれども、ちゃんとオーナーシップを持ってできる人がいたりだとかっていう技術力があって、
人柄もするレベルですね。
改めて思うんですけど、プラムザはとても説明がしづらいですね。
内製か外注か。
いや、いいんじゃないですか。
切り分けることもなかなかないですね。
特性なんでね。
ちょっと話を戻りまして、改めて。
では、内製か外注かっていう切り分けをユーザー企業様が決めていくときにはどういったことを、
そもそもこういった相談って島田さん多かったりします?あったりするもんですかね?
ありますよ。やっぱり内製、どこの会社もだいたいはですね、はじめは内製で考えていくものだと思うんですよね。
なるほど。
パソコンに詳しい人とかが、エクセルとかね、ファイルメーカーとか使って、
なんかちょっと作ってみようかみたいなね、社内のちょっとしたシステムだったら。
っていうところから始まるのが普通なので、それは内製ですよね、完全にね。
で、作っていくんだけど、手に負えなくなってきたとかですね、チーム大きくなりすぎちゃって、
結構喧嘩状態じゃないけど、派閥ができちゃってなかなか先進まないとか、
そういう悩みから外部のね、ベンダーにちょっとお願いしたいっていう相談も結構ありますよね。
ありがとうございます。そういった相談がプラムザにも送るというところの中で、
辰巳さん、これどこを切り分けて考えていっていたりするものなんでしょうか?
これは内製がいいのか外注が良いのかみたいな相談を受けたときには。
そこのカルチャーとかにもよるかなと思う。
いろんな判断軸があると思うんですけど、まず何を成し遂げたいかっていうゴールだったりだとか、
あとはその手法をどういうふうに考えているのかっていう感じですよね。
それがもうキンキンにやんなきゃいけないんだったら、やっぱり外注だったりすると思うんですよ。
例えばですけど、長期間によってまず概念からディスカッションをしていって、
プランを熟成させた上で、じゃあプロダクト作っていきましょうとかシステム作っていきましょうってなると、
多分そこの議論って本当に内部で会社の歴史とかフードを理解している人たちがやる必要があると思ってて、
エンジニアの人たちって多分そこに入りたくないっていう部分もあったりするんですよね。
実際にどういう技術でできるんだろうとか、どういうノウハウを得られるんだろうとか、
自分の軽減値になるんだろうっていう観点で結構考えがちなんで、
そういった意味では内製化する部分では時間がかけてやりたい場合は、
そこでどこかのタイミングで言えるみたいな話割だと思うんですけど、
じゃあもう本当に何か別にビジョンとか何もいらないからとりあえず動かせるものを作ってって話になる場合だったら、
まず外注を選ぶんじゃないかみたいなところが一つ判断軸としてあるかなと思いますね。
なるほど、基本的にある種、
ピード感を持ってシステム開発を行っていきたい場合は、
基本的には外注の方が早い、単純に早い。
あとは何かさっき言った話ですけど、上司が指揮系統を持っている、
内製と外注の判断基準
リーダーシップとってやれる人が、内部でいたら内製を考えてもいいと思うんですけど、
その人のITリテラシーの部分もあると思いますし、
じゃあその成し遂げたいことに対しての技術アセットが現状内部にあるのかとか、
それを長期間育成してやっていけるのかっていうところに多分なってくると思うんですよね。
そこを耐えられる土曜と資金力があるのかみたいなところ。
そうですね、それはある種人材リソースって言っていいんですかね。
まあそうだと思います。
社内にこうやってできる人間がいるかどうか、
そこの人が技術難易度も含めて精査できるかどうかっていうところって感じですかね。
あとはまあさっきこれはまあ確かにプラムザの事例もそうだと思うんですけど、
社長のこだわりも一つ出る気がしていて。
こだわり。
例えばですけど、しわんさんとかってエンジニア出身だから、
そこら辺の理解があるから内製もできるし、
そこから発想を転換して外注に変えていきましたけど、
多分別にこれが悪いって言ってるわけじゃなくて、
実際そうだと思いますっていう話なんですけど、
営業でゴリゴリやってる人が多分内製化とかあんまり考える余地がない気がして、
とか、全くIT畑じゃない人たちが立ち上げられた会社っていうのは、
外注にした方が多分その先ほど言ったカルチャーフィット的な部分でも
いい進み分けができて、
そっちの方が結果的にうまくいけやすいんじゃないかなとか思いますよね。
ありがとうございます。
アジャイルとラボ型開発の導入
では島田さん改めて、
内製化外注化っていうのを島田さん的にはどう切り分けて考えているのかお伺いしたいと思います。
そうですね。
辰巳さんが大体言った通りかもしれないけど、
あとはその混合もあるからね。
内製でやっててその中に外注の人間一部入れてやっていくっていうパターンもあるでしょうし、
だからまあいろいろなパターンがあると思うけど、
過去にうちに相談に来た中では、
割と大きな会社、割とっていうかかなり大きな会社さんで、
30人規模の開発チームがいるということなんだけど、
3チームに分かれて10人10人10人でチームを作ってやってるんだけど、
うまく回っていないということで、
うちのラボ型にちょっと興味があって、
1チームだけそのラボ型でやってみたいと、
アジャイル的にですね。
1チームだけ。
そうそう。
何が目的かというと、
それは3つのチームをまとめてる経営者の方から相談を受けたんだけど、
何が目的かというと、
そのチームをうまく回して、
ラボ型でアジャイル的にやっていくっていうのが、
すごいいいものだっていうことを、
あとの2チームに見せつけて、
みんなに真似させたいっていう、
そんな感じの構想だったんだよね。
だからうち2人マネージャークラスを1チームに入れてもらって、
そこでグイグイ引っ張ってもらいたいって言われたんですが、
結果的にお断りしたんだけど、
やっぱりさっき言ったみたいな、
アジャイルとかうまく回るのって、
チーム全体がうまくまとまってないとできなくて、
いきなりそういうとこにマネージャーが2人入っていったら、
うまくいくかっていうと、そんなこともないわけなんでね。
そういうわけで、その時はお断りしたんだけど、
なくはないスタイルかなというふうに思ったんだよね、その時もね。
なるほど。
そう考えると、そういう意味で、
内政は内政でいいとこもあるし、悪いとこもあるし、
外中はその反対もあるんで、
それを混ぜ合わせていいこともあるし、悪いこともあるし、
その都度その都度考えていくべきだと思いますけどね。
途中で変えるっていうぐらい柔軟な思考と言いますか、
合宿で変えるというか、
そういう意味ではないんですかね。
そういう意味ではないんですけどね。
途中で変えるっていうぐらい柔軟な思考と言いますか、
がっしり、どっしり構えてやっていくぐらいの感じがいいですよね、決めつけないで。
基本的に成功はないので、成功じゃない、成功はないわまずね。
正解はない。
正解はない。
正解はないので、やってみてね、調整していくしかないと思いますよ。
なるほど、ありがとうございます。
基本的に辰巳さんがおっしゃっていただいたスピード感とか、
技術難易度とか人材リソース、
あとはこの先をどう考えているかっていうとか、
ノウハウを蓄積したいかっていうところになってくるのかなと思うんですけども、
単純に正直そこだけで終わりきれないっていうところが
実際のところなのかなっていうふうに聞いていて、
思いましたので、どうですかね、
プラムザにご相談くださいっていう仕組みになるんですかね。
無理やりこっちに持ってきたりはしないので、
コンサルティックにアドバイスはしてもらえるんで、
何でも相談していただければと思いますよ。
ありがとうございます。では本日はこんなところでいかがでしょうか。
いいと思います。
ありがとうございます。
本日はいかがでしたでしょうか。
楽しんでいただけましたらフォローや評価をお願いします。
また、Xでも最新情報を随時発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら、
公式ホームページから気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
