「Developers Summit 2017」に参加しました

2017/2/17(木)～2/18(金) 「Developers Summit 2017」に参加してきました。
もう1ヶ月も前ですが、復習を兼ねてスライド見返しメモ書いておくことにする。

公式サイト
http://event.shoeisha.jp/devsumi/20170216

仕事に都合をつけて２日間の参戦です。
今年も大盛況のようで、通路を歩くのも大変なほど。見ろぉ、人がゴミのよう（略


書籍販売コーナー。欲しい本がいっぱいです。


以下、makopi23が聴講したセッションのメモ。自分の復習用。

１日目

【16-E-1】　Web フロントエンドの変遷とこれから（仮）

Service Workerを使ったオフライン対応

• オフラインでキャッシュを返して、オフラインでも使える
• プッシュ通知も受信できる

Extensible Web

• トップダウンで仕様を決めるのは限界が着ている

夜明け

• ブラウザの限界とか未成熟な疲弊をなんとかしたい
• ないからやる

依存パッケージを積極的に使う文化

• モダンなライブラリはコンポーネント化
• UIをコンポーネントとして扱うことを目指している
• UIもパッケージとして使われることが多い

今、依存しているパッケージの数が多い

• 規模が大きくなるほどjavascriptのコード量が多くなて、それにしたがってライブラリも多くなる
• フロントエンドが太りだす

選定の観点

• githubのスターを見る、とかはあたりまえにやる

うちのアプリ

• loadashやrxはなくてもアプリ作れるライブラリ
• velocity-animateも少ししか使っていない

ビルド　gulpとか使ってる

• 依存関係の強烈さにアップデートが引っ張られる

• 健全な新陳代謝の余地を残す
• ssr : server side rendaring
• 先人の知恵に乗る。位置から構築するよりよい
• ある問題を解く過程で、その問題よりも難しい問題を解いてはならない

【16-C-2】　Google のインフラ技術から考える理想の DevOps

Googleのインフラ技術から考える理想のDevOps from Etsuji Nakai

そもそもDevOpsって何でしたっけ？

• いろんなサイトで定義があるが、DevとOpsがどう共同するのがベストなのか、その定義がない。ばらばら。

Site Reliability Engineer

• 開発者に運用をやらせるのは「若干違うな・・・」と思っていた。
• Googleに来る前に「Site Reliability Enginner」という本を読んだすごいな、と正直思った。
• Googleの中の運用チームは、採用時に、開発者とまったく同じスキルセットを要求する
• Googleのインフラは超巨大なので、運用チームは手作業を減らすためのコード、ツールを開発するかがメインの仕事。
• 「業務時間の５０％以上は手作業してはいけません。コードの開発をしなさい。」とある。徹底的に合理的。
• 「バーンナウト；疲れちゃう」という言葉が本にたくさん出てくる。
• 普通に運用させてるとバーンナウトしちゃう。
• モチベーション高くやらせるためにバーンナウトさせないために、運用チームにコード書かせる。

Googleが開発した分散ソフトウェア技術の例

• Googleはインフラ技術もぜんぶ自分でスクラッチで作ってる。

公開論文から読み解くインフラ技術の「思想」

• アーキテクチャは論文やプレゼンで公開されている。読むとGoogleのインフラの仕組みがわかる。
• 下から全部スクラッチで作ってるので、特定の技術の論文だけ読んでもわからない。
• 下がこうなってるからここがこうなっている、と理解できないと。
• 論文を読んでGoogleのインフラの考え方を説明する記事をいま書いてる。
• 「技術的制約」をただ受入れるのではなく、真に重要な制約を見つける洞察力が強い。
• この制約を打ち破れば、更に先にいけるなら、徹底的に投資をする。
• 一番重要な制約を外すことによって、新しいシステムやインフラができる、という点がポイント。

理想のDevOpsを実現するための隠された視点

