HOME/ AINOW編集部 /データサイエンティストはコードの書き方を知っていなければならない
2021.08.31

データサイエンティストはコードの書き方を知っていなければならない

最終更新日:

著者のTyler Folkman氏はコンテンツマーケティング会社Branded Entertainment NetworkでAI技術部門のリーダーを務めており(同氏の詳細は同氏公式サイトを参照)、以前に同氏が執筆した記事をAINOW翻訳記事『心配しないで、エクセルは意外と効果的』として紹介しています。最近、同氏が執筆した記事『データサイエンティストはコードの書き方を知っていなければならない』では、データサイエンティストがコードを上手に書けるようになるためのヒントが解説されています。
Folkman氏によれば、データサイエンティストはコードを書く機会が多いものも、ソフトウェアエンジニアほどには高品質なコードを書けず、また上手にコードを書く努力を怠っています。しかし、AIモデルがさまざまな製品や環境に実装されるようになった今日、データサイエンティストであっても高品質なコードを書けるようになるべきなのです。
高品質なコードを書くためのヒントとして、Folkman氏は以下のような5項目を挙げています。
  • 関数を簡潔に書く。具体的には1つのタスクだけを実行し、内容を反映した変数名を使う。
  • Print文は不要になったら削除するか、ログを採取するコードに置き替える。
  • スタイルガイドを採用し、それを遵守する。
  • テストコードを作成し、保存する。
  • コードレビューを実施する。

以上のようにヒントを挙げたうえで、コードを上手に書くこと自体は難しいことではないが、上手くなるまでに時間と努力が必要、とFolkman氏は述べています。

なお、以下の記事本文はTyler Folkman氏に直接コンタクトをとり、翻訳許可を頂いたうえで翻訳したものです。また、翻訳記事の内容は同氏の見解であり、特定の国や地域ならびに組織や団体を代表するものではなく、翻訳者およびAINOW編集部の主義主張を表明したものでもありません。

画像出典:UnsplashRoman Synkevych

ただコードを書くのではなく、良いコードを書く

(もしあなたがデータサイエンティストだとして、コーディングができるかと尋ねられたら)あなたが考えることはわかる。「もちろん、コードの書き方を知っているよ、そんなことを聞くなんて正気かい」

あなたは毎日、Jupyterノートブックに何百行もの大量のコードを書いている。明らかにコードを書ける。機械学習のモデルを手作業やExcelでトレーニングしているわけではないのだ(それも可能だが)。

では一体、私が言いたいこととは何か。

言いにくいことだが、データサイエンティストが行うコーディングのほとんどは、私がプログラミングと見なすものではない。データサイエンティストはデータを調査し、モデルを構築するためのツールとしてプログラミング言語を使っている。しかし、作成したプログラムは、仕事を遂行するためのものに過ぎず、あまり気にかけていない。

データサイエンティストのコードはたいてい散らかっていて、(ノートブックのおかげで)連続して実行されることもないかも知れない。また、ユニットテストを書いたことがなく、再利用可能な優れた関数の書き方についてもほとんど知らないだろう。

しかし、データサイエンスが実際の製品に組み込まれることが多くなると、そのようなコードでは対応できなくなる。悪いコードは信用できないし、信用できないコードを製品に組み込むと、膨大な技術的負債(※訳註1)と悪いユーザ体験を生み出してしまう。

(※訳註1)技術的負債とは、複雑なソースコードや文書化されない仕様のようなソフトウェア開発上の欠陥が引き起こし得る損害に対する改修コストのこと。欠陥が少ないうちは改修コストも少なくて済むが、欠陥が累積すると改修コストも膨らむことを負債になぞらえている。

「わかったわかった。しかし、私はデータサイエンティストであって、ソフトウェアエンジニアではない」とあなたは言うだろう。自分の仕事はモデルを構築することであって、コードをきれいにするのは他の人の問題だ。企業によってはそのようなやり方もあるかも知れないが、今のところ私が思うのは、データサイエンティストがよりよいコードの書き方を学ぶことのほうがはるかによい考え方である。エリートレベルのソフトウェアエンジニアにはなれないかも知れないが、データサイエンティストでも信頼できるコードを書け、そうしたコードを多少の労力で製品に投入できるのだ。

関数から始める

コードのレベルアップを図るには、まず関数の書き方から始めよう。ほとんどのコードは、関数(あるいは潜在的にはクラス)の集まりであり、優れた関数を書けるようになれば、コードの品質向上に大きく貢献する。

関数のコードは、以下のように必要最小限であるべきだ。

  1. 1つのこと(タスク)しかしない
  2. ドキュメントを作成する
  3. 良い変数名を使う

クリーンな関数の書き方については多数の本が書かれているほどだが、まずは以上の3項目から始めよう。

1つ以上のことをやろうとしているような関数は、絶対に避けなければならない。関数が多くのことをやりすぎている可能性がある兆候には、以下のようなものがある。

  • 1画面分より長い、あるいは30行程度のコードよりも長い(私の経験上)。
  • 多くのことを実行しようとしているために、関数名を明確に命名するのが難しくなっている。
  • if/elseブロック内に多くのコードが含まれている。こうした場合は実際には別々の関数に分割する必要がある。

