nDiki : プロダクトバックログ

スクラムプロダクトバックログ (Product Backlog)

フィーチャー・不具合・技術的な作業など、プロダクトに必要でプロダクトオーナーから見て価値のあるものが優先順位付けされて並べられたリスト。

2018年2月6日 (火)

今日のさえずり: チームのかんばんの優先順位会議というかレビューをした

2018年02月06日

[ 2月6日全て ]

2018年2月16日 (金)

エッセンシャル スクラムを読む会: 第16章 ポートフォリオプランニング

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

今のチームでポートフォリオプランニングの運営をしているので、勉強のためチームメンバでエッセンシャル スクラムの「16章 ポートフォリオプランニング」を読む会をやりました。昨年度に別のメンバで1冊通しでエッセンシャル スクラムを読む会をやって以来なので久しぶりです。

今回の自分のパートは以下。

  • 16.5 アウトフローの戦略
  • 16.5 仕掛品の戦略
  • 16.6 終わりに

「プロダクトをいつポートフォリオバックログから取り出すか」についてのアウトフローの戦略は

  • 「作業者の手待ちではなく、作業の手待ちに注目せよ」
  • WIPを制限する」
  • 「チーム全員の準備が整うのを待つ」

がポイントでこれらは、スプリントプランニングに通じるものがあるのでわかりやすいところです。

仕掛品の戦略は作業中のプロダクトについて

  • 維持
  • デリバリー
  • ピボット
  • 打ち切り

を判断するための戦略です。限界費用で考えましょうということ。限界費用が適切に見積もれる必要がありますが、そこが難しいところですね。

16章を通して11の戦略が示されていますが、おわりにの節でどれかを選ぶとしたらとして 11の戦略から選ぶとしたら

  • 遅延コスト
  • 小さめのリリースを頻繁に
  • WIP を制限する
  • 限界費用

だとのこと。参考にします。

やはりポートフォリオレベルでは収益とコストをしっかり考える必要があるなと。

読み直して、やはり今ポートフォリオバックログと呼んでいるのは階層化プロダクトバックログだなと。複数チームで取り組んでいるのでそれはそれで必要なのですが、ポートフォリオプランニングという意味では考え直したいところです。

[ 2月16日全て ]

2018年7月2日 (月)

ポートフォリオバックログのスプレッドシートに概要レベルのプロダクトバックログ列を追加

ポートフォリオバックログ」のスプレッドシートに「概要レベルのプロダクトバックログ」列を追加したら、プランニングでより具体的な話し合いができるようになりました。

  • 各アイテムが何をやるのかが明確になり共通認識になる。
  • 内容が明確になることで規模感を考えられるようになる。
  • 完了条件ではなくプロダクトバックログにすることで、柔軟に再計画できる。

みたいなメリットが生まれました。

今日のさえずり: まだ1年の半分終わっちゃいない! 7月2日正午までまだもうちょい!

2018年07月02日

[ 7月2日全て ]

2018年7月27日 (金)

プロジェクトでみんなをバスに乗せるために書いておく項目リスト

みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。

項目名を整理して決めておくと楽なのでちょっと書き出してみました。

コンセプトシート

比較的軽量にまとめる時。

  • タイトル
  • 概要 (What)
  • 目的(と背景) (Why)
  • ゴール (Goals) and/or 目標 (Objectives)

プロダクトプラン

プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。

  • プロダクト名
  • プロダクトビジョン
    • 概要
    • 目的(と背景)
    • ゴール and/or 目標
    • 成果物
    • 完了条件
    • スコープ(含むの・含まないもの)
    • (opt) 依存するプロジェクト・制約条件
    • (opt) リスク
    • (opt) 予算
    • (opt) メンバ
  • 概要レベルのプロダクトバックログ
  • プロダクトロードマップ

ポートフォリオバックログアイテム

ポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。

  • プロダクト名
  • プロダクトプラン
  • 期間
  • 遅延コスト(ビジネス価値・時間価値・リスク軽減/チャンスと利用)
  • WSJF

プロダクトバックログアイテム

スクラムで1スプリントで完成できるサイズのアイテム。フィーチャーレベル。

タスクチケット

ちょっとしたタスク。

  • タスク名
  • 概要
  • (opt) 目的と背景 (概要で自明でない場合)
  • (opt) 成果物/アクション (概要で自明でない場合)
  • 完了条件
  • 期日

プロジェクト憲章

  • プロジェクト名
  • 概要
  • 目的と背景
  • ゴール and/or 目標
  • 成果物
  • 完了条件
  • スコープ(含むもの・含まないもの)
  • (opt) 依存するプロジェクト制約条件
  • (opt) リスク
  • (opt) スケジュール・期限
  • (opt) 予算
  • (opt) メンバ

備考

他には以下のような形式もあります。

[ プロジェクトマネジメント ]

[ 7月27日全て ]

2018年9月30日 (日)

2018年第2第3四半期ふりかえり

四半期毎にふりかえりをしようと思っていたんだけれど、第2四半期末は後回しにしている間に終わってしまった。第3四半期末も後回しにしてこれを書いたのは10月23日だったりする。

続けたいこと

写真を見に行く (前回: 続けたいこと)

最近行ってないなと思ったけどここ半年43回は行っていた。もっといろいろ見て感性を磨きたいな。

本を読む (前回: トライしたいこと)

最近は通勤時にスマートフォンで Kindle本を読むようにしている。ちょっとずつだけれど時間的にはこの枠が習慣化しやすいかなと。

写真を撮る (前回: トライしたいこと)

毎朝通勤時に1枚撮ることを日課にしたら習慣になった。

それ以外に毎日2枚 Twitter に投稿するという自分ルールを作ったら、撮りためなきゃというのがあってカメラを持って出歩く時間が増えた。 DSC-RX0 が気軽に持ち歩けること・ Lightroom を買って現像が楽しくなったというのも大きいな。

フィルムの方は TC-1 に入れたフィルム写ルンですがまだ撮り終わっていない。今となってはフィルムは撮りどころが難しくて。

自分の Tweet を Retweet する (NEW)

感想を聞いたことはまだないんだけれど、 Retweet したらいいねがつくので継続してみる。

will doリスト作りは前日に(NEW)

前日に will do リスト(クローズドリスト)を作っておいた方が朝の仕事の出だしが早い。前日作れないこともあるけれど、できるだけ前日で。

引き続き続けたいこと(前回: 続けたいこと)

以下はいい感じなので引き続き継続。

改善したいこと

自分の頭で考える (前回: 改善したいこと)

元日に今年意識してみることにしたもの。「情報を遮断して考える」「毎日考える時間をとる」仕組み化できてない。

体力アップとメタボリックシンドローム解消 (前回: 続けたいこと)

自重筋トレ続かず。

ビジネスについて考える (前回: トライ)

関連する本を読んだりするようになったけれどまだ不足している。

WSJF (NEW)

ポートフォリオプランニングの優先順位決めに WSJF 導入しようとしたんだけれど、うまくいっていない。今はほぼない感じになってしまっているので、続けるのかやめるのか判断せねば。

ちなみに「ポートフォリオバックログ」のスプレッドシートに「概要レベルのプロダクトバックログ」列を追加したのは良い感じ。

トライしたいこと

ふりかえりからはなし。

やめるもの

六面立体パズル(いわゆるルービックキューブ) (前回: 改善したいこと)

最近はオフィスでポモドーロテクニック的休憩の間にたまに回すぐらい。忘れない程度にいったん維持できればいいかな。

歩く会 (前回: トライしたいこと)

行きたいとは思っているんだけれど優先度下げ。

アイカツ!

