docker の実行環境を選択する

　現在、様々な環境で docker が動作します。先日同僚から、「docker はいろんな環境で動作するが、どの環境で動かせばいいの？」と質問を受けました。

今、初めて docker を始める場合、どこで環境を作ればいいのか迷ってしまうほどたくさんの選択肢があります。この問いに自分なりに答えてみたいと思います。

このポストは現在(2016/3/15)のところの私の個人的な意見を書いておきたいと思います。よりよい選択があれば是非コメントいただきたいと思います。

　またこの話は、私より1000倍 docker に詳しい方に共有しておいたので、彼がもっといい記事を書いてくれるかもしれません！

1. 開発環境

開発や、docker を試してみたい目的で docker を動かす環境が欲しい場合、現在はほぼ一択で、「Docker Machine」を使うと良い。Docker Machine は、docker の実行環境を簡単なコマンドで作ってくれる。サーバーは自分で作る必要はない。

docker のページから Docker Toolbox

Docker Toolbox | Docker

をダウンロードしてインストールしよう。準備はこれだけ。これは簡単だ。Win / Mac をサポートしている。

上記のコマンドで --driver オプションを指定している。オプションを指定すると、VirtualBox や Hyper-V もしくは、Azure などのクラウド環境にサーバーを作ることができる。開発時には、手元のPCに環境を作るVirtualBox か、Hyper-Vが良いだろう。無駄にお金を使う必要はないし、何も違いがない。そもそも手元の方が早い。クラウド環境だと、ファイアーウォールの設定等実際に運用する時には必要なことを考慮する必要がある。

$ docker-machine create --driver=virtualbox dev

Docker Toolbox をインストールしたあと、これだけで docker を実行する dev という名前のサーバーが起動する。実際には、docker 実行環境がインストールされたバーチャルマシンが起動する。docker は、手元のPCでもサーバーでも全く同じように動作するのが売りなので、大抵のことはDocker Machine で十分だ。この後、docker-machine env devとタイプしたときに一番下に出てくるワンライナーを実行すると、環境設定が終了して、docker が使えるようになる。Windows ユーザへのTips としては、--shell=powershellとか--shell=cmdとかつけてあげると、それぞれの環境用の環境変数設定用ワンライナーを生成してくれる。下記はPowerShellを使った例だ。

PS C:\WINDOWS\system32> docker-machine env dev2 --shell=powershell
$Env:DOCKER_TLS_VERIFY = "1"
$Env:DOCKER_HOST = "tcp://192.168.99.100:2376"
$Env:DOCKER_CERT_PATH = "C:\Users\tsushi\.docker\machine\machines\dev2"
$Env:DOCKER_MACHINE_NAME = "dev2"
# Run this command to configure your shell:
# C:\Program Files\Docker Toolbox\docker-machine.exe env dev2 --shell=powershell | Invoke-Expression
PS C:\WINDOWS\system32> docker-machine.exe env dev2 --shell=powershell | Invoke-Expression
PS C:\WINDOWS\system32> docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS
NAMES
PS C:\WINDOWS\system32>

これだけで docker が既に使用可能になる。詳しくは docker-machine のコマンドのマニュアルを見て欲しいが、docker-machine ssh dev とタイプすると dockerのサーバーが起動している仮想マシンにログインすることもできる。このツールで大抵のことができる。

docs.docker.com

開発環境として、Docker Machine を選んでいる理由は、何と言っても手間が少ない、お金がかからないということに尽きる。docker の開発は基本的に

• Dockerfile を作る / テストする
• Docker-Compose のファイルを作る / テストする
• Dockerfile / Compose のファイルをリポジトリに格納する
• DockerHub にイメージをプッシュする

ということを実施することが多いだろう。Docker Compose は、dockerコンテナを組み合わせて環境を作るためのテクノロジだ。例えば、webとdbの組み合わせでシステムを構築したりすることが多いだろう。そういう場合に、Docker Compose 使うと設定ファイルを書くと、いい感じで動作してくれる。

docs.docker.com

Web-DB 構成を起動する　docker-compose.yml の例

web:
  build: .
  ports:
   - "5000:5000"
  volumes:
    - .:/code
  links:
    - redis
redis:
  image: redis

大抵はこれらのワークフローが簡単に構築できる環境があればいい。

2. シングルサーバ運用環境

次に、複雑な構成は不要だが、docker で作ったアプリケーションを手軽に公開したい場合のオプションを幾つか紹介する。

2.1. Docker Cloud

最も簡単なのはおそらくDocker Cloud だろう。docker 社が作成している SaaS で、ほぼ何もしなくても、docker が動作するインスタンスを画面 もしくはコマンドラインで起動することができる。実際のインスタンスは Azure などのいくつかのパブリッククラウドで動作する。簡単さでは右に出るものがない感じだ。

現在のところの課題は、Docker Compose が動作しないこと、リージョンによっては動作しなくなることがあるので、試してからにした方がいい。だが、今後、Docker Compose 対応すれば最も注目度の高い環境になると思う。

2.2. docker on Ubuntu

docker の入ったシングルサーバ環境をクラウド環境などに作る方法はたくさんある。

• docker-machine
• docker cloud
• ARM などの IaC のテンプレート
• Vagrant / Terraform の docker プロビジョナーを使う
• CoreOS :

　Docker Cloud を別とすると、Docker Machine がもっとも楽な方法だ。docker だけでなく、Docker Compose や、後述する Docker Swarm も使えるのも良い。

ただ、きっとこのオプションを選ぶ人は動作させるサーバーを「自分でコントロールしたい」と思う人だろう。自分でコントロールしつつ、できるだけ楽に docker 環境をデプロイしたい場合は、環境をデプロイする IaC テンプレートを利用するのが良いと思う。環境のデプロイがコード化されているのですぐにデプロイできるし、気にくわないところは、コードを変更して自分のものにしてしまえばいい。

　私は、Microsoft の中の人なので、Azure ぐらいしかよく使っていないが、他のプラットフォームでも同様のものはあるだろう。Azure の場合だと、Azure Resource Manager というテンプレートがあり、パラメータを設定してワンボタンでdocker 環境をデプロイできる。コードは JSON で書かれた簡単なものだが、自分のコードにしてカスタマイズすることもできる。Azure Portal からも、docker が動作する環境を複数選ぶことができる。HashiCorp の terraform を使うのも良い手だ。クラウドを選ばず記述できる。

blogs.technet.microsoft.com

Terraform by HashiCorp

　この際、CoreOS や Ubuntu ... 等の選択肢があるが、私が個人的にお勧めするのは現状では Ubuntu になる。世の中の手順や、3rd パーティツールの対応具合を見ても、最もテストされている環境と思われる。その点は CoreOS も悪くないのだが、自分でコントロールしたいという用途の場合は、CoreOS は、当然といえば当然だが、通常の Linux にあるコマンドがなく自分でインストールする必要になるケースが多く、サイズが小さいことを重視したい人にはお勧めだがそうでなければ Ubuntu という選択でよいと思う。例えば CentOS などを選択したい人もいるかもしれないが、3rd Party ツールのサンプル等でも大抵は Ubuntu なので、比較すると圧倒的にペインが少ない可能性が高い。

