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

# この記事について

2021年5月12日に開催された「[デジタルトランスフォーメーション(DX)時代のアジャイルマネジメントセミナー](https://easg.smartcore.jp/C22/notice_details/QVdBSE1WRmw=)」のセッションレポートです。
「[技術転換は組織変革 ～ 業務SEをモダンエンジニアチームに変える](https://easg.smartcore.jp/dxagilemanagement#pg4b)」のセッションを聞いた、まとめや感想です。

イベント・セッションの思い出しにお使いください。

# チーム参加してきました
 
[aslead Agile](https://aslead.nri.co.jp/solution/aslead_agile.html) のチーム「[オキザリス](https://speakerdeck.com/viva_tweet_x/huesudeyong-qi-wode-taxin-gui-timugashi-yan-wozao-rifan-sitejin-nizhi-rumadefalsewu-yu?slide=3)」にて参加してきました。
チーム4人中、4人で参加して、その場で実況しつつ、記事も作っています。

# 講演概要

> 内製化とモダン技術への転換は、DXの推進や組織アジリティ向上のために、マネジメントが取り組む必要がある大きな課題です。長年上流工程を担当してきたベテランを、どのようにしてコードが書けるモダンなエンジニアに転換し、さらにそれを顧客と自社の価値につなげていくのか。私の所属する永和システムマネジメントも同様の課題を抱えておりますが、組織的な取り組みを進めることで、大きな成果を上げつつあります。今回は、これら具体事例をふりかえりながら、組織変革の一環としての技術転換のあり方についてお話をさせていただきます。

# 登壇者

永和システムマネジメント  岡島 幸男様

株式会社永和システムマネジメント 取締役 CTO / [Agile Studio](https://www.agile-studio.jp/) ディレクター
Web・組込等、様々なソフトウェア開発とマネジメントの現場を経て、現在はAgile Studioにて、リモートアジャイル開発事業を担当。著書に『受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法』（技術評論社）他。

# 内容

1. 0から1の話
2. 1から10の話

# なぜ今、技術転換が必要なのか？

- 想定以上のアジャイルシフト
- 採用の難しさ

徐々に積み上げる＝技術習得
一気にジャンプする＝技術転換
↑連続性がなく難しい

# 0から1の話

## 最初の一人

最初の一人、が肝心
ラグビー日本代表の強化策における人選でも、人望の厚さなどを軸に人選

"トップダウンで始める"
トップとして、「アジャイルに向かおう」と決心。
やる気だけではなかなか技術のジャンプは難しい。
「空き時間で勉強してね」もしんどい、「ならば転職したほうがいい」という考え方も出てくる。

## ゴール

6ヶ月でJavaを利用したWeb案件で活躍できること
アジャイル開発を身につけるけと

## 進め方

すべての時間を技術移管に当てる（会社内でAgile Studioに留学）
できるだけ想起に実案件で稼働してもらう
フォローは重層的にすすめる

## フェーズ

1.5ヶ月：体験フェーズ
2.5ヶ月：実習フェーズ
3ヶ月：実践フェーズ

粋なる習得は難しいと考え、少しずつ成功体験を積み重ねてもらう作戦とした。
結果的に７ヶ月かかった。

## 本人へのヒアリング
いきなりスクラムチームに入ったら大変だったかもしれない。
T人材どころかIですらない状況ではハードルが高すぎる。
責任に潰されていた可能性もあったかもしれない。


体験フェーズ→実習フェーズ：十分な知識が身についているか
実習フェーズ→実践フェーズ：実践に臨む十分な動機づけができているか

## 体験フェーズのフォーメーション

師匠（メンター）と先生に学び、手を動かすことで知識を自分のモノにする感覚を持ってもらう。

書いたソースコードをGitHubにプッシュ／プルリクエストし師匠にレビューしてもらう。など
どんどん失敗してOK!


### 教育用コンテンツは上手に使い回す

流用と組み合わせで効率化。
定期メンテナンスとアップデートでフレッシュさを保つ。

- Git/Unixは新入社員教育依頼
- GASは技術転換社用由来
- そのほか必要に応じて適宜流用


## 実習フェーズのフォーメーション

師匠とのペアワーク。
小さいながら実務をこなす。

これまでの仕事経験と体験フェーズで得た知識を組み合わせて実務を成し遂げる。

## 実践フェーズのフォーメーション
新規開発プロジェクトをScrumでチーム開発する。

SM、伝説（的なエンジニア）、師匠、といった万全な体制

### 実践フェーズのとある一日

- DSで困ったことを共有
- ふりかえりで課題をカイゼン
- 初めて利用するフレームワークを手分けして調査

## チーム開発の教育的意義
ラーニングピラミッド
見る・聞くだけでなく、Scrumによるチームワークで教育効果が高まると期待

# チームメンバーの抱えるもやもや

## 本人

- 言われたことを実現しないと行けない
- できるか不安
- マインドが変わっていないことに気づく

## 他のチームメンバー

- 言われたからやらないといけなさそう
- 今、やっていることはあとでいいの？
etc

# 実践の厳しさ／難しさ

- 顧客に添加するわけには行かない
- 実務の一環のため、バランスのいいチームが常に組めるとは限らない
- 「何が何でも終わらせること　＞　自己の成長」　誘惑との戦い。強い責任感。

# 成果が出ない状態が続く

- カイゼンできない、フィードバック対応に追われる
- 計画通り動けない
- 優先順位付けができない
- チームとして機能していない、無意識にチームを誘導してしまう

*頭の中と行動にギャップ*

## サポートを受け学びながら前に進む

周りが諦めず関与し、徹底的にサポートする姿勢がよかった

*この経験から得たもの8

- チームの大切さ
- お客様との関係性 


# マインドセット変遷の軌跡

## 体験フェーズ、実習フェーズ

アジャイル開発をなんとなく理解
師匠に見ちびてもらう

## 実践フェーズ終盤まで

お客様の言うことは絶対として動いてしまう。
無意識に自分の考えを肯定させるようなチームファシリテート


## 実践フェーズ最終盤まで

アジャイルを実践
お客様との対話・強調を重視

**実践を通じてダブルループ学習に突入していた**

## 効果的だったプラクティス

- **モブプログラミング**
- **ふりかえり**

# 1から10の話

## 仲間が増えると学びが加速する

仲間と学ぶことによって、教えることができるようになる。

## 実践コミュニティとは

共に学ぶ社内のコミュニティ。仕事メンバーとかではない。
深山のメンバーが中核のメンバーになるにはどうしたらいいか？を考えながら勉強している。

## 知的創造のループに入り込め！

以下の知識創造のループにうまく入り込めた
①Agile Studio留学【個人】
②チームで横展開【集団】
③各現場の知見まとめ【組織】
④定着と拡大【個人】

## 無関心との闘いに勝利するために

自分たちが頑張っても、興味を持たれないことがある。
コミュニティが活発化するとアイデンティティが確立される。

## 「モダンチーム」で大切にしていること

立場で自然と決まってしまう役割分担をフラットな組織へ
コミュニケーションの範囲をPJ内から事業全体へ
失敗を恐れない組織への改革

## 組織により良い文化を広めるために

エネルギーを供給する → 組織（顧客）のために成果を
アポートシス（変換促進）→形骸化した習慣を打破する
違う遺伝子を持っている → 自分のメンタルモデルになる
一体化する → チームで事にあたる

## 技術転換を組織的に行うために

1. 技術転換は継続・拡大しないと意味がないことを知る
2. 一番期待している人を先駆者に選ぶ
3. 同じマインドを持つ小さなチームを作る
4. トップによる期待とメンターによる導きでサンドイッチする
5. 実践コミュニティとしての活動を通じてメンバーを増やす
6. メンバーが実務できるプロジェクトを確保し続ける
7. 活動を通じてより良い文化を育てることが組織変革であることを知る

## 感想


（中川）技術転換を行う際に、個人ではなくグループで行う必要があり、その際の先駆者は誰でもいいわけではないという点に関心を持ちました。組織やチームが変わった際にも同じ手法が通じるのか興味が尽きません。
（森）組織そのものの構成や、人の変革に対する考え方がないとなかなか実現できない内容だなと感じました。それでも、少しずつ文化や風土を変えていくことはできるはずなので、あきらめずに仲間と一緒に小さく続けていくことも大事なんだなと思います。
（岩崎）最初から最後まで為になる発表だったなーと思いました。単純にラーニングピラミッドとか、ダブルループ学習とか概念的に知らない部分が多い。