The HIRO Says

If you smell what The HIRO is cooking!!!

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

Agile ProjectMetrics

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

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

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

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

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





所感

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

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

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

Agile Scrum

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スプリント毎に、各チームの成果物（ソフトウェア）を統合します。
    • これを実現するために、「自動化」の必要性が言及されています。
複数チームで１つのものを作るので、以下のものを各チーム間で調整・統合する必要が出てきます。
  • 要求（requirements）
  • ドメイン知識（domain knowledge）
  • ソフトウェア・テスト成果物（software/test artifacts）


これらを調整するために、既存のスクラムの上に以下の「調整・統合の場」的なイベントと、「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年10月15日付けで、楽天株式会社を退職することとなりました。

3年弱の在籍ではありましたが、自分自身のキャリアの中で一番手応えのある職場でした。入社直後から多くの難題にぶち当たりましたが、その都度手を差し伸べて下さった方たち・仲間たちがいたおかげで、この刺激的で激しい会社を生き延び続けることができました。
また、会社のニックネーム制で「The Hiro」（The Rockリスペクト）と名乗っていたのですが、それをもじって「ヒーロー」「スーパーヒーロー」といじっていただいたことは、良い思い出です。
関わらせていただいた皆さんに、心から感謝の気持ちを伝えさせていただきます。


なぜ退職するのか？

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

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


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


思い出

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


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


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

SIerからServicerに移ってきて

前にいた会社・部署は、典型的なSIerでした。そこでは技術的な貢献や改善（例：自動化の推進で作業時間を9割削減など）が評価されることはまずなく、上司・プロジェクトマネージャの指示に従うことを強いられていた側面がどうしてもありました。
一方で楽天に移ってからは、自分自身の成果を自力で上司に示すことが求められました。特に数値で成果を見せることを。この点が最初のカルチャーショックでした。（この変化に最初は耐えきれず、入社１ヶ月で歯を１本折りました。）

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

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

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


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

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

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

Agile Metrics in Action: How to measure and improve team performance

Agile Metrics in Action: How to measure and improve team performance


最後に

今までは、「楽天の伊藤宏幸」と、会社の名前に守られている部分が多分にあったと考えています。
「楽天」という会社名がなくなっても生きて行けることを、着実に証明し続けて行く所存です。いままでお世話になった方たちへの恩返しをし続けます。

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

Infrastructure as Code

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)

Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus)

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


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

ツール バージョン
OS Mac OS X 10.9.5
Chef-solo 12.3.0
Knife-solo 0.4.2
Ruby 2.0.0p0
Vagrant 1.7.2
Virtualbox 4.3.24

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


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

（１）問題
  • "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


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

$ kitchen create default-centos-64
（中略）
Couldn't open file <ワーキングディレクトリ>/.kitchen/kitchen-vagrant/-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/-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
（２）原因

2015/08/25時点でBentoで配布されているboxは、"centos-6.6"。centos-6.4/6.5は配布されていないためエラーとなる。
（参考）https://github.com/test-kitchen/test-kitchen/issues/663

（３）解決策

".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


インスタンス生成時（正常終了）

$ kitchen create default-centos-66

    

  • 

      

    • 

        

      • 

          

        • 

            

          • > Starting Kitchen (v1.4.1)
            • 

          • > Creating ...
            • 

          • 

        • 

      • 

    • 

       Bringing machine 'default' up with 'virtualbox' provider...
       ==> default: VirtualBox VM is already running.
       [SSH] Established
       Vagrant instance  created.
       Finished creating  (0m4.44s).

    

  • 

      

    • 

        

      • 

          

        • 

            

          • > Kitchen is finished. (0m5.75s)
            • 

          • 

        • 

      • 

    •


インスタンス生成後

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

課題２.Recipeが見つからない！

（１）問題
  • "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  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 .
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
']
（２）原因

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

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

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)

最後に

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

【備忘録】活動記録


これまでに発表した資料や活動内容について、備忘録＆棚卸しとして記録していきます。適宜更新です。

2015/04/16　Agile Japan 2015

2015/03/07　メトリクスによる「見える化」のススメ: エッセンシャル・リーン at DevLOVE関西

→ブログまとめ

2015/02/23　認定スクラムプロフェッショナル（Certified Scrum Professional・CSP）取得


→How to acquire CSP／「認定スクラムプロフェッショナル」の資格を取得する方法

2014/12/16 - 2015/04/09　@ITでの連載（スマートフォン開発におけるシステムテスト自動化ツールについて）

  1. iOS／AndroidにCucumberのBDDをもたらすテストフレームワークCalabashの基礎知識とインストール
  2. Calabash-Androidでテストシナリオを作成する方法
  3. Calabash-AndroidによるBDDの実践とJenkinsによる「Living documentation」
  4. Calabash-Androidのテスト高速化、GPS、スクショ、データ駆動型テスト

