2020/02/14 に開催された Developers Summit 2020 Day2 のイベントレポートです。

■Day1の様子

■チーム・ジャーニー 〜逆境を越える変化に強いチームをつくりあげるまで〜

市谷 聡啓 さん [DevLOVE]

●自己紹介
・最近の仕事
　　DX支援
　　仮説検証、アジャイル開発の実践支援
　　仮説検証型アジャイル開発でのプロダクト開発
　　公演、研修、執筆
・チーム・ジャーニー
　　本日先行発売中！
・プロフィール
　　https://ichitani.com/

●われわれがプロダクト開発で直面する最大の難関とは？
・不確実性とどう向き合っていくか
・プロダクト開発での不確実性
　　絶対的な正解をあらかじめ手にすることはできない
　　さまざまな期待は寄せられる
　　意思決定、合意形成が難しい
　　理解不足や練度不足で成果につながらない
・組織変革での不確実性
　　DXで組織変革に乗り出すが
　　プロダクト開発と同じ問題に当たる

●変化の傾きが急すぎる
・今までのやり方を変える必要がある
　　なんで変えなきゃいけないんですか？
　　これまでが引寄寄せる重力を突破できない
・分断が二項対立世界をつくる
　　一方を通すために、もう一方を格段に低評価する
　　アジャイルを通すために、未だにウォーターフォールやってるの？
　　-> ソフトウェア開発のこれまでのアプローチ

●変化格差にどう立ち向かうか？
・段階の概念を取り入れよう
　　変化が急勾配なら、段階を置いてなめらかにする
・段階を経るごとにこんなはずじゃなかったに出会う
　　その都度向き合うことは必要
・カイゼンジャーニーでも段階を経ていた
　　一人で、状態の見える化
　　二人で、チームで

●全体性の欠如
・ウォーターフォールとアジャイルの二項対立
　　どこにたどり着けるのか
　　を描かずに始めがち
・組織を変革していく場合に周りを巻き込んでいけるのか？
・agile
　　少しずつ繰り返しながら形づくる
　　これで全ての粒度に立ち向かえるわけではない
・1週間のタイムボックスと、単一のリストだけ
　　自分たちの意思を形にするのは難しい
　　自分たちの希望を「あーそれそれ」と話せるか

●段階の設計
・目的地を見立て、たどり着くために必要な状態を構想
・構想自体を変化させる
　　進めた結果から、わかったことに合わせて
・段階の青写真が当事者に方向性を与える
　　チーム、ステークホルダーで共通認識が必要
・段階 = ジャーニー
　　一般的な用語なので名前をつけたい
　　かかるタイムボックスは段階のミッション次第で可変

●DXジャーニー
・DXでやること
　　組織のトランスフォーメーション
　　ビジネスモデルのトランスフォーメーション
　　開発のトランスフォーメーション
　　業務のデジタル化
・一気にできる？
　　段階を踏みましょう
・SoEで進め、チームの練度を高める
　　整ってから本丸のSoRへ

●仮説検証型アジャイル開発
・これも段階を踏んでいる
　　仮説検証ジャーニー
　　MVP開発ジャーニー
　　MVP検証ジャーニー
　　-> わかったことでPBLを見直し

●チーム・ジャーニー
・チームの成長にも段階が必要
　　いきなりスクラムに取り組んで
　　失敗して問題ないなら失敗すれば良い
　　多くはそうではないはず
　　段階を踏みましょう
-> ジャーニーは重なり合う
　　かなり複雑なことをやっていることを意識しよう

・ジャーニー = 段階的発展 = 進化
　　意思のある進化を仕組み、見直していく
・だれかが10年かけてたどり着いた場所
　　これに3ヶ月で挑む
　　冷静に考えよう

●リーン・ジャーニー・スタイル

・選択肢を広げ、絞り込む
　　仮説検証をセットベースからポイントベースへ
　　セットベースはリーン製品開発の言葉
・メンバーの多様性を生かして選択肢を広げる
・段階の設計
　　分からないなりに構想を決め、進めていく
　　次のジャーニーでは逆のことをやるかもしれない
・動的にフォーメーション、チームの主義を選ぶ
　　ジャーニーのミッションに合わせて

●重奏的仮説検証
・第1段階 仮説の外在化
　　POの解釈を一方的に伝える
　　-> 仮説キャンバスで仮説を外在化
　　　　わかっていること、わかっていないことを外在化
　　　　そうだったの？を表明できる
　　仮説キャンバス
　　　　14の問い
　　　　プロダクト開発は問いに答え続けること
　　POの視座をプロダクトのボトルネックにしない
　　　　プロダクトオーナーの民主化
　　　　PO一人の視座・視野
　　　　-> チームの視座・視野
・第2段階 仮説検証の重奏化
　　チームとして合意した仮説以外に
　　メンバーそれぞれの中に仮説を描く
　　よくある質問
　　　　チームを仮説検証に巻き込むには？
　　　　POを仮説検証に巻き込むには？
　　同じことを考えているが、変化が大きい
　　第1ジャーニー: 事前学習
　　第2ジャーニー: イベントベースの検証
　　第3ジャーニー: 継続的な検証活動

●意味あるものを作り出したい
　という思いはPOだけのものではない
・このあり方の先にあるものとは？
　　ともに考え、ともにつくる
・6年前なら 正しいものを正しくつくる と言っていた
・チームや関係者の中心に仮説を置いて
　　ボトルネックを越えていく
・これを続けていくには？
　　現実には二項対立、変化格差
・お互いの関係性に意味を見つける
　　われわれはなぜここにいるのか？
　　「われわれ」であることが大切

