LayerX Trustブログ #6 ISMSの取得と、エンジニアが主導するITガバナンスについて
※本記事は LayerX エンジニアブログにも掲載されています。
CTO室 @ken5scal です。座右の銘は「当社はブロックチェーンの会社ではもうありません」です。
主にインフラ構築・運用をしたり、社内の基盤を整えたり、自分のcommitが不具合を起こしてるのを特定して泣いたりしてます
Intro
当社は「すべての経済活動を、デジタル化する」というミッションを掲げており、生産性向上の達成という価値を新しいサービスによって提供しています。
しかしながら、新しい価値にはリスクが伴います。信頼できない価値を提供するサービスを採用する合理的な判断はありませんので、お客様に価値を価値のまま提供しなければlose-loseな関係になってしまいます。
今回は2021/08/27に発表されたISMS認証の基準準拠を含む、「LayerXは信頼できる」ブランドを確立していくための当社のITガバナンス活動について触れようと思います。
ガバナンス体制、その遷移
当社は代表の福島が「LayerXはブロックチェーンの会社じゃありません、という話」で述べたとおり、以前はブロックチェーンのコンサル事業を主としていました。
私が入社した2020年頃は、全員が機動的に配置を変え①Ethereumのシャーディング技術の研究開発 ②金融業界を中心としたブロックチェーンの設計・標準の調査およびPoCの開発に携わるような体制だったと記憶しています。
しかし、こういったコンサル活動を通して学んだことを基に、次のようなプロダクトの模索が始まります。大体、2020/04頃です。
- SaaS事業：LayerX インボイス, LayerX ワークフロー
- Fintech事業：不動産などのアセマネを裏付けとした証券発行 （三井物産デジタル・アセットマネジメント）
- LayerX Labs：Anonifyを使った事業研究
このようにプロダクト領域が定まるとともに、チームも固定化されました。
それとともに、コンサル事業をしていたころのような社内 or Notな情報セキュリティ管理の二元論ではなくなり、各部は各部の事業領域および成功にコミットする方針が打ち出されました。
言い方を変えると、仮に社内であっても職権や業務形態によって情報セキュリティ管理に強弱が発生したにほかなりません。
情報セキュリティ管理に毀損があればリスクが顕在化することに変わりはありませんが、そのリスクの性質およびその変化に対する対策も大きく転換を強いられることになります。
最初のガバナンス態勢とゴール
そうしてまず2020/08に立ち上がったのが「ガバナンスをいい感じにし隊」です。
この時点では、横断組織としてのCTO室がボトルネックにならないよう、各部におけるインフラ的なCommit（もちろんGit的な意味で）をしていたエンジニアを担当者として呼んでいます。横断組織における中央集権化は早晩にボトルネック化し、結果的に場当たり的かつ非実践的な対応になりがちだからです。
そして私の経験上、横断組織はそもそも採用が難しい（≒候補が少ない）領域です。もちろん採用を諦めるわけではないのですが、人の頭数によるスケールは悲観的に見ざるをえず、特に各部が独自の技術スタックを採用する当社においては、
事業リスクと対策・実装に詳しい現場が主導的に動いてもらう必要がありました。
ガバナンスをいい感じにし隊では、そういった現場の実装的なAsIsと世間一般で言われるベストプラクティスとのすり合わせをする場としての意識をしていました。
具体的には、以下のようなことを議題として取り上げています。
- AWSリソースにつけるタグのルール
- Secretsの管理方法
- AWS環境へのログイン方法
参加者のリソースの使い方に関する議論もあるなど、この頃はunofficialな場ではありました。
ISMS取得が決まってからの変化
2021/02に経営レベルでISMSの取得が決定しました。ゴールは変わりませんが、体制とスコープが変わりました。
情報セキュリティ委員長に代表取締役である松本（ @y_matsuwitter )を設置することで、体制がかなりオフィシャルなものになりました。
同時にメンバーをエンジニアに限定せず、経営管理や人事広報も含め各部から情報セキュリティ担当者を任命しています。特に事業部については、広く様々な観点が必要であるため、複数人にコミットをお願いしました。例えばDX事業部ですと、エンジニアとBiz（営業）を１名ずつ確保した形になっています。
なお、三井物産様と当社が出資して共同設立した「三井物産デジタルアセットマネジメント（MDM）」でアセマネサービスを手掛けるMDM事業部は、全員MDMに出向し、全て先方の契約・管理するシステム上で開発・運用することになっているため、LayerXのISMS審査対象からは外れています（この辺はまた別ブログにて）。
ちなみに、ISMSの審査自体は全てZoomによるリモート審査でした。ただISMSの範囲に含まれるオフィスセキュリティなどの物理的な確認はZoomで画面共有をしながら審査してもらいました。たまたま出社している社員が指名され「今、情報資産の扱いはどうなっているか」といった抜き打ち的審査もありました。
どういうやり方をやっているか
現在は月１度の定例を設け、下記の情報を共有・議論しています。
- 各部施策の進捗状況確認
- ヒヤリハットの共有
- 最新の動向の共有
また、全社を巻き込む議論については、GitHubのIssueでの議論をしています。
例えば次のIssueでは、LayerXに参加した時点で追加されるグループメールを、
事業の変化とともにその役割をおえたということで廃止を提案したものです。
ここで重要なのは、背景とその際に上がった意見、そして結論に至った仮定を残し、タイミング関係なくそういった文脈が参照可能な形で保存されることです。
そういった意味では、だんだんとGitHubを使わないメンバーが増える中、また
異なるやり方を考えねばならないフェーズに来ていると思っています。
これから何をやるか
さて、ITガバナンスが代表取締役配下におかれたということは、PDCAのように執行および振り返りを計画的にやっていく必要があります。2021年度の対応としてエイヤっとやることは、以下の通りです！ちょっとまだブログで公開できるか自信がないので、まずは量が多いことだけお伝えします。
従来だとこのようなガバナンス活動は、エンジニア以外が手動でGUIを操作したり、チェックを年数回確認することが一般的だったかと思います。しかし、不確実性が高いスタートアップでは、ソフトウェア化によるガバナンスのコード化によって、計測可能な形でアジリティの高いセキュアな活動をしていかねばなりません。
従って、人を募集しようにもなかなか「これ！」といったポジション名を特定できません。そこで私たちは、あまり見ない求人を作成しました。名付けて「屋台骨エンジニア」です。
新しすぎて「？」になること間違い無いかと思いますが、要は横断的な活動によって事業を支えるポジションです。
本件について詳しく聞きたい方は当社のポジションにアプライいただくか、あるいは気軽にken5scal個人のmeetyでお話・議論させていただけると幸いです
お待ちしております！