[201802] Cloud Days 東京 2018

Contents

参加セッション

 

製造業のアプリストア構築における最重要ポイントとは ~誰も教えてくれないマネタイズを成功させる方法~

製造業では以前はハードウェアを製造し売っていたが、ソフトウェアはその無償の付属品扱いであった。
しかし、近年では有償のソフトウェアや拡張機能、ソフトウェアのサポートサービス、ソフトウェアに付加価値を与えるサービスを販売する製造業の企業が増えてきている。
更にハードウェア上で動作するソフトウェアのSDKを他社に提供し、アプリストアを運営する企業も出てきた。
※後は「ジェムアルト」社サービスの紹介

リコー社も大分昔から複合機で動作するSDKを提供しており、私も学生の頃、コンテストに参加したことがある。
PCやスマートフォンといった汎用機器とはまた違った使い方ができ、ユーザーとしては歓迎すべき。
どの程度の企業が取り組んでいるのかはわからないが、日本経済へのインパクトも大きそうである。
ITRONのようなRTOSを載せるのか、別のOSを載せるのか、OSなしなのか、デファクトスタンダードの争いもありそうである。
リコーの複合機は、OSは開発者からは見えなかったが、ユーザープログラムはJVMで動作していた。

 

Agileトランスフォーメーションは何故失敗するのか -スピーディーな組織を作る成功のカギ

Agile開発を導入しようとしても失敗する例が後を絶たない。
その原因は局所的にAgile開発を導入しようとするからである。Agile開発導入には組織的な支援が必要。

まず、Agile開発の利点を理解しなければならない。
開発体制に柔軟性を取り入れるにはウォーターフォール型からアジャイル型へのパラダイムシフトが必須である。
ウォーターフォール型は開発スコープを決めてから、予算と時間を変動させるが、
アジャイル型は予算と時間を固定してから開発スコープを決めることができるようになる。
これによって、無制限に予算・時間を追加していくという事態を避けられる。

Agile開発を導入するには、経営層のコミットメントが重要だが、最も重要なのは現場への権限委譲を行うことである。
権限委譲後、組織への定着のために、現場主導で行っていくのが最も成功しやすい。
まずは開発環境の整備(JenkinsやRedmine等の用意)から始めるのが良い。

 

人材ビジネスをAIで革新! フォーラムエンジニアリングの挑戦

フォーラムエンジニアリング社は製造業系の技術者派遣ビジネスを行っている。
フォーラムエンジニアリング社は技術者採用に利便性の高い都心に拠点を置いている。
しかし、派遣先である製造業者の生産設備は地方にあるため、派遣先への営業は負担が大きかった。

その為、フォーラムエンジニアリング社は行かない、会わない、話さない営業を目標に取り組んだ。
その一環として、技術者のマッチング、紹介を行うAIを開発した。

AIは顧客とチャット形式で会話しながら、必要な技術者の要件を聞き出し、最適な技術者を紹介する。
AIは顧客の依頼内容を自然言語処理を行い要素分解し、必要なスキル・経験を洗い出していく。
その後、予め構築しておいた技術者のデータベースから最適なものを検索し、紹介する。
単価交渉もできるらしい。

このAIサービスは試験導入されており、効果を上げている。
具体的には、これまで派遣先企業は一人のエンジニアを採用するのに平均6名の人材を検討しており、フォーラムエンジニアリング社もエンジニアの派遣先を決定するのに平均6社の案件を検討していたが、大半のケースでAIが提案する第一候補のマッチングで派遣契約が成立するようになった。
AIはスコアリングによる客観的なマッチングの度合いを論拠として示すことができるので、説得的であり、この点が効果を上げているとのこと。

更に派遣先企業の社内人材も登録可能にし、その企業内で調達可能な人員全体での人材マッチング基盤も提供する予定である。

非常に面白い試みである。
製造業は、製造部品は明確でおよそ共通化されているのでコンピューターによるマッチングも可能なのではと思わないでもないが、IT業界でも一定の制約下で適用可能だと思う。
ただそうなると、派遣企業の意義はあまりなくなるのではと思う。

