Upcoming SlideShare
Kichijoji pm7[talk2]技術的負債だらけのチームで技術マネージメントしてみた
- 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
Be the first to comment