初心者エンジニアが機械学習の研究開発をする中で思ったこと

はじめまして。SMARTチームエンジニアの鍋谷と申します!
こちらは弥生アドベントカレンダー2020の19日目の記事です。

はじめに

まずは簡単に自己紹介します。

  • 2019年4月 弥生に入社・・・開発ほぼ未経験で入社
  • 2019年6月 開発本部に配属・・・開発研修を受ける
  • 2019年11月 テスト自動化チームに配属・・・自動テストの開発・運用を行う
  • 2020年4月 SMARTチームに異動・・・機械学習の研究開発業務を行う

機械学習の研究開発業務を行ってきた中で、初心者エンジニアの私が感じた点を書きます!

機械学習の特徴と、研究開発の重要性

普通プログラムで何かの判断を行いたい!と思ったら、以下のような流れを考えます。 f:id:ym_AdventC:20201214192005j:plain しかし、ルールを事前にはっきりと形にできないものもありますよね。
そういう場合、仮に最初にルールを決めたとしても、誤って判断されてしまうことが大半でしょう。

機械学習は、「正しい入出力をペアとしたデータをもとに、判断ルールを自動で改善していく手法」です。1
つまり、判断をしてきた経験をもとに、どんどんとルールが改善されていくわけです。 このルール改善の過程を、「学習」と呼びます。

学習の結果どのようなルールができるかは、学習の際に用いるデータや、学習方法の設定などによって異なります。
そして、どのようなときにどのようなルールとなるかを、 一度も学習させずに予測することは難しいです。
つまり、「最終的にどれだけ成果が出るか」は、実際にモデルを動かしていかなければわかりません
これは普通のプログラムとは異なる、機械学習の大きな特徴です。

とはいえ、どれだけ成果が出るのか全くわからない状態では、会社としてプロジェクトに大きく投資することは難しいでしょう。
だからこそ、実運用するプログラムを作る前に、研究開発でモデルを動かし試行錯誤することが、機械学習のプロジェクトでは特に重要であると考えます。
実運用の状況を想定して研究開発ができていれば、その知見を活かして成果をある程度予測できるでしょう。
これが、私の考える研究開発の重要性です。

研究開発をするために大事なこと

「何を実現したいか」を明確にする

これは機械学習以外のプロジェクトについてもいえることですが、 特に機械学習の研究開発をする上で、「何を実現したいか」を明確にすることは非常に大事だと感じました。 理由は以下です。

「何を実現したいか」で用いる手法が変わる

一口に「機械学習」といっても、古今東西いろいろな手法があります。 そしてこれらの手法はそれぞれに特徴があります。
実現において何を重視するのかがわかっていないと、最適な手法を選ぶことができません。

たとえば、単純な線形回帰でそれなりの正解率が出る問題について、それなりに正解率が高ければいい、運用コストは抑えたいという場合を考えます。
この場合に、非線形なディープニューラルネットワークをGPU環境で学習してモデルを作成する......といった手法を選択するのは、オーバースペックで高コストとなってしまいますよね。

このように、「何を実現したいか」を把握してタスクの性質を捉えたうえで、技術を選定することが大事です。

「何を実現したいか」で評価指標が変わる

機械学習の研究開発では、複数のモデルを用意して性能を比較していきます。
このとき、単純に「正解率」をモデルの評価指標とすればいいかというと、必ずしもそうではありません。

単純な二値分類について、予測結果と実際の分類結果をある区分に属するかどうかで整理すると、以下の図のようになります。 f:id:ym_AdventC:20201215194521j:plain この図において、評価指標は以下のようにいろいろあります。

  • 正解率・・・すべての判定に対する真陽性と真陰性の割合
  • 再現率・・・実際の陽性のうち真陽性として検出できたものの割合
  • 適合率・・・陽性と判定したもののうち真陽性だったものの割合

そして、最適な評価指標は場合によって異なります。

たとえば「コロナウイルスの感染者かどうかを一時予測したい」「陽性の可能性が少しでもある人を逃したくない」という場合であれば、 評価指標として「再現率」を重視します。

一方で、「会計システムで勘定科目を予測したい」「ただ、誤った勘定科目には分類したくない」という場合であれば、評価指標として「適合率」を重視します。

このように、ものによって最適な評価の指標は変わります。2
だからこそ、「何を実現したいか」を明確にし、どのような指標で判断すべきなのかを考えなければなりません。

技術動向に常にアンテナを張っておく

機械学習分野は最近ホットな話題ということもあり、非常に研究成果のアップデートが早いです。
技術選定をした2年後にもっといい技術が出た...ということも多々あります。
このため、最新の技術動向がどうなっているかを追っていないと、そのときに最適な手法の選択ができません。