●自分のミッションと役割を問い直し続ける
・ミッションやフォーメーションは変わり続ける
・専門性は自分の好きなことを磨けば良い、必要なこと
・ただ「だから私の役割はこれです」では
　　プロダクトづくりには適応できない
　　自分の理解している役割定義の内側での最適化になってしまう
・このチーム、ジャーニーにおいて自分の役割は何なのか？
-> 「あなたは何をする人なのですか」
　　カイゼン・ジャーニーで話したこと

●カイゼン・ジャーニーのよく聞く感想「難しいですね」
・いつもこのタフな問いに答えきれるわけではない
　　だからこそチームがある
　　ともに在る誰かがいる

自分は何者にもなれやしない
誰かとともにいることで、何者かになれる

ともに考え、ともにつくる
だから、ともに越えられる

あなたのチームも段階を経れば
きっとどこかにたどり着けるはず

■守りのモニタリングから攻めのモニタリングへ

大谷 和紀 さん [New Relic]

●モニタリングといえば
・障害を検知して、担当者を叩き起こして、仕事させる
・MTTRを短縮する
-> 他にもできるのでは？

●自己紹介
・Customer Success Manager
・New Relicは去年の11月から
前の仕事でずっとNewRelicを触っていた
・AWS, Scala, Go, Make
どちらかというとアプリを書く
・ajito.fm 準レギュラー
・ボルダリング

●New Relic
・こんなサービス
　　いろいろな情報を集めて
　　可視化して
　　ビジネスに役立てるクラウドサービス
・データの流れ
　　ブラウザ、モバイル、センサー
　　コンテナ、VMなどの情報
　　-> NRDB
　　-> NewRelic ONE
・20億イベント/分 以上
　　yahooで 400億PV/月
・17,000社+
　　ビジネスパフォーマンスの計測、可視化
・モニタリングでリスクのあるデプロイができるようになった

●Observability成熟モデル
・step0 計測をはじめる
・step1 受動的対応
・step2 積極的対応
・step3 予測的対応
・step4 データ駆動

●step0 計測をはじめる
・SRE: The four golden signals
　　Latency, Traffic, Erros, Saturation
　　-> Serverアプリなら？
　　-> Browserアプリなら？
　　-> Mobileアプリなら？
　　-> データエンジニアなら？
・オブザーバビリティとは？
　　監視
　　　　動いているか？
　　オブザーバビリティ
　　　　どう動いているのか？
・アラートが来て調べに行ったら落ち着いていた
　　原因を蓄積して
　　分析できる必要がある
・4つの柱
　　Metric
　　Event
　　　　NewRelic独自
　　Log
　　Trace

●デモ
・処理時間
-> どの処理に時間がかかった？
-> どのクエリに時間がかかった？
　　Avg calls
　　　　MySQL inventory_table select 64
　　　　n+1問題
・web app, mobile app などで見える項目は違う
・3ステップくらいでAPMが使えるようになる

●step1 受動的対応
・アラートが頻発している
　　まずは落ち着かせる
・この箇所が遅い
　　見つけて、改善していく

●step2 積極的対応
・何かが跳ねたときに問題が起きるかもしれない
　　先回りして不安定さをなくす
・サービスレベルを考えていく
　　可用性
　　レスポンスタイム
　　SLI -> SLO
・ユーザ体験の定義
　　一覧->詳細->カート->購入
　　一覧が遅ければ離脱
・アラートの前に定常状態と違う挙動

・New Relicでのサイクル
　　どうしたいのか考える
　　計測
　　可視化
　　基準を決める
　　パフォーマンスを上げる
　　運用に合わせる

●step3 予測的対応
・コスト削減に関心がある人は多い
　　まずは3倍のリソースを確保することが多い
　　予測で 1/2 で済むことも
・避難訓練
　　99%の可用性 = 1%は動かなくても良い
　　　　-> エラーバジェット
　　本番でどこかを止める
　　　　検知から回復までを試す
　　　　可用性 99%なら、本来は大丈夫なはず
　　でも不安がある
　　　　備えて大丈夫になったら、実際に落としてみる
　　　　ダメなら直しましょう
　　夜中ではなく、業務時間帯に
・リスクのあるデプロイを試す
　　Testing in Production: the hard parts
　　成長企業の方がデプロイ頻度が高い

●step4 データ駆動
・デプロイの副作用
　　CPU使用率下がった
　　どこかでバグが発生した
・顧客満足の向上
　　NPS

●まとめ
・ツールと文化
　　observabilityチームのゴールは
　　データを集めることではない
　　事実に基づいたエンジニアリング
・壮大さん
　　ツールが変わると運用が変わる
　　運用が変わると文化が変わる
　　文化がプロダクトを育てる

■自己組織的な開発チームを如何にして作り上げるか

木利 友一 さん [TIS]

銀の弾丸はないが気をつけるポイントはある

●自己紹介
・TIS
・ITアーキテクト
・モード2の不確実性に切り込む
・大学院で自己組織的ネットワークを研究

●TIS
・バイモーダルに対応するSIerを目指す
・Fintan
　　ノウハウを集約したサイト

●やりたいこと
・複数の会社の混成チームで
　　自己組織的なチームにしていきたい

