DeNA・LINE・SmartHRのコーポレートエンジニアが語る「仕事の面白さと挑戦する理由」

アーカイブ動画

登壇者プロフィール

株式会社ディー・エヌ・エー
システム本部 IT統括部 IT戦略部
システム開発グループ　小山達也氏
2021年5月にDeNAへ中途入社。前職では会計システムを開発する会社で、Web系システムのアーキテクチャ設計やフレームワーク、共通ライブラリの開発を担当した。入社後は、会計業務を効率化する社内システム『Rome』の開発を行っている。開発技術だけではなく、開発工程やチームビルディングにも興味があり、2021年7月からRome開発チームのスクラムマスターを担っている。

株式会社SmartHR
General Support グループ
コーポレートエンジニアリングユニット　大竹洋平氏
前職ではスマートフォン向けゲームのサーバサイドエンジニアに従事し、2021年7月にSmartHRにコーポレートエンジニアとして入社。Slackと各種SaaSの連携開発や開発環境の効率化などを担当。

LINE株式会社
Enterprise ITセンター IT推進室
IT推進1チーム　金岡徹氏
新卒で独立系SIerに入社し、R＆Dや新規事業立ち上げなどに従事。2019年2月にLINEに入社。コーポレートITを担うEnterprise ITセンターにてバックオフィス系業務全般かつグローバルで使用できる社内メッセージ配信システムのPMの他、社内データ連携のためのシステム開発や運用なども担当。

【SmartHR】サーバサイドで培ったスキルで社内システムを開発

最初に登壇したのは、SmartHRの大竹洋平氏。クラウド型人事労務ソフトウェアの開発ならびに、同ソフトウェアで得たデータをもとに、各種人事サービスを提供している。

まずは、SmartHRにおけるコーポレートエンジニアの立ち位置や特徴を紹介した。

「コーポレートエンジニアのユーザーは、自社の社員です。SmartHRは年々社員が増加傾向にあり、それが私たちの仕事に直結しています。例えば、社員が100～200人規模で動いていたシステムが、600人近くになるとうまくスケールしなくなる。これまで手作業で行っていた業務も自動化しないと業務が回らなくなってきます。」（大竹氏）

大竹氏が所属するGeneral Support グループは、情シスと総務の機能を持つグループ。その中で情シス的な機能はコーポレートエンジニアとコーポレートITに分かれている。コーポレートエンジニアの業務は社内システムの開発・保守がメインだが、ヘルプデスクに入ることもあるし、入社直後のメンバーに対して、オンボーディングを実施することもあるという。

開発・本番環境など、社内システムで使われる言語はRuby on Railsが基本だが、最近はReactやTypeScriptも利用するために、社内で勉強会などを実施している。

開発フローは1週間を1スプリントとするスクラム開発ではあるが、こちらは大竹氏曰く「そこまでカチッとはできていません」とのこと。Backlogによるチケット管理で、タスクの数や優先度、日々の進捗を確認している。

「社内の要望などにより、Slackの新しいワークフローなどを開発しています。ただ、今はリモート作業が基本なので、以前のように雑談の中から業務課題を汲み取ることが難しい状況。そのため業務中は常に通話状態にするなどして、オフィスにいるように、雑談の中から課題を拾い上げられるように配慮しています」（大竹氏）

実は、大竹氏が入社した当時はコーポレートエンジニアが今より1人少ない2名体制だったこともあり、通常業務に追われ、リポジトリが煩雑な状態であった。

そこで、Ruby on RailsのテストフレームワークであるRSpecや、Circle CI、GIthub Actionsを利用したCI/CD環境の整備によって、開発環境を改善した。

さらに、Slackを軸にSaaSを連携する仕組みも構築していった。例えば、総務や労務、そのほか各部署への問い合わせをSlack経由で簡単に行えるワークフローを開発した。中でも特に注力したのが、書籍購入制度のワークフロー化だ。

yomuyomuというSlackアプリをゼロから開発。欲しい書籍のIDを事前に用意されたスプレッドシートで確認し、ワークフローに入力してもらう。領収書のやり取りにおいては、個人情報が担当者以外からは見えないよう Google フォームから別途申請して貰う形で実装した。

「総務や経理のメンバーと相談しながら実装したアプリが稼働し、ユーザーが使っているのを見たときは、嬉しく思いました。ただ残念なことに、この制度がなくなってしまったので、工数をかけすぎたことへの反省もありました」（大竹氏）

大竹氏はもともとサーバサイドエンジニア。テックブログでコーポレートエンジニアについて書かれた記事に興味を持ち、カジュアル面談を経て入社に至った。

これまでのプロダクト開発スキルを活かしつつも、SaaSに関する知識のキャッチアップも含め、エンジニアとしてスキル・キャリアアップの幅を広げられると感じたからだ。そして実際、入社してからは、まさにその感覚を体感しているという。

