XP祭り2020(0919) 基調講演エンジニアの創造力を解き放て！（抜粋）

エンジニアの創造力を解き放て！
～XPと歩んだ17年・技術・現場・仲間～
2020/9/19 XP祭り
富士通ソフトウェアテクノロジーズ
神部知明
Copyright 2020 FUJITSU SOFTWARE TECHNOLOGIES LIMITED0

掲載内容は私自身の見解であり、富士通
グループを代表するものではありません。

巨大SIerの中でアジャイル 17年
• 受託開発8割、自社開発2割
• 開発リーダー ➡ 管理職
• 地方在住（静岡）
• 中規模アジャイル（～50名、～270チケット/週）
• ふつうの開発者たち
活気があって、新しいことに挑戦的なチーム
自由だけど、規律があって誠実なチーム
こんな場所で働きたいという漠然とした想いから始まっている

企業内のナレッジマネジメント
• グループウェア開発
• 企業向けSNSの企画・開発・運用
https://www.slideshare.net/InnovationSprint2011/2011-6794551

日本のアジャイルはいよいよキャズムの瀬戸際
しかし、アジャイル開発と日本型IT(SI)はギャップだらけ。
ギャップを乗り越えるためにあらためて基本に立ち返ろう。
◼ DXとアジャイル開発
◼ SI現場の開発に限界を感じた2003年
◼ 巨大SIerの中でのアジャイル開発
◼ アジャイリストの育成

アジャイル開発と日本型ITのギャップ
アジャイル開発のイメージ日本型IT(SI)のイメージ
ITによるイノベーション ITによるコスト削減
能力の高い開発者を集める普通の開発者たちの寄せ集め
個々のメンバーが主体的に行動メンバーは従属的で指示待ち
自律型で高速に進化するチーム指揮命令や重厚長大な開発規約
により統制

により統制

DXとアジャイル開発
～なぜアジャイル開発を理解できないのか～

Agile＋
Studio 見学者の声
Copyright 2020 FUJITSU SOFTWARE TECHNOLOGIES LIMITED
Agile＋
Studio @サウスポット静岡 10F
8

Agile＋
Studio 静岡見学者の声
Digital Transformation
参考）https://riverflex.com/so-youre-in-charge-of-a-
digital-transformation-what-exactly-does-that-mean/
テクノロジーの変革
アジャイルへの変革
新しい
ビジネスモデル
顧客と
チャネル
DevOps
アジャイル開発の見積りや計画に
成功するイメージが持てない
正直、ペアプログラミングは
生産性が悪そう
DXにはアジャイル開発と言われても、
やっぱりよくわからない
大規模な開発になると
上手く管理できる気がしない
9

私のDXのイメージ（事例から）
https://www.inditex.com/en/our-pictures
各店舗から集めた顧客の声を2～3週間で商品化
・企画、デザイン、生産は本社に近い欧州
・デザイナー、リサーチ、バイヤーの3人チームで決定
多品種少量生産、ハイトレンド
グローバルNo1
顧客を起点とした商品づくり
ファストファッション
＝原価低減（途上国での大量生産）
Zara
＝顧客価値＆スピード志向 ≠
10
INDITEX

ハイトレンド、価格維持
◼ シーズンの立ち上がりでは3割の企画しか決まっていない
◼ シーズンが進むにつれ顧客の欲しがる商品が充実、魅力UP
◼ 広告宣伝はしない、店舗に磨きをかける
◼ １色で勝負
参考：https://www.fashionsnap.com/article/2015-04-09/zara-uniqlo/

Digital Transformation (DX)
「企業の在り方や、そこで働く人たちを変化させること」
データとデジタル技術を活用して
顧客や社会のニーズをもとに
私のDXの捉え方
12

DXとアジャイル開発
顧客価値＆スピード志向
どう変化させるか
アジャイル開発
ITシステムの在り方
13

アジャイル開発の様々なプラクティス
カンバンボードバーンダウンチャートイテレーション共同所有属人性の排除
バックログチケット化ふりかえりペアプログラミングモブプログラミング
14
自動テストマイクロサービスローコード自動デプロイ

様々な問題が発生
理解したつもりでも、そう簡単には上手く行かない。
要件が終息せず、デスマーチ状態になってしまった。
全体を結合したら、インターフェースや機能に不整合が多発した。
スピード優先で開発したら、品質問題が発生した。
上手く折り合いがつかず、結局ウォーターフォールに戻した。
経験者が足りない顧客と認識が合わない社内で説明できない
15

どこまで受け入れられますか？
半信半疑
計画がアバウト
取組める
タスク化、見える化、改善
生産性が悪そうで
理解が得られない
過剰なチーム志向
バックログイテレーション
チケット化
カンバンボードペアプログラミングモブプログラミング
バーンダウンチャート共同所有属人性の排除ふりかえり
16

なぜアジャイル開発を理解できないのか
Waterfall
Agile
価値創出
原価低減
未来の失敗
から学ぶ
過去の成功
から学ぶ
実験的
計画的
スペシャリストが分業し
効率的に
チーム一丸となって
小さくすばやく
17