弥生では定期的に大学の先生とディスカッションや機械学習に関する勉強会への参加など、 このような技術動向を知る機会をいただいています。これはかなり恵まれていますし、勉強のモチベーションも上がります。

機械学習以外についても知る

運用に乗せるための研究開発をする中では、「機械学習以外の知識」も必要です。

たとえば、モデルの性能比較においては、測定誤差を踏まえて考察を行うなど、統計の知識を持って取り組む必要があります。
また、運用環境の検討では、メモリやCPUなどのリソースの使用状況を監視することが状況改善の考察につながります。
さらに、クラウド上で動かすということであれば、クラウドコンピューティングの知識も必要となります。
機械学習を実際に動かすシステムの全体像がどのようになっているかを知っておくことも、いわずもがな重要です。

このように、「機械学習の研究開発」をするといっても、実際の運用を考えるためには機械学習以外の知識が必要です。
機械学習の知識とエンジニアとしての知識の両方をもっと勉強して、頑張っていきたいです。

さいごに

研究開発は新しく覚えることも考えることも多く、大変刺激的で楽しい業務です。
興味を持っていただけるかたは、採用ページを是非ご覧ください......! www.yayoi-kk.co.jp


  1. 厳密に言えばこれは機械学習の中でも教師あり学習の定義です。

  2. 余談ですが、再現率と適合率のどちらも同じくらい重要という場合は、これらの調和平均をとったF値という指標がよく用いられます。

PowerBIよもやま話

この記事は 弥生 Advent Calendar 2020 の17日目の記事です。

弥生の川本です。開発本部でQAを担当しています。
皆さん、QAってご存知でしょうか。
一般的には、Quality Assurance=品質保証と呼ばれることが多いですね。 会社によっては品質管理と呼んでいたり、業務内容がテストだけにフォーカスされていたり、定義にバラつきがある印象です。
と言うより、「Quality Management」「Quality Control」「Quality Assurance」がごちゃ混ぜになっているのかな。 特に「Quality Management」「Quality Control」をどちらも日本語で「品質管理」と訳してしまうのが混乱の元のように思います。
弥生のQAがどのような活動をしているかと言うと、「品質監査(Quality Audit)」はもちろん、「プロセス・指標の策定」や「プロセスの啓もう」なども行っています✨
なので一般的な定義に照らし合わせると、「Quality Assurance」+「PMO (Project Management Office)」という定義が近しいのかなと思います。

さて、ここまで書いておきながら、今回のテーマは「QA」ではありません笑
タイトルの通り、今回のテーマはMicrosoftが提供しているBIツールであるPowerBIについて、雑多に書き連ねます。

BIツール(BIシステム、ビジネス・インテリジェンス・ツール、英語: Business Intelligence tools)とは、企業の基幹システムで生成されたデータを、ユーザ自身が抽出・加工するためのアプリケーションソフトウェアである。加工したデータは企業の意思決定に利用される
出典:BIツール - Wikipedia

ノンプログラミングで集計できる!

PowerBIには「コネクタ」と呼ばれる機能が搭載されています。これは文字通り、PowerBIと各種データをコネクト(接続)するための機能です。 これまでExcelファイルでVBAマクロ等を駆使してデータ集計してきた方ならイメージしやすいと思うのですが、Excel集計の何が大変かって、まず集計対象のファイル種別やフォーマットにあわせてカスタマイズすることが大変だったと思うのです。
ファイル種別はTxtだったりCSVだったりXmlだったりExcelだったり様々ですよね。さらに同じファイル種別でもデータ構造が異なっていて、集計対象にあわせてカスタマイズする経験をした方も多いのではないでしょうか。
PowerBIのコネクタは、その悩みを(概ね)解消してくれます👍

今のところ私が主に使っているのは以下の7種類だけですが、基本的にPowerBIのUIに沿ってポチポチするだけでデータを取得することができます。正直めっちゃ楽ちん!

  • Excel
  • CSV
  • Json
  • Odata
  • MySQL データベース
  • フォルダー
  • Web

ちなみに2020年12月現在、PowerBIが対応するコネクタは実に143種類もあります。
Power BI Desktop のデータ ソース - Power BI | Microsoft Docs

プログラミングできるとより捗る!

ノンプログラミングでも使えるとは言え、やっぱり簡単なプログラミングの知識はあった方が良いなと思います。 データの取得自体はお手軽に実現してくれるのですが、欲しいデータ構造で取得できなかったり、大量データの取得に失敗したり等の課題にぶつかり、私も試行錯誤する日々です。

タイムアウトでデータを取得できない!

