2020年これから

# これから

ここではHowは述べない。「何を」「何故」にフォーカス

Howはその組織ごとに議論して、組織に合わせた形にしていく必要がある。

# 存在意義（ミッション）

テクノロジーを用いて組織の価値（生産性や提供価値など）を高め続ける事

# 生み出すべき価値

ミッションの実現の為に何をしていく必要があるか。

大きく分けると下記4つの観点が今考えられる。

1. LeanなDevOpsの文化と体制を構築してひたすら開発組織力を向上させ続ける

2. 開発組織拡大・強化して開発組織力を向上させ続ける

3. 組織の全てのオペレーションをソフトウェアエンジニアリングを用いて効率化

4. テクノロジーから新たな価値を生み出す

5. オーシャンズ１１型組織

1,2が開発組織としての力の向上

3が組織全体の効率化と平等化

4がイノベーション

# 1. LeanなDevOps体制構築

利用者に提供する価値を最大化し続けることが求められる。

その為には、ドメイン知識が不要な場所に割いている時間を可能な限り0に近づけ、ドメイン知識が必要な場所の開発に集中できる状態にしていく必要がある。

プロダクト、基盤と物だけではなく、物に関わる人、組織、文化、仕組みをLEANに改革し続け、テクノロジーの戦略的に変革を起こし続ける。

**開発スループット**

- 起案から実装、そしてデプロイまでのフローがシンプルか

- 起案からデプロイまでの間で意思決定者は直ぐに捕まり判断できるか。中にいてるか外か

- 同じチーム内部で別々の作業をしてるとレビューはコンテキストスイッチコストが発生するしWIPが生まれ辛い

- みんなでやりにくいをやりやすい。働きやすいに変えていこう

1. WIPの制限

2. 品質、生産性に関する数値指標、障害発生、障害対応時間など、ビジュアルディスプレイを作成して可視化

3. アプリけーション、いんふらのモニタリングと可視化

- 学習の機会

- チーム内・別チームとの情報共有（社内を知る）

1. 1週間未満で製品と機能を頻繁にリリースできるよう細分化して進める能力

2. 開発職から顧客関連業務に至る作業フロー全体に対するチームの理解度とフローの可視化の度合い

3. 組織が顧客フィードバックを積極的・定期的に収集して製品デザインに盛り込む能力

4. 承認不要な開発プロセスの一部として開発チームが有する製品の作成・変更権限

1. 特許戦略が必要

# 2. 開発組織拡大・強化

LeanなDevOps体制構築とも関わるが、開発組織も継続的に成長する事になる。

人を増やす事も大事だけど、増やしたあとはコストがかかるので、増やす前にできる事を考え動く。

増えたとしても可能な限りコスト低くパフォーマンスを発揮できる状態まで成長してもらう事が大事

- eNPSが大事

- 組織

- メンバー

- 開発環境

- 開発文化

- 多様性

- Career・技術支援などの文化

- 心理的安全性を事前に上げておく

- 全社員から歓迎されているという居やすさ

- プロダクト説明など、現状の把握しやすさ

- 配属後はペアプロ、ペアオペなどで働き方のcatchアップしやすさと、自走に向けたsupport

- 発言の失敗を気にせず、発言できる空気

- 心理的安全性が高い状態

# 3. テクノロジーを使って社内の課題を解決する

開発組織の効率化、技術力向上や採用などを通して生産性を高める事はもちろんですが、現代の企業では開発組織以外（例えば営業、バックオフィスや人事などなど）でも様々な社外のテクノロジーの活用すて業務を行っていると思います。

使うテクノロジーが増えれば増えるほど、効率も悪くなり、結果として運用ルールなどが生まれ、様々なオペレーションが非効率になってしまっていると思っています。

このような状態だからこそ、これからは開発組織だけでユーザに提供する価値の最大化を考えるのではなく、、社内の全ての人がより効率的に（仕組み化、ツール化、自動化、AI化など）することで会社全体の生産性を高めていく事で、より高い価値を提供し続けられる組織にしていく必要があると思っていますし、やっていきたいです。

- 緊急性が高い（同期的である必要がある）物はSlack

- 非同期的で良い（期間に余裕がある相談・依頼など）はチケット（Asanaなど）

- Asana

- 大体の依頼は「すぐ」であるひつようはない

- 「すぐ」になる場合はギリギリまで依頼をしないことが原因が多い

- ふわっとした状態だから..ではなく、その時点で一度共有しよう

- そうする事で非同期的に円滑にコミュニケーションを行う事ができる

- Kibela

- Slack

- 同期的返事を期待してはいけない

- 電話と同じで相手の時間を奪うのは悪を前提としよう

- 自分の効率より相手の効率を意識しよう

# 4. テクノロジーから新たな価値を生み出す

もしくはデータドリブンで新たな価値を生み出す。

企業が成長続ける為には、既存の事業以外も生み出せる体制仕組みになっている必要がある。

またテクノロジートレンドや、社内で生まれた技術・仕組みを前提に考え直すことで新たな事業として立ち上げれる事にもつながる。

## 社内で生まれた技術から一つの事業になった例

## テクノロジードリブンと呼ばれる企業

# 指標

## 開発組織力という観点で見ていきたい指標

- 1日5人で10デプロイしたら、10 / 1 / 5 = 2

- 1日4人で8デプロイしたら、8 / 1 / 4 = 2

- どちらもチームとしての生産性は同じという指標に

- 指標が安定していることがまず大前提

- 安定させつつもより向上させていくにはどうするかを考えていく事に繋がる

- 派生してデプロイ時間とか開発時間とかの計測に繋がる

- 中長期的に開発が継続して続けて、気づいたら使わないコード、重複したコードなどが生まれてくる。

コードの肥大化は負債となって返ってくるのでしきい値を設けて改修タイミングを考えていく必要がある。

- また初回リリース以降数年立つと負債になるので、作り直しもちゃんと考えないといけない。

目先の利益を追いすぎると将来の大きな利益を得るタイミングで負債が爆発する

- 障害発生から修復までの対応時間

- デプロイして失敗した回数

## 組織全体の効率化で見ていきたい指標

## 採用・オンボーディング

# 参考図書