開発チームに求められること
成功の鍵
全体マネジメント
強いヒエラルキー
適切に分業 SAVE MONEY
ＷＦ開発
綿密に計画を立て
失敗しないよう
ぬかりなく対応すること
スペシャリストがそれぞ
れの能力を最大に発揮
できるよう調整する
優秀なチームを
育てるしくみ
EARN MONEY
権限委譲
自律分散
事前に予測できない
失敗から学び
すばやく対応すること
多様な背景の技術者が
チームを組んで
課題を解決する
18

チームの育成に効果的なプラクティス
過剰なチーム志向
ペアプログラミング
多様な背景の技術者が
創発し学び合えるチームをつくる
モブプログラミング
19

ＤＸとアジャイル
20
アジャイル開発で最も重要な視点
「失敗から学び高速に成長できるチームづくり」

により統制

SI現場の開発に限界を感じた2003年
～WF開発でXP？～

昔の資料から（知創空間の作り方 2010/5）
富士通製品開発通信大手SI 自社製品開発その後は受託メインに
受託開発を始めてから悩み始めている（笑）
課長に

アジャイル開発に取組むきっかけ
Scrum
XP
Lean
2002 2010 2015
日
本
③共創案件に積極的に適用
②XPに取り組む中で実感
・開発者のモチベーションUP
・高い品質、スピード向上・イテレーション
・プロセス継続改善
・自動化
第1次ブーム
XPを開発者が導入
試行錯誤
第2次ブーム
導入しやすいScrumが普及
コンサル・資格教育
第3次ブーム
大規模へ適用
改めて価値が見直される
①通信大手SI（WF開発）
開発期間が1/2に短縮
・短期の人員育成
・リスク早期発見
2003～
・ペアプログラミング（知識伝搬、プロセス徹底）
・常時結合（現物確認、検証の前倒し）
24

2003年ウォーターフォールにXP？
① 体制の流動化に伴い、未熟な開発者が急激に増えた
② 開発サイクルが短期化する中で、性能問題が一番のリスクだった
要件定義運用試験
設計
実装
テスト
②設計段階から
実装＆性能検証
技術力の底上げ、
規律
リスク検知、
動くコード＝設計
イテレーション
オープンな作業空間
ふりかえり
計画ゲーム
ストーリー
テスト駆動
コードの共同所有
継続的インテグレーション
リファクタリング
デイリーミーティング
タスクボード
：
①最初に取り入れた
プラクティス

自由と規律 8歳アメリカ
Google画像検索 “全校集会”
クラス毎に整列、体操着に赤帽
号令で前へならえ
叱られるまで無駄話
自由とは自らの努力で手に入れるもの。
与えられないと文句を言う人々ではない。
静かに待つ
https://www.micds.org/news/article/faculty-and-staff-recognized-at-final-all-school-assembly/
並ばない、クラス毎にもならない、
号令もかからない
https://www.ne
wsmax.com/fast
features/pledge
-of-allegiance-
history-
poem/2014/11/
09/id/604690/

自由と規律 16歳高校
入学初日、先輩方の声量にどぎもを抜かれた
数学の授業
75分間ひたすら問題集の答え合わせ
体育の授業
75分間ひたすらランニングと筋トレ
その反面
校則なし、土足
なぜかわからないが、自分も大声で歌うようになっていた
https://www.shizuoka-h.ed.jp/
岳南健児
一千の
理想は高し
富士の山
八面玲瓏
白雪の
清きは
吾等の
こころなり

自由と規律 18歳大学
1987年
山梨大学計算機科学科
VAX-11/785 UNIX 4.2 & 4.3BSD
JUNET（インターネットに接続）
24時間いつでも触れる
ネットニュース、IRCで世界と繋がり
OSS、ハッカー文化にはじめて触れる
https://en.wikipedia.org/wiki/Discipline_(King_Crimson_album)

29
チケットの作業に着手
チケット作業完了し、第三者
によるレビュー待ち
リーダーによる作業内容のレ
ビュー待ち
チケットの作業が全て完了
新規にチケットを作成作業前
チケットステータス
進行中
第三者確認
リーダー確認
完了
チケット駆動 Sprint
計画
開発
Sprint
レビュー
リリース
厳格なルールを全員が順守する
29

ペアプログラミング Sprint
計画
開発
Sprint
レビュー
リリース
ペアで作業し品質を作りこむ
30

ソースコードの共同所有
多能工化を促進
品質の維持・向上
Sprint
計画
開発
Sprint
レビュー
リリース
チーム全員がソースを理解・変更できる状態をめざす
31

テスト内容観点
単体テストアプリのロジック層のクラスの各メソッドに対するテストクラス内の各メソッドが、ドキュメントに記載の通り動作することを確認する
結合テストユーザーストーリテストＰＯが作成したユーザーストーリテストを実施する各機能が、プロダクトオーナーが求める動作をすることを確認する
結合テスト各機能に対して要因分析を行いテスト項目を作成様々なパラメタ、ステータスの組み合わせのテスト
1行テスト仕様書をそのままテスト項目として扱い実施仕様書と実現機能の整合性、消し込みとも呼ばれる、テストファースト
探索的テスト機能に対して探索的にテストを行う対象機能の特性を意識し、テスターが自由にテストを行う、コスパ高い
システムテスト性能多重アクセステスト /耐久性テスト / 大量データテスト
セキュリティセキュリティ検証ツールを利用してセキュリティチェック
運用性、信頼性 DBバックアップ・リストア / リソース監視、ログ監視 / 異常時のテスト
テスト工程
スプリント内で品質確保＋リリース前にシステムテスト
・・・・
リリーススプリント
・・・・
リリース
システムテスト
スプリント
機能開発
単体テスト
結合テスト
スプリント
機能開発
単体テスト
結合テスト
ユーザーストーリテスト
結合テスト
探索的テスト
Sprint
計画
開発
Sprint
レビュー
リリース
32

