© 2021 ESM, Inc.
技術転換は組織変革
~ 業務SEをモダンエンジニアチームに変える
株式会社永和システムマネジメント
取締役CTO/Agile Studioディレクター
岡島 幸男
2021年5月12日
1
© 2021 ESM, Inc.
本日お伝えしたいこと
● 0から1の話
○ 最初の一人の技術転換をどう進めたか
○ コードを1行も書けなかった業務SEが、7か月でモダンでアジャイルな
Webエンジニアに
● 1から10の話
○ 組織にどう広げていくか
○ 転換経験者でチームを組み、組織的に拡大させていく
2
© 2021 ESM, Inc.
こんにちは
3
岡島 幸男
取締役CTO/
Agile Studio ディレクター
© 2021 ESM, Inc.
永和システムマネジメント
4
福井本社
東京支社/神田
沖縄支社
● 金融、医療、組込み(自動車)
● Web/Cloud、アジャイル開発
● 社員 220名エンジニア集団
© 2021 ESM, Inc.
Agile Studio (福井の開発拠点)
5
© 2021 ESM, Inc.
なぜ今、技術転換が必要なのか?
● 想定以上のアジャイルシフト
○ Web企業を皮切りに日本でもアジャイル開発が進展
○ DX特需によるモダンエンジニア不足
○ その一方、レガシーエンジニアの単価下落
● 採用の難しさ
○ 人材流動性の高まり。受託会社から事業会社に転職
6
© 2021 ESM, Inc.
技術転換はソフトウェア業界全体の課題
● 事業会社
○ プロダクトのスケールに合わせて開発者を増やしたい
○ 内製と外部委託のバランスを変えたい(内製比率向上)
● システム子会社
○ システム保守しながら新規開発にも対応させたい
○ 外販(独自ビジネス)を増やしたい
● 受託会社
○ スピーディーにモダンな(高く売れる)技術を習得させたい
○ 転換の再現性をあげたい(パターン化、マニュアル化)
7
© 2021 ESM, Inc.
なぜ「技術転換」は難しいのか?
8
徐々に積み上げる=技術習得 一気にジャンプする=技術転換
ウォーターフォールから Scrum
4GL開発からモダンWeb開発
ExcelからIDE・エディタ
タイムスタンプバージョン管理から Git
☺連続性が感じられない
© 2021 ESM, Inc.
0から1の章
~最初の一人
9
© 2021 ESM, Inc.
永和システムマネジメントの事業(組織)
© 2021 ESM, Inc.
永和システムマネジメントにおける技術転換
11
1980’s
1990’s
2000’s
2010’s
Join
Establish 金融
金融 医療
金融 医療 オブジェクト指向
(技術ドメイン特化)
金融 医療 組込み アジャイル
金融を出発点に、柱となる受託開発事業領域を増やしてきた。
2020’s 金融 医療 組込み アジャイル
金融事業でもモダンでアジャイルな開発を!
© 2021 ESM, Inc.
本日の主役
12
良い意味で「THE業務SE」。どうやって彼をモダンエンジニアにシフトさせるか?
● 雄一さん
● 入社12年目(36歳)
● 客先常駐での設計業務を10年(金融系)
● ウォーターフォールの一部(要件調整・設計)をずっと担当
○ 何千人月の世界
● プログラミング経験は実質なし(新人教育のみ)
© 2021 ESM, Inc.
「最初の一人」が肝心
13
http://www.historist.jp/articles/entry/feeling/prospective/048973/ より引用
ラグビー日本代表の強化策( 2012~)における人選。1年目でハードワークなカルチャーを定着させた
人望の厚さ、
人格に優れる
キャプテンの採用
© 2021 ESM, Inc.
トップダウンで始める
● 組織の壁を超えることになりがち
○ 事業ごとに利用する技術が違う
○ 仕事は自分で選べない環境は多い
● 連続性のない技術チャレンジには組織的支援が必要
○ COBOLで勘定系開発⇒TypeScriptでモバイルアプリ開発
○ PM⇒モダンなプログラマー
● やる気があっても自助努力では難しい
○ 空き時間での学習には限界が
○ 転職したほうが早い
15
「本人の自発的な日々の努力の積み重ね」だけに期待しないプラン作りが肝要
© 2021 ESM, Inc.
技術転換プラン
● ゴール
○ 6か月程度でJavaを利用したWeb案件で活躍できること
○ アジャイル(Scrum)開発を身に付けること
● 進め方
○ 全ての時間を技術転換にあてる(金融事業部から1年間Agile
Studioに留学させた)
○ できるだけ早期に実案件で稼働してもらう
○ ゴール達成に必要なら、複数のプロジェクトで必要なステップを踏
んでもらう
○ 複数の役割でフォローは重層的に行う
16
© 2021 ESM, Inc.
雄一プランの実際
17
いきなりJavaを習得するのは難しいと判断し、 JavaScriptベースのGAS(Google Apps Script)から始
め、少しづつ成功体験を積み重ねてもらう作戦とした。結果的には 7か月を要した。
● 模擬プロジェクト
● 個人(with 教育担当)
● アジャイル的
● HTML、CSS
● GAS、G Suite
● Git/GitHub
● SQL、JavaScript
● 実プロジェクト
● 追加機能開発
● 個人(with メンター)
● アジャイル的
● レガシーWeb
● GAS、G Suite
● JQuery、JavaScript
● 実プロジェクト
● 新規開発
● チーム
● 本格Scrum
● モダンWeb
(SPA+REST API)
● Java、GCP
● Vue.js、TypeScript
体験フェーズ(1.5か月) 実習フェーズ(2.5か月) 実戦フェーズ(3か月)
ゴール
© 2021 ESM, Inc.
いきなり実戦Scrumチームに入れると潰れるかもしれない
● Scrumチームは機能横断的でT字型の人材から構成される
⇒ TどころかIですらない状況でハードルが高すぎる
● チームで学びながら徐々に成長する可能性はあるが、チームのベロシ
ティは相当下がる
⇒ ビジネスの責任者もチームメンバーも苦い顔するかもしれない
● このような環境は本人にとって相当なプレッシャー
⇒ 失敗を自分の能力のせいにしてしまい、次の良い行動やパフォーマンスに
つながりにくくなる
18
段階的な成長と「本人の努力による成果」を都度実感させるため、フェーズ分けは重要
© 2021 ESM, Inc.
フェーズチェンジの判断材料
19
● 本質が学べる技術で
の模擬開発
● 座学+手を動かす
● 師匠によるマンツーマ
ン指導
● 実プロジェクト
● 体験フェーズで学んだ
ことを実際にやってみ
る
● 師匠によるマンツーマ
ン指導とペア作業
● 実プロジェクト
● ゴールとした技術の獲
得
● ここまで学んだ技術の
応用
● チームプレイ
● 支援体制の増強
体験フェーズ 実習フェーズ 実戦フェーズ
対象のここまでの成長を評価し、実戦に
臨む十分な動機付けができているかどう
か
十分な知識が身についているか
(手を動
かせているか)
© 2021 ESM, Inc.
体験フェーズのフォーメーション
20
師匠と先生に学び手を動かすことで知識を自分のものにする感覚を
雄
一
師
匠
知恵
管
理
メンターとなる経験豊富なエン
ジニア。基礎を身をもって示し
教える
技術転換
対象
相談
先
生
知
識
プログラム言語等の教育を担
当。主に知識面に関するサポー
ト。座学中心
何かあったときに相談先。パ
フォーマンスの評価
● 先生に教材を元にGAS(JavaScript)の文
法を学ぶ
● サンプルのソースコードを読んでHTMLや
CSSの基礎を学び、実際にWeb画面を表
示させてみる
● 書いたソースコードをGitHubにプッシュ/
プルリクエストし師匠にレビューしてもらう
とある一日
© 2021 ESM, Inc.
技術転換者用
新入社員用
学生インターン用
教育用コンテンツは上手に使いまわす
21
流用と組み合わせで効率化。定期メンテナンスとアップデートでフレッシュさを保つ。
Git/UNIX
GAS
(+Web基礎)
SQL
Java
Git/Unixは新入社員教育由来
GASは技術転換者用由来
他必要に応じて適宜流用
メンテナンス頻度
・GAS(Web)は適宜アップデート(独自コンテ
ンツ)
・Gitは(外部サイトなので)自動的にアップ
デートされる
・JavaやSQLは年1で検討(書籍ベース)
先
生
コンテンツのメンテナンスも
担当
© 2021 ESM, Inc.
実習フェーズのフォーメーション
22
これまでの仕事経験と体験フェーズで得た知識とを組み合わせ実務を成し遂げる
雄
一
師
匠
仕事
管
理
技術転換
対象
相談
何かあったときに相談先。パ
フォーマンスの評価
同じプロジェクトチームの一員
として一緒に仕事をこなす。任
せらえる仕事は任す
● 実際のプロジェクトのソースコードを読み修
正点を検討する
● 師匠に確認しながら修正が必要な点を
Issueとしてまとめる
● 書いたソースコードをGitHubにプッシュ/
プルリクエストし師匠にレビューしてもらう
● テストが完了したソースコードを本番環境
に適用する
● 障害の連絡を受け原因を調査する
とある一日
© 2021 ESM, Inc.
実戦フェーズのフォーメーション
23
ここからが本番。新規開発プロジェクトを Scrumでチーム開発する
雄
一
SM
B
A
相談
管
理
伝
説
バリバリのアーキテクト。
コードレビューへの参加、アーキテクチャ(ソフトウェアス
タック)の決定、サンプルコードの提供など
レ
ビ
ュ
ー
スクラムマスター
(ベテランエンジニア)
モダンWebもScrumも初体
験
モダンWebもScurmも初体
験
技術転換対象。 PO(代理)
役も兼ねる
師
匠
仕事 仕事
© 2021 ESM, Inc.
実戦フェーズのとある一日
● デイリースクラムで困ったことを共有する
● ふりかえりを実施し自分たちの課題を洗い出し改善に向けた行動を
する
● 初めて利用するフレームワークを手分けして調査する
● 技術的な課題が解決できないので伝説役に聞きにいく
● チームワークの課題についてスクラムマスターからヒアリングを受け
る
24
© 2021 ESM, Inc.
チーム開発の教育的意義
25
講義
読書
視聴覚
デモンストレーション
グループ討論
自ら体験する
他の人に教える
5%
10%
20%
30%
50%
75%
90%
ラーニング・ピラミッド
アクティブラーニングと
呼ばれる領域であり、
Scrumによるチーム
ワークで教育効果が高
まると期待できる領域
共育定着率
※ 数値に根拠は
ないそうなので参
考程度に考えべき
だが、経験則とし
てはマッチしてい
る。
© 2021 ESM, Inc.
26
❏ 言われたからやらないといけなさそう
❏ 今、やっていることはあとでいいの?
❏ 作ってもすぐ変わってしまう・・・
❏ 異論が次々と出てくる
雄一さん
他のチームメンバー
❏ 言われたことを実現しないといけない
❏ できるか不安
❏ マインドが変わっていないことに気づく
チームメンバーの抱えるもやもや
© 2021 ESM, Inc.
実戦の厳しさ/難しさ
● 学習中でベロシティーがあがらないからといって、顧客に転嫁する
わけにはいかない
● 実務の一環なので、バランスの良いチームが常に組めるとは限らな
い(スキルの偏り)
● 「何が何でも終わらせること > 自己の成長」誘惑との戦い
27
© 2021 ESM, Inc.
28
❏ フィードバック対応に追われるのみ
カイゼンできない
頭の中と行動に大きなギャップが発生
(アジャイルのつもりだった)
❏ その場で起きたことを優先
計画どおり動けない
❏ フィードバック最優先という固定観念
優先順位付けができない
❏ 無意識にチームを誘導
チームとして機能していない
成果が出ない状態が続く
© 2021 ESM, Inc.
29
❏ バックログ整理
スクラムマスター
❏ 不足技術のフォロー
先輩エンジニア
❏ お客様との折衝を指南
マネージャ
❏ 不足観点をアドバイス
メンター
チーム
❏ 実際に行動する
❏ できるようになることで自信と勇気が芽生える
サポートを受け学びながら前に進む
伝
説
SM
師
匠
管
理
周りがあきらめず関与し、徹底的にサポートする姿勢と行動が決定的に大切
雄
一
B
A
© 2021 ESM, Inc.
30
❏ 適切な対応と熱い気持ち
❏ 言われたらやるという考えは
NG
❏ 「共に創る」という関係性
❏ 受注ー発注の関係ではなく、仲間
❏ チームの信頼関係を築く
❏ 雰囲気、勇気ある行動
❏ お客様へ届ける価値の向上
❏ チームの成長
❏ 個人、チームの弱点を克服
チームの大切さ
お客さまとの関係性
この経験から得たもの
© 2021 ESM, Inc.
マインドセット変遷の軌跡
31
体験フェーズ 実戦フェーズ終盤まで
<マインド>
 アジャイル開発とは、を理解