改めて半年を振り返り、次のように述べセッションを締めた。

「ユーザーがすぐ隣にいるのは楽しいですね。一方で、社員が増えれば、要望や課題は無限に出てきます。課題を解決できる開発スキルを有していることは前提として、場合によっては適切なSaaSを導入し、担当部署が自ら管理できる体制を構築することも重要だと考えています。」（大竹氏）

【DeNA】ユーザーとチームが一体感を持って開発に臨む

続いて登壇したのは、2021年5月に、他社のプロダクト開発エンジニアからDeNAのコーポレートエンジニアに転職した小山達也氏。「企業を支える新時代のエンジニアの仕事」と称し、コーポレートエンジニアの魅力を伝えた。

「ユーザーが近く、古い技術を使う必要もない。チーム開発も楽しいので、デメリットを感じることなく、毎日楽しいエンジニアライフを送っています」（小山氏）

DeNAでは、会計や人事などの基本的なシステムから、各部署における業務効率化ツールや業務システムまである。さらにSlackなどSaaS間はもちろん、様々なシステム間の連携を実現するユーティリティなど、合計100以上のアプリケーションをSaaSの拡張も含めて開発している。小山氏が所属するIT戦略部が、その業務を担っている。

IT戦略部内、小山氏が所属するシステム開発部の役割は、アプリの開発・保守業務がメイン。システム開発部は全領域に携わっている。つまり、幅広いスキルやキャリアが身につくと小山氏は強調する。

案件の依頼や課題解決の相談は、社内の他部署からはもちろん、部内の他グループからあがってくることも多く、常に数十件の案件が開発対象となるか議論されているという。優先順位が高い、費用対効果が高いなどと思われる内容から着手されていく。

「ジョインして驚いたことでもありますし、嬉しかったことは、SEやPGといった役割が存在しないことです。全メンバーがユーザーとコミュニケーションを行い、プログラミングを実施し、課題解決に臨む体制となっています」（小山氏）

開発フレームワークは、スクラムを採用。ゲームコンテンツの開発会社とのイメージが強い同社だが、ライブストリーミングやヘルスケア事業といった分野にも進出している。M&Aや事業の譲渡なども多いため、スピードの早い変化に応じる必要があるからだ。

各人が強みを活かしながらも、チーム全体でプロジェクトを進めていくのも特徴だ。例えば小山氏はマネジメント経験があるため、リードポジションを担うことが多い。また、ユーザーの距離が近く業務に協力的であることも特徴であり魅力だと続けた。

例えば、インターフェースを作った段階で、すぐに確認してもらえる。評価や喜びの声がすぐ届くことも、仕事をする上でのやりがいになっているという。開発環境はスライドのとおりだが、あくまで推奨であり、それぞれのエンジニアが使いやすい、好きな技術要素を使える環境でもある。

小山氏は実際に開発した、社内システムについても紹介。社内には数多くのシステムやSaaSがある。よりよい使い勝手のためにシステム間でデータを連携したいが、要件毎に個別にアプリケーションを開発していくと、組み合わせの数が多いため開発工数はもちろん運用後の保守工数も増大することは明白だった。

そこで、GitHubやSlack、Googleグループ、SaaSからEmpowerment（従業員管理システム）といった内製システムなどをまとめて連携するシステム「Sweet Cherry」を開発する。同システムが開発されたことで、たとえばGoogleグループの情報にEmpowermentの持つ詳細な人事情報を突合し、Jira上のユーザー情報に連動させるようなことが低コストで実現できるようになった。

注目すべきは、このシステムはリッチUIではなく、コマンドラインツールであることだ。見た目よりも使いやすさや開発・管理工数の削減を意識しているからであり、小山氏は「裏でうまいことやるシステムを意識している」と語っている。

小山氏は、改めてコーポレートエンジニアの魅力を次のように述べ、セッションを締めた。

「コーポレートエンジニアは近くのユーザーであり、同じ会社の仲間であるメンバーに喜んでもらえます。ともにシステムを作っていく楽しさも味わうことができます。エンジニアそれぞれの思考性によるとは思いますが、私は今の状況に満足しているし、楽しいエンジニアライフを送っています」（小山氏）

【LINE】社員番号の入力でマルチチャンネルに配信するシステムを開発

続いて登壇したのは、LINEの金岡徹氏。部署の特徴と、実際に取り組んだプロジェクトについて説明していった。バックオフィス業務におけるメッセージ配信の課題を解決するシステム開発である。

「私が所属するEnterprise ITセンターでは、LINEグループのIT業務に関わる戦略立案・企画・開発・運営を担っています。そのためZホールディングス関連の案件もあります」（金岡氏）

