2021/04/22 文字の発明とデータマネジメント

データマネジメントについて色々と勉強したり業務をしていく中で、『「データマネジメント」と名前は付いているけれど、とても普通のことをしているのでは』という感覚がでてきました。もちろん技術的な話はあるのですが、ガバナンスが大切だとか、用語集を統一しましょうとか、とても基本的な事項が多く含まれます。

それであれば何か歴史から学べることはないか？とぼんやり考えて、Twitter でもツイートしたりしたのですが（面白いリプをいくつかいただきました）、先日Podcastを聴いていて気づきがありました：

歴史を面白く学ぶコテンラジオ （COTEN RADIO）

• COTEN inc.
• History
• USD 0
• 

podcasts.apple.com

コテンラジオは同僚がお勧めしてくれてたまに聴いていたのですが、その第3回で「文字の発明」についての話があります。私は専門家でも何でもないので詳細はPodcastを聞いていただくとして、以下のような話題が話されていました：

• 文字の発明によって、物事を記録することができるようになった
• 文字によって思考の抽象化が進んだ
• 紙の発明によって利便性が向上した
• 凸版印刷の発明によって大量印刷ができ、多数の人が同じ情報を共有しやすくなった（マスメディア）

この一連の流れは 1:N の情報伝達手段であるマスメディアまで発展し、インターネットの登場によって成熟しきったと考えられるようです。そしてインターネットの利用が深まるにつれ、個人が発信する新しい時代（多対多、N:M）に突入していったというんですね。「文字」というテーマでここまで話が広がるのかと驚きます。

さらにこの情報伝達を効率化するために、古代都市は街の整備にとても力を入れていたそうです。中央集権国家では効率的に情報を集め、効率的に情報伝達（拡散）させることが大切なのでしょう。知識がないので想像しかできないのですが、飛脚のような役割の人や、馬などが通りやすいように道路を整備したりしたのかもしれません。日本だと五街道はよい例かもしれません。モールス信号のような遠隔で情報伝達できる手段についても触れられていて、私からするとアナログなインターネットのような雰囲気さえ感じます。

ここまで書けばデータマネジメントとの相似性がかなり見えてくるのではないでしょうか。紙の発明は石版・木版に比べればデータ書き込み速度の向上（もしくは保存容量の増加）に擬えられそうですし、凸版印刷はコピー速度の向上、街整備はネットワーク整備や組織構築に近そうです。どんなツールを使って、どんなガバナンス体制を敷くか。小さい街・国づくりのような気さえしてきます。ガバナンスが弱いと統制が効かない点も、まさに一国のような気がします。

かなり類似性がありそうだという気づきだけがあるだけでまだ深く考えられていないのですが、コテンラジオのおかげで「データマネジメント」を違った観点で見ることができそうですし、データガバナンスがデータマネジメントの肝、というのはやはり正しそうです。

にしても、歴史は面白いですね。「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言いますが、私は歴史の授業は苦手でした。でもコテンラジオは歴史嫌いだったのに歴史マニアになってしまった人たちが放送しているようで、楽しく聞けると思います。よかったらどうぞ。

2021/03/12 データマネジメント成熟度のフレームワークに何を使えばよいか

データマネジメントについて色々考えている時期で、今日は成熟度について。

様々なフレームワーク

とあるプロジェクトでデータマネジメント成熟度を測ろう、となったのですが、成熟度を測るフレームワークにも色々あるようです。

www.cloudtimes.jp

こちらの記事で紹介されているのは以下の３つです：

• CMMI研究所 が定めるもの（DMM）
• Deloitte 社が提供するもの
• Data Orchard 社が提供するもの

他にもウェブ検索していたら EWSolutions 社が提供するものも見つけましたが、大半はコンサルティング企業が有償提供するサービスが多いようです。

ちなみに Deloitte 社が提供するものは、アンケートに答えるだけで成熟度が測れるので面白そうです。ちょっと軸が独特な気がしますが。

