マイクロサービスとAIについての勉強会ということで、
わくわくしながら行ってきました。場所はSAPオフィスです。
dev.classmethod.jp
ユニクロなど大手衣料品店を経営するファーストリテイリング様と、
クラスメソッド様の合同勉強会です。
採用活動も目的としてあるようでしたが、私はエントリーする予定ありません（笑）
マイクロサービスの苦労話が本当に参考になる勉強会でした。
また、パネルディスカッションは私の価値観を大きく変える可能性のあるものでした。
まずは、レポートしていきます！
レポート
FRが取り組むmicroservicesとアーキテクチャ変革
- FRの取り組み
- 技術力の長期的な確保と選定
- 日本から世界に向けてチャレンジを
- グローバルチームの構築
- IT内製の実態
- AWS4000台、マルチリージョン利用
- AzureやGCPも使っている。
- CDNにはAkamai
- JavascriptかJavaがメインになる。
- マルチブランド・マルチリージョン
- 店舗・EC含めてビジネスが十分に複雑
- 変化のスピードが非常に早い→通常の会社より５倍くらいのスピードがある会社。
- Queueにkafkaを利用してたりする。
- Microservice 良い点
- Microservice 課題
- 技術的に統制効きにくい
- 運用は自動化込みじゃないと難易度があがる
- 各サービスでのプロダクトマネージメントの観点が必要
- 各サービスでオーナーをしっかりたてていく必要がある
- 大事なのはビジネスを支える最小単位のコンポーネントは何かを考える必要がある
- Microservices for data
- 実績データ
- 計画領域
- IoT
- 各種マイクロサービス
- イメージ管理
- アナリティクスなど
- →データプラットフォームに格納して、あとからどうやって活用するかを考える。
- データの長期の保存と、データの利活用を分ける。すごいなー。
- Microserviceを支えるDevOps
- インフラの自動化＋デプロイの自動化が基本。
- 課題は標準化・大きな粒度での自動化などがまだ
- ツールだけから、組織で広域な自動あの取り組みへ
- 自動化していくにあたり、問題にぶちあたる
- 大量の技術負債
- 組織的な問題や仕事の分量そのものの見直し
- プロセスの見直しや役割がおかしい部分が明らかに
- 全員がちょっとづつコンフォートゾーンから出る必要性
- 自動化そのものよりも、その過程でのプロセスや組織体制・チームの分担などの変化が大事に思える。
- ツール選びで何か変わったわけではない。
- 呼び水となったのは運用不可を劇的に下げたいなど
- ビジネスのバリューストリームへの貢献度は低い
- 今品質が大事なのか、タイムラインが大事なのか、
- それに応じて自動化の仕組みが変わってくる。
- みんなで取り組まないと定着しない・・。
- ツールだけで達成できるものじゃない。
- これからのアーキテクチャを考える。
- 基本的にはone way(大きなものを適切な粒度に分界)で、これは避けられない
- SoR的なことだけが求められているわけでもなく、顧客同行により常に変化していく必要がある
- KISS
- YAGNI
- 関心事の分離
- リスコフの置換
- Microservice.ioを見れば、どのようなデザインパターンや黄金律があるのか、大体まとまっている。
- すごいな。microservices.io/patterns/index.html
- まとめ
- Microserviceは総合力。技術だけでなくて、チーム編成からDevOpsまで含めてやらないと効果はでない
- 足回りのDevOpsは当たり前に強化する必要がある
- チーム編成も大事。色々なタイプの人が必要。
- 全体の相互理解・底上げ、普通の話だが大事
- 世の中の複雑さをいかにシンプルに解決するか
- ビジネスを成立させるための最小粒度のコンポーネントが大事
Amazon Alexa の衝撃と新たなエコシステム
- Alexaを使った音声インターフェースの事業部について
- クラスメソッドってデカイんだなー・・。
- 700社から1000社と取引
- 世界にまたがるオフィス
- セルフマネジメントとアウトプットを重視する会社
- 子供が生まれたら半強制的に休ませる
- Alexa事業部について
- 設立の経緯は、一言でいうと面白そうだから。
- iPhoneが出てきた頃の黎明期に似ている！？
- 新しいUIが出てくる頃には世の中は激変する傾向にある？
- 世代別の利用サービスから見る音声の需要
- シニア層は音声インターフェースを必要とするはず
- 国による違いはなくなってきているけど、世代間のギャップのほうが大きい
- 働く人が必要なのに減る。
- 人が少なくなっていくなかで、付加価値の高い業務に注力して、付加価値の低い業務は自動化などを推し進めていく必要がある
- 裏側のシステムが重要(カスタムスキルはOAuthを利用する必要ある的な)
- カスタムスキルの例
- スタバ - 直近10店舗で注文したドリンクの再注文やスタバカードの残額確認
- クラスメソッドのカスタムスキル、20個くらいある。
- 帳票の仕組み＋音声サービスでユーザーエクスペリエンスを目指す→それがEcho Show
- dash wand→バーコードリーダーがついていて、Amazonで注文できる。さらに音声操作できる。
- VUIによる個人ではなく企業への問題解決のために、事業部署を設立的な。
- まとめ
- 音声はすべての人々にリーチする
- その技術を使って、事業の価値を高める。
所感
たまに、このような魅力的な勉強会があるから、勉強会は本当に行くべきだと思う。
今回は、自分自身のITの価値観が変わる出来事だったかもしれない。
それはパネルディスカッションで起きました。
レガシーになることを意識する
私はここ最近、様々な技術知識の吸収を行ってきましたが、
これらの技術も最終的にレガシーになりえるわけなんですよね。
つまり、技術を追い求める上で、その知識はどれもレガシーになりえることを覚悟しておかなければならないわけですね。
これはAWSも同じことなんだと思います。。私はAWSの認定資格を取得しましたが、
この認定資格すら、レガシーになりえるわけですね。
そして、AWSは100以上のサービスがあるわけですが、
実際に主流として使われているサービスが100以上あるわけではないということも、
理解しなければいけませんでした。
AWSなどのパブリックIaasは非常に魅力的ですが、その全てのサービスが
ITベンダーに受け入れられているわけではない、ということなんだと思います。
主催会社様の意外な印象
個人的に意外な印象を受けたのが主催会社様の運用保守メンバーが
全社員の3分の1近くを占めていることでした。
私は今まで散々運用保守はやってきたので、
最近はもっと違うことをやってみたいと考えています。
しかし、お客様と取引する関係上、
やはり簡単に今の案件を抜けることは難しいのでしょう。
システム屋、とくにサーバ屋は運用保守とは切っても切れない関係にあるのでしょうね。
「分からない」ということを正確に伝えることのリスク
それと、自分が今持っている引き出し知識以上のことが分かっていないことを
ちゃんと伝えられることは重要という話がありましたが、これってリスクもあると思っています。
私は上記のことを実践しています。なぜなら、嘘をつくよりはわからないと伝えたほうがいいから。
でもこれが、たまに舐められることがあるんですよ。見下されるんです。
個人のバックグランドや得意技術はそれぞれ異なるはずなので、一緒に知識を補って補完してくれる
メンバーと一緒に仕事したいですよね。と、心底思います。
ITエンジニアの出せるパフォーマンス
ITエンジニアが一人で出せるパフォーマンスの現実を、
私はもっと理解しなければいけないと思います。
一人のスーパーエンジニアが10のパフォーマンスを出せるとして、
他のエンジニアが5しかパフォーマンスが出せないとしても二人いることで
スーパーエンジニアのパフォーマンスに届く可能性があります。
そういったエンジニアの集まりでチームを形成し、一人では長時間かかる案件を
短時間で作り上げていく。
私たちは一人では出来ない事をチームで実現することが多いのです。
チームで仕事をするとなると、どうしても技術レベルの低い人に合わせることがあるし、
全員にスーパーエンジニア並みのパフォーマンスを求めるのは不可能です。
技術勉強会では登壇者が主役となり、アウトプットを見せることがありますが、
もしそれがチームで行った成果なら、そのアウトプットの背後には
チームメンバーが出した成果も含まれていることもありえると思います。
一人で仕事をしたいなら、フリーランスになって
自分自身のやりたい仕事をマネジメントしてみたほうがいいかもしれない。
会社が個人のアウトプットを重視するのか、チームのよる成果を重視するのかによりますが、
どちらにしても本当に自分自身が居心地のいい職場が存在するかというと、
どうなんだろうと思ってしまいます。
参加した皆さん、お疲れ様でした！
以上、かなり長文になりましたが、レポート終わります！
