現実モデリング

データとかエンジニアリングとか健エミュとか

すみません、孤独のグルメ、グルメ抜きでお願いします

カレーライスからライスを抜いたら何が残るだろうか。カレールーが残る。過去にカレーライスを食べた経験があるなら、「ライスが欲しいな」と思うだろう。

別の例を考えてみる。寿司からシャリを抜いたら何が残るだろうか。刺身が残る。寿司を食べるつもりだったのに、シャリが抜かれた寿司が出てきた。港区女子でないのなら「シャリが欲しいな」と思うはずだ。

僕は自分の生活を表現するのに「孤独のグルメからグルメを抜いたようなもの」と表現することがよくある。孤独だと主張したいなら「孤独」と言えばいい。そう表現しないのは、「あってほしい何かが欠けている」感覚を示すためだ。意味が一番近いのは「ファントム・ペイン(幻肢痛)」だと思う。

bsd.neuroinf.jp

四肢切断後の患者が、失った四肢が存在するような錯覚(phantom limb awareness)や失った四肢が存在していた空間に温冷感や痺れ感などの感覚(phantom sensation)を知覚する現象を幻肢と総称する。幻肢は四肢切断でなくても、脳卒中、脊髄損傷や末梢神経損傷などの運動麻痺や感覚遮断によっても発症し、これらは余剰幻肢と呼ばれる。また、乳房や陰茎、眼球などの切除後にも幻身体は現れる。幻肢に痛みを感じる現象を特に幻肢痛と呼ぶ。

東京に住んでいたり、インスタグラムを眺めていたりすると、グルメな生活に手が届きそうな錯覚が生まれる。豊かな食生活は幸福をもたらすが、それは幻想だ。幻想によって生み出された痛み、それを表現するのが「孤独のグルメ、グルメ抜き」なのだった(固定化された朝食、冷凍完全食、たまに外食)

しょうもな

現実世界のために:数字で振り返る健常者エミュレータ事例集2周年

はじめに

健常者エミュレータ事例集に初めて投稿された記事は、管理人がテスト目的で投稿した以下の記事だった。

healthy-person-emulator.org

この投稿をしたのが2022年の3月3日であり、2年前のことになる。今日2024年3月9日時点で合計投稿数は8985件、コメントの総数は20081件にもなった。改めて、健常者エミュレータ事例集の発展に協力してくれたユーザーに感謝したい。投稿してくれたユーザー、コメントしてくれたユーザー、運営に協力してくれたユーザー、投稿フォームにフィードバックをくれたユーザー、Discordのコミュニティ運営を手伝ってくれたユーザー、応援してくれたユーザー、技術的なサポートをくれたユーザーなど、様々なユーザーの支えで健常者エミュレータ事例集は成り立っている。

健常者エミュレータ事例集は健常者・非健常者を問わず、多くの訪問者が投稿やコメントを通じて互いに情報を共有する場所となってきた。そんな健常者エミュレータ事例集の2周年を、わかりやすく数字で振り返ってみたいと思う。健常者エミュレータ事例集がどのような性質を持つサイトなのか、少しでも伝われば幸いである。

基礎数値

まず最初に、投稿数やコメント数、PV数など、基本的な数値を追っていこう。

月ごとの投稿数

まずは月ごとの投稿数を可視化してみる。

月ごとの投稿数

  • 2023年1月の投稿数が2500となり、突き抜けて投稿数が多い。新規記事をX(Twitter)に投稿する際、5W1H+Then状況説明の画像を生成するようにしたためである。
  • 2022年の8月から急に投稿数が伸びている。Reactで作った投稿フォームが公開され、スマートフォンからも気軽に投稿できるようになり、投稿のハードルが下がったのが原因と思われる。
  • 2023-01を除くと、月ごとの平均投稿数は359件程度であり、一日当たり平均10件程度投稿されている計算になる。

余談だが、昨日2024-03-08にリニューアルした投稿フォームを公開した。コードがスパゲッティすぎて公開できなかった旧投稿フォームとは違い、今度のはコードを公開している。どなたでも開発に参加することが可能なので、よかったら見てみてほしい。Starをつけてくれるだけでも励みになる。

