何か着ていればいいよ

ソフトウェア技術者の日常や技術の話を書こうと思います。

Testing Casual Talks #2 に行ってきました #testingcasual

テスト 学習 ポエム

atnd.org

最初にまとめ

  • なぜ、参加したのか
    • 今年に入ってからテスト周りの学習をしているが勉強会には参加できていなかったので
    • 本の読書会だと個人的事情で全部は参加しづらいが、一発ものだと参加しやすい
    • テスト周りでの求職あったらいいな。
  • 結果としてどうだった？
    • 内容には満足。*1
    • 久しぶりに勉強会の懇親会に参加したがボッチで参加したので人と話すのが難しかった。
      • でも、少し話せて面識ない人と話すリハビリになったし、刺激を受けられた。
    • 自分もその一端を担っていたSI業界との意識の差に分かっていたことだけどズシリと来るものがあった。

以下はほぼ自分用メモのまんまです。
ヒカリエがオシャレすぎてビビりながら入場

そして発表が始まりました。

"How to test code with mruby"

GMOぺぱぼのhsbtさん

内容

ミドルウェアのテストの話。 シングルバイナリなのでmrubyはミドルウェアに組み込みやすい ex)ngx_mruby nginxやapacheの中でちょっと複雑な処理をしたいときに役に立つ 例えばアプリ側で普通やるdigest hashをnginxの段でできる。 Ruby のテストは簡単(CRubyの場合) test-unitを当初使ってみたとのこと 環境周りばmockでぼかしているのでモヤっとする ngx_rubyの振る舞いをテストできている訳じゃない。 モックとスタブを使いすぎると何をテストしているんだか分からなくなる。 現状cross platformなテストになっていない。CIも回っていない nginx.confをどんどんmrubyに置き換えていきたい。

感想

正直、mrubyをどういう場面で使うのか具体例が組み込みかと思って遠い存在的に感じていたけど、急に身近に感じられた。 面白そうだな。

"スクラムにおけるQAメンバー(非開発者)の関わり方を模索してみた"

ガイアックスの境野さん

内容

Scrum テストメンバーの関わり方についてテストを書かないQAの人に向けた話っぽい
スクラムのプラクティスを取り入れた開発(社内で2例目)
QA（コードが書けない人）がチームに入っていく。（初めから）
要件定義にQAが入って定義を充実させる（完了条件をはっきりさせるとか）

  • スプリントごとにテスト
    テストがスプリント内に収まらない問題
  • 振り返りはKPT
    • K:要件ヒアリングで仕様が詰められる
      まとめてテストより細かくテスト
    • P:テストがスプリント収まらなかった
      テスト項目の想定
      機能単位でのテストになった
    • T:テストのやり方、内容を変える（正常系をさらっとなぜなら開発者が書いてるから）
      ストーリーごとにテストする

ガイアックスでQAチームの技術力がもっと欲しいとのこと
関連でDeNAにSWETとというチームがある。

"大規模Webサービスのブラウザテスト自動化・並列化"

DeNAのdeme0607さん

speakerdeck.com

内容

NBPF (Next Browser Platform) 次世代ブラウザプラットフォームに関わる話。

効率的なリグレッションテストができた（自動化できたので）

  • 自動テストでは担保できないこともある
    • UI
    • 機種依存

QA工数を新機能やUI検証に集中

  • ブラウザ自動テストの拡充の問題点
    • ブラウザ自動テストは実行時間がかかる
      • HTTPリクエスト, Ajax, Mail
    • 実行するテストケースを削減するのはさけたい
      • テストの並列化による
      • テストの処理が互いに衝突しないように

  • 問題点

    • 大規模サービスの環境構築コストが大きい
    • 環境依存の問題にテストで気づけない
      • 本番環境、テストデータ
    • DB操作によるテストデータ作成
      • 仕様変更に追従しづらい
      • 実環境DBをテストから操作する（やばくね？）

  • 不安定なテスト

    • TimeOutError Ajaxのタイミング
    • テストの失敗に慣れてしまう

  • どうするか？

    • 地道にテストを修正していく
    • 不安定なテストを分析する

  • 不適切な実行計画

    • マシンリソースを最大限使いたい
    • テスト結果集計APIを利用
    • 過去のテスト結果から分散した形で割り振るようにする*2

  • 今後の課題

    • データ作成　APIの充実
    • 分散実行ノードを動的に増やす仕組み
    • push型ではなく、pull型の実行

