メソッド屋のブログ

米マイクロソフト Software Development Engineer 牛尾の日記です。ソフトウェア開発の上手なやり方を追求するのがライフワーク。本ブログは、個人の意見であり、所属会社とは関係がありません。

Serverlessconf 最高でした!ーAWSな人に贈る、最も簡単に分かる Azure の Serverless

10/1に、ServerlessConf 出店ブース始め、会場におられる方も、AWSを利用されている方がほとんどだった様子だったので、講演では、AWSを普段使っておられる方を想定して、お話しをしました。ただ、盛り上がった一方、詳細なアーキテクチャが知りたかったとか、AWSのλとの違いがわからなかったというご意見をいただきましたので、そういうフォローアップ記事を書いてみようと思いました。

f:id:simplearchitect:20161005075246j:plain

 個人的には、Serverless は、Microservicesの次のパラダイムぐらいの勢いがありますが、どのような利用がされているかのアイデアとその未来を知りたくて参加しました。ちなみに、スポンサーセッションと思われていますが、一応、スポンサーセッションではなく、サブミッションを出しています。本イベントは、非常に熱気があり、学びも多く、素晴らしいイベントでした。こんなにも素晴らしいイベントをこんなにも早く日本でも開催いただいた、主催の吉田さんに本当に感謝です!

では、早速、AWSな人に贈る Azure のServerless のお話し、そして最後に、私が感じたServerless の未来についてお話ししてみたいと思います。

1. 講演概要

 講演の概要は、9/26-30 まさに直前に行われたMicrosoft Igniteでの発表の資料を中心に、いくつかのデモを加えて行われたものです。講演資料はこちらになります。講演資料は、当日、日本人と海外の方が両方おられたので、英語の資料で、日本語で講演というスタイルにしました。

2. Azure Functions (AWSのλっぽいもの)

Azureでの、Serverless のサービスは、Azure Functions というサービスです。一緒に講演した、佐藤(NEO)直生さんが、当日早速 Getting Started 等のURLを整理したブログを書いてくれたので共有したいと思います。

azure.microsoft.com

[ServerlessConf Tokyo] Serverless Patterns with Azure Functions (Azure Functionsでのサーバーレス パターン)satonaoki.wordpress.com

 このサービスは、元々 Azure で使われていた、WebJobs という仕組みが元になっています。何らかのトリガーをきっかけに、バッチ等 の小さなプログラムを動かすこの仕組みは、Serverless のAzure Functions を動作させるためには最適な仕組みでした。

f:id:simplearchitect:20161005075738j:plain

azure.microsoft.com

 AWS のλに相当する Azure Functions は Azure の PaaS 基盤である App Service の上に構築された仕組みで、Web Appsをはじめとした、例えばWebのPaaSを使っていれば、そこにサーバーを新たに建てることなく、バッチを実行することができました。  そして、C#はもちろんの事、様々な言語で動作します。中身は現在のところ、Windowsサーバーがベースとなった、Windowsの技術がバックグラウンドにあります。ただ、このWebJobsを創るためには、そこまで大変ではありませんが、ちょっとめんどくさい部分があったのは事実でした。

2.1. トリガ

 Azure Functions では、Severless を実現するため、この仕組みをつかって、そもそもの Web Appsすらも起動することなくこのサービスを利用可能にしました。想定するシナリオとしては

f:id:simplearchitect:20161005075949p:plain

  • Timer
  • Data Processing
  • Webhook + API

 それに加えて、Blobストレージ(S3相当)へファイルをアップロードする、Queueにメッセージを投げるなどのきっかけを元に、プログラムを実行します。結果は、Blob(S3相当)、HTTP, ServiceBus (SQS相当)、データベース、通知のハブや、SendGrid, Twilio へのサポートをテンプレートレベルでサポートしており、他のものも自分でコードを書けば何とでもなります。

2.2. インプット / アウトプット

インプット、アウトプットのリソースとしては、様々なサービス、プロトコルと連携します。下記の図がわかりやすいと思います。

f:id:simplearchitect:20161005081743j:plain

Azure Functions の画面では次のようなイメージでインプット、アウトプットを設定できますし、設定ファイルでももちろん設定できます。

f:id:simplearchitect:20161005081302p:plain

f:id:simplearchitect:20161005081321p:plain

2.3. 言語

使用できる言語は、C#, Node.js, F#, Python, PHP, 等、、、と書いています。他にもBashや、Cmd、PowerShell等も動作するみたいですし、私の同僚は、Goを動かすものを書いていました。

github.com

2.4. プログラム構成

 これはC#の例ですが、下記のようなプログラム構成になっており、run.csxがC#のファイルです。function.json が設定ファイル。そしてproject.json は、nugetパッケージ(npm や、Ruby gemsの様なもの)を取得するために使えるファイルです。

function.json

{
  "bindings": [
    {
      "name": "myBlob",
      "type": "blobTrigger",
      "direction": "in",
      "path": "pictures",
      "connection": "pooryou_STORAGE"
    }
  ],
  "disabled": false
}

project.json

{
  "frameworks": {
    "net46":{
      "dependencies": {
        "Microsoft.ProjectOxford.Face": "1.2.1.2"
      }
    }
   }
}

今回私がデモで使用したソースコードは、簡単ですが、GitHubにあげておきました。より細かい情報は、佐藤さんがPowerPointの資料に書いてくれています。より細かいプログラム構造(nodeの場合)、使える言語、トリガの種類などです。

github.com

2.5. AWS λと比較したメリット

ブースにいるときにAWSを普段使っておられる方から、「ここはAzureのほうがいいね!」と言っていただいたポイントがいくつかあったので、それを共有しておきたいと思います。私も深くAWSの事を知っているわけではありませんが、あくまでブースに来ていただいた人から学んだことですので、細かいミスなどはご容赦ください。また、そういうものがあれば本ブログをリンクして是非皆様のブログでフォローしていただければと思います。

これは個人的な意見ですが、ざっくりうと「すべてをコントロールしたい人は AWS」、「レールに乗って楽したい人は Azure」というイメージを持っています。  もちろん、Azure でも、Linux/Windows の IaaSとかは使えますが、Azureの面白さはやっぱり、PaaSや、SaaSだと思います。またこの辺りは別のポストでお話ししてみたいので、割愛します。

Azure Functionsに絞ると、ざっくりいうと次の通りです。

  • わかりやすいGUI
  • 様々なトリガ、イベント
  • プログラム構造の透明化
  • デバッグ機能の充実
  • Azure の機能との連携
  • API Gateway不要

2.5.1. わかりやすい GUI

統一されたわかりやすい GUIは、Azure の良さの一つです。 Azure Functions の場合は、結構 Azure で操作する、エディタがなかなかイケています。なぜなら、このエディタはかのエリック・ガンマが作成した、Visual Studio Online の技術が使われているからです。彼もマイクロソフトの一員です。結構これだけでも、自分的にはうれしい!

f:id:simplearchitect:20161005083911p:plain

2.5.2. 様々なトリガ・イベント

Serverless の選定要素の一つを現在実現されているもののみで考えると、どれぐらいいろいろな、トリガや言語に対応しているか?というのがキーになると思います。Azure Functions では、Blob(S3相当), Timer, IoT/EventHub, Webhook, http, Queue(SQS相当), SaaS SendGrit, ServiceBus等のトリガに対して、C#, Node, Bash, PowerShell, Python, PHP等多くの言語に対応しています。

f:id:simplearchitect:20161005081743j:plain

2.5.3. プログラム構造の透明化

 λでは、サーバレスのコードを書くとそれが、どういう形で格納されているかわかりません。一方 Azure Functions では、先に説明 した通り、構造が明確であり、サーバーレスですので、しばらくしたら寝てしまいますが、サーバーぽいものの中にどのように格納されている かが、KUDOというツールで見ることができます。また、パッケージマネージャ(npm, nuget)等も、使えるというのも利点です。

2.5.4. デバッグ機能の充実

 デバッグも先のKUDUを使ってログを見たり、コマンドをたたいてみたりということができて大変便利です。

f:id:simplearchitect:20161005153506p:plain

2.5.5. Azure の機能との連携

 これはあまり比較のメリットではありませんが、Serverless の場合、いかに楽にnano serviceを書けるのががポイントになると思います。そのケースで、Azure はいろんなサービスがあり、Azure Functions と連携しているのでこれはラクチンです。

2.5.6. API Gateway不要

 AWSAPI Gateway に相当する httpのトリガが用意されていますので、API Gatewayの様なものを設置する必要がありません。つまりそこに課金もされません。

もちろん、λの利点もあると思いますので、このようなメリットデメリットを考慮して皆様の環境で便利なほうを是非ご利用ください!先行されておられるAWSさんと比較してもなかなかのものですね。(2016/10/3時点の情報)

 ちなみに、ブースの会場で、AWSの方と話したのですが、「競合とかなんとかいうより、Cloudをもっと多くの人に使ってほしいですよね」という素敵な話されていて、本当にその通りだなと思いました。DevOps もそうですが、競合とかそんなパイを食い合うようなセコい話ではなくて、もっと多くの人がCloudを使うようになれば、みんなHappyになってくると思います。

3.デモンストレーション

 当日じっくり解説する時間がなかったので、こちらのデモの内容とコードを公開しておこうと思います。このデモは、Unityと、Cognitive Service という、マイクロソフトのAIの研究の成果を使ったAPIサービスを利用しています。