少し前に私がつまづいた部分についてお話をします。
背景として、弥生はチケット駆動開発のプロセスがあり、チケットのデータを取得しようとしていました。 チケットはWebブラウザからアクセス可能なので、試しにWebのコネクタでチケットのURLを指定したところ難なく取得できました。
しかし該当のプロジェクトの全チケットを取得しようとすると、何回やってもタイムアウト。。。
オプション設定からタイムアウト時間を延長してもタイムアウト。。。

PowerBIの機能だけでは打つ手がなさそうだったので、そもそもチケット件数が多すぎるからWebクエリーではデータ取得できないんだと仮説を立てました。
つまり、1回に取得するデータサイズを減らして複数回に分ければいけるのでは?というExcelマクロ的な発想です。

関数化してぐるぐる回す!

ここからは実際にPowerBIでどういう操作をしたのかをお見せしたいと思います。 品質データは公開できないので、サンプルとして弥生コーポレートブログを読み込む処理を関数化してみました。

①Webコネクタでデータを取得

  • ホームメニューの「データを取得」をクリック f:id:ym_AdventC:20201211162853p:plain:w600
  • 「Web」をクリック f:id:ym_AdventC:20201211163134p:plain:w600
  • 取得対象のURLを指定 f:id:ym_AdventC:20201211163138p:plain:w600
  • 取得したいデータ構造のテーブルを選択 f:id:ym_AdventC:20201211163141p:plain:w600

    ②webコネクタで自動生成された処理に、「PageNo」の引数を追加して関数化(詳細エディターを直接編集)

  • ホームメニューの「データの変換」をクリック f:id:ym_AdventC:20201211163818p:plain:w600
  • 詳細エディターから直接編集 f:id:ym_AdventC:20201211163821p:plain:w600
  • 以下の内容を追記 f:id:ym_AdventC:20201211163824p:plain:w600

    ③引数PageNoとして1~30までのリストを渡して、ブログの1ページ目から順番に読込

  • 列の追加メニューの「カスタム関数の呼び出し」をクリック f:id:ym_AdventC:20201211164815p:plain:w600
  • ②の関数を指定し、引数PageNoとして1~30の数字が入力された列を指定 f:id:ym_AdventC:20201211164819p:plain:w600
  • カスタム関数のテーブルを展開 f:id:ym_AdventC:20201211164831p:plain:w600
  • 全データの取得が完了 f:id:ym_AdventC:20201211164834p:plain:w600

いかがでしょうか?関数化と書きましたが、ただ引数を追加するだけで実現します笑
あと、重要なポイントがもう一つあります。

Web.Contents("URL", [RelativePath=""])

この記述です。今回実現したのは「動的データソース」と呼ばれる仕組みです。動的データソースには厄介な以下の制約があるのですが、この記述であれば制約に引っ掛からずに更新スケジュール機能(自動更新機能)を使用することが可能です。

ほとんどの場合、動的データ ソースを使用する Power BI データセットを Power BI サービスで更新することはできません。
Power BI でのデータの更新 - Power BI | Microsoft Docs

実のところ一番つまづいたのはこの部分で、単純に関数化しただけだと自動更新が使用できなくなるので悩まされました😅 この内容が同じような課題で困っている方の参考になれば幸いです。

これからのPowerBIとExcel

つい先日、Microsoftのブログに以下の記事が投稿されました。 www.microsoft.com

要約すると、PowerBIとExcelの連携を更に強化していくとのこと。Excel⇒PowerBIの一方通行の連携から、今後はExcel⇔PowerBIの双方向の連携がしやすくなるということかと思います。 PowerBIはデータの取得、可視化という点では非常に使い勝手が良いのですが、分析という点だとやはりExcelの柔軟性に一日の長があるということでしょう。

弥生もPowerBIの導入を最近始めたばかりで、今はまだ既存のものを置き換えるために試行錯誤している段階です。将来的にはもっとたくさんのデータを集約して、それらのデータ活用から新しい価値を提供できたら良いなと思います。私個人としてもこれからのアップデートがとても楽しみです!

業務運用の自動化、すすんでますか?

この記事は、弥生 Advent Calendar 2020 の16日目の記事です。

こんにちは。新課金チームのいっしーです。

急に寒くなりましたね。
エアコン、加湿器、電気ひざ掛けを駆使しているので、電気代がすごいです。*1

さて、今回は業務運用の自動化について書きます。

さかのぼること1年前

情シスについて、こんなことを書いていました。

  • いろいろな部署やシステムのハブといっても過言ではない部署
  • 結構、開発もできる
  • 社内業務の効率化を継続して提案・実現していければ、最強の弥生を作り上げられるのでは

