デブサミ 2020 春 備忘録4：[14-A-6] 世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた
Developers Summit 2020 春を聴講してきたログ。仕事柄デジタルビジネスへの取り組み方やよいチーム開発とはという観点を重視して聴講しました。業務の都合上午後のセッション中心になってしまったのが残念なところ。
とはいえおもしろいセッションを色々聞けたので、いくつかを備忘録もかねて公開します（というか久々に書こうと思う余裕ができた最近）。
- [13-C-6] 礼節から始めるチームの健康と信頼性
- [13-D-5] ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜
- [13-E-8] チームをつくるモブプログラミング ～内側と外側から語る～
- [14-A-6] 世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた ★当記事★
[14-A-6] 世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた
鈴木 雄介, 河村 明彦 アイムデジタルラボ
アイムデジタルラボ：三越伊勢丹グループにおけるDX推進のための会社
（元JJUG会長の鈴木さんだった、強い）
YourFIT365というサービス
足の3Dスキャンから最適な形状のパンプスをレコメンドするサービス 自分のスマホでいつでもデータを確認できる
- 昨年夏から開始
- 対象ブランドは現在 25
- 計測者数 5000人以上
2年間模索(これまでの道のり)
販売担当の想い：足に合う靴を提供したい
自社内の独自資格制度を作るなどもしていたが、販売員の個人スキルの差を埋めるために３D計測を活用できないかという仮説からこの取り組みが始まった
この取り組みはシステム部門主導ではなく、現場部門が自分たちの予算で動いていた（自分事としてやっていた）
計測器をいろいろ探した結果、国内のアイウェアラボラトリーを選定した。 選定理由として、機器の精度もあるが、企業モチベーションや理念にシンパシーを感じたことが大きい。
立ち上げ（どうやってサービスを作っていったのか）
既存の開発プロセスは切り離して実施した方がよい、との考えからアジャイルで開発でやることにした。それを後押しする経営のコミットもあった。
Graat社（登壇された鈴木氏が代表を務める企業）からアジャイルコーチを招聘し、進めることとなった。
プロダクトオーナーは現場のメンバーから立てることになった。これは、現場と開発チームが直接やりとりするのが最も重要とのことから、間に情シスが挟まらない体制にするためである。
- 役員のコミット
- 現場の担当を情シスに異動することで
- 社内の構造的(政治的かな？)な課題をクリアさせた
- ただし情報技術に明るいから、というのではなくPO支援という形で現場の方との橋渡し役という役割りとしたており、またこれが重要なポイントでもあった
元々店舗の改装日が決まっていたため（＝リリース日として決定済みの状態） 4月から8月28日までの開発プロジェクトとしてMVP開発を進めることとなった。
多くの関係者がアジャイルもなにもかも初経験でありまたどういうモノを作ればいいのかの共通認識を持つ必要があったため、バイヤーからカウンセラーから関係者全員をあつめてのワークショップを数回おこない。 リーンキャンパス、カスタマージャーニーなどをGWくらいまで作成していった。
その結果、ビジョンと優先順位が共通認識としてもてた。
木型のデータ収集も重要な要素だったが、本来は門外不出なもの。 だが、三越伊勢丹のブランド信頼より数社賛同していだきスタートに至ることができた。
業務とITを同時に検証するために使った手法
サービスブループリント
レーンを決めてヒトやシステムが何をするのかを決める(UML的なものか)業務フローとシステム構成を並行して考える手法。システム側の制約で業務を変える部分を見つける・合意をとるのが目的。
体制
- 内製エンジニア＋外部のエンジニア
- ただしアジャイルは未熟な状態で、3か月で初回リリースを目指す
技術選定
- Spring Boot / Anguler
- Docker on Azure app servuice
基幹システムのAPIチームからも多くのデータ提供などの強力をいただけてMVPを無事リリース。毎日数十件の計測をしつつ開発側にフィードバックを行っており、リリース後2か月間くらいかけてブラッシュアップ（毎週何等か機能アップデートが入る感じ）を続けていった。
次に向けて（現在～）
11月くらいから意図的にアップデートサイクルを緩めて安定期にしている
安定期：予約件数を絞って対応することで顧客に提供する価値と業務のバランス／効率化を測ろうとしている
当初の目論見では、接客時間の効率化に繋がるのでは、という想いがあったが実際は顧客満足度が上がるとともに接客時間も長くなっていた。悩みを抱える顧客の状態が明らかになったというメリットがあるが、接客負荷のコントロールも重要になってきた。
このサービスを利用した顧客ムーブの傾向として、夏に買ったお顧客がまた秋冬に買いに来るというサイクルが生まれていたため、同じ木型の新商品をレコメンドしてみたらコンバージョン率が明らかに高かった。
このように今までとは違う観点でのアプローチを見定める必要も出てきた。
また、足形データから、一般論との乖離が見えてきたりもする。 一般には日本人の足形は細くなっていると言われているが、このサービスの顧客は幅広だったりと一般論で取りこぼしている領域の形が見受けられた。このような観点についても商品開発・ブランド側にフィードバックもしているため、今後の開発サイクルにも影響を与えることができそうである。
新たな顧客開発のために歩き方講座やトレンド講座を抱き合わせてみたりといった顧客獲得のための取り組みも実施している。
ともにつくる
関係者各位全員が当事者意識をもって行動することが一番重要である。
極端に言えば、当事者にならない人は不要
- 企画部門問題
- 情シスの企画はアイデアだけで行動に繋がらないので当事者意識が薄いのでこういうDX的な開発ではあまりいても効果がない
アナログと、ともに作る
デジタル技術を活用しているが、デジタルが中心ではない
アナログがあるからデジタルが生きる、デジタルがあるからアナログが伸びる、これはDXの本質ではないか
ツール先行は成功しない、「それAIでなんとかしてください」というのは本質的にうまくいかないスキームである。
DX導入パターン
2019年に立ち上げたアイムデジタルラボは、DX推進向けの機能子会社であり、既存の枠踏みのなかでやりにくいことをやるための組織である。
アイムデジタルラボは出島型の組織として開発を進めている。
適度な自治権を与えられているが、三越伊勢丹としての運用やセキュリティのルールは守っている。
そして、広げる
メンズのサービスも 2020/3/25 からイセタンメンズ館にてスタートする。 （行ってみよう）
デブサミ 2020 春 備忘録3：[13-E-8] チームをつくるモブプログラミング ～内側と外側から語る～
Developers Summit 2020 春を聴講してきたログ。仕事柄デジタルビジネスへの取り組み方やよいチーム開発とはという観点を重視して聴講しました。業務の都合上午後のセッション中心になってしまったのが残念なところ。
とはいえおもしろいセッションを色々聞けたので、いくつかを備忘録もかねて公開します（というか久々に書こうと思う余裕ができた最近）。
- [13-C-6] 礼節から始めるチームの健康と信頼性
- [13-D-5] ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜
- [13-E-8] チームをつくるモブプログラミング ～内側と外側から語る～ ★当記事★
- [14-A-6] 世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた
[13-E-8] チームをつくるモブプログラミング ～内側と外側から語る～
デンソー アジャイルモンスター 及部 敬雄 アジャイルコーチ 安井 力
ペアプロ・モブプロを経験した人がどれくらいいるか
- 10～20％弱がやったことある
- 5%くらいは常時やっている感じ
Codezinでモブプロ講座ができるらしい（その2人）、youtubeチャンネルとかPodcastもあるよ。
ここ2年くらいでペアプロ・モブプロをやった、やってみた系の声を聞くことが多くなってきた印象がある。自分もどうやってか仕事に取り入れられればと思っているのでとても参考になるセッションだった。
モブプロやるにあたって重要なこと
目的とゴールを定めること
方向性の認識合わせが大切、近距離のゴールとして今日どこまでやるというのも重要
目的は押しつけ型ではだめ、リーダーが「これでいいですか？」という形でやっても押しつけになりがち
モブプロを始める前に、「自分たちのモブプロの進め方」を表明する
どういう段取りで進んでいくのかのイメージの共有が大切（TODOリスト化するなども有効）
- 進む方向が逸れてしまったときに気が付ける
- 今何をやっているのかはドライバーがシャベルのがよい
- 何をやっているのかを正しく伝えるため
議論と実験のバランスをとる
モブでの議論は大事、だけど、話すだけでなく試すことも大事
最初は 議論＜＜実験 くらいのバランスで進めるのが慣れやすい
その場でフィードバックを得る
フィードバックはお互いの知恵を出し合うのがよい
攻撃的にはならないように、また、後だしはしないようにする
個々人のペースとやり方で復習することも大切
Q やりかたにネガティブな反応があった場合
「まず試しにやってみて反応をみて考えてみましょう。」という風に進める案を出してみる。
外部での体験者からの声やヒトのお墨付きがあれば始めやすい
Q 個人でやりたいんだけどなヒトがいた場合
大事なのは仕事を進めるやり方を学ぶこと。
なので、個人でやるタスクがあるのは、別にそれでよい
モブプロのやり方が全体としての進捗に影響が出るよう様な制約・拘束になるのはよくない
ただ、まずやってみて「モブにあったタスク、そうでないタスクがあることを」自分の中で見つけて良いバランスで実行するのが良い
チームをブーストするモブプロとはどういうものか
知識移転
経験値の低い人を、ドライバーにするのがよい
できる人がドライバーの場合、走ると止まれない、モブプロの知識移転を狙うなら、止まれる状態を作る
モブプロは知識のジャストインタイム、聞きながら学べる、全員に同時に同じ内容を伝えることができる
全ての暗黙知が形式知にできるわけではない、経験・体験に基づく振る舞いだったり、染みついた操作だったり、体験を共有することが大切
レビューの目的3分類
- 検査
- 品質管理
- 学習
- 知識、技術の転移
- 強化 ★
- リファクタ
- もっとよくする
そもそもモブプロやること自体がレビューの観点も含んでいる。モブプロではチーム全員で合意がとれた状態のものとして出来上がる。忖度せずにチームのベストを目指すことができる。とはいえレビューが完全にいらなくなるわけではない。
また、知識移転を狙う場合、3分類のうち★の部分が弱くなる
リアルタイムレビューと通常のレビューの違いを認識し、うまく使い分けることが重要（( スライド56ページの表）
Q レビュー中でのやりとりや発言など
全員仕事に集中しているので議論が熱くなりがち、だけどこれはよいこと
まれにケンカになることもある、ただ、建設的に前向きに進められるようになるチャンスでもある。言葉の使い方は人間的な部分でケンカにならないように気を付けることが大切。
ただし、そもそも合わない者同士がやった場合は爆発する
Q 「わからない」 が言いにくいのでは
そういう人はいる、チーム内でのスキル差がある場合は、タイミングタイミングで復習する時間をとって知識レベルの同期を取ることが重要。分かってそうな人にふってコメントをもらうというのもよい。
仕事をドライブするモブプロ
ソロワークよりも「優れた成果」を出せるのがモブプロの強み
ただし、「優れた成果」とは、旧来の、行数やコミット数などの単純な定数では測れないものを指す
そのためモブプロという取り組みは、定量的な部分を評価できないといけない。そのための文化や考え方が大切となる。
仕事をドライブする場合のモブプロは、知識移転・チームブーストとは違う（多くは逆の視点）を重視して取り組むことになる。
どちら寄りのモブで進めるかによって、重視するポイントや進め方を正しく選び認識し実践することが大切。
また、「仕事」か「チーム」かの二元論ではなく、相互のバランスをとったチームにとってよい状態で進めていくことでチームのドライブ効果が仕事の成果に直結していけるように成長できる。
スライド79ページの「パニック／学習／快適」の図 が分かりやすい。
Q モブプロって生産性高いの？無駄も多いのでは？
単純作業はモブでやるメリットはない
作業 を単純とみるか 複雑と見るか
人数が多すぎると効率は下がる、例えば 10人 は多すぎに思う。
中期的にヒト・チームの生産性が上がるのはよく見るが、短期的なメリットだけでみられると厳しい （このあたり工数主義者には適用にし難い様に感じる。何を狙うのか次第ではあるが）
モブの目的をただしく理解していただくように働きかけることが大切
Q 心理的安全を維持するには
ラーニングセッションを活用する
Q モブプロがうまくいっているチームの特徴とは
- なによりも楽しそう
- 全員がよく発言する
- ドライバーをだれでもが取りに行く（わかんないけどやります）
- マネージャーの過干渉がない（ようにうまくマネージされている）
まとめ
モブプロはチーム全体の活動である（スライドp.95の図はインテグラル理論より）
デブサミ 2020 春 備忘録2：[13-D-5] ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜
Developers Summit 2020 春を聴講してきたログ。仕事柄デジタルビジネスへの取り組み方やよいチーム開発とはという観点を重視して聴講しました。業務の都合上午後のセッション中心になってしまったのが残念なところ。
とはいえおもしろいセッションを色々聞けたので、いくつかを備忘録もかねて公開します（というか久々に書こうと思う余裕ができた最近）。
- [13-C-6] 礼節から始めるチームの健康と信頼性
- [13-D-5] ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜 ★当記事★
- [13-E-8] チームをつくるモブプログラミング ～内側と外側から語る～
- [14-A-6] 世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた
[13-D-5] ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜
株式会社 Insight Edge CTO 福井 勝史
Insight Edgeとは
住友商事グループのデジタルトランスフォーメーション（DX）を加速する技術専門家集団
住友商事グループ DXセンターの一つの機能としての位置づけ
- DXセンター
- 企画チーム
- 部門別DX推進機能連携
- 当事者意識を持った取り組みとするため、現場の人間を抜擢して構成している
- それまでの縦割りから横につなげる意識への変革が進んでいる
- 先端技術活用チーム ・・・ ここがIE社の領分
- エンジニアとデータサイエンティストの集団
- 投資チーム
- CVC(コーポレートベンチャーキャピタル)機能
- 先端技術のベンチャー提携や支援
- 企画チーム
住友商事のグループ企業である900社を対象にDXビジネスを展開
2020年2月現在、約160のプロジェクトが進行中
この数にはRPAはカウントしていないとのこと
進行プロジェクトの分類
IEの実績では、産業ごとの取り組みやすさ／にくさはあまり感じないとのこと
- 金属 28
- 輸送 39
- インフラ 22
- メディア、ITデジタル 5 → この分野の企業は自分達でやってるので少ない
- 不動産 40
- 資源・化学 19
進行プロジェクトの目的分類
- ビジネス高度化 91
- 新規ビジネス創出 57
- アイデア整理 12
活用テクノロジーの分類
進行中プロジェクトのフェーズ別分析
★の部分が特に重要である
- 相談アイデア想起 62 ★
- このタイミングからエンジニアが参画することで、先の技術的な課題に対してのエンジニア目線での実現可能性コメントや先行検証が重要となる
- ビジネス課題整理 施策検討 44 ★
- ゴールを明確化し、定性と定量の両面を文字化する
- 技術的な可能性だけでなく、ビジネスとしての可能性についてもエンジニア観点も踏まえて検討する
- ビジネスモデル検討 実証実験 40
- ビジネス実証 技術実証 実用化検討 14
- 運用 15
従来体制との違い・対策
企画をコンサルが行い、ITベンダーが実行するという形式では、スピード感が生まれにくくまた委託領域のかぶりなど費用の重複感も出る。
自社エンジニアの確保・育成が重要 自社エンジニアであることにより、自社ビジネスへの理解もあり、またスピード感も損なわれない 費用についても持ち出しでなという観点で内部調整がしやすい
DXは始まりがカッチリ決まっていないことが多いが、自社エンジニアがいることでやわらかい相談にも乗ってもらえて進めやすい
グローバルへの取り組み
グローバル拠点のDX支援なども行っていく
- M&Aによるデジタルバリューアップ創出
- 海外スタートアップへの投資および技術支援
- 国内スタートアップの海外展開支援
- スタートアップは単なる仕事の出し先ではなく、一緒に作っていく共創メンバーという位置づけ
デブサミ 2020 春 備忘録1：[13-C-6] 礼節から始めるチームの健康と信頼性
Developers Summit 2020 春を聴講してきたログ。仕事柄デジタルビジネスへの取り組み方やよいチーム開発とはという観点を重視して聴講しました。業務の都合上午後のセッション中心になってしまったのが残念なところ。
とはいえおもしろいセッションを色々聞けたので、いくつかを備忘録もかねて公開します（というか久々に書こうと思う余裕ができた最近）。
- [13-C-6] 礼節から始めるチームの健康と信頼性 ★当記事★
- [13-D-5] ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜
- [13-E-8] チームをつくるモブプログラミング ～内側と外側から語る～
- [14-A-6] 世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた
[13-C-6] 礼節から始めるチームの健康と信頼性
クラスメソッド 事業開発部 塩谷 啓
チームリライアビリティエンジニア(自称)
Opsチームのスクラムマスター兼マネージャー
余談：技術書店にて河童書房の本を出されるらしい
チームとはなにか
グループ と チーム は違う
- チームとは
- 目的は共通
- 協力して行動する
- メンバーが相互に依存している
（グループはもう少しメタな目的・目標に対する実行集団として色々なカットのチームから構成されるもの、かな？）
プロセス知識スペクトル
高い ←←←知識の成熟度→→→ 低い
ルーチン←←← 複雑 →→→ イノベーティブ
低い ←←← 不確実性 →→→ 高い
成果を出すチーム行動
- 継続的な改善
- 専門性を結集した問題解決
- 仮説検証による
健康と信頼性
健康なチームとは何か
- 建設的な衝突を、人間関係のリスクなしに行える
（これめっちゃ重要。ほんとそう。最近やった仕事はここが凄く良かった。）
建設的な衝突を可能にするもの＝心理的安全性
[引用] プロジェクト・アリストテレス
だれがチームメンバーであるか よりも チームがどのように強力しているか が重要だった
[引用] チームが機能するとはどういうことか（TEAMING）
チームが機能する = カジュアルにヤバいことを言える雰囲気がある ということ
- カジュアルに → 対人関係にリスクがない状態
- (建設的な)やばいこと → 不確実なこと、不安なこと
心理的安全性の誤解
なかよし＝安全（かというと、そうではない）
心理的安全な人たちが仲が良い は 真
仲が良いから心理的安全性が高い は 偽
仲間内、身内で集まることによる暗黙の同調圧力や視野の狭まり、身内と外の境界を意識しすぎた振る舞いなどが助長される場合がある。自分も見たし、自分がそうだったことがあった（と思う）。
（人間性が未熟な状態の）エンジニアあるある
正しければ何を言っても良いという勘違い（そうではない）
- モヒカンの手斧
- コードレビューの人格否定
（そこに愛はあるのか、その愛は相手に伝わる形をしているのか、独善や自分はこういうキャラだからという"言い訳"の刃の鎧を纏っていないか）
礼節
[引用] Team Geak
HRTが大切、あらゆる人間の衝突はHRTの欠如から起きる
- Humility（謙虚）
- Respect（尊敬）
- Trust（信頼）
（この本はとても好きな本で、自分もよくお勧めしている）
[引用] Think CIVILITY
礼儀正しさこと最強の生存戦略である
礼節とは何か
よりも
無礼とは何か
から考えるのが分かりやすい
- 攻撃的
- マウンティング
- 弱点・失敗を突く
- ポジショントーク(ポジハラ)
- 無関心
改めて、礼節とは何か
無礼の対称
- まわりに敬意をもって接すること
無礼がなぜ悪いか
- 健康被害
- 会社に損害をもたらす
- 周囲の思考能力を下げる
- 周囲の認知能力を下げる
- 周囲の攻撃性を助長する（伝染する）
もっとも近い「周囲」はチーム、ゆえに無礼はチームを害する行為であると言える
やばいことほど礼儀正しく
- 「正しいこと」はそれだけで強い
- 出し方を間違えるとモヒカンの手斧になる
まとめ
健康なチームをつくるためには、次のような関係を意識して、積み上げ作り上げていく必要がある
礼節 → HRT → 心理的安全性 → 健康なチーム
ギルドカンファレンス 2019 まとめ
ギルドカンファレンス 2019の第一部に参加した際のメモをまとめたものになります（当日ちょい体調悪めだったので一部で退散・・・）。
この投稿では、具体的な取り組み事例のセッションやQAに注力してまとめています。
「カイゼンジャーニー」や「正しいものを正しく作る」で有名なギルドワークスの取り組みについては、あちこちに書かれたりしているので記述はあっさり目にしています。
ギルドワークス 市谷 聡啓
ギルドワークス 現場コーチ 中村 洋
ギルドワークス
次の3つが事業の柱
プロダクトマネジメントツールGuildHubによる仮説検証型アジャイル開発
ギルドワークスが開発・サービスしているアジャイル開発支援ツール
GuildHubが生まれた背景：Guild Worksとしてビジネスを進める中で、学びの蓄積・共有がうまくできていないというのが最近の悩みとなっていた。
今のGuildHubの機能はプロダクトオーナー寄りの部分を提供している。
- どのような観点でプロダクトの構想を練ればいいのか
- 仮説から機能へどのように落とし込めばいいのか
- 仮説検証スプリントを繰り返すことで事業テーマ＝ミッションが明確になる。
ギルドワークスと推進した新規事業開発 ?組織を動かす「忘却」「借用」「学習」のマネジメント?」
リクルートマネジメントソリューションズ 小川 卓也 さん (プロダクトオーナー)
専門家が伴走する組織マネジメントのパーソナルコンサルティングサービス INSIDES の開発にギルドワークスと一緒に取り組んだ話
INSIDESとは
対話の改善に使えるツール 組織・メンバーマネジメントを可視化 コミュニケーションを支援 ＋専門家によるコンサル
評価 × ワークメンタリティ
サブスク型で提供
本編の前に
大企業だけじゃない、中小企業でも起きる新規事業・新規サービスがうまくいかないあるある
- やり方変えられない
- 反対にあう
- 既存事業に似た感じになる
- リソースがうまく活用できない
- えとせ
スタートアップから見た大手と組んだ場合の新規事業・新規サービスがうまくいかないあるある
- スピード遅い
- 役割が不明瞭
- どう推進されているのかわからん
- えとせ
以下本編
次のセクションに分けてまとめています
- 前提・市場環境、組織について
- ギルドワークスと組む前
- ギルドワークスと組んでから
- いま現在
- 学んだこと
- QA
前提・市場環境、組織について
昨今の市場の変化スピードは速い／どの事業もそうだが／HR-Tech（アセスメント～コンサル～トレーニング事業）もそう。
リクルートマネジメントではアセスメント～コンサル～トレーニング事業の3つは部として分かれているが、今の市場ではバリューチェーンが統合されたSaaSなどが出てきている。また、HR-Techへの参入企業も多くなってきている。
リクルートマネジメントでのINSIDESの取り組みは、スタートアップや出島形式ではなく、既存事業と両立しながら進めるというやり方で実施している。
リクルートマネジメントの主な既存事業はSPI：会社の利益の大半がここ：でかい既存事業という位置づけ。
INSIDESでは、「忘却・借用・学習」という3つの観点のバランスを取りながら新規事業を進めている。
忘却
既存の成功体験、常識、パターンを捨てる
真似締めと方式など
借用
既存が保有している経営資源の一部を活用する
ブランド・チャネル・人材・制度など
学習
不確実・道な事業で成功をつかむために
積極的で柔軟な試行錯誤のサイクルが重要
リクルートマネジメントの既存事業では、「忘却」が非情にしにくいという特徴が強かった。
INSIDESは、次の３ステップで開発を進めている。
一次開発＞二次開発＞三次開発
ギルドワークスと組む前（一次開発）
一次開発では、アプリケーションを自社のメンバーと外部のアジャイル開発会社で作っていた。
既存事業はガチガチのWFモデルなので社のどこにもアジャイルの知見はなかったため、次のような体制でなんとなくアジャイルを実行。
機能を最小限（MVP）で作るなど、大きな失敗もなく半年でリリースできた。
ただし、既存事業でやっていた運用手順などが整理されていないことなどから、オペレーション設計・運用の担当やマネージャーから、運用として何をすればいいのかわからない、他のサービスと同じような形式にしてほしいなどの声が上がった。
オペレーション設計・運用への働きかけ/既存の開発規模や運用手順と異なる部分の認識共有など/がうまくいっていなかった。
営業も同じく、従来のSPIと同じような感覚で売りに行ったが、営業が顧客に説明した内容に対して実態の機能数が全然少ないなどの問題にも発展した。
この状況を「忘却・借用・学習」で整理すると、開発サイドは「忘却」ができていた（＝既存のやり方に縛られずに進められた）が、「借用」の動きができてなさすぎた、といえる。
なぜできていなかったのか。
「対話」を通じた連携が不足していた。
「量的」な借用はできても「質的」な借用（＝同じ価値観で動いてもらう）が重要ということに気が付いた。
ただし、その働きかけを開発もやりながら全部自分たちでやるのは大変だと感じた。
ギルドワークスと組んでから（二次開発）
二次開発から、ギルドワークスと組んで実行した。
一次開発時に課題となった「借用」の働きかけや、「忘却」を続けられる土壌作りという観点を重視してギルドワークスに助けてもらうことにした。まず、オペレーション設計・運用のメンバーについて「借用」と「忘却」を強化するための体制を強化する取り組みを実施した。
- 開発定例に参加してもらう、勉強してもらうなど
これにより、「忘却」を続けられる土台を作ることができた。
二次開発の主な内容は、個別売りからサブスクリプション型への課金体系やサービス体系の変更・アプリのリメイクとなった。
これを半年で実施した（大変）が、新規事業の不確実性の高さやスピード重視の観点でギルドワークスに支援してもらえたので助かった。
一次開発～二次開発まで、なんとか開発を進めてこられたのは、既存の開発リソースを「忘却」し、アジャイルに強い人で作れたことがでかかった。 また、組織の当たり前を「忘却」し、アジャイル開発への思考にシフトしたきっかけとして、オペレーションの担当として若手（2年目）をリーダーに立ててやったこともでかかった。
ただし、売り込みについては、営業側まで説明ができていたとしても、従来のSPI顧客は提案されるサービスというものは「WF的な機能が揃ったもの」としてイメージしがちなので、サービスへの期待値がずれることも多かった。これは今でも注意が必要な観点。
そのほかの様々な懸念と対策
- 営業の期待値への未達の懸念
- 営業の「借用」
- 勉強会
説明会を実施- 市場における立ち位置、今後の開発計画、営業に理解してほしいことなど
- これにより、「量」ではなく「質」としての「借用」ができた
- 勉強会
- 営業の「借用」
- システム外の管理工数増加の懸念
- 事業支援の「借用」
- 実際に触ってもらい、明確に下記事項を共有して共に対策を検討
- 開発背景／アジャイルであること、課題意識／課金の考え方
- これにより、コーポレート部門への説明なども橋渡し的に動いてもらえるなど協動的に進められた
- 顧客フォローの増加の懸念
- （ギルドワークスに多分に支援してもらったところ）
- オペレーション組織の「学習」
- オペレーションチームがすべての顧客を支援する際、顧客のフォローに学習サイクルを組み込んだ
- これにより、保守開発でもスピーディに不確実性を解消できた
二次開発の結果「忘却」できたもの
- ハード（ギルドワークス）
- 自組織内で対応できるようになった
- ソフト（旧来の思考）
- 当初アンチ側だったオペレーション組織からアジャイル開発に関する発表がされるなど、組織内への変化も生まれてきた。
いま現在（三次開発）
三次開発として、今現在取り組んでいるのは次のような機能拡張
- 社内システム連携
- 未取引顧客の登録・Web化
やることが複雑化・巨大化していくとリソース増強のための「借用」が重要となりそうだが、やりすぎると既存事業と同じようになってしまう懸念がある。（ミイラ取りがミイラ理論）
また、企業側の都合でコーポレート部門の構造が変わったことから、ステークホルダーがどんどん増えてしまった。
このままでは「忘却するということ」を忘れてしまうと、新しいことがやれなくなっていくという懸念も感じるが、ギルドワークスの支援により、「忘却」の振る舞い・思考の基盤ができているため、自分の役割をシンプル化でき、ステークホルダーへの対応や外部の「借用」に集中できている。
学んだこと
忘却
- ハード・ソフトの両輪を移管組織に装着できるか
- 若手をつかって、発信力を強める
- 内部資源の活用にこだわらず、外部からも取り入れることで正しく進められるようにする
借用
- アジャイルの専門家や価値検証の専門家をうまく活用する（餅は餅屋）
- 「量」の借用も重要だが「質」の借用も意識する
学習
- 学習が回る仕組みが重要
- 俗人的な体制は厳しい
QA
[Q]. 学習が回る仕組みはどうやって作ったのか/作ればいいのか
[A]. 新たに仕組みを作るのは大変、既存のアクションフローをうまく活用して差し込むなどから始めるのが良いと思う
[Q]. 古株の反対にどう対処するか
[A]. 古株の影響外の場所にいる味方を見つける、古株の影響を排除する
経営者の観点から見た現場コーチをうまく使う方法
エウレカ 執行役員 金田 悠希 さん ギルドワークス 現場コーチ 中村 洋 さん
＜対談形式からのコミュニケーションセッション：質門対応＞
エウレカの紹介＠金田さん
マッチングアプリ Peirs（ペアーズ） を提供している会社。
金田さんはPeirsの事業責任者
ペアーズの開発は、合計50,60人くらいで、いくつかのチームに分かれて実行している。
チームやエンジニアの話は、@futabooo というエンジニアがよく発信している。
現場コーチの仕事＠中村さん
正しいものを正しく作る：そういう現場を増やす：のが現場コーチのミッション
エウレカ社へのコーチ開始は2017年2月、今は週2回ほど訪問してヒアリングしたり雑談したり。
エウレカでのアジャイル開発の実情
50,60人くらいのメンバーを、４チームに分けて機能毎に開発を進めてきたが、同じプロダクトの開発であっても、チームごとのサイロ化が課題に上がってきた。経営などの上層からはそこまで課題があるように見えなかったが、現場の声としては他のチームが何をやっているのかなどが見えなくなったという感触があったらしい。
そこで、いちど全チーム共通のカンバンを作ることにし、それにより事業のあるべき像を見えるようにしてみようとした。 また、この取り組みを機に、社内から「プロセス改善委員会」が自発的に発足した。
カンバンは当初の目的での活用のほかにも、事業・仕事が実態としてどう進んでいるのかの見える化にもなった。
QA
[Q]. 5,60人で4チームだと1チーム辺りの人数がちょっと多い感じもしますが、チーム内での分担とか協力体制とか何か工夫されていることがあるのでしょうか。
[A]. 遊撃隊の人もいるし、横断的チーム（SRE）もいる。なんだかんだ1チーム10人未満位で回している感じ。体制については、工夫というよりはジュニアが一人っきりになるのは避けるようにしている。シニアは一人はチームに入れている、入れないとチームの空気が悪くなった時に立ち直れなくなる。
[Q]. プロジェクトを止めて立ち上げてを頻繁にされているとのことですが、チームメンバーは毎回異なるんでしょうか？学びはチームではなく個人に蓄積されている状態ですか？
[A]. 学びがチームに蓄積されるのでテーマ変えてもあまりチームは変えたくない。が、テーマによってアサインも違うほうが良いので悩みながら対処している。
[Q]. マネージャーの立ち位置はどうなってますか？
[A]. マネージャーはプロジェクトにアサインしない。外側から見てフォローとチェックを行う役割としている。
その他全体 QA (アンサー：ギルドワークス 市谷さん)
[Q]. 雁行陣からスクラムに変えるタイミングの勘所は？パターンはありますか？
[A]. 背骨が作り終えられたらがよいでしょう
[Q]. ジャーニーはコミットメントな目標？ムーンショットであるべき？ チームの成長させるのであればムーンショットであるべきだと思いますが、コミットメントでないとプロダクトがうまく成長しない可能性があると思っています。
[A]. ジャーニーの位置づけ次第、適宜伸ばすなりもあり
[Q]. キャンバスやユーザーストーリーで、要素を言語化していくことに慣れていない現場や人にどう教育・育成していけば良いでしょうか？暗黙知を引き出したり、論理の飛躍をほぐすことが難しいと思います。
[A]. その通りだと思います。どういう状態でやれるか・コミットメントが厳しいときついとか。キャンバス・仮説検証は勉強も大切だけどやってみるが一番効く。
[Q]. Guildhubのツールでを、例えば、まったく知らない他のユーザに対して内容を共有して（編集も可能）、オンラインで仲間を見つけて、同じ意志を持った人同士が繋がってものづくりできる、ような機能はあったりしますか？
[A]. 見ず知らずの人が探すのはあまりないけど、近いことは考えている。似たような考えのツールは海外にある。GuildHub上で仕事の受け渡しがやれるような方向も考えている。
[Q]. チームリード、プロダクトリード、各々何をどの程度リードしますか？
[A]. ケースバイケース
[Q]. 正しいものを正しく作る取り組みを広げるために研修プログラムを作ってエンハンスする予定はありますか？
[A]. 実は結構いろんな現場でやっている、表立って行っていないけどこれからやっていこうかと考えている
[Q]. ジャーニーはミッションの達成にむけた目安的なものだと理解しましたが、いつの間にか必ず達成が求められる（かつ、方針転換などで達成しないことが明確な）状況に陥ったりしたことはありますか？ もしあればその時にどう対応したかを伺いたいです。 なければ、そういった事態の予防のために気をつけていることを伺いたいです。
[A]. ありうると思います。プロジェクトという概念の中で起こりがちではそれを意識するためのモノがインセプションデッキだったりする。
＝・ω・)ノ いじょう
対談イベントログ：「人のDxを笑うな」及川卓也x海部美知
connpassで偶然見つけた及川卓也さんの対談会に参加してきた際のログです。
講演者は及川卓也さんと海部美知さんとなっていましたが、この対談会を支援しているGNUS（ヌース）というフリーランスエンジニアネットワークを活用したソフトウェア開発企業のCEOである文分邦彦さんからもGNUSの取り組みの紹介がなされた。
本記事はこの対談会を聞いているときに取ったログとなります。
対談会は大きく次の4つのセクションに分かれていました。
ここでは1～3に関するログを掲載します。 聴きながら目盛った意訳的な速記をすこし整形した位のモノなので、本当に対談で使われた表現とは違う場合があります。 また速記のため読みにくさはご容赦ください。
※ 対談イベントのタイトルはとある小説/映画の引用になりますが一応伏せときます。キャッチ―さって大事よねというくらいのもんです。またこの会自体はまったくネガティブなものではなく、終始面白い・考えさせられる話ばかりでした。
海部美知さん：アメリカでの「DX的な取り組みの実情」
海部美知さんは経営コンサル＠シリコンバレー
アメリカでGigsterというフリーランスエンジニアネットワークを形成してSW開発を行う企業を手伝っている。 GNUSは、日本でGigster流のエンジニア開発をやろうとしているスタートアップ企業。
なぜ今回「DX」に注目した話をするに至ったかシリコンバレーのコンサル仲間のゆきちゃんから「DXって言葉」が日本ではやってるらしいというタレコミから、DXなにそれ、知らない、と思って調べたり考えたりしたことから。
また、関連して及川さんとTwitter上でDXに失敗した企業について色々Disったりしてた経緯から、ちゃんと話してみようということになった。
なぜシリコンバレーで「DX」という言葉を聞かないのか、既にデジタル化しているから
またアメリカではSW技術製品を売りにしていても個別のプロダクトとして売り文句を作るので、DXみたいなふんわりした言い方はしない
要するに、進んでいる会社は使わない、メディアなどが持ち上げている言葉
DXよくわからん → 何をデジタル化するのかがあいまいだから
DXで何かを達成するためには,、必ず何かを捨てる／犠牲にすることになる
例えば 効率化が進めば人がいらなくなるなど、本気でやればやるほど犠牲は避けられない
経営としての問題/課題であり、DXのやり方の問題ではない
DXの７０％失敗するというマッキンゼーのレポートもある それは経営が腹をくくれていなかったから
DX失敗例：Hertz 今年ニュースになった 社内の開発部門を首にしてコスト削減したぜ 開発力をなくしたうえでアクセンチュアの部隊でデジタル化を進めようとしたが全然うまくいかない 結果としてアクセンチュアを提訴するに至った
アメリカのDXの現状 GAFAへの対抗策としてのサバイバル戦略として本気で取り組んでいる
積極的なのは次の分野 - 流通小売り事業 - 金融事業
先進事例：Walmart / WalmartLabs 小売り大手のWalmartは、2011年にシリコンバレーのベンチャーを買収してWalmartLabsを作った
最初は田舎でダサい会社には生きたくないという風潮からなかなかエンジニアが増えなかった 社長がエンジニアを直接口説くなど、地道に投資を続けた結果、現在6000人
先進事例：ゴールドマンサックス リーマンショック後に、それまでのホールセールスオンリーからリテール部門の強化も始めた Appleカードの裏側を作っているのも実はゴールドマンサックス
「内製化／DevOps／アジャイル／マイクロ」がポイント＠アメリカ ：日本はちょっと違うポイけどーという発言あり
～質問タイム～
Q WalmartLabの6000人はエンジニアなのか？本体企業とつながらないとDXは難しいと思うのだが？
A 詳しいことはわからないがほぼエンジニアだと思う。そこをどう使うかを経営側が考えているのだろう。 （会ったことある感じだとインド人が多い印象）
Q 日本はDXが進むと技術力のない老人が排除されることになる（はずだけど、できない）という問題のはどう考えるか
A 答えはない、ドライに言えば切り捨てるしかない。年寄の仕事は別の形を与えるなどを考えるなどが必要。
アメリカはレイオフでバッサリ切ることができるし、なんだかんだ独立してコンサルやったりするなど自分で動く風潮もある。ただどのみち厳しい世界ではある。
文分邦彦さん：GNUS（ヌース）の取り組みの紹介
GNUSは、日本でGigster流のエンジニア企業をやろうとしているスタートアップ企業。
文分邦彦さんは、電通 → 新規事業(社内スタートアップ) → アメリカDXコンサル → 日本でGNUS設立
アメリカでDXコンサルをやっているときに、海部さんが支援しているGigstarを活用したら凄かったので、そのやり方を日本に持ち込もうとしている。
DXはアメリカでもコンサルが焚き付けてもリソース不足や組織間の壁などによりなかなか実行に移せていないのが現状。
Gigstarは、数名で100プロジェクトを回したことが評価されて32Mの投資を受けるに至り、現在トップレベルフリーランスが600人登録している企業。
アメリカはフリーランス大国 リモート当たり前の文化もフットワークの軽さに寄与している
フリーランスネットワークというものをつくり 要求に最適なチームを組んで仕事を斡旋する 斡旋といっても常駐派遣はやっていない、リモートワーク前提。 だからこそGeekで強いエンジニアに全力で働いてもらえている。
斡旋されたエンジニアはSWを作って納品するまでを責務としてやっていく というのがGigstarのビジネスモデル
エンジニアの良より質を重視している。本当の意味でトップレベルのエンジニアをネットワーキングしている。
GNUSはこの日本版として2019/7から営業を開始
開発の契約は半年から1年くらいが多い感じ
～質問タイム～
Q エンジニアに高額な報酬を与えるというのは広まるか
A 日本はそもそもサービス業が買いたたかれるという風潮が強い。 大企業に対するバリュー出し、コンサルティング、ビジョンで戦うしかない。 エンジニアの能力はGithubのコードを見たり、試しにコードを書いてもらうなどして実力をよくよく見る。
Q 上流人材はどっから持ってくるのか、見つけてくるのか
A フリーランスの人の中から過去の経歴などもよくよく見て探して見つけようとしている
Q プロジェクトと人のマッチングはどうやっているの 古臭い仕事へのアサインは嫌がられるのでは？
A 内部評価を付けており、評価の高い人ほど自分のやりたいプロジェクトにアサインされるようになる なので最初は仕事選択の自由度は少し低くなる
及川卓也さんと海部美知さん：「DX」という取り組みの在り方
※ 基本的に及川さんの発言をベースに記録
「DX」は実は避けていたが去年位から絡んている＠デンソー：1年半くらい
<宣伝> 10月くらいに日経BPから本が出ます：「ソフトウェアファースト」というタイトル ソフトウェアだけでなく、組織改革も込みの話として書いています。
ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略
- 作者: 及川卓也
- 出版社/メーカー: 日経BP
- 発売日: 2019/10/10
- メディア: 単行本
- この商品を含むブログを見る
日本の大企業は動きが遅い、ソフトウェアの価値を分かっていない
もともとGoogleなどにいたが、外資に魂を売ったわけではなく、外資の目線から日本を良くしようとしたかった
スタートアップもしばらくやってやりがい／手ごたえもあったが スタートアップが頑張っても、社会が変わるのに時間がかかる
大企業を変えないと、変化のレバレッジが効かない
日本はラベルが付いた瞬間に思考停止する。予算と人を付けた、で終わってしまう。
なので「DX」という（あいまいな）言葉は嫌いだった。
重要なのは、DXの定義を作れ、ということ。ただの言葉として扱ってはいけない。 自分の言葉として語れるようになれ。浸透させないといけない。
それを自分事として考えない会社はつぶれていく。
トップが自分の言葉でDX戦略を語れなかったら死んでしまう。 語れない会社からは出た方がよい。
日本の市場でよく作っているソフトウェアはマイクロサービスにするまでもないものがほとんど。 エンジニアあるあるなのはハイスペック適用を好んでしまうことで、過度な適用にやりがち。
組織が100人を超えない限りはマイクロサービスを適用するものではない。 ソラコム、クックパッドなど先進のソフトウェア企業がやってきた経験からみんな言っている。
DXの分かりやすいイメージ ゲータレードがサブスクで売り始めた、スポーツチームにロットで売るという商売それをSWで支援している。 これまでと違うロジックをSWを使って推し進めるのがDX。
デンソーのDXってどういうもの 内製化。内製化ではないのにDXというのは意味が分からない。 ただし、100%内製化しろというわけではない。
DXがイケている企業かどうかを見極めるポイント 中途でSW人材を採用しているか、採用ページがイケてるか ベンダーコントロールとかではない作る人として採用しいるか
オープンソースを利用する というのは外部リソースを活用している／アウトソースしているとも言える
オープンソースにコントリビュートすることは、丸投げではなく自分でコントロールするという意味でもある ★ここまでやれることで広い意味での内製化といえる
製造業のDX HW、組み込みは技術部分も自分でやっていた、コネクテッド(IoT技術)は専門家に出すことが多いが、それを自分でコントロールしているか居ないかで、DXを進められる企業とそうでない企業に分かれていく（★の理論）
Hartzの何が悪かったのか、丸投げ思考
及川さんはIT業界のチコちゃん（自称）
DXに向かうには、トップが覚悟を決めるのはもちろんだが、社内も同じ方向を向いてもらうように努力することが重要
文化を変えないといけない
DX＝デジタル＋変革 と捉えると
デジタル まず、デジタル文化を根付かせる／デジタルの価値を知る必要がある アナログじゃなく、デジタル情報を使いましょう、社長から末端まで、全員が。
変革 デジタルができた上での、事業のトランスフォーメーション
ヤマト運輸 大切にしているのは、エイリアンとミュータントの存在 エイリアン・・・外部からの中途人材 ミュータント・・・社内の異端者
IT人材を「育成」という表現自体が自分のこととして考えていない証拠
ITのリテラシーはマッスルメモリーだ、触ってないから怖がっている、上から下まで全員触ることが重要
厚生労働省の若手が出した資料 プレゼン版
厚生労働省の若手が出した資料 文書版
IT活用、人事評価制度を変える話まで書いてある。必読。
経産省のDXレポート（IDC）2025年の壁 SIerのえらいさんが調査・編集？に関わってるので、最初は脱SIのようなトーンで始まっているに最後に今後のSIとはというオチになっている。残念。中身は良いから最後のページ以外を読むと良い。
SIがどうDXやるの 富士通の取り組みなど、最終的には自分の首を締める取り組みではと見えるが、どうなんだろう。
アメリカではあまりSIがどう頑張っているのかは聞かない。 本気でやっているところはユーザー企業が自分でやっている。
アクセンチュアがかっさらうので残っているのは小さいパイしかないから話になりにくいのかも。
～質問タイム～
Q スクラムをやっていて、最初はWebツールなどを活用していたが開発者が使いにくいということから付箋などのアナログになってしまった。これはデジタルでないと思うのだが。
A スクラム開発はデジタル派とアナログ派に分かれる
デジタルを使うのはリモートでやる場合は鉄板（というか使わないとどうしようもない）だけど カンバンボードのようなものアナログのほうが親和性が高い あの手のやり方は、手法・考え方に「デジタルの仕組み・表現力」が追い付いていないと考える。
使っているツールがアナログだろうがデジタルだろうが、自分で考えて適切なやり方を選べているかが重要なのです。 ツールを使うことがデジタルである証明ではない。
Q GEが失敗した理由
A まず、成功事例としてのWalmartは、Labsの設立から発展まであきらめずに投資し続けて今がある。
GEは本業が悪くて投資が続けられなかったため、過去の負債が影響して失敗した。
GEの進め方について、実はやるべきこと（＝本に書いてあるような教科書的に正しいやり方）を全部やっている 育成などに向けてリーンスタートアップの提唱者エリック・リースやアジャイルの指導にPivotal Labsを活用するなどそれ自体はよいアプローチだった。 GEが投資しきれなかったのは人材、トップ人材を雇えなかったことが敗因。 中途半端な力量の人材を大量に採用してしまったのが失敗に繋がっている。
また「やるべきことをやっている」というのが「本気でやっていたか」かというのもポイントだった。 内部でやっていた人の声を調べると、形式はあるが、実態はできていないということが多かったようだ。
スクラムやデザイン思考も必須なものではない、必要だったら使う手段だ。 綺麗な方法論よりも「文化として根付いていること」が重要。 事業を考える場合にソフトウェアを軸に考えましょう。
余談
connpassで量子コンピュータのハンズオンがあるよ。と宣伝されていた方がいらっしゃった。 これかな？
それにしても、前日に偶然見つけて申し込んだけどとても考えることが増えて楽しい会だったなあ。
いらすとやで理解するスクラム用語
祝！はてブロ初投稿。
はじめましてu-tanickといいます。
今後の仕事的にも興味としてもちゃんと勉強しておいた方がいいと思ったので、年明けに認定スクラムマスター(CSM)の研修を(慈悲で)受講して、先日無事に試験にも合格して認定スクラムマスター(CMS)になれました。
で、せっかくスクラムというものについての自分の理解や捉え方がはっきりしてきたので、復習も兼ねて「いらすとやさん」を活用して初心者向けの簡単なスクラム用語のまとめスライドを作りました。
（まだまだ私自身、理解・表現の甘いところもあるかと思いますので、誤りがございましたらご指摘いただけますとうれしいです）
いらすとやで理解するスクラム用語
このスライドでは、スクラムの全体像と、スクラムの公式ルールとして定義されている24個のルール＝用語と、合わせて使われることの多い9個の用語について、分類わけをしてまとめています。（このブログでは公式ルール外の用語には * 印をつけました）
このブログでは、各分類を1枚にまとめた「いらすと」を掲載します。 スライドでは、各用語ごとに、1ページで端的に説明した文章を添えてあります。
スクラムの全体像
スクラムの3本柱
- 透明性
- 検査
- 適合
スクラムの5つの価値基準
- 確約
- 勇気
- 集中
- 公開
- 尊敬
スクラムの役割
スクラムの成果物
スクラムのイベント
その他の用語
- スプリントゴール *
- インクリメント *
- タイムボックス *
- ベロシティ *
スクラム/アジャイルでよく使われるツール
- インセプションデッキ *
- ストーリーボード *
- バーンダウンチャート *
- プランニングポーカー *
とりあえず、初めての投稿はこんなところで。
いやすとやで理解シリーズは、作ってても楽しかった他にも作ってみたいなぁ。
