技術関連の覚書

案件でやったり自宅で試したことの覚書、自宅Redmineから移行

事業会社とブログ会社が語るAIとマイクロサービス、そして技術者の働き方 〜ファーストリテイリング × クラスメソッド勉強会〜

ここに行って来ました

【7/26(水)開催】事業会社とブログ会社が語るAIとマイクロサービス、そして技術者の働き方 〜ファーストリテイリング × クラスメソッド勉強会〜 | Developers.IO

タイトルは勉強会ですが、最初の挨拶で横田社長が「勉強会という名の会社説明会」と言ってました。

ファーストリテイリングが取り組むmicroservicesとアーキテクチャ変革

株式会社ファーストリテイリング コアエンジニアリング 部長 大谷 晋平 KafkaのExactly Once 最近クラスメソッドのブログの内容が変わってきたことが気になってるそうです

Microservice、DevOpsについて、メリットデメリット、FR社での運用方針などを語ってくれました。

グローバルチームの構築

採用もグローバルにかけてるのでグローバルチームを構築している 日本初のグローバルエンジニアリングチームを構築し事業に貢献していく

FRの内製の考え方
  • どの領域でも重要なのはどれが優れているという話ではなくシステム全体を成立させるにはどれも重要

  • オンプレをやめて全部クラウド

  • ツールセットをオープンソースに持っていってる

なぜMicroserviceか
  • マルチブランドマルチリージョンでやりたい

  • 店舗・EC含めてビジネスが十分に複雑

  • 変化のスピードが非常に早い

microserviceは技術の話でなく総合力

ユニクロを展開するファーストリテイリングなのでサービスは多様でそれらすべて1つのシステムとしてやっていくのは大変なようです。 銀行システムのような大規模システムもこのように細分化していけば合併や法改正にも素早く対応できそうです。

Microserviceの良い点

  • 技術負債は返しやすいので技術選定の心理的負担が比較的低い

  • 障害の局所化

  • 全死のリスクが低い

  • 開発が並行で出来やすい

  • 複雑な環境下では逆に他の方法ではうまく行かない

課題と思う点

  • 技術的には統制効きにくい (カオスを受け入れる)

  • 運用は自動化込みじゃないと難易度が上がる

  • 各サービスでプロダクトマネジメントの観点が必要

  • 各サービスでオーナーをしっかり仕立てていく必要がある

技術的に統一していこうとすると失敗するようです。 基本的な大勢はあっても例外を受け入れていかなければそこでハマってしまいそうです。

プロダクトとして何を求めていいくか
  • microserviceが大事なのではなく、プリミティブなビルディングブロック探し カタログ、在庫管理…

  • ビジネスバリューを出すための最小粒度が大切(ビジネスドメインとWillが重要)

  • データをあるがままに保存して加工は後

  • 時代の流れで変わるものは後でもいい

  • 会社として共有していく

Microserviceを支えるDevOps

インフラ自動化、デプロイ自動化

自動化していく上での問題

  • 自動化のために返済しなくてはいけない大量の技術負債

  • 自動化を阻む組織的な問題や仕事の分量そのものの見直し

  • プロセスの見直しや役割がおかしい部分が明らかに

  • 全員がちょっとずつコンフォートゾーンから出る必要性

自動化よりもその過程でのプロセスや組織体制・チームの分担などの変化が大事に思える ツールで変わったわけでない DevOpsがシステム開発だけの話ならシステム開発行為だけ 要求は企画などの初期フェーズでDevOpsの価値を理解してIT以外の巻き込みや教育

DevOps

ツールやIT だけで達成できるものでもない

これからのアーキテクチャ
  • 基本的にはOneway

  • 大きい物を適切な粒度に分解

  • SoR的なことだけが求められてるわけでなく顧客動向により常に変化する部分を

  • 原理原則は変わらず適用領域を広げるのみ

http://micorservices.io/patterns/index.html

microserviceではチーム編成も大事でいろいろなタイプの人が必要 全体の相互理解・底上げが大事

自動化にこだわりすぎない

世の中の複雑さをいかにシンプルに解決するか Microserviceが大事だなのではなくビジネスを成立させるための最小粒度

Amazon Alexaの衝撃と新たなエコシステム

クラスメソッド株式会社 代表取締役 横田 聡 ブログ(横田あかり) 社内では見てくれない、社外からのフィードバックを見て社内が見てくれる

立ち上げたばかりのAlexa事業部のこともありAmazon Alexaを使ったVUIの話です。

Amazon Alexaの衝撃と新たなエコシステム

