Tbpgr Blog

Employee Experience Engineer tbpgr（てぃーびー） のブログ

2014年振り返り

振り返り 雑記

概要

2014年 を振り返って

お題

  • 仕事
  • CodeIQ
  • GitHub
  • 個人学習

仕事

コンテキスト

業務に関する詳細やドメインについては話せないのですが、

という立ち位置で仕事をしています。

自社（グループ）向けの Web システム ( Rails ) の開発が主業務です。
ちなみに、入社以降下記に挙げたような突発的な受注が続きまだ Rails のシステムには関わっていません。

自社の本業の関係でお客様に必要なシステムの開発を突発的に受託したりすることもあります。
条件は様々なので、出された条件でシステムを構築します。
C# だったり、 PHP だったり、 Java だったり、 Perl だったり。

こういったプロジェクトは本業の受注を支えるサービス的な意味合いが強いので利益とはあまり関係なく
緩い期間と緩い予算で行われることが多く、割と柔軟に納期やスコープを変更できます。
荒ぶる四天王（時間・予算・品質・スコープ）が荒ぶらない現場です。

2013年 から 2014年の状況

私は 2013年 の 5月に入社したのですが、突発的な受注が続き Java や PHP や C# のシステムの構築・保守を行っていました。
当時のチームは 4 人。

  • A さん
    • リーダー（私の直属の上長）
  • B さん
    • Rails システムの保守担当者 1 名
  • C さん
    • 色々なプロジェクトの実装などを担当するプログラマ 1名
  • 私

という体制。

私が入社し、 リーダーは外向けの営業やプロジェクト・マネジメントなど 1 レイヤー上の業務の比率を増やす。
私がシステム全体の設計開発や開発基盤の構築などを主に担当。
他の 2 名はあまり変わらない立ち位置で。
といった想定です。
人数が少ないので、結局全員がほとんどのことをやる機会があるのですが。

現場の特徴として

  • 新しいことへの挑戦推奨。導入に至らなくても、学習自体に価値がある
  • 自発的な改善、改良は自分の判断でどんどん行う
  • 変化を恐れない。途中方向を誤っていたら迷わず捨てる

というような、感じ。

2014年になると同時に C さんが退職。

C さんはどちらかというと、決まり決まった業務を定形で地道に実装するようなタイプの
現場にあった人だったので、今のチームの特徴が耐えられなかったのかな、と思う。
決められた仕様のものを、最低限の品質で、手早く実装する能力については長けていた。

これは、スキルのミスマッチであって C さんに対する個人批判ではないのだけど、

  • プログラムの品質が低い
  • 暗黙知が多い

など、負債を増やしていく傾向があって、これはチームとしての効率化の壁になっていた。
結局、仕組みを作っても手を動かす人間が負債を作り続けていてはチーム全体として改善されない状況だった。
（もちろん、アドバイス・指導などは行った上で。結局のところ、最終的には本人が自発的に学習しなければ改善しないですし）

そういった経緯もあり、 C さんの退職はお互いにとっては幸せだったようで、 C さん退職を機に状況は一変。
チーム全体の開発フロー、開発基盤の変更による改善への障壁がなくなった。
そして 2014 年へ

2014年

さて、障壁もなくなったということで心置きなく・徹底的に改善しました。
以下の様な点を私主導で改善中。

