radioc@?

レディオキャットハテナ

【勉強会メモ】Payara&関ジャバイベント

kanjava.connpass.com

  • 日時:2018/10/16(火) 19:00 〜 21:00
  • 場所:サイボウズ株式会社 大阪オフィス

f:id:radiocat:20181016235616p:plain

今回の関ジャバはJakarta EEについてのおさらいと、Payara、Hazelcastの特集でした。 ParyaraとかHazelcastとか何?というのはこのあたりの情報を参照。

ascii.jp

Payaraのほうは概ね理解できたのですが、Hazelcastのほうは個人的に馴染みの薄いプラットフォームなので理解度が低いです。拙いメモになっていますがご容赦ください。

なお、Hazelcastのほうのセッションを担当されていたかたが来られなくなったとのことで、すべてのセッションがPayaraの蓮沼賢志さんによる説明でした。

Session 1: To see the future - Jakarta EE, MicroProfile and Payara

Session 1-1: Jakarta EE Update - October 2018

JavaEE8

昨年秋に策定

↓移管

Eclipse EE4J

JakartaEE working Group

  • Steering Committee
    • Strategic Memberが中心に引っ張る
  • Specification Committee
    • JakartaEEの仕様に関する部分を扱う
  • Marketing Committee
    • どういう方向に持っていくかを考える
  • Enterprise Requirement Committee

Jakarta EE Strategic Members

EE4J Project

  • Project Management Committee
    • Oracleが持っていたJavaEEの資産を引き継いでいく
  • Project Lead
  • Committer
  • Contributer

Migration Status

www.eclipse.org

Roadmap

  • Source Code Moves⇒2018年中
  • EE4J側でGlassFishをビルドし直してJavaEE8の標準であることを証明
  • Jakarta EEのマイナーチェンジ
  • Jakarta EEでの新しいGlassFishを作る
  • Jakarta EE9の開発

※参考

www.infoq.com

Session 1-2: Introduction to Payara Platform 5.183

What's Payara?

  • Derived from GlassFish
  • MicroProfile compatible
  • 365日24時間サポートあり
  • 4半期ごとにリリース
  • 有償版は毎月バグフィクス提供

Payara Platform

  • payara Server
  • Payara Micro
    • 軽量ランタイム
    • マイクロサービス向け
    • ラズパイ上で動かしたという情報もある

Payara's Version

  • Payara 4.1.2.181
    • 4.1.2⇒GlassFish 4.1.2互換
    • 181⇒2018年Q1

Production Enhancements

New Features for 5.183

  • MicroProfile 2.0サポート

Bash auto completion

  • asadmin.autocompleteを読み込むとpathが通る
  • 自動補完がきく
  • Bash専用

Download

https://www.payara.fish/software/downloads/

Session 1-3: MicroProfile 2.0 Overview with Payara Platform

MicroProfile is

  • JavaEEAPIを追加してマイクロサービス向けに作ったサブセット
  • Payaraも初期から主導

Implementations

  • いろんなベンダーの実装を選べる
    • Open Liberty/WebSphere Liberty(商用)
    • Thorntail
    • Payara Micro

Features Overview

MicroProfile 1.0

  • 2016年9月
  • 基本骨格

MicroProfile 1.1

  • Config 1.1が追加

MicroProfile 1.2

  • 2017年9月
  • 以下が追加
    • Metrics 1.0
    • Fault Tolerance 1.0
    • Health Check 1.0
    • JWT 1.0

MicroProfile 1.3

  • 追加
    • OpenAPI OpenAPI v3、実態はSwagger
    • Open Tracing
    • Rest Client
      • TypeセーフなRESTクライアント

MicroProfile 1.4

  • APIは変化なし
  • Java EE7/8両方動く

MicroProfile 2.0

  • ベースとなるJavaEE共通部分がEE8対応
  • Java EE8で動く

Session 2: Thinking Distributed: The Hazelcast Way

Hazelcast

  • 分散コンピューティングを実現するプラットフォーム
  • 2つの製品
    • IMDG(in-memory Data Grid)
    • JET

とにかく世の中にデータが多くなってきた

今後2040年までに年40%ペースで増える

4つのV

  • Volume
  • Velocity
  • Variety
  • Value

