Weitere ähnliche Inhalte
Ähnlich wie 【SFO2020】業務SEを7か月でWebエンジニアに変える方法 ~アジャイルマインドを得るために~ (20)
Mehr von Yukio Okajima (8)
【SFO2020】業務SEを7か月でWebエンジニアに変える方法 ~アジャイルマインドを得るために~
- 1. © 2020 ESM, Inc.
業務SEを7か月でWebエンジニアに変える方法
~アジャイルマインドを得るために~
株式会社永和システムマネジメント
Agile Studio Fukui
岡島 幸男
橋本 雄一
2020年6月25日
1
- 2. © 2020 ESM, Inc.
Table of Contents
● 実例に見る(本人が語る)技術転換と、マインド転換
○ 7か月で業務SEをモダンWebエンジニアに技術転換
○ その後1年かけてアジャイルマインドを得た話
2
- 3. © 2020 ESM, Inc.
よくある話?
3
どうやって彼をWebエンジニアにシフトさせていくか?
● 雄一さん
● 入社11年目(34歳)
● 客先常駐での設計業務を10年(金融系)
● ウォーターフォールの一部(要件調整・設計)をずっと担当
○ 何千人月の世界
● プログラミング経験は実質なし(新人教育のみ)
○ SQLはかろうじてわかる
● 幸男さん
● 入社26年目(48歳)
● 今回の技術転換の仕掛け人
- 4. © 2020 ESM, Inc.
7か月の軌跡:3つのフェーズ
4
「JavaによるWeb開発をScurmできるようになること」をゴールとしたが、
「モダンWeb開発」を手軽に実現できる GASでの開発体験からスタート
● 模擬開発
● 個人(with 教育担当)
● アジャイル的
● HTML、CSS
● GAS、G Suite
● Git/GitHub
● SQL、JavaScript
● 追加機能開発
● 個人(with メンター)
● アジャイル的
● レガシーWeb
● GAS、G Suite
● JQuery、JavaScript
● 新規開発
● チーム(3名)
● 本格Scrum
● モダンWeb
(SPA+REST API)
● Java、GCP
● Vue.js、TypeScript
体験フェーズ(1.5か月) 実習フェーズ(2.5か月) 実戦フェーズ(3か月)
ゴールとしたい技術
領域
- 5. © 2020 ESM, Inc.
体験フェーズのフォーメーション
5
師匠と先生に学び手を動かすことで知識を自分のものにする感覚を
対
象
師
匠
知恵
管
理
メンターとなる経験豊富なエン
ジニア。基礎を身をもって示し
教える技術転換対象
相談先
生
知
識
プログラム言語等の教育を担
当。主に知識面に関するサポー
ト。座学中心
何かあったときに相談先。パ
フォーマンスの評価
- 6. © 2020 ESM, Inc.
体験フェーズでのある一日
● 先生に教材を元にGAS(JavaScript)の文法を学ぶ
● サンプルのソースコードを読んでHTMLやCSSの基礎を学び、実際
にWeb画面を表示させてみる
● 書いたソースコードをGitHubにプッシュ/プルリクエストし師匠にレ
ビューしてもらう
6
- 7. © 2020 ESM, Inc.
実習フェーズのフォーメーション
7
これまでの仕事経験と体験フェーズで得た知識とを組み合わせ実務を成し遂げる
対
象
師
匠
仕事
管
理
技術転換対象
相談
何かあったときに相談先。パ
フォーマンスの評価
同じプロジェクトチームの一員
として一緒に仕事をこなす。任
せらえる仕事は任す
- 8. © 2020 ESM, Inc.
実習フェーズでのある一日
● 実際のプロジェクトのソースコードを読み修正点を検討する
● 師匠に確認しながら修正が必要な点をIssueとしてまとめる
● 書いたソースコードをGitHubにプッシュ/プルリクエストし師匠にレ
ビューしてもらう
● テストが完了したソースコードを本番環境に適用する
● 障害の連絡を受け原因を調査する
8
- 9. © 2020 ESM, Inc.
実戦フェーズのフォーメーション
9
新規開発プロジェクトを Scrumでチーム開発する
対
象
SM
20
年
若
手
相談
管
理
伝
説
バリバリのアーキテクト。
コードレビューへの参加、アーキテクチャ(ソフトウェアス
タック)の決定、サンプルコードの提供など
レビュー
スクラムマスター
(ベテランのエンジニ
ア)
ベテランだがモダン Webも
Scrumも初体験
モダンWebもScurmも初体
験
技術転換対象。 PO役も兼
ねる
師
匠
- 12. © 2020 ESM, Inc.
Scrumチームでの実戦:チームワークの教育的意義
12
講義
読書
視聴覚
デモンストレーション
グループ討論
自ら体験する
他の人に教える
5%
10%
20%
30%
50%
75%
90%
ラーニング・ピラミッド
アクティブラーニングと
呼ばれる領域であり、
Scrumによるチーム
ワークでも教育効果が
高まると期待できる領域
共育定着率
※ 数値に根拠は
ないそうなので参
考程度に考えべき
だが、経験則とし
てはマッチしてい
る。
- 13. © 2020 ESM, Inc.
実戦フェーズでのある一日
● 初めて利用するフレームワークを調査する
● デイリースクラムで困ったことを共有する
● ふりかえりを実施し自分たちの課題を洗い出し改善に向けた行動を
する
● 技術的な課題が解決できないので伝説役に聞きにいく
● チームワークの課題についてスクラムマスターからヒアリングを受け
る
13
- 14. © 2020 ESM, Inc.14
効果的だったプラクティス
❏ 毎週実施
❏ 自分たちの課題を出し合い改善策を探る
❏ スクラムマスター・師匠も時々参加
❏ 改善しようと決めてもできなかったこともある
❏ チームワークを生み出す効果があった
❏ 一つのPCとディスプレイ
❏ 同じ課題にみんなで立ち向かう
❏ 知識の伝搬が早い
❏ レビューも同時に行うことで効率的
❏ 結果的に...ソースコードのコンフリクトが発生しない
❏ 伝説エンジニアとのセッションも多数実施
モブプログラミング
ふりかえり
- 15. © 2020 ESM, Inc.
実戦の厳しさ/難しさ
● 類似技術で実習したとはいえ、新たに学ぶことが多い
● 学習中でベロシティーがあがらないからといって、顧客に転嫁する
わけにはいかない
● 実務の一部なので、バランスの良いチームが常に組めるとは限らな
い(スキルの偏り)
● 「何が何でも終わらせること > 自己の成長」誘惑との戦い
15
周りがあきらめず関与し、徹底的にサポートする姿勢と行動が決定的に大切
- 16. © 2020 ESM, Inc.16
❏ 言われたからやらないといけなさそう
❏ 今、やっていることはあとでいいの?
❏ 作ってもすぐ変わってしまう・・・
❏ 異論が次々と出てくる
雄一さん
チーム
❏ 言われたことを実現しないといけない
❏ できるか不安
❏ マインドが変わっていないことに気づく
当事者の実態(対象者・チームの状態)
- 17. © 2020 ESM, Inc.17
❏ フィードバックに終始、徹底
カイゼンできない
頭の中と行動に大きなギャップが発生
(アジャイルのつもりだった)
❏ その場で起きたことを優先
計画どおり動けない
❏ フィードバック最優先という固定観念
優先順位付けができない
❏ 無意識にチームを誘導
チームとして機能していない
当事者の実態(何がダメだったのか)
- 18. © 2020 ESM, Inc.18
❏ バックログ整理
スクラムマスター
❏ 不足技術のカイゼン
伝説のエンジニア
❏ お客様との折衝を指南
管理
❏ 不足観点をアドバイス
師匠
チーム
❏ 実際に行動する
❏ できるようになることで自信と勇気が芽生える
当事者の実態(なぜ改善できたのか)
- 20. © 2020 ESM, Inc.20
❏ 適切な対応と熱い気持ち
❏ 言われたらやるという考えはNG
❏ 「共に創る」という関係性
❏ 受注ー発注の関係ではなく、仲間
❏ チームの信頼関係を築く
❏ 雰囲気、勇気ある行動
❏ お客様へ届ける価値の向上
❏ チームの成長
❏ 個人、チームの弱点を克服
チームの大切さ
お客さまとの関係性
この経験から得たもの
- 21. © 2020 ESM, Inc.
マインドセット変遷の軌跡
21
体験・実習フェーズ( 4か月)
実戦フェーズ(〜現在)
3ヶ月 12ヶ月(現在)
<マインド>
アジャイル開発とはを理解
<行動>
教育担当、師匠に付き添ってもら
いながら、アジャイルを実施(体験)
<お客様との関係性>
師匠に導いてもらう
<チームビルド>
師匠がファシリテート
(one on oneの体制)
<マインド>
アジャイル だけど・・・
<行動>
お客様の言うことは絶対として動
いてしまう
<お客様との関係性>
(悪い言い方をすると)
発注ー受注だけの関係性
<チームビルド>
無意識に自分の考えを肯定させ
るようなチームファシリテート
<マインド>
アジャイルを実践
<行動>
お客様との対話・協調を意識
チームとの会話を徹底
<お客様との関係性>
「共に創る」をお互いに意識
仲間として動ける
<チームビルド>
チームの強みを活かす
弱みをカイゼンする
メンバとの信頼関係を築く
…
- 22. © 2020 ESM, Inc.
段階を踏まずいきなり実戦Scrumチームに入れるとどうなるか
● Scrumチームは機能横断的でT字型の人材から構成される
⇒ 結構敷居が高い
● チームで学びながら徐々に改善・成長する可能性はあるが、チームのベロシ
ティが相当下がることを覚悟する必要がある
⇒ 普通ビジネスは嫌がるしチームメンバーも苦い顔しがち
● このような環境は本人にとって相当なプレッシャー
⇒ 失敗経験を自分の能力に帰属させてしまいがち ⇒ 次の良い行動やパ
フォーマンスにつながりにくくなる
22
段階的な成長と「本人の努力による成果」を都度実感させるため、フェーズ分けは重要
- 23. © 2020 ESM, Inc.
フェーズチェンジの判断ポイント
23
● 本質が学べる技術で
の模擬開発
● 座学+手を動かす
● 師匠によるマンツーマ
ン指導
● 実プロジェクト
● 体験フェーズで学んだ
ことを実際にやってみ
る
● 師匠によるマンツーマ
ン指導とペア作業
● 実プロジェクト
● ゴールとした技術の獲
得
● ここまで学んだ技術の
応用
● チームプレイ
● 支援体制の増強
体験フェーズ 実習フェーズ 実戦フェーズ
対象のパーソナリティとここまでの成長を
評価し、実戦に臨む十分な動機付けがで
きているかどうかが判断材料
十分な知識が身についているか(十分手
を動かせているか)が判断材料
- 24. © 2020 ESM, Inc.
まとめ:技術転換を成功させるポイント
1. 本質が学べる類似環境から始め、技術ギャップがもたらす混乱を最
小限にする
2. 手を動かして覚えたことと、これまでの経験とを関連付けられるよ
う、実習(実プロジェクト)の場を作る
3. フェーズ分けにより成功体験を積み重ね、段階的に動機づける
24