アイカツスターズ! を2年間観たわけだけど、アイカツフレンズ! は観ないことに。最近観ているのは「レイトン ミステリー探偵社 〜カトリーのナゾトキファイル〜」。

iThoughtsX マインドマップを都度 Markdown 形式でエクスポートして Ulysses で管理

煩雑なので続かず。

Day One Premium をキャプチャツールとして使うのを控える

無くてもまわるようになった。次回 Premium プランは更新無しかな。

[ 9月30日全て ]

2018年10月3日 (水)

組織サーベイと見積もりゲーム

アンケートによる組織サーベイ、「スクラムにおけるプロダクトバックログアイテムの見積もり」の最大の目的が「話し合う過程でいろいろな気付きを得ること」だというのと同様に考えて使うのは確かにアリだなと。

[ 10月3日全て ]

2018年11月7日 (水)

プロダクトマネージャー・カンファレンス 2018 2日目 #pmconfjp

image:/nDiki/2018/11/07/2018-11-07-092414-nDiki-800x1200.jpg

プロダクトマネージャー・カンファレンス 2018 2日目。

以下メモ。

10:00 - 10:15 [07-01] Welcome Talk

プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏

今日もタイムテーブルから遅れて 10:10 スタート。

10:15 - 10:45 [07-02] 巨大なFinTech事業開発におけるプロダクトマネジメント

▲株式会社FOLIO 代表取締役 CEO 甲斐真一郎(@folio_kai)氏

経営者という立場でのセッション。金融サービスは一般のネットサービスとは異なる要求がある。また今まで枯れた業界であった。3カ月でできると思ったが2年かかったとのこと。 リリース後に単一プロダクトから異なるビジネス/KPIの複数のプロダクトに事業展開していく中で、個別のアプリケーション部分と共用されるバックエンドという構成になっていきマネジメントが複雑化し始めたとのことだった。

今は全プロダクトを単一の巨大なプロダクトバックログで管理しているのだそうで、今後どうしていくのかぜひ知りたいところ。単一の方が事業全体での優先度が明確になるもののリファインメント含めバックログの管理コストが大きいという問題があり、これはいつも悩ましい判断である。

その他の紹介されていた課題ははエッセンシャル スクラムでも取り上げられているテーマのものが多く、あるあるだなーと。

「愛されるプロダクト」

(まだ FOLIO 社にはいないが)プロダクトマネージャーには「プロダクトへの尊敬」を求めたいとのこと。プロダクトへの尊敬とは何だろう。愛じゃ駄目なのかな。

11:00 - 11:30 [07-03] C向けアプリのPM経験者から見た、B2B SaaSのプロダクトマネジメント

▲株式会社マネーフォワード MFクラウド経費本部 本部長 プロダクトオーナー 今井義人

短期的にはプロダクト改善が最適な改善ではない。人力で頑張るという局面も確かにあるよね。

B2C と B2B の違いはそうだよねで終わりがち。これから B2C から B2B に移ろうとしている人には参考になるかもという感じ。

「愛されるプロダクト」

「愛をお金に変えよう」で築いたエンゲージメントをベースに、より高いプランを作って移ってもらう施策などを紹介。

11:45 - 12:15 [07-04] 気がついたらプロダクトマネージャーになっていた

Nature株式会社 代表取締役 CEO 塩出晴海氏 新規事業での製造まわりのトラブルあるある談を含めた、プロダクトリリースまでのストーリー。プロダクトマネージャーというよりは起業家としての話。あきらめずにやり切る態度は凄いな。

「愛されるプロダクト」

特に話題なし。

12:25 - 12:40 [07-05] リクルートの横断組織で考えるプロダクトマネジメント

▲株式会社リクルートコミュニケーションズ ICTソリューション局 アドバンスドプロダクト開発部 部長 宮里裕樹氏、▲株式会社リクルートコミュニケーションズ ICTソリューション局 戦略企画グループ マネジャー/シニアプロデューサー/シニアプロダクトオーナー 金田將吾氏

