https://gyazo.com/2d7c3ec1b5e59399c8d2ed308aded342
スタートアップ目線での強み
チューニングの土台がすでに出来上がっている
スロークエリを直す本質的な改善に集中できる
採用効果が強い
4人 => 7人に
出勤したら何もしてないのに壊れてた
production, developmentが駄目になってた
起こったこと
status code 502
request headerが怪しい
完全移行後に起こっていたら機会損失額がやばかった
Goode bye Lambda
Hello Elastic Beanstalk
振り返り
インフラの問題はかなりクリティカル
BDDどんなインフラ構成でも移行できる
差分吸収
2018年振り返り
リリースした施策数は100件以上
PV UUともに1年間で2倍に
大きいリリース
ファイルアップロード
目次機能
UI改善
editor画面や記事画面の更新
2重メンテしているのがやばい
覚悟を決める
インフラの負荷試験も兼ねることができる
ファイルアップロード
目次機能
4月中頃にリリースしたい
サービスドリブンな開発
サービスドリブンな開発
効果を最大限に発揮するためのスケジューリング
最前な問題解決を行うための連携を重視した体制
2018/12/15 ローンチの有料サービス
4 => 2ヶ月のスケジューリング
フロントとCAと連携して行った
500円ポイントプレゼント
前澤社長1億円配るのに便乗
3~4倍の会員数に
うまくやってるわけ
フロントエンドの開発環境
モダンじゃないからこそジョインのしやすい工数軽減を図れる
環境構築が必要じゃないから
これからについて
サービスドリブンな開発をより堅牢にしたい
モダン化を進めている
基盤づくりをしている
WebXR Device API（仮）
デバイス
ヘッドセット
mobile Phone
最新の仕様が差し替わった
requestSession
XR Session
canvasを作る
contextを合体
WebGL framebufferになる
Real world coordinate
postion and orientation
xrFrame.getViewerPose(space)
座標のリファレンス
ユーザーのインプットがないと始められない
clickが必要
AR Quick Look
.usdzという拡張子
博物館の展示物が自分の部屋における
開発を担当した三年間の振り返り
デザインエンジニアリング
新規機能追加
大規模改修
技術選定
当初
エンジニアが確保できるフレームワークを選びたかった
型システムをチームで保守可能か？
入れてみても有益なのか？負債になるのでは？と懐疑的
既存コードに乗せることはありがたかった
方を早いうちに導入したのはよかった
よかったこと
プロダクト要件が複雑
常にリファクタが必要
型があって助かった部分がある
やりたい！からの技術選定はあり
チームにもこれをやりたい！という意見が上がった
プロダクトに貢献するか吟味してみてどんどん入れてみる
技術選定で言い切れること
流行り
追っかけたほうが良い
流されない信念も大事
解決策も見つかりやすい
状態管理で悩んだ
でもエコシステムが充実して設計に助けてくれることがわかった
モデル駆動はうまく行った
ステート不利なコンポーネント管理は大事
UIの状態はUIがもつべき
ライブラリの共通点
いろいろ試すと共通点が見えてくる
マジョリティ
他のライブラリで出来ない場合は知識に載せない工夫が必要
知識を切り出すとライブラリに引っ張られない
テストの書きやすいコードに
設計について
賢いUIは移植が大変
フレームワークに知識を載せない
最適解は１つではないが共通項が多い
経年劣化対策を考える
このフレームワークはいつ腐るのか？
将来の自分やチームが助かったと思えるコードベースを考えよう
学んだこと
フレームワーク対策には無意味
やるべきことは悩みすぎる必要はない
成功したこと
React.Hooksに移植して大成功
知識の切り出し成功例
ライブラリには従うべき
切り出しは劣化の備え
将来のコードに役立つ
簡単なチェック
importせずに書ききれるのは上流工程
変化に強いもの
純粋な言語仕様で完結する処理
importをしているファイルは下流工程
寿命が短い
最上流工程
型定義がそれ
すべての処理は定義に依存
型定義が変化すると号令のようにプロジェクトが変化する
言い切れること
フレームワークはいずれ腐る
上流・下流の線引が多いと経年劣化に強い
過剰な線引のオーバーエンジニアリングはNG
頃合いをみて線を引き直すことが大事
まとめ
足りなかったこと
バックエンドの力不足を痛感
良かったこと
任された課題に向き合うことができた
長期運用で必要な考慮が得られた
意識的なアウトプットをしていた
アウトプットを排出することでアウトプットが連結
課題の嗅覚があがった
プロダクト開発におけるスキルと肩書
デザイン本部 サービスデザイン部
IPPF事業部
小説投稿プラットフォーム
プロダクト開発チーム
20名
プロダクトマネージャーに軸足がうつりつつある
モダンなプロダクト開発の２つのフェーズ
Delivery
具体的
プロダクトやサービスを作って届ける
エンジニア
Discovery
抽象的
プロダクトやサービス可能性を見つける
エンジニアも役割拡大化している
Hi-FIプロトタイプ（実際にデータを流して検証）に
どちらに情熱を向けられるか？
どうやって領域を超えるか？
スキル・役割を捉える
デザイン思考
https://gyazo.com/472f7141a4b661839bb40acd703654e3
empathize（理解と共感）
define（問題定義）
ideate
prototype
test
surface（表層）
ビジュアルデザイン
skelton（骨格）
インターフェースデザイン、情報デザイン
structure（構造）
インタラクションデザイン
scope（要件）
機能仕様
strategy（戦略）
ユーザーニーズ、目的
上層の段階ほどより具体的であり、下層の段階ほどより抽象的である
各役割でどの段階を踏んでいるかを再認識
捉えたスキルを自分に当てはめる
デザイナーと同様に画面めっちゃ見る
サイトの構造をどう考えるか
ユーザーインタビューをして解釈する
提供するスキルと提供しないスキル区分け
UIデザインやサービス企画はするが
ビジュアデザインやビジネスはやらない
どういうふうに人に期待されているか？をわかりやすくする
アプリケーションのデベロッパ・アーキテクトとして持続可能な開発体制を作り上げる責務
問題を未来予知する
破綻しにくい設計をする
だいたいは意識できている
サービス提供者としてよりよい体験を提供する
製品のUIをよく触る
ユーザーが不便に思うこと＝フラストレーション
小さなフラストレーションに妥協しない
器用貧乏である
アーキテクチャに真摯に向き合えない
デザイナーと同じく体験やインターフェースについて考えたできの良いものは作れない
表現力を常に磨けるるわけではない
そこそこの領域だけでも掛け算して強みにできるのがフロントエンドエンジニア
改めて何のために専用の領域が生まれているかを見直す
実例から学ぶフロントエンドでできる改善
例：会員登録のフロー
ユーザー名・パスワード入力
サブミット
送信完了
ローディングをつけるべき？がエンジニアの責務
最低処理時間とインタラクションが必要
落とし所や遅いAPIのための設計も考える
ロードの取扱はSPA開発の肝
変なアニメーションはなくてもいいが
ブランドロゴでのスプラッシュスクリーンをつくるといいかも
抑えたフェードアウトがあってもいいかも（感覚による）
https://gyazo.com/989331a9dd86ea820f688bfa2468e496
デザイン思考関連の書籍を見ると良さそう
ゴール
実態を把握する
強味と弱味を適切に理解する
望ましい立ち振舞が何かを理解する
問題提議を責務とする
餅は餅屋
https://gyazo.com/720d2a750a26cfdd8e0683e5d6e10e8a
yamanoku.icon感想
FROKAN初参加だった
DeNAの会場自体は何回か来てるので勝手は一応知ってた
通常の勉強会と同様、資料公開してほしいなと思った
時間的に押していたのか、LT終了時点での懇親会時間があまりなかった
次のLTの間での5分の休憩時間中に交流しておけって感じだと思うけど
noteのやつは何だかんだで結構聞いていたので新鮮味はあまりなかった きいたやつ
元jQueryおじさん（というかデザイナースタート）だったのが衝撃 久々に見たpotato4dさんは金髪味が強くなってた