ケロSE

ケロいSEが日々思う事を書きます

境界を越えた先にあったもの

はじめに

このエントリーはDevLOVE AdventCalendar 2014 「越境」の2015年1月6日のエントリーになります。

前日はrei_mさんの越境 1歩踏み出すことの大切さでした。

で、誰？

あさの(@uasano)といいます。

主にJVM関連の言語でコード書いたり、Herokuを使ってシステム構築したりするお仕事に従事しています(今年のテーマはScala力の強化)。

平時は、TDDBC界隈、アジャイル界隈に出没することが多いです。

DevLOVEとの繋がりは、ちょこちょこと開催してくださるイベントに参加させてもらっていたりしたのですが、昨年、アジャイルサムライ横浜道場のご縁で DevLOVE現場甲子園2014 東日本大会で登壇する機会を頂きました。

概要

このポストを簡単に3行でまとめると

  1. ここでの越境は「転職」です
  2. 転職先は前職より自分に適した環境でした
  3. 転職しても理想郷にはたどり着けなく、日々の精進が必要でした

です。

どんな越境をしたの？

このポストでとりあげる越境は、「転職して、会社と会社の境界を越えた」です。

  • 越境した時 : 2014年10月
  • 越境元 : 新卒で入社してから10年在籍した某大手メーカー系SIer
  • 越えた理由 : よくあるSIerをdisる流れで出てくるごく一部の事
  • 越境先 : 創立10年弱のシステム受託開発の会社

結果

転職して3ヶ月ちょいの状態で判断するに、現状にはとても満足しています。

今の職場では

  • Githubを使ったPullRequestベースの開発
  • Werckerを使ったCI
  • チケットベースのタスク管理

がごく当たり前に行われています。 前の職場ではバージョン管理の標準がSubversionだったことを考えると時代が随分現代に近づいた気がします。

環境を変える為にパルプンテ的な手段を使ったところ、幸運にも良い効果が出た感じです。

とはいえ、開発チームの中では良いプラクティスが実践できていても課題はあって、 (他チーム(デザインチーム・顧客との折衝チーム)との連携で見るとサイロ化感があったり) 色々と改善の為に試行錯誤が必要です。

気付き

「自分たちみたいなチームの改善に取り組んできた人が、 突然理想的な環境に置かれたらどうなるのかな？ 存在価値なくなっちゃうのかな？」

DevLOVE現場甲子園2014 東日本大会で、同じ隊トラックに登壇されていた @terahide さんとこんな話をしてました。 この問いかけには考えさせられたので気づきの冒頭に持ってきました。

転職した結果、期待していたものに近しい現場になれた今、この問いかけに応じると――

  • 転職等の手段で、環境を劇的に変える事はできる。
  • それが上手くハマったとしても理想的な環境(※改善の余地がまったくない、のような意味)は手に入らない
  • だから、チームの改善に取り組む人はいつになっても必要。

のようになります。

この辺りは、魔除けの逆柱 っぽいなぁなどと思っています。 チームの活動も、これで完璧！と思った瞬間に崩壊(というか劣化)が始まりますよね。

だからって、ワザと改善の余地があるのに手付かずにしてていいってわけではないですがｗ

おわりに

このエントリを最後まで読んでくださってありがとうございました。

明日1月7日のDevLOVE AdventCalendar 2014 「越境」はyyt0103さんの越えるべき境は、さながらマトリョーシカのよう。 - 黄色いレンガの道です。 「転職という越境」をしての気付きを書かれています。マトリョーシカのメタファ、しっくりきました。

メトリクスによる「見える化」のススメ:エッセンシャル・リーン #yuru_gee に参加しました

9月19日(金)の19:30〜21:30 に開催された第八回ゆるぎー メトリクスによる「見える化」のススメ: エッセンシャル・リーンに参加しました。

講師は、伊藤宏幸さん(@hageyahhoo)

会場提供は、21Cafeさん

当日の内容は、伊藤さんがブログ(THE HIRO Says メトリクスを題材に勉強会が成立するかを検証してきた)にまとめてくださっています。

つぶやきまとめはこちら

そして相変わらずゆるぎーはこんな感じ。

で、ここからが本題です。

今回の勉強会は伊藤さんが「参加して面白かったで終わる人を０人にする」を目標にされており参加者全員に宿題が出ています。

で、私は、こちらのお題について書きます。