github.com

コメント数

次に、一つの投稿ごとのコメント数の分布を対数グラフで見てみる。

一投稿当たりのコメント数の分布

  • わかりやすく右にゆがんだ分布になっている。年収の分布と似たような感じか。
  • 一部の記事での大量コメントが目立つ(詳細は後述)
  • 平均のコメント数は2.23

PV数

PVは「ページビュー」を指す言葉で、ユーザーがどの程度そのサイトのページを見たかを示す値である。値をどこかにストアしておくのを忘れており、Google Analyticsの画面をコピペするぐらいしかできなかった。

Seesaa Wiki時代のPV数

Wordpress時代のPV数

※Google Analyticsを使っていなかった2022年4月から7月までの時代のデータは紛失した

  • 合計PV数は2年間で800万程度

人気のあったコンテンツ

次に、健常者エミュレータ事例集に投稿されたページ・コメントの中で最も人気があったものを確認してみる。「人気」を図る観点はいろいろあるので、いろいろな観点で見てみよう。

いいね数が多かったページ

いいね数が多かったページをざっと見てみると、有益な知見が上位を占めているのがわかる。上位10件の中に北朝鮮が2つある。

「無期限いいね順」からいいね数の多かったページは閲覧できる

1. 言葉は人格修正パッチである(いいね数:163)

個人的にもかなり好きな記事

healthy-person-emulator.org

2. 認知症患者の記憶力を侮ってはいけない(いいね数:125)

healthy-person-emulator.org

3. 異常行為でも行動の健常化につながることがある(いいね数:98)

healthy-person-emulator.org

PV数の多かったページ

健常者エミュレータ事例集においては、流入の半分以上がX(Twitter)からの流入となっている。TwitterでバズりやすいページはPV数が多くなりやすい。

1. セックス中にコンパクト性を確認しない

healthy-person-emulator.org

2. [メタ事例]コミュニケーションの目的は情報伝達だけではない

早く知っておきたかった

healthy-person-emulator.org

3. 横浜のデートで北朝鮮の工作船を見に行こうとしてはいけない

健エミュ初期のキラー記事

healthy-person-emulator.org

コメント数の多かったページ

記事の内容がcontroversialな場合、コメント欄での議論が活発になり、コメント数も多くなりやすい。

1. 先生の言うことにすぐに従うべきでは無い。(コメント数:129)

healthy-person-emulator.org

2. 友人の家にインターフォンを鳴らさずに無言で入ってはいけない (コメント数:113)

healthy-person-emulator.org

3. ダウン症の子供をちいかわと呼んではいけない(コメント数:77)

healthy-person-emulator.org

もっともいいねされたコメント

上位3コメントを下痢便あみだくじが独占する結果となった。 余談だが、うつ病とユーモアは関連されて研究されることも多い。真面目に考えることも大事だが、同じくらいユーモアも大事だと管理人は思っている。

いいね数 コメント内容 親ページタイトル 親ページURL
122 全部ハズレじゃねぇか ジャングルジムの頂上で大を我慢してはいけない https://healthy-person-emulator.org/archives/27502
86 下痢便あみだくじってなんだよ ジャングルジムの頂上で大を我慢してはいけない https://healthy-person-emulator.org/archives/27502
84 下痢便あみだくじって日本語好きすぎる ジャングルジムの頂上で大を我慢してはいけない https://healthy-person-emulator.org/archives/27502
81 昔同居してた認知症のおばあちゃんが人恋しさで毎日同じ話するのを嫌がって距離取ってたけど今思えば酷いことしてたな なんの意味もないような会話でもニコニコして話聞いてやってなんか簡単なゲームでもしてやれば良かった孫に辛く当たられてどこにも居場所がないような気がしたから徘徊したりトイレ失敗したりしてたんだなって 認知症になっても人間は人間で 物覚えが悪くても心はあるんだと言う当たり前の事実をしっかり覚えておかないと後悔することになる 認知症患者の記憶力を侮ってはいけない https://healthy-person-emulator.org/archives/30022
77 自己診断で気軽に発達障害を自称してる奴らはこういうの読んだ方がいい 試食用コーナーの「ご自由にどうぞ」で本当にご自由に食べてはいけない https://healthy-person-emulator.org/archives/27362
74 聞こえてたことわざわざ伝えるのが健ブレだよ 陰毛の話をする際にはリスクマネジメントが必要 https://healthy-person-emulator.org/archives/33982
72 これが本当のウインナーコーヒー 電気ケトルでウインナーを茹でてはいけない https://healthy-person-emulator.org/archives/28153
72 凄く自己肯定感が低いけれど優しい人なんだね 「世界への仕返し」だと思って異性にアプローチしてみた https://healthy-person-emulator.org/archives/31448
71 メタ事例 その人が納得して付き合っている交際相手を不用意に貶める発言をするべきでは無い 銀座のオシャレな喫茶店でベーリング海のカニ漁の話はしない方がいい https://healthy-person-emulator.org/archives/30132
70 その性癖をここで開示しなきゃ始まらないぞ 飲み会での下ネタトークでアクセルを踏みすぎてはならない https://healthy-person-emulator.org/archives/32133