　サーバーを運用するときは、docker だけ使えればいいというケースではない場合も多いように思う。その場合は Ubuntu がお手軽だろう。ただ、今後は、CoreOS のようなサイズが小さいソリューションが重視される傾向にあると思う。昨今の PaaS の動向からすると、CoreOS のようなものは、PaaS の中身として使われることが増えるのではないだろうか？

3. クラスタリング環境

　さて、複数サーバーでクラスタリングを構成したい場合もいろいろ有力なオプションがある。それぞれに関してのざっくりした感想を共有したい。クラスタの場合は、決定的なソリューションは存在しない。各ソリューションによって、特色が違うので、その好みによって使い分けるといいだろう。

• Docker Swarm
• docker cloud
• Mesos / Mesosphere DCOS
• Nomad
• Kubernates

最初にお断りしておくが、私はKubernates だけ試していないのでその感想は他の方にお譲りいたします。

3.1. Docker Swarm

Docker Swarm はクラスタリングを構成する環境としては、Docker Compose もサポートされているため操作は快適に感じる。単にクラスタを構成したい場合のオプションとしてはかなりいい感じ。唯一の欠点をお話するとインストールが面倒臭いことにある。 　この点は、上記でご紹介した「IaC テンプレートの利用」がら楽だろう。Azure とかの例しかしらないので、恐縮だが、Azure の場合だと、Swarm クラスタをワンボタンでデプロイできる テンプレートが公開されているし、より凝ったものでも、Azure Container Service というサービス化されたテンプレートも公開されている。

docs.docker.com

azure.microsoft.com

3.2. Docker Cloud

Docker Cloud もスケールとかは可能だ。楽さにかけては No.1 ただし、前述したとおり Docker Compose に似た仕組みは動くが、Docker Compose はまだ動作しない。今後楽しみだ。

3.3. Mesos / Mesosphere DCOS

Mesosphere DCOS はクラスタ自体を１台のコンピュータのように扱える「データセンターOS」と呼ばれる仕組みだ。リソースのアロケーションとジョブ / サービスの実行、インストールが大変簡単だ。AirB and B で生まれて、Twitterや Apple でも使われているが、結構ごっついトランザクションをさばく必要のある基盤で使われる。 docker の実行も上記の２つに比べるとリソース割り当てを意識する必要があるので簡単ではないが、負荷の高い環境では要注目！

課題はインストールの面倒くささ。これはSwarm 以上のめんどくささだが、これも同じく「IaC テンプレート」が用意されている。Azure Container Service も内部は Mesosになっているので、そういったものを利用するといいだろう。

mesosphere.com

azure.microsoft.com

3.4. Nomad

　最後にご紹介するのが、HashiCorp の Nomad だ。Nomad はよりシンプルで、多機能ではないが Mesosに近いことができる。Nomad の素晴らしいところは、インストールが劇的に簡単で、シンプルなので理解がしやすいところだ。上記のソリューションと同じく、「IaC テンプレート」を使うと良い。私が個人で書いた Nomad と Docker がインストールされた環境を簡単に Azure で使えるようにしたテンプレートが次の通りだ。テンプレートのインストール部分は劇的に簡単だ。尚、HashiCorp は Vagrant で有名な会社だが、他にも良質なソフトウェアを多数作成している。Consul とクラスタ構築の基盤が Nomad でも使われているが、先ほど紹介した Swarm でもこのConsul がクラスタを構築する基盤の一つとして採用されている。

Nomad - HashiCorp

これは私が書いた ARM のテンプレートで、学習目的で Nomad と Docker が入ったインスタンスを５００台までプロビジョンできるコード。GitHub ページの Deploy to Azure ボタンを押すと Azure に仮想サーバーが Deploy されるにようしている。

github.com

まとめ

　簡単ですが、現在の docker 環境構築のパターンをまとめてみました。少しでもお役に立つと嬉しいなと思います。繰り返しますが、日進月歩の分野でもあるので、コメント や他のいい方法など Welcome です！ 私も勉強したいです！

本番環境の「聖域化」を再考する - DevOps の「リードタイムの短縮」の次に来るもの

DevOps という言葉は2009年のVelocity conference でFlickerが発表した 10 deploys per day という発表が起源になっています。

10+ Deploys Per Day: Dev and Ops Cooperation at Flickr from John Allspaw

www.slideshare.net

残念ながらアジャイル開発宣言のような公式の定義がないため、多くの人がその定義をしようと頑張っています。私はその起源や、インターネットでいろんな人が定義している内容を総括して次のように「DevOps のエレベータピッチとは」という問いに答えてきました。

ビジネス・Dev・Ops が協力し、ソフトウェアのライフサイクルと価値の創出を改善する活動

これはこれで特に悪くないとは思うのですが、正直若干「ふわっ」としているのは否めません、また、私が個人的に、Microsoft で一番の DevOps チームと呼ばれる Visual Studio Team Services のチームの事例を研究していく中で、「現在形」の DevOps の形について考えがまとまってきたのでシェアしたいと思います。

リードタイムと10 deploys per day

DevOps の定義を掘り下げる前に、メリットについて考えてみましょう。DevOps のメリットとその本質として最初に言及されるのが、「リードタイムの短縮」です。DevOps の起源のプレゼンテーションにもあったとおり、「１日１０回以上も本番に安全にデプロイできるほどの、自動化と仕組み作りをできるようにする」ということはイメージとしてわかりやすいかもしれません。

注：10 deploys per day に対する私の意見とディスカッションはこちら*1

実際には改善活動なので、いままでアイデアを思いついてから、それを本番にリリースできるまでの時間が「６ヶ月」「３ヶ月」だったのが、冗談抜きで「３時間」とかになったりします。

　私も「1日に10回以上デプロイ」は「起源」で使われていますし、大変わかりやすいものなのでDevOpsの「エレベータピッチ」的に使っています。実際は１０回以上リリースできても、「価値」が伴っていないければ意味がないのですが、わかりやすさのためそれをつかうことが多いです。

　私にとってこの基準はとてもしっくりきていたのですが、先で述べたVisual Studio Team Services のチームのDevOps 実践の事例を見ていくと、実際には、「リードタイムの改善」に関して言及しており、リリースサイクルの短縮は語られていますが、本当に小さな扱いです。なんでだろうと思っていたのですが、その理由はこのチームは「リードタイムの短縮」の先に進んでいるからそっちの方が素晴らしい成果だからということが言えます。実際に強調されているのは、「本番からのフィードバック」「フィーチャーチーム」そして、「仮説駆動のバックログ」「アラートルーティング」「テレメトリ」などです。

リードタイムの次に来るもの - Gene Kim の 3way

【DevOps Enterprise 2015 参加レポート】第 2 回 – DockerによるDevOpsソフトウェアサプライチェーンの改善 - Live DevOps in Japan! - Site Home - TechNet Blogs

私が考えるまでもなく、既に有名な概念があります。 DevOps の世界で著名な Gene Kim 氏がまとめた「DevOps の 3 ways」です。3 ways は私の別のブログで言及をしていますので、詳細はそちらをごらんください。私は最近はGene Kim 氏の 3 waysで DevOps を考えるのが非常にしっくりきています。

上記の図のようにDevOps の達成するゴールを３つの段階に分けています。

