almost weekly useful materials - 11/30 -

[GENZITSU]

エンジニアのためのマネジメントキャリアパス ~１章 マネジメントの基本 ~

エンジニアのためのマネジメントキャリアパスを読んだので要点をまとめていく

できる上司が持つべき特徴

• 部下を1個人として気にかける
• 部下のキャリアアップを後押しする
• 部下に適切なフィードバックを与える
• 部下が直面している難局をバックアップする
• 部下が焦点を当てるべき要点を把握できるようにする
• 部下が実際に焦点を当てられるように調整する

1 on 1 ミーティングの実施

• 上司にはまず1 on 1ミーティングの開催を求める
• 1 on 1 の目的
  • 上司と部下の間に人間的な繋がりを作り、信頼関係を構築する
  • 上司と部下で検討しなければらないことを話せる定期的な場を提供する
• 1 on 1 を効果的にするためには
  • 現状確認に終始しない
    • 現状確認だけならメールなどの別の手段をとれる
  • 事前に話しておきたいテーマを用意しておく

フィードバックと指導

• 次にフィードバックおよび指導を求める
• フィードバックを得られることは幸運なことである
  • 評価面談の時だけでなく定期的に得られるとなお良い
• 上司からのフィードバックはきちんとメモしておく
• フィードバックを乞うことは相手に敬意を示す良い方法である
• 上司側はフィードバックは時間を開けずに与える
• 良いフィードバックはできるだけ人前で行うべき
  • 中には人前で褒められたくない人もいるので事前の確認をする
• 1 on 1 をフィードバックの場とするのも良い

トレーニングとキャリアアップ

• 上司が効果的なトレーニング法を押してくれる場合もあるが、能力開発については基本的に自分で責任を持つこと
• 上司は会社でのキャリアアップ方法について詳しく説明できる必要がある

自分に対する責任は自分で負う

• 自分の希望をはっきりと伝えること
• 自分の目標実現のために手を尽くす責任は自分自身にある

上司も人の子

• 上司も超人ではなく、日々仕事をしている1人の人間である
  • 気分が乗らない時や苛立っている時だってある
• 上司と自分の関係において、コントロール可能なのは自分だけである

コメント

まだピンとくることが少ないが、今後のためにメモしておく

出典

エンジニアのためのマネジメントキャリアパス

[GENZITSU]

エンジニアのためのマネジメントキャリアパス ~2章 メンタリング ~

エンジニアのためのマネジメントキャリアパスを読んだので要点をまとめていく

インターンのメンター

• インターンにできるだけ最高の体験をしてもらえるように手を尽くす
  • 取り組むプロジェクトを用意し、マイルストーンとそれに至る過程を合意する
  • プロジェクトのボリュームは新入社員なら半分の期間で終えられる程度にする
• インターンのメンタリングを通して培える管理スキル
  • 傾聴
    • 自分の言いたいことを相手に正確に伝えられる人は少ない
    • 相手の言葉だけでなく仕草にも気をかける
    • 自分とインターンの双方がお互いを正確に理解できるまでしっかり時間をとる
    • 萎縮せずに質問しやすい雰囲気を作る
  • 明確な伝達
    • インターンがやるべきこと、達成するべき目標を明確に伝える方法を模索する
  • 調整力
    • インターンの反応・進捗をみて種々の調整を行う

新入社員のメンタリング

• メンタリングで行うこと
  • 新人の研修
  • 必要な情報にアクセスするための手助け
    • チュートリアル資料がある場合は、修正箇所の更新を新人に行ってもらうのも良い
  • 会社に溶け込んでもらうための支援
  • 新人の人脈作り
    • 新人を通してメンターの人脈を強化されていく
    • 人脈作りを時間と労力に見合うものである

その他のメンタリング

• シニアエンジニアが行う技術的なメンタリング
  • チームの開発能力が上がることが期待される
  • シニアエンジニアの職責の一つとしてみなされることが多い
• 他チームのメンバー同士で組むメンタリング
  • 社内の人脈作りのために用いる
