SESの概要
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳です。よろしくお願いします。
はい、では今回のタイトルですが、SESと受託開発、あなたのプロジェクトに合うのはどっちというタイトルです。
まずこれ、SESと受託開発とは何ぞやという話を聞いていかないといけないんですが、辰巳さん、SESって何でしょうか。
SESはシステムエンジニアリングサービスの略です。
多分その略語の正式名称を聞いただけで、何それっていうふうに思う人が大体だと思うんですけど。
簡単に言うと、エンジニアさんが基本的には、発注元の会社に出向というか、駐在というか。
だいたいフルタイムで稼働して、さもその会社のメンバーであるかのような形ですね。
その稼働した分に売り上げが、というか費用が発生して、お支払いしていただくようなビジネスモデルですね。
じゃあ、SESってシステム開発の業界における派遣みたいな認識であってますか。
おおむねそれで認識としては。
なるほど。
受託開発の仕組み
それと比較になるのかどうか、まだ現状だけよくわかってないんですが、
受託開発っていうのはどういった形になるんですかね。
本当に比較されやすいとは思うんですが、
受託開発は、準委任の契約の場合もあるんですけれども、一括請負の場合も当然ありますけれども、
相手先に徴収するような形ではなくて、
基本的には自社内で構成しているチームでクライアントからの依頼に沿って開発をする。
クライアントワークであることっていうのは同じなんですけれども、
価値の提供の仕方が、相手のチームに入って時間で稼働していく。
SESと違って、私たちがシステム開発要望をクリアするにはこれぐらいの費用がかかりますという形で、
お見積もりを出して、それに対して実際にサービス提供者側は、
実際にどれぐらいの費用が最終的に乗るかわからないですけれども、
なんとかそれを要望に沿った内容を開発して納品するっていうスタイルになってくるので、
似てるようでちょっと違うんですよね。
境界線が自社側になるのか、相手側になるのかっていうところで、
多分、受託開発とSESが大きく変わってくるんじゃないかなと思います。
なるほど。そうすると受託開発っていうものは、ある程度クライアントさんからすると
お任せするっていう形で、SESは単純に人が欲しい。
開発できる人が欲しいみたいな感じになるんですかね。
こっちの方が近いと思います。
よくも悪くも、確かに受託の方が丸投げ感はクライアント側に起きがち。
逆にSESの方はサービス提供者、ベンダー側が受け身になりがちだと思う。
確かに派遣しとけばいいかみたいな感じのイメージは。
とりあえず動いて、相手の言うことに従っておけば。
最近はそれだけではバリューというかサービスを満足に提供できてないから、
そこの主体性を持ってやりましょうみたいなところは全然あると思うんですけど。
島田さん、SESと受託開発の法則等ありますか。そんな認識であってますかね。
そうですね。
辰巳さんおっしゃる通りで、SESの方は派遣なので、
指揮命令系統がお客さん側にあるんですよね。
これを作ってもらいたいとか、やっぱりこうして欲しいとかですね。
どんどん仕様を変えていっても構わなくて、
言ってみれば社員のエンジニアと同じような形になるので、
言われた通りに作っていくと。
もちろんプロなんで、そんなことだったらぐちゃぐちゃになりますよという意見はするんでしょうけども、
とりあえず時間で働いているので、何を言われてもやっていく形になりますよね。
一方、受託開発の方はそういうことはなくてですね、
初めに要望を聞いて、それに対してこういうことですねという感じでお見積もりを出して、
そこから契約してスタートするので、途中で気が変わってとかですね、
こんな機能だったらこういう風になったらもっといいなと思ったりして、
追加の仕様変更は一般的には簡単には許されないということになりますよね。
そこが結構大きな違いかなと思いますね。
そうすると基本的にSESをお願いする会社さんというのは、
ある程度内部にシステム開発部みたいなものがあったり、
SESと受託開発の比較
それが分かっているチームや人がいて、
プラスちょっと人手が欲しいという時に使うのがSESって感じになるんですかね。
意外とそんなこともない気がします。ケースバイケースだと思います。
ケースバイケースですね、確かに。
どういった場合があるんですか。
例えばですけど、極端なパターンを2つ出すと、
本当にITの部隊がゼロですと。
いろんなSESの会社さんに声かけて20人のエンジニアチーム、
というかITチームを作りたいです。
というので一斉にかき集めて、
じゃあ1人リーダーを立てて、サブリーダー2人立てて、
そこの20人のチームで、これやりたいから後はよろしくみたいなことも全然あるし、
既存の社内だけのエンジニアチームがいる中で、
ちょっと1人欠員が出ちゃったんで、
新しくちょっと1人を暫定的に補充したいです、
というようなケースも全然あるから。
なるほど、確かに今の話を聞いていると、
ちょっと人手が足りない時に、
ということのSESのイメージつきやすかったんですけど、
丸々チーム作りたいってことでもSESで活用される場合もあるってことですね。
あると思います。
例えば自社サービスの提供している会社とかあるじゃないですか。
そこで採算が立たないうちって、
受託の業務とかも受け取ったりするんですね。
時に例えばその受託の業務に関しては、
フリーランスとかSESからかき集めたチームで、
そこで得たキャッシュを自社開発のエンジニアの工数に当てていく、
みたいなものがよくあると思うんですね。
なるほど、なるほど。
そういった活用方法もできるとなると、
今回のタイトルがSESと受託開発、
あなたのプロジェクトに合うのはどっちっていうタイトルにはなるんですが、
これなかなか線引き難しいと思うんですが、
島田さんいかがでしょう。
これどうやって定めていけばいいものなんですか。
そうですね。
やっぱり大きな違いは、
自由にエンジニアを自由度高く使っていけるかどうかっていうのは結構違うので、
受託開発の方はやることを決めて要望を出したんで、
それを作ってもらうっていうのがゴールになるわけですよね。
そういう案件には受託開発の方が向いたりしますけども、
そうじゃなくてさっきみたいな、
外部から非税人を稼いでもらうと、
よくラーメン代とかって言いますけど、
とにかく運転資金を稼がないとですね、
自社開発も進められないので、
生きていけないので潰れちゃうんで、
外部の他の仕事を取りながらやっていくみたいなことも当然できるわけですよね、
SESだとね。
メンバー余ってれば他の仕事もやってもらえることがあると。
開発仕事じゃないと流石に嫌がると思うんですけども、
開発の仕事だったらやってもらえることになると思いますんで、
あらゆる仕事がやってもらえるし、
仕様変更も簡単にできるしっていうことになると思うんですよね。
その違いじゃないですかね。
なるほど。
SESに関しては何でしょうね。
やっぱり概算見積もりっていうか、
人月単価で時給制だったり月給、月払い制みたいな形で生産していくんで、
ちょっともう予算オーバーだなとかいらないなと思ったら、
よく悪くも切りやすいというか、
逆に人を取りやすい増やしやすいっていうのはあるかもしれないですね。
なるほど。
これ、プラムザは受託開発になるんですよね。
そうですね。
代表島田さんなので聞きたいんですが、
SESじゃなくて受託開発にした理由っていうのはどういったところになるんですか。
うちがSESやらない理由ですかね。
そうですね。
SESやらないんですかっていうお客さん、
結構何回も問い合わせきて、毎回やってませんって言ってるんですけど、
やっぱり人を出してしまうとですね、
仕事っていうか安定的に利益は上がってくるんですけど、
あれですよね、ノウハウ打ちくちきされないし、
感謝されることがあんまりないじゃないですか。
いった人はですね、感謝されてると思うんですけど、
会社としてはダイレクトに感謝が伝わってこないし、
何をやってるかわからないみたいなことになりますんで、
それは非常に開発会社としては面白くないなっていうふうに私は思うわけですよね。
さらには帰属意識も社員さん、スタッフさんに芽生えにくいんですよね。
そうそう、どこの人間かわかんないって自分がね、ってなっちゃうんで、
会社で忘年会やるよって言って、みんな初顔合わせみたいな感じになって、
おたくはどこに行ってるんですかみたいな、浜松町ですとか新橋ですとかって、
ああそうですかみたいな感じで、よそよそしい感じになってね。
確かに会社でのチーム化みたいなのはほぼゼロですもんね、SESってなると。
そうなりますよね。
なるほど、これ単純な疑問なんですけど、
派遣会社とかSESの会社さんって、
どうやってそれこそメンバーのモチベーションというか、
そこの帰属意識とかそういったものを管理してるのかなって聞いていて思いましたね。
ちょっと本文とはだいぶ脱線すると思うんですけど。
確かにどうやってるんでしょうね、僕ら受託だからわかんないんだから。
変相だなっていうイメージですね。
そうですね、うちも来てもらったことは1回2回あるんですよね、SESね。
あまりにも人足りなくてですね、ちょっと来てって言ったんですけど、
モチベーションは高くはないですよね。
SESはやっぱりモチベーションは高くならないものですか?
やっぱり高くならないですね、いればお金になっていくんで。
Nが1とか2なんで、その辺はちょっと分からないですけど、人によるのかもしれないですけど、
基本的にはこの言語で開発っていうんで、私できると思って手を挙げてくれたみたいな、
そんな感じで来てもらったんだけど、あまり実際はできなくてですね、
ちょっと触ったことある程度で、即戦力とは言えないなってなって、
チームの中でちょっとなかなかお任せできる仕事がないなみたいな感じで、
孤立していってしまうみたいなね。
そうすると、島田さんのSESの派遣の会社に連絡してくださいよとか言われて、
SESの特性と課題
俺が連絡するみたいなね、ちょっと難しいみたいですよみたいな。
手を借りたくて行ったり、手を離したいから人を入れるのにあんまり意味がないっていう風になっちゃうんですね、
そうすると管理とかも含めて。
うちの場合は開発会社なんで、正社員として来てもらえば一生懸命教えて育てようっていう気もするんですけど、
SESで来てもらうとですね、もうそういう気持ちはないですよね。
即戦力でガンガンやってもらわないといけないっていう感じになるので、
ちょっとできなくて実力不足だなと思うと、とりあえず変えてもらおうかみたいな感じになりがちですね。
本当にできる人はおそらくやっぱりフリーランスで独立してたりだとかっていうこともあるので、
期待値の調整だったりだとかカルチャーフィットっていうところは結構一生起きている課題なのかなって思います。
そうですね。難しいですよ、SES使うっていうのは。
うちみたいなプロでも使えないので、
ああいう人がエンドユーザーのところに入って何か作るっていうのはなかなか難しいとは思いますけどね。
それも人にもよるのかもしれないですけどね。
人手が足りないときに単純に人欲しい。
それが即戦力として動いてくれればそれはもう万々歳ですよね。
それで回れば十分ありがたい話だと思うんですが、
やはり外部から来るということで多分社風と合うかどうか、そもそもその技術があるかどうかっていうところは正直来てもらうまでわからないっていうところはありますもんね。
そうですね。チェンジはしやすいんですけどね。
その分受託開発であればある種、もちろん単純にお任せというわけにはいかないと思うんですが、
ある程度決まったチームだったりマネジメント方法がある中でそこに一連してお任せできるかつ、
ある種の責任全体を受託開発で受け入れることができるので、それを何とかしてくれるっていうところもありますね。
SESであればダメであればまた変えなければみたいなところのマネジメントも発生してくるっていうところですかね。
受託開発の利点
気にする必要はないですよね。
受託開発の会社においても通常の会社だと所属している人材に対して案件は手配する
人ありきの案件。
じゃあこういう技術が得意だからこういう案件取ってこようみたいな。
それってなかなか難しい話じゃないですか。
それが案件があるわけでもないし、案件に提言しても受注できるわけではない。
プラムザは逆でして、案件に対して人を集めるスタイル。
簡単に言うと選り好みしない基本的にありますね。
なんでそれができるかっていうと事業部制というのを導入している。
事業部制。
自分たちの事業部独立採算で動いていて、
ゴールは会社全体で共有しているけれども、
それぞれの得意不得意を持っていたりとか、
自分たちの方向性になった動きができる。
それに必ずどこかしらの案件がフィットするような形になっているので、
案件に対して人を当てやすいと。
なるほど。
事業部制っていうことは、
それぞれの事業部に一人事業部長がいて、
それぞれが開発チームを持っているということになるんですか?
そういうことです。
なるほど。プラムザに来た問い合わせに対して、
まず事業部単位でどの事業部が合っているかどうかっていうところから選別でき、
かつその事業部内の中でも合う人材をフィットしていくことができるから、
プラムザはまず案件から入るんだよっていうのが、
そういった話になったっていうことの認識であってますかね?
そういうことです。
なるほど。
それはやっぱりSESとか受託開発進めていく中で、
この形が良いだろうっていうふうになったって感じですか、島田さん?
そうですね。
やっぱり、もう今案件が言語とかプラットフォームを多様化しているし、
一つのプラットフォームだけに特化していると、
できる案件、できない案件って結構あったりするので、
いろんな案件、お客さんがプラットフォームとか指定してくることがあったので、
そういう意味ではいろんなことができるようになっていかないと、
いうふうになっていったんですよね。
そういう意味では、やっぱりフリーランスとかそういう人たちのパワーも
借りないとできなかったりしますので、
たくさんのエンジニアとつながっておいて、
案件ごとに人をアサインしていくというようなことをやっています。
そのとき初めて使うようなエンジニアだと、
ろくなものができないので、何十人もエンジニアと人となりをよく分かって、
小さい案件からやってもらって、
信頼関係作っておいて、
大きな案件からやってもらうみたいな、
そんな体制をこの5年ぐらいかけて作ってきたという感じですね。
なるほど。
これはまた別回にして改めてちゃんと聞きたいところですね。
これはSESとか受託の話じゃないけどね。
だいぶずれてしまいましたが、タイトルで
SESと受託開発のプロジェクションに合うのはどっちというところで、
島田さんこれ分かりやすくまとめるとどんな感じになるんですかね。
まとめるとSESについては柔軟に仕様変更とかができますよと、
人がその場にいるんでね、いろいろと細かい指示がしやすいですよと。
ということでですね、受託開発はその反面ですね、
そういうことは細かい仕様変更とかできないけども、
依頼したことに関しては責任を持って最後までやってもらえることが期待できると、
そういう違いがあると思いますね。
それでプロジェクトによってよく考えていただいて、
受託がいいなと思ったらですね、
宇宙の方に相談していただきたいっていうのと、
今言ってる受託とSESの中間みたいなものも用意してますので、
そういう提案もできますんでっていう感じですかね。
その国内ラボ型開発というサービスなんですけれども、
過去のエピソードで収録をしておりますので、
そちらもお聞きいただければなと思います。
ありがとうございます。
開発の話をしているとどうしてもプラムザ内のやり方とか、
開発方法に寄っていってしまうところがあると思うんですが、
SESと受託開発、開発形態、方法に迷っている方は、
ぜひ参考にしていただければと思います。
本日はこんな形で良いですかね。大丈夫ですかね。
はい、大丈夫です。
ありがとうございます。
本日はいかがでしたでしょうか。
楽しんでいただけましたらフォローや評価をお願いします。
またXでも最新情報を随時発信していますので、よろしくお願いします。
システム開発に関するご相談がございましたら、
公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