最新の手法ばっかりありますが、現状の問題を踏まえた上での導入です。

  • メールベースの連絡から Chat ベースへ
    • Kandan 試行 => 不採用
    • Slack 試行 => 採用
    • チームの人数は少ないが、上長がリモートワークをする機会も多く、そういったケースにも便利
  • 暗黙知を可視化
    • ナレッジ共有環境の選定
      • Confluence を試す => 不採用
      • GitLab の Wiki を試す => 不採用
      • Qiita::Team を試す => 不採用
      • Qiita
        • オープンにして良い内容は私が個人アカウントから投稿
      • esa.io を試す => 採用
        • カテゴライズの機能が Qiita::Team より使いやすいのが決め手で esa.io を選択
    • ナレッジの共有
      • まずは率先して自分が可視化
        • 運用に関する情報を可視化
        • 業務で使った技術情報を可視化
        • Ruby やその他の技術関連情報について共有したいものを Slack で管理
          • 自分が以下の様な情報を個別に周知
            • 技術ブログ
            • podcast
            • 技術イベント情報
            • 業務で利用している技術のリリース情報など
          • 有益情報を Slack / Feed 連携で流す
  • 仮想化とインフラのコード化
    • AWS は元々利用していたが、 txt ファイルのメモを見ながらの手動作業だった
    • Vagrant 試行 => 採用
    • Chef 試行
    • Itamae 試行 => 採用
    • Docker 試行 => 採用
    • 今後作成するシステムは、 EC2 上に イミューターブル に デプロイ できるようにする予定
  • メール と Excel による課題管理からの脱却
    • JIRA 試行 => 不採用
    • GitLab Issue 試行 => 不採用（ 予算が決まるまで GitHub の代用として使っていた ）
    • GitHub Issue 試行 => 採用
    • Trello 試行 => 採用
      • 雑多なタスクについては Trello で管理
  • chatops の導入
    • Hubot 試行 => 不採用
    • Ruboty 試行 => 採用
      • チームが Ruby に習熟しているため Ruboty を選んだ
    • 今後の Rails システム周りのデプロイなど、 Ruboty 経由で行う予定
  • git リポジトリの管理方法決定
    • Unfuddle => 元々利用していたが廃止
    • Stash => 元々利用していたが廃止
    • GitLab 試行 => 不採用 ( 予算が決まるまで GitHub の代用として使っていた )
    • GitHub 試行 => 採用 ( 主要プロジェクト用 )
    • BitBucket 試行 => 採用( ツールなど雑多なプロジェクト用 )
  • GViz の導入
    • 有向グラフで図解出来そうなものが合った場合に利用
    • GUI のツールに比べて表現は制限されるが生産性が高く、プレーンテキストのため履歴管理が便利
  • Reveal.js の導入
    • 内外のプレゼン向けに Reveal.js を採用
    • GUI のツールに比べて表現は制限されるが生産性が高く、プレーンテキストのため履歴管理が便利
    • Markdown で簡単に書ける
  • Markdown の導入
    • Wiki なども含め、技術文書作成の標準は決まって居なかったが Markdown を主軸に置くことに決定
  • Private な gem のサーバー管理
    • geminabox 試行 => 不採用
    • gemfury 試行 => 採用
      • 外部サービスを選んで保守の手間を減らすことが目的でこちらを採用
  • 自動化可能なシステムを自動化して保守対象から外す
    • 他部署から依頼されて手動で担当者と連携しながら保守していたシステムを自動化して受け渡し
      • 緊急時のみ連絡してもらうことに( 受け渡し後の連絡なし )
      • 細切れで使っていた、割り込みがなくなり作業に集中できる時間を増やした
  • 社内の使いにくい勤怠システムなどの自動化
    • 外部の会社が提供しているシステムで、システム自体は改修できない
      • ブラウザオートメーションで自動化
  • GoogleDrive を利用したお客様との課題管理の変更状況監視を自動化
    • API 経由で ファイル内容をチェックして変更内容を検出。内容に応じてメールを生成して送信
  • PDF から Wiki への変換を自動化
    • 大半を手動で行う予定だった PDF ファイルの内容を Wiki に変換する業務を自動化

ほとんど残業してない。 1 日 8 時間勤務でもこのぐらいできるもんですね。
チーム全体が、新しいものへの学習に慣れているので移行コストをあまり考えなくていいのが楽。

その他、改善以外になぜか営業も。

個人的な学習の過程で、色々と人脈が増えて、その人脈と話していると自社の本業で巻き取れる内容があったため、提案。
結果として、 2件受注しました。
実務担当に引き渡し済みですが、うまく行けばどちらも継続案件。

あとは、はじめて 技術カンファレンスに出席しました。

業務として RubyKaigi 2014 に参加。
色々と貴重な話を「目の前」で聞けて、刺激をうけました。
また、いくつかの技術については持ち帰りで社内で役に立ち実益も兼ねました。

synvert とか、たまたま上長が実装していたプログラムの役にたちましたし、
geminabox は採用にはいたらなかったものの導入してみましたし。
また、他社が実際に運用に使っている構成や悩みどころを知ることができたのも大きかった。
自社で、課題を解決するために「これを解決するためには、これをやろう」など、
考えたり実施してきたことが、他の Ruby の最先端を進んでいる方たちと同じ方向を
向いていることも確認できた。

人見知りを発動して誰とも話さなかったという点を除けば最高のカンファレンスでした。

CodeIQ

2013年12月より出題を開始。
CodeIQ 漬けな 1年でした。

苦戦の序盤

序盤は、挑戦者数も伸びず、試行錯誤を続ける。
問題自体に関するツッコミなども複数いただき、改善を続ける。

Emmet 問題でブレイク？

Emmet Golf 問題で初めて 100名 + 74名に挑戦していただく。
その間、挑戦者が少なかった問題に関しても丁寧なフィードバックをしていた甲斐があってか、
必ず私の問題に挑戦してくださる挑戦者さんが増えてきた。

デスコロ登場

そして、「デスマコロシアム」のシリーズ化。

影の功労者