Hazelcastの特徴

  • スケールしやすい
  • 障害に強い
  • ピュアJava
    • Javaの標準のAPIを使っている
  • 高パフォーマンス

In Memory Data Grid

3つの役割

  • ストレージ
    • In Memory Caching
    • データストアシステムの間にHazelcastが入ってキャッシュする
  • データ処理
  • データ受け渡し

キャッシング

キャッシング - Hazelcast.com

HD Memory

  • 使うメモリの大半をネイティブ領域に追いやってHeapを最小限にすることでパフォーマンスを上げる
  • Javaのメモリ管理ではGCがパフォーマンスに影響
    • Heapの容量が大きくなるとGCの時間も長くなる

データ処理

  • Executor Service APIを使う
  • Lock API⇒悲観ロック、楽観ロックをサポート
  • Messaging
    • Queue
    • Topic
    • RingBuffer
  • NodeごとにPrimaryとBackupを持つ
    • Nodeの増減によってBackupがリバランスされる
  • MicroServiceのスケーリング
    • Java以外の言語も使える

※参考

kazuhira-r.hatenablog.com

Hazelcast Cloud

今年の8月に発表

hazelcast.com

Management Center

Webベースの管理コンソール

Jet

Edition

  • OSS
  • Pro…OSSにサポート
  • Enterprise⇒追加機能あり
  • Enterprise HD⇒HD Memoryをサポート

hazelcast.com

リリースサイクル

  • 4,5ヶ月ごとにバージョンアップ
    • 直近:3.3、3.4、3.5
  • 3.xのx部分が一致していないとクラスタが組めない
  • 有償版は1メジャーバージョン(3.xのxの部分の1つ違い)の互換性は保証
    • OSS版は無停止でバージョンアップできない

【勉強会メモ】第9回 関西DB勉強会

kansaidbstudy.connpass.com

  • 日時:2018/10/13(土) 13:00 〜 18:00
  • 場所:Insight Technology 大阪支店

※途中から参加しました。

Amazon Aurora Deep Dive

AWSジャパン 藤原 吉規さん

aws.amazon.com

リージョンとAZ(アベイラビリティゾーン)について

  • 東京リージョンは4つのAZ(データセンターを4つの区域に分けて分散化)

特徴

  • データベースをクラウドで利用
  • ハイエンドデータベースのような性能と可用性
  • OSSデータベースのようなシンプルとコスト効率
  • MySQL 5.6,5.7/PostgreSQL 9.6,10

価格

  • MIN:db.t2.small/$0.063
  • MAX:db.r4.16xlarge/64cpu/488/$11.20

https://aws.amazon.com/jp/rds/aurora/pricing/

特徴

  1. スケールアウト、分散、マルチテナントデザイン

  2. ログストラクチャードストレージ

    • もともとのMySQLやPGに変更を加えている
    • マルチテナント
    • 3つのAZに分散(データセンターまたがってデータ保持)
  3. AZに2つずつ計6つのデータをコピーを保持
  4. マスターとレプリカが同じストレージを参照

  5. AWSサービスの活用によるサービス試行アーキテクチャ

  6. Lambda

  7. S3
  8. IAM
  9. CloudWatch

  10. 完全に管理されたサービス - 運用管理作業の自動化

  11. AWS管理でアプリケーションの最適化に集中

  12. 自動化された管理タスク

なぜAuroraに移行?

  • オープンソースエンジンを使っている
    • より高いパフォーマンス
      • 優れた可用性と耐久性
      • コスト最大60%減
      • 簡単な以降
  • コマーシャルDBエンジンからの移行
    • 1/10のコスト

Auroraのパフォーマンス

書き込み中クラッシュからの復旧

Real-life data

  • リードレプリカレイテンシ
    • 通常のMySQL遅延が12分
    • Auroraのレプリカ遅延は20ミリ秒

Auroraの耐久性と可用性

  • 3つのAZに計6つのコピー
  • 最大15の読み取りレプリカが利用・昇格可能

Aurora Driver

  • JDBC Driverと同じように使える
  • Writer/Readerノードの識別

SQLフェイルオーバーのテスト

docs.aws.amazon.com

最大64TBのストレージ

  • 自動ストレージスケーリング
  • 10GB単位で自動増分