品質指標（例）
◼ 単体テスト指標値(CI環境で測定)
◼ 結合テストの指標値
カテゴリ言語測定項目測定ツール指標
フロントエンド Javascript ソースカバレッジ Karma-Coverage
(istanbul)
80%以上
静的解析 ESLint 指摘0件
Objective-C 静的解析 Analyze 指摘0件
メモリリーク Leaks 指摘0件
バックエンド Java ソースカバレッジ Cobertura 80%以上
静的解析 CheckStyle 指摘0件
Findbugs 指摘0件
PMD 指摘0件
CPD 指摘0件
テスト指標指標値
ユーザーストーリテスト故障検出率故障0件であること
結合テストテスト項目数 KStep あたり、22.9-34.3件のテスト項目を作成すること
故障検出率 KStepあたり、2件を下回っていること
Sprint
計画
開発
Sprint
レビュー
リリース
33

スプリントレビュー
スプリント
機能開発
単体テスト結合テスト
開発機能のデモ
（動くアプリを確認）
開発の進捗、課題の報告
品質状況の報告
Sprint
計画
開発
Sprint
レビュー
リリース
スプリント毎に実機デモ、品質報告を実施
単体テストの状況報告
- カバレッジ率
結合テストの状況報告
- テスト項目
- 故障件数
- 品質見解
品質課題があった場合、次スプリント作業としてタ
スク化、機能制限とする場合は制限事項一覧に記載
34
スプリントレビュー

ウォーターフォールとアジャイル
あらかじめ、要件が定義
できる場合に効率的
・分業して効率的に
・ドキュメント重視
ビジネス環境（要件）の
変化に追従しやすい
・一丸となってすばやく
・動くソフトウェア重視
フルスタック・多能工チーム
機能Z機能Y機能X機能D
35

IT系人材の差
ヘルシンキ
Aalto Talent Expo 2019にて
当社のインターン募集
• 学生の履歴書がJob Description
から始まっている
• 学生は世界中から集まる
• SLUSHは学生主体で運営
スタートアップ4000社、投資家2000人、
参加者2万5000人
https://www.upgraded.fi/slush-2019-side-events-health-tech-life-sciences/

により統制

アジャイル開発への取り組み
～組織文化を変える～

立ち上げから開発へのフェーズ
スプリント０
（立ち上げ）
チーム
ビルディング
https://www.slideshare.net/dleyanlin/99-
inceptiondeck
プロト1 プロト2
プロトタイピング
https://www.linkedin.com/pulse/design-thinking-
enough-transform-your-business-2-steps-dayo-adefila/
スプリント1 スプリント2 スプリントn・・・
開発・リリース・フィードバック
39

むだを省く・品質を作りこむ・透明化する
チケット化バーンダウンチャートタスクボード
日々の作業状況を確認しチーム
が自律的に活動するための基盤
残タスクの状況を全員がいつ
も見える場所に掲示
ソースコードとタスクの紐付け
/ 作業のエビデンス / 予実管理
自動化
継続的に素早いフィードバック
を得ることで変更コストを削減
勉強会ふりかえり
毎週、開発作業をふりかえり、
継続的にプロセスを改善
定期的に勉強会を開催し、
チームメンバーのスキルアップ
迅速に関係者を集めて検討ドライバーとナビゲーターの双方
が知力を合わせてプログラミング
スタンドアップミーティング
40

41
開発・品質・運用を含めざっくり計画をたてる
開発
品質
運用
モバイル
サーバー
PC
チーム横断で計画
品質や運用課題も反復に組み込む

プロダクトの機能／要望／修正
点などに優先順位を付けた一覧
バックログ
実装するストーリーの
決定
- 作業タスクの詳細化
- 工数の見積もり
プロダクトオーナー
との合意
計画
成果物のレビュー
- 指摘・要望を
バックログへ反映
ふりかえりの実施。
- プロセスの見直し・改善
レビュー
成果物の公開
- 利用者から
のフィードバ
ックを
バックログへ
反映
リリース
スプリント０
（立ち上げ）
スプリント1 スプリント2 スプリント3 スプリント4 スプリントn・・・
2週間のスプリントを複数回繰り返し
多くのチームが2W毎の反復リズムを採用
開発・テストの実施
- 朝会／夕会
- ペアプログラミング
- 継続的インテグレーション（自動テスト）
開発
42

スプリント計画
プロダクトオーナーも含め全員で計画
タスク出し、工数見積もり
プロダクトオーナー報告/調整
プロダクトオーナー報告/調整方式検討
Sprint
計画
開発
Sprint
レビュー
リリース
43