細かいところはエンジニアがどんどん進められる組織なので、プロダクトマネージャーは HOW ではなく WHAT に注力しているとのことだった。開発チームのスキルや成熟度によって千差万別なところだ。

プランナーと呼ばれていた人がやっていた役割を

  • ビジネスプロデュース
  • プロダクトマネジメント
  • ITディレクション
  • プロダクトリード

に分けて定義しチーム体制を構築、得意な役割を任せたり不得意な役割を成長させたりしているらしい。しっかりピープルマネジメントに取り組んでいるなあと感じた。

「愛されるプロダクト」

特に話題なし。

12:40 - 12:55 [07-06] 顧客、会社、チームをHappyにするプロダクトマネジメント 〜観点・プロセス・レバレッジ〜

▲楽天株式会社 顧客戦略統括部 Vice Senior Manager 山下徹朗氏

顧客・会社・チームを Happy にする」ことをプロダクトを作る目的として事業を進めている。全能なプロダクトマネージャーは(ほとんど)いないので、ビジネス・UX・マーケティングについてそれぞれ担当を割り当てそれぞれ問いを立て答え続けていくことで結果を出すプロダクトを生み出すという体制を全てのプロジェクトで採用しているとのことだ。

「愛されるプロダクト」

冒頭で「高すぎる目標の」「自己満足な」「誰のためのかわからない」プロダクトという偏った愛あるあるという話を取り上げていた。

12:55 - 13:10 [07-07] Build Narrative in Product

▲株式会社ドワンゴ サービス開発本部 副本部長 池田明啓氏、株式会社ドワンゴ セクションマネージャー 宮城良征氏

前半は、様々な手法を利用・開発してプロダクトマネジメントに取り組んでいるという紹介でとても研究されているなと感じた。知らない手法が紹介されていたので、それぞれちょっと調べてみたいな。

後半は実際のプロダクト開発事例の紹介。

「愛されるプロダクト」

特に話題なし。

13:40 - 14:10 [07-09] The mindset of building the product that user will love

▲株式会社メルカリ UX consultant Jasper WU 氏

Design Thinking についての非常に洗練された圧倒的なプレゼンテーションだった。ベストスピーカー賞があれば絶対 Jasper WU 氏だったと思う。

自己紹介や会社紹介などに時間は割かずセッションのメインテーマに絞ってきちんと語られた。直メルカリのプロダクトについて直接アピールしていないのだが Design Thinking についての取り組みのみの中で出てくる感じなのだが、結果的に組織・プロダクトについて好印象を受けてしまうというマジック。

デザインスプリントで駄目な案だったということがわかったことは失敗ではなく学びだということがきちんと根付いているのが素晴らしいなあ。

デザイン思考についてもきちんと学びたくなった。

「愛されるプロダクト」

一過性のキャンペーンを繰り返すのではなく、継続的な取り組みをしていくことが愛されるプロダクトにつながると言っていた。

14:25 - 14:55 [07-10] 北米・アジア・欧州のプロダクトマネジメントとスマートニュースのプロダクトマネジメント

▲スマートニュース株式会社 プロダクトマネージャ 宮田善孝氏

海外のカンファレンス紹介は、カンファレンスセッションとして知見を広める良いコンテンツだった。

スマートニュースではファンクショナルな組織のもと、プロジェクト毎に人が集まりチームを作るという体制とのことだった。プロジェクト毎にチームビルディングが必要そうだなというのと、機能開発プロジェクト終了後のその保守についてどうなっていくのかが気になった点。ファンクショナルな組織の方で保守していけるのかな。

「愛されるプロダクト」

特に話題なし。

15:10 - 15:40 [07-11] 中国のプロダクトマネジメントのリアル

Baidu, Inc. Product Manager 陈兆伟 (Chen Zhaowei)氏