高速なデータベースクローニング

  • 重複したストレージのコストを伴わずにデータベースのコピーを作成
  • 元のデータとクローン後のデータが異なる書き込みのみ作成する

バックトラック

  • 時間を指定して特定の時点に戻る
  • バックアップからの復元ではない

セキュリティとコンプライアンス

  • 暗号化
  • SSL接続
  • 監査ログ

移行

マイグレーションAWS Database Migration Service(DMS)

  • 移行時にアプリケーションの動作を維持
    • EC2またはRDSが複製先/元である必要がある(オンプレは不可)
  • Schema Conversion Tool
  • RDS DBインスタンスからAurora Read Replicaを作成
  • MySQLナップショットバックアップから移行
    • mysqldumpから移行の約20倍高速

Auroraの新機能

  • Parallel Query
    • 数千個のCPUを使用
    • CPU課金されない
  • Serverless
    • 自動スケール
  • Performance insights
    • クエリレベルでパフォーマンスをモニタ
    • Hour,day,week,month
    • 35日前まで表示

今秋リリース予定のPostgreSQL 11を徹底解説

日本PostgreSQLユーザ会 澤田 雅彦さん

www.slideshare.net

PostgresSQL 11

  • 150の新機能・改善
  • 約300のコントリビューター

テーブル・パーティショニング

  • 全150件中約1割がテーブル・パーティショニングの改善
  • Partition Pruning高速化
    • 小テーブルの刈り取り/絞り込み
    • 大量の小テーブルがある場合に性能向上が期待できる
  • 実行中のPartition pruning
    • 実行計画作成時には小テーブルを絞り込めない場合に有用
      • Prepared Statement
  • Hash Partition
    • キーのHash値に基づいてデータを配分
    • データが均等になる
  • Default Partition
    • その他を入れる子テーブル
  • Partition-wise Join,Aggregation
    • 子テーブルごとに結合、集約を行う
    • デフォルトではOFF
    • パーティションが多いとプランニングに時間がかかる

できないこと

パラレルクエリ

  • 1つのSQLを複数のCPUで実行
  • ブロック単位でパラレル
  • デフォルトON
  • ブロック度が3倍になると処理並列が1つ増える

サポートされた機能

  • SQL
    • CREATE INDEX
    • UNION
    • CREATE TABLE AS, SELECT INTO, CREATE MATERIALIZED VIEW
    • LIMIT
  • ノード
    • Hash Join
    • Append
  • 読み込みが並列化⇒書き込みはまだ

max_parallel_xxxパラメータ

  • 上限値の設定
    • workers
    • workers_per_gather
    • maintenance_worker
  • 実際の並列数はデータ量等で自動的に使われる
  • 個別の並列度の指定はテーブルごとに指定できる

Parallel Append

  • UNIONやパーティションテーブルへのスキャンで使われる
  • スキャン結果をあわせる処理
  • それぞれのworkerが各プランを並列で実行する

パラレルできないこと

  • CTE
  • VACUUM
  • Window関数

JITコンパイル

  • CPUネックになるような処理で有効
  • ExplainにJITの情報が出る

PROCEDURE

後半の発表に関連するMySQL8.0の新機能の話

Oracle 山﨑 由章( @yyamasaki1 ) さん

MySQL8.0を使ってブロックチェーンを実装する

森崎雅之( @masayuki14 ) さん

https://speakerdeck.com/masayuki14/mysql8-dot-0woshi-tuteburotukutienwoshi-zhuang-suru

使っているもの

ブロックチェーン

  • 分散型ネットワーク
  • 合意形成
  • スマートコントラクト

データ構造の部分だけにフォーカス

MySQLブロックチェーンを実現

  • ブロック⇒Record
  • チェーン⇒Table
  • ハッシュ⇒MD5
  • ハッシュ制約⇒戦闘に0が4つ連続

CTE共通テーブル式

  • 8.0でサポート
  • 再帰的にJOINが実行できる

JSON_TABLE()

  • 8.0で新規追加
  • JSONを表に変換できる
  • 他のテーブルとJHOINできる

まとめ

  • MySQL ShellでDBプログラミング
  • 8.0新機能が便利

【勉強会メモ】Cybozu Meetup Osaka 大阪のエンジニアが好きそうな話

cybozu.connpass.com

  • 日時:2018/10/02(火) 18:30 〜 21:00
  • 場所:サイボウズ株式会社 大阪オフィス

