なむなむ

@namb_nam による恥晒し

優しさの実装

『ウルトラマンコスモス』の放送が2001年7月から2002年9月。 劇場版最終作の公開が2003年8月公開。

『機動戦士ガンダムSEED』の放送が2002年10月から2003年9月。 『機動戦士ガンダムSEED DESTINY』の放送が2004年10月から2005年9月。

小学校高学年の頃に連続して観ていたこの2作品が、自分の価値観に大きく影響したことは間違いない。

コスモスは"強さとやさしさ"、SEEDは"想いと力"、表現は異なるが、当たらずとも遠からずなテーマを扱っていたように思う。強い力を持つウルトラマンとして、怪獣を保護するために戦うコスモス。主人公たちが戦争を終わらせるための戦いを始めるSEED。2つの作品から、守るためには力がいるが、力だけでは守れないことを学んだ。

その思想を、自分はどう活かせているだろうか、と思う。特に仕事において。

コンサルとしての4年間は、データドリブンの入り口に立てるかどうかのフェーズの企業と向き合い、"そもそもデータ活用とは"から始める教育、文化醸成の一端を担うことが多かった。だから実装のハードスキル、話し方や調整力、無茶振りや余計な雑務から自分と後輩を守る力などのソフトスキルが伸びた気がする。仮に高度なテクニカルスキルを持っていたとしても、使う場面がなかったので積極的に伸ばそうとは思わなかった。

今はどうだろう。どう考えてもハードスキルが足りない。 自分の視座や心遣いが秀でていたとしても、それを実装に落とし込むスキルがない。 SEEDでいう、「気持ちだけで……一体何が守れるって言うんだ！！」状態である。 想いと力のバランスを早急に取らねばならない。

足りてないことの意識（概念的定義と操作的定義）

概念的定義と操作的定義の話。

軽くググったところ心理学や哲学でよく使われる用語らしいが、『分析者のためのデータ解釈学入門』では、「測定の難しさ」の項で触れられている。データを取得する際、「そのままでは測れないもの」を実際に測れる指標で代替するが、厳密には異なるものを測っているという意識を忘れてはいけない。測定したいものと、測定できるものの違いを意識せよ、という話である。

整理すると、

  • 概念的定義：測りたい概念（例：頭の良さ）
  • 操作的定義：測定という操作による定義（例：IQ）

直接は測定できない概念（例：頭の良さ）は理論的構成概念とも呼ばれる。また、理論的構成概念を操作（測定）によって定義する方法論を操作主義といい、概念的定義と操作的定義はこの操作主義で生まれた概念らしい。

これを実務に適用する。 例えば、「社内で重要なデータって何？」と聞かれて「クエリ数が多いデータ」と答えたとする。

  • 概念的定義：データの重要性
  • 操作的定義：クエリ数

であるということだ。 しかし、クエリ数だけでは測定できない「重要性」があることを常に意識しておかないと抜け漏れが発生する。この場合だと"クエリ数が多いけど重要"という状態がないかは考えないといけない。

  • 操作的定義が表現したかった概念的定義は何か
    • クエリ数が多い≒使用回数が多い
  • 操作的定義が概念的定義につながっていないケースはないのか
    • スクリプトが繰り返しアクセスしていると参照回数は多くなるが、重要とは言えない
    • 逆に、結果がキャッシュされて使用される場合、参照回数は少なくなるが、重要でないとは言えない
  • 概念的定義に対して測定可能な操作定義は他にないのか
    • 参照している社内組織数
    • 社外公開数値の元になっているかどうか
    • 法的に保護しなければならないデータかどうか

などなど。 自分の思考が必要十分かどうかは、常に意識しておきたい。

amzn.to


超今さらだが本の読み方がよくなかった

本当に今さらなのだけど、自分は文芸書とそれ以外の本を同じような丁寧さで読んでしまっていたかもしれない。 いや、ビジネス書でも実用書でも、基本的には必要な部分だけ読めばいいのだと思うし、読み飛ばしていいとは言わないが「全てじっくり読む必要はない」のは明らかだろう。

が、僕は、得られるものはすべて得ようとしてしまっている節があり、なるべく満遍なく集中力を保って読もうとしていたのではないか、と思った。

これは『STARTUP 優れた起業家は何を考え、どう行動したか』という書籍を読んでいたときにふと気付いたことである。この本は、著者のまとめと起業家へのインタビューパートで構成されているのだが、それぞれが（個人的には）ちょうどいい分量で細かく切れていて、とても読みやすかったのである。集中力を保つ必要がある時間が短く、波のようなのでいいペースが生まれる。少し離れてもまた戻りやすかったし、自分には明らかに不要な箇所にも気付きやすいし、いいことづくめだった。

この、なんでもじっくり読んでしまう感じ、読み終わった本を売るようになってからかもしれない。 「この本を読み返すことはないだろう」「この本から学べることはもうない」と言い切る必要はないはずなのに、手元からなくなると考えるとその思いが強くなってしまっていたように思う。


SQLスキルが足りてない

SQLスキルが足りてない、と感じた。

データ整備の仕事において、 例えば新旧テーブルの比較や乖離状況の把握はよくある集計作業だが、 そのクエリくらいサクッと書けないと改善のための時間が不足する。