感想

LT

"ECサービスの負荷テストの裏側"

@kenchan さん

speakerdeck.com

内容

初めて負荷テストを行った際の話
gatlingを使って負荷テストの結果のレポートを出していたが…。

  • レポートから見えるもの
    • ざっくりしている
      • 詳しく見たい
    • 分布を詳しく見たい
    • 時系列のデータが見たい
      • どのタイミングで負荷があがる？
      • アプリの特性把握ができた

感想

あまり負荷テストをやったことがないのでふぇーっと聞いていただけ。
不勉強な領域だったなぁ。

継続的Webセキュリティテスト

本日福岡から来たという市川さん

www.slideshare.net

内容

VAddy OWASP ZAP（Javaのセキュリティテスト） CIのフローに乗せるのが大変

感想

発表中に「あれ？この話どっかで聞いたな？」と思ってそれが気になり全然メモできず。
あとで調べたらJenkins Conference 2015のLTにいらしていた方でそちらを聞いていたので既視感があったんだとおもいます。*3

» Jenkins ユーザ・カンファレンス 2015 東京 – セッション/LT 日本Jenkinsユーザ会

"serverspecとかのカジュアルな話"

yudoufuさん

speakerdeck.com

内容

インフラ担当で自動テスト
サーバー構築はChef化していた
動きが予想が違ったらもう一度VMを作り直して通しチェック
チェック作業が辛い
インフラの人が少ないし通しテストは大変
ChefにServerspec最初から入っている

  • 振る舞いのテストの自動化
    • infratasterというのがある
    • Issueに暫定対応が載っていた

感想

正直、僕の目にはこれでcasualなの！？というくらい高度な話をしているように見えたのだけど、今はもう場所によっては当たり前になっているのかな？
うおおおお！！ていう感想。

"カジュアルなテスト&仕様書としてJSON+node requestのご提案"

k12u kawamotoさん

speakerdeck.com

内容

立ち上げ時期でテストガチガチではない感じ
Web APIサーバーの仕事
面倒でも仕様書、フロントエンドとの連携を
テストコード書くの正直面倒（楽にできるなら楽にやる）
JSON SChemaでやるかとももったけどボツにした
ルールが必要十分なものを確保できない
JSONで仕様書にできる
実装、仕様、仕様書の不備がCIでfailする
* Web開発の気持ち
* 単体テスト中心 * API開発が普通になると * 仕様がViewになる

感想

正直、事前に公開されていたタイトルと実際のタイトル*4が異なっていて事前公開のタイトルに意識がいっていた自分はリアルタイムでは内容がいまいち頭に入らず、あとから見直してやっと何言っていたのか分かるという状態でした。
なんも構えず聞けばよかった…。

全体としての感想

*1:個人的には得るものがあった

*2:実行時間の長いケースから順に実行するということ？

*3:内容もかなり切り口が異なる同じ内容だったけど、それはそれで色んな視点を提供してくれるので良いこと。LTだし、casualだし。

*4:もしかして内容も？

退職しました（旧職でやったことまとめその２）

キャリア 仕事

wkubota.hatenablog.com

上記記事の続きです。 前職でやったことの備忘録的な色合い強いです。

チケット駆動開発

Tracを社内に先輩が導入してくれたのですが、最初はどう使ったものかよくわかりません。
Excelでのプロジェクト管理とタスク管理を徐々にTracへ移しながら世の中の利用方法を調べながら試行錯誤しながらチケット駆動開発をチーム内で行いました。
一番、この試行錯誤で役に立ったのが新人教育の各自のタスク管理等をチケット駆動でやる試みです。
新人研修はやることが決まっているので、チケット化しやすくチケット駆動に慣れていない人間がチケット駆動の勘所を学ぶのに適していると結果としてわかりました。

