# 2022統括mtg #20

| 日付　　 | 2022/1/10 |
| ------- | ---------------------------------- |
| 開始時刻 | 21:00 |
| 終了時刻 | |
| 場所　　 | Zoom |
| 参加人数 | 人 |
| 参加者　 | 武田、大鐘、阿部、樋口、中井、西川 |

## PMからの意見など
- 樋口さんの意見
- (武田)確かにTOBEは具体的であるべきだった
- 松本さんの意見
- エンジニアに主体性がないのでエンジニア自らタスクを切り分けることが難しい。ICEのような体制のほうが望ましいのでは
- (武田)持続的に出来るならそれで良いが、TLがいつまでも残っているわけではない
- (中井)ICEは開発体制が異なり、期限がないのであまり参考にならない。追加開発もキャッチアップしやすく、LIMEは開発難易度が高い
- (中井)見習うべきは理社アプリ。tobeの姿として同様の開発方式になることが理想
- (樋口)ICEの育成について、はじめの一歩としては良いと思う
- (中井)一番の問題は、開発の速度が早くて振られたチケットをこなしているうちに開発が進んでしまうこと。一部のエンジニアを除いて保守に徹するか
- (樋口)以前話にでたITサポートは開発力向上の面では微妙
- (武田)話がそれたが、このバイトに来ている人は有名難関大のひと。頑張る素養はあるはずだが、そのベクトルが開発に向いていないのか？だから良い環境を用意してもコミットが少ない。
- (樋口)毎回0ベースになる&積み重ねが必要なことがITチームの特徴
- cf. 科目チームの統括は特別なスキルが必要な訳では無い。熱意や責任感で成り立つ
- →達成感を感じにくい
- タスクを切るタイミングをmtgで行いたい
- (大鐘)理社アプリのキックオフもそうだった。ITチームにうまく入れても良いのでは
- (樋口)出来る人にとってはチケット制のほうがやりやすいが、なれていない人のドロップアウト率を下げるためにはmtgをやっても
- (中井)振り分けアプリで導入すると、テストコードをずっと書いているような人が出る。導入するとしたらマイペースに開発できるタスクに限られる。チケット制はコーディング力がある人のことを考えての導入
- (阿部)mtgによる進捗管理は開発速度が異なるメンバーでは成り立たない。理社アプリは期限が決められたタスクに同程度のoutputを出せたから出来た
- (武田)慣れていない人の育成＋レベルの高い人に合わせたチケット制は若干matchしていない
- (中井)チケットに移行したタイミングでの議論：今年度前半は育成を重視したが中途半端な結果になり、プロダクトをリリースできなかった。
- (武田)育成と開発をどう両立するか
- (中井)前半の開発での問題点は、集中的に進めるpjを選定して主にmtgで進める形。結果としては最初の方で脱落＋TLなら数日で出来ることを2ヶ月かけて開発する。科目よりITチームのことを重視した。ある程度は成長した方もいたが、離脱。メンバーからは達成感がなく受動的になっている
- (樋口)タスクが上から降りてきていて、かつブレイクアウトルームも知らない相手なのでグダる
- (武田)完全フルリモートの弊害ですね。対面コーディングはどうだったか？
- (中井)作業効率は上がらないが、帰属意識はあがった
- (阿部)もともと稼働率が高い方が来た
- スプリントプランニング/スクラムについて
- (中井)管理コストが生じていることから、その負担を減らしたかった。だんだんスクラムの導入が目的になってきた。開発が偏ると、チケットを登録しなくなるがその頃から開発が早まった
- (武田)概念自体は良かったが開発者側の働き方としては厳しいものが合った
- (中井)科目との連携はよく取れている。PMの恩恵か
- (阿部)プロダクトのアウトプットもこれまで以上にできている。育成やドロップアウトの阻止は出来ていない部分。そもそも新規開発はTLレベルでないと無理なのでは
- (阿部)開発：育成＝8:2ならうまくいくが、現状は1:9くらい。タスクもそこまでふれない
- (中井)itサポートが出たのもこの経緯から
- (中井)今の話はitサポートを設けるのではなく保守に回ること
- (武田)それを楽しめるか？
- (樋口)ステップアップはありつつも適正なレベルを振り分けるしか無い
- (阿部)今後リクルートした方全員をitサポートに回してもwebエンジニアとしての経験を積めない
- (中井)やる気あるといって入ってきているのも微妙。継続する条件が欲しい
- (阿部)理想像としてはやる気のある方で、自分からキャッチアップし開発に移行できる形
- (阿部)雰囲気として当たり前に開発をみんながする形にしたい
- (樋口)適切にタスクを割り振ることができれば解決するのか？
- (阿部)自主性は微妙だが継続はしてくれそう
- (樋口)ある程度はPMが管理できているが、浮いている人をどうするか？
- (阿部)個人chやメンター制度は作ったが、自主性は必要
- (中井)話を戻して…今はitサポートor保守の二択。ここで話していたのはタスクを割り振る話なので後者。
- (阿部)研修資料による育成の話はなくなった？
- (中井)研修資料で出来る人はそれで良いが…
- (阿部)できれば育成は研修資料で完結させたい。出来る人で集めたい
- (中井)リクルートでそこまで考えるのは難しい。
- (武田)現状のリクルートは未経験に近い人しか入ってこない。こういった方の育成モデルを考えておくことが大事。初心者しか入ってこない前提ならどう活用するか。あるいは中程度の経験者を入れられるなら初心者にプレッシャーをかけられる
- (阿部)ITチームのメンバーによる友人紹介は科目を経由せずリクルート可能
- (中井)リファラルを主軸に置くのは良くない。AIもそれで崩壊気味
- (樋口)育成を考えると、知識の重要度に差がある(バックエンド、フロントエンド…)
- (武田)全体像が見えていると就職や意識の面で良いのでは
- (樋口)成長のモデルを考えるということ？
- (武田)そうです。これを知らずにバイトをやるのはもったいないと思う
- (樋口)ITで考えると、バック・フロントがある？
- (武田)あとはインフラとか
- (武田)人のモチベートをすることが目的
- 給与、就職、経験などetc

