- チームのミッションは，データサイエンスの力で事業成果に直結する課題解決を主導すること
- 提供価値はクライアントの事業成果への貢献で測る：分析結果を示唆で終わらせず，意思決定・施策・業務変革につなげる
仕事効率化
2025年12月01日
regmonkey_index:
title_fontsize: 1.4em
bullet_fontsize: 0.9em
title_position: -0.5em
bullet_position: 1.5em
children:
- title: 1. チームを知る
description:
- ミッション・役割変革
- アプローチ「ドメイン×データサイエンス」・相談先
width: [35,65]
- title: 2. 最初の4週間
description:
- 週ごとのタスクリストで「教わる」から「任される」へ
- 環境構築・1on1から小規模テーマの主担当まで
width: [35,65]
- title: 3. 業務プロセス
description:
- 受託分析プロジェクトのデリバリーと社内活動
- クライアント定例・スケジュール管理・リモートワークのルール
width: [35,65]
- title: 4. リソース・ツール
description:
- アカウント申請・コミュニケーションルール
- ツール・開発作法の学習資料
width: [35,65]
- title: 5. 評価とキャリア
description:
- 半期の評価サイクルと2種類の評価
- JG別の期待役割・3つの「目指す姿」
width: [35,65]
- title: Appendix
description:
- 用語集：チーム内の頻出ワード
- FDDS・MBO・JGなど11の用語の意味を確認
width: [35,65]チームを知る
最初の4週間
業務プロセス
リソース・ツール
評価とキャリア
Appendix
record1:
目指す姿:
- 事業成果に直結する問いを設計する<br>（Analytics Translator）
果たす役割・貢献の形:
- クライアントのドメインと意思決定の構造を理解し，解決すべき課題を「分析で解くべき問い」へ落とし込む
- 分析結果を示唆で終わらせず，意思決定・施策・業務変革につなげる
主なキーワード:
- 業務理解・課題設定・問いの設計
- KPI・指標設計・仮説構築・検証設計
- ステークホルダー合意形成・施策実装への接続
record2:
目指す姿:
- 分析可能なデータ・指標基盤を設計する<br>（Analytics Engineer）
果たす役割・貢献の形:
- 分析すべき観点・指標を具備したデータ基盤を整備・運用し，データと加工の品質を担保する
- AIと人間の双方が正しく使える環境の構築で，クライアントの価値創出をリードする
主なキーワード:
- データ定義・指標設計・データ品質
- メタデータ・セマンティックレイヤー
- AIエージェントが誤解しにくいテーブル設計
record3:
目指す姿:
- 高難度な分析・実装をリードする<br>（AI-empowered Specialist）
果たす役割・貢献の形:
- AIエージェントを使いこなし，分析・実装・検証・ドキュメンテーションのサイクルを高速化する
- DSの諸領域の専門性を深め，高難度な分析・実装をリードする
主なキーワード:
- AIエージェント活用・分析自動化・実装高速化
- 統計・機械学習・因果推論・最適化・MLOps
- AI出力の妥当性評価・専門知によるレビュー「データだけでなく，知識を使って学習する」がチームの共通思想
機械学習を素朴に適用する難しさ
ドメイン知識をモデルに組み込む
背景：LLMの性能向上で分析実務の一部は誰でも実行できる時代に
AS-IS：「分析の実行役」の限界
TO-BE：「設計・実装の担い手」への変革
ストラテジスト：変革を牽引
エンジニア：価値を実装
DS：モデルを仕上げる
regmonkey_index:
title_fontsize: 1.1em
bullet_fontsize: 0.85em
numbering: false
bullet_position: 0.5em
children:
- title: ユニットリーダー
description:
- プロジェクトのアサインと優先順位を決定：キャリアの方向性も週次1on1でここに相談
- 勤怠・休暇など労務関連の相談先
width: [30,70]
- title: プロジェクトリーダー（PL）
description:
- 担当プロジェクトの進め方・成果物・スコープの相談先
- プロジェクトの困りごとエスカレーションもまずPLへ
width: [30,70]
- title: ストラテジスト
description:
- クライアント戦略・提案・ステークホルダー調整の相談先：経営層との合意形成をリード
width: [30,70]
- title: エンジニア
description:
- クライアント環境・実装・インフラ制約の相談先：本番リリースまでの技術判断をリード
width: [30,70]
- title: 先輩DS
description:
- 分析設計・モデリングの実務を担当：分析手法・過去の分析事例はまずここに相談
width: [30,70]チームを知る
最初の4週間
業務プロセス
リソース・ツール
評価とキャリア
Appendix
第1週
分析に着手できる状態を作る
第2〜3週
実務サイクルに参加する
第4〜5週
主担当として回す
record1:
週:
- 第1週
重点テーマ:
- 分析環境と関係構築
主なタスク:
- アカウント・権限の一括申請：分析基盤・ソースコード管理・BIツール（詳細は「リソース・ツール」章を参照）
- 分析環境のセットアップ：リポジトリの取得・仮想環境の再現・サンプルコードの実行確認
- チーム・ワンチームメンバー（ストラテジスト・エンジニア）との1on1：日程は各自で調整
- ドメイン知識講座（1回目）：クライアント業界の構造と主要KPIの基礎
- 期初目標（MBO）を設定し，ユニットリーダーとすり合わせ：詳細は「評価とキャリア」章を参照
record2:
週:
- 第2週
重点テーマ:
- データとドメインの土地勘
主なタスク:
- 担当プロジェクトのスコープ・成果物・データ環境を把握：DWHの主要テーブルとデータ定義を読む
- 過去の分析レポート・リポジトリを読み，チームの分析作法（レビュー・再現性のルール）を理解する
- クライアント定例資料の作成を先輩DSとのペア作業で体験
- ドメイン知識講座（2回目）：クライアントのデータ基盤と帳票の読み方record1:
週:
- 第3週
重点テーマ:
- 実務サイクルに参加
主なタスク:
- 担当プロジェクトのキックオフまたはクライアント定例に参加し，論点と意思決定の流れを把握
- 小規模な分析タスク（EDA・データ品質チェックなど）をレビュー前提で担当
record2:
週:
- 第4週
重点テーマ:
- 主担当デビュー
主なタスク:
- クライアント定例資料を主担当として作成・報告
- 分析の一次アウトプット（仮説・検証設計・ベースラインモデル）をレビューに提出
- 期初目標（MBO）の修正・確定
record3:
週:
- 第5週
重点テーマ:
- 独り立ち
主なタスク:
- 小規模なワークストリームを主担当として推進：分析設計から報告までを一巡させる
- コード・データ・手順をドキュメント化し，再現可能な形でチームコラボレーションできる状態にする
- 困りごとは翌週に持ち越さず，週次1on1で共有チームを知る
最初の4週間
業務プロセス
リソース・ツール
評価とキャリア
Appendix
プロジェクト（デリバリー）
社内活動
record1:
会議体:
- クライアント定例<br>(External)
頻度:
- 週次
目的・参加ルール:
- 進捗報告と論点討議：報告資料は前日までにPLのレビューを受ける
record2:
会議体:
- プロジェクト内定例<br>(Internal)
頻度:
- 週次〜日次
目的・参加ルール:
- ワンチーム内のタスク・ブロッカー共有
record3:
会議体:
- チーム会
頻度:
- 週次（月曜）
目的・参加ルール:
- チーム内の案件状況共有と意思決定：全員参加
record4:
会議体:
- 朝会
頻度:
- 毎営業日
目的・参加ルール:
- 当日のタスクと困りごとの共有：15分で完結
record5:
会議体:
- 月次レビュー
頻度:
- 月次
目的・参加ルール:
- プロジェクト横断で品質・稼働・収支を振り返り，翌月アクションを確認リモートワーク日に毎日実施する3ステップ
勤務開始時
勤務中
勤務終了時
チームを知る
最初の4週間
業務プロセス
リソース・ツール
評価とキャリア
Appendix
record1:
区分:
- 開発・分析環境
申請・設定するもの:
- ソースコード管理・分析基盤・BIツールの各アカウント
ポイント:
- ツールごとに申請先が異なる：チームの申請一覧に従う
- ソースコード管理の初期設定は<a href="http://localhost:4201/posts/2025-06-07-getting-started-with-github/#/title-slide">はじめてのGitHub</a>を参照
record2:
区分:
- コミュニケーション
申請・設定するもの:
- チャット・Web会議・共有ドライブの権限
ポイント:
- チームスペースへの招待はユニットリーダーに依頼
record3:
区分:
- 人事・労務
申請・設定するもの:
- 人事システムへの個人情報・緊急連絡先の登録
ポイント:
- 初週中に登録を完了させる
record4:
区分:
- 総務・経費
申請・設定するもの:
- 入館証・名刺・経費精算システムの設定
ポイント:
- 経費の承認ルートを最初に確認しておく取り扱い注意の情報が多いため，用途ごとに指定ツールを使い分ける
record1:
用途:
- チャット・通話
ツール:
- Slack
運用ルール:
- 即時性の高い連絡・質問・勤怠報告に使用
- 短時間の相談・画面共有はSlackハドル
record2:
用途:
- Web会議・予定表
ツール:
- Google Meet
- Googleカレンダー
運用ルール:
- 会議依頼はすべてカレンダーで管理
- クライアント定例・社内定例はMeetで実施
record3:
用途:
- ドキュメント・タスク管理
ツール:
- Notion
運用ルール:
- 議事録・ナレッジを集約し，プロジェクトタスクと社内活動タスクを一元管理
record4:
用途:
- 資料作成・共有
ツール:
- Google Drive
運用ルール:
- 提案書・報告資料は原則Drive上で作成・共有
- ローカル保存はしない
record5:
用途:
- ソースコード管理
ツール:
- Git
- GitHub
運用ルール:
- 分析コード・実装はリポジトリで管理
- レビューはPull Requestで実施
record6:
用途:
- 分析・開発基盤
ツール:
- Google Cloud
運用ルール:
- データ分析・モデル開発の標準基盤
- プロジェクトによってはAWSなどクライアント指定の基盤を使用
record7:
用途:
- コーディングエージェント
ツール:
- Claude Code
- Codex
運用ルール:
- 許可されたエージェントのみ使用
- クライアントデータの取り扱いはプロジェクトのルールに従うrecord1:
チャンネル:
- チームチャンネル
用途:
- 日常の連絡・質問・相談
運用ルール:
- 質問は歓迎：迷ったらまずここに書く
record2:
チャンネル:
- 勤怠報告チャンネル
用途:
- 勤務開始・終了の報告
運用ルール:
- リモートワーク時は毎日実施
record3:
チャンネル:
- 部門アナウンス
用途:
- 部門一斉の連絡
運用ルール:
- 共有ドライブの権限設定の単位としても使うため覚えておく
record4:
チャンネル:
- 全社・現場発信
用途:
- 営業・デリバリー現場からの情報発信・全社連絡
運用ルール:
- 必読：返信は全社に配信されるため送信前の相談が必須record1:
テーマ:
- バージョン管理
資料:
- <a href="http://localhost:4201/posts/2025-06-07-getting-started-with-github/#/title-slide">はじめてのGitHub</a>
内容:
- アカウント作成からPull Requestまでの基本操作
record2:
テーマ:
- 開発フロー
資料:
- <a href="http://localhost:4201/posts/2026-05-25-git-development-flow/#/title-slide">小規模ProjectにおけるGit開発フロー</a>
内容:
- ブランチ運用・コミット・マージ戦略のチーム標準
record3:
テーマ:
- コーディングエージェント
資料:
- <a href="http://localhost:4201/posts/2026-04-13-claude-code-101/#/title-slide">はじめてのClaude Code</a>
内容:
- コーディングエージェントの導入手順と基本的な使い方
record4:
テーマ:
- リモート接続
資料:
- <a href="http://localhost:4201/posts/2026-06-01-manual-example/#/title-slide">OpenVPN 接続設定手順書</a>
内容:
- リモートワークに必要なVPN接続の設定手順
record5:
テーマ:
- 分析レビュー
資料:
- <a href="http://localhost:4201/posts/2026-06-12-analysis-check-list/#/title-slide">分析レビューの８つの観点</a>
内容:
- 分析アウトプットをレビューに出す前のセルフチェック観点
record6:
テーマ:
- 資料作成
資料:
- <a href="http://localhost:4201/posts/2025-05-07-how-to-write-slide/#/title-slide">構造化されたストーリーとしてのスライド</a>
内容:
- 1スライド1メッセージ・結論先出しのスライド作成作法チームを知る
最初の4週間
業務プロセス
リソース・ツール
評価とキャリア
Appendix
半期の評価サイクル：4つの評価イベント
目標設定
プロジェクト評価
期末評価
評価会議・通知
プロジェクト評価
期末評価（人事評価）
record1:
JG:
- J5
期待する役割:
- データサイエンスの特定領域でチーム内で最も知見を持ち，複数プロジェクトをQCD観点からマネージできる
評価のポイント:
- 明確なビジネス貢献を評価する：新規提案・新技術の社内導入・標準化による生産性向上・外部発信など形は問わない
record2:
JG:
- J4
期待する役割:
- 1つのプロジェクトのデータサイエンスパートを，品質を担保しながら推進できる
評価のポイント:
- プロジェクトマネジメントを期待：アウトプット定義・タスク分解・メンバーのレビュー・早期のエスカレーション
record3:
JG:
- J3
期待する役割:
- 上位者のサポートをほとんど必要とせず，自律的にタスクを設計・推進できる
評価のポイント:
- 1つのワークストリーム・テーマを担当：判断に必要なアウトプットを定義し，レビューを受けながら推進する
record4:
JG:
- J2
期待する役割:
- PO・PLの指示を受けながら一定の品質でアウトプットを出せる
評価のポイント:
- プロジェクトの実質的な原動力：期限までにアウトプットを作成し，成熟度に応じて粗い粒度のタスクを担う
record5:
JG:
- J1
期待する役割:
- PO・PLの指示を受けながらタスクを遂行できる
評価のポイント:
- 育成段階：渡されたタスクの確実な遂行から始めるキャリアを考えるうえでの3つの前提
キャリア例：「目指す姿」ごとの歩み方
チームを知る
最初の4週間
業務プロセス
リソース・ツール
評価とキャリア
Appendix
glossary:
- def: 1on1
description: |
1対1の定期ミーティング：ユニットリーダーとは週次で実施し，困りごとを早めに共有する
- def: ワンチーム
description: |
ストラテジスト・エンジニア・DSの3職種が1チームでクライアントに入り込み，プロジェクトを進める体制
- def: MBO
description: |
Management by Objectives：期初に設定する個人目標．評価サイクルの基準になる
- def: JG
description: |
ジョブグレード：習熟度・レベルを示す社内の共通言語．JGごとに期待役割が定義される
- def: プロジェクト評価
description: |
プロジェクト上長との1on1で成果を記録するスナップショット：期末評価のインプットになるglossary:
- def: QCD
description: |
Quality（品質）・Cost（コスト）・Delivery（納期）：プロジェクトを品質・工数・納期のバランスで管理する考え方
- def: KPI
description: |
重要業績評価指標：チームがモニタリングする数値目標．定義はBIアナリストに確認
- def: FY・上期・下期
description: |
会計年度とその前半・後半：四半期・月次の計画サイクルの基準になる
- def: DWH
description: |
データウェアハウス：分析用データを集約した基盤．分析はここのデータを正とする
- def: 独り立ち
description: |
クライアント定例資料とワークストリームを主担当として回せる状態：オンボーディングのゴールRegmonkey Presentation. ©Ryo Nakagami. All rights reserved.