自分たちが現場で行えるネクストアクションは何か？

10月1日から転職するので、現場でのネクストアクション、として実際に行動するのは少し先になりますが、これをやるぞーという意思表明をします。

職場の開発プロセスを改善する為に手を加える前後は必ず効果を測定する為のメトリクスを取る

これ、実は現職の現場でも開発プロセス改善の為に色々な取り組みをしてきたのですが、 今ひとつだったなと思っていたトコロなのです。

  • そもそもプロセス改善を”業務として取り組む価値のあること”とチームの皆にわかってもらう為には、どうすれば「ここで無駄が発生していてこうすればその無駄が減らせる」と伝える事ができるだろう
  • 改善の為にアクションを取ってみて、それが有効な対策だったかの判断ってどうやるんだろう

という思いを現職で強く感じていました。

次のプロジェクトがどんな環境なのかはまだわからないのですが、上記の悩みに対する1つの道標を示していただけたと感じているので、メトリクスを取りつつ歩んでいこうと考えています。

最後に、登壇してくださった伊藤さん、イベントを企画・運営してくださったゆるぎースタッフの皆さん、同じ場を共有し盛り上げてくださった参加者の皆さん、会場提供の21Cafeさん、ありがとうございました。

JJUG CCC 2014 Spring に参加しました。

JJUG CCC 2014 Springに参加しました。

メインはTDD BootCamp in JJUG CCC -レガシーコード対策ハンズオン- をTAとしてお手伝いすることでした。

渡辺 修司さん(@shuji_w6e)の講演のスライドはこちら。

Java使い必携の書、JUnit実践入門が4刷、累計１万部突破めでたい！