• Googleは開発者が運用をしているわけではない。運用チームは専任でいる。
• インフラ・開発・運用の３つのチームがお互いに強力して、世界規模のインフラを運用している。
• 人間の能力は限界があるので、それぞれの分野でベストを尽くすのが合理的。
• 開発チームも運用チームをすごく気にしている。
• 運用チームは５０％以上は運用を手作業できないので、運用に手作業が必要となるアプリを開発チームは作らないようになる。
• DevOpsは「一緒に会議する」というような話ではない。
• チームを分け、プロセスや責任分解点は別れている。真に重要なポイントに叡智を集中する。

この先生き残るために・・・

• フルスタックは合理的じゃないと言ったが、仕事範囲/役割のフルスタックではなく、自分が知っている知識範囲はフルスタックであるべき。
• 全員が同じレベルの知識だからこそ、ただしく分業して協業できる。
• 知識のフルスタックを目指しましょう。

Googleが開発した基盤技術の例

• Borg / Omega
  • アプリケーションデプロイシステム Kubeernetes のGoogle版。
  • Dockerが流行りだして、Googleが論文を出し始めた。
  • 「今頃盛り上がってるんじゃねー！もうGoogleはずっと前からそんなことやってたんだ。」
  • 全世界のデータセンターがコンテナで共通化されている。
  • OSより上のレイヤーだけにアプリ開発者は集中すればいいという責任分解点の考え方。

Googleが開発したデータストア技術の例

• コンテナのローカルにデータを保存するのは駄目パターン。スケールできないしポーダブルにならない。
• ネットワーク上に保存する。
• Google File System / Colossus
  • シーケンシャルリードとアペンドライトしかできないファイルシステム。
  • ランダムアクセスできるけど遅い。
  • 1個上のレイヤーにBigTableがあって、Google File Systemを意識しなくてもよくしている。
• Spanner
  • テーブルでトランザクションしたい人は使ってください。googleは使っている。

Borg / Omega

• OSSとして再実装したものがKubenates。Kubenatesを勉強してください。

Google File System

• Googleで大容量ファイルにどういうアクセスパターンが多いか調査した。
• シーケンシャルリードかアペンドライトだった。
• 一番よく使われているアクセスパスに特化して徹底的にスケーラブルにした。
• 分散する際に、３つ同時に送信するのはネットワーク帯域を1/3しか使えないので無駄。
• そうじゃなくて、キャッシュに貯めながら受け取ったデータを隣のチャンクサーバに送る。ところてんん方式。
• どのネットワークが近いかはIPアドレスで判断している。
• Googleはネットワークも自前なので、配置もわかっている。IPアドレスが近いとネットワーク的にも近くなるように配置してる。
• Googleの管理しているデータセンターでベストな性能を出せるように、下のレイヤーから積み上げている。
• データをメモリに流した後、そろったらドンとライトする。
• プライマーが指示をだして、セカンダリが一斉にライトする。
• プライマリが制御して、全部のセカンダリが同じ順序になるようにしている。

Bigtable

• 行をまたがったトランザクションはできない。Gmailのファイルとかが格納されている。
• Search Engineのクローラーもデータを入れてる。
• 行のキーとしてサイトのURLを使っているけど、URLがひっくりかえっている。
• Bigtableは行またがりのトランザクションができないが、範囲を指定して取ってくることはできる。キー順になると取れる。
• URLを反対にするとcom.cnn.*とかすると、それ全部とってこれる。
• アプリ開発者はBigtableの特定を知っているからこそ、正しいアプリ開発ができる。
• アプリ開発者もインフラを知っていることが重要。

• どうやってランダムアクセスを許しているか。
  • １つの巨大なテーブルを一定のTabletという単位に区切って、それぞれのTabletサーバは自分の担当するTabletを保存している。
  • リードオンリーで保存。ライトは、また別にTabletログの追記式のログにアペンドで追記していく。
  • リードのリクエストがきたら、ログを見て変更が入っていなければそのまま返す。
  • 変更入っていたらアペンドと組み合わせて返す。
  • Tabletログの肥大化はコンパクションする仕組みがある。

まとめ