毎日、ボードの前で短い時間で開催
チームごとの朝会チームごとの朝会
全体の朝会遠地との朝会
Sprint
計画
開発
Sprint
レビュー
リリース
44

タスクボード
チケットID
チケットの見積りポイント
Sprint
計画
開発
Sprint
レビュー
リリース
チームのプロセスを見える化する
45

バーンダウンチャート
常に見える場所に掲示
残
作
業
の
ポ
イ
ン
ト
残り時間（日数）
Sprint
計画
開発
Sprint
レビュー
リリース
具体的な数字で管理％ではない
46

ふりかえり Sprint
計画
開発
Sprint
レビュー
リリース
プロセスを自ら改善し続ける
47

どうぶつ救護センターへの導入
（初期登録、写真撮影中）
福島センター（飯野町）
2011.7.28-29
エースアーキテクト
自分ごととして生の感覚を開発チームに持ち帰る Sprint
計画
開発
Sprint
レビュー
リリース
48

SIアジャイルの課題
SIアジャイルの課題当社の取組み / 育成ノウハウ
顧客都合で変動が多い
お客様の投資額に依存
チームの変動耐性向上
◼担当制(個別最適)の排除、リーダーの定期ローテーション
◼詳細なエビデンス記録による業務知識の流出防止
常に育成が必要
入替わり多、WFから転換
技術の継続的獲得
◼徹底したペア作業で即戦力化
◼技術領域をまたぐ部門間ローテでフルスタックエンジニア育成
高品質が前提
スピード優先の提案は危険
アジャイルプロセスのガバナンス＋WFの技法
◼ツールの徹底利用、ルールの徹底、WFの品質管理組み込み
◼リアルタイムで定量的な進捗確認
WFからの転換は難しい
準委任（契約問題）
計画主導から価値主導へ
顧客への透明性確保
KAIZENの伝道ノウハウ
◼5Sから始まる意識改革
◼フリーアドレス導入でチーム志向へ
◼見える化で自律化、ふりかえりによるプロセス改善を定着
体制
品質
人材
文化
49

9:00 始業後
意識改革

フリーアドレス制で
清潔な作業場所を維持
8:20 始業前
個からチーム志向へ
意識改革
意識改革
51 Copyright 2020 FUJITSU SOFTWARE TECHNOLOGIES LIMITED

FYI : Cultural Diversity and Agile
US
https://www.pri.org/stories/2019-01-10/japan-s-shrinking-
labor-force-finding-new-ways-fight-kar-shi-death-overwork
Japan
https://www.opensourcedworkplace.com/news/is-there-
a-legal-minimum-office-square-footage-requirement
52

Research by Edward Hall & Fons Tronpenaars
SEQUENTAL TIME (monochromic) (polychromic) SYNCHRONIC TIME
Germany US
UK
China Japan France
India
Mexico Brazil
Sequential Synchronic
Single task focus Multiple task focus
Short-time orientation Long-term orientation
‘Time is money’ attitude ‘Relationship is money’ attitude
53

Difficulty to apply Agile（Analyzed by Alistair Cockburn）
Country Japan Germany US Austraria UK Singapore Denmark
Difficulty 80 55 49 49 45 43 19
PDI 54 35 40 36 35 74 18
MAS 95 66 62 61 66 48 16
UAI 92 65 46 51 35 8 23
Power Distance 権力の差
Masculinity 男性社会
Uncertainty Avoidance 不確実性の回避傾向
54
※数字はホフステードモデルのスコア

日本企業の調査
https://handbook.bizsci.net/culture2/
コンピュータの分野で日本を代表する大手
電機メーカーF社、N社、T社の3社で
IT96 (Information Technology 1996)調査が
行われた(高橋, 1997, ch.3)。
※高橋伸夫 (1997)『日本企業の意思決定原理』東京大学出版会.
PDI 権力格差
1.従業員が所属長に反対を表明することをしりごみする頻度
2.決定を行なう前に部下に相談する相談的管理者のもとで働きたい
と思わない人の割合
3.自分の上司が独裁的または説得的な管理者であると知覚する人の
割合
UAI 不確実性の回避
1.たとえそうすることが最善でも会社の規則は破るべきではないと
考える程度
2.今後5年より長く今の会社で働き続けたい人の割合
3.仕事の上で神経質になったり緊張したりする頻度
http://books.bizsci.net/principles1997/index.html

日本企業の従業員
PDI 権力格差
相談的管理者のもとで働きたいと思わない
UAI 不確実性の回避
たとえそうすることが最善でも会社の規則は破るべきではない
誰かに指示を出してもらいたい
現状を自ら変えたいとは思わない
主体的な社員が、支配的
にリーダーシップを発揮

により統制

アジャイル開発の考え方
XP
よいものをつくるための
知恵の集まり
Scrum
反復型開発をうまく
回すための仕組み
Lean software development
見える化する、ムダを無くす、品質を作りこむ
自律とリーダーシップ
顧客満足、市場創造
(eXtreamProgramming)
58

重要なのは、
XP:eXtreme Programing
59

ループから知識が生み出される
Team

