少し前になりますが、Preferred Networks（PFN）社が自社開発のディープラーニングフレームワーク「Chainer」のメジャーアップデートを終了して、Facebook主導の「PyTorch」にシフトすることが話題になりました。
【PFNがChainerの開発を終了しPyTorchへ移行、西川社長「非常に大きな決断」】
https://monoist.atmarkit.co.jp/mn/spv/1912/06/news052.html
PyTorch自体はちょくちょくニュース記事などで目にするものの、あまりちゃんと調べてこなかったので、今回取り上げてみたいと思います。
Web等で開発をしている人であれば、PyTorchはフレームワークというよりもライブラリというほうがしっくりくるかと思います。下記の記事にサンプルソースがありますが、機械学習を行う上でのメソッドが用意されてる感じですね。
【PyTorch 入門！人気急上昇中のPyTorchで知っておくべき6つの基礎知識】
https://www.codexa.net/pytorch-python/
機械学習系のライブラリというと、Googleが主導のTensorFlowが私的に最初に挙げられますが、最近はPyTorchの伸びがかなりあるそう。もちろん産業界ではTensorFlowがまだまだ主流みたいではありますが。
【PyTorch vs. TensorFlow、ディープラーニングフレームワークはどっちを使うべきか問題】
https://www.atmarkit.co.jp/ait/spv/1910/31/news028.html
実際にどんなことがライブラリを使ってできるか、下記の記事に紹介されています。物体の認識やGANによる画像の生成など、いろいろなことができそうですね。
【PyTorchでBERTなど各種DLモデルを作りながら学ぶ書籍を執筆しました】
https://qiita.com/sugulu/items/07253d12b1fc72e16aba
ソースコードのコメントについて今更ながら考えてみる
たびたびTwitterなどで話題になる、ソースコードのコメント。今回はこのコメントについて、取り上げてみたいと思います。
まず、コメントとは何かという点について一応。コメントとはソースコード中に書かれるメモのようなもので、それ自体は処理に影響を与えません。基本的には該当の処理が何をやってるのかというよりは、なぜそのロジックがあるのかとか設定値の注意事項などを、書くのが望ましいとされています。
【【プログラミング初心者】コメントを書くとき知っておきたいこと】
https://eng-entrance.com/commentout
こういうコメントはイケてないという、アンチプラクティスは下記の記事にまとめられています。私の前の現場は、改訂履歴がコメントで書かれてたり、コメント内容がソースでかあ書かれている処理と合ってなかったりして、ソースの可読性がイマイチでした。。
【コメントの9割は無駄！～アンチプラクティスから学ぶ洗練されたコメントの書き方～ #code #コード】
https://next.rikunabi.com/journal/20131216_t21_iq/
処理は極力コードで表現するのが望ましいと上記で書きましたが、他の人でも理解しやすいコードを書くのは中々難しく、変数名とかも工夫する必要もあります。そんなときは、なるべく下記の記事にある「意図」を意識したコメントを、適宜入れていくのも、有効かなと感じます。
【「正しく書かれたソースコードにコメントは必要ない」なんて幻想だという話】
https://t-tutiya.hatenablog.com/entry/20170519/1495197904
オフラインと広告
以前に本ブログでO2Oについて取り上げました。
https://toaruit.hatenablog.com/entry/2018/06/07/001811
オンラインからオフラインへ誘導する施策はまだまだこれかなという感じはしますが、オンラインがほぼレッドオーシャンになっているような状況を鑑みると、オフラインへ誘導していくのは悪くない取り組みと感じています。
広告に関してもオンライン広告から実際にコンバージョンに結び付くケースはWebに慣れている人程、少なる気はしています（そういう人は実際にWeb上で色々調べると思うので）。なのでオンライン広告はコンバージョン目的というよりは、認知のための手段にシフトしていくのではと、個人的に感じています。
他方、オフライン領域での広告はまだまだ進出の余地があると感じています。ここでいうオフラインは、雑誌や新聞などにある広告ではなく、下記のような例えば店舗において訴求が可能なものです。
【ジーニー、歯科医院のデジタルサイネージへプログラマティックOOH広告を配信可能に】
https://markezine.jp/article/detail/32340
オンラインでは自分で調べた上で、目的買いの購買の比率が高くなっていくだろうと思う一方で、オフラインは店舗にきてから決めるケースもあり、まだまだ広告の効果が見込めると考えています。下記の記事のようなカメラで来店者の行動を分析し、最適な商品をリコメンドするような仕組みも最近発表されて、今後より色々な技術が使われるのではないかと感じています。
【凸版印刷、来店者の行動に合わせ最適な広告をリアルタイムで配信】
https://prtimes.jp/main/html/rd/p/000000342.000033034.html
カスタマーエクスペリエンスマネジメント(CEM)とは何か
カスタマーエクスペリエンスやカスタマーエンゲージメント、という言葉はそこそこ認知されたようになってる気がします。この考え方自体は顧客との関係性を深めるためには重要なのですが、じゃあこれをどういうふうに管理するのか、という話が出てきます。ので、今回はカスタマーエクスペリエンスマネジメント(CEM)なるものについて、取り上げてみたいと思います。
管理をする上で、大事になるのは指標選定です。カスタマーエクスペリエンスで達成すべきことは顧客ロイヤリティで、これを計測するために下記の記事ではNPS(ネットプロモータースコア)やリピート率が挙げられています。そして、この指標をベースに顧客ロイヤリティをいかに高めていくかというのが、CEMでの取り組みになると考えられます。
【CRMからCEMへ広がる新たな世界。カスタマーエクスペリエンスマネジメントとは？】
https://www.cloudtimes.jp/dynamics365/blog/customer-experience-manegement.html
アンケート等で満足度を計るのも大事なのですが、数が集まらなかったり、質問項目を適切に設定するなど手間がかかってしまいます。下記の記事にあるような、ロイヤリティ顧客の行動等を分析するようなツールも出てきてて、こういうところから指標の選定をするのも良いかなと思います。
【オプト、ロイヤルカスタマーを育成するAIツール「Handy CEM」の概念実証を開始】
https://markezine.jp/article/detail/31969
指標選定を行った上で組織でどう取り組んでいくかというのが、下記の記事にまとめられています。「シームレス」というのがキーワードで、顧客が企業の提供するサービスをオンライン・オフライン問わず触れる機会がある中で、企業の組織がタテ割りになっている状態ではダメだろうということです。ここら辺はUXでのチーム作りと近い考え方かなと感じていて、顧客の体験を最大化するには一部門が集中して取り組むだけでなく、サービスに関わる人をチームとして取り組み、様々な視点から検討する必要があるべきことと感じます。
【カスタマーエクスペリエンス マネジメントを始めるには】
https://blog.sprinklr.com/ja/define-customer-experience-management/
課題解決とIT
ハンコを押すロボットが話題になっていますね。これは技術の無駄遣いではないかと、感じている人もいるかと思います。
そもそもITを使う目的として答えは人それぞれにあると思います。業務効率化のため、コミュニケーションの手段のため、はたまたゲームのためかもしれません。ただ、どのような分野であれITが果たす役割で、重要なのは「課題解決」だと私は思ってます。
作っても使われないシステムや機能、これらは課題解決に失敗した結果のものと思ってます。かくいう私も過去に使われない機能を、作ってしまったりしました。。適切な課題設定がされてない状態でプロジェクトを走らせること(とりあえずやってみようぜ的な感じ)は上手くいくか賭けになってしまうだろうし、プロジェクトをいかに上手くまわしたところで、そもそも走ってる方向が間違ってるので、使われないシステムが作られてしまうわけです。
以前にも本ブログで紹介した伊藤直也さんの記事ですが、マネジメント以外でも「問題にフォーカスする」ということは、やはり大事なことだと思います。
【伊藤直也氏が語る、マネジメントで本当に大事なのは「問題にフォーカスする」である理由】
https://getnews.jp/archives/1734166
下記の記事にもある通り、これだけITが浸透しているなか、エンジニアが作ったシステムで課題解決できるシーンは増えていると感じています。ただ、すごいシステムを作ることがエンジニアの役割だけではなく、「課題解決」のためにどのような手段が望ましいかを考えるというのも求められてきていると感じます。エンジニアも要求通りのシステムを作ることに加え、課題解決を行う経験を増やしていくことで、より必要とされる人材になるのではと思います。
【エンジニアは技術とコミュニティで社会課題を解決できる──及川卓也氏が考える「テクノロジーのこれから」】
https://www.si-ght.jp/entry/techandme-oikawa02
さて、ハンコを押すロボットが解決する課題は、ハンコを押すという作業の効率化になると思います。ただ、そもそも物理的にハンコを押すという行為にどれだけの意味があるか。
課題をもう一段掘り下げて考えないと、せっかく手間をかけて作ったものが価値のないものとなってしまう可能性があり、作り手となるエンジニア自身がきちんと意識すべきではないかと思います。
プロセスマイニングとは何か
以前にRPAの導入について取り上げました、
https://toaruit.hatenablog.com/entry/2019/07/07/021807
その中で、効率化するための業務の要件を整理すべきと書いた通り、業務のプロセスを明確化することは大事になってくると感じています。ので、今回はプロセスを明確にする手法「プロセスマイニング」について取り上げてみます。
プロセスマイニングとは、下記の記事にある通り、「企業で行われている様々な業務プロセスに関して記録される「イベントログデータ（トランザクションデータ）」を分析し、業務改善に活用する取り組み」になります。そして、ログデータの中から繰り返し発生するものや、価値を生み出さない業務を明確化していきます。
【プロセスマイニング 導入ガイド】
https://www.heartcore.co.jp/process-mining/guide/index.html
少し前にドイツのCelonisというプロセスマイニングのツールを開発してる会社が、日本に進出したというニュースがありました。Celonisについて下記の記事にまとめられていますが、ERP等の業務システムから業務のログを集めて、プロセスの可視化を行ってます。
【プロセスマイニングツール「Celonis」についてまとめてみた】
https://www.cresco.co.jp/blog/entry/7516/
有償でツールを導入するのもよいのですが、OSSを使ってログをまず収集してみるのも、よいかなと感じました。下記はGraylogというOSSなのですが、テキストデータやHTTP経由でもログデータのインプットができそうで、試しに使ってみるのも良いのかなと。
【統合ログ管理・監視のOSS〜Graylog〜 >ログ解析とログ収集】
https://www.designet.co.jp/ossinfo/graylog/analysis/
サポートの仕事について考えてみる
サービスやシステムの運用をする際に必要になってくるのが、問い合わせのサポート対応。私も前の会社でやっていたことがあるのですが、なかなかにタフさが求められてきます。今回はこのサポートについて、取り上げてみます。なお、以前に本ブログでカスタマーサクセスについて取り上げましたが、今回はそれを実現する前段階の問い合わせ対応の部分にフォーカスします。
https://toaruit.hatenablog.com/entry/2016/08/28/021953
サポートの仕事に求められるのは、ITやサービスの知識はもちろんのこと、いかに顧客の状況を把握するか、というのが大事になってきます。状況の認識のズレがあると、いくら知識を与えても解決まで導けないし、短い時間で認識を合わせるというのもかなり困難です。サポートの辛さは、下記の記事にも書かれていたりします。
【ここが辛いよカスタマーサポート業務】
https://www.itmedia.co.jp/enterprise/spv/1409/24/news045.html
問い合わせ対応を効率化させるために、色々なツールやサービスもありますが、まずは人間がちゃんと状況分析を行う必要があると考えています。下記の記事で紹介されている、「クネビンフレームワーク」を用いて、可視化してみるなどの手段が考えられるでしょう。
【クネビンフレームワークを使ったテクニカルサポートチームの行動指針の立案】
https://dev.classmethod.jp/etc/da-product-support-cynefin-framework/
状況分析の結果、自動化できそうな部分があるならFAQやチャットボットの導入も検討してみても良いと思います。FAQとチャットボットが連携できるツールなども、最近はあるようです。
【ユーザーローカル、チャットボットと連動しAIで自動最適化するFAQサイト構築ツールを提供開始】
https://markezine.jp/article/detail/32162
サポートの仕事をやってた中で私が感じたのは、全ての問い合わせを自動化するのは困難ということです。自動化できない複雑な問題に対応していくことが今後サポートの価値になってきて、カスタマーサクセスにもつながるものと感じています。システムやサービスの価値を上げるためにもサポートは重要な役割で、メンバーがより付加価値の高い業務にフォーカスしていくような環境を整えて上げることが大事かなと思います。
