はじめに
データサイエンス領域のPoCを実施するときに、「検証だからコードはとりあえず動けばOK」という考え方で、ソースコードが汚い状態のまま放置されていたりしないでしょうか？
PoCの間はそれでいいのでしょうが、後にシステム化する際や、別の人に引き継ぐときに、引き継ぐ側の人が大変苦労します（私は実際に苦労しました）
そんな悲劇を防ぐために、データサイエンス領域のPoCでもGitHub Flowに沿って開発したほうがいいのではという記事です。
プロジェクトで起こっていた問題
私はこれまでにいくつかのPoCプロジェクトの引き継ぎ（引き継ぐ側）を経験しました。
そして、ほぼ全ての案件で次のことが起こっていました
- 複数の開発者がそれぞれの作業ディレクトリにコードを残していてどれが最終バージョンかわからない
- 手順書通りに動かしても、ソースコードが動かない
ということで、引き継ぎにはかなり苦労しました。
GitHubを導入していないのか！？と思われるかもしれないですが、導入しています。
導入しているのですが、開発途中のものをpushして終わっていたり、「GitHubにはAさんのディレクトリがpushされているが、一部Bさんが書いたコードを使わないといけない（BさんのコードはGitHubにはない）」みたいなことが起こっていました。
信じられないと思う方もいるでしょうが、エンジニアのバックグラウンドなしにデータサイエンティストになっていたりすると、こんなことはよくある話なのかなと思いました。
そこで、私が推奨している方法は、PoCでもGitHub Flowを使うことです。
これによって、上記の問題はある程度軽減されるのではないかと考えています。
GitHub Flowとは？
GitHubが推奨している開発フローです。
公式ガイドはこちらにあります
→https://guides.github.com/introduction/flow/
大まかに言うと、次の流れになります
- gitのブランチを切ってブランチ上で機能開発をする（ブランチは機能ごとに切る）
- 開発が終わったらPull Requestを送る
- 第三者がコードレビューを行う
- コードレビュー完了後にmasterブランチに変更をマージする
GitHub Flowを使うとなぜ問題が解決されるか
では、いまご紹介したGitHub Flowを使うとなぜ冒頭の問題が解決されるのでしょうか。
まず、1つめの課題
- 複数の開発者がそれぞれの作業ディレクトリにコードを残していてどれが最終バージョンかわからない
に対しては、GitHub Flowを適切に運用すれば各個人の変更内容は順次masterブランチに統合されていき、masterブランチが全員の変更が反映された最新バージョンになります。なので、引き継いだ人はGitHubにアップされているmasterブランチだけ確認すれば良いということになります。
また、2つめの課題
- 手順書通りに動かしても、ソースコードが動かない
については、GitHub Flowのコードレビューを途中で挟むプロセスで一定軽減できると考えます。
データサイエンス領域でよくある事例は、「自分の環境では動くが、環境設定や必要なファイル準備の手順が抜けていて他の人の環境では動かない」ということかと思います。
このような場合、コードレビュー時に動作確認しようとすると動かないので、その時点でコードを書いた人が修正することになります。
見落としもあるかとは思いますが、ある程度この課題は軽減できると思っています。
実際にGitHub Flowをプロジェクトで導入した結果
実際に私が携わるプロジェクトではGitHub Flowを導入してみました。
そうすると、引き継ぎ時の問題はほとんどなくなり、gitレポジトリをそのまま渡せばスムーズに動作確認が取れ、引き継ぎが完了するようになりました。
また、「コードレビューによって自分の書いたデータ処理、アルゴリズムが間違っていないと自信を持った上で次のタスクに進める」といった意見もあり、チームメンバーからも大変好評でした。
よくある質問
Q. Jupyter Notebook形式で開発しているのでgit管理には向かない
A. はじめはJupyter Notebook形式で実験的に開発していたとしても、ある程度内容が固まってきたら.py形式に変換してgit管理すればよいのではないかと思います。
参考として、もしVSCodeを使っているとしたら、.py形式のファイルをインタラクティブに実行する方法もあります。
→https://code.visualstudio.com/docs/python/jupyter-support-py
Q. レビューでは何を確認すればよいか
A. まずは動作確認をしたほうが良いと思います。動作確認はテストコードで担保すべきという意見もあるかとは思いますが、データサイエンス領域のPoC段階だとそのままシステム化するわけではないですし、実験的にコードも変わっていくので手動で確認してもいいかと思います。
そのうえで、コードの中身を確認し、データ処理やアルゴリズムに間違いがないかをチェックしていきます。
意外と、よく読むとソースコードが間違っていることはよくあります。（一見ちゃんと動いているので厄介です。これもデータサイエンス領域特有かもしれないです）
まとめ
以上、私が引き継ぎで感じた課題と、GitHub Flowで開発するとその課題が軽減されると考える理由を紹介しました。
同じ悩みを抱えている方がいらっしゃれば、ぜひ一度GitHub Flowを試していただきたいと思います。
また、もし別の解決策をご存知でしたら教えていただけると幸いです。