評価の分かれたコンテンツ

次に、以下の式を基準にして「重みづけされたエントロピースコア」を算出し、評価の分かれたコンテンツの検出を行った。なお、Gはいいね数、Bはよくないね数である。

重みづけエントロピースコアについて:

  • GとBの値が近いほど、スコアは大きなものになる。つまり、「いいね」の数と「よくないね」の数が近いほど、スコアは大きくなる。
  • G+Bの値が大きいほどスコアは大きなものになる。つまり、「いいね」の数と「よくないね」の和が大きいほどスコアは大きなものになる。

{\displaystyle \text{重み付けされたエントロピースコア} = -\left( \frac{G}{G + B} \log_2\left(\frac{G}{G + B}\right) + \frac{B}{G + B} \log_2\left(\frac{B}{G + B}\right) \right) \times \log_2(G + B + 1)
}

評価の分かれた記事

カッコ内はエントロピースコアを表す

1. 3年ROMれの精神は有用 (5.686857)

healthy-person-emulator.org

2. 自殺動画で音MADを作ってはならない (5.268799)

healthy-person-emulator.org

3. マクドナルドでカスタマイズをしよう (5.077953)

healthy-person-emulator.org

評価の分かれたコメント

コメント内容 親ページタイトル 親ページURL エントロピースコア
親を責めろ お前のせいでこんなに不幸になったと泣きながら責めろ 東京都内生まれて住んでいる子供は、親の転職転居に関する動向を注視した方が良い。 https://healthy-person-emulator.org/archives/33563 5.39
障害者が飲食店に来店してはいけない スタバのテーブルで障害者手帳メンコをしてはいけない https://healthy-person-emulator.org/archives/26916 5.38243
ネタ記事はこのサイトの趣旨に反しますよ Amazonの送付先に皇居の住所を設定するべきではない https://healthy-person-emulator.org/archives/33056 5.37147
鳥だって求愛行動する時は綺麗な模様見せてアピールすんのに、人間が求愛行動する時に悪臭漂わせてんのは自意識が鳥以下って感じするし、そんな鳥以下の自意識の奴にイケると思われてナンパされるたらプライド傷つくのもわかるわな この投稿にBadつけてる奴は体臭とか自意識のレベルが健常者じゃないから気をつけてな… お願いですから毎日お風呂に入って、洗濯済みの服を着てください https://healthy-person-emulator.org/archives/33913 5.11161
この投稿がタイトル通りに嫌味を含んでいていいブレイク例 知識を教えるときは嫌味を含めないほうがいい https://healthy-person-emulator.org/archives/27910 5.08409
この投稿もコンテンツをクソにする一員であるということに投稿者が気付ける日が来るといいですね 3年ROMれの精神は有用 https://healthy-person-emulator.org/archives/34977 5.02232
それは東京都内じゃなくても同じこと。 東京都内生まれて住んでいる子供は、親の転職転居に関する動向を注視した方が良い。 https://healthy-person-emulator.org/archives/33563 4.98739
ふつうにえっち 性欲旺盛だとしても小学生の従兄弟に性的行為をしてはいけない。 https://healthy-person-emulator.org/archives/32335 4.96998
いや、「こういうときに本当に届き得る住所や実在する宛先を設定すると事故る原因になるからやめとけ」って教訓は立派な集合知だと思うが? Amazonの送付先に皇居の住所を設定するべきではない https://healthy-person-emulator.org/archives/33056 4.9383
異性からサシの誘いを受けたら自分に気があるのかも?と考えるのは一般的だと思うので、承諾されて期待を抱くことは健ブレではないと思います(もちろん二者の関係性にもよりますが)。先方が何も考えてないか、筆者さんが一切下心を感じさせなかった(ので純粋に友情と捉えた?)か…… 多分一生独り身 https://healthy-person-emulator.org/archives/32127 4.90268