<行動>
 教育担当、師匠に付き添ってもら
いながら、アジャイルを実施(体験)
<お客様との関係性>
 師匠に導いてもらう
<チームビルド>
 師匠がファシリテート
 (one on oneの体制)
<マインド>
 アジャイル だけど・・・
<行動>
 お客様の言うことは絶対として動
いてしまう
<お客様との関係性>
 (悪い言い方をすると)
 発注ー受注だけの関係性
<チームビルド>
 無意識に自分の考えを肯定させ
るようなチームファシリテート
<マインド>
 アジャイルを実践
<行動>
 お客様との対話・協調を意識
 チームとの会話を徹底
<お客様との関係性>
 「共に創る」をお互いに意識
 仲間として動ける
<チームビルド>
 チームの強みを活かす
 弱みをカイゼンする
 メンバとの信頼関係を築く
転
換
点
実習フェーズ
実戦フェーズ最終盤 ~
現在
© 2021 ESM, Inc.
32
実戦を通じてダブルループ学習に突入していた
行動
前提 結果
シングルループ学習
改善:物事に適切に取り組んでいるか
フィードバックへの迅速な対応
ダブルループ学習
改革:適切な物事に取り組んでいるか
メンタルモデルの見直し
© 2021 ESM, Inc.
33
効果的だったプラクティス
❏ 毎週実施
❏ 自分たちの課題を出し合い改善策を探る
❏ スクラムマスター・師匠も時々参加
❏ 改善しようと決めてもできなかったこともある
❏ チームワークを生み出す効果があった
❏ 一つのPCとディスプレイ
❏ 同じ課題にみんなで立ち向かう
❏ 知識の伝搬が早い
❏ レビューも同時に行うことで効率的
❏ 結果的に...ソースコードのコンフリクトが発生しない
❏ 伝説エンジニアとのセッションも多数実施
モブプログラミング
ふりかえり
© 2021 ESM, Inc.
技術転換を成功させるポイント
1. 模擬環境から始め、技術ギャップがもたらす混乱を最小限にお
さえる
2. フェーズ分けにより成功体験を積み重ね、段階的に動機づける
3. 実プロジェクトを通じたタフな経験がダブルループ学習とマイン
ドチェンジをもたらす
34
マインド(メンタルモデル)の変化まで到達できて成功といえる
© 2021 ESM, Inc.
1から10の章
~ 仲間の増やし方
35
© 2021 ESM, Inc.
技術転換を繰り返すために
● 一人が転換しただけでは意味が薄い
● 転換者だけでチームが組めるように
● 転換者だけで、さらなる転換者を育てられるように
○ 技術転換から、技術習得になるようにする
36
© 2021 ESM, Inc.
金融事業部「モダンチーム」の結成
● 雄一プランを応用し、その後2名をモダンエンジニアとして育成
○ 同じ苦労、同じ考えを共有し、共に歩む仲間ができた
37
● はんそでさん
● 入社12年目(30代)
● 客先常駐で10年(金融系)
● ウォーターフォールの一部
(要件調整・設計・PJ固有ツールでCOBOL開発)を担当
● Excelとプロジェクト固有ツールを使いこなす
● まりこさん
● 入社22年目(40代)
● 主に金融系、管理部(採用等)を担当
● COBOL、Access、VB.net、C言語など幅広く開発は経験
© 2021 ESM, Inc.
仲間が増えると学びが加速する
38
© 2021 ESM, Inc.
技術転換を組織的に広げていくために
1.トップダウン(事業部の目標として明確化)
・事業部長からのミッション(期待)
・実践できる場(プロジェクト)の継続確保
39
2.ボトムアップ(先駆者の実践コミュニティ化)
・本人たちの自律性、主体性
・+CTOによるメンタリング(サポート)
© 2021 ESM, Inc.
実践の場と支援の場
40
金融モダンチーム(実践コミュニティ)
プロジェクトA プロジェクトB プロジェクトC
A
氏
C
氏
B
氏
内部発注
支援・情報共有の場(週一集まる&いつでもチャット)
Agile Studioのプロジェクト 実践の場(それぞれの持ち場で学び成果を出す)
二つの事業部が連携。 それぞれメリットがある 形
© 2021 ESM, Inc.
実践コミュニティとしての金融モダンチーム
● 先駆者3名は中核メンバー
○ 週一の顔合わせ(+様々なおオンラ
イン)を通じ、自己成長、仲間づくりと
いうミッション達成に向けた情報共有
や企画活動等を実施
● その後に続く新参のメンバー(※)は、参
加を通じて学び、役割を変化させ、より深
い貢献ができるようになっていく
○ 現在6名が該当。うち1名は中核メン
バーになりつつある。
41
※ 正統的周辺参加者( LPP)
タスクかんばん
読書記録
ループ図
© 2021 ESM, Inc.
知識創造ループに入り込め!
42
①Agile
Studio留学
【個人】
②チームで
横展開
【集団】
③各現場の
知見まとめ
【組織】
④定着と拡
大【個人】
「金融事業組織全体のモダン化」を現実とするために
メンバーそれぞれ各現場で
学んだことを持ち寄り、自分
たちのやり方、を意識し始め
る
Agile Studioで一緒に開発す
ることで暗黙知として学び取
り込む
①で体験したことをモダン
チームで共有し、関心を継続
・発展させる
通常業務化。次に期待する
メンバーの巻き込み
金
A A 金 金
金 金 金
金
© 2021 ESM, Inc.
新参メンバー
● みんなで学び、みんなで支える
○ いろんな「輪」をつくる
さらに仲間を増やすために
43
中核メンバー
A
氏
やりたいを広げる
みんなでサポート
C
氏
B
氏
知
識
相
談
やりたいことを相談
気付きを与えてくれる
外部
発信
社内
勉強会
社内
イベント
積極的
に絡む
やりたいと思ったことは 自由に
誰か任せにしない、みんなで創る
事業部内活動
師
匠
© 2021 ESM, Inc.
モダンチームによる事業部活動への協力(一例)
● 顧客と一緒にイベントで事例発表
(AgileJapan2020)
● AgileJapan2020の企業サテライトと
なって基調講演を一緒に観る
● 事業部の会議で外部イベント(デブサ
ミ)の参加レポート
● Agile Studioのウェビナー録画を皆で
観る
● 「技術転換を身近に感じる会(座談
会)」を実施
44
© 2021 ESM, Inc.
無関心との戦いに勝利するために
45
● 実践コミュニティが活発化す
ることによりアイデンティティ
が確立する
● 事業環境が変化しているこ
とへの危機感が見えること
● 育成への投資を続けること
による会社としての本気度
● 実際にモダンチームが事業
貢献できていること
技術転換への関心を促す要素
© 2021 ESM, Inc.
「モダンチーム」で大切にしていること
46
行動 ❏ フラットに接する
 全てをゼロベースから始める関係づくり