1 way: リードタイムの短縮
2 way: 本番環境やユーザからの学び
3 way: 継続的な実験と検証

それぞれについてご説明したいと思います。

1 way: リードタイムの短縮

　これはリードタイムの短縮です。これは 10 deploys per day などのキャッチフレーズの背景にあるリードタイムを自動化や組織変更、フィーチャーチームを構成して、短くしていこうというのが最初のゴールです。これは、アイデアを思いついてから本番にデプロイするまでを高速化することにあります。

　これのために使われる DevOps プラクティスの例は次のようなものです。

　自動テスト
　継続的インテグレーション
　継続的デプロイ
　Infrastructure as Code
　リリースマネジメント
　ロードテストと自動スケーリング
　フィーチャスイッチ
　フィーチャーチーム / Kanban
ChatOps
:

注; DevOpsプラクティスの参考 DevOps Practices | IT Pro Guy & Tesar.info

まずはここを目指すだけでも相当ビジネス的にインパクトがあります。

　この辺りは、アジャイルや、Continuous Delivery、アジャイルテスティングの考えを元に、クラウド・インフラ自動化技術、Web Operation あたりのアイデアが元になっていると思われます。

2 way: 本番環境やユーザからの学び

1 way が達成できたら、次の段階に進みましょう。

2つめは本番にデプロイした後に、そこから如何に学んでいくかという、本番から次のバックログへのフィードバックループを指します。本番からの学びを如何に効率良く行っていくかという視点です。

この目的のために使われるプラクティスは

アプリケーションパフォーマンスの監視
可用性監視
自動回復（ロールバックとロールフォワード）

これも、Web　Operationやインフラの自動化技術、クラウドの自動化技術の影響を受けていますがこのような技術で本番環境からの学びを高速に反映することができるようになります。

3 way: 継続的な実験と学び

　DevOps の最終形態です。 今までは本番環境は「聖域」と考えて、失敗しないように準備や計画をしまくって慎重にデプロイするものでした。ところが今は「本番環境」は聖域ではなく、「仮説を検証する場所」という考え方に変わってきています。結局のところ、デプロイしてみないと、全て卓上の空論です。実際に本番にデプロイして、要求的にもアーキテクチャ的にも学びを得て、早く失敗して、早く方向修正して、資金が尽きる前に自分のビジネス的に「正しい方向性」を見出していく実験をします。 　　このサイクルを如何に高速に回して、「正しい方向性」を見つけていくか？のゲームです。

　ここで使われるプラクティスは

　仮説に基づく開発
　　・運用環境でのテスト
　　・フォールトインジェクション
　　・使用状況監視 / ユーザテレメトリ
　・仮説駆動のバックログ
　　　　　：

　このあたりは、リーンスタートアップのムーヴメントに非常に影響を受けていると思います。リーン系の考えを学んだことがある人は、この辺りはスッキリ受け入れられるかもしれません。 　ただ、今の DevOps ムーヴメントがリーンスタートアップの盛り上がっていた頃と違うことは、エンタープライズ系企業でもこれらの「実験」の考えを採用して、高度な自動化、コラボレーションを実現できるようになってきたことです。

たんにリリースサイクルの短縮だけを考えると見えてこない、DevOps の次の一歩がようやく見えてきました。こういった実践が日本でもガンガンに増えてくるのを少しでもお手伝いしたいなと思っています。

参考

この記事と一緒に、Visual Studio Team Services のDevOps Journey の記事を読まれるとより一層よくわかるかもしれません。

www.publickey1.jp

doc.co

*1:10 deploys per day VS the lead time is less than 3 hours - How do we get to know if we are a decent DevOps team? - Live DevOps in Japan! - Site Home - TechNet Blogs

生産性を向上させるためには、日本人エンジニアに英語での会話力は必須だと思った

私はマイクロソフトのインターナショナルチームで働いています。特に私は以前からUSのエンジニアの生産性の高さの秘密を学びたいと思っています。今回は同僚からの何気ない一言からの気づきをシェアしたいと思います。

David からの何気ない一言

私は無宗教で葬式の時は曹洞宗なのですが、以前から聖書には興味がありました。私の叔父はドイツ、アメリカに長年住んで仕事 をしていました。そんなガチに海外で生活していた彼が言っていました。

彼らの文化を理解したかったら聖書を読むのがいいよ

　確かにイギリスにいた時もあらゆる場面で、日本に帰っても海外の映画を見ても様々な場面で、聖書の影響を感じます。 私は自分の仲間をより理解したいし、明るさ、生産性の高さ、芸術性などを本当に尊敬しているので、是非ともその考えを学んでみたいと思っていました。

　私の尊敬する同僚の David もクリスチャンなので、彼にどの聖書を読んだらいいか教えてもらいました。スノボに行った時も会話しましたが、昨日改めて私に一番あった聖書を選んでくれて、一言こう言ったのです。

君がこの本を読んで、一緒にディスカッションをするのを楽しみにしているよ。

たぶん、日本人だったら、自分がよく知っている分野の本をお勧めした場合、こうは言いません。きっと「読んだら感想聞かせてな」だと思います。

初めてその分野の本を読もうとしている人に「ディスカッションをしよう」という発想自体がありません。

マイクロソフトではやたらディスカッションが多い

そういえば、自分のチームもやたらディスカッションが多いことが頭によぎりました。一方的な情報伝達の会議みたいなものはほぼなく、 定例会議も例外なく、ディスカッション形式のものです。もしかすると、日本でイメージするディスカッションとUSでのディスカッションは意味が 違うのでしょうか？英英辞典で調べてみました。

1. If people discuss something, they talk about it, often in order to reach a decision。

2. talk about something with a person or people

違う辞書で調べてみましたが、1. の場合はほぼ同じイメージ。ただ、2. の場合は、日本人の持っている「議論」よりは「お話し」 というノリに近い感じです。しかしどちらの定義も日本人が持っているイメージよりずっと気軽に話をする感じです。

ディスカッションはバトルではなく、楽しいもの

　自分が持った違和感の正体を考えてみると、「ディスカッションはその対象をよく知っている人同士がやるものである」というイメージがあることに気が付きました。では、「ディスカッション」は何のためにやるのでしょう？

　私が持っていた「ディスカッション」のイメージを掘り下げると、意見を交わして「どちらの意見が正しい」みたいなことを決定する勝ち負けがあるものでした。確かにそのイメージだと、初めてその本を読んだ人が、ベテランと話をしても意味がなさげです。

これは先の 1. の方の意味合いに近いです。だから「ディスカッション」はバトルみたいなイメージがありました。でも実際に、自分のチームで活動をしてきた経験を思い起こしてみると、どうも 2. のほうがよっぽど機会が多く感じます。

その目的は

「お互いが持っている意見を交換して、知識や考えを深めること」

　で、ディスカッションは「楽しいもの」というイメージがあります。ディスカッションをすることで、自分のわかってなかったこととか、気づいていなかったことを知ることができます。これは楽しいことです。

　本や資料を見ることは一方通行のコミュニケーションですが、フィードバックがあるので相当短い間に高い位置に近づくことが できます。そういえば今のチームのコミュニケーションでは、一方的に伝達があるコミュニケーションの形態はほぼありません。

　よくよく考えると、考えを「深める」というと、「その分野をよく知っている人だからできる」というイメージがありますが、 知識「０」の人だって「０」から考えを「深める」ことは可能です。 　