おわりに

こうして数字で振り返ってみると、多種多様な投稿がされてきたことがわかる。9000件近くの暗黙知が集まるとは二年前には思ってもいなかった。

健常者エミュレータ事例集は、健常者/非健常者の区分を問わず、すべてのユーザーに開かれた暗黙知の共有プラットフォームとして作られた。これからもそうであり続けたいと思う。時と場合に応じて誰もが健常者となり、誰もが非健常者となり、絶対的な常識は存在しない、そんな世界を生き抜くための糧を互いに提供できる場所を作りたい。今健エミュを必要としている人に、そんな場所が提供できれば幸いです。

マザーボードのBIOSをアップデートするときはよく名前を確認した方がいい

健エミュに書こうと思ったがマニアックすぎたのでやめた。自作PCの話だ。

朝起きて自作PCの電源を入れてみると、ディスプレイに映像が出なくなっていた。昨日までは動作したが、今日はなぜか動作しない。心当たりは特にない。とりあえずグラボの抜き差しや別ディスプレイでの映像出力を試したが効果がないので、BIOSをアップデートすることにした。マザーボードはASRockのX570S Phantom Gaming Riptideだった。

自作PCの構成は以下の通り:

  • CPU:AMD Ryzen 7 5800X
  • DRAM:Crucialの32GB × 2枚
  • グラボ:MSI GeForce RTX™ 4090 SUPRIM X 24G
  • マザーボード:ASRock X570S Phantom Gaming Riptide
  • LAN:Archer TX3000E

X570S Phantom Gaming RiptideにはBIOSフラッシュバック機能が搭載されており、画面が映らなくても背面USB経由でマザーボードのBIOSを更新することができる。このときに間違えてB550 Phantom Gaming RiptideのBIOSを入れてしまった。

そのあとはステータスチェッカーの「CPU」と「DRAM」が点灯し、すべてがダメになった。メモリの抜き差しやCPUの抜き差しなどいろいろ試した後、(最初にやればよかった)CMOSクリアを実施し、BIOSの再度アップデートを試したが正常に起動しなかった。

もう自分の手ではどうにもならんと思い、秋葉原に行ってツクモの「基本構成パーツ診断」のサポートを受けた。基本構成パーツ診断では、マザーボード・CPU・メモリ・電源・VGAの起動がうまくいかない場合に問題個所を特定してくれる。

support.tsukumo.co.jp

どうやらCMOSクリアがうまくできていなかったらしく、店員さんがCMOSクリアを実施し、BIOSアップデートをしたらBIOS起動画面までたどり着いた。その後は家に持ち帰り、SSDを接続しWindowsの起動を試したが、異常終了してしまった。いろいろ試した後、BIOS設定からブートの順番を変更したら正常に稼働した。なぜブート順番を変更したら正常に稼働したのかはよくわからない。

結局最初にディスプレイに映像が出力されなかったのはなぜなのだろう。なぜ壊れたのかわからないし、なぜ治ったのかもよくわからない。明日また壊れているんじゃないかと思える。

健常者エミュレータ事例集を支える技術

はじめに

  • この記事では、健常者エミュレータ事例集を構成する技術について記述します。
  • 健常者エミュレータ事例集を構成する技術について俯瞰的に見たのち、個々のコンポーネントについて触れ、技術選定をした歴史的経緯などについてもちょびっと書きます
  • Wordpressの異常な使い方として参考になれば幸いです

