24/08/12 ~ 24/08/18 Weekly Report

はじめに

この一週間に学んだ内容や私生活について、備忘録として残していこうと思います。

Input

Books

1. データエンジニアリングの基礎

読了。データエンジニアリングについて包括的な知識を習得することができたと思う。データエンジニアリングのスキルはできるに越したことはないが、技術習得のハードルは高い。しかし、最低限の知見を有していればデータエンジニアと技術的な会話をすることができるはず。基本知識として覚えておく必要があるので、リファレンス的な使い方をしつつ繰り返し復習していこう。

9章 アナリティクス、機械学習、リバースETLへのデータ提供

データ提供は、アナリティクス、機械学習、リバースETLの３つの主要分野に分けられる。 データ提供を行う上で重要な考慮事項は、データの信頼性、ユースケースとユーザー、データプロダクト、データ提供方法、データ定義とロジック、データメッシュである。

• 信頼性: データエンジニアは、提供するデータの正確性と信頼性を保証する責任がある。
• ユースケースとユーザー: データの用途やユーザーを理解することは、適切なデータ提供方法を決定するために不可欠である。
• データプロダクト: データは、レポート、ダッシュボード、APIなどのデータプロダクトとして提供される。
• データ提供方法: データは、セルフサービスで提供される場合と、データエンジニアが管理するプロセスを通じて提供される場合がある。 セルフサービスデータの需要が高まっている。
• データ定義とロジック: データの定義とロジックは、データの正確性と一貫性を確保するために、データエンジニアリングライフサイクル全体を通じて維持する必要がある。
• データメッシュ: データメッシュは、各ドメインチームがデータの提供と消費の両方に責任を持つ、分散型データアーキテクチャである。

データ提供ステージでは、セキュリティ、データ管理、DataOps、データアーキテクチャ、オーケストレーション、ソフトウェアエンジニアリングという底流も重要となる。 特に、データセキュリティは、データ漏洩のリスクを軽減するために不可欠である。

10章 セキュリティとプライバシー

セキュリティとプライバシーは、データエンジニアリングのすべての側面に不可欠である。 データエンジニアは、人、プロセス、テクノロジーの観点からセキュリティについて考える必要がある。

• 人材: データエンジニアは、フィッシング詐欺やソーシャルエンジニアリング攻撃から身を守るために、セキュリティ意識を高める必要がある。 組織は、従業員に対してセキュリティに関するトレーニングを実施し、明確なセキュリティポリシーを策定する必要がある。
• プロセス: セキュリティは、データエンジニアリングプロセス全体に組み込む必要がある。 アクセス制御、データの暗号化、脆弱性の管理などのプロセスを導入することが重要である。
• テクノロジー: データのセキュリティを確保するために、ファイアウォール、侵入検知システム、データ損失防止ツールなどのテクノロジーを活用する必要がある。

11章 データエンジニアリングの未来

データエンジニアリングは、急速に進化する分野であり続けている。 データエンジニアリングライフサイクルは今後も重要だが、複雑さは減少し、使いやすさは向上するようになると思われる。

• データエンジニアリングライフサイクルは消えない: データエンジニアの役割は、ツールやテクノロジーの変化に合わせて進化するだろうが、データエンジニアリングライフサイクルは今後もデータエンジニアリングの中核であり続ける。
• 複雑さの衰退と使いやすいデータツールの興隆: データプラットフォームは、より使いやすく、管理が容易になる。
• クラウドスケールデータOSと相互運用性の改善: クラウドベースのデータプラットフォームは、より堅牢になり、機能が豊富になる。
• 「大企業的」データエンジニアリング: データガバナンス、データ品質、データセキュリティの重要性は、ますます高まる。
• 職種名と担当範囲は変化する: データエンジニア、データサイエンティスト、MLエンジニアの役割は、ますます重なり合うようになる。
• モダンデータスタックからの脱却とライブデータスタックへの移行: モダンデータスタックは、リアルタイム分析とML機能を統合した、より動的なライブデータスタックに進化する。

ライブデータスタックの出現により、データとアプリケーションの融合が進むだろう。 これにより、リアルタイムの意思決定と自動化が可能になる。 また、データエンジニアとビジネスユーザー間の連携も強化されるだろう。