メッセージ配信における課題解決の事例も紹介された。例えば、人事は有給休暇の取得を全社員に促すために、年に何度もメッセージを配信しているが、その多くが手動。一部、自動化もされてはいたが、手を加えるなどの手間が必要であった。

目指すべき姿としては、エンジニアに依頼することなく、用意したテンプレートをこれまでの業務の延長、つまり手動でありながらも、効率よく行えるプラットフォームにするというアイデアでかたまった。

配信側だけでなく、受信側への配慮も意識した。例えば、日々の業務に忙しくメールをほとんど見ないエンジニアや、メールを開封したが、そこからの具体的なアクションが分からない、といったことがないような仕様を心がけた。

当初はMAツールを導入するが、いくつかの課題が生じる。一方で、ツールを導入したことにより、現場から評価の声が上がっていたため、システムそのものは必要だと判断。内製化を進めることにした。

アーキテクチャは以前使っていたMAツールを踏襲したフローとした。

「Web・APIと大きく2つのコンポーネントに分け、Web側は配信者がメッセージや配信を入力し管理します。Web側からリクエストされたメッセージがAPIゲートを通り、配信APIが受信します。配信APIでは分散メッセージキューのKafkaを経由し、複数のチャネルに配信されていきます」（金岡氏）

大きく2つに分けたのは、配信APIコンポーネントは他のシステムでも利用される可能性が高いと感じたからだ。中央部のAPIゲートを経由し、他のシステムとも連携される仕様となっている。

Kafkaを採用した理由も、将来性ならびにスケーラビリティを意識したからに他ならない。現在はメール、Slackといったチャネルでトピックを切っているが、新しいトピックが出てきた際、Kafkaであればすぐに対応できる。

一方、Web側にも工夫を施した。配信者の業務フローはできるだけ変えたくない。そこで、それまで使っていた業務データを、そのままスキーマレスのMongoDBに登録してもらうことにした。利用者は業務データの内容はもちろんのこと、社員番号をキーに自動補完された名前や所属部署を簡単にメッセージに反映できる仕様とした。

同じく、これまで手間であった配信先のチャネルのアドレスやIDに関しては社員番号と紐付けて管理しているため、配信者は入力することなく、社員番号だけで配信できるように配慮した。

金岡氏も他の企業でエンジニアとしてのキャリアを積んでから、LINEのコーポレートエンジニアにピポッドしている。最後に改めて、コーポレートエンジニアの魅力を語った。

「共通インフラは全社基盤として提供されているため、プライベートクラウドの申請ボタンを押せば、すぐに使うことができます。社内システムでもプロダクトと同様に、エンジニアが使えるシステムが制限されることはありません」（金岡氏）

【Q＆A】参加者から寄せられた質問を紹介

セッション後は、Q&Aタイムが設けられた。その中からいくつか紹介する。

Ｑ．社内IT部門は孤立無援感が強いイメージがあるが、実際はどうか

大竹：エンジニア比率が高く、エンジニア以外の方々もITリテラシーが高いため、孤立無援を感じることはありません。コミュニケーションも良好で、Slackを通じて課題解決したフィードバックを直接もらえるので、役に立っていることを肌身で感じています。

小山：私も以前はそのようなイメージでいました。ただ実際に入社してみると、他のエンジニアと同じ感覚です。実際、社内のエンジニア向け勉強会でも声がかかるなど、孤立無援感は味わっていません。

金岡：私も不遇な思いをしたことはありません。

Ｑ．コーポレートエンジニアとして孤立無援を感じない企業の見極めポイント

小山：今回のようなイベントに、コーポレートエンジニアが登壇しているかどうかが、ひとつの見極めポイントではないでしょうか。

大竹：カジュアル面談で気軽に聞いてみるのもいいと思います。

金岡：私もカジュアル面談をおすすめします。会社のカルチャーについて聞けば、見極めポイントが見えてくると考えます。

Ｑ．優先順位を決める際のポイント

大竹：そこは苦労している、というのが正直なところです。ただ、いくつかスタンスはあります。まず、リファクタリングよりも社内要望を優先します。要望内の順位付けはケースバイケースですが、ユーザーの期待値と僕らの状況をしっかりとコミュニケーションなどを通じて照らし合わせることで、期待値からずれないよう意識しています。

小山：スクラム開発なので、プロダクトオーナーとユーザーが優先順位を決めるのが前提です。その上で意識している指標や費用対効果を考え、ユーザーの優先順位を3段階で立ててもらう。こちらも、工数をざっくりとですが3段階立てることで、指標としています。スプリントの内容はオープンなので、優先順位で揉めることはほぼありません。

金岡：我々もスクラム開発のため、基本的にPOが判断しています。緊急度と影響範囲、開発工数や体制などを総合的に鑑みて判断しています。