社内エンジニアチームの現状
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、にぎやかし役の辰巳です。よろしくお願いします。
今回のタイトルなんですが、社内にエンジニアチームを持つメリット・デメリットというタイトルですが、辰巳さん、取引先の会社さんの中に、社内にエンジニアチームを持っている会社さんとかって結構いらっしゃるんでしょうか。
それで言うと、プラムザは基本的に受託開発の会社なので、自社でエンジニアチームを持っていない人たちに代わりに開発をする人たちなので、持っていないことが多いですが、知り合いの会社さんとか、直接お付き合いがあるわけではないですけれども、そういった会社さんに自社のエンジニアチームがいますよ。
ありがとうございます。
辰巳さん、クライアントさんが社内にエンジニアチームを持っているけども、依頼してきたみたいなことって今まであったりしました。どうでしょうか。
そうですね。少ないですけども、あるにはありましてね。いろんなケースがあるんですが、社内のほうで、10人規模の開発チームを持っていて、社内システムを作っていたんですけども、うまくできあがらないということで、うちのほうに助けてほしいと言われたことはありますよね。
では、プラムザは過去、社内にエンジニアチームがあったと思いますし、今は外注のプログラマーも使っているというところで、このタイトルに関しては、結構、島田さんの話をたくさん聞きたいなと思っているんですが。
じゃあ、その話をちょっと掘り下げていきますか。
お願いします。
お願いします。僕も久しぶりに聞きたいな。
ちょっと特定されないようにぼやかしていいますけども、ある大きな会社なんですね。開発チームを作って、10人くらいのチームを作ってやってたっていう話なんですよね。
私のところに、それは個人的に相談があったんですけど、うまく回ってないと、作りたいシステムもあるし、手は動かしているんだけども、思っていたようなものができてこないし、スピード感が足りないし。
何しろ争いが絶えないと、社内で言われたんですよね。
さっき、鴨志田さんも言ってましたけど、うちも一時期、社内に内製して、ほとんど100%内製をやってましたけども、同じようなことがその会社さんでも起きていて、エンジニアが何人も集まって、毎日毎日同じ屋根の下で仕事をしていると、大体争いが起きるんですよね。
コードのインデントっていうのは、余白を空白4文字にするのか、タブを入れて揃えるのかとか、そういうところから始まって、コードの書き方とかで主義主張があって、書き方だけじゃなくて使うべき言語ですね。
開発言語とかも、こっちがいいとか、それはもう古いとかですね。そういうことをやって、だんだんチームが分裂して、毎日毎日そんなことを争いをしているという状況が起きるわけなんですよね。
どうしても派閥ができてしまうんですね。
どうしてもできますよね、やっぱりね。細かいトラブルがあるごとに、またそもそもなんでこの言語でやってるんだっけみたいな話になってですね。
そういう状況になって、うちに相談きて2人ぐらいそこに派遣して、ちょっとテコ入れしてきますよって言って、やっぱり外部の人間が来るとピリッと引き締まるというか、恥ずかしいところを見せられないっていうのもあるんで、
割とですね、うまく回っていくようになったっていう。それでも喧嘩はしてましたけども、2年ぐらい付き合ってましたね。割とうまく回るようになって、ちゃんとシステムできあがったところで、うちは撤収したという感じですね。
そう聞くと、逆に社内にエンジニアチームを持つことによって良いところとかってどういった点があるんですかね。
それはやっぱりですね、我々みたいな開発ベンダーが仕事するとですね、初めに契約書を作って、要件をまとめて要件定義書を作ってですね、見積もり書いて、で、契約書を作ってからスタートするっていう。
で、その開発期間中はですね、その契約書に沿ったものができるためにですね、ずっと仕事していくって形になるんで、基本的にはその契約書の前に作った仕様をですね、変えられないっていうことになりますよね。
だけど、社内で作ればそんなことはないので、基本的に雇用契約で雇ってますので、雇用契約の人はですね、やっぱりこうしようって思えばですね、あ、そうですかってやるしかないっていう感じになりますよね。
だから、仕様変更はやりたい放題になっていくというのは一番のメリットじゃないですかね。
自社サービスの会社だとやっぱり内製化していることがほぼほぼ多いんじゃないかなと思うんですよね。
そうですね。
そうすると派閥争いはあるかもしれないんですけども、トップの一声で変えられたりっていうところも含めて意思疎通は取りやすいのかなとも思いますね。
基本的には毎日会社に来てるはず、そういう会社はほとんどだと思うので、そういう意味では何々さんってちょっと来てとかって言えばすぐそこで会議が始められるっていうのはいいですよね。
そうするとやっぱりトラブルが起こった時にどうするかっていう派閥争いと言いますか、というところが問題点になってくるんですかね。
それだけではなくてですね、やっぱりですね、そういうふうに毎日同じところにいて仕事してるっていうのもあまり精神衛生が良くなくてですね、別にそういう派閥というかですね、開発方針の食い違いがなくてもですね、
このパックのジュースを飲む音がうるさいとかですね、ズルズルズルズルって言って、スコーッとかっていう音がすごい気になるみたいな。
飲み切る時のあれですね。
そうそう、とかね、毎日牛丼食ってとかですね、臭いっていうかすごい良い匂いっていうかみたいな、そういうことが積み重なってですね、仲悪くなったりするんですよね。
へー。
そうそう。だからね、うちは最近2020年のコロナをきっかけに基本的にフルリモートにしちゃってますけど、毎日一緒にいるっていうのはね、良いところも悪いところもあるわけですよ。
特にエンジニアさんに関して言うと、最近は全くそうではないのかもしれないんですけど、どうしても職人気質と言いますか、気難しい。
前もそんな話をした気がするんですけど、そういうところですごい過集中して作業に取り組むっていうことも全然あると思うんで、そこを五感を変に刺激されてしまうと、確かにその仕事のパフォーマンスにも影響が出るんじゃないかなと思いますね。
特にすぐ会話したがる人と集中してコーディングしたいっていう人は結構バッティングするわけですよね。うちにもプロマネですぐ話をしたがる方がいると思うんだけど、ああいう人は当時からすごい話しかけてくるんで、何とかしてくださいって苦情を受けたことがありますけども、そういうこともあるわけですよね。仕事のスタイルが違うっていう感じですね。
人材とリソースの限界
何と言いますか、とても人間を感じる話ですね。
基本的にはうちはデメリットが大きいなと思って、社内のリソースをどんどん外部のフリーランスとか小さい会社に渡していって、案件ごとにチームを組むみたいな風に変えていったわけなんだけど、
いまだに私の知り合いの開発会社の社長さんは、当時はうちよりちょっと小さかったんだけど、2019年当時ね、そこからどんどん人を増やしていって、今は50人くらいいるんだよな。そっちの方に振り切ってやってるんだって思って、すごいなと思いますよ。
そこの会社同じく受託ですか?
受託。完全に受託。でもやっぱりね、社長が人格者。やっぱり優しいんで、非常に優しくて包容力があって、ちょっとイケメンなんだよね。みんなから好かれてる感じだね。
その人に会いに行くみたいなのも、もしかしたらあるのかもしれないですね。
そうね。あと真剣に会社を良くしてチームも良くしていこうって考えてるんで、あんまり裏切れないみたいな感じなのかなとは思いますね。
それは人によると言いますか、やり方によると言いますか、そのやり方やるなら人は選びそうですよね。
そうですね。
だし、入ってこないだけでもしかしたら社内は大変なことになってるかもしれませんしね。
そうかもしれないです。それはそうです。
あとね、やっぱりね、社内にエンジニアを雇ってしまうとですね、どうしてもその人ができることっていう範囲で決まってしまうんですよね。できることが。システムの限界がですね、今集めたメンバーでできることってなってしまうわけですよね。
技術スタックだけではなくて、単純なリソースの問題っていうのも限られそうですよね。
エンジニアチームの課題
リソースの問題もありますし、今こうやって作ってきたけど、これってAI使ってね、最近のオープンAIとか使ったら完全にもっと違うものができるんじゃないって経営者の方が思いついてもですね、相談をするとですね、エンジニアチームからこんなのできるんだったら自分でやったらいいじゃないですかみたいな、そういうことを言われてしまってですね。
そういうこともあり得るんですよね。
なるほど。
ストライキじゃないけども非常に反発を食らうことがあったりするんで、そういうのもデメリットですよね。
確かにある種、言い方はあれかもしれないですけど、雇われてる身としては変な波風は立てたくないですもんね。変に新しいことをしない方が。
そうそう。
腕の立つエンジニアさんほど、そういうところはやっぱり技術にこだわりを持ったりする部分は当然あると思うんですけど、うまくコミュニケーションが取れなかったらちょっとそれは大変かもしれない。
そうですね。さっき言ったみたいな、開発会社で50人くらいいるって言ったけども、そういうところはエンジニアの社長なんだけど、基本的には一般企業の場合はですね、技術のことよくわからないっていうケースの中に技術のチームができるわけなんで、結構ブラックボックス化するわけですよね、その情報がですね。
何やってるかわからないと。成果物も上がってこないと。報告も上がってこないみたいな。完全にディスっておりますが、その解決策があるんでしょうか。
そうですね。今聞いてて、確かにやりやすさっていう部分とやりにくさっていうのは明らかにあるんだろうなっていうふうに思ってるんですが、そこら辺の良いところを取れたらいいなっていうふうにはやっぱり誰もが思うのかなっていう中で、ちょこちょこワードは出てきましたが、
外部のリソースを使うとか、プロジェクトごとっていうのが、島田さんにワードをいただいておりましたが国内ラボ型開発を作ることにつながったっていう形でしょうかね。
そうですね。そういうお客さんにですね、うちの開発チームを使ってもらったら、そんな毎日どっぷりというわけではないし、そういう人間的なですね、トラブル、さっきのジュースのパックの音とかですね、そんなに気にすることはなくてですね、基本的にうちのチームはお客さんのところに入らないのでリモートで作業しますので、
言いたいことはどんどんPMに言ってもらって、PMを相手にして要望を伝えて、PMがうちのエンジニアに指示を回していくっていうふうにすればですね、非常にお互いにストレスなく、しかも仕様変更も全然言ってもらって構わないのでね、国内ラボ型開発はね。なので、そういうスタイルでやったら多分死角はないんじゃないかなと思いますけどね。
コンセプトとしては自社にエンジニアのチームを持つみたいな形なので、それを業務委託形式でできると。
そうです。
確かにそうするとプロジェクトごとという形になるので、流動性も持ていますし、新しい試みとかもしやすいですし、まとまりがないわけでもないですし、というので確かに考えてみてもあまり死角が見当たらないなっていうところですからね、開発ラボに関しては。
社内でチーム組むとですね、あともう1個あったのがですね、メンバーを雇ってくるのがですね、上の技術のわからない経営者が選んだ、技術のチーフは面接に立ち会うのかもしれないですけども、基本的にはですね、会社都合で採用した人がボコッとチームにアサインされてくるんですよね、社内で作ったときってね。
なので、そりが合わなかったりですね、技術スタックが違ったりするんですよね。それがまた既存スタッフのですね、勘にさわるとい言いますかね、だったりするんで、そういうことはないわけですよ。国内ラボ型開発の場合はですね、もうこういうことやってほしいというふうにプロマネに指示すると、プロマネがそれに必要なエンジニアを見つけ取って集めてチーム作ってきますので、そんなような人間関係のトラブルみたいなのは一切ないっていう感じですね。
あとチームはすごくさっきの話と真逆でクライアントを向いて仕事ができるっていうのは非常に大きいんじゃないかなと思いますよね。
そうなんですよね。この仕事をやるんだって、そのために我々プロが集められてるんだっていう意識でやるんでね。
社内にエンジニアチームを持つメリット・デメリットを主に島田さんに説明していただく上で、国内ラボ型開発っていうのはやっぱり現状良いのではというふうに思っているという形ですよね。
そうですね。一長一短ある中で、国内ラボ型開発が現状最適な選択肢であるんじゃないかという話ですね。
そうですね。国内ラボ型開発については別の回で話してもいるので、ぜひ遡ってみていただけると大変ありがたいです。
プロジェクトの推進
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価お願いします。
また、Xでも最新情報を随時発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。