むだを省く・品質を作りこむ・透明化する
チケット化バーンダウンチャートタスクボード
日々の作業状況を確認しチーム
が自律的に活動するための基盤
残タスクの状況を全員がいつ
も見える場所に掲示
ソースコードとタスクの紐付け
/ 作業のエビデンス / 予実管理
自動化
継続的に素早いフィードバック
を得ることで変更コストを削減
勉強会ふりかえり
毎週、開発作業をふりかえり、
継続的にプロセスを改善
定期的に勉強会を開催し、
チームメンバーのスキルアップ
迅速に関係者を集めて検討ドライバーとナビゲーターの双方
が知力を合わせてプログラミング
61

官僚文化からイノベーション文化へ
OCAI(Organization Culture
Assessment Instrument)より各人
が組織文化をどのように捉えてい
るかをアンケート調査
対象：当社のアジャイル開発者
・アジャイルで開発中のメンバー34名
・過去に関わったウォーターフォール
型開発と比較
出典『IPA 非ウォーターフォール
型開発の普及要因と適用領域の拡大
に関する調査平成24年3月28日』
0.3
0.35
0.4
0.45
0.5
0.55
0.6
Non Waterfall Waterfall
Stress
Stress
0.3
0.35
0.4
0.45
0.5
0.55
0.6
Non Waterfall Waterfall
Quality of Life
Quality of Life
生きがい(QoL)が高く
ストレスが若干低い
62

私のＸＰのイメージ
プラクティスの多くは人材・チームの育成が目的
◼ ふつうの開発者の能力を高めてゆく
◼ 顧客との関係を緊密にし、顧客価値志向にチームを変えてゆく
◼ チームの長期・継続的な成長を実現する

私のスクラムのイメージ
開発者の高い能力をビジネス価値に高速変換するのが目的
◼ 個々の開発者の能力をチームとして発揮できるようにする
◼ 最速で価値を提供するために役割(責任)を決める (PO/SM)
◼ 個々の能力は高いことが前提
アジャイル開発版「情報システム・モデル取引・契約書」
～ユーザ／ベンダ間の緊密な協働によるシステム開発で、DXを推進～
https://www.ipa.go.jp/ikc/reports/20200331_1.html

スクラムとXPの調和 https://www.fujitsu.com/jp/group/fst/about/resources/featurestories/about-agile-03.html

上手いチームは組み合わせている
スクラムとXPの調和
https://www.fujitsu.com/jp/group/fst/about/resources/featurestories/about-agile-03.html

により統制

SIアジャイルのさらなるギャップ
ここを超えないとSIerのビジネスにならない
イ
ノ
ベ
ー
タ
ー
ア
ー
リ
ー
ア
ダ
プ
タ
ー
ア
ー
リ
ー
マ
ジ
ョ
リ
テ
ィ
レ
イ
ト
マ
ジ
ョ
リ
テ
ィ
ラ
ガ
ー
ド

巨大SIerの中でのアジャイル開発

お客様
パートナー
お客様
お客様
社長
グループ
事業部
部
神部B
事業部
グループグループ
全体の0.02%
グループ子会社
グループ子会社パートナー
パートナー当社
0.02%
代表取締役社長
グローバルソ
リューション
エンタープライズ
ソリューション
ファイナンス＆リ
テール
グローバルサービ
ス
デジタルインフラ
デジタルソフト
ウェア
JAPANリージョン
JAPANビジネス
公共・社会インフ
ラ
海外リージョン
システムプラット
フォームビジネス
2020/4現在
2015年当時

アジャイル開発の扱い
◼ 一部の推進派が必要性を説き続けるものの…
◼ ”先進的なユーザー”の”先進的なサービス”を開発する手法
◼ SIでの受託アジャイルは規模が小さすぎる
◼ 既ビジネスに最適化された組織とプロセスの壁は高く…
◼ 本来の価値を発揮できず、アジャイルは上手く行かないという烙印
◼ モノの納品が顧客価値、アジャイルは利益が出ない
◼ 文化的に受け入れがたい
◼ SEの憧れは大規模なWFのプロマネ

わかりやすいSIアジャイルの成功事例
7年間WF(7～12名)でエンハンス ➡ アジャイルに転向
◼ 効果
◼ 残業半減・平準化（平均：30→15h/月、ピーク50→25h/月）
◼ 毎月リリースを実現（不定期→1回/月）
◼ 受発注件数 ½以下（25件→10件）
• Before: 改修機能ごとに提案、見積、費用交渉、稟議、受発注、管理業務が発生
• After: 四半期ごとの契約、契約待ち時間０、顧客側の負担も大幅軽減
• 双方ともにアプリケーションの価値向上に集中
◼ 金額は変わらず、顧客満足は向上
◼ 残る課題
◼ 長期にわたる属人化の解消、テストの自動化

アジャイル適用分野の拡大
要件が社外にあり、ユーザからのフィード
バックによって改善していくしかない世界
SIにおけるアジリティ向上
企業システムの
モダナイゼーション
Enterprise Agile
ビジネス要求に対する
迅速なサービス提供
・デジタル技術の活用
・SIerアジャイル変革
・顧客接点、営業の業務改新
・基幹系の周辺機能強化
開発しながら業界・業務知識を蓄積
SoE + SoR
現場に密着
ソフトウェアで業務改革
高齢者ケアクラウド
動物医療など
提案価値が高い機能から開発
SoE
リーンスタートアップで
新たな価値創出
野球映像
検索システム
ドローン活用
避難誘導システム
73

