研究室が研究を基に OSS を開発、公開するときに気をつけるポイントをまとめました。

1. 研究を基にした
オープンソース開発
チェックポイント
株式会社リクルートテクノロジーズ
伊藤 敬彦
1

2. 自己紹介
名前：伊藤敬彦
Twitter アカウント: takahi_i
所属：株式会社リクルートテ
クノロジーズ ATL
専門分野：データマイニング、
グラフ、検索
2

3. 略歴
要約：研究から開発に流れてきた（どっちつかず）
研究（マイニング） いろいろ開発現職
KDD、PKDD Hadoop
ツール群の開発
検索プラットフォーム
3
自動文書校正ツール
デプロイパイプライン

4. 最近関わっている OSS
RedPen
自動文書校正
ツール
URL: http://
redpen.cc
4
Walter
デプロイメント
パイプライン
URL: https://
github.com/
walter-cd

5. 本日のトピック
アカデミックの人が研究成果をオープンソースとし
て開するときに気をつけること解説
5

6. トピックを選択した理由
研究室は論文を執筆する。
研究成果を基にコードを公開することで様々なメ
リットが享受できる。
6

7. 研究室でオープンソースを行
うメリット
研究室の先進性をアピール
共同研究
研究資金
学生獲得
社会還元の手段
論文だけでは中々成果を利用してもらえない。
7

8. 学生がオープンソースを行う
メリット
就職活動
ちゃんとしたコードを書けることをアピール
8

9. 内容
オープンソースの基礎知識
気をつけるポイント
多くの影響をあたえるためのポイント
9

10. 内容
オープンソースの基礎知識
気をつけるポイント
多くの影響をあたえるためのポイント
10

11. オープンソース？
プログラムのソースコー
ドをおいておくこと
現在，多くのソフトウェ
アがオープンソースプロ
ジェクトとして公開され
ている
11

12. 研究分野でも
最新の研究を搭載したツールがオープ
ンソースとして公開されている
深層学習
分散フレームワーク
音声認識
等
12

13. 事例：Apache Spark
UC Berkely の AMPLab で研究プロ
ジェクトとして開始
研究論文：https://
spark.apache.org/research.html
Apache のトッププロジェクトとして
登録される。
BigData界のキープレーヤにサポート
された。
13

14. 事例：Hivemall
産総研の油井さんが開発されている分散機械学習ラ
イブラリ
リポジトリ：https://github.com/myui/hivemall
米 Tresure Data 社のサービスでサポート
http://docs.treasuredata.com/articles/
releasenote-20140617#backend-hivemall-library-
v02
14

15. どこで公開する？
バージョン管理システムを設置して運用するのはコストが大
きい
ホスティングサービスを利用すると便利
メジャーなサービス
GitHub
Google Code
Bitbucket
15

16. 公開前に
やはりバージョン管理システムについて最低限の
理解が必要
バージョン管理システムでは三つがメジャー
Git
Subversion
Mercurial
16

17. しかし、ただ研究の際に利用したスクリプト群を
置いておけばよいわけではない。。。
17

18. 内容
オープンソースの基礎知識
気をつけるポイント
多くの影響をあたえるためのポイント
18

19. オープンソース公開前に
研究成果のツールがあった場合，そのまま出すと
理解されない
使ってもらうところまでいかない
使ってもらうには品質を持つことを示さないといけな
い。
論文も重要な国際会議で採録されるのには品質が必要
なのと同じ。
19

20. 論文の品質
研究論文は品質が充分でないと採録されない
論文の品質とは
革新性
論理展開
フォーマット、スタイル
比較検討(サーベイ)
実験の網羅性
20
以外に重要

21. OSSの品質
OSSも品質が充分でないとインパクトが与えられない
革新性
有用性
コードの品質
使いやすさ
導入しやすさ（わかりやすさ）
21
今日のトピック

22. 研究と技術的負債
所感：最新の研究の成果はそもそも技術的負債が
たまりやすい
参考（技術的負債）：http://qiita.com/
erukiti/items/9cc7850250268582dde7
理解できる人が限られる➔コードを移譲してチー
ムでメインテナンスという流れが起こりにくい。
22