日本語入力アプリ Simeji のプロダクトマネージャーの方のセッション。

コンピュータサイエンスやビジネススキルの高いスキルが求められる米国とは違い、中国のプロダクトマネージャーはニーズを掴みイノベーションを生み出す能力の方が求められているという話だった。またプロダクトマネージメントが階層化されていて、プロダクトマネージャーの下にプロダクトマネージャーがいる体制らしい。Baidu ではプロダクトマネージャーの役割/スキルについてのテーブルがあり、育成にも力を入れているようだった。

「愛されるプロダクト」

特に話題なし。

15:55 - 16:25 [07-12] Anycaにおけるプロダクトマネジメント

▲株式会社ディー・エヌ・エー オートモーティブ事業本部 Anyca事業責任者 馬場光氏

DeNA もプロダクトマネジメントの定義をしっかりともたれていた。 DeNA でも「全部できる人はいない」という前提で体制化しているようだ。

やはりある程度の規模になるとプロダクトマネジメントの定義・体制化・育成の仕組みが必要だなあ。

「愛されるプロダクト」

特に話題なし。

16:40 - 17:40 [07-13] [ワークショップ] 日本のプロダクトマネージャーは今何をすべきか

東京大学 本郷テックガレージ ディレクター 馬田隆明(@tumada)氏、プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏、プロダクトマネージャー・カンファレンス 実行委員 本登史文氏、プロダクトマネージャー・カンファレンス 実行委員 横道稔氏

馬田氏は「逆説のスタートアップ思考の人」の方。

「なぜ愛されるプロダクトにしていく必要があるのか」また「そのために自分の Next Action は何か?」をカンファレンスの最後にワークショップ形式で考えましょうという枠。聞きっぱなしにさせず、きちんとリフレクションまでカンファレンス内で完結させるという仕組みを入れるところに運営のセンスを感じた。

まわりの人と自分の考えを披露しあってその言語化を相手にさせるというフォーマット、1つめのワークで sli.do というサービスで anonymous で入力させて気持ち的な投稿障壁を下げたあとに2つ目のワークで自社製品名まで書かせるテンプレートで Tweet させるというマーケティング戦術にも恐れ入った。

ちなみに1つ目のワークで自分が考えた愛されるプロダクトについては

わたしは愛されるプロダクトがだいじだとおもっている。なぜなら「チームメンバの士気とパフォーマンスが向上し、さらに良いプロダクトへと導ける」から。

で Next Action については

わたしは「製品名」をもっと愛されるプロダクトにしたい。そのためにわたしは「プロダクトマネージャーを組織化する」。

としてみた。

17:40 - 17:50 [07-14] クロージング

プロダクトマネージャー・カンファレンス 実行委員長 関満徳氏

2日間合計の来場者数速報値は563名との発表。1ホールでのカンファレンスでは結構な人数だ。

[ 11月7日全て ]

2018年11月29日 (木)

スクラムブートストラップ #nNote

  1. [ ] スプリント期間・開始日を決める。
  2. [ ] スクラムインベントをスケジュールする。
  3. [ ] プロダクトバックログリファインメントをスケジュールする。
  4. [ ] プロダクトバックログを作れるようにする。
    • [ ] ツールを決める(付箋・Google スプレッドシート・Trello など)。
    • [ ] 見積もり方法を決める。
  5. [ ] スプリントバックログを作れるようにする。
    • [ ] ツールを決める(付箋・Trello など)。
    • [ ] ふりかえりで決めた改善案も書いておけるようにする。
  6. [ ] デイリースクラムのフォーマットを決める。
  7. [ ] ワーキングアグリーメントを書く場所を用意する。
  8. [ ] スプリントレトロスペクティブのフォーマットを決める。
  9. [ ] スプリントレトロスペクティブのツール(付箋紙・マジック)を用意する。
  10. [ ] 最初のプロダクトバックログを用意する。
  11. [ ] キックオフをする。
  12. [ ] 初回プロダクトバックログリファインメント(内容の確認と見積もり)をする。
  13. [ ] 初回スプリントプランニングをしてスプリントを開始する。
  14. [ ] デイリースクラムを開始する。
  15. [ ] 初回スプリントレビューをする。
  16. [ ] ベロシティを記録する。