大手のお客様から、アジャイル適用の相談が急増
商談何故アジャイルか
通信
SM・チーム派遣
コンシューマ向けサービス改版スピードの向上、魅力ＵＰ
金融
アジャイル導入
新マーケット商品、顧客接点、業務改新、基幹系の周辺強化
金融
アジャイル導入
上位の顧客向けサービス、基幹系の周辺強化
自動車
チーム派遣・ツール導入グローバルな社内システムの利用者からの要望反映を迅速化
自動車
開発管理ツール導入
塩漬け大規模システムの運用・保守を効率改善
自動車
アジャイル導入・コーチ派遣次世代モビリティサービス展開にむけた開発力の強化
74

商談急増の背景
デジタルディスラプション
新たなテクノロジーを
活用した市場破壊
働き方改革
IT技術者の生産性向上
ビジネスとITの融合
ITをビジネスに直結
差別化のコア
市場での生き残り IT人材確保
デジタル技術活用 SoE+SoR 人材育成
ツール導入
2015 2016 2017
アジャイル関連商談 ※ツール導入商談を除く
費用削減・スピード向上 DX 人材育成
【アジャイル商談のキーワード】
従来
“開発費用の削減” ”スピード向上” ”品質問題の解決”
(Digital transformation)
最近
”DX” ”内製化” ”人材育成”
75

アジャイル導入への課題
デジタルディスラプション
新たなテクノロジーを
活用した市場破壊
働き方改革
IT技術者の生産性向上
ビジネスとITの融合
ITをビジネスに直結
差別化のコア
市場での生き残り IT人材確保
デジタル技術活用 SoE+SoR 人材育成
ツール導入
大規模開発
複数のアジャイルチーム
ウォーターフォール混在
品質の考え方
ウォーターフォール開発の考え方が適用できない
マイグレーション
マイクロサービス化
分散システムの監視・運用
SIerとの付き合い方
多重請負構造の中での契約
社内の人材確保
SIer側も人材が不足
76

WF混成アジャイル
共通DB
入金
システム
(A社)
与信DB
与信
システ
ム
帳票
システム
入会受付
システム
請求
システム
変更
変更変更
変更変更
Waterfall
アジャイル
(C社)(B社)
(D社) (Ｅ社)
WFとアジャイル混成チームの故障割合
IF漏れ
IF誤り
70%
(参考)WFでの故障割合
IF漏れ
IF誤り
15%
顧客管理請求売上照会発行
漏れ漏れ漏れ遅れ遅れ
x 30
77

レイヤー分割アジャイル
基盤基盤
制御制御
キャッシュキャッシュ
共通
I/F I/F Iteration #1 Iteration #2 Iteration #3 Iteration #n・・・
Iteration #1 Iteration #2 Iteration #3 Iteration #n・・・
2 weeks
レイヤー毎のチーム体制（WFでは生産性向上）で同期取れずスケジュール遅延
関係者が多く情報共有・進捗確認で忙殺（X拠点XXX名超）

ツールでアジャイル
それぞれが
自分を主張し
要求をチケット投入
タスク管理ツール
開発チーム
お客様
矛盾心変わり丸投げ
すべてが最優先
アジャイルは、タスク管理ツールを導入し、チケットで進捗管理すればいい
お客様の要求は
すべて正しいと信じている
受け身体質
112 113
114 115
116 117
大量の要求
チケット
残タスク 1168件
ソース中のTodo 250箇所
プロセス・ルール無しの安易なツール導入による混乱
79

外野に丸投げアジャイル
利用率が低いPFの刷新
・使い勝手が悪い・要望を反映できない
を指示
Top
コンサル
Agile!
スクラム
コーチ
PO 開発チーム
コンサル
PMO
有識者
共通技術
一括請負
A！ B！
X！
SI事業部
Agile?
情報システム部門
Agile?
SM
Agile?
品質

半年アジャイル（状況ヒアリング本人作成資料）
委
託
者
受
託
者
カットカット

半年アジャイル（担当者の吐き出し）
プロジェクト責任者
ベンダー PMO
細かい仕様はベンダーで考えてほしい
• 技術的なことはよく分からない
• 受入テストは簡単なのしかできないよ
• 基盤とか非機能とか依存関係を考慮できない
PO
アジャイルの何が良いか分からない
• 残業増えた
• 構築途中でバグのある基盤で開発
• 無理と思っても計画を詰めこまれる
• PO が外圧に屈してスプリント計画を変える
• PO がなかなか捕まらない
• プロジェクトが終わればチーム解散
Dev
アジャイルにメリットを感じていない
PO、Ｄｅｖ、PMOたちを繋げなければならない
アジャイルコーチの強い干渉
• 無責任に適当なことを吹き込まれる
• このプロジェクトにハマらないワークショップ
• 心理的安全性が無いとプレッシャーかけられるだけ
SM
プロジェクトが失敗しても自分達の責任ではない
• コーチの実績としてスクラムワークショップ
はやらせたい
• 「心理的安全性がないからダメだね」
アジャイルコーチ
アジャイルに巻き込まないで
ほしい
• スケジュールにない割り
込みや変更は防ぎたい
下請け幹部
基盤部隊 (WF)
業務設計
それぞれの思惑はバラバラで
WF型に戻るのは必然だったと思う
カット
カット
カット
カット
一部カット