TAとしてウロウロしている間に参加者の方が質問してくださった事に対して私がどんな回答をしたかをシェアします。

  1. 今の課題はプロダクションコードが既に出来上がっている状態なので、本来のTDDのサイクルがいまいちピンとこないのですけど、本来のTDDはどういう風に進めるものなのですか？
    • 一番シンプルなケースから実装していくので、まず最初は消費税率が0%の時に金額が計算できるテストを書いて、そのテストがクリアしたら、リファクタリング、次は消費税が5％の時のテストを書いて、そのテストもクリアするように実装を変えて...のように進めていきます。(この疑問はフルバージョン？のTDDBCでペアプロのデモを見ていただけると 解決するかも) 本来のTDDのサイクルを体感するのだと、今のプログラムに機能を追加する(例えば商品10個以上買った時は割引になるとか)のを、まずテストから書いてみるとかどうでしょう。
  2. Order#orderメソッド（注文）の注文数が負数になった場合は不正な処理として例外を発生させるようにしたいのだけど、TDD的にこれはどう進めるのが良いですか？教科書通り先にテストを書くのですか？先に実装を書くのですか？
    • やりやすい方で良いと思います。JavaはRuntimeExceptionが予期せぬ箇所で発生する場合があるので、教科書どおりに最初に「IllegalArgumentExceptionが発生する」テストが失敗させてからプロダクトコードを変えてテストを成功させた方が安心できる気はします。好みや慣れの問題もあるので、どうしても先にテスト書かなきゃだめ、ってことはないです。(あくまでコーディングを快適に進める為の手段なので、先にテスト書くのが重いなら後まわしでも良いかと(
  3. 注文時に設定する消費税率の上限はどこまでテストするべきでしょうか？ 消費税率100％のようなケースがいるかと思ったのですが、よく考えると不要かな？と思えてきて...
    • TDDでは「不安をテストにする」という言葉があるので不安であればテストを書いて良いと思います。のくらいテストをすれば十分か、はテスト技法を学ぶと良いと思います。消費税率が100％以上になると計算方法が変わる等であればテストすべきですが、特にそういう物でもないので私は無くていいと思います。
    • この質問はちょうど渡辺さんも聞いていて「もう1つ、補足として、明らかな異常値をエラーにするような実装をしておくのも現場では必要になるかも。そういう作りにしておくと、某株式の誤発注事件のような事件が防げます。システムがしばらく止まるのと、会社の経営が傾くのとを秤にかけたら、後者を選びますよね。」のように仰っていました。

と、誤発注をテストで防ぐ、のような話を聞いたあと、お酒の過剰発注が明らかになったお陰で楽しく懇親会に参加させていただけましたｗ。

第5回ゆるぎーでJenkinsについて語ってきました #yuru_gee

渋谷のオシャレイベントスペース 21Cafe で開催された第5回ゆるぎー にスピーカーとして参加しました。

前半は、私が所属するチームにJenkinsを導入した結果、チームがどんな風に変わっていったか〜のような事をお話しました。

スライドはこちら。

Jenkinsさんで、何かを自動化することのコストが劇的に下がった事でチームの皆が「自動化できることは自動化して機械に任せよう」と考えるようになり、人は人がやるべき事に意識が向けられるようになっていった。 Jenkinsを導入して良かったなぁ〜と感じている体験談の紹介でした。

そして、後半はハンズオン。

ハンズオン用リポジトリ はこちら。

やったことはREADME.mdに書いてある通りです。演習はこのテキストを見たら進められるような感じになっているのですが、「肝心のJenkinsのセットアップ」部分がブラックボックス化していたので補足。(README.mdにも追記しました)

インストールしていたプラグインは以下の通りです

あとは、Jenkinsを実行しているユーザで、 grails コマンドが実行できるようにしていました(バージョンは2.3.7)

時間足りないのでは？の懸念があったのですが、「ビルドパイプラインを作る」がどうしてもやりたかったのです。 ビルドパイプラインは、振り返りの時に参加者さんから「これは面白かった」とポジティブな声が多く聞けたのでこだわってよかったのです。 (時間を捻出する為に、ソースコードの内容に一切触れなくていいようにGithubから特定のブランチを取ってくるだけの3分間クッキング方式にしたり色々ｗ)

あとは、ハンズオンの最中に参加者の方から受けた質問について共有を。

  • 他のジョブで保存した成果物を、別ジョブに取り込むことはできますか？ → Copy Artifact Plugin を使うとビルドステップで「他ジョブの成果物をコピー」が使えるようになります。
  • ジョブごとにワークスペースが作られるけれど、ワークスペースを複数ジョブで共有したい。 → Shared workspaceプラグインを使えばできる（はず)
  • パイプラインビューのNo Of Displayed Buildsの設定はどういう意味ですか？→ビューに表示されるビルドパイプラインの行数の設定です。(?をクリックすると説明が表示される、を伝えるのを忘れてしまっていた...)
  • Jenkinsの1つ1つのジョブの単位ってどのくらいですか？(1つのジョブでビルドとテストとデプロイを実施するの？それとも3つのジョブで分担するの？)→目的が違うなら、ジョブを分割した方が良いと思います。1つのジョブで色々と実行しているとジョブが失敗した時に「何が失敗したか」がわかりづらくなってしまうので。

Jenkins、プラグインが沢山あって素敵なのですが、多すぎて把握できないってのもまた真実なので、下のように思った…。

参加してくださった皆様、素敵な会場を提供してくださった21Cafe様、講演内容へのアドバイス・宣伝等してくださったゆるぎースタッフ様、本当にありがとうございました。

ミニTDDBC presented by yokohama.devtestingに参加しました #tddbc #devtesting

3月30日(日)に開催された ミニTDDBC presented by yokohama.devtestingにスタッフとして参加してきました。

 

当日は生憎の雨にもかかわらず、申し込みされていた方が全員出席してくださる幸先の良いスタート。

 

そして、キーノートはこれまで3年間横浜TDDBCを主催されてきたせとあずさ(@setoazusa)さん。

 
ついで、参加者の皆さんにTDDの進め方を知ってもらう為のペアプロデモ。恒例のFizzBuzz問題をとーます(@grimrose)さん解説、てらひで(@terahide27)さんと私がペアを組んで解きました。
 
ここで休憩を取って、それからペアを決めてTDD演習。 参加者さん5人とスタッフ3人を混ぜ混ぜして4組のペアでそれぞれ進めて行きました。
 
今回のイベントは「JavaとEclipse」と言語も環境も指定していたのですが、普段使っている言語がJavaでない方が多かったのです。TDDBCのgithubで各言語のスケルトンが公開されているので、「よくわからんけど、これが動く環境つくればおｋだろう」みたいに参加の障壁が低くなっているのだと想います。(間口を広げる地道な活動大事ですね)
 
諸般の事情で1ペアはコードレビューができなかったですが、残り3ペアのコードレビューはどれも良かったのです。
会場にいた方が主に使われている言語にばらつきがあると、1つの課題に対して色々見解が出てきて面白いです。
1ペアがprivateメソッドの名前の先頭に _を付けていて、「Javaは明示的にprivate修飾子を付けるからつけない方が多い」「Pythonはそもそも__(アンダースコア2つ)がprivateの意味を表しますよね」等など。
他の言語を知るのも勉強になるわー、と思った次第。(今年覚える言語を決めないと...)
 
自分のKPT。 Try … 職場のランチミーティングでFizzBuzzをTDDで作る、をデモする！ にしよう。
 
以下、見つけられたこのイベントのブログ投稿です。
 

MacでMajestouch MINILA Air を使う

自宅では、MacBook Pro にMajestouch MINILA Airを繋いで使っています。

 

使っていて気になるのは、「無変換」キーと「Kana」キーの挙動が本体付属のキーボードの「英数」キー、「かな」キーと挙動が違うところです。

 

PCKeyboardHackを以下のように設定すると無変換キーが英数キーと同じ挙動、Kanaキーがかなキーと同じ挙動になりました。

 

For Japaneseの項目で2つにチェックを入れます。

 * Enable NFER Key on PC keyboard

 * Enable KATAKANA Key on PC keyboard

さらに、「Enable KATAKANA Key on PC keyboard」のキーコードをデフォルトの54から104に変更します。

 

 

Jenkinsを導入して2年を振り返る

昨日、日本オラクル様で開かれた「

JJUG ナイトセミナ 「師走の Jenkins 祭り」 - 日本Javaユーザーグループ | Doorkeeper

」でGREEの岡崎さんが「Jenkins運用3年でわかったこと」という発表をされて、それに触発されて職場プロジェクトのJenkins導入の歴史を振り返ってみようと思った次第。（導入して3年かと思っていたけど、2年やった…(；´∀｀)）

 

なんとなく、6ヶ月区切りくらいで歩みを振り返ります。

2011年12月〜2012年5月 導入期

導入のトリガーになったのは、リリースビルドの手順が面倒(色んなファイルの設定をデプロイ対象のサーバに応じて手で書き換えていた)でかつ手ビルドになっていて、変なアプリがデプロイされてしまう事が頻発していました。

それを抑止するために、Jenkinsで自動ビルドするようにしました。

この頃はMaster1台に、Jobが20程度の運用で、機能的には

  1. Flashのビルド (Flex Builder を使用)
  2. warファイルのビルド(Ant + build.xmlを使用)
  3. Androidアプリのビルド(AndroidSDKとAntを使用)

でした。

2012年6月〜2012年11月 放任期間

この頃は自分がプロジェクトを離れていて、Jenkinsのお世話ができませんでした。代わりに面倒をみてくれていた後輩様が自分の作ったジョブをコピーして一部値を書き換えて、で活用してくれていました。(その後輩が別のプロジェクトでもJenkinsを導入してくれていたのがとても嬉しかったな〜)

この頃は、Master1台に、Jobが40程度の運用でした。

2012年12月〜2013年5月 雌伏期間

面倒をみてくれていた後輩様は転勤でプロジェクトを離れ、私が再びプロジェクトに戻ってきて管理者バトンタッチ。賢いCron的な使い方も導入していきSlaveを使うようになってきて、Master1台にSlave1台、Jobが60程度の運用でした。

Job数が多いのは、1サイトで6ジョブくらいあってそれがサイト数分あるのでモリモリ増えてしまうのです。

2013年6月〜2013年12月 飛躍期間

雌伏期に蓄えていたネタが一気に実を結んで、いろんなことができるようになりました。

  1. 検証サーバ(AWS上のサーバ)への1クリックデプロイ
  2. iOSアプリのビルド
  3. サイト別リリースビルド・デプロイジョブを生成するジョブ

かねてからやりたいと思っていた、AWS上の検証サーバへの1クリックデプロイがチームのメンバに非常にウケました。(使い出して1年経ってやっとみんなに価値が提供できた…)

この頃は、Master1台に、Slaveが6台、Jobが90程度の運用になっています。

 

2014年の展望

最近、プロジェクトの中でJenkinsがゴールデンハンマー化の傾向があるので、適切なツールに役割を分散させないといけないなーと感じつつあります。

もう1つは、職場で運用周りのプロセスを共有して楽しよう、という流れがあるのでその中でJenkinsをどんどん宣伝して行きたい。