23. 研究と技術的負債
研究系のシステムは他の人がついてこれるコード、
システムになっているか常に意識する必要がある。
意識しないと、
開発が進まなくなり、残骸プロジェクト（メイン
テナンスされなくたったコード）になる。
品質向上が進まず、実際のサービスに入れる（運
用する）のが難しくなる。
23

24. オープンソースを公開する前
にやるべきこと: 入門編
テストをつけよう
パッケージングしよう
静的コード解析ツールをつかおう
CI を回そう
ドキュメントを書こう
ライセンスを書こう
24

25. オープンソースを公開する前
にやるべきこと: 入門編
テストをつけよう
パッケージングしよう
静的コード解析ツールをつかおう
CI を回そう
ドキュメントを書こう
ライセンスを書こう
25

26. テスト
プログラムが期待した振る舞いをしているかを検
証する関数群
各言語毎にテストツールが存在する
JUnit (Java)、RSpec (Ruby)、gTest(C++)
etc..
26

27. 例：足し算のテスト
int add(int a, int b) {
return a+b;
}
int testAdd(int a, int b) {
27
assertEquals(2, add(1,1))
}

28. テストのメリット
早期のバグ発見
変更した際に間違い（バグ）を混入させるとエ
ラーが起こる
新しい開発者への支援
新しく開発者がプロジェクトに参加した時にテ
ストから，各コンポーネントの振る舞いを学習
できる
28

29. テストがないと
様々なデメリットを被る
例：利用方法を理解するコストが増大する。
特に研究系のとんがったツールでは，バグなのか仕様なのか
判断が難しい。
➔ 理解が進まないので共同開発者が育たない
➔ 生産性の低下
コードを改変した際に、バグを埋め込む可能性が上がる。
29

30. 勉強：テスト
本を読む
テスト駆動開発入門
GitHub 等で管理されているツールのテストを参
考にする
RedPenのテスト: http://bit.ly/1yzbIDs
30

31. オープンソースを公開する前
にやるべきこと: 入門編
テストをつけよう
パッケージングしよう
静的コード解析ツールをつかおう
CI を回そう
ドキュメントを書こう
ライセンスを書こう
31

32. パッケージを作る
プログラムを利用しやすくするためにビルドツー
ルを利用してパッケージングする
ビルドツール：ソースファイルからどのように成
果物を生成するかの手順を記述する
言語ごとに存在する：
C (Make, CMake, Autotools), Java (Maven),
Ruby (Gemfile) etc…
32

33. ビルドツールが無いと
どうやって成果物を生成するのかわからない（分
かりにくい）。
成果物を生成できる人が限られてしまう。
➔ ユーザ数が伸びない。。。
33

34. 勉強方法：パッケージング
本（各言語毎にパッケージングを扱う本がある）
ウェブ記事
GitHub 内のプロジェクトを参考に：
https://github.com/fluent/fluentd
34

35. オープンソースを公開する前
にやるべきこと: 入門編
テストをつけよう
パッケージングしよう
静的コード解析ツールをつかおう
CI を回そう
ドキュメントを書こう
ライセンスを書こう
35

36. ソースコードのフォーマット
フォーマットが変だと，プロジェクトの品質に疑
いを持たれる
フォーマット不良の例：
➔タブとスペースの混在
➔一行が長すぎる
➔変数名に統一感がない
36

37. フォーマットを整えるために
静的チェックツールを利用する
フォーマット異常や潜在的なバグを教えてくれ
る
言語毎に存在する
Java (CheckStyle), C(lint) etc…
37

38. 勉強方法：静的コード解析ツー
ル
本ではあまり扱われていない
Java Power Tools とか一部の本で触れられているが。。
ウェブ上の記事を参照(CheckStyle)：https://
sites.google.com/site/yasuda/maven/3-pomno
やはり。。。：既存のプロジェクトを参照
Hadoop: https://github.com/apache/hadoop-common/
blob/HADOOP-3628/build.xml
38

39. オープンソースを公開する前
にやるべきこと: 入門編
テストをつけよう
パッケージングしよう
CI を回そう
静的コード解析ツールをつかおう
ドキュメントを書こう
ライセンスを書こう
39

