🏢

インフラエンジニアがスタートアップで情シスを兼任した時のメモ

2024/01/09に公開

この記事について

元々インフラエンジニアだった私が、スタートアップに転職した際に合意のうえで情シスの一部を兼任しました。
その時の話を備忘録がてらに残しておきます。
なお、すでに当該の会社では情シス業務をやっていないことと、家庭の事情でリモートワークメインだったこともあり、リアルオフィス業務はほとんどやれていません。

また、家庭の事情もあり途中から休業しているため、やりきれてない部分などは多々ありますし、「これ抜けてるだろ！」みたいなのもあると思いますが、あくまでメモとして読んでいただければ幸いです。

当時の状況

私が情シスを兼任し始めた際は以下のような状況でした。

創業数年目、社員数は40名程度
創業メンバーであるCTOが片手間で情シス業務を回していた
採用の加速があり、CTOが情シス業務で忙殺されていた

そのため、本当の最初期にはCTOがやっている業務を私の権限上できる範囲の全てを一旦引き受け、社内において必要とされる情シスの立ち位置を探っていました。

使用していたサービス

使用していたサービスについては、おそらく他の企業と大きく異なる点は無いと思います。
全てではないですが、以下のようなツールを使っていました。

社内のコラボツールのメインとしてGoogle Workspace
- 後述しますが、一部の業務ではMicrosoft 365( 以下M365 ) を利用しています。
Slack
Notion
Figma

やったこと

一覧

SaaSのID管理
- SaaSのID管理をSaaSでやるとは、と思うが無いと棚卸しや入退社時のID管理で結構死ねます。あると便利
Google Workspace関連
- Google Drive
  - 社内におけるGoogleドライブ利用方針を策定 / 断捨離
  - 社外向けには別途OneDrive利用で設計( ただしあまり筋が良くなかった )
  - 社外に共有しちゃってるファイルの洗い出し( 地味だけど大事 )
- Gmail
  - 共有メールアドレスが作成されてたのをできる限りGoogleグループへ移行
  - ドメイン変更に伴うDKIM対応不備を修正
- 全般
  - Googleグループおよび組織と実際の組織図を対応させる
  - Google WorkspaceをIdPとしたM365のID連携( 途中 )
M365関連
- 体外共有用にOneDriveを利用する
全般
- 利用中SaaSの洗い出し / SaaS ID管理ツールと連携
- 入退社に向けたID管理とその手順の作成 / ID管理は別働隊へ引き継ぎ
- ISMSの更新対応 / ISMSの新規格への対応
- 社内デバイスのMDM対応(途中)

やったことの中で振り返って優先度が高いと思ったもの

Google Driveの利用方針策定とGoogleグループの利用方針策定

おそらく、スタートアップで使われるサービスとして勝手なイメージですがGoogle Workspaceがかなりの割合を占めると思います。

Google Docsなどのツールもそうですが、Google Driveもよく使われるでしょう。
ただ、このGoogle Driveの運営を放置しておくと以下のような弊害が発生します。

共有ドライブが乱立する
共有ドライブへの権限付与が個々のアカウントに対して付与されることが多いため、入社時に「hogeドライブが見れません」と言う問い合わせが届く
外部に対して共有リンクを作成することができてしまう

1.の 共有ドライブの乱立 はしょうがない側面もあります。
新しいプロジェクトが立ち上がった際や、ちょっとしたグループ内に閉じたアイテムを保管したい場合など、ドライブの作成自体を閉じてしまう / 申請制にしてしまうとスピードが落ちてしまいます。
更に言えば、情シスの負担も増えます。

そのため私の場合は、Googleグループを使うことで以下を目指しました。

Google Driveへの権限付与ルールとして、「Googleグループ単位」で付与させる
例: 「Zenn」という共有ドライブには以下のように権限が付与される
- 全社員グループはコンテンツ管理者
- 情シス管理者グループは管理者
共有ドライブは、誰が作成しても良い、が作成者が管理者であることを明確にし、アクセス権限の付与はその管理者が行う

「Zenn」という共有ドライブへのアクセス権限付与を情シスに聞かれても権限上は可能だが、該当のGoogleグループメンバーにフォワードする

情シス管理は特定のGoogleグループ のみ を管理し、それ以外は全社員が個々で作成して良いルールとする
例: 雇用形態( 正社員 / 業務委託など ) に合わせたGoogleグループ
Googleグループ作成時のルールはきちんと策定し、共有する
例:
- Google Driveとメーリングリスト用のGoogleグループは分ける
- 命名規則

一度権限がぐちゃぐちゃになってしまった / なっているとしても、30〜40名程度のスタートアップであればみんなで一斉に権限の洗い出し / グループの作成 / 権限付与、を行うことができます。
逆に、それ以上になってしまうと情シスが強権を振りかざし修正する必要が発生し、情シスの疲弊と現場からのヘイトをもらうことになるので、なるべく最初から潰す && ルール化しておくと良いと思います。