Data Maturity Benchmark

DMBOK の書籍の中に紹介されているのは、

• CMMI データマネジメント成熟度モデル（DMM）（これは上と重複）
• EDM 協議会 DCAM
• IBMデータガバナンス評議会成熟度モデル
• スタンフォー ド・ データガバナンス成熟度モデル
• ガートナーのエンタープライズ・インフォメーションマネジメント成熟度モデル

…というように非常に多くのフレームワークが存在します。

さらに「DAMA-DMBOKはDMMAの準備や基準を確立するために利用できる」ともあって、DMBOK 自体を成熟度を測る基準にできる、とも書いてあります（ただしその方法やチェックリストは書かれていません）。

CMMI研究所 DMM(DataManagement Maturity)

唯一 CMMI研究所が定めるものが、CMMI の前身がカーネギーメロン大学のソフトウェア工学研究所であったことからなのか、無償でチェックリストが公開されています。以下のリンクからCMMI研究所が定めるデータ成熟度モデルのチェックリストがダウンロードできます：

CMMI Institute - DMM Model At-A-Glance - Japanese Language (Digital Version)

CMMI研究所の定めるDMMは5+1カテゴリ

DAMA DMBOK での成熟度チェックリストは公開されていない

私が会社の方と読み進めていたのは DAMA DMBOK(v2) だったので、できれば DMBOK ベースのものがないかなぁと探していました。データ総研の記事によると、CMMI DMM と DAMA DMBOK の関係が紹介されていて、DMM は6カテゴリに対して DMBOK は10カテゴリ（v1当初？）ですが、DMM でも DMBOK 10カテゴリの内容は網羅されているとのこと。

データマネジメントマチュリティモデルその2 | 株式会社データ総研

それでも今から CMMI DMM ベースで成熟度を測るのがやや抵抗と手間があるのと、DMBOK の書籍内でも11カテゴリに対してレーダーチャートで成熟度を描画している図があるなど、DMBOK の11カテゴリをベースに成熟度評価できるようにも見受けられます。DMBOK が教科書だとすると、それをどう計測するかは各々の状況に応じて・・・ということなのでしょうか。

それに CMMI DMM だと書籍が英語のものしかなく、技術的な学習であれば英語でもよいのですが、会社に広めようと思うと日本語書籍がある DMBOK でないと苦しい気もしています。

データ総研では DMBOK を読み込み、独自のチェックリストを作成して成熟度評価されているそうです。すごいですね。そういったサービスを利用したい気持ちもありつつ… ひとまず簡易的なDMBOKベースでの成熟度評価チェックリストを作ってみようと思っています。意外と公開事例が見つからなかったので、ちゃんと整備して運用できれば、社外公開などもいつかできるかも・・・いやどうだろう、分かりませんが。。DMBOK の復習にもなって、今のところは楽しめています。

謝辞

Twitter で情報いただきました もりたく様、ありがとうございます！

DM成熟度チェックは各種コンサル会社が有償サービスでやっているケースが多く、CMMIのDMMを除くと公開情報は少ない印象です。
ただ、以下サイトにチェックリストの項目要素等が記載されてます。
DMBOKベースのチェックをする参考になれば幸いです。https://t.co/iFKKmojPaOhttps://t.co/IzWI2Hh0av

— もりたく (@moritata9) March 11, 2021

2021/03/05 データマネジメントは成熟度から進める

雑談：テレビについて

最近 NHK の ねほりんぱほりん がかなり気に入ってます。見ないようにしてきた世界（最近の放送だと戸籍がない人、闇金の取り立て人、DVをしていた人）のドキュメンタリーをあんなふんわりしたテイストで提供するなんて驚きです。。番組構成はシンプルなので民法でどうしてやらないんだろう？と思ったら、スポンサーの関係で難しいのかもしれません。ザ・ノンフィクションとかも嫌いじゃないんですが、ねほりんぱほりんの方が気軽に見れて好きです。民法だと不倫騒動など同じテーマばかり扱われているのも好きではないので、意外と攻めた番組を作っている NHK とか、ショッピング番組の QVC とか・・・テレビではないですが同じ理由で ABEMA を見る、というのも人によってはありそうですね。

