街の本屋さんのアナログ伝票管理をデジタル化した話
- 本記事の雑な3行まとめ
- 背景
- プロジェクトのはじまりと課題設定
- 顧客の事情に寄り添いながらソリューション提案
- Google Spreadsheet + GAS で売上管理システムを作る
- GAS開発環境の整備
- 開発の中で学んだTIPSとか
- おわりに
この記事は データラーニングギルドアドベントカレンダー 4日目の記事です。
データ利活用をテーマに一つ四方山話を書こうと思います。
本記事の雑な3行まとめ
- 街の本屋さんのアナログ伝票管理をデジタイズするお手伝いをしました
- 顧客の課題はなんだろうって話
- GASでシステム開発する時のノウハウの話
背景
ある時、とある街の本屋さんでIT周りのお手伝いをさせてもらう機会をいただいたのですが、その一環として、全店舗の売上管理デジタル化に着手することになりました。
それまでその書店では、全て店舗ごとの売上は紙媒体で管理しておりました。その紙ベースの売上伝票を見ながら、経理部や社長が集計用のエクセルに手書きで打ち込んでいくという気の遠くなるようなオペレーションをしていたのです。
さらに、そのエクセルファイルはローカルファイルです。誰かに受け渡す際、コピーが発生してしまい、（重要な経営資料が）多重管理に陥るという状況でした。マスターデータの多重管理はあまり良い結果を生みません。
プロジェクトのはじまりと課題設定
まず何が問題なのかを明確にしました。上記のような背景情報をいただいた段階では、「自動で集計結果を出してほしい」という要望があるだけです。顧客から上がるのはソリューション案なので、それをそのまま実現するのではなく、そのソリューションによって解決しようとしている問題を明らかにすることが重要です。そして、それがそもそも問題であるかどうかも見極めて行く必要があります。
この段階では、何が問題なのかを明らかにするために話を聞き、議論を進めました。結果として、以下のような課題が浮き彫りになりました。
売上データを入力する行為が2重に行われている
- 工程として無駄である
- ヒューマンエラーが発生する量も2倍になる
離れた場所にいる者同士で同じデータを共有、編集できる仕組みがない
- 正確性を担保すべきデータが多重管理されてしまい、エラーを発生させる要因になっている
- 各店舗でレジ締め（夜10時以降）作業後、紙の伝票を経理部社員の元に物理的に集めて、はじめて集計作業にとりかかれるため、リードタイムが無駄に長い。売上管理のズレに気づくタイミングが遅くなり、諸々の対応が遅れてしまう。
顧客の事情に寄り添いながらソリューション提案
さて、上記の課題をみると、私のようなエンジニア風情の者からすると、「クラウド売上管理サービス導入すれば終わりじゃね？」って考えてしまうのですが、そういう訳にも行かない事情もあるようです。
例えば以下のような事情がありました。
- 本屋特有の収入パターンがある（地域の教職員互助会の助成券など）ため、一般的な会計ソフトで賄えない領域がある
- ITに詳しい社員が少なく、新たな枠組みを導入したときの教育コストが高くつくし、教育できる人材もいない
- そもそも新しいシステム導入ができるほど潤沢な投資予算がない
- など…
お金がないからシステム開発を委託することも当然難しいです。低コストでなんとか実現する必要がありました。
そんな中、どうやら「エクセルなら使える」ということもわかりました。
Google Spreadsheet + GAS で売上管理システムを作る
そこで、私が提案したのが Google Spreadsheet + GAS による売上管理システムの構築です。データインフラやプログラムのランタイム環境を完全にGoogleさんに頼った構成です。各店舗用のGoogleアカウントはすでに作っているということだったので、その点は幸いだったかなと思います。
この構成だと以下のメリットがあります。
- Google Workspaceのインフラを存分に活用することで、フルスクラッチシステム開発に比べて開発コストが抑えられる
- 運用コストも安い
- 店舗の社員は、Google Driveでのファイル共有などは少し利用しているとのことなので、新システムに対する心理的障壁が低い（と期待できる）
- 売上伝票の入力インターフェイスとして（エクセルライクに扱える）Spreadsheetを利用できるため、新システムに対する教育コストが抑えられる
- 私の以前のGAS開発経験（※素人に毛が生えた程度）を活かせる
まぁ、こんなとこでしょうか。
あとは個人的なものとして、 GAS 開発でいろんなことの自動化は前々から興味があったので、「自分が楽しいと思える」というものもあります。 楽しめることは重要です。
GAS開発環境の整備
さて、ここからは少しだけ技術寄りの話をしたいと思います。
この章で言いたいことは一つだけです。「数年前に比べてGAS開発環境は圧倒的に良くなった」ということです。
GAS の基本
基本的なことは以下の参考サイトを読めばわかるでしょうが、簡単に説明しますと、
GASは V8エンジンをサポートする JavaScript ランタイム環境です。最もシンプルなコーディング方法は、 Google Apps Script のプロジェクト画面のWebエディタを使う、というものです。
clasp + TypeScript こそ至高
さて、本格的にコーディングする場合は、好みのエディタを使いたいものですし、バージョン管理もしたい、Git Repository ホスティングサービスも使いたいです。そんな要望に応えるのがGoogle 社謹製 GAS 開発支援CLIツール clasp です。コマンド1発でGASプロジェクト上にコードをデプロイすることができます。
（本格的に開発したい場合は）clasp のない GAS 開発なんて有り得ないと、そう思います。そして、この clasp ちゃんですが、実は TypeScript のトランスパイル機能を内包しています。
使い方はこちら
DOA なシステム開発では TypeScript が有り難い
DOA という言葉をご存知でしょうか？
Data Oriented Approach の略です。日本語で言えば データ指向なアプローチ という意味になるでしょう。
私の尊敬するミック大先生の言葉を引用しておきましょう。
近年のソフトウェア開発では、データ中心アプローチ（Data Oriented Approach : DOA）という考え方が主流です。これは、文字通りシステムを作る際に、プログラムよりも前にデータの設計から始める方法論です。スローガン的に言えば「最初にデータありき」です。
『達人に学ぶDB設計 徹底指南書』（ミック）
ということで、システム開発の重要なポイントの一つはなんと言っても、 データ設計 です。
データのモデリングをしっかり実装しようとすると、クラスの継承、インターフェイスや型というものが欲しくなります。そういった事由から、今回 clasp + TypeScript という選択をしました。
開発の中で学んだTIPSとか
さて、最後は本開発で自分なりに学んだことを整理する場所とさせてください。ただの備忘録です。今回の案件でワークした、というだけで他のシーンでは適用できないノウハウという可能性もありますが、そこは良しとしましょう。
スプシでは人のためのUIとプログラムのためのInterfaceを定義する
今回、売上伝票の入力UIとしてSpreadsheetを利用した訳ですが、少し工夫することでより安全に開発を進められるなと感じました。それが、UIとデータの分離です。
具体的には、売上伝票で店員の方が実際に入力するセル群とDatabaseに取り込む（すなわち、Scriptで読み取る）セル群を明確に分けるということです。
※もちろん、データベースの読み取る領域には保護をかけて、通常のユーザーが入力できないようにしています。
こうすることで、 UIの変更とデータ仕様の変更を分離する ことができました。
通常のWebアプリケーションと違って、SpreadsheetをUIとして使う場合は、セルの位置がそのままオブジェクトのIDになります。したがって、Scriptから読み取るセルはあまり頻繁に変更してほしくありません。一方で、ユーザーからのUI変更の要望は頻繁に上がります。UIの変更とデータ仕様の変更を分離する ことにより、これらの要件を満たせる様になった訳です。
まぁ、ソフトウェア開発では間に緩衝材を入れることでシステムの柔軟性を高める手法はあるあるですよね。例えば、BFF ( Backend for frontends ) は、リソース指向な世界とUIコンポーネント指向な世界を橋渡しするための緩衝材みたいな役割を果たしています。
「スタンドアロンGAS + テンプレートスプシ + 定まったフォルダ構造」 が保守性高く開発しやすい
Spreadsheetに紐付いたスクリプトは辛い事が多い
GASにおけるスクリプトファイルの作り方はいくつかあります。
一つはSpreadsheet、FormやDocumentといった Google形式のファイルに紐づくマクロとして作成するパターン です。VBAみたいな雰囲気ですね。
もう一つは、Google Apps Script のダッシュボードから単独のスクリプトファイルを作成するパターンです。後者は通常 「スタンドアロンなGoogle Apps Script」 と呼ばれるようです。
ちゃんとしたシステムを作るなら、 スタンドアロンなGoogle Apps Scriptを利用することを推奨します。 ファイル（今回はSpreadsheet）に紐付いたスクリプトを使うことは、以下の理由によりアンチパターンになると感じました。
- スプシをコピーするとスクリプトもコピーされる
- その結果、バックアップなどでSpreadsheetをコピーするたびに Google Apps Script ダッシュボード上に同じ中身のスクリプトが無限増殖する
- 生データを保管するSpreadsheetは基本的にバックアップを取るため、実行されるプログラムが一箇所にまとまらない。プログラムファイルの多重管理につながる。開発ノウハウとしては論外。
ということで、ファイルに紐付いたスクリプトを使うのは、アドホックなユースケースに限ったものであるべきだと感じました。私見ですが。
テンプレートのスプシを用意しておくと楽
Google WorkspaceにおけるSpreadsheetは、プログラムの一部と考えるべきでしょう。したがって、管理すべきSpreadsheetは一つの目的に対して、1ファイルだけにしておきたいです。
Google Apps Scriptには Spreadsheet や Drive を操作するためのAPIラッパーライブラリが実装されています。このライブラリ群が超優秀でして、ファイルのコピー、移動や権限設定などが超簡単に実装できます。テンプレートを元にその日のファイルを新規作成する、といった処理も簡単に実現できます。
以上のことから、テンプレートのスプシを作っておき、日毎・ユーザー毎にファイル生成するアプローチが良い開発体験を実現してくれます。
フォルダ構造の例
さて、ファイル操作は以下のような形になるでしょう。
- テンプレートファイル： File ID でアクセス
- 都度作成するファイル：フォルダ情報（名前 or ID）とファイル名でアクセス
ちなみに、フォルダやファイルはIDが使える状況なら積極的にIDを使うべきでしょう。フォルダ名やファイル名の変更に頑健だからです。
今回は、こんな感じにしてみました。
- SERVICE_ROOT/ <-- IDでアクセス
- template/ <-- IDでアクセス
- XXX-template <-- IDでアクセス
- YYY-template <-- IDでアクセス
- backup/ <-- IDでアクセス
- database/ <-- IDでアクセス
- report/ <-- IDでアクセス
- YYYY-MM-DD_1_AAA <-- 名前でアクセス（都度生成されるファイル）
- YYYY-MM-DD_2_AAA <-- 名前でアクセス（都度生成されるファイル）
- YYYY-MM-DD_3_AAA <-- 名前でアクセス（都度生成されるファイル）
おわりに
明日は、バンコクで活躍中の @DaikichiDaze さんの『社内DXで苦しんでいる話』です。乞うご期待。
Pythonで文字列処理〜大文字小文字全組み合わせを作る
記事の内容
タイトルどおり
背景
オンラインコミュニティで（NLPに関するプロジェクトでの）専門用語の辞書作りどうやって楽にできるかなぁって話がきっかけ。
（簡単な）表記ゆれぐらいなら吸収できそうですよね、という話になった。
機能
入力文字列の大文字小文字の全パターンを作成し、リストとして返す。
実装
import itertools def get_unique_list(seq): seen = [] return [x for x in seq if x not in seen and not seen.append(x)] def case_ch_flgs(input_text: str="") -> list: if input_text == "": return None ch_flgs = [] tl = len(input_text) for i in range(tl): flg = [1] * (i+1) flg.extend( [0] * (tl - i - 1) ) flg_prm = list(itertools.permutations(flg)) flg_prm = get_unique_list(flg_prm) ch_flgs.extend(flg_prm) return ch_flgs def text_data_augmer(input_text: str="") -> list: """テキストデータ拡張 """ if input_text == "": return None # 大文字小文字の全組み合わせを作る ch_flgs = case_ch_flgs(input_text) _lower = input_text.lower() _lower_chrs = [c for c in _lower] # 全組み合わせの文字列リストを作る aug_text_arr = [] for ch_flg in ch_flgs: _aug_text = [c.upper() if f == 1 else c for f, c in zip(ch_flg, _lower_chrs)] aug_text_arr.append(''.join(_aug_text)) return aug_text_arr
結果のイメージ
所感
itertoolsで順列組み合わせを計算している- 話によると
more-itertoolsという便利なやつがあるらしい
- 話によると
- 今回の実装は再帰で書くともっとスマートに実装できたはず
- 計算の効率がすごく悪いので、文字列の10文字ぐらい超えるとColab上ではメモリが足りなくなる（クラッシュする）
- n文字の計算時間は、O(n!)なので、こんなものを仕事で使うわけには行かない😇😇😇
エッセンシャル思考とは何か？
はじめに
年明けから最近まで、「やりたいこと」や「やらねばならないと思うこと」が、可処分時間に対して多すぎると感じる日々を過ごしていた。
結論から言うと、この原因のほとんどは、年始の「2021年は○○をやるぞ！」と意気込んで、何にでも手を出し始めたことだと思う。ちょっと気合を入れすぎた。
そこで私は、実は以前から積ん読していた『エッセンシャル思考』という書籍に助けを求めた。本記事では、エッセンシャル思考とは何か？について簡単に紹介できればと考えている。
ずばり
「エッセンシャル思考とは何か」という問いに答える切り口は、いくつもある。ここでは、エッセンシャル思考と非エッセンシャル思考の比較から意味を理解してみよう。
非エッセンシャル思考とは、
- やらなくては
- どれも大事
- 全部できる
という思考パターン
エッセンシャル思考とは、
- 「やらなくては」ではなく、「やると決める」
- 「どれも大事」ではなく、「大事なものはめったにない」
- 「全部できる」ではなく、「何でもできるが、全部はやらない」
という思考パターン
これだけ覚えておけば、もう大丈夫な気がする。かなり明確な表現でわかりやすい。短くて覚えやすい。
ちょっと細かい話
前述の3つのポイントについて、筆者は「選択」「ノイズ」「トレードオフ」という3つの章でわかりやすく解説してくれている。せっかくなので、それらを簡単にまとめてみる。
この本では、至るところに心くすぐるパワーワードが散りばめられているので、それらを拾っていく感じでまとめよう。
選択〜選ぶ力を取り戻す
選ぶ能力は誰にも奪えない。ただ、本人が手放してしまうだけだ。
本書では、「早い段階でタフな選択を行い、後の些末な選択に時間を奪わせるな」と繰り返し述べている。本ワードは、その最初の部分である。今回の私のように「あれもやらないと、これもやらないと」という状況のとき、選ぶことから目をそむけている気がする。実際私は、そうだったと思う。選択肢は奪うことはできても、選ぶ能力（自由意志）は誰にも奪えない。これはとても勇気をくれる言葉だと感じた。自由意志を大事にしたいと思った。
エッセンシャル思考の最初の一歩は、「選ぶ」ことを選ぶことだ。
自分の自由意志を大切に、選ぶことを選べば、他人の選択（あるいは、自分自身の過去の選択）を黙々と実行する自分から開放される。選ぶ権利を大切にし、他人に自分の人生を決めさせないことが重要だ。
決して、「わがままになれ」という意味ではないと思うが、その境目は曖昧な気もする。本書を読んで、「わがままになればいいんだ」と解釈する人もいるかもしれない。
ノイズ〜大多数のものは無価値である
重要な少数は些末な多数に勝る
有名な「80対20の法則（パレートの法則）」のお話である。成果の80％は20％の努力に起因するという説である。やがて、この仮説を元に品質管理の分野において、「決定的に重要な少数の法則」というものが唱えられた。これは、問題のごく一部の改善が全体の品質を大きく改善させるという話である。
ほとんどあらゆるものは、徹底的に無価値である
by ジョン・C・マクスウェル
これはなかなか強い言葉だと思う😅（ちょっと言いすぎかなと思うぐらい）ただ、後の世に語り継がれる言葉というのは、力がこもっているもの。多めに見ておこう。着目すべきは、「ほとんどが無価値だ」という部分ではなく、（行間の）「ごく少数の価値あるものを見つけよ」という言葉だと私は解釈した。
トレードオフ〜何かを選ぶことは何かを捨てること
完璧な答えなど存在しない。あるのはトレードオフだけだ。
by トーマス・ソエル
本書の中で、トップクラスに好きな言葉だ。実は最近、キャリア選択で悩んでいる方にこの言葉を贈ってドヤ顔をしたというエピソードがある。けど、ここで語るのはやめておく。自分もそうだが、「すべてを叶えられる手段や選択肢が（まだ気づいていないだけで）どこかにあるのではないか？」と考えてしまうことがよくある。特に大切にしたい複数のことを天秤にかけなければならなくなったときだ。まさに「タフな選択」が必要なとき。そういう時にこの言葉を覚えておくと、ある種のバイアスから逃れられるような気がする。「すぐに何かをあきらめる」という意味ではないと思うので、そこは間違えないようにしたい。
「顧客、従業員、株主の皆様をもっとも大切に考えます」というステートメントも見かける。みんなを優先するのは、誰も優先しないのと同じだ。
耳が痛い。なんか聞き覚えがあるな。特に「みんなを優先するのは、誰も優先しないのと同じだ。」という部分。
エッセンシャル思考の人は、（中略）「何をあきらめなくてはならないか？」と問う代わりに「何に全力を注ごうか？」と考える。
何かを捨てて、何かを選ぶという同じ行動をとったとしても、心の中でどう考えるかでその後の行動も変わってくるのではないかと私は考える。何かを捨てたことを「後悔する気持ち」よりも、何かを選び「大切にするという決意」に目が向くからだ。
おわりに
昨年の秋頃、この本を手に取りざっと読んだとき「なるほどね、そうだよね。わかるわかる。自分は実践できてるな」と感じたのを覚えている。当時は、結構余裕があったからだと思う。そしてここ最近は、（大したものではないけど）苦境に立たされてい訳だ。状況が変わると人間の心や考え方は変わるものだなぁと感じた。その本を「手に取るべきときに手に取れる」状態にしておいたという意味では、積ん読にしてたのは悪いことではないよね。（え？）
メタ思考とは何か？いつ役に立つのか？
今回は、「メタ思考」というトピックについて、自分なりに感じることを簡単に整理したいと思います。
（読むのに必要な時間：約5分）
メタ思考とは何か？
メタ思考とは何でしょうか？
まずは、言葉の意味から考えてみます。メタ思考とは、「メタ」な「思考」のことです。
それでは、「メタ」とはどういう意味でしょうか？以下、Wikipediaの引用です。
「あとに」という意味の古代ギリシャ語の接頭辞。 転じて「超越した」、「高次の」という意味の接頭辞で、ある学問や視点の外側にたって見る事を意味する。 「変化」を意味する接頭辞。例えばmetamorphose（変化）、metabolism（代謝）などで用いられる。
言葉の意味を純粋に考えると、ある視点の外側に立って思考することと言えそうです。
一般的には、「一つ上の視点から思考する」などと表現されます。（参考）
わかりやすくなるように下のような絵を描いてみました。
私たちは見聞きした情報に対して、思考する訳ですが、その思考に対してさらに思考するというイメージを私は持っています。 例えば、「失敗Aの原因はBである」と考えている場合、「じゃあ、その根拠は何か？なぜそう考えているのか？」と思案を巡らせる行為がメタ思考です。
思考とメタ思考の対応関係は以下のようになるでしょう。
- 「失敗Aの原因はBである」＝思考
- 「『失敗Aの原因はBである』と考える根拠はCである」＝メタ思考
メタ思考の具体例
先ほど挙げたのは、「失敗の原因分析」というメタ思考活用シーンの一つです。ここでは、もう一つの活用シーンとして、「前提を見直す」という事例を挙げましょう。
例：前提を見直す
「Xという事実をみて、Yという仮説を立てた」時に、「その仮説は妥当か？と考える行為」がメタ思考です。
先ほどと同じように対応関係を書くならば、以下のようになるでしょう。
- 「Xという事実に基づくと、Yという仮説が立つ」＝思考
- 「『Xという事実に基づくと、Yという仮説が立つ』は妥当ではない。なぜなら、Yという仮説はXが前提条件Zを満たす場合においてのみ成り立つものであり、今は前提条件Zが成り立っていないからである。」＝メタ思考
といった形になります。
終わりに
今回挙げた「前提を見直す」「失敗の原因を分析する」は、いずれも探索的な要素の強い仕事において、成果を出すために重要なことだと感じます。（これは私の解釈です）
前提を見直すことができないと、容易に本来の目的とはかけ離れた施策打ってしまうでしょう。議論も発散しがちになります。失敗の原因を分析できないと、トライアルから得られた結果を元に適切な改善策が見つけられません。
私はこれまで、前提条件の整理ができていない or 忘れていることが原因で、どんどん議論が脱線していってしまう現場や失敗に対して表面だけしか見られていない（真の原因を特定できていない）為に的外れな対策しか打てない現場を見てきました。いずれもメタ思考力が不足していたことが原因の一つと言えると思っています。
現代のように、不確定性の高い事柄、かつ様々な要素が複雑に絡み合った事柄を扱わねばらないシーンが多いと、これらの能力が求められることも多いと感じるのです。
尤度と最尤推定がいつも分からなくなる君へ
わたしは、数学がめっちゃ苦手です。どれぐらい苦手かというと、大学入試の二次試験で数学250点満点中60点を叩き出したぐらい苦手です。わたしは物理学科だったので、周囲の友人は数学強強な人ばかりでした。点数開示のときに数学の点数を暴露する勇気がありませんでした。
タイトルの「君」とは、わたしのことです。仕事柄、数学とはうまく付き合っていかなければならない立場にあり、数学苦手マンな自分としては、何度学んでもわからなくなる概念、迷子になる理論がたくさんあります。その中の代表格が「尤度」です。
考えてみたんです。なぜわからないのか。
結論としては、「尤度とは？最尤推定とは？」というその語の意味を理解しようと考えていたからだと思っています。これらの語は、何か問題を解くときに、手法や指標に明確な名前付けをすることで、後々の議論をやりやすくするという狙いが含まれているものと（勝手に）解釈しています。最初にこの言葉が生まれたというより、「こいつに名前つけないとなぁ」となって名付けられた類のものということです。（←わたしの解釈です）
統計学で詰まる時
個人的な考えですが、統計学で詰まるときは、「何が与えられていて、何を解こうとしているのか」がわからなくなっているケースが多いと感じています。
実際のデータ分析業務では、すでに与えられているものは「データ」です。これは、数理統計学の言葉で言えば、観測データ、何らかの確率分布モデルに従っている確率変数の実現値の集合などと表現できるでしょう。
そのデータの背景には、何があるのかわかりません。どんな確率分布モデルに従うかもわからないことがほとんどです。
にもかかわらず、統計学の教科書の例題や練習問題はそういった状況を容易に無視します。確率分布モデルがすでに分かった状態で、いきなり「期待値を計算せよ」みたいな問題がたくさんあるわけです。概念を理解するための練習問題なので、これ自体は悪いことでもなんでもないのですが、実務において「通常与えられるはずもないもの（データが従う確率分布モデルとか）が平気で与えられてしまっている」ことが、読者を混乱させるのではないかと感じています。特に、わたしのような数学弱々人間は、平気でわけがわからなくなってしまいます。😭😭😭
ということで、ここでは、現実のケースに準えて、最尤推定なるものがいつ登場するのか？を記してみたいと思います。
ここから本題に入ります。
尤度という言葉を使わずに最尤推定を説明する
与えられるもの
現実の課題を解く時、「手元に何があるか」を理解することが重要です。 通常、（分析するぞーとなっている時であれば）観測データが手元にあります。
ここでは、例として日本に生息するアサガオの花弁の長さのデータとでもしておきましょう。 アサガオの花弁の長さが1000件ほどあるとします。
解くべき問題
ずばり、「日本に生息するアサガオの花弁の長さはどのような確率分布に従っているのか」を求めること、とします。
問題解決の糸口〜確率分布の型を決める
問題解決の糸口として、最終的に求めたい確率分布の形の候補を絞ります。ここでは、正規分布モデル（※）という確率分布モデルに従うとしたら…と考えてみます。ここは、解こうとする問題ごとに利用するモデルをヒューリスティックに当たりをつけます。
※…厳密には、今回のような非負で連続な数については、ガンマ分布などを用いるべきですが、尤度の理解に支障なしと考え、簡単のため正規分布を使います
正規分布を数式で表すと上記のようになります。xは、確率変数（連続値）です。確率変数xが得られる確率はf(x)である、ということを意味しています。練習問題などでは、xが9~10となる確率を求めよ、みたいな問題がありますが、実務ではあまり使わないように思います。ただ、確率密度関数の性質を理解しているかどうかを確認する上では、大切な問題なので、別にディスっているわけではありません。😅
答えを求める〜具体的な確率分布を求める
さて、前項で確率分布モデルを決めることで、解答の候補を絞りました。しかし、まだ答えには至っていません。なぜなら、パラメータが決まってないからです。
確率分布モデルは、あくまでもざっくりした型を表現するもの。具体的な確率分布とするには、パラメータを定めないといけません。下記のようなイメージです。正規分布というモデルを定めたとしても、平均・分散というパラメータ（図中のつまみみたいなもの）を調整して、最終的にどういう分布を採用するのか具体化する必要があります。じゃあ、このパラメータは一体どうやって決めればいいんだ？ってなりますよね。
この時、パラメータを定める手段の一つが最尤推定です。
最尤推定を考えついた人（誰か知りませんが）はこう考えた訳です。 「平均○、分散△のときに、手元の1000件のデータが観測されうる確率を求め、その確率が最大になるような○と△を最適であるとみなそう」これこそが最尤推定という方法です。
ちょっと、数式でも書いておきましょうか。
1000件のデータは、 と表すものとすると、平均○、分散△のときに、手元の1000件のデータが観測されうる確率は、以下のように表現できます。
パラメータがμ、σという条件の下で値が となる確率（
）をひたすら掛け合わせていきます。
余談ですが、1以下の確率という値をこれだけ何個もかけ合わせたら、めちゃくちゃ小さい数になりますよね？なんで普通に計算すると、やりづらいんです。コンピュータ計算するときとかも。なので、対数をとるのが通例です。
名前をつけた方が議論しやすい
さて、最尤推定の説明は終わりました。これで割と頭がすっきりした気がします。
とはいえ、この手法について説明する場合、もっと明快に説明できた方が良いですよね。この手法は「○○を最大化（あるいは最小化）するものである」みたいな感じで。この○○に該当するものが、評価関数とか目的関数とか、いろんな名前で呼ばれる概念です。
今回の評価関数は、「平均○、分散△の時に、手元にある観測データ(N個)が観測されうる確率」です。これを尤度（likelihood）と名付けました。
以上〜♬
参考書
結論、データドリブンな意思決定を下せる友達の多い総合格闘家になりたいのかもしれない
この記事は「データ分析人材のキャリアアドベントカレンダー」の23日目の記事です。
はじめに
内容だけさっと目を通したい方は 結論 をお読みください。
この記事は、「主にデータ系職種に携わる場合のキャリア構築アイデア」と「私のキャリアプラン」を紹介することを主題としています。自己紹介をつらつら書くつもりはないのですが、最近以下の記事を書きました。ありがたいことに色々と反応もいただきまして、2020年の良き思い出となりました。
超大作。この記事一つでデータサイエンティストがどんな仕事をし得るかという全体像が掴めるのではなかろうか。データサイエンティストへの転職に役立つかどうかとは別に、一読の価値があると思われるhttps://t.co/GcMCGh3pkk
— TJO (@TJO_datasci) 2020年11月25日
本記事では、はじめに「データサイエンティストとしてのキャリアをスタートさせた契機」を述べ、次に「データ系職種としてのキャリアプランニングのアイデア」を提供し、最後に「私のキャリアプラン（2020/12版）」をご紹介します。
結論
自身の経験を正しく評価し、なりたい人材に求められる知識・経験・スキルを正しく調査し、それらの差をとることで、自分がやるべきことを明らかにしましょう。そのためにDSのスキルやキャリアについての解説記事が役に立つと思います。
私のビジョンというかやりたいことは、「社会に潜む構造的な課題を技術の力で解決し、関係者が無為な作業から解放され、よりクリエイティブでワクワクすることに集中できる社会」の実現です。（長い）私は、「データドリブンな意思決定を下せる、頼れる友達の多い、総合格闘家」になることで自身のビジョンを実現しようと思っています。
そのために必要なことは、大きく2つあると考えています。1つ目は、（運に左右されますが）実務を通して走りながら学び、専門知識を手に入れつつ、業務外での勉学を通して、浅い知識を手に入れつつ、知見の深さと広さを向上させる。2つ目は、自身の能力を生かして人のためになることを実行していく、自分のビジョンを語る、他者を巻き込んだプロジェクトを推進していく、といった行動です。あとは運に任せます。
データ系職種キャリアスタートの契機
結論から述べますと、私のデータ系職種としてのキャリアがスタートした一番の契機は、「データラーニングギルド」というコミュニティに入ったことだと思います。
このコミュニティにおいて、データ分析に関わる人から「おすすめ学習リソース」「現場で得た知見」などを学びとりながら、一緒に勉強ができたことがキャリアをスタートさせる上で、最も重要な要素であったと思います。こういう風に書くと、宣伝感が強いのですが（しかも某○○ゼミっぽさを感じる）、実際そうなので仕方ないです笑
まずは、前職の内容を説明したあと、データ系職種としてのキャリアをスタートさせた経緯を説明することにします。
前職は、3Dデジタル地図の製造研究やデジタル地図製造アプリケーションの開発に携わっていました。約7年ぐらいです。 扱うデータは主に、地図計測用車両の計測データです。内容は以下のような感じです。
これらをつかって、センサー同士のログの時刻同期処理や各センサーの理論的な誤差モデルを求めたり実測誤差を計測するための実験計画・推進を行っていました。
技術スタックは、以下のような感じです。
仕事の中で、実験データを分析し、考察した結果をお客様にレポートしていました。そんな中で、技術情報を漁っていた時に見つけたのが「データサイエンティスト」という職種です。そこから、なんやかんや調べていて、データラーニングギルドというコミュニティを見つけて、入ることにしました。2019年の12月のことです。このとき既に2020年夏までに転職することを決意していました。
このコミュニティでは、データ分析人材（になりたい人も含む）が集まっていて、日々分析業務で詰まったことの相談やおすすめ学習リソースの共有がなされたり、勉強会や懇親会が催されたりしていました。前職では、私の周りに「データ分析」に詳しい人は誰もいなかった為、私にとってこのコミュニティはとても貴重な情報源であり、勉強仲間を見つけられる憩いの場でもありました。
そんな中、コミュニティ内でSlackの会話データをつかった分析プロジェクトを立ち上げる話が持ち上がり、（やったこともないのに）私は手を挙げました。今考えると、この瞬間に何かが大きく動いたような気がします。
そこから、Slackの会話データをラングリングするために自然言語処理（の主に前処理技術）を学び、BigQuery上に蓄積されたデータを用いてSlackをインターフェイスとしたレコメンドシステムを作るためにGCPを学び、といった感じで課題解決のために走りながら学んできました。
そんな感じで、コミュニティ内で割と活発に活動しつつ、転職についても相談していた時にコミュニティの代表である村上さん (@GreenGreenMidor) にお声掛けいただいた、というのが経緯になります。
データ系職種としてのキャリアプランニングのアイデア
私の観測範囲内におけるデータ分析に興味を持つ方のバックグラウンド
データラーニングギルド（以下、DLG）に所属してから、多くの方と「どんな経緯でデータ分析に興味を持ったか？データ分析を仕事にしたいと思ったか？」という話をさせていただきました。 その流れで、元々従事されていた仕事というか、その方の（技術的な）バックグラウンドをお聞きする機会がありまして、おおよそ以下のようにまとめられる気がしています。
- ■ エンジニアリング領域
- Web系エンジニア
- ハードウェアエンジニア、IoTエンジニア
- 製造業の生産技術／生産管理
- ■ ビジネス領域
- 経営
- 営業
- 企画
- マーケティング
- ■ 先端研究領域・アカデミア領域
- コンピュータサイエンス
- 自然科学系（数学・物理学・化学・生物学等）
- 医療業界の方
- 経営学・経済学・社会学
広義のデータサイエンティストは総合格闘家
広義のデータサイエンティスト（参考）は、いわば総合格闘家と言えるでしょう。幅広く、深い知見が求められます。
先程、挙げたようにデータサイエンティストになりたいと考えられている方は、様々なバックグラウンドを持っています。データサイエンティストに求められるスキルが広い範囲にわたるのならば、自分が得意とする（少なくとも幾ばくかの経験値を持つ）領域がどこかにあるはずです。各々の得意分野を理解して、どこから攻めていけばいいかを考えると良いと思います。格闘技に例えれば、ボクシング出身の人は、キック力、絞め技や寝技の能力を高めて総合力を上げていく、みたいなイメージです。言うは易く行うは難し、ですが。そこを見極めれば、データサイエンティストとしてのキャリアプランニングのスタート地点に立ったといえるのではないでしょうか。
私のキャリアプラン
ここまでの文章で「総合力を上げる」ことばかりを述べている気がしますが、実は私は総合力を上げる戦法はとらないことにしています笑
もう少し正確に言うと、「自分一人の力だけで全ての能力をシニアレベルで保持することは諦めている」でしょうか。
私はどんな人材になりたいか
結論から言えば、「いくつかの専門領域を持ちつつ、他分野の専門家と協調できるような広い技術的知識とコミュニケーション力を持つ者」であり「他分野の専門家との人脈を持つ者」が目指す姿です。（簡単に書いたけど、めっちゃ難しい笑）
2つの観点から、自身のなりたい人物像を考えてみました。
1つ目は技術的興味です。
私が最も興味があるのは、データエンジニアリングの領域です。エンジニア出身というのもあるかもしれませんが、アイデア段階のソリューションを「実現できる力」に魅力を感じます。この領域はシンプルに「面白い！」と思えるので、学習効率やモチベーション維持率が高いと考えており、自身の専門領域の一つにしたいと思いました。
2つ目は人生のビジョンです。
私の人生のビジョンは、「社会に潜む構造的な課題を技術の力で解決し、関係者が無為な作業から解放され、よりクリエイティブでワクワクすることに集中できる社会」を実現することです。これを実現するためには、まだまだデータ分析の対象に含まれていない（私が知らないだけかもですが）領域に手を出していかなければなりません。例えば、介護問題、生活習慣病、環境汚染問題、心の病などです。
これらの課題に相対した場合、データサイエンス力やデータエンジニアリング力だけでなく、ビジネス力もとても重要になってくると思います。説得力のある施策効果の説明、古い枠組みを取り払って、新しい枠組みに移行するプロセス設計など、必要なスキルは様々と思います。もちろん、課題にはチームで取り組むことが多いと思いますので、メンバーと協調するスキルやマネジメントスキルも必要になるでしょう。
このビジョンを叶えるためには、現実のビジネス課題を解決する経験を得ること、他の専門家と（主に分析プロジェクトにおいて）協調できるような人物になることが必要と思いました。また、自分が生涯をかけて解決したいと感じる社会の課題に出会ったとき、協力してくれる仲間を集められるような人脈も大切と思います。
なりたい人材になるために何をすべきか？
さて、前項で述べたような人材になるためには何をすればいいのでしょうか。
大きく分けて2本の柱で進めていく予定です。
- 専門性を高める
- 人脈を広げる
ざっくりいうと、そうなのですが、それぞれ具体的なアクションを以下に示します。
1. 専門性を高める
専門性の向上方法は、「業務で携わる」「業務外で学ぶ（独学・勉強会など）」という大きく2つあると思っています。
まず、「業務で携わる」について。現在、私は受託分析を行っています。したがって、必ずしも学習したい領域を学べるとは限りません。運に左右されるところもありますが、業務で携わる場合は自学するよりも深い知見を蓄えることができるというメリットがあると思います。実務を通して走りながら学ぶというスタイルは強力です。
次に、「業務外で学ぶ」について。冒頭で述べたように私はDLGというコミュニティに所属しておりまして、仲間内で勉強会や輪読会を開催して、勉強しております。また、座学だけでなく、業務の状況に近い分析プロジェクトを実施し、生のデータを触りながら、システム構築もしながら学んでいます。この場合は、「業務で携わる」とは異なり、自身の学びたい領域を選択できるというメリットが有る一方で、実務よりは得られる知見も浅いものになることは否定できません。
（あくまでも私の想像ですが）ここまでの内容からして、自身の専門領域は業務として携わり、深い知見を得た領域だけになるでしょう。つまり、自身のビジョンを成し遂げるには、一人じゃ無理というのは確かかと思います。前項で示した私のビジョンを成し遂げるには、様々な分野の専門的スキルが必要かなと漠然と考えているからです。なので、トランザクティブメモリーを大切にしたほうが良くて、他の人とコミュニケーションがとれるような他分野の基礎知識と、他分野専門の人を手助けできるような自身の専門知識を携えて、次項の「人脈を広げる」を頑張らなければならないと思うに至りました。
2. 人脈を広げる
最近「GIVE & TAKE」という書籍を読みまして、人脈が広い人の特徴について学びました。その学びと私のオリジナル考察結果に基づいて、人脈を広げる方法を考えてみました。
やることは以下の3つです。
- 自身の専門性を生かして、誰かを助ける（できるだけWINWINになるような課題解決を）
- 他者を巻き込んだプロジェクト推進（仕事でなくても勉強会とかでも可）
- ビジョンを掲げ、発信し、ビジョンの実現に懸命に取り組む
- あとは、運に任せる
それぞれの説明はしないですが、「ビジョンを掲げ…」については、私のオリジナルアイデアなので、補足説明をしておきます。ビジョンを掲げ、発信することで、「私がどんな人物か、どうなりたいか」ということを周りの人に伝えることができます。もしかしたら、共感してくれる人がでてくるかもしれません。それを期待しています。また、「ビジョンの実現に懸命に取り組む」ことで、本気度が伝わり、共感してくれる人に出会ったときに「一緒にやりたい・手助けしたい」と思ってもらえる確率が上がります。（と勝手におもってます）
あとは、運任せです。ぶっちゃけ人脈とかはコントローラブルではないと思ってますし、今考えてもしかたないこと。先のことだし、運によるもの。であれば、今できることに集中しましょう。ついでに、幸運が目の前を通り過ぎるとき見つけやすいようにアンテナを張っておくぐらいの仕掛けはしておいていいでしょう。（これがビジョンの発信）
最後に、私の好きなアリストテレスの言葉を記します。
ざっくり意訳すると、「将来の目的や計画をいったん忘れ、今この瞬間のやりたいこと、やるべきことに熱中せよ」ということです。
Google Data Portal に入門〜データビジュアライゼーションの基本を少し実践するまで
- はじめに
- 1. 今回参考にさせていただく資料
- できるネットさんの解説記事
- データビジュアライゼーションの教科書
- データ視覚化のデザイン
- 2. 基本操作を学ぶ
- データポータルのホーム画面
- レポートの概観を把握する
- 3. ダッシュボード構築の基本のキ
- 3.1. データソースに接続してデータを取り込む
- 3.2. 取り込んだデータを表示する
- 3.3. データの表示手段いろいろ試す
- ① 指標に売上目標を追加する
- ② 日付の順序になるように棒グラフをソートする
- 4. ダッシュボードのデザイン基本のキを実践
- 4.1. フィルタを設定してみる
- フィルタ機能とは何か、何のための機能か？
- フィルタ機能を扱う
- ① 複合グラフのフィルタを追加する
- ② フィルタ設定UIが表示される
- ③ 所望の条件とフィルタ名を設定してフィルタを保存する
- ④ フィルタを適用した結果を表示する
- 4.2. スタイルを扱う
- 4.3. デザインを意識したスタイル修正
- スタイル修正の前に〜ビューモードで実際の見栄えを確認する
- 伝わるデザインにするための９つの色の基本
- 「色の数は少なめに」を実践
- 「色相違いの２色使いは要注意」を実践
- 4.1. フィルタを設定してみる
- その他
はじめに
直近の業務でダッシュボード構築を経験させてもらえることになりそう。
一応軽くDataPortalを触ったり、DataVisualizationの書籍*1, *2を読んではみました。ですが、業務レベルのダッシュボード構築をするには、まだまだ勉強不足だと思うので、入門してみたいと思います。
できるだけ効率良く学ぶ為に、まず最低限の機能や操作方法を学んだら早速（基礎的な）ダッシュボード作成をやってみる、という流れで行こうと思います。
1. 今回参考にさせていただく資料
できるネットさんの解説記事
Google Data Portal 自体の解説＋BIの基礎知識をきれいにまとめてくださっています。
データビジュアライゼーションの教科書
データビジュアライゼーションとは何なのか、という本質的な内容にはじまり、 データビジュアライゼーションに関する様々な How to が体系的にまとまっている書籍です。
そもそもこの書籍自体が非常に読みやすいです。
インフォメーションデザインを専門にする方が書いているので、当然かもですが笑
アウトラインや色使いなど細かいところが丁寧に作られているので、個人的には電子書籍より紙媒体を推奨します。
この手の本は、電子書籍で読むとせっかく整えられたデザインが崩れてしまうという難点がありますからね。
電子書籍の仕様が今後改善されることを密かに期待しています……
データ視覚化のデザイン
あえて「データビジュアライゼーションの教科書」との比較をするならば、 データビジュアライゼーションに関する Why が体系的にまとまっている書籍と言えるでしょう。
なぜそのような見せ方をすべきなのか、といった情報ですね。
データビジュアライゼーションの教科書同様に、読者が読みやすいようにデザインされています。この本自体がインフォメーションデザインの教科書になりますね。
本書の著者である永田さんは、私の所属するデータラーニングギルドのメンバーでもありまして、 出版前、表紙デザインのアンケートにも携わったことから、個人的に思い入れのある本でもあります。
続きを読む