• いずれのメンタリングも何のために組ませたかを明確にしておく

メンターになったら

• メンティーに何をして欲しいかの希望を伝える
  • メンタリング前にしておいて欲しいことやいつメンタリングに時間を避けるか、など
• メンティーの同僚や上司から得られないようなFBを与えてあげる
• 時間の制約上厳しい場合は無理に引き受けなくても良い

メンティーになったら

• メンタリングを通して何を得たいかを明確にする
• メンタリングに望む前にしっかり準備をする

アルファギークへの対応

• 最先端の技術にまで精通している凄腕のエンジニアのことをアルファギークと呼んだりする
• 自分がチームで一番優秀であることを心の拠り所にしている場合、チームメンバーに悪影響を及ぼす
• 有害なアルファギーク気質があるかどうかはメンターを経験させてみると浮き彫りになる
• 有害なアルファギーク気質を持つものに人的管理の職権やリーダー職を与える際は熟慮すること
  • 任命後チームに悪影響を及ぼしていないかのチェックも忘れずに

メンターを管理するコツ

• メンタリング関係を結ばせることで何を達成したいかを明確にする
• メンタリングの枠組みや環境を整えておく
  • メンタリングによる時間的負担を考慮する
• 人的管理スキルに興味のある人材にメンターを依頼する
• メンタリングを重要な業務の一つとして扱う
  • 丁寧なメンタリングによるチームへの見返りはとても大きい
• メンタリングのペアを決める際に偏見を持ち込まない
  • 白人 x 白人, 女性 x 女性 など
  • 同じ職務内容を持つ人と同士というのは○
• メンタリングを通して将来のリーダーが育つことを意識する

メンターの心得

• 常に好奇心を持ちオープンな心構えでいる
  • メンタリングを通して物事の見方を見つめ直す
• 相手の言葉をよく聴き、相手の言葉で返す
  • 相手が理解できる方法で傾聴し、自分の意見を正確に伝えるコミュニケーションスキルを伸ばす
• 人脈作り
  • メンティーが将来の働き口を紹介してくれることもある
  • テクノロジー業界は狭いのでどんな人も丁重に扱うべきである

コメント

メンタリングはチーム作りをする上でもとても重要な下地になると思うが、軽視されることが多い印象がある。
まずは重要な業務であるという認識合わせからしていくべきか。

出典

エンジニアのためのマネジメントキャリアパス

[GENZITSU]

Sale Forecasting and Fraud Detection

CPMPさんによる売上予測や不正検知などの時系列予測モデルのモデリング方法とその注意点を解説した資料

勉強になったスライドを抜粋

gapの存在

売り上げ予測に関しては特徴として利用できる期間と予測すべき期間の間に時間的なギャップが生じることがある

データの整形方法

gap期間を設けた状態でhistoryとtargetのペアを作成 → history期間中から特徴量を生成

validationの方法

時系列に沿ったvalidationを実施する

時系列予測全般の注意点

トレンド成分からの乖離を予測する場合もある

最近のデータが重要なので、重み付けをすることも

系列予測を行う場合

モデルの予測値を再帰的に入力して、系列予測をする方法

各時点ごとのモデルを作成する方法

入力と系列のgapを特徴量にする方法

売り上げ予測特有の注意点

商品によっては課題予測はそこまで大きな問題にならないケースがある

種々のイベントによる影響も大きいのでできるだけ特徴量に組み込む

不正検知について

不正の数は本当に少ない、そして検出すべき不正が本当に正しいものかの確認を怠らないようにする

コメント

系列予測の方法が特に勉強になった。

出典

Sale Forecasting and Fraud Detection

[GENZITSU]

エンジニアのためのマネジメントキャリアパス ~3章 テックリード ~

エンジニアのためのマネジメントキャリアパスを読んだので要点をまとめていく

テックリードに求められる職責

– テックリードはチームの誰よりも技術力に優れた人物が引き受けるわけではない