半年アジャイル（解説）
SI事業部
WF
Before
業務設計
チーム
開発
チーム
開発
チーム
開発
チーム
利用部門
SI事業部
Scrum
After
業務設計
チーム
開発
チーム
開発
チーム
開発
チーム
PO
PO
PO
利用部門
Scrumコーチ
チーム
WFのほうがコミュニケーションが濃くて柔軟だった
×

受託でアジャイル開発を長く続ける秘訣は？
「お客様にたくさんお金を使わせないことです。」
売上目標のある受託開発組織にとってはどうか？
MVPを開発し、お客様のビジネスを育てて …
受注側の現場のマネージャーは今期の予算達成のために増員を提案。
優秀なメンバーだけをずっと引っ張られても困る。
成果を上げられなければ続けられない。
でかいMVPを …

参考）State of Testing Report 2020
85
https://qablog.practitest.com/state-of-testing/ 80ヵ国 1,500人のテストエンジニアへの調査

参考）USでAgileの普及が加速している要因
•アジャイルの成熟
スクラム (1986) やXP (1996)といった根本的な考えやプラクティスをベースにアジャイルソフトウェア開発
宣言が2001に提言された。その後、様々なエンジニアがこの宣言を元にプラクティスを熟練させていき、
SAFeなど大規模向けのフレームワークが整備されるなど、10年の時を経てアジャイルが成熟した。
SAFe® for Lean Enterprises 5.0 Kniberg and Anders (2012). “Scaling Agile @ Spotify”
86

FYI :Volvo Cars
87
https://europe.safesummit.com/presentations/
From 0 to 500 Agile Teams in 18 Months –
Volvo Cars implementing SAFe
Mikael Westerdahl

世界は Team Agile から Enterprise Agile へ
開発チーム企業横断
プロダクトValue
ビジネスValue
企業活動全体の価値向上
組織風土変革スキル
Lean Enterprise
単一システムの価値向上
エンジニアリングスキル
自律組織
Team Agile
Enterprise Agile
←（マネジメント対象）→
企業変革コンサル
・組織風土改革
・PPM連携
Agileコーチ
・プロセス/Testing
・自動化/ツール
・品質（QCD）改善
プロジェクト・
ポートフォリオ管理
財務会計
Agile/WFの同期管理
Issueの依存関係管理
XP,Scrum,Lean
Team
Large Solution
Portfolio
88

参考）USでAgileが普及が加速している要因
https://www.ibm.com/developerworks/community/blogs/c914709e-8097-4537-92ef-8982fc416138/entry/comparing_approaches_to_scaling_agile?lang=en
89

US Japan
トップの強いコミットメント
ビジネスモデルを変革
現場まかせ
ビジネスモデルは不変
Menlo Innovation headquarters in Ann Arbor, Mich. Photo by Elise Hu/NPR 90
スクラムは
「組織変革」
日本人にとっては
「新しい開発手法」

危機感
◼ 強いエンジニアは実践でしか育たないと長年考えてきた
◼ 大規模アジャイル案件が始まっている状況でそうも言っていられない
書籍：More effective agile から
…その多くはリスクを嫌う。妨害を克服する
ために自ら進んでエネルギーを注ぎ込むどこ
ろか、妨害があるということは、その変革が
危険な考えで、諦めるべきだという証拠であ
るというスタンスである。
自分で乗り越えて行く放っておいても変わることはない

育成の取り組み
◼ Dojo 実践訓練
富士通グループ、パートナー、お客様も受講可能
◼ Studio 場
アジャイル開発チームを１か所に集結
◼ 教材整備
コラムとして社外にも公開
◼ 独自の社内認定制度
アジャイルCoEによる社内認定
◼ アジャイル予備校
主にマジョリティー向け座学

Agile+
Studio Dojo
仮想プロジェクト実践訓練
93

①SIアジャイルの典型的な「失敗」を追体験
◼ 発注元との交渉
◼ スプリント計画
◼ 顧客要求の引き出し
◼ タスクの分割、見積
◼ 時間管理
◼ 見える化
◼ タスクボード
◼ バーンダウンチャート
◼ スプリントレビューでの状況報告
◼ Gitの使い方
：
Aさん
「研修なんだからほどほどで良いんじゃないですか？」
講師
「練習で出来ないことを本番で出来ますか？」

②WF脳からの方向転換
綿密に計画を立て
失敗しないよう
ぬかりなく対応すること
事前に予測できない
失敗から学び
すばやく対応すること

③ツールチェーンの効果を実感
チーム
ペア
自動化・実行環境
ペア開発環境バックログ、
チケットを
作成・管理
ドキュメントを
作成・管理
コミュニケーション
各ツールからの
情報を集約
コミットごとに自動
ビルド自動テストな
どのレポート生成
コンテナを自動デプ
ロイ常に最新のアプ
リケーションを実行
ソースコードを
管理
ペア
開発ツール
96
仮想の場

