こんにちは、伊藤忠テクノソリューションズ（以下、CTC）CDEC 事務局の瀬尾です。

　暑さ続きますが、朝晩はいくらか過ごしやすくなってきましたね。皆様、いかがお過ごしでしょうか。

　2019年8月6日、伊藤忠テクノソリューションズ（以下、CTC）は東京・五反田の Innovation Space DEJIMA において、『CDEC 2.0』を主催しました。

　5月に主催した「CDEC 1.0」が好評につき、ふたたび主催することになったCDEC。

　その名も「CDEC 2.0」・・・。

　今回は「AI・RPA x 人の共創～システム開発の現場で業務効率を高める方法と費用耐効果～」をテーマに、ご参加いただいた企業とCTC データセンターサービス基盤開発部 システム開発課 課長の横堀 雅人を交え、猛暑にも負けずと劣らない熱いディスカッションを行いました。本記事では、その模様を簡単にお伝えします。

▼ 目次
・ディスカッションテーマ
・ディスカッション

1. ディスカッションテーマ

　今回のテーマは「AI・RPA × 人の共創～システム開発の現場で業務効率を高める方法と費用耐効果～」としました。ディスカッションテーマとして本テーマを取り上げた理由は、国内企業のシステム開発の現場において、システム開発エンジニアの人手不足が深刻な状況であり、何らかの対策が急務であると思えたためです。経済産業省の推定によれば、当面はシステム開発エンジニアの受容と供給が開き続ける傾向にあるとの事です。

図 1. IT 人材需給に関する調査 
(出典 : 経済産業省｜調査報告書)

　この課題を解決する主な対策として、次の何れかが考えられます。

• 高いコストを掛けてSEを確保する
• 海外や地方の人材を確保する
• 自動化

　システム開発エンジニアの単価は上昇傾向にあり、コストの上昇を避けるためには、海外や地方の人材に期待するしかない状況と言えます。しかしながら、低コストな人材を活用するには、高度な能力を持つブリッジエンジニアが不可欠となります。

　そこで、注目される対策こそが「自動化」を切り口とした作業効率の向上です。

　自動化に向けては、まず「システム開発エンジニアのタスクを棚卸」して、自動化できるタスクを明確化することが重要です。

　システム開発エンジニアのタスクの主な内訳は「要件定義、設計、プログラム、テスト、ユーザーサポート」である。自動化に向けて、AI や人間に適したタスク領域を配慮して役割分担を考えると下記の様に考えられる。

図 3. システム開発エンジニアの主なタスク

では実際の開発現場では、どのような自動化に取り組んでいるのでしょうか。CDEC の参加者に伺いました。

2. ディスカッション

岩崎　開発現場において、何をどのように自動化或いは、効率化していますか？


横堀　弊社の開発現場では、システム開発エンジニアが担っていタスクの内、下記を自動化、効率化しています。

図 4. 自動化、効率化したタスク

横堀　まず「開発テストの自動化」を実現する上で、RPA を導入しました。

岩崎　RPA (ロボティック・プロセス・オートメーション : Robotic Process Automation) とは、PC に常駐したソフトウェアロボットが、PC の画面を一定のルールに基づいて捜査して作業を自動化する仕組みですね。RPA は、比較的安価でユーザ部門でも容易に活用できることから、昨今、急速に普及している自動化ソリューションですね。

横堀　はい。RPA は定型化された作業を、ミスなく高速に、そして超過労働も気にせずに代行してくれます。しかしながら、ソフトウェアロボットは柔軟な判断や対応は苦手なのですが。

　RPA の詳細については、以下よりご覧ください。

岩崎　RPA は様々なベンダーが提供しています。RPA はどのように選定されましたか？


横堀　RPA の選定にあたっては「UiPath」と「WinActor」を評価しました。デグレードテスト（具体的には共通機能に変更が生じた際、その共通機能を使う各種機能のテスト）の自動化を目的とした RPA として、それぞれを評価した結果、UiPath を選択することにしました。その理由は下記になります。

• 高機能で情報システム部門向き
• UiPath は CTC の RPA 関連製品で最も売れ筋であり、多くのアプリに対応している
• 操作が比較的簡単で、細かい制御も可能
• ソフトウェア開発のテストに適している

岩崎　WinActor はどうでしたか？



横堀　WinActor も「使いやすくユーザー部門でも使いやすい」と思えました。

横堀　UiPath の RPA を導入し、デグレードテストを RPA に担わせ、開発テストの自動化を実現しました。

図 5. RPA を利用したデグレードテストのイメージ