Googleアカウントの使いまわし( Gmailの共有メールアドレス ) 撲滅

どこの組織でもあるあるだと思いますが、共有アカウントが存在していることがあるでしょう。
ただし、これがGoogleアカウント( Gmail ) だとかなり厄介です。

まず、そもそもGoogleのサポートページでもやらないようにと記載されているという前提で、以下のような破壊的なデメリットが存在します。

そのアカウントを誰が使っているか、が分からない
退職した人がそのアカウントを使っている可能性が存在する
過去に設定されたMFAが突破できずに情シスに問い合わせが来る
コストがかかる

他にもいくつかあるでしょう。
3. や4. に関しては些末なことではありますが、コスト最適化の観点からも共有アカウントはやめたほうが良いでしょう。

ここで問題になるのは、1. ~ 2. です。
スタートアップとはいえ、他の企業様とやり取りする際の紋所の一つとしてISMSなどの認証があると思いますが、完全にアウトです。
正しくいえば、「どうにかはできる」のですが、どうにかして得られるメリットをデメリットが秒で上回ります。
どうにかしてISMSを突破したところで、悪意の有無に関わらず退職した社員がアクセスして・・・なんていうリスクが常につきまといます。

メールの送受信を特定の個人ではなく、組織で使うアカウント( 例えば support@... ) にしたい場合はメーリングリストを使用しましょう。
受信はもちろん、送信も可能です。

注意点としては、デフォルトで設定されるフッターは必ずオフにしましょう。
詳しくはサポートページを見てもらえば良いのですが、普通にグループを作成した状態でメールをやり取りすると、以下のような文言を含むフッターが生成されます。

このグループから退会し、グループからのメールの配信を停止するには test-group+unsubscribe@example.com にメールを送信してください。

原因究明まではできませんでしたが、私が過去いた環境では上記を受け取った別会社さんがそこにメールを送ってしまったかなにかをして、面倒なことになりましたので、オフにしておくと余計なトラブルを引かないでしょう。

SaaSのID管理と個人契約になってるSaaSの撲滅

入退社に伴い、各種SaaSのID管理が必要になってきます。
入社はまだ良いにしても、退社では漏れが発生しやすく、セキュリティ的にもコスト的にもよろしくありません。

スプレッドシートなどを使って自前で管理しても良いのですが、すぐに限界を迎えます。
私は、以下をSaaSを検討しました。

詳しいことは各サービスのドキュメントを読んでもらえればわかりやすいと思いますので、詳細は省きます。
2023/1月ごろでは以下のように判断しました。

ID管理したい
各部署ごとにSaaSアカウントテンプレートを作り、そのテンプレートを適用するだけでアカウントを作成したい
将来的に、PCをリース購入したい、キッティングなども丸投げしたい

ということで、ジョーシスさんのサービスを利用することになりました。
Adminaさんの場合、50人未満の場合は無料なので手早く試すのであればそちらが良いかもしれません。
もしくは、Google Driveで公開されているアイテムを洗い出す、などといった場合にはAdminaさんが適していると思いますが、古い情報なので実際に利用される場合は最新の情報を確認してください。

ちなみに、全てのSaaSのIDを管理できるとは限りませんので、その点には留意してください。
どちらのサービスも、手動でID管理できますが、実態はスプレッドシートのそれに近いものがあります。
特に大手のサービス(Slackとか)の場合は、ID系のAPIを触るなら上位プランの契約が必要だぜ！ってことがよくあります。

その他、やったこと

ISMS対応 / 新規格に向けた理解

ISMS対応は、当時は以下のような状況でした。

すでにISMS自体は取得していた
ISMSの更新対応を実施した
- この時、情シスとして私が実施
旧規格で監査が通っていたため、ISMSの新規格(2023)に向けて対応を進めていた
- 私の事情により、新規格で通し切ることは一旦Pendingとなった

ISMS対応を進めていくうえで、以下のような考えを得ました。

コンサル会社は仲間として考える
ISMS対応は「我々は、こうやって情報を管理してます！」という手順を用意し、その結果を残す
- 主体はその会社( ISMS監査に対応している人 )
- 監査を通すことも大事ではあるが、実態に合わせてドキュメントを記載した方が良い。出来ないことを書いてしまうと大変
「管理出来ている」ことを示せれば基本的には良い。

すでにISMSが取得されている場合は、ドキュメントに対して1度目を通して置くと良いと思います。
オンプレのインフラをやってる場合、そこまで戸惑うことはないと思います。

新規格については、このようなサイトを読んでいただくのが良いと思います。

もし、今からISMSの取得が視野に入っている場合は、以下を重視すると良いかもしれません。

