技術的貯金

鳴かぬなら 作ってしまおう ホトトギス

「会社を変える分析の力」を読んだ

下記記事で紹介されていた bdm.change-jp.com

下記本を読んだ。

内容は統計の話というより、分析をビジネスに生かさないと意味ないよと繰り返し主張するものであった。

分析だけする人(バックオフィス型)ではなく、ビジネスに生かすところまで行う人(フォワード型)になれというもの。

たしかに自分の経験に照らし合わせても分析するのが楽しくなってしまい、ついつい個人の趣味でデータを分析してしまうこともあった。。気をつけねばと感じた。

そのためにもまず分析する前に、目的を確認し、4つの壁「データの壁」、「分析の壁」、「KKDKKT条件みたいにかっこいいものかと思ったら、勘と経験と度胸ということらしいです。。この重要性も本書では指摘されてました。)の壁」、「費用対効果の壁」を突破できるかを見据えるべきということでした。

下記の3ステップを一気通貫ですべてできることが大事とも。 ビジネス課題 -> 「1. 見つける」-> 分析問題 -> 「2. 解く」-> 数値解 -> 「3. 使わせる」-> ビジネスの意思決定

「2.解く」が視認性が高く身につけがちなスキルだが(私も現在身につけようととしていたが)、むしろ2はコンペに出したり外注すればよく、2以上に1と3が重要ということだった。(当然2の基礎も必要ではありますが...)

現在エンジニアとして手を動かす日々なので、分析ツールも自動化して手軽に「3. 使わせる」まで丁寧に面倒が見れるようになりたいと思った。

GCPのML Opsハンズオンに参加した

Kaz Satoさんによる講演。

下記簡易メモ

01 MLOps at Google

PoC段階で終わる例が多い。データサイエンスとエンジニアの壁。 Operatingの方がLaunchingより難しい。 精度が落ちた時に検出できるか。

  • DevOpsとMLOpsは別物。
    • DevOps: CI/CDを回す。Reproducibility大事。
    • MLOps: 振る舞いを決定するのは特徴データ。DevOpsのように単体テストで検証できない。データのガバナンスが大事。共変量シフト。機械学習のアウトプットをきちんと専門家ではない方にも説明できるか。デプロイした後で考えるは遅い!

Googleの論文。苦労の証。タイトルは「機械学習使うのは高いクレカ使うのと同じ」「機械学習使うのは技術的負債ですよ。」

うまく機械学習を回している例。ライゾマティクス社

cloud.google.com

02 AI Platform

Gaussian Processでハイパラチューンできるよ。sage makerにもありますね。

03 MLOps withAI Platform Pipelines

エンドユーザーが治して再学習できる。active learning。加工図面の自動予算見積もり。

04 AI Platform Pipelines Hands-on workshop

kubeflowのお試し。beta版なので途中で動かないものもちらほらある模様。

youtu.be

youtu.be

05 Beyond Pipelines

データの分布が時間と共に変わったかグラフなどで見れる機能( TensorFlow Model Analysis (TFMA) )できるよ。SHAP使って重要な特徴量の変化も見れるようになるよ。。

www.youtube.com

感想

MLOpsの概要について知ることができた。

ハンズオンのデモで割とトラブっていらっしゃった。やはりデモにトラブルはつきもの。それも含めてリアルで良いですね。

kubeflowやはり便利そうだ。docker-composeやaws fargateで済ませて、kubenetes避けてきたが勉強しようかしら。

統計検定2級を取得した

最近アプリケーションエンジニアだが、データを使った根拠のある改善をしたくなり統計を復習する。

昨日、CBT(コンピュータ)での統計検定2級を受けて無事取得した。

対策は過去問をひたすらとき、(1問1問解いてはすぐ答え合わせが良かった)間違った問題についてはぐぐったり、何回も繰り返すのみ。(正月休みがこれで潰れた...)

https://www.amazon.co.jp/dp/4788925524

