Developers Summit 2019 Summerに参加
デブサミに参加してきました。
このようなイベントの参加は久々だったのですが、とても良い刺激になりました。
アウトプットしないと一年後には忘れているので、会場で殴り書きしたスマホのメモを、ブログに書いておきたいと思います。
会場で書いたメモ
愛されるプロダクトをつくるエンジニア組織とは――「テクノロジー」「開発プロセス」との緊密な関係
※途中参加でした
・プロダクトマネージャー
プロダクト全体を見る 事業全体に等しい
営業、サポートも一眼のチームになる
地味で全て拾い上げる泥臭い仕事である
・エンジニアリングマネージャー
強いエンジニアリング組織をつくる
個人より組織を考える 開発はしない
テックリードも求められる
・エンジニア
テックリード 技術リード 育成などを行う
組織は事業主体で横断的になる
・ジョブディスクリプション作成の勧め
職種が何を表すか組織によって異なる
役割を文書化してみる
・エンジニアは全体を経験するのがよい
運用、QA
・要件について
仮説検証サイクルをまわす スケーラブル
スクラップアンドリビルド
壊すことを厭わない
属人性を外す
メイクファイルでドキュメント、開発環境すべて用意する
マイクロサービス 分割 協調 自律
柔軟性と規律を考える
そのテクノロジーがどう組織に貢献するか
・プロダクトマネージャーが調整役でおわっていないか？
事業者、エンジニアと対等である
プロダクトマネージャー以外もプラダクトを考える
コード1行でもユーザーの姿を考える
プロダクト愛
テクノロジーで人の生活を変える喜びを覚える 日本人はパッションが足りない
プロダクト志向 愛されるプロダクトを考える
ヤフーのアプリにおける会社全体での業務効率化について
会社における数多くのサービスチームのノウハウ、情報共有
サービス横断チームを作成
大規模組織における情報、知識共有がテーマ
ソフトウェアアーキテクチャの組織力学
開発者体験 ＝ 企業のデジタル化
アーキテクチャと組織
アーキテクチャは、権力
ある選択肢を選びやすく、ある行動が不快になるようにする
技術でなく人間やビジネスに焦点を合わせる
ビジネスモデル、プロジェクト、組織構造は相互に関連して、アーキテクチャを構成する
アーキテクチャとは、何かをしやすく、何かをしにくくする →コードもそう書く
ウェブ開発フレームワークは、ウェブ以外をしづらく、ウェブ開発をしやすくする
社会を取り巻く目に見えない力を生み出す構造 ＝ アーキテクチャ
よくすることができる ＝ 交換可能
依存することで理不尽が生まれる
選択肢を持つ方が強く、持たない方が弱い
ソフトウェア、プロジェクト、組織においても、理不尽はいつも選択肢が少ない方へ
ソフトウェアアーキテクチャにおいて交換可能性が重要
廃棄可能、再構築可能のインフラなど
プロジェクトの依存関係は自明ではない
プロマネの仕事は進捗管理ではない
依存性、困難性に対して、常に選択肢を持ち続けるようアーキテクティングする
漸進的プロセスはアジャイル、スクラム
依存関係は自明ではない リファクタリングしていく
継続的なコードリリースを前提にする
組織構造はコミュニケーション構造そのもの
悪い組織構造は悪いシステムを生み出す
ころころ組織構造を変える会社はシステムがダメ
取引コストによって会社、組織の境界線が決まる
取引コストが高いと技術的負債が生まれる
古いからでなく、組織が必要な速度で変更できなくなるのが技術的負債
抽象的なものほど安定的な方が良い
目的に対して手段を交換可能に維持する
ティール型組織でサービス立ち上げが成功した話
大失敗から立ち直した話
縦割り組織で情報不透明 管理コスト増加
反省してティール組織へ
ティール組織とは
ゴールに向かって自走
自立であり統治しない
すべての情報にアクセス可能
ミッションを共有して自走する体制に
1人企画からチーム全体で考えるように
ゴールを見据えてアーキテクト設計可能に
工夫した点
サポーター制度 各分野で困ったらサポーターに必ず相談
■あらゆるものをカイゼンせよ
・ナビタイムジャパンさん
プロダクトは改善しながらビジョンに近づく
重要な順に並べられたバックログを実施していく
優先順位とはビジョンへの最短経路
気づいたこと、ユーザーの声から新たなバックログが生まれる
カイゼンを阻むもの
ユーザー、関係者、あふれるバックログ、長い開発歴史
何と向き合うか？
まずあふれるバックログを整理
ルールを設け、棚卸しして勇気を持ってクローズ、削除
デグレを起こさない仕組み作り
リグレテスト環境を用意する
スプリントのどこかで内部完全に集中する日を作る
リファクタ、リリース自動化、テストなど
優先順位を決める土台
チームでインセプションデッキを作り、チームで共通認識をつくる
雑多なユーザーの声に対して
狩野モデルでなんの品質を上げるか検討
ユーザーボイスだけでなくユーザーログで課題解決
ログでは時間をずらした検索が多かった
ユーザーストーリマッピングをみんなで作成して、共通の課題意識をつくる
組織の壁に直面したら目線と温度感を合わせる
・駅すぱあとさん エモい話
・ギルドワークス・エナジャイルさん
プロダクトオーナー2.0
アジャイル開発は二度失敗する
1 アジャイルの習慣をチームで身につける
2 開発チームとプロダクトオーナーの間に生まれる境界線
プロダクトオーナーは高負荷
いつも機能するとは限らない
開発チームからPOへの越境
チームで補完していく
開発者が技術的なこと、ビジネス側がビジネス的なことを補完する
PBLの詳細化、受け入れを開発チームで行う
仮説検証が大事
仮説検証を実施して、得られた学びをチームで分かち合う
向かうべきはプロダクトオーナーの民主化
仮説検証から学びのプロダクトの基準をつくり、チームに宿す
役割による調整から仮説検証による学びを中心とした共創へ