●自己組織化
・外部からエネルギーを取り込み続ける
・個々はバラバラに行動
・いつの間にか全体の秩序ができる

●自然界の自己組織化
・個々のアリ、群れのアリ
　　餌への最短経路を効率よく見つける
・ホタルの発光同期
　　近くの蛍の光に刺激を受けているだけ
　　指揮者はいない

●自己組織的なチーム
・意思決定の機会や精算的に前進するとき
　　リーダーから独立して機能するチーム

●チームのフェーズ
・サバイバルモード
・学習モード
・自己組織化モード

●参画したプロジェクト
・サバイバルモード
　　明確な指示系統
　　リーダーベースでタスクアサイン
・スケールしない
　　人数の増加
　　システムの複雑化
　　→判断が雑になっていく
・フロー効率が下がる
・リーダーとして
　　全てを把握
　　全てを理解
　　正しい判断をしたい
-> 把握できる箱庭を作ろうとしていた

●VUCAの時代
・状況も刻々と変わる
　　目指すべきプロダクトの姿
　　開発のボトルネック
・現実は複雑
　　1人のリーダーが指示するのは無理

●今のチーム
・個別具体的な指示は不要
・今日公演してるが、現場は問題なく回っている

●チーム
・個人の行動
・個人間の相互作用

●SECIモデル
・個人と個人をつなぐ
　　相互作用させるための場
　　がなければ回らない

●ファシリテーション
・人と人の知的相互作用を促進する働き

●個人の尊重
・全員が完全に同じベクトルを持つ必要はない
・チームの動く方向が不安定になる
　　今その瞬間、その人が誰よりも詳しい分野がある
　　その人だけが感じている変化がある
・チームの進む先をリーダーが限定しない

●個人の行動
・説明責任を伴わせる

●個人間の相互作用をファシリテートする
・チームが成長すると、今のプラクティスは陳腐化する
・フィードバックをくれる信頼関係をつくる
・人間には学ぶ力がある
　　変化を起こす
　　結果をふりかえる
・学習性無力感と戦う
　　何をしても意味がない と学ばせてはならない

●まとめ
・個人の尊重でチームは不安定化
・個人間の相互作用のファシリテートでチームは安定化

タックマンモデルから
エラスティックリーダーシップに50年

経験を共有して
私たちのSECIモデルを回していきましょう！

■デザイナー/リサーチャー/エンジニアが語る、UXとの関わりかた

松薗 美帆 さん [メルペイ]
山本 興一 さん [スマートニュース]
重田 桂誓 さん [クックパッド]

●自己紹介
・山本さん
　　スマートニュース
　　プロダクトデザイン
・松薗さん
　　メルペイ
　　UXリサーチャー
・重田さん
　　クックパッド
　　UXエンジニア

●山本さん
・Product Designというロール
　　両輪となる作業の分類
　　　　Product Design
　　　　Product Management

・プロダクトビジョンの正しい具現化
　　どんなプロダクトをつくるのか
　　どんなビジュアルで、そんな操作感で実現するのか
　　正しさを求めてデザインすることが重要

・What
　　ミッションに適合するのか
　　スケジュール的に実現可能か
　　ユーザに正しく伝わるか

・現在までの経緯
　　2006
　　　　趣味のウェブサービスがきっかけで状況
　　　　どんなサービスだったの？
　　　　　　CGM
　　　　　　お絵かきの軌跡を残し、共有
　　　　フリーランスのウェブデザイナー
　　2008
　　　　ウェブサービスのスタートアップ
　　　　モノづくりは自分だけ、いろいろなものに携わる
　　スマートニュースへ

・プロダクトデザイン
　　各フェーズをチームで担当する
　　　　企画
　　　　ユーザーサーベイ
　　　　インパクト評価
　　　　UXデザイン
　　　　レビュー
　　　　プロダクト仕様書

　　ユーザーサーベイをProduct Managerがやるの？
　　　　クーポン機能の場合
　　　　Product Manager, Marketerがやっていた
　　　　つくるもの次第
　　Engineerのレビューの観点は？
　　　　期間中に実現可能か？

・UXデザイン
　　デザインという作業は
　　氷山の隠れた部分を考えること

　　スマートニュースのクーポン機能は
　　ユーザーにとってどうあるべきかを考える

　　お得だから食べたい
　　　　-> 美味しそうだから食べたい + お得

　　どうレイアウトしたら美味しそうに見えるか
　　ブランドのトップページに載っている写真は美味しそうに見える
　　+ お得感

・ひろがり
　　いろいろな立場を経験することで
　　多様な視点を持つことができる
　　ユーザーになりきって発想することが必要

・軸を持つことが必要
　　Product Designという役割に
　　ニートという経験をどう繋げられるか
　　きっかけとなる軸を持つ

・Product Designを選んだのはなぜ？
　　渡された名刺に書いてあったw
　　ので、必死に学んだ
　　どうあるべきか、どう会社に貢献できるか

　　やくわりを与えられた瞬間に
　　経験がつながった感覚があった
　　与えられなくても、自分でつくっていたと思う

●松薗さん
・メルペイのUXリサーチャー
　　アメリカではメジャー
　　日本では100人いないかも
　　UXリサーチをやっている人は結構いる
・人類学選考 -> リクルート -> メルペイ