• Google社内はオペと開発と基盤はチーム分けて合理的にやってるが、全員が同じスキルセット持ってるので合理的な強力ができる。

【16-D-L】　エンジニアが働きたい場所で働けるために、チームに必要なこと

エンシ・ニアか・働きたい場所て・働けるために、チームに必要なこと from 勇樹 岡田

サイボウズの働きやすさを向上させる社内制度についてのお話です。
以前、弊社でもサイボウズの青野社長がこのネタでセミナー講演をしてくださったので、制度の大枠は知っていました。
「ツール、制度、風土」の３つが大事とのこと。
世の中にこーいった流れが広まるといいですね。

【16-C-3】　人気イベントサービスの実例から見るWebサービス・コミュニティ発展のコツ

勉強会やイベントなどの告知を担うWebサービスの開発に関するセッションです。
DoorKeeper、connpass、Atnd、dotsはどれも使ったことがあるサービスだったので、身近に感じますね。


(1) Doorkeeper

• たくさんのユーザがいなくても利益が出せる戦略、積極的な宣伝をしなくてもユーザが集まるビジネスを目指した。
• 人を雇わずに100万円を毎月稼ぎたい。というのも、人の人生を背負うのは大変。
• 前払い機能を開発したが、使ってもらえなかった。
• というのも勉強会やイベントはほとんどが無料だし、有料だったとしても集金は当日現地でする。安いチケットくらい。
• 前払いチケット機能の利用率は2.5%くらいで14万円/月だった。100万円に届かない。
• バナー広告は40万件のイベント申し込みがないと100万円は稼げない。
• Doorkeeperを有料サービスにした。理由もちゃんと説明した。ベンチャーは隠し事をしないべき。
• 有料化したら、ユーザは半分になった。もっと減ると思ってたが、けっこう残ってくれたので励みになった。

(2) connpass

connpassの戦略決定0チームで取り組んだ価値のデザイン from Haruo Sato

成長期の取り組みについて紹介する。

横ばい期間から脱出するために匠メソッドを取り入れた。

匠メソッド

• ステップ０：解決すべき問題領域の発見
• ステップ１：ステークホルダーは誰か？　・・・　これを見落とすと、いろんなものをあとで落とすので慎重にやる。
• ステップ２：自分たちはどのようなサイトを作っていきたいのか？　・・・　ビジョン、コンセプトを決める。
• ステップ３：ユーザのニーズを考える　・・・　ステークホルダーに対して、どういう価値があるのか。
• ステップ４：要求（IT要求）に落とし込む　・・・　要求分析ツリーを使う。ビジョンが左にあって、その手段を右にツリーで落としていく。

匠メソッドへの取り組みによるサービス開発への効果

(1) 建設的な議論が可能になった。

• 機能の単位で話をすると、自分のアイデアがすごいとおもってしゃべるので収集がつかない。
• ユーザの価値に近いところで議論する。

(2) 「要求の爆発」の恐怖から開放

• ツリーなので葉っぱを足すだけでOK
• どこで必要なのかね、をツリーから探すことでミニマムにできる

• このやりかたでやると1日とか3日でできる。迅速な決定ができる。
• 出た問題を一番左の領域にぶらさげることで、その対策の話ができるようになった。

戦略の攻めと守り

• 攻め：ユーザ向け改善
• 守り：運用とか負債解消とか

まとめ

• 時間、リソースは有限
• シーズ、ニーズ、ITの重なるところにリソースを集中する

(3) Atnd

• 2008年からスタートさせた。
• 社内勉強会告知用の「Atnd Internal」を開発している。

【16-A-4】　市場で勝ち続けるための品質とテストの技術

市場で勝ち続けるための品質とテストの技術① from Yahoo!デベロッパーネットワーク

Pivotal Labs

• 従来開発の課題に対応するためPivotal Labsへ修行に行った。
• ユーザに価値を与えるもの以外はすべて無駄、というLEANの考え方があった。

LEAN XP

• プロダクトマネージャー、エンジニア、デザイナーが三位一体で開発していく。