• テックリードに求められる職責の例
  • 経営陣や他チームとの話し合いをする際のチームの代表となる
  • プロジェクトのプランニングやマネジメントを行う
  • チームメンバーの管理
    • メンバーとの定期的な 1 on 1
    • 進捗状況に対するFB
    • スキルアップに関するFB
  • タスクの割り当て
  • チーム全体の生産性の向上
• テックリードにはコミュニケーションスキルなどの対人能力が求められる

テックリードが1番に意識すべきこと

• プログラミング作業の第一線からは身を引く
• 「技術面からの貢献」と「チーム全体に対する貢献」のバランスをとる
• メンバーが集中して作業できるような調整を行う

テックリードの主な役割

• プロジェクトを推進するための大局的な視野を持つ
• システムアーキテクトとビジネスアナリストとしての役割
  • 要件を達成するためのシステム構成の設計・把握をし、必要な工数の見積もりを行う
  • ビジネス要件の理解およびシステムへの反映
• プロジェクトプランナーとしての役割
  • プロジェクトを個々のタスクに分解しスケジューリングを行う
  • タスクの優先順位付を行う
  • チームメンバーからのアドバイスをもらうことを忘れずに
• 開発者兼リーダーとしての役割
  • リーダーとしてタスクの割り振りを行う
  • 自身もコードを書くべきではあるが、メンバーに任せるべき箇所かの見極めは常に行う
  • 一人で何とかしようとするスタンドプレイを行わない

プロジェクトの計画

• テックリードはプロジェクトの計画作成から責任を負う
• プロジェクトの計画作成により、プロジェクト開始前にあるプロジェクトを掘り下げ、洞察を得ることが可能になる
  • 情報が不足している状況下でも目指すべき成果を定め、リスク要因を洗い出しておく

プロジェクト管理のコツ

1. 複数の工程に分割する
   • 個々のタスクに分解し、取り組む順序を決定する
   • よくわからない箇所はメンバーからのアドバイスも取り入れタスクを分解する
2. 細部の引っ掛かりや未知の事象にへこたれない
   • プロジェクト進行は往々にして行き詰まるものである
   • 多少の想定外にめげず、これ以上やっても意味がないと納得できるところまで取り組む
3. 調整を行いながらプロジェクトを進める
   • 最初に立てた計画を指針に作業状況を見つめ直し、調整を行う
4. プロジェクト計画時点で得られた洞察から要件の変化に対応する
   • 要件の変化に応じて、機能・品質・納期の間の妥協点を見つける
5. 完了が近づいたら細部を詰める
   • 見落としや必要な検証が全て終わっているかを確認する
   • 死亡前死因分析などを活用してリスク要員を潰す
   • 障害発生時の対応も決めておく

プロセスツァーと健全なプロセスベース

• プロセスツァー
  • プロセスやツール、規約に関して異常に執着するような人物
  • 時に柔軟な対応や想定外の変更が必要であることを認めず、何でも新たなプロセス・ツールを導入することで解決を図る人物
  • 新任管理者が失敗やリスクを過度に恐れるあまりに陥ってしまうケースが往々にしてある
    • そのような上司を持った場合は安心材料を作るべきである
• 健全なプロセスベース (アジャイルソフトウェア開発宣言より)

  • プロセスやツールよりも個人と対話を、

  • 包括的なドキュメントよりも動くソフトウェアを、

  • 契約交渉よりも顧客との協調を、

  • 計画に従うことよりも変化への対応を

  • 必要なのは個人・顧客を念頭においた柔軟性である
• プロセスやルールを物事の解決の拠り所にしない
• プロセスやルールが自動的に順守される方法を模索する

優秀なテックリードであるために

• 対象とするアーキテクチャーをしっかり把握する
  • 関連するデータの流れやシステム間の繋がり、最終的な製品に対する影響に至るまで把握する
• チームプレイを第一に考える
  • 面白い作業を積極的にメンバーに渡し、退屈な箇所や技術的に難しい箇所をどうにかできないか考える
  • ただし自己犠牲はほどほどにする