何かを一から学ぶにしても、一方方向で本当に理解できているかわからないことより、双方向のほうがフィードバックを得られるので、明確にわかってないことがわかりますし、一緒にいる人もわかっていない部分を「ちがうんとちゃう？」って言ってあげることができます。これはすごく生産的だしうれしいことですね！ 　

「間違えてたら恥ずかしい」感覚はもったいない

　自分の心に聞いてみると、自分が持っている「初心者のうちはまず自分で学んで、成熟したらディスカッション」という考えの裏には「自分がいうことが間違えてたら恥ずかしい」という感覚があったように思います。

　以前このブログでも書きましたが、自分がどんなレベルになっても、「知らないものは知らない」し、「理解を間違えているものは間違えてる」だけであって、だれでもあるし、恥ずかしくもなんともないと思います。それを知っているふりするほうがよっぽどかっこ悪いし、他人のそれを許容しないのもチームの生産性を考えるともったいない気がします。そして、それを後でこっそり調べるのも本当に生産性的には無駄な作業だと思います。理解できるまで聞いちゃえばその場でバリューが出ます。

自分にとってわからないことを聞くだけでも十分

　 そう考えると、ディスカッションをは「どっちが正しい」とかまったくもってどうでもいいことで、「自分の考えが自分なりに深めるための行為」と考えると、初心者時代からそれをやったほうがよっぽど効率がよさそうです。

　 　ちなみにディスカッションといっても、素晴らしい意見をいうとかじゃなくても全然かまいません。「教えてもらったけど、俺全然理解できてないわ」とか、「この用語ってどういう意味？」とか、ある意味理解できてなくてかなり的外れなことを言ったり、質問したりしてもそれで充分なディスカッションです。素直な気持ちを隠さず表現すればいいだけです。誰も「的外れだから勉強して来い」とか言いません。

だから全然自分にとって知りたいことをお話しするだけで十分です。

合意できないことに合意できる

　日本のマイクロソフトのエバンジェリズムのトップを務める伊藤かつらさんに教えてもらった言葉で「Agree to disagree」というのがあります。

「合意できないことに合意する」という意味です。別に合意なんかしなくても、どっちが正しいとか強引に決めなくても、相手のことを理解する助けになりますし、それでいいのではないでしょうか？ 　 そう考えると、自分の考え、知識を深めることができるなんて、なんてディスカッションって効率的だしなんて楽しいんでしょう！これが、「正しくないといけない」とか「議論に勝たないといけない」とか思うとめんどくさいし、楽しくなさそうです。そしてどうでもいいですね。

　思い起こしてみると、同僚がディスカッションをして意見が違うことがあっても、感情的になったり、揉めるとかそういう場面を仕事では見たことがありません。自分の意見を「こう思う！」というのはいいますし、「合意」に達しないことはありますが、「自分の理解を助けてくれてありがとう」といったノリであることが大半だと思います。

だから彼らはディスカッションしたがるんじゃないかなと思いました。

技術者には英語での会話力が必要

我々エンジニア系の英語に対する意見はいろいろあって、コンピュータ系の場合は英語はできたほうがいいという意見が多いですが、「読み書きさえできればいい」「話す機会はほぼないから、せいぜい講演が聞けたらいい」とか、そういう意見が多くて、「会話」はあまり重視されていません。正直言うと、私も英語の勉強が趣味だから会話は練習しましたが、正直「エンジニアとして必要だから」勉強したという感覚ではありませんでした。

　しかし、今、初心者の頃から「ディスカッション」をさせてもらえることの楽さと効率の良さが理解できてくると、今の自分のしょぼい英語力が本当にはがゆくなります。

　私の同僚はUSの人はすくなくて、私と同じように2nd Language learnerがほとんどです。ヨーロピアンとか、南米とか、インドの人とか中国の人とか皆、ガンガンにディスカッションをします。よく聞くと彼らの英語力が素晴らしいかといえば微妙かもしれませんが、それでも自分の思ってることをガンガン伝わるまで話して、ほかの人の意見も理解できるまで聞いてディスカッションをしまくっています。

むしろ「わかってない」からディスカッションする

　私は、彼らがそのことをよく知っているからだと思い込んでいましたがよくよく思い起こしてみるとそうじゃないのかもしれません。むしろ「わかってない」からディスカッションをするのではないでしょうか？

　今の実力とか、あってるか否かは関係なくて、自分がそう思っていることを話してそれでフィードバックを受けて、お互い影響しあって、考えや知識を深めて、そして話終わったら、お互い「助けてくれてありがとう」という感じの気がします。

　今はスカイプや、音声チャットなど普通にできます。チャットでもできますが、音声のほうが１００倍以上情報量がありインタラクティブ性があり、フィードバックが早いです。日本人でも、すごくイケてる技術者の人は、知らないことを知らないと素直に言うし、自分の意見が合ってるとか間違っているとかを恐れず、自分の意見をシェアします。

　 こういう楽しい「ディスカッション」ができる体質に多少なりともなることで、いろんなことが楽になるし、効率的になっている気がします。

日本だけに閉じているのはもったいない

　そうなると、こういうすごく効率的なことを「日本国内」だけでやるのはパイが少なすぎるので、すごくもったいないと思います。例えば私は、DevOps のことが分からなければ、DevOps のことに超絶詳しい David やチームメートとディスカッションすることができます。海外カンファレンスに行けば、著名な本を書いている経験ある著者と直接ディスカッションができます。これは本当に効率的なことです。

こんな楽ちんになることが、英語の会話力がないばっかりに、この恩恵を受けられないとなると相当効率が落ちてもったいないです。逆にもっと会話力があれば、もっと楽に知識を深めれるのに！！！と思うわけです。私も歯がゆいのでもっと高めたい！

　最近はディスカッション重視のカンファレンスが増えているように思います。DevOps Daysなども、著名な人のプレゼンオンリーより、参加者同士のディスカッションが重要であるようです。それも今ならそちらのほうが価値があると十分うなづけます。

いわゆる「英語力」ではない「会話力」が重要

　ただし、ここでいう「会話力」は英語のTOEICのスコアが高くなってから、、、とかじゃなくて、たとえそれが300点台であっても、自分の言ってることを伝え、相手の言っていることを理解する「気合い」もしくは「慣れ」の要素での「会話力」だと思います。

　私も昔イギリスに行っていたときに、英語力が下から２番目の「Elementary」のクラスの奴が、イギリス人のネイティブの女の子をナンパしようとしていました。（そして会話が成立していましたｗ）別に高度な表現を使う必要はなくて、しょぼかろうが、単語だろうが、伝える、理解しようとする意志の問題だと思います。正直私もここはまだうまくできていませんが、技術ではなく意識の問題じゃないかと思っています。今までは「会話力」のメリットをそこまで感じませんでしたが、「ディスカッション」の楽さと効率性を知ってしまった今となっては是非身に着けたい能力です。

まとめ

そういえば、昔、スクラムの第一人者の江端さんがこんなことを言っていました。

僕は本を読まないんですよ。直接作者に会いに行きます。

