概要
2014 年度下期( 2014 年 10 月 - 2015 年 3 月 )に業務で行ったことをまとめます。
経緯
2014 年度下期の開始時点では、自チームが担当しているシステムのリプレイスに合わせて、
利用技術、ツールなどを一通り最新の構成にするための 調査・検証・選定・学習 を進めていました。
調査時は常にドキュメントを作成し、 esa.io で共有しています。
（ esa.io 利用前は Confluence や GitLab の Wiki を利用していました ）
メインで担当しているシステム以外も 細かなシステムが幾つかあり、
それらの運用・保守をしながらの対応 です。
年度の終わり際になり、他部署が抱えているシステムもちょうどリプレイスの時期であり、
技術的負債がたまってきていることや部分最適化が行われている状態になっていたため、
これを機に全体的な組織改善をする方針に移行しつつあります。
2014 年度末から現在までは組織の改善のための調査・検証・資料作成および、
それらをもとにした業務分析ミーティングが主業務 になっています。
※以降にでてくる CLI のツールなどの調査・検証は基本的に私一人ではなくチーム全員で利用するためのものです。
現状
Before
私が入社した 2013 年 5 月から 2014 年度前期にかけて
私主導で導入済みの内容が以下。
※基本的には自チームのみ導入済。
- ナレッジ共有
- GitLab, Confluence などに蓄積
- メールからチャットツールへの移行
- Kandan を導入したがいまいち使いにくい
- ChatOps の仮導入
- Kandan に Hubot を導入
- UnitTest
- 入社後、私が関わった案件については UnitTest を導入
- ブラウザ自動テスト
- 入社後、私が関わった案件については ブラウザ自動テスト を導入
- パフォーマンス自動テスト
After
これから行おうとしていること
- CI の導入
- CD の導入
- ChatOps の実運用導入
- インフラ自動化
- より使いやすいチャットサービスへの移行
- より使いやすいナレッジ管理サービスへの移行
- チームにあったタスク管理ツールの選定
- Microservices
- インフラ自動化
- システムリプレイス
- その他組織レベルでの開発体制の改善
- その他、気づいた改善はいつでも自発的に行う
2014 年 10 月
プロビジョニングツール Itamae の調査・検証
ライブラリ管理 gemfury の調査・検証
チャットツール Kandan のメンテナンス
Kandan の調査・検証・メンテナンス。
Kandan の環境は社内の VMWare vSphere 上に Vagrant + Chef で作成しました。
チャットツール Slack の導入
チャットツール Slack の調査・検証・導入・メンテナンス。
元々、有料かつクラウドのサービスは社内の稟議を通すなど障壁が高かったので、
選択肢から外していたが、Kandan の使い勝手が悪かったため、
Slack の利用の許可を取ることにした。
どうにか制限付で承認され、現在チーム内で運用中。
実際に導入してみると、 使い勝手は雲泥の差 。
もはや Kandan には戻れない。
Ruboty の Adapter がある 点もポイントが高かった。
導入後、 他サービス類との Integration の設定やチャンネルに流す RSS などの選定も担当。
ChatOps Ruboty
Kandan 利用時に Hubot を検証レベルで導入済みだったが、
Ruboty を使えば Ruby で Bot を作成できる ため乗り換え。
Ruboty 乗り換えのための調査・検証・導入・Plugin 開発を担当しました。
適用対象のシステムのリニューアル自体が進んでいないため、各種検証はしたが、
ChatOps としての実運用はまだ。
DevOps ・ インフラ 界隈の最新動向を調査
Immutable Infrastructure, Vagrant, Docker, Chef, Ansible, Puppet, Itamae などの最新動向を調査。
調査・検証の結果、 Vagrant / Docker / Itamae をメインで使う方針を決める。
（実運用時に情勢が変わっていれば変更する可能性は十二分にある）
2014 年 11 月
Ruboty Plugin 開発
Docker 調査・検証
CI / CD サービス Wercker 調査・検証
ghq の調査・導入
ghq は git のリモートリポジトリのローカル管理を楽にするツール。
Vagrant 調査・検証
新しいバージョンの機能、 VMWare Workstation 連携、 itamae 連携などを調査・検証。
2014 年 12 月
Ruboty Plugin 開発
EC2 自動化 調査・検証
esa.io 仮導入
esa.io を仮導入。
無料期間で評価使用。
この時点で、かなりの快適さを感じていた。
GitHub ・ Bitbucket の API 操作 調査・検証
各種自動化に備えて GitHub ・ Bitbucket の API 操作 調査・検証を行った。
pry の調査
Ruby で開発を行う上で、 pry を活用できれば生産性が上がると判断し、
pry について調査し、チームと情報を共有した。
Qiita - tbpgr - Ruby の 定番対話ツール pry 徹底攻略
2015 年 01 月
Ruboty Plugin 開発
Heroku 調査・検証
Git 運用ガイドライン作成
pry の調査
pry は機能が多いため、先月に引き続き。
esa.io ・ Qiita:Team ・ DocBase 比較
UI の見た目や使いやすさ。カテゴライズ機能。スライド機能など esa 独自の機能や
運営のレスポンスの良さが刺さり esa.io の利用を決定。
esa.io 導入・先導者
esa.io を本導入。
先導者としてどんどん情報を蓄える。
その他、外部連携などの設定をメンテナンスしたり、
フィードバックを送ることで、より使い易いサービスにしてもらったりする。
esa.io は、他サービスに比べ フィードバックをサービスに反映してくれる可能性が高く 、
反映までの期間も非常に早い （即日や数時間などのケースも珍しくない）ため、
積極的に フィードバックをすると得をする ことが多い。
2015 年 02 月
Ruboty Plugin 開発
Git コミットテンプレート作成
前月に決めた Git のガイドラインで、 Emoji + 定型文によるコミット種別ごとの
テンプレートを作ることになったため、テンプレートを Sublime Text の Snippet にした。
テンプレートは Web スクレイピング で、 Font-Awesome や Emoji-Cheat-Sheet から
スクリプトで生成した。
- Qiita - tbpgr - Git の Commit Template + Subliem Text 2 の Snippet でコミットメッセージの作法を統一・効率化する
- Qiita - tbpgr - Git | Emoji を利用した Git の commit フォーマットの一例
hub の調査・導入
hub は GitHub の操作を CLI から行うことができるツールです。
pry の調査
pry は機能が多いため、先月に引き続き。
Trello API 操作の調査・検証
2015 年 03 月
業務外で得た知見を社長・上長と共有
業務外の副業から得た知見や、副業の人脈から得た情報を社長と共有した。
ちなみに副業の人脈を本業につなげて 2 件受注しました。
現在 3 件目も受注予定。
業務では得られないノウハウも身に付くため、 副業は本業に活きる。
thor の調査
thor は Ruby で CLI ツールを作成する際に使う gem です。
頻繁に活用することになるのですが、 細かな機能を把握していなかったため、
一通りの機能を試して把握することにしました。
- Qiita - tbpgr - Ruby の CLI ツールの作成を支援する、 thor gem の基本について
- Qiita - tbpgr - thor gem でテンプレートを利用してファイルを生成する
コードリーディングについて調査
複数のシステムのリプレイスを控え、様々なレガシーコードを読むことになりそうなので、
コードリーディングの技法について下調べをしました。
Chart.js サンプル作成
何かとグラフ付きの資料を作成する機会が多かったため、 Chart.js を導入。
組織の改善のための調査・資料作成・ミーティング
私の所属する会社はシステム開発会社ではあるものの、
親会社のシステム部的な立ち位置の会社です。
そのため、基本的な方針については親会社の社長・役員の承認を得る必要があります。
資料の作成目的ですが、組織・技術の方向性を決定するための判断材料とするためです。
資料をまとめて社長・上長・私＋各種意思決定をするためのキーマンなどとの
ミーティングに使用しています。
- 開発手法（アジャイル、ウォーターフォール）
- 組織の戦略・戦術ストーリー
- 組織としてのプログラム言語選定
- 組織全体として見た場合のシステムの問題点分析
- 組織の業務分析
- 内製開発と外注開発に関して
- ソフトウェア開発の人材採用・人材評価に関して
まとめ
紆余曲折があり、今のところ直接の成果に結びついてはいないものの
着々と土台作りとしての調査・検証を進めることが出来ました。
一般的には開発基盤チームなどが行うような業務なのかな？
また、 3 月以降は組織改善の主メンバーに加わり、全体に関わる業務を担当するようになってきました。
技術的側面から経営に関する意思決定に加わる・・・ってプチ CTO 的な感覚ですね。
そこまで上等なものでもないですけど。
個別の開発と異なり、短いスパンでの成果が見えにくくモチベーション管理が難しいものの、
大きく物事を動かす難しさと充実感の両方を味わう毎日です。
色々と方針が固まり、実際に開発に着手するまでの間は
業務中にプログラムを書く機会がほとんど無くなっているのが残念ではありますが、
幸い弊社は基本的に残業がないため家で好きなだけプログラムを書くことが出来ます。
補足
細かくは書いてませんが、元々解決すべき問題があった上で
様々な手法、技術、ツールを導入しています。
目的と手段が入れ替わって「これを使いたい！」から新規の技術やツールを
利用しているわけではありません。
