読者です 読者をやめる 読者になる 読者になる

Scrumからエンジニアのキャリアを考える

本記事ではエンジニアのキャリアについてScrumで定義されているロールから考えてみます。

3つのロール

Scrumでは3つのロールが定義されています。

  • プロダクトオーナー
  • 開発チーム
  • スクラムマスター

それぞれのロールをエンジニアのキャリアという視点で考えていきます。

プロダクトオーナー

プロダクトオーナーとは

  • プロダクトオーナーはプロダクトの責任者
  • エンジニア以外が担うこともある

プロダクトオーナーとしてのキャリア

一般的なエンジニアに求められるスキルよりも、マーケティング等のビジネスサイドのスキルが求められると思います。
ただし、プロダクトの全体のリスクに占めるエンジニアリングリスクの割合も高いと思いますので、エンジニアの知識があるとよい場面も多いと思います。
また、プロダクトオーナーはエンジニアに比べてその人の能力が見えづらいため、具体的な成功実績がエンジニアよりも重要になると思います。
成功しているプロダクトの一部のプロダクトオーナーとして経験を積めばこのようなリスクをヘッジできるかもしれません。

開発チーム

開発チームとは

  • プロダクトの生産者

開発チームとしてのキャリア

開発チームはいわゆるエンジニアのキャリアとして考えればいいと思います。
インフラ、ソフト、DB、ネットワークなどの専門知識をより深く伸ばしていったり、これを全て身につけるように知識を増やしていったりスルことになると思います。 それらの領域はスクラムでは定義されていませんので本記事では開発チームの詳細については考察しません。

スクラムマスター

スクラムマスターとは

スクラムマスターとしてのキャリア

スクラムマスターという名前ではありますが、スクラムではあまり多くのプラクティスが定義されていないため、開発を生産的に行うためのプラクティスを多く身に着けておく必要があると思います。
生産的にするための手法の中には、CI環境等のエンジニアリングの要素も多くあるため、エンジニアのスキルが必要になる場面は多いと思います。 ただ、自己組織化された開発チームでは、スクラムマスターの必要性が低くなります。
スクラムマスターとしてのキャリアを考えるならば、様々なプロダクトに関われる環境にいる必要があると思います。
従って、組織内のプロダクトが少ない場合は、スクラムマスターだけのキャリアを考えることは難しいかもしれません。

まとめ

  • プロダクトオーナーとしてのキャリアはエンジニアよりもビジネスより。
  • 開発チームとしてのキャリアはいわゆるエンジニアのキャリア。
  • スクラムマスターとしてのキャリアを考える場合、様々なプロダクトに関われる環境にいる必要がある。

参考にした書籍

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

アジャイルソフトウェア開発スクラム (アジャイルソフトウェア開発シリーズ)

アジャイルソフトウェア開発スクラム (アジャイルソフトウェア開発シリーズ)

「学習する組織 改訂版によせて」読書メモ

学習する組織――システム思考で未来を創造する

学習する組織――システム思考で未来を創造する

改訂版によせて

サマリ

学習する組織の本題に入る前に全体像について触れられている。

メモ

  • 学習する組織の3つの中核的な学習能力と5つの領域。
    • 志の育成
      • 自己マスタリー
      • 共有ビジョン
    • 内省的な会話の展開
      • メンタル・モデル
      • ダイアログ
    • 複雑性の理解
      • システム思考
  • 組織の基本的な学習単位は仕事チーム(ある結果を生み出すためにお互いを必要とする人たち)
  • 学習する組織の弊害となるマネジメント体型
    • 評価によるマネジメント
    • 追従を基盤にした文化
    • 結果の管理
    • 「正しい答え」対「誤った答え」
    • 画一性
    • 予測とコントロールが可能であること
      • 変化をコントロールするのではなく適用するって感じだろうか?
    • 過剰な競争と不信
    • 全体性の喪失
  • 何よりも変化にエネルギーを与えるのは、開放性、内省、より深い会話、自己マスタリー、共有ビジョンであり、システム全体を見て問題の原因を理解することが決定的に重要である。

「学習する組織 日本語版 訳者まえがき」読書メモ

学習する組織――システム思考で未来を創造する

学習する組織――システム思考で未来を創造する

日本語版 訳者まえがき

サマリ