• 技術的な意思決定を主導する
  • 主導するものの、全ての決定権を持っているわけではないことを意識する
    • 自分が決定すべきこと、チームの意見を聞くべきところの区別をつける
• コミュニケーションの達人となる
  • 書く力、話す力をつける
  • 相手に意見を求め傾聴し、自分が相手の意図を理解できたかを確認する

時間を割いて説明することの重要性

• 誰かに物事を説明する際は、丁寧に相手が理解できるまで時間をかけて説明する
• 経営陣や上司も超人ではないので、基礎知識や背景の事情から丁寧に説明をする
• 説明する時間を惜しんではいけない

コメント

ここで書かれているテックリードの職責はかなり重たいが、給与とのバランスはちゃんと釣り合うものなのだろうか...

出典

エンジニアのためのマネジメントキャリアパス

[GENZITSU]

【JupyterNotebook/Lab】Jupyter上でデバッグする３つの方法【Pdb】

jupyter上で対話的にデバックする方法の紹介

エラー発生直後に%debugを打つか、%pdb onを設定することでエラー発生時に自動的にpdbに入ることが可能

コメント

EDAする際のでバックに便利だった

出典

【JupyterNotebook/Lab】Jupyter上でデバッグする３つの方法【Pdb】

[GENZITSU]

エンジニアのためのマネジメントキャリアパス ~4章 人の管理 ~

エンジニアのためのマネジメントキャリアパスを読んだので要点をまとめていく

人の管理で求められる主な仕事

• 部下との関係構築
• 定期的な 1 on 1
• 普段の業務やキャリアアップのためのFB
• メンバーの長所の見極めとその強化

部下と良好な関係を築くコツ

• 信頼感と親近感を構築する
• 部下のことをよく理解するための質問例
  • 人前で褒められることに抵抗はあるか？
  • FBの形式に希望はあるか？口頭 or メール or 文書 ?
  • このチームで仕事をしようと決めた理由・モチベーションはなにか？
  • 不機嫌な時に示す行動パターンはあるか？定期的にそうなる理由があるか？
    • 例えば定期的に断食をしている場合がある
  • 耐え難い上司の振る舞いはどういったものか？
    • 唐突な1on1のリスケなど
  • キャリアに関する目標はあるか？
  • 事前に伝えておきたいことはないか？良いことでも悪いことでも
• 直近 1ヶ月 / 2ヶ月 / 3ヶ月 の計画を立ててみさせる
  • 上司やチームも支援をする
  • 明確な計画ができない場合や、いつも達成できない場合は何かがおかしい
• 新人研修用のドキュメントのアップデート文化を根付かせる
• 自分自身の流儀や要望を伝える
  • メンバーに対する期待は明確に伝えておく
  • 自分の管理スタイルがあればそれをインプットしておく
• 新人 (and メンバー) からのフィードバックを得る

1 on 1 の方法

• 1 on 1 は週1回を基本とする
  • 開催時刻は他のミーティングや作業時間との兼ね合いで決定する
• 1 on 1 に関する調整
  • その部下と頻繁にやりとりをしているのであれば頻度を落としてもよい
  • 部下のレベルに応じて割く時間や取り上げる話題を変更する
  • 部下との関係性の良し悪しに依らず公平に機会を設ける
  • チームや会社の情勢が不安定な場合は隠さず丁寧に説明する

1 on 1 の種別

• ToDoリスト型
  • 事前に話し合いたいことを議題としてあげていき 1 on 1 の場で話す方法
  • わざわざ 1 on 1 の場で話すのが不自然にならないように注意
  • 事前に互いが確認できるドキュメントを設けると良い
• キャッチアップ型
  • 議題は決めずに部下に関する最新情報を収集する方法
  • 不平不満を並び立てる場にならないように注意
• フィードバック型
  • 4半期に1回のペースで当人の仕事ぶりに関するフィードバックを行うと良い
  • ただし注意すべき行動、褒めるべき行動に関しては間隔を開けずに行う必要がある
