Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
イケてない開発チームがイケてる開発を
始めようとする軌跡
WHO AM I
@renjikari
NTTコミュニケーションズ 技術開発部
新卒二年目
I ♡ Infrastructure as Code
I ♡ ISUCON
Agenda
はじめに
webアプリ開発
奮闘記
イケてる開発をしたい
目指すべきよい開発チームとは
チーム開発における懸念点
現在どうなってきたか
はじめに
この発表について
この発表は私が参加しているチームにつ
いての事例で、会社全体を代表するもの
ではありません
なぜこの発表をするのか
大企業で内製をしているような人たちもた
くさんいると思うが、その叫び声があまり
世に出ていないなとい...
はじめに
何がしたいの?
イケてる開発がしたい!!
社内システム基盤の更改というプロジェ
クトの中の1チーム
クラウド利用のための契約、provisioning
等を自動化できるwebアプリを開発
社内の人がクラウドを触るまでのリード
タイムを短くするという目的
webアプリ開発
チーム体制
内製開発
2年目2人と中堅1人 + 3人ほどwebアプリ
外のところを開発
LB+WEBAPP+DBそれぞれ2台ずつ
Python + Django
弊社システム部の変革
From 受動型、製造請負型
To 能動型、 提案開発型
マインドセットの大きな変化が必要
そしてこれが非常に難しい
なんで内製?
奮闘記(〜4月末くらい)
ざっくり時系列
開発start => 2月頭
初期リリース => 4月末
リリースまで2ヶ月半で、設計から
とにかく時間が足りず、イケてる開発
チームになるために割ける時間がなかっ
た
イケてる開発したい
初回リリースが終わって反省フェーズに
イケてるチーム開発できてないな…
もともとどんなつもり
だったっけ…
リリースサイクルの早い開発を!
Agileでユーザのフィードバックを受けて
開発に活かす!
なんかイケてる開発を!
_人人人人人人人人人_
> すっごいふわってしてる!<
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y ̄
もともとどんなつもり
だったっけ…
具体的にはやりたいことがあった
コードレビュー,テスト, CI,
など、いわゆる”イケてる”感じのこと
でも、なんでそれをするんだっけ?とい
うことがちゃんとチームに伝わってな
かった
そもそも何ができれば
ええのやろうか
目指すべき
よい開発チームとは
お客さん(エンドユーザ)の望む成果を
無駄なくスピーディに提供できる
Agileである必要はない、これが達成でき
るチームの意識や体制があればよい
チームとしてここを目指そうという提案
チーム開発における
懸念点(〜5月ころ)
チームの人が開発にフルコミットできてない
タスク(進捗)の管理が適切でない
コードレビューをしていない
testを書いていない/継続的なtestができていな
い
Primary Ownerが明確でない
どうしてできてないんだろう
時間的制約
文化的制約
この2つの観点でできてないことを見て
いきます
チームの人が開発にフルコ
ミットできてない
チームリーダもメンバーも他の主業務を抱
えている
この開発にずっと時間をとることができない
タスク(進捗)の管理が適切で
ない
進捗管理(=開発におけるコミュニケーション)
不足
[エクセルWBSガントチャート]しかない
他のチームメンバが何をやっているか(どこ
のコードを書いているか)わからない
まるでそれぞれのタスクを受託開発する...
testを書いていない/継続的
なtestができていない
アプリが”いつでも動く”ことを担保するため
に継続的なtestが必要
品質の担保ができていない
現場的な問題として、テストフェーズがとて
も大変
コードレビューをしていない
他人の書いたコードを理解していない
(まだ発生してないが)引き継ぎがうまくい
かなそう
コードの質をチームで一定に保てていない
各自勝手にdevelopにマージするみたいなフ
ローになっていてよろしくない
Primary Ownerが不明
仕様とその実装順の決定権をもっている
人を明確でない
決定できる人が決まってないと、優先度
[最大]のタスクが5個も6個もできたりする
(実話)
ある程度解決
チームの人が開発にフルコミットできてない
コードレビューをしていない
Primary Ownerが明確でない
解決してない
タスク(進捗)の管理が適切でない
testを書いていない/継続的なtestができていない
現在どうなってき...
チームの人が開発にフルコ
ミットできてない
チームの人たちの主業務として、開発を割り
当てることになった
ただし、今までやっていた仕事も同じくある
ので根本的な解決にはなってない
コードレビューは必須に
全開発にコードレビューを必須として、実際
に回り始めている
MR(Merge Request)にWIP(Work In
Progress)フローを適用してMRに実装するこ
とを書いている
また、issueを使ってタスク管...
コードレビューは必須に
一番改善して効果があったと思えるのはここ
これにより他の人が何をやっているかも一目瞭
然になりチーム開発としてのコミュニケーション
不足が補われた
Primary Ownerの役割を担
う会議
初回リリース以降、開発定例時にタスクの
優先順位を決めてもらえるようになった。
また、優先度もきっちり12345をつけてもらえ
ていて、POの役割を擬似的に担えている。
タスク(進捗)の管理が
適切でない
ガントチャート+GitlabでIssueとMRの管理を
行うことによって少し改善した。
しかし、イテレーション毎の進捗管理には
なっておらず、作業の見積もりもざっくりとし
た感じになっている
タスク(進捗)の管理が
適切でない
JIRAが使えるのでそれを使おうとしていたが、
チームメンバに定着しない
issueを使った管理は(実装に寄っていることも
あって)定着し始める
Gitlabのカンバンライクな機能を使うのはどう
かと検討中
...
testを書いていない/継続的
なtestができていない
データベースを使った操作が多く、それ
ぞれ会社的に重要なデータを利用してい
る
そのためテストデータを用意するのが非
常に大変でほんの一部しかテストが実施
できていない
まとめ
目指すべきチームの姿を共有してから
少しずつ加速した
メンバーの文化やマインドごと変えな
いといけないという実感
組織論や、稼働のかかる部分にも手を
つけてよりイケてる開発を目指したい
同志、求む
Enterpriseの海でイケてる内製開発を
してる/したいという同志がいらっしゃ
いましたらぜひご意見、ご連絡を👍
Ha terminado este documento.
Descárguela y léala sin conexión.
Próximo SlideShare
Redmine + gitlab: merge base development
Siguiente
Próximo SlideShare
Redmine + gitlab: merge base development
Siguiente
Descargar para leer sin conexión y ver en pantalla completa.