元々実家ではバラエティばかり見ていた家族が嫌で、割と部屋に籠もっていたことが多くて、一人暮らしして何年かはテレビを持っていませんでした。高校〜大学の頃ですかね。学び続けないと、という強迫観念みたいなものがあって・・・今でもあるんですが、バラエティばかり見ている家族、というのが嫌でした。

ところが一人暮らしして何年かして、体に不調があって精神的にまいっていた時期があって、その時にふとテレビがほしいなと思ったんです。土日の昼過ぎ、ベッドで横になって何も考えられない時でしたかね。テレビ見たいな、と突然思ったんです。

それからテレビを買って、少し地上波を見た後は Amazon Prime Video でひたすらドラマと映画を見ました。実家では能動的にテレビを見なかったので映画は何も分からなくて、そういえば父親は寅さん見てたなとか、昔スターウォーズ勧められたけど見なかったな、という感じで有名どころばかりですが楽しかったです。英語字幕で見るとリスニングの勉強にも多少なっていたので罪悪感がなくてよかったですし、おかげでその後受けた TOEIC のリスニングは大幅に点数が伸びて驚きました。

データマネジメントは成熟度から考える

先日書いたデータマネジメントに関する記事ですが、

bynatures.hatenadiary.jp

「結局どうしたら良いのか、私もまだ分かっていません。」なんて締めくくってしまいましたが、DMBOK 読み直したり、データ総研さんの資料を頂いたりしてわかったのは、データマネジメント成熟度アセスメント（DMMA）を行い、幅広いデータマネジメント領域のどこにウィークポイントや理想との乖離があるかを明確にする、というのが最初のステップになるようです。

DMMA を進めるのもガバナンスが必要なのではないか、とも思ったのですが、

DMMAプロセスの監視はデータガバナンスチームの役割である。正式なデータガバナンスが存在しない場合、DMMAを開始した運営委員会か経営層が監視を受け持つ。

というように、ガバナンスがなくても気づいた人（？）から始めなさい、ということですね。

データマネジメントの成熟度を評価する必要があると判断した組織は、すでにその活動を改善するために取り組んでいると言える

とも書いてあります。DMBOK はどこまで行っても教科書でしかなくて、どう進めるか？についてはあまり触れられていないのですが、堅苦しい文章の中でこの一文は血が通っているように見えて励みになりました。

データ総研さんはいろんな資料を無料で公開していて、無料のウェビナーも定期的に開催しています。ウェビナーは一度参加しましたがとても分かりやすくて、自分が悩んでいる領域にはすでに先人が多く歩いてきたんだと分かりました。会社に頼んでセミナー受けさせてもらえないかな、と思っているのですが、はたして。

jp.drinet.co.jp

2021/02/19 データマネジメント改善の難しさ

最近、業務ではデータマネジメントの改善に取り組んでいます。

「データマネジメント」と一言にいっても、国際的な非営利団体 DAMA は DMBOK という、データマネジメント体系ガイドをまとめています。DMBOK が制定する領域では、以下の11の領域がデータマネジメントの対象とされています：

DAMAホイール https://www.dama-japan.org/Introduction.html

「データセキュリティ」や「データ品質」など直感的なものもあれば、「データ統合と相互運用性」といった聞いただけではよく分からない領域、「ドキュメントとコンテンツ管理」といった、それもデータマネジメントなの？といったものも含まれています。そして円の中央に位置する「データガバナンス」が、周りの10の領域を統合することを上図では表しています。

DMBOK はいわゆる教科書的な書き方がされていて抽象的な部分が多いのですが、実企業の状態に合わせてどのようにデータマネジメントを推し進めたら良いか、が "Data Management at Scale" という O'reilly から出版された本で記載されています。