❏ 直接会話する習慣
 ツールのみの会話だけにしない文化づくり
❏ 楽しむ姿を見せる
 自分自身・関わる人が楽しむことが大事
思考 ❏ 全ての情報をオープンに
❏ NGを作らない、できることを一緒に考えていく
みんなの思いを行動に移せるように支援
❏ 伝搬させる
自分のやりたい⇄みんなのやりたい
変えたい・変えようとしている文化
❏ 立場で自然と決まってしまう役割分担をフラットな組織へ
❏ コミュニケーションの範囲を
PJ内から事業部全体へ(物理的な距離を感じさせない文化へ)
❏ 失敗を恐れすぎてしまう文化をチャレンジできる文化へ
© 2021 ESM, Inc.
組織により良い文化を広めるために
47
「組織のために成長」から、「組織と共に成長・進化」する、へ
ミトコンドリア式働き方
1. エネルギーを供給する → 組織(顧客)のために成果を
2. アポトーシス(変革促進) → 形骸化した習慣を打破する
3. 違う遺伝子を持っている → 自分のメンタルモデル
4. 一体化する → チームで事に当たる
© 2021 ESM, Inc.
技術転換を組織的に行うために
1. 技術転換は継続・拡大しないと意味がないことを知る
2. 一番期待している人を先駆者に選ぶ
3. 同じマインドを持つ小さなチームを作る
4. トップによる期待とメンターによる導きでサンドイッチする
5. 実践コミュニティとしての活動を通じてメンバーを増やす
6. メンバーが実務できるプロジェクトを確保し続ける
7. 活動を通じてより良い文化を育てることが組織変革であることを知る
48
© 2021 ESM, Inc.
ありがとうございました
49