サイボウズさんの広くなった大阪オフィスで初Meetup開催。スクラム開発の取り組みは私のチームと状況が似ている部分が多くとても参考になりました。リファインメントを毎日やっていたり、ふりかえりに合計2時間使っている状況などから、しっかりコミュニケーションをとってチーム力を上げることに注力している様子が伺えます。さらっと説明されていましたが、3チームでスクラムオブスクラムしているということなので、単一チームのスクラムより進め方が難しい面も多い大規模スクラムの事例としてもとても参考になります。

給与交渉については、その制度の是非よりもこういう機会が与えられること自体がとても恵まれた状況だと個人的には思います。私は2度転職しましたが、転職というのは自分の市場価値と向き合ったりエンジニアとしてのキャリアパスについて真剣に考える貴重な機会でもあります。転職せずともこのような機会が与えられ、しかも会社が給与交渉にも応じてもらえるというのは、エンジニア以前に社会人としての成長のために恵まれた環境だと思います。毎年やるのは大変だと思いますが。

今後も継続的に開催して大阪を盛り上げたいとのことで、また次回も参加したいと思います。

大阪-松山-東京-自宅をつなぐリモートスクラム開発 by 太田 絵一郎

資料(デブサミ関西版)

speakerdeck.com

最も難しいリモートタスクって?

  • リモート飲み会

リモート飲み会は無理でもリモートスクラムはやれてるよ

→kintoneの新機能開発チームの話

メンバー構成

  • ほとんど東京
  • 大阪:2
  • 松山:9
  • 上海:2

スクラムの期間・体制

  • 1スプリント=1週間
  • PG5名x3チーム
    • 5人を超えると会議の発言が減るなどチームとしてのパフォーマンス低下
    • 拠点混成チーム
    • 東京に知識が偏っているのでチームで分散する
  • QA、デザイン、TC→3チームのうちどれかに適宜入る

プロダクトバックログ

  • 機能追加、不具合改修、ライブラリアップデートなど全て
    • 不具合改修はバッファでやっていたが忙しくなるとどちらを優先するかを議論しないといけなくなる
    • 常にどちらをバックログの優先順位を議論しないといけないがそこから逃げない

プランニング

  • 設計の議論もする
  • 進め方
    • 全体でスプリントのゴールを決める
    • チームに分かれて議論する
  • 誰かに頼らないとできない状態をなくす
  • その人が休んだら止まるというのをやめる

タスクの実施

  • 常にチーム全員でモブプロ
    • 知識の共有が進みやすい
    • レビューのスイッチングコストが不要になる
  • 常時接続端末をおいてTV会議できる状態をつくる

デイリースクラム

  • チーム別に15分
  • 電子カンバンの利用

リファインメント

  • 毎日30分
    • 不十分だと次のスプリントを開始できない
  • 議論の場をできるだけ確保
    • 短いとリモート会議のあとで延長戦が始まる

スプリントレビュー

  • 営業など全体でやる

ふりかえり

  • KPTを事前に登録
  • 問題がある場合はTryを設定
  • 2部構成
    • チーム別に1.5h
    • 全体で0.5h

スクラム改善の軸

  • 属人化を防ぐ
  • 形骸化させない
  • 職能を超える
  • 無駄を省く

  • 教科書どおりの正しいスクラムに近づける
  • 指揮者のコーチングは近道
  • 達成にはリモートの壁がしばしばたちはだかる

リモートの壁

  • 心理的に相談しにくい
  • ツールに差がある
  • 会議が難しい

リモートスクラムの難しさ

  • スクラムが高度なコミュニケーションを要求
  • どうするか?
    • まずは正しいスクラムの理想像を持つ/教えてもらう
    • その実現に必要なリモート改善を考える

リモート改善

  • 他拠点に出張して一緒に仕事をする
    • お互いに出張して辛さや良さを知る
  • HRT(謙虚・尊敬・信頼)を大切に
  • 会議の進め方を勉強する
  • ツールをいろいろ試す

まとめ

  • リモート飲み会は無理でもリモートスクラムはできる

Salary negotiation battle Round2 on Cybozuサイボウズの給与交渉戦 第2ラウンド)by 佐藤 鉄平, 三苫