## 終着点
- TL層はLIME開発を進める(継続)
- メンバー選定は未確定
- それ以外をどうするか＋どうやってコミットしてもらうか
- 流入
- 未経験者(0)
- リファラル(1以上)
- 継続性はないので組織構築ではなく開発力強化が主目的に
- 育成
- 戦略案
- 育成モデルを思考
- 要素
- 動機付け
- 技術
- 研修
- 普段の開発
- 振るタスク
- (統括などの)エンジニア+PM数名で人事部を作る
- エンジニアは主体性のある人
- エンジニアは統括の指名制
- 採用育成周りを主体的に動く部門
- メンバー
- 樋口(翔)
- PMの希望者
- 長谷
- 瀬尾
- (しばらくは)統括全員

# 2022統括mtg #19

| 日付　　 | 2022/12/29 |
| ------- | ---------------------------------- |
| 開始時刻 | 10:00 |
| 終了時刻 | |
| 場所　　 | Zoom |
| 参加人数 | 人 |
| 参加者　 | 武田、大鐘、阿部、石本、中井、西川 |

## 求める人材の定義

- 長谷さん瀬尾さんレベル(スキルレベル2)がいれば開発が促進される
- 中井さん阿部さんは3-4
- レベルを上げることをやっていきたい
- 瀬尾さん長谷さんはある程度の勤務時間をもってコミットしている
- 他の方は育つ前に離脱してしまった

## 人材育成のステップ

1. リクルート
* いかに成長意欲のある人財を取れるか
2. 研修・育成
* 技術
* マインド
* エンジニアリングの楽しさを体感、それを活かしていきたいと思うように
* 人(出来るエンジニア)とかかわることで、自分も出来るようになりたいと思うように
3. コミットメント
* 技術を実際に東進のプロダクトに活かす
* プロダクトの開発を通じてよりレベルを上げていく
* ある程度の稼働量を確保できるように
* 時間を東進の開発に使いたいと思うようになることが大事
* 業務を通して得られるものによって

### Asis