横堀　さらに、AIチャットボットを導入して「ユーザーサポートの自動化」を実現しました。ユーザーサポートとは、社内外からの問い合わせ対応です。CTC のデータセンターでは、社内外向けに Web マニュアルや各種ドキュメント、FAQ を開示しています。情報量が拡充されていく過程で、情報過多となり「見てくれない」、「探せない」といった課題が発生しました。この課題を解決する糸口として、人に代わって情報を探索できる「IBM Watson」のAIチャットボットに着目しました。

図 6. AIチャットボット導入の背景

岩崎　AIチャットボットに課題はありますか？


横堀　はい、AIチャットボットを導入してみて、気づかされた課題があります。それは、AIチャットボットの育成です。AI に正しい回答を学習させるまでに一苦労します。しかし、この課題を大きく上回る程のメリットとして、ユーザーサポートの自動化によるエンジニアの負担の削減は大きいと感じています。

図 7. AIチャットボットの学習のプロセス（探索と知識）

図 8. AIチャットボットの学習のプロセス（学習と理論）

図 9. AI チャットボットによる問い合わせ対応の流れ

横堀　最後に「ローコード開発」ですが、「ServiceNow」や「OutSystems」を活用しています。


岩崎　ローコード開発とは何ですか？


横堀　ローコード開発とは、コーディングをすることなく WEB 等の GUI にて「コードがテンプレート化されたブロック」を組み合わせてアプリケーションを高速かつ簡単に開発する手法を指します。従来まではフルスクラッチでウォーターフォール型開発を行っていましたが、現在はローコードでのアジャイル開発を推進しています。

図 9. ローコード開発画面 (OutSystems)

横堀　ローコード開発プラットフォームを活用すると、GUI で処理フローを作成するだけで、簡単にプログラムを自動生成できる。コーディングが不要であるため、人材教育の時間をはじめ、開発時間も大幅に削減できる。従来は、12 時間かかっていた開発作業が、今では 3 時間で済むようになりました。しかし、ローコード開発にも課題はあります。それは、ローコード開発プラットフォームのライセンス費用です。また、要件変更に振り回されることは変わりはありませんので、要件変更に柔軟に対応するための手法を確立することが重要ですね。

岩崎　要件変更に柔軟に対応するための手法とは何ですか？


横堀　「Scrum」という開発手法です。Scrum とは短いサイクルで開発を進めるアジャイル開発の 1 つで、要件変更に対して柔軟に対応できる特長をもちます。具体的に、私たちは10日間のスプリントを設定し、このサイクルでアプリやロボットを量産している。自動化ツールは「作って終わり」というものではなく、定期的なメンテナンスが必要だからです。私たちは、これによって様々な自動化ツールを活用し、システム開発エンジニアの不足を補っています。

図 11. CTC データセンターサービス基盤開発部の「Scrum」のイメージ

メーカー系情報システム子会社　RPAを活用したアジャイル開発を行う上で、ガバナンスのためのルールをどう策定していますか。またアプリやOSのアップデートへの対応についてどの程度のリソースを割いているのか、実際にメリットはあるのかについても教えて下さい。


横堀　ルールは部門内で作っていますが、禁止事項などは特に決めていません。今後ガバナンスを強化するため、このようなルールも策定していこうと考えています。アップデート対応については、優先順位を決め、高いものから対応しています。メリットについてですが、メンテナンスを含む稼働工数はむしろ増えています。しかし不具合が減少しているため、品質向上やリスク抑制というメリットがあると評価しています。


データセンター事業者（プリセールス担当）　いままさにRPAの導入に向けた取り組みを進めています。そこでお聞きしたいのが、費用対効果です。どの程度繰り返される作業であれば、RPAを導入すべきなのでしょうか。またチャットボットの公開までには、どの程度の期間が必要ですか。

横堀　よく言われるのは4回以上繰り返す作業であれば、RPAを導入する意味があるということです。それ以下なら手作業のままの方がいいでしょう。チャットボット公開までの期間は、データ次第です。当社ではFAQを作りながらチャットボットを構築していったので、公開までに半年程度かかりました。最初から豊富なデータが存在するのであれば、公開までの期間はもっと短縮できるはずです。

メーカー系情報システム子会社　ローコード開発で3時間での開発が可能になったということですが、そこに至るまでどの程度の期間がかかりましたか。また研修は行いましたか。

横堀　SQLなどの最低限の知識があるという前提ですが、12時間かかっていた開発が3時間になるまで1か月程度でした。研修は半日コースのものを1回受けただけです。あとはトライ＆エラーを繰り返すことでマスターしていきました

岩崎　CDEC 2.0 にご参加いただいた方々に下記を伺いました。

• 開発現場で困っていることは何ですか。
• 新しいツールによる生産性向上の取り組みは行っていますか、効果と今後の期待についてもお教えください。