• 経過報告型
  • 状況のアップデートしか行っていない場合は 1 on 1をやる意味が薄れている証拠
  • 別の話題を持ち込むように努力するべき

1 on 1 をする際に意識すること

• 部下を一人の人間として扱い、相手のことを知るための場であることを意識する
• 内容を他人に聞かれないような場所で行う
• 簡単な議事録をまとめておく

細かすぎる上司と任せ上手な上司

• 不安のあまり細部まで厳しく管理してしまうマイクロマネジメントは部下のやる気を削ぐ
  • マイクロマネジメントは自分がその仕事をしているのとほぼ同義である
  • 経験の浅いエンジニアに対してはマイクロマネジメントが適切な場合もある
• 任せ上手な上司は裁量権を与えた上で適切な支援を惜しまない
• 裁量権の有無はモチベーションに大きく影響する

効率よく仕事を任せるために

• チームの目標を設定し、それに至る計画を作成する
  • 計画に沿った行動ができているのであれば口を出さない
• 人に尋ねる前に自分で調べてみる
• プロジェクトの進行に応じてコミットメント調整する
  • プロジェクト初期や終了間近の際は強いコミットメントが必要になりがち
  • 中盤は進捗状況の大まかな把握で十分なことが多い
• コードやシステムに関する基準を定めておく
  • コードレビューやデザインレビューに関する基準を設けておくでいちいち口出ししないで済む
• 情報をオープンにする
  • 良いニュースも悪いニュースもオープンに共有できるようにする
• 細かい点に目を瞑り、部下に仕事を任せるコツを覚える
  • そうしないと最終的に自分が苦しむことになる
• あえて、週の労働時間を制限してみる
  • 本当に注力すべきことが見えてくる

継続的なフィードバック文化の構築

• 常日頃から褒めるべきこと注意すべきことのFBを行う
• 継続的なフィードバックを行うためのtips
  • 部下の基本情報を集める
    • 職位や職歴、長所や短所、目標など
    • 1 on 1 を通じて教えてもらうのも効果的
  • 日頃から部下に目をかける
    • 毎週部下の良いところを見つけられると良い
    • 定常的な粗探しにならないように注意する
  • 深刻なFBもさらりと行う
    • 肯定的なFBから入る
  • コーチング
    • プロジェクトをより上手に推進させるために何ができたか？などを共に検討する
    • 部下のレベルに応じては効果がない場合もある

効果的な勤務評価を行うためのtips

• 勤務評価を行う際は一人一人十分時間をかけて行う
• 直近数ヶ月ではなく過去1年を通した評価を心がける
• 具体例や他の人のFBを引用する
• 褒める時間をたっぷり取る
• 改善点は焦点を絞って伝える
• 部下を驚かせないようにする
• 評価面談の時間をたっぷり取る
  • 評価が平均・平均よりも低い場合はその理由を丁寧に説明する

部下のキャリアアップ支援

• 管理者は誰が昇進に値するかと昇進に必要な準備をサポートする必要がある
• 部下が実際に昇進するまでのプロセス・条件を把握しておく
• 昇進材料となりうるプロジェクトに目を光らせる

コメント

ここまでくると実務経験がないのであまりピンとこなくなってくるな...

出典

エンジニアのためのマネジメントキャリアパス

[GENZITSU]

機械学習の階層モデルの適用でコールドスタート問題に対処する 〜 広告コンバージョン予測の事例

新規広告に対するコンバージョン予測精度を向上させるため、広告カテゴリ / 広告主 / キャンペーン種別などの広告の階層性を活用した事例の紹介

コメント

階層性を活用してCVRが2.0%向上しているのがすごい

出典

機械学習の階層モデルの適用でコールドスタート問題に対処する 〜 広告コンバージョン予測の事例

[GENZITSU]

ディープラーニングにおけるdeconvolutionとは何か

convolution や deconvolutionが行列演算としてどう計算されているかを解説している記事

コメント

恥ずかしながらなぁなぁにしていた部分だったので勉強になった

出典

ディープラーニングにおけるdeconvolutionとは何か

[GENZITSU]