学習する組織が求められる社会的な背景、相互依存で複雑、変化が激しい、事を紹介し、学習する組織の導入になっている。

メモ

  • 学習する組織には唯一完全の姿があるわけではない。
  • 変化の激しい環境下でその変化に適応し、学習し、自らをデザインして進化し続ける組織が学習する組織。
  • かつてないほど「相互依存」の時代を生きている。
  • 相互依存であるから複雑な社会。
  • 複雑で変化の激しい時代には、多様な関係者が真の対話を重ね、複雑な現実を見つめ未来のビジョンを共有することで、自ら創造し、再生し続ける組織が必要。
  • 安定成長の時代には、効率改善や標準化が常套手段である。しかし、複雑に激しく変化する時代には、しなやかさ(リジリアンス)や多様性を強化することで、長期的な効率の最適化を図る。
  • 安定した成長の時代に私たちの思考や行動の前提として染み付いたメンタル・モデルを浮かび上がらせ、それがこれからの環境や課題状況にあったものかを組織として精査するために、物事を多面的に見て多様性を創造につなげる対話が欠かせないのだ。
  • ただ話し合うばかりでは、皆が望む結果を出せる組織は作れない。どんな未来を作りたいのかの具体的なビジョンを共有し、一人ひとりがそのビジョンを自分ごととして創造的に取り組まなければ前進できない。

PublisherAdViewに動的に広告IDを設定する

PublisherAdViewはGoogleDFP広告ライブラリの広告Viewのクラスです。
このクラスのインスタンスに、広告ID(adUnitId)を設定し、広告リクエストを投げると広告が表示されます。
この広告IDを動的に設定しようとした際に、次のエラーが発生しました。

  • XML上でdatabindingを使ってadUnitIdに対して値を設定すると、Viewには一度しか広告がadUnitIdを設定できないというエラー。
  • XMLでの指定はせずに、コードからfindByViewIdでViewを取得して、adUnitIdに値を設定すると、xmlにはAdUnitIdは必須というエラー。

どうやらコードでレイアウト組み立てるしか方法はなさそうです。

関連する投稿

LINE DEVELOPER DAY 2016 に参加してきました。

参加してきたので簡単にまとめておきます。

雰囲気や印象

  • メイン開場の収容人数が1000人程で、ほぼ満席でした。
  • LINEの海外のエンジニアの方も多く参加されていました。
  • ノベルティが豪華だったり、ヒカリエ11Fのカフェを貸し切っていたりと予算からも本気度がうかがえました。
  • ほとんどの発表が日本語でした。
  • 至る所にLINE要素が盛り込まれていました。
    • このイベント用のLINE@
      • 事前受付の連絡
      • 当日受付で使うバーコードの送信
      • 資料公開の連絡
      • Beaconイベントの紹介
      • アンケート回答
    • BeaconとLINE
  • LINEはWebよりもアプリの会社という事もあり、発表の随所でアプリに関する内容が出てきたことが印象的でした。

午前

  • 午前はオープニングトークとキーノートです。
  • キーノートでは新しくリリースされたサービについて紹介されていました。
  • 詳しくはこちらを参照下さい。

午後

  • 午後はLINEエンジニアの方の発表でした。
  • 発表資料はこちらにまとまっています。
  • 発表動画はLINE LIVEで見れるようです。
  • 非常に具体的な内容が多かったので詳細は資料等を確認頂くとして、私が見た発表について簡単に非常に紹介します。
  • 午後の整理していないメモも一応公開しているのでリンクを張っておきます。

LINEが乗り越えてきた困難な問題

  • 2016/3/11に発生したサービスダウンについて

LINE Login - LINE Platform

  • LINE Loginについて
  • LINE Loginのロードマップ

Security x LINE Platform

  • メッセージや通話のセキュリティについて
  • アプリのセキュリティについて

LINE LIVE を支えるアーキテクチャ

New stream processing platform with Apache Flink

  • LINE LIVEの視聴者数をどのようなシステムで実現しているか

A True Agile Team - Global LINE News

  • 海外のLINE NewsをAgile Teamで開発した話

LINEのエンジニアが働く環境と文化

  • LINEエンジニアが働く環境について
  • 開発文化について
  • 基本的なマインドについて

LINE DEVELOPER DAY 2016 午後 整理されていないメモ