従業員パート

従業員から見た評価の流れ

  • 年末に給与について上長と話し合いの機会がもたれる

サイボウズの評価制度

  • 市場価値
    • 社外的価値
      • 転職したらあなたの年収いくら?
    • 社内的価値

2016年の給与交渉

つのる不信感

  • 人事:社外での相場感はだいたいわかる

転職ドラフト - 転職を目的としたサービス - 事前に市場価値がわかる - 良いオファーが来たら真面目に検討する

ボスと交渉

  • 事実と解釈を分けて伝える
    • この技術を欲しているA社からこう評価された
    • 似ている業態の会社と比較して○万のギャップがある

サイボウズで推奨されている議論のフォーマット

会社にどう変わってほしいかを伝えよう

給与はどうなった?

  • 上がったか下がったかは重要じゃない
  • 自分の選択に納得して眠りにつけるよう給与交渉もベストを尽くそう

ボスサイド

www.slideshare.net

市場価値とは?

  • 2つの視点がある
  • メンバー視点の市場価値と会社視点の市場価値

あたりまえ?→そうでもない

  • 建前:まだまだメンバーの巻き込みが足りない
  • 実際:昇給予算が足りない

→ゆがみが起きる

給与テーブルの問題

  • 絶対評価には無限の昇給予算が必要
  • 定義を決めるのは組織側なので交渉が困難

市場価値ベース

  • 正規のルートで正々堂々と交渉ができる
  • 転職時は市場価値で評価される
  • 市場価値が反映されないと
  • 入社時期によって給与が決まってしまう

評価は何のため?

  • 給与の決め方
  • 成長へのフィードバック

→供与評価と成長FBを分離

まとめ

市場価値ベースの給与評価

  • 大事にしていること
    • 自立
    • 多様な個性や働き方
  • これらの実現に市場価値ベースの給与評価がマッチする

大阪について好き勝手喋るLT

大阪っぽくおせっかいする話

@rdlabo さん

  • サイボウズのWebサイトをレビュー
  • Webサイトの速度改善サービスを公開

www.rabify.me

GraphQL SQL

chimame さん

speakerdeck.com

エンジニアが好きそうな話

@QoopMk さん

  • フリーランスでリモートワーク
  • 休憩2時間→美味しいランチを食べに行ける

藤乃(福島)

  • 親子丼とそば

ラ ピッツァ ナポレターナ レガロ(福島)

  • ピザ

かしわやとりあん(中津)

  • 唐揚げ
  • オススメ:おろし鶏あん定食

イルペペ(北新地)

  • イタリアン
  • コースが1000円で食べれる

大阪のローカルメディアに関わって良かったこと

Yukinobu Asakawa さん

bochi2.net

ITコミュニティ@大阪

@mkkn_info さん

  • コミュニティイベントの魅力
    • 人がたくさん集まるイベントがいいイベントではない
    • 人と人とのつながり、技術でコミュニケーションできる

フロントエンドカンファレンス 2018

kfug.connpass.com

【読書メモ】コーチングの手法と実践がよ〜くわかる本

近年、アジャイルな開発のプラクティスやチームのマネジメントでコーチングの手法が取り入れられることが多いので、その手法を紹介している本を見つけて読んでみることにした。

コーチング(英:coaching)とは、促進的アプローチ、指導的アプローチで、クライアントの学習や成長、変化を促し、相手の潜在能力を解放させ、最大限に力を発揮させること目指す能力開発法、クライアントを支援するための相談(コンサルテーション)の一形態である。ただし、世界的に合意された明確な定義は存在しない。

コーチング - Wikipedia

そもそもコーチングとは何なのか、何をしたらコーチングなのかもよくわかっていなかったのだが、Wikipediaによると上記の通り概念的なもので、明確な定義は存在しないようなので、あまり深く考えず、「個人や複数人で構成されるチーム・組織のパフォーマンスを上げるための支援の手法」ぐらいでとらえることにした。

前半はコーチングの基礎的なスキルの話で、コミュニケーションのとり方やチーム活動での人間的な課題発見に役立ちそうな知識が紹介されている。後半になると発展的なコーチング手法の話になってきてカウンセリングや心理学の話まで紹介されている。このあたりはそれぞれの手法ごとに学会があったり、深く研究もされていて、それだけで1冊の本になるようなものなので、概要レベルの紹介になっているが、私個人の今回の読書の目的からすると概要レベルで十分だった。