開始30分前には会場入りしようとしたが、10分前まで空かないとういことでカフェ探すのもだるいので外で待機して下記読んで復習する。

qiita.com

qiita.com

会場はなんと自分一人で貸し切り状態!(密じゃなくて良かった。。私のためだけに会場開いてくださりありがたい。。)

CBTの良さだけあって、解答後即座に結果が出る。。(受かったから良いが落ちてたらしょげそう。。)

受験のコツは、やはり時間が厳しいので(後半の問題の方が解くのに時間がかかる印象)、とにかくささっと解いて行って時間かかりそうな問題や難しい問題は「あとで見直す」にチェックをつけてあとで解くのが良さそう。 (結局時間足りずにあとで見直す時間ほとんど取れなかったが。。)

学んだ知識を実務で生かしたいと思う今日この頃である。

入門監視読んだ

最初はアプリエンジニアだったがアラートが上がって夜に電話がかかってくる経験があり、強制的にバックエンドや監視に興味を持つことになった。

今ではバックエンドも普通に開発しているが監視に関しては terraformでコード管理されたdatadogで監視を入れている程度の知識しかなく、 先人が設定していただいたアラートがなったらなぜなったか調べる程度しかしてこなかった。

これではまずい、最初から学び直そうということで著名な本を読んでみる。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

  • 作者:Mike Julian
  • 発売日: 2019/01/17
  • メディア: 単行本(ソフトカバー)

学びの多い本だった。

各章にまとめが書いてあったので備忘録として残しておく。

一部:監視の原則

1. 監視のアンチパターン

  1. ツールには依存しない。
  2. 監視は全員がやる仕事。devとopsの共感大事。
  3. 会社の基準のチェックボックスを埋めるだけではダメ。
  4. 監視するだけではもちらんダメ。都度直す。

「 監視は全員がやる仕事」が特に響いた。一部の人が行うと負担がかかる。

2. 監視のデザインパターン

  1. 監視もモノリシックシックよりマイクロサービスが良い(組み合わせ可能なものが良い)。
  2. ユーザー視点での監視からはじめよ。webノードの監視などにも手を広げる際にも常にユーザーへの影響を考える。
  3. 監視の仕組みはSaaSからはじめよ。airbnbもいまだにSaaS。よほどSaaSで対応しきれないものである限り自作しないのが賢明。
  4. 継続的改善

ゴリゴリにSaaS推しだった。たしかに悪意のあるSaaSには気をつけねばならないが初期はたしかにSaaSを使うべきだと感じた。

3. アラート、オンコール、インシデント管理

  1. アラートはメールで送らない。
  2. 手順書をかく。 1.すべての アラートはシンプルな閾値で決められるわけではない。
  3. 常にアラートを見直す。
  4. メンテナンス期間を使う。
  5. 誰かにアラートを送る前に自動復旧を試みる

最後の「誰かにアラートを送る前に自動復旧」が実現できると監視者いらない世界があってとてもいいですね。。

4. 統計入門

ノイズみたいなシステムの不具合に対してアラートしないようにするには統計の知識が必要。 ちょうど統計検定を勉強していてやはり統計はいろいろな分野でいきそうだ。

二部:監視の戦略

詳しいメモは qiitaに記事があった。

qiita.com

一口に監視と言っても、下記のように監視対象が様々であり具体的に紹介されている。

  1. ビジネス監視
  2. フロントエンド 監視
  3. アプリケーション監視
  4. サーバー監視
  5. ネットワーク監視
  6. セキュリティ監視

埋め込む前に各コンポーネント一通り復習して埋め込もうと感じた。

www.tbs.co.jp

圧倒的ヤラセ番組「モニタリング」人気だが、「IT観察バラエティ モニタリング」だれかyoutubeで放送してくれないかな、と思う今日この頃であった。

ワークマン、論点思考を読んだ

松岡 剛志さんの記事 を読んで 2週に1冊くらいは本を読んでいたのだが、週に3冊読むと言う話があり刺激を受けた。 全然inputたりてないと思いさっとポチってエンジニアだが、ビジネス書を読んでみる。