当時は単に「スゲーな！」と思いましたが、今考えると、最も効率的に新しい技術を学べる素晴らしいTipsと思います！ 是非皆さんも「ディスカッション」の楽しさを実現するために、まず自分から一歩を踏み出してみませんか！海外の話だけではなく、自分から、自分の職場で「楽しくディスカッション」することから始めてみませんか？

というか、私がまずやってみたいです！　日米の環境問わず、こんなことから始めてみようと思っています。

• 素直に自分の思ったことを言い、理解できるまで相手の話を聞くようにする　（日、英関係なく。自分のレベルや、あってるかは気にしない）
• ディスカッションは、お互いの知識を深め合うための助け合い行為だと思って話をする
• ディスカッションを楽しむ。意見が違う人がいても、フィードバックが得れたとか、違う意見が聞けたと喜ぶ
• 知らないこと、よく理解できてないことほど正直にそういう。たとえ相手がだれであっても。結局そっちのほうがフィードバックを得られ、誤解もなく、得ができる。

そして

• 自分や、相手が、「知ってる」か否かどうでもいいこと。今の瞬間から、お互いの位置から、お互いが知識をシェアして高めあうことを助け合い、楽しむことに集中する。今、その瞬間の楽しみと、生産性の向上に注力する。

ということを心がけて、明日から実践してみたいと思います。実験なので、何かまた気づきがあればシェアしたいと思います。

とりとめがありませんが、自分のメモとして。

私は Infrastructure as Code をわかっていなかった

私はここ１週間ほど、同僚の David の一言で Infrastructure as Code について頭が大混乱状態でした。

それは次の一言です。

Chef や Puppet は大体の部分は Infrastructure as Code じゃないよね。ARM (Azure Resource Manager) はそうだけど。 ただ、Chef-Provisioning は Infrastructure as Code だよね。

もう頭が大混乱です。なんとなく言わんとしていることはわかりますが、私は今まで Chef とか、Puppet とか、Ansible とかで やっているようなことが、Infrastructure as Code と思い込んでいましたが、何か間違っていたのでしょうか？そういえば、 Chef はConfiguration Management Toolと紹介されていたなとか頭によぎります。

Chef (software) - Wikipedia, the free encyclopedia

ここ数日様々な記事やビデオを見て Infrastructure as Code について再考してみたのでここに共有したいと思います。

Infrastructure as Code 再考

まず定義から行きましょう。David 本人が定義している Infrastructure as Code は次の通り

Infrastructure as Code とはソフトウェア開発で実施されてきたテクニック、プロセス、そしてツールセットをシステムやアプリケーションやミドルウェアのデプロイやコンフィグレーションの管理に役立てるための戦略のことである

itproguy.com – DevOps practices

DevOps Practices | IT Pro Guy & Tesar.info

他も見てみましょう Thoughtworks の人の定義

Infrastructure as Code とは、インフラの構成を管理したり、プロビジョニングを自動化するためにハイレベル、もしくは宣言的な言語でコードを書くことである。これは単にスクリプトを書くのではなく、ソフトウェア開発で実証されているプラクティスを使う。例えば、バージョン管理、テスト、小さなデプロイメント、デザインパターンの使用などだ。

www.thoughtworks.com

どちらの定義にも書いてあることは、Infrastructure as Code は、インフラやプロビジョニングを自動化するための、ハイレベル / 宣言的なコードを書くプラクティスであり、それらがコード化されることで、単に自動化できるとかではなく、ソフトウェア開発で培われてきたプラクティスがインフラ構築にも使えるようになることが大きなイノベーションです。具体的には、バージョン管理ツールを使うことだったり、テスト駆動開発やCIだったり、リファクタリングだったり、今までソフトウェア開発でしか使われてこなかったことが、インフラの構築にも使えるようになるわけです。

ここまでは私が理解していたことです。この「ソフトウェア開発のプラクティスをインフラ構築に使える」というイメージはChef のチュートリアルを実施するととても分かりやすいです。このチュートリアルでは、Test Kitchen や、Serverspec というツールを使って、インフラストラクチャをテスト駆動開発で実施します。

Learn to develop your Ubuntu infrastructure code locally - | Learn Chef

３種類の Infrastructure as Code の領域

実際に私のイメージするインフラをコード化したものとしては３種類の対象があります。１つは「VMや、PaaS、Network」などの 生成の自動化、そして、もう一つは起動したVMに対して、各種のツールやライブラリをインストールして設定していくことを自動化するものです。前者は、ARM（Azure Resource Manager), Azure / AWS SDK, Chef-Provision などでできる領域であり、後者は、Chef や Puppet や Ansible、Windows 系なら PowerShell DSC が実施してくれる領域です。様々なインターネットの定義を確認しましたが、前者と後者がまとめて Infrastructure as Code と呼ばれることが大半のようです。ちなみに３つめはコンテナですが、今回の記事では割愛します。

私も頭が混乱して、David 本人に聞いてみましたすると、彼は、「このビデオを見てみてよ。それでまだ質問があったらいつでも聞いてくれよ」とのことでした。

Configuration as Code

そのビデオでは、私は知らなかったのですが、先ほど述べた前者と後者を Infrastructure as Code と、Configuration as Codeとして明確に使い分けていました。David 本人もこのビデオでちらと言っていますが、Configuration as Code とみんながみんなそう呼んでいるわけではないけど、自分はこの考えがメリットがあり好きだから使っていると言っています。

channel9.msdn.com

　実際にインターネットで検索すると、いくつかの Configuration as Code のアーティクルが見つかりました。

DevOps Practices:Configuration as Code from Doug Seven

www.slideshare.net

dzone.com

Configuration As Code - Adoption of the Job DSL Plugin at Netflix from Justin Ryan

www.slideshare.net

　Wikipedia の Infrastructure as Code もよく見たら、Configuration as Code の部分は「extension」と書いてあります。

Infrastructure as Code - Wikipedia, the free encyclopedia

本当の歴史はわかりませんが、きっと 一般的な用語の Infrastrucure as Code は、きっと AWS SDKぐらいから始まっているのでしょう。それが、だんだん拡張されて、Configration の領域もそういわれるようになったという感じでしょうか？

Infrastructure as Code と Configuration as Code

このビデオやアーティクルで Configuration as Code を明確に分けるメリットについて述べられています。

• Dev と Ops の役割が明確に分かれること

• 混乱がなくなること (Infrastructure as Code と Configuration Management)

• ライフサイクルの違い

最初のポイントに関しては、「DevOps と逆方向じゃね？」とお思いになる方もおられるかもしれません。ただ、私の意見としては、DevとOps はフィーチャーチームとして同じチームになるほうがいいと思いますが、フルスタックエンジニア的なものになる必要はないと思っています。これは意見がわかれるところでどちらでもいいと思います。個人的には、Dev と Ops というのは萌えポイントが違うことが多いと思うのです。

　例えば、私と一緒に働いている小塚さんという非常に優秀なITProのクールガイがいるのですが、彼はたまに私のやっていることが「全然興味ない」と言っています。一方、Dev出身の私は、彼がたまに、OSのパラメータをいじってパフォーマンスがちょっと向上したとかいってほくそ笑んでいる姿をみて「まったく興味ないわ」と思っていますw。やっぱり人は自分が楽しいことをやって、それで周りと協力するほうがずっと仕事も楽しいと思うので Dev と Ops はあったほうがいいと思うのです。お互いのキャリアは一瞬で簡単に身につくものでもありません。 そういう全然違う人が同じチームで助け合う姿のほうが私は DevOps として楽しいんじゃないかと思っています。

