More Related Content
Similar to 業務SEを7か月でWebエンジニアに変える方法 (20)
More from Yukio Okajima (9)
業務SEを7か月でWebエンジニアに変える方法
- 1. © 2019 ESM, Inc.
業務SEを7か月でWebエンジニアに変える方法
株式会社永和システムマネジメント
Agile Studio Fukui
岡島 幸男
2019年6月25日
1
- 2. © 2019 ESM, Inc.
Table of Contents
● 実例に見る技術転換
○ 7か月で業務SEをモダンWebエンジニアに技術転換
● (おまけ)実例に見る開発プロセス変革
○ ウォーターフォールからアジャイルへ
2
- 3. © 2019 ESM, Inc.
よくある話?
3
どうやって彼をWebエンジニアにシフトさせていくか?
● 雄一さん
● 入社11年目(34歳)
● 客先常駐での設計業務を10年(金融系)
● ウォーターフォールの一部(要件調整・設計)をずっと担当
○ 何千人月の世界
● プログラミング経験は実質なし(新人教育のみ)
○ SQLはかろうじてわかる
- 4. © 2019 ESM, Inc.
まとめ:技術転換を成功させるポイント
1. 本質が学べる類似環境から始め、技術ギャップがもたらす混乱を最
小限にする
2. 手を動かして覚えたことと、これまでの経験とを関連付けられるよ
う、実習(実プロジェクト)の場を作る
3. フェーズ分けにより成功体験を積み重ね、段階的に動機づける
4
- 5. © 2019 ESM, Inc.
7か月の軌跡:3つのフェーズ
5
「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か月)
ゴールとしたい技術
領域
- 6. © 2019 ESM, Inc.
繰り返すことでうまくなる:学習プロセスモデルとの対応
6
体験フェーズ
実習フェーズ
実戦フェーズ
http://www.mext.go.jp/component/b_menu/shingi/toushin/__icsFiles/afieldfile/2015/09/24/1361110_2_5.pdf より引用
- 7. © 2019 ESM, Inc.
体験フェーズのフォーメーション
7
師匠と先生に学び手を動かすことで知識を自分のものにする感覚を
対
象
師
匠
知恵
管
理
メンターとなる経験豊富なエン
ジニア。基礎を身をもって示し
教える技術転換対象
相談先
生
知
識
プログラム言語等の教育を担
当。主に知識面に関するサポー
ト。座学中心
何かあったときに相談先。パ
フォーマンスの評価
- 8. © 2019 ESM, Inc.
体験フェーズでのある一日
● 先生に教材を元にGAS(JavaScript)の文法を学ぶ
● サンプルのソースコードを読んでHTMLやCSSの基礎を学び、実際
にWeb画面を表示させてみる
● 書いたソースコードをGitHubにプッシュ/プルリクエストし師匠にレ
ビューしてもらう
8
- 9. © 2019 ESM, Inc.
実習フェーズのフォーメーション
9
これまでの仕事経験と体験フェーズで得た知識とを組み合わせ実務を成し遂げる
対
象
師
匠
仕事
管
理
技術転換対象
相談
何かあったときに相談先。パ
フォーマンスの評価
同じプロジェクトチームの一員
として一緒に仕事をこなす。任
せらえる仕事は任す
- 10. © 2019 ESM, Inc.
実習フェーズでのある一日
● 実際のプロジェクトのソースコードを読み修正点を検討する
● 師匠に確認しながら修正が必要な点をIssueとしてまとめる
● 書いたソースコードをGitHubにプッシュ/プルリクエストし師匠にレ
ビューしてもらう
● テストが完了したソースコードを本番環境に適用する
● 障害の連絡を受け原因を調査する
10
- 11. © 2019 ESM, Inc.
実プロジェクトで深い理解を促すことができる
11
POINT
1. 「動機づけ」実プロ
ジェクトはあらゆる
動機づけを発動させ
る可能性が高い
2. 「多面的学習」実務
の緊張感は、手を動
かして新たに覚えた
ことと自分の既存知
識との関連付けを促
進する
3. ただし当然動機には
個人差があることに
注意
http://www.mext.go.jp/component/b_menu/shingi/toushin/__icsFiles/afieldfile/2015/09/24/1361110_2_5.pdf より引用
- 12. © 2019 ESM, Inc.
実戦フェーズのフォーメーション
12
新規開発プロジェクトを Scrumでチーム開発する
対
象
SM
20
年
若
手
相談
管
理
伝
説
バリバリのアーキテクト。
コードレビューへの参加、アーキテクチャ(ソフトウェアス
タック)の決定、サンプルコードの提供など
レビュー
スクラムマスター
(ベテランのエンジニ
ア)
ベテランだがモダン Webも
Scrumも初体験
モダンWebもScurmも初体
験
技術転換対象。 PO役も兼
ねる
師
匠
- 15. © 2019 ESM, Inc.
Scrumチームでの実戦:チームワークの教育的意義
15
講義
読書
視聴覚
デモンストレーション
グループ討論
自ら体験する
他の人に教える
5%
10%
20%
30%
50%
75%
90%
ラーニング・ピラミッド
アクティブラーニングと
呼ばれる領域であり、
Scrumによるチーム
ワークでも教育効果が
高まると期待できる領域
共育定着率
※ 数値に根拠は
ないそうなので参
考程度に考えべき
だが、経験則とし
てはマッチしてい
る。
- 16. © 2019 ESM, Inc.
実戦フェーズでのある一日
● 初めて利用するフレームワークを調査する
● デイリースクラムで困ったことを共有する
● ふりかえりを実施し自分たちの課題を洗い出し改善に向けた行動を
する
● 技術的な課題が解決できないので伝説役に聞きにいく
● チームワークの課題についてスクラムマスターからヒアリングを受け
る
16
- 17. © 2019 ESM, Inc.
効果的だったプラクティス
17
モブプログラミング
● 一つのPCとディスプレイ
● 同じ課題にみんなで立ち向かう
● 知識伝搬が早い
● レビューも同時に行うことで効率的
● (結果的に)ソースコードのコンフリクトが発生しな
い
● 伝説エンジニアとのセッションも多数実施
ふりかえり
● 毎週実施
● 自分たちの課題を出し合い改善策を探る
● スクラムマスター・師匠も時々参加
● 改善しようと決めてもできなかったこともあるけど
● チームワークを生み出す効果があった
- 18. © 2019 ESM, Inc.
実戦の厳しさ/難しさ
● 類似技術で実習したとはいえ、新たに学ぶことが多い
● 学習中でベロシティーがあがらないからといって、顧客に転嫁する
わけにはいかない
● 実務の一部なので、バランスの良いチームが常に組めるとは限らな
い(スキルの偏り)
● 「何が何でも終わらせること > 自己の成長」誘惑との戦い
18
周りがあきらめず関与し、徹底的にサポートする姿勢と行動が決定的に大切
- 19. © 2019 ESM, Inc.
内部 外部
安定 不安定 安定 不安定
統制不可能 能力 気分 課題
難易度
運
統制可能 普段の
努力
一時的
努力
教師
バイアス
他者の
助力
周りができること:達成動機づけ理論を参考に
19
先行経験 原因帰属 原因次元 帰結的行動
成功
失敗
帰
属
配
置
決
定
能力
普段の
努力
一時的
努力
難易度
運
気分
教師の
バイアス
他者の
助力
行動
パフォーマンス
自尊心
の感情
期待度の
変化
他者の
評価
原因の
位置
時間的
安定性
統制
可能性
影
響
Wienerの達成動機づけ理論
影
響
影
響
「スクラムマスター」
「管理」
前のフェーズにおける成功は、普
段の努力のおかげなんだ!という
実感を持ってもらえるような活動
や評価
「スクラムマスター」
「伝説」「師匠」
外部からの支援の質・量・頻度を適切
にコントロールしてあげる
- 20. © 2019 ESM, Inc.
注意:達成動機付けはパーソナリティに依存しがち
● 満たされることのない大きな望みによって常にもっと努力しようと駆り立てられる
● 人生において、立派な成果を成し遂げることほど価値のあるものはないと思う
● 仕事で成功して注目に値する成果を残すことによって、私の将来は安定し、自尊心が満たされることに
なると思う
● 困難な目標達成を自分自身に課すようにしている
● 将来を夢想するというよりも、自分が今、直面している仕事に対して労力を注ぐタイプである
● 自分の利害が損なわれそうな状況では、自分の仕事に完全に集中し、他人との義理を忘れる
● 仕事に成功してひと段落したときだけ、休養を心から楽しめる
● 自分が行うほとんどの活動に対して競争心を抱いている
● 引き受けたすべてのことに対して、自分がその成果に満足するまで働く
● 遊びと同じくらい仕事を楽しんでいる
20
Murrayによる達成要求を測定するための質問事項( 1938)
- 27. © 2019 ESM, Inc.
当事者からのコメント
27
元業務SE
● いきなりモダンWebに取り組まなくて良かった。多分混乱していた
と思う。
● チームで高めあえたのが良かった。モブプロが効果的だった。
● 上から下まで全部担当(プログラミング、テスト)することで、変な
上限関係ができず、風通しの良いチームになった。
● アジャイルなので、要件が変わることには正直戸惑った。
● 1週間スプリントで都度ふりかえり改善することで、ウォーター
フォール時代に比べもやもやが早く解消できてよかった。
● 7か月前では想像できなかったぐらい成長したと思う。技術面だけ
ではなく、仕事のスタイルや価値観までも変わった(変化を許容
できるようになった)。
- 28. © 2019 ESM, Inc.
段階を踏まずいきなり実戦Scrumチームに入れるとどうなるか
● Scrumチームは機能横断的でT字型の人材から構成される
⇒ 結構敷居が高い
● チームで学びながら徐々に改善・成長する可能性はあるが、チームのベロシ
ティが相当下がることを覚悟する必要がある
⇒ 普通ビジネスは嫌がるしチームメンバーも苦い顔しがち
● このような環境は本人にとって相当なプレッシャー
⇒ 失敗経験を自分の能力に帰属させてしまいがち ⇒ 次の良い行動やパ
フォーマンスにつながりにくくなる
28
段階的な成長と「本人の努力による成果」を都度実感させるため、フェーズ分けは重要
- 29. © 2019 ESM, Inc.
フェーズチェンジの判断ポイント
29
● 本質が学べる技術で
の模擬開発
● 座学+手を動かす
● 師匠によるマンツーマ
ン指導
● 実プロジェクト
● 体験フェーズで学んだ
ことを実際にやってみ
る
● 師匠によるマンツーマ
ン指導とペア作業
● 実プロジェクト
● ゴールとした技術の獲
得
● ここまで学んだ技術の
応用
● チームプレイ
● 支援体制の増強
体験フェーズ 実習フェーズ 実戦フェーズ
対象のパーソナリティとここまでの成長を
評価し、実戦に臨む十分な動機付けがで
きているかどうかが判断材料
十分な知識が身についているか(十分手
を動かせているか)が判断材料
- 30. © 2019 ESM, Inc.
まとめ:技術転換を成功させるポイント
1. 本質が学べる類似環境から始め、技術ギャップがもたらす混乱を最
小限にする
2. 手を動かして覚えたことと、これまでの経験とを関連付けられるよ
う、実習(実プロジェクト)の場を作る
3. フェーズ分けにより成功体験を積み重ね、段階的に動機づける
30
- 31. © 2019 ESM, Inc.
(おまけ)
実例に見る開発プロセス変革:
ウォーターフォールからアジャイルへ
31
- 32. © 2019 ESM, Inc.
オリジナルメンバー
チームをアジャイルに
32
チームリーダ
メンバ メンバ メンバ
追加メンバー
スクラムマスター
リードプログラマー
・仕様を決める
・開発もする
アジャイル経験者
アジャイル経験者
スピーディーにアジャイル化する場合、アジャイル経験者を複数名ジョインさせる
・仕様は決めても売らう
・開発専任
- 33. © 2019 ESM, Inc.
フラット化したチームを定着させる
33
チーム内PO
開発メンバ
スクラムマスター
リード
プログラマー
開発メンバ
開発メンバ
・仕様ホルダー
・開発はしない
・開発メンバの立場で
スクラムをチームに浸
透させる
定着するには少なくとも数か月(数十スプリント)は必要
- 34. © 2019 ESM, Inc.
ウォーター・スクラム・フォール
34
時間をかけて徐々にアジャイルシフトしたほうが良い場合もある
- 35. © 2019 ESM, Inc.
経験者からのコメント
35
アジャイル初体験の
エンジニア
● スクラムが始まってから、主体的に動けるようになった
○ 自分のやるべきタスクが、今までより、よく見える
○ アサインじゃなくて、サインアップが効果的な気がする
○ 今までは、人のタスクは、どこか他人事であった
○ チームメンバーとしての活動ができている
● テスト駆動開発を本格的に取り組み始めた
○ 満たすべき要件(仕様)がはっきりわかるので、捗る
● 時間の使い方を意識するようになった
○ 今までは、「1機能三日」など、アバウトだったし、自分で見
積もったわけではなかった
○ 今は、自分で見積ることができるし、タスクの粒度が細かく
なったので、見積もりやすい