・メルペイのUXリサーチャー
　　お客様の豊かな体験を実現
　　本質的な問い
　　あらゆるリサーチ手法
　　鋭い洞察で事業の意思決定にコミット

・どう「本質的な問い」を考える？
　　リサーチやりたいがくる
　　なぜやるの？わかってどうするの？を一緒に考える
　　チーム立ち上げ時は受動的な活動
　　-> 少し先を考えて動くようになった

・リサーチ対象
　　お客様
　　社内
　　　　カスタマーサポート
　　　　法人営業
　　加盟店

・Weekly UX Research
　　毎週社内にお客様に来てもらう
　　PdMやデザイナーはリアルタイム中継で参加
　　-> 即デザイン修正、要件反映
　　翌日には簡易レポート

　　レポートはGoogleDocs
　　提案を出して、開発可能か判断してもらう

　　エンジニアとの関わりは？
　　　　ちょっと遠い。
　　　　雑談で近づけようとしている

・Project Research
　　特定のプロダクトにがっつり入る
　　プロダクトチームと他チームの間でHubになる

　　ReseacherだけUXがつく？
　　　　UXはみんなでやることロールにつけない
　　　　Researcherだとわからないから付いた
　　　　変えたい

・ひろがり
　　どう価値を伝えるか？
　　　　デジタルマーケティング
　　どんな価値を生み出すか？
　　　　PdM -> UXデザイナー -> UXリサーチャー

・ジェネラリストのためのプロフェッショナル機関
　　広げることと深めることのバランスが大切
　　やがてはPdMに戻りたい？
　　　　もどりたい

●重田さん
・たべドリ
・エンジニアとして深く広く関わることを考えてきた
　　関わりの広さ
　　　　企画・体験設計、UIデザイン、実装
　　関わりの深さ
　　　　自分で意思決定
　　　　自ら手を動かし考える
　　　　議論に参加する
　　　　関わらない

・リニューアルしたけど取り下げた事がある
　　３ヶ月以上掛けて
　　1万人に公開してA/Bテスト
　　数値が悪かった
　　-> 言われたままつくった

・つくっている最中にダメさに気づいた？
　　気づかなかった
　　はじめから入れていたら納得感は違った

・全員がデザインに関わるべきか？
　　そんなことはない
　　興味があるからやっている

・デザイナーとの分業は？
　　全体の見栄えはデザイナー
　　　　一部の見栄えはやったり
　　言語化への興味が低いデザイナーなので
　　　　強みを生かして分業

・プロトタイピングフェーズでやっていること
　　Figmaでつくったり
　　デザイン原則を用意したり
　　　　古くなってしまった部分もありますが

・実装フェーズでやっていること
　　いかにデザインファイル以上のことを+アルファできるか
　　アニメーション
　　マイクロインタラクション
　　エラー、データの状態への対応
　　-> デザイナに一気に求めるのは酷

・領域を広げることによる価値
　　仮説検証サイクルのスピードが上がる
　　抽象と具体を行き来して、正解に近づける
　　　　抽象：体験からロジカルに
　　　　具体：手を動かして考える
　　今後は？
　　　　もっと職種を広げていきたい

■テクノロジーとクリエイティブがコマース体験を変革する

河野 貴伸 さん [フラクタ]

●自己紹介
・フラクタ
・デジタル戦略
・hopifyの日本エバンジェリスト

●フラクタ
・一般的なブランディング
　　クリエイティブの意味合いが近い
・自分たちで自走できる状態を目指している
　　共創する、ともにつくる活動
・ブランディングスクール

●ECのイメージ
・自由度が低そう
　　EC、カート、ASP < 企業サイト < LP
・関わる会社が多くて進行管理大変そう
・要件が多くてめんどくさそう
・個人情報とか怖い
->
　　頑張っても評価されなそう
　　喜ばれなさそう
　　つまんなそう

いままではそうだった
これからは違う！

●ヘッドレス・コマース
・shopify
　　表と裏を分離してAPIを利用できる
・異なる外部サービスをAPIでつないでいる
　　顧客向けウェブサイト、コンテンツ・マネジメント、
　　割引、決済、在庫、ロジスティクス、分析

●USでのEコマースチームの価値が上がっている
・ライティング、3D、動画など労力がかかっていた部分を売っている
・Eコマース上のコミュニケーションをどうつくるかにシフト
　　どうすればよりお客様に伝わるか

●D2Cの成長を支えたテクノロジーとクリエイティブ
・オフラインに対してもコミュニケーションを反映できた
　　ECで一番見られているコンテンツが店頭で表示される
　　タブレットで商品を選ぶと、試着室に持ってきてくれる
・オムニチャネル、O2O、OMOが求められる
　　クリエイティブもオンライン、オフラインの結合が必要

●ECだけつくって売れるということはない
・自分たちのリアルなコミュニケーションまで含めて設計
・土屋鞄製作所
　　かばんがどう使われるかを動画で紹介
　　社員がつくっている
　　動画制作のスキルも必要
・ブランドの世界観を体感してもらう
　　規模は違えどチームラボさんのような
　　いかにコンパクトに実施できるか
・Eコマースからコマースに変化

●デザイナーとデータサイエンティストの共創
・取れるデータ
　　どういう人が買ってくれる
　　どういう人が店舗に来てくれる
・クリエイティブをつくった
　　だれに響くべきかを考える
・人に合わせてクリエイティブを切り替える

