112
77

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

データサイエンティスト1年目の学び(2025年)

112
Posted at

はじめに

こんにちは!データサイエンティストのタランチュラです。

「データサイエンティスト1年目って、結局なにをやって、なにで詰まって、なにが一番伸びるの?」
これ、目指している人ほど気になる一方で、いざ探すと“キラキラした成功談”か“技術だけの話”に偏りがちで、実務の肌感が分かる記事って意外と少ないなと感じていました。

そこで今回は、新卒データサイエンティストとして1年間働いてみて、実際に「これは効いた」「これは遠回りだった」「もっと早く知りたかった」と思った学びを、できるだけ実務目線でまとめます。
華やかな話よりも、現場で手触りのある内容を意識して書きました。

この記事が特に役に立つのは、たとえばこんな方です。

  • これからデータサイエンティストを目指す学生・社会人の方
  • 未経験/異業種から中途でDSを目指していて、現場のリアルを先に知りたい方
  • 「技術は勉強しているけど、仕事としてどう進むのか」がイメージできていない方
  • 1年目で“伸びる人の動き方”を知りたい方

データサイエンスやAIエンジニアとして成果を出すために必要なのは「技術力」だけではなく、コミュニケーションや進め方も含めた総合力だと、1年目で痛感しました。

この記事では、僕が1年間で特に重要だと感じたポイントを、次の順で整理していきます。

コミュニケーション:認識ズレを減らし、手戻りを最小化する方法
技術力:実務で効いた“地味だけど強い”技術の話
仕事の進め方:不確実なタスクを前に進めるための型
副業のすゝめ:本業だけでは得にくい学びと、成長が加速した理由

どれも「こうすれば正解」という話ではなく、僕が失敗しながら学んだ、現時点のベストです。
同じような状況の方が、遠回りを少しでも減らせるなら嬉しいです。

また、Xでもデータサイエンスや生成AIに関する情報発信をしています。
Qiitaでは書き切れない小ネタや学びも日々投稿しているので、興味があればぜひフォローしていただけると励みになります。

それではまず1年目の仕事内容について簡単に説明します。

1年目の仕事

image.png

本章では、まず前提として「1年目にどんな仕事をしていたのか」を簡単に共有します。
このあと書く「コミュニケーション」「技術力」「仕事の進め方」の学びは、この業務内容をベースにした体験談なので、先にここを押さえておくと読みやすいと思います。

僕が1年目で主に担ったのは、生成AIを活用したアプリ開発です。
従来の「分析レポート作成」や「モデル構築」といった、いわゆるデータサイエンティスト業務だけでなく、今まさに現場で増えている「生成AIをプロダクトに組み込む」タイプの開発に深く関わることができました。

少し極端に言うと、最近は「データサイエンティスト=モデルを作る人」というよりも、
生成AIを前提に、プロダクトを素早く作って改善する人の役割が求められる場面が増えていると感じています(もちろん会社やチームによりますが、体感としては確実に増えました)。

実際の業務でも、生成AI(LLM)を扱うだけではなく、

  • 画面側の体験を作る フロントエンド
  • APIやデータ処理、認証、プロンプト管理などを担う バックエンド
  • そして、品質・速度・コストのバランスを見ながら運用に乗せる 実装〜改善

まで含めて担当し、働き方としては フルスタックに近い形 でした。
この経験が、のちの「コミュニケーション」や「仕事の進め方」の学びにそのまま直結しています。

また、1年目から 副業にも挑戦しました。
副業では、SNS関連のレポートを 生成AIを活用して自動で作成するシステム を構築しました。

こちらは当初、設計・開発・運用まで完全に1人で取り組んでいました。
要件を整理して、仕組みに落として、動かし続けるところまでやり切る必要があり、本業とは違った意味で「仕事の全体像」が一気に鍛えられたと感じています。

最近はメンバーを2人追加し、現在は 3名で協力して開発を進めています。
1人で進めるフェーズと、チームで進めるフェーズの両方を経験できたことで、コミュニケーションの重要性もより強く実感しました。

コミュニケーション

image.png

それではまず、「コミュニケーション」関連での学びについて書きます。

「データサイエンティストやエンジニアも結局コミュニケーションが一番大事。」学生の頃から何度も聞いてきた言葉ですが、1年働いてみて、これは本当にその通りだと痛感しました。