という話である。

しんゆうさんの記事

analytics-and-intelligence.net

では、

整備の仕事はどんなデータが来てもなんとかできるスキルが必要

とある。同意だ。。。

ほしい物リストに入ったままだった 『ビッグデータ分析・活用のためのSQLレシピ』を即購入した。

自分のポジションはアーキテクトなので、そこまで複雑な分析（のためのクエリ）はいらないと思って SQLスキルを伸ばすのは一旦止めていたけど、全然そんなことなかった。勉強しよう。

amzn.to


M1チップって何

ビックカメラの「Macアップグレードプログラム＋」でMacbook Proを購入してから2年経った。 たしか「2年ごとに買い替えたらええやん〜」と思って2年プランにした記憶があり、たいして使いきれてないが買い替えも検討していいのではと思った。

それに際し、ずっと気になっていたM1チップってなんなのかを調べる。 ※知らない単語を調べただけで、特徴を調べたわけではない。

www.apple.com

公式のプレスリリースを読む

  • AppleがMac専用に設計したチップ
  • システムオンチップ（SoC）である
    • 多くのパワフルなテクノロジーを1つのチップにまとめ
    • ユニファイドメモリアーキテクチャを採用することで、パフォーマンスと効率を劇的に進化させています
    • 従来、CPU、入出力、セキュリティなどのために複数のチップが使われていました
  • M1は最先端の5ナノメートルプロセステクノロジーを使って作られた初めてのパーソナルコンピュータ用チップ
  • 1つのチップとしてはApple史上最も多い160億個という驚異的な数のトランジスタを搭載
  • 4つの高性能コアと4つの高効率コアで構成された8コアCPUを搭載

調べたこと

システムオンチップ（SoC）
  • CPUやGPUなどのプロセッサと、メモリや周辺機器などを制御するためマイクロコントローラを統合したもの
  • 似た概念として、LSIやASICがある
    • LSI（Large Scale Integrated）：大規模集積回路、コアとしての機能はあるが、メモリやマザーボードなどの機能は別途組み合わせる必要がある
    • ASIC（Application Specific Integrated Circuit）：特定用途向け大規模集積回路
  • 複数の集積回路を組み合わせてシステムを実現するのではなく、チップ上に各種回路を組み込んで配線し、システムとして動作させる
  • 組み合わせるものは、「コア」と呼ばれる組み込みCPU、マイコン(マイクロコントローラ)、メモリなど
これまでのMacにはWindows PCなどにも搭載されているIntel製CPUが採用されていた
  • つまりM1 Macのインテル入ってないのか
  • 今の自分のMacbook Proの説明には、2つの欄にIntelの記載がある
  • つまりCPUとGPU
  • M1チップのCPUは8コアで、4つの高性能コア＋4つの高効率コアで構成
CPUが異なることによる影響

Gitいつ覚えるの問題

Gitを勉強しているうちに、さらに議論が進んでいた。

GitやDockerは、あくまで入れ物にすぎない。「環境を整えてから何かを成す」という意味ではGitやDocker → エンジニアリングや分析 の順番なのだろうが、「本質を優先する」意味では優先順位は逆だろう。

大切な但し書きとして、「ただし、いずれはGitやDockerをきちんと使えないとダメだが。」 がつく。 個人的には、今まさにその”いずれ”に直面しているのだと思う。つまり、時間がない、英語が難しいなどの理由をつけて逃げているわけにはいかないフェーズ。

逃げないぞ。

そういえば、

todes-mentor.hatenablog.com

にもGitのおすすめ資料が載ってた。 この業界、本当にありがたい。

Gitを何となく使っている

軽く叩かれているので引用するのも申し訳ないが、「Gitの基本は知っててくれよ！」というような趣旨のTweetを見かけた。

まず、引用RTを見るとすごくためになる。わからないことは聞いたほうがいいし、ワードチョイスや前提を気にしすぎると聞きづらくなるから、多少相手の負荷になっても早めに聞いたほうがいい、という意見。自分は気にしてしまって質問が遅くなるから、その辺の抵抗感は捨て去りたい。

そして、本題(?)のGitの知識レベルについて。個人的にはだいぶ刺さってしまった。というのも、Gitがある程度わかってないと、キャッチアップや作業の初速が遅くなる実感があるからだ。前職でまったくと言っていいほどGitを使っておらず、GitとGitHubの違いすらわかっていなかったくらいなので、転職直後には苦労した。付け焼き刃で凌いでいるが、本質的には理解できてないので改めて学びたい。

まず気になるのは、必要最低限のレベルはどこまでなのかということだ。 Gitの概念は当然として、各自が理解しておくべき基本機能はここまでで、それ以上は各組織の運用ルールに委ねる、というようなレベルの分かれ目はあるのだろうか。

上記ツイートにこんな引用RTがあった。

マジの最低限は、

  • リモートからローカルへ取得〜ローカルからリモートへ共有までの基本操作
  • 適切にブランチを切り、修正箇所／更新先（push先）を間違えない

あたりだろうか。 ...とまで書いたところで、自分の経験がなさすぎてどこまでが最低限を判断する基準すらないことに気づいた。まとめ記事でも書きながらあたりをつけることにする。