はじめに
こんにちは。メディア統括本部 Data Science Center（DSC）の土井 悠生（どい ゆうせい）です。2025年に新卒でデータサイエンティスト（DS）として入社し、もうすぐ2年目を迎えます。
タイトルは大石哲之さんの名著『コンサル一年目が学ぶこと』にあやかりました。本の中で語られている「仕事の基礎力」は、コンサルに限った話ではない――DSの現場でも、まったく同じことを痛感した1年間でした。そう気づけたのは、トレーナーからの指摘を愚直にメモし続けたことがきっかけです。
DSとして配属されてから、トレーナーにレビューをしていただくたびに、受けた指摘をNotionに記録してきました。最初はただの備忘録のつもりでしたが、気づけばチェックリストは205項目にまで膨れ上がっていました。
実際のチェックリスト：
💡 チェックリストの完全版（PDF）はこちらからダウンロードできます。
ある日、そのリストを俯瞰してみると、面白いことに気が付きました。指摘の過半数は、特定の技術やツールの話ではありませんでした。
205項目を分類してみた結果がこちらです。
課題の設定の仕方、ドキュメントの書き方、メッセージの送り方、コードに向き合う姿勢――いわば「特定の技術やドメインによらない、仕事の基礎力」が全体の約59%（121項目）を占めていたのです。残りの約41%はモデル設計や可視化といった技術的な指摘でしたが、本記事では前者の「基礎力」に焦点を当て、特に重要だった学びを4つの章に分けて紹介します。
目次
- 第1章：「何を解決するのか」を正しく決めよう
- 第2章：伝わるドキュメントを書こう
- 第3章：相手に届くコミュニケーションをしよう
- 第4章：信頼されるコードを書こう
- 指摘をメモし続けて気づいたこと
- おわりに
対象読者
- DS職での就職・配属を控えている学生の方
- DS1〜2年目で同じような壁にぶつかっている若手の方
- 新卒DSを受け入れるトレーナー・メンター側の方
- 「DSの実務って実際どうなの？」と気になっている非DS職の方
忙しい方向け：おすすめの読み方
各章の冒頭に「3つのポイント」をまとめています。まずはそこだけ目を通して、気になった章から読んでみてください。
第1章：「何を解決するのか」を正しく決めよう
3つのポイント
- 手を動かす前に、現状を深く理解する。 ここを飛ばすと正しい問題設定はできない
- 問題と原因を区別する。 頭の中で混同したまま進めると、分析の方向がずれる
- 分析の範囲を明確にし、その妥当性を疑う。 狭すぎないか、広すぎないかを確認する
DSの仕事は、データを活用してビジネスの課題を解決することです。
しかし、いきなりデータに飛びつく前に、まず「そもそも何が問題で、何を解決すべきなのか」を整理する、いわゆる「要件整理」と呼ばれる工程があります。
私は、この最初の一歩で盛大につまずきました。何がまずかったのか、順番に振り返ってみます。
現状分析が浅く、問題を決めつけていた
配属直後の私は、データをざっと眺めて「これが問題だろう」と決めつけ、すぐに分析に取りかかっていました。しかし、トレーナーからは「その問題の中にどんな種類があるのか、深掘りしたのか？」と問われ、何も答えられませんでした。
例えば、「インシデントが多い」という問題を分析するとします。一口にインシデントと言っても、障害系なのか、セキュリティ系なのか、オペレーションミスなのか、種類は様々です。この分解をせずに「インシデントを減らすには？」と分析を始めても、焦点がぼやけたアウトプットにしかなりません。
現状を十分に理解しないまま問題を設定してしまい、分析の方向がずれ、手戻りが発生する――これを何度も繰り返しました。
問題と原因の区別がついていなかった
もう一つ、自分の思考の癖として根深かったのが、問題と原因の混同です。
例えば、「予測モデルの精度が要件を満たさない」が問題だとしたら、「学習データに欠損値が多い」は原因の一つです。しかし当時の私は、こうした原因を問題そのものだと思い込み、そこから直接対策を考え始めてしまうことがありました。
トレーナーに「それは問題？原因？」と何度も問い直され、ようやく意識できるようになりました。問題と原因が整理できていないと「結局何を解決したいのか」がぼやけ、的外れなアウトプットになります。
分析の範囲を正しく区切れていなかった
現状分析が浅いと、分析の範囲――スコープの設定も甘くなります。
あるタスクで「ユーザーの声を分析できていない」という課題に対して、「ユーザの不満を分析する」とスコープを設定したところ、トレーナーから「なぜ不満だけに絞ったのか？ポジティブな声を除外した根拠は？」と問われ、答えられませんでした。なんとなく「不満＝課題＝分析すべきもの」と思い込んでいただけで、その範囲が適切かどうかを検討していなかったのです。
スコープが曖昧なまま進めると、途中で「あれも必要だった」「ここは対象外では？」と方針がブレ始めます。最初に範囲を正しく区切るためにも、まず現状を深く理解することが不可欠でした。
今では、まず紙にラフに書き出して現状を分解し、抜け漏れなく把握した上で、「なぜ？」を繰り返しながら根本の問題を探りに行くようにしています。
第2章：伝わるドキュメントを書こう
3つのポイント
- 大事なのは「上から読んだときに理解しやすい流れ」になっていること。 見た目の整いと読みやすさは別物
- 言葉の定義を揃え、解釈がブレない表現で書く。 曖昧な言葉は読み手ごとに違う意味になる
- 極力シンプルに、必要な情報だけを簡潔に伝える。 余分な記述は余分な指摘を生む
分析の設計書、報告書、運用マニュアル――DSの仕事では、ドキュメントを書く場面が想像以上に多くあります。
私は「それっぽい」ドキュメントを量産しては、トレーナーに「読みづらい」と返される日々を過ごしていました。当時の自分が何を間違えていたのか、振り返ってみます。
体裁は整っているのに、読みやすくなかった
見出しの階層は揃っている。文章も簡潔に書いた。見た目は整えた。――自分の中では十分だと思ってレビューに出すと、トレーナーからは「上から目を通したときに、流れが頭に入ってこない」と言われました。
当時の私は、「見た目が整っている＝読みやすい」と思い込んでいました。しかし実際には、読み手が初見で上から目を通したときに、理解しやすい流れになっているかどうかが最も重要でした。当時の自分のドキュメントは、背景のセクションにアプローチの話が混ざっていたり、結論のセクションに情報を詰め込みすぎてどれが結論なのか分からなくなっていたりしました。一つひとつのセクションは成り立っているのに、情報の置き場所と量が整理されておらず、読み手に余計な負荷をかけていたのです。
読み手によって解釈がブレる言葉を使っていた
ドキュメントの構成だけでなく、使っている言葉そのものにも問題がありました。
例えば、「関係者」のような曖昧な表現を多用していました。「関係者」と書いても、それが誰を指すのかは読み手によって解釈が異なります。「関係者に確認する」ではなく「運用担当の○○さんに確認する」のように、誰のことかを明示して書くだけで解釈のブレはなくなります。
プロジェクトに関わる全員が読んで、解釈が一致する言葉で書く。当たり前のようで、意識しないとすぐに抜けてしまうポイントでした。
余計な情報が多かった
「せっかく調べたから」と、主題に直接関係しない情報まで盛り込んでしまう癖もありました。 情報量が多ければ丁寧に見えると思っていたのですが、実際は逆でした。
余分な記述があると、読み手は本筋と関係ないところにも目を通すことになり、「ここはどういう意図で書いてあるのか？」と余計な指摘を生みます。
トレーナーからは「極力シンプルに、必要な情報だけを簡潔に伝える」と何度も言われました。ドキュメントは自分のための記録ではなく、読み手のためのものです。
今では、書き始める前に「このドキュメントで一番伝えたいことは何か」を決め、そこからアウトラインを組み立てるようにしています。
第3章: 相手に届くコミュニケーションをしよう
3つのポイント
- 全てのコミュニケーションは「相手の時間を使う行為」だと認識する。 この意識があるかないかで、伝え方が根本から変わる
- メッセージには目的・依頼・期日を明示する。 相手がスムーズに判断・回答できる材料を揃えてから送る
- MTGは事前準備が9割。 ゴール・材料・時間配分を決めてから臨む
メッセージを送る、レビューを依頼する、ミーティング（MTG）を進行する。 どれも日常的な行為ですが、その一つひとつが相手の時間を使う行為だという認識が、当時の私には欠けていました。
何がまずかったのか、テキストでのコミュニケーションと、MTGでのコミュニケーションに分けて振り返ります。
テキスト編: 「だから何？」と思われるメッセージを量産していた
最初に課題だったのが、レビュー依頼やSlackでのメッセージです。
レビュー依頼では、目的・期限・Next Actionsが不明確でした。「レビューお願いします」とだけ送り、何をどの観点で見てほしいのか、いつまでに必要なのかを伝えていなかったのです。「レビューしていただく＝その人の時間を奪う」 ことだと認識していれば、もっと丁寧に準備できたはずでした。
Slackでの共有も同様です。「クエリはまだ動きませんが一旦共有します！」と送り、「なぜ今共有するの？」と返されたことがあります。本来は明確な意図があったのですが、メッセージから目的が読み取れないと、受け取った相手は「だから何？」としか思えません。
次に、質問や相談をする際にも課題がありました。「これってどういうスケジュール感で動いてます？」と聞いて、相手から「もっと早く対応した方がいい？できるけど？」と返されたときに、「う〜ん……」としか言えない状態になることが多かったです。聞く前に、自分がどうしてほしいのかを明確にし、相手の反応も想定した上で質問する必要がありました。
MTG編: 準備不足で相手の時間を浪費していた
MTGでの失敗も数え切れません。
最も多かったのは、MTGの目的と、相手に期待することが曖昧なまま臨んでしまうことです。「アウトプットを共有します！」とだけ伝えてMTGを設定したものの、「それ、テキストでも良かったのでは？」と言われてしまいました。MTGを開く以上、相手にどんな判断や意見を求めたいのかを明確にしておく必要があります。
議論の材料が不足していたことも問題でした。「このアウトプットを見て良さそうか判断ください」とだけ言っても、判断に必要な背景情報や比較対象がなければ、相手も「これだけでは判断できない」としか返せません。
ファシリテーションでも苦戦しました。そもそも事前にアジェンダごとの時間配分を決めていなかったため、何にどれだけ時間を使うかの基準がありませんでした。議論が発散しても落としどころを決められず、時間だけが過ぎていく。話す必要がない内容を端折れず、時間が足りなくなる。早く終われる場合でもダラダラと続けてしまう。――そんな場面が何度もありました。「参加者全員の時間を使っている」という意識があれば、もっと思い切って進行できたはずです。
第4章: 信頼されるコードを書こう
3つのポイント
- 全ての処理を理解し、説明できる状態にしてからレビューに出す。 「なぜこう書いたのか」に答えられないコードは出さない
- 命名規則やコメントで、レビュアーが読める状態にする。 自分が分かるだけでは不十分
- 品質を担保することが、DSとしての信用につながる。 「正しく動く」と「安心して使える」は違う
DSの仕事では、SQLでデータを集計したり、Pythonで分析スクリプトを書いたりと、コードを書く場面が日常的にあります。
私は「とりあえず動いた」時点でレビューに出してしまい、何度もやり直す羽目になりました。どこに問題があったのか、振り返ってみます。
「なぜこう書いたのか」に答えられなかった
当時の私は、コードが意図通りに動くことを確認したら、すぐにレビューに出していました。しかしトレーナーから「この処理はなぜこう書いたのか？」と聞かれたとき、明確に答えられないことが何度もありました。
動くコードを書くことと、そのコードを理解していることは別です。全ての処理について「なぜこの方法を選んだのか」「他にどんな方法があったのか」を説明できない状態は、つまり自分のアウトプットに責任を持てていない状態でした。
もしまだ十分に考えられていないなら、レビューに出す前に立ち止まります。「まだ考えきれていません」と正直に伝える。その方が、根拠のない主張をするよりもよほど責任ある姿勢だと学びました。
品質チェックが甘かった
コードの品質チェックにも大きな課題がありました。
例えばSQLでは、テーブルの結合で意図せずデータが重複していないか（1対多の結合）、出力件数が想定通りか、ウィンドウ関数のウィンドウ幅が正しいかなど、確認すべきポイントが多くあります。しかし当時の私は、こうしたチェックを「たぶん大丈夫だろう」で済ませていました。
命名規則の統一やコメントの不足も繰り返し指摘されました。テーブル名やカラム名が何を表しているか分からない、複雑な処理や判断の背景がコメントで補足されていない。レビュアーがコードを読み解くのに余計な時間がかかる状態でした。
「もう何度も確認しているから大丈夫」は、大丈夫ではありませんでした。品質チェックリストを作り、レビュー前に必ず通す。この仕組みを持つことで、ようやく確認漏れが減り始めました。
「正しく動く」と「安心して使える」は違った
品質チェックを続けるうちに、もう一つ気づいたことがあります。コードの品質は、単に正しく動くかどうかの問題ではありませんでした。
自分が出した集計結果をもとに、ビジネスメンバーが意思決定を行う場合、その数値に不備があれば、判断そのものが狂います。「この数字、合ってる？」と毎回確認されるようでは、アウトプットとして機能していないのと同じです。
そのアウトプットを、利用者が安心して使えるか。品質を担保することは、データサイエンティストとしての信用を積み重ねることなのだと、ようやく実感しました。
指摘をメモし続けて気づいたこと
ここまで第1章〜第4章で紹介してきた学びは、全てトレーナーからの指摘がきっかけでした。ここでは、その指摘をメモし続けたこと自体から得た気づきを紹介します。
やっていたことは単純で、指摘を受けるたびにその場で一行メモしていました。最初はただそれだけでした。しかしメモが溜まってくると、同じ指摘を受ける頻度が減っていきました。 見返すたびに過去の失敗が思い出されるので、自然と意識するようになったのだと思います。
体感では、3〜4ヶ月を過ぎたあたりから明らかに同じカテゴリの指摘が減り始め、代わりに新しいカテゴリの指摘が増えていきました。途中からはメモをカテゴリ別のチェックリストに整理し、レビュー前に必ず目を通すようにしました。仕組みにしてしまえば、意志の力に頼らなくて済みます。最近では、大きな指摘なくプロジェクトを進行できる場面も増えてきました。
余談ですが、現在はトレーナー主導でこのチェックリストの内容をClaude CodeのSkillsに組み込み、レビュー前にAIが指摘事項を自動チェックする仕組みも運用し始めています。
さらに面白かったのは、メモを俯瞰したときに自分の癖が浮かび上がってきたことです。「課題設定が甘い」「ドキュメントが読みづらい」「メッセージが伝わらない」「コードの品質チェックが甘い」。原因はどれも同じで、自分の視点だけで完結していて、相手からどう見えるかを考えていなかったのです。
指摘をメモし、チェックリストにして、次から同じミスをしないようにする――地味な作業ですが、1年間続けたことが一番の成長実感につながっています。
おわりに
全ての根底にある「他者視点」
メモし続ける中で気づいた「相手からどう見えるか」という視点を、各章に当てはめてみます。
- 課題設定：誰の、何の意思決定に使うのかを考えているか
- ドキュメント：読み手が初見で理解できる流れになっているか
- コミュニケーション：相手の時間を使っていると認識しているか
- コード：レビュアーが安心して受け取れる品質になっているか
「自分が何をやったかを伝える」ではなく、「相手がどう受け取るか」この視点を持てているかどうかが、全ての仕事の質を左右していました。
DSの実務は、技術だけでは成り立ちません。この記事が、これからDSを目指す方にとっては実務の解像度を上げるきっかけに、同じ壁にぶつかっている方にとっては「自分だけじゃない」と思える共感対象になれたら嬉しいです。そしてもし指摘を受ける機会があるなら、ぜひメモしてみてください。少なくとも自分にとっては、一番効果がありました。
最後に
この1年間、数え切れないほどの指摘をくださったトレーナーの鈴木 元也（すずき もとや）さんには、感謝しかありません。
改めて200個近いメモを振り返ると、これだけの量のフィードバックを一つひとつ丁寧に返し続けてくださったこと自体が、本当にありがたいことだと思います。正直しんどい時期もありましたが、あの指摘があったからこそ今の自分があります。
元也さん、本当にありがとうございました。2年目は、いただいた指摘の数だけ成果で返せるよう頑張ります。