正直、入社前は「技術力さえ上げれば成果は出る」と思っていました。
もちろん技術力は大切です。ただ、今の実務ではそれと同じくらい、場合によっては コミュニケーションの方が成果に直結する と感じています。

理由はシンプルで、生成AIの普及によって技術の“底上げ”が進み、実装自体は以前より早くできるようになりました。
一方で、仕事のボトルネックになりやすいのは、技術そのものよりもコミュニケーション力だと感じています。

逆に言えば、コミュニケーション力が高い人は仕事が速い。この差が、体感として「天と地」くらい開きます。

この章では、僕が特に重要だと感じたコミュニケーションを 3つの型 にまとめて紹介します。

  1. 前提から説明した上で、質問・議題を投げる
  2. 構造的に整理してから発言する
  3. 聞かれる前に、こまめに進捗共有する

前提から説明した上で、質問・議題を投げる

上司や他部署に相談するとき、いきなり「これってどうすればいいですか?」と聞くと、相手はまず状況把握から始める必要があります。
結果として、

  • 質問がズレる
  • 回答もズレる
  • 追加で聞き返される
  • さらに時間が溶ける

という事故が起きやすいです。

僕が意識するようになったのは、“前提→論点→希望する判断” の順で投げることです。

  • 前提:いま何をしていて、何が目的か
  • 状況:現状どうなっていて、何が課題か
  • 論点:何で迷っているか(選択肢があるなら並べる)
  • 相談:相手に何を決めてほしいか / 何を教えてほしいか

例(イメージ)
「目的は◯◯です。現状△△までできていて、詰まっているのが□□です。選択肢はAとBで、僕はA寄りですが、リスクは〜です。どちらで進めるのが良いですか?」

これだけで、相手の脳内ロードが減って、回答の質と速度が一気に上がります。
そして何より「この人は状況整理して持ってくるな」と信頼が積み上がりやすいです。

続きの議論をするときは、「前回までのおさらい」などもコミュニケーションに加えると非常にスムーズです。

構造的に整理してから発言する

会議や相談の場で、頭の中で整理しながら話し始めると、だいたい途中で迷子になります。
すると、「結局何が言いたいの?」となり、議論が止まります。これ、僕も何度もやりました。

ここで効いたのが、結論→理由→具体(必要なら次アクション) の型です。
いわゆるPREPに近いですが、仕事ではこの順が本当に強いです。

話す順番のおすすめ

  • 結論:私はこう考えています / これを提案します
  • 理由:なぜなら〜(判断軸は何か)
  • 具体:データ/例/前提条件
  • 次:次に何をするか(相談なら“決めてほしいこと”)

また、データサイエンス領域は論点が散らばりやすいので、発言前に一度だけ

  • 「論点は2つあります」
  • 「決めたいのはAかBです」
  • 「結論から言うと〜」

みたいな “ラベル付け” を入れると、聞き手が迷子にならないのでおすすめです。

結果として、会議での理解が早くなるだけでなく、
「この人が話すと整理される」→「重要な相談が集まる」→「任される」
という良い循環が起きやすくなります。

「今の進捗は?」と聞かれる前に、こまめに共有する

1年目で特に効いたのはこれです。これだけは全員やるべきだと感じています。
進捗共有は「報告」ではなく、手戻りと不安を減らすための行為 だと理解してから、ストレスが減りました。

上司が「進捗どう?」と聞いてくるのは、多くの場合、

  • 遅れているかもしれない不安
  • どこで詰まっているか分からない不安
  • いつ成果物が出るか見えない不安

を解消したいからです。

なので、こちらから先に 短く・定期的に 出すだけで、驚くほど仕事がスムーズになります。

まとめ

ここまで書いた3つは、センスの話ではなく、誰でも再現できる型だと思っています。

  • 前提→論点→判断依頼で相談する
  • 結論→理由→具体で話す
  • 聞かれる前に、短く進捗共有する

生成AIで実装は速くなる一方、仕事の差分は「認識合わせ」に集約されやすくなっています。
だからこそ、1年目のうちにコミュニケーションを“スキル”として鍛えると、伸び方が変わるはずです。

次章では、実務で効いた「技術力」について書いていきます。

