Developers Summit 2019 Summer

A-1 愛されるプロダクトをつくるエンジニア組織とは――「テクノロジー」「開発プロセス」との緊密な関係

及川卓也[Tably]

コンサルティング
- 技術
  - どういう技術が正しいか
  - 作り方は正しいのか
- 製品
  - 製品として本当に望まれているか？仮説検証
- 組織
  - 良い製品を作るための組織づくり、よい技術者を集めたい
＝愛されるプロダクトを作るためのエンジニア組織とはどうあるべきか？
愛されるプロダクト
- Product Manager Conference
- MVP　リーン開発
- MLP　Minimun Loveable Product
- Tower Recordsの栄枯盛衰
  - フォーマットの変遷
    - アナログ→デジタル（CD）→iPod、Apple Music
    - 所有の変化
    - 価値の変化
      - 所有から利用へ
      - そして体験へ
    - 背景
      - シェアリング需要
      - コネクテッドが当たり前に
      - 富の概念の変化
        
        所有という概念に意味がなくなっている
    - サービス産業化
      - WEB→スマートフォン
        
        WEBに対して、購入という概念がない
        
        →マネタイズ（収益化）を考える必要がある
      - 従来は一括購入
        
        サブスクリプション
        
        アプリ内課金
        
        Freemium
        
        ＝使われ続ける必要がある＝愛されるプロダクト
        
        Growth Hacking
        
        スマートフォンアプリを出せばユーザーに使ってもらえるという誤解
        
        継続利用してもらい、紹介してもらう必要がある
- プロセス
  - 不確かなものを確かにする
    - 性別や年齢でのグルーピングは意味がなく、小さなグループが混在
    - ＝正解を最初から導くのは不可能
    - ＝仮説検証を素早く繰り返す
      - LEAN-AGILE-DEVOPS
    - ウオーターフォール：設計が上位、製造は下位：手戻りは当然発生するという考え方にはそぐわない
    - DEVOPS
      - 開発→リリース→運用
      - から
      - 開発＆運用が一体化、その間にリリース：リリースしてからが始まりの部分も
  - ただし、魔法の杖や銀の弾丸ではない
    - 新たなフレームワークを導入すればいいものが作れるわけではない
    - 型を守り切ることが重要ではない
- ソフトウェア開発に必要な職種
  - プロダクトマネージャー
    - プロダクト＝事業になりつつある
      - 組織横断的なプロダクトチームを束ねる：MiniCEO
      - チームを率いるが、人事権は保有しない
      - 高いビジョンと強い意志が必要
  - プロダクトマネージャー：プロダクトの成功に責任を持つ
    - What、Why、When＝どのように作るかは考えないほうがよい
  - エンジニア：どのように実現するかに責任を持つ
    - Hou
  - エンジニアリングマネージャー：成長し続けるエンジニアチームをバックアップする：エンジニアの成長
    - 個人よりも組織のことを考える
    - 長期的な視座に立つ
  - 各職位をまたいだ昇進はない：ジョブ型雇用：職位をまたぐのであれば正式な異動（転職に近い）
    - ＝ジョブ型雇用
    - 日本はメンバーシップ雇用
  - テックリードの位置づけ
    - 職種ではなく、役割
    - エンジニアがある一定以上のレベルになった場合、
      - 開発を技術的にリードすることが求められる
- 組織パターン
  - 職能組織
  - 事業主体組織
    - いずれにしてもマトリクス型運営
  - ジョブディスクリプション作成のすすめ
    - 職種（ジョブタイトル）が何を表すかは組織によって異なる。自明と思わずに作成するべき
  - 多能工VS単能工　フルスタックを目指すか
  - 運用（インフラエンジニアやSRE)は担当者を固定するか
  - QAの必要性