ペアプログラミング

• 各ペアのうち、次の日は一人残って、一人は変える。
• 残った一人が、次に来た人にアウトプットする。これにより全員が案件の仕様に詳しくなる。
• 自分が知らなかったことが知れた。技術力の底上げ。
• 手を抜くエンジニアとかいる場合、ペアプロしたほうがいい。

• 「git duet」というコマンドを使い、一人でなくペアで作業したんだよ、とログを残している。
• ペアプロはプライベートな時間が一切無い。疲れる。
• ペアプロ以外で開発したコードは認めてない。なので定時内に頑張る。
• ペアプロで学習意欲が向上した。

テスト駆動開発

• 失敗するテストをプロダクトマネージャが用意するようにした。

バックログマネジメント

• １つ１つのタスクはペルソナから生まれる。
• シナリオを抽出してストーリー（タスク）に分解する。
• タスクは最も小さく分解した単位。

シナリオ

• シナリオはリアルなシナリオで書く。
• 赤字でポイントを書く。

ストーリー

• ストーリーは受け入れテストできるように最小限にする。
• 非エンジニアでも書けて読めるように、Gherkin formatにしている。

開発の１サイクル

• 「IPM」は見積もりミーティングのこと。
• プロダクトマネージャが受け入れテストする。
• 作った人が受け入れテストをしないことがポイント。

ジャンケン見積もり

• 時間見積もりはしてない。
• あたらない。焦る、いいことない。

結果

• 受け入れテスト失敗数が激減した。
• 受け入れテストの失敗率が減るとエンジニアの自信につながる

総括（Pivotal Labs）

• より小さく価値の高いもの順に
• 単体テストの修復は最優先　・・・　未来に渡って保証してくれる。自信になる。
• 実装は自分以外が確認　・・・　自分は自分の実装を信じてしまうので。

市場で勝ち続けるための品質とテストの技術② from Yahoo!デベロッパーネットワーク

テスト自動化の始め方

• 原則、ユニットテストからはじめる。
• 導入が簡単かつすぐに効果を出せる。

テスト自動化のピラミッド

• まずユニットテスト。一番下で、一番広い。
• ユニットテストが量が多い。障害検知とか一番ROIが高い。

よくやる過ち

• どう教えていけばいいか。よくやる過ちは、座学やワークショップとかをやること。
• ほとんど役に立たない。実際に手を動かしてその価値を体感させない限り、効果が見込めない。

解決策

• Cyber DojoでTDDやペアプロを体感させる。
• サンプルコードでなく、プロダクションコードにユニットテストを入れる。即実践で鍛える。
• 必要になってから、理論やテクニックを深く教える。余裕が出たときに。

byber-dojo

• フリーのサービス。TDDとかペアプロとか学べる。
• 複数人でもできる。誰がどこでハマったかわかる。
• 習わせるより慣れさせる。
• 1ヶ月くらいやると自動化を進められることができるようになった。

罠１：コードカバレッジの罠

• 価値のあるテストをすることが大事。
• どういうテストが価値あるのか。
  • 金額が絡むところ
  • 障害が頻発するところ
  • 頻繁に修正するところ

罠２：テストが作りづらい

• テストをしやすくするツールを探し出して適用する
• 仕様化テストを整備する。その後にリファクタリングする
• 今あるコードをベースにしたテストが仕様化テスト。レガシーコード改善ガイドに書いてある。

罠３：目的を見失う

• 作業のマンネリ化。
• 新たな刺激を与えると伸びるチャンス。
• 短期で目的を設定し、振り返りをやる。

ポイント

• 目的のためによい手段を選ぼう。

ステークホルダー管理

• テスト作成に集中するために環境を作ることもテスト自動化

【16-A-5】　行列ができるECサイトの悩み～ショッピングや決済の技術的問題と処方箋

行列ができるECサイトの悩み～ショッピングや決済の技術的問題と処方箋 from Yahoo!デベロッパーネットワーク