レビュー文化

アジャイルの書籍を読み漁った結果、職能横断的なチームを作りたいと思ったのがきっかけです。
なぜ、職能横断的なチームを作る上でレビュー文化が必要と考えるに至ったかというと、それ以前はWBSを元に各自の担当を決めると「自分の担当はこれ、あとは知らん」という部分が多かれ少なかれ各担当者に出てしまいます。
ただ、（ソース、ドキュメントの）レビューをWBSあるいはチケットの担当者以外が行うことによってチームメンバーとして自分の担当箇所以外にも責任を持ちやすくなるのではないか？と考えたからです。
つまり、大きな目標として職能横断的なチームを作るというものを立て、その手段の一つとしてレビューを取り入れたのが始まりといえば始まりです。
そして、結果からいえば2-3年ほど時間はかかりましたが、そういった多少なりとも職能横断的な部分のあるチームに我々は育つことができました。
ただし、職能横断的なチームは人の入れ替えに弱く、その面で生産性を高く保つことは非常に困難だったのですがレビュー文化がチームに根付いたことで当初考えていた職能横断的なチームを作るという目的以外にも、「新しいチームメンバーへの文化の伝道」であったり「チームメンバーの向上心への寄与」であったり色々な面で非常に有意義な取り組みに育ったと後から考えれば思え、ある意味自分が旧職でやったことのなかで一番目に見えない形での組織への貢献だったのではないかなあと考えています。

サーバー監視導入

当時請負プロジェクトのリーダーとして、複数案件を抱えた状態だったのですが、システム管理者が社外常駐業務となってしまい、社内システムをメンテナンスする人間がいなくなってしまうことを防ぐため多少なりともLinuxを触ったことがあった自分がシステム管理者になりました。*1
その時、問題意識を感じたのが利用者が報告を上げるまでサーバーの異常に気づかないことでした。
利用者が障害報告を上げてきた時点ではたいてい業務が滞るため特急の対応が必要な状態になっています。
請負プロジェクトをやりつつ、特急のシステム障害対応をちょくちょく割り込みでなんてやってられないのでシステムの異常を早期発見、早期対処をする必要があると感じました。
社内システムにはコストをかけないというシステム管理者にとっては萎える思想で運用されていたので、廃棄マシンの中からまだ動くものを無理やり復活させてzabbixを立ち上げ勝手に監視体制を敷きました。
効果が分かってからは申請すれば新規サーバ購入の予算が通ったのでしょうが、暇もなかったのでそのまま運用を自分の退職まで続けましたが、サーバー監視としては非常に役立ちました。

ランチタイム勉強会

ランチタイム勉強会と称する内輪の勉強会を毎週社内の会議室で昼食をつまみつつ、様々なテーマで勉強会を開こうという企画を考え、実行に移しました。
これをやるにあたっては、誰の許可も取らず会議室の予約を取って社内掲示板に告知を勝手に出した訳ですが、誰も文句を言ってこなかったのでそのままのやり方で5年くらい断続的に続きました。*2
内容は、その時の流行りの技術についてであったり、プロジェクト管理やツールの使い方、ワークライフバランスについてや雑談などあまりとりとめもなくなんでもやった記憶があります。
というのもテーマを絞ってしまうと少ない人数でやっている会のため続かなくなってしまうので、続けることを優先した形で自由度を高く開催していました。
自分は言い出しっぺではありましたが、周りの人間の協力や理解があって続けられたものだと思います。

イテレーティブな開発