40. CI?
Continuous Integration (継続的インテグレージョン)
の略
Jenkins が有名
CI がやってくれること：
Git や Subversion 等のソースレポジトリにコードを
コミットすると，定められた処理を実行する
一般的な利用：テストを実行
40

41. CI のメリット
テスト自動実行してくれるので，バグが起こった
ことがわかる
クリーンな環境で実行してくれる（ものもある）
ので，ローカルでは発現しないバグを発見できる
バグは早めに潰さないと，後になるほど修正にコ
ストがかかる
所感：何度も助けられました ＞＜
41

42. CIを導入する
Jenkins は運用を研究室内でやらないといけな
いため、研究室で稼働させるには敷居が高い
おすすめ：CI サービスを利用する
➔ Travis、Wercker など CI を手軽に利用でき
るサービスがある．
42

43. 勉強する：CI
概念について：
➔継続的インテグレーション入門
CIの使われ方：
➔実際のプロジェクトを参照する。
➔ウェブ記事を参照：http://
shoma2da.hatenablog.com/entry/
2014/02/02/200546
43

44. 例：CI サービスの利用
RedPenより
https://travis-ci.org/recruit-tech/redpen
44

45. Travisの設定
単純なテストなら非常に
簡単
プロジェクトトップに設
定ファイル
（.travis.yml）を追加
設定ファイルでは対象言
語を指定する
45
例：Ruby
language: ruby
rvm:
- 2.1.0

46. オープンソースを公開する前
にやるべきこと: 入門編
テストをつけよう
パッケージングしよう
静的コード解析ツールをつかおう
CI を回そう
ドキュメントを書こう
ライセンスを書こう
46

47. ドキュメントを書こう
ツールを利用する敷居をさげるためにドキュメントは必
ず書く．
ドキュメントには種類がある
クィックスタート：簡単なタスクを用意してユーザに
実行してもらう
マニュアル：詳細な利用法を記述する
FAQ: よくある間違いに対する解答を載せる
47
特に重要と思う

48. クィックスタート
自分のツールが簡単に利用できるかはクィックス
タートを書いてみるとわかる．
もしクィックスタートで実行する必要なステップ
が多い
➔ソフトウェアが手軽に利用できないおそれが
ある
48

49. 例：クィックスタート
Hadoop:
http://hadoop.apache.org/docs/r0.19.0/
quickstart.html
RPMで簡単にインストール
起動も２、3ステップ
49

50. クィックスタートの利益
ソフトウェアのインストールや起動までのステップが短いと、
ユーザ獲得以外にも利益がある。
利益：
問題の再現
バグが報告された時に、簡単に問題を手元で再現できる
ステップが短いことで他のソフトウェアへの組み込みが容
易
50

51. オープンソースを公開する前
にやるべきこと: 入門編
テストをつけよう
パッケージングしよう
静的コード解析ツールをつかおう
CI を回そう
ドキュメントを書こう
ライセンスを書こう
51

52. ライセンスが明記していない
と
公開されてても使っても良いのかわからない。
ライセンスには色々ある（GPL, BSD, Apache
2.0 etc）。
各自調査したのち自分の用途にあうものを選択す
る。
参考記事：http://www.slideshare.net/
YutakaKachi/ss-8616029
52

53. ではちょっと先の話を
以下もう一歩踏み込んだトピックについて話しま
す。
いきなり全部取り入れるのは難しい、話半分で。
53

54. オープンソースを公開する前
にやるべきこと: 中級編
Pull Request ベースの開発
リファクタリング
設計の勉強
54

55. オープンソースを公開する前
にやるべきこと: 中級編
Pull Request ベースの開発
リファクタリング
設計の勉強
55

56. Pull Request
複数人でひとつのソフトウェアを開発する際に、
開発者のローカルのリポジトリでPushした変更
や機能追加を、ほかの開発者のリポジトリやブラ
ンチに取り込んでもらうためのリクエストを出す
機能のこと。
コードブレイクより
56