●クリエイティブ・リバランス
・ECってバナーとかすごいコピーするんでしょ？
　　クリエイターのパワーを考えずに、とりあえずつくる文化だった
・どこに力をかけるのか？を考えられるように
　　よく考えられたテンプレートができている
・動画と3Dモデルで商品を公開
　　お客様にエンターテインメント性をもたせて見せるにはが考えられる
　　動画クリエイターの力を借りてECは更に広がる
・shopify AR
　　商品の配置をARで試せる
　　3Dモデラーと連携

●購入がエンターテイメント化
・リスティング広告から買うことは少ない
　　誰かからの紹介など、体験が大切になってきた

●ブランドならではの印象的、象徴的な体験が大切
・シンボリックエクスペリエンス
　　味、香り、テクスチャー・手触り、音
・ブランドが自社ECの中でプレイリストを公開
　　五感を刺激して、ブランドへの共感
　　slackの通知音カカカカッ
　　　　すぐにslackだと分かる
　　　　体験が設計されている
・体験の連続性を忘れないように心がけよう

●ビジネスを理解できる事が必要
・コマースはビジネスの全体像を
　もっともインスタントに理解し、体感できる
　　掛けたお金とお客様の体験

●日本のものをもっと世界へ
・知ってもらう、売っていく
　　ができなければジリ貧
・これからのコマースの魅力
　　自分たちのアイデア、技術、クリエイティブが
　　世界中の人達に使われ、愛される可能性
・それぞれの文化が在るから難しい
　　これまでの日本のものを
　　同じ様に見せていても売れない
・wordpressでできることは広がった
　　Eコマースは入りにくかった
　　shopifyでwordpressと同じようなことが起きている
　　エンジニアやデザイナーがコマースの世界に入りやすい状況

一緒にコマースの世界を
テクノロジーとクリエイティブの力で変えていきましょう！

■オープンソースのこれまでとこれから

川口 耕介 さん [Launchable]

●自己紹介
・サン・マイクロシステムズ
・Hudsonで企業
・オープンソースが大好き！
　　つくったものは世界と戦える
　　　　天下一武道会のようw
　　　　さらしに包丁一本で戦える
　　ユーザーの顔が直接見られる
・人類が開発した最も優れたソフトウェア開発方式
　　安定した開発が続けられる
　　世界中に広がっている
　　世界を動かしているかなりの部分がオープンソース
・資本主義社会の悲しい現実
　　道徳なき経済は罪悪であり
　　経済なき道徳は寝言である

　　できるエンジニアに頼り切り
　　エンジニア以外の人を巻き込むには経済が必要

●もっとオープンソースが繁栄するために
・1985年 ボストン
　　リチャード・ストールマン
　　GNU Project
　　　　自由を勝ち取る運動としてフリーソフトウェア運動を始めた
　　　　帝国軍と戦う反乱軍のような
　　　　若者がわっと集ってきた
　　　　bash, viみんな使っている
・1990-2000
　　Microsoftと戦うために
　　　　当時は悪の帝国的な存在
　　　　乗っ取られてしまうかもしれない
　　団体
　　　　Apache Software Foundation
　　　　　　Sun, IBMが一緒に作業する場が必要だった
　　　　Linux Foudation
　　　　Eclipse Foundation
　　企業が同盟したり、攻めたりする道具として組織が使われた
　　XMLが流行っていた頃
　　　　沢山の人が使っているparserが強かった
　　　　冷めた後はすっと1つにまとまってきた
　　Cathedral & Bazaar
　　　　スーパーハッカーが一人で引っ張る
　　　　-> 企業のエンジニアに

●オープンソーススタートアップの時代
・VCがオープンソースにお金を払うw
　　spring, jboss, hashi corpなど

●時代ごとに色んな人がオープンソースに参加
・自由を求める一匹狼
　　-> ベンダーの戦い
　　-> スタートアップ
　　-> 新しい主役
・ユーザー企業
　　自社で開発したサービスを消費者向けに提供
　　netflix, twitter, spotify
　　楽天、はてな、メルカリ など

●ベンダー < ユーザー企業
・より面白いことをやっているから流行る
　　ベンダーの対応を待っていられない
・aws
　　自社向けのはずが大きくなった
・microsoft
　　唯一、自社に必要ないのにつくっている

●DONATIONS
・使った分だけ貢献しなきゃ
　　な、慈善事業的に説得されていそう

●コストの圧縮
・ナイーブに運営されているオープンソースが多い
　　公開しただけで、プルリはこない
・同業他社と協力する
　　モノポリーのように交換することでどちらにも得が出る
　　2,3位が協力して1位と争う
・spinnaker
　　netflixの社内利用
　　他者が参加できるようにpluginの仕組みをつくった

●開発者を雇うため
・どこでもエンジニアが足りない
　　福利厚生としてオープンソースに着目されている
　　カンファレンスでの企業スポンサーも求人のため
・求人活動の一環
　　新しいことをやっている面白さと尊敬が必要
　　Liftのenvoy
　　　　マイクロサービスの規模が大きくなっていて
　　　　サービスメッシュが必要なんだ
　　　　とエンジニアから理解されている

●従業員満足
・エンジニアとしては
　　どういう風につくったかにこだわりたい
　　みんなに見てほしい