アジャイルプロセスに傾倒していた頃（5年前くらい）からウォーターフォールプロセスは自分たちのような数十人月程度の規模にはフィットしないと考えており、それならアジャイルプロセスはどうなのだろうか？というところが出発点です。 実際、小規模な割に要件も要望もモヤッとしたものが多く、早くリリースして顧客の反応を見る形でないと立ちいかないという結論に手痛い失敗から学習しての結論でした。
実際にはウォーターフォールでないからといってプロジェクトの成功が約束された訳ではなく、利益を出すのに苦戦もしましたが、プロジェクトがコントロールを離れて『とにかく作れ」とは以後ならなくなりました。*3

デイリースタンドアップミーティング

6,7年まえから朝会というやつをデイリースタンドアップミーティングという形で実施してみました。
週次進捗会議というのは自分の新人時代からちょこちょこ経験していたのですが、やはり情報共有という点であまり効率が良くないと以前から思っていました。
そんなとき、朝会の話をネット上で目にして物は試しとやってみたのが始まりです。 やり方はシンプルかつ柔軟をモットーにしていて、朝でも昼でも夕方でもプロジェクトメンバーの一番都合が良い時間をチームで決めて「これまでにやったこと」「これからやること」「問題点」の三つを報告するというものでした。
この会議体の意義や捉え方は時期やチームによって様々でしたが概ね常に*4実施しており、時間的なスパンや生産性等を考慮すると非常に良い取り組みができたと思います。
これは、時差のある遠隔地のメンバーやリモートワークのメンバーがいなかったから出来たともいえるのでそういうチームではどうしたら良いかな？というのも考えてみると面白いですね。

議事録のExcel廃止MarkDown化

おそらく、日本の多くの企業では会議後の議事録をExcelまたはWordで記録しているのではないでしょうか？ とりあえず、この件はブログに以前書いています。

wkubota.hatenablog.com

書き出してみるとぶっちゃけ普通じゃんという感じの事を色々やっていた訳ですが、組織内では誰よりも早く何かを始めるというやり方をやってちょっとは貢献できていたはず…。
そう思いたいです。
これからは一技術者としてコードで何かを残す方向にシフトするのが当面の目標ですね。

*1:自分一人では荷が重すぎるし、わからないことだらけなので常駐に出た先任の先輩の助けと、後輩をシステム管理者チームに加えることでなんとか回そうという体制でした。

*2:自分が常駐に出てしまったり、やるきが失せて途中中断したりしましたがそれでも100回以上にわたって開催できました。

*3:他にも色々対策を打っての上なのでイテレーティブな開発がその直接的な要因とは言い切れないとは思います。

*4:一人プロジェクトのとき以外は

退職しました（旧職でやったことまとめその１）

キャリア 仕事 ポエム

本日（4/30）をもって新卒から12年働いた会社を退職します。
ここで、自分が旧職で行った仕事のうちで公開しても問題なさそうな部分を中心にいろいろ思い返してみます。

Javaによる新人教育問題作成

自分の入社時(2003年)はVB6による新人研修を行っていたのですが、入社4年目くらいでVB6は時代遅れってことでその当時Javaの案件をやっていた自分が業務の片手間で新人教育用の問題をVB6の問題を元に作りました。
ただ使うというのと、人に教えるということの違いに戸惑いつつも非常にJavaの文法や教育というものについて考えさせられる経験でした。
その後、一昨年まで断続的に新人教育のJava研修担当をしていましたが、同僚の意見や新人の反応を見ながら毎年ブラッシュアップする機会を得て(Javaについてやプログラム学習についての)自分の理解を深められたと思います。

xUnit普及

JUnitの導入については先輩が先鞭をつけてくれていました。
ただ、そこから進まず特定の案件（というより一つのプロジェクト）のみJUnitのテストコードがある状態。
それではいかんなと思い、JavaのプロジェクトにはJUnitを入れてまわり、.NetのプロジェクトではNUnitを入れました。
xUnit不要論も最初はあって（上司や顧客に）よく反対されたのだけど、 マクロの視点で考えればプロジェクトの利益になることは論理的に間違いなかったので説得したり無視したりして周りを巻き込みテストを自動化しまくりました。

CI導入