スーパーエンジニアに業務集中
育成ができていない
人が増えてマネジメントコストが上がっているにもかかわらず成り上がっているイメージを持てない
TLmtgはもう二人しか残っていない
成果物の開発に関わるのがハードルの高いことになっている
すごい簡単なタスクを一ヶ月かけてやる、みたいなことが自然になっている
ITteamの平均に合わせてしまうと勉強するという感覚になれない。キャッチアップしてやろうという気持ちになる

#### みなさんが最初頑張れたのはなぜ？難しいものに挑戦できるのは？

- 阿部
- 最初の管理POSのPMになって自分がやらざるを得ない環境になった
- 中井さんからキャッチアップして技術力を上げていった。
- 現実的にできる範囲だと思えた。自分で続けたら自然とできることが増えていった。
- いきなり難しいデザインパターンは考えられないので、簡単なwebアプリケーションから始めて、だんだんレベルを上げていった。
- 中井
- 添削マクロが初めてのプログラミング。
- web系の知識をつけたのは小泉さんから振り分けアプリを引き継いだから
- 添削webアプリも二年前くらいに始めていた。
- ITteam入ってから本とか読んだり勝倉さんとTAKOS開発したりして学んだことも多かった。
- 添削マクロを1からpythonで書こうという話だったし期限も決まっていなくてダラダラできた。自分自身添削やっていたのでモチベーションも維持しつつ。
- なぜ乗り越えられたか？→GUIの前提(LibreOffice)があって、やりたいことを実装しやすい環境だった

### ToBe

高度な育成機関になる

### GAP

- 属人的な開発体制
- 一部のエンジニアだけでプロダクトのアウトプットを出している
- その人たちが時間が取れなくなったら何もリリースできなくなる
- 育成基盤が整っていない
- 前向きに業務に取り組む人が少ない
- 参入障壁が高くキャッチアップのモチベーションが続かない
- 文法を勉強してからアウトプットまでの間に求められる知識が少ないほどモチベーションは続きやすい
- 管理側の目が行き届かない
- 半人前未満の人をトップレベルのTLが見る必要はない
- ①半人前未満→半人前と②半人前→TLは別レイヤー

### 提案

①の人と②の人で開発内容を分けるべき

- ①の人 → (1)一時的な保守の必要ない成果物
- 科目に求められる
- ②の人 → (2)プラットフォーム
- ITチームとしてこれまで重視してきた

- 質問
- ①の人にもLIME側でできる課題は作れるんじゃないか
- 現状トライしている部分
- (1)を作るのもITチームとしてやっていくのもアリじゃないか
- 現状の問題 : 全て完全状態に持っていこうとする傾向があり (未アップbotを整理したいからadposを作って...etc) 、その結果開発が高度化
- プラットフォーム以外の成果が認められない状況が現状ある
- もっと高レベルの開発をしたい人がプラットフォーム開発に移行する選択肢がある

### 結論

* 戦略
* メンバーが勝手に勉強したくなる/自身で技術を吸収する環境を作る
* メンバーがモチベーションを維持しやすい環境を作る
* 戦術 (how)
* ①半人前未満→半人前と②半人前→一人前は別レイヤーで考える
* ① ITサポート
* 運用 : PMや半人前エンジニアのサポート
*
* 開発 : 参入障壁の低い (=早いうちから主体的な開発をできる) 課題に取り組んでもらう
* 施策
* 科目チームの保守しているtmpプログラムの開発に関わってもらう (プログラム統括みたいな動き方)
* 個人開発よりになる (ex: 科目とやり取り → 未アップbotにこういう課題 → ここを修正しよう)
* 懸念 : ITとしてプラットフォームを開発したいという方向性とは逆を向いてしまう
* 対策 : この開発内容がtmpであり、抽象化・恒久化によってプラットフォームに落とし込むことが必要であるという認識を共有する
* ② LIMEプラットフォーム開発エンジニア
* 現状のLIMEチケットベースのアプローチである程度解決できている (ex: 瀬尾さん長谷さんのallocation-appの例)
* チケット切り分けについて知見が少ないので、ここは考えていく必要がある

---

議事録v1 https://docs.google.com/document/d/1GoR5KWCvJtaYeArYceah4Lgh9YNNg1Wfuda0u2HwGEA/edit