- 要件
  - 事業サイド
    - 仮説検証を素早く回す：スクラップ＆リビルド
    - スケーラブル
  - 組織サイド
    - 集合離散：スクラップ＆リビルド
    - スケーラブル
      - 成長する組織
  - スクラップ＆リビルド
    - 壊すことをいとわないシステム
    - 壊れないシステムではなく、すぐに復旧できるシステム
      - クラウド
      - マネージドの活用
      - XXX as a Code :コードによる記述
  - スケーラビリティ
  - DevOps →　NoOps
    - サーバレス
      - PaaS
      - コンテナ
      - FaaS
  - マイクロサービス
    - 管理可能な粒度に分割　協調性　自律性
    - 組織全体の規律：マイクロサービスでも共通開発基盤（言語やツールチェインなど）
    - ＝柔軟性（自由）と規律が重要→組織が使いこなせるかに関わる重要な要素
- プロダクトマネージャーの認知を高める活動
  - PMの認知は高まったが。。。：調整役で終わっていないか？
    - ふわっとしたアイデアをPM経由で開発へ投げる：
  - 分業制を進めるのではなく、全員が「プロダクト志向」を高める
    - PMだけでなく、全員がプロダクトへの責任を持つ
- コードの向こうにユーザを見る
  - 自分が書いているコードの価値がどこにつながるのか
  - 目標を決めるときに、その技術を使うことでどこへつながっているのかを考える
  - ＝プロダクト愛

A-2 今後の生き方についてサラリーマンエンジニアが人生半ばにして考えてみた

上野淳[ディライトワークス]

まず結論
- 環境に流されるエンジニアになってはならない
組織を作っていくための知見
- 組織を作るのはマネジメント層ではなく、我々一人ひとりの問題
ノウハウの共有や獲得をチームや社内だけで完結させるのは無理がある
- ＝外に転がっているノウハウを拾いに行く必要がある
- 役立つノウハウを体験だけから得るのは難しい

A-3 新卒社員研修からはじめるアジャイルソフトウェア開発チームのつくり方

新田章太[ギブリー]

codeprep
- 内発的動機での教育ビジネスは難しい
Track
- BtoB向けの採用・社員教育サービス
プログラミング研修を効果的にしたい
- 研修と現場のギャップをどう埋める：アジャイル？現場でつかえんの？
バイモーダルIT
- モード1とモード2：守りと攻め：モード2へ徐々に転換
- 終わらない研修：研修にとどまらずそのまま現場へ：アジャイル文化を社内に広める
- ビジネス要素 X 技術要素のバランス
- 技術レベルや指向性がバラバラな状態でも、一人一人の効果を最大化したい
- モード1への理解と基礎から→徐々にモード2：Leanやスクラムへ
  - 新規事業立案をゴールに
    - Design Thinking X Lean Startup X Agile をベースに
  - スキル・思考性：オンライン学習で埋める
- アダプティブｘアクティブ学習の実践
  - 難易度のコントロール
    - 講義を最大限減らして、「他人の人に教える」をゴールに
    - 研修前試験でスキルの可視化
  - 早く終わった人が常にまだ終わっていない人のナビゲータとする
  - 用語や概念をインプットした内容は定期的なLT会で説明する：アウトプットを意識した学習
- How ではなく、WhyとWhat
  - ただフレームワークを実践しても内容・目的の理解にはつながらない
  - ＝自ら学び、経験する力を身につけさせたい
  - 課題としてHowをあたえるのではなく、Whatを与える
- ファシリテートとメンタリング
  - 研修事前のアンケートでは会社の方向性や価値観などに共感性を持っていないことが判明
    - 講師としてではなく、全体のファシリテートやメンタリングに専念
    - 定期的な1on1を実施して、モチベーションや研修との向き合い方について確認
    - デイリーでのKPTを導入、チーム内でも日々の行動目標、カイゼン
- よかったこと
  - 高いプログラミング習熟度
    - オンライン、オフライン両面の取り組み
    - スキルの可視化は大事
  - エンゲージ・モチベーションの向上
    - メンタリング実施の効果
    - 講師よりメンタリングが大事
  - リアリティの体験
    - 座学だけでなく、チームでのリアルな活動体験
    - ウォーターフォール＝つらい、アジャイル＝楽しい　謎の先入観をぶち破れた
    - アジャイルが楽しいなんて思うな
