現場改善プロジェクトを1年間やってみて
技術的な話ではなく、現場というかマインドについてのお話。先日、会社のエンジニアメンバー向けに1年間やってきた改善プロジェクトのふりかえりをしたので、そのサマリをあげておく。
プロジェクトが目指す方向
ユーザに価値を提供するスピードを最大限向上させる
を目標に掲げてプロジェクトを進めています。
やったこと(時系列)
書けないこともあるのでざっくりですが、こんな感じです。
2014/04 ~ 2014/06
- プロジェクトキックオフ
- 新しい情報共有・コミュニケーションツールとして Hipchat / Qiita Team を導入
- 朝会・カンバン・ふりかえりといったアジャイル／スクラムのプラクティスを導入
- SVN→GHEへの移行を見据えてGit/GitHubのハンズオンを実施
- 情報共有・ドキュメント整備としてWiki/用語集の整備を開始
2014/07 ~ 2014/09
- SVN→GHEへの移行を完了
- デプロイ時のテストを自動化(E2E)
- CI(Jenkins)を導入してデプロイ作業の大半を自動化
- 情報共有は引き続き自律して実施できるように継続アクション
2014/10 ~ 2015/01
- naoyaさんが正式に「技術顧問」に就任
- 開発フロー改善チームを発足してRedmineチケット見直しとContributing.mdを整備
- E2Eテストの高速化（30min→10minくらいの圧縮に成功）
- レガシーコード改善チームを発足
- デザインメンバーもGitワークフローにJoinし、手動作業の削減に成功
2015/01 ~ 2015/04 (現在)
- 本番リリースの自動化にトライ(継続実施中)
1年前に立てた目標の延長でやってきたことも伸びしろが少しずつ減ってきたので、新たな目標を再設定して2年目に入りました。
継続的改善と小さな成功体験
継続的改善を繰り返す
プロジェクトの進め方として
- 3ヶ月を1つの単位として、3ヶ月後に目指す状態を定義する
- 定義した状態へ向かってアクションを考えて実施する
- 中間(1.5ヶ月経過後)で全体へ共有しつつ、目指す状態と現在地を再確認
- 3ヶ月後にふりかえりの場を設定し、達成できたこと、できていないことを共有しつつ、次の3ヶ月へ
というサイクルを回すようにしました。このフレームワークはとても機能していて、期間もちょうどよく、スピード感をもって成果を出しつつ、前進を続けることができたと感じています。
組織の規模や課題感にもよると思いますが、自分たちにはとてもフィットしました。
小さな成功体験が前進をブーストさせる
自己啓発などではよくある表現ですが、今回は身を持ってこの効果を実感しました。1年前に「1年後にいまの状態を目指すよ！」と言われても、ここまでの成果は出なかったと思っています。
3ヶ月という単位で小さな成功を積み重ねてきて、1年経ってふりかえると様々なアクションが出来ていて、その結果セールスチームやデザイナーといったエンジニア以外のメンバーからも「最近は開発が早くなった」と言ってもらえるようになってきました。
この体験は 次に立てる目標もなんとなく達成できるのではないか という、ポジティブな雰囲気を継続させる効果も持っていると思います。
外部のエンジニアとのつながり
このプロジェクトがきっかけで、以前書いたようにイベントに登壇させていただいたり、社外のエンジニアとのつながりが強くなったように思います。
イベント登壇やメディア紹介
DevLOVEのイベントへの登壇や、CROSSパネルディスカッションなど、外部のインベントに参加する機会が増えたり、Qiita Teamの利用事例として取り上げていただいたり、露出の機会が増えたように思います。
採用にもつながった
発表内容やメディアを見て会社に遊びに来てくれた方がいたり、応募をしてくれた方もいて、その中から正式にジョインすることが決まった方もいるので、直接の利益にはなっていないアクションでも、続けていれば会社に貢献できることがあるんだと自信にもなりました。
おわりに
まだまだこれから
こうやってふりかえってみると、いろいろなことをやってきました。
ただし、社内で実施したふりかえりでも話したのですが まだまだ改善の余地はあるし、スタートラインに立ったばかりのタスクもたくさんある と思っています。
ありがたいことに今年もプロジェクトを継続できることになったので、さらに前進を続けてエンジニアがよりサービス開発に集中出来る環境を作って行きたいと思います。
詳しく話を聞きたかったり、興味がある方は...
ぜひ、オフィスに遊びに来てください！お茶でも飲みながら、情報交換などできれば嬉しいです。
hatena engineer seminar#4 に行ってきた
2/7(土) に表参道のはてなオフィスで開催された hatena engineer seminar#4に行ってきました。 20~30minのセッションが5本あったのですが、印象に残った2本をチョイスして技忘録。
セミナーの内容は こちら
Goで書かれたmackerel-agentのOSS化や自動化にまつわるあれこれ
- id:Songmu / @songmu
昨年秋頃にカヤックからはてなに転職された id:songmu さんの発表。スライドはこちら
mackerel
- サーバサイドは Scala
- エージェントは Go
日本製としては珍しいモニタリングサービス。
入社してからやったこと
- テストをオープンに
- ビルドをオープンに
- リリースをオープンに
mackerel-agent
- Goなので、マルチプラットフォーム
- Windowsでも一応動く（公式サポートはされていない）
- シングルバイナリ
- セットアップが容易
- 常駐プロセスのプログラムに向いている
なんでOSSにしているのか?
ユーザがHACK出来る余地をのこしておく
- エンジニア的には嬉しい
- SaaS系でも結構あること
- Travis CI
- コンテナのCookbookを外部公開している
- github-service
- service連携部分を公開されている
- Travis CI
ソースをオープンにして第一段階クリア
パッチ受け入れ
- 放置してはいけない
- プルリクは公平に
- レビュー体制大事
- CI整えておけば、レビューややりとりがラクになる
CI
- テストコケてたら直してといえる
- パッチのAccept基準も不明瞭になる
- SaaSを使う
Travis CI
- 使い慣れている
- tagをトリガにしてCIが動く
mackerel-agentのCIでやっていること
- go vet/golint
- フォーマットの検査
- 些細なコーディングスタイルの違いで議論したくない
- go test
- テスト実行
- coverage
- Coveralls
- cross build可能かを検査
- Travisのほかに社内Jenkins
Windows対応
- AppVeyorでCI/CD
- テストとインストーラー作成
レビュー体制
- しっかり作っている
- agentは社内の誰かがレビューする
- 業務時間内の社内リソースをどう割り当てるか
- 気づいたとき
- あまり仕組み化できていない
mackerel-agent plug-in
- たくさんある
リリースプロセスをオープンに
- make release コマンドでリリース用のプルリクを作る
- バージョンのBump Up
- リリースノートの作成
- release merge commit に対してTravisが自動でtagを作る
- tag を打たれた commit に対して更にTravisがビルド成果をリリースノートに貼る
- これ、いい
ここ、近いことはやっているのですが、もうちょい改善できそうなので、詳しく仕組み知りたいと思いました。
仕組みはPerlで
- releng
- リリース用のプルリクをつくる
- autotag
- Travis側から実行する
- tagを作成
テストもしっかり
課題
まとめ
はてなブックマークの新機能における自然言語処理の活用
id:skozawaさんによるはてブの「トピック機能」の裏側のお話でした。結構刺さった。スライドがまだ公開されていないっぽいので、公開されることを期待。
はてなブックマークでの自然言語処理
トピックページ
- 関連性の高い話題の記事をまとめたページ
要望は前からあった
- インターネットで盛り上がっている話題を知りたい
- ホットエントリでの同じ話題のエントリ重複を避けたい
トピック生成
- クラスタリング精度が低い
重要語抽出ベースのアプローチへの変更
- 検索技術: Elasticsearch
トピック生成の流れ
- トピック作る
- 関連するエントリを集める
- トピックのマージ
タイトル生成
- 重要語抽出
- 重要文抽出
トピック生成
トピックとは
- キーワードの集合
トピックモデル
- PLSI
- LDA
Elasticsearchでトピック生成
- 重要語を取得出来る機能がある
スコア計算方法
- jlh
- mutual information
- chi square
- google normalized
- JLH
- 出現割合
- 話題の単語のスコアが高くなる
タイトル生成
- トピックに含まれる記事は同じ話題
- 各記事のタイトルはある程度しっかりしている
- いずれかの記事を使うとうまくいく可能性が高い
- ただ、闇雲にとってもダメ
- 重要文を利用する
- タイトルから重要語を抽出
- 係り受け関係に基づく文圧縮
まとめ
- Elasticsearch
- 自然言語処理
- トピック機能
所感
hatena engineer seminarは2回目の参加でした。今回は
- mackerelでの自動化あれこれの話
- はてなブックマークとはてなブログの開発環境の話
- 自然言語処理で作ったはてなブックマークでのトピック機能の話
- iOS/Swiftの話
- TypeScriptとMVPパターンの話
というバラエティに富んだ内容で、非常にインプットが多かったです。中でも以下の2つはイロイロな面で参考になる話が多く、反芻して取り込んでいきたいと思いました。
id:songmu さんのmackerel での自動化あれこれの話
- いまの自分のミッションに結構マッチしている
- github-service などからOSSに入っていくのは面白そう
- 自動化系スクリプトでもテストを書く
- 言語はやはり揃えた方が良い
- いまの一休では、自動化系スクリプトは windows batch, Javascript, Ruby 等、散らばっている
id:songmu さんの自動化・オープンマインドには非常に共感出来る部分が多くて、「こういう文化を作っていきたい」そのために、自分のスキルや考えをもっともっと伸ばしたいと思う内容でした。
id:skozawa さんの自然言語処理の話
- 個人的に興味深い領域
- いろいろなサービスで活用の仕方を考えられそう
- Elasticsearchが使えそう
id:skozawa さんの内容は、今年自分がチャレンジしたい領域にマッチしそうな話だったので、ファーストインプットとしてとても参考になりました。
また、休憩時間に id:stanaka さんとお話していて、面白そうなお話を頂きました。こちらについては、話が進められそうになったタイミングで発信したいですね。
はてなさんは東京オフィス（表参道）と一休オフィス（赤坂見附）と近いので、交流する機会を作っていきたいと思いました。
ありがとうございました :)
CROSS2015で旅行ECについてパネルディスカッションしてきた
1/29(木) に横浜大さん橋ホールで開催されたCROSS2015にパネルディスカッションのセッションオーナー兼スタッフとして参加してきた。人生初のパネルディスカッション、しかもセッションオーナーをやってすごーーーく勉強になったので忘れないようにメモっておく。
自分が開いたセッションはこちら
セッションタイトルと内容
「旅行ECサイト各社に聞く成長の秘訣とこれから」というタイトルで
- 楽天トラベル
- 一休.com
- relux
という3社のエンジニアが集まり、EC系共通テーマや組織デザインなど、いろいろな内容について話をしました。話の内容はspeakerdeckにスライドを上げてあるので、貼っておきます。
事前準備
企画が立ち上がってから、いろいろ準備をしました。
2014年10月頃: 企画の内容詰め
CROSS運営のセッションプログラムを調整するチームと1度話をしました。「こういう内容がやりたい」というドラフトを持って行って、「その内容は一部分はもう枯れてるから」とか「もっとぶっちゃけた内容が知りたい」とか、いろいろ指摘をいただいて、内容を固めていきました。まだ、この段階では固めたといっても、話すネタ候補を箇条書きでまとめたレベルです。
2014年10月~12月: 登壇者の調整
内容の方向は少し見えたので、トラベルEC系のサービスに携わるエンジニアとコネクションして登壇の依頼を始めました。
- 知人を介して楽天トラベルの id:taichiw とつながった
紹介していただけるということで、品川シーサイドまでお邪魔して、ランチミーティングしながら、ネタ候補を話して、ここでも「誰得なのか」、「こういう内容を入れたらどうか」といったネタに対するフィードバックや「事前に登壇者同士で顔合わせしたい」などの準備の仕方についていろいろご意見をいただけて、内容がまた少し固まりました。
「まだ正式OKじゃないけど、多分大丈夫」とポジティブなお話をいただけて本当に嬉しかったです。この場を借りて御礼申し上げます。
- 勉強会でreluxの @tom_furu とつながった
以前、参加したSlack×Hubot勉強会でCTOの @tom_furu とつながることが出来て、その勢いで後日2人で飲みに行って、CROSSの話をしたら「面白そうですね！」と言ってもらえたので、さらに後日お声がけをして参加いただくことになりました。
勉強会の参加エントリはこちら
- 一休.comからは部長とリーダーの2名にお願いした
こちらはリーダーである id:sisijumi については直前にお願いする形となってしまいました。ゴメンナサイ。
2015年1月（本番2週間前くらい）: 事前顔合わせ
id:taichiw から提案があった事前顔合わせを渋谷の居酒屋で実施しました。お酒を飲みつつ、想定しているパネルディスカッションの流れを話しながら、「こういう話をしても面白いかも」とか「この話聞きたい」とかを話しました。具体的には
- 各サービスの紹介とともに、規模感がわかるスライドを1枚入れたらどうか
- 質問に答えられない場合のためにNGサインがわかるものを用意したらどうか
- ホワイトボードがあるとパパっと図説できてよさそう
とかですね。もっとあるのですが抜粋するとこんな感じです。
2015年1月（本番3日前くらい〜当日）: スライド作り
ようやく内容も固まったので、スライドを作り始めました。パネルディスカッションなので、そんなに作りこまずにイントロだけをパラパラ書いていった感じです。一旦粗めで仕上げて、前日にちょこちょこ直す、という流れで作りました。
パネルディスカッションなので、「Yes or No」を意識した内容にするべきだ、と思ったのが既に前日の夜だったので、手直ししきれずに中途半端な感じになってしまいました。
で、いざ本番
ここからは反省点を中心にメモっていきます。
入りがカタかった
カタい入りになってしまいました。もっと会場を柔らかくしてアイスブレイク感を出したかったのですが、参加していただいたお客さんも4割くらいの入りで、前方の座席は空席が目立っていたので、すこしやりづらかったです。
- Try
- ネタスライドなどを入れて柔らかく入ることを意識する
セッションオーナーとパネリストの会話になってしまった
「パネリスト同士で会話をつないでいく」というのが良いパネルディスカッションだと思うのですが、セッションオーナーである自分がネタをパネリストに振ってその受け答えを繰り返すような感じなってしまって
理想の流れ
- セッションオーナー:「XXということはありませんか。Aさん。」
- パネリストA:「XXについては、YYですねぇ」
- パネリストB:「あー、YYはありますね。ウチでもZZZ」
という感じで会話がつながらずに、
実際の流れ
- セッションオーナー:「XXということはありませんか。Aさん。」
- パネリストA:「XXについては、YYですねぇ」
- ...
- セッションオーナー:「Bさんはどうですかね。」
- パネリストB:「ウチはZZZですねぇ」
というカタチでセッションオーナーである自分が結構話をする感じになってしまいました。この部分が個人としては非常に悔しい点で、パネルの醍醐味である「会話のつながりで盛り上がる」みたいなシーンをほとんど作れませんでした。
- Try
- 事前にパネリストに理想の流れを説明する
- お互いの主張が出やすいテーマと振り方を意識する
時間配分
90分という時間で話をしたのですが、始める前までは「90分なんて持つかな」と考えていて、結構ネタを盛り込んでいました。もし、足りなくなったらスライドをスキップして調整するという作戦を想定していました。
ところが、始めて見ると時間に対するネタの量がアンマッチであることに気づいて、中盤〜後半はスライドを一部スキップして乗り切ることになりました。思っている以上に皆さんしっかり話してくださり、もっとネタは絞っていいんだと勉強になりました。
- Try
- ボリュームを減らして余裕を持ったタイムマネジメントをする
クロージング
時間を若干オーバーしていたので、クロージングでは
- 参加者の皆さんへの御礼
のみを話して終わってしまいました。時間がなくても
- パネリストへの御礼と拍手求める
- 自分のクロージングトーク
- 今回なら「旅行ECに興味を持ってくれたり、各サービスに共感してもらえたら嬉しいです」とかの自分の所感を添えてクロージングする
くらいは話をしないと締まりが悪い印象になってしまうと感じました。同時にパネリストの方々への感謝が足りておらず、これは次回は絶対に改善したいと思います。
- Try
- 参加者、登壇者に感謝の意を述べて、自分の思いを伝えてクロージングする
所感
- 事前準備大事
- 何事にも言えること。事前の準備がどれだけ出来たかで、当日の成果が決まるようなもの
- パネルディスカッション難しい
- 実に難しい。1人で話す方が数段ラク
- 議論に発展する≒会話がつながるファシリテーションの修行不足
- パネリストの会話をうまく引き出す方法は修行が必要
- 旅行ECエンジニアで横のつながりができたのはポジティブ
- 今回の収穫。 id:taichiw からも「延長戦やりましょう」と言ってもらえたし、同業のエンジニアともっとカジュアルトークができるようになりたいので、今後も継続してアップデートの共有とかしつつ、夜会を開いたり、一緒に勉強会をやったりしたい。
- 少しは3社の認知度が上がったり、エンジニアの行き先候補となれば嬉しい限り
- 今回の目的の1つです。旅行ECにもっと光があたって、参加していただいた各サービスの成長の手助けになると嬉しい
CROSSは本当に多くのエンジニアが参加するイベントなので、今回のような機会をいただけて幸運でした。実行委員長の山口さん、プログラム係の森崎さん、森藤さんには特にお世話になりました。本当にありがとうございました。 スタッフとして参加していて、他のセッションはのんびり聞けなかったので、次回は「登壇者兼一般参加者」としてCROSS2016を楽しみたいと思ったCROSS2015でした。
Jenkinsユーザカンファレンスに行ってきた
1/11(日)に市ヶ谷の法政大学で行われたJenkinsユーザカンファレンスに行ってきました。
聴講したセッション
時間を1時間間違えてて、keynoteはほとんど聞けなかったので割愛。
はてなにおける継続的デプロイメントの現状と Docker の導入
- 株式会社はてな 信岡裕也 (@nobuoka)
はてなでは はてなブックマーク の開発や ジャンプルーキー という集英社がやっているサービスの開発を担当されているそうです。
Agenda
- はてなのサービス開発とJenkins
- ジャンプルーキーの開発フローとJenkins
- Dockerコンテナによる確認環境とJenkins
はてなのサービス開発とJenkins
はてなブックマーク
- テスト実行、静的ファイル生成、デプロイ等でJenkinsを活用
Mackerel
- Scalaなので、コンパイルとか、テストとかをJenkinsでやってる
- hakobeさんの資料が参考になる
各サービスとJenkins
- それぞれのサービスでJenkinsを活用している
- 一昔前は master/slave 構成のJenkinsを1組用意して全サービスで運用していた
- ライブラリの違いや、Jenkinsやプラグインのバージョン差異などで、トラブルが発生するようになったので、最近ではサービス毎にJenkinsを分けて運用している
なんのためにJenkins??
- ソフトウェア進化を継続するため
- テスト、ビルド、デプロイ
- 意識しなくてもテストが実行される環境を作るため
- 手順の自動化
- 特にテストは大事
- CIサーバ上に本番相当の環境を用意して実行
Jenkinsサーバ自体の管理
- Chefを使ってる
- 理由: 本番サーバもChefで構築しているから
ちなみに、一休ではJenkinsサーバの管理は手動。。。。イケてない部分ですね。
Jenkins使用の方針
- 設定を複雑にしない
- 秘伝のタレ状態を防ぐ
- だんだん設定が複雑化していくのは、めっちゃよく分かる
- Jenkinsジョブではシェルを実行するだけにしといて、シェルの内容はリポジトリに入れる とか
スマホとJenkins
- メモれなかった。。。
ジャンプルーキーの開発プロセスとJenkins
- 漫画家の卵的なユーザがマンガを投稿できて、エンドユーザはそれをタダで読めるサービス
- 開発・運用は「はてな」が担当
- ディレクター: 1人
- デザイナー: 1名
- エンジニア: 数名
最近のはてなでの開発・運用を踏襲・改善
ビルド・デプロイ
- gulp(node.js)
- Capistrano3(ruby)
- GHE
- Jenkins
-
- はてなグループ
- Slack
- Trello
プロセス
- スクラム(1splint 2week)
- リリースは毎週
- 自社サービスじゃないので
- ただ、masterは常にリリース出来る状態を保つようにしている
ブランチ戦略
- Git-flowに沿っている
- master / staging / devel の3ブランチ運用
pull request
- 開発中に作るかどうかは任意
- WIPを義務付けてはいない
- テスト結果を可視化
- pull request builderプラグイン？
- 失敗時にはチャット(Slack)に通知
- 開発中に作るかどうかは任意
良いところ
- push都度自動でテスト実行
- 失敗時の通知が来る
- ファイルの変更結果をコミット
- コマンド1つで確認用環境にデプロイできる
悪いところ
- 失敗が続くと慣れてしまう（オオカミ少年問題）
- ファイル変更とテスト実行が同じShellになってて管理しづらい
Staging/Production のデプロイ自動化はまだできていない
Jenkins Workflow Plugin
- イケてそうなので、試してみたいがまだできてない
Docker コンテナと開発環境
開発中の機能（branch）を自分以外のメンバーに公開したい
- ex. ブランチ名をサブドメインにして公開する
今まではNginxでブランチとポート番号を紐付けてProxyしてた
- ブランチとポート番号の管理がめんどい
- ライブラリを共有するので、ツラいときがある
そこでDocker
- 開発用サーバで複数のDockerコンテナを起動
- 別ポート番号を使用
- ポート番号の解決にはDockerAPIを使用
- ブランチからイメージをビルドするときにブランチ名に対応したタグをイメージにつける
- ホスト名からブランチ名を抽出
- DockerAPIにより、対応するタグ名のイメージのコンテナを探す
Jenkins上でのビルド・デプロイ
- 手動でブランチ名を指定してデプロイ
- ここも自動化したいところ
開発用サーバにJenkins
- CIサーバ上にコンテナが複数立ち上がってるという意味
- キャッシュが効いたり、いろいろいいことがある
クックパッドにおけるJenkinsの活用
- クックパッド株式会社 高井直人
- クックパッド技術部高井さんのセッション
master/slave
- サーバ構成管理はpuppet/Itamae
- クラウドとオンプレ
ラベルでノードを管理
- ラベルはカオスになりやすいが、頑張っている
ci-slave-ruby
- ci-slave-android/ios
- オフィスに置いてあるサーバ
- Androidは実機でテスト（サーバにUSBでぶら下がっている）
なぜ、CIしているのか
- 毎日の料理を楽しみにしたくてやってる
- いち早く、ユーザに価値を届けるため
- 要はリーン・スタートアップでいうMVPを可能な限り早く回すため
CIで守るべき価値
- 意図しない変更を予防できる
- 再現可能で自動化されている
- リソースや情報を集約できる
意図しない変更を予防できる
- ターンアラウンドを短くする
- すぐに失敗を伝える
- 不具合を放置させない
- 開発者は十分に傲慢なので、10分でイライラして、20分でキレる
ターンアラウンドを短くできる
- マルチプロセス化
- 分散化
- remote_spec
- rrrspec
- AWSスポットインスタンスを活用
- プロセス停止からの自動復帰
- 失敗したテストの自動再実行
- テスト実行順序の最適化
- 長時間かかるテストの投機的実行
- オープンソース
これで10分以内をキープしている
すぐに失敗を伝える
- 単に失敗を通知するだけでは、誰も見ない
- マジであるある。。
- jenkins-hipchat-publisher
- その場で通知しないと、すぐに風化して「あ〜、あれはたまにコケるんだよね」といって放置することにつながる
- その場で処理・対応することが大事
不具合を放置させない
- 偽陽性を避ける
- 偽陽性があると、エラーを気にしなくなってしまったり、本物のエラーを見逃してしまうリスクが高まる
- まじであるある
- CIで稀に失敗してしまうテストへの対処法が参考になる
- 全員がコードに対してオーナーシップを持つ
- ソースコードを共同所有する
再現可能で自動化されている
- マーティン・ファウラーの継続的デリバリー
- CIでの自動化
- アセットの生成と管理、テスト、デプロイ、通知
リソースや情報を集約できる
- メモれなかった。。
CIの価値を守る
- 意図しない変更を予防できる
- 再現可能で自動化されている
- リソースや情報を集約できる
コレが出来てないと、CIの価値が低下する
所感
はてな
- CIサーバの構成管理はやはりChef/Puppet/Ansibleなどを使うべき
- 一休ではまだできていない
- pull request時点でテストが走るのはやはり良い
- 一休ではUTが少ないのと、E2Eテストに少し時間がかかってしまうので、いまはやってない
- Dockerを使ってCIサーバ上にブランチ毎にコンテナを立ち上げて、確認用環境を作る
- すごく良さそうなので、試してみることにする
Cookpad
- 偽陽性を避ける、再現可能で自動化されてる など、散らかりがちな部分についての対応をしっかりされていて、さすがはCookpadさんだな、と感じた
- 全員がコードに対するオーナーシップを持つ、失敗したらすぐに対応するような通知や文化作りなど、組織・文化についても重要な部分だと再認識した
全体
- 2つしかセッションは聞いていませんが、TwitterのTLなど見てても、すでにJenkinsを導入していて、その上で発生する課題についてこう解決した、という内容が多かった気がしました
- 基本的にはJenkinsで テスト , st/productionへのデプロイ などを行っていて、+αとして、Dockerを使って特定ブランチをCIサーバ上にデプロイしたり、Chefを使った環境構築など、単純なデリバリーの道具からもう一歩先へ進んだ運用の事例紹介が多かったです
- 「Windowsはしんどい」という話がちらほら聞こえる中で、一休での取組みももう少し洗練して、活用事例として話せるレベルにしたいです
- Dockerについては「はてな」の事例が非常に参考になって、改めて開発基盤・CI周りでのDockerの重要性を再認識したので、3月までに今のミッションとして掲げている「Dockerを使った開発基盤の構築」を進めていこうと思いました
- あと、重要なこととして、1年前の我々からすると少しはモダンにやれてる実感が湧きました。自分達の取組みがそんなに間違っていないんだ、とちょっと自信も持てたので、これからも前進を続けていきます
- Jenkinsユーザカンファレンス2016があれば、その時にはスピーカーとして参加したいです！
運営について
まず、このような大きなイベントを企画・運営されたスタッフの方と、良い発表をしてくださったスピーカーの方々に御礼申し上げます。楽しい企画をありがとうございました！ イベントをよりよくするために、参加していて感じた改善点をいくつか。
- セッションの始まりと終わりは運営スタッフによる一言があると、スピーカーの方は話をはじめやすいと思いました
- 質問によって意識が分断されてしまうのと、話がブレるので質疑応答などはセッションの最後にまとめてするようにしてほしいな、と思いました
2014年、ありがとう
10分前になってしまった。
だいぶイロイロあった1年だったので、2014年をふりかえろうと思っていたけど、時間がないので簡潔に。
今年はイロイロあった。
- naoyaさんとのアドバイザー契約と技術顧問契約
- 一休の現場改善プロジェクト
- DevLOVEでのはじめての登壇
- チームメイトの退職騒動
etc...
挙げるとキリがないけど、本当に楽しい年でした。
2014年は充実していた分、来年もより頑張って、より良い年だったと来年末を迎えられるように頑張りたいと思う。
- 一休のみんな
- naoyaさん
- ガジェットセンパイやアラちゃん( id:wknar )はじめ、社外のエンジニア仲間
いろんな人に支えられていると思うけど、引き続き id:kentana20 をよろしくお願いします！！
来年もみなさんにとって良い年になりますように。