こちらの午後のメモを整理しよう整理しようと思い、数日経ってしまいました。
もう整理することを諦めて貼り付けてしまいます。
網羅性はないし、タイポなたくさんあって、自分にしか理解できない内容になってしまっています。
それではどうぞ。

LINEが乗り越えてきた困難な問題

2016/3/11に発生したサービスダウンについて

  • 1時間40分ダウン
  • デマで炎上する。
  • 今でもテレビ局の取材がある

発生の経緯

  • LINEのきせかえ機能の更新
  • クライアントサイドのきせかえ画像の更新
  • サーバ負荷増大

データ更新の仕組み

  • UEN: ユーザにリクエストしてもらうための通知のサービス
  • サーバからクライアントに通知
  • 通知を受け取るとクライアントからサーバにリクエスト
  • 一斉に通知が飛ばないように全ユーザ通知は時間を分散している
  • 今は3時間程
  • 通常の更新は認証不要
  • ただし、全データ更新の場合は認証必要
  • 全データ更新は更新データが2000を超える場合に、通信のオーバーヘッドを減らすための仕組み
  • 全データ更新は長期間LINEを使って

データ更新の仕組み

  • データ構造の変更が必要
  • 着せ替えの数がテストのときと本番のときで違った
  • 植えたし
  • 2000を超えると全データ更新になる仕組みがあった
  • リクエストのオーバーヘッドを彫らすため全データ更新
  • 全データ更新の場合は認証が必要
  • 全データ更新通知を全ユーザに通知
  • 通常は1日10名程度
  • 全データ更新は時間分散しない
  • 全データは久しぶりに起動したユーザ扱いなので認証必要
  • 認証サービスに障害が発生したのでデータ更新が以外のサービスにも影響が出た

    復旧対応

  • 認証サーバの不可を減らす
  • 全データ更新リクエストが飛ばないようにする
  • 認証種類がある
  • リクエスト制限
  • 認証の仕組みを回収

    対応

  • 全データ更新にも時間分散導入
  • UAMの登録上限を儲ける
  • 認証にサーキットブレーカーの仕組み導入
  • だいたい全箇所(Micoroservices)に再発防止先を入れた
  • 総務省への報告義務(音声通話があるため)
  • 総務省のHPに議事録報告書がある
  • Microservicesが不完全であった
  • それぞれのサービスに自衛の仕組みが必要
  • リクエストバーストを検知
  • 全データ更新のリクエストだと判明
  • なぜ全データ更新なのか。着せ替えの更新をやってるらしい。
  • で判明。

LINE Login - LINE Platform

LINE Loginとは

  • LINE ApplicationからLINE Service(LINE PayやLINE game)を利用する際にLINE Loginが使われる
  • LINEユーザの会員情報を利用したログイン
  • Web/iOS/Androidで実装可能
  • iOS/AndroidにはSDKを提供
  • Autoログイン
  • LINEアプリからの動線のみAutoログイン
  • Web:OAush2.0
  • Native SDK: ApptoApp
  • チャネルの作成が必要
  • 使っている会社
  • niconico
  • ikyu.com
  • Demae-can
  • Rilunabi

LINE Loginロードマップ

  • Official WebApplicationと密に連携
  • Profile + 個人情報を事前登録しECサイトなどで何度も入れるのを避ける
  • New API Plans
    • Phone number Login
    • Social APIの提供。フレンド情報や投稿情報
    • email API
    • LINE@ アカウントをフレンド追加
    • LINEPayと連携

Security x LINE Platform