まとめとして、データエンジニアは、この進化し続ける分野で成功するために、常に学習し、新しいスキルを身につける必要がある。

2. 世界一流エンジニアの思考法

以前kindleで半額セールされていた際に購入し、積読していたので読み始めた。
著者はマイクロソフトのクラウドサービスを開発しているエンジニアで、azure functionsに携わっているらしい。もちろん、世界トップレベルのエンジニアが集う環境で働いているため。一流のエンジニアの仕事ぶりを（自称）凡人の著者との違いを基に比較しつつ書かれている。
また、個々のエンジニアとしての思考法にとどまらず、一流の開発組織としてどのような文化があり、コミュニケーションを行っているかも紹介されており、エンジニアからマネージャまで幅色い層にお勧めできる内容となっている。

• 第１章 世界一流のエンジニアは何が違うのだろう？

  • 頭は良くても理解に時間がかかる:どんなに頭がいい人でも。azureのシステムを理解するには時間がかかる。頭がいい人が理解が早いように見えるのは、単に時間をかけて何度も基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキストが残っている。
  • 頭の中にメンタルモデルを作る:自分の業種、業態にあった思考の枠組みを学んだり、経験したりして自分なりの脳内イメージを作り上げることができれば、頭の中で考えを整理したり問題発見に至るプロセスが高速化する。
  • まずはエキスパートに頼る:正直、組織文化にもよるところだと思われるが、一つのことで何時間もブロックされるより、質問や相談をしておいて他の仕事をやっておく方が断然生産性が高い。
  • 偉大な習慣を身につけたプログラマになる:結局のところ、シンプルな日々の積み重ねが1番強い。

• 第2章 アメリカで見つけたマインドセット

  • いかにやることを減らすか？:一流のエンジニアは「いかにやることを減らすか」に頭を使っている。
    1. 一つだけピックアップする
    2. 時間を固定して、できることを最大化する
    3. 「準備」「持ち帰り」をやめてその場で解決する
    4. 物理的にやることを減らす
  • 失敗を受け入れる:失敗はただの結果であり、そこでどのような「フィードバック」を得られたかが重要だ。「失敗に学ぶ思考の習慣」は生産性を飛躍的に高めてくれる。
    1. 「フィードバック」を歓迎するムードをつくる
    2. 「検討」をやめて「検証」する
    3. 「早く失敗」できるように考える
  • 不確実性を受け入れる:「納期は絶対」の神話を捨てる。プロジェクトには必ず不確実性が伴う。品質を落としてまで納期を厳守することは極力しない。「やらないこと」を見つけることがポイントとなる。

• 第3章 脳に余裕を生む情報整理・記憶術

  • コードリーディングは極力コードを読まない:コードリーディングのコツは他のディベロッパーのことを信頼して、実装はちゃんと動くものとする。
  • 仕事の難易度別で考える:仕事のレベルを4つに分けて考える。
    • L1：何もググらず実装できる。
    • L2：ググれば解決できる。
    • L3：スパイクソリューションがあればなんとかなる。
    • L4：自分では無理。
      レベル4をクリアすることは諦め。人に頼ることを考える。生産性とはいかに「レベル1」を増やすこと。レベル3を増やすよりも、レベル2をレベル1に向上させた方が生産性は高い。
  • マルチタスクは生産性が最悪なのでやらない:WIP(=Work In Progress)=1にすることを意識する。マルチタスクが生産性を損なうことは様々な研究により実証されている。
  • 記憶を定着させるために:人に説明可能な状態に持っていく訓練の最良手段として、ブログを書いてみること。記憶の定着化に有効なことは、シンプルに「思い出そうと頑張る」こと。また、理解・記憶・反復という黄金即を実践することが重要である。

