nDiki : Google

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日全て ]

2019年2月15日 (金)

Developers Summit 2019 2日目 #devsumi

image:/nDiki/2019/02/15/2019-02-15-124522-nDiki-800x1200.jpg

昨日に続き本日も Developers Summit 2019 参加。今日は寒い一日だったのか、途中窓の外にが舞う時間もあった。

昨日参加証の読み取り率が低かったので受付で再発行していただいた。

今日はコーヒー確保できず。今度来る時はやはり何か買ってこよう。

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

10:00~10:45 【15-D-1】 プロダクトマネージャーという生き方

楽天株式会社 熊谷亘太郎氏

プロダクトマネージャー・カンファレンス 2018 1日目でもトークをお伺いした熊谷氏。今回も発表の骨子は同じだったので、今回は復習となった。

メモ

Enjoy your work!

11:05~11:50 【15-B-2】 メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと

ヤフー株式会社 山本学(@yamamoto_manabu)氏

Developers Summit 2016 1日目 で myThings の話をされていた山本氏。今回はマネージャーについて知ってもらいたいという内容で、マネージャー予備軍が響く層であろうという感じのセッション。

12:10~12:40 【15-E-3】 Entertainment x Tech~多くのアーティストとファンを繋ぐ技術と組織~

エイベックス株式会社 山田真一氏

  • 年約250の新規アーティストサイト、現時点で約500を運営。クラウドシフトはステークホルダーが多く順番に。
  • 予期しないバーストトラフィック
  • アーキテクチャは社内アーキテクトで、開発は外部パートナーがエイベックスとしての理想の姿。

アウトソーシング中心での体制構築についての取り組みのセッション。「研修に行かせる」「身に付けさせる」のような表現をみると、トップダウンが強めの雰囲気なのかな?

13:05~13:50 【15-A-4】 3周年に突入するAbemaTVの挑戦と苦悩

株式会社サイバーエージェント 山中勇成(@toriimiyukki)氏

GCP 含めバックエンドで使っているものを順番に紹介していくセッション。浅く全部紹介する感じなので全体的に知りたかった人向けのセッションだ。

14:10~14:55 【15-B-5】 Site Reliability Engineering at Google

グーグル・クラウド・ジャパン合同会社 中井悦司(@enakai00)氏

流れるようなトークに酔いしれてしまうセッション。

  • 50% ルール
    • 50% 以下で運用業務、50%以上をシステム安定化に関わるプロジェクト活動にあてる。
    • SRE(優秀なソフトウェアエンジニア)が Burnout して退職することを避ける。
  • Toil の削減
  • 生涯対応では問題解決を最優先。「他人を頼ること」をスキル不足と認識しない文化。
  • Postmortem (障害ふりかえり)は Google ドキュメントを使っている。全エンジニアに共有されている。

(Google の) SRE についてちょっとではあるが理解が進んだ。目的がすべて明確で、それに対して合理的に取り組んでいるかのようで改めてすごいなと。

15:15~16:00 【15-A-6】 プロダクトをGrowthさせるデータ駆動戦略の基礎知識~DMM.comにおけるユーザーレビュー基盤のKPIツリー公開~

合同会社DMM.com 石垣雅人(@i35_267)氏

データ駆動戦略で成長させていくという話。今回はユーザーレビュー機能に関して。

既にあるものを少しずつ伸ばしていくことにフォーカスしている状況なら、施策に対する予測がしやすいので良いよねというところ。

16:20~17:05 【15-E-7】 セキュアな環境でDevOpsを実現する厳選ツール

マクニカネットワークス株式会社 根本竜也氏 株式会社セガゲームス 上田展生氏

前半は厳選ツール = GitHub Enterprise (GHE) (上田氏)。3年前はまだ Subversion を使っていた。そこから GHE と CircleCI Enterprise を導入していったという話。ゲーム会社だけれど Web 企業とは距離感のある企業風土を感じた。

根本氏は商材紹介。営業っぽい感じになってきたので退室。

17:25~18:10 【15-A-8】 エンジニア人生と定年退職、人生100年時代のエンジニアの生き方

