攻めのサーバーサイド戦略！技術トレンドの実態に迫る
2020年12月8日に開催されたCTOmeetup。今回は医療、人事、製造といった全く異なる分野で活躍する3名に登壇いただき、攻めのサーバーサイド戦略をテーマに熱く語っていただきました。
クラウドの活用が当たり前になる近年、サーバーサイド開発はどのように変化しているのか、そしてどのような技術選定や品質管理が求められていくのか。サーバーサイドに関する気になるトピックが満載です。
目次
登壇者
登壇者の紹介
AWSやGCPを駆使してサーバーサイドの開発を行う各社
エムスリー株式会社 執行役員 VPoE/PdM/CDO 山崎 聡 氏（以下、山崎）： 本日ファシリテーターを務めるエムスリー株式会社の執行役員VPoE山崎です。私自身エンジニアバックグラウンドですが、ほかにもプロダクトマネージャーとして自らプロダクトの画面設計などもしています。
最近はエムスリーのデザイン部門を強化するために、CDO（Chief Design Officer）にも就任しました。プロダクト開発が大好きで、コンピューターには8歳の頃から触れています。
今回はテーマが「攻めのサーバーサイド戦略」ということで、進化し続けているサーバーサイド技術についてギークなお二方と盛り上がれればと思っております。
では次に吉田さん、自己紹介をお願いします。
株式会社サイダス 取締役CTO 吉田 真吾 氏（以下、吉田）：株式会社サイダスで取締役CTOをしている吉田と申します。私のキャリアのはじまりは携帯基地局や証券システムなどのサーバーサイドアプリケーションやインフラの開発でした。
2012年からクラウドエンジニアへキャリアチェンジしたのですが、そのとき最も身を助けたのは、ネットワークの知識やデータベースチューニングの技術といった、サーバーサイドエンジニアとしての幅広い知識です。クラウドを利用するようになるとエンジニア個人のケイパビリティが大きくなり、多くの役割を一人で完結できるようになるので、レイヤーの低いところから高いところまで知識を持てば持つほどやれることが増えます。これが素晴らしいことだと感じて現在はクラウド一本で仕事をしています。
当時から私はAWSが大好きで、2012年にAWSウルトラクイズの初代チャンピオンになったこともあります。2019年にはグローバルでも数十人、日本において唯一のAWS Serverless Heroにも認定されました。そのほかサーバーレス技術に関しては書籍の執筆も行っており、サーバーレスの良さを知っていただくような活動を続けています。
現在はHRテック領域でSaaSの開発・運用を行っています。2020年4月にはCYDAS PEOPLEというサービスをローンチしました。これは2017年頃から構想していたもので、人材のオンボーディングから目標設定、1on1、適切な成果に基づいて評価・抜擢するといった、社内の人材に活躍してもらうためのプロセスを総合的に支援するサービスです。
当社はレガシーなシステムが多く主なプログラミング言語はPHPなのですが、バッチはGoで書いてLambdaで動かしたり、SPAはVueで書いてNetlifyにホスティングしたりしています。検索の一部にAlgoliaを使って検索速度を速めたり、DevOpsのためのCI/CDのパイプラインもプロジェクトスタート時には必ず組んでから始めてたりします。
今日はAWS Serverless Heroとして、サーバーをなくすスタンスで話ができればと思っています。
山崎：ありがとうございます。では小橋さんよろしくお願いします。
キャディ株式会社 最高技術責任者 小橋 昭文 氏（以下、小橋）：キャディ株式会社でCTOを務めている小橋と申します。僕はもともと電子工学出身で、軍事企業のロッキード・マーティンで衛星の画像システム解析を行ったり、アップルでアルゴリズム開発などに携わってきました。
キャディは特注金属加工品の製造をしている会社で、部品の設計図をカスタマーからいただき、キャディが持つ製造のドメイン知識とテクノロジーを駆使してパートナーである加工会社に製造を依頼しています。「モノづくり産業のポテンシャルを解放する」というミッション達成に向けて、日々挑戦しているところです。
技術選定についてはGCPやKubernetesを利用しており、インフラもコンテナ化して活用しています。BFFやバックエンドの言語やフレームワークの選定は型安全なものが多いです。
製造業というドメインは非常に複雑でミスが起きやすいため、型安全な仕組みによって極力開発の生産性や効率向上に挑戦しようとしているんです。本日はよろしくお願いします。
サーバーサイド技術選定について
小さなチームでマイクロサービス的に開発を進めるメリット
山崎：まず、サーバーサイドを担うチームの規模やどんなチームなのかを簡単に教えていただいて良いでしょうか。
吉田：当社はサーバーサイドとフロントエンド、SRE、QAのチームに分かれています。エンジニアは30名ほどで、このうちサーバーサイドは10名ほどです。この10名がさらにそれぞれ4名のスクラムチームに分かれています。
本当はフロントエンドもサーバーサイドも一体となって開発をしたいのですが現在は分かれている状態で、サーバーサイドは特にAPIやWebアプリケーションの開発を担っています。とはいえ、最近はサーバーサイドエンジニアがフロントを実装することもよくあるので、だんだんメンバーがフルスタックになっているという感じです。
小橋：当社の開発に関わっているメンバーはエンジニアやデザイナー、SRE、プロダクトマネージャーなどを含めて30名前後で、3、4つのプロダクトラインに分かれています。
ラインごとにフロントエンド寄りやバックエンド寄り、インフラ構築が得意といったメンバーがそろっている状況を作っており、縦のラインで完結できる構造です。プロダクトラインにはR&Dに近いものもあります。
このような体制なので、本日のテーマであるサーバー開発にはほぼ全チームが関わっています。
山崎：当社もそうなのですが、両社とも比較的小型のチームで開発を進めていくようなスタイルですね。
サーバーサイド開発というとSIer的にウォーターフォールで大きなモノを作るのも一つの方法論ですが、今回集まっている3社は5、6名のチームでサーバーサイドのサービスを手早く高品質にリリースしている。この前提でトークを聞いていただくのが良さそうです。
吉田：僕はSIerの経験もあるのでそこと比較すると、大人数のチームに推進力を与えるにはかなり優秀なプロジェクトマネージャーがいないと難しいですよね。
数名のチームならビジョンやミッションを設定することである程度自走できますし、問題解決に対する当事者意識も生まれます。増えたとたんに自分の問題と捉えられずに見落としが多くなる傾向があるので自ずと少人数にならざるを得ないのではないでしょうか。
山崎：マイクロサービス的なチームですね。小橋さんとしては小さなチームについてどのような考えをお持ちですか？
小橋：コンウェイの法則的にも、マイクロサービスをエンジニアリングで作っていく上で組織を小さく切っていくのはすごくいいと思います。
当社はプロジェクトのフェーズによって組織体制を変更しているのですが、0-1の突貫工事で新しく何かを作るようなときは、4人でも多い。2人でとりあえず何かを作ったほうが早いです。完成したのが良いモノであれば徐々に人数を増やしていきます。5、6人になってスピードが落ちたり、お互いが何をしているのかわからなくなってきたら、また分解を考えるのがいいのではと思います。
やはり基本的にチームは小さいほうが当事者意識を高められます。メンバーが「自分で状況を変えられる」という自信を持ち、なおかつ権限が移譲されている状態を作るのは一番効率がいいですよね。
エンジニアの効率的な戦力化と技術選定の密接な関係
山崎：では実際のサーバーサイドの話に移りましょう。ビジネスの性質上使っている技術や注目している技術があればお聞かせください。吉田さんからいかがでしょうか。
吉田：うちは基本的にCYDAS PEOPLE以前のバージョンからずっとPHPを利用しています。Webアプリケーションを提供する事業なので、エンジニアが採用しやすくキャッチアップしやすいという意味で引き続きPHPでいいと思っています。
「この技術でなければ解決できない制約事項」といったものがWebアプリケーションの世界にはさほど多くありませんからね。これはモバイルアプリケーションにおいても同じです。基本的には世の中の大きな流れに合わせて選定すれば十分だと考えています。
ただ少しだけ先を見て、バッチやプログラムを書くのに便利なGoも利用しています。サーバーサイドに関してはこの2つの言語が主流ですね。
山崎：技術選定の理由に採用を含めるのは重要ですよね。
吉田：例えばRustなどを導入したら人が採用できなくなるじゃないか、という率直なおそれはあります。
山崎：一方で時代の流れを読んでGoは採用する。最後はバランス感覚ですよね。
吉田：今見えている採用の雰囲気を考慮するとPHPからGoに替えるようなことはあってもいいかなと思っています。
山崎：ここ5、6年でGoは非常に伸びていますからね。3年ほど前から採用でも通用するようになってきたイメージがあります。
小橋：5、6年前までのGoはエコシステムがそろっているのか、Googleのエコシステムに縛られないのかといった懸念がありましたが、今はPHPと並んで活躍できるようなエコシステムができていると思います。
技術選定をする上では、解決したい事業課題に適した技術という要素と実際にその技術を生かして事業価値につなげられる人材を獲得できるかという観点、そして選定自体が負債化しないか、継続的に使っていく上での将来性があるかなどが大事ですね。
当社はRustを採用していますが、大きな理由はやり型を大切にしているからです。例えば金属加工の領域では、鉄やアルミといった材質が10～20種類ほどあります。これらを何らかのUIに変換したり、裏側でシリアライズしてJSONに渡したりするのですが、タイプミスなどによって一瞬でミスが起きてしまいます。型に縛られた状態を作るのは、こういったミスを極力減らす意図があるんです。ドメイン駆動設計でもあると思います。
山崎：事業のタイプによって、動的型付け言語か静的型付け言語かという選択肢はありますね。私も医療系で電子カルテを作っているのでわかりますが、ドメイン駆動設計でコーディングをすると新入社員のオンボーディングがすごく楽です。
小橋：ドメインが複雑で「入社したらまずドメインを半年勉強してください」ということになると、開発者としてすぐにアウトプットにつなげられません。オンボーディングという観点でも、人に叱られるよりコンパイラに叱ってもらうほうが楽です。
ドメインのキャッチアップにしてもProtobufのDefinition fileや型定義を見たほうが手っ取り早いので、最小限の情報を最速でインプットできる部分はあると思います。金融なんかではScalaが流行っていますし、ドメインに適した言語選定は重要ですね。
山崎：お二人ともおっしゃっている本質は一緒なのかなと思いました。いかにして人材を採用して戦力化するのかという工程においては、とっつきやすい言語でキャッチアップしてもらうこともあれば、言語のシステムで素早くパフォーマンスを発揮してもらうこともあるということです。本質的なゴールは同じで、アプローチが違うのだと感じました。
サーバーレスの本質は「オンデマンド処理」にある
山崎：次に、吉田さんにサーバーレスの活用事例をお伺いしたいと思います。
吉田：マイクロバッチ処理から切り出して、少しずつサーバーレスの比率を上げています。バッチの処理は基本的に必要なリソースが予測不能なので、サーバーを確保しておこうとすると中小企業ではとても買いきれないリソースが必要になってしまいます。その点サーバーレスは、FaaSであるLambdaを使いどんどん切り出していけば必要な分だけリソース調達して処理をしていけるので最適です。
Lambdaの仕様も汎用性が高くなってきていて、今はメモリーを10GBまでアプリケーションから利用できますし、実行時間の制約も60分まで指定可能です。処理が重いバッチはECS上のコンテナアプリケーションとして動かし、小さな処理はLambdaで動かすといった形で分けていたのですが、最近はLambdaの制限がなくなってきたおかげでどちらも選べる状況が増えてます。
また、AWS re:Inventで発表があったAWS Protonというサービスでは、サーバーレスやコンテナのアプリケーションをインフラからアプリまで全て一箇所でテンプレート管理できるようになりました。これを使えば、将来的にサーバーレス・アプリケーションを少し書き換えてコンテナ・アプリケーションに変更したり、その逆といった行き来がしやすくなるのではと思います。
山崎：小橋さんはどういったところでサーバーレスを使っていますか？
小橋：まさしくマイクロバッチのような形で、ボリュームがわからないリクエストが流入したときにサーバーレスを使っています。
CGPでもコンテナをファンクションで動かせるCloud Runというものがあり、例えば画像処理が2枚か1000枚か1万枚かわからないけれど低遅延のレスポンスを返したいといったときは、プールされているリソースをAWSやGoogleに委ねることで波を吸収しやすい構造にしています。
昔ならオンプレでサーバーを立ち上げるためにはまず機械を買い、さらに数週間遅延するといった世界だったのが、仮想マシンを立ち上げるための遅延は1分です。ユーザーにとって素早いレスポンスで多くの処理を短時間でできるという流れは製造業にとっても価値があるので、ぜひ試してみてほしいと思います。
山崎：「サーバーレス」という名前からはなかなか本質が捉えにくいんですよね。サーバーレスの本質は動的なオンデマンド処理ということだと思いますがいかがでしょうか。
吉田：クラウド上のVM（仮想マシン）を使うようになった時点で、全てのリソースはオンデマンドに調達できるようになってますからね。その割にOSのセットアップやサーバーのメタファーによる制約が残ってしまっていましたが、最終的にそれも不要になり、ただ書いたプログラムが実行されるときだけリソースを調達するというモデルになっていくのがサーバーレスです。
質疑応答
注目の技術はAWS ProtonやAurora Serverless
質問者：最近発表された新しい技術や機能で、近いうちに採用しようと思うものはありますか？
吉田：先程言及したAWS Protonは早めに導入しようと思っています。サーバーレスのアプリケーションをきちんとインフラ回りから統合管理していこうという感じですね。
それ以外には、Aurora Serverlessというサービスがあります。これはRDBMSのストレージとコンピュート部分が別々に管理されており、コンピュート部分がゼロからスケールするデータベースサービスです。
2年前にリリースされたv1はこのスケールに若干時間がかかり、アプリケーションからデータベースに接続してスピンアップするまでに数十秒かかっていました。それがもうすぐリリースされるv2ではmsec規模でスピンアップするようになったようです。これならリソースがゼロの状態からスケールしても応答性能にばらつきがなくなり、今ちまたにあるRDBMSのユースケースすべてに使えるようになるはずです。
当社が提供しているSaaSでは、テナントを1データベース内のテナント個別のスキーマで管理しています。これは全テナント合計のワークロードに合わせた調達が必要なので、これをそもそもゼロからスピンアップする個別のデータベース・インスタンスに分割することができれば、リソース効率もアイソレーションレベルも高い構成に変更できるのではと期待しています。
インプット・アウトプット・振り返りの比率が成長の鍵を握る
山崎：サーバーサイドエンジニアとしてもっと成長したい人に向けた、おすすめの勉強法はありますか？
小橋：やはり手を動かすのが一番早いです。本を読んだりして勉強するOff-JTと実務で手を動かして肌で学ぶOJTの2つの手法があると思いますが、これらを上手く両立させるのが重要です。理論で勉強するのはもちろんすごくいいのですが、それが現実世界でどうなるのかを試行錯誤し、さらに良い方法を求めて理論に戻る。この往復ですね。
吉田：成長には、研修が1割、経験が７割、他人に教わるが2割のバランスがもっとも役立つというロミンガー社の調査結果があります。机上の学習が1割程度ということなので、小橋さんがおっしゃるように実務で経験するというのが一番成長に寄与すると言われますね。
山崎：インプットしてアウトプットして振り返るというパターンですね。エンジニア業界はどんな言語でもまずFizzBuzzをやれとか、Webサービスのフレームワークを学ぶならとにかくToDoリストを作れといった鉄板がありますが、私も新しい言語を触るときはタイムゾーンの取り扱いに特徴が出る場合があるので世界時計を作るようにしています。
品質に対する考え方
QAチームがチェックすべきプロダクトを定義して品質と向き合う
山崎：では次に品質管理に関する考え方を掘り下げていきたいと思います。これは私も思い入れのあるテーマですね。
私は小さなスタートアップ企業で自らプロダクトを開発してきた経験があるのですが、いわゆる専任のQAチームは無い企業が多かったです。エンジニアが全ての品質を担保するという、品質管理としてはシンプルな考え方でした。
専門チームはあったほうがいいのかどうかも含め、「攻めのサーバーサイド」という文脈ではどうやって品質を管理するべきなのか、小橋さんからいかがでしょうか。
小橋：僕は製造業という領域なので、設計図を基に品質を担保しながらモノを作っています。
日本の製造業はクオリティが高いモノを作りますが、その一方で品質とはどういうものなのだろうかという点を、まさに我々も業務として掘り下げているところです。
例えば金属加工において、金属の塊を削って穴を開けるとしますよね。最終的に出来上がってからカメラなどの技術を使って寸法を全て確認しても良いのですが、ほかにも穴を開けた時点ですぐにチェックするやり方もあります。
こうした物理の世界ではどういったモノが求められているのか、かなりクリアに決まっています。ソフトウェアの場合も、SIerさんなんかだと設計図で決められた通りに作るので、物理の世界のようなやり方もできると思います。
ただ、ベンチャー企業として急成長しており何を求められるのかが常に変わり続けるような状況では、求められるモノをわかっているふりをしてはいけません。まずはわかっている範囲で開発を進めて常に工程間検査を行い、自分たちが何を作ろうとしているのか、ステークホルダーと擦り合わせてチェックできるような状況を作っていくことになります。そういう意味で、我々はメンバー全員がある程度QAを意識できるようにしないといけないのではと感じています。
山崎：吉田さんはいかがですか？
吉田：品質の作り込みという観点では2つの方法があります。まず特定のユーザーにプロトタイピングレベルでリリースするようなものに関しては、QAチームを通さずユニットテストやインテグレーションテストなどでエンジニア自身がチェックします。プロダクトとして正式にリリースし、永続的にメンテナンスするとなった場合はきっちりQAを通して品質に向き合うようにしています。
山崎：エムスリーの場合、事業の立ち上げ期は基本的に早く検証を進めたいので、最低限の品質を確保したらどんどんリリースしていくようにしています。それが上手くビジネスになり、1億、10億、100億円といった稼ぎを生み出していった場合は、きっちりとしたQAが重要になります。何かあったときのダメージが大きいかどうかですよね。このように品質管理にはビジネスのフェーズも依存しそうな気がします。
品質管理のためにアクセス状況やチームのベロシティを分析する
山崎：品質管理においては振り返りのサイクルも重要だと思いますがいかがでしょうか。
例えば車なら何年式といったモデルが出ますが、スマートフォンアプリなら実装している最中に自分で使ってみて不具合がわかれば、その場で直します。学習サイクルのスパンが年単位なのか、月単位なのか、あるいは5分なのかという違いもあるのでしょうか。
小橋：スパンが短くなればなるほど積み上げが見えるということかもしれません。
山崎：スパンが短いほうが方向修正ができるということですね。
小橋：業界によっては「ユーザーが求めているものを作っているか」ということと「意図したものを作っているか」ということは別軸で区別しなければいけないと思いますが、ソフトウェアの場合は軌道修正が早いためあまり区別する必要がありません。
特にクラウドを利用していればインスタンスを立ち上げてすぐに切ればいいだけなので、コストもかけずに済みます。オンプレだとどうしても100万円のサーバーを買うかどうかという話になりサイクルが遅くなりますから、サーバーレスや仮想マシンでPDCAのサイクルが回りやすくなっているというのは革命的だと思いますね。
吉田：当社では品質に関して追加で追跡しているKPIがいくつかあります。
一つは、プロトタイピングであれ正式リリースしたものであれ、どの機能がどれくらい使われているかのアクセス解析です。想定以上に使われているプロトタイプなら早く品質管理工程に戻して、正式リリース判断をしたいと思っています。
逆に思ったより使われていない機能に関しては、使われていないならデータ破壊を伴う不具合がなければ優先順位は下げていいという言い方ができます。
もう一つ取ろうとしているのが、プルリクを出してからマージされるまでのリードタイムやプルリクのサイズなどです。デベロッパー側のメトリクスですね。海外にはGitHubやGitLabを解析してそれらを可視化できるCodacyやCode Climate Velocityといったアプリケーションがあり、チームがどの程度のベロシティで活動しているのかをヒートマップなどで見ることができます。
例えばチームのベロシティが落ちてきていて、その理由がプルリクがマージされるまでのリードタイムが長くなっているからであるとか、このチームにプルリクを送ったときだけレビューまでのリードタイムがかかっているといったことがわかります。開発者単位で平均のプルリクサイズのランキングなども見られるので、プルリクをもう少し小さい単位で作ろうねと指導したりすることもできます。こういった形で開発者のベロシティを計測して対応することも、品質に影響しそうだと考えています。
目指すべきは不具合の原因を突き詰めて改善するQAチーム
山崎：QAチームが最後のゲートキーパーになるだけの組織というのは、QAとしては本当に初期段階の状態だと思います。ベルトコンベアで最後に検品して不具合があれば戻すだけだということですね。良いチームに進化してくには、なぜ不具合が混入したのか、原因まで突き止めて直せるQAチームになることが非常に大事だと思います。
そういう意味で、吉田さんがおっしゃったようにロスの原因を突き止める取り組みはサーバーサイドにおける品質管理の重要項目の一つなのかもしれません。その点はいかがでしょうか。
吉田：製品の品質やDeveloper Experience(DX)、エンジニアの成長にも効いてきそうです。
小橋：社外不良のようなものを労働時間を使って食い止めるといったこともあり得ますが、それは本質的ではありません。我々はソフトウェアを開発しているわけですから、ソフトウェアが勝手にソフトウェアを改善してくれるというのが究極的な姿なのではと思います。
山崎：QAチームがバグを埋め込んでいるわけではないので、QAチームがいくら頑張ってもバグはなくならないんですよね。QAチーム自体がエンジニアやデザイナー、プロダクトマネージャーに対して影響力を持つようになって初めて品質が良くなる傾向がある気がします。
質疑応答
クラウド活用において許容すべきリスクとその範囲
質問者：クラウドを利用している場合、クラウドが落ちたときの対応や対策はありますか？
吉田：極力冗長性を持たせるような構成にはしています。ただし、組織の規模的にクラウド全体が落ちるリスクは受容して代替手段を提供する経営判断はしています。
例えばクラウドが落ちたときのためにオンプレにホットスタンバイなシステムを構築しておくとか、AWSが落ちたらAzure側にフェイルオーバーするようにしておくといった対策は、お金をかければできます。
ですが、その実効性や有効性を経営的に考えて、最終的にクラウドが落ちたときに発生するダウンタイムのリスクは受け入れています。
山崎：その許容範囲については、いわゆるSLAのような形で顧客に合意を取っているんですか？
吉田：利用規約上の補償は48時間ですが、内部的には8時間以内と定めています。8時間あればAzureやGCPに展開し直すことができますから。
山崎：SLAとして48時間は補償の対象にならないと明言しておき、その基準に合わせて設計していくということですね。小橋さんはいかがですか？
小橋：経営リスクやGoogleのSLA、システム上の負債に対する肌感、自動で復旧できるかどうかといった部分も含めて、人が入るべきかどうかの判断が必要だと思っています。
我々のサービスは基本的にBtoBで国内のお客様がほぼ100％なので、日本時間の深夜はみなさん寝ているので重要視していません。
一方で、町工場さんとの取引があるので早朝の時間帯は重要になる可能性があります。これに対して内部ではSLAを持っていますが、さらに経営リスクがあるかどうかでも判断します。
というのも我々にはフェイルオーバーとしてメール、電話、FAXなどのコミュニケーション手段を持っているので、Webが落ちても業務は進められるんです。
甘えられるところは甘えて、逆に絶対落ちてはいけないところは保守的に見るという部分がありますね。
組織やプロジェクトの立ち上げ段階から品質管理を担う人材は必要
質問者：品質管理の専門チームや人材を配置するタイミングは、みなさんのお考えではいつがベストでしょうか。
山崎：吉田さんのところはQAチームがあり、小橋さんのところはこれから作りたいという感じだと思いますが、タイミングは恐らくプロダクトのフェーズや規模感、領域といったいろいろな考えが絡んできます。
吉田さんの場合はどんなタイミングで配置したといった過去の事例はありますか？
吉田：僕が入社した段階ですでにQAチームがあったのですが、できれば新規立ち上げの段階から役割は置くべきだと思います。早いうちから誰かが開発チーム内で品質プロセスを啓蒙する教育係になったり、最後の検品をするゲートキーパーとなったりと、組織フェーズによって役割の移動や変化をすることも必要だと思います。
製品の立ち上げ期にはとにかく稼げるプロダクトを作るのが第一優先なので、QAの役割は多くないのですが、稼げるようになってきたら品質をマネジメントする役割が必要になります。
それは例えば僕や山崎さんのような人でよくて、ゲートキーパーや教育係を自分だけで賄えなくなってきた時点で、専門の人材を配置するという判断をするのがいいのではないでしょうか。
小橋：すごく参考になります。そもそもなぜQAという言葉が出てきたのかというと、多能工を求めすぎると集中しづらい、効率が落ちるといった状況が起きるからだと思います。
そういう意味でも、組織が大きくなってくると「プロセス改善やゲートキーパーの役割を同じ人がやっていていいのだろうか」「そもそも兼務し続けられるのか」といった議論が出てくるのかもしれません。これは単純にロールの仕事量が増えているから分担する意味合いですし、これを組織の中のほかのプロジェクトやプロダクトに横展開していくことが重要です。
最後にひとこと
山崎：エムスリーでは今回のような議論を楽しみたいサーバーサイドエンジニアやQAエンジニアを積極的に募集しております。私と話したいと言っていただければカジュアル面談も対応させていただきますので、どうぞよろしくお願いします。
吉田：サイダスではサーバーサイドエンジニアを募集していますが、同時にフロントやインフラもやりたいという欲張りな方を大歓迎しています。私と一緒にAWSからVue.jsまで覚えたいという方は、ぜひいらしてください。
小橋：キャディでは「モノづくり産業のポテンシャルを解放する」というミッションのもと、日本が誇る製造業を支えるためのITインフラなども作っています。そういう意味も含め、型安全な開発がしたい、QAやフロントエンド、バックエンド、サーバーサイドに興味があるという方はぜひご連絡ください。
山崎：それでは今回のディスカッションはこれで終了とさせていただきます。本日はありがとうございました。
企画/編集：FLEXY編集部
