98
81

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

NTTドコモ R&D Advent Calendar 2020

Day 2

社会人2年目がデータ分析で得た教訓

Last updated at Posted at 2020-12-01

はじめに

こんにちは.
NTTドコモサービスイノベーション部で働いております社会人2年目の橋本です.
業務では機械学習を中心にコードを書いています.
社会人2年目もあと残すところ4ヶ月弱となりましたが,社会人1年目から今日までデータ分析業務にて突っ走って来ました.
そんな私がこれまでを振り返るとスタート時にこれを知っておけばもっとスムーズにデータ分析を進めれただろう感じるポイントがいくつかあります.
アドベントカレンダー2日目の今日はそんな私からのクリスマスプレゼントということで「社会人2年目になった私が感じるデータ分析業務の教科書」を皆様にプレゼントしようと思います!

           christmas_santa_elf.png

※これ以降に出てくる内容は,難しい技術の内容は出てきません.
ただエンジニアとして働く上では大切なことも含まれていると思います.
データ分析業務に従事している方や,それ以外の技術者の方,
多くの方に読んでいただいて「わかる!あるあるだよね」と思っていただけたら幸いです.

  

ちなみにこれから書くことはまだ実践中で,完全にできている訳ではないです.
(わかっていても中々すぐにできるようにならないというのが私の所感です.)

教訓その1.超重要!コードは誰が見てもわかるように書くべし

そもそもコードをあえて汚く書こうと思っている人なんていませんよね.
ただ何も意識しないで書くと,挙動がすぐに理解できないコードだったりすることはよくあります.
特に私の場合は
試行錯誤のフェーズ(データの中身を軽く確認する・どうやってコードに落とし込むか考える段階のこと)
でできたコードは読みにくいことが多いです.

ここでは,
qiita_woman_computer.png
ことの大切さをお伝えしたいです!

1.1 なぜコードを綺麗に書くか?

業務をしていてたまに起こるのが,

qiita_hatena_woman.png

みたいな状況です. この状況は割と深刻な状況です.
過去の自分は他人のようなものなので,
自分が読みづらいと思ったコードは他人も読みづらいです.
例えばデバッグしてもらいたいと思って第三者にコードを見せると

などの弊害が生まれてしまいます.

1.2 どうすればコードが綺麗に書けるか?

じゃあどうすれば読みやすいコードになるの?という疑問が湧いてくるかと思います.
詳細については,参考書籍:リーダブルコードを読むのがお勧めですが,
いくつか参考に私が実践していることを書いておきます.

  1. コメントでどんなプログラムか書く
    データ分析をする際はjupyter-notebookを使用することが多いです.
    精度向上のためにmodelを複数作る場合などがありますが
    後でコードを見るとどんな特徴量を付け足し・削除をしたのか一々コードを確認しないといけなかったり,
    なぜその特徴量を付け足したかなどの自分の思考プロセスを思い出せないことがあります.
    このようなことを避けるため,一番上のセルになぜ・どんなことをしたのか書いておいて識別できるようにしています.

  2. なるべくネストは使わない
    試行錯誤的にコードを書いていくと,過去の私が作成したif文の中に更にifを分岐させて…みたいな状況がよくあります.
    作業している私からするとごく自然な流れでifが二重になるコードを生成しているのですが,
    このようにしてコードを書くと未来の私がとても苦しみます.

  3. ドキュメントを書く
    どのコードがどんな動きをするコードなのか書いてまとめましょう.
    ディレクトリの構造も書いておいた方が後々の自分が助かります.

社会人1年目の頃はコードは試行錯誤のフェーズで書いたらそのままにしてしまうことが多かったですが
試行錯誤のフェーズから相手にコードを見せるフェーズに移る前にコードをわかりやすく書き換えるのが基本です.
大切なことは「とにかく一目見たらどんなコードがなんとなくわかるコードにする」ことです.

※勿論試行錯誤のフェーズでそのままにしていたのは,サボっていた訳ではなく
コードを綺麗にすることの価値がきちんとわかっていなかったので,別のことに時間を使ってしまっていた.というのが正しいです.
ただ時間はかかってもコードをわかりやすく整理しておくことはかなり重要なので
生産性向上のため絶対にやったほうが良い
です.

教訓その2.メモリや計算時間には気を遣うべし

データ分析をしていると,必然的に大きなデータを扱うことが多くなってきます.
qiita_atama_woman.png

