# Tech Casual Lunch #3
## タイトル
新規事業とアジャイル開発　～NeWorkを事例に～

## 日時
11/5(木) 12:00～13:00　@Teams

## イメージ
- Digital Forumの吉羽さんと大津谷さんクロストークの深堀版
- 吉羽さんがファシリテートする進め方。流れはこういう感じ。
- 世の中的な流れを解説(吉羽さん)
- NeWorkの実例をインタビュー(吉羽さん→大津谷さん)
- コムが解決すべきポイントを示唆(吉羽さん)
- ディスカッション含め全体で60分以内（随時割り込み質問もOKか）
☆Teamsでのクロストークのオペは要検討

## スピーカ
- 吉羽さん(ファシリテータ)
- 大津谷さん　or/and NeWork開発メンバ（PdMなど）

## ゴール(３つ)
1. **NeWorkの開発過程**を経営層や管理職/社員へ発信する（＠社内Stream）
2. 不確実で変化の激しい領域での新規事業の成功確率を高めるために、プロダクト開発を**阻害しているポイント**は何か、**どう変革する**といいのか
- キーワード：**内製開発**（戦略的な人材配置や予算配置を含む）、**機能するチーム**、**社内プロセス**
3. **第2のNeWorkを創り出す**ために、まず何をやっていくかヒントを得る

## シナリオ
### (1) 導入 15分
- （吉羽さんから）**不確実で変化の激しい領域での新規事業開発**では、WFな従来のやり方ではうまくいく可能性は低く、**短くフィードバックサイクルを繰り返していくアジャイルな開発手法を適用することが重要**になる、ことを簡単におさらい的に解説　＃動画リンクは共有しているものの見ていない人もいる想定
- その中でもキーになるのが、**内製開発**（人材配置・予算配置も含む）・**機能するチーム**・**社内プロセス**
- これらがなぜ重要なのか、どうやって実現していくのか、なぜコムでは実現しにくいのか、を**NeWorkの開発の裏側を深堀ながら紐解いていきたい。** とフリ。＃具体例や成功例があった方が幹部がイメージしやすい
- 「新規事業とアジャイル」のダイジェスト版

### (2) 内製開発　-10分
- （吉羽さん）なぜ新規事業開発では「内製開発」が重要なのか、どうやって内製開発を始めるといいのか、を解説
- フィードバックサイクル、スピードの話の話、オーナーシップ/リーダーシップの話
- （吉羽さん→大津谷さん）NeWorkはどうやって内製チームを作っていったのか？その過程で苦しんだことはどんなこと？
- （吉羽さん）コムが解決すべきポイントを示唆
- 実はパートナー社員に頼らざるを得なかった。
　→　**内製開発の始め方、内製と外注の戦略的な取捨選択やエンジニアの戦略配置、事業ポートフォリオ自体の短いサイクルでの見直し**　など
- 内製をなぜ始められないか？
- 人がいない or ホント? 2ヶ月で作れたこともある
- 強いゴール設定、制約条件があったからこそ
- 澤田さんのコメントは良い面と、悪い面がありこれは良かったこと
- 2ヶ月の制約はMVPでだすしかない、現場は怖がるから
- リリース日は本当に怖かった。20人分の5000人Waiting。Twitter評判よくてみれた
- イメージ的には30点でできた
- セキュリティは絶対という話
- 若干、軽視している点があったが、手を抜かない方針にできた(例のインシデントなどもあり)
- 幹部の意識としては、セキュリティインシデントさえおこさなければ許容できるのでは
- アジャイル開発に変化したとしても、セキュリティは守る、それ以外は柔軟にやろう
- NeWorkは、大津谷さんにとって、SkyWayの再現であった
- それは今回、NeWorkで検証できた

### (3) 機能するチーム　-10分
- （吉羽さん）なぜ「機能するチーム」が重要なのか、どうやってチームを成長させていくといいのか、を解説
- チームビルディング、Working Agreementの話、安全性の作り方
- e.g. 何を言ったかを重要視する、何でも言っていい風土づくりをサクラ的に、など

- （吉羽さん→大津谷さん）どうやって機能するチームを作ったのか？その過程で苦しんだことはどんなこと？
- （吉羽さん）コムが解決すべきポイントを示唆
　→　**心理的安全性、ヒトを集めただけではいい成果は生まれない、タックマンモデル、チームビルディングや1on1等のコミュニケーションに投資を厭わないこと**　など
- チームを維持するのが大事という話まで持っていける

### (4) 社内プロセス -10分
- （吉羽さん）アジャイル開発を実現している会社はどういうサービス開発プロセスで運用していることが多いのか、を解説
- （吉羽さん→大津谷さん）NeWorkはどうやってコムの中でアジャイル開発を実現しているのか？その過程で苦しんだことは？
- （吉羽さん）コムが解決すべきポイントを示唆　
　→ 開発/提供/廃止判断プロセス、やその意思決定会議などへのオーバーヘッド　など
- サービスマネジメントのポリシーを例に
- 超大作で読む気をそがれる
- PPTベースで分かった気になりがち
- 実際には抽象的な表現が多い
- 企画側とPoC、大量生産とチームが違うイメージを持っています
- 新規事業とインフラ事業では、ポリシーは異なるだろう
- ペーパーワークなどのOHを考えるとボトムアップ的に新規事業は生まれにくい
- このサビマネ下で、アジャイル開発のやりかたが暗黙知化してしまっている

