kentana20 技忘録

技術ネタを中心に、セミナー、勉強会、書籍、会社での出来事を綴っていきます。不定期更新。

モダンな現場にするために

現場 github

このエントリーは『DevLOVE Advent Calendar 2013 「現場」』の63日目？の記事です。
Doorkeeperからのメールに反応して、勢いで急遽参加させていただくことになりました。
chachakiさん、いきなりのご連絡にも関わらず快く応じていただき、ありがとうございます。

●自己紹介

はじめまして、kentana20と申します。Twitterも「@kentana20」でやってます。
株式会社一休という会社で自社サービスの開発・運用を行っています。
普段は追加開発のプロジェクトでPMやPL的な管理業務を行いながら、
運用業務や運用改善などにも携わり忙しくも楽しい毎日を過ごしています。
社外勉強会には積極的に参加するようにしていますが、コミュニティには所属しておらず
最近はどこかのコミュニティに深く関わりたいと考えるようになってきました。

●一休という会社

外部の勉強会などに同僚が参加したり、話したりしているのをあまり見たことがないので
「一休」という会社について少し説明をさせていただきます。

  • サービス
    • 一休.com（http://www.ikyu.com/）
      • 高級ホテル・旅館の予約サイトです。「じゃらん」とか「楽天トラベル」のようなサービスで、「高級」に特化しています
    • 一休.comレストラン（http://restaurant.ikyu.com/）
      • 高級レストランの予約サイトです。「OzMall」とか「Cena（食べログ予約）」のようなサービスで、やはりこちらも「高級」に特化しています
  • 社員（従業員）
    • おそらく120名くらい（あんまり把握してない）そのうち、開発メンバーはパートナーも含めて40名程度だと思います。入社した当初はシステムメンバーは自分を含めて6人で自社サービスを開発・運用を行っていたので、DevとかOpsとかの境界はなかったのですが3年ほど前から「開発部」「インフラ部」と分かれてある程度の業務分掌が行われています。

●現場の話

一休の開発現場は「ザ・レガシー」と呼ぶに相応しいNot Modernな現場です。自虐ではなく客観的に見てもそう思っていて、現在は改善活動を少しずつ（ホントに少しずつ）行っています。

  • どのへんが「ザ・レガシー」か
    • 開発プロセス
      • 小規模なエンハンスであればササッと直してリリースしていますが、中～大規模な案件になってくると、当たり前のようにウォーターフォール型開発が登場します。その時のPMによってはアジャイルっぽくやってる場合もありますが、朝会やカンバン、プロダクトバックログを活用しているようなケースは非常に稀です。
    • テスト
      • テストは殆ど自動化出来ておらず、追加開発毎に似たようなテストを手動で実施しています。メンバーみんなExcelとマブダチです。
    • レビュー
      • コードレビューの標準化がしっかりと行われていないため、レビュアーによって観点はマチマチです。また、バージョン管理システムはSubversionを使用しているため、ブランチ運用の負荷が高くてtrunkへのコミット前にレビューを行うことが難しい状況があります。
    • デプロイ
      • trunkへのコミット後に行うデプロイ作業の内、一部の作業は手動で実施しているためデプロイ運用も負荷がかかっています

改めて書き出してみると、ホントにレガシーですね。。昭和の香りが漂ってきそうです。
他にも「メンバーによってはあまり外部の勉強会に参加していないために、情報のキャッチアップが遅い」とか「新しい技術や、やり方を試そうとすると変更を嫌う意見が頻出する」とか色々ありまして、現場改善欲がある方にはたまらない「現場」となっております。

●Not Modernな現場を改善する

これは私の個人的な感覚ですが、上記のような現状を「このままで良い」と考えているメンバーはいないと思っています。「改善したい」とは思いつつも、次々と湧いてくる課題や新たなプロジェクトを前にして改善活動をしっかりと行なえていないという状況です。
ただし、課題や新たなプロジェクトがなくなることはなく、誰かが動き始めないとこの現状を変えることはできない、そう考えて昨秋頃から現場を改善するために情報収集を行い、コミットしてくれそうな社内のメンバー（2名くらい）と以下のような改善活動を行っています。

  • Modernな開発現場を目指して実施・トライしていること
    • 開発プロセス
      • 自分が担当した・するプロジェクトではスクラムを基本スタイルとして朝会や見積りポーカー、振り返りを行い、作業の改善を図っています。参加してくれたメンバーからも「前よりやりやすい」とフィードバックをもらえているのでこのスタイルをチームのスタンダードにするべく、改善できたことやメンバーの声を内部で共有しようと画策中です。
    • テスト
      • エンハンス開発で修正を行う箇所の内、重要部分・頻繁に修正を行う部分から優先してテストコードを書いています。テストコードを書く分、初期のコストは一時的に増加しますが、回数を重ねる毎にコスト・品質の両面で効果が表れてくるハズなので、成果を出しつつ、内部で共有し「テストを書く」という行為を習慣にしていこうと考えています。
    • レビュー
      • 「コードレビューをしやすい環境作り」を行うべく、SubversionからGitへの移行を検討しています。
        • GithubやBitbucketなどのホスティングシステムを使う
        • GithubEnterpriseを内部サーバに立てる
        • Git（内部サーバ）で頑張る
      • の3択なのかな、と考えていますが、まだ十分に調査ができていないのでGitへの移行ポイントやハマりやすい点、「XXXしたらレビューを回しやすくなる」などのアドバイスをいただけると嬉しいです。
    • デプロイ
      • デプロイ運用を自動化するべく、Jenkinsの導入を進めています。現在はデイリービルドをして結果を通知するのみですが、テスト実行・デプロイまでを自動化できるように改善中です。
    • メンバーのスキル・意識アップ
      • 参加した勉強会のフィードバックを定期的に行っています。デブサミや昨秋のDevOpsDaysなどで聞いた話を社内勉強会で共有したり、読書会も隔週で実施しています。現在は「SQLアンチパターン」の読書会兼勉強会を行っており、こなれてきた頃（3月頃？）に監訳者である和田卓人さん（@t_wada）にお声がけをして、遊びに来て頂こうと考えています。前にTwitterでその旨をつぶやいたら和田さんからもアクションがありました。

●自分が想う現場

私にとっての現場とは
「外部で得た事や自分が考えた事を実践し、成果を出す場であり学びを得る場」
だと考えています。

自分が外部の勉強会に参加をするようになったのは1年半くらい前だと思うのですが、
それまでは会社の仕事に夢中になりすぎていて、視野が狭くなっていたと感じます。

勉強会に参加するようになってからは、積極的に外部の方とコミュニケーションをとり、情報交換を行うことで

  • 自社の現場のダメなところ（要改善点）を認識できる
  • これからの開発現場やエンジニアはこうなっていくべきといった未来のイメージが湧く
  • 実際に改善活動やアクションを起こした人を見ることで、自分にもできるかもと思える

といった様々な「気付き」を得られる貴重な場所だと思っています。そこで得た「気付き」を具現化し、成果を出すことで会社も個人も成長する、それが私が想う現場です。

前述の通り、要改善点だらけの現場ですが社歴も長いせいか（もうすぐ8年）会社にも愛着がありますので、よりよい現場になるべく精進を続けていきたいと思います。

●最後に

一休では自社サービスの開発・運用を行うエンジニアを積極採用中です！
レガシーなB2Cサービスをモダンにしたいエンジニアでご興味のある方がいらっしゃいましたら @kentana20 へお気軽にご相談ください。

飛び入りで参加したので、次回があるかはわかりません。スミマセン。。

最後までお読みいただき、ありがとうございました。