xUnitを導入して開発者がテストを自動で流すことができるようになったのですが、xUnitを流すかどうかはそれぞれの担当者任せみたいな点に嫌気がさし、かつ規模の大きなプロジェクトでテストを定期的に流したくなり、丁度その頃世に出始めていたHudson*1を導入しました。
この辺から、何か新しいことを始めるにしても顧客は理解してくれないし、上司もなんやかんや消極的（というか多忙でプロジェクトの納期とかそういうの意外には多くリソース割きたがらない）。
そんな状態では「とりあえず一人で勝手に初めて良さげだったら周りを巻き込む」というやり方が良いのだなと学習しだした頃だと思います。

カバレッジ

xUnitでCIしていれば、見たくなるのがカバレッジ。IDEのpluginとかでたまに見ていたのですが、これも開発者全員やってくれるわけもなく。
というわけで、ビルドスクリプトに混ぜてデイリーテストのカバレッジもとるようにしました。

ER図作成自動化

新規開発の案件で、顧客要件が詰まってない案件をやった際に基本設計でER図まで超頑張って書いたのに、実装入ってから要件が変わってER図(Excel)をなんどもて編集するのに心底嫌気がさして自動化できそうなツールを探しました。
色々試行錯誤した結果、バッチからSchemaSpyでER図をhtml1で生成してJenkinsのリンクに出すのが一番楽という形にまで進化させましt。

にこにこカレンダー導入

こう言ってはなんですが、自分が入社して5年ほどはひたすら炎上案件を渡り歩いて火消し*2をしてました。
まぁ、簡単に言えばデスマからデスマを渡り歩くことになるのでメンタルが疲弊します。
その、疲弊度を見える化したくてにこにこカレンダーを組織内に意欲的に伝道しました。
当初、紙で各自カレンダーをだしてシールでにこにこを表現するというのが、その時の採用担当だった上司的に見栄えが良かったのか採用関連で（うちの会社はこういう取り組みをしているよと）比較的広報され、徐々に周りの人たちも使うようになりました。
*3

プロジェクト振り返り

入社以降自社案件ではうまくいかないプロジェクトに参加することが多かったので、その状況をなんとか改善したいなと思って始めたのが"プロジェクト振り返り"です。*4
それまでは、自社の請負の各チームを見たところプロジェクトが終わったらそれで解散・終了。
その教訓等もあまり共有されていなくて、同じ失敗を繰り返すみたいな部分もありました。
また、プロジェクトの教訓を生かすにしても経験を積んだ誰かが人間力で伝導するような形。
若手のうちから右も左も分からず、チームリーダーをやることが多かった自分は常に手探りでその非効率さをなんとかしたいと考えました。
そんな折、何かの本で見た*5プロジェクトの振り返りは徐々に自分のチームから自部署へ広がり多少なりとも経験値の見える化に貢献できたのではないかと思います。

以下後で書く

チケット駆動開発

レビュー文化

サーバー監視導入

ランチタイム勉強会

イテレーティブな開発

デイリースタンドアップミーティング

議事録のExcel廃止MarkDown化

*1:今のJenkins

*2:もっと燃え上がらせてしまった気もするけど、最後は消した。

*3:紆余曲折を経て自分が退職する時点ではWebアプリを使うようになっていました。

*4:そして振り返り結果を社内へ公開する。

*5:多分アジャイルプラクティスだった気がする。

Unit Testについてちょっと思ったこと

コーディング テスト ポエム
  • 問題が出がちな場所に限ってUnit Testが無かったりする。
    • Unit Testが無いということと不具合が発生する箇所の因果を立証するような根拠はない
    • しかし、Uni Testが書きづらい設計や動作確認が不十分であることなど、経験上は相関関係があると思う
    • テストケースそのものは品質を担保するものではない。
    • しかし、Unit Testが疎かなものはアカンことが多いんだな。
    • カバレッジなぁ。取ってみると分かる『むむむっ？』な部分。

人月見積で困るところ

アジャイル 仕事 ポエム 見積