システム全容

健常者エミュレータ事例集を構成する技術

健常者エミュレータ事例集の本体のほかにも3つのコンポーネントがあり、それぞれ本体とREST API経由で接続されています。順を追ってみていきます。

健エミュ投稿フォーム

hpe-form-v2.vercel.app

作られた背景

  • 事前知識
    • 2022年3月から2023年2月まで、健常者エミュレータ事例集はSeesaa Wiki上で展開されていた wiki.seesaa.jp

    • Seesaa Wikiにはテンプレート投稿機能があり、事前に作成されたテンプレートを使って記事を作成することが可能だったが、PCからしかテンプレート投稿機能が使えない欠点があった

    • 当時、健常者エミュレータ事例集WikiのPV数は9割をスマートフォンが占めていた
  • 健常者エミュレータ事例集の理念を実現するためには、スマートフォンから記事を投稿できない状況を解消し、新規投稿を促進する必要があった

構成

  • Next.js + Vercel
  • 長所:無料枠の範囲内でできる
  • 短所:オーバーエンジニアリングな点
    • 正直Next.jsを使うほどではなかったかもしれないので、今はReact + Cloudflare Pagesで作り直そうとしている
  • 構成の欠点ではないが、作った当初はフロントエンドが全く分からず適当に作ったため、技術的負債がたまっている。現在では新規に機能を追加するのが難しい状態になっている

健常者エミュレータ事例集本体

  • Seesaa Wikiの機能が不足していたため、2023年の2月にWordpressを中心にする構成に移行した

構成

  • Amazon LightSail + Wordpress + Route 53
  • 長所:料金が定額であり、過剰な料金がかかることがない
  • 短所:過剰なアクセスが集中すると落ちる
    • 実際Xでバズって落ちたことがある
    • CDNを挟めば何とかなるかもしれない

利用しているプラグイン

  • wpDiscuz : コメント機能
  • WP Mail SMTP : ユーザー登録時のメール配信
  • Taxopress : タグ管理
  • Sassy Social Share : SNSシェアボタンの作成
  • Like Button Rating ♥ LikeBtn : 「いいね」「よくないね」ボタンの作成
  • Ivory Search : 検索機能
  • Advanced Random Posts Widge : ランダム記事リストの作成

健エミュ分析基盤

  • 健エミュ内に蓄積されたデータを分析するために作成された

構成

  • dbt Cloud + BigQuery + Looker Studio
  • 長所:激安。ほぼ無料に近い
  • 短所:特になし

参考:

contradiction29.hatenablog.com

健エミュX通知Bot

  • 作った背景:Seesaa Wikiを使っていた当初、Seesaa WikiにビルトインされているTwitter(当時)連携機能が不十分だったため自作した
  • 10分に一回REST APIをたたき、新しい記事があったらスクレイピングして投稿画像を作成し、X APIを使って投稿する仕組みになっている
  • コードはこちら

    github.com

構成

  • AWS Lambda + Serverless Framework + Python
  • 親の顔より見たPythonで作った
  • 長所:激安
  • 短所:特になし

おわりに

  • 追加で知りたいことがある方はこっそり教えてください

社内データ基盤 as a Product : いい感じにやっていけ

  • 筆者がスタートアップの「データ何でもチーム」をやってきた中で、考えてきて実践してきたことを吐き出します
  • ポエムです

data as a product

データメッシュを実現する文脈の中で、「それぞれのドメインに分散されたチームが自身の提供するデータセットに対してproduct thinkingを適用するべきだ」とする考えが生まれてきた。

For a distributed data platform to be successful, domain data teams must apply product thinking with similar rigor to the datasets that they provide; considering their data assets as their products and the rest of the organization's data scientists, ML and data engineers as their customers*1.

(筆者日本語訳)分散データプラットフォームが成功するためには、ドメインごとに配置されたデータチームが自身の提供するデータセットに対してプロダクトシンキングを適用しなければならない。データアセットをプロダクトとして捉え、組織内の他のデータサイエンティストや機械学習エンジニア、データエンジニアを顧客とみなすのである。