ワークマンの本

www.amazon.co.jp

職人向けの店として認知されていたワークマンがいかに一般向けに認知度を広げ売り上げを上げたかと言う話。

全店舗でデータをみる姿勢(基本テストも簡単なものにしてできる感を醸成する取り組み)、 データに基づく自動注文を採用していることで競争力を高めたとのこと。やはりデータは重要だ。

x軸をデザイン性ー機能性、y軸を価格、で取るとワークマンは機能性かつ低価格であり敵がおらず、アマゾンにすら戦える存在になっているようだ。

ワークマンに興味を持ついいきっかけになった。

論点思考

www.amazon.co.jp

研究でも研究テーマを見つけるのが一番難しいように、ビジネスでも論点(何を問題とするか)が重要で、その論点をいかに設定するかについて書かれた本。

割と意外だったところは下記。

仕事でも私生活と同じように、相手の発言の真意、意図、バックグラウンドを考えるべきだ。一ついえることは、仕事でもプライベート同様に直感を大切にしたほうがいいということだ。仕事は論理的に考えなくてはならないと思い込んでいるビジネスパーソンは多い。だが、直感を重視し、後からそれを論理的に説明するように考えたり、あるいはどうやったら検証できるかを考えるということがあっていい。

結局相手の発言の真意を察する能力が必要ということだ。

またロジックツリーやMECEといった定跡を網羅的には使わないとのこと。経験でなにがいいかを判断しているそうだ。

複数の論点を設定して8割完了させるより、論点を一つに絞り完遂するやり方はアジャイルにつながるものを感じた。

本書で肝要と語られていた 2つ上のポジションで物事を考える癖、大論点<->中論点<->小論点を行き来するやり方 実践したいと感じた。

LinusのTED

LinusのTEDがyoutubeでリコメンドされて見てみる。

www.youtube.com

Linuxを開発した当初はOSSを特に意識してなかったようだ(単純に他の人に見てコメントした欲しかった程度)。

visionがあるわけでもなく、人が好きでもないという彼は自分自身をエジソンかテスラ派のどちらかで言うとエジソンの名言「天才とは、1%のひらめきと99%の努力である」にあるようにエジソン派という。

listから要素を除去するサンプルコードの比較の話も面白かった。やはりif文などなく、シンプルであればあるほどいいtasteよねということだ。

コーナーケースにも対応できるシンプルなコードを常にかけないか考えようと感じた。

彼はlegendだが、まだ年齢も50歳ということでソフトウェアの進化の早さを感じる次第であった。

世界最先端の戦略がわかる「amazon」 読了

メルカリでポチッたamazonの本読んだ。

amazon 世界最先端の戦略がわかる

amazon 世界最先端の戦略がわかる

  • 作者:成毛 眞
  • 発売日: 2018/08/09
  • メディア: 単行本(ソフトカバー)

amazonがいかに顧客中心でビジネスを考えてきた(そのため競合には手強すぎる会社)かが伝わってきた。

同時にユニクロ然り顧客にとってはホワイト企業だけに中は相当ブラック(大変)な会社なんだろうなとも。

結局アマゾンが追求している世界観では人間の労働はほとんど不要になる気がする。 ドローン含め機械がうまく動くように機械整備士などの仕事が増えそう。

しかしながら失業は増えるのだろうなとも。。ホームレスシェルターなど用意しているののは好感が持てる。

www.businessinsider.jp

もはや国を超えた存在のGAFA。日本政府より余程頼りになる感じだ。(世襲政治も終わりにしてオープンソース政治にしてほしい。)

利益を追求し仕事を効率化/機械化していくのは素晴らしいと思うが、 生まれる失業者に備えて(新しい仕事も増えるとは思うが、、)ぜひ近い将来ベーシックインカムを導入してほしい。(給付金10万、毎月もらえると最高さある)