東京大学大学院 よしおかひろたか(@hyoshiok)氏

よしおか氏視点を交えつつ IT 史と概論を語る前半。途中退室。

[ 2月15日全て ]

2019年2月21日 (木)

Google ドライブ ファイル ストリーム駄目だった

MacBook Pro のリプレースにあたり Google ドライブのローカルへの同期を「ドライブ ファイル ストリーム」にしてみたんだけれど、自分の使い方ではデメリットが多いので即日「バックアップと同期」に戻した。

ドライブ ファイル ストリームにしようと思った理由

  • 共有ファイルを気軽にマイドライブに追加してたらどんどんファイルが増えた。
  • ファイルのオーナー引き継ぎを何度も受けてどんどんファイルが増えた。
  • シンボリックリンクがないので「追加」多用しているのだけれど、これバックアップと同期ではローカルにそれぞれ実体ができて無駄な感じになる。

ドライブ ファイル ストリームなら実体はクラウドストレージ側にあるのでファイル数が多くてもへっちゃらではないか。そう思ったわけです。

ドライブ ファイル ストリームにしたら困ったことに

機能比較で「Microsoft OfficePhotoshop などのネイティブ アプリを使用する」とあったので、 Google Chrome 拡張機能の Application Launcher for Drive (by Google) が使えると思ったら使えなかった。ファイルシステム上で開けるという意味だったようだ。この拡張機能がないと「Chrome 上で Google ドライブ検索してからの、ネイティブアプリで閲覧編集」という使い方ができないので劇的に不便になる。

それから Finder (Path Finder でも)ブラウズできないフォルダがあってこちらは致命的な問題。ターミナルで cd していけるのだけれど Finder では駄目。これは駄目。

バックアップと同期に戻す

結局ドライブ ファイル ストリームはやめてバックアップと同期に戻すことにした。 archive フォルダをマイドライブ直下に作ってここは同期しないことにし、いったん全部そこに移動した。

選択同期は面倒なので今まで避けてきたけれどしかたあるまい。今後は作業中のフォルダだけ同期することにする。

今日のさえずり: ドライブ ファイル ストリームだと Application Launcher for Drive が使えないのか……

2019年02月21日

[ 2月21日全て ]

2019年3月19日 (火)

今日のさえずり: Google スプレッドシートの「テキストの回転」て任意の角度に回転できるのね

2019年03月19日

[ 3月19日全て ]

2019年4月9日 (火)

PC でのワンタイムパスワードのシークレットキー管理に KeePassXC を使う

TOTP アルゴリズムを使っている2段階認証/2要素認証のシークレットキーの管理・ワンタイムパスワード生成はスマートフォンアプリの Google Authenticator とIIJ SmartKey を両用している。メインのスマートフォンが使えなくなった時のために、使っていない古いスマートフォン残しておいてそこにもシークレットキーを登録しているのだけれどこれ面倒。バックアップは PC (Mac)で管理したい。

そう思って調べたところ、普段パスワード管理に使っている KeePassX のフォーク版 KeePassXC が TOTP 生成機能をもっているということを知った。

KeePassX の開発保守が停滞していることもあり KeePassXC にこのタイミングで乗り換えつつ KeePassXC で 2段階認証/2要素認証のシークレットキーの管理をしてみることにした。

クロスプラットフォームで公式サイトでは Linux 用・macOS 用・Windows 用のパッケージが配布されている。

シークレットキーの登録

IIJ SmartKey に登録しているキーについてそれぞれ QRコード生成をし別のカメラで読み取り、その中の secret の値を KeePassXC のエントリに登録していく。エントリを作成し(あるいは既存のエントリを選択し) TOTP の設定でキーを入力し保存すれば OK。

ワンタイムパスワードの生成

もちろんワンタイムパスワードの生成にも対応している。これがあればスマートフォンが手元に無くても要 TOTP 認証ネットサービスにログインできる。便利。

パスワードデータベースファイルの管理

KeePass パスワードデータベースファイル (kdbx) に保存されるので、あとは好きな方法でバックアップ

[ Mac アプリケーション ]

[ 4月9日全て ]

2019年5月26日 (日)