自分的な結論

　また、ビデオでも、David が多くの人が、Infrastructure as Code と Configuration Management の混乱を感じていると 言っています。私も思いっきりそうでした。Chef は Configuration Management Tool であるが、Infrastructure as Code でもあるという風にすると、確かにどこに「インフラ」はいっちゃったのかな？という感じになります。

　きっとこのInfrastructure as Code のムーヴメントは、元Develper の人に主導されてきたのではないか？と仮説を立てています。 私のようなDevの人からすると、コードを書くのに集中したいので、デプロイする先のは、まるっと「インフラ」という感じなので、その 細かい違いに無頓着です。 　一方 David は ITPro guy と名乗るぐらいなので、ITPro の人です。彼にとっては、インフラ構築と、コンフィグレーションは まったく別物で、使うタイミングも違うものという考えをしていました。例えば、「コンフィグレーション」は何回か実施します。

　というわけで、私も David の考えに大変共感しましたので、今後は Infrastructure as Code と Configuration as Code という２つの用語を使って明確に分ける派になろうと思っています。

おまけ: Donovan Brown の姿勢

このビデオのDonovan Brown の姿勢がとても好きです。彼は、Visual Studio Team Services の Product Manager で、DevOps を広める立場にあります。その人が「私は Infrastructure as Codeがわかってないんだ」と言って、David にビデオという人前できいてそれをなおかつ共有するとか、日本人ではありえない展開です。でも彼は演技ではなくて素直にそれを人前で聞いています。そしてそれをシェアして、同じように思っている人と学びを共有しました。私もそうありたいと思います。

日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む

私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日本なので日本側のオペレーションも実施しています。

前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この２つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。

見えてきた「物量」の違い

　私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日本だとしょっちゅうです。日本のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか？いくつかの事例を通じてだんだん見えてきたことは１つのことをこなすための「物量」が違うということです。

海外イベントに行った時の報告の違い

　 　一つの例を具体的に考えてみます。インターナショナルチームで、以前高額のDevOps Enterprise 2015というイベントに参加した時のことです。インターナショナルチームでも当然レポートとかはあるのですが、一般的に大変シンプルです。E-Mailで、Wordでいうと1-2ページ程度、大まかにポイントがまとまり、写真で雰囲気がわかればオッケー的な感じです。ですので、これを作るのはそんなに時間がかかりません。２－３時間ぐらいでしょうか？

　一方日本側として、海外のイベントに参加した時の報告は、プレゼンを作って、そのプレゼンをみんなで見れるように報告会があり、それが録画されます。これはとてもいいことなのですが、報告する人からすると、最低１日はがっつり準備が必要になってくるでしょう。見るほうも１日のイベントになります。

ちなみに、私が初めてインターナショナルチーム向けにレポートを書いたときに、がっつりとした日本式のものを書いて提出した事がありました。それは没になりました。というのも、彼らによると「読むのに時間がかかるからシンプルなのを」とのことでした。

会議に対する姿勢の違い

１つの会議に参加する工数もずいぶん違います。この辺りはMSの日本チームも米国チームと近いので、過去に日本の企業で務めていた時のことと比較してみます。インターナショナルチームの会議は、会議を実施している時間はとにかく集中していて、議事もOne Noteという共有サービスを使いその場でシェアしてシンプルなものを書いていきます。だから、会議の前も、後も何もする必要がありません。必要な時間は会議の時間だけです。

　ところが、日本で過去に実施していた典型的な会議の場合、実施前に準備し、実施後に、数時間かけて議事録を作成します。その議事録も、会議の内容がすべて収まったような詳細なものです。また、会議では次の会議までにこれを済ませてほしいという重厚な宿題がだされるケースも多くあります。

　ワークショップを開催する例はどうでしょう？

　例えば米国でValue Stream Mappingというワークショップを同僚のDavidと実施した時のことです。会場に行ってワークショップを実施して、他チームのプロセスや課題を見える化してディスカッションします。ワークショップをしながら、テンプレートに簡単なテキストベースで記録をとります。手書きでダイヤグラムを作成、写真をその場で撮影して共有にアップロードします。他チームのメンバのほうも、「後日資料をまとめて提案しててください」みたいなことは言われず、「いやー助かったわ。次はこういうことお願いします」という感じでその場が濃厚に終わります。

　私はゲスト参加だったので、何もしなくてもいいのですが、折角なのでバリューを出そうと、写真を撮りまくって ほかの仲間と共有するために、ワークショップの進め方の資料をその場でさっとつくりました。さすがにそれはワークショップ中に終えるのは無理だったので、終わった後１時間ぐらい作業していました。Davidがやってきましたが私がワークショップの 続きのことをやってるのを見て「何をしているんだろう」という感じの若干微妙な顔をしていました。彼らにとっては、ワークショップの作業の続きがワークショップの後にも行われているのが、不思議なのかもしれません。

そして、Davidのもう一つの会議が終わった後、４時ぐらいですが、さっさと切り上げて一緒にスノーボードに行きました。なぜなら、会議の後に必要な残作業などないからです。

万事がこんな感じで、必ず「会議をしている時間」の中で基本的にすべてが無理なく完結するようにできています。会議の間は集中していますが、その前後にかけてる時間が全然違う感じです。でも成果はどの程度かわるのでしょうか？

お客様との会議でもかわらない

驚くことに、これは、お客様が相手でも変わりません。先日も欧州のお客様とIoT x DevOpsのディスカッションをしたときのことです。たまたま参加させてもらいましたが、500人ものデベロッパーを抱えるお客様のところで、ハッカソンを開催して業務プロセスを変えるというイベントの相談でした。お客様は手ぶらで来ていますが、こちらに対してやってほしいことがとても明確です。こちらも手ぶらです。ディスカッションは濃厚に行いますが、終わった後にやはり議事録をだしてくれとか、提案してくれとかそういう話は一切ありません。びっくりしたのですが、「500人ものハッカソンを開催して、業務プロセスを変える」というイベントを行うという決定が、その場で「じゃあ、やりましょう。」と決定されたことです。

日本だったら、上の人にお伺いを立てて、稟議を通して、承認されて、、、、とかあるところなのに、全然違います。これはスピードで勝てるはずがありません。

考え方の違いに対する考察

万事がこのような感じで、結局のところ、彼らの生産性が良い大きな理由は、彼らがものすごい量のことをものすごい速さで効率的にやっているのではなく、物理的に「量」が少ないからということが大きいと思います。アジャイルのコンサル時代 に学びましたが、改善の最大のポイントは「やらないことを増やす」ことです。日本の文化だと、どうしても、仕事というのは「献上」モデルになっていると思います。仕事の成果を「献上」する相手の生産性や成果を最大化しようとします。だから「献上する側」が楽かどうか、時間がかかるか？はあまり考慮されません。 　一方インターナショナルチームだと、「チーム全体の生産性」をあげるように工夫されているように感じます。日本だと「献上」する相手を敬い、そこに最大限のパワーを使う感じでじゃぶじゃぶ時間が過ぎていきますが、インターナショナルチームだと、後述しますが、「助け合い」という感じで上下関係もないので、仕事をやる側の人にとっても「大変」なことは要求されません。