2014/09/19　第八回ゆるぎー メトリクスによる「見える化」のススメ: エッセンシャル・リーン

→ブログまとめ

2014/09/06　XP祭り2014

1. 『国際会議 Agile2014の風 〜とある参加報告〜』


2. LT

2014/08/23　DevLOVE現場甲子園2014 東日本大会

2014/07/29　Agile2014

2014/03/13　情報処理学会　第７６回全国大会

『ビッグデータ時代に立ち向かうイノベイティブなシステム開発〜Agile, Big-data, Cloud, DevOpsのプラクティスから 〜』

2014/02/14　Developers Summit 2014

OpenJamにて、以下の資料を発表。

2014/01/15　Regional Scrum Gathering Tokyo 2014

OpenJamにて、2度この資料を発表。

2013/12/13　Android Test Casual Talks #1

2013/11/09　DevLOVE現場甲子園2013

下記の元ネタを公開。

2013/11/06　変化の担い手チェンジエージェントの実践を追え！

台湾の「DevOps 2015 Conference」に、キーノートスピーカーとして登壇してきます

Agile

2015年7月20日（月・祭日）の朝、それは突然やってきました。

台湾のIThomeの担当者を名乗る人物から、9月1日に台北で開催される「DevOps 2015 Conference」に、キーノートスピーカーとして登壇してくれないか？というオファーメールが届きました。


冗談にしては悪質だぞ？と思ってもう一度読み直してみたら、以下のことが分かりました。

  • IThomeは、日本で言うところの@ITに相当するものらしいこと。
  • 私の上司が6月に、IThome主催の「Cloud & Datacenter EXPO」に登壇したこと。
  • 担当者が「Agile Japan 2015」の私の発表資料に目を通してくれて、内容に理解を示してくれてオファーをしてくれたこと。

以下の資料、日本でも良く言えば玄人受け、悪く言うと広く一般的には受入れられていない印象だったので、このオファーは正直意外であり、嬉しくもありました。（私の生きる世界は日本ではないのかな〜などと思ったりw）


会社と調整した結果、特に問題ないとのことだったので、オファーを受けることとしました。


早速、スピーカー情報も載せていただきました（中国語がワカラナイ…）
http://devopsconf.ithome.com.tw/speaker.html#day1_%E4%BC%8A%E8%97%A4%20%E5%AE%8F%E5%B9%B8


英語版＆英語で40分好きに話して良いとのことだったので、「Agile Japan 2015」の時には時間的制約でお話できなかった部分についてもお話してこようと思います。

D10 地球の歩き方 台湾 2015~2016

D10 地球の歩き方 台湾 2015~2016


補足

KAVALANという、世界的にも大人気の台湾製ウィスキーがあるらしいですね〜。ちょっと楽しみ♪

カバラン クラシック シングルモルトウイスキー 700ml.hn　KAVALAN CLASSIC SINGLE MALT WHISKY　正規品

カバラン クラシック シングルモルトウイスキー 700ml.hn　KAVALAN CLASSIC SINGLE MALT WHISKY　正規品

http://www.emanak.co.jp/kavalan/

補足２

8月3日（月）の午後、Agile2014のも別途発表してくれないか？というオファーをいただく。現在調整中。まさかの２日連続登壇か！？

レビュー頻度：レビューによる作業の割り込みを「見える化」する

Agile Lean ProjectMetrics

解決したい課題

例えば、スクラムを採用しているケースで、スプリント期間中に全てのスプリントバックログアイテムを完了できないことがある。その原因として、（Pull Requestなどによる）レビュー依頼による割り込みが多いという意見が出ることがある。しかし、具体的にどの程度の頻度・量のレビュー依頼があるのか、コレガワカラナイ。これが分からないと、適切な対策を打つことが難しい。

解決方法

レビューの頻度を記録する。

具体的には、レビューを依頼された回数（Pull Requestの依頼数など）とその成否をdailyで記録し、一定期間毎（日次・週次など）にその傾向を分析してみる。

利点

  • 作業の遅れや割り込みを、客観的な数値で他者（特にマネージャ）に説明できるようになる。
  • レビューの頻度と量が分かるため、減らすための具体策がチームから出やすくなる。

注意点

初めのうちは、記録自体を面倒だとチームメンバーに思われがち。その場合、色付きシールを使うなど、記録に楽しさを加えてみると長続きしやすい。

補足

Henrik Knibergさんの『Scrum and XP from the Trenches』などにある dots を応用したもの。

関連するメトリクス

割込率

参考文献・資料

CHANGELOG

  • 2015/08/02 第１版公開