吉祥寺.pm7 Talk2 （2016/4/22） #kichijojipm https://kichijojipm.connpass.com/event/28818/

1. 2016/04/22 吉祥寺.pm7
@yassan168（やっさん）
技術的負債だらけのチームで
技術マネージメントしてみた

2. Who are you？
• @yassan168（やっさん）
• あらふぉー
• お家は京都。４月で単身赴任２年目突入。
• SIer→プリクラなどやってる会社に勤務
～2015/03：プリ機のソフト開発
2015/04～：プリ機に関するデータ分析
2

3. チームのメンバは、
技術に関心がありますか？
3/52

4. 技術的負債の返済は、
お済みですか？
4/52

5. 今日話すこと
新しく入ったチームが、
技術的負債でいっぱい かつ
メンバが技術に関心が無い状態で、
やった事 と そこで悩んでいる事について
5

6. 私が1年前に言われた事
データ分析エンジニアが辞めて、
誰もいなくなってしまうので、
そこを引き継ぎ、さらに、
今後、人を増やしてチーム化するので
良い感じにして欲しい。
6

7. 1年前の私の状態
• Perl？あぁ、あのラクダさんのヤツね。
• Svnなら知ってるけど、Gitの経験無し
• WindowsでVC++使って開発
• Svn/Redmine/Jenkinsなどのサーバ管理
7

8. １年前の状態
• すべてがメールベース
• ドキュメントはほぼ無い
• 最強の属人化。個人のパワーで乗り切る
• 技術に関心が無く誰も行動しない
• 暫定スクリプトが今も元気に本番稼働中
8

9. １年前の状態
• ソースには、ほぼコメント無し
• hoge.pl.(日付) 形式のソース管理
• チーム共有ライブラリをrequireして使用
9

10. これ、 に出てたやつだ！
（by 進研ゼミ）
10/52

11. こ、これはマズイ事になった
11/52

12. まず、やった事
12/52

13. なかまをさがす
1人でやるよりみんなでやった方が、
辛くない。
• インフラ担当者が運良く技術に興味が
あって話に乗ってきた！
– インフラ担当が味方だとかなり動きやすいです。
13

14. Redmineの仮導入
自分と前任者だけでもタスク管理を
Redmineに移行
• 作業内容や経過を残す為に、
作業をチケット化
– 同様の作業をする際に見直しが可能になるの
で、引き継ぎ資料の一部に出来る。
14

15. Redmineの仮導入
前任者に以下をチケット化してもらった
• 過去やった事
• 過去の障害
• データ分析でのコツ
• 各スクリプトの概要
（何が目的で、いつ動き、なにを出すのか）
15

16. Redmineの拡散
メールベースの文化をやめて、
部全体で、チケットによるタスク管理をす
るために、布教活動を開始。
16

17. Redmineの拡散
ただ、ひたすらに
「便利だよー」「こう使うと良いよー」と
利点とユースケースを説いて周り、
ちょっとだけでも使ってみないか？と、
ジワジワと広げ、無いと不便な状態を作る
17

18. イメージ図
18

19. 得られた事
• 引き継いだ情報がRedmineにすべてあるの
で後で検索が可能
• 作業をチケット化した事で、
残作業やその優先度、進捗状況が分かる
ようになった
19

20. ソース管理
スクリプトと同階層に、
r○ディレクトリがあって、
そこに、hoge.pl.r○ が沢山おいてあった。
20

21. ソース管理
共通ロジックを特定のパス
/path/to/lib/Hoge/hoge.pl に配置して、
みんなでこれを requireして使う。
21

22. あれ？今、昭和？
22/52

23. ソース管理
まず、バージョン管理システムの導入。
• Git使いたかったが、Svnしか知らなかった
ので、まずは、Svnで自分管理のソースや
ライブラリをバージョン管理化
23

24. ソース管理
ローカルsvnから始めて、
ローカルGit→GitBucketと段階を踏みながら
移行
24

25. ソース管理
やったことはRedmineと一緒。
布教活動とRedmineに導入手順などの情報
を残しつつ、ジワジワ広げる。
25

26. バージョン管理をまともに使ったことのあ
る人が私しかいないので、
バージョン管理の学習コストがデカイ。
サイクル（ ）が回せない！マズイ！
かだいがあらわれた
26

27. かだいがあらわれた
これをなんとかしないとマズイ・・・
• バージョン管理システムの概念
• Gitの使い方
27

