2020-07-21 Developers Summit 2020 Summer #devsumi
2020/07/21 に開催された Developers Summit 2020 Summer のイベントレポートです。
●イベント概要
昨今のDevelopers Summitは、世の中やテクノロジーの変化にフォーカスし、不確実性の高い世の中において、開発者が一歩踏み出す勇気を授けたい、そのような思いでお届けしてきました。「デジタルトランスフォーメーション（DX）」に代表されるように、これまでテクノロジー化されていなかった領域にも、開発者の影響力が及んでいます。
その「変革」が、新型コロナウイルス感染症の拡大により、半ば強制的にもたらされました。リモート開発、事業の転換などさまざまな変化が余儀なくされた昨今の状況。戸惑いと試行錯誤を伴いながらもこのような世の中の過渡期に関与できることは、開発者として面白い時代に生きていると言えるのではないでしょうか。
今回の「Developers Summit 2020 Summer」では、デブサミシリーズ初のオンライン開催として、開発者が世の中の変革を力強く楽しく推進していくための、ヒントを得られる場を目指します。
■その後のソフトウェア・ファースト
及川 卓也さん [Tably]
●テイブリー
・tableは名前の卓から
・岩切さんが考えてくれた
一緒にいる人を今いるところから
高いところに連れて行ってくれる
noteにまとめてあります
テーブルがなければ
地べたで食べたりしなければならない
食べ物を人が使えるところに高めている
テーブルは人が集まる場所
・3つのことをやっている
技術、プロダクト、人と組織
はじめは技術を支援していた
プロダクトのマネジメント、グロースが
できていないところが多いことに気づいた
人と組織に関わることが
できていないところが多いことに気づいた
外部に任せていたから
管理や育成の方法がわからない
組織として健全に成長していくために支援
・はじめはスタートアップの支援が中心だった
大企業はゆっくりとしか進化しない
ソフトウェアを武器にしようとする姿勢にも
後ろ向きに見えた
・今はスタートアップ、中堅、大企業を支援
海外のスタートアップで刺激を受けた
日本でも刺激していけるのでは
大企業が本気で変わろうとしたときの
インパクトは計り知れない
・ハッカーライフラボで話した
ログミーの記事になっている
●ソフトウェア・ファーストで伝えたかったこと
・ソフトウェアが大事だよ
・ソフトウェアが一番という意味ではない
ソフトウェアの割合は小さいかもしれない
ハードが基本かもしれない
人が触れるサービスが大切かもしれない
・ソフトウェアをどう使うかを定義することで価値が変わってくる
事業でもプロダクトでも
ソフトウェアは全体の1%くらいの小さなものかもしれない
でもその影響は計り知れない
・顧客のニーズは簡単にはわからない
昔は単純だった
先に進んでいる諸外国に倣えば良かった
産業の破壊 & 再生
仮説検証
仮設を立てて検証していく
小さく始めて大きく育てる
●SIerに伝えたいこと
・SIerが日本の社会をIT面で支えてきた
・視座を変えてみてもらえると良いのでは
顧客がSIerにシステムを発注して利益を得る
自社の利益を優先すると
使わなそうな機能がほしいと
言われてもつくってしまう
・顧客は提供したサービスで利益を上げる
サービスを提供して
エンドユーザーから利益を得る
・SIerは顧客が国内の競合に打ち勝つための支援をしているはず
日本は世界の最先端ではない
ITの活用方法は最適ではないかもしれない
海外のプレイヤーが入ってきたら市場を取られてしまうことも
海外のアプリの使い勝手の良さに驚くことがある
・IT力は社会力そのもの
顧客を通じて社会力を上げている
・日本の社会を上げていく視座を
お客さんに言われたものを出すだけでなく
・コロナで世界は危機的な状況
世界は課題だらけ
SDGs
・視座を上げる
自社が儲かる
顧客が儲かる
日本が儲かる
世界が儲かる
・自社の儲けからでも考えられる
お客さんをだまくらかして収益を得る
お客さんの競争力が落ちていく
搾り取りたくても、搾り取れない
・世界からプライヤーが入ってきて市場を奪われる
日本の社会力が低迷したら、市場が小さくなっていく
日本で儲けることもできなくなる
・世界の市場が小さくなれば
世界で儲けることもできなくなる
・SIerだけでなく、すべての人が高い視座で
●ソフトウェアとは
・各国の捉え方
米国：ビジネス
欧州：科学
日本：製造
・日本は製造業を模範にしすぎているのでは？
考え方、手法などリスペクトすることは多い
そのまま持ち込むことには無理がある
例えば、ソフトウェアに製造工程は存在しない
●ソフトウェア・ファースト発売後に起きたこと
・トヨタ 豊田章男社長が言及
・COVID-19
新しい生活様式 ニューノーマル
●コロナ禍で気づいたこと
・情報の欠落
会って話したほうが意思を理解しやすい
何を伝えるべきか、相手に与えられる価値はなにかを考える
・リモートワークは2つの側面
福利厚生
子供の送り迎え、親の介護、休むほどではない体調不良
働きやすいから、通勤の手間をかけたくないから
以前は懐疑的だった
メンバーのクリエイティビティ、プロダクティビティを
考えると非効率
サテライトオフィスでも、メインの場所と情報格差
となり同士でちょっと話したほうが早い
・リモートワークしかない状況
何を伝えるべきか
相手に与えられる価値はなにか
本質を考えるしかない
・会社の中、個人の中の課題が今の状況になって浮上してきた
・そもそも不要だったこと
当たり前のようにオフィスに全員集まって進めてきた
できなくなったときに、不要だったことが見えるように
・コロナ禍の捉え方
Anomaly or Transformation
障害であり、いずれ復旧する
不可逆的な、元に戻ることのできないもの
・落ち着いたとしても、なかなか元に戻そうとは思わない
●プロダクトの強い軸
・視点の抽象度
core：ビジョン
input：ユーザーの課題、得たい価値
output：UI/UX、ユーザーシナリオ
・ユーザーの課題、得たい価値が変わってきている
→ もう一度ビジョンから考えることが必要
・飲食店でこだわってきた音楽や店の雰囲気などの体験
同じことはできない
どんな価値を提供したかったのかを考え直す
もしかしたら飲食ではなかったのかもしれない
●今の日本はスタート地点に立った状態
・プロダクトだけを見ていてはだめ、高いところから
・ソフトウェア開発からプロダクト開発へ
ユーザーにどういった価値を提供するのか
コードの向こうにユーザーを見る
■GCP を支える Google のソフトウェア開発環境に見るマイクロサービス設計のヒント
中井 悦司さん [グーグル・クラウド・ジャパン]
●GCPのコンセプト
・Googleのソフトウェアエンジニアと同じ体験を
一般のデベロッパーにもパブリッククラウドとして提供
・コンシューマー向けの便利なツールを提供してきた
SearchEngine, Mapsなど
・気づいたらクラウドインフラをつくっていた
世の中でパブリッククラウドが広まってきた
社内の体験を一般の人にも使ってもらおう
として始まった
・Googleのソフトウェアエンジニアと同じ体験
そうは言ってもどう組み合わせればいいのやら、、、
中の人は実際どうやって使っている？
・グーグルを支えるテクノロジー
社内での使い方を説明していっています
・マイクロサービスという観点では公開されていない
GCPのサービスを組み合わせて
ほぼほぼ同じしかけはつくれる
・同じ問題
そうは言ってもどう組み合わせればいいのやら、、、
中の人は実際どうやって使っている？
●マイクロサービスによるシステム設計
・アプリケーションデザインの知見
業務要件に合わせて、マイクロサービスに分割
・クラウドインフラの知見
要件だけを見て分割したらうまくいくわけではない
実装してみたらインフラにマッチしないなどはあるある
●この２つの役割が軸
・SRE
システム運用の方法論
クラウドインフラの知見
・マイクロサービスアーキテクト
アプリケーションデザインの知見
クラウドインフラの知見
SREとペアになる役割
・ここを語る仲間を増やしたい
立場としてやっている人はたくさんいる
集まって知見を共有する場所がまだない
●システムアーキテクチャーとは
・設計者がシステムに与えた形
・システムアーキテクチャの目的
要求通りに動くことだった
要求が変化するようになった
変化に追従できることが必要
→ 開発者、運用者の生産性を最大化
使う人のためではなく、提供する人のため
提供する人が幸せになれば、使う人も幸せになっていく
●マイクロサービスとは
・協調して動作する、小規模で自律的なサービス
・ネットワークデバイス
自分の中に自分のconfigだけを持って動く
これをアプリケーションで実現しようとしている
・疑問
なぜマイクロサービスは生産性を上げるのか？
マイクロサービス以外ではだめなのか？
・変化に追従するための基本原則
単一責任の原則
１つの要求を満たすために１つのモジュール、クラスを用意する
・目指すところはマイクロサービスに似ている
要求の変更が、小さな一つだけだと変更は簡単
大きくなると、周辺を思い出す、悩む時間が必要
一度に理解できる範囲には限界がある
間違いなく、安全に変更できる
・モノリスとマイクロサービスの比較
適切にモジュール化されたモノリスなら変化に追従できる
●マイクロサービスが必要な理由
・これらを満たす方法はマイクロサービスしかない
技術異質性
部分的スケーラビリティ
対象外性
デプロイ容易性
・技術異質性
C++で、Golangで、などマイクロサービスごとに実現できる
・部分的スケーラビリティ
モノリス全体でのスケールは大変
１モノリスに１物理サーバなど
コンテナ単位で手軽にスケール
・耐障害性
１つが止まっても、他のサービスが影響を受けない
・デプロイ容易性
つくった機能はデプロイしなければ意味がない
モノリスだと、モジュール分割しても、デプロイは大きな一つ
サービス単位でカナリア、ブルーグリーンなど
●マイクロサービスの設計例
・Building Secure & Reliable Systems 11章
パブリックCAシステム
リクエストパーサはC++、Golangの2種類が動いている
外部のサービス呼び出しは機能制限された安全なコンテナで実行
●どのような業務・システムにマイクロサービスを適用していますか？
・自社開発のサービスは全てマイクロサービス
・社内の環境がマイクロサービス前提で作られている
標準化された開発ツール・プロセスがある
●単一リポジトリによるソースコード管理
・Single Source of Truth
GitHubだと、プロジェクトごとにリポジトリを分ける
gitとは違う独自のしくみで1つのリポジトリで管理
ディレクトリを分ける形で管理
・プロジェクト間でソースの再利用が簡単
リポジトリが別れていると、shared libraryのバイナリを共有する
プロジェクトごとに、バージョン管理や全体の適用状況の管理が必要
ソースをインクルードするだけ
●ブランチを持たない開発ツリー
・修正はメインラインに直接反映
継続的インテグレーションそのもの
・リリース用のブランチだけ分けて管理
●コミット単位を小さくする
・コードレビューシステム
gerritの前身のシステムを利用
コミット前にレビュー
・change list
ファイル
90%は、10ファイル以下
35%は、1ファイル
行
中央値は 24行
10%は 1行のみ
レビュア
99%で、レビュアーは5人以下
75%で、レビュアーは1人
・コミット単位が小さいとレビュアーも楽
●デプロイツールとモニタリングサービスの連携
・本番環境に反映するときはカナリア、ブルーグリーンなどを適用
・カナリアで一部だけデプロしたものと全体のモニタリングデータを比較
動作異常を自動検知するサービス
・自動化のツールは乱立している
どの組み合わせが良いかはわかりにくい
●アプリケーションフレームワーク
・標準モジュール、テンプレート適用
※railsに近い
scaffolding
gRPクライアント
ロギング、モニタリングの自動適用
・CI/CDの標準も自動適用
環境移行
カナリアリリース適用
ロールアウト、ロールバックの自動化
●マイクロサービスのデメリットを克服するツール・手法
・サービスの自律性を保ちつつ、トランザクション的な連携を実現する方法
・サービスメッシュなどマイクロサービスのためのインフラ技術が進化
・マイクロサービスを前提としたアプリケーションフレームワーク
・google社内向けに最適化されているので、そのままでは便利にならない
●今後に向けて
・サービスの組み合わせでgoogleの基盤を再現することはできる
・どうこれを使っていくかの知見が必要
・google社内のものをそのまま出しても、使いづらい
・マイクロサービスアーキテクトが集まって知見を語る仲間を増やしたい
■コロナ禍の企業変革とデジタル変革 ～内製エンジニア組織がビジネスを牽引する時代へ～
小久保 岳人さん [Insight Edge]
※出遅れてお話伺えず。
猪子 徹さん [Insight Edge]
●ビジョン
・Re-design the workld
技術の力で世界を変える
まずは
Re-dsign the company to the tech company
住友商事をテックカンパニーに変える
●tech campany
・step
既存ビジネス高度化
新ビジネス創出
ビジネスモデル変革
→技術力とともに素早く/大きな価値創造できる企業
・価値創造の素早さ、大きさ
縦の素早さ
1PRJの実現速度
横の大きさ
事業横断の情報共有/場の提供
→Bizと一体で実現していく
●内製エンジニアに求められる役割
・共有
事例、ソリューション、パートナー情報
・相談
案件などの問い合わせ
・実現
システム構築、データ分析
・蓄積
ノウハウ蓄積、ソリューション開発
・このサイクルを高速に、並列化して回す
→大きな価値貢献へ
・Lean Cycleと構造と同じ
●どこから始めるか
・起点は共有
プレゼンスを高めなければ相談が来ない
・経緯
「内部エンジニア組織ができたので、活用するように」
→認知はするが、活用方法がわからない
→計画/推進で課題発生
・課題一例
PoCで効果が出たが商用化で見積もりが予想外に高くてスタック
複数ベンダーに依頼したが求める成果が出ず
検証フェーズ直前で、コロナ影響で遅延
●社内マーケティング戦略
・おもてなし
認知：タッチポイントの質・量
興味検討：情報の質・量
・タッチポイントの充実
テックタッチ
ロータッチ
ハイタッチ
・コロナ禍で、常時オンライン化
ハイタッチのコミュニケーションコストが下がった
ニアリアルなコミュニケーション
Zoomのブレイクアウトセッション
miro
SpatialChat
・各事業に寄り添った情報提供
事業ごとの課題、それぞれに
どんな価値を提供できるかを整理して伝える
どこで活用してもらえるか、どのフェーズから参画できるか
参画することでこうなる！を伝える
取引コスト、コミュニケーションコストの削減
過去の案件を批判しないように
●共有→相談
・マッチングなのでマーケティングファネルと同じ
認知（共有）
→興味/関心
→検討
→購入（相談）
●相談→実現
・案件種別ごとに事例を含めた検討アプローチを提供
テンプレート化
事業高度化、データ分析、新規事業
・体制、開発プロセス
不確実性の大きさ
得られる知見の価値の大きさ
開発規模の大きさ
で
Insight Edge内製/アジャイル
外部ベンダ/ウォーターフォール
を切り替え
●実現→蓄積
・案件内外で知見を蓄積、組織全体へ
・組織値/ソリューション
DX案件
ふりかえり、事例まとめ
案件外
アイデアソン/勉強会
・使える知見の蓄積
知見のレベル × 技術要素で整理
知見のレベル
概念を知っている
類似技術・製品の評価ができる
案件特性に合わせて利用・実装できる
ベースを上げつつ、Bizとともに重点領域を進めていく
・知見の獲得/Lv上げ：アイデアソン/勉強会
2ヶ月単位でテーマ選定
心理的安全性の工場、テレワークうつ対策
業務外のメンバーとコミュニケーション促進
●KPI
・貢献額
案件による利益貢献+削減できた外注コスト
・サブKPI
案件装弾数
デリバリ数
●目指す姿
・InsightEdgeが各事業部のCTOとして入りこみ
Re-design, DXを加速していく
■リモートワーク×Employee Experienceでつくる ～with コロナ時代の「Work fun! Management」とは～
新村 北斗さん [Works Human Intelligence]
●Works Human Intelligence
・ビジョン
「はたらく」を楽しくする
●前提
・人生の目標設定
・仕事の目標設定
今日は仕事の目標設定の話
●いままで
・目標設定→成果・結果
・評価・振り返り・FB
顔色、行動、会話を踏まえて
→リモートワーク
●employee experienceｈの変化
・意外と仕事できる
・自由な場所と時間で仕事できる
・副業しやすい
・他社や関係者も受け入れた
・ツールやシステムが拡充してきた
→リモートワークは定着していく
●仕事の特性
・やる気と達成感
・職務特性
技能多様性
スキルを活用できるか
タスク完結性
全体を任されているか
タスク重要性
重要だと感じているか
自律性
自分で決めることができる
フィードバック
成果を知ることができる
・心理状態
仕事の有意味感
仕事の責任感
成果の知識
→やる気と達成感
・アプローチ
上司：本に合わせた腹落ちする説明
本人：自ら決める
組織：成果発表会
●なぜ目標なんて決めなきゃいけないの？
・質問
定年まで同じ会社で働きたい？
収入を増やしたくない？
どうせやるなら、楽しくやりたくない？
・現状を変えるために、何かをやる必要がある
やりたくない
やらなければならない
→ やりたいに変えていく
・大切なのは
なぜやるかを自分で決めること
他の人に説明できるようにする
・なぜ目標設定するのか
現状を変えるために、目標を設定
変えることは大変
継続的に取り組むことが必要
やり続けるための理由が大切
目的を説明できる状況
●関連ワード
・目的
現状を変えたい理由
・ゴール
結果の定義
・目標
ゴールまでのマイルストーン
・例：勤務実績承認
目的 ：承認者のチェック業務を楽にしたい
ゴール：規定違反者のデータのみ表示
目標 ：規定違反データ検出のしくみをつくる
●目標の特性
・目標タイプ
創出・開発
向上・強化
改善・解消
維持・継続
・達成基準
期日基準
状態基準
数値基準
●目標設定の仕方
・主題
簡潔な題名
優位性を伝え、本人が選択
・副題
誰をどんな状態に、なぜしたいか
本人の言葉で表現 コレが書ける人は達成できる
・アクションプラン
いつまでに、何をするのか3〜5+
論理的かつ実現可能なプラン化確認する
・達成の定義
どの状態を達成とするのか
目標通り ：100点
目標を上回る：120点
上司と本人で事前に合意
●目標設定例
●期間と目標
・期間と目標数
3ヶ月： 3〜 5
6ヶ月： 5〜10
12ヶ月：10〜15
・月一つくらい
・少ないと具体性が乏しくなる
・多いと目的を見失う
●運用5箇条
・目標設定は時間がかかる
やったことがない人には難しい
できるようになるまで寄り添う
締切はいらない
決まったらやる
・目標設定はいつでも追加、修正して良い
上司とすり合わせして変更
やりたいことが変わったら変えていく
・達成できたら素晴らしい、できなかったら分析
達成できることが素晴らしい
できなかったら原因を分析
・進捗を確認するのではなく、障害を取り除く
そこで止まってるなら、Aさんがわかると思うよ
・節目でFBを得られる機会を必ず設ける
上司からだけでなくチームや部署
範囲が広いほど達成感は高くなる
●大切なのはしくみではない
・一緒にやる仲間一人ひとりの気持ちに向き合う
・自ら相手のFanになり
相手が自分のFanになってくれれば
どんなWorkもFunになる
■この半年で変わったものと変わらないもの - SaaS開発の現場より
粕谷 大輔さん [はてな]
●時系列
・2月中頃
冗長に相談すれば在宅勤務可能
・3月中頃
在宅勤務に切り替える人が増える
daiksyは3/25から完全在宅勤務
・4/7
緊急事態宣言期間中は、原則在宅勤務
出社には申請が必要
・7月現在
ルールは緩和
人によっては出社している人もいる
●リモートワーク
・もともとリモートチームだった
東京・京都オフィスにメンバーが在籍
在宅のメンバーもいた
・開発プロセスもリモート前提だった
・家庭の事情で在宅が難しい人もいた
●仮説：パフォーマンスに影響がるのでは？
・在宅勤務になれない人が多い
・パフォーマンスの計測
現状把握のため
お尻を叩くためではない
防空壕に避難している人に
いつもどおりの仕事をしろというのも違う
・開発タスクのリードタイムを計測
PRのコミット〜mainブランチにmergeされるまで
・2週間時点
赤線が中央地
変化がないように見える
・2ヶ月後
大きな変化は見えない
●仮説：パフォーマンスは落ちてないけど、頑張り過ぎなのでは？
・3ヶ月後
大きな変化はない
保育に預けられないから仕事しづらい
などは1on1で拾っている
・広木さんのgilotで計測
変わってなかった
●チームを安定させるための施策
・リモートワークの課題
コミュニケーションの低下
雑談できない
気軽に質問しづらい
テキストの非同期コミュニケーション
・取り入れたもの
discordでボイスチャット
昼会 + 夕会
ワーキングアグリーメント
・ワーキングアグリーメント
チームの暗黙的な約束事を明文化する
会議体、レビューフロー、当番など
ツールの使い方
振り返りのタイミングで更新
・なぜ重要か？
エンジニアは参加必須にした
CPUパワーが取られる、集中が削がれるなど
在宅は個人に大きな裁量
チーム運営にはある程度の強制力が必要
スクラムイベントには全員参加など
とりあえずやってみる
だめなら変えられる
●変わったものと変わらないもの
・開発チームのパフォーマンスは変わらなかった
・チームの取り組みはたくさん変わった
変えやすいルールを設けた
・新しいチャレンジが受け入れやすくなる工夫をすれば
不確実性に向き合っていけそう
■不確実性の高い世界のなかで、非連続な成長を生み出す
門脇 恒平さん [プレイド]
●プレイド
・ミッション
データによって人の価値を最大化する
・KARTE
CXプラットフォーム
●直近の経緯
・2月：原則フルリモート開始
・7月：フルリモート解除
→コロナ禍は、原則フルリモートで進めてきた
●どんな不確実性に直面しているのか？
どんな非連続な成長が必要なのか？
・進捗率 2% → 0.2%
社内で通説になっている進捗率の定着値
ミッションは
インターネットの構造を変えるレベルの壮大な話
実現された世界の正解はどこにもない
やりたい、できることは増えていく
・不確実性の高い環境
正解がない中でつくる
環境はすごい速度で変化
→ 変化に柔軟に適応しながら
不確実性を減らしていく
・非連続な成長の必要性
積み上げの成長では到達できないミッション
タイムリミットがある
→ 前提にとらわれないで
インパクトのあるものをつくる
●コロナ禍で会社、プロダクト、開発チームにおきたこと
・会社におきた変化
02/25：原則リモートワーク
07/01：解除
・事業・プロダクトに起きた変化
クライアント企業の商環境の変化
機能の価値、可能性の変化
・プロダクト開発チームに起きた変化
取り組むテーマの優先順位
個人の生産性・コミュニケーション
●適応するために開発チームが取り組んだこと
・開発チームは大きな混乱なく、変化に一定の適応ができた
全ての人のこれまでのチャレンジの積み重ねのおかげ
・適応力を重視した開発スタイルが活きた
変化の兆しに直面したチームや個人が
自律的に意思決定してアクション
ゼロベースで取り組むテーマ
・フォーカス
2,3ヶ月の開発サイクル
注力べきテーマでチームをつくる
テーマは決めきらずに始める
各チームで考えてやり方を決める
毎回ゼロベースで考える
・チームや個人が自走して課題を解いていた
家が働きにくい
自発的に相談
環境整備を金銭的サポートする制度へ
生産性、モチベーション低下
生産性が上がった人が自律的にフォロー
相談、会話がしづらい
雑談・おやつタイム
チーム感共有の場で広がる
●なぜ変化に柔軟に対応できたのか
・不確実な世界の中で非連続な成長を生み出すための累積
みんなのチャレンジのおかげ
・必要だと考えていること
個人の創造力・発想力を最大限活かす
正解はどこにもない
トライ&エラーを高速に繰り返す
・大事にしていること
ルールはできるだけ決めない
取り除くのが大変
生産性は自分で上げる
働きづらいなら、アクションするのは自分
常にゼロベースで考える
前提にとらわれない
プロダクトアウトを大事にする
良いと思ったらすぐ出す
だめなら作り直す
●問題提起
・ここで満足していてはいけない
解決できていない課題
見えていない不確実性は無限
・何をすべきか
変化のストレス・機運を生かして
更に成長するチャレンジ
・チャレンジしたこと
開発チームの自律性・並列性を更に強化
プロダクトに関するWhy/How/Whatを意思決定できる人を増やす
・これまでの組織構造スケールの変遷
CPOからチームへWhyの責任を委譲してきた
WhyはCPOに強く依存
長く考えているから当たり前
あえてCPOに頼らない状況をつくる
・やったこと
Whyに責任を持つ場をつくり
CPOには抜けてもらった
8人のメンバーでフラットに議論
全社・長期視点のビジョン
テーマの優先順位づけ、ポリシー
など
●今後の展望
・たたきの精度を上げ続ける
・Whyを主体的に考えられる人を増やす
・生み出すものがダメなら意味がない
■トランスフォーメーションジャーニー
市谷 聡啓さん [レッドジャーニー]
●自己紹介
・株式会社レッドジャーニー
いろいろな会社のDXを支援
・政府CIO補佐官
・DXといっても各社でやっていることは色々
内製チームを作っていく
新しい事業をつくっていく
●プロダクト開発のイマココで立ちふさがるものは？
・不確実性
事実との分断
・逆境
未来との分断
・断絶
理解との分断
●不確実性
最初から体制が整っていて、何をやればよいか見えていることはない
・シャローコンセプト
コンセプトが浅いまま進めてしまう
・過剰な意気込み
意気込みでカバーして進めてしまう
・ゼロチーム
プロダクトオーナーは孤独
一人の人の知見に依存
広げようがない
・本人にもわからない
コンセプトはある、イメージはある
アウトプットはない
・われわれは何を作るべきなのか？
想像でつくっていったものはユーザーに受け入れられない
・オーバーエンジニアリング
やりかたは無数
何を作るかの基準がないとやってみたいベースで足かせに
●逆境
DXで背負わなければならないものが増える
・歴史的な前提負債
基幹業務システム
早い開発遅い開発を器用に進める必要がある
・ゼロエキスパート
多くの専門性が必要だけど誰もいないところからスタート
・政治的安全性
これまでこうしてきたから
こういうルールだから
・目の前の最適化
DXに総論としては賛成
このプロジェクトで通すことはない
プロジェクトレベルで判断すると
これまで通りで良いじゃんになってしまう
●断絶
リモートワークで生まれる問題
・始まらない対話
あいまいなまま始めていく会話ができない
・窮屈な対話
会話を始めるコストが高い
昔で言う電話を掛けるのと同じ感じ
・あなたのことが分からない
チャットの文字だけでは相手の機微をつかめない
問題が連携したり強めたりして分断のトライアングルができていく
●乗り越えるために「越境」
・イマココの立ち位置から歩み出る
●最初に取り組むことは？
・共通の認識が大事
整理できない
一時的にでも仮の方向性を置く
方向性を変える約束をしておく
・方向性を変える約束 = タイムボックス
最大：ジャーニー
中間：スプリント
最小：一日
・次の方向性を変える
ジャーニー：ミッション
スプリント：スプリントゴール
一日：今日何をするか
●13の問題に向き合うためのすべ
・不確実性→探索と学習
仮説検証型アジャイル開発
・逆境→段階とむきなおり
段階の設計
・断絶→対話と再定義
自律分散協調
●仮説検証型アジャイル開発
・詳しくは書籍とスライドで
●段階の設計
・到達したい目的地を見立て
たどり着くために必要となる状態を構想
・わかったことに基づき、高層を変化させる
・なぜ変更するものを作るのか？
当事者に方向性を与える
・詳しくはスライドで
●自律分散協調
・始まらない対話
意図的な雑談をつくっていく
・窮屈な対話
図解などで情報密度を高める
・あなたがのことが分からない
小さく、短く、一巡させる
その過程でお互いを理解する
●価値観の分断が起きている
・それぞれの立ち位置でそれぞれの価値観
世代、役割、職位
・すり合わせる時間がなくなっている
そういう考えでやっているのねを考える時間
●Transformation = 価値基準の再定義
・自分たちにあった価値基準を見つけに行く
・価値基準を自分たちのものにしていく
・環境変化で価値基準は変わっていく
・「価値観を揃えて統一することが適応力を高める」ということではない
それぞれに価値基準がある
適切に分かれている上で協調する
・個々人の価値基準を捨てるのではなく
チームの価値基準と個人の価値基準を協調させる
バラバラのままの合意形成
チーム・ジャーニーに書いてます
分断のトライアングルがプロダクト開発を難しくしている
立ち向かう３つのアプローチを紹介しました
みなさんにとってのよい旅を
■感想
・顧客の課題の変化に合わせて
ビジョンから問い直す姿勢
・内製組織には、企業での
顧客接点の機能がひと通り必要
・体系化された目標管理の考え方
・あらかじめ変更を盛り込んだ
新しいものを取り込むプロセス
・人への依存を分散するアプローチ
など、たくさんの共感と気づきをいただきました。登壇者の皆さん、運営の皆さん、ありがとうございました！
この記事が参加している募集
いつも応援していただいている皆さん支えられています。