　よく外資系に務めていると「本社から、とてもやれないようなことを要求された」とかよく聞きますが、本当のところは、１つの仕事に対する、仕事量イメージの違いが生み出している不幸のような気がします。私はBOSSにとてもできないような仕事を要求されたことは１回もありません。彼のイメージする仕事をこなしているのは本当に楽に定時内で楽々できるものです。 　きっと、仕事をお願いするほうがそういうイメージなのだと思います。ところが、日本側からすると、先ほどの会議の例でもそうですが、「日本式」に同じ仕事をするイメージをすると、ものすごい物量になってしまうということではないでしょうか？ だから、本国側も「なんで、あんなに簡単な仕事を頼んでるのに、日本側は大変だとかいうんだろう？」みたいな感じになっているのではないでしょうか？

上下関係がない

　ほかに気づいたことは、日本では「偉い」人がいるのですが、インターナショナルチームでは「偉い」人がいないということです。インターナショナルのチームでは、「BOSS」や「マネージャ」はいるのですが、彼らが「偉い」という感覚がありません。単なる同僚で違う役割の仕事をしてくれているという仲間という感じです。彼らも私に命令をしてくるなんてことはなく、私に意見を求めたり、チームで一緒に仕事をするのがうまくまわるのに、協力してくれている感じです。 一方日本では「偉い人」が存在するので、「偉い人」にお伺いを立てないと万事何事も進まなかったりします。チーム内でも「偉い人」の順番があって、「偉い人」が若い人に指導をするみたいな雰囲気があります。インターナショナルチームでは、誰も年齢とかを気にしません。自分で考えて、お互いが助け、助けられ、お互い感謝する感じです。だから、基本的に自分で意思決定をして物事を楽に進めることができます。もちろん時にはBOSSに相談したほうがいいことはありますが、頻度が圧倒的に少ないイメージです。 基本仕事は、自分の意志で「俺これやるわー」というノリでやるもので、KPIのみがあり、強制的にやらされることはない感じです。だから圧倒的にストレスがありません。

日本で生産性を上げるために

外国人上司にしょっちゅう言われることは「最も少ない工数で、最大のインパクトを」ということです。彼らは私がたくさん工数を使うこと、休日も働くことを全くいいと思っていません。例えピカピカな成果を休出して出したところで、微妙な顔をされるのが関の山です。

　大量の物量を速い速度でこなそうとしても結局無理がかかって、結局時間外労働することになります。それよりも、物量を減らして、本当の「実」をとる方法を考えます。 「偉い人に献上する成果」だけを最大化するのではなく、「チーム全体の生産性」を最大化させるために、「チーム全員が大量の仕事をしなくてもいい仕組みづくり」をするほうがよっぽど簡単でしょう。

仕事をする側も楽になる仕組みづくり。余った時間でさらに新しいことも取り組みやすくなりそうです。

　でも、こう書くと「いやー君が言う通り、文化が違うから日本では無理だよ～」という声が聞こえそうですが、日本でこのレベルのことをやっている会社さんを私は知っています。ソニックガーデンさんです。倉貫代表のブログがあるので、これを読めばその考えの一端に触れることができるでしょう。

kuranuki.sonicgarden.jp

　私が一度彼らとお仕事させてもらった時です。彼らは私のクライアントでした。ある仕事をするために会議をするという段取りになったときです。代表の倉貫さんがその時に私に言ったことが衝撃的でした。

「牛尾さん。会議をやるときに準備はしてこなくていいです。無駄ですので。その代わりに会議のその場で良い成果を出しましょう。」

　普通でいうと、人を雇うときに、その人にいっぱい仕事をしてもらいたいと思うのが普通だと思います。だから新しい仕事を始める前、クライアントは私がいっぱい準備して、提案書とか作ってくれることを期待するのが普通だと思っていました。ところが、倉貫さんは全く逆でした。雇っている方が、無駄な作業をしてこなくていいというのです。雇われているほうも、こっちのほうが楽に仕事ができますが、その「場」で成果を出すためには普段から実力をつけておくしかないので、空いた時間で本当の「実力」をつけることに注力できます。

　日本の全体を今すぐ変えることは難しいですが、こういう人が一人でも増えてくると日本の生産性は上がってくると思うのです。お客様相手の箇所が難しいなら、自分の会社内、いやグループ内だけならできるかもしれません。少なくとも自分がそうなることもできます。米国の人ができることも日本人ができることも大して違いはありません。しかし、「成果」につがならないこういう無駄の積み重ねで、日本がソフトウェア産業で負けているのだとしたら、相当もったいない気がします。以前にも書きましたが個々の日本人の能力は高いと思います。

こういう環境で働ける人が増えたら、もっとみんなが楽しく働けて、グローバルから見ても成果が楽に上げれるようになると思います。少しづつでも始めてみませんか？日本だから仕方がないとあきらめるのではなくて、私も自分の幸せのためにも実践してみたいと思います。

ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策

　マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。

それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。

　私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。

気軽に「聞けないこと」が生産性を阻害しているのでは？

　 　以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 　英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それどころか個々の人だと、日本人の人のほうが優秀な人が多いんじゃないだろうか？と思うぐらいです。

　これにはいくつの要因があると仮説を立てているのですが、その大きな要素の一つである「気軽に聞けない文化」について考察してみたいと思います。

　私を含めた日本人は気軽に何かを聞けません。聞いたところで、「ググれカス！」と言われたり、「よく調べてから質問しなさい」という風に言われることもよくあります。 　米国で仕事をしているときは、誰でも気軽に質問していることに気づきます。それもとってもしょ～もない質問でも気軽にするのです。そして誰も「ググれカス」とかいいません。

　私が気づいた衝撃的な例をお話しすると、どれだったかは失念したのですが、確かAppleの製品発表の時に、故Steve Jobs氏が、iPadかiPhoneか何かの新機能の特徴を説明していました。その直後の質問コーナーで、質問した人がいたのですが、その内容が「新機能の特徴を教えてください」というもので、私は「なにいっとんねんこのおっさん！今Jobsが話していたばっかりやん！」と思いました。　ところが、Jobsは「Good question」といって先ほどした説明をまったく同じように繰り返していました。そして、その質問者は満足したようでした。

　私の職場でも、とっても優秀な人でも、日本だったら「えっ？そんなこと聞く？」ということでも自分が知らなかったらカンタンに隣の人に聞きます。例えばマイクロソフトに入社した人が「Azureって何？」というレベルのことを質問しているぐらいの勢いでも誰も問題と思いません。知らないことは知らないのです。

　実際に気軽に質問することを実践すると、相当効率がよく感じます。聞けばその場で自分よりよっぽどわかっている人から教えてもらうことができます。もし、その前に自分でググるとすると、自分で調べる力はつくかもしれませんが、結局のところ自分がよく知らないことなので凄く時間がかかってしまいます。だから、気軽に教え、教えられしていると、本当に効率よく仕事が進みます。

気軽に聞くためには、「簡単に断れる」ことが必要