Google One 100GB を月間プランから年間プランに変更

年末Google ローカルガイド特典で Google One 100GB 6カ月無料となったので、ロックインの罠にハマる可能性はあると思いつつも利用開始してみていた。

結局その後ストレージを多く使うことも無くもうすぐ6カ月。定期購入の解約する前に「Google One をファミリーと共有」にしていたのアカウントを確認してもらった。そうしたらいつのまにか Google フォトをメインにすでに 15GB を超えていて、 Google One が必要な状態になっていた。スマートフォンで撮った写真バックアップとして使っている(過去に自分が勧めて設定した)ので、この先も少しずつ必要な容量が増えていくだろうしということで無料期間が終わっても Google One を継続利用することにした。

月間プランより年間プランの方がお得なのでこのタイミングで変更しておいた。https://one.google.com/home にアクセスし「設定アイコン」→「ストレージ プランを変更」→「年間プランに変更」で OK。無料期間が終わった時点で年額が請求される。

月間プランから年間プランへ変更できなければ、いったん 15GB 以下にがんばって利用を減らしておいてもらい、月間プラン解約で無料期間終了後に直ちに年間プランで契約しなおしかなと思っていたけれど、その必要は無かったよ。

[ サブスクリプションサービス ]

[ 5月26日全て ]

2019年5月27日 (月)

個人 OKR をやってみる (1)

部門で OKR をやってみよう思う。

その前に自分の理解を深めておくために、個人 OKR を立てて実践してみることにした。あまり考え過ぎずに始めて、疑問にぶつかったり失敗したりしながらやり方を学ぼうと思う。

高速にイテレーションを回して失敗するために、あえて1週間サイクルで始めてみる。

やったこと

  • OKR を1つ立てた。KR は3つ。それぞれの KR にアクションを設定。
  • Remember The Milk に O - KR - アクションを登録(GTD としてすでに入れてあった重複のものを削除)。
  • 毎日 OKR をふりかえるルーチンワークを設定。

起きたこと・わかったこと

  • 自分の中で優先度が上がった。
  • 四半期 OKR は3〜5項目程度とのこと。1週間なのでまず今週は1つで。

トライすること

  • GoogleOKR スプレッドシート (OKR スコアカード) を使ってみる。
[ 5月27日全て ]

2019年5月28日 (火)

個人 OKR をやってみる (2)

やったこと

起きたこと・わかったこと。

  • GoogleOKR スプレッドシートはカスタマイズ前提のシンプルなもので、KR のスコアの平均値をもって O のスコアとする式と、スコアで色が変わる(0.6〜0.7が黄色、それより上が緑、それより下が赤)ぐらいのものだった。
  • バーンアップチャートみたいなのが欲しい。

トライすること

[ 5月28日全て ]

2019年6月27日 (木)

Google One メンバーの皆さまに Google Home Mini を進呈

Google から

日頃の感謝の気持ちを込めて、 Google One メンバーの皆様に Google Home Mini を進呈いたします。

というメールが届いた。タイミング的には Google ローカルガイド特典での Google One 100GB 6カ月無料期間だけれど対象だったみたい(その後、今日のお昼に無料期間が終了して Google One 100GB 年間プランで定期購入更新のメールが届いた)。

今まで無料だったし今日からの1年で2,500円(税込)なので、Google Home Mini 6,480円(税込) (キャンペーン時に3,000円でぐらい家電量販店で売られたりする)の値段を考えると Google One 実質タダみたいな感じだ。

既に1台 Google Home Mini があってどうしようかなと思ったんだけれど、家族に話したら別の部屋でラジオを聞きたいという需要があったので、2台あってもいいねとなった。

[ サブスクリプションサービス ]

今日のさえずり: 青色の灯火。歩行者は、進行することができること。

2019年06月27日

[ 6月27日全て ]

2019年7月3日 (水)

今日のさえずり: 「君の名は。」にも登場したあおい書店 渋谷南口店があった辺り

2019年07月03日

[ 7月3日全て ]

About Me

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

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

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

月別インデックス
Process Time: 0.167167s / load averages: 0.28, 0.48, 0.49
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker