THE HIRO Says

2016-03-13

『組織にテストを書く文化を根付かせる戦略と戦術』の再演に参加してきました

2016年3月11日(金)に、『再演 ~ 組織にテストを書く文化を根付かせる戦略と戦術 +α』というイベントに参加してきました。

@t_wadaさんの下記スライドが、今まさに自分がやっているテスト自動化支援・アジャイル支援のヒント満載だったため、どうしても直接お話を伺いたく参加した次第です。

『組織にテストを書く文化を根付かせる戦略と戦術』

http://www.slideshare.net/t_wada/test-strategy-and-tactics


以下、個人的に気付きがあった点のメモです。



戦略編(6-19ページ)

7ページ目
  • 導入を目的にしてはいけない。
    • ついやりがち。
    • 現実を見せ、現実に即した解決策で改善していくことになる。(伊藤)

11ページ目
  • 文化を変えるのには、2-5年はかかるとのこと。
  • 環境は変わり続けるので、コードに触れないわけにはいかない。

13ページ目
  • AS-IS & NotToBeから始める。
  • 人は自分の速度でしか成長できない。
    • プロジェクトについても、同様のことが言える。(伊藤)
      • 早過ぎてもダメ、遅過ぎてもダメ。
      • 自分の支援しているプロジェクトの進め方は妥当だったか?

14ページ目
  • 人を知る
    • メンバーが何によってモチベートされるかを考えてアクションすべし。

15ページ目
  • リファクタリングのジレンマ(独立タスク化すると、却って行われなくなってしまう)
    • ビジネス価値を提供していないように見えてしまうため。

17ページ目
  • 全ては変化する

18ページ目

19ページ目
  • テストは品質を上げない
    • 品質は分かるようになる
    • 品質を上げるのは、設計とプログラミング
    • テストを作って既存プロダクトを「壊す」ことで、プロジェクトに改善の必要を気づかせることは可能。(伊藤)


戦術編(20-33ページ)

21ページ目
  • どこからやるか?
    • 不具合駆動
    • マネーパス etc.

22ページ目
  • テスト指針(Lean from the trenches)
    • リスク
    • 手動テストのコスト
    • テストの自動化コスト

23ページ目
  • 誰とやるか?
    • 全員でやるのではなく、できる人を少しずつ増やして行く方が良い。
    • 教えられる人を増やす。
    • ペアプロでひとりずつ。
      • いつも「遅すぎないか」というジレンマに襲われているけれども、これでいいのだという安堵感を感じた次第。(伊藤)

24ページ目
  • 最初から全部やろうとはしないこと!

25ページ目
  • こだわるべきところ・優先度
    • repeatability
    • independent

27ページ目

29ページ目
  • コードレビューだけでも、改善につながる。
    • 誰かに見られる → 改善

30ページ目
  • 実装を変えることを後押しするテストをつくるべし。

31ページ目
  • (テストの)サンプル・デモは大事。
  • 動かして初めて実感してもらえる


所感

現在PHPのテスト自動化支援を主にやっているのですが、必ずしもユニットテストにこだわらなくても良いのかな、と感じた次第です。というのも、PHPにはstaticベースのフレームワークが多くて、モックを差し挟んで…といったレガシーコード改善ガイドチックなテクニックがほとんど使えない。で、それでも無理矢理テストを書こうとすると、DBAPIを直接叩くものになってしまい、そこがビルドを壊す脆い点になってしまうのではないかと…

しかし今回の講演で、出来るところから確実に改善すべしと伺い、別にそんなテストでも無いよりまし、プロダクトの改善につながるのであれば良いのではないかと。

そういう気付きを得られたという意味では、@t_wadaさんに感謝です。



参考資料

2015-12-02

プロジェクトメトリクスのワークショップ at プロダクトオーナー祭り2015

去る2015年11月28日(土)に、『プロダクトオーナー祭り2015 〜世界を変えるのは俺たちだ!〜』というイベントに参加し、プロジェクトメトリクスのワークショップを開催してきました。

ありがたいことに、ワークショップ参加者は21名の満員でした。また、プロダクトオーナー祭り全体でのワークショップ満足度No.1にも選んでいただきました。参加していただいた皆さん、場を提供してくださった関さん初めスタッフの皆さんに感謝です。

ワークショップで使用した資料は下記になります。

内容的には、以前開催した「ゆるぎー」「DevLOVE関西」のものとほぼ同じですが、参加者同士でフィードバックを与え合う機会と、それを反映する機会とに時間を多めに割くようにしました。

参考までに、参加者の作成したプロジェクトメトリクスたちをご紹介させていただきます。

f:id:hageyahhoo:20151128191256j:image

f:id:hageyahhoo:20151128191606j:image

f:id:hageyahhoo:20151128191613j:image

f:id:hageyahhoo:20151128191810j:image

f:id:hageyahhoo:20151128192013j:image

f:id:hageyahhoo:20151128192230j:image


所感

参加者が既にプロだったこともあるせいか(?)、お題とその考え方・進め方をお伝えさえすれば皆さん自律的にチームを組み、私から指示をしなくてもフィードバックを与え合う姿勢が既に出来ていました。一方でプロジェクトメトリクスには、そうした自律性やチーム学習を促す側面で、私の想像以上に効果があるのかも知れないと思った次第です。

今後も、プロジェクトメトリクスについて調査・研究・実験を繰り返して、皆さんのプラスになる知見をより提供できれば幸いです。

2015-10-04

Nexusフレームワークについて簡単に調べてみた

RyuzeeさんTwitterで、InfoQの『スクラムのためのNexus Guideを公開』という記事を教えてもらったので読んでみました。

Android開発の記事かな?と思ったら、『スクラムガイド』で有名なKen Schwaberさんによる、スクラムをより大きなプロダクト・チームで活用するためにスケールするための新しいフレームワークなんですね。

既にNexus Guide』を公開しているということだったので、実際に読んでみました。ちなみに『Nexus Guide』は、https://www.scrum.org/の右下の「HOW DO YOU SCALE SCRUM?」をクリックすると閲覧することができます。



ポイント

基本は、スクラムをベースとしたフレームワークです。但し、以下の点に特徴があります。
  • 3-9チームで、1つのプロダクト/ソフトウェアを開発するケースを想定しています。
  • 1スプリント毎に、各チームの成果物(ソフトウェア)を統合します。
    • これを実現するために、「自動化」の必要性が言及されています。


複数チームで1つのものを作るので、以下のものを各チーム間で調整・統合する必要が出てきます。

これらを調整するために、既存のスクラムの上に以下の「調整・統合の場」的なイベントと、Nexus Integration Team」という調整チーム(スクラムチームとは別)とを設けています。

  • Nexus Sprint Planning(各チームで行うものとは別に行う)
  • Nexus Daily Scrum(各チームで行うものとは別に行う)
  • Nexus Sprint Review(全チームで一緒に行う)
  • Nexus Sprint Retrospective(各チームで行うものとは別に行う)
    • 次のトライをどう「見える化」してトラックするか(≒メトリクスを取るか)といったことにも言及されています。
  • Refinement


依存を如何に扱うか?

3-9チームで1つのプロダクト/ソフトウェアを開発し、スプリント毎に統合するため、各チーム間での依存関係をどう扱うかが鍵になります。依存関係の解決方法として、次の3つが言及されています。

  • 依存を洗練する
  • 依存を取り除く
  • 依存を極小化する


スクラム色が濃い

以下の点は、スクラムの影響が濃い、もしくは同一だと言えそうです。

  • Transparency(透明性)
  • Inspection(検査)
  • Adaptation(適応)
  • Definition of Done(DoD)


「スケール」という次のメインテーマ

Nexusの他にも、近年スクラムをスケールするためのフレームワークや方法論が多く提唱されるようになってきました。


いよいよ、「スケール」について広く真剣に考える時が来たのかも知れませんね。

2015-09-23

退職。

一部の方にはお伝えさせていただきましたが、2015年10月15日付けで、楽天株式会社を退職することとなりました。

3年弱の在籍ではありましたが、自分自身のキャリアの中で一番手応えのある職場でした。入社直後から多くの難題にぶち当たりましたが、その都度手を差し伸べて下さった方たち・仲間たちがいたおかげで、この刺激的で激しい会社を生き延び続けることができました。

また、会社のニックネーム制で「The Hiro」(The Rockリスペクト)と名乗っていたのですが、それをもじって「ヒーロー」「スーパーヒーロー」といじっていただいたことは、良い思い出です。

関わらせていただいた皆さんに、心から感謝の気持ちを伝えさせていただきます。



なぜ退職するのか?

アジャイルコーチ・自動化アーキテクトとして、現場に入ってチームを指導し、最強のチームを創るということに専念したいと考えたためです。

  • 組織が色々と変わりまして、これまでのようにアジャイルコーチ専任で仕事をすることが難しくなったという背景があります。
  • 自分自身の強みをより活かそうと試行錯誤した結果、改めてアジャイルコーチ・自動化アーキテクトが自分には合っているなという認識に至りました。
  • 楽天という会社自体は、今でも好きです。

次の会社では、アジャイルコーチ・自動化アーキテクト専任で働きます。



思い出

得たもの・残せたもの

多くの先生・仲間
  • 藤原大さんからは、現場から問題点を見つけ出す目からメンバーとの接し方、生き方に至るまで、非常に多くことを学ばせていただきました。
  • 及部敬雄さんとは、最大のライバルかつ入社時からの個人的メンターとして、言い尽くせない程お世話になりました。(なお、この師弟関係は生涯続きます。)
  • 楽天技術研究所の森正弥さんには、社外発表の機会の提供、仕事で行き詰まったときのアドバイス、「スーパーヒーロー」の称号、テスト駆動開発グループの設立など、どれほどお世話になったことか。
  • 直井和久さんには、大組織でのリーダーシップの示し方、またエンジニアを成長させるための基盤整備などについて、多くのことを学ばせていただきました。また、Agile Japan 2015に共に登壇させていただいて、社外的にも成果を残せたことが、個人的には嬉しいです。

他にも、一人一人名前を挙げて感謝の念をお伝えしたいのですが、Word文書で100枚でも不足しそうな勢いですので、個別にお伝えさせていただきます。



今だから書けること-プロジェクトメトリクスの由来

SIerからServicerに移ってきて

前にいた会社・部署は、典型的なSIerでした。そこでは技術的な貢献や改善(例:自動化の推進で作業時間を9割削減など)が評価されることはまずなく、上司・プロジェクトマネージャの指示に従うことを強いられていた側面がどうしてもありました。

一方で楽天に移ってからは、自分自身の成果を自力で上司に示すことが求められました。特に数値で成果を見せることを。この点が最初のカルチャーショックでした。(この変化に最初は耐えきれず、入社1ヶ月で歯を1本折りました。)


プロジェクトメトリクスへの昇華

一方で、成果の見せ方を求められる裏に、私が最初に属した組織に次の問題が潜んでいることも分かりました。

  • 具体的な成果目標を設定していなかった/できていなかった
  • 成果を測る指標を持ち合わせていなかった
    • そのため、単純な仕事量の多さで成果としようとしており、結果多くのメンバーを疲弊させていた
  • 成果指標を次の施策に活かす仕組み・考え方が欠落していた

そのため私は、具体的な成果目標の設定・成果指標の開発・成果指標に基づいた改善施策というものを創り上げることにしました。これが、昨今私が多用している「プロジェクトメトリクス」の始まりです。


「プロジェクト」メトリクスという表現

当初は単に「メトリクス」と表現していたのですが、後にQAの方と多く仕事をさせていただくようになり、QAでいうところの「メトリクス」との混同・誤解が生じ易いことが分かりました。そこで、現場のプロジェクトで使うものだから、「プロジェクト」メトリクスと呼称することにしました。

一方で昨今では、「アジャイルメトリクス」という表現が海外で出ているようです。



最後に

今までは、「楽天の伊藤宏幸」と、会社の名前に守られている部分が多分にあったと考えています。

楽天」という会社名がなくなっても生きて行けることを、着実に証明し続けて行く所存です。いままでお世話になった方たちへの恩返しをし続けます。

2015-08-27

Test Kitchenが想定通り動作しない場合の解決方法

ChefとServerspecでテスト駆動開発を試したいと思い、こちらの書籍に記載のあったTest Kitchenを試してみたところ、想定通りに動作せずにハマりました。ハマった箇所2点とその原因および解決策を、下記にまとめます。



このエントリーの前提条件

ツール バージョン
OS Mac OS X 10.9.5
Chef-solo 12.3.0
Knife-solo0.4.2
Ruby 2.0.0p0
Vagrant 1.7.2
Virtualbox4.3.24

Provisioningは、Vagrantを経由してVirtualbox上のVMに対して行います。



課題1.CentOS 6.4/6.5でインスタンスが生成できない!

(1)問題
  • "kitchen init"コマンドで生成した".kitchen.yml"ファイルに最初から定義されている"centos-6.4"を使用しようとすると、後述のエラーが発生する。
  • CentOSのバージョンを"centos-6.5"へ変更しても、同様のエラーが発生する。

".kitchen.yml"のデフォルト値(必要な箇所のみ)

platforms:
  - name: ubuntu-12.04
  - name: centos-6.4

suites:
  - name: default

インスタンス生成前

$ kitchen list
Instance           Driver   Provisioner  Verifier  Transport  Last Action
default-centos-64  Vagrant  ChefSolo     Busser    Ssh        <Not Created>

インスタンス生成時のエラーメッセージ

