Please enable JavaScript.

Coggle requires JavaScript to display documents.

西場さん，笹川さん，大瀧さん指摘まとめ (MUST で行ってほしいこと (出来ないとわかったことはすぐに宣言して周りに伝える, 迅速な情報共有,…

- - - - 与えられた選択肢の中から選択する，その際の選択基準を考えるべき
      - 物事を分解して捉えようとする努力をしているか
        
        何でも良いと〜系が良いという人にはたいてい大きな差がある
        
        機械学習を具体化出来ている人は分類ができている
        
        物事をカテゴライズ，分類した上で自分は何がしたいのか，真剣に考えているか
        
        画像
        
        言語
        
        音声
        
        予測モデルを作る
        DataScience 分野
        
        分析をし，ビジネスサイドの意思決定をサポートしたい
- - - - 周りの人の仕事の段取りも
        
        考えて仕事を行う
        
        互いの仕事をブラックボックスにする必要はない
        
        例 : Bourbaki
        
        - 堀井さんの出社日程と，仕事のお願いの仕方
        
        - 笹川さん，池田さんにお願いするインフラタスク
        
        - Unit1, デザイン側のスケジュール把握（いつまでにこちらが修正を出せれば，リリースはいつになるのか
        
        最終的な， Bourbaki を無事に動かすことを念頭に置いた，当事者間のスケジューリングを行う
      - なぜ今日終わると思ったのか？
        
        根拠と考察について
        
        自分の無意識の思考を分解する
        
        ロジックのレビューに何日かかると思うのか
    - - 因果関係がはっきりしているか？
        
        例：3ヶ月の時間差でのデータからの推定は難しい
      - 問題の本質に立ち返ってもっと簡単な方法が無いか？と議論する
        
        むやみにデータと機械学習に飛びつくのは危険
    - - 自分の仕事で他人に迷惑をかけないことなんて無い（誰しもそう）
      - 早めの段階で相談することで双方の負担を減らす
    - - どれが終わったらどれくらいの利益見込み？
        
        いつまでに終わるのか？
      - チームとして利益を追求するにあたって，いつまでにどれくらい，どのようにして稼げるのかを把握したいのは当然
    - - 自分が専門にしているプロジェクトにおける，インサイト，課題発見は自分が一番できるはず
        
        - 他の人がやろうとすると，キャッチアップ -> 思考まで沢山時間がかかってしまう
      - 課題がわかっていれば，手を動かすだけ？なので他の人に渡しやすい
        
        - 仕事の分散，引き継ぎ　がしやすくなる
    - - 各ステップにおける出力を把握し，課題の全体感を見失わないようにする
      - 各ステップのゴールの定義を周囲にレビューしてもらう
  - - - 何故 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で，１時間前に資料を共有するので良いのか？？今回のMTGは内容の共有というよりも，精査して議論するため，論文の共通理解の上で行うMTGのハズ．１時間前では読む時間が取れない
      - 伝える情報には専門家，担当として責任を持つ
      - 自分が行っているタスクの情報を細かく共有する
        
        そうすることで，仕事の分担，
        
        サポート等がスムーズに行える
      - コードレビューを積極的に行う
        
        コードレビューされないと仕事が前に進まない
        
        自分が助けてもらうのは確実なのに，相手を助けられるところで積極的にならないのはおかしいのでは
  - - - 必ず具体的な数値で尋ねる
        
        百, 千, 億？規模のリターンなのか
        
        どこまで工数を割けるかが判断できる
        
        数百万
        
        とりあえず Cloud Vision に画像を突っ込んだらこうなります
        
        あとは考えてみてください
        
        数千万
        
        Cloud Vision に画像を突っ込んだらこうなった
        
        改善のためには ~ こうすると良くなる -> 画像収集設計
        
        認識した文字列から情報を抽出するには ~ -
      - 互いのビジネスバックグラウンド，肌感の違いで認識のスレが生まれる
    - - + 相手の質問にまず答える
    - - 1. クライアントが欲しい情報を伝える
        　- こちらが頑張ったことを伝えるのでは決して無い
        2. 行って欲しい行動を伝える
      - 相手を動かすことが目的のコミュニケーション
        
        相手にとってメリットのある話になっているか
        
        相手が気になる点，不安な点を解消できているか
    - - 冗長な文章を書かない
        
        削れるところは徹底的に削る
      - 文章を構造化して，視覚的にどこが
        
        重要なメッセージなのかわかるようにする
    - - 資料は１，２割作ったところで見せて
        
        早めに談する
      - 何をどこまで作り込む必要があるのか
        
        相手の前提知識
        
        伝えたい情報，起こして欲しい行動，何が相手にとって価値があるのか
      - 資料の共有方法は何が良いのか考えて作業する
        
        スライドである必要があるの？
- - - - アルゴリズムチェックには事前に論文内容の共有をして相手に読んでもらった上でのレビューが必要
      - 事前の論文共有等，仕事の段取りを考える
    - - ユニットテストとモデルテストを分ける
      - シミュレーションにはその複雑さが本当に必要なのか
  - - - WIP を付けて，MR 作成，随時push
        
        WIP が付いていれば周囲の人もそれを理解して時間をかけて見ることはしない
        
        随時push することで開発過程を周りに可視化する
  - - - 不等号による比較を行う
        
        ==0 ではなく， <= 1e-5 だったらにする
        
        どこまで小さい値に意味があるのか考える
      - 値域を分割するのは連続性の観点?から好ましくない
        
        1e-5, <= 1e-5 と条件分けをすると ☓
        
        用いる値自体を x + 1e-5 としてしまうことで 0割を回避， & 最小でも 1e-5 を用いる事ができる
    - - 共有にあたって
        
        処理はほぼ関数化して，実行の流れを追いやすくする
        
        データはなるべくグローバル変数に入れない
    - - ログをメモリ上ではなく，ファイルに残すことができる
      - log レベルを設定ファイルから一括変更することで，デバッグモードでの出力， product 時には出力しない等を変更できる
    - - 変数名が長くなるのはそれが原因では
    - - 実行スクリプト，実行時の設定等は
        
        モジュール内に含めない
        
        開発されたモジュールは，実行したい環境で設定，実行関数等書くことによって用いられる ( 自分が import numpuy as np としているのと同じ
      - 環境設定と，ユーザー入力による設定を区別する
        
        環境設定
        
        実行時の環境設定(保存先，スクリプトの置き場所etc) は一度作ればそんなに変わることはないので，環境設定ファイルを作成し，デフォルトで値が入るようにすれば良い
        
        必要に応じて，環境設定ファイルを切り替える
        
        ユーザー入力
        
        実行スクリプトの引数としてユーザーの入力を引き受けて，処理を変更する
        
        https://bourbaki{env} / test.com / {policy_name} /
        
        - {env} までは環境設定であまり変わるものではないので，環境設定ファイルを作成して渡してしまう
        
        - {policy_name} 以下は，ユーザーの目的によって頻繁に変わるので，入力引数として引き受ける
    - - レビューをもらう際には，結果を「再現」できる状態で相手に渡す
- - - - 何故，自分の抱える課題についての本を読まないのか
        
        生産性
        
        プログラミング
      - 何故，読んだ内容を実践しないのか
        
        ビジネス書は実践のためにあるはず
        
        実践しなければ身につくことはない，価値を理解することもできない