などに悩ませられることがあります.

2.1 tqdmを用いて処理時間を目視で確認しよう

まずforループを回すときや,大きなデータを読み込むときには
tqdmを用いてプログレスバーを表示させるようにしましょう.

tqdm は進捗を目視で確認できる便利なモジュールです.

from tqdm import tqdm
for i in tqdm(range(100)):
    ...

このような形で簡単にforループ内に組み込むことができます.

100%|██████████| 100/100 [00:00<00:00, 273066.67it/s]

余談ですが,

2.2 適材適所のデータ構造を使うべし

python にはlistやdict,setなど様々なデータ構造があります.
普段pythonを使い慣れている方でも,きちんとドキュメントを読んだことがない方も居るかもしれません.
一度目を通してみると新しい知見があって面白いです.

業務ではlistを使用してしまうことが多いですが,
listだと処理が重く,遅くなってしまうことも多いのでsetなどが使えないかどうか考えてみると良いです.

小ワザとして,listを用いてappendを行う場合は
forベタ書き→リスト内包表記を行うことで多少は高速になります.
また,大きな疎行列などを扱う際にはscipyを使うなど工夫をしてあげると良いです.

2.3 chunksizeを使って大きなファイルを読み込む

あまりにもファイルが大きくて

df = pd.read_csv('img_data.csv')

このような形で読み込んでも時間がかかる場合は

df = pd.read_csv('img_data.csv',chunksize='500')

のようにしてファイルを読み込むと良いです.

教訓その3.最強のチームを目指し個人のスキルを向上すべし

データ分析の仕事は,比較的属人化しやすいです.
そのため,個人のスキルが高ければそれで充分だと感じる人も多いかもしれません.

3.0 属人化って何?

属人化という言葉を知らない人のために,念のため記載しておきます.
weblio より抜粋

企業などにおいて、ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。多くの場合批判的に用いられ、誰にでも分かるように、マニュアルの作成などにより「標準化」するべきだとされることが多い。企画・開発業務など、属人化されているのが一般的と言われる業務もある。

上記にあるように,属人化という言葉は批判的に用いられることが多いようです.
あくまで個人の見解ですが,属人化と標準化はバランスが大切であり,どちらに傾きすぎても良くないと考えています.
           

3.1 なぜ属人化しやすいの?

データ分析の仕事は,仕事の性質上属人化が起こりやすいと考えています.
データ分析の大まかな流れは,

  1. ビジネス課題からデータ分析できる課題に落とし込む
  2. どんなデータが使えるか考える
  3. データ基礎分析
  4. 特徴量生成
  5. モデル作成
  6. 精度確認
  7. 精度向上のため4.5.6.を繰り返す

このような一貫した流れで仕事をすることが多いです.
基本的に上記のタスクを一人でこなしていくことが多いと思います.
1.2.の部分は比較的チーム内で相談しやすいかなと思いますが
3.以降はやはり一つのデータについて詳しくなっていってしまうので,一人で行うことが多くなります.

3.2 属人化のメリット・デメリット

上述したように,属人化と標準化は対義語にあたるものですが,どちらかであればいいというものではなくバランスがとても大切です.

属人化のメリット

  1. 自分のペースで働くことができる
  2. 責任感をもち一人一人が働く
    タスクが個人に紐づいているので,
    標準化で起こりがちな”だれかにタスクをなすりつける人が出てくる”ということは少ないです.

属人化のデメリット

  1. 異動などによるチームメンバーの欠如によってアウトプットに大きな差が出てしまう
    チームのメンバーによってアウトプットが異なってしまうので,割と致命的な属人化のデメリットです.
    できるだけアウトプットに差が出ないように対策をしておいた方が良いと思います.
  2. 引継ぎに時間がかかる
  3. ミスに気付きにくい
    社会人1年目の時に特に不安だったことの一つです.
    自分が何かミスしても自分しかわからないのでいつも最悪の場合を想定し,慎重に作業は行っています.
  4. きちんと作業しているか不透明
    タスクが個人で紐づいているので,他人の作業については何をしているかよくわからないこともありますが
    基本は相手を信用して作業をしているだろうと思っています.

3.3 どんなスキルが必要か?