1つのことだけをする関数は、コードの理解、管理、テスト(テストについては後述)を容易にするために重要だ。

本番環境にリリースされる関数には、一連のドキュメントが必要である。そうしたドキュメント群にはその関数が何をするのか、入力パラメータに関する情報を記述されているべきであり、その関数の使い方に関する簡単な例が示されているかも知れない。文書化された関数があれば、後に自分自身に感謝することになるだろうし、他の人があなたのコードを理解するのが非常に簡単になるだろう。

最後に、わかりやすくて親切な変数名を使うようにしよう。多くのデータサイエンティストが「a」、「a1」、「a2 」などの変数名を使うことで悪循環に陥っている。短いが不親切な変数名は実験時には早く入力できるが、コードを本番環境に投入する際には他の人がコードを理解するのに役立つ変数名にしよう。

Print文の削除

データサイエンティストは起こっていることに関する情報を表示するために、しばしばprint文を使用する。しかし、本番環境では、これらのprint文は不要になったら削除するか、log文に変換する必要がある。

(ログを採取する)ロギングは、コードからの情報やエラーを伝達する方法であるべきだ。ロギングをよりシンプルにするために、PythonのライブラリとしてLoguruがある。Loguru は、ロギングに関する煩わしい部分のほとんどを自動的に処理し、単なる print 文を使用するのと同じように感じられる。

スタイルガイドの使用

プログラミングにおけるスタイルガイドは、多くの人が同じコードに取り組みながらも、そのコードのほとんどが一人で書かれたように見えるようにするために使用される。

なぜスタイルガイドが重要なのか。

一貫したスタイルを持つことで、コードのナビゲーションや理解が非常に容易になる。スタイルガイドを使用すると、バグの発見が驚くほど簡単になる。標準的なコードの書き方に準拠することで、他の人と同じように簡単にコードをナビゲートできるようにもなる。つまり、コードを理解するためにそれがどのようにフォーマットされているのかを解析するのに多くの時間を費やす必要はなく、代わりにコードが何をするのか、それが正しく動作するどうかに集中できるのだ。

PEP 8(※訳註2)は、おそらくPythonのスタイルガイドとして最も広く使われている。しかし、世の中には多くのスタイルガイドがある。スタイルガイドのもう1つの人気のあるソースはGoogleで、彼らは社内のスタイルガイドを公開している。

(※訳註2)Pythonの標準ライブラリに含まれているPythonコードのコーディング規約であるPEP 8の内容をまとめた日本語サイトはこちら

重要なのは、1つのスタイルを選び、それを遵守することだ。こうしたことを容易にする1つの方法は、IDE(※訳註3)にスタイルエラーをチェックする機能を持たせ、スタイルガイドに従わない場合にはコードがプッシュされないようにするスタイルチェックを設定することである。さらには、コードを自動的にフォーマットしてくれるオートフォーマッターも使える。これは、好きなようにコードを書いたとしても、実行すると標準に準拠するようにコードを自動フォーマットしてくれるものだ。Pythonで人気があるオートフォーマッターはBlack(※訳註4)である。

(※訳註3)IDE(Integrated Development Environment:「統合開発環境」)とは、テキストエディタ、コンパイラ、デバッカ等を統合した総合的なソフトウェア開発環境のこと。
(※訳註4)PythonのオートフォーマッターであるBlackのGitHubページはこちら

テストの作成

私が思うにほとんどのデータサイエンティストがテストを恐れるのは、テストの始め方がよくわからないからだ。

実のところ、多くのデータサイエンティストは、テンポラリーテスト(一時的なテスト)と私が呼んでいるものをすでに実行している。彼らのあいだでは、自分のノートブックで新しい関数に関するいくつかの「健全性チェック」を素早く実行するのが一般的なようだ。つまり、いくつかの簡単なテストケースを通過させて、その関数が期待通りに動作することを確認している。

ソフトウェアエンジニアはこのプロセスをユニットテストと呼んでいる。

データサイエンティストとソフトウェアエンジニアのテストにおける唯一の違いは、前者はテンポラリーテストを削除して次に進んでしまうことだ。テストを削除する代わりに、それを保存し、コードがプッシュされる前に必ずテストを実行して、何も壊れていないことを確認する必要がある。

Pythonを使ってテストを始めるにあたっては、私はpytestを使っている。pytestを使えば、簡単にテストを作成し、それらを一度に実行して合格を確認できる。簡単な方法は、「tests 」というディレクトリを作り、そのディレクトリ内に “test “で始まるPythonファイルを置くのだ。例えば、以下のような「test_addition.py 」を使える。

# content of test_addition.py
def add(x, y):
return x + y

def test_add():
assert add(3, 2) == 5

