DevelopersIO2019
今年聞いてきたもの
| タイトル | スピーカー |
|---|---|
| Developers.IO CAFEのこれまでとこれから 〜顧客体験へのフォーカスから考える技術選択〜 | 横田聡 |
| 「今」のAI技術と「3年後」のAI技術のご紹介 | 清野剛史（せーの） |
| AWS初心者が陥りやすい運用アンチパターンから学ぶ成功の法則 | JIG-SAW 小嶋一毅 氏 |
| Serverless ー SaaS版 Developers.IO Cafeのアーキテクチャ設計で考えたこと ー | 渡辺修司 |
| ITの民主化とユーザー部門によるIoTコトはじめ | LIXIL 佐々木義 氏 |
| AWSに超詳しいエンジニアが育つ環境を作る方法 | 豊崎隆 |
| クラメソ金曜ロードショー「沈黙の分析3」〜スティーブン・セガール映画の邦題に「沈黙」がつくかどうか機械学習で予測してみた | 玉井励 |
| 全部Excelだけで実現しようとして後悔するデータ分析 Second Edition | 小澤祐也（じょんすみす） |
| ハイブリッド/マルチVPC環境を構成するためのAWSネットワーク完全理解 | 菊池修治 |
DevelopersIO CAFEは去年聞いたものから現状まで ０ヶ月目 (横田社長が)感動する １ヶ月目 とりあえず動くものにしてみる ２ヶ月目 展示する
無謀なスケジュー感だけど思うけど、
動画でやりたいことを見せる
要件定義書や設計書を書いてる時間それらの合意にかける時間を考えずにすむ。
社内だからできたことだけど、この成功事例を広めて無駄に時間をかけて大量の書類を作る文化をそろそろやめてもいいと思う。
できたところと出来上がったイメージを組み合わせてやってみる
出来上がってから試す場合、出来上がりを待つのも時間がかかる
出来上がってないところをダミーにすることで次にやるべきイメージができる
決済部分ができていなくても決済画面を表示することはできる 実際の買い物の決済と違っていてもイメージはできるようになるからそこからまた勧めていくことができる
こういったことが３ヶ月で展示までたどり着いた要因だとは思う。 ここまでは前回の話でも出てきたところで、その続きは 実店舗Developers.IO CAFEを作ってみた。
実際に運用することで、
お客様からのフィードバック
カフェ店員からのフィードバック
エンジニアからのフィードバック
これらを得ることができて次にやるべきことがわかってくる。 ただし、この時点では利益はあまり出ない。
実際に店舗を作ることで問い合わせも来る そうなってくると、量産化、利益を生むための仕組みが必要。
スピード重視の開発から保守性、汎用性を考えた開発 モジュール化、基盤の発注など
まとめると、 紙（パワポ資料）よりも動画 まず作ってみる できてないところはダミーで全部つなげて試してみる やってみて蓄えたノウハウがそのまま事業になる
AWS初心者が陥りやすい運用アンチパターンから学ぶ成功の法則 アンチパターン：監視ができていない、監視しすぎる、稼働目標が高すぎる、想定外を想定していない、運用を意識していない構成
監視についてはお客さんとどのように監視していくか、テスト段階で実際に必要だったかをブラッシュアップしていき最適化していくということはできていたが 稼働目標が高すぎるについては、コストとのバランスを見ないと何でも盛り込みすぎてコストに見合わないような構成が出来上がる。 想定外を想定することは一見難しそうだけど、エスカレーションフローを考える、ユーザーへの障害アナウンス、DR環境の準備 これらは、運用手順として盛り込んでおくことで解消されること。 運用を意識していない構成は、AWSがPaaSであることを意識しないで運用設計をしてしまうこと。 既存のオンプレをそのままリプレースしても構成は可能だし、AWSのサービスを利用しなくてもCloudWatchを利用して変更や追加に柔軟に対応できるようにする。 RDSを導入しなくてもGuardDutyを利用してセキュリティを強化するということもできる。
実際にやってみたことでは、Elasticsearchのバージョンが合わずにElasticCacheを使えずEC2にElasticsearchを入れて動かすといった運用をした。 その時、オンプレの時に出していたログでは足りない部分があったりで導入前に改修 その後も運用していくうちに不要なログや足りないログを調整し、その管理は社内のGerritのmasterにcommitした時にフックしてCLoudWatchで再構築
と言ったことをしていたのでわかりみな部分も多かった。
クラメソ金曜ロードショー AIに詳しくない人がAIをやってみた話
まず本を見る そのとおりにやってみる データパターンを考えてみる データの入手先を探す 実際にそのサンプルが適当か、AIにする合理性があるかは考えず、まずやってみたというところ 実際に正しいかどうかはやってみたあとにわかるというのも横田DeGoに近いかもしれない
サンプル数が５０以下は不可能なので、映画のタイトルという一人の俳優が出演するのに限界があるものではサンプルが集まるかも厳しい ポスターに写ってる面積から割り出してみたけど別の俳優に認識されたり、人として認識されないので手作業で補正するところもあった そういう苦労をしたのに実際にはポスターの面積は関係なかった など、こういうことはやってみないとわからないという典型例です。