Compartir

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

Descargar para leer sin conexión

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

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

  1. 1. イケてない開発チームがイケてる開発を 始めようとする軌跡
  2. 2. WHO AM I @renjikari NTTコミュニケーションズ 技術開発部 新卒二年目 I ♡ Infrastructure as Code I ♡ ISUCON
  3. 3. Agenda はじめに webアプリ開発 奮闘記 イケてる開発をしたい 目指すべきよい開発チームとは チーム開発における懸念点 現在どうなってきたか
  4. 4. はじめに この発表について この発表は私が参加しているチームにつ いての事例で、会社全体を代表するもの ではありません なぜこの発表をするのか 大企業で内製をしているような人たちもた くさんいると思うが、その叫び声があまり 世に出ていないなという思い
  5. 5. はじめに 何がしたいの? イケてる開発がしたい!!
  6. 6. 社内システム基盤の更改というプロジェ クトの中の1チーム クラウド利用のための契約、provisioning 等を自動化できるwebアプリを開発 社内の人がクラウドを触るまでのリード タイムを短くするという目的 webアプリ開発
  7. 7. チーム体制 内製開発 2年目2人と中堅1人 + 3人ほどwebアプリ 外のところを開発 LB+WEBAPP+DBそれぞれ2台ずつ Python + Django
  8. 8. 弊社システム部の変革 From 受動型、製造請負型 To 能動型、 提案開発型 マインドセットの大きな変化が必要 そしてこれが非常に難しい なんで内製?
  9. 9. 奮闘記(〜4月末くらい) ざっくり時系列 開発start => 2月頭 初期リリース => 4月末 リリースまで2ヶ月半で、設計から とにかく時間が足りず、イケてる開発 チームになるために割ける時間がなかっ た
  10. 10. イケてる開発したい 初回リリースが終わって反省フェーズに イケてるチーム開発できてないな…
  11. 11. もともとどんなつもり だったっけ… リリースサイクルの早い開発を! Agileでユーザのフィードバックを受けて 開発に活かす! なんかイケてる開発を!
  12. 12. _人人人人人人人人人_ > すっごいふわってしてる!<  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y ̄
  13. 13. もともとどんなつもり だったっけ… 具体的にはやりたいことがあった コードレビュー,テスト, CI, など、いわゆる”イケてる”感じのこと でも、なんでそれをするんだっけ?とい うことがちゃんとチームに伝わってな かった
  14. 14. そもそも何ができれば ええのやろうか
  15. 15. 目指すべき よい開発チームとは お客さん(エンドユーザ)の望む成果を 無駄なくスピーディに提供できる Agileである必要はない、これが達成でき るチームの意識や体制があればよい チームとしてここを目指そうという提案
  16. 16. チーム開発における 懸念点(〜5月ころ) チームの人が開発にフルコミットできてない タスク(進捗)の管理が適切でない コードレビューをしていない testを書いていない/継続的なtestができていな い Primary Ownerが明確でない
  17. 17. どうしてできてないんだろう 時間的制約 文化的制約 この2つの観点でできてないことを見て いきます
  18. 18. チームの人が開発にフルコ ミットできてない チームリーダもメンバーも他の主業務を抱 えている この開発にずっと時間をとることができない
  19. 19. タスク(進捗)の管理が適切で ない 進捗管理(=開発におけるコミュニケーション) 不足 [エクセルWBSガントチャート]しかない 他のチームメンバが何をやっているか(どこ のコードを書いているか)わからない まるでそれぞれのタスクを受託開発する個 人事業主になっている
  20. 20. testを書いていない/継続的 なtestができていない アプリが”いつでも動く”ことを担保するため に継続的なtestが必要 品質の担保ができていない 現場的な問題として、テストフェーズがとて も大変
  21. 21. コードレビューをしていない 他人の書いたコードを理解していない (まだ発生してないが)引き継ぎがうまくい かなそう コードの質をチームで一定に保てていない 各自勝手にdevelopにマージするみたいなフ ローになっていてよろしくない
  22. 22. Primary Ownerが不明 仕様とその実装順の決定権をもっている 人を明確でない 決定できる人が決まってないと、優先度 [最大]のタスクが5個も6個もできたりする (実話)
  23. 23. ある程度解決 チームの人が開発にフルコミットできてない コードレビューをしていない Primary Ownerが明確でない 解決してない タスク(進捗)の管理が適切でない testを書いていない/継続的なtestができていない 現在どうなってきたか
  24. 24. チームの人が開発にフルコ ミットできてない チームの人たちの主業務として、開発を割り 当てることになった ただし、今までやっていた仕事も同じくある ので根本的な解決にはなってない
  25. 25. コードレビューは必須に 全開発にコードレビューを必須として、実際 に回り始めている MR(Merge Request)にWIP(Work In Progress)フローを適用してMRに実装するこ とを書いている また、issueを使ってタスク管理している
  26. 26. コードレビューは必須に 一番改善して効果があったと思えるのはここ これにより他の人が何をやっているかも一目瞭 然になりチーム開発としてのコミュニケーション 不足が補われた
  27. 27. Primary Ownerの役割を担 う会議 初回リリース以降、開発定例時にタスクの 優先順位を決めてもらえるようになった。 また、優先度もきっちり12345をつけてもらえ ていて、POの役割を擬似的に担えている。
  28. 28. タスク(進捗)の管理が 適切でない ガントチャート+GitlabでIssueとMRの管理を 行うことによって少し改善した。 しかし、イテレーション毎の進捗管理には なっておらず、作業の見積もりもざっくりとし た感じになっている
  29. 29. タスク(進捗)の管理が 適切でない JIRAが使えるのでそれを使おうとしていたが、 チームメンバに定着しない issueを使った管理は(実装に寄っていることも あって)定着し始める Gitlabのカンバンライクな機能を使うのはどう かと検討中 CIもgitlabにしちゃえばいいのではと思っている
  30. 30. testを書いていない/継続的 なtestができていない データベースを使った操作が多く、それ ぞれ会社的に重要なデータを利用してい る そのためテストデータを用意するのが非 常に大変でほんの一部しかテストが実施 できていない
  31. 31. まとめ 目指すべきチームの姿を共有してから 少しずつ加速した メンバーの文化やマインドごと変えな いといけないという実感 組織論や、稼働のかかる部分にも手を つけてよりイケてる開発を目指したい
  32. 32. 同志、求む Enterpriseの海でイケてる内製開発を してる/したいという同志がいらっしゃ いましたらぜひご意見、ご連絡を👍
  • MurataDaisuke

    Dec. 31, 2019
  • MichiyoChuman

    Mar. 5, 2018

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

Vistas

Total de vistas

5.378

En Slideshare

0

De embebidos

0

Número de embebidos

395

Acciones

Descargas

11

Compartidos

0

Comentarios

0

Me gusta

2

×