- 改善したいこと
  - 開発力・経験のすくないスクラムは難しい
    - 「Smart」なプランを立てられない
      - 自分たちで自分たちの目標設定をする中で「Smart」なプランを立てるのはすごく難しい
      - 内容の質がないとなんちゃってアジャイル研修にもなりえる
    - MVPを作れない
      - 適切なユーザストーリーが立てられない：機能から入ってしまっている
      - →通過儀礼的なレビューを強化すべきだった
    - 手戻りがたくさん発生
  - ＝＞現場巻き込み型（経験者の巻き込み）での実践が必要
まとめ
- 新人研修から本格的なアジャイル導入
  - スキルの可視化、アダプティブな学習設計
  - メンタリングに注力することで組織エンゲージは高まる
- 「なんちゃって」にならないようにプロフェッショナルや現場からのレビューは強化が必要
- 新人研修にとどめず、現場（メンター）や一部の若手も交えることで、組織全体の文化構築に広げていけるのでは
- ウォーターフォール　VS　アジャイルではなく、バイモーダルIT

B-4 組織にテストを書く文化を根付かせる戦略と戦術

和田卓人[タワーズ・クエスト]

テストを書いていく筋道
戦略編
- 疲弊しきった現場
- 荒みきったコード
- 爆弾処理のようなリリース
  - テストがないコードはレガシーコードだ！
- 2つのならわし（呪いの言葉）
  - テストを書く時間がない
    - テストを書かないから時間がなくなるのです
  - 動くコードに触れるな
    - コードが変わらなくても、周りの要素がどんどん変わっていく→コードに触れなくても動かなくなる
    - 触れなければ競争力が弱まり、事業は緩やかに死んでいく
- Cover and Modify
  - セーフティネットの重要な要素＝自動テスト
- 文化の醸成は2年から5年かかる
  - 銀の弾丸はない
- 導入方法
  - 導入を目的にしてはいけない
  - ToBeではなくAsIsとNot ToBeから始める
  - 人は自分の速度でしか成長できない
    - プロジェクトもそう
  - 「周りはもうやっている」は劇薬　用法容量をまもる
- 理論武装する
  - 不具合の発見が遅いほどコストがかかる
  - TDD導入効果
    - Towers Quest MS,IBMのサーベイ
    - エリクソンのアンケート
      - デバッグの工数へらす
      - 要求が洗練される
      - 開発工数が減ると感じる
        
        デバッグの工数が減るため、テスト書いた分が増えても全体では減ったように感じる
        
        デバッグは工程の最後にくるため辛いもの
  - テストは品質をあげない（体重計のメタファー）
    - 品質が「わかる」ようになる　
    - 品質をあげるのは設計とプログラミング
    - 再設計とリファクタリングをテストで支える
    - 「テストはあくまでも品質をあげるきっかけ」
戦術編
- 2つの道しるべ
  - 「レガシーコード改善ガイド」
    - レガシーコードのジレンマ
    - レガシーコードにさわるための語彙と技法を整理した本
  - 「レガシーソフトウェア改善ガイド」
    - 上記よりやや抽象度が高い
      - リファクタリング
      - リアーキテクティング
      - ビッグ・リライト
- どこにテストを書いていくか
  - どこからやるか
    - 「何がいちばんやばいですか？」
    - もっとも困っているところから
      - お金、個人情報
    - 新機能開発から
    - バグ修正から
    - 静的解析でピンポイントに
    - 「傷んだ箇所」と「手が届く果実」
- テストのトリアージ
  - 機能ごとにリスクを見積もる
  - 手動テストのコストを見積もる
  - 自動化コストを見積もる
  - →優先順位をつけて並び替える
- どうテストを書いていくか
  - 「レガシーコード改善ガイド」参照
- こだわるな
  - 最初から全部やろうとしない
  - テスト駆動にこだわるな
  - テストファーストにこだわるな
  - ユニットテストにこだわるな
  - 実行速度、網羅性にこだわるな