社内で利用している各種システムやSaaSの各種監査ログが取得できているか

オフィスの各種機器もそうですし、自社で提供しているサービスのログも含まれます。

個人情報はマスクされる運用になっているか
データ漏えい防止策(DLP)は出来ているか
データの削除フローは整備されているか
脅威インテリジェンスに対応するためにアップデートは適切に行われているか
悪意のあるサイトにアクセスしていないか
各種機器の構成管理は行われているか

1や2、3については現状出来ている、もしくは、手順を整備すれば良いという方が多いかもしれません。

5~7については、他のところでも述べましたがMDMを導入すると一発で終わります。
なお、6については、「HTTPサイトへの接続はブラウザのデフォルト機能で遮断される」のようなものでもOKだと判断されることがあります。

事業継続のためのICT準備等も大変ではありますが、そこまで大掛かりなものは求められなかった記憶があります。

やれなかったけど、やった方が良いと思うこと

社内で利用しているデバイスのライセンス確認

一言で表すと、Windowsマシンのライセンスは「Pro」が搭載されているかどうかを確認しましょう。
極初期に、ライセンス周りがあやふやなまま社内のPCが整備されていくと「安い方を買う」となり、Home版が搭載されていることがあります。

というか、ありました。

Home版ライセンスの場合はADに参加するといった、組織用のデバイスとして利用するための機能が一切使えません。
そのため、AzureADに参加することができずWindowsデバイスやアカウントを一元管理することが出来ません。

それだけであれば運用でカバー、ということも出来ますが、以下が大変になります。

Microsoftの個人アカウント発行を誰かが行わなければならない
Microsoftの個人アカウントなので、一元管理出来ない
「WordやExcelの利用でM365が必要なんです！」と言われた際に、独自ドメインを利用することが出来ない

Windowsのログイン時のアカウントとM365用アカウント、2つのアカウントが存在してしまう
独自アカウントをプライマリとして利用すると、AzureADにログインを試みるもHomeアカウントなのでログイン出来ない = デッドロックの発生

IPO後の監査、ISMSの新規格対応で虚無を覚える運用が発生しうる
WindowsデバイスでMDMが利用出来ないので、ISMSの新規格対応で虚無を覚える運用が発生する

アカウント発行周りはなんとか管理出来ますが、「一人情シスが時間とパワーをなるべくかけずに監査を通す」という観点においてはMDMの利用がほぼ必須と考えた方が良いでしょう。

特に、営業職用のスマートフォンを導入したい！みたいな話もあると思いますし・・・
別の話ですが、スマホはAppleアカウント周りが面倒ですがiPhoneが最強だと思います。
もしくは、個人のスマホに会社契約のIP電話SaaSをぶっこむことです。

ファイルを社外共有するためのクラウドサービス選定

最初に述べたように、私は以下のような方針を立てました。

社内共有にはGoogle Driveを利用する
社外共有にはOneDriveを利用する
- 提携企業様がGoogleアカウントを持っていない場合が多々あるため

実際に運用していくとOneDriveの場合、以下のような点が非常にデメリットでした。

OneDrive自体がSharePointに内包されているため、SharePointの利用が必須
Exchangeとも連携してしまい、例えばあるアイテムを共有すると、M365のアドレスから共有先にメールが飛んでしまう

そこに返信をされても、普段見ないアカウントのため返信が出来ず・・・といった自体が発生
更に、ここにもグループの概念が存在するため、社内メンバーにどうやって説明すんねん・・・と頭を抱えた

Google Workspaceだけでも覚えること大変なのに、M365 + Azure関連の膨大なリソースまで覚えるのは正直無理
に関しては、私の考慮・設計不足が多々あることは自覚しています。
元々、OneDriveを利用することを決めたのは、WordやExcelなどを利用するためにM365を導入しているメンバーが多かったから、なのですが
安易に決めてしまったことは正直後悔しています。

そうすると、残った選択肢がBOXを使う、しかなくなってしまうのですが、他に良い選択肢が無いかを考えればよかったな・・・と今更思っています。

一方で、「このデータは国内ストレージに存在すること」を求められることもあり、正直頭が痛いです。
特に、先方から「このサービス以外は使えない」みたいなことを言われることも多く、弱小スタートアップはそれに振り回される日々もあるので、何が正解かが分からないという・・・

情シスをやる方針として決めてよかったこと

積極的なドキュメンテーション

これは、この後に続く「積極的な権限の移譲」などにも通じます。

社内で1度質問されたことはドキュメントを残しておき、検索できるようにしておく
設計思想や変更した理由などをドキュメントに残す

最近流行りのADR的な思想ですね

正直、片手間で情シスをやっていると「そんなことやってる余裕ねーよ！」になると思います。私もなりました。
ただし、1番に関してはなるべく手厚くした方が、将来を見据えた際に良いと思っています。