コーチングのカバーしている範囲が非常に幅広いので深い知識を得るのは熟練を要すると思うが、アジャイルな開発やチームのマネジメントで活かすにはひとまず体系的な知識と手法の概要を把握しておけば十分なのでとても参考になった。

コーチングとは?

コーチングの3原則

  • 人は誰もが自分で答えを見つけ出す力を持っている
  • 人は誰もがパーフェクトな存在である
  • 人は誰もが限りない可能性を持っている

好意返報性の法則

  • 自分に好意を持ってくれる相手には好意を返したくなるという法則

コーチに求められる資質

  • 解決志向
  • 共感的理解

コーチングの進め方基本5ステップ

  1. 安心&リラックス
  2. 現状確認
  3. 目標設定
  4. リソース探し
  5. 行動計画

時間とスペースの確保

  • まとまった時間(30分以上)
  • 座り方(90〜120度)

YESセット

  • YESと言いたくなる話題を振って相手に3回”YES"を言わせる

コーチングの基本スキル

  • ペーシング&ミラーリング
    • ノリをあわせて安心感を与える
    • ペーシング
      • 話すペースをあわせる
    • ミラーリング
      • 見た目をあわせる
  • 承認のスキル
    • 相手を認めて強みに目を向けてもらう
  • フィードバック
    • 見たまま、感じたままを伝えて気づいてもらう
  • 傾聴と質問
    • 頭を整理し発想を広げる

傾聴スキル

  • アイコンタクト
  • うなずきとあいづち
  • おうむ返し

傾聴を妨げる8つのブロック

  • 評価・批判
  • 自分の意見
  • 競争意識
  • 勝手な推測
  • 先入観
  • 興味関心
  • 同一視
  • 感情にとらわれる

→これらは直接的な会話だけでなく内的会話にも現れてしまう

パワフル・クエスチョン

  • 視野を広げたり本質的な部分に切り込む質問

フレーミング

  • 違った視点から捉え直す

ナラティブ・セラピー

  • 人と問題を切り離して物語化する

※参考

「ナラティブ・アプローチ」とは? - 『日本の人事部』

IメッセージとYOUメッセージ

  • Iメッセージ
    • 私はこう思ったという伝え方
  • YOUメッセージ
    • あなたはこうだという断定的な伝え方
    • 上から目線や断定口調になって伝わらない

上司・部下間のコミュニケーション

「無知」の技法NotKnowing

「無知」の技法NotKnowing

コーチングを生み出した心理学・カウンセリング手法

コーチが学んでいる心理学メソッド・関連手法

Rakuten EC Tech Meetup(楽天EC開発の働き方 in 大阪) Vol.2

rakuten.connpass.com

  • 日時:2018/09/26(水) 19:30 〜 21:30
  • 場所:楽天株式会社ー大阪オフィス

f:id:radiocat:20180926234742p:plain:w500

楽天さんのMeetupに初参加。今回は楽天市場を支えるEC部門によるTech Meetupでした。様々な事業を展開している楽天さんでも、実際のお客さんにヒアリングしながら仮説検証をくりかえして小さく生んで大きく育てるアプローチを実践しているというのはとても参考になりました。

開発の最前線で語るAMP / Kim

最近のウェブ業界の動向

Mobile-friendly

  1. いつでも・どこでも
  2. 快適なサービス環境

快適なサービス環境の実現のためにAMPを導入

なぜ速いか

  • グーグルのCDNを活用
  • リソースを事前にキャッシング
  • キャッシングされているページを高速にロード

実現するために

  1. 非同期スクリプトのみ仕様を許容
  2. 全てのパネルのサイズを静的に決定
  3. 外部ライブラリの使用を制限

スマホ版のランキングページ

<link rel="amphtml" href="....">

開発の流れ

原則

  1. 既存のものと同じ挙動を保証
  2. AMPのルールを違反しない

試行錯誤

広告スライドエフェクト

  • スライドエフェクトが独自JSライブラリで実装

解決

  • グーグルが提供している専用のAMPタグを利用
  • amp-carousel
  • amp-list

