Published on

機械学習システムの​ための​Joel Test​（または​現状の​確認）

Naver の Lucy Park 氏による ACML-AIMLP Workshop での 発表 "My model has higher BLEU, can I ship it? The Joel Test for machine learning systems" をざっと読んだときの感想．

Joel Test: ソフトウェア開発チーム・プロジェクトの質の評価

Joel Test (Joel on Software 日本語版) は，ソフトウェア開発チームの質を評価する，「12 個の Yes/No で答えられる質問リスト」のこと．色々便利に使おうとする例や，これ自体が時代遅れだとする記事も出るぐらい時が流れたが，今回それらは関係ない．

  1. ソース管理システムを使っているか？
  2. １オペレーションでビルドを行えるか？
  3. 毎日ビルドを行うか？
  4. 障害票データベースを持っているか？
  5. 新しいコードを書くまえにバグを修正するか？
  6. 更新可能なスケジュール表を持っているか？
  7. 仕様書を持っているか？
  8. プログラマは静かな労働環境にあるか？
  9. 買える範囲で一番良い開発ツールを使っているか？
  10. テスト担当者はいるか？
  11. プログラマを採用するときにコードを書かせるか？
  12. 「廊下での使い勝手テスト」を行っているか？

こうやって問われるとちょっと自信をもって回答できない．少なくとも今いる環境では……． まぁ，そもそもソフトウェア開発メインかどうかすら怪しい，なんともふらふらした立場にいるので，ひとまず置いておく．

機械学習システムのための Joel Test

Naver の Lucy Park 氏による ACML-AIMLP Workshop での 発表 "My model has higher BLEU, can I ship it? The Joel Test for machine learning systems" をざっと読んだ．

機械翻訳システムの実運用を例に，Scully の一連の論文12 で示された「機械学習システムの技術的負債化」の問題に向き合うための方策を議論している．

タイトルの通り，キャッチーなわかりやすいスライドでよかった．（機械翻訳はあくまでこの事例での背景．別に BLEU でいいとかダメとかの話は中心ではない．例としては出てくるけど…．）

スライドでざっと挙げられている「機械学習システムのための Joel Test」はこんな感じ．

  1. Do you keep your data versioned as well as your code? （コードだけじゃなくてデータもバージョン管理してる？）
  2. Do you have an experiment database? （実験データベースはある？）
  3. Do you have specified evaluation metrics? （定まった評価尺度はある？）
  4. Do the evaluation datasets match the needs of your users? （ユーザーのニーズに適合した評価データはある？）
  5. Can you reproduce your experiments in one step? （実験は 1 ステップで再現できる？）
  6. Do you have up-to-date documents? （ドキュメントは常に最新？）
  7. Do you have the best computational resources money can buy? （お金で買える最高の計算機資源はもってる？）
  8. Do you have tools to test model training? （モデルの学習をテストするためのツールはある？）
  9. Do you have tools to interpret your models? （モデルを解釈するためのツールはある？）
  10. Can you easily replace a component of your algorithm? （簡単にどこかの部分を入れ替えられるつくりになってる？）
  11. Does your team have a clear vision? （チームには明確なビジョンがある？3）

うちのスコアは？

Joel on Software から引用すると，

１２点は完璧で，１１点は許せる範囲だ．だが，１０点以下だったら君は本当に深刻な問題を抱えていることになる．実際のところ，大半のソフトウェア開発組織は２点か３点の状態で仕事をしている．そして，彼らは本当に助けを必要としている．なぜなら，マイクロソフトのような会社は常に１２点の状態でいるのだから．

ML 版は 11 個しかないので，単純に 1 点下げて考えればいいのだろうか．

今の環境は インダストリィ 3.10.0 って感じの製造業にくっついているデータ分析部門みたいなやつなので，当然点数は悲しい感じになっている． 直近ではやっていくしかない:muscle: が，自分も企業自体も，それじゃつらいだけなので，なんとかしたい．

（あえて）こうしたものを後追いで導入するような環境に身を置いているのだから，先人の知恵を借りたい． そう思って，[Scully+2014, 2015]を一緒に読みましょう，といっても自分と同じような人しかそれに参加しなかった経緯がある． つらい経験をしないとわからないならまだしも，そこまでいかないと問題の存在すら見えないのであれば，他人の経験が無駄になってしまう． もしそうなら，自分はもう脱出するしかなくなる．

その前の確認として，このチェックリストは使えそうだな〜と思った．なんでそんなのが必要なの？と言われても，今ならまだ対話ができる余裕は互いにあるのだから．

Footnotes

  1. Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., … Young, M. (2014). Machine Learning : The High-Interest Credit Card of Technical Debt. In SE4ML: Software Engineering for Machine Learning (NIPS 2014 Workshop) (pp. 1–9). https://doi.org/10.1007/s13398-014-0173-7.2 ↩

  2. Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., … Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. In NIPS’15 Proceedings of the 28th International Conference on Neural Information Processing Systems. Retrieved from https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf ↩

  3. この文だけではビジョンがあるかどうかだが，この項目のスライドで "Keep in mind that a vision is USELESS if no one is aware about(原文ママ) it" とある． ↩