### (5) その他（時間があれば） -なし
- （吉羽さん→大津谷さん）今NeWorkが抱えている/今後顕在化しそうな課題はあるのか？

### (6) まとめ
- （吉羽さん）第2のNeWorkを創り出すために、解決すべきポイントとアクションのまとめ
- NeWorkを再現するための必要条件とは
- 事務方をアサインしていただければ具体的な検討を技術顧問3名でお手伝いさせて頂く
- HR部　もしくは、直接技術顧問へご連絡ください

## 10/19 打合せアジェンダ
- シナリオと時間配分のイメージ合わせ
- 資料作成の分担
- 次回打合せ（10/29）

## 10/29 打合せアジェンダ
- スライドのディスカッション
-
- 時間配分
- イントロ：1分
- 吉羽さんトーク：約45分
- 前回のサマリ　15分（かなり巻いて）
- 内製開発　10分
- 機能するチーム　10分
- 社内プロセス　10分
- まとめ　1分
- 質疑：15分
- 丸岡さん / NeWork
- 工藤さん / NeWork
- 金井さん / サビマネ
- 佐々倉さんのProject MCU　など

## 番外編 深堀りインタビュー
### 「前回のサマリー」部分について
- 「プロダクト価値の思い込み」のスライド
- 「なかったことにする／一部の数字だけ成功として報告する」
- To経営だけではなく社員～マネージャ間や社員間・組織間でも起こり得る
- プロダクト開発だけではなく、施策でも同じ
- なぜこれが起こってしまうのか？
- 組織重力の話？隠した失敗を後々上司から責められる可能性があるかないか、が尺度になっている？
- **成果の測定**ができていない/下手なので、うまくいったか/失敗したかの判断がだれもできない？
- 何らかの目的をもって施策を立ち上げるので、目的が達成されたかどうか指標/OKRが大事
- 指標化が難しい　本当は会社や組織全体の数値目標と紐づけたいがなかったりすることが多い。あとはデータが少ない。
- AWSだと起こりにくいのか？
- そもそも**失敗**ってどうやって判断される？
- 良い失敗と悪い失敗 / Google
- 2種類の意思決定 / Amazon
- レトロスぺクティブの文化やタイムボックス
- Ⅱ型で失敗した人やチームの**評価や処遇**ってどうなるの？
- どういう対策があるのか？
- まずは、こういう重力があるということを頭に入れる
- 経営やマネージャができることは？
- 失敗をオープンにしたり、よい失敗を称える、2段構えの意思決定とレトロスぺクティブの文化
- 社員ができることは？
- オカシイと思ったことは声を上げる
- さもないと不要な仕事が減らない
-
### 内製開発
- 「マネージャーの経験によって開発手法が決まるのではなく、問題のドメインによって決まる」のスライド
- 裏を返すと未経験の開発手法や技術を採用するには"恐さ"がある（特にIT業界は後発・若者優位だし）
- 経営ができる支援は？
- 成果を短期で求めすぎない、**マネージャへの教育支援**
- AWSではマネージャへの教育ってどんなのやる？
- 1on1のやり方2日間
- 採用面接のトレーニング
- プレゼンテーション
- マネージャとしての活動
- ランダムで朝から晩まで
- コーチング
- マネージャへの役割が重要視されている
- 失敗を計画できたらいいと思う
- その時はどのように**順調さを測れば**いい？
- 社員はどうすればいい？
- 開発手法や技術について、組織を説得することが大事？
- マネージャがHowまでマネジメントしない。
- マネージャはどうすればいい？
- アンラーニング、部下から学ぶ姿勢
### 機能するチーム
- 90年代の野村ヤクルトのファン
- 「チームの形成」のスライド
- エンタープライズのSI領域のような、「失敗しづらい／効率性が求められて／クネビンでいうと右側で／外注率が高くそもそも長く持続させるつもりがないようなチーム」ではどうするといいのか？
- (持っているスキルや経験のカットで)プロジェクトに人をアサインしがち
- 結果、チームとしてのパフォーマンスは高まりにくい
-
- 切って貼ってのアサインメントよりも多少アジリティが落ちるとはいえ、重要なところには機能するチームを形成すべき
- どうやって機能するチームになるといいのか？
- まずは、人は集まったからあとよろしくというわけではないってことを全員が認識しておくべき
- チームビルディングっていう組織文化でもない
- 正直、飲み会くらいしか・・
- オンラインでのチームビルディングって何からやっていくといい？
- マネージャや社員ができることって？
- 「良いチーム」と「良くないチーム」って相対化されてた？