$ kitchen create default-centos-64
(中略)
Couldn't open file <ワーキングディレクトリ>/.kitchen/kitchen-vagrant/<xxx>-default-centos-64/centos-6.4
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Failed to complete #create action: [Expected process to exit with [0], but received '1'
    ---- Begin output of vagrant up --no-provision --provider virtualbox ----
STDOUT: Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'centos-6.4' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Adding box 'centos-6.4' (v0) for provider: virtualbox
    default: Downloading: centos-6.4

STDERR: An error occurred while downloading the remote file. The error message, if any, is reproduced below. Please fix this error and try again.

Couldn't open file <ワーキングディレクトリ>/.kitchen/kitchen-vagrant/<xxx>-default-centos-64/centos-6.4
 ---- End output of vagrant up --no-provision --provider virtualbox ----
Ran vagrant up --no-provision --provider virtualbox returned 1]
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

(2)原因

2015/08/25時点でBentoで配布されているboxは、"centos-6.6"centos-6.4/6.5は配布されていないためエラーとなる。

(参考)https://github.com/test-kitchen/test-kitchen/issues/663


(3)解決策

".kitchen.yml"ファイルのCentOSのバージョンを、"centos-6.6"へ変更する。


".kitchen.yml"の修正後の値(必要な箇所のみ)

platforms:
  - name: centos-6.6

suites:
  - name: default

インスタンス生成前

$ kitchen list
Instance           Driver   Provisioner  Verifier  Transport  Last Action
default-centos-66  Vagrant  ChefSolo     Busser    Ssh        <Not Created>

インスタンス生成時(正常終了)

$ kitchen create default-centos-66
-----> Starting Kitchen (v1.4.1)
-----> Creating <default-centos-66>...
       Bringing machine 'default' up with 'virtualbox' provider...
       ==> default: VirtualBox VM is already running.
       [SSH] Established
       Vagrant instance <default-centos-66> created.
       Finished creating <default-centos-66> (0m4.44s).
-----> Kitchen is finished. (0m5.75s)

インスタンス生成後

$ kitchen list
Instance           Driver   Provisioner  Verifier  Transport  Last Action
default-centos-66  Vagrant  ChefSolo     Busser    Ssh        Created


課題2.Recipeが見つからない!

(1)問題
  • "kitchen converge <インスタンス名>"コマンドで、作成したRecipeを適用しようとすると、下記のエラーが発生する。
ERROR: Running exception handlers
Running handlers complete
ERROR: Exception handlers complete
Chef Client failed. 0 resources updated in 1.24109821 seconds
FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
ERROR: Cookbook <Recipe名> not found. If you're loading config from another cookbook, make sure you configure the dependency in your metadata
FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

Converge failed on instance <default-centos-66>.
Please see .kitchen/logs/default-centos-66.log for more details
 ------Exception-------
Class: Kitchen::ActionFailed
Message: SSH exited (1) for command: [sh -c '
sudo -E /opt/chef/bin/chef-solo --config /tmp/kitchen/solo.rb --log_level auto --force-formatter --no-color --json-attributes /tmp/kitchen/dna.json
']

(2)原因

Berkshelfが、Berksfileに未定義のcookbookをインスタンスにロードしないように振る舞うため。

インスタンス上のワークディレクトリである"/tmp/kitchen"には、cookbooksディレクトリはあるが、"site-cookbooks"ディレクトリはない。この挙動は、下記の実行時ログからも確認できる。

 INFO -- default-centos-66: Preparing dna.json

 INFO -- default-centos-66: Resolving cookbook dependencies with Berkshelf 3.3.0...

 INFO -- default-centos-66: Removing non-cookbook files before transfer

 INFO -- default-centos-66: Preparing data_bags

 INFO -- default-centos-66: Preparing environments

 INFO -- default-centos-66: Preparing nodes

 INFO -- default-centos-66: Preparing roles

 INFO -- default-centos-66: Preparing solo.rb


(3)解決策
  1. Berkshelfに、site-cookbooksを参照するRecipeの情報を追記する。
    1. (参考)cookbook 'config', path: './site-cookbooks/config'
  2. kitchen destroy -> kitchen create -> kitchen convergeをやり直す。

(4)補足

http://stackoverflow.com/questions/27687647/vagrant-chef-cookbook-not-found

こちらには、「vagrant-berkshelfプラグインが悪さをしているので、これを除去すればよい」との記述がある。しかし今回調査したところ、vagrant-berkshelfプラグインインストールされていなかった。

$ vagrant plugin list
sahara (0.0.17)
vagrant-omnibus (1.4.1)
vagrant-share (1.1.4, system)


最後に

枯れていない技術に触れる一番の楽しさは、こうした問題の解決策を考え試して、実際に解決していくことにありますね。そのことを改めて痛感。