• 第4章 コミュニケーションの極意

  • 情報量を減らす:特にエンジニアとのやり取りでは、情報が少ない方が好まれる。付加的な情報は聞かれた時に答えた方が、真に理解すべき情報が明快になる。
  • 相手がもtめている情報への感度を研ぎ澄ます:メモを共有する際や、コードを書く時は、日頃から人に伝えることを前提とした準備をしておくと何か聞かれた際にも工数削減になる。
  • クイックコール:リモートワークの際には、オフラインと比較して明らかにコミュニケーションがスローになる。自分が抱えている課題を説明しようとしても、チャットだと伝わりにくい場面も多い。この欠点を補うために、クイックコールを頻繁に使うことをお勧めする。
    音声の方が100倍情報量があってインタラクティブ性がありフィードバックが速い。自分に知見がない場合はすぐさまエキスパートに聞いた方が早いため、とりあえずメッセージを送っておく。
  • 気軽に聞ける空気を醸成する：理解できないことは恥ではないし、聞かれた方も不愉快とは思わない。優秀なエンジニアが集まる著者の職場でも、初歩レベルの質問をしたところで誰も問題視しない。「気軽に聞ける仕組み」は「気軽に断れる空気」とセットになっていることがポイントでもある。
  • 意見が対立しても否定しない：相手を尊重していることを言葉だけでなく態度でも表すことが大事。「相手を否定しない」「相手のアイデアを否定しない」そして「自分の考えとして意見を言う」と言う鉄則を守る。

• 第5章 生産性を高めるチームビルディング

  • サーバントリーダーシップ:リーダーは＜ビジョンとKPI＞を示すが、実際にどのように動くかは、チームが主体的に考えて意思決定していく。
  • 自己組織チーム:タスクに割り振りもチームが自らやっていく。基本的に各自がやりたい仕事を「自分がやるよ」と選択していく。特に、メンバーが「楽しんでいるか」が重要視される。
  • ボスの役割はサポートすること:ゴール設定は親身になってサポートするが、細かく指示をすることはない。マネージャの主な仕事は「アンブロック」。そして、中長期的にどうキャリアアップしていけるか、相談に乗って支援する。
  • チームにパワーを持たせることの価値：できる人たちがのびのびとパフォーマンスを発揮してほしいのであれば、チームメンバーが「仕事を楽しめる」環境を作ること。支持されてやる仕事は面白くない。
  • 意見が対立しても否定しない：相手を尊重していることを言葉だけでなく態度でも表すことが大事。「相手を否定しない」「相手のアイデアを否定しない」そして「自分の考えとして意見を言う」と言う鉄則を守る。

3. Pythonで学ぶ効果検証入門

以前「効果検証入門」を学習していたが、Pythonで書かれている本書が発売されたタイミングで購入しており、積読していたので着手している。
「効果検証入門」よりも実装より実務における考慮事項の説明に重きを置いており、勉強になることは多いと感じた。因果推論領域の書籍はまだ数冊積んでいるので、１ヶ月程度で消化していきたい。

• 2章 A/Bテストを用いてクリーンに効果検証を行う
  • A/Bテストのデザイン
    • A/Bテストを用いた施策効果の分析は、A/Bテスト全体のデザインを考える必要がある
    • A/Bテストのデザインは「設計」「データ収集」「分析・評価」という3要素を含む
    • 設計時には、試作内容やメトリクス、割当方法、サンプルサイズ、分析方法ナフォを施策実施前に定める
    • 分析・評価時には、事前に定めた分析方法に基づいて施策効果分析を行う。方法として回帰分析などがある。
  • A/Bテストの設計にあたり、少なくとも次の項目について考えておく
    1. 施策内容
    2. メトリクス
    3. 割当対象、割当方法、割当比率
    4. サンプルサイズ
    5. SYTVAに反していないか
  • A/Bテストのアンチパターン
    • 施策効果があるアウトカムを探してしまう
    • A/Bテストの停止を逐次的に定めてしまう
    • A/Bテストのデザインを定めずにテストを始めてしまう
    • テスト後の分析を怠る / 結果ばかりを気にする
    • 真のKPIを見過ごしてしまう
    • ローカルな指標で一喜一憂
    • 効果に対する想像力の欠如

Blogs

• 検索結果の品質向上
• A/Bテスト概論
• 事業価値と Engineering 2024年版
• 100 以上の生成 AI 事例に見るビジネスインパクト創出の方程式
• Kaggle LEAP Competition Solution解説&振り返り
• 機械学習基盤のアーキテクチャ特集　〜8社の設計意図と今後の展望〜
• Google Colab で Vertex AI の Gemini API を試す
• AI・機械学習チームで学んだ開発技法で趣味の通知系ツールを量産した
• RAG入門: 精度改善のための手法28選
• UU数 160%成長を支えたエンジニアと共創するテックブログ醸成術
• 今だからこそ、Sansanで挑戦するデータ活用の最前線