技術力

続いて、1年目で学んだ「技術力」について書きます。

学生時代の僕は、新しいAIアルゴリズムの理解や、生成AIの実装そのもの(プロンプト・RAG・LLM活用など)に重きを置いていました。
もちろんそれも大事です。ただ、実務に入って強く感じたのは、評価される“技術力”の中身が想像以上に違うということでした。

1年目のデータサイエンティスト / AIエンジニアは、基本的に player(プレイヤー) です。
つまり「設計して、作って、動かして、直して、改善する」人。
分析も開発も、とにかく手を動かして前に進める立場だからこそ、技術力は「知ってる」ではなく “動くものを最短で作り、安定して回す力” に寄っていきます。

この章では、1年目で特に重要だと感じた技術力を 3点 にまとめます。

  1. フロント・バックエンド・インフラのフルスタック技術の習得
  2. 実装設計を熟考し、レビューでPDCAを回す
  3. 実装箇所は「全行」論理的に説明できる状態にする

フロント・バックエンド・インフラのフルスタック技術の習得

image.png

生成AIの台頭で、生成AIアプリの需要が爆発的に増えています。
そして多くの場合、「LLMを触れる人」よりも先に求められるのは、非エンジニアでも使える形に“プロダクト化”できる人だと思います。

実務では、生成AIを扱う部分だけが切り出されて存在していることは少なく、だいたいこうなります。

  • フロント:ユーザーが入力して、結果が返ってくる体験を作る
  • バック:API、認証、DB、プロンプト管理、ログ、エラーハンドリング
  • インフラ:デプロイ、環境変数、監視、スケール、コスト管理

つまり、機械学習アルゴリズムや生成AIは、アプリの内部で動く部品の一つになりやすい。
この状態で強いのは「自分の担当範囲だけやる人」より、隣の領域まで分かっていて、チーム間の連携を滑らかにできる人だと感じました。

もちろん全員がフルスタックになる必要はないです。
ただ1年目のうちに、最低限

  • 自分の実装が「どこに繋がって」「どこで動いて」「どこで壊れるか」
  • 障害が起きたときに「どこを見れば切り分けられるか」

を理解しているだけで、開発の速度と質が大きく変わります。僕もインフラの知識は今一生懸命勉強しているところです!

実装設計を熟考し、レビューでPDCAを回す

1年目でやりがちなのが、とりあえず書く → たくさん書いてからレビューです(僕もやりました)。
でもこれ、後で気づくんですよね。
「ここ、根っこから設計変えた方が良くない?」って言われると、手戻りが大きすぎてつらい。

だから僕が意識するようになったのは、レビューは“実装後”ではなく“設計段階”で貰うことです。

たとえば、

  • どういう責務分割にするか(どの層が何を持つか)
  • データ構造・I/Oをどう置くか
  • 将来の拡張(機能追加、モデル差し替え、プロンプト変更)に耐えるか
  • 運用時に詰まりそうなポイントはどこか

を、コードを書く前に軽く整理して共有します。
設計が固まってから書くと、実装が速くなるのはもちろん、レビューの指摘も「表層」ではなく「本質」になります。

これはコミュニケーションにも近いですが、技術力としては“良い設計で、良いコードを書くためのPDCAを回せる”という力が、1年目から差になるポイントだと感じました。

実装箇所は「全行」論理的に説明できる状態にする

生成AIやCline、GitHub Copilotなどでコード生成が当たり前になった今、逆に増えるのがこの問題です。

「これ、なんでこう書いたの?」

自分が手で書いていなくても、AIが書いたとしても、レビューでは当然聞かれます。
ここで答えられないと、次のどちらかが起きます。

  • 直すべきか判断できず、コードが“ブラックボックス化”する
  • 事故ったときに原因が追えず、運用が破綻する

だから僕が強く意識するようになったのは、提出する前に最低限、

  • なぜこの実装にしたのか(目的)
  • どんな選択肢があって、なぜ落としたのか(比較)
  • どんな前提や制約があるのか(条件)
  • どこが壊れうるか、どう検知するか(運用)

を、自分の言葉で説明できる状態にすることです。

これができると、AIで実装が速くなった分、“設計・判断・レビュー対応” に時間を使えるようになります。
そしてここを握れるようになると、単なる実装担当(player)から一段上の、任される立場に近づける感覚がありました。