●技術部門のリーダーにできること
・自社の技術を発信できること
・目的と繋げられること
　　エンジニアリング、リクルーティング、ハイアリング
・たとえば
　　自社の技術の一部をオープンソースで公開
　　技術ブログを片手間ではなく、企業の活動として
　　人事の人と仲良くなって、採用が大変の解決策として
　　　　ビジネスゴールとつなげて説明できるように
・ソルジャーだからできないではなく
　　より高いレベルのことを考えて
　　活動していくから上がっていく

●デブサミにおねがいしたいこと
・アカデミー賞みたいのがあったらいい
　　ソフトウェアは見えにくい
　　パーティー会場で赤いカーペット
　　「うちの技術なんかすごいらしい」が分かりやすいように
　　流動性が上がれば給与も上がる

●オープンソースは利益の追求が必要
・成功例はnetflix
　　自社のミドルウェアスタックを公開
　　Java EEのようなイメージ
　　技術ブログがセット

　　AWSは当時、アプリの書き方を変えなきゃな意識があった
　　成功例が必要だった
　　　　-> メディア露出
　　中に行くと普通の会社
　　　　外からの評判で社内で使わせる
　　リーダーはnetflixをクラウドネイティブにした人として有名に

●オープンソースプログラム・オフィス
・インバウンド
　　よそのオープンソースを社内で使うため
・アウトバウンド
　　中では
　　ビジネスのインパクトを考える
　　人や予算の調整など
　　誰かがやらないと回らない

　　事業部の人は、事業部の目標に拘束される
　　-> 専門の組織が必要

　　オープンソースのサイトがきれいなのは専門組織がやっている
　　ポジションをローテーションして回せたら良い
　　火事場で疲れ果てた人が楽しんで、回復して帰っていく
　　新しい人が来るから足りない部分に気づける

・企業のためのオープンソースガイド
　　Linux Foundation

●これから
・Linux Foundationに注目している
　　プロがいて、お金を吸い上げる仕組みができている
　　企業を連れてくる
　　集めたお金で、プロジェクトのリソースに変えていく仕組みがある

　　開発者だけでできる時代は終わっている
　　いろいろな人が必要

・コモディティの共同制作
　　つくるレイヤーが上がってきた
　　特定業界のコモディティ
　　　　付加価値がないものは、みんなで一緒に
　　　　経営戦略の話題になる
　　Academy Software Foundation
　　　　映画業界のそうそうたるメンバーが参加
　　　　　　ベンダーに吸い上げられるより、自分たちでつくってタダに
　　　　という活動をLinux Foundationが進めている

　　自社のインシュランスプラットフォームをMSとオープンソース化
　　タイでできたeGovementをオープンソースに
　　飛行機のチケット予約も社内から会社に切り出された

・オープンソースはもっとすごくなる
　　出世のため
　　世界につながる
　　独裁と戦う正義の見方
　　企業の枠を越えた入れ物
　　だけではない

パッチを書くだけで終わっている場合ではない
ビジネスにつなげていこう

■エッジコンピューティングの時代にサーバーはどこにいくのか、自社製品をハッキングしてもらった話

及川 信一郎 さん [日本ヒューレット・パッカード]

●サーバのイメージ
・ブレードサーバ
・データセンター

●Memory Driven Computing
・288core / 12TB
・このサーバを渡されたら何をしますか？
　　メモリ、coreの制限がない
・アルツハイマーの分析の例
　　バラバラのデータをすべてつなげて分析が可能に

●データセンターからデータエッジへ
・HPE Edge line EL300
・製品ラインの完成品検査
　　写真1枚 75MB
　　クラウドにアップするには時間がかかる
・70%はデータセンターの外側
　　FWの内側でも攻撃を受ける
　　セキュリティの話はお金にならないから人気がない

●ハードウェアセキュリティ
・2017年 HPのプライベートイベントにFBIの人を呼んだ
　　ハードウェアへのセキュリティインシデントが増える
　　なるほどといったのは防衛省の人だけだった
・2019年 ハードウェアを気にし始めた
　　2021年までにサイバー犯罪は世界経済に6兆ドルの損害
　　SPOILER, Pants Down
　　ネットワークトラフィックを全部メモリに取り込んで分析なども可能に
・情報セキュリティ10大脅威
　　4位 サプライチェーンへのリスク
・ハードウェアのほうが着目されないから攻撃されやすい

●外部機関によるペネトレーションテスト
・Gen10がNo1
・エンジニアなので、本当なの？を試したい

●日本でできないか？
・沢山断られて、諦めたところで
　　サイバーディフェンス研究所
　　ハードをいじるならハッキングできるかも
・ファームウェア
　　ハード -> ファーム -> OS
　　SPI flashメモリを買ってくればクラック可能
・あらゆるポイントが改ざんできた
・HPE Silicon Root of Trust
　　BMC->BMCファーム->BIOS->OS
　　BMCをカスタムに置き換え
　　　　正しいデータを保存してあるので
　　　　電源投入時に改ざんを検知したら上書き

・手島さんコメント
　　惨敗したが、次はもっと時間をかけてリベンジしたい

●世界のエッジ
・空母、イージス艦、ヘリ
・興味のある人は airbus hacking
・NIST SP800-147B
　　ファームウェア保護の必要性
　　あらゆる処理の前に起動されるので、ここを守らなければ危険
・ファームウェアは、ハードのあらゆる部品に含まれる
　　すべてに一気に対応は無理

●HPEのセキュリティビジョン
・サーバープラットフォームセキュリティ
・ボトムアップの防御