Services

• transformer explaner
  Transformerの情報が伝わる挙動を可視化しているサービス

Life

• 今週はお盆休みをいただき夫婦で旅行に行った。
  • 1日目
    今夏のピークといえる猛暑の中、新幹線で名古屋に向かった。お盆休みの影響により街は人で溢れ返り、暑さとにとゴミに圧倒された。お盆は都会ではなく喧騒から外れた方がいい。
    名古屋では美味しいものを食べることだけを目的として行動した。昼食はひつまぶしで有名な「蓬莱軒」赴き、2時間待ちとのことだったので、待ち時間の間に熱田神宮に参拝した。
    蓬莱軒のひつまぶしはこれまで食べたことのないくらい美味しいうなぎ料理だった。
    夜はこれまた名古屋名物の手羽先を食べるため「風来坊」に訪れた。ここの手羽先は健康を度外視した致死量とも思える塩を手羽先にふりかけており、この塩味が美味な手羽先であった。
    健康と引き換えに美味しいものを食すという罪悪感も合わせ調味料として、美味しいお酒と共に夜を過ごした。
    この日は久しぶりに数軒ハシゴ酒をして名古屋の夜を堪能した。
  • 2日目
    岐阜県にある日本三代名泉でお馴染み、「下呂温泉」にレンタカーで行った。温泉旅行は人混みが苦手でゆったりとした旅行が好きな我々夫婦にとって、基本的な旅行スタイルと化している。
    温泉街を散策する上でふらっと立ち寄った「囲炉裡」という飛騨牛の炭火焼店が、店主とご婦人共々親切で、提供される牛串も絶品だった。
    宿泊する旅館は「水鳳園」というところで、料理がとにかく美味しいという情報で予約をしたが、実際に提供される料理は何を食べても繊細で美味しい味付けだった。館内もきれいに清掃されており、快適に過ごせた。
  • 3日目
    「水鳳園」で美味しい朝食をいただき、旅館をあとにした。名古屋に帰る途中、「犬山城」というお城を観光した。
    国宝として指定されている城で、天守閣からの眺めは絶景ということなので訪問。酷暑の中行列に並び、木造の立派なお城を堪能した。
    名古屋でレンタカーを返却後、新幹線で帰路についた。連日の日照りの影響で、軽い熱中症になったのがお土産となった。
• 旅行後は実家に2日間ほど帰省した。地元の美味しい料理を食し、昔の友人と交流した。
• 休みの期間中は自己研鑽の時間をとることができなかった。日常を充実させることが重要なので、学習に満足のいく期間が訪れることはしょうがない。重要なのは、これまで継続していた習慣が崩れないようにすること。自分のやるべきタスクを再確認し、目標立てて積み上げていこう。
• 新たに書籍を購入した
  • AWSではじめる生成AI
    生成AI領域で実務家向けの書籍。プロンプトエンジニアリングから、LLMの基本的な仕組みと実装、FineTuning、RLHF、評価などのモデル構築までの流れから、RAG、マルチモーダル、拡散モデル（画像生成）などかなりの領域をサポートしている。ソースコードもサポートされており、スクリプトで学習することもできるのでかなり充実した内容。優先度は低いけど、通読だけでもしておこう。
  • SQLポケットガイド
    なぜか衝動買いしてしまった。SQLのリファレンス本は、ビッグデータ分析・活用のためのSQLレシピを購入していたが、もっと基本的なSQL本も欲しいと思っていたので購入した。
  • 独学で鍛える数理思考
    こちらも衝動買い。データサイエンスにおける数学の本は今まで何冊も購入してきたが、この書籍は独学者向けにより実務的な例題を取り上げ、その背景にある数式を紹介してくれているとのこと。
    先日アイシア=ソリッドの中の人がデータサイエンス向けの微積、ベクトル書を出版するということだったので、こちらも予約済み。

Task

• Deeplearning.AI Short Course
• Pythonではじめる数理最適化
• データ指向アプリケーションデザイン
• 機械学習デザインパターン
• 評価指標入門
• 機械学習を解釈する技術