Yahooショッピングのサービス開発・運用の工夫が随所に紹介されていました。
ここまで大規模なトランザクションが発生するシステムの事例紹介は少ないので、とても参考になりました。

【16-B-6】　ユーザ事例と開発手法の二本立て！毎月3万チケットが登録されるRedmine運用と今どきのRubyによるアジャイル開発手法

(1) 前半：東京海上日動システムズの事例

全社導入

• WFが主流だったが、標準ツールとしてプロジェクト管理に使う

見える化のポイントは、標準化とツール

• プロジェクト管理情報でRedmineの使用を必須化

２種類のツール

• 操作性の向上　・・・　ワンクリックで集計・加工
• 見える化

全社展開するためのポイント

• ユーザビリティ（ユーザ満足度）の向上
• 使ってない人に使えと言うのはやってない
• よく使ってる人の声を拾って良い事例を展開していく

改善サイクルの確率

• 多様な利用シーンへの適用
• ４つのルールに絞った。

1. 　プロジェクト階層
2. 　プロジェクト番号＋名称
3. 　バージョン
4. 　トラッカー

• ルールで縛らずバランスを考える。

全社的な推進体制の構成

• 部内やチームの推進役を決める。
• 推進社間のネットワークの構築をし、悩みを共有できるようにしている。
• 役員を含めた上へのコミットメントが大事。全員の強力が必要。

確実に対応出来るプラグイン

• 有償プラグイン Lychee Redmine を導入した。決め手は３つ。

　１．バージョンアップの保証
２．改善，不具合への確実な対応
３．機能拡張の実現

• 社内で使うにはこれらが大事。
• 要望、不満をどうやったら素早く聞き出せるのかを考えておく必要がある。

工夫

• ダブルクリックですぐ編集できるようにした。
• タスクかんばん風のインタフェースを導入して、２重管理しないで住むようにした。

Redmineを推進して大事に思うこと

• プロジェクト管理も変化していく必要がある。現状を変えたい気持ちを持ち続けていく必要がある。
• まずやってみよう、という環境や風土が大事。効果がなかったら分析・改善してまたやってみる。

(2) 後半：開発手法とLychee Redmine


フロー

• Git-FlowからGitHUb-Flowに変えた
• プルリク発行する
• 内部品質を高める
• エンジニアは邪魔されたくないので、自分の好きなタイミングでレビュー依頼、レビューできるようにした。
• テストコードのわかりやすさで、実装コードの質を判断するようにした。
• テストコードは必須。コミットできないようにした。

役割分担、適材適所

• プログラマは画面のテストすらしない。
• レビューが通ったら、あとはテスターにどんどん投げる。

Slack

• だれでもいつでも平等に発言できる。好きなときに返事する。自由。強制的な打ち合わせではない。
• オープンなコミュニケーションで見える化。
• 採用技術も、個人のエンジニアの責任で選ぶ。

なるべくチームプレイ

• ペア営業
• 複数人で見積もり、レビュー
• ペア本番環境構築

信、忍、認

【16-C-7】　「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2017」プレゼン大会

当日の様子はCode Zineで詳しくレポートされています。

(1) ゼロから作るDeepLearning

１．作る経験

• 作れないものは理解できない

２．動かす発見

• 手元で実験
• 疑問に思ったらコードを動かす

３．わかる喜び

• 平坦な言葉でわかりやすく説明
• 数式とコードの両視点
• 最初に数式で迷わない工夫

今は便利な時代になってコピー出来るものが多いが、作る経験はコピーできない。

(2) 暗号技術入門

• 難しい数式は使わず、中学生が読める
• 内容は妥協せず、暗号の最先端まで扱う
• ２００３年が初版
• 改定で全面見直し

(3) 達人プログラマー

• アジャイル宣言の提唱者の二人
• ベテランプログラマによる実践的な心がけと技術的知識が１冊にまとまっている
• 読むたびに新しい発見がある
• 他の本も合わせて読むと当時の背景がわかるかも。情熱プログラマーとか。

総評