LINE Architecture

  • ApplicationはLEGYにリクエスト
  • LEGYはルーティングと暗号化が主な責務
  • TLSv1.2
  • ネイティブアプリだとハンドシェイクなどで通信が必要
  • TLSv1.3はハンドシェイクの簡略化がされる予定

    Messaging E2EE

  • iOSAndroidのチャットのみ
  • ユーザの端末でしか復号化できない技術
  • Letter Saling Evalution
  • Group Chat 対応
  • Bの公開鍵、Aの秘密鍵で暗号化してサーバに投げる
  • BはサーバにAの公開鍵のリクエスト
  • BはAの公開鍵と自分の秘密鍵で受け取ったメッセージを復号化
  • グループチャットも仕組みは違うが同じような仕組み
  • サーバも平文を見れないようにしている
  • VoIP(電話)もE2EE
  • ローカルデータも安全に。
  • 削除したら本当に削除する。フラグ立てるだけじゃない

    Risk Assessment

    Reverse Engineering

  • Security Measures
  • 改ざんされてもサーバでブロックできるように
  • 最初の障壁を高くすることは大切
  • ゲームのチート
  • スピードハック、時間のハック
  • 時間取得をフックして偽装するなど
  • ネットワーク
  • HTTPSでも証明書を入れると通信を覗ける
  • 証明書を端末でチェック SSL Piling
  • 短波正
  • サーバサイドのチェック
  • マシンランニングで自動化したいが攻撃側もマシンランニングしているので考えて実装が必要
  • ご検知は0.01%以下でないと使えない
  • he

Anti-Spam/Fame Abusing

LINE LIVE を支えるアーキテクチャ

  • 2014年に追加したLINE LIVE CASTの評判が良かったのでLINE LIVEをうあることに
  • 視聴者数をリアルタイム集計している
  • HLS
    • Appleが開発している動画
    • 小さな動画(2秒)をまとめて動画を配信する
    • CDN使える
    • ビットレート毎に動画のチューニングを行える
  • チャット機能はWebSocket

New stream processing platform with Apache Flink

  • DataLabの体制
    • Planner
    • Developer
    • Analist

LINE LIVEの視聴者数の話

  • 10秒毎に更新しているリアルタイム集計している
  • 求められる機能
    • リアルタイム集計
    • ユニークユーザ集計
    • 耐障害性
  • はじめは norikura を採用した
  • LINE LIVEの仕様追加(だれでも配信)でスケーラビリティも求められるようになった
  • そこで Apache Flink を採用
  • ユニークユーザ集計で消費されるメモリ問題以外は Apache Flink で解決できた。
  • メモリ問題はHyperLogLogで採用
  • HyperLogLogはユニークユーザを推定する
  • 誤差1%以内に収まった
  • 使用メモリが180Gから80Mになった TODO: 後で数値確認

A True Agile Team - Global LINE News

  • 海外に需要があるかわからなかった
  • 6wで完了
  • 経験無し
  • チームも若く、シニアエンジニアがリモートで参加
  • 他国にまたがりコミュニケーションが大変
  • Agile/Scrum
  • 様々な国のチームメンバー
  • Scrumは手法でしか無い。CoreValueが大事。
  • チームスピリット
    • 信頼とコミットメント
      • プランナーと開発者の信頼関係
      • プランナーは正しい
      • コミットメントは守る
      • 開発者だけがスケジュールをコミットできる
      • マネージャ(Scrum master)はアドバイスする立場。コミットしない。
      • Planner -> Why -> What -> Developer -> How -> When -> Plannerのループ
      • プランナーはなぜ開発にそれだけ時間がかかるか納得する節用がアアル
    • セルフマネジメント
      • コミュニケーションを簡略化。Inner or Outer.
      • DeveloperはPlannerとのみ会話
      • Developerは外と会話しない
      • スクラムボードを使った
      • コミュニケーションに様々なツール
      • ダイアグラムを使った
      • FaceToFaceのためにビデオチャット
      • 開発方法論もいろいろ採用UnitTest GitFlow
      • 少しづつ展開していった

LINEのエンジニアが働く環境と文化

  • Github Enterpriceを利用
  • リポジトリ数 2016.9: 10660
  • エンジニアはJapan, Korea, China, Taiwan, Thailand, Indonesia
  • 海外だけのサービスも有る
  • 各国独自のカルチャを理解して開発する必要がある
  • ローカライズだけではなく、カルチャライズしている
  • MicroServicesを採用していることもある1つのプロダクトが1つのオフィスで収まることはほとんどない
  • 多言語のコミュニケーションは英語がマストではなく社内コミュニケーションでも通訳を通すこともある
  • LINEの翻訳BOTを使ってコミュニケーションもしてる
  • 翻訳BOTは社内の需要から出てきたもの
  • なんだかんだFaceToFaceが一番良い
  • 来年は新宿 MiRAINAに移転予定

開発文化

Take Ownership

  • 自分ごととして考える