派遣先企業の社内人材も含めたマッチングができるというのは良い考えであると思う。
派遣先企業の情報もビジネスに活用できる為、基本的に派遣先企業の案件ありきである人材ビジネスもより攻めの姿勢で活動できそうである。

 

コンテナを用いたレガシーシステムの移行事例 -グルメサービス Retty

旧タイプと新タイプのWebサービスが混在し、両方で同じコードを呼び出している部分が多々あったので、旧タイプのサービスに影響を与えないように開発を続けるのが困難であった。
RettyはAWS上で動作しており、Webサーバ、キャッシュサーバ、DBサーバの3種類のサーバで構成されていた。
初めに検討されたのは3タイプのサーバ群をもう1セット用意して、そちらに旧システムを移行すること。しかし、サーバ増加による運用負荷増大を懸念して断念。

そこで、Dockerコンテナに3種類のサーバのソフトウェアを入れて、一台で完結してサービス提供するようにした。
旧サービスの負荷は小さなものであったため1台に集約しても問題なかった。
更にDBサーバをSQLiteに変え、負荷を軽減した。
ドメインは共通であったため、ロードバランサでパスによってクエリ転送先を分ける方法で、ロードバランサは共通化したままにできた。

その他良い写真AIを使用するなどしてサービス改善したところ、旧サービスのアクセス数を増やすことができた。

 

アサヒグループ「アサヒCSIRT」の取組みと、サイバーセキュリテイ対策強化の状況

海外への露出が増え、サイバーリスクが高まった。
経済産業省が公開している、サイバーセキュリティ対策の重要10項目で評価したところ、非常に低い評価であった。
このため、下記のような対策に取り組んだ。

情報資産の重要度の評価、運用体制の刷新を行い、その過程でCSIRTが発足された。
経済産業省のセキュリティガイドラインをもとに組織構築し、運営されている。
経営層との情報連携体制の確立、社員教育、セキュリティ情報や技術の外部発信、情報保護環境の構築等を行う。
その結果、再度評価項目で評価したところ、良い結果が出た。
ただし、セキュリティのレベルを維持することが重要であるので継続的な取り組みを行っている。もっとも重要なことは社員教育、訓練である。

組織のセキュリティの強度は、よくある例を用いれば、鎖のもっとも弱いところとなる。つまり強いところを強化するより、弱いところをなくすことが需要である。
実際に情報資産を扱うのはCSIRTのようなセキュリティの専門家ではなく、一般の社員であるのだから、社員教育、訓練が需要であるというのはうなずける。

 

展示会について

働き方改革を受けて、リモートワークやリモートアクセスの為のセキュリティ関連、バーチャルデスクトップ等の仮想化基盤、RPA(Robotic Process Automation)、チャットボットの展示が多かった。
特別興味を惹かれるものはあまりなかったが、次の製品は面白かった。

 

iTutor

マニュアルの自動作成ソフト。デスクトップ録画ソフトの一種で、このソフトを起動後に行った動作をキャプチャしてくれる。
その際、キャプチャ上にクリックした場所・キーボードで入力した場所に吹き出しを置き、「○○をクリック」や「○○と入力」と自動で記載してくれる。
自動生成されたマニュアルはパワーポイントライクなUIで手動編集もでき、PDFやワード、WEBページとして出力可能である。
厳密なフォーマットがあれば採用しづらいだろうが、内容重視であるなら、十分な内容のマニュアルをかなり簡単に作成できるので、とても良さそうである。
現在Windowsのみ対応しているが、Mac版も開発中らしい。

MaxGauge

アプリケーションサーバとRDBMSサーバ間のセッション情報を可視化し、DBサーバのステータスをグラフ化する。
流れているSQLを補足し、実行計画を試すこともできる。
MySQL Workbenchなど、各DB製品のモニタリングツールの統合化版みたいなもので、使用感は良さそう。
サーバ上で動作するので、クライアント環境の準備が不要なのもよい。


Notice: Trying to get property 'queue' of non-object in /usr/local/wordpress/wp-includes/script-loader.php on line 2876

Warning: Invalid argument supplied for foreach() in /usr/local/wordpress/wp-includes/script-loader.php on line 2876