- こだわろう
  - リピータブルであること
  - インディペンデントであること（依存関係がないこと）
  - 他はそれからでいい
- 設計の可動域を確保する
  - 実装のテストを書かないこと
  - 設計、実装を変えることが前提
  - テストサイズを自分たちで定義し、調整する
- 背中を見せる　周りを動かすために
  - サンプルとデモが大事
  - 真似してもらう、最初はコピペでも
- てきるからやるではなく、やるからできるようになる
  - あなたがかけなければまわりもかけるようにならない

A-5 Infrastructure as Codeでインフラチームはもっと強くなる〜ぼくのかんがえたさいきょうのいんふらちーむ〜

左近充裕樹[ブロードリーフ]

自動車アフターマーケット
- 新車販売市場の後の自動車整備市場やカー用品市場、リサイクル市場、中古車市場など
- BroadLeaf Cloud Plaform
少人数インフラチームの課題
- インフラチーム5名
- 特にまずいこと：欠員
  - 労働時間増・オンコール増
    - モチベーションが下がる：やったことない業務を突然やらされるストレス
      - さらなるストレス：完全に負のスパイラル
- 課題
  - 構築手順がロスト・陳腐化
  - ノウハウが蓄積しない・再利用できない
  - オレオレの仕組みが多く、メンバーが同じプロトコルで会話できない
  - 人間の作業が多い
    - →チームメンバーならだれでも対応可能、交換可能な組織、仕組みにする必要がある
昨今のインフラ
- SDN
- AWS,GCP,Azureはプログラマブルに管理される
  - →ソフトウェアでの管理が必要＝IaC
- パブリッククラウド：Terraform
- OS:Ansible
- Image:Packer
  - Image構築はCI/CDパイプライン作成
TerraformとAnsibleを併用する理由
- Ansibleだとクラウドリソースの管理がしづらい
- Terraformのほうが扱えるクラウドリソースが多い（特にGCP）
- クラウドリソース管理はTerraformがデファクトとなりつつある
モブプログラミング
- Hangouts Meet + VSCode LiveShare
- メリット
  - 品質向上
  - レビュー不要（というか同時にレビュー）
  - 情報共有が密にできる
  - チーム全体のスキルが上がる
- デメリット
  - スケジュール管理（メンバーをそろえる）のが難しい
開発スピードを落とさないために
- 厳密にIaC管理すべきだが、実情は難しい
  - 本番環境以外はインフラチーム以外のメンバーがクラウドリソースを触れるようにしている
    - 手作業で差分が出た場合、terraformer terraformingで
    - Slack通知ツールで差分チェック
    - 極力負債を抱え込まない仕組み
使用するサービスの基本方針
- マネージドサービスを使う
- 自前のツールを作らない、まず探す
- それでもなければ作る
- 理由
  - メンテナンスが必ず発生する
  - 世の中の人は大体同じ問題を抱えている
  - 一般的に使われているツールは多くの専門家が作っている
  - より良いサービスを提供することにフォーカス（ツールを作ることが目的となってはいけない）
CGP環境でCronつらい問題
- どこで何が動いているかわからない
- 絶妙なバランスでピタゴラスイッチ状態（依存関係）
- 失敗したか成功したかがわからないまま放置
- →RunDeckを導入
  - OSSのジョブ管理ツール
  - 定期実行やワークフロー制御も可能
  - SSHで接続するだけなので、エージェント不要
  - プラグインが豊富
  - アカウント、権限管理も可能
監視について
- すべてのアラートをメールにて通知
  - →一応見るが、ほとんどアーカイブするだけ
- 監視に重要なこと
  - 本当に必要なものだけを通知する
  - １．サービスが提供できていない状態
  - ２．確実に障害になるもの
  - ３．過去の状態はメトリクスの収集のみ
IaCを導入することで、人に依存しない交換可能な組織になる
IaCは手段：ツールで解決できることはツールで行い、より価値があることにフォーカスできるようにする
- 時間ができる→できることを増やす→もっとつよくなる
- 必要な失敗だけをして、常にチャレンジし続けられるチーム