●パブリッククラウドベンダーの取組状況
・メジャーなクラウドベンダーは全て対応
・Azureの場合
　　セキュリティ用コ・プロセッサでRoot of Trustを実装
・HPEの場合はiLO

●信頼できるハードウェアの仕組みを作っていくことが必要
・見えないだけで身近な場所にサーバが置かれている
　　データの扱い方が変わってくるとエッジに置かれるかもしれない
　　サーバを従量課金で提供するようになるかもしれない
　　個人や商店へばらまかれている状況になるかもしれない
・データセンターでもエッジでも信頼できる様に努力中
　　Root of Trustが出て3年くらい
　　まだ破られていない
　　いたちごっこなのでいつかは破られるかもしれない

■キャリアトランスフォーメーションをみんなで考えよう～開発者から事業責任者、役員へのキャリアパスはどうよ～

石井 智康 さん [石井食品]
市谷 聡啓 さん [ギルドワークス/エナジャイル]
黒田 樹 さん [リクルートテクノロジーズ]
岩切 晃子 さん [翔泳社]

●岩切さん
・翔泳社の社員
・デブサミの初代オーガナイザー
　　今日は故郷に返ってきた感じ
・書籍の営業担当役員
　　出すよ！の門番

●全社会人に覚えておいてほしいこと
・GURUのメンバーとして入った
・この雑誌ダメだと思ったが
　　なくなっても次に頑張れば良いや
　　それなりに頑張った
・廃刊のときにみんな泣いた
　　これはダメだ
　　マネジメントの教訓になっている
・どうしてPLくらいは見てないのか
　　知っているか否かで、人生のハンドルの握り方が違う

●今日聞きたいこと
・日本のビジネスサイドの意思決定や変化がおそすぎませんか？
・チームと言うときの範囲が狭過ぎませんか？
　　役員、マネージャー、POが含まれてない気がする
・companyはともにパンを食べるが語源
　　無関心ではいられない
　　XP的に言うとステークホルダーがチーム
・開発チームとビジネスサイドでKPIを共有している？
・何をやってもITがからむ
　　開発者がどんどん口をだすべき

●3人の勇者から話を聞いて背中を押してもらいましょう！
・起業した市谷さん
・家業を継いだ石井さん
・昇進した黒田さん

■自分のハンドルは自分で握れ
市谷さん

●17年の検証結果
そのばその場の環境に身を委ねるのではなく
自分が良い感じと思う方に舵を切ろう

●2003年
・n次受けの開発者
　　客先常駐
　　請負という名の派遣
　　組み込み系
　　　　世の中と別のことをやっている
・でも、俺達と関係ない
　　本当に良いのかわからない、会社の外に出よう
　　Developers Summit 2003
　　　　すごい！
　　　　俺がやっているのは何なんだ
・目の前の最適化に陥るな
・デブサミに毎年通う
　　自分と世の中とのdiff
　　スターの背中が見える、圧倒的遠くに
・会社を変えたり、業界を変えたり
　　一貫して追い求めたこと
　　　　自分が作ったソフトウェアを使ってくれる人が近い場所
　　自分が作っているものに
　　どれほどの意味があるかを知るためのジャーニー

●2013年
・間違ったものを正しくつくる問題
　　作り方はうまい
　　でも、これ何のためにつくったんですか？
・造り手が心のなかに引いた線
　　何をつくるべきかは、自分ではない誰かが考える
・顧客、プロダクトオーナーに踏み込んでみたが
　　誰も答えなんて持っていなかった
・仮説検証で自分のあり方を世に問う

●なぜ経営者を選んだの？
・自分がこれで価値を出せると信じて
　　でも説明できない
・自分で全てを背負うしかなかった
　　プロダクトが使い物にならない
　　ビジネスとして成り立たなかった
　　となったとしても
・人を説得するより自分で動いた

●正しいものを正しくつくる
・6年これを背負っている
・正解はない、だから
　　何を考え、どうつくるのかを考え続ける
・デブサミで話すことも努め
　　自分の場所を今よりも良い感じの状況にするには？
　　あなたは何をする人なんですか？

そのばその場の環境に身を委ねるのではなく
自分が良い感じと思う方に舵を切ろう

そうすることで
人には説明が難しいけど、楽しさを感じられる

■エンジニアの事業継承
石井さん

●石井食品
・ミートボール、ハンバーグ

●石井さん
・2006 アクセンチュア・テクノロジー・ソリューションズ
・2010 ベンチャー
・2014 フリーランス

●日本は事業承継が大問題
・家族経営の企業が沢山
　　19年 1万件+が休廃業
　　承継がうまくいかなかった
・自分の人生 vs 家業

●SIer
・システム構築は越境的行為
　　コンピュータの世界
　　お金の世界
　　人の営みの世界
　　ここを行き来

●ベンチャー
・CMS導入で開発が遠くなった
・デブサミ2011が刺激に

●フリーランス
・お金持ってきてるかどうかの違い->フリーランスへ
・いいチームで開発したい
　　技術的負債
　　チームマネジメント
　　顧客価値の提供
　　PL
　　採用
　　評価
-> これって経営に近くないか？

●自分の人生と家業がなんとなく近づいてくる
・vs構造から融合してきた
・事業承継はベンチャーの一つの形

●石井食品
・エンジニアとして経営に入る
・インフラやばい、、、
　　domain管理どうしてる？
　　物理メールサーバにVPNでつなぐ、、、？
・エンジニアとして学んだことはどこでも活かせる
　　コンウェイの法則を知って経営！
　　ただし、上からいかない