Amazon | Data Management at Scale: Best Practices for Enterprise Architecture | Strengholt, Piethein | Network Administration

小さい組織では問題にならない

"Data Management at Scale" ではデータガバナンスについて、スタートアップや小さい企業では必要にならないと書かれています。これは小さい組織ではデータを管理するのは数人のみで、データも種類も比較的少ないからです。さらにデータに関する質問があれば、周りの人に聞けばすぐに解決できる状態だ、とも書かれています。

大きな組織ではデータガバナンスが必要

組織が大きくなるとそれぞれのメンバーが注力する領域が分化され、知識も分散していきます。意思決定プロセスが複雑になるにつれ、データ所有者も不明瞭になっていきます。同時にデータ利用に対する重要性や緊急性もまし、GDPR, CCPA といったデータ利用規制も最近では登場しており、個々人の努力では管理がしきれません。そこでガバナンスを強く敷き、データが正しく"管理"(management) された状態にすべき、ということですね。

大きな組織に、後からガバナンスを敷くことは可能なのか

最初からデータマネジメントが重要だ！と思っている組織は少なくて、大抵は後からその重要性に気づくと思うのですが、DAMA ホイールと周りの10個の領域を見ると、データガバナンスありきで物事を考え、整備するのが綺麗に見えます。実際に DMBOK では、効果的なデータマネジメントにはリーダーシップとコミットメントが重要だとし、CDO(Chief Data Officer) を据えることを提案しています。

企業の実情に合うように、DAMA ホイールの11の領域に関係性を定義したのが、Peter Aiken のフレームワークです：

Peter Aiken のフレームワーク https://blogs.sap.com/2020/07/09/why-hr-data-management-strategy-is-important-in-your-hr-transformation/

このフレームワークの面白いところは、青→黄→緑→赤 の順番に企業はデータマネジメントに取り組む、と考えている点です。最初にデータをため、モデリングし、セキュリティやワークフローエンジンを導入するなど、基本的な事項に取り組むと（青）、データアーキテクチャに歪みが生じ、データ品質の問題が生じ、メタデータが足らないことに気づき（黄）、データガバナンスの重要性に気づく（緑）・・・といった流れです。

ただこれもかなり理論的で、現実的には赤のデータ分析やビッグデータまでデータ活用が進んでから、土台部分の様々な領域に問題が生じる・・・ということが多いのではないでしょうか。スピードが求められるサービス開発では、データを利用した様々なアプリケーションがサービスイン直後から求められるかと思います。

しかしシステムが巨大化するにつれてデータ品質に問題が生じてデータへの信頼性が損なわれ、データアーキテクチャはその場その場で拡張された場当たり的な使いづらいアーキテクチャになり、利用者はそれぞれが使いたいデータを自由に使う、統制が取れない状態となります。

ピラミッドの各要素が下位レイヤーに依存していて、問題が生じているなら土台から固めるべきでしょう。上記フレームワークで言えば、結局データガバナンスを固めよ、ということになります。ではデータガバナンスとは何かといえば、データ自体やデータ利用方法に統制を敷くことなので、かなりのトップダウンが求められます。

結局どこから手をつけたら良いのか

DMBOK では CDO の役職を置き、長期スパンでのデータマネジメント改善へのロードマップを策定すべきと書かれていますが、実際はこのトップダウンアプローチを敷くのが難しいように思えます。データの問題に気づくのは現場のメンバーで、それを問題として管理者へ伝えていかなければなりません。

現場レベルで改善していくアプローチも取れるかもしれませんが、データマネジメントは想像以上にステークホルダが多いです。データを生成するシステム部門、それを使うユーザ部門が全て関係してきます。すでに業務が回っている状態だと、業務改善と称して既存の業務フローを変更してもらわなければなりません。

面白い考え方があって、業務改善が起こるには以下の式を満たさなければならないというのです：

C = D x V x F > R
D: 不満
V: Vision
F: ステップ
R: 抵抗