私の入社時、お世辞にもナレッジ集約システム上には情シス関連のドキュメントが残っているとは言い難く、「〜さん、この間やってもらったアレ、もう1回お願いできませんか？」のようなSlackが飛び交っていました。

これを見た時、以下の状態であると認識しました。

必要となる情報・手順が生成されていない
情報・手順があっても権限が無い
結果として、従業員は調べようとしない。「聞けばやってくれるっしょ」の精神になってしまう。

「聞けばやってくれる」というのは、ある種それはその通りではあるのですが、毎回毎回そんな問い合わせに答えていたら、情シスを本業にしたとして回りません。片手で兼務しているならなおさらです。

そのため、「情シス関連ならドキュメントが残されているはず」と思わせられるようになったら情シスの勝ちだと考えて、以下のようなお気持ちでドキュメントを残すようにしました。

些細なことでもドキュメントに残す
スクショなどを使い詳細にドキュメントに残す。
誰向けのドキュメントであるかを明確にする

例えば、部署のマネージャ用なのか、従業員全員なのか

「情報が古くなってたら勝手にアップデートしてくれよな！」の一文を入れておく

私はインフラエンジニアであり手順書を生成することが多いため、ドキュメントを生成することに対する抵抗がなかったことも大きい要因だったかもしれません。

途中から私が休業してしまったため、うまく回せたかどうかの自信はありませんでしたが、「ドキュメント残っててマジ助かる」的なコメントは複数人からもらったので密かにガッツポーズしてました。

積極的な権限の移譲

大企業では、例えばメーリングリストに追加されるにも情シスに依頼して・・・となると思いますが、兼務一人情シスがそんなことをやってしまうとボトルネックになるのは明白です。

そのため、基本的には以下のような設計思想をもとに各種利用方針などを作成していました。

社内に閉じるものは基本的に好きにして良い

そのためのガイドラインはある程度キッチリ作る

SaaSの利用も基本的に好きにして良い、ただし、追跡ができるようにしておく

ジョーシスを利用すると、過去に「こんなSaaSにログインしたよ」が見れるので、それをたまに閲覧する

社外とのやり取りが発生する部分はそもそも利用サービスを分けることを検討する

入社後に必要なGoogleドライブへの権限付与などがまさに上記にあたります。
今まで情シスでやっていたことを各部署もしくはGoogleドライブの作成者に責務を切り出します。

こうすることで、「情シスに聞けばどうにかなるでしょ」という空気を少しずつ自責に寄せられることを期待しました。

情シスは必要最小限の権限しか持たない / 実際の部署やグループに権限を寄せる

情シスは基本的に強権を持つことがほとんどです。
そこで、強権ばかりを持つと色んなお仕事が舞い込んでくることになるため、なるべく最小限の強権を持つことを考えた方が良いです。

また、従業員が個人で色々なサービスを契約することもあるでしょう。
実際に、とあるサービスを数名が会社アカウントで個人プランの契約していたところ、退職時にアカウント削除が抜け漏れているということがありました。
これはSaaS ID管理の部分にも通じるところではありますが、原則として法人契約を結びましょう。
そうすると、SaaS ID管理ではなくとも、管理者が一括で管理できるようになります。

この際に、管理者は情シスではなく、そのサービスを使いたいと言った人が属する部署のマネージャーにしておくと良いでしょう。

自前実装は最小限にする / ChatGPTを活用する

情シス業務をしていくと、「ここはこんなコードを書けば手間が減るのでは・・・？」と思うことが往々にしてあると思います。

もちろん、何かしらのコードなりなんなりを実装してやるのも良かったのですが、一人で保守をし続けることや、他の人のヘルプ / 要望が発生することを考えると正直労力に見合いません。
積極的に、外部のSaaSを利用する、OSSを利用する、ChatGPTにサクっと書いてもらう、などをして、手を動かす時間を圧縮していきましょう。

この際に、「積極的なドキュメンテーション」が根付いていると、将来「あれ何やったんだっけ？」とか「どういう気持ちで決定したんだっけ？」などを振り返ることが出来ます。

過去に経験しててよかった技術 / スキル

私が過去に会社、趣味問わず情シスをやるにあたってやっててよかったな〜と思うことを羅列しておきます。

オンプレの経験
Windows Server関連で基礎的なサービス群の構築
- e.g. AD / ADFS / ADCSなど
- AzureADは別物ではあるが、「認証してくれるのね」みたいな当たりはつけられる
MDMに関する知識
- これは前職がそうだったため、ある種特殊枠
過去に自作PCをWindowsで組んだことが複数回ある
- この経験が有りと無しだと割と違う気がする
- ハード的なことは稀に、WindowsOS的なことは結構使った

将来、自分が振り返るかもしれないので備忘録でした。