A-6 ティール型組織でサービス立ち上げが成功した話

手塚卓也[スリーシェイク]

Reckoner
ピポット前
- 組織体系：各ロールに相互関係がない
- 縦割りの問題
  - 情報が不透明
  - マネジメント工数肥大
    - PO/PMが優秀じゃないとチームが死ぬ
    - PO/PMの負荷
  - 意思決定の遅延
- 全員ロナウド時代
  - 各自が自分たちのタスクにしかフォーカスしていない
  - 自分のロールを飛び越えてタスクをこなすことが重要であるはず
- 3つの失敗
  - 企画の失敗
    - 明確なビジョンがない、仮説検証不足、競合調査不足
  - 技術の失敗
    - 俗人化された大量のコード
    - 20を超えるリポジトリ
  - 組織の失敗
    - マネジメントの爆発
その後ティール組織へ
- Mission再定義
- ティール組織
  - 人：ゴールに向かって自走
  - 組織：互助的に自律
  - 情報：すべてアクセス可能
  - 評価：メンバーの感謝
- 特定の管理者を持たず、ミッションを共有し、それぞれが自走する体制に
  - 共有したミッション以外の作業は全く意味をもたない
- 企画が良くなった
  - 一人企画からチーム全体で考えるように
  - ユーザ視点が根付いた
- 技術が良くなった
  - ゴールを見据えてアーキテクト設計可能に
    - その場しのぎの開発の解消
    - 半年後、数年後を意識してアーキテクト設計
  - メンバーの技術力向上
    - お互いを助け合う中で技術カバー範囲が広がった＝フルスタック気味へ
    - 属人化解消へ
  - チームが良くなった
    - 各メンバーのモチベーション向上
      - タスクの意味が分かる＝ゴールへの達成感
    - 意思決定のスピードアップ
      - 情報はすべてオープン
- 工夫した点
  - サポーター制度
    - 各メンバーの得意領域に対してサポーター認定
    - 困ったことがあったらサポーターに必ず相談
  - 採用活動
    - チーム全員で採用活動（主にwantedly）
- 今後の課題
  - 特定の人頑張りすぎちゃう問題
    - 性善説が前提のため、頑張りすぎちゃう人が出てくるとバランスが壊れる
  - 個人の評価問題
    - ティール組織は個人の収入を上げることがゴールではないため、評価が不透明になりがち
    - 誰がどうやって評価するのか

A-7 エンジニアとマネージャーは、いつも勝負をしているのだと思う

森田想平[グリー]

成長にフォーカスする意味やメリット
成長に影響を与えた組織構造、システム構造
よくある悩み
- さらなる成長を求めて旅立ってしまう
- メンバーの成長が重要だが、どのくらいフォーカスすべきか、事業との関係性はどうとらえれるべきか
- 成長は事業成果に還流される変化
  - 「失敗を許容するために、能力不足は許容できない」
  - 「不確実な環境では知識は動く標的になるが、そんな環境で新たなスキルを学ぶことが、およそどの業界でも競争するうえで不可欠になっている」
成長のWILL/CAN/NEED
- 重なりが大きくなるよう努力することが必要
- 重ならないNEEDへの対応
  - WILLとCANが重なる別メンバーを探す
  - 専門職集団として組織化
  - グループ外連携
- NEEDを動かす
  - 事業ニーズのハック
- WILLを動かす
  - 本人の気づきを見逃さない
  - 何を目指しているかのビジョンを明確にし、伝えること
- NEEDが重要である以上、特定職種のみ成長すればよいわけではない
- 基本的にすべてのメンバーが成長できる環境を整えるべき
事業という制約条件
- 成長環境整備の制約条件に事業貢献があるという割り切り
- 制約条件は順守するが、売り上げ最大化のような取り組みはしない
- 事業成長、事業衰退ともにメンバーの成長環境に大きな影響を与える
成長を求めて旅だつ若者を引き留めるべく、成長にコミットした組織運営はありかなしか
戦場を定義する
- プロフェッシャナルなエンジニアは甘くない
- 技術力勝負は厳しい
- 技術的に優秀なメンバーvs技術的に平凡なマネージャー
  - 弱み
    - 技術力
    - 自分より優秀な人材を採用するゆえのジレンマ
    - マネージャーの成長のためにメンバーがいるのではない
  - 脅威
    - ライブイベント。育児と介護
  - 強味
    - 組織構造の決定権限
    - システム構造の決定権限
    - 評価基準の決定権限
    - 予算を取りに行く力
  - 機械
    - 上司が偉い人
    - 部下が優秀な人
