水道局は各家庭での珈琲消費量を知っているか
こちらは「【初心者優先枠】corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#2」 16日目の記事になります。
珈琲ではなくて情シスの話です
タイトルでいきなり水道局などと語り始めておりますが、ちゃんと履いてます情シスのネタです。ご安心ください。
尚、私はコーヒー飲めない人なので紅茶派です☕🍵
まずは情報管理規程を作った話
色々あって2021年の4月に突如情シスと情報セキュリティ委員会なるものを両方引き継ぐことになったのですが、その情報セキュリティ委員会が行おうとしていたことのひとつが、社内の情報セキュリティ規程を作る、ということでした。
つまり、情報セキュリティ規程を作っている最中で「あとヨロ！」と規程策定作業と委員会運営の両方まるごと引き継いだわけです。お、おぅ。
※実際は情報セキュリティ委員会の定義そのものから全部作り直したのですが、そのお話はまた後日
そしてこの情報セキュリティ規程、もちろん会社の規程としますので、全従業員守れよ？いいな？絶対だぞ？という鉄の掟となります。それなら好き勝手やってやるぞ、というわけで、まず法令順守といった絶対的なポリシーや、判断基準・行動規範となるスタンダードを固めました。スタンダードで一番最初に明記している骨子はこれです。
全ての情報は、それを管理する管理者を定め、以下を管理すること
- その情報の開示先（情報開示区分）
- その情報は誰がどの様にアクセスできるべきか（情報アクセス）
ISMS/ISO27001 や ISO27002/JISQ27002 に何らかの形で関わったことがある方なら、開示区分はお馴染みですね。この情報開示区分と情報アクセス区分に関しては、また別の機会に別のところで記載する予定ですが、その前提となる最大のポイントが情報管理責任を明確化したことです。これが大元の「鉄の掟」です。
といってもピンと来ない方、或いは「そんなの当たり前やん」という方もいらっしゃるでしょうから、これが今回の情シスの話とどの様に絡むのか、もう少し具体的に見て行きましょう。
ここまでは情報セキュリティ委員会＝全社部門横断の委員会のお話ですが、ここから先は管理部門の１組織である情シスについてのお話しとなります。
SaaSは誰がメンテするか問題
みなさん、SaaS使ってますか？SaaS使ってますよね？SaaS大好きですよね？
SaaSの中のデータやアカウントって、誰が管理してますか？
新しく社員が入った時や組織変更などでSaaS内でのデータやアクセス権限を変える必要が出てきた時…そんなときの設定変更は、どうされていますか？
管理者を立てて管理していますか？それとも全部情シスですか？
辞令が出る度に都度アカウントやアクセス権限の管理をSaaS毎にする…なんて考えただけで面倒ですよね。地獄ですね。まっぴらごめんですね。
Active Directory や LDAP を用いたり、サクっとSCIMで連携したり…なんて設定しておく方が、圧倒的に楽ですよね？うんうん、わかります。
水はどこから湧くのか
では、その大元の人事データは誰が管理していますか？
人事ですか？情シスですか？
元データはどこに、どんな形式で保存されていますか？
門外不出のネ申エクセルですか？
古より代々伝わる一子相伝な秘伝のウナギのタレになっていませんか？
という話はともかく、実際のところ、様々な会社さんで最もよくあるのが以下のケースかと思います。
人事が何かマスターを持っている
Excelやスプレッドシート、CSVで「これですよろしく！」とポーンと渡される
情シスが受け取って人事DBに入れる
Active Directory やら LDAP やら IDaaS やらが更新される
Active Directory や SCIM で各SaaSに反映される
毎回Excelを受け取るのは面倒ではありませんか？
Excelを受け取るまで待っていなければシステム反映できないんですよね？
Excelにミスがあったり、修正が入ったらどうしますか？
これは典型的なウォーターフォールですよね？
というわけで「鉄の掟」＝人事データの中身は人事が責任を持つを更に推し進めて、へーしゃでは下記のようにしています。
全社で使うSaaSのアカウントとアクセス管理
この説明をする前に、前提として、へーしゃで使用している様々なSaaSのうち全従業員が必ず使う＝全社的に使用されている代表的なものを、目的と併せて並べておきます。
Google Workspace : メール、カレンダー、ビデオ会議、ストレージ、スプレッドシートなど総合的なオフィススイートを含むグループウェア
Slack : テキストコミュニケーション、botやワークフローを活用した業務フロー全般
Confluence : 様々なマニュアルや永続的なドキュメントの保持
SmartHR : 従業員個々の個人情報（家族・戸籍情報、給与振込先、年金関連、マイナンバーなど、就業する上で人事上保管しておく必要がある個人情報）
HRBrain : 組織図、目標管理、人事評価、1on1履歴、スキル、自己紹介、そのほか従業員に関する事柄で、業務上、従業員同士・社内で共有すべき情報、共有することで業務が円滑になる情報の保存と管理
少なくともこの5つのSaaSは、従業員として入社した際に必ずアカウントが発行され、従業員である限り永続的にアカウントを使用するSaaSとなります。
アカウントの発行
まず入社時に、これらのSaaSのアカウントを作成し、メールアドレスを設定し、名前を設定して…という作業が発生します。
このあたりをまとめてやってくれるSaaS管理サービスも、ジョーシス、メタップスクラウド、マネーフォワードIT管理クラウド などなど沢山ありますね。
また、最近はSCIMに対応しているSaaSも多いので、SCIMで連携しておいてアカウントの生成は設定含めて自動、とされている会社さんも多いでしょう。
ログインはSSOにしておけば安心で簡単ですね。SAMLに対応したSaaSも増えてきましたし、それを使われている会社さんも多いかと思います。
…あれれ？
SAMLやSCIMの設定は、誰がやりますか？
大元のSaaS管理サービスの管理は？
SaaSが増えれば増えるほど、結局、情シスの管理対象が増えていませんか？
アクセス権の管理
実はアカウントの発行やアカウントそのものの管理よりもっと面倒なのがアクセス権などを含めた組織管理です。
アカウントの名前やメールアドレスは無事連携して、サインインもSSOで簡単で、でも…
「Slackで教えてもらったConfluenceのページが開けない」
「Confluenceに貼られたスプレッドシートのリンクが開けない」
なんてこと、ありませんか？
「全部パブリックチャンネル！」
「社外秘なら誰でも見られるはずだよね！」
としておけば楽ですよね。
でも、特定の組織内や役職者だけに閲覧権限を絞りたかったり、社内誰でも見られるけど更新は特定の部門やチームの人だけにしておきたかったり。
はい、ここで鉄の掟です。「個々の情報はその情報管理者が管理してね」と。
とはいえ、組織変更で人が移動したり、新しく人が入ったりするたびに全部アクセス権を追加したり見直したりするのは、果てしなく面倒ですよね？
ITとかよーわーらんから情シスよろしく！と丸投げしたくなりますよね？
お断りです。勘弁してください。いくつあると思ってんですか。😇
ていうか知らんがな。
「鉄の掟どこいったん？」
アカウントの管理者、グループの管理者、システムの管理者の分離
というわけで、ここからが本題です。前置き長くてすみません。
へーしゃでは、以下の構成でアカウントとアクセス権をグルーピングして管理しています。
アカウントの作成と名前の設定
従業員個人に関する情報は、全て SmartHR をマスターデータとしています。
SmartHR
従業員が入社時に必ずアカウントが作られる。
管理者は労務人事。
個々の従業員に関する下記の基本データをマスターデータとして持つ。
氏名（ビジネスネームで日本語・英語の両表記）
社員番号
メールアドレス
入社日（就業開始日）
就業中・休職中・退職済といった就労状態
正社員、契約社員、アルバイトといった就業契約形態
退職済の場合は退職日
就業開始前、入社が確定して入社日・就業開始日が決まったら、SmartHRのアカウントが作られます。この時点で、メールアドレス、社員番号、社内での呼称（ビジネスネーム）が確定となります。その情報を元に HRBrain、Slack、Google Workspace、Confluenceといった各SaaSのアカウントが生成されるようにしています。
※具体的には、各SaaSのWeb APIをGoogle Apps ScriptやJavaScriptで呼び出して、人手を介さず生成しています。
もし戸籍上の名前が変わった場合でも、本人がビジネスネームでの呼称を継続したい場合は、SmartHR上のビジネスネームをそのままにしておけば、保険や年金、給与振込先といった個人に紐づく人事労務上の手続きは戸籍名で行いつつ、それ以外の社内の手続きやアカウントなどは全てビジネスネームのまま、といった取り扱いが可能になります。
もちろん戸籍名と併せてビジネスネームを変更するのも問題ありませんし、ケースとしては少ないのですがビジネスネームのみを変えたい場合にも有効です。
そして、氏名、メールアドレス、従業員番号といった、入社してから退社するまで一貫して変わらない（あるいは業務内容や役割とは関係なく変わらない）情報は、SmartHR 一箇所で変えればSlack、Google Workspace、Confluenceほか全てのSaaSアカウントの氏名、従業員番号が変わる、ということがポイントです。
更に、休職や退職というステータスの変更に応じて、他のアカウントも連動して停止 and/or 削除もされるようになっています。
そしてなにより、個人の情報を変えることが出来るのは本人のみ。かつ、SmartHR上のデータの変更に責任を持っているのは労務人事、というところが押さえておきたい要点です。
誰がいつ戸籍名が変わったか、休職しているか・退職したのか、と言う情報は、情シスが事前に全く知らなくても1ミリも問題ありません。それらは本人と労務人事が管理出来ていて、それに伴う関連した退職処理などの業務が正しく行われていれば良い事です。それらはすべて、SmartHRに保存されている情報を元に自動で動くようになっていますし、その影響を受けないSaaSや社内業務は、何の影響も受けずに動作し続けます。
アカウントが所属する集団
アカウントが所属する「集団（グループ）」に関しては、従業員の役職や役割、配属先が決まった時点でそれらがHRBrainに登録されます。もちろん、変更が起きた場合もHRBrain上のみで変更が行われます。
HRBrain
従業員が社内でどのような位置づけか、誰がどのような部門に所属し、どの様な役割を持つか、といった従業員と会社との関係性に関する下記の情報を定義、及び管理する、という位置づけ。
役職、役割の定義
組織名、組織構成、およびそれらを図表にした組織図・組織表
各従業員の所属部署、役職、役割、アクセスできる情報区分
従業員の評価者
従業員が持っているスキル
従業員自身による自己紹介
情報の管理者は部門人事（組織人事）。労務人事と同じ人事部門ではなく、各部門の組織開発の担当者が分散して担当することも可能なところがポイントです。
この情報を元に、登録された役職・役割・配属先に応じて Google グループが生成されます。そして、そのGoogle グループを元にSlack、Confluence、その他のSaaSなどのユーザーグループやアクセス権が自動で設定・更新されます。
こちらも同様に、設定されるSlack/ConfluenceのWeb APIを、Google Groupsの値を元に呼び出して自動で設定するようにしています。また、Google Groupsを始めとする各ユーザーグループやチャンネル名の命名規則を別途定めており、グループの作成やユーザーグループの生成は全て命名規則に則って自動で行われるようにしています。
またGoogleグループを元に他のSaaSのユーザーグループやアクセス権を設定
労務人事情報と組織人事情報を分けるのは何故？
この様に、センシティブな情報である労務情報・個人情報は労務人事が責任を持って情報を管理しつつ、同じ人事でも組織人事は労務情報や個人情報には全く触れずに分離して、部門組織側にて下位組織やメンバー構成、役割を柔軟に設定することができます。また併せて、組織変更や役割変更が起きた際は同じタイミングでアクセス権なども全て切り替わるようにしています。
情報セキュリティ的には個人情報を取り扱う情報取扱者を厳密に区分することができますし、社員個々に関わる業務と、社員と組織・社員間の関係性に関わる業務とを非同期でシームレスに行うことができます。
そして、組織改編、人事異動はHRBrain上で編集するだけで完結し、それを元にGoogleカレンダーに溜まっている会議の予定、Googleドライブのファイルへのアクセス権、そしてSlackでのメンション先やチャンネルの入室メンバー、Confluenceでのページやスペースのアクセス権に至るまで、HRBrainの編集のみで一気に完了します。
更に、組織を超えた社内活動や組織を横断するプロジェクトなども、この応用で対応出来るようになります。この場合、HRBrainではなくGoogleグループを単体で作成すればOKです。そこから先はHRBrainをベースにしたものと同じで、そのGoogleグループのメンバー構成に応じてSlackのユーザーグループやチャンネル、Confluenceのスペースやアクセス権なども併せて同時に設定されるようになっており、プロジェクトを立ち上げる際に必要な情報インフラを素早く整えることがかできます。もちろん、立ち上げ時だけでなくプロジェクトの進捗によって急な増員やメンバーの入れ替えが発生するような場合でも、Googleグループのメンバーを編集するだけ。メンテナンスが一気に容易になり、管理負担も減ります。
そしてなにより、その作業を情シスは一切行うことなく、すべて部門責任者やプロジェクト責任者の手中で完結することが大きなポイントです。
水道局と情シス、同じところと違うところ
この仕組みの中における、情シスの役割とは何でしょうか。
情シスが行っているのはあくまで「SaaS間の連携が動く仕組みを提供する」ということのみであって、「アカウントを作る」「アカウント名を設定する」「グループを作る」「グループの設定を行う」ということには全く関与していないことに注目してみてください。
情シスはアカウントもGoogleグループも全く作っていませんし、どんなグループがあるかすら知りません。もちろん中身のメンテも全く行っていません。
※とはいえどの様なグループがあるかを見たり知ったりすることはできますし、もちろんシステムの監査ログや動作ログなどから把握することもできます。一方で
SmartHRでアカウントを作れば他のアカウントも作られる
氏名はSmartHRを元に他のSaaSに反映される
HRBrainで組織移動が出来る
HRBrainを元にGoogleグループが生成され、GoogleカレンダーやGoogleドライブのアクセス権などもHRBrainを元に変更される
Googleグループを元にSlackのユーザーグループやConfluenceのアクセス権なども変更される
という「仕組みを提供する」ことが情シスのオシゴトであり、そしてその「仕組みが常に完全に動く」ことに責任を持っています。
水道局のオシゴト
水道局の役目は、端的に言えば公衆衛生の重要なインフラとして上下水道が円滑に機能することです。
具体的には、浄水場で精製された清潔で安全な水が、各家庭や企業、施設などに滞りなく必要な分だけ供給され、蛇口をひねればすぐに水を使え、しかも飲料水として飲めること。（上水道）
また各所から出た汚水・排水は詰まることなく適切に下水として集められ、滞りなく処理され、環境と衛生に充分考慮した上で廃棄、処分されること。（下水道）
この両水道の安定稼働です。
※東京都の場合は、上水道を管轄する水道局と下水道を管轄する下水道局に分かれています。
水が飲料水として安全でなければ家庭や施設などには配れませんし、足りなくなってしまったり、時間によって出たり出なかったりしたらとても困ります。蛇口をひねったら飲める水がすぐに出てくる。それが上水道に求められる必要条件。
そして、下水は人知れず集められ、適切な処理を施されて、安全に廃棄される。街に悪臭が漂うこともありません。これが下水道。
日本は世界でも稀に見る高水準の水インフラが、当たり前の様に提供されている国です。
ところが水道局は、各家庭で水を誰がどのくらい飲んだのか、お風呂の温度は何度にしているのか、そもそもシャワー派なのか入浴派なのか、珈琲は何時にどのくらい沸かすのか、ご飯は自炊派なのか外食派なのか…といった、水の個別の使われ方には一切関知しません。お湯が熱すぎて火傷してしまったり、水が多過ぎて御飯がおかゆになってしまったり、というのは、それぞれ水を使う側の自己責任です。
インフラ提供者としての水道局は、誰がどのように使うのかに関わらず、それらをすべて満たすだけの量と質の水が常に安定して供給され、そして汚水が滞りなく処理されること。つまり上下水道を中心として、それが安定稼働する事を守備範囲とされていらっしゃいます。
なので、どこかのご家庭が、お風呂のお湯を沸かし忘れて「今日は湯船に浸かってゆっくりしたかったのにシャワーで済ませざるをえなくなった！」とか、「今朝の味噌汁は薄かった！」と水道局に言われても、知らんがな、と言われるのがオチでしょう。
※ただし近頃では、あまりに異常に使われたり、逆に全く使われなかったりする場合はアラートを上げてくれる親切なサービスはあるようですネ
IT介護問題
情シス界隈で時折使われる、「IT介護」という衝撃的な言葉があります。
もし水道局が「水介護」も職務だとしたら…
「お湯の沸かし方がわからない人」「コーヒーを美味しく入れる適温がわからない人」「水割りに適した氷の作り方がわからない人」に対して、水道局から各家庭へ手取り足取り教えてくれる水道局員が派遣されることになります。
仮にそんなことになったら、今の水道システムは間違いなく維持できません。少なくとも、水道料金が今の数千倍、いやそれ以上になることは容易に想像できるでしょう。なにしろ、水を一杯飲むたびに都度人を呼び、人件費を払い、コップに水を注いでもらい、飲ませてもらって、また別の人がコップを洗い…となります。たった一杯の水を飲むだけで、一体どれだけの時間と労力が割かれてしまうのか、全く想像もできません。
水だけでなく電気でも同じですね。明かりの付け方、掃除機の動かし方…いちいち誰かに頼っていては、生活もままなりません。
ところが「IT介護」では、残念なことにまだまだこれに近いことが起きており、そして時には「それが普通」という概念までまかり通ってしまっています。たかだかコンマ何秒の数クリック、数タップで済んでしまうようなことに、多大な時間と労力が割かれることも珍しくない現場もあるようです。
情シス=情報インフラ提供者たれ
「水」や「電気」に比べれば「情報技術 = IT」は最後発となる「文明の利器」です。ですから、まだまだ使いこなすのが難しい面が多い点も否めません。とはいえ、他人に頼りっぱなしでは文明は前には進みません。
水や電気と同じく、情報も、安定したインフラが供給された上で、各自が責任を持って存分に活用できる様になれば、今以上に便利な世の中となることは間違いないでしょう。人類は、そうして文明を発展させてきました。というのも、水道、ガス、電気、交通、電話といった様々な既存インフラが、それを見事に証明してくれているからです。
一緒に素敵な情報インフラを作りましょう
株式会社ティアフォーでは、このような便利なITの仕組みを自ら企画・作成・提供することで、社内の様々な事業活動において迅速かつ高度な情報の活用を促し、会社の成長に貢献できるコーポレートエンジニアを募集しております。
本格的なWebサービスやSaaSを作るまでいかなくとも、Google Apps Scripts や JavaScript/TypeScript を駆使して各種SaaSのWeb API を呼び出し、データを連携させたり業務を自動化、簡便化して楽するのが好き・得意・やりたい！と言う方からの応募をお待ちしております。🙋♀️
この記事が気に入ったらサポートをしてみませんか？