2018年10月30日『データサイエンティスト養成読本 ビジネス活用編』の発売を記念して，「⁠仕事ではじめる機械学習」の共著者としてもおなじみの中山心太氏（ところてん）に，データ分析業界に突如として現れたイキリデータサイエンティストのマスクド・アナライズ氏（マスクド）がデータ分析者の未来について聞きました。第1回は，データサイエンティストの育成や業務知識を持つことが必要かなどの話で大いに盛り上がりました。

SIerさんが持つ完成責任と機械学習システム

マスクド：機械学習や人工知能に関連する仕事をはじめたいと思っているSIerさんは多いと思います。ところが，これまでのSIerさんによるシステム構築と保守契約で稼ぐビジネスモデルから変化する部分も大きいですよね。そのあたりの違いについてお伺いします。

ところてん：機械学習について乱暴な言い方をすると，機械学習はプログラミングの仕事を置き換える作業なんです。機械学習が入ってくると，年に1回の仕様変更でお金を取っていたのが取れなくなってしまうというケースがあったりするんですね。

たとえば，行政文書は1年に1回フォーマットが微妙に変わりますということですと，追加開発費用などの名目でちゃんと売上がとれるわけです。機械学習によって，フォーマットの自動認識しましょうとかをやりはじめると，年に1回トレーニング（訓練）をやり直すだけになってしまいます。

しかし，一方でいまのSI企業の保守部門が年に1回のトレーニングの作業をできるのかという問題があります。いまSIerさんは二重苦にあると思うんですよ。機械学習によって追加の売上がとれなくなっていることと，その機械学習のシステムを保守できないということ。

このあたりが，SI企業に対してビジネスモデルの転換が要求されているところだと思います。

マスクド：原稿の中でSIerの契約のお話もされていますね。

ところてん：なぜSIerが重宝されており，みんなSIerに仕事を頼むかっていうと，SIerは何が何でも完成責任を果たすからですね。でも，人工知能システムというか機械学習を含んだシステムって，予測モデルの精度が上がらなくて，完成責任が果たせなくなる可能性があるんです。

やっぱり一番そこが怖いので，私は「たぶんこのデータからこういう結果が出ると思うんですけど，どれぐらいまでできるかわからないけどとりあえずやってみます」というくらいの，ザクっとした受け方が可能な案件しかとっていません。こういった契約の話は『人工知能システムを外注する前に読む本』（⁠坂本俊之, 2018,株式会社シーアンドアール研究所）でも同じ話をされていて，合わせて読むといいかもしれません。同書を引き合いに出して，じゃあどうするって話をいろいろSIerさんとしてたんですけど，どうするべきかという結論は出ませんでした。

マスクド・アナライズさんはどうですか？

マスクド：機械学習や人工知能システムの導入問い合せは増えていますし，契約の問題も敏感に感じています。必ず100％の精度が出る保障もできないので，やってみてダメだったらそれでおしまい，もう少し予算を追加して修正すればもう少し上がると思いますという契約しかできません。だからある程度余裕のある会社でなければ導入は無理ですしね。会社として大きな責任を負わない契約をするのは，我々も一緒です。

ところてん： 現在は，SIerさんだけで機械学習案件が完結するのが難しいので，SIerさんが持ってるキャッシュ余力でベンチャー等に外注して，そのリスクをSIerさんが負担している状態なんですね。仕様はベンチャーに聞かないとわからない，しかしリスクはSIerが負っているという状態は健全なのか？と考えています。

マスクド：明らかに今までのSI的な「システム作ります」とは違うんですよ。SIerさんもまだ認識不足かとは思いますけど。

ところてん：ただSIの企業の中でもR＆Dをやって，機械学習に取り組んでいる人もいます。その人たちは結構我々と同じような見解を持ってるんですけど，なかなか社内で発言力を高めていけてないと言っていますね。

マスクド：手っ取り早く儲けるなら従来の通りにシステムを作って定型に保守できれば良いのです。経営的にも短期的にはAIや機械学習の導入開発を切り替えるのは難しいと思います。大きい会社ならなおさらですし，しばらくはベンチャーやデータ分析を得意とする会社が併存するのではないでしょうか。

A/Bテストは人事フレームワーク？

マスクド：SIerさんが取り組むときに他に問題になることはありますか？

ところてん：業績評価制度が問題になると考えています。

開発部門の目線で考えてみましょう。データ分析部門から，自分たちの業績評価と関係しない仕事を依頼された場合，それをどう評価するかを考慮する必要がありますね。公正な評価をすればするほどデータ分析部門の依頼と付き合うと評価が下がるんですよ。本来の仕事ができてないという話になるんで。

どうしても新しい業務については評価しにくいですし，かといってデータ分析部門からデータ取得してくださいって言われたのでやりましたって言って，じゃあそれをどう業績評価するかってきわめて難しいんですよ。

マスクド：前例がないですもんね。

ところてん：データ分析部門からの依頼が単に雑用とみなされてしまうと，

「君は期首に掲げた目標に達成してないよね」 「いやいや僕はデータ分析の協力して結果的に売上何％上がりました」 「いやそれは彼らの成績だ，君の成績ではないでしょ」

とかなってしまうと上手く回りません。緩すぎても回らないですけど，厳密すぎる評価制度にデータ分析に関わる業務を組み合わせるとほんとに回らなくなりますね。

マスクド：人事制度を厳密にやっていくとネックになることがありますよね。データサイエンスというと，どうしても技術的なところに着目される方が多いんですけども，その組織の裏側の話，評価制度も含めて課題が残っていると感じます。

ところてん：システム的にうまく回す事例は結構あって，たとえばA/Bテストの基盤を早々に作ってしまうことです。施策の評価がA/Bテストの基盤の上で評価できるのと，何かトラブルがあったときに，A/Bテストシステムで切り戻しができるんですね。すると，他部署との連携を少なくして，機動力を上げることができます。

マスクド：ABテストと他部署との連携はちょっと繋がらないように聞こえるのですが，どういうことでしょうか?

ところてん：要するに隣の部署に断らないでシステムをデプロイできるかどうかが重要です。何かをデプロイするために，「⁠すいませんがこの機能入れてください」ってみんなに頭下げて回るのも大変ですよね。

A/Bテストの基盤があれば，全体の1％にデプロイして，効果を測定して安定稼働するかどうか，KPIが改善するかどうかを調べることができます。A/Bテストの結果が明確であれば，ABテスト比率を100％にして，全体にデプロイすることができます。逆にクラッシュが発生したり，A/Bテスト結果が悪かった場合，ABテスト比率を0％にして，システムを切り戻しすればそれはそれで問題にはなりません。

機械学習システムをうまく活用できている会社には，A/Bテストのフレームワークを会社の創初期から導入していて，なおかつそれをデータ分析グループが勝手にデプロイできる仕組みがあります。勝手にデプロイして落ちたらそこで切り戻しする。これはもう安定動作してるのでこれを100％デプロイしますって言ってマスタブランチにデータ分析系のブランチがマージされていくみたいな文化があると，きわめてうまく回ると思います。

そうするとさっきの人事評価の問題も回避できたりするので，A/Bテストは人事評価フレームワークと言えると思います。