(※訳註5)上記のPythonファイルでは、任意の2値の和を返すadd(x, y)が定義された後に、add関数をテストするtest_add()も定義されている。test_add()の実行内容は、add(x, y)のxに3、yに2を代入すると、5に等しいことをassert文で確認している。
なお、assert文は任意の条件を満たさない場合にAssertionErrorを送出する。

一般的には、実際の関数を別のPythonファイルに記述し、それをテストモジュールにインポートするだろう。また、以上のようなPythonの追加コードをテストする必要はないだろうが、非常に単純な例を示したかった(ので例示した)。

これらのテストモジュールには、関数の「健全性チェック」をすべて保存できる。一般的には、通常なケースだけでなく、エッジケースや潜在的なエラーケースもテストするのが良い習慣とされている(※訳註6)。

原註:テストにはさまざまな種類がある。ユニットテストは、データサイエンティストがテストを始めるのに最適なものだと思われる。
(※訳註6)エッジケースとは、任意の単一のパラメータを極端な値に設定したテストケースのこと。例えば、ステレオスピーカーで音量を最大にして動かす場合が該当する。似たような概念にコーナーケースがある。コーナーケースもパラメータが極端な値の場合であるが、エッジケースとの違いは複数のパラメータが関係することにある。

コードレビューの実施

最後になるが、より良いコードを書くためにすべきことリストのトップは、コードレビューだ。

コードレビューとは、メインブランチにコードを提出する前に、自分が働いているドメインでコードを書くことに精通している別の人にコードをレビューしてもらうことである。このステップでは、ベストプラクティスが守られていることを確認し、うまくいけば悪いコードやバグを発見できる。

コードをレビューする人は、できればあなたと同じくらいコードを書ける人が望ましいのだが、あなたより経験が浅い人にコードをレビューしてもらうだけでも、非常に有益なことがある。

怠惰なのは人間の常で、コードにもその怠惰さが入り込んでしまうことがある。誰かが自分のコードをレビューしてくれると分かれば、良いコードを書くために時間をかける大きなきっかけにもなる。コードレビューは私が見つけた最善のコード改善方法でもある。経験豊富な同僚が自分のコードをレビューし、改善のためのヒントを与えてくれるのは、とても貴重なことなのだ。

あなたのコードをレビューする人が楽になるように、新しいコードの量を少なくするようにしよう。小規模で頻繁に行うコードレビューはうまく行く。時々しか行わない膨大な量のコードレビューは最悪だ。1,000行ものコードが送られてきてレビューさせられるのは、誰も望んでいない。このようなレビューでは、一度に多くのコードを理解するのに必要な時間を取れないため、フィードバックが悪くなる傾向がある。

(※訳註7)以上のツイート画像を翻訳すると、以下のようになる。

10行のコード(レビュー) = 10の問題点(を指摘)

500行のコード(レビュー) = 「良いように見える」

以上のツイートの真意は、10行のコードレビューではコードを詳細に精査できるので細かな問題点を指摘できるが、500行のそれではレビュアーがあまりコードレビューに労力を費やさなくなるため、コードを精査せずに「何となく良い」という粗雑な結果が返ってくる、ということにある。

コーディングのレベルアップ

この記事が、より良いコードの書き方を学ぶのに時間をかけるようにあなたを触発することを願っている。コーディングが上手くなるのは難しいことでは決してないのだが、上達するには時間と努力が必要なのだ。

以上の5つの提案に従えば、コードの品質が大きく向上するに違いない。

コーディングが上手くなれば、将来の自分や同僚に感謝されることだろう。

・・・

機械学習モデルの実装方法に関する私が監修している無料講座についてもチェックしてみてください。


原文
『Data Scientists, You Need to Know How to Code』

著者
Tyler Folkman

翻訳
吉本幸記(フリーライター、JDLA Deep Learning for GENERAL 2019 #1取得)

編集
おざけん

無料メールマガジン登録

週1回、注目のAIニュースやイベント情報を
編集部がピックアップしてお届けしています。

こちらの規約にご同意のうえチェックしてください。

規約に同意する

あなたにおすすめの記事

アリババDAMOアカデミー、2022年のテクノロジートレンド予測を発表

エクサウィザーズ、パーソルテクノロジースタッフのDX/AI人材の育成を共同で開始

河川水位をAIで予測。三信電気とMatrixFlowがAIを共同開発

日テレ、ドコモら3社がニュース記事自動要約サービスを開発、β版の提供開始

【製造業でも進むDX】先端技術や新素材を活用した社会課題の解決へ -三井化学DXオンラインイベントレポート

【無料から】AIやDXがテーマの講演依頼はこちら

あなたにおすすめの記事

アリババDAMOアカデミー、2022年のテクノロジートレンド予測を発表

エクサウィザーズ、パーソルテクノロジースタッフのDX/AI人材の育成を共同で開始

河川水位をAIで予測。三信電気とMatrixFlowがAIを共同開発

日テレ、ドコモら3社がニュース記事自動要約サービスを開発、β版の提供開始

【製造業でも進むDX】先端技術や新素材を活用した社会課題の解決へ -三井化学DXオンラインイベントレポート

【無料から】AIやDXがテーマの講演依頼はこちら