ソフトウェア開発のプロジェクトで見積を行う際にいつも思い悩んでいること

  • 人がアサインされる前に見積もる

これに尽きる

で、困っているばかりでは仕事にならないので今までやってきたことを書き残しておきます。

経験の浅い頃

  • 標準的な人で見積もる まず、標準的な人ってなんですか？って感じですね。

  • 自分を標準とする

  • 2年目くらいの若手を標準とする
  • プロジェクトに参加しそうな人を周囲に聞いて回り、候補者からなんとなく平均像を標準とする

ぱっと見では、一長一短のようにも見えますが結論としてはほとんどうまくいきませんでした。 あまり上手くいかなかった原因の分析は出来てませんが、上記のいずれも未来を見通せたものではなかった。 というのが結果論的には言えると思います。
特に最後のプロジェクトに参加しそうな人を聞いて回るの案とか、最初は良い案だと思ったのですが、他案件の動きもあり大はずれしてしまいました。

最近

色々見積に失敗して、勉強もしました。

その結果、最近やっている方法

  • 相対単位で見積、人がアサインされた段階で相対単位を係数としてかける。

というものです。
アジャイルな見積に近いですね。
一番最初の見積がコミットメントになってプロジェクトの予算と納期が固定になってしまう案件だと辛いのですが、*1少なくとも
プロジェクト開始後にはある程度正確な見積ができ、
正直ベースのリリーススケジュールを立てることができるようなやり方だと思います。

ちなみに勉強したのはこんな書籍

ソフトウェア見積り　人月の暗黙知を解き明かす

ソフトウェア見積り　人月の暗黙知を解き明かす

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

*1:そのような案件の見積をどうやったらうまくいくかなんて天のみぞ知るだと思う

メールが文字化けするのは仕方ない

プログラマー インフラ 仕事

最近、メールを受信してその中身を解析し、その結果に応じて
また次の処理を行うというアプリケーションをいじっています。
その中で思ったのが表題の件。

ドロドロした部分は（特にMS製の）メーラーが何とかしてくれていた。

昔*1はメールが文字化けするとかって結構良くあったんですが、最近はさほど感じません。
*2

で、なめていました。文字化け。
最近あまり見ないし、メールって枯れてきているからもう文字化けなんてならないんだろう。
なんて少しでも思ったのが馬鹿だった。

実際流れているデータを解析する処理を書くと、電文内のcharsetなんて何も信じられない。
適当というかフリーダムな状況。
文字化けは全てメーラーがよしなに解釈してくれていただけだったんだな…。

日本語の含まれるメールは魔境

自分が扱っているのは特定の形式のメールだけというはずだったのに、全然対応しきれない。
今の時点でどうもあちらをたてたらこちらがたたずみたいな、
フリーダムなものから人間の解釈出来るものによしなに持っていく…。
そんな、先の見えない作業をやっています。
そして、こう思った。
『もう、お前らメールを日本語で送ってくんな！』

同じ電文の中に色んなcharsetとencodeが入り乱れて、さらにそのうちなんぼかが嘘っぱち。 とか、こりゃひどい。
むしろ、このようなヘドロのようなデータを濾過して人間に見せているメーラーってすごいんだな。*3

*1:10年以上前かな？

*2:それでもたまにありますが

*3:自分のまわりであまり良い評判を聞かないWindows Live Mailだって何気に凄い！

最近の"プログラマーの毎日を少しだけ有意義にする習慣"

プログラマー 仕事

以前こんなことを書いてました。

プログラマーの毎日を少しだけ有意義にする習慣 - 何か着ていればいいよ

で、習慣とか言って実際はなかなか習慣化出来ていませんでした。*1

でも、最近うまくいっているのがポモドーロテクニックとの組み合わせ。

数ポモドーロこなして取る少し長め休憩時間に上の記事で言っている、普段使っているツールのあまり使わない機能を使ってみるというのをやっています。

休息時間に頭は少し休めたいけどぼんやりもしたくないときいい感じなんじゃないかな？

*1:忙しいとつい忘れちゃったり