広告のロード・表示

  • 広告がCookieによってパーソナライズドされている
  • 広告APIのリクエスト先へのURLを同動的に作られている

解決

  • amp-iframe として広告部分を別フレーム扱い

  • 使用目的の制限

    • Googleに問い合わせしてペナルティがないことを確認

インデクシングスキップ

  • AMPページがGoogleのボットからAMPページとして認識されない

解決

  • AMPを判定するボットはPC用のボット
  • PCのページにもamp-htmlタグを追加
    • スマホ用のページだけに入れていた

⇒ページロードの改善

感じたこと

  • メインエンジニアとして様々なタスクを経験
  • 大規模システムの運用に関する責任感
  • どんな状況の中でも道はある

楽天での新サービスの生まれ方 / Matz

プロダクト開発の体制

  • BU:事業部門
  • CWD:UI/UX考える人
  • TECH:開発部門

真ん中にProduct

プロダクトマネージャー(プロデューサー)が主にやること

  • 要件定義⇒SPRINT 1
    • ⇒要件定義⇒SPRINT 2
      • ⇒要件定義⇒SPRINT 2

SPRINT=最短1日、最長1週間

事例1)楽天車検の場合

立ち上げのきっかけ:クライアントの要望

  • 楽天ダイニングを車検に使いたい

⇒事業側から相談

何をやったか

  • ①早い段階でクライアント要望を全て洗い出す
    • クライアント要望が新たにでるたびに「それがなかったら、このサービス夜に出たら許せませんか?」
  • ②動向にデザイン部門を連れて行く
    • 手書きパラパラ漫画で説明
    • IT業界じゃない人には妄想しやすい

結果

  • 最低限のリリースの内容を死守できた

事例2)楽天ブックスダッシュボード

立ち上げのきっかけ:他社サービス追随

  • 最大のミカタ:使ってくれる出版社が協力

なにをやったか

  • ①協力的な出版社からヒアリング
    • すでにユーザーがいる状態であることを逆手に取る
    • 妄想で要件を考える必要が減る
    • ベータ版として利用を制限
  • ②使っている機能だけをまず作る
    • めちゃくちゃ使っている⇒実装
    • 使っているけど使いにくい⇒改善して実装
    • それ以外⇒実装しない

結果:ベータ版リリース⇒正式版リリース

⇒小さく生んで大きく育てる

事例3)楽券の場合

関わったきっかけ:とにかく時間がない

  • 最大のミカタ:営業

何をやったか

  • ①大量の要望を観点別にまとめあげる手伝い
  • ②一緒になって優先度を考える
  • 営業担当にプロダクトの観点を伝授

結果:なんとかリリース

⇒だれでもプロダクトマネージャになれる

まとめ

イデアを形にする方法は自分次第。それが醍醐味

小さく産んで大きく育てるプロダクトマネジメント / Taka

「トレンドアイテムランキング」コンテンツをリリース

prtimes.jp

開発の流れ

  • 企画⇒ここの話
  • 仮実装
  • 実装
  • 展開

総合ランキング上位の結果

  • 上位の商品が強すぎて、変動が少ない
    • ※悪いことではない
  • もっとおもしろいランキングをユーザーに見せたい
  • 小さな種を形にしていく⇒プロダクトマネージャの出番

ゴールを具体化する

もっと面白いランキング

新しい商品に出会えるランキング

まず思いつくランキングを作成

  • 商品ページのPV
  • 商品のブックマーク数

など

イデアの絞り込み方

  • いっぱいランキングを作る
  • 限られた時間でステークホルダーにレビューをしてもらう
  • 効率よくレビュー

ポイント

  • つかみ重要
  • シンプル
  • わかりやすく

ステークホルダーレビュー

  • 意外と良い反応
  • 新しい商品に出会えるランキングには届かず

3つの新しいランキング案

  • 新商品
  • ジャンル別
  • キーワードで絞る

2回目のステークホルダーレビュー

  • 「キーワードで絞った」にスポットライトがあたって掘り下げることに
  • 開発中APIを使ってプロトタイプ作成

キーワードランキング(仮)に決定

  • BBQ⇒肉、道具などがミックスされたランキング

⇒企画・実装・展開⇒9/13にリリース

リリース=ゴールではない

  • おもしろい商品に出会えるように⇒俺たちの戦いはこれからだ