![見出し画像](https://assets.st-note.com/production/uploads/images/93223446/rectangle_large_type_2_03c9edbc6a749d957855be64d03493c8.jpeg?width=1200)
入社して約3ヶ月の中で実施してきたことをご紹介
この記事は UbieCorporateアドベントカレンダー
https://adventar.org/calendars/7774 の10日目(12/10)にエントリーしています!
こんにちは。
Ubie Corporateでコーポレートエンジニアを担当している下村と申します。
会社では simon(さいもん)と名乗らせて頂いています。
( Twitterもやっているのでフォローしてくれると嬉しいです )
2022年9月よりユビーにジョインさせていただいております。
約3ヶ月程度経過したので、これまでに行ってきたことを記録する観点でもこのnoteを記載したいと思います。
この記事を読んでいたくことで、
「ユビーのコーポレートエンジニアになれば色々できそうだぞ!」
と思ってもらえれば幸いです。
この記事の目的
3ヶ月やってきたことを振り返りつつ、下記のようなことを説明できればと思っています。
スタートアップのコーポレートエンジニアって何やってるんだろう…?の肌感をつかんでもらいたい。
ユビーのコーポレートエンジニアって楽しそう、って思ってもらいたい。
コーポレートエンジニアって何やってる人なの?
と、思われる方は手前味噌ですが、下記をご参照ください。
(人によって定義が異なるので私なりの定義を下の記事に書いてます)
やってきたことのサマリ
今までやってきたことを「課題」「やったこと」「残課題」と言った形で記載したいと思います。
( いっぱいやった 感を出すために、あえて粒度はバラバラで小粒の案件も記載しています )
IdPのリプレイス( Google Workspace → Azure Active Directory )
製品導入( Halp )
iPaaS周り( Zapier等 )
各種Slack Botの開発
ちょっとしたGoogle Apps Scriptの開発
IdPリプレイス( Azure Active Directoryへのリプレイス )
![](https://assets.st-note.com/img/1670345920148-YyCT4COHWY.png)
こんな課題がありました
Google WorkspaceをIdPとしていたので機能に限界があった(実質、無料付帯でできる機能なので機能を求めるのは酷ですが…)
例
柔軟なアクセス制限がやりづらい
Terraform等に対応していないので構成管理がしづらい
ユーザープロビジョニングできないものがある
公式に連携ができないSaaSも存在する。
セキュリティ強度が不安
昨今、 MFA疲労攻撃対策 のような攻撃手法も騒がれてきたので、その対策を打ちたい( ID + パスワード + MFAでは守りきれないものがでてきている )
やったこと
Azure Active Directory(以下、AzureAD)へのリプレイス
Oktaへのリプレイス案もありましたが、コストバランスや Windows 365 Offline への期待も込めてAzureADへのリプレイスをしました。
世間的にはOktaが人気あるのは認識しています。今回はAzureADで要件を満たしていたこともありますが、AzureADは使いこなせれば高度な認証機能が実装できるので「AzureAD"で"いい」ではなく「AzureAD"が"いい」と私個人は思ってます。
パスワードレスの導入
段階的に「AzureADへのリプレイス」→「パスワードレス導入」も検討しました。ただ、ユビーの皆様はリテラシーが非常に高いことに加え柔軟性も高いのでいきなりパスワードレス導入に踏み切りました(この判断は正解だったなと思ってます)
Terraform化 & GitHub ActionsによるCI/CD環境の構築
Google Workspaceで抱えていた課題として「構成管理のしづらさ」があったのでそちらを解消するために最初からTerraformで構成するようにしました。
いずれ、違うIdPにする可能性もあるためコードによる構成管理は手厚くしたい。
工夫したポイント
初回は各ユーザーに一時的なパスワードは発行しなければいけません。しかし、いちいち手動で発行&連絡していてはそれだけで1日が終わってしまうのでGraph APIやSlack APIを利用して発行処理を自動化しました。
導入へのオンボーディングは手厚くしました。
ユーザーからすると認証方式の違いは苦痛でしかないはずなので、ハレーションを生まないためにも、特に大事にしたポイント。
そのおかげ?か社員からの大きな不満の声は聞こえてきませんでした。
![](https://assets.st-note.com/img/1670548544723-MoKZqeBd3p.png?width=1200)
![](https://assets.st-note.com/img/1670548644092-n5Ba40QYY4.png)
残課題
よりセキュリティ強度を高めたい
今回はパスワードレス認証を選択しましたが、ゆくゆくは FIDO2対応のYubikeyを配布&それに伴うポリシーを規定して、より安全にしつつ、SaaSへのアクセスを簡単にしていきたいと思っています。
( 全社員にFIDO2対応のYubikeyを配布するのは費用的な都合で今回は見送りました )
社内利用SaaSのほぼ全てをAzureADに連携
今回、IdPをGoogle WorkspaceからAzureADへリプレイスしただけで肝心のSaaS群の連携は手つかずです。ここは来年以降にフルスピードで連携数を増やしていこうと思っています。
Halpの導入
![](https://assets.st-note.com/img/1670346203164-2TlEUPDCxn.png)
こんな課題がありました
ユビーは複数組織が存在するため以下のような問題点がありました。
各組織ごとのヘルプデスクチャンネルが存在する。
ヘルプデスク担当者は各チャンネルを巡回する必要がある。
巡回することによりコンテキストスイッチが起きやすく非効率な状態になっていた。
問い合わせをSlackチャンネル/DMで受け付けていたため問い合わせ回答者の固定化など属人化が発生しやすい状況になっていた。
やったこと
できるだけ時間をかけず &シンプルに現状課題を解決したいと考えていました。
そこで、ユビーでは既にタスク管理ツールとしてJIRAが導入されていたため、Halpを導入することにしました。
導入自体は設計の時間を含めても 数時間程度で完了しました。
しかしながら、Halpでは「かゆいところに手が届かなかった」ため下記を追加で自前実装しました。
問い合わせ元のSlackで投稿された質問文のURLがわからない、問い合わせ内容の原文が残らない
JIRA APIを利用して下記を実装し、Slack Bot化した。
Halpで自動生成したJIRAチケット情報を取得。
上記チケットのdescriptionなどに、「Slack投稿文のURL」「Slackでの質問内容の原文」を自動転記。
問い合わせ担当者のランダムアサイン(属人化の防止)
JIRAの「オートメーション」の機能を利用し 担当中のチケット数が少ない担当者順 にチケットを自動アサイン。
こうすることでタスク流量を均一化し属人化の抑制を目指しました。
残課題
できるだけ時間をかけず&シンプル にしたかったのに追加実装をしてしまったので、実装部分が負債(引き継ぎが困難)になってしまっていると感じています。
ここについてはZapier等のノーコードツールで解消できないかと目論んでます。
iPaaS周り
![](https://assets.st-note.com/img/1670551347765-DwtiM2k1f4.png?width=1200)
こんな課題がありました
ありがたいことに、入社してからしばらくして「こういうのやりたいんだけどー。。おてすきのときで!」みたいな依頼が増えるようになってきました。ただコード書いている時間は無さそう。さてどうしたものか。となりました。
例
Slackチャンネルが作成されたら通知したい。
毎月、ToDoを通知するためのチャンネルを作成したりメンバー招待を自動化したい。
やったこと
クイックに解決するならiPaaSだよね、ってことで既に導入済であったZapierを利用して要望を叶えていきました。
結果として、平均1時間もしないで要望を解決することができました。
やったこと2
Zapierを使いこなしたい! というニーズもあるかなと思い、勉強会をSlack Huddleで開催しました。(これにより途中参加離脱をしやすくし、勉強会参加のハードルを下げました)
結果として、Ubie Corporateの半数程度のメンバーが勉強会に参加いただき下記のような嬉しい声があがるように。
![](https://assets.st-note.com/img/1670551025883-7pqWYHlmBe.png)
残課題
万能に見えるZapierにも実は弱点があります。
・連携可能なアクションが少ない。
・かゆいところに手が届かない( 個人アカウントへの連携禁止などの制限やZapが失敗したときに●●するといった分岐が弱い )
そのため上記を解消するためにはWorkatoやMuleSoftなどのiPaaSへのリプレイスも検討していかないとな、と思っています。(その分コストは高くなってしまいますが…)
Slack Botの開発#1 - マルチワークスペース化bot
こんな課題がありました
ユビーでは複数組織があることから SlackのEnterprise Gridプランを利用してマルチワークスペース構造にしています。
( 組織ごとにワークスペースが存在する )
ただ、「組織間の連携チャンネルを作成したい!」みたいな要望は当然発生するので、その対応の都度、管理者がマルチワークスペースチャンネル化していました(数も多いので大変&依頼者を待たせる時間が発生する)
やったこと
Enterprise Gridの最大の旨味である「Admin API」を駆使して解決することにしました。
社員側の入力は簡単にしたいので、Slackの ワークフロービルダー を利用して入力を受け付けるようにしようと考えました。
ただ、ワークフロービルダーでは外部へのPOST送信ができないため、高度な処理はできません。
そこで、下記のようにすることでワークフロービルダーからGCPのCloud Run環境へデータを渡すように工夫しました。
1. ワークフロービルダーで入力してもらう。
2. その入力内容を特定のPrivateチャンネルへ書き込み。
3. Privateチャンネルへの書き込みを検知(Event Subscriptionアクション)してCloud Runにデータ送信。
4. Cloud Run側でマルチワークスペースチャンネル化を実施。
その結果、ユビー社員にマルチワークスペース化の権限委譲することが可能になりました。
社員はクイックにマルチワークスペース化できるので、物事に向かう時間が早くなり、かつ、管理者の作業は激減するというWin-Winの結果に。
ありがたいことにリリース後は多数の反響を頂き、利用頻度の高い人気ツールになっています。
![](https://assets.st-note.com/img/1670552165381-X4bHkGbcXO.png?width=1200)
残課題
リリースしたあとに気づいたのですが、「マルチワークスペース化と同時に●●のSlackグループも全員招待したい」みたいなニーズがあることがわかったので、時間をとってその機能も盛り込みたいと思ってます。
Slack Botの開発#2 - Slack投稿を複数組織に複製転送
こんな課題がありました
ユビーは複数組織が存在するため、Slackのワークスペースも複数に分かれています。そして、それぞれの組織で取り扱う情報も異なるので別組織のチャンネルでの投稿は少し意識して投稿する必要があります。
例: ●●の組織でつぶやいている情報は△△では共有されないほうが良さそう、等
※こう書くと「情報透明性が無いじゃないか」となりそうですが、そういうことではなく、ユビーのお客様のことを考えると情報を分離しておいた方が良いものなど、ケースバイケースで情報を分離しています。
ただ、上記の観点でいくと全社横断の投稿(代表やUCメンバーの投稿)が若干やりづらくなります。
具体的に言うと「同じ投稿内容を複数組織で投稿しなければならない」です。
なぜかというと、投稿された組織の、"組織メンバーからの返信内容"に上記観点が悪意なく含まれる可能性があるためです。
例: 〇〇という施策をやりましょー → 組織メンバーからの返信「△△の件ですよねー」 → 別組織メンバー「△△って我々知っていい情報か…?」となる。
このような制約があることから単純に全社横断マルチワークスペースチャンネル化することもできないという課題がありました。
やったこと
「投稿元チャンネルで投稿後、その投稿メッセージに特定Slackリアクションをつけると、転送先チャンネルに投稿元内容の複製投稿を送る」というSlack Botを用意しました。
このようにすることにより「複数組織に対して同一内容を手動で投稿しなければいけない問題」を解決しつつ悪意ない返信による事故を防ぐことができました。
また、特定Slackリアクションをつけないと転送されないようにしているので、「転送される前に別メンバーからの投稿文のレビューを受ける」ことができるようにしました。
Google Apps Scriptの開発#1 - カレンダー共有権限設定ツール
こんな課題がありました
ユビーでは、入社者のオンボーディング時に「特定Googleグループへの閲覧許可制限」を 手動 で設定してもらっていました。
( Google Workspaceの管理者設定で強制適用できないため… )
ただ、手順が多いことがあるためか 設定漏れしてしまう新入社員 が多発していました。
そこで登録を簡略化するためにGASでCalendarAPIを利用して簡略化することにしました。
GASを叩くのも面倒なので、スプレッドシートにボタンを配置しボタン一発押せばカレンダーに登録できるようにしてます。(共有先Groupも簡単に変更できるようにスプレッドシートにパラメータとして入力するようにした)
![](https://assets.st-note.com/img/1670553937206-jvsZ2MMTu7.png?width=1200)
このようにすることで、カレンダー共有設定のハードルを「ぐっ」と下げることに成功。本来、これの設定に必要だったオンボーディングの時間も削減しました。
Google Apps Scriptの開発#2 - GoogleForm連携
こんな課題がありました
個人的な所感ですが、社内要望の多いランキングの上位に「Googleフォームで入手した内容」を「Slackチャンネルに投稿したい」というのがあると思ってます。(ユビーでもそうでした)
ただ、Googleフォームの連携は意外と面倒でGAS等でコーディングしないとならず、開発経験の無いメンバーには敷居が高いことからコーポレートエンジニアに相談が来ることが多い実情がありました。
やったこと
基本的には事前に用意してあるGASをコピペすればいいだけ の汎用的なGASを作成&それを設定するための手順を用意しそれを全社展開しました。
今までは「GoogleフォームのAPI仕様を理解」「フォームの内容を取得するコードを書く」「Slackチャンネルへ投稿するコードを書く」と実装までのステップが多かったものが、
「GASをコピペ」&「SlackのIncoming Webhook URLを用意」するだけで良いようにしました。
( Incoming Webhook URL自体は、フォームの回答収集先として生成されるスプレッドシートに別シートを用意してもらって、そこに記載するようにしているのでGAS自体の改修は不要にしました)
こうすることで 非開発者のGoogleフォームをSlack投稿する ことのハードルが「ぐっ」と下がったのではないかとおもっています。
![](https://assets.st-note.com/img/1670591540859-p1uzzuIHsT.png?width=1200)
残課題
"コピペすればいいだけ" にしたものの、それでもそれなりに設定に時間はかかるものにはなってしまっています。(トータルで15分程度)
ここの設定を「Slackワークフロービルダーで必要項目を入力していけば設定が完了するようにする」みたいにして手順をより簡略化したいなと思っています。
(なお最近、社内リリースしたものなので、まだまだ残課題はあるかもしれません…)
Google Apps Scriptの開発#3 - テキスト自動加工系
こんな課題がありました
組織図の作成:
人事情報をスプレッドシートでテーブル形式(エクセルみたいな形式)で記録している会社は多いと思います。ユビーもご多分に漏れず、そうです。
このスプレッドシートを利用して「組織図を自動作成したい!」というプロジェクトが立ち上がり、それ用のGASを作成することになりました。
要件としては「テーブル形式をツリー形式の見た目に整形したい」です。
とある経理ソフトのCSVデータの加工:
とある経理ソフトから出力されるCSVデータを元に各種分析を経営企画で行う、という業務があるのですが、このCSVデータが特殊な形式をしており、なぜか 1-5行目までが出力データのサマリ情報 、 それ以降の行も独自ルールでデータ記載されている というなかなか分析泣かせの形式になっていました。これをテーブル形式に変換して分析したいという要件がありました。
要件としては「特殊フォーマットをテーブル形式にしたい」です。
やったこと
「テキストデータの加工」をやるのはコーポレートエンジニアに大好物の領域です。(多分)
これをできるだけ、コーポレートエンジニアを介さずに自動化したいのでGASを採用しました。
( メンテのことを考えると、GCPのCloud RunやAWS Lambdaでも良かったかもしれませんがスピード優先でGAS )
組織図については、スプレッドシート上に実行ボタンを設置して、ツリー形式の組織図自動生成をしようとしています(現在実装中)
経理データについては、特定のGoogleドライブにCSVをアップロードするとそれをトリガーにデータ加工してスプレッドシート形式で同一ドライブに保管するようにしました。
残課題
特にこれと言った残課題は無いのですが、GASでの実装は負債になりやすいので、SaaSを活用してリプレイスできる道があれば積極的に採用したいと思っています。(例えば組織図についてはSmartHRの組織図生成機能とかを使えると良さそう、とかと思っていたりします)
今後、やろうとしていること
12月までの間にやろうと考えていたのですが、力及ばずできなかったことも記載してみようと思います。
情報システム部門の設計
過去、情報システム部門の立ち上げなどを行っていた経験値等を踏まえて、ユビーの情報システム部門の効率的な進め方や、取り組み方といったフレームワーク的なものを定めようとしましたが、時間が取れませんでした。
( ユビーでは評価制度が無いので、こういった本来マネージャーがやるような仕事も手をあげれば取り組めたりするのが魅力です)
こちらは、あきらめず来年以降に取り組みたいと思います。
Salesforceのより良い環境作り
ユビーにはSalesforceに詳しい&事業設計が上手なメンバーが揃っていたこともあり、Salesforceが広い範囲で積極的かつ効率的に利用されている状況です。
※現行のSalesforce管理者の皆様が情熱的&驚異的なスピードでメンテをしてくれているおかげです。
ただ、会社規模が急成長したこともあり管理面で追従できていない部分が見えてきています
(開発プロセスの整備や利用用途がわかりづらい項目の整理など)
よりユビーが成長するためにはSalesforceのさらなる利活用が急務であると考えています。
「今のスピード感を止めず」に「障害件数などを減らして安定稼働できるように」できるように来年以降に改めて取り組みしたいと考えています。
各種自動化対応
この数ヶ月でユビー社員のニーズをいくつか満たせてはいたのですが、まだまだ全部のニーズを満たすのには程遠い状態です。
たとえば、「社外ユーザーのSlackシングルチャネルゲスト招待」などを自動化&権限委譲することで事業スピードにブレーキをかけずに社外連携してもらいたいなどと思っています。
(※もちろんこれ以外にもSlackに限らず自動化の余地は多数あります)
来年以降も優先度を付けつつ、社員の要望をかなえていきたいと考えています。
チャットボットの導入
バックオフィス業務には切っても切り離せない 問い合わせ対応 というのがあります。これを過去回答ナレッジを元に Dialogflow 等を利用して自然語解析しつつ、自動回答して問い合わせ対応の効率化を図りたいなと思っていましたが時間が足りずできませんでした。
こちらも来年以降で機会を見つけつつ、自前で開発しなくても良いものを探したいと思っています。
例えば、HiTTOさんとかですかね。
SaaS利用の適正化
どの会社もそうだと思いますが、ユビーもご多分に漏れず、多数のSaaSを利用しています。
SaaSの無駄なアカウントがあればそれはコストでしか無いので見える化をしないといけないと思っており、その整理に来年以降は取り組みたいと考えています。
例えば、マネーフォワードさんのIT管理クラウドやジョーシス さんなどのSaaS管理SaaSの導入も検討しています。
VPN環境のリプレイス
社内環境へのアクセス用途などで一部社員がVPNを利用していたりします。
今後、ユビーは多数の組織、拠点が生まれていくことが予想されることから拠点型のVPNではなく、Cloudflare WARPやCisco Umbrellaなど、どこに居ても安全 かつ 高速な環境 を実現したいと考えています。
( 私個人はあまり好きな表現ではないですがゼロトラストな環境を作っていきたいと思っています )
こちらも来年以降、導入計画をしてまずはPoCなどから試してみようと思っています。
最後に
いかがでしたでしょうか。
できるだけ文字数を抑えて書きたかったのですが、想いがあふれてしまい文字数が多くなってしまいました。
(それでも各項目の詳細部分はほとんど記載できていないので、詳細が気になるものがあればコメント頂くかカジュアル面談等で気軽にお聞きください)
「ユビーのコーポレートエンジニアになれば、3ヶ月という期間でも割と色々やれることがあるんだ!」といったことが感じ取って頂けたら嬉しいです。
それと同時に まだまだやることがたくさん残っている! とも思ってもらえたのではないでしょうか。
そんな環境に身を置いてみたい!と思う方はぜひカジュアル面談しましょう。
現在、Ubie CorporateではSalesforceに強い方のジョインを熱望しています。
(我こそは!という方はぜひ私と一緒にやりましょう!)
その他にも複数のポジションでも採用を積極的に行っていますので、ぜひお気軽にご応募ください。