2016/04/22 吉祥寺 .pm7

@yassan168 （やっさん）

技術的負債だらけのチームで

技術マネージメントしてみた

Who are you ？

• @yassan168 （やっさん）

• あらふぉー

• お家は京都。４月で単身赴任２年目突入。

• SIer→ プリクラなどやってる会社に勤務

　～ 2015/03 ：プリ機のソフト開発

　 2015/04 ～：プリ機に関するデータ分析

2

チームのメンバは、

技術に関心がありますか？

3/52

技術的負債の返済は、

お済みですか？

4/52

今日話すこと

新しく入ったチームが、

技術的負債でいっぱい かつ

メンバが技術に関心が無い状態で、

やった事 と そこで悩んでいる事について

5

私が 1 年前に言われた事

データ分析エンジニアが辞めて、

誰もいなくなってしまうので、

そこを引き継ぎ、さらに、

今後、人を増やしてチーム化するので

良い感じにして欲しい。

6

1 年前の私の状態

• Perl ？あぁ、あのラクダさんのヤツね。

• Svn なら知ってるけど、 Git の経験無し

• Windows で VC++ 使って開発

• Svn/Redmine/Jenkins などのサーバ管理

7

１年前の状態

• すべてがメールベース

• ドキュメントはほぼ無い

• 最強の属人化。個人のパワーで乗り切る

• 技術に関心が無く誰も行動しない

• 暫定スクリプトが今も元気に本番稼働中

8

１年前の状態

• ソースには、ほぼコメント無し

• hoge.pl.( 日付 ) 形式のソース管理

• チーム共有ライブラリを require して使

用

9

これ、　　　に出てたやつ

だ！（ by 進研ゼミ）

10/52

こ、これはマズイ事になった

11/52

まず、やった事

12/52

なかまをさがす

1 人でやるよりみんなでやった方が、

辛くない。

• インフラ担当者が運良く技術に興味が

あって話に乗ってきた！

– インフラ担当が味方だとかなり動きやすいです。

13

Redmine の仮導入

自分と前任者だけでもタスク管理を Redmineに移行

• 作業内容や経過を残す為に、

作業をチケット化

–同様の作業をする際に見直しが可能になるので、

引き継ぎ資料の一部に出来る。

14

Redmine の仮導入

前任者に以下をチケット化してもらった

• 過去やった事

• 過去の障害

• データ分析でのコツ

• 各スクリプトの概要

（何が目的で、いつ動き、なにを出すのか）15

Redmine の拡散

メールベースの文化をやめて、

部全体で、チケットによるタスク管理をす

るために、布教活動を開始。

16

Redmine の拡散

ただ、ひたすらに

「便利だよー」「こう使うと良いよー」と

利点とユースケースを説いて周り、

ちょっとだけでも使ってみないか？と、

ジワジワと広げ、無いと不便な状態を作る

17

イメージ図

18

得られた事

• 引き継いだ情報が Redmine にすべてあ

るので後で検索が可能

• 作業をチケット化した事で、

残作業やその優先度、進捗状況が分かる

ようになった

19

ソース管理

スクリプトと同階層に、

r○ ディレクトリがあって、

そこに、 hoge.pl.r○ が沢山おいてあった。

20

ソース管理

共通ロジックを特定のパス

/path/to/lib/Hoge/hoge.pl に配置して、

みんなでこれを require して使う。

21

あれ？今、昭和？

22/52

ソース管理

まず、バージョン管理システムの導入。

• Git 使いたかったが、 Svn しか知らな

かったので、まずは、 Svn で自分管理の

ソースやライブラリをバージョン管理化

23

ソース管理

ローカル svn から始めて、

ローカル Git→GitBucket と段階を踏みな

がら移行

24

ソース管理

やったことは Redmine と一緒。

布教活動と Redmine に導入手順などの情

報を残しつつ、ジワジワ広げる。

25

バージョン管理をまともに使ったことのあ

る人が私しかいないので、

バージョン管理の学習コストがデカイ。

サイクル（　　　）が回せない！マズイ！

かだいがあらわれた

26

かだいがあらわれた

これをなんとかしないとマズイ・・・

• バージョン管理システムの概念

• Git の使い方