• Deep Learningの本は、自分で１から作ることで見えてくるものがある。
• 暗号は昔からあるが、新しい暗号がどんどん出て来る。本か改定されていくのはすごく大切。
• 達人プログラマは読むたびに発見がある。何回も読み返したくなる本。

(4) なぜ、あなたの仕事は終わらないのか

• 中島さんはWindows興隆の礎を作った伝説の日本人。
• 締切は絶対に守るもの、と考えると世界は変わる。
• 要点は、選択と集中
• いかに仕事を減らすかが重要。雑務をバシバシ終わらせて、大事なことに集中できるようにする。
• 残った仕事に集中してどんどん仕事を終わらせていく。最も大事なことに取り組める時間の余裕が生じる。

(5) ITエンジニアが覚えておきたい英語動詞30

• get以外の名詞に注目
• 名詞は普段使っている。なので基本動詞を覚えるだけで会話できてしまう。
• コミュニケーションで一番大事なのは動詞力。基本動詞をいかに駆使して表現力を高めていくか。

(6) 最強の働き方

1. 優先順位
2. 体系的
3. 面白く書けてる

• 世界中の上司に怒られ、すごすぎる部下・同僚に学んだ７７の教訓を書いている。

１．グローバルだが下から目線

４．読みやすさの徹底的なこだわり

　・体系的論理性

　・エンターテイメント

２日目

【17-D-1】　今どきのアーキテクチャを現場の立場で斬る（仮）

【17-D-1】今どきのアーキテクチャを現場の立場で斬る from Developers Summit

この講演の最初にrms（ストールマン）が出てきますが、知らなかったのでググってみた。

• IT業界の最変人、リチャード・ストールマンの偉大な人生 - Naverまとめ
• Wikipedia 

Yagniのジレンマ

• 起きることは必然。いつまでも待っていられない。

合議制のジレンマ

• 合議制で納得感が得られればモチベーションは最高になるが、時間がかかる。
• 一定の人数以上になると、全員が納得することはできない。

決定者のジレンマ

• 一定規模を超えると、ひとりの人間がすべてを把握できない。
• 決定権の委譲は不可避。

ジレンマとの闘い

• 決定者を決めて、決定者が決めたことには従う。

多くのトレードオフ

• 並行処理とか非同期処理は実現が難しい。生産性とのトレードオフ。
• 抽象の漏れ。プロセス間通信とか、抽象化ぜんぶできない。

難しい技術課題が必ず残る

• ４象限の、難しくてメリットが高いもの。なかなか回避できない。

MSA

• 手段として頭でっかちになるのを恐れて最初はMSAにしなかった。
• 最初からMSAを掲げるのは重要だったかも。
• 各サービスがデータストアを持たせるところまではやってない。サービスまたがりのデータストアはあってもいいかな。

マルチテナント

• 最初からはしなかった。
• 低レイテンシのため、シングルテナントがいいかな、と思っていたが、IaaSコストが上がりすぎて変えた。

ステートレス

• APサーバをステートレスに最初からしなかった。
• IaaSコストが上がりすぎてステートレスに変えた。

「戦うプログラマー」が好き。

綺麗事だけで物事は進まない。ブルドーザーのような人たちが進めていく。

【17-E-2】　サーバーレスアーキテクチャにしてみた - エンタープライズチャットアプリでの挑戦 -

サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】 from dreamarts_pr

FaaS: Function as a Service

• AWSやAzureのようなナノサービスを使う

mBaas: Mobile Backend as a Service

僕達のサーバーレス

• ケータイとSSHは嫌いだ
• TDLにケータイ持って行きたくない

なぜサーバレスに行き着いたか

１．金が無い

２．時間がない

３．興味のままでは生きていけない

１．お金

• ナノサービス単位で、使った分だけ課金

Firebase

• モバイルとpcが同期できる
• Heroku使ってるのでサーバレスとは言えないかな。でも自分でサーバ立てるより楽
• Firebaseが中国で使えない説