このころ、甥っ子と雑談していたら CodeIQ をやっていることを知り、回答者視点でアドバイスを聞く。
とりあえず、出題者アイコンがイケてないので外注しなよ、と言われたので外注することに。
結果が、今のアイコンです。
人に教えを請うのに年下とか全然関係ない。
ありがとう甥っ子。

おせっかいな出題者

運営担当者さんに

  • 出題者・運営向けのワークフロー改善案
  • ツイッターなどで見かけた解答者の意見を運営に報告
  • CodeIQ のサービス自体に関する提案

など、定期的に行う。

出題者としてオファーを受けただけなので、運営自体の改善や最終的なユーザーである
挑戦者の皆様や採用企業の皆様のことまで考える必要は無いのかもしれないのだけど、

何のために出題しているのか？
CodeIQ というサービスは何のためにあるのか？

ということを考えたら無視できない要素なわけで。

また、自分は解答者としても CodeIQ を利用しているので、双方の視点で運営のお役に立てるかな？と思っている。

全てが実現されるわけではないけど、少なくない数の提案を受け入れたり
企画を実現していただきました。

運営に対して「融通が効かなそう」というイメージを持っている方もいるかもしれませんが、
そんなことは無いんですよ。

CodeIQ MAGAZINE

Web MAGAZINE の寄稿を初体験。

最初に寄稿した

が、いきなりランク入り。

副題に言語の情報が強めに押されてるのは出題タイミングや出題カテゴリなどもあり
意図的なものがあったり。お察しください。
可読性を意識しているのは Ruby だけじゃないだろ！みたいな意見もありましたが
ホントその通りだと思います。
その辺の反応は予測出来たので自分的には控えたかった（苦笑
この記事がずーっと CodeIQ MAGAZINE の週間ランキングに居残り続けてます。
読んで頂いてありがとうございます。

その他、各種問題の結果記事を定期的に書いたり、
たまに特定テーマの技術記事を寄稿させてもらいました。

記事のリストについては、 Tbpgr Personal Page を参照。

今に至る

  • デスマコロシアム
  • 新規分野
  • 変な問題

という芸風を確立。

GitHub

草

こんな感じ

f:id:tbpg:20141231214245p:plain

中身

実際のところは、 ruby のサンプルコードを書いただけとか rubocop の警告を直しただけという日が多いので
偽物の草原だったりします。毎日プログラムを書いているのは間違いありませんが。

自分の作業を効率化するための gem は大量に作成しました。
また、 typo や ちょっとした修正レベルではありますが、色んな OSS へ Pull Request を送り Merge してもらいました。

  • Kandan
  • did_you_mean gem
  • gitlab
  • Rails Guilde
  • Wercker のドキュメント
  • るりまのドキュメント

など。 Pull Request 自体今年が初めてだったのでよくやったほうかなと思います。

オープンソース開発 | はじめてのPull Request結果報告

個人学習

アウトプット

新たに学んだことはほぼすべてアウトプットしてあります。

  • 2014年1月 - 6月は はてなブログ （当時はダイアリーでしたが移行しました）
  • 2014年6月 - は Qiita

副産物

CodeIQ も、元はといえば私がブログに大量にアウトプットをしていたことがきっかけなのですが、
別件でもう1案件お声がけいただきました。
こちらはラウンチ前なので詳細をお話出来ないのですが、

この話が縁で、前述の自社の受注につながりました。
趣味が実務の売上になっているという。

今年辺りに動き出すと思うので、私の手元にはさらに定期タスクが増えることに。
さらなる効率化と取捨選択が必要になります。

2015年に向けて

個人やチームレベルで役に立つ、生産性を高めるものを作るスキルは大分上がってきました。
様々な OSS プロダクトのソースコードも読んだので少しずつレイヤーを登ることができているかな、と思います。

2015年はより多くの人の役にたつプロダクトを一人で（もしくは、必要な協力者を自分で判断して巻き込んで）作れるように
階段を登って行きたいと思っています。

その他は、2014年の内容で十分すぎるほどうまくいっているので、
現状にあぐらをかかずに、引き続き改善を続けます。

PS

個人の振り返りとは関係ないけど、 デスマな現場で疲弊している人へ。
定時勤務でこれくらいの成果を挙げることが出来ました。

逆に私の転職前は、毎月 250 - 300 時間労働をしていましたが、
年間とおしてやったことといえば

  • BTS のボタンを押す
  • アサインを振り分ける
  • 管理用の Excel を編集する
  • 会議にでる
  • 手が回らない人の実装を手伝う
  • ナイショで勝手に自動化する

くらいです。
毎月 250 時間以上 1年間働いた内容が 6行で済んでしまいました。

技術に明るくて、技術が好きで、もっと生産的な仕事をしたい方は
迷いなく転職した方がいいと思います。