28. かだいがあらわれた
その他にも、、、
• 固定パスのhoge.plをrequireして
使い回す程度にしかPerlを使えていない
• 温かみのあるCGI.pm
• crontabに > /dev/null がチラホラ
もっとちゃんと開発が使いたい！
28

29. よし。チーム勉強会だ。
29/52

30. べんきょうかい
メンバにヒアリングし、
下記を満たせば参加してもOKと言うことに
• 業後じゃなければOK
• テキストを買うのはイヤ
30

31. べんきょうかい
上司を以下のポイントで説得
• 技術共有の場の一環としてエンジニアだけ
のMTGを開催
• そこでたまたま輪読会をしていた
31

32. べんきょうかい
上司の立場上、他の部署などの事考えると、
業務時間内に業務以外の事をする事を
大っぴらに許可し難い。
なので、
あくまでMTGを実施していて、
その中の一部としてたまたま輪読会をしてい
たと言う体を用意。
32

33. べんきょうかい
実施サイクル
月２回：Perl
月１回：バージョン管理
33

34. 得られた事
• 現状がいかにマズイかという共通認識を
得られた
• ソースのバージョン管理への理解
• メンバ間で技術の話を共有できるように
なった
34

35. 得られた事
コーディングの話をするようになった
「ここはこう書いたほうが良いよね」
「変数名とかコーディングスタイルは合わ
せるようにしたいよね」
とか。
35

36. まとめ
36

37. 進める上で意識した事
一気に理想を求めない
• ちょっとずつで良い。
• 初めの一歩は小さくて良い。
やっていくと当たり前になるので、
そのうち回り出す。
37

38. 進める上で意識した事
上司との交渉でツール先行で話をしない
どんな課題があって、何でやるのか、
やることによるメリットを伝えたうえで、
それを解決するために○○を使いたいって
話を持っていく。
ツールはあくまでオマケ。
38

39. 振り返ってみて、、、
39

40. 振り返る
個人的には、
自分だけモダンにPerl使って、
RedmineとGitを使ってまともな仕事をする
だけでも良かった。
40

41. 振り返る
ただ、１年前の状態を続けた場合、
一緒に働くメンバは、残念な経験しか残らな
いし、その後の仕事にも影響しないか？
そもそも、
「開発って、技術って、楽しい！」
って状態で、みんなで楽しく仕事をしたい！
41

42. 得られた事
技術MTG（輪読会）
技術共有する場を設けてメンバ間で技術を
考えるきっかけを作った（はず）
Redmine、Git
現状を正しく把握＆正しく記録。
まともな開発経験が出来るようになる（はず）。
42

43. 課題
• まだまだGitを使えていない
• Redmineの使い方にメンバにより
バラ付きがある
→ 細かくケアする。
時間がなんとかしてくれるはず？
43

44. 今後に向けて
44

45. 今後に向けて
• テストが一切なく、デグレが怖いので、
テストを入れたい
• もっと気軽な共有の場として、
Chatツール導入したい（但し、政治的な理由でオンプレで）
• スキルの底上げ＆ノウハウ共有の為に、
ペアプロをやりたい
45

46. 今後に向けて
１年でガラッと変えたけど、
（本当は半年でやりたかった）
本当に、メンバは幸せなのか？
46

47. 今後に向けて
このまま進めていって良いのか？
押し付けになっていないか？
47

48. 今後に向けて
「やる事は出来てるし、仕事増やしてくれ
るなよ(´・ω・`)」
「勉強会とかいらんし仕事させて」
ってなっていないか？
• そんな人がいた（or 出てきた）場合、
どう対応していけば良いのか？
48

49. 今後に向けて
ただ、
「みんなで技術の話が出来る場が出来て良
かった」と言ってくれる人もいるので、
たぶん、大丈夫なはず（と思いたい）
49

50. 今後の事
みなさんならどうしました？
今後どうしたらよいでしょうか？
是非、教えてください！
50

51. まとめ
技術的負債だらけのチームでやった事
今を残す事
– Redmineを使ってタスク管理
– ソースのバージョン管理
技術の共有
– 技術ミーティング（輪読会）
51

52. まとめ
一気に理想を求めない
• 最初の一歩は小さくていい
上司との交渉でツール先行で話をしない
• 課題と目的、効果を中心に説明して
ツールはオマケ程度。
52

53. 以上です。
53