f:id:simplearchitect:20161005084400p:plain

github.com

弊社の藤本氏が作成した、Interactive いちゃLoveゲームというUnityで作られたゲームが元になっています。このゲームは、Cognitive Service のEmotion APIという人の顔の感情を読み取るAPIを使っています。ゲームをやっている人の感情に合わせてゲームの反応を変えるというデモンストレーションです。スペースバーを押すと、PCのカメラで画像を撮り、それを、Emotion APIにRESTベースで送付して感情分析をして、キャラクターの振る舞いを変更しています。  キャラクターデザインと、ボイスは、ちょまどさんが担当しています。

 この面白いゲームの詳細を知りたい人は、次のブログポストで説明されています。

qiita.com

 私の方では、このゲームに対して、プレイヤーの属性を分析したいと思ったので、写真を撮った後に、それをBlobストレージ(S3相当)にアップし、それをトリガーに、Azure Functions(λ相当) を起動しています。Functionsで、Cognitive ServiceのFace APIをコールして、プレイヤーの年齢、感情、顔の輪郭、ひげの位置などの情報を分析して、それをSQLサーバーに送付しています。このFACEAPIを使うと、社員をいくつか覚えさせると、その人かどうかの判別を行うこともできます。  最後に、PowerBIというBIサービスにその情報を連携させて、分析を行うというデモでした。実際に、Serverless アーキテクチャを使うと、簡単に実装できたのでとても楽しかったです。パターンとしては、ある意味王道的な使い方ですが、本当にさっくり作ることができました。これは楽です!

f:id:simplearchitect:20161005084732j:plain

ご興味がある方は、ソースコードを置いておきましたので、ご参照ください。実は佐藤さんは、更に凄いCognitive Service を使い倒したデモを用意していましたが、時間の関係でお見せできませんでした。

4. Azure の関連情報

さて、AWSを使ったままでも使える、Cognitive Service 等の情報を共有しておきたいと思います。 Cognitive Service に関してはエバンジェリストの大森彩子さんがいい資料をたくさん作ってくれています。紹介したもの以外にも動画をリアルタイムに解析したり、画像/文章の感情分析したり、言語解析したり、翻訳したりとむっちゃ凄いサービスになっているので、個人的にも熱いサービスですが、REST-APIを呼ぶだけなので簡単に使えます。 次のような情報が日本語でもあるようです。

1. Cognitive Services の機能紹介などは MSDN Blog

blogs.msdn.microsoft.com

2. 実装方法など具体的な手順、コードなどは Qiita

qiita.com

3. 説明資料 (PPT)

docs.com

最初のステップとしては、以下の記事がおすすめです。

a. Cognitive Service でできることをざっと知りたい人向け (from ①)

「人間にとって “自然な” アクションの実装 ~ Microsoft Cognitive Services を始める前に」

blogs.msdn.microsoft.com

b. エンジニアで実際にコード書いて理解したい人向け (from ②)

人工知能パーツ Microsoft Cognitive Services を使った表情分析アプリを作ろう!」 Emotion API × JavaScript

qiita.com