エンジニアの成長と組織構造
- キャッチアップサポート
  - 上司の上司と1on1
    - 基本的に偉い人から言われるほど安心するのでは？
    - 成長スピードについて認識を合わせることで、心理的安全性を与えるようにする
      - 1年以上かかるよ、とか＝一年以上待つ気持ちがありますよ、という表明
- 開拓フェーズのサポート
  - 新サービスの開発リーダー
  - リーダーを任されたメンバーは会社に残りやすく、サポートをお願いしたメンバーは転職していくことが多い
  - とはいえリーダーを一人に絞るのは大原則
- 研究開発案件は兼任体制で
  - 重要だけど緊急でない問題
    - 取り扱うチームを分けるべき？
  - 各メンバーの成長に対する波及効果を考慮して、チームは分けない
  - 技術力向上の手段としてアカデミアをレバレッジする
- 出向・技術顧問制度
  - 中に専門家がいないdので、外の専門家に面倒をみてもらう
  - 出向については本人の能力依存だが、よいフィードバックループが回り始めている
- 早くからマネージャーにしない
  - アンチパターン
  - もちろん本人のWILLしだいで、本人が望まない限りマネージャーにはしないほうがよいと思っている
- 相互学習しやすい組織
  - 新卒同期を集める
    - 雑談しやすい
    - 情報共有とか勉強会とか発生しやすい
    - マウントを取るメンバーがはっせいしづらい
    - 一般化すると、社内のソーシャルグラフを利用するとか
- 指示系統ラインが強くなりすぎないようにする
  - ファシリテーター
    - いわゆるスクラムマスター
    - マネージャーではなく、一メンバーが仕切ってくれるのが助かる
    - 同じPMチームの所属でも、PMチームのマネージャーが仕切るのと、メンバーが仕切るのはおそらくエンジニアメンバーのやりやすさに違いが生じる
    - PMとメンバー間の情報格差をファシリテーターが埋めてくれる

B-8 スタートアップの創業期から不確実性を乗り越えるためにやってきたこと

赤沼寛明[ユニファ]

保育業界特化のスタートアップ
すてきなデザイナーさんが在籍
- 今回の登壇のために手書きでパーカー作ってくれた
保育園で実際に業務体験
- 保育士さん目線での体験　社長も保育士さんに混ざって業務体験しながらヒアリング
保護者ユーザへのヒアリング
- パパママ社員も多い：社員とその周りの保護者の意見
早期のQA採用：プログラマのテストとプロ（QA）のテストは質が違う
- バグ検出のみならず、ユーザビリティ含めた品質向上
R&D部門設置：役割明確に
業界特有のピークへのスケール対応
- 写真のアップロード機能：運動会ピークの週、ハロウィンは1日ピンポイント・・・
社員主導での1 on 1（基本週１）
社員持ち回りでのTech Blog

C-9 本気で実践している人たちにしかできない話が聞きたい

【司会】大庭直人[Quipper]

【まだ見ぬ価値へ辿り着くためのデータプロダクト開発と組織づくり】山邉哲生[Quipper]

【組織を変えるまえに変えること】高山泰基

【組織本能の考察と適応】佐藤大典[アスクル]

【マイクロサービスにおける技術と組織の衝突に向き合う】森久太郎[FiNC Technologies]

【Engineering Managerは何をする人なのか】湯前慶大[アカツキ]

LT形式、5名の方とも話しの熱量が大きすぎてまとめきれない・・・
とりあえず「ラリー・ペイジ育ち良すぎ」