現状への不満と、改革へのビジョンへの共感、そこに到るまでのステップが明確化されていることの3つが、現状維持の抵抗を上回ったときに初めて改革が起きる、というのです。システム刷新などでも使えそうな考え方です。

データだと現場レベルでの考え方だと「とりあえず使えているし」ということで、「D: 不満」があまり起きていないような感覚があります。そのビジョンには共感するし今のデータにも多少不満はあるが、別に現状でもそんなに困っていない・・・といった感じですかね。これを草の根的に様々なステークホルダを対象にヒアリングし、改善してくのは大変な労力です。

結局どうしたら良いのか、私もまだ分かっていません。データマネジメントの知識が増えるにつれ、結局データガバナンスの欠如に戻ってきてしまうような感覚があります。それでもロードマップを敷き、やれることから少しずつ改善していくしかないのでしょうが、まだまだ経験不足だと感じます。

このあたり、一緒に議論していける方がいれば、気軽にお声がけください。まだまだ知識不足・経験不足なので、学んで理解を深めていきたいです。

2021/02/03 「内向型を強みにする」を読んで

ブログがすっかりご無沙汰になってしまいました。今見たら2019年の6月に書いたのが最後でしたね。

2019年、夏頃にチーム内の上長が退職してしまって、その代わりを務めることになってマネージャーとしてタスク管理や目標設定・面談なども行うようになりました。最初は私で良いのかなと思っていましたし不安でしたが、移動元の部署とやり取りすることが多いチームなので何とか働けています。

近々、今取り組んでいるデータマネジメントへの取り組みも思考整理のために書き出してみようかと思いますが、今日は最近読んだ本を一つご紹介です：

「内向型を強みにする」 https://www.amazon.co.jp/dp/B00DEEK1EY/

去年買って Kindle に入れたものの読んでいなかったんですが、ふとタイトルが目について読んでみたところ、とても面白い本でした。外向型・内向型という分類（もちろん明確に分けることはできない）を紹介していて、それぞれの特徴や、外向型が多い現代社会において、内向型の人間がどう適応していくかといったことが書かれています。適応先も、恋愛・仕事・子育てなどシチュエーション別になっていて、思わずうなずきたくなる場面が多かったです。

外向型か内向型かの判別方法がいくつか紹介されているのですが、最も簡単なものを抜粋します。A と B、どちらが多く当てはまるかというテストです：

（Ａ）

• 物事の中心にいるのが好きだ。
• 多様性を好み、単調だと飽きてしまう。
• 大勢知り合いがいて、その人たちを友達だと思っている。
• 相手が知らない人でも、おしゃべりするのは楽しい。
• 活動のあとは高揚し、もっと何かしたいと思う。
• 前もって考えなくても、話したり行動したりできる。
• たいてい元気いっぱいだ。
• 聞き手になるより話し手になることが多い。

（Ｂ）

• 自分ひとりか、二、三人の親しい友達とくつろぐほうが好ましい。
• 深くつきあっている人だけを友達だと思っている。
• たとえ楽しいことでも、外で何かしたあとは、休息をとる必要がある。
• 聞き役になることが多いが、自分にとって重要なテーマについてはたくさん話す。
• 無口で冷静に見え、観察するのが好きである。
• 話したり行動したりする前に、考えることが多い。
• 人前で、または、プレッシャーがかかったときに、頭が空っぽになったことがある。
• せかされるのは好きでない。

私の場合は A 2 or 3個/8個, B 7個/8個 でB（内向型）に寄っているようです。考えながら話すとか、人と話すとそれが楽しいものでも疲れる（外向型の場合は人と話すことがエネルギーの充電になるとのこと）、1日に予定は詰め込みたくない等々、当てはまる性質が多いです。ふいに電源が切れたように思考や口が回らなくなったりする、といったことも書いてあって、驚きました。実はよくあるんです。慣れない環境だったり、一緒にいることがストレスな人と長時間いると急に電源が切れたりして、そういう時は静かな場所で充電しないと次の活動ができません。