Take Risk

  • 大前提として物事は計画通りに行くとは限らない
  • だからといっていつも同じ事をやっていてはいけない
  • リスクをどうとるか

Be Open

  • コードはエンジニア全員見れる

基本的なマインド

  • Trust $ Respect -> Self-directed Work -> Positive Peer Pressure -> Trust & Respcetのループが大事
  • Trust $ Respect 信頼と尊重
  • Self-directed Work
  • PositivePeer Pressure
    • 仲良しグループではなくいい意味でのプレッシャー
  • 人事評価が大事
  • マネージャはコードを読んでいないのではないか
  • 同僚からの評価が一番大事
  • マネージャは良いサイクルが回っているかサポートする
  • 今までLINEは秘密的だった気がする

LINE DEVELOPER DAY 2016 午前 参加レポート

Opening & Introduction

ビジョン:Closing the Distance(距離を縮める)

  • コンテンツプラットフォームをライフプラットフォームを連携
  • コンテンツプラットフォーム
    • ゲーム, ニュースなど
  • ライフプラットフォーム
    • LINE@, LINE MOBILEなど
  • 他社とも連携も必要。そのためにOPENに。
  • 長期間BOTを運用してきた。ナレッジが蓄積してきた。
  • 他のアプリケーションをチャットに入れられるようにするChat Extention

Tech Focus

  • Technology for a Large-Scale Platform
  • Augmented/Mixed Reality in Daily Life
  • Data Processing & Machine Learning

Keynote : New world by the LINE BOT

LINE Notify

  • LINE Notifyにリクエストを送ると、LINE Notifyアカウントでユーザに通知
  • OAuth2 / HTTPSで利用可能。
  • OAuth2 を使わなくても Personal Access Tokenも使える。
    • 管理画面でToken作成
    • ヘッダーにToken付与してHTTPリクエスト
  • IFTTT/Github/mackerelとも連携

LINE Messaging API

  • LINE Botは大企業向け、LINE@は中小企業向けで運営してきた。
  • 今までは公式パートナーのみAPI型のBOTを利用可能だった。
  • 本日よりAPIを公開。
  • 公開に伴い一部仕様変更。マジックナンバーをなくしたり。
  • オープンソースSDKを用意。
  • 3機能追加公開
    • Group
      • LINE GROUPに入れるBOTを開発可能に。
    • New Message Type
      • Carousel
      • Confirm(2択)
      • Button(3~5択程度)
      • これらのようにリッチなメッセージが作成可能に。
    • Reply Push API
      • Pushは有料で提供しているが返信は無料で提供。
      • ユーザの投稿にreplyaTokenが付与される。
      • そのTokenを付与してPushすると返信扱いになる。
      • ReplyTokenの有効期限は数十秒。
      • ReplyTokenは1度使うと無効になる。
  • New Message TypeとReply Push APIはLINE Messaging APIのみで提供
  • BOT API Trialは廃止。代わりにDeveloper Trialを開始する。

Rich Menu

  • BOTとのコミュニケーションがテキストだけは不十分ではないか。
  • ユーザは何を送ってよいかわからない。
  • この問題を解決するRichMenu
  • BOTを開くと画像などを載せたサジェスト(Rich Menu)を表示

LINE Web Login from the LINE App

  • LINEのWebログイン機能。Autoログイン機能。ID/PW不要。
  • スマホでの利用を想定。
  • BOTで使うと便利。
  • 例:食べログネット予約(Web)
    • 食べログBOTを開く
    • 食べログBOTがRich Menuでラーメン、焼肉、イタリアン、寿司など表示
    • ユーザが焼肉を選択
    • 焼肉店舗の候補をNew Message TypeのCarouselで複数表示
    • ユーザが店舗を選択し、ネット予約を選択
    • ネット予約画面にいく、氏名、電話番号等の入力が求められる
    • LINE PROFILE PLUSから入力するを選択し、自動入力
      • LINE PROFILE PLUSは公式パートナーのみ利用可能

Iot Beacon

  • LINEのIotの取り組みとしてBeacon
  • Beaconを店舗に設置し店舗に来たユーザにクーポンを発行

LINE BOT AWARDS

  • 優勝賞金最大1000万円
  • 応募受付11月初旬

ユーザはWebのブックマークよりもLINE友達登録の方が気軽にしてくれるでしょ?だからLINE BOT