　さらに気が付いたことは、この「気軽に聞ける仕組み」を作るためには、「気軽に断れる空気」を作ることが重要だということです。これは、スポーツカーが速く走れるのは、良いブレーキがついていて、いつでも止まれるからということに似ています。

　例えばハッカソンをしていて、ハッカソンのサポートをしてくれる同僚がいます。彼らに助けを求めたら、気楽にきてくれますが、自分がわからないと簡単に「わからないから、あいつに聞いたらいいと思うよ」とか、「うーん。わからないないなー、サポートに聞いたら？」とか言います。これは、社内だからとかではなく、お客様を相手にしていても同じなのです。そして、サポートを受けたほうも「助けてくれてありがとう」って笑顔で返します。

　もし、これが日本だったら、自分がサポートをしている以上、一旦お客様から質問を受けたらサポートに連絡するとか、自分も一緒になって意地でも最後まで付き合うとか、 「後日回答します」と最後まで責任を持ったりするところです。 　 　よくよく考えたら、やくざ映画や、寅さんとかを見ていても、「頼まれちゃぁ断れねぇなぁ」といって、一旦助けを受けたらとことんやっちゃうのが日本人の性質だと思い出しました。だから、気軽に助けを受けず、ググれカスとか、調べてから来なさいということを言いますが、一旦受けたからにはとことん助けてくれます。

　また、助けを受けて、途中で投げ出すと、相当いい加減に見られたり、頼りにならないと思われたりもします。

それは、素晴らしい美徳ですし、顧客対応に対してもいいことかもしれませんが、事ソフトウェア開発の効果や効率を考えるとこれは相当な無駄を生んでいるかもしれません。簡単に聞けて、助けになれなかった場合は、すぐに「ごめん」とできる。

これだけ、でも聞く方、聞かれる方、双方相当に楽が出来ると思うのです。

　日本の文化は素晴らしいですが、ソフトウェア開発に関してはそれがマイナスに働いている場面が多く、大変もったいなく感じます。インターナショナル環境で彼らを観察して、何か改善できそうなヒントを見つけたら共有して、自分でも実施して試してみたいと思います。

ご意見、ご感想など歓迎です！

技術イケメンをつくってみる。

イケメンへの憧れ

実は私はずっとイケメンなプログラマに憧れている。

　NEC時代も、最初は営業から初めて、若い頃は役立たず。アジャイルとかやるようになったり、オブジェクト指向だったりから、活躍できるようになった。これは、何を意味するか？というと、抽象的なことや、リーダーシップとか、チームビルディングが得意ということだ。

　でも、本当になりたいのはイケメンプログラマになりたいのだ。自分の周りのイケメンの皆さんをみては、ああぁかっこいいなぁ。でも自分にセンスないのわかってるしなぁ、、、。ただ、新技術系でも教育とか、記事書いたりはいいのだ。作業がぜんぜんできないタイプなのだ。あー、神様私に数学センスを！！！

　イギリスにいって振り返って、その後もいろいろあって、やっぱり自分は技術が好きやなぁと思うようになってきた。英語勉強に関しても一区切りした。（ちなみに、完璧になったということではなく、これ以上は実践して慣れるしかない、少なくともそれをしないと上達しなさそうなフェーズと感じたから）

　自分はほんまはプログラマになりたいけど、プログラマとしては三流。これはずっと自分の憧れで、コンプレックス。NECに入った時は、OSのコマンドを担当したいといって入社したんだ。（でもほぼ営業的な部門に配属されましたw）その後も、大手SIerなので、無理やりプログラミングしたけど、とても十分とは言えず、センスもなく。

イケメンコンプレックス克服への道

　今回ふとおもったけど、何を自分のやりたいことを躊躇しているんだろう。センスとか言ってるけど、もともとすべてのことにセンスなどないやん。わしはメソッドと努力だけでいろんなことをなんとかしてきた。自分の人生で望んでいたことはがんばってなんとか叶えてきた。

　英語バリバリになりたいとか（途中だけど）、歌うまなりたいとか（これも途中だけど、イギリスでヒントゲット）、コンサルタントになりたいとか（これはOK）アジャイルやりたいとか（これは死ぬほどやった）要求開発したいとか、コンパニオンの美人お姉さんとお付き合いしたいとか（一応結婚はした。終了したけど orz）

なーに、今回もできるさ。技術イケメンの道。というわけで、趣味ベースかもしれませんが、私の友達にたくさんいるガチで技術イケメンになってみるプロジェクトをやってみようかと思っています。今の時代みんな技術イケメンが求められているので、わしぐらいコテコテに向いてない人が技術イケメンになったら、そのメソッドいけてない？的な。

リンクが見つからないけど、プログラミングの学び方 - Web/DB プログラミング徹底解説このお方の言ってることとか参考になりそう。とりあえず、なぜ自分がイケメンプログラマじゃないと思うのかとか、イケメンプログラマが共通で持っているポイントとか、何を達成したら自分でイケメンと思えるのかなんてことを整理した。

自分がイケメンじゃないと思うところ

他の人が書いたロジックを読むのが遅い
自分の書いたコードがクールじゃないと思うときがある。
オープンソースのコードをすらすら読めない
テストスキルがしょぼい
オペレーションの経験が弱い
基本能力に抜けがある気がする

イケメンの性質

おしゃれなコードを書く
問題解決が早くて、生産性が高い（これは、無駄なものを大量に作るわけではなく）
変化を抱擁する
新しいことを素早く、正確に学ぶ
内部構造を奥の奥まで理解している

分析

これから、せっかく一生懸命やった、英語学習に当てはめて考えてみた。英語だったらどういうのが重要だろう？

リーディング　：自分のレベルにあったちょっと簡単めの本をたくさん読む。
　　　　　　　　グラマー（言語の文法／動作原理理解、ネットワークやハード、OSなどなどの動作原理／仕組み）を鍛える
ボキャブラリ　；技術系だと、クラスライブラリやイディオムに相当？
ライティング　；コードを書くこと。多分グラマーとか、イディオムとか、パターン重要？
リスニング　　；なし
スピーキング　；なし

何をすべきか？

自分の場合きっと、最初のステップは、コードリーディングが自由自在に読みまくれることが重要だろう。そして、実践としてのコードを書くことをすればいいだろう。運用付きの。

最初の一歩は、コードリーディングテクの強化だから、この本を読み始めた。

Code Reading―オープンソースから学ぶソフトウェア開発技法

しかし、この本を読み始めるには、C言語をおさらいする必要がありそう。長年触ってないが、せっかくだから英語で勉強しよう。Learn C - Free Interactive C Tutorial　あー、懐かしい。英語ではこんな風に見えるのか。なんだか感じが違うなぁ。

それが終わったらデータ構造とアルゴリズム→コードリーディング（LinuxとかCoreOSとか)をやってみよう。

きっと自分がイマイチだったのは、一足飛びにやろうとしたから。下の方から積み上げてみる。すでに学んでいることも多いんだけど、きっと、そこに抜けている箇所があると思うんだ。これは、実は英語学習から学んだこと。できることならすぐ終わるはず。

アジャイルの流儀で英語に挑戦！ - ［挫折と挑戦編1］日本人が英語を話せない本当の理由：ITpro

これは、自分にのこった最後のコンプレックス。果たして、４０超えたおっさんは、イケメンになれるのか？わからんけど、手探りでやってみます。