[ 11月29日全て ]

2019年2月14日 (木)

Developers Summit 2019 1日目 #devsumi

image:/nDiki/2019/02/14/2019-02-14-145351-nDiki-800x1200.jpg

2015年2016年2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。

朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00〜10:45 【14-D-1】 Scrum@Scale入門

株式会社アトラクタ 原田騎郎(@haradakiro)氏

メモ
  • スケール
    • 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
  • Scrum @ Scale フレームワーク
    • スクラムだけでもスケールする。
    • スクラムマスター(SM)
    • プロダクトオーナー (PO)
      • チームに1 PO。PO チーフ PO。チーフチーフ PO。
      • PO は上位のオーナーが絶対。
    • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
  • PO
    • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。

*1 どんなプロダクトバックログをいくつ用意すべきかを考えるにあたっては、基本原則がある。プロダクトごとに、プロダクトバックログをひとつ用意するというルールだ。-- エッセンシャル スクラム 6.7

11:05〜11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローOSS

GitHub 池田尚史(@ikeike443)氏

GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。

12:10〜12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話

株式会社grasys 長谷川祐介氏

サンドイッチ。HashiCorp 製品と Google Cloud の紹介。それから企業の話についての自分語りを伺えた。

13:05〜13:50 【14-D-4】 大学におけるイマドキのエンジニア教育

ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

前半永瀬氏による enPiT 事例紹介。

後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。

こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。

ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。

東工大生イジりが嫌味がないのも素敵。

14:10〜14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた 〜spanner、GKE導入の実体験から得たこと〜

株式会社コロプラ 廣本洋一氏

  • コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
  • コピーベースで新しいアプリケーションを作ることによる課題があった。
  • ノーメンテナンス時間というポリシーを前提とした技術選択。
  • オーバーエンジニアリングとの戦い。

機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。

15:15〜16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏

ECナビについて2年弱かけて AWS 移行した話。

サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。

別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。

発表者の1人が年末退職済みということで、嗚呼となった。

16:20〜17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話

株式会社ZOZOテクノロジーズ 塩崎健弘氏

BigQuery 移行事例についての、味わいのある発表。

今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。

17:25〜18:45 【14-A-8】 「ITエンジニアに読んでほしい!技術書・ビジネス書大賞 2019」プレゼン大会

高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーション投票・発表のセッション。

[ 2月14日全て ]

2023年6月29日 (木)

今日のさえずり: 縦型通帳が使える ATM ずいぶん減ってきていた

  • 09:31 さようなら「ぱ・る・る」 1997年1月25日の繰り越しから26年使ってきた「ぱ・る・る」縦型通帳がついに終わった。
  • 09:40 縦型通帳が使える ATM ずいぶん減ってきていた。
  • 16:31プロダクトバックログアイテムがタスクリストになり、スクラムチーム全員が興味を持てない」状態になるなどを避けるための手段の提案。スクラムにおける現実的最適手段の選択 - INVEST編 - KAKKA is not 閣下 https://kakkablog.hatenadiary.jp/...
  • 16:38 『エッセンシャル スクラム』に INVEST の解説があった。
  • 19:16 LINE BLOG 今日サービス終了だった。お疲れさまでした。
  • 24:24 2023年6月29日 (木) したこと - 「ぱ・る・る」縦型通帳から普通の通帳に繰り越す
[ 6月29日全て ]

About

Naney Naneymx

Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。

※本サイトの内容は個人的見解であり所属組織とは関係ありません。

Process Time: 0.02415s / load averages: 0.34, 0.31, 0.26