この考え方を「data as a product」といい、平たく言えば「データセットをプロダクトとみなし、プロダクトマネジメントをやっていこう」と主張する考え方である。国内の大規模エンタープライズの中でデータメッシュを実現できている企業は聞いたことがない2024年2月現在だが、データメッシュの文脈から外れたとしても、「data as a product」の考え方は有効である*2と僕は考えている。

社内データ基盤 as a product

実際にデータの利用者の立場になって考えてみると、データセットそのものに対してProduct Thinkingを適用するだけではデータの利用者に対して価値を提供することはできないことに気づく。データセットは重要な要素だが、データの利用者は「自分のビジネスに役立つインサイトが欲しい」のであり、「データが欲しい」わけではないからだ。

インターフェースを入り口とし、インサイトを出口とする一連のユーザー体験の中で、データの利用者は価値を得る。この価値を最大化することが、社内データ基盤のプロダクトマネジメントの役割である。大事な事だから繰り返すが、「データを提供すること」は手段であって目的ではない。目的は「ビジネスインサイトの提供」である。

たとえば、BIツールのユーザー発行プロセスが面倒であり、結果的に社内の誰も使えない状態になっているのなら、ユーザー発行プロセス自体を自動化し、オンボーディング体験をよくする事も必要となる。データに触れるインターフェースを入り口とするなら、入り口に至るまでの段階がボトルネックになっている状態を解消することは責務の範囲内になる。

別の例として、「苦労して作ったが、使われていないダッシュボード」があるとしよう。ダッシュボードはプロダクトを構成する一つの機能と捉えられる。このダッシュボードは「利用数が少ないが、プロダクトの方向性と一致する」分類の技術的負債*3であり、優先度が低い場合は削除、優先度が高い場合はUX自体のアップデートが必要となる。プロダクトなので当然技術的負債もあり、社内データ基盤で実現したいゴールと現状から負債を分類し、アプローチする事も責務の範囲内である。

この「インターフェースを入り口とし、ビジネスインサイトを出口とする」一連のユーザー体験を最大化することを目的に、プロダクトマネジメントっぽくやっていくことが、「社内データ基盤 as a Product」の考え方である。

実践してきたこと

上記のような考え方をもとに今まで仕事してきたが、実際にやっていたことは一般的なプロダクトマネジメントの教科書に書いていることばかりであった。曖昧な状況をクリアにし、明瞭なコミュニケーションをとり、ユーザーに価値を届けるためにいろんなことをやってきた。たとえば以下のようなことである:

ユーザーのニーズ調査

  • ヒアリングやエスノグラフィの手法を使ってユーザーのニーズを調べる
  • 実践テクニックだが、ダッシュボードのニーズを調べるならホワイトボードにグラフをラフに書いて「あなたが欲しいのはこんな感じですか?」と聞くとスムーズである。詳しくはこちら

contradiction29.hatenablog.com

ビジネスインパクトを基準にした優先順位策定

  • データ基盤を運営していく上では、「アドホックなデータ抽出で済ませるか、ダッシュボード化するか」が判断の分かれ目になることが多い。後者はテーブルの作成が必要になる場合も多く、アナリティクスエンジニアリングの領域も絡んでくるためである。
  • この場合は「ビジネスインパクト」なんて難しい言葉を使わずに、「他の場面でも使用するイメージが想定できるか」を基準にしてダッシュボード化するか、しないかの判断をしていた。「ビジネスインパクト=PDCAサイクルを回す時間を削減できる程度」として捉え、多くのユーザーに使われるならそれだけ削減できる時間も長くなる=ビジネスインパクトがあるよね、とする考え方である。

品質

  • 当然であるが、データの品質がおかしくなることはある。
  • 特に手入力のデータをソースとするデータセットは被ってはいけないIDが被ったりすることが多いので、適宜dbtのtestを組んだりして品質担保をしたりする。