仕事では人に何かを伝えることを遠慮して業務を抱え込みがちな反面、人の話をしっかり聞いて熟考した上で判断するので上司には向いているともあって、弱みを理解して対処するようなノウハウはありがたいです。

ところでこの「外向型」「内向型」という分類、HSP, HSS といった分類にも少し似ているかもしれません：

studyhacker.net

この分類だと、HSP, 非HSP と HSS, 非 HSS の2軸があって、人間の性質を4象限に分けることができます。ただ「外向型」「内向型」はこの軸とはまた違いますし、何らかのフレームワークに人を当てはめるのは難しいことも多いです。どちらの分類にしても自分に近しい性質を見つけたり、近しい人たちとうまくコミュニケーションを取るための判断材料の一つとして使うなどして、うまく生きていくための術を得られればよいかなと思います。

2019/06/24 PlantUML によるロバストネス図

ユースケース駆動開発の手法を実践しているのですが、ロバストネス図・シーケンス図・ドメインモデルと、とにかく「図」を作ることが多いです。これを簡易にしないと作業効率がとても悪いということで、調べたところ PlantUML というツールがありました。

同じユースケース駆動開発を実践されているかたのブログも見つかりました。この方は vscode を利用されていますが、Atom にも PlantUML 可視化のツールがあったので、Atom でも大丈夫です。UML をコーディングしながらそれがすぐに可視化されて、そこからベクターファイルにも変換できるのでとても便利でした。

tk2000ex.blogspot.com

こちらは PlantUML の公式サイトです。各図の作成方法が詳しく紹介されています。

plantuml.com

私は既存のプロジェクトに対してユースケース駆動開発を当てはめようとしていて、ドメインモデルを構築するのがかなり煩雑で、言わんやクラス図をや・・・といった状態ですが、ロバストネス図までなら適切な工数で適切なアウトプットが出せそうかなと試行錯誤しています。どちらにしてもロバストネス図は必要なので、ひとまずここをターゲットに整理しています。このあたり詳しい方と話がしたい昨今。Twitter でご連絡お待ちしています〜。

2019/06/19 Elastic Beanstalk の ALB の scaling trigger では RequestCount がうまく機能しない

Elastic Beanstalk では ALB を簡単に定義することができます。今構築しているアプリケーションでは、リクエストがシンプルかつ大量であるため、リクエスト数に応じてスケーリングさせようと思い、スケーリングトリガーのメトリクスで RequestCount を設定していました。

ただあまりこの値を利用している例が見つからず、、AutoScalingGroup で直接、RequestCountPerTarget を設定している方はいましたが、RequestCountPerTarget は Elastic Beanstalk の管理画面では設定できません。ひとまずインスタンス化下限を十分大きな値にしてステージング環境で色々と調べたところ、RequestCount は ELB に対する指標で、有効指標が Sum であることから、ロードバランサーにどれだけリクエストが届いているか、という値で、いくらスケーリングしてもこの値は変化することはないようです。この辺りのフォーラムと：

https://forums.aws.amazon.com/thread.jspa?threadID=247542

https://forums.aws.amazon.com/message.jspa?messageID=399607

あとは公式の指標説明のドキュメントが役に立ちます：

docs.aws.amazon.com

そうすると、TargetResponseTime を使うか、NetworkIn/Out を使うかといったところで（CPU 消費するアプリケーションならCPUが良いと思いますが今回はCPUほとんど消費しないアプリケーションなのです）、リクエストがシンプルなので NetworkOut が有効指標になるかなと思っています。まだクラスタ立ち上げたばかりなので多めのインスタンスで立てておいて様子見中です。Beanstalk の公式ドキュメントでは NetworkOut をベースに説明されていて、初期値も NetworkOut の下限2MB上限6MBなので、とりあえずこれを参考にしつつ閾値調整かなぁと思っています。

docs.aws.amazon.com