So What!?

カテゴリ

記事

連絡先

何か間違っている情報などがあればTwitterにてメッセージください。

ご注意

このBlogはアクセスデータをGoogle Analyticsおよび、Cloudflare Analyticsに送信しています。また研究開発用にSentryにパフォーマンスデータを送信しています。それ以外のデータは収集していません。

デブサミ2019夏

2019年7月2日

参加してきた。組織づくり的なセッションが多くて、最近リーダーになった自分にとっては少しでも多くのインプットを行う必要があると思ったから。

各セッションのスライドはDevelopers Summit 2019 Summer、講演関連資料まとめにある。

t_wadaさんは前々から知っていたけど講演を聞いたのは初めてで、目から鱗が止まらなかった。 プレゼンのスタンスはギルドワークスの市谷さんが一番好きだった。

最初に愚痴だけど、明らかに会場のキャパオーバーで、事前登録に乗り遅れた人はほぼ立ち見だったと思う。 バーコードの仕組みも謎で、クラウドに誰がどのセッションに登録しているかをデータとして持っておけば、スキャンした時に止められるんじゃないの。と思った。

及川さん

  • なにかをもつということに価値がなくなってきている
  • デバイスや端末はそれそのものにお金を払うが、Webコンテンツは基本タダ。マネタイズ前提でプロダクトを作らないといけない。
  • AAARRモデル
  • 設計と実装は切りはなせない。ウォーターフォールだろうと出戻りはあってしかるべき
  • PMはwhat, why, when
  • エンジニアはhowに責任を持つ
  • EMはエンジニアを成長させることを通してプロダクトに貢献する
  • TLは成長をリードする
  • マネージャーとリーダーシップは表裏一体
  • アップセルとクロスセル
  • 壊れないシステムではなく、すぐに復旧できるシステムを作る

ラヴァブルプロダクトをつくろうという話。自分が好きなプロダクトってなんだろう?と思いながら聞いてた。やっぱりスマートウォッチかなー。腕につけてないとなんか落ち着かない。 一回チームのタスクを全部洗い出して、各タスクを割り振る形でジョブデスクリプションを作るという方法はなるほど、と思った。

ディライトワークス 上野さん

  • 役立つノウハウを体験だけから得るのは時間がかかる。いろんな人に経験談を聞くルートが必要
  • いいツールを使ったからといっていいものが作れるわけではない。浮いた時間で作り込むため。
  • 何歳までに何がどれだけつくれるかの見通しをたてる。やりたいこととやれることを考える。
  • 不安は進化の予兆
  • 無意識的な選択をしていないか、今の働き方はちゃんと考えて自分で選択したものなのか

自分が仕事を離れるまであと何歳で、それまでにはどのくらいの成果物を作ることができるのか、見通しを立てるのはいいなぁと思った。 自分の場合、年間でつくるWebページやアプリがだいたい10個だとすると、40で前線を退いたとしても仕事で作れるのはだいたい100個。 そのうち自分が一番興味のあるWebGLコンテンツをいくつ作れるのかを考えると厳しい。一つ一つしっかりと作っていかないとと再認識するきっかけになった。

mixi さかいさん

  • エンジニアやチームの意見の重要性をマネージャー以上が理解している
  • ボトムアップだと、意見をいったものが責任感を持つようになる。またリスクに対して寛容になれる(ただし言い出しっぺの法則にならないように。)
  • 学習はしているけど、トップダウンになっている組織は、上からの指示に対してどう立ち回るかを考える保守的な組織になる
  • メンバーを守り、モチベーションを維持するためのルールを作る
  • エンジニアがリーダーとなってプロジェクトをおまかせする制度

全社的に指示待ちな人が増えてきていて、それがボトムアップにつながらない一因かもしれない。学習しているけどトップダウンな組織のくだりは響いた。確かにマネージャーの話をどう受け流すかみたいな話をすることがあったわ。

t_wadaさん

  • 新しい言語で書いてもテストがなければレガシーコード
  • 安全なポイントがあるから攻めることができる。だめだったらすぐに巻き戻せる環境を作っておく。
  • 進化のスピードは環境やプロジェクトによる。だから自分たちでやっていくしかない。
  • テストを書くことは仕様をつめることにもつながる
  • テストは品質の度合いをわかるようにするためのもの
  • リエンジニアリング
    • リファクタリング
    • リアーキテクティング
    • ビッグ・リライト
  • どこからテストをいれるか。
    • 一番ヤヴァいところ
    • お金、個人情報
    • 新機能、バグが出たところ
  • 機能を一覧し、それぞれのリスクの高さをつけていく
    • 一覧したら手動テストのコスト、自動テストのコストをつける
  • テストは繰り返し可能で、独立していることはほしょうすること。これが一番大事
  • テストサイズをきめ、できるだけ小さいテストを多く、大きいテストを少なく

テストは体重計と同じというくだりはわかりやすすぎて、会社ですぐにメンバーに共有した。 テストを書いても(体重計を買っても)、品質は上がらない。(体重は下がらない)テスト(体重計)は品質(体重)を測るためのツールだ。 品質(体重)を上げる(減らす)ためには、リファクタリング(ダイエット)しないといかんのだ。

グリー 森田さん

  • 失敗は許容できるが、能力不足は許容できない。チャレンジするのはいいが、するからには能力を上げたうえで臨むこと。それがチャレンジの無謀の境目。
  • 取引がある会社と研究開発する
  • 社内のソーシャルグラフを活用する

小田中さん、新井さん、市谷さん

  • マシュマロチャレンジ
  • リーダーズインテグレーション
  • 組織に溶けてなくなるチームがいい
  • プロダクトオーナーがやるべきこと