Creatorshead

株式会社クリエイターズ・ヘッドのつぶやき

失敗しないためのAIシステム導入とは?

 

最近、弊社にも、AIを利用した業務システム提案として欲しいという要望が増えています。

具体的にAIを利用した要望の高い技術としては、画像認識、チャットボット、音声認識、予測、マッチング、テキスト解析などの話ですが、弊社がこれまでAIシステム構築に携わってきた経験則から、成功するケースと失敗するケースの違いは何か?を考えた結果、失敗するケースでは、お客様側で下記のような課題があることが挙げられます。

①導入目的が不明確
②システム化するためのデータが不足気味
③運用を含めてSIerに丸投げ
④AI結果精度の過剰な期待

上記の中で、特に予測モデルを作りたいというケースでは、②のお客様の現状所有しているデータが不足気味であるにも関わらず、④のAIでの過剰な結果精度を求めるがために、結果精度があまりにも悪いと高いコストを払ったのに、AIは「使えない」と短絡的に判断されてしまうケースが見受けられます。

これは提案するSIer側も受注欲しさに、お客様の環境を十分に調査せずに過剰な結果精度を適当に約束した上で、プロジェクトを開始する傾向があるため、SIer側にも非があると思われます。

弊社では、上記のようなお客様との齟齬が起こらないように努めており、まずは、AIシステム構築前に、導入目的を明確化して、現状対象業務フローを調査した上で、お客様所有のデータでは、導入目的に対して、どの程度の結果精度が出るかを調査報告するコンサルティング的なフェーズを設けて、お客様との認識Gapが生じないようにした上で、具体的にAIシステム構築のアプローチをしております。

AIの結果精度は機械学習と言うように日々学習しながら精度向上していくものですので、長い目での評価が必要です。そういう意味では、AIシステムは、導入したら終わりではなく、一番重要なのは導入後の運用フェーズということになります!

弊社は、お客様にご納得いただける結果精度が出るように運用フェーズにて、AIエンジン部分のチューニングなどを行っていきます。

そのように「使える」AIシステム実現に向けた万全なコンサルティング提案から運用までの体制を持って、お客様に満足いただけるようアプローチしていきます!

これからプログラミング言語を学習する際、Javaにするべきか?Pythonにするべきか?

最近の傾向として、人気のプログラミング言語の定番ともいえる「Java」と、人工知能(AI)などで有名になった「Python」の2つで迷う人が増えています。

一言で言えば、Javaは、C系と同じくプログラミング言語で、Pythonスクリプト言語という違いがあります。

Javaは、最も汎用的で人気のプログラミング言語であり、現在もエンジニア不足は深刻で、Javaのエンジニアは引く手あまたの状態ですね!

Javaの特徴を一言で表すと「環境に依存しない」ということです。Javaでは「Java仮想マシンJVM)」によって環境の違いを吸収してもらうことで、どんなコンピュータ上でも動くことを可能にしています。

Javaは、携帯電話やスマートフォンなどで使われる小規模なアプリケーションから、金融業で使われるような大規模な業務システムを開発する際にも用いられます。
特に、他の言語と比べて大規模な業務システムを作る際に採用されることが多いのが特徴です。

Javaで開発されているシステムの代表例の1つが「業務システム」です。金融業の取引システムや小売業の在庫管理システムなどがあります。

Javaはインターネットと相性がよく、大規模なWebサービスも開発できます。

一方、Pythonの特徴として、スクリプト言語のため文法がシンプルで「読みやすい」「書きやすい」という点が挙げられます。他人の書いたコードも比較的読みやすいものになります。その可読性の高さから、プログラミング初心者でも学びやすい言語だと言われています。

Pythonで作れるものは「Webアプリ」「データ解析/分析ツール」のほか、最近なにかと話題の「人工知能(AI)」などが挙げられます。

Pythonが最近人気なのは、まさにこの人工知能(AI)を作りやすいことにあります!

Pythonは以前から人工知能の研究で利用されていて、機械学習ディープラーニング専用のライブラリが用意されているなど、人工知能を作りやすい環境が整っています。

今後、どちらの言語が普及するのか未知数なところはありますが、いずれにしても、JavaPythonC#といったあたりのエンジニアは当面は重宝される(慢性不足の)状態が続くと思われます!

弊社も、この3言語のエンジニアを中心に開発体制を強化しておりますので、当該開発案件あれば、お声掛けください!

Watson Weatherによる台風予報

今日は、そろそろ帰宅しないと台風の影響が不安な状況ですが、IBM社が最近推している天候サービス「Watson Weather」の最新予報を見てみると、

今晩東京都内は、PM7時~8時に風速が20~26mと強くなるので要注意。

明日はAM11時頃から大雨に変わる可能性あり、午後は弱まる可能性もありますが、現在の気象状況からは、確実に雨が止むのはPM9時以降で、午後からPM9時までは天候が不安定なようです。

今回の台風は、東京直撃はなく、千葉・水戸から仙台に向けては、直撃の可能性がありますが、東京は被害最大にはならない風向きのようです。

皆さん今日から明日にかけて早めの台風の備えをしましょう!

 

受託開発契約の新たな形態

弊社のメイン事業は持ち帰り型の受託開発なのですが、従来型のウォータフォール型の受託開発から開発手法もアジャイル型を要求されてきたことに合わせて、契約もアジャイル型の受託開発に適した形態を模索しております。

その1つの解が、契約としては月単位の準委任契約ですが、当月の開発に関する一定レベルの成果物責任は負うという準委任と請負の中間くらいの契約形態となるものです。
通常の従来型受託開発(請負)と言うのは一般的に、要件定義に従い、開発工数を見積って、受注後は、要件定義通りに請負開発・納品・検収・請求を行い、約1年間の瑕疵担保責任があるということになりますが、お客様側のデメリットとしては、
・テスト工数を含めた要件定義内容の最終合意(確定)までの意思決定に時間がかかる。
・開発工数の妥当性(根拠)がお客様では判断しにくい。
・要件定義・開発費用の初期投資が高額となる。
・開発期間が長くなれば納品時には、既に機能が陳腐化している可能性が高い。
・開発中の急な仕様変更対応が容易でない(開発費、納期に影響)
・機能改善など追加開発に伴い、都度、追加開発コストと納期がかかる。
・契約した時点が最高で、そこからは陳腐化が始まる。

また、準委任契約(SES)に関しては、上記請負開発のようなデメリットは無い反面、成果物(検収)責任がないため、月単位に決められた場所で、決められた作業時間の中で作業するだけということになりますので、派遣契約に似ていますが、簡単に言えば、たとえ開発が完了していなくても、契約期間が終了すれば逃げられてしまうリスクがあるということになります。

その請負と準委任契約のお客様リスクを軽減する契約として考えているのが、お客様にとって請負と準委任のいいとこどりのハイブリッド型開発契約で、弊社で想定している主な契約内容と前提条件は以下の通りです。

月額精算契約(契約期間:3ヶ月単位)
<主な開発作業内容>
・持ち帰り開発前提
・前月末までに当月開発作業内容および月末時点での成果物内容の確認
・お客様のご要望に応じた柔軟なシステム開発・改良
 ⇒継続した品質改善・機能拡張
 ⇒クイックスタートが可能
・週1回の定期打合せ実施(オンサイト or リモート)
 ⇒前週までの作業進捗状況(成果レベルの画面確認)および
  今週の作業内容の確認

<契約には含まれないこと>
・要件定義
・納期コミット(検収条件)
・詳細な開発文書化

常に使っている時点で最高、最新のものを利用できる新たな開発形態にご関心のあるお客様は弊社までお声掛けください!

着衣型ウェアラブルがIoTやIoBの導入を促進する?

このブログでも何回か「IoB(Internet of Bodies)」に関する記事を紹介してきましたが、弊社もウェアラブル端末データを活用したIoTソリューションをヘルスケア分野などで展開していますが、ミツフジ株式会社という会社が自社の銀メッキ導電繊維「AGposs」を利用した着衣型ウェアラブルIoTブランド「hamon」を、この分野に展開しているようです。
ミツフジ社は、事業コンセプト「ライフ・インテリジェンス」を掲げ、従業員の見守りや健康管理システムなど、あらゆる場面で生体情報マネジメントを提供するスマートウェアとして、法人向けにサービスを提供してきました。
「hamon」は、スポーツ分野に限らず、工場などの作業現場や介護分野など多岐の分野に着衣型で情報発信するという活用としてIoT促進の起爆剤として期待が高まります。
ミツフジ社は、スマートウェアによる生体情報マネジメントで、生活のあらゆる場面で知恵と予測を提供し、社会課題の解決に貢献するコンセプトで事業を拡大中であり、弊社のIoTソリューション提案でも積極的に活用していきたいと考えております。

工場IoT化実現のための指標


現在、工場の生産効率を上げることを目的として、工場のIoT化の取り組みが各企業で進んでおり、弊社もある大手製造業のお客様向けに工場IoT化を支援しております。

その工場のIoT化を実現するための指標として、いかに生産効率を阻害する要因を解消するか?ということが大切になりますが、工場の生産効率を阻害する設備のロスについて日本プラントメンテナンス協会では、7大ロスと定義しています。この7大ロスの考え方は、設備の本来持っている機能を、十分に発揮させることを妨げる要因をロスとして挙げています。

◎設備効率を阻害する7大ロスとは、
1. 故障ロス
突発的・慢性的に発生している故障によるロスで、時間的なロス(出来高減)、物量ロス(不良発生)を伴うものです。
2. 段取り・調整ロス
段取り・調整ロスとは、現製品の生産終了時点から次の製品の切替え・調整を行い、完全な良品ができるまでの時間的なロスを言います。 
3. 刃具ロス
刃具ロスとは、刃具の定期的交換・切損による一時的な交換に伴う時間的なロスと交換の前後に発生する物量ロス(不良・手直し)です。
4. 立上がりロス
立上がりロスの定義は、以下のとおりです。
・定修後のスタートアップ時
・休止後(長時間停止)のスタートアップ時
・休日後のスタートアップ時
・昼休み後のスタートアップ時
5. チョコ停・空転ロス
チョコ停・空転ロスの定義は、以下のとおりです。
・一時的な機能の停止を伴うもの
・機能の回復は簡単な処置(異常なワークの除去とリセット)でできるもの
・部品交換,修理は伴わないもの
・回復時間は2~3秒から5分未満のもの
6. 速度低下ロス
速度低下ロスとは、設備のスピードが遅いために発生するロスで、以下のように定義します。
・設計時点のスピード(あるいは品種ごとの基準スピード)に対する実際のスピードの差によるロス
・設計時点のスピードが現状の技術水準またはあるべき姿に比べて低い場合のロス
7. 不良・手直しロス
不良・手直しロスの定義は以下のとおりです。
不良・手直しによる物量的ロス(廃棄不良)と修正して良品とするための時間的ロスです。一般的に,突発不良は対策が立てやすく,放置されることはまずないが、慢性不良はなかなか原因がわからず、対策を講じてはみるが良い結果が得られず、放置される場合が多いです。

上記、7大ロスに加え、8大ロスとか、16大ロスという定義もあります。

◎設備操業度を阻害するロス

8. SD(シャットダウン)ロス

◎人の効率化を阻害する5大ロス
9. 管理ロス  
10. 動作ロス  
11. 編成ロス
12. 自動化置換ロス
13. 測定調整ロス

◎原単位の効率化を阻害する3大ロス
14. 歩留りロス       
15. エネルギーロス  
16. 型・治工具ロス

工場IoT化実現には、設備や装置から、どのような稼働データを取得して、上記ロスのどれにあたるか?データを仕分けて、それぞれのロスの原因の特定、改善方法を分析し、タイムリーに実行にうつすという考え方とシステム化が必要です!

「Shield Share」がPCI DSSに対応したソリューションとして登録されました!

7月24日付で日本カード情報セキュリティ協議会(以下 JCDSC)の「PCI DSSソリューション」に対応したソリューションとして弊社エンドポイントセキュリティ製品である「Shield Share」が登録されました。

PCI DSSとは、「Payment Card Industry Data Security Standard」の頭文字から取ったもので、カード会員や取引の情報の保護を目的にネットワーク等の処理システムや情報管理に関する事を定めた今、話題のセキュリティ要件となります。

PCI DSSの要件とは、6つの項目と12の要件から構成されており「Shield Share」は、このうちの以下3つの要件に適合したことが認められました。

・要件3:保存されるカード会員データを保護する
・要件4:オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する
・要件9:カード会員データへの物理アクセスを制限する
※上記内容は、JCDSC様ホームページ(http://www.jcdsc.org/index.php)より抜粋しています。

また今回認定いただいた弊社「Shield Share」とは、

ファイルサーバー運用やテレワーク環境において、デスクトップ仮想化やインストール
が不要なエンドポイント情報漏えい対策製品です。独自技術である「アプリケーションシールド」によって、閲覧・編集時のデータをアプリケーションの動作を制限する事により、PCからの情報漏えいを防ぐ画期的なエンドポイントセキュリティ製品です。

ぜひ、PCI DSS準拠を考えられているお客様で、情報保護環境構築時には「Shield Share」をご検討ください!