＃10日間(4sprint)の実験/観察の場
先日の講師のブログから引用
「腕に覚えのある人が一人だけいるチームって、これまで最初早いけど
SPレビュー段階では一番遅かった、ってのが割とあるかも。
みんなその人に頼っちゃうし、その人も自分が（良かれと思って）全部
主導しちゃうから結果的にロスが多い感じというか。
もしかしてWFだったらばっちりしっくりなチームの形なのかしら？」
このような現象がわずか3日目で観察できる。

Agile+
オンラインDojo 受講者・見学者の声
◼ オンラインでやると聞き、どうやってやるかと思っていたが、各
種ツールを活用してアジャイル開発ができると認識できた。名前
は知っていても、使ったことがなかったツールを身体で覚える
ことができた。
◼ これまで、開発状況、都合悪いことを隠していた。しかし全部
オープンにすることで、ドロップするときに論理だてて説明す
ることができる。特にリモートにおいては、チーム内・お客様
の信用得るために見える化が必要であり、ツール活用やルール
決めにより、やってやれないことはない。
◼ オンライン会議での合意形成に向けたスキルがこの研修で見に
つけることができた。
◼ 見学者コメント
◼ これは研修だけでなく、これからのオンライン開発そのもの
◼ 先進的な取り組みは大変参考になるとともに、オンラインの可
能性を感じた
◼ 遠隔で開発演習できることがすごい、コーチ陣の育成、指導ス
キルが高い
◼ 研修をやりながら、研修そのもののやり方をアジャイルで変えて
いる
◼ 受講者コメント
◼ 受講前はリモートでアジャイル開発がどこまでできるのか疑問
だったが、ツールややり方を工夫すれば可能だとわかった。
ニューノーマル時代ではリモートが増えるため、リモートで
もアジャイル開発ができるように備えておくべき。
◼ 本を読んだりスクラム研修も受講済みで、アジャイルをどう
進めていくかは理解していたが、「知っている」と「でき
る」の違いは大きい。時間の意識のしかた、見える化、チー
ムのモチベーションを保つことの重要性を感じることができ
た。
◼ 「SDEMみたいな型なんだろう」と思っていたが、アジャイ
ルは、組織や働き方の改革であり、手法ではない。考え方やマ
インドを学ぶ機会が多くある10日間だった。リーダーとして
やるべきことは何か？できるかも？！自分の立ち位置を考え
させられるきっかけになった。
◼ 多能工化された高レベルのSEであること、決断力・交渉力
（機能落としの嫌な調整に躊躇しない）、コミュニケーショ
ン能力がとても大事。・・・まさに富士通で求められている
DX人材そのものの姿ではないか。
98

教材の整備
https://www.fujitsu.com/jp/group/fst/about/resources/featurestories/download-agile.html

アジャイル予備校
ターゲット層
自分で勉強しない
なぜか？がわからない
経験が少なく原則を消化、昇華できない
業務上必要な知識獲得 → 社内認定

富士通、米Scaled Agile, Inc.とパートナーシップ締結
https://pr.fujitsu.com/jp/news/2020/06/1.html
大規模アジャイル開発
企業全体の変革
個人的な想い
・SIerのビジネスとして成り立つ規模に
・大きなことを言わないと誰も乗ってこない
・「丸投げ＆外野だらけのアジャイル」
を回避する処方箋

アジャイルと日本型ITのギャップは乗り越えられるか？
アジャイル開発のイメージ
ITによるイノベーション
能力の高い開発者を集める
個々のメンバーが主体的に行動
自律型で高速に進化するチーム
※私のイメージ
開発者の高い能力をビジネス
価値に高速変換するのが目的
‘Time is money’ attitude
スクラム
日本のSI文化
高PDI：階層構造は心地よい
高UAI：長期志向＆リスクのある
変化は好まない
開発者のスキルレベル
それほど高くない
越
え
ら
れ
な
い
ギ
ャ
ッ
プ

基本に立ち返りイメージを再構築する
開発者の能力を高める
チームで顧客価値を追求
自律型で継続的に進化するチーム
野中スクラム
https://www.slideshare.net/InnovationSprint2011/2011-6794551
能力の高い開発者を集める
個々のメンバーが主体的に行動
自律型で高速に進化するチーム
※私のイメージ
開発者の高い能力をビジネス
価値に高速変換するのが目的
‘Time is money’ attitude
スクラム XP+KAIZENが
埋
め
る

エンジニアの創造力を解き放つ
◼ 日本のアジャイルは普及の瀬戸際
大規模基幹系への適用も始まった
◼ しかし、美辞麗句では動かない
スクラムだけでは越えられない溝
◼ 多くの“まじめで忍耐強い”
日本のエンジニアに向けて
今こそ基本に立ち返り、
あらためてXPの思想を伝えてゆこう
引っ越し後の定番プラクティス、
「配線引き直し」

XP祭り2020(0919) 基調講演エンジニアの創造力を解き放て！（抜粋）

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie XP祭り2020(0919) 基調講演エンジニアの創造力を解き放て！（抜粋）

Ähnlich wie XP祭り2020(0919) 基調講演エンジニアの創造力を解き放て！（抜粋） (20)