**# これから** ここではHowは述べない。「何を」「何故」にフォーカス Howはその組織ごとに議論して、組織に合わせた形にしていく必要がある。 **# 存在意義（ミッション）** テクノロジーを用いて組織の価値（生産性や提供価値など）を高め続ける事 **# 生み出すべき価値** ミッションの実現の為に何をしていく必要があるか。 大きく分けると下記4つの観点が今考えられる。 1. LeanなDevOpsの文化と体制を構築してひたすら開発組織力を向上させ続ける 2. 開発組織拡大・強化して開発組織力を向上させ続ける 3. 組織の全てのオペレーションをソフトウェアエンジニアリングを用いて効率化 4. テクノロジーから新たな価値を生み出す 5. オーシャンズ１１型組織 1,2が開発組織としての力の向上 3が組織全体の効率化と平等化 4がイノベーション **# 1. LeanなDevOps体制構築** 利用者に提供する価値を最大化し続けることが求められる。 その為には、ドメイン知識が不要な場所に割いている時間を可能な限り0に近づけ、ドメイン知識が必要な場所の開発に集中できる状態にしていく必要がある。 プロダクト、基盤と物だけではなく、物に関わる人、組織、文化、仕組みをLEANに改革し続け、テクノロジーの戦略的に変革を起こし続ける。 - ***アーキテクチャ**** - 疎結合化され修正による影響範囲が狭い - テストの大半を統合環境を必要とせずに実施できること（テスト容易性） - アプリケーションのデプロイに、ほかのアプリケーションデプロイなど作業を必要としないこと（デプロイ容易性） - 他チームやチーム外のメンバーに依存せずに変更を加える事ができてデプロイ可能 ****開発スループット**** - 品質、生産性に関する数値指標、障害発生、障害対応時間など、ビジュアルディスプレイを作成して可視化して改善 - 開発フロー - 起案から実装、そしてデプロイまでのフローがシンプルか - 意思決定者の存在 - 起案からデプロイまでの間で意思決定者は直ぐに捕まり判断できるか。中にいてるか外か - チーム内のコミュニケーションやレビューによる割り込み - 同じチーム内部で別々の作業をしてるとレビューはコンテキストスイッチコストが発生するしWIPが生まれ辛い - リソース効率とフロー効率 - 組織全体の意識 - みんなでやりにくいをやりやすい。働きやすいに変えていこう - ***継続的インテグレーションと継続的デプロイメント**** - CI待ちやデプロイ作業、そしてデプロイ後動作確認、デプロイ後のロールバックにかかる時間をいかに0にできるか - セキュリティ、監査などの対応を以下に小さい段階に発見して対応できるか - デプロイ直前に重大なインシデント発覚による手戻りなどはスループットが下がる要因になる - 依存関係がなくアプリケーション単体でのオンデマンドなデプロイがいつでも可能な状態 - ***リーンマネジメント**** 1. WIPの制限 2. 品質、生産性に関する数値指標、障害発生、障害対応時間など、ビジュアルディスプレイを作成して可視化 3. アプリけーション、いんふらのモニタリングと可視化 - ***組織**** - バーンアウト（燃え尽き症候群） - 成長（レガシーでモダンな他社に意識が向くとそれだけでNG） - 学習の機会 - チーム内・別チームとの情報共有（社内を知る） - ***リーン開発のプラクティス**** 1. 1週間未満で製品と機能を頻繁にリリースできるよう細分化して進める能力 2. 開発職から顧客関連業務に至る作業フロー全体に対するチームの理解度とフローの可視化の度合い 3. 組織が顧客フィードバックを積極的・定期的に収集して製品デザインに盛り込む能力 4. 承認不要な開発プロセスの一部として開発チームが有する製品の作成・変更権限 - ***不要な争いから将来的に身を守る**** 1. 特許戦略が必要 **# 2. 開発組織拡大・強化** LeanなDevOps体制構築とも関わるが、開発組織も継続的に成長する事になる。 人を増やす事も大事だけど、増やしたあとはコストがかかるので、増やす前にできる事を考え動く。 増えたとしても可能な限りコスト低くパフォーマンスを発揮できる状態まで成長してもらう事が大事 - ***採用（自然応募、スカウト、リファラル）**** - リファラル - eNPSが大事 - 組織 - メンバー - 開発環境 - 開発文化 - 多様性 - Career・技術支援などの文化 - ***入社前オンボーディング**** - 入社後可能な限り早く溶け込んで、パフォーマンスを発揮できるように、入社前に行える事があるのではないか - 心理的安全性を事前に上げておく - ***入社後オンボーディング**** - 入社してから可能な限りパフォーマンスを発揮できるように - 全社員から歓迎されているという居やすさ - プロダクト説明など、現状の把握しやすさ - 配属後はペアプロ、ペアオペなどで働き方のcatchアップしやすさと、自走に向けたsupport - 発言の失敗を気にせず、発言できる空気 - 心理的安全性が高い状態 **# 3. テクノロジーを使って社内の課題を解決する** 開発組織の効率化、技術力向上や採用などを通して生産性を高める事はもちろんですが、現代の企業では開発組織以外（例えば営業、バックオフィスや人事などなど）でも様々な社外のテクノロジーの活用すて業務を行っていると思います。 使うテクノロジーが増えれば増えるほど、効率も悪くなり、結果として運用ルールなどが生まれ、様々なオペレーションが非効率になってしまっていると思っています。 このような状態だからこそ、これからは開発組織だけでユーザに提供する価値の最大化を考えるのではなく、、社内の全ての人がより効率的に（仕組み化、ツール化、自動化、AI化など）することで会社全体の生産性を高めていく事で、より高い価値を提供し続けられる組織にしていく必要があると思っていますし、やっていきたいです。 - ***情報の透明化**** - 誰でも見たい情報にたどり着くことができる。 - どういう情報が存在するのか知ることができる - 情報に対してのACLは取得する人が選択する事ができる - ***コミュニケーション**** - コミュニケーションは他者の時間を奪うことにも繋がる為、特性に応じたコミュニケーション方法を選択できる様に整える。 - 緊急性が高い（同期的である必要がある）物はSlack - 非同期的で良い（期間に余裕がある相談・依頼など）はチケット（Asanaなど） - ***オペレーション効率**** - 社内ワークフローなどの仕組み化と簡素化など - ***上記課題に対して今使う物の例**** - タスク管理（基本すべての作業・依頼などがここに集約） - Asana - 大体の依頼は「すぐ」であるひつようはない - 「すぐ」になる場合はギリギリまで依頼をしないことが原因が多い - ふわっとした状態だから..ではなく、その時点で一度共有しよう - そうする事で非同期的に円滑にコミュニケーションを行う事ができる - ストック型情報共有サービス（基本すべての調べてがここに） - Kibela - 非同期・同期コミュニケーションツール（基本議論がここに） - Slack - 同期的返事を期待してはいけない - 電話と同じで相手の時間を奪うのは悪を前提としよう - 自分の効率より相手の効率を意識しよう - ***作り上げる仕組みなど**** - 人事労務周りはAI化、自動化など効率的に支援する仕組みを作ることで解決していくことは可能 **# 4. テクノロジーから新たな価値を生み出す** もしくはデータドリブンで新たな価値を生み出す。 企業が成長続ける為には、既存の事業以外も生み出せる体制仕組みになっている必要がある。 またテクノロジートレンドや、社内で生まれた技術・仕組みを前提に考え直すことで新たな事業として立ち上げれる事にもつながる。 **## 社内で生まれた技術から一つの事業になった例** - Amazonから生まれたAWS - ECStudioから生まれたチャットワーク - Mixiから生まれたDeployGate **## テクノロジードリブンと呼ばれる企業** - AirBnb - Uber **# 指標** **## 開発組織力という観点で見ていきたい指標** - Deploy / Dev / Developer - 1日5人で10デプロイしたら、10 / 1 / 5 = 2 - 1日4人で8デプロイしたら、8 / 1 / 4 = 2 - どちらもチームとしての生産性は同じという指標に - 指標が安定していることがまず大前提 - 安定させつつもより向上させていくにはどうするかを考えていく事に繋がる - 派生してデプロイ時間とか開発時間とかの計測に繋がる - Code Lifecycle - 中長期的に開発が継続して続けて、気づいたら使わないコード、重複したコードなどが生まれてくる。 コードの肥大化は負債となって返ってくるのでしきい値を設けて改修タイミングを考えていく必要がある。 - また初回リリース以降数年立つと負債になるので、作り直しもちゃんと考えないといけない。 目先の利益を追いすぎると将来の大きな利益を得るタイミングで負債が爆発する - 平均修復時間 - 障害発生から修復までの対応時間 - 変更失敗率 - デプロイして失敗した回数 **## 組織全体の効率化で見ていきたい指標** - 課題（依頼）解決平均時間 - 不要な物が何か、オペレーションごとに指標を取る **## 採用・オンボーディング** **# 参考図書** - [LeanとDevOpsの科学](https://www.amazon.co.jp/dp/B07L2R3LTN)