ユーザーに価値を提供する手段の選択

  • ユーザーにデータを提供する手段は複数あり、それぞれに得意不得意がある
    • ダッシュボード
      • 自動で更新することが可能
      • SQLで完結する範囲内ならなんでもでき、チーム内でも使えるメンバーが多い
      • 柔軟性に欠ける
    • Streamlit
      • 自動で更新することが可能
      • 動的にSQLを生成し、インタラクティブなダッシュボードを作成することができる。ダッシュボードを補完するツールとして利用可能
      • ダッシュボードよりは作成に時間がかかり、管理もダッシュボードと比較すれば面倒ではある
    • Slack API
      • 自動でプッシュ型の通知をすることが可能
      • オペレーショナルアナリティクスの場面で役に立つ。ユーザーに一方的にデータを送りつけることができるため、物忘れの防止に役立つ。
      • 複雑なデータは送れない
    • Google SpreadSheetのIMPORTDATA関数の利用
      • AWS Lambdaの関数URL機能とGoogle SpreadSheetのIMPORTDATA関数を使えば、スプレッドシートに直接データを吐き出すことができる
      • 営業やカスタマーサクセスチームの定常レポートなど、定型的な業務を効率化するために利用できる
    • アドホック抽出対応
      • プログラム化されていない分析を提供することが可能
      • 最も柔軟なデータ提供の形
      • 人的リソースの制約の影響を受ける
  • 実務では手段Aを指定されても最適なのは手段Bだよね、みたいに提案しにいく事も多く、複数の提供手段の得手不得手を理解し、最適なデータ提供の手段を考えるのはパズルのようで面白い

おわりに

雑に要約すると「社内データ基盤もユーザーを持つアプリケーションだから、プロダクトマネジメントしていこうね」という考えでした。それはそうだよね、と思ってくれたら嬉しいです。

*1:https://martinfowler.com/articles/data-monolith-to-mesh.html#DomainDataAsAProduct

*2:この「考え方は有効である」という主張はプラグマティズムの観点に基づくものである。つまり、その考え方があることによって、現実世界での行動はより意味があるものとなる。

*3:https://speakerdeck.com/sansantech/sansan-20231121?slide=14

私的:Notionで社内ドキュメントを書く時に気をつけていること

はじめに

  • この文章は、筆者がおしごとをしている中で気をつけているNotionのドキュメント作成術についてまとめ、記憶を整理するために作成されました。
  • 内容は些細なものであり、特段大きなテクニックはありません。
  • 参考にしてくれるとうれしいです。

0. ドキュメントを書く時の原則

読み手の認知負荷を下げる

ドキュメントは読まれるために書く。だから、できるだけ読みやすいように書く。

書き手の認知負荷も下げる

ドキュメントを書くのは面倒である。だから、できるだけ書きやすいように書く。

1. 最初にドキュメント概要を書く

ブレットを四つを使って、ドキュメントの一番最初に「ドキュメント概要」を書く。

  • ブレット一つ目:このドキュメントの存在意義
  • ブレット二つ目:記述していること
  • ブレット三つ目:(あれば)重要な補足
  • ブレット四つ目:読者に対して期待すること

例えば、チーム内の個人情報保護ガイドラインの冒頭に書く「ドキュメント概要」は以下のようになる


  • このドキュメントは、データ分析チーム内における個人情報の取り扱い方針を確立し、個人情報を取り扱う社員の負担を軽減するとともに、 個人情報漏洩などの事業上のリスクを削減することを目的に作成された。
  • このドキュメントでは、総務省ガイドラインによる個人情報の定義、社内における個人情報の定義、およびその取り扱いについて記述している。
  • この文章で定められた方針は、全社レベルでの個人情報取り扱いガイドラインが作成されたのちに破棄され、再構成される想定である。
  • このドキュメントは、現実世界における個人情報保護法関連、およびデータ基盤の利用状況に基づき更新されることを想定している。アップデートがあり次第更新すること。

ドキュメントの最初にドキュメント概要を書くと、以下のようなメリットがある。

  • 書き手にとっての利点
    • この文章で何をしたいのか、何の情報を伝えたいのか明確に文章化することにより、文章を書く方針がずれなくなる
  • 読み手にとっての利点
    • この文章が何の目的で作成されたのかわかるため、時代遅れになった場合に更新するかどうかの判断がしやすくなる
    • この文章で伝えたいことが最初にわかるので、この文章を読むべきかどうかが最初にわかる