57. Pull Request の流れ
1. レポジトリをフォークする
2. ブランチを作成する
3. 機能の実装をする（テストも追加）
4. コミットする
5. 取り込んでもらうように要求（Pull Request）する
6. マージしてもらう
57

58. Pull Request の何が嬉しい
か
レビューを徹底できる
➔結果コードに関する理解が共有される。
特に研究室の場合
開発に割ける時間が限られている。
複数の人がわかっていないとすぐにコードがメンテナン
スできなくなる。
レビューをすることでコードを理解できる人を増やそう。
58

59. 例：Pull Request
Apache Spark(SPARK-4611)より
トピック：ベクトルのノルム計算の高速化について
https://github.com/apache/spark/pull/3462
ポイント：
コミット毎にテスト（Jenkins）が走っている。
コード部分について、マージ前に数多くの対話がなされて
いる。
59

60. オープンソースを公開する前
にやるべきこと: 中級編
Pull Request ベースの開発
リファクタリング
設計の勉強
60

61. リファクタリング
コンピュータプログラミングにおいて、プログラ
ムの外部から見た動作を変えずにソースコードの
内部構造を整理すること
Wikipedia より
ソフトウェアは書いていくとコードが複雑になる
➔定期的にコードをシンプルにする
61

62. コードをシンプルにしないま
ま開発が続くと。。。
コードが複雑になる（技術的負債の増大）。
結果プログラムの改変に大きなコストが必要になっ
てしまう。
保守できなくなったコードは最終的に放置される。
62

63. 関連書籍：リファクタリング
リファクタリング - プログラ
ムの体質改善テクニック
レガシーコード改善ガイド
63

64. 例：リファクタリング
RedPen でも多くのリファクタリングが行われている
ジェネリクスを廃止し、コードをシンプルにしたリファ
クタリング
https://github.com/recruit-tech/redpen/pull/
341
• 変更前：http://bit.ly/1vfpLgJ
• 変更後：http://bit.ly/1vEl9Ra
64

65. オープンソースを公開する前
にやるべきこと: 中級編
Pull Request ベースの開発
リファクタリング
設計の勉強
65

66. ソフトウェア設計技法
一部はデザインパターンと呼
ばれ、共通知識となっている
導入することで、コードの保
守性が向上する
注：私は教えらるほどわかっ
ていないので割愛＞＜
66

67. 内容
オープンソースの基礎知識
気をつけるポイント
多くの影響をあたえるためのポイント
67

68. 敷居を低く
基本：
専門家でなくても利用できるようにする
理想：
専門家でなくてもコードを変更できる
プラグイン化
研究に関する知識が必要な部分を一部コンポーネント
に集約する
68

69. 宣伝する
リリースしても、なにもしないと存在が知られな
い。
布教活動が必要
オープンソース系の勉強会
ブログ
を活用する
69

70. オープンソース系カンファレ
ンス
できれば広いトピックを扱うところで発表するのがのぞましい。
言語毎
GoCon (Go言語), JJUG CCC (Java), Ruby Kaigi (Ruby),
YAPC(Perl), PyCon (Python) etc
トピック毎
機械学習、OS、BigData etc
http://eventdots.jp/#26
70

71. サポートする
新規ユーザをサポートする仕組みを提供する。
メーリングリスト
http://blog.redpen.cc/
チャット（IRC）
Issue Tracker
新規ユーザが質問すると答えてくれる。
例： Apache Solr
http://lucene.apache.org/solr/resources.html
71

72. 依存を避ける
不用意に多数のツール、ライブラリに依存しない。
インストールや実際に動かすところまで出来る限
りスムーズにする。
依存がある場合には、RPM などを利用して簡単
にインストール出来る道を残す。
72

73. 最後に
今回述べたトピックは全部いっぺんに取り入れる必要は
ない。
ソフトウェア開発の勉強は研究室内だけで行うのは難し
い。
企業の長期インターンに参加、もしくはアルバイトで
勉強できる。
技官としてソフトウェアエンジニアを雇うのも一つのア
イデアかと。
73

74. とはいえ
基礎研究を集中してできるのは学生の間だけ。
OSS を頑張るのも素晴らしいが、まずは研究論
文で大きな業績を狙ってほしい。
74