Please enable JavaScript.
Coggle requires JavaScript to display documents.
西場さん,笹川さん,大瀧さん 指摘まとめ (MUST で行ってほしいこと (出来ないとわかったことはすぐに宣言して周りに伝える, 迅速な情報共有,…
西場さん,笹川さん,大瀧さん 指摘まとめ
MUST で行ってほしいこと
出来ないとわかったことはすぐに宣言して周りに伝える
迅速な情報共有
開発工数見積の改善努力
生産性の向上
ビジネス側に迷惑をかけない(損失については当然)
同じことを何度も言われない
チームの他のメンバーの生産性を下げない
1 on 1 意識についてetc
仕事の中で意思決定が出来ない
というのはあってはいけない
自分の意志決定すら出来ない人がなぜ他の人の意思決定をサポートできるのか
やりたいことの相対比較はできるはず
与えられた選択肢の中から選択する,その際の選択基準を考えるべき
物事を分解して捉えようとする努力をしているか
何でも良い と 〜 系が良いという人にはたいてい大きな差がある
機械学習を具体化出来ている人は分類ができている
物事をカテゴライズ,分類した上で自分は何がしたいのか,真剣に考えているか
画像
言語
音声
予測モデルを作る
DataScience 分野
分析をし,ビジネスサイドの意思決定をサポートしたい
説明がおかしいのは理解が足りていないから
自分自身を客観的に評価出来ているか
定量的な目標があるか
話している内容がどれも定性的過ぎて,客観的に他人が評価できない
何かを聞いた時に明確な定義が抜けていることが多い
定量的なコミュニケーションを心がける
立てた目標に対してコミットする
今やっている,これからやろうとしているプロジェクトで 2億円行きそうですか??
仕事一般
タスク管理
見積もりがダラダラ伸びるのはいい加減x
周りの人の仕事の段取りも
考えて仕事を行う
互いの仕事をブラックボックスにする必要はない
例 : Bourbaki
- 堀井さんの出社日程と,仕事のお願いの仕方
- 笹川さん,池田さんにお願いするインフラタスク
- Unit1, デザイン側のスケジュール把握(いつまでにこちらが修正を出せれば,リリースはいつになるのか
最終的な, Bourbaki を無事に動かすことを念頭に置いた,当事者間のスケジューリングを行う
なぜ今日終わると思ったのか?
根拠と考察について
自分の無意識の思考を分解する
ロジックのレビューに何日かかると思うのか
無茶なデータ解析仕事は引き受けない
因果関係がはっきりしているか?
例:3ヶ月の時間差でのデータからの推定は難しい
問題の本質に立ち返ってもっと簡単な方法が無いか?と議論する
むやみにデータと機械学習に飛びつくのは危険
何のリスクが残っていて,何を行えば潰せるのか,
潰せないとするならそのリスクは許容範囲なのか
プロセスのレビューを周りにお願いする
自分の仕事で他人に迷惑をかけないことなんて無い (誰しもそう)
早めの段階で相談することで双方の負担を減らす
谷村さんに見せる資料と,直接チームをマネジメントする際の資料は異なる
どう異なるという話だったのか??
どれが終わったらどれくらいの利益見込み?
いつまでに終わるのか?
チームとして利益を追求するにあたって,いつまでにどれくらい,どのようにして稼げるのかを把握したいのは当然
問題点を発見し,まとめておくことで,他の人にタスクを切り出すことが可能になる
自分が専門にしているプロジェクトにおける,インサイト,課題発見は 自分が一番できるはず
- 他の人がやろうとすると,キャッチアップ -> 思考 まで沢山時間がかかってしまう
課題がわかっていれば,手を動かすだけ? なので他の人に渡しやすい
- 仕事の分散,引き継ぎ がしやすくなる
最終目標にむけて,マイルストーンを予め設定する
各ステップにおける出力を把握し,課題の全体感を見失わないようにする
各ステップのゴールの定義を周囲にレビューしてもらう
資料は 1 ~ 2 割の概観を早めに作って一度共有する
逐次JIRAを更新し,タスクと進捗を共有する
心構え
社長意識
何故 Bourbaki の update エラーがわかった時点ですぐに共有しないのか?
堀井さんは いつエラーをチェックすると言っていたのか?
責任者として時期の把握はするべき
ビジネス上の優先順位を考えよう 自分個人のではなく
夜でもわかった瞬間に緊急連絡で教えてください
損失に直結する意識 しかも大きな
なんのために開発をするのか
サービスで使うため,サービスを意識したテスト,検証でなければ意味はない
黙っていたらいないのと同じでは
質問が出ないのは何故なのか
仕事のレベル感が低い
仕事の視野が狭い
何故笹川さんと差がつくのか
テクノロジースキルの差だけではないはず
差はあっても仕方がないが,そこを埋めるための思考を怠ってはいけない
情報収集,共有への姿勢が異なるのでは
社内での知り合いは増えているか
面白い仕事をするには,企画を一緒に行ってくれるビジネス側が必要不可欠
目的意識を持ったコミュニケーションが出来ているか, そもそも目的を持てているか
輪読会の目的
周囲からの質問に答える練習
準備の生産性は極限まで高めよう!
他のUnitへのプロモーション
こんな内容があるよ!
各ビジネス専門で仕事をしている人に,実際に適用するイメージを持ってもらえれば,話は進むし,ビジネスを詳しく知っている分,より良いプロジェクトになる可能性が高い
どんな特徴量が作れて,何が効きそうかetc
佐野さん,磯畑さん
時間を有効に活用する,生産性を上げる意識,行動を常にする
1 on 1 においてその場で質問を考えるのは何故なのか?
時間を最大限活用する,聞き漏らしをしないためにも事前に考えておいてもよいのではないか?
誰とのMTG であっても相手の貴重な時間をもらっていることには変わりない
一日早くリリースできたら,どれくらい利益は変わるのか??
自分の 50万は大事にするのに,会社の50万は大事にしないのは当事者意識に欠けている 谷村さんのよくある指摘
QAは間違っていることしかわからない
-> Eng 側が改善しなくてはいけない -> Eng,QA のフィードバックループを早く回す必要がある
間違いはどの工程で入ったのか? 今後繰り返さないためには? の視点が非常に大切
組織で働くことを意識できているか?
個人プレイ感が強い
エンジニアリンググループに貢献するという考え方は??
エンジニアリング,プログラミング,Ai 以外にも組織につながる貢献はできる
なぜ,Luigiを を自ら取り込まなかったのか?
チームの先を見よう
コードレニューが足りない?
生産性を上げる意識が足りない??
常に行動の理由を考える
何故その手法を取るのか
スライドを作る必要があったのか
数式・証明まで書く必要があったのか
漫然となんとなく な行動をしていては成長しない
指摘の背後に存在する理由を考える
プロジェクトは完全に引き継いでいる -> 全て渡っている ということ
データ,ロジックの流れは一度しっかり確認しておいて欲しい
不安があるのだったら聞いておく
クライアント第一
仕事相手は誰なのか考える
相手に成果・アウトプットが見えなければ何も進んでないのと同じ :fire:
Bourbaki であれば Unit1
Not AIチーム
ビジネス側の欲しいものを考える
100 % のイメージを作成 <-> 現状と比較
100% に至るまでに提供できるものはないのか?
必要最低限なものを迅速に共有していく
自分がどこで相手に価値を与えられるのか意識し,実践する
情報からわかる事実を伝えるだけなら誰でもできる
事実 + α の考察,専門家としての
意見が求められている
テスト群のCTRは コントロール群に比較して勝っている
- > で ?
勝っているからどうしたら良いのか???
効率的にリフレッシュできる方法を模索しておく
数年のうちに時間任せの働き方は体がついていかなくなる
リフレッシュも効率的・効果的にできるようになっておくべき
みんなを尊重
相手の席に突撃は NG,
相手の時間を尊重していない
相手受け取りやすいように整理した上で情報を伝える
会社のサービス,社内での発言は,周り巡って相手に伝わることを意識した上で発言しましょう
発言内容・方法を人によって変えない
全員をプロフェッショナルとして尊重する
インターン生に対してのみタメ口というのはおかしい.
それは勝手に実力以外のところで評価を下している,立場関係を暗黙的に気づこうとしていることになるのでは
フラットな組織にとってそれは全く好ましくない
時間の使い方が自己中心的になっていないか
相手が自分の思うように動いてくれると何故思っているのか
月曜MTGで,1時間前に資料を共有するので良いのか?? 今回のMTGは内容の共有というよりも,精査して議論するため,論文の共通理解の上で行うMTGのハズ.1時間前では読む時間が取れない
伝える情報には専門家,担当として責任を持つ
自分が行っているタスクの情報を細かく共有する
そうすることで,仕事の分担,
サポート等がスムーズに行える
コードレビューを積極的に行う
コードレビューされないと仕事が前に進まない
自分が助けてもらうのは確実なのに,相手を助けられるところで積極的にならないのはおかしいのでは
コミュニケーション
オープンクエスチョンはNG
必ず具体的な数値で尋ねる
百, 千, 億?規模のリターンなのか
どこまで工数を割けるかが判断できる
数百万
とりあえず Cloud Vision に画像を突っ込んだらこうなります
あとは考えてみてください
数千万
Cloud Vision に画像を突っ込んだらこうなった
改善のためには ~ こうすると良くなる -> 画像収集設計
認識した文字列から情報を抽出するには ~ -
互いのビジネスバックグラウンド,肌感の違いで認識のスレが生まれる
ピラミッド構造で話をまとめる
簡潔 と 丁寧は 相反する概念ではない
+ 相手の質問にまず答える
相手に意思決定を促す伝え方
1. クライアントが欲しい情報を伝える
- こちらが頑張ったことを伝えるのでは決して無い
2. 行って欲しい行動を伝える
相手を動かすことが目的のコミュニケーション
相手にとってメリットのある話になっているか
相手が気になる点,不安な点を解消できているか
具体例
冗長な文章を書かない
削れるところは徹底的に削る
文章を構造化して,視覚的にどこが
重要なメッセージなのかわかるようにする
誰に対する何のための資料なのか考える
資料は1,2割作ったところで見せて
早めに談する
何をどこまで作り込む必要があるのか
相手の前提知識
伝えたい情報,起こして欲しい行動,何が相手にとって価値があるのか
資料の共有方法は何が良いのか考えて作業する
スライドである必要があるの?
プログラミングについての指摘
テスト関連
動作確認には2種類
コードチェック
アルゴリズムチェック
アルゴリズムチェックには事前に論文内容の共有をして相手に読んでもらった上でのレビューが必要
事前の論文共有等, 仕事の段取りを考える
実験の時,テストコードで乱数を使う際には シードを固定する
再現性の担保
テストコード部分を書き換える際には MR で必ず周知
特に自分の作業範囲外の部分や,共有モジュールを変更する際には注意
テストを作成し,通らないことを確認してから実装する
極力シンプルなテストを心がける
ユニットテストとモデルテストを分ける
シミュレーションにはその複雑さが本当に必要なのか
GitLabとの連携
開発の際には feature branch を切る
WIP を付けて,MR 作成,随時push
WIP が付いていれば周囲の人もそれを理解して時間をかけて見ることはしない
随時push することで開発過程を周りに可視化する
Asignee を随時変更して周囲の人に見てもらう
2つ以上の LGTMでマージ
開発し直す場合には自分に Asing し直す
自分がAsignee になっているものがないか随時確認
コードの書き方
Double 型 と特定の値との等号比較は基本行わない
丸め誤差等で意図した値と異なる値になることがある -> 一致しないことが発生する可能性 -> 意図しない挙動に
不等号による比較を行う
==0 ではなく, <= 1e-5 だったらにする
どこまで小さい値に意味があるのか考える
値域を分割するのは連続性の観点?から好ましくない
1e-5, <= 1e-5 と条件分けをすると ☓
用いる値自体を x + 1e-5 としてしまうことで 0割を回避, & 最小でも 1e-5 を用いる事ができる
Jupyter-notebook は必要最低限で
共有にあたって
処理はほぼ関数化して, 実行の流れを追いやすくする
データはなるべくグローバル変数に入れない
print ではなく Logger を使う
ログをメモリ上ではなく,ファイルに残すことができる
log レベルを設定ファイルから一括変更することで, デバッグモードでの出力, product 時には出力しない等を変更できる
一つのコードに多数の役割を担わせない
変数名が長くなるのはそれが原因では
モジュールの開発をしていることを意識する
実行スクリプト,実行時の設定等は
モジュール内に含めない
開発されたモジュールは,実行したい環境で設定,実行関数等書くことによって用いられる ( 自分が import numpuy as np としているのと同じ
環境設定と,ユーザー入力による設定を区別する
環境設定
実行時の環境設定(保存先,スクリプトの置き場所etc) は一度作ればそんなに変わることはないので,環境設定ファイルを作成し,デフォルトで値が入るようにすれば良い
必要に応じて,環境設定ファイルを切り替える
ユーザー入力
実行スクリプトの引数としてユーザーの入力を引き受けて,処理を変更する
https://bourbaki{env}
/ test.com / {policy_name} /
- {env} までは環境設定であまり変わるものではないので,環境設定ファイルを作成して渡してしまう
- {policy_name} 以下は,ユーザーの目的によって頻繁に変わるので,入力引数として引き受ける
全てのプログラムは共有できることを念頭において開発する
検証コードもそう
レビューをもらう際には,結果を「再現」できる状態で相手に渡す
仕事への向き合い方
どう働きたいのか
谷村さん,西場さんは沢山のビジネス書を読んでいる
何故,自分の抱える課題についての本を読まないのか
生産性
プログラミング
何故,読んだ内容を実践しないのか
ビジネス書は実践のためにあるはず
実践しなければ身につくことはない,価値を理解することもできない
仕事への向き合い方は人それぞれ
but AIチームは仕事へのプロフェッショナル意識を持った集団を目指している
谷村さん,西場さんと同じ目線,同じ土俵にみんな必ずしも立っているわけではない
分析関連
取り込もうとしている特徴量は目で見て活きると思うのか??
ユーザーの傾向は?
A / B テストでもその要因で負けているのか?