狠狠撸

狠狠撸Share a Scribd company logo
1
? Internet Initiative Japan Inc.
プロダクトオーナーと開発者が別会社?別組織でも
前のめりなチームを生み出す取り組み事例
株式会社インターネットイニシアティブ
2023年7月1日
中日本事業部 名古屋支社 技術部 技術4課
北河 直樹
2
アジェンダ
1. 自己紹介
2. 日本におけるソーシング手段の現状
3. ビジネスと開発が分かれていることによる問題
? 地理問題
? 立場問題
? 常識?組織文化問題
4. コミュニケーションの質と量を高める 事例
5. まとめ
3
自己紹介
4
自己紹介
北河 直樹
株式会社インターネットイニシアティブ
中日本事業部 名古屋支社 技術部 技術4課
IIJ名古屋支社でのアジャイルへの取り組みに共感して2020年8月に入社
組織運営?スクラムマスター?技術営業をしながらIIJでの取り組みを社外へ情報発信中
スクラムフェス三河実行委員会
■Twitter @nk_tamago
1998 カーナビ向け地図エンジニアとして地図製作システムの開発?運用に従事
2018 チーム開発に専念するため、ユーザ―企業からベンダー企業へフィールドを移す
2020 IIJ名古屋支社でのアジャイルに共感し現職に至る
2014 アジャイルに出会い可能性を感じる
PdM 兼 PO として自動運転を見据えた次世代地図プラットフォームを推進
国内2拠点 + オフショア1拠点 の 3チームで成功体験し、チームのポテンシャルを知る
1997 デジタルカメラの組み込みエンジニアとしてキャリアスタート
5
情報発信
IIJ Engineers Blog で情報発信しています
IIJ Technical NIGHT vol.11
https://eng-blog.iij.ad.jp/archives/10716
名古屋開発チームのアジャイルな日々
https://eng-blog.iij.ad.jp/ngy-agile
6
日本におけるソーシング手段の現状
7
日本におけるソーシング手段の現状
日米におけるソーシング手段
出典: DX白書2023 ITシステム?デジタル技術活用
日本は全てにおいて内製よ
りも外部委託の比率が高い
コア事業やアジリティを重
視するシステムに関しては、
米国が内製重視に対し、日
本は外部委託の比率が多い
ノンコア事業を見れば、米
国も外部委託の比率が高い
? 米国はコア?ノンコアで内製と外部委託を使い分けている
? 日本は外部委託頼みとなっている
1
1
2
3
2
3
8
日本におけるソーシング手段の現状
ITシステムに求める機能の達成度
出典: DX白書2023 ITシステム?デジタル技術活用
全体的に日本の達成度の低さが目立つ
日本は変化に弱いが浮き彫りになっている
日本と米国で達成度に大きな差が生まれた
理由の一つに、ソーシング手段が内製か外
部委託が関係していると推測
日本のコア事業は外部委託依存に
なっているため変化に弱い
1
1
9
日本におけるソーシング手段の現状
内製化への推進と妨げ
出典:IDC Japan 内製化する社内エンジニアの状況(従業員規模別) 2022年6月29日
出典:ガートナージャパン 2023年1月18日
日本の内製化はまだまだ時間がかかる
大企業は内製化は進んではいくが、
中小企業の内製化は進みが遅い
内製化推進の妨げとして、
人材不足、育成、スキルの問題がある
1
1
2
2
10
日本におけるソーシング手段の現状
まとめ
出典:IPA プレス発表記事 2020年3月31日
? 日本はまだベンダーによる開発が主流
? しかし変化に弱く満足していない
? 内製化したいがすぐには出来ない
日本での外部委託は無くならない
ビジネスと開発の分断は当面続くこと
が予想される
ベンダーへのアジャイル開発が期待される
11
ビジネスと開発が分かれていることによる問題
12
ビジネスと開発が分かれていることによる問題
こんな経験ないですか?
なんか進んでいない感ある
? スプリントは進んでいるのに、リリースバーンダウ
ンが落ちない
? レビューするたびに修正や追加PBIが生まれて同じ
機能ばかり触っている
? レビューの場で初めて知る事実がある
“こんなはずじゃなかった…” を感じた瞬間 その1
POと開発者でズレが生じている
今スプのお届け物です!
うーん、これだと受け入れ基準
を満たしえているか微妙だね。
ここはこうして欲しかったな
(えっ?受け入れ基準満たしていると思うけど…)
では、修正しますね…
開発者
PO
開発者
とあるレビューにて
13
ビジネスと開発が分かれていることによる問題
こんな経験ないですか?
“こんなはずじゃなかった…” を感じた瞬間 その2
まだ慌てる時間じゃない。
イベント時に聞けばいいん
じゃね?
こちら あちら
あれ?これちょっとPOに聞か
ないと分からないな…
開発者A
開発者B
チームにグルーヴ感がない
? 開発者がPOと積極的と会話しようとしない
? 聞けば解決できる内容をイベントまで待とうとする
? POがプロジェクトオーナーのような振る舞いになっ
ている
? 無意識に ”こちら” と ”あちら” を使い分けている
POと開発者間に壁がある
とある日常
んん?なんでバーンダ
ウン落ちてないの?
なんで?なんで?
アッアッ…
とあるデイリーにて
14
ビジネスと開発が分かれていることによる問題
“こんなはずじゃなかった”
? この問題はユーザー企業、ベンダー企業だけの関係だけではない
? 内製をしていても、ビジネス部門とIT部門で分かれている所は注意が必要
? どの企業でも起きる問題
スクラムチームが機能していない
POと開発者でズレが生じている POと開発者間に壁がある
なんか進んでいない感ある チームにグルーヴ感がない
15
ビジネスと開発が分かれていることによる問題
なぜ機能しないのか? (深掘り)
会社?組織が異なる
なんか本音言ってくれない
軽く言っただけなのに大事になる
うまく伝わらない
開発者の声(経験談)
POの声(経験談)
要因の一つ
スクラムチームが機能していない
話かけにくい
深く突っ込こんでよいのか迷う
立場が気になる
常識?組織文化が異なる
場所が異なる 立場が異なる
16
ビジネスと開発が分かれていることによる問題 (地理問題)
場所が異なると
? 相手の状態が見えない
? 急ぎだけど今連絡しても良いか悪いかわからない
? コミュニケーション手段が限られる
? チャットで長文は嫌だし、画面共有してもホワイトボードほどうまく伝えれない
? 話すきっかけが減る
? 近くにいないので
? 心理的にも遠く感じる
? 会話するのにひと手間かかる (めんどくさい)
In communication theory, the Allen curve is a graphical representation that reveals the exponential drop in
frequency of communication between engineers as the distance between them increases. It was discovered
by Massachusetts Institute of Technology Professor Thomas J. Allen in the late 1970s.
コミュニケーション理論におけるアレン曲線は、エンジニア間の距離が離れるにつれて、エンジニア間のコミュニケー
ション頻度が指数関数的に低下することを示すグラフです。1970年代後半に マサチューセッツ工科大学のトーマス?
J?アレン教授によって発見されました。
出典元 : Wikipedia. Allen Curve. https://en.wikipedia.org/wiki/Allen_curve, 翻訳 : Google
コミュニケーションが減る
アレン曲線
おーい、聞こえるかい?
17
ビジネスと開発が分かれていることによる問題 (地理問題)
A Scrum Book (Collocated Team)
The graph shows two sets of situations: those in which question and
answer are available and those in which they are not. “Warmer” indicates
that more emotional and informational richness gets conveyed
グラフには、質問と回答が利用できる場合と利用できない場合の 2 つの状況が示
されています。「より暖かい」は、より感情的で情報的な豊かさが伝わることを示
します
The Allen Curve from 1977 shows that when people separate to a distance
of 10 meters their probability of communicating at least once a week is less
than 10 percent. Despite recent developments in communication technology,
Allen has said this has not improved
1977 年のアレン曲線は、人々が 10 メートルの距離に離れると、少なくとも週に
1 回コミュニケーションをとる確率は 10 パーセント未満であることを示していま
す。通信技術の最近の発展にも関わらず、この状況は改善されていないとアレン氏
は述べています。
コミュニケーションの有効性
感情的、情報的なコミュニケーション
人々の間の距離が離れると、人々が週に一度コミュニケーションをとる確率は減少する
出典元 : A Scrum Book. Collocated Team. http://scrumbook.org/, 翻訳 : Google
ホワイトボードがある個室が最高の環境
出典元 : A Scrum Book. Collocated Team. http://scrumbook.org/, 翻訳 : Google
距離 (m)
週に1回コミュニケーションを取る確率
18
ビジネスと開発が分かれていることによる問題 (立場?常識?組織文化問題)
常識?組織文化が異なると
? 自分の “当たり前” が通用しない
? 文化が違うので当然。日本の常識は海外の非常識と同じ
? 「それは普通やって当然でしょ?」「(普通って…)」
? 話し手 と 聞き手 で捉え方が異なる
? 自分の常識(経験)で脳内変換して納得してしまう
? 抽象度が高い言葉だとなおさら
立場が異なると
? 立場を意識してしまう (開発者の立場が弱いと)
? こんなこと聞いて失礼じゃないかな? など気にしすぎて聞きたいことを聞けない
? 軽い一言が大事になる (POの立場が強いと)
? そんなつもりで言ったわけではないのに…
? 受発注や組織間の関係性を持ち込んでしまう
? PO (発注): 進捗管理しなきゃ!
? 開発者 (受注): 報告しなきゃ!
伝えたいことが正しく伝わらない
しょうもない思考が生まれる
思考に不純物が混じる
赤いボタンは押すのが常識ですよね
意識しすぎて思考停止
19
ビジネスと開発が分かれていることによる問題
コミュニケーションが減る
正しく伝わらない
思考に不純物が混じる
コミュニケーションの量と質が低い
? 苦しい道のりが約束されている
? 上手くいくはずがない
? コミュニケーションの量と質を高める必要がある
要するに
20
コミュニケーションの質と量を高める 事例
21
コミュニケーションの質と量を高める 事例
コミュニケーションの質と量を高めるにはどうすれば良いか?
現実を知り、
? 物理的に離れていることを知る
? スクラムガイドや事例の多くはPOと開発者が同じ場所、組織にい
る世界線
? 離れていた場合は同じことをしていてもだめ
? お互いの常識、文化や価値観が異なっていることを知る
? 当たり前が異なるということを前提とした、コミュニケーション
が取れているか?
? 立場が異なっていることを知る
? 受発注、部署間の関係性を持ち込んでいないか?
? 勝手に壁をつくっていないか?これは聞いてはダメなやつとか
スクラムの三本柱と同じ
透明性 … 現実を知る
検査 … 理想とのギャップを見つける
適応 … 行動に移す 出典元 : IIJ Engineers Blog. なぜ、スクラムが上手くいかない?しっくりこないと感じるのか考えてみよう
理想とのギャップを見つけ、行動に移す
22
コミュニケーションの質と量を高める 事例
(私たちの実践例) 現実を知り、ギャップを見つける
? チームビルディングを行う
? お互いの立場、背景を知って、目指す方向性に合わせる
? 何処までOKかNGかのボーダーを確かめる
? ○○の話とかは聞いちゃっても大丈夫ですか?
? ワーキングアグリーメントに落とす
? 1日目
? 自己紹介
? アジャイル開発の概要説明
? スクラムの概要説明
? レゴスクラム体験
? 2日目
? グラウンドルールの確認
? チェックイン
? MVP概要の説明
? インセプションデッキ作成
? われわれはなぜここにいる、エレベータピッチ、ご
近所さんを探せ
? バックログの作成方法、粒度の説明
? 3日目
? グラウンドルールの確認
? チェックイン
? Step1 お互いを知る
? Step2 目指すものを明確にする
? チームで大事なことは?、ワーキングアグリーメン
トを決定する、チーム名を決定する
? Step3 スクラムの時間割を設定する
? Step4 Ready,Doneの定義を設定する
? 4日目
? グラウンドルールの確認
? 開発?本番環境、ネットワーク等のアーキテクチャの整理
を行う
? 非機能要件の整理を行う
? 環境?非機能要件から技術的負債が存在しているかの洗い
出し
? メンバースキルの明確化
? 不安に思っていること、心配ごとの洗い出し
? インセプションデッキ作成
? トレードオフスライダー
? 5日目
? グラウンドルールの確認
? チェックイン
? バックログの優先度決め
? 相対見積に関する座学
チームビルディング例
ここに労力を惜しんではダメ!
23
コミュニケーションの質と量を高める 事例
(私たちの実践例) 行動に移す
コミュニケーションの量を増やす
? POも可能な限り日常(デイリーなど)に参加する
? スクラムガイドではPOのデイリー参加は開発してたらOKという扱いだが、場所が離れている現実を考えると少しでも顔を合
わせたい
? POと開発者のオフラインの場を可能な限り作る
? 一部のスクラムイベント、節目でも良いのでオフラインで集まれるチャンスを作る
? オンラインはスクラムコニュニティー並みの練度を期待しちゃだめ
? 非同期コミュニケーションで気軽に発言できるチャンネルを用意する
? 現実を知っていれば、何を聞いても、書いても怖くないはず!
? 飲み食いの場を作る
? POはパーティーオーナー
コミュニケーションの量は
どれだけ会話のチャンスを作れるか重要
24
コミュニケーションの質と量を高める 事例
(私たちの実践例) 行動に移す
コミュニケーションの質を高める
コミュニケーションの質は
どれだけ同じ土俵?世界線に乗せれるかが重要
? デイリーでワーキングアグリーメントなど刻みたいことを意識付け
? 毎日見る?読むことで心に刻まれる
? ワーキングアグリーメント観点でふりかえりを行う
? 今の現実を知って改善出来る
? オンラインミーティングは顔出し必須
? 五感の内、視覚と聴覚しかないオンラインで情報量を増やす
? 飲み食いの場を作る
? やっぱり強い
25
まとめ
26
まとめ
出典元 : IIJ Engineers Blog. なぜ、スクラムが上手くいかない?しっくりこないと感じるのか考えてみよう
? 確約
? 組織、立場が違ってもゴールに向けて全力出すぞ!
? 集中
? 立場とかしょうもないことを考えるな!
? 公開
? 組織、立場が違っても隠し事無しよ!
? 尊敬
? お互いの価値観を尊重し個人を尊敬し合いましょう
? 勇気
? 立場は違っても伝えるべきことは伝える勇気!
実は…
全てが詰まっている
ここまで話した内容は全てスクラムの5つの価値基準と同じ
27
まとめ
シン?スクラムチームになろう
? 異なる組織で構成されたチームは非常に不安定でコミュニケーションに爆弾を抱えている
? 形はチームでもスクラムチームとは言い難い状態
? スクラムチームになっていない現実を知って、爆弾を取り除くことが大切
スクラムの三本柱、5つの価値基準 を実践して、
コミュニケーションの量と質を高め、本当のスクラムチームになりましょう!
? 取り除き方は無限大
? 私たちは “チームビルディング” と “日々の活動を工夫する” ことによって爆弾を取り除いている
? スクラムの三本柱、5つの価値基準 を意識しよう
28
IIJ-BKLT999-0001

More Related Content

プロダクトオーナーと开発者が别会社?别组织でも前のめりなチームを生み出す取り组み事例