【17-E-L】　Google Chrome 56登場で待ったなし！30分で学ぶ常時SSL/TLS実装のポイント

常時SSLの課題

１．サーバ証明書の費用

２．サイトアクセスの遅延

３．証明書管理負荷の増加

４．暗号化で十分か

まずはノウハウ貯めるために常時SSLを検討してみる

http/2

１．ヘッダ圧縮

２．バイナリ化

３．接続の多重化

httpsへの301転送が常時SSLに必要

相対パスでhttpでもhttpsでもいけるように書く

なぜ今から

１．webサイトの価値向上

２．セキュリティの強化

３．管理の効率化

【17-D-3】　リーンスタートアップとスマートなエンジニアリングの葛藤

【17-D-3】リーンスタートアップとスマートなエンジニアリングの葛藤 #devsumi #devsumiD from 満徳 関

モノとコトの実現プロセス

• 図で、左側がリーン、右側がスクラム
• 赤と黄色の間に葛藤がある。

リーンから見た葛藤

• スクラム　・・・　２週間後にだせばいい
• リーンスタートアップ　・・・　２週間内でも、だせるなら見せて欲しい
• 両者に葛藤がある。サイクルに乗らない

• スプリントに乗らないタスクどうすればいいのかが、リーンからみた葛藤

アーキテクチャ設計でできること

• アーキテクチャの設計戦略は選べる。
• 戦略３：犠牲的な構造パターンの導入
  • ミニマムに作って、どうせ後で変わるんだから、変えていく。並行運用していく。

リーンでできること

• スプリントのサイクルに入らないタスクは「かんばん」で管理する。
• ユーザーストーリーが確定していなものは「オボチュニティバックログ」で管理する。
• オプチュニティバックログは、PO研修とかでも名前が出て来る。ジェフ・パットンも言っている。

ストーリーテスト

• ストーリーが完了したときを確認する条件
• 昔は「Doneの定義」と呼んでいたが、先月発売の本では「ストーリーテスト」と呼ばれている。

リズムを合わせる

• 左のリーンと右のスクラムのリズムを合わせる。

スプリントバックログとかんばん、どのくらいの割合で工数を見ればいいの？

• 開発チームからよく質問が来る。
• カンバンによくチケットが貯まる状況。例えばリリース直後とか、消費税が変わるとか、なにか起きそうなタイミングは、かんばんに割り当てる工数を多めに割り当てておく。
• かんばんに開発コストを多く割り当てておく。

どう動くと良さそうか

• スプリント始まる前にアーキテクチャは決めておかないといけない。
• ちゃんとしたアーキテクチャを考えるフェーズと、とりあえず開発できればよい最低限のアーキテクチャを決めるフェーズを分けることもある。
• 他のやりかたもある。
• マーケティングとか企画はかんばんに入れるのがいいのかなぁ
• スプリントではまる場所とはまらない場所を管理する場所を設ける

【17-C-4】　正しくプロダクトを作り、リリースプランニングするためのプロダクトオーナーの役割とは

正しくプロダクトを作り、リリースプランニングするためのプロダクトオーナーの役割とは from Narichika Kajihara

• 見積もりはその時点での情報に基づく最良の推測でしかない
• 見積もりはコミットメントではない

良い計画

・定期的に計画を更新

・見通しに対してトレードオフを常に提示し続ける

・意思決定を支援する

スプリントゴールとマイルストーンを置くのが良い。

【17-C-5】　コミュニティとエンジニアの生き方（仮）

勉強会、コミュニティの初まりと成長 Developers Summit 2017 from Yoshinori Kobayashi

デブサミ2017 Javaコミュニティ作ったら人生変わった from Koichi Sakata

• すごい人と触れていると、「上」からの景色がわかってくる。
• 頂上が見えないと、見通せない。
• すごい人に触れて、雲が晴れてくうると上が見えてくる。「あ、あのくらいならいけそうだ」となる。

---

感想

今年も刺激を貰えました。
たまには普段の仕事から少し離れて、こーゆうイベントに参加するのは良いですね。