NTT Tech conference #2での発表資料です

1. イケてない開発チームがイケてる開発を
始めようとする軌跡

2. WHO AM I
@renjikari
NTTコミュニケーションズ 技術開発部
新卒二年目
MSPのベンチャーでアルバイトしてました
I ♡ Infrastructure as Code
I ♡ ISUCON

3. Agenda
はじめに
webアプリ開発
奮闘記
イケてる開発をしたい
目指すべきよい開発チームとは
チーム開発における懸念点
現在どうなってきたか

4. はじめに
この発表について
この発表は私が参加しているチームにつ
いての事例で、会社全体を代表するもの
ではありません
なぜこの発表をするのか
大企業で内製をしているような人たちもた
くさんいると思うが、その叫び声があまり
世に出ていないなという思い

5. はじめに
何がしたいの?
イケてる開発がしたい！！

6. 社内システム基盤の更改というプロジェ
クトの中の1チーム
クラウド利用のための契約、provisioning
等を自動化できるwebアプリを開発
社内の人がクラウドを触るまでのリード
タイムを短くするという目的
webアプリ開発

7. チーム体制
内製開発
2年目2人と中堅1人 + 3人ほどwebアプリ
外のところを開発
LB+WEBAPP+DBそれぞれ2台ずつ
Python + Django

8. 弊社システム部の変革
From 受動型、製造請負型
To 能動型、 提案開発型
マインドセットの大きな変化が必要
そしてこれが非常に難しい
なんで内製？

9. 奮闘記(〜4月末くらい)
ざっくり時系列
開発start => 2月頭
初期リリース => 4月末
リリースまで2ヶ月半で、設計から
とにかく時間が足りず、イケてる開発
チームになるために割ける時間がなかっ
た

10. イケてる開発したい
初回リリースが終わって反省フェーズに
イケてるチーム開発できてないな…

11. もともとどんなつもり
だったっけ…
リリースサイクルの早い開発を！
Agileでユーザのフィードバックを受けて
開発に活かす！
なんかイケてる開発を！

12. ＿人人人人人人人人人＿
＞ すっごいふわってしてる！＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y￣

13. もともとどんなつもり
だったっけ…
具体的にはやりたいことがあった
コードレビュー,テスト, CI,
など、いわゆる”イケてる”感じのこと
でも、なんでそれをするんだっけ?とい
うことがちゃんとチームに伝わってな
かった

14. そもそも何ができれば
ええのやろうか

15. 目指すべき
よい開発チームとは
お客さん(エンドユーザ)の望む成果を
無駄なくスピーディに提供できる
Agileである必要はない、これが達成でき
るチームの意識や体制があればよい
チームとしてここを目指そうという提案

16. チーム開発における
懸念点(〜5月ころ)
チームの人が開発にフルコミットできてない
タスク(進捗)の管理が適切でない
コードレビューをしていない
testを書いていない/継続的なtestができていな
い
Primary Ownerが明確でない

17. どうしてできてないんだろう
時間的制約
文化的制約
この2つの観点でできてないことを見て
いきます

18. チームの人が開発にフルコ
ミットできてない
チームリーダもメンバーも他の主業務を抱
えている
この開発にずっと時間をとることができない

19. タスク(進捗)の管理が適切で
ない
進捗管理(=開発におけるコミュニケーション)
不足
[エクセルWBSガントチャート]しかない
他のチームメンバが何をやっているか(どこ
のコードを書いているか)わからない
まるでそれぞれのタスクを受託開発する個
人事業主になっている

20. testを書いていない/継続的
なtestができていない
アプリが”いつでも動く”ことを担保するため
に継続的なtestが必要
品質の担保ができていない
現場的な問題として、テストフェーズがとて
も大変

21. コードレビューをしていない
他人の書いたコードを理解していない
(まだ発生してないが)引き継ぎがうまくい
かなそう
コードの質をチームで一定に保てていない
各自勝手にdevelopにマージするみたいなフ
ローになっていてよろしくない

22. Primary Ownerが不明
仕様とその実装順の決定権をもっている
人を明確でない
決定できる人が決まってないと、優先度
[最大]のタスクが5個も6個もできたりする
(実話)

23. ある程度解決
チームの人が開発にフルコミットできてない
コードレビューをしていない
Primary Ownerが明確でない
解決してない
タスク(進捗)の管理が適切でない
testを書いていない/継続的なtestができていない
現在どうなってきたか

24. チームの人が開発にフルコ
ミットできてない
チームの人たちの主業務として、開発を割り
当てることになった
ただし、今までやっていた仕事も同じくある
ので根本的な解決にはなってない

25. コードレビューは必須に
全開発にコードレビューを必須として、実際
に回り始めている
MR(Merge Request)にWIP(Work In
Progress)フローを適用してMRに実装するこ
とを書いている
また、issueを使ってタスク管理している

26. コードレビューは必須に
一番改善して効果があったと思えるのはここ
これにより他の人が何をやっているかも一目瞭
然になりチーム開発としてのコミュニケーション
不足が補われた

27. Primary Ownerの役割を担
う会議
初回リリース以降、開発定例時にタスクの
優先順位を決めてもらえるようになった。
また、優先度もきっちり12345をつけてもらえ
ていて、POの役割を擬似的に担えている。

28. タスク(進捗)の管理が
適切でない
ガントチャート+GitlabでIssueとMRの管理を
行うことによって少し改善した。
しかし、イテレーション毎の進捗管理には
なっておらず、作業の見積もりもざっくりとし
た感じになっている

29. タスク(進捗)の管理が
適切でない
JIRAが使えるのでそれを使おうとしていたが、
チームメンバに定着しない
issueを使った管理は(実装に寄っていることも
あって)定着し始める
Gitlabのカンバンライクな機能を使うのはどう
かと検討中
CIもgitlabにしちゃえばいいのではと思っている

30. testを書いていない/継続的
なtestができていない
データベースを使った操作が多く、それ
ぞれ会社的に重要なデータを利用してい
る
そのためテストデータを用意するのが非
常に大変でほんの一部しかテストが実施
できていない

31. まとめ
目指すべきチームの姿を共有してから
少しずつ加速した
メンバーの文化やマインドごと変えな
いといけないという実感
組織論や、稼働のかかる部分にも手を
つけてよりイケてる開発を目指したい

32. 同志、求む
Enterpriseの海でイケてる内製開発を
してる/したいという同志がいらっしゃ
いましたらぜひご意見、ご連絡を👍