_人人人人人人人人人人人人人人人人人人人人人人人人人人_
> 社内業務の効率化を継続して提案・実現していければ、<
> 最強の弥生を作り上げられるのでは         <
 ̄YYYYYYYYYYYYYYYYYYYYYYYYYY ̄

はい。

せっかくなので最強の弥生をつくっていきましょう。

まずは、新課金システムまわりの業務運用を自動化することになりました。

新課金システムとは?

新課金システムは、クラウドサービスの契約管理や請求管理を行っているシステムです。お客さまはプランを契約したり、支払方法を登録したり、毎月の請求金額を確認することができます。その裏では定期バッチにより契約更新や請求書発行、自動決済がおこなわれるようなそんなシステムです。

f:id:ym_AdventC:20201215120157p:plain
契約一覧画面

つまり、お金に絡む問い合わせや対応依頼が日々くるわけです。
その最たるものが銀振入金消込……!

銀振入金消込とは?

銀行振込をおこなうことにより、請求している金額を消し込む作業のことです。
弥生の売上などの経理業務に関わるため、欠かせない作業です。

自動決済されるんじゃないの?と思った方は鋭いですね。
弥生では、クラウドサービスの支払方法は基本的にクレジットカードか口座振替です。ただ、自動決済に一定回数失敗するとサービスが利用制限状態になり、以降の決済は自動では行われません。サービスが利用できないことに気づいたお客さまが支払いを済ませるための最後の手段、といったところです。*2

現状の運用と課題

以下が現状の運用を図にしたものです。

f:id:ym_AdventC:20201215174121p:plain

ふーん…?

……

………手作業多くない?

課題その1:手作業が多い

そうなのです。入金情報と請求情報の突合も、実際の消込作業(データメンテナンス)も、現状すべて手作業なのです。一般的に、請求書の数が増えれば増えるほど入金消込の対応は煩雑になるといわれています。また、手作業が多いということは、いくら気をつけていてもミスが発生しやすくなります。

会計ソフトを提供している会社としてはお金まわりのミスは信頼を失うことに繋がってしまうため、なんとしても避けたいところです。

課題その2:依頼頻度が高く、1回の件数も多い

現状、1~15件程度の消込依頼が毎日あります。繁忙期明けの4~5月になると、契約更新ラッシュ(とその決済失敗)により1日に30件近くになることもあります。そして、「原則、入金確認した翌営業日中には利用制限状態を解除する」とアナウンスしているため、がんばって対応するしかありません。

ユーザー数も年々増えており、再来年には旧システムからのデータ移行も控えているため、はやいところ自動化する必要がありました。

業務運用を自動化するときに大切にしたこと

全体最適をめざす

せっかく自動化しても、開発本部だけが楽になってカスタマーセンターの運用担当者がつらいままにはしたくないですよね。

そのため、まずは各部署でおこなっている業務の洗い出しを行いました。
また、現状の運用の中で目的がよくわからない作業などは今回を機に見直しをかけました。例えば、これまでは契約更新の請求書では請求月と入金月が異なる場合はデータのメンテナンス方法を変えていたのですが、請求月と入金月が同じ場合と同様のメンテナンス方法に統一する予定です。また、システム化しやすいように入金明細リストの記入方法をすこし変更してもらうことも提案しました。CRMにもこれまで確認できなかった情報を確認できるようにしてもらう予定です。

いろいろな部署やチームに協力いただけているので、本当にありがたいです。

繁忙期を避けた改善計画をたてる

弥生のカスタマーセンターは確定申告期間の2~3月が最繁忙期となります。ただでさえ忙しいその時期に運用フローの変更を行うと、お客さま対応に影響が出てしまいます。とはいえ、繁忙期までに改善できるところはしておきたいので、3段階に分けてリリースをすることにしました。

f:id:ym_AdventC:20201215174144p:plain
第一段階

第一段階はひとまずチケット起票をなくし、開発本部側の自動化をします。
繁忙期がおわったらカスタマーセンター側の運用フロー変更も含めて、改善していく予定です。最終的にはバーチャル口座をつかって、入金情報と請求書の突合も不要になる予定です。

まとめ

銀振入金消込の自動化について書きました。文中でところどころ過去形で書いてますが、ようやく要件定義や計画がおわり絶賛設計中です(笑)実を言うと、ほかにも重要度の高い依頼がいくつかあります。改善しがいがありますね!

わたしたちと一緒に改善していってくれる人を募集しています。 www.yayoi-kk.co.jp

明日は、弥生品質の守り人、QAチームの川本さんです。

*1:弥生では毎月リモートワーク手当がでるのであんしん!

*2:支払方法を新規のカードに切り替えることでも即時決済は行われます。ただ、なんらかの理由でカードを登録できないというお客さまには銀振入金を案内しています。