技術転換は組織変革 ~ 業務SEをモダンエンジニアチームに変える

  • 1.
    © 2021 ESM,Inc. 技術転換は組織変革 ~ 業務SEをモダンエンジニアチームに変える 株式会社永和システムマネジメント 取締役CTO/Agile Studioディレクター 岡島 幸男 2021年5月12日 1
  • 2.
    © 2021 ESM,Inc. 本日お伝えしたいこと ● 0から1の話 ○ 最初の一人の技術転換をどう進めたか ○ コードを1行も書けなかった業務SEが、7か月でモダンでアジャイルな Webエンジニアに ● 1から10の話 ○ 組織にどう広げていくか ○ 転換経験者でチームを組み、組織的に拡大させていく 2
  • 3.
    © 2021 ESM,Inc. こんにちは 3 岡島 幸男 取締役CTO/ Agile Studio ディレクター
  • 4.
    © 2021 ESM,Inc. 永和システムマネジメント 4 福井本社 東京支社/神田 沖縄支社 ● 金融、医療、組込み(自動車) ● Web/Cloud、アジャイル開発 ● 社員 220名エンジニア集団
  • 5.
    © 2021 ESM,Inc. Agile Studio (福井の開発拠点) 5
  • 6.
    © 2021 ESM,Inc. なぜ今、技術転換が必要なのか? ● 想定以上のアジャイルシフト ○ Web企業を皮切りに日本でもアジャイル開発が進展 ○ DX特需によるモダンエンジニア不足 ○ その一方、レガシーエンジニアの単価下落 ● 採用の難しさ ○ 人材流動性の高まり。受託会社から事業会社に転職 6
  • 7.
    © 2021 ESM,Inc. 技術転換はソフトウェア業界全体の課題 ● 事業会社 ○ プロダクトのスケールに合わせて開発者を増やしたい ○ 内製と外部委託のバランスを変えたい(内製比率向上) ● システム子会社 ○ システム保守しながら新規開発にも対応させたい ○ 外販(独自ビジネス)を増やしたい ● 受託会社 ○ スピーディーにモダンな(高く売れる)技術を習得させたい ○ 転換の再現性をあげたい(パターン化、マニュアル化) 7
  • 8.
    © 2021 ESM,Inc. なぜ「技術転換」は難しいのか? 8 徐々に積み上げる=技術習得 一気にジャンプする=技術転換 ウォーターフォールから Scrum 4GL開発からモダンWeb開発 ExcelからIDE・エディタ タイムスタンプバージョン管理から Git ☺連続性が感じられない
  • 9.
    © 2021 ESM,Inc. 0から1の章 ~最初の一人 9
  • 10.
    © 2021 ESM,Inc. 永和システムマネジメントの事業(組織)
  • 11.
    © 2021 ESM,Inc. 永和システムマネジメントにおける技術転換 11 1980’s 1990’s 2000’s 2010’s Join Establish 金融 金融 医療 金融 医療 オブジェクト指向 (技術ドメイン特化) 金融 医療 組込み アジャイル 金融を出発点に、柱となる受託開発事業領域を増やしてきた。 2020’s 金融 医療 組込み アジャイル 金融事業でもモダンでアジャイルな開発を!
  • 12.
    © 2021 ESM,Inc. 本日の主役 12 良い意味で「THE業務SE」。どうやって彼をモダンエンジニアにシフトさせるか? ● 雄一さん ● 入社12年目(36歳) ● 客先常駐での設計業務を10年(金融系) ● ウォーターフォールの一部(要件調整・設計)をずっと担当 ○ 何千人月の世界 ● プログラミング経験は実質なし(新人教育のみ)
  • 13.
    © 2021 ESM,Inc. 「最初の一人」が肝心 13 http://www.historist.jp/articles/entry/feeling/prospective/048973/ より引用 ラグビー日本代表の強化策( 2012~)における人選。1年目でハードワークなカルチャーを定着させた 人望の厚さ、 人格に優れる キャプテンの採用
  • 14.
    © 2021 ESM,Inc. トップダウンで始める ● 組織の壁を超えることになりがち ○ 事業ごとに利用する技術が違う ○ 仕事は自分で選べない環境は多い ● 連続性のない技術チャレンジには組織的支援が必要 ○ COBOLで勘定系開発⇒TypeScriptでモバイルアプリ開発 ○ PM⇒モダンなプログラマー ● やる気があっても自助努力では難しい ○ 空き時間での学習には限界が ○ 転職したほうが早い 15 「本人の自発的な日々の努力の積み重ね」だけに期待しないプラン作りが肝要
  • 15.
    © 2021 ESM,Inc. 技術転換プラン ● ゴール ○ 6か月程度でJavaを利用したWeb案件で活躍できること ○ アジャイル(Scrum)開発を身に付けること ● 進め方 ○ 全ての時間を技術転換にあてる(金融事業部から1年間Agile Studioに留学させた) ○ できるだけ早期に実案件で稼働してもらう ○ ゴール達成に必要なら、複数のプロジェクトで必要なステップを踏 んでもらう ○ 複数の役割でフォローは重層的に行う 16
  • 16.
    © 2021 ESM,Inc. 雄一プランの実際 17 いきなりJavaを習得するのは難しいと判断し、 JavaScriptベースのGAS(Google Apps Script)から始 め、少しづつ成功体験を積み重ねてもらう作戦とした。結果的には 7か月を要した。 ● 模擬プロジェクト ● 個人(with 教育担当) ● アジャイル的 ● HTML、CSS ● GAS、G Suite ● Git/GitHub ● SQL、JavaScript ● 実プロジェクト ● 追加機能開発 ● 個人(with メンター) ● アジャイル的 ● レガシーWeb ● GAS、G Suite ● JQuery、JavaScript ● 実プロジェクト ● 新規開発 ● チーム ● 本格Scrum ● モダンWeb (SPA+REST API) ● Java、GCP ● Vue.js、TypeScript 体験フェーズ(1.5か月) 実習フェーズ(2.5か月) 実戦フェーズ(3か月) ゴール
  • 17.
    © 2021 ESM,Inc. いきなり実戦Scrumチームに入れると潰れるかもしれない ● Scrumチームは機能横断的でT字型の人材から構成される ⇒ TどころかIですらない状況でハードルが高すぎる ● チームで学びながら徐々に成長する可能性はあるが、チームのベロシ ティは相当下がる ⇒ ビジネスの責任者もチームメンバーも苦い顔するかもしれない ● このような環境は本人にとって相当なプレッシャー ⇒ 失敗を自分の能力のせいにしてしまい、次の良い行動やパフォーマンスに つながりにくくなる 18 段階的な成長と「本人の努力による成果」を都度実感させるため、フェーズ分けは重要
  • 18.
    © 2021 ESM,Inc. フェーズチェンジの判断材料 19 ● 本質が学べる技術で の模擬開発 ● 座学+手を動かす ● 師匠によるマンツーマ ン指導 ● 実プロジェクト ● 体験フェーズで学んだ ことを実際にやってみ る ● 師匠によるマンツーマ ン指導とペア作業 ● 実プロジェクト ● ゴールとした技術の獲 得 ● ここまで学んだ技術の 応用 ● チームプレイ ● 支援体制の増強 体験フェーズ 実習フェーズ 実戦フェーズ 対象のここまでの成長を評価し、実戦に 臨む十分な動機付けができているかどう か 十分な知識が身についているか (手を動 かせているか)
  • 19.
    © 2021 ESM,Inc. 体験フェーズのフォーメーション 20 師匠と先生に学び手を動かすことで知識を自分のものにする感覚を 雄 一 師 匠 知恵 管 理 メンターとなる経験豊富なエン ジニア。基礎を身をもって示し 教える 技術転換 対象 相談 先 生 知 識 プログラム言語等の教育を担 当。主に知識面に関するサポー ト。座学中心 何かあったときに相談先。パ フォーマンスの評価 ● 先生に教材を元にGAS(JavaScript)の文 法を学ぶ ● サンプルのソースコードを読んでHTMLや CSSの基礎を学び、実際にWeb画面を表 示させてみる ● 書いたソースコードをGitHubにプッシュ/ プルリクエストし師匠にレビューしてもらう とある一日
  • 20.
    © 2021 ESM,Inc. 技術転換者用 新入社員用 学生インターン用 教育用コンテンツは上手に使いまわす 21 流用と組み合わせで効率化。定期メンテナンスとアップデートでフレッシュさを保つ。 Git/UNIX GAS (+Web基礎) SQL Java Git/Unixは新入社員教育由来 GASは技術転換者用由来 他必要に応じて適宜流用 メンテナンス頻度 ・GAS(Web)は適宜アップデート(独自コンテ ンツ) ・Gitは(外部サイトなので)自動的にアップ デートされる ・JavaやSQLは年1で検討(書籍ベース) 先 生 コンテンツのメンテナンスも 担当
  • 21.
    © 2021 ESM,Inc. 実習フェーズのフォーメーション 22 これまでの仕事経験と体験フェーズで得た知識とを組み合わせ実務を成し遂げる 雄 一 師 匠 仕事 管 理 技術転換 対象 相談 何かあったときに相談先。パ フォーマンスの評価 同じプロジェクトチームの一員 として一緒に仕事をこなす。任 せらえる仕事は任す ● 実際のプロジェクトのソースコードを読み修 正点を検討する ● 師匠に確認しながら修正が必要な点を Issueとしてまとめる ● 書いたソースコードをGitHubにプッシュ/ プルリクエストし師匠にレビューしてもらう ● テストが完了したソースコードを本番環境 に適用する ● 障害の連絡を受け原因を調査する とある一日
  • 22.
    © 2021 ESM,Inc. 実戦フェーズのフォーメーション 23 ここからが本番。新規開発プロジェクトを Scrumでチーム開発する 雄 一 SM B A 相談 管 理 伝 説 バリバリのアーキテクト。 コードレビューへの参加、アーキテクチャ(ソフトウェアス タック)の決定、サンプルコードの提供など レ ビ ュ ー スクラムマスター (ベテランエンジニア) モダンWebもScrumも初体 験 モダンWebもScurmも初体 験 技術転換対象。 PO(代理) 役も兼ねる 師 匠 仕事 仕事
  • 23.
    © 2021 ESM,Inc. 実戦フェーズのとある一日 ● デイリースクラムで困ったことを共有する ● ふりかえりを実施し自分たちの課題を洗い出し改善に向けた行動を する ● 初めて利用するフレームワークを手分けして調査する ● 技術的な課題が解決できないので伝説役に聞きにいく ● チームワークの課題についてスクラムマスターからヒアリングを受け る 24
  • 24.
    © 2021 ESM,Inc. チーム開発の教育的意義 25 講義 読書 視聴覚 デモンストレーション グループ討論 自ら体験する 他の人に教える 5% 10% 20% 30% 50% 75% 90% ラーニング・ピラミッド アクティブラーニングと 呼ばれる領域であり、 Scrumによるチーム ワークで教育効果が高 まると期待できる領域 共育定着率 ※ 数値に根拠は ないそうなので参 考程度に考えべき だが、経験則とし てはマッチしてい る。
  • 25.
    © 2021 ESM,Inc. 26 ❏ 言われたからやらないといけなさそう ❏ 今、やっていることはあとでいいの? ❏ 作ってもすぐ変わってしまう・・・ ❏ 異論が次々と出てくる 雄一さん 他のチームメンバー ❏ 言われたことを実現しないといけない ❏ できるか不安 ❏ マインドが変わっていないことに気づく チームメンバーの抱えるもやもや
  • 26.
    © 2021 ESM,Inc. 実戦の厳しさ/難しさ ● 学習中でベロシティーがあがらないからといって、顧客に転嫁する わけにはいかない ● 実務の一環なので、バランスの良いチームが常に組めるとは限らな い(スキルの偏り) ● 「何が何でも終わらせること > 自己の成長」誘惑との戦い 27
  • 27.
    © 2021 ESM,Inc. 28 ❏ フィードバック対応に追われるのみ カイゼンできない 頭の中と行動に大きなギャップが発生 (アジャイルのつもりだった) ❏ その場で起きたことを優先 計画どおり動けない ❏ フィードバック最優先という固定観念 優先順位付けができない ❏ 無意識にチームを誘導 チームとして機能していない 成果が出ない状態が続く
  • 28.
    © 2021 ESM,Inc. 29 ❏ バックログ整理 スクラムマスター ❏ 不足技術のフォロー 先輩エンジニア ❏ お客様との折衝を指南 マネージャ ❏ 不足観点をアドバイス メンター チーム ❏ 実際に行動する ❏ できるようになることで自信と勇気が芽生える サポートを受け学びながら前に進む 伝 説 SM 師 匠 管 理 周りがあきらめず関与し、徹底的にサポートする姿勢と行動が決定的に大切 雄 一 B A
  • 29.
    © 2021 ESM,Inc. 30 ❏ 適切な対応と熱い気持ち ❏ 言われたらやるという考えは NG ❏ 「共に創る」という関係性 ❏ 受注ー発注の関係ではなく、仲間 ❏ チームの信頼関係を築く ❏ 雰囲気、勇気ある行動 ❏ お客様へ届ける価値の向上 ❏ チームの成長 ❏ 個人、チームの弱点を克服 チームの大切さ お客さまとの関係性 この経験から得たもの
  • 30.
    © 2021 ESM,Inc. マインドセット変遷の軌跡 31 体験フェーズ 実戦フェーズ終盤まで <マインド>  アジャイル開発とは、を理解 <行動>  教育担当、師匠に付き添ってもら いながら、アジャイルを実施(体験) <お客様との関係性>  師匠に導いてもらう <チームビルド>  師匠がファシリテート  (one on oneの体制) <マインド>  アジャイル だけど・・・ <行動>  お客様の言うことは絶対として動 いてしまう <お客様との関係性>  (悪い言い方をすると)  発注ー受注だけの関係性 <チームビルド>  無意識に自分の考えを肯定させ るようなチームファシリテート <マインド>  アジャイルを実践 <行動>  お客様との対話・協調を意識  チームとの会話を徹底 <お客様との関係性>  「共に創る」をお互いに意識  仲間として動ける <チームビルド>  チームの強みを活かす  弱みをカイゼンする  メンバとの信頼関係を築く 転 換 点 実習フェーズ 実戦フェーズ最終盤 ~ 現在
  • 31.
    © 2021 ESM,Inc. 32 実戦を通じてダブルループ学習に突入していた 行動 前提 結果 シングルループ学習 改善:物事に適切に取り組んでいるか フィードバックへの迅速な対応 ダブルループ学習 改革:適切な物事に取り組んでいるか メンタルモデルの見直し
  • 32.
    © 2021 ESM,Inc. 33 効果的だったプラクティス ❏ 毎週実施 ❏ 自分たちの課題を出し合い改善策を探る ❏ スクラムマスター・師匠も時々参加 ❏ 改善しようと決めてもできなかったこともある ❏ チームワークを生み出す効果があった ❏ 一つのPCとディスプレイ ❏ 同じ課題にみんなで立ち向かう ❏ 知識の伝搬が早い ❏ レビューも同時に行うことで効率的 ❏ 結果的に...ソースコードのコンフリクトが発生しない ❏ 伝説エンジニアとのセッションも多数実施 モブプログラミング ふりかえり
  • 33.
    © 2021 ESM,Inc. 技術転換を成功させるポイント 1. 模擬環境から始め、技術ギャップがもたらす混乱を最小限にお さえる 2. フェーズ分けにより成功体験を積み重ね、段階的に動機づける 3. 実プロジェクトを通じたタフな経験がダブルループ学習とマイン ドチェンジをもたらす 34 マインド(メンタルモデル)の変化まで到達できて成功といえる
  • 34.
    © 2021 ESM,Inc. 1から10の章 ~ 仲間の増やし方 35
  • 35.
    © 2021 ESM,Inc. 技術転換を繰り返すために ● 一人が転換しただけでは意味が薄い ● 転換者だけでチームが組めるように ● 転換者だけで、さらなる転換者を育てられるように ○ 技術転換から、技術習得になるようにする 36
  • 36.
    © 2021 ESM,Inc. 金融事業部「モダンチーム」の結成 ● 雄一プランを応用し、その後2名をモダンエンジニアとして育成 ○ 同じ苦労、同じ考えを共有し、共に歩む仲間ができた 37 ● はんそでさん ● 入社12年目(30代) ● 客先常駐で10年(金融系) ● ウォーターフォールの一部 (要件調整・設計・PJ固有ツールでCOBOL開発)を担当 ● Excelとプロジェクト固有ツールを使いこなす ● まりこさん ● 入社22年目(40代) ● 主に金融系、管理部(採用等)を担当 ● COBOL、Access、VB.net、C言語など幅広く開発は経験
  • 37.
    © 2021 ESM,Inc. 仲間が増えると学びが加速する 38
  • 38.
    © 2021 ESM,Inc. 技術転換を組織的に広げていくために 1.トップダウン(事業部の目標として明確化) ・事業部長からのミッション(期待) ・実践できる場(プロジェクト)の継続確保 39 2.ボトムアップ(先駆者の実践コミュニティ化) ・本人たちの自律性、主体性 ・+CTOによるメンタリング(サポート)
  • 39.
    © 2021 ESM,Inc. 実践の場と支援の場 40 金融モダンチーム(実践コミュニティ) プロジェクトA プロジェクトB プロジェクトC A 氏 C 氏 B 氏 内部発注 支援・情報共有の場(週一集まる&いつでもチャット) Agile Studioのプロジェクト 実践の場(それぞれの持ち場で学び成果を出す) 二つの事業部が連携。 それぞれメリットがある 形
  • 40.
    © 2021 ESM,Inc. 実践コミュニティとしての金融モダンチーム ● 先駆者3名は中核メンバー ○ 週一の顔合わせ(+様々なおオンラ イン)を通じ、自己成長、仲間づくりと いうミッション達成に向けた情報共有 や企画活動等を実施 ● その後に続く新参のメンバー(※)は、参 加を通じて学び、役割を変化させ、より深 い貢献ができるようになっていく ○ 現在6名が該当。うち1名は中核メン バーになりつつある。 41 ※ 正統的周辺参加者( LPP) タスクかんばん 読書記録 ループ図
  • 41.
    © 2021 ESM,Inc. 知識創造ループに入り込め! 42 ①Agile Studio留学 【個人】 ②チームで 横展開 【集団】 ③各現場の 知見まとめ 【組織】 ④定着と拡 大【個人】 「金融事業組織全体のモダン化」を現実とするために メンバーそれぞれ各現場で 学んだことを持ち寄り、自分 たちのやり方、を意識し始め る Agile Studioで一緒に開発す ることで暗黙知として学び取 り込む ①で体験したことをモダン チームで共有し、関心を継続 ・発展させる 通常業務化。次に期待する メンバーの巻き込み 金 A A 金 金 金 金 金 金
  • 42.
    © 2021 ESM,Inc. 新参メンバー ● みんなで学び、みんなで支える ○ いろんな「輪」をつくる さらに仲間を増やすために 43 中核メンバー A 氏 やりたいを広げる みんなでサポート C 氏 B 氏 知 識 相 談 やりたいことを相談 気付きを与えてくれる 外部 発信 社内 勉強会 社内 イベント 積極的 に絡む やりたいと思ったことは 自由に 誰か任せにしない、みんなで創る 事業部内活動 師 匠
  • 43.
    © 2021 ESM,Inc. モダンチームによる事業部活動への協力(一例) ● 顧客と一緒にイベントで事例発表 (AgileJapan2020) ● AgileJapan2020の企業サテライトと なって基調講演を一緒に観る ● 事業部の会議で外部イベント(デブサ ミ)の参加レポート ● Agile Studioのウェビナー録画を皆で 観る ● 「技術転換を身近に感じる会(座談 会)」を実施 44
  • 44.
    © 2021 ESM,Inc. 無関心との戦いに勝利するために 45 ● 実践コミュニティが活発化す ることによりアイデンティティ が確立する ● 事業環境が変化しているこ とへの危機感が見えること ● 育成への投資を続けること による会社としての本気度 ● 実際にモダンチームが事業 貢献できていること 技術転換への関心を促す要素
  • 45.
    © 2021 ESM,Inc. 「モダンチーム」で大切にしていること 46 行動 ❏ フラットに接する  全てをゼロベースから始める関係づくり ❏ 直接会話する習慣  ツールのみの会話だけにしない文化づくり ❏ 楽しむ姿を見せる  自分自身・関わる人が楽しむことが大事 思考 ❏ 全ての情報をオープンに ❏ NGを作らない、できることを一緒に考えていく みんなの思いを行動に移せるように支援 ❏ 伝搬させる 自分のやりたい⇄みんなのやりたい 変えたい・変えようとしている文化 ❏ 立場で自然と決まってしまう役割分担をフラットな組織へ ❏ コミュニケーションの範囲を PJ内から事業部全体へ(物理的な距離を感じさせない文化へ) ❏ 失敗を恐れすぎてしまう文化をチャレンジできる文化へ
  • 46.
    © 2021 ESM,Inc. 組織により良い文化を広めるために 47 「組織のために成長」から、「組織と共に成長・進化」する、へ ミトコンドリア式働き方 1. エネルギーを供給する → 組織(顧客)のために成果を 2. アポトーシス(変革促進) → 形骸化した習慣を打破する 3. 違う遺伝子を持っている → 自分のメンタルモデル 4. 一体化する → チームで事に当たる
  • 47.
    © 2021 ESM,Inc. 技術転換を組織的に行うために 1. 技術転換は継続・拡大しないと意味がないことを知る 2. 一番期待している人を先駆者に選ぶ 3. 同じマインドを持つ小さなチームを作る 4. トップによる期待とメンターによる導きでサンドイッチする 5. 実践コミュニティとしての活動を通じてメンバーを増やす 6. メンバーが実務できるプロジェクトを確保し続ける 7. 活動を通じてより良い文化を育てることが組織変革であることを知る 48
  • 48.
    © 2021 ESM,Inc. ありがとうございました 49