Emotion API × Bot Framework (C#)編 qiita.com

Azure Functions のサンプル等

真壁さんがこんなサンプルとその解説を書いてくれています!

Azure Functionsで運用管理サーバレス生活(使用量データ取得編) · re-imagine

まだ仕掛ですがこんなものもある様子

github.com

もちろん、プレゼンテーション資料にもたくさんリンクをつけていますので、Azure Functions 自体の資料もお楽しみください。

5. Serverless に感じる未来

マーチンファウラー氏の、Serverless アーキテクチャで有名なサーバーレスですが、日本語では、会場にも来てブースをサポートしてくれていたデプロイ王子こと廣瀬一海さんの記事が私はわかりやすくて好きです。

japan.zdnet.com

今回のサーバーレスカンファレンスでも、いろいろ面白い事例や使い方が出てきてとても面白かったのですが、Nano Serviceという言葉もある通り、マイクロサービスとのつながりもとても強く感じました。

個人的な意見では、現在マイクロサービスの環境がたくさん出ています。例えば、DC/OSは、データセンタOSと呼ばれて、クラスタ自体をまるで1台のサーバーかのように扱い、リソースのアロケーションをしてくれたりします。大変未来的で私は大好きなプラットフォームですが、残念ながら現時点では、せっかくリソースを最適化してくれていますが、使わなくても、使っても、VMを上げておく必要があります。 デプロイ後もVMの存在を意識する必要があります。

現在のアーキテクチャでいうと、IaaS, Container, PaaS, Serverless の順番にどんどんやることが減っており、よりプログラムに集中できる環境ができています。ただ、現時点では、Serverless は、サーバーを立てるまでもないものや、グルーコード、イベントの処理などの簡単なもに対するユースケースがうまく行きそうです。

 しかし、ちょっと先の未来を見ていくと、DC/OSみたいなサービスは本来、VMの存在は忘れてリソース配置をしてくれるものだと思いますし、PaaSもできれば、VMの境目を意識しなくていいような状態になったとしたら、凄く楽で便利な世界が広がると思います。  つまり、それは思いっきりサーバーレスの世界で、サーバーレスで出来ることが、PaaSと、現時点でのサーバーレスで出来ることの間が縮まって、PaaSと見分けがつかなくなるときに、本当にサーバーレスの凄い世界がやってくる気がします。しかも、それは、たぶん数年とかからない気がします。私が知らないだけですでにそういうものが存在するかもしれませんが。

 また、Ito Naoya さんのパネルもすごく面白いお話しでしたが、最後に、「この事例は、本当は、Actorを使うとうまくいくと思う」という話をされておられました。個人的に、マイクロソフトの出しているものでも最もホットなものとして、Service Fabricというのがあります。 これ激アツです。これは、マイクロサービスのPaaSというとんでもないもので、もともと、Azureの各種サービスに使われていた基盤を公開したものです。Stateless/Stateful のサービス、そして、Actorをホストしてくれます。Stateful / Actor に関しては、デプロイするとサーバーに対して、レプリカを自動で組んでくれて、VMがダウンしたとしても、メモリを共有しているので、処理がそのまま継続して実行されたります。つまり、Netflixさんがやっているような、カオスモンキーを使うようなFault Injectionをぶちかませる基盤が最初から手に入る感じです。実際に、Service Fabric には、そのようなChaos Testing のAPIが最初から組み込まれています。

 そして、Actorをガンガンにサポートしています。次のゲームとかを見ると基盤の凄さが伝わるかもしれません。余談ですが熱くなってしまいました。

f:id:simplearchitect:20161005153957p:plain

web.ageofascent.com

このように、Azure も個人的には激熱なテクノロジーがたくさんあって、むっちゃ楽しいです。是非皆さんもよかったら楽しんでくださいね!

最後に

主催の吉田さんが、世界に向けて、日本のServerlessの盛り上がりを記事にされておられます。素晴らしいです!

read.acloud.guru

これは単に宣伝ですが、Azure が気になる方はこんなイベントもあります!

microsoft-events.jp

「それ、アジャイルできてへんのちゃいますか?」チェックリストの公開

 DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。

f:id:simplearchitect:20160923161901j:plain

 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます!」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。  スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。

1. 進化型設計ができていない

 アジャイル開発を実施するということは、単に繰り返し型で開発すればいいものではない。アジャイルは「変化に対応する」ことが大きな目的の一つになっている。スプリントや、イテレーションで繰り返し型の開発を行う場合、繰り返し型で開発を行って、変化があっても、メンテナンスを実施しやすいコードベースをキープしないといけない。  そうでなければ、早晩、プロジェクトはメンテ不可能になって破たんする。スプリントを通して、変化を受け入れても、メンテ可能な状態を保つには、十分な自動実行できるユニットテストが書かれている事、変更があったときに、それが自動で検査されること、そして、設計が「変化前提」の方式になっているということが重要だ。

 こういったアジャイルにおける「テクニカルプラクティス」やその「マインドセット」を学ぶには、Extreme Programming を学ぶのが一番おすすめだ。更に高度なテクニカルプラクティスを学ぶには、DevOps のプラクティスを学ぶとよい。

 アジャイルは世界的にスクラムが最も流行っているが、スクラムの作者も、「テクニカルプラクティス」を軽視しているわけではない。確か、Ken Schwaber がQ&Aでこんなことを言っていた。

Q: スクラムを採用しているが、エンジニアリングがちゃんとできないメンバーだったらどうなりますか?

A: うん。10倍のスピードでものができるよ。ただしゴミだけどね。

 スクラムを回していても、ソフトウェアを開発しているケースでは、「テクニカルプラクティス」を無視してしまうと、非常に危険なこと になる。

1.1. テスト駆動開発

 まず、最初におすすめしたいのが、テスト駆動開発(Test Driven Development) もしくは、振る舞い駆動開発(Behavior Driven Development) で開発するのをおすすめしている。最先端での議論では、TDDは死んだと言っている向きもあり、すべてをそれで開発しなくてもいいが、このいづれかの開発スタイルが「やろうと思ったら出来る」ということは絶対的に重要だ。だから、これが「できない」と言っているアジャイルベンダーは「エセ」といっても差し支えない。変更があったら当然テストが必要だが、変更が当然のアジャイルで、変更の度に全量手動テストなんてやってられないだろう。

 十分な単体テストを書こうと思うときに、後追いで、ユニットテストのコードを書くと死ぬほど難しく、複雑になる。本番のコードは甘くないのだ。じゃあどうする かというと、少しだけ先に「テストコード」を書いて、テスト実行。エラーになったのを確認してから、本番コードを数行実装、テストを実行してパスしたら、次のテストコードの実装を少しだけ、、、更に、コードが重複したら「リファクタリング」という方法でコードの設計を改善する。  このようなステップを踏んで開発をすると、常にテストコードが十分な状態で無理なく開発を進めることができる。イメージがわきやすいようにビデオを作成したので、参考にされるとよいかもしれない。15分程度だ。

docs.com

1.2. 進化型設計 

   次に進化型設計アジャイル以前の世界の設計の考え方は、Big Desgin Upfront という設計の方法だ。時間をかけて分析、設計を行って、そのあと実装やテストに入る方法だ。一方、アジャイル以降は、進化型設計と言われる方法をとっている。ソフトウェアエンジニアリングの技術、例えばデザインパターンなどの知識が変わるとかそういう話ではないが、設計の進め方が変わる感じだ。これは、次のようなパラダイムの変更が影響している。

f:id:simplearchitect:20160923162637p:plain

この図はExtreme Programmingから紹介された概念だ。1つの変更に対してどの程度変更のコストがかかるか?という図になっている。ウォータフォール開発時代は、一つの変更に対するコストは、後のフェーズに行けば行くほど指数関数的に高価になってしまっていた。例えば要件定義フェーズで問題を発見したら、要件定義書を直すだけだが、テストフェーズで発見したら、実装をおなして、設計書を書き直して、要件定義書を、、、といったように非常に高くついてしまう。  だから、要件を固めよう!ということを一生懸命やっていたのだ。一方アジャイルの世界では、テスト駆動開発などで適切に自動テストが書かれており、継続的インテグレーションにより、それが常時結合されて、テストされており、なおかつ、「進化型設計」を用いて、変更が簡単にできるのであれば、開発の後半になっても一つの変更に対するコストがあまり変わらないという状態を創れるようになった。

f:id:simplearchitect:20160923163844j:plain

Big Design Upfront で設計している場合、最初の設計で想定していない変更が入ると、どんどん設計は崩れていく。そもそも、設計に長く時間をかけても、現在のソフトウェアは実装するまで本当のところがわからないケースが多いため、実装せずに設計するのは相当に難しいことだ。一方、進化型設計は、テスト駆動等を用いて、テストがある状態をキープしているので、変更を行っても、おかしくなったらすぐわかるし、DRY(Don't Repeat Yourself)をはじめとしたマインドセットでコードが作られていると、1箇所変えるだけで変更ができるので、こういった、コストカーブが実現できるようになる。だから変更に強くなる。

 ということは、そういうことをしていなかったら、いくらアジャイルっぽくスプリントを回したところで、ソフトウェアはその変更に耐えられなくなってしまう。だから、テスト駆動などの方法を学んで、常にクリーンコードを書くことを実践しないと、あなたのコードベースは遅かれ早かれメンテ不能に陥ってしまう。

マーチンファウラー氏の進化型設計のページ

 こういったことは、ツールをいくら導入しても解決できない。これは「開発の習慣」だから、本を読んでもすぐにできるわけでもない。じゃあどうするかというと、本当に「テスト駆動などの開発習慣を何年も当然として実施できる」メンバーを開発チームに入れるのだ。これは数カ月でもいい。本で読んでもすぐわからないかもしれないが、そういう「イケメン」と一緒に開発をすると、「あーこうだったのか!」と簡単に理解できる。ただ、こういう「技術イケメン」は普段あなたがお付き合いしているベンダーにはいないかもしれない。実際問題として、できないベンダーでも受注するために「できます!」というケースもあるし、自分が「できない」ことに気づいていないベンダーさんも多い。これを、一人で見分けるのは最初は難しいかもしれないが、シンプルな方法としては、アジャイル系のイベントに参加して、スポンサーセッション以外で登壇している人を捕まえて、その人に、「テスト駆動をホンマにできる人紹介してくれませんか?」とお願いしてみよう。そしたら、本当にそういうことができるベンダーさんを教えてくれるだろう。アジャイルができる人は、ちょっと話をしたら、誰がちゃんとできるかもわかるものだ。   もしくは、t-wadaという男を見つけて、彼にしっかりとした対価をお支払いするのがいいかもしれないw (注:TDDと言えばt-wadaと言われる日本のテスト駆動の大家ですw)

twitter.com

もちろん私に聞いてもらっても結構だ。

1.3. スプリントはミニウォーターフォールではない

 よくある誤解で、スプリントの内部はウォータフォールになっているというのがある。実際はそうではない。進化型設計で開発すると、「要件ー>分析・設計ー>実装ー>テスト」という順番で物事は進まない。

f:id:simplearchitect:20160923170842j:plain

先ほどのテスト駆動開発だって、そもそも実装の前にテストであり、実装をした後にリファクタリングで「設計」変更を行う。進化型設計とは、常に設計をしているような状態だ。実際に実装してから、ユーザさんに見せると、「あーイメージが違うよ」となるかもしれない。それは要件を確認している行為だろう。  つまりアジャイルの開発では、要件、分析、設計、実装、テストはいったり来たりする感じで開発されるので、シーケンシャルに流れるものではない。だから、もしそうなっていたら、ミニウォータフォールと呼ばれるバッドプラクティスに陥っている可能性が高い。これも、先ほどの「良い開発習慣を持った人をチームに雇う」ことが最も良い解決策だと思う。 

2. ビルドが中心になっていない

 次によくありがちな状態としては、開発のスケジュールが決まっていて、機能1を第一スプリントで、機能2を第二スプリントで、、というような形態になているケース。

f:id:simplearchitect:20160923164229j:plain

これは何が問題か?というと、アジャイルの考え方では、「動作するアプリケーションで物事を判断する」ということがある。例えば、機能1ができて、機能2ができてから、機能3を作ってやっとお客様に見せて価値があるとかいうスケージュールになっている場合が多い。でも、それだと、第三スプリントが終わるまで、仕掛品を作り続けていることになり大変危険だ。アジャイルの場合は、最初のスプリントから、価値の出る単位で、開発していこう。別に「最終製品」のクオリティが実装されていなくてもいい。 最初のうちに必要なのは、価値の出る単位ものが、つながってビルドとなっているかだ。仕掛品は、つなげてみるまで結局本当にできているかはわからない。だから小さくてもいいし、機能がフルに実装できてなくていいので、つながっているものを創っていく。最初に作ったものがそのまま本番に使われると考えるよりも、最初のものは、アーキテクチャ的だったり、仕様的だったり、どれが正しいかを探索する実験のようなものだ。工数をかけず、さっとつなげて、ビルドをつくって、そこからフィードバックを得よう。だから、がっつり機能1、機能2を実装していくなんてことは、本当にそれでよいかわからないものに対して多大な工数をかけていくことに他ならない。 それは大変アジャイルの世界では危険な行為なのだ。まずそれがそのプロジェクトにとって「正しいか」を確かめよう。最小の工数で。

3. 予定の機能の実現がMUSTになっている

 さらによくあるのが、予定の作業をすべて実装しようとしているケースである。アジャイルでやったからといって、自動的にウォーターフォールに対して生産性が強烈にアップするだろうか?ポイントは、「無駄なことをやらない」ことだ。すべての機能実装を100%やって、それを劇的に早める方式などない。

f:id:simplearchitect:20160923171235j:plain

 しかし、実際のところ、機能のうち、本当に使われるものは、40%未満だ。それを考えると、使われない機能を実装しないだけで、生産性は倍になる。多くの人は、「たくさん早く実装する」ことがよいと思っているかもしれないが、ポイントは、「やらないことを見つける」事だ。そのためにアジャイルでは「スプリント」をつかって学びを得て、いかに少ない工数で、より高い価値を提供するかを追求している。ものをたくさん生産したらたくさん価値が出るわけではない。だから、最初に予定している機能を100%実装するということは、無駄を大量に実装していることになり、そんなことをしたら、アジャイルで開発しても全然価値が出ないことになる。

 たくさん機能を実装したら、たくさん価値が出るという考えを捨てることから始めよう。

simplearchitect.hatenablog.com

 こういう「マインドセット」は、プロジェクトの開始前に関係者にプレゼンテーションなどをしてシェアするのをおすすめしている。後出しじゃんけんになると、反発してくる人も多く出てくるが、始まる前で、かつアジャイルを導入しよう!と会社で決めているならば、皆さん喜んで学ぼうとしてくれる。アジャイルコーチを採用して、こういう事を最初の段階から共有するようにしよう。「シンプルさ」に関するマインドセットもExtreme Programming から来たものだ。

Do The Simplest Thing That Could Possibly Work

You Arent Gonna Need It

Once And Only Once

4. マネージャーの指示でチームが動いている

 最後のアンチパターンとしては、マネージャの人が、スプリントでの実施内容を決めていたり、マネージャの指示にしたがって、メンバーが動いているようなケースだ。

f:id:simplearchitect:20160923164915j:plain

アジャイルの場合は「自己組織チーム」といわれる考えでチームを運用する。チームに技術的決定や、タスクの分割、割り当て、見積もり、、などなど大きく権限を与えて彼ら自身が考えて判断するようにする。DevOps の時代でもそれが進化したフィーチャーチームという考えになる。そこには開発チームだけではなく、Opsのメンバ、テスター、プロダクトオーナーも含まれる。そういうチームにがっさりと権限を与えて、彼ら自身に判断してもらいながら、プロジェクトを遂行させる。  普段プログラムを書いていない人が、現在の流れのはやい技術の世界で正確な指示が出せるはずもない。諦めて、彼らに任せよう。もしかすると、受け身なメンバーを見ていると、任せるのが不安かもしれないが、任せて、メンバーも慣れてくると、生き生きと自分で考えて行動するようになってくる。最初のしばらくの辛抱だ。  そうやって、自己組織チームができてくると、上の人が判断していた時代と比べても、圧倒的に早く生産的でイノベーティブになることができる。

 任せる方法がわからない場合は、やはりアジャイルコーチをやとって、自己組織チームを構成するようにするとよい。組織的にそれが現在はできないって? 上に掛け合って実現しちゃえばいい。人事制度がって?変えればいい。やらなければ、生産性が相当わるくなって、チームがやらされムードに支配されてあまり生産的でもイノベーティブにもならないだけだ。

5. 日本の「常識」で考えている

 最後に、私の自戒も込めて。我々はどうしても、制約事項を「日本の常識」で考えてしまい、「これはできない」とか判断してしまいがちだ。しかし、アジャイルは西洋の人が考えたものなので、西洋の人の考え方を学べば、もともとどういう概念でそれが提唱されたか、どういう前提条件があるのかが非常に理解しやすくなる。

 これに関しては今すぐおすすめの解決策はなく、私のブログを読んでぐらいしかないのだが、現在Rochelle Koppさんという専門家の方と共に、そういった考え方を学びやすくする取り組みを始めている。しばしお待ちを。

おわりに

自分の経験ベースではあるが、日本の現場におけるアジャイルアンチパターンとその対策についてまとめてみた。より多くの人が、アジャイル開発を実施して、実際にそのメリットを享受できればという思いでまとめてみた。基本的には、ツールや方法を表面上インストールしてもたいした変化は期待できない。重要な事は、本質を理解しすること、それから、良い開発の習慣を身につけることだという理解を持つこと。考え方や、習慣はすぐには身につかない。だからこそ価値があり、効果がある。

少しでも皆さんの参考になれば幸いである。

アジャイルを創ったアリスターのひとこと

f:id:simplearchitect:20160911181258j:plain Fig1. アリスターとXPJUGの仲間 2002年

How I saved Agile and the rest of the world

アジャイル開発」そして「オブジェクト指向」などに多大な貢献をしたアリスターコバーンさんが、最近こんな記事を公開した。

Alistair.Cockburn.us | How I saved Agile and the Rest of the World

アジャイル」が広まりだした2000年当初、アリスターは、Kent Beckと共に日本に来てくれた。本でしか見たことがない、想像上の偉人のように感じていたアジャイル界の大物の来日は衝撃的だった。当時は外タレの来日は非常にまれだった。これはテクノロジックアートの長瀬さんそして、XP JUGのコミュニティの貢献が大きかったと思う。しかも、東京だけではなく、関西に来てくれたのだ。

 当時、アジャイルの世界は今のようにScrumが最も普及したものではなく、Extreme Programming という手法が全盛だった。ソフトウェアエンジニアリングの世界でも大上段で複雑なプロセスが主流で、エンジニアリングらしく、「誰がやっても同じ結果が出る」ということを目指したプロセスがほとんどだった。Extreme Programming は、プロセスより個々の「人」に注目した方法で、ペアプログラミングや、テスト駆動開発継続的インテグレーションなどマインドセット、技術の両面で世界に衝撃を与えた。私も大好きなExtreme Programming だが、常にどんな時でも使えるというものではなかった。

アリスターコバーンがくれたもの

 アリスターコバーンは、「クリスタル」シリーズと呼ばれる方法論を発表していた。彼の考え方は「すべてにあう一つの方法論は存在しない」という考えであり、クリスタルシリーズは、クリスタルオレンジ、クリスタルイエロー、クリスタルクリアーと様々なケースに合わせて考えられたものであり、私が最初に大変お世話になった「アジャイルプロジェクト管理」は非常に実践的で、大変参考になった一冊だった。

books.rakuten.co.jp

更に世の中のアジャイル本の中でも最もディープな内容を持ったものの一つが、「アジャイルソフトウェア開発」だ。人やプロジェクトは異なるという彼の考えの結果生まれた本書は、人やソフトウェアの開発に非常に深い知見を与えてくれる。

books.rakuten.co.jp

それ以外にも、ユースケースの書籍の中で、自分的に最も完成度が高く実践的な「ユースケース実践ガイド」も彼の書だ。この一冊でほかは読まなくていいぐらいの完成度とオリジナリティだ。

books.rakuten.co.jp

アジャイル開発宣言

そんな多大な貢献をした彼は、「17人のライトウェイトな方法論」をそれぞれ作っていた人を集めて、「アジャイル開発宣言」をまとめ上げた。今回の記事はその経緯と、17人それぞれがどういう人なのかを紹介している。そして

What I hope you see is that the Agile Manifesto was the product of 17 people from different schools and backgrounds. No one person is responsible for the words we came up with – it is clear that it was the product of all 17 people. The addition or removal of any 1 person would have changed the outcome, something we recognized and discussed at the end of that meeting.

貼り付け元 http://alistair.cockburn.us/How+I+saved+Agile+and+the+rest+of+the+world

日本語訳例

私があなたにアジャイルマニフェストに対してどういう風に考えてほしいか?というと、アジャイルマニフェストは、17人の違った知見、バックグラウンドを持った人のプロダクトということだ。誰かが「アジャイルマニフェスト」という言葉を思いついて責任を持ってるとかではない。一つだけはっきりしているのは、17人全員のプロダクトであるということだ。もしたった一人の人が減ったり、増えたりしても、我々がそのミーティングで、認識してディスカッションした結果は違ったものになっていただろう。

アリスターのひとこと

彼が以前日本に来たがっていたときに、こんなことを言っていた。

I'm not famous enough in Japan. (私は日本ではそんなに有名じゃないから)

私はとてもびっくりした。彼よりアジャイルで有名で、業界に貢献した人は誰がいるのだろう?私は彼にこう答えた。

あなたは、アジャイルの父じゃないか?私は信じられないよ。

かれはこういった。「アジャイルは私のものではない。17人の人々によって生まれたものだ。17人の成果なんだよ。」と。そんなことをこの記事を読んで思い出した。

アジャイルの本当の理解のために

現在アジャイルというとScrumが有名で、Extreme Programming が次に来る。現在DevOps の世界が来ているが、Scrumで世界に受け入れられたアジャイルが、DevOpsの時代になり、Extreme Programmingのようにクラウドとともにテクニカルプラクティスが戻ってきた感を受ける。

しかし、私がアジャイル導入にかかわっていつも感じるのが「アジャイル開発の根本の考え方」みたいなものがあまり浸透していないことを感じる。アジャイルは、Scrumと、Extreme Programmingを指す言葉ではない。クリスタルシリーズ、FDD、DSDM等様々な手法があり、それぞれの手法からいろいろな学びを得ることができた。アリスターのいう通り、すべての状況にフィットするものなどないのだ。

でも、我々にはアリスターがいた。講演をしてくれて、日本に来て、一緒にたこ焼きを食べて、いろんなことを直接教えてくれた。そんな彼が日本に来たいのに来れない現状を何とかできないだろうか?

我々がアリスターに出来ること

私にできることはたぶんブログを書いたりすることぐらいかもしれない。しかし、彼は私がエンドースしたいという理由を除いても未だ素晴らしく魅力的なのだ。  最近の彼は、アドバンスドアジャイルマスタークラスを定期的に開催して非常に高い評価を得ている。そして、ICAgile というオープンで本質的な認定をリードしたり、ハートオブアジャイルというより「人」に踏み込んだカンファレンスを開催している。

www.tabar.com.au

Heart of Agile | Rediscovering the heart and spirit of agile

books.rakuten.co.jp

Alistair.Cockburn.us | Alistair Cockburn

 個人的にもアドバンスドアジャイルマスタークラスは最高に受けてみたい。アジャイルの「入門」を終えた皆さんも本物かつ現役でインパクトを出し続ける「アジャイルレジェンド」に日本にもう一度来てもらう機会を作りませんか?

彼が「日本では有名ではない」という状態はもったいなすぎるよね!

おまけ

最後に私も興味ありありの、Advanced Agile Master Class のコース概要に関して日本語訳をつけておこう。前からこれはホンマ出たい!ちなみに、参加者のコメントを見るとガチで凄そう!

Advanced Agile Master Class with Alistair Cockburn

Modern “expert” agile practitioners have mastered the practices – but not why they work, not how to adjust practices to situations, not how to approach new and surprising situations, not how to apply agile practices to non-software projects, not how to incorporate results from other fields back to their own projects, not how to tailor the practices to different organizational cultures. This advanced course from industry guru Dr. Alistair Cockburn addresses those areas.

In this discovery-filled course,

  • Learn why agile works, in software or outside of it,
  • Learn how to articulate and deal with the weaknesses in agile development,
  • Test yourself and your partners with the Test-Driven Carpaccio exercise.
  • Learn to reduce risk and maximize results by viewing design as a Knowledge Acquisition activity.
  • Practice backing up your recommendations with solid theory, not just an appeal to authority,
  • Learn how to plan and track larger, more complicated projects using Story Mapping or Blitz Planning (time permitting),

. . . and most of all

  • Come face-to-face with yourself, your strengths and your weaknesses, as you confront one situation after another with equally inquisitive classmates.

アドバンスドアジャイルマスタークラス

最近の熟達したアジャイル実践者は、「プラクティス」をマスターしているでしょう。しかし、なぜそれがうまくいくかはわかっていないかもしれません。どうプラクティスを特定の状況に当てはめるかはわからないかもしれません。また、新しくて、驚くべき分野にどう適用できるのか、ソフトウェア以外の分野にどう適用するのか、他の分野のプロジェクトに戻った結果との協調や、他の組織文化へのテーラリングなのについてもわからないでしょう。このアドバンスドコースは、この産業のグルであるアリスターコバーンが次の分野について教えてくれます。

次のような発見に出会うかもしれません

  • なぜアジャイルがうまくいくか、ソフトウェアそして、それ以外で
  • アジャイル開発に熟達し、その弱点を扱う方法
  • 自身とパートナーをテスト駆動カルパッチョエクササイズでテストする
  • リスクを減らして、結果を最大化する。知識によってデザインを見ることによって。スキルを高めるアクティビティ
  • 確固たる理論で、あなたの推薦事項をバックアップする練習。単に権威に対してアピールする方法ではなく。
  • 大きくてより、複雑なプロジェクトを計画して、トラッキングする方法。ストーリマッピングと、ブリッツプランニングを使って(時間があるなら)

・・・そして、より重要なこと * あなた自身に向き合うこと。あなたの強さ、弱さ。敵対する一つの状況から、別の状況に対峙する。同じように興味をもっているクラスメートと

次回は11/15 - 17 メルボルンみたいですね。

www.tabar.com.au

英語鎖国で深刻なのは情報入手のスピードじゃないと思う

エンジニアに英語が必要と言われて久しい。技術情報を早く入手するためには、英語を使えないといけないからとあるがこれは本当なのだろうか?自分的な気づきがあったので、その考察をシェアしたい。

f:id:simplearchitect:20160906194626j:plain

 エンジニアに英語が必要と言われている。いろんなことが言われているが、情報の入手のスピードが遅くなるという意見がある。個人的にはこの意見はある意味微妙な意見だと思う。 最近だと例えば最新技術に関する海外イベントがあったとしても、翌日、早ければ当日の間に誰かがまとめブログをアップしてくれたりする。もっと時間がかかったとして、2カ月程度後に誰かが書いた日本語の情報でそのことを学んだ ところで、大勢に影響はない。 また、日本語で出ている書籍は確かに翻訳のタイムラグがあるが、海外の人も主だったすべての本を読んでいるわけではないし、日本語になったものを着実に勉強しても、勉強の知識としては、相当なエンジニアになれるはずだ。 では、なぜ?

日本人の英語アレルギー

日本にいると、英語の拒否っぷりにすがすがしい気分すら覚える。私は英語でもブログを書いているが全く読まれないし、それどころか、Facebook に英語でポストするだけで、「いいね」はほとんどつかない。もちろん、英語のMeetupには絶望的に人がいないし、海外の人と会議をしても全くしゃべらない人も多い。

f:id:simplearchitect:20160906200438j:plain

一方、ネイティブじゃなくても、他国の人は英語がむっちゃくちゃでもとにかくしゃべってコミュニケーションを取ってくる。昔、今のインターナショナルチームに入った時に、最初は同僚がしゃべりまくるスカイプコールがつらくて、Damien に自分は英語がうまくないからといった時がある。そしたら彼はこういった。

Tsuyoshi は英語がうまいよ

私は明らかに同僚より全然聞けていない感じがする。しかし、それは、Damienが気を利かせたわけではないということに気づいた。彼らの中には文法とかぐっちゃくちゃの人もいる。それに比べると私のは相当ましということなのだろう。彼にとってはそう聞こえようだ。  私がどうこうではなく、本来高度な教育を受けている日本人は平均して、英語はわるくないのかもしれない。ところが、圧倒的に英語を「敬遠」する人が多いように感じる。  私は厚かましいたちなので、あまり遠慮はしないたちだが、同僚と働いている中で「英語」を避けることの本当の大きな問題に気が付いてきた。

インターナショナルチームでの苦悩

 インターナショナルチームでは楽しくやらせていただいているが、一つだけ心苦しいことがある。自分のチームに対してバリューが出せていないのだ。私の純粋なチームには「英語ネイティブ」はいない。だけど、彼らは全員英語で仕事をしている。それは、対お客様に対してもだ。もちろんイベントの資料もそうだ。だから、彼らは自分が作った資料やアセットをチームに共有すると、他のチームメンバーがとても喜ぶ。英語でデモをするコードを作ったら超喜ばれる。  ところが、日本だけが、日本語で書かないとお客様や、イベントでは見向きもされない。だから、私がどんだけ一生懸命資料を作ったところで、それは日本限定であり、チームには貢献できない。

 他にもある。私のチームで、PartsUnlimited という、Hello Worldレベルではない DevOps のハンズオンラボをGitHub 上で公開している。今期の戦略に合わせて、その内容を修正/追加しないといけない。

github.com

 ところが、私は日本側の準備(日本語化)をするので手一杯だ。しかも、そのプロジェクトに貢献したところで、日本では英語だから全く役に立たない。だから、メンバーには言わないけど、いつも心の中でメンバーに申し訳ないという気持ちを 持っている。

世界コミュニティは、特にハードルが高くない

日本にいると、「世界挑戦」という言葉があるとおり、「世界」は凄いところで世界に出ていくのはハードルが高いというイメージがある。ところが、他国のメンバーや、他国の友達をみているとそんなことは全くない。私の友達のポーランドの マリアは、16歳のころからモデルをして、他の国を渡り歩いていた。

f:id:simplearchitect:20160906200801j:plain

ほかのイギリスの語学留学時代の友達も、英語が下手でもなんでもその人が他の国で働くこと自体にハードルを感じている人はいない様子だった。  実際にインターナショナル環境で働いてみると、彼らが圧倒的に優秀とかではない。世界にも優秀な人そうでない人もいる。MLBは、本当に世界の超一流が集まっているのでハードルは高いが、普通の仕事はそうではない。日本はそうでも ないが、海外に行くと、他の国の人々を頻繁に見かける。

f:id:simplearchitect:20160906202133j:plain

 しかし、問題は、ソフトウェア開発だと平均すると、日本のレベルははっきり言って相当低いと言わざるを得ない。世界が凄いのではなく、日本がしょぼいのだ。これはなぜだろう?

世界コミュニティに貢献できないことがもたらす問題

 英語を避けることによって、最も問題なのは、世界コミュニティに参加できなくなることだ。私が「インターナショナルチームでの苦悩」で書いたことは、日本の縮図である気がする。

f:id:simplearchitect:20160906204906j:plain

 例えば何かの仕事を一緒にするときに、日本以外の国は、英語でも突撃して、世界コミュニティがやっていることに対して「貢献」をする。それはブログかもしれないし、コードかもしれない。講演をして、アイデアをシェアするのもその一つだ。  実際にアジャイルカンファレンスに出かけると、スピーカーが「ネイティブ」とは限らない。普通に講演しているし、ブログや書籍も英語でガンガンに書くし、例え英語がしょぼくても、英語でガンガンにコミュニケーションを取って、その場でバリューを出して貢献しようという姿が感じられる。

 ところが、日本だと、「英語での最新情報を早く入手したい」という意識はあれど、「貢献しよう」という人は相当少ない。もし、それを、「世界コミュニティ」のメンバーから見たらどう感じるだろう。何の貢献もしないけど、情報だけを欲しがる 「クレクレ君」に見えるのではないだろうか?私は少なくとも、みんなにいろんなことをしてもらっているのに、もらう一方だと相当肩身が狭いので、貢献をしたいという気持ちになる。誰が「クレクレ君」と一緒に仕事をしたいと思うだろうか?

 その為には、英語のレベルがどうや、こうや、と言っている暇があったら、世界コミュニティに「貢献」を始めたほうがいい。気軽に始めるのは、ソフトウェアだと、Issueを送るとかPull Requestを送るでもいい、ブログでもいい。なんでもいいけど あれだけ情報をもらっているのだから、こちらもシェアしないのは相当イケていないと思う。

 我々はどれだけ日本語で情報発信したところで、日本国内の人にしか役に立たない。素晴らしいアイデアをもらっている世界コミュニティーには何の貢献もできていないのだ。情報だけをゲットしておいて、自分の成果は、自分だけで享受なんてなんとも虫がいい話じゃないか?

翻訳業にパワーを割くのをやめよう

 また、他にも問題がある。世界コミュニティに「貢献」することは、単に親切だからとかではなく、自分が欲しいものを作った時に、他にも同じ問題で困る人がいるようだったら、それを単にシェアすると、その人が助かる。特に成果物がコピーできる ソフトウェアはそういうものだ。そして、「貢献」によって作り上げられた成果物は、みんなでシェアすることができる。  例えば、ハンズオンラボをみんなで作ったら、URLをシェアして、お客さんに渡してあげると喜んでもらえてバリューが出る。しかし、日本だとその成果が翻訳されるのを待つしかなく、それをお客さんに渡しても、英語のままだと全く喜ばれない。しかも、文化的背景もあり、向こうでうれしいものがこちらでもうれしいかはわからない。

f:id:simplearchitect:20160906205220j:plain

だから、多くの日本人の人は「翻訳業」に多くの工数を使っている。しかし、ソフトウェアはバージョンアップするものなので、その保守はどうしたらいいのだろうか? そんなことをしている間に世界コミュニティのメンバーは、協力・貢献して、どんどん成果をシェアしていってその恩恵をうけて生産性が向上していくことになる。翻訳を鍛えるよりハックを鍛えよう!

フィードバックを受けられない問題

それだけではない。世界コミュニティに参加できないことの問題として、フィードバックを受けられない問題がある。それは、最初の英語力のレベルとかそういう問題ではない。

 例えば、ブログを書いたら反応があるし、コードで貢献したら、コードがイケてないと受け入れてもらえない。そういう過程を経て世界の人がどういうレベルなのかを肌で感じることができる。また自分に足りないことはどこだということも、試行錯誤を繰り返す中でだんだん明らかになってくるだろう。世界の中で働くことで自分が世界で働くには何が足りないかが明確に見えてくる。

blogs.technet.microsoft.com

しかし、日本のサイロに閉じこもって、日本国内だけで思考していると、そういうフィードバックを受けることはできない。以前のポストでも書いたが、海外の人はAgileでもDevOps でもコンセプトを誤解していることが非常に少ない。それは、ロジカルに、抽象的に考えることが得意な傾向があるからではないか?と以前のポストで書いたが、そのほかにも「フィードバック問題」があるかもしれない。

simplearchitect.hatenablog.com

 我々は、数年後だが、翻訳本を入手できるし、ブログで最新技術を紹介してくれる日本語ブログを書いてくれる人もいる。だから「情報」だけでは、「5年とか、8年」と言われる日本の遅れは説明できない。問題はそこではなく、実際にプロジェクトで実施する レベルに到達する程度に本に書いてあることを理解するためには、やってみて、失敗して、フィードバックを受けたり、経験者とディスカッションする必要がある。日本だと、せいぜい狭い日本人コミュニティの中でしかこれができない。日本人の中だけだと、 すべを日本人の常識や、日本人の現在の状況だけで物事を判断しがちになってしまい、結果として、魔改造が「正」として横行するケースもあるように思う。

channel9.msdn.com

 今は海外に行くハードルは高くないので、海外カンファレンスに行けば、本を書いている著者と直接話すことができる。そうじゃなくても、海外のカンファレンスに来ている人々と、ディスカッションをしてみることで、他の国の人がどの程度のアジャイルを実践しているかがわかる。そういう、インタラクションを通じて、「肌感覚」みたいなものはわかるのだと思う。

 これが、日本だと、「海外だからうちは関係ない」となりがちだが、日本は大したプレイヤーがいないから、と日本市場になだれ込んで来たらどうするのだろうか?今は「鎖国」だから、そうはなっていないが、少しづつ、文明開化を足音が聞こえてきている気がする。 私のおすすめは、日本にいても、世界コミュニティの一員という視点で考えてみるのがいいのではないだろうか?

どうやって、世界コミュニティに進出するか?

 世界コミュニティに進出する方法は、基本単に進出すればよい。特にそこに準備は必要ない。英語があったほうがいいとは思うが、「〇〇ができるようになってから」というタイミングは永遠に来ない。じゃあ、どうやって、日本にいたままそれを達成するか? 現在の私のおすすめは、「英語のMeet up」に参加するというものだ。もちろんすべて英語だ。

f:id:simplearchitect:20160906201054j:plain

www.meetup.com

 英語がわからない不安が当然あると思うが、ここでは、「英語がわかる」を目的としていない。英語勉強にはモチベーションが重要だ。全く英語を使う必要がない人と、月に1回でもいいので、英語をしゃべれないと何もできない環境にやってきて、「次こそやってやる」 と思うのと、どちらが英語が上達しそうだろうか? 今の時代「英語を学ぶ方法」はいくらでも転がっている。それよりも、パッションが最も重要だ。遊び系がよければ、完全英語のコメディショーも面白くておすすめだ。

itpro.nikkeibp.co.jp

東京で行けるガチ英語コメディショー: Improvazilla Main Stage Show

日本ではなく、世界コミュニティに貢献する

私は日本人のためだけに仕事をするのをやめよう。日本人に対して仕事をするのをやめるという意味ではなく、世界コミュニティの一員として貢献していこうと考えている。たくさん失敗もすると思うが、そうしていくと、「世界平均」ぐらいの実力は身につくかもしれない。  私は、本当に重要なノウハウというのは、人の中にあると思う。本やビデオで習得するのは限界がある。だから、マイクロソフトでも、講演やデモを中心としたスタイルから、ハックフェストといって、お客様の社内でハッカソンをしてお客さんと一緒に最も難しい問題を解くことを支援するという動きに変わってきている。

f:id:simplearchitect:20160906205517j:plain

 これは、おそらく、講演やビデオは、いくらでもオンラインで見れる。だから、本当の価値は、それぞれの人の中に潜むノウハウなので、ディープな知識を移転し、かつ、実際にコードを共同で書いて問題を解決するのが、最も成果(リードタイム短縮など)を出しやすい。だから そういうスタイルを本社も押しているのだろう。そのためにも、自分がまず世界コミュニティの一員になれるように頑張ってみて、そこで世界平均ぐらいのレベルを獲得してみたい。

 だから、「世界コミュニティに参加しよう!」思っている人を今後は積極的にご支援していきたいと思っている。それが、私のビジョンである「日本をUSと同じスピードで技術やプロセスを導入することができる国にする」ことには必要な気がしている。

衝撃的な効率性~最高の DevOps チームは「知っている事」で構成されていた~

 今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。

f:id:simplearchitect:20160809120031j:plain

 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。

 だから、今回Samにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。

気になっていたSamの一言

 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行ったときに、彼がある先進的な会社を訪問した時に私にぽろっと言っていた事を思い出した。

f:id:simplearchitect:20160618214227j:plain

先進的な企業と言っているけど、レイアウトが全然アジャイルじゃない。オールドファッションな日本企業だ。

 その当時自分はその言葉の意味が分からなかった。オープンなスペースで、プログラマに対してもディスプレィもしっかり複数支給されていて、見晴らしも良い。だからスルーしたのだが、心には引っかかっていた。Matthewのチームを見にきて「ああ、そういうことか!」ということが相当腹落ちした。

伝説のルームレイアウトが眼前に広がった

 開発チームがいる部屋に入ってみると、みんながとても歓迎してくれた。私はみんなは、日本では有名でヒーローなんだよ という話をしてあげたらとても喜んでいた。

f:id:simplearchitect:20160809120355j:plain

ルームを見ると、小さな島で構成されている。部屋はオープンスペースで、とてもペアプログラミングがしやすい構成になって いる。その中の「マネージャ」という人がポイントを教えてくれた

すべての机に滑車がついているだろう?だから、簡単に場所を移動できるので、ペアプログラミングとかしたくなったら移動 できてすごく楽なんだよ。

 そして、彼は続けて説明してくれた。

もし、集中したくなったら、フォーカスルームを用意しているから、そこにこもって集中することもできるようになっているんだ。みんなが作業に集中できるようにね。

f:id:simplearchitect:20160809120449j:plain

 オープンスペースでの開発は、大きなディスプレイが与えられて、頻繁に声を掛け合いながら開発をしている。横の人が ペアプログラミングを始めた。

f:id:simplearchitect:20160809120505j:plain

 この感覚はなんだろう。Extreme Programmingの白本で見た、当時衝撃を受けたあのレイアウトだ。フォーカスルームの アイデアも何かで読んだことがある。しかし、日本ではここまでしっかりやってるところはどれぐらいあるだろうか?なんで私は今まで「知っている」はずのものをたいして効果がないだろうと決めつけてやらなかったのだろうか?そんなことを考えるとさらにドキドキしてきた。

強烈なフォーカスを生み出す力は、フォーカスできる環境から

 各プログラマがそれぞれフォーカスできるようにとても工夫しているようにも感じた。ペアプログラミングをしている人以外は 集中したい人は大きなヘッドフォンをしているし、スタンディングディスクになっているので、スタンディングスタイルにチェンジして開発を始めた人もいる。

f:id:simplearchitect:20160809120756j:plain

 マイクロソフト最高のチームは、特に日本にないような特別の部屋で開発をしているわけではないし、我々もやろうと思えば 全然できてしまうはずなのだが、彼らは私が本を読んで知っているはずの事を忠実に実行していた。

日本よりアクティブなスタンドアップ

 次にスタンドアップが始まった。時間は 13:30 。もちろん、VSTSのソフトウェア看板がどっかーんと表示されたバカでかい スクリーンの前にみんなが集合してきた。意味不明だが、なぜかMacだった。  みんな今日やる作業に関しての共有が始まったが、日本で行われている朝会よりもずっと「アクティブ」に感じた。日本のは もっと淡々と「きのうやったこと、きょうやること、課題」を共有していく感じだが、そこに、時間は短いけど「ディスカッション」が入る感じ。教科書通りだと、「ソリューション」は終わった後で個別に解決が定石だが、ディスカッションの時間と問題解決が速いので、特に問題に感じなかった。むしろ相当効率的に感じた。

f:id:simplearchitect:20160809120849j:plain

 このチームには、休暇含む9名のメンバーと2名のリモート(中国、インド)のメンバーがいるチームだった。リモートのメンバーの一人が、横にあるディスプレィで、常時顔が見えるようになっていた。

f:id:simplearchitect:20160809120839j:plain

カンバンの工夫

 ただ、ソフトウェアKanbanに、レーンが設定されていたので、それは何かを聞いてみた。実は一瞬「ま、まさかバッドプラクティスのミニウォーターフォール?」と思ったがそうではなかった。レーンは

Backlog -> Up coming -> Investigate / Design -> Implementation -> Pull Request -> Evaluate -> nag -> Done

f:id:simplearchitect:20160809122118j:plain

となっていた。各レーンは、ワークアイテムの最大数が決まっている。Backlogの優先順位が高いものから、Up comingに取り込んで 、Designに移る。Designは、企保的にストーリが「理解できたら」次のimplementationに移るらしい。その後、Pull request を実施したら、Evaluateだ。例えばあるペアが開発を行ったワークアイテムだと、それ以外の人がをのプルリクエストを見るようにしているらしい。駄目じゃない?というときはnagに移すとのこと。

テレメトリの徹底活用

さて、ここまでは特に特別なことはないのだが、次の2つはアジャイルチームではなく、DevOps チームである特徴にあふれていた。 まず、一点目は、徹底的にテレメトリをとって、それをいつでも見えるように共有していることだ。PowerBIをつかって、大きなスクリーンに画面いっぱいのさまざまなテレメトリをリアルでチェックできるようになっている。朝会でも見ていたが、常にこれを見ることができる。

f:id:simplearchitect:20160809122202j:plain

Fチーム / Lチーム

次のプラクティスが結構すごいと思ったのだが、Fチーム、Lチームという考え方だ。このチームは内部で2つのチームに分かれている。だから今どちらのチームにだれがいるか?というダッシュボードも存在している。

f:id:simplearchitect:20160809123933j:plain

Fチームというのは、新しい機能を作るチームだ。Lチームは、顧客からの要望だったり、緊急対応、リリース後出たバグの対応をするチームだ。それぞれのチームに対してKanbanが存在している。

Fチームは、プログラマがフォーカスできることと、品質を高めることを重視している。だから、開発中に実施できるワークアイテムの数を例えば5に制限している。お偉いさんがやってきて、今すぐ機能を対応してほしいときは、その枠を超えないように入れ替えをする。

 Fチームの開発に関しては、基本的にペアプログラミングのペアで作業している。これは、すべての機能を誰か一人しか知らない状況を防ぐためとのことだ。さらにペアは組み替えられる。  ここで、私はFチームは楽しそうだと感じた。メールもほぼほぼ見る必要もないし、割り込みも入らない。これは相当集中できるだろう。

しかし、Lチームはおもろないやろなー。と。しかし、Matthewは続けた

 Fチームと、Lチームは、定期的に入れ替える。単純にそれぞれのチームに最も長く滞在しているメンバをスワップするんだ。 そうしたら、ペアのうちの一人が入れ替わるから、知識共有の面でもいいだろう?

自己組織チームはこういう姿

なるほどー。と思った。これは素晴らしいアイデアだ。フォーカスルームやレイアウトもそうだが、このチームは徹底的にプログラマが集中できるような環境を工夫して改善していると感じた。Fチームは、Lチームのおかげで相当集中して、安定した機能をデリバリできるだろう。Matthewによると、この方法でもう1年ぐらい運用しているが、すごく生産性と品質が向上しているらしい。近々Mathew本人が記事を書いてくれるらしいので楽しみにしていよう。

 そして、チームメンバが同じゴールに向かって、相当いい感じで、楽しく仕事ができているようだった。完全に自律的なチームで、まさに自己組織化チームだ。マネージャと呼ばれる人はいるけど、チームを助けてすごくサポーティブだ。

9割は既に知っていたはずの事だった

 このチームを観察して感じたことは、「新しいことを知った」とか、「見たこともない最新技術を見た」とかいうことでは決してなく、最先端の DevOps チームというものは自分たちが「知っていたはず」のことを着実に忠実に実行して、そのうえでしっかり改善を続けているチームだったということだ。何のマジックもそこにはない。

f:id:simplearchitect:20160809122837j:plain

 ただ、私は今まで出会った中で最高のプロフェッショナルなチームだと感じた。観察していると全く無駄がないし、各メンバーはリラックスしながらも誰に言われるわけでもなく、すごく集中して作業を実施している。自分が勝手に「あまり効果がない」と思ってやらなかったことの積み重ねが本当は重要なんだということを思い知らされた。  彼らに限らないことなのだが、こっちにいると、本当にみんなプロフェッショナルなのだ。誰もダラダラしている人がいないし、無駄話もだれもしていない。このオフィスも遊びの要素はほとんどなくて、集中しているが、定時になったらみんなバリューを出してさっと帰っていく。  そこからいろいろ楽しむのだろう。

フォーカスへの投資が効率を生む

 スタンディングディスク、複数台の大きなディスプレィ、可動式のディスク、フォーカスルーム、大きな看板用のディスプレイなども、日本の会社だと認められないかもしれないが、そういうものが本当に生産性を生むということを本当に認識した。生産性をあげるためには、チームをルールで縛るのではなく、チームの自律的な「フォーカス」を生み出すことに集中するべきなのだろう。しかし、我々は本当に、エンジニアが、「フォーカス」できることに徹底的に投資してきたのだろうか? 彼らはフォーカスのためにあらゆることを実施していた。

 正直なところ、私がかつてこの目で見たチームの中で、圧倒的に効率がいいと感じた。しかも、それは、ほとんど自分が知っているプラクティスによって生み出されていた。我々はどこまでプラクティスを本当の意味や、価値、そしてそのバリューを理解してきたのだろうか?簡単に日本では通用しないと魔改造してきたのではないだろうか?でも、私が見た彼らは圧倒的に洗練されていた。言語とかツールじゃないのだ。

我々がすべきことは、「当たり前の事」をできること

 我々が彼らのスピードに追い付くためにやるとよさそうな事は、「まず教科書通りにやってみる」ことじゃないだろうか?と思った。彼らを観察すると、バカにされるかもしれないが本当に「教科書」的に、愚直に実施している。ソフトウェアエンジニアリングの基礎、ペアプログラミングスタンドアップ、Kanbanの運用、スプリント、継続的インテグレーション / デリバリ 我々が見たExtreme Programmingの本や、Scrum、DevOpsの本や講演で見聞きしたプラクティスが、そのまま行われている。それをきっちりやったうえで新しいプラクティスを積み重ねて、さらなる工夫をしている感じだ。

f:id:simplearchitect:20160809123229j:plain

 我々は現場に合わないと、すぐに駄目だということにして、違う方向に改造してしまう。しかし、本当に重要なことは、何千人もの人が実施して認めたベストプラクティスをまずは正しく理解して、愚直にやってみることかもしれない。我々はそこにも到達していないのでないだろうか?という思いを新たにした。

まとめ

今後、PaaS, SaaSの力が増大し、マイクロサービスの時代、そして、現在はServerlessに注目が集まっている。今後は 人手が多くいることはどんどん自動化してくるだろう。そして、人でしかやれない部分が残る。そういう時代に必要なのは、本当にプロフェッショナルでスキルの高く、自分で考えることのできるエンジニアになってくるのではないだろうか?誰かが考えたことの作業をするだけの人は、要らなくなる。  そうなってくると、本当に生産性を上げるのに重要なのは、実際に開発や運用をする人が如何に効率よく作業を実施できるかにかかってくる。

f:id:simplearchitect:20160809123212j:plain

プログラミングは高度な頭脳労働が残る。そして、プログラマの生産性の差は10 - 25倍と言われるのだから、これからは、「チーム」や「人」を重視して、彼らが「フォーカス」を獲得するために何をするかが、地道だが差別化のポイントじゃないだろうか?

新技術導入の遅さの一端はラーニングモデルの違いかもしれない

f:id:simplearchitect:20160804204258j:plain

以前から不思議に思っていたことがある。それは、少なくとも米英の人は、ソフトウェア技術やプロセスに対して誤解が圧倒的に少ないということである。

 別の回でも書いたが、イギリスの会社とお話しした時も、「アジャイル」に対するとらえ方、考え方は、100%といっていいほど正確だった。

バリューストリームマッピングで困っている人の話

 今回の出張で、Sam Guckenheimerに依頼されたことがある。ある人が「バリューストリームマッピングをやっているのだが効果が出なくて困っている」だから原因を一緒に探ってほしいとのことだった。

 Samと一緒に彼の話を聞いていると、バリューストリームマッピング、DevOps に関する考え方とらえ方は極めて正確だった。彼の問題は、「コンセプトの理解」は何の問題も無く、その先の「実際にやってみて工夫してみないと到達できない部分」の問題だった。

f:id:simplearchitect:20160804204907j:plain

なぜか米英では、ソフトウェアのコンセプトの誤解が圧倒的に少ない

 幸いなことに彼は相当喜んで帰ってくれたが、ふとホテルに帰って振り返るとこっちの人は、アジャイルやDevOpsといったものに対する誤解が圧倒的に少ないことを思い出した。  そういえば、自分の上司も両方とも元Opsなのに、同僚も、上司も「あー誤解しているなぁー」みたいな場面に遭遇したことがない。

 アジャイルそして、DevOps を実践して、15年以上になるのだが、経験上日本では、それを相当専門にしていない限り「アジャイル」「DevOps」に対する理解はずれている、もしくはむっちゃくちゃずれている場合が圧倒的に多い。それどころか、専門の人でも、かなりのコンセプトを誤解しているケースもある。もちろん私もそうで、少しづつ修正して今に至っているので、今でもなんか勘違いしているかもしれない。これは一体何なのだろうか?

最高の DevOps チームの観察で得たこと

 同じ日に、マイクロソフトの最高の DevOps チームを生で観察してきた。その詳細なレポートは別の回に譲りたいのだが、私が彼らに感じたことは、見たこともないようなすごいテクニックが使われていたわけでもなく、すごい新技術を導入しているわけでもないが、むっちゃくちゃ無駄がないということだ。  しかし、そこで、使われているTipsは一つを除いて今まで見たことがないものなどなかった。私は逆にそこでびっくりした。「今まで自分が知っているはずのプラクティス」をちゃんと使ったらここまでできるのか?と。彼らは、本当にそれらのプラクティスを正確に理解して導入していると感じた。

 私がExtreme Programming の本の写真で見たような光景が目の前で本当に行われている。それはちょうど、むっちゃ歌うまい人 が基本が超絶に凄いのに似ている。

http://ronjeffries.com/xprog/images/C3Room003.jpg

ronjeffries.com

歌のうまい人の基礎力

 歌とか演奏とかが本当にうまい人は、高い声が出るとか、複雑なリズムを乗りこなせるとかそういう話ではない。そもそも、何の変哲もない、だれでも歌える音域の声を「あー」ってだすだけでも、全然違うのだ。ドラマーなら、ドラムをたたかずともスネアを一発「パン」ってたたくだけでそこから全然違う。つまり、達人というものは、ものすごく「基礎」ができている人なのだと思う。

Rochelleさんの生け花の体験

ホテルの中で、考えていると、この前一日ミーティングをした、Rochelle Koppさんの言葉を思い出した。彼女は、日本と西洋のラーニングモデルの違いを説明してくれた。

f:id:simplearchitect:20160804205115j:plain

 彼女がアメリカで生け花を習ったときは、先生は日本人だけど、アメリカに長く住んでいた。彼女は、この花をどうさすと、こういう効果があるからと、説明して実際にやってみてくれた。ところが、Rochelleさんが、日本に来て生け花を学んだら全然違ったらしい。

師匠は、「今回はななめざし」といったっきり、しゃしゃしゃしゃー。と目の前で実演してくれたけどのそのあといきなり「じゃあやってみてください」とのこと。

Rochelleさんは何とかまねてやってみたけど、師匠がやってきて、全部さしなおして修正してくれた。確かに師匠が修正した後のほうが全然いいのだけど、理由は全く分からなかった。翌週も、その翌週も同じ感じだったそうだ。  そして、しばらく通っていると、何となく自分はできるようになっていたが、なぜできるのかは他人には一切説明はできなかったという話だった。

日米のラーニングモデルの違い

 インターナショナルという意味ではまだ分からないが、Rochelleさんによると少なくともアメリカの人は「すべてを理解する」ことに重きを置く。 ところが、日本の人は「具体的なやり方」を知って真似することを好む傾向にある。それはどういうことになるかというと彼女曰く

学ぶのに時間がかかるし、スケールしないのよ。柔道や、生け花みたいな変わらないものだとそれでいいのかもしれないけど、 ビジネスみたいに変わるものには絶対向いてないわね。

 あああ、、、これだ、、、自分の中で彼女のこの言葉を思い出して自分の中で何かがつながった。アメリカ人と、日本人の多くの人はラーニングモデルが決定的に違うんだ。だから、アメリカの人は概念の説明の段階でも質問しまくるし、日本人の人は、概念ではなく具体的なものや事例を求めようとするのだ。

完全理解タイプがスピードを生む

 アメリカの人は、たとえ経験をしていなくても、本を読んだり、講演を聞いたりして、「徹底的に理解する」ことに慣れているから、未知の新しいコンセプトでも導入が進みやすい。  一方日本人は、新しいコンセプトを取り入れるときは「具体的なもの」を見て真似するのが得意だ。ところが、新しいコンセプトであり、それが、自分の置かれている現状と違えば違うほど、具体的に想像できないので、ものすごく勘違いしてしまったり、魔改造してしまったりするのではないだろうか?しかも、学びが実物からなのだから、実物から、学んでいくので、少しづつしか広まらない。だからいろんな導入が遅くなってしまうのかもしれない。 f:id:simplearchitect:20160804210719j:plain

 また、もちろんこれも仮説なのだが、ソフトウェアの場合は、問題をややこしくしているのは、日本でもトップエンジニアは、「理解を重視」している思考をしているのではないか?という部分だ。

 私は昔「オブジェクト脳のつくり方」という書籍を書いてありがたいことにたくさん読んでいただけた。その当時のモチベーションは、既存のオブジェクト指向の書籍が大変分かりにくく感じたからだ。

books.rakuten.co.jp

ラーニングモデルとわかりやすさの違い

 書籍は当然その分野が分かっている人が書くことが多い。そういう人はソフトウェアができる人なので「理解を重視」しているスタイルで学ぶ。 一方、私は、こてこての日本人なので、「やってみなければ理解できない」タイプだった。だから、そういう人が「わかりやすい」書籍を書いた。  理解重視の人にとって「わかりやすい書籍」と体験重視の人にとって「わかりやすい」は全く異なる。そして、きっと日本は「体験重視」の人のほうが多いのだろう。

 昔衝撃を受けたことがあるのだが、日本の「算数」の教科書と、米国の「Math」は相当に違っていてびっくりしたことがある。日本の教科書は定義も一応ちょろっと書いてあるが、「さあ、解いてみよう」ということが中心になっている。「Math」の場合は、徹底的に各用語の意味を定義してあり、そのあとにサンプルが乗っている。私は数学は暗記でカバーしたタイプで苦手だったが、この構成だったら、わかったかも、とびっくりした思い出がある。

日本の算数

http://www.gakujutsu.net/image555.jpg

英語の算数のページ

What is Data?

日本を米国と同じスピードにするために

 つまり、この仮説の部分においては、日本で技術導入がスローである原因の克服には2つの方法がある。1つは、日本人の気質に合わせて、説明の仕方を変えるか、「理解を重視する」考え方を広めていくかだ。  自分的には、短期的には、最初の方法を採用し、同時に、「理解を重視する」考えを広めていくのがいいかなと思っている。おそらく、ソフトウェア産業のプロフェッショナルの場合、「理解を重視する」やり方のほうが圧倒的にあっていると思う。

 しかし、そんなにすぐにモデルチェンジできるわけでもないので、多くの人のラーニングスタイルを考慮して新しいコンセプトを広めていきたいと思う。実際、オブジェクト脳の後に開発した、「オブジェクトゲーム」という手法を使えば、当時理解が難しいといわれたオブジェクト指向を、数時間で、みんなに納得してもらえるようになった。日本人でも工夫したらいけるのだ。

docs.com

日本人でも、「米国以上」のスピードになるチャンスはある

 一点だけ日本人に有利なお話しもしておきたい。日本人の多くは、「体験型」で「見て真似して学ぶ」のが得意だ。実際私も、同僚の誰よりも一度見たものを正確に真似することに関しては抜きんでていると思う。アメリカの人が完全に理解するのが得意なのと同じように、われわれも、見てまねる方法ばっかりやっているので、それは一日の長がある。つまり「本物」を観察したのならば、それを吸収するのは彼らより速いのだ。  だから、冒頭のバリューストリームマッピングの彼にも適切なアドバイスを多く送ることができたのだ。理解だけでカバーできる範囲も限界があるので、「やってみる」領域に関してはかなりの一日の長があるのだ。

f:id:simplearchitect:20160804205828j:plain

 ただ、それだけをするのは、中長期的に見ていい作戦ではない。しっかりと「理解重視」のやり方を身に着けていく方がおすすめだ。私は以前は、体感型だったが、インターナショナルチームに入って、「完全理解派」にモデルチェンジを試みている。道半ばだが、焦らずやれば、できそうな気がしている。だから、今後は、DevOps の導入も、しっかりとこの2つのラーニングモデルの違いを考慮して日本でも米国並みの実践をできるようにいろいろ準備をしていきたいと思う。

「ウォータフォールは何のメリットも無い」のラジオ番組の公開

f:id:simplearchitect:20160726045407j:plain

おかげさまでたくさん読んでいただいたブログですが、この内容について聞いてみたいということで先日アジャイルラジオという番組の収録を行いました。

simplearchitect.hatenablog.com

前半、後半になっています。私の意図していることなどについて、自分の声でお話しさせていただきました。 よかったらお楽しみください。

agileradio.github.io

agileradio.github.io