2. ブレットは三段まで

ブレットを使う際、四段以上は入れ子にしないようにしよう。

  • ブレット一段目
    • ブレット二段目
      • ブレット三段目(←ここまでOK)
        • ブレット四段目(←これ以上組み込むと読みづらい)

経験則ではあるが、ブレットが四段以上入れ子になると読みづらさが急増する。四段以上になりそうになったら、段落を再構成しよう。

3. トグルは「閉じてても本筋には影響ない補足情報」を入れる

トグルは便利なので、見出しにされることがある。読みづらいのでやめよう。トグルを見出しに使いたくなったら目次をつけよう。

www.notion.so

トグルの中にトグルがあるととても読みづらくなる。可能な限りやめよう。トグルを使うのは「閉じていても本筋には関係がない、補足情報」に限ろう。

4. 絵文字を使わない

ノンデザイナーズ・デザインブックには、以下の四つの原則が書かれている。

このうち「反復」の原則は以下のようなもの:

デザインの視覚的要素を作品全体を通して繰り返すことです。色、形、テクスチャー、位置関係、線の太さ、フォント、サイズ、画像のコンセプトなどを反復させることができます。反復は、組織化を促進し、一体性を強化します

『ノンデザイナーズ・デザインブック』P13

絵文字は恣意的に、何の法則もなく使われがちであり、「反復」の原則を侵犯する。可能な限り絵文字は使わず、別の方法での構造化を考えた方がいい。

おれはデータエンジニアでもアナリティクスエンジニアでもなく、データを使ってビジネスをいい感じにしていきたいだけなんだ

キャリアの方向性について方向性が掴めてきたので、殴り書きしてみる。

俺はデータを使ってビジネスをいい感じにしていくのがやりたいんだ。

データエンジニアをやりたい訳ではない。アナリティクスエンジニアをやりたいわけでもない。どちらも単体では価値を出すことはできないし、データエンジニアとアナリティクスエンジニアはぶっちゃけ境界が曖昧だし、実務上兼ねることはよくあるし、役割上分けているのは採用しやすいからだと勝手に思ってる。同様の理由で、データアナリストも違う。データで価値を出したいなら全部やらないといけない。ビジネスユーザーやML担当者の話を聞いてデータモデリングをやり、データソースからデータをDWHに取り込み、ダッシュボードを作ったりする役の全部をやらないといけなくて、境界線はビミョいものになる。

そういうロールじゃなくて、なんかこう、データを使ってビジネスをいい感じにしていくのがやりたい。データ・パイプラインを一つのプロダクトとして、そのプロダクトをいい感じに成長させて、ユーザーの価値に貢献していくのが俺はやりたいんだ。価値貢献がゴールなのだから、手段はもっと自由に考えてもいいはずだ。データPdMは?と思ったけど、一般的にPdMにはエンジニアリングの権限がない場合が多いから、それも違う。自分でやらなくてもいいならそれでもいいが、大抵の場合は自分でなんとかする必要がある。

この世界にはデータを使って解くことができる魅力的な問題で溢れている。そういった問題を、フルコンタクトなやり方で解く仕事を表す単語はないから、「データ・ハッカー」とでも名付けてみるのはどうだろう。今までやってきたのは「データを使ってビジネスをいい感じにしていく仕事」だと思っているし、これからもやっていきたい。より良いやり方で、ベストではないけどベターなやり方を追い求めていきたい。

以下余談:

技術の進歩に伴い、データエンジニアリングをやるハードルは下がってきている。BigQuery, Snowflakeをはじめとするクラウド系DWHや、FivetranやAirbyteなどのELTツール、そしてdbtなど、技術選定をちゃんとやれば、運用負荷が低いデータ基盤を構築できる時代に今はもうなっている。実現できれば、運用保守に割く労力は減り、ユーザーとのコミュニケーションに費やせる時間が長くなる。

これからはフルコンタクトスタイルでも十分やっていける時代だ!と個人的には思っている。Web系の産業に勤める人間の思い上がりかもしれない。