2015年 DMM.com ラボ（現DMM.com）入社。2017年から社内の情報管理の課題解決に取り組む。その際に SSoT を実現する情報管理システム Pagoda を開発。2018年7月に完成させ、同年11月に旧システムのリプレースを完了。その他に OpenStack や StackStorm などの OSS 開発にも貢献。IPA未踏IT人材発掘・育成事業、認定スーパークリエータ。
合同会社DMM.com (以下、当社) の IT インフラ本部では、効果的・効率的な業務の実現のため SSoT と呼ばれる集約的な情報管理の手法を活用しています。これを実現するため Pagoda というアプリケーションを開発、そして2020 年に OSS として公開 し、この度こちらのデモサイトを一般向けにリリース致しました。
本稿では、情報管理が組織における生産能力にどのように影響するか（具体的には、組織が大規模化、また業務が複雑化した際に、組織の稼働効率を低下させる要因）と、SSoT 及び Pagoda による情報管理でどのように組織の生産能力が高まるかについてご紹介します。
情報管理の方法で組織の能力は変わるのか？
どんなに優秀な人材を多数擁する組織といえど、組織作りとコミュニケーションの方法如何ではその真価は発揮できないといった課題について、「エンジニアリング組織論への招待 [*1]」において理論的に解説されています。
同書では、組織の人数を増やしても組織全体の能力（情報処理能力）が向上せず、場合によっては人員を増やすほどに低減し得るという事を説いています。その理由として、コミュニケーションのコストを指摘しています。
（[*1] Chapter5. 技術組織の力学とアーキテクチャ / 「個人の総和が組織の能力にならない」より抜粋）
この理論は情報管理においても適用できると考えています。その理由は、組織運営の観点から見た場合、情報管理は本質的にはコミュニケーションと同じ性格を持つためです。
情報を管理する目的は (1) 自己が後で正しい記録を引き出せるようにする自己利用用途と、(2) 自己が得た情報を他人に共有するためのコミュニケーション用途に大別されます。このように組織的な活動において、情報管理とはコミュニケーションの一つの手段と位置付けることができます。
そして組織・企業活動の目的を「顧客を満足させる（その対価として報酬をもらい、その活動を通じて社会の発展に寄与する）こと」としたとき、コミュニケーション自体は直接的にはこれに影響しません。組織内でどんなに会議を重ね、従業員同士の交流がどんなに活発だとしても、顧客を満足させること（それを通じて売上を立てる事）はできません。同様に、情報の記載ミスの修正や、他の情報との不整合の確認や修正をどんなに頑張っても、残念ながら企業活動の目的に直接的な貢献は図れません。もっと端的に言うと、どんなに頑張ってもお金を（おそらく成果や評価も）得られません。
しかしコミュニケーションなしには、組織的な活動は不可能と言えます。つまり、より効率的・効果的なコミュニケーション・情報管理が組織の能力を向上させることに繋がります。
[*1] 広木大地 (2018). エンジニアリング組織論への招待―不確実性に向き合う思考と組織のリファクタリング 技術評論社
組織の能力を向上させる情報管理の方法とは？
機材を運用する部署が対象機材の情報を管理したり、営業を行う部署が顧客情報を管理したりと、各々が必要な情報を、必要に応じて記録・管理する運用の場合、必然的に以下のように、それぞれの部署毎に管理する形になると思われます。
こうした管理形態を「分散管理」とここでは呼びます。おそらく、多くの組織においてスプレッドシートなどの表計算ソフトを用いて一般的にされている事だと思いますが、こうした管理形態で運用した場合に予測されるコスト（頑張ってもお金や評価に繋がらないムダな労力）を列挙します。
1. 情報取得に伴うコミュニケーションコスト
情報が分散管理されている状態では、ある部署のメンバーからは、別の部署で管理されている情報の存在はわかりません。こうした場合、往々にして (a) 求める情報があるか否か、(b) 求める情報がどこにあるかを確認するために、情報のハブとなる「人」に確認する運用がなされます。
業務フローにおいて「人」を介在させる設計は、以下の複合要因によって、その業務の効率を著しく低下させます。
(1) 人間の応答速度はコンピュータプログラムと比べて格段に遅いこと
情報を取得したい人（Aさん）が、目的の情報を把握していると思われる人（Bさん）に問い合わせ、確認をしてもらって返事をもらうまで、数十分から数時間（Bさんの状況によっては数日）掛かることがあり得ます。
(2) 問い合わせを受けた人の生産性を低減させること
業務フローに「人」が介在することによって、ある人（Aさん）の目的を達成するために、別の人（Bさん）の業務時間や労力が消費されます。加えて、人間は特定の作業に集中している際に、電話で呼び出されたり、声を掛けられたりといった形で作業を中断させられた場合に、その人の作業効率が低下することが知られています[*1]。さらに、問い合わせを受けた人（Bさん）が目的の情報を把握していなかった場合、さらに別の人に問い合わせが発生し、こうした生産性の低減が累積的に発生します。
一方で、業務フローに「人」を介在させるこは、承認といった組織統治（ガバナンス）を維持するために必要ですが、そうした合理的な理由が無い場合、組織の生産性を低減させる要因でしかなく、そうした要因を内在する情報の分散管理は、業務運用の観点からは非効率的な方法であると言えます。
2. 情報の管理・更新に伴うコスト
組織ではそれぞれの役割に応じて、様々な種類の情報を扱います。分散管理の方法では、組織内の部署毎に、その役割や目的に応じ、必要となる情報のみを管理すると考えられます。
ケーススタディとして、以下の組織構造・管理情報を例にして、分散管理された手法における情報の管理・更新に伴うコストについて考えます。まず製品開発部が管理する「製品情報」には以下のような情報が記録されているとします。
一方で顧客との売買に関する情報をまとめた「売買情報」には、以下の情報が記録されているとします。
（一部で「製品情報」の内容と食い違っている）
「製品情報」には、S0002 の納品日は 2024/07/31 に B者に納品したと記録がありますが、「売買情報」の T0003 には同社と取引した日は 2024/08/03 と食い違っています。このように、ある場所で管理されている情報と同様の情報を、別の場所でも管理することを、ここでは「多重管理」と呼びます。どちらの情報が正しいかは、記録からのみでは判断ができないため、他の情報による（納入記録や取引先への）確認が必要になります。
また製品 S0004 は「製品情報」によると、品質の問題がありどこにも納入されていないという記録になっていますが、「売買情報」の T0004 では C 社に販売したことになっています。こうした情報の不整合の実際の原因が「販売情報」を記録した際に "S0003" を "S0004" と誤記入したために発生したものだとしても、別のもっと深刻な可能性（品質不良の製品 "S0004" を実際に C 社に納品してしまった事態）も疑われるため、危機管理の観点からこうした事態が発生していないかの確認が必要になる可能性も考えられます。
このように、情報を分散管理させることによって、それぞれの情報同士の不整合を発生させる可能性を高め、また不整合が発生していた場合には、その確認や修正に記録する以上の多大なコストが発生することが予測されます。
さらに情報の管理が例で示したような部署毎に行われ、それぞれの部署において共有がなされていない場合には、不整合が発生しているという事実にすら気付かず、潜在的なの発見が遅れる事態も予測できます（私は危機管理の専門家ではありませんが、脅威となる危機を放置して事態が好転するといった理論は寡聞にして存じません）。
3. 情報の生成に伴うコスト
情報が「新たに生まれる」際に発生するコストも無視はできません。というのも、情報は常に肥大化・複雑化します。
こうした事象はエントロピー増大の法則によって説明されることもありますが、経験則に照らしても、新たな顧客の開拓、既存の顧客からの新たな要望、設備投資の増加、従業員増に伴う組織の複雑化など、今までに扱わなかった事象への対処が日々求められることからも、情報は常に肥大化・複雑化することは感じると思います。情報が常に増えることは不可避だとして、管理方法によって組織力にどのように影響するでしょうか。
例えば、製品開発部が「製造済みの製品の情報はあるが、製造前（または製造中）の製品に関する情報が無い！」といったことに気が付き、以下のように時間管理と資源管理の観点から「製造中情報」という情報の管理を始めた（情報を生成した）とします。
一方で営業部においても、同様に進行中の取引について管理したいと考え、以下のような情報を新たな情報として管理しはじめたとします。
（「製造中情報」と重複している情報を含む）
完全に同じ情報というわけではないにしろ、営業部で管理する「取引中情報」と、製品開発部で管理する「製造中情報」はかなりの部分で重複しています。このように、情報が分散管理されている状況においては、組織において必要な情報を、必要に応じて適宜生成しはじめた場合、多重管理の問題が深刻化する恐れがあります。
この他にも、秘匿情報を取り扱う場合には、秘匿情報を記録したシートを別途作成されると思いますが、その存在は他の人間からはわからないため、同様の情報を記載したシートが別の人間によって作成され、さらに情報の多重管理が進む結果となります。そして、こうした問題を解消するためには、お互いの組織で一層綿密な情報の共有や確認といったコミュニケーションが要求されるようになってしまいます。
情報が多重管理される問題は、つまるところ情報管理の運用の問題であるため、情報が集約管理されていた場合に必ず解決するというものではないですが、ある情報を別の情報と関連づけることができれば、ここまでに示した問題は解決できます。
SSoT で解決するこれらの課題
各部署が必要な情報を各々で管理するのではなく、以下のように基幹となるシステムで集約的に情報を管理する形態で管理する手法があります。こうした管理手法を SSoT (Single Source of Truth : 唯一の信頼できる情報源) と呼んだりします。
ここでは SSoT による情報管理において、分散管理で生じていたコストがどのようになるかについて見ていきます。
1. 情報取得に伴うコミュニケーションコスト
情報の集約が１つシステムに対してなされている場合、当該システムへの参照によって、即座に必要な情報を取得することができます。
こうした即時性だけでなく、業務フローにおいて「人」が介在しないことによって、組織全体の業務効率を向上させることができます。
さらに、情報は組織的な活動を行う上で必要な材料であると共に、活動の結果でもあるため、組織構造（部署の縦割り構造）に関係なく、組織のあらゆる情報が集約されている場合、組織内部の透明性が図られ、組織内の部署の連携の容易性（シナジー効果）が高まるといった副次的効果も期待できます。
実際に、我々 DMM の IT インフラ本部の活動においても、情報の集約管理を始めてから、運用・財務・セキュリティといった様々な部署との業務連携が基幹となる情報管理システムを軸に構築されました。
2. 情報の管理・更新に伴うコスト
情報が集約管理されることによって、情報の多重管理の問題が構造的に解消できます。
さらに我々は IFTTT と呼ばれる様々な外部システムと連携する仕組み を活用し、情報の取得や整合性の検査などを自動で行う仕組みを構築しています。
これにより、従来人間が実施していた登録された情報の間違いや、他の情報との整合性の確認といった作業コストを低減させることができ、また誤った情報に基づいた作業によるオペレーションのミスの低減にも寄与できていると考えています。
3. 情報の生成に伴うコスト
基幹となる情報管理システムで、組織内で活用されている全ての情報が集約管理されていれば、既に管理されているものと同じ情報を新たに作成する事態は発生せず、ムダな情報の肥大化は抑制できます。
逆に、欲しい情報がシステムに無い場合には、その情報は組織として扱っていないという事を意味するので、そうした情報を追加することで、他の部署からも利用できる形で新たな情報が加わるので、情報の複雑化においてもムダなく対処できます。
このように SSoT により、情報の多重管理やそれに伴うコストが低減できます。
SSoT は万能な情報管理の方法ではありません。業務が非常に単純で、業務に関係する人数がごく限られた組織（あるいは個人）においては、スプレッドシート１個（あるいはノート１冊）で事足りるかもしれません。ただ、組織全体で扱う情報の量と人数が１人の人間で把握できる限界を超えた環境において、組織の能力を最大限に発揮することに関しては SSoT による情報の管理が最適な方法であると考えています。
Pagoda で実現する SSoT
SSoT 自体を実現するのは容易ですが、継続することは難しいと考えます。SSoT を実現する方法は無数に存在します。例えば、複数の乱立したシートを１つに強引にまとめ、以後それを組織全員で参照・更新することができれば SSoT と言えなくはありません。しかし、こうした運用を維持するのは極めて難しく、すぐに破綻をきたし、実態として元の分散管理の方法になることが予測されます。SSoT の実現を難しくする大きな要因は以下の２つであると考えます。
(1) 情報の多次元性
(2) 情報の秘匿性
ビジネスの成長に伴い、情報は日々増殖・複雑化することは既に述べましたが、その構造は以下のように多次元的です。これをひとつのシートだけで表現・管理し続けるのは現実的に不可能と言えます。
またセキュリティ・クリアランス（情報にアクセスできる権限の適正管理）などの観点から、特定の情報にアクセスできる人間を、特定の権限・役職を有する人間に絞りたいといった要求があります。
Pagoda では以下の２つの基本設計によって、これらの要因に対処しています。
(1) モデルとアイテムによる情報の抽象化と関連付け
Pagoda では、「モデル」と「アイテム」という２種類のデータ構造によって全ての情報を取り扱います。
- モデル ：どのような種類の情報を持つかを定義したもの
- アイテム ：モデルによって規定された具体的な情報を持つもの
先ほどのケーススタディで扱った情報を Pagoda のモデルとアイテムに変換して表すと以下のようになります。
このように全ての情報がアイテムという形で表現され、そしてそれぞれのアイテムが関連づけられ、全体で一つの情報ネットワークを構成しています。これにより、情報がどんなに複雑になろうとも、基本的なデータ構造を損なうことなく情報の拡張・複雑化に対応することができます。
(2) モデル・アイテム・属性に対する RBAC による権限管理
Pagoda では、モデル（ 例：顧客情報全体 ）・アイテム（ 例：山田太郎さん ）・そして属性（ 例：連絡先 ）レベルで、ロールベースでのアクセスコントロール (RBAC) による権限管理が実現できます。
これにより情報を集約しつつ、情報の秘匿性を同時に担保することができます。
また分散管理において秘匿情報を取り扱う場合、お互いに秘匿情報の存在が認知できないため、それぞれが秘匿情報を作成し、情報多重管理によるコストの増大や、別々の方法によって秘匿情報が管理されることによる漏洩リスクの増大が起こり得ました。しかしPagoda では、許可されていないユーザからは、当該情報にアクセスすることはできませんが、情報がそこに存在していることがわかるため、こうした問題が避けられます。
Pagoda「デモ」サイト
このたび、情報管理でお困りの方や、組織でもっと効率・効果的に情報を取り扱いたい方に向けて、DMM の IT インフラ本部で開発・運用そして、活用している Pagoda を使い SSoT を体験してもらうため、デモサイト をリリース致しました。
ご用意したデモサイトでは、以下のように食材を調達して、パスタソースを製造し、販売する架空の食品加工会社を例に、当該組織で活用するあらゆる情報（人事・顧客・製品・契約情報など）を集約しています。
（食材（左）を調達し、パスタソース（右）を製造・販売）
実際にログインしてもらうと、以下のように当該会社の人事・顧客・契約・製品などの業務で必要とする情報がプリセットされています。
こちらに登録されているデータは、参照・検索はもちろん、自由に更新・削除を行なっていただいて構いません。モデルの拡張、アイテムの追加や絞り込みなど、Pagoda を使ってできる事を、ぜひ体験してみてください。
ただし、当サイトはあくまでデモ版で、ユーザさまに SSoT の PoC を実施してもらう意図でご用意したものであり、このサイトによってユーザが登録した情報の管理を保証するものでもなければ、ユーザが登録されたデータによって問題が生じた場合につきましても、当社は一切を負いませんのでご注意ください。
おわりに
我々がこちらのデモサイトをリリースした目的は、Pagoda による情報管理によって業務を効率化する仲間を増やすことにありますので、もし、情報管理で困っている方、Pagoda に興味があるという方いらっしゃいましたら、↓こちらからご連絡ください。
我々の仲間になっていただける方へは、最大限の協力を惜しまない所存です。