異常音検知関連の情報まとめ

異常音検知タスクの解説資料や論文、データセットなどの情報をまとめているブログ

コメント

いつか役に立ちそうなのでメモ

出典

異常音検知関連の情報まとめ

[GENZITSU]

Behind the Yahoo! JAPAN Top Page: Trial and Error of the Article Recommendation System and Future Challenges

Yahooのトップページにどのニュースを表示するかの推薦システムと試行錯誤の歴史を紹介しているスライド

気になったスライドを抜粋

全体システム

ユーザーのベクトルと記事のベクトルを事前に計算しておいて、optimizer APIがユーザー訪問時に記事を推薦

ベクタライズモデルの訓練方法

BERTやGRUを用いて記事ベクトルとユーザーベクトルを取得している

類似記事のフィルタリング

類似度ベースの手法やクラスタリングベースの手法を適応

現在は表示する他の記事も含めて多様性を計算できないかを試しているが、計算時間が重たいことがネックとのこと

dislikeをどう扱うか

dislikeした記事を用いてuserベクトルを求めたり、dislikeするかどうかを使ってみるのはよいが、なぜdislikeされるかの理由が様々あるため難しいらしい。

再学習に関する不安定性

少数群に対するA/Bテストを行う場合は非対称群に対する性能が支配的になる

コメント

推薦システムのアーキテクチャー参考になる

出典

Behind the Yahoo! JAPAN Top Page: Trial and Error of the Article Recommendation System and Future Challenges

[GENZITSU]

PaLM a 540B state-of-the-art language model

2022年4月にGoogleが開発した大規模言語モデルPaLMの学習にどれくらいお金がかかったかを見積もっている記事

Googleは計算機を保有しているので正確な値ではないが、GCPでインスタンスを購入した場合は以下のような見積もりができるとのこと

Our three (not independent!) methods estimate $17M, $23.1M, and $9.2M for the final training cost of PaLM.

コメント

だいたい20 ~ 30億円くらいのモデル...

30代人間のFLOPSは10 ** 26オーダーらしいので、2,3000億円用意すれば人間相当のモデルが作れる

またCompute Trends Across Three Eras of Machine Learningによると最近の大規模言語モデルは10ヶ月で倍になると言う傾向があり、PaLMのFLOPSが2 x 10*24程度であることを考えるとあと4,5年程度でそこに到達する見込みである

出典

• PaLM a 540B state-of-the-art language model
• 関連ツイート

[GENZITSU]

Federated Learning Tutorial (IBIS 2022)

IBIS 2022にてオムロンサイニエックスが実施したFederated Learningのチュートリアル資料

Federated Learningがもつ様々な課題に対する近年の研究動向が詳細にまとめられている。

以下はまとめページの抜粋

コメント

非常に勉強になる。面白い。

出典

• Federated Learning Tutorial (IBIS 2022)

[GENZITSU]

Sticker Recommendation Using Federated Learning

Federated Learningを用いたスタンプレコメンデーションを実現するシステムアーキテクチャーの紹介

既存のMLシステムのサービング方法の比較

対象とした問題

ユーザーのテキスト入力から適切なスタンプを推薦するタスク
今回はLINEスタンプのプレミアムプランに登録されているのみを対象

適用したモデル構成

サーバーサイドで事前に候補を絞っておき、クライアントサイドで最終的なスタンプ推薦を実施すると言う構成

クライアントサイドで使用されるユーザーベクトルはここクライアントでパーソナライズされていて、スタンプ推薦モデルはFederated Learningにより更新される

システム構成

利用しているモバイルOSごとにONNXで最適化している

プライバシーへの配慮方法

個々のクリックイベントではなく、クライアントサイドで学習されたモデルを収集してグローバルモデルの更新 (単純平均ベース)を行っている

また差分プライバシーとして、モデルにノイズを載せてサーバーに送信

コメント

実務でFederated Learningを用いることはまだ稀だと思うので、アーキテクチャー例がとても参考になる

出典

Sticker Recommendation Using Federated Learning