タスクの流れは3.1でなんとなくわかったかなと思うので,
3.2ではデータサイエンティストとして必要なスキルを紹介します.
業務で必要なスキルは割と幅広く,
社会人として他の業種でも必要な論理的思考力やプレゼン力,タイムマネジメントから
専門的なものまであると感じています.
データサイエンティストはコーディングについては
python(特にPandasなど)やSQLなどを用いることが多いです.
深層学習も扱うので深層学習系のライブラリも使えると良いかなと思います.

データサイエンティスト協会から
スキルチェックリスト
2: https://www.datascientist.or.jp/common/docs/skillcheck_ver3.00.pdf
なども出ているようですのでぜひ参考にしてみてください.

3.4 チームで働く意義

教訓その1で書いたようにチーム内でコードを見せ合うこともありますし,
それぞれ持っているバックグラウンドが少しずつ異なるので,詰まった時にアドバイスをもらうことも多いです.
またチーム内では,急病や異動などによって急遽人が抜けてしまうことが考えられます.
その際にあるタスクを一人でこなしていて,必要なドキュメントやコードだけ置いていかれてしまうよりも,
日頃からチーム内でのメンバーである程度やっている内容やコードなどを理解していた方が
メンバーが欠如した際の立て直しが早く,
僅かではありますが属人化を防ぐことができます.

またチームで仕事をすると,様々な考え方やスキルを持った人が増えるので
一人だけで作業をするよりも良いアウトプットを出せるようになると考えられます.

教訓その4. 新しい技術のキャッチアップをすべし

4.1 なぜキャッチアップするの?

キャッチアップが必要な理由は大きく分けて二つです.

  1. 技術の進化スピードが速い
    機械学習の分野は,技術の進化のスピードがとても速いので,新しい技術のキャッチアップは欠かせません.
  2. チーム内での個性の確立
    3章でもチームについて触れましたが,
    チームで仕事をこなす際には,多様性が重視されます.
    これはデータサイエンティストなどの括りではなく,世間一般的にそうであると考えます.

       

考え方のみでなく,スキルセットも多様性に富んでいるほうが
チームはより素晴らしく洗練されたものになります.
3章で述べた基本的なスキルセット+αによって個人の地位を確立すると
チーム内での存在意義を感じられて仕事をしやすくなります.

しかし新入社員や経験が浅い人が,すぐにチームで個性を発揮できるほど,
ある一つの分野に精通しプロフェショナルになるのは難しいです.

もちろん先輩と同じ分野で先輩以上のスキルを身に付けられるのであれば何も問題ないですが,
そうなるには膨大な努力と時間が必要になります.
そこで,新しい分野を取り入れるという方法が考えられます.
新しい分野であれば,先輩社員であってもあまり知らない部分も多く
先輩と同様に地位を確立できるチャンスを掴むことができます.

このように,最新技術をキャッチアップし,詳しくなることで自分だけでなく,
チームとしても最強になれるのです.

4.2 キャッチアップの方法と最新技術の導入・検証について

キャッチアップの方法は人それぞれだと思います.
どの方法が正しいというのはないと思うので好きな方法で行えばいいと思っていますが,
大きな学会で発表された論文などは手堅くチェックしておくと良いかなと思います.
Google Scholarなどを用いて検索するのも良いかと思います.

良さそうな最新技術を見つけたら,実際にその技術が活かせるか検証してみましょう
技術の導入検証は,つまづくことが多いです.
先輩も知らないことを取り入れようとしているので
わからない時にどうしたら良いか困ってしまうこともあるかもしれません.

お勧めの方法は

  1. 公式ドキュメントを参考にする
  2. 公式のQuestion&Answerを参照する
  3. 公式のQuestion&Answerで質問する

この流れで行っていくと良いです.
(先輩曰く大抵のことはドキュメントで解決できるらしいですが
私はドキュメントと公式のQuestion&Answerを行ったり来たりして少しずつ知見を深めていくのが好きです.)
どうしてもわからない時は,公式のQuestion&Answerで聞きましょう.

※質問は英語ですることが多いですが,英語が苦手な技術者であることも想定して,
わかりやすい英語で書くか,コードを貼り付けたりすると良いと思います.

最後に

いかがでしたでしょうか?
私がデータ分析をする中でつまづいた部分とそこから得られた教訓について大まかに書きました.
社会人2年目までに感じた葛藤や,つまづいた部分をできるだけわかりやすく書いたつもりです.
これからデータサイエンティストを目指す方,エンジニアとしてコードを書く方,チームで仕事をする方など幅広い人に読んで貰えたら嬉しい限りです.

98
81
2

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
98
81

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?