なぜ音声入力に注力しているのか

前半はDevelopersIO 2017でも話していた内容

【来場御礼】Developers.IO 2017レポートまとめ #cmdevio2017 | Developers.IO

スマホの普及、誰でもPCを使う時代と思ってもやはり、まだシニア世代の通信手段の中心は電話、FAX、手紙 そこに、音声でいろいろ操作できるものがあればその世代も使いやすいものができるのではないかという発想のようです。

  • Alexaを始めた理由 -> 面白そうだから

  • 社会背景 ->2015年登場

  • ヒューマンインタフェースの歴史 ->おもちゃ→インタフェースの変化

確かに遊び道具のようなものから発展してビジネスで使えるチャットが普及してますね。 VRもゲームから住宅展示、自動車の試乗などにも使われています。

頭の硬い会社は今でも就業中のLINE禁止やプライベートでもSNS禁止(バカッター投稿者を会社から出したくない理由から) こういう会社はボットなどを新たな開発をするにも既に出尽くしたくらいから参入して新しいものを作る余地がなくなってしまいそうです。

新しいもの=楽しい、遊び道具がビジネスにも使える=ビジネスも楽しめる こんな発想をすれば、居心地のいい会社づくりもできそうです。

  • 新しいUIが出てきたら世の中が変化する

  • VUIが普及したらマイクとイヤフォンだけになる?

  • すべての世代に繋がるサービスがない

  • おじいちゃんおばあちゃんにスマホをいじる

  • 国によるギャップより世代間のギャップが大きい

ターゲット
  • シニア世代は電話FAX手紙窓口で記入 ->この世代をどうにかしたい

  • 付加価値の高い仕事に人間が注力 ->付加価値の低い仕事は機械に任せる

  • 人手不足へのアプローチ ->バイリンガルトリリンガル→外国人への対応 要求レベルの向上

  • Alexaは現在英語、ドイツ語のみ ->いろんな言語で対応していければ世界中の人とコミュニケーションできるチャンス

  • 決済もボーダレス ->AWSで世界のリージョンが使える

インタフェース

音声をUIとしてAlexaで音声認識→テキスト→chatOps的なサービス

AWSのまえAdobeFlexをやってた またUIを作る

VUIによる対話で重要なのは文脈(コンテクスト)
  • いつもので寿司が出る ->VUIではこれが一番心地良い

  • お茶頂戴でコーヒーが出る ->DeepLearningが発達するとできる

文脈から会話をする ユーザが望んでる者の先読み 注文履歴などから

カメラで見て誰が喋ったかを判定できる? ->誰が喋ってるかを認識

もしかしたら、音声の特徴(声紋とかかな)で誰が喋ったか認識できるかもしれない

音声はすべての人に立直する

パネルディスカッション

イベント参加登録時の質問をいくつか紹介して答えてもらう形式でした

お互いのことはどう思ってますか?

最初の出会いは同じ案件 AWS日本人1号大島さん 2年目くらいに大谷さん

CMがすごく変わった まさかクラウドやるとは思わなかった 1周回ってUIに

なぜブログの会社に? 最先端の取り組みをしている2社だと思うので大変なことは?

新しい技術 摂り過ぎて失敗することもある 失敗もいっぱいある

開発をしている会社ってやっぱり、失敗も含めてノウハウになっていくんだな。 受託と言ってもこんなものを作ってくれと頼まれたものをそのまま作るだけであれば機械で作れたりどこかの会社に持って行かれたりするんです。

最初入った時は技術が溢れてて何のための技術かわからなくて削っていった マルチクラウドでやってるのはどうなのか? 役割で区切る

クラスメソッドは自社向けでは AWS,AZURE,Googleもやってる

サービスがどれか覚えてない どれは使うべきでないかというのは抑えておく

これは、いろいろと触ってないとできないことですね。

技術好きで飽きっぽいから新しい記述をとっかえひっかえしてる

FR:事業会社でしかできないこと

  • システムはどこまでやるべきなのか

  • ものがずれる、在庫が余る

  • 人間はそこまで完璧じゃない

CM:AWSに特化した企業文化特徴・大変なところ

  • 1000社のインフラを相談される、アドバイスする

  • 管理コンソールを触ることも多い

  • 100社のアパレルのインフラを覗ける

機械の得意な部分と人間が得意な部分を明確にして、事業のどれを割り当てるかを考える事業会社と 1000社のインフラを相談されてアドバイスをする、インフラを覗くと言った様々なサービスに触れられる開発会社とでは楽しみ方が違いますが、それぞれの楽しみ方ってありそうです。