メーカー（情報通信システム部門）　当社もUiPathを使っています。しかし導入目的はCTCとは異なり、エンドユーザー作業の自動化です。私はもともと製品開発部門におり、そこから情報システム部門へと移ったのですが、製品開発のテストプロセスにRPAを組み込んで使っていました。情報システム部門に来て感じたのは、テンプレートで生産性を上げることの重要性です。最終的に目指すべきなのは、outsystemsのようなローコード開発なのかなと。アジャイル開発に関しては、すでにスクラムを実践しており、スクラムマスターの認定も受けています。しかし当社では、ユーザー部門が『情報システム部門に発注するときには要件を固めておかなければならない』と考えているため、要件変更はほとんど発生していません。

ITソリューションプロバイダー（情報システム部長）　当社はクライアントベースRPAを開発・販売していますが、RPAの最大の問題はWindowsのアップデートに極めて弱いということです。マイクロソフトは事前情報を出さずにWindowsの仕様を変更するので、これへの対応は非常に大変です。しかしうまく使えば、RPAはいいツールになります。
　そのガバナンスで重要なのが倫理観です。例えば、RPAによる処理を進めるためにアカウント入力が必要な場合、これを自動的に行うべきなのか。当社では必ず人間が入力することにしています。これを自動化してしまうと、RPAが言語化してしまうからです。RPAはあくまでもソフトウェアレイバーであり、言語ではありません。これを開発言語として使ってしまうと、維持コストが高くなってしまいます。
　また当社ではチャットボットも販売していますが、これはディープラーニングとは全く異なります。ディープラーニングは高度で難しいAIですが、チャットボットは機械学習であり、身近なAIだと言えます。

システムコンサルティング（IoTプラットフォーム構築担当）　当社ではRPAもチャットボットも使っていますが、RPAを導入する際にはまずガバナンスをどう確保するかを決めるところからスタートしました。Excelでは野良マクロが増えて大変な目に会いましたが、RPA導入でも野良ロボットが増えることで、同じことが起こりえます。このような事態を避けるため、どうしても必要なところだけにRPAを入れることにしたのです。
　そのためにまずガイドラインを作成し、相談窓口を設置しました。優先順位としては、外部にアウトソースしている業務の効率化からRPA活用を進めています。今のところはこれで問題は発生していません。
　その一方で、チャットボットでは課題に直面しています。問い合わせ対応の効率化を目指し、まず調達部門にトライアルとしてチャットボットを導入したのですが、実際に問い合わせを行う際にどの部門に質問すべきなのか、わからないことが多いのです。今後、他の部門にもチャットボットを入れることになった場合、チャットボットが複数存在する状況では、ユーザーによる利用は進まないでしょう。部門をまたいだチャットボットをどう作っていくのかが、大きな課題になっています。
　またグループ全体でみると、同じシステムでも個社毎に中身が異なります。これも含めて回答できるチャットボットを作るには時間がかかりそうです。また下手に統合しても、混乱するのではないかという危惧もあります。

まとめ

　CDEC 2.0 後篇では「AI・RPA × 人の共創～システム開発の現場で業務効率を高める方法と費用耐効果～」をテーマに、ご参加いただいた企業と有益な情報交換を行いました。私自身もディスカッションに身を置くなかで、幾つかの気づきを得られた。

• 開発現場で困っている事
• RPA導入時のガバナンスの考え方
• RPA導入による費用対効果の証明
• 生産性向上に向けた取り組みをしているのか?
• RPA、AIチャットボットは導入検討・既に導入済みの企業が多い
• どのシステムに導入するべきか?が重要
• 実際の効果はあったのか?
• RPAを導入して不具合のリスクが減ったので品質があがった
• AIチャットボットの導入に関しては、ユーザの使い勝手がよく利用頻度が高い
• 今後の期待
• 運用現場では複数のシステムと連携しながらすべて自動化になることを期待。
• 本当に必要なところに自動化をして人が楽になる事を期待。

　今回の CDEC においても、ご参加いただいた企業のあいだで、普段では情報交換がし難いテーマについて、それぞれの考えや取組状況、今後の展望などについて情報を交換できる有益な機会となりました。他にも、興味深い議論が展開されたが、各社の機微に触れる内容も多く、本レポートでは割愛します。

　CTC は、今後も CDEC を主催して企業間の情報交換を活性化させ、得られた知見をお客様に積極的すると共に、CTCのサービスや他のクラウド事業者との連携などにフィードバックしていきます。

　本コミュニティにご興味を抱かれた方は、ぜひともCDECにご参加ください。

　尚、「CDEC」の開催案内メルマガの登録方法のご説明及び、CDEC 2.0 の前編は下記よりご覧いただけます。