副業のすゝめ

ここからは「副業のすゝめ」について書きます。
少し生意気に聞こえるかもしれませんが、僕は 1年目から副業でもAIエンジニアとして働きました。

副業先はSNS運用代行企業で、当初はほぼ 1人でAI開発に従事 する形でした。
具体的には、単なる実装だけではなく

  • 何を作るべきかの整理(提案)
  • 要件定義・設計
  • 実装・検証
  • 保守運用(改善・不具合対応・運用フロー整備)

まで、一気通貫で担当しました。

正直、1年目のデータサイエンティスト / AIエンジニアが、ここまで裁量を持って「プロダクトを作って回す」経験を積める機会は多くないと思います。
だからこそ、この経験は本当にありがたかったですし、結果として 本業との相乗効果 が想像以上に大きかったです。

副業をおすすめしたい理由(メリット)

副業のメリットは「収入が増える」だけではありません。
特に1年目で効いたのは、次の4つでした。

1. 本業と副業で学びが循環する(成長が加速する)

本業で学んだことを副業で試せる。
副業で詰まったことを本業の知見で解決できる。
この 往復運動 ができると、学びの定着が一気に進みます。

体感としては「学んだつもり」が減って、使えるスキルになるスピードが上がりました。

2. 裁量が大きく、提案から全部経験できる

副業では小規模なAIチームだったこともあり、裁量がとても大きかったです。
実務で一番伸びるのは「作業」よりも、

  • 何を作るか決める
  • どこまでやるか線を引く(スコープ)
  • 誰のために、どう価値を出すか考える

みたいな部分だと感じています。
副業は、この部分を強制的に経験できる環境になりやすいです。

3. 本業で3〜5年後に経験しそうなことを、1年目から踏める

本業だと役割分担やレビュー体制が整っている分、経験が段階的になることが多いです。
一方で副業は、良くも悪くも「全部自分」で回す局面が出ます。

この “背伸び” の経験が、結果的に本業での視座を上げてくれました。
(「今自分がやってる作業は、全体のどこに効いてるのか」を考える癖がついたのは大きかったです)

4. 収入が増える(精神的な余裕ができる)

これは現実的なメリットです。
収入が増えることで、学習投資(書籍・ツール・クラウド費用)もしやすくなりますし、精神的な余裕も生まれます。

デメリット(正直しんどい点)

もちろんデメリットもあります。
僕の場合は、本業の定時勤務に加えて 月100時間ほどの稼働 が必要でした。

これは普通にハードです。
睡眠・運動・人間関係が崩れると本業にも影響が出るので、全員に無条件でおすすめできるわけではありません。

ただ、それでも僕は 圧倒的にメリットが大きかった と感じています。

副業の探し方や、どう始めるのが良いかは人によって変わるので、もし興味があれば個別に相談してもらって大丈夫です。
タイミング次第ですが、若干名であれば僕の副業先の開発にも参画できる可能性があります。

  • 強いやる気がある
  • 長く一緒に進められる
  • 上述した1年目の学びを実践できる

こういう方なら、大歓迎です!

さいごに

最後まで読んでいただき、ありがとうございました。
本記事では、新卒データサイエンティストとして1年働く中で学んだことを、できるだけ実務の手触りが伝わる形でまとめました。

1年目を振り返って強く思うのは、成果を出すために必要なのは「技術力」だけではなく、
コミュニケーションで認識ズレを減らし、仕事を前に進める“型”を持つことだということです。
そして副業のように、提案〜運用までを一気通貫で経験できる環境は、成長を加速させる大きなきっかけになりました。

これからも僕自身、コミュニケーション力と技術力の両方を磨きながら、副業も継続し、より大きな価値を出せる仕事を達成していきます。
その積み重ねで、5年後に掲げている自分の夢・目標を実現していきたいと思っています。

また、Xでもデータサイエンスや生成AIに関する学び・試行錯誤を発信しています。
この記事が少しでも参考になった方は、ぜひフォローしてもらえると励みになります。

今後も実務で得た学びは、Qiitaでも継続的に共有していく予定です。
少しでも参考になれば、いいね・ストックよろしくお願いします!
ありがとうございました。

112
77
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
112
77

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?