複業から始めてもいいんじゃない？
自分も、始めは研修講師からだった

■偶然の出来事の流れに身を任せ
　エンジニアからマネジメントの道に進んだ話
黒田さん

自分のキャリアに中途半端なビジョンを持たない
流れに身を任せる

●キャリア・アンカー理論
・登山型
・ゴールから逆算

●計画された偶発性理論
・川下り型
・偶然の出来事にベストを尽くす経験の積み重ね
　　よりよいキャリアが形成される
・おまえのwillは何なんだ？
　　ないっす
　　見えなかったものが見えて、へぇー！はほしい
・良い波が来た時にお気にいることが大事
　　波はコントロールできないが
　　沖にいることはコントロールできる

●20-25歳
・SIer
　　1トランザクションスクリプトを書く人
　　-> アーキテクト
　　大規模更改時に相対的に知識があった

●25-30歳
・リクルートへ
　　新規事業が偶然大ヒット
　　人数が増えてビジネスと開発がギスギス
　　PL，残存簿価が見えた

●30-35歳
・リンスタ
　　視座が仮説検証型に
　　出資先の支援へ
　　ビジネスフェーズ x エンジニアリングが開けた

●35-38歳
・SoE,SoR両方を含む組織を牽引するおじさん枠
　　組織全体のスループットが出ない
　　新規事業で散々経験した
　　これは完全に、強くてニューゲーム
・アウトカムの積分値が最大化されれば何でも良いよね
　　部長やらない？
　　　　やりまーす
　　執行役員やらない？
　　　　やりまーす
　　知的好奇心が刺激されて脳汁がブシャー

みんなが見えていないぼんやりしていることを
構造化/言語化して見えるようにし、課題定義する

こうなるぞ！という明確なビジョンはない
やってきたら全部押さえた
それぞれの状況でパラダイムを理解できるようになった

■パネルディスカッション

●マネージャー、経営者に向いている人はいる？
　醍醐味はどんなもの？
・市谷さん
　　視座を変えられる人
　　視座を切り替えることで色々見えてくる
　　　　プロダクト、組織
・石井さん
　　向いている、向いていないは、ないんじゃないかな
　　　　やるしかない
　　　　覚悟を決められるか
　　　　苦しみながら学ぶ
　　苦しさばかりだけど
　　　　人生よりも長く会社がある
　　　　ミートボールで良い思い出がある人がいる
・黒田さん
　　マネージャーは、エンジニアは全員向いている
　　　　体制図を描くってクラス図にしか見えない
　　　　兼務って実体はどっちかだから、シンボリックリンクだよね
　　　　今名前をつけていいんだっけ
　　　　　　役割が決まるまで名前をつけてはいけない
　　　　対象が人になっただけ
　　そういうのがハックできたときに、うひょーってなる

●将来実現したいと思っていることはある？
・市谷さん
　　なんとかしたいもの
　　　　大企業のDX
　　　　地方、アトツギの事業づくり
　　　　国、自治体をなんとかしなくては
・石井さん
　　いいチームで開発したい
　　モブでもいいから週一プログラマやりたい
・黒田さん
　　意思決定を歪ませるものを
　　構造化、言語化してスムーズにしていきたい

●つらくなったらやることは？どうリカバーする？
・黒田さん
　　ゲームをひたすらやる
　　集中すると脳が100%使われる
　　ここでMPを回復
・石井さん
　　ベロシティでとらえて
　　持続可能性を保つ
・市谷さん
　　一人になる時間をつくる
・岩切さん
　　リングフィットアドベンチャー
　　疲れると寝れる

●ともにつくる組織をつくるときに大切にしていることは？
・石井さん
　　色んな人に対する敬意
　　一人ではミートボール一つ作れない
　　イケてないことは沢山
　　でもそこまでつくってきた人に経緯
・黒田さん
　　歴史を大切にする
　　なんでもロジックツリーにしない
　　歴史があるからネットワークが張り巡らせれている
・市谷さん
　　人の時を想う
　　それまでにどういうことがあって今があるのか
・岩切さん
　　課長になった時に大切なことは
　　事業を引き継いでくれる人がいるか
　　事業が継続できることがともにつくる原動力
　　　　チームのメンバーの健康、お給料が払えているか

■感想

・急勾配の変化を乗り越えるための段階の設計
・Observability成熟モデル
・個人間の相互作用をファシリテートする
・デザインは氷山の隠れた部分を考えること
・隣の職種を補完する
・コマース領域へのテクノロジーの適用
・オープンソースとビジネスのつなぎ込み
・ゼロトラストセキュリティのハードウェアへの適用
・組織とソフトウェアアーキテクチャの共通点
など、たくさんの
「なるほど！」「ワクワクっ」「そうですよねー」をいただけました！

帰りにはヘトヘトになっていたんですが、ふりかえると
・ハードウェア、アーキテクチャ、アプリケーション
・SRE、アプリエンジニア、デザイナ、経営者、ファシリテータ
・事業企画、新規開発、保守・運用、カスタマーサクセス
と、視座と視点を切り替え続けた一日でしたw

ここまで幅広く気づきをもらえるカンファレンスは他にはないと思います。
改めてデブサミの凄さを感じました！

登壇者の皆さん、運営の皆さん、ありがとうございました！！