27

かだいがあらわれた

その他にも、、、

• 固定パスの hoge.pl を require して

使い回す程度にしか Perl を使えていない

• 温かみのある CGI.pm

• crontab に > /dev/null がチラホラ

もっとちゃんと開発が使いたい！ 28

よし。チーム勉強会だ。

29/52

べんきょうかい

メンバにヒアリングし、

下記を満たせば参加しても OK と言うこと

に

• 業後じゃなければ OK

• テキストを買うのはイヤ

30

べんきょうかい

上司を以下のポイントで説得

• 技術共有の場の一環としてエンジニアだけ

の MTG を開催

• そこでたまたま輪読会をしていた

31

べんきょうかい

上司の立場上、他の部署などの事考えると、

業務時間内に業務以外の事をする事を

大っぴらに許可し難い。

なので、

あくまで MTG を実施していて、

その中の一部としてたまたま輪読会をしてい

たと言う体を用意。 32

べんきょうかい

実施サイクル

月２回： Perl月１回：バージョン管理

33

得られた事

• 現状がいかにマズイかという共通認識を

得られた

• ソースのバージョン管理への理解

• メンバ間で技術の話を共有できるように

なった

34

得られた事

コーディングの話をするようになった

「ここはこう書いたほうが良いよね」

「変数名とかコーディングスタイルは合わ

せるようにしたいよね」

とか。

35

まとめ

36

進める上で意識した事

一気に理想を求めない

• ちょっとずつで良い。

• 初めの一歩は小さくて良い。

やっていくと当たり前になるので、

そのうち回り出す。

37

進める上で意識した事

上司との交渉でツール先行で話をしない

どんな課題があって、何でやるのか、

やることによるメリットを伝えたうえで、

それを解決するために○○を使いたいって

話を持っていく。

ツールはあくまでオマケ。38

振り返ってみて、、、

39

振り返る

個人的には、

自分だけモダンに Perl 使って、

Redmine と Git を使ってまともな仕事を

するだけでも良かった。

40

振り返る

ただ、１年前の状態を続けた場合、

一緒に働くメンバは、残念な経験しか残らな

いし、その後の仕事にも影響しないか？

そもそも、

「開発って、技術って、楽しい！」

って状態で、みんなで楽しく仕事をしたい！

41

得られた事

技術 MTG （輪読会）

技術共有する場を設けてメンバ間で技術を

考えるきっかけを作った（はず）

Redmine 、 Git現状を正しく把握＆正しく記録。

まともな開発経験が出来るようになる（はず）。42

課題

• まだまだ Git を使えていない

• Redmine の使い方にメンバにより

バラ付きがある

→ 細かくケアする。

時間がなんとかしてくれるはず？

43

今後に向けて

44

今後に向けて

• テストが一切なく、デグレが怖いので、

テストを入れたい

• もっと気軽な共有の場として、

Chat ツール導入したい（但し、政治的な理由でオンプレで）

• スキルの底上げ＆ノウハウ共有の為に、

ペアプロをやりたい45

今後に向けて

１年でガラッと変えたけど、

（本当は半年でやりたかった）

本当に、メンバは幸せなのか？

46

今後に向けて

このまま進めていって良いのか？

押し付けになっていないか？

47

今後に向けて

「やる事は出来てるし、仕事増やしてくれ

るなよ (´・ω・ `)」

「勉強会とかいらんし仕事させて」

ってなっていないか？

• そんな人がいた（ or 出てきた）場合、

どう対応していけば良いのか？48

今後に向けて

ただ、

「みんなで技術の話が出来る場が出来て良

かった」と言ってくれる人もいるので、

たぶん、大丈夫なはず（と思いたい）

49

今後の事

みなさんならどうしました？

今後どうしたらよいでしょうか？

是非、教えてください！

50

まとめ

技術的負債だらけのチームでやった事

今を残す事

– Redmine を使ってタスク管理

–ソースのバージョン管理

技術の共有

–技術ミーティング（輪読会）51

まとめ

一気に理想を求めない

• 最初の一歩は小さくていい

上司との交渉でツール先行で話をしない

• 課題と目的、効果を中心に説明して

ツールはオマケ程度。

52

以上です。

53