読者です 読者をやめる 読者になる 読者になる

メソッド屋のブログ

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

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

 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

ソフトウェアの納期見積もりは、星占いレベルのものであると思う

このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは?という私のアイデアをシェアしたいと思う。

f:id:simplearchitect:20160707002214j:plain

注:このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。

ソフトウェアの見積もりの正確さ

ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。

books.rakuten.co.jp

この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。

f:id:simplearchitect:20160707002506j:plain

 請負開発を実施するときに、私がSIerだった頃、画面や帳票の仕様を確定する遥か前に「見積もりが間違っていてもいいので、大体でいいから見積もってくれないか?」という話を受けて見積もりを実施する。その見積を元に「予算」や「納期」が決定されていた。  実際に、見積もりとは大幅にずれるわけだが、実際そうなってみると「間違ってもいいといっても、2倍以上開きがあるのは、ありえないだろう」みたいな話になることも多かった。しかし、この図を見ると、統計上至極当たり前の現象であると言える。

 見積もりに4倍の開きがあるものなど、占いレベルでなくてなんだろうか?1.6倍の開きと言ってもかなりのものだ。しかもこれは「画面・帳票の仕様を完全にFixしたもの」という前提である。

 若干乱暴だが、この著名な書籍の結論をお話ししておくと、スケジュールの見積もりに関しては納期を1点に決めてしまう見積もりは、クレイジーなので、ここから、ここまでの範囲内の見込みといったような「レンジ」を持った見積もりを様々な見積もり手法を用いながら実施するとよいということになっている。

  つまり、現在のソフトウェア開発においては

納期を1点に正確に見積もる方法は、世の中には存在しない

のだ。

納期をある程度正確に見積もれる状態は、何回も同じような状態で繰り返し実施してどの程度の時間がかかるか想定できるものに限定されている。ソフトウェアに関していうと、毎日のように新しいツール、機能がでてきて顧客の要望も、競合の動きに合わせて変わっていく。プロジェクトは2度と同じようなプロジェクトは存在しない「不確実性」にあふれた性質をしており、ソフトウェアにおいて、納期の見積もりは、未来を予見する、博打に等しいものだと思う。

納期厳守のプレッシャー

ところが、日本では一旦決めた「納期」を守るプレッシャーが相当に存在する。それが、どれだけ妥当性に欠けるものであったとしても、それを守るためなら徹夜でもなんでもやって納品するのが「プロ」と言われる。だから、相当無理なスケジュールでも、「やるしかない」という話になり、プロジェクトが炎上して、徹夜三昧になった挙句、プロジェクトは延期されるなんてことはざらにあるだろう。

では、「納期」が絶対なものとすると、「物理的」に考えるとどういう手が打てるだろう?これは、ソフトウェア開発の「納期」「コスト」「品質」「スコープ」に関する物理的な制約を表した図だ。

f:id:simplearchitect:20160707003011j:plain

「スコープ」つまり、実施する範囲を変えないまま、「納期」を守ろうとしたら、「品質」か「コスト」を犠牲にしないといけないというトレードオフの図だ。プロジェクトが遅れている状態で、「納期」を守ろうとしたら、「コスト」「スコープ」「品質」もしくはいくつかの複合要素を妥協する必要がある。  計画通りいかなかったプロジェクトは、優秀な人がいたなら、間に合わなくなりそうな兆候を見た時点で、「作業量」を減らしたり、「テスト」の手を抜いたり、「お金」をかけて高級なツールを買ったり、人を増やしたりということをしているだろう。

物理的にいって、ソフトウェア開発において「納期」「コスト」「品質」「スコープ」を確実に守るプロジェクト遂行ができる可能性は先ほどの見積もりの話と合わせて考えると、少なくとも理論上、統計上は「無理」に等しいのだ。

インターナショナルチームでは、「納期」はほとんどない。

 私も「納期」に関しては疑問を持たず厳守するものという考えがあったが、インターナショナルチームに入ってから大きな疑問に代わっていった。インターナショナルチームに入ると、そもそも「納期」がほとんどないのだ。数が少ないが、あったとしても、例えば自分が4時間程度かけたらできそうなものに対して、2週間ぐらいの「納期」が設定される。つまり、楽勝でできる余裕がある状態でしかそういう納期が設定されない。日本だと、金曜日の夜に、「これ月曜日までに、なるはやで」みたいな仕事の依頼が来ることもしょっちゅうだったが、インターナショナルチームでは、そういう展開はありえない。

f:id:simplearchitect:20160707003258j:plain

 もしそういう話になったら、仕事を依頼したほうのマネジメント能力が疑問視される。尚且つ、やってみたけど、間に合わなかったケースがあったとしても、それを無理に詰めて1日も早く終わらせようとはしない。課題を仲間と共有して、対策をうつなり、継続してやるならさらにそこから余裕を持った目標日が設定される。そして、今回何が課題で、何が学べたか?ということを関係者で共有して、次はどうしようという前向きな話になる。

 よくよく考えると、見積もりは、未来を予見する行為なので、ロジカルに考えると、理論上も、統計上も、100%達成できるはずがないので厳守などできるはずがないのだ。見積もりや計画を立てることはいいことだと思うのだが、少なくとも理論上はそれを「Fix」してしまう行為は自殺行為とも言える。見積もりや、計画は、あくまで「予定」であり、何かが変わったり、想定外のことが発生したら、それに合わせて「変更」 していくものであると思う。

そもそも「納期」はどこまで重要なのだろうか?

 日本では大小にかかわらず、一度設定した「納期」は守ることが大変重要視される。しかし、実際のところ、「納期」はどれぐらい重要な要素なのだろうか?日本にいるときは、大小たくさんの納期が設定される。相手からも「いつまで」というのが緊急なものをたくさん含んで設定されたり、自分で決める必要があったりする。そんなこんなで、日々見積もりが想定外だったら、残業休出でカバーする場面は私もしょっちゅう あった。

 海外に行ったり、インターナショナルチームに加わると「納期」はあまり重要でない気がする。そういえば海外の電車は遅れるのもしょっちゅうだし、電車がプラットフォームに入るまで、どのプラットフォームにつくかもわからない。会議も開始時間に遅れないことは日本はむちゃくちゃ重視される。一方海外だと、開始時間に遅れても、会議自体に出なくても「自分次第」になる。問題視もされない。自分次第だからだ。

 よくよく考えると、海外の巨大なソフトウェア企業がロードマップを発表したり、いつ頃、この機能をリリースするとかアナウンスしても、しょっちゅう、しかも、がっつり遅れたりする。しかし、それでどの程度のビジネス的な損害があるのだろう?  確かに、「納期」をがっつり守ったほうが良い場面というのは存在するが、本当はそんな場面は多くないのに我々は何でも早くしようとして無駄に納期を設定していないだろうか?

f:id:simplearchitect:20160623142229j:plain

 インターナショナルチームである納期といえば、ビジネスレポートや、勤怠の提出、出張申請。ビジネスレポートは、月末だが、毎日やっていれば全然問題ないし、全体的に物量が少ないので簡単だ。勤怠も、忘れていたら相当早くからリマインドが来るし、やるのを忘れ続けてもデフォルトでサブミットされる。出張申請はやらなかったら、自分の財布にお金が入ってこないだけだ。  テクニカルワーキンググループで、自ら立候補した資料をつくるのに、「絶対的な納期」ではなくて、「ここまでにやろう」という日は設定される。でもむっちゃくちゃ余裕はあり、ぎりぎり達成可能な日とは程遠い、絶対にできるだろう日しか設定されない。もし、その日までにできなかったら、きっと自分のパートの部分がカットされてリリースされるだけだろう。なんてことはない。次回のリリースのときに追加すればいいだけだ。

私はこういうことが重要じゃないかと思う。

その「納期」が本当に重要かをもう一度自問自答してみる

 私のポジションの問題もあるかもしれないが、肌感覚で感じるのは同じポジションでも、日本でいるときより圧倒的に納期設定が少なく、あってもむっちゃくちゃ余裕があるということだ。だから、逆にみんな数少ない納期は言わなくても普通に守る感じだ。全く「無理」が無いから。

「無理を承知」をなくせばうまくいく

これらの多くの問題は、「無理」なものを「無理」と本当の意味で認識していないことからくるのではないだろうか?日本にいると「無理を承知 でお願いします」「しばらく死んでくれ」「無理だけどやるしかない」という言葉を聞くこともあるでしょう。  納期の見積もりだけではないが、「無理」なものを「無理」と認めないマインドセットというのは相当いろんな悪影響がある気がする。「無理」と認識したうえで、次どういう「無理のない」手を打つか?は建設的だと思うが、「無理」なままつっこんでも、博打程度の確率でしか成功しないのは自明なことだろう。

でも、我々は、様々なプレッシャーや過去の習慣から、「無理」でも頑張ろうとしてしまう。そもそもその「無理」は本当に価値があるものなのだろうか?納期が1週間、いや1か月、さらに3か月遅れてどれだけのビジネスインパクトがあるのだろうか?「現行のビジネスモデル」で考えると、「少なくとも自社にはインパクトがある」という話になると思うが、みんなが「無理」なものを「無理だよねー」と顧客も、開発者も、運用者も、企画も、認めるような考えを業界に広めていくほうがより重要な気がする。そうでなければ、悲惨なことが続くだけじゃないだろうか?

無理なものは無理なのだから、それを単に認めよう。認めてから対策を考えよう。

「納期厳守」がもたらす圧倒的なデメリット

「納期厳守」で無理を承知で、人をたくさんぶち込んで、徹夜徹夜で何とかソフトウェアを仕上げて納期通り納品した。これは大変な美談になることが多いが、ソフトウェアの専門家からすると、まったくプロフェッショナルさからかけ離れた行為だ。

何故なら、ソフトウェアは、リリースして、使われてからがなんぼだからだ。それは結局のところ先ほどの「納期」「コスト」「品質」「スコープ」のトレードオフに対して一番曖昧な「品質」に対して大幅に妥協した結果に過ぎないからだ。徹夜でふらふらの頭でしっかりした、メンテナンス性が良く、自動テストがついているようなコードが素早く書けるはずがない。これは物理的な制約だから。

 だから、そのあたりが妥協されていることになる。納期通りリースしたところで、そのプログラムはその先何年もメンテナンスされていくのだ。「品質」を妥協した先に待っているのは「バグ」だけではない。「技術的負債」と言われるものはある意味「バグ」より恐ろしいものだ。

f:id:simplearchitect:20160707004137j:plain  

技術的負債の恐ろしさ

「技術的負債」というものは、技術的に良くない何かがソフトウェアに組み込まれている状態だ。例えば汚いコードとか、可読性の悪いコードだ。それは必要悪として一定以上は仕方がないが、借金と同じでそれを定期的に返していけば、特に問題ないのだが、返済せずにためていると、破たんしてしまう。つまり「メンテ不能」状態に陥るのだ。だから、「コードを常にリファクタリングし、重複の無い状態をキープして、1つの変更に対するコストが膨れ上がらない」ように、コードベースを常に変更可能な状態に保つ必要がある。しかし、この「技術的負債」の問題は本当に重要かどうかわからない「納期」の前にスルーされることが多いように思う。そんな欠陥三昧のソフトウェアを本当に重要かわからない納期に合わせてリリースしたところでそれは本当にプロフェッショナルな行為で顧客のためになるのだろうか?

 さらに、「納期厳守」は「占い」レベルの確度なので、「守れない」場合もある。その場合、「技術的負債」をてんこ盛りに抱えたまま、さらに納期遅れで納品される。そういったシステムは、1つの変更に多大な工数がかかる。変更が難しいからだ。だから顧客は将来的に高いお金、そして、長い納期を受け入れないといけなくなる。

 この「技術的負債」は先端の開発手法を用いている米国であってもトップ3の問題に数えられるぐらい難しい問題だ。DevOps Enterpriseというカンファレンスに行くと、よく上がる問題として、「レガシーマイグレーション」「自動単体テストを記述すること」「技術的負債」がいつもテーマにあがる。それぐらい先端の手法を用いている会社でも苦労するポイントだ。なぜなら、「技術的負債」は、ツールを導入したら解決できるものではなく、「クリーンコード」がどういうものかを共有し、チームで、その文化を育てていくような「習慣」だからだ。それぐらいじっくりとりくまないと、「メンテに非常にコストがかかるソフトウェア」が出来てしまうものなのだ。

シンプルな解決策

これらに関するシンプルな解決策は、必達の「納期」というのをあきらめるというのがシンプルだ。だって無理なのだから。実際に、No Estimatesというムーヴメントがある。「無理」なものなのだから、「やる価値もない」。「計画」は見通しをよくするために立てるけど、それを「絶対」のものにするのが、意味のない行為だと思う。単にリスクを増しているだけだ。

ronjeffries.com

完成見込みを知る方法

ソフトウェアの世界で、現在の技術的にも仕様的にも不透明な現在において、妥当性があり、完成見込みがどの程度か?を知るおすすめの方法はないだろうか?先に見積もりの本にもさまざまな手法が紹介されているが、一番シンプルでおすすめで、なおかつたくさんの人が使っている方法は、その開発しているチームの「実績」を測定して、「実績」をもとに予想する方法だ。 実際見積もりを確定させるための「変数」は多すぎる。例えば、人月で考えたところで、プログラマの生産性は、10-25倍の開きがあり、チームの中にそういう人が含まれているか?というのを知るのは難しい。そういう人がいたとしても、誰かが仲たがいしたら生産性が落ちるかもしれない。顧客のチームに問題があれば、沢山の「待ち」が発生するかもしれない。こういうのを見積もりの段階ですべて見切るのは不可能だ。チームごとに生産性は異なるのだ。

だから、そのチームで、一定期間働いて、その間、何らかの指標で生産性を測定する。そして、実際にチームの生産性が安定したところで、残作業をどの程度の割合でこのチームはこなせるか?という割合から、「完了見込み」の日を設定するとよい。ただし、これはあくまで見込みだ。 もし、その日に何らかのリリースをしたいのであれば、機能が無理なく盛り込めればよし、そうでなければ、優先順位をつけて、盛り込めないものをそのリリースから落とせばよい。これは一つの方法だ。

f:id:simplearchitect:20160707004810j:plain

この方法の良いところは、実際にビルドして、「動作するアプリケーション」の進捗実績をもとに計算しているので、確実性が高まることだ。私は、「純粋なウォータフォール」はメリットが無いと思っているが、その理由の一つに、「ソフトウェアは、コードを書かずして設計はできない」ということがあるからだ。少なくとも現在のソフトウェアでは、慣れた言語ですら、バージョンアップがしょっちゅうあり、使い慣れたライブラリをインターネットから落とす際に仕様がかわって動かなくなったり、ドキュメント通り動かないことは普通だ。だから、コードも書かず、紙だけで設計するなんてことは到底できない。

マイクロソフトの伝説的なスーパープログラマの中島さんが最近「なぜ、あなたの仕事は終わらないのか?」という書籍を出している。大変面白い内容なのでよかったら是非読んでいただきたい。  そこで紹介されている、彼が必ず納期を守った作戦というのは、納期をしるために、実際にモノを作る作戦だ。ロケットスタートでモノを作ってみて、最初の2日間で8割程度の完成にもっていけたらその後の納期を受け入れる。だめなら、この仕事は難しいから、スケジュール変更を行うというもんのだ。

books.rakuten.co.jp

 これも、無理がない素晴らしい考えだと思う。  

「納期」が重要なケースにどうしていくか?

「納期」が重要ではないケースが多いのではないだろうか?という話をしたが、一方で数は我々が思ってるより少ないと思うが本当に「納期」が重要なケースは存在する。例えば、オリンピックで使われるアプリケーションをリリースするなどの場合は、納期をオーバーしたら、ほぼ意味がないような状態になってしまう。こういったケースではどうすればいいだろう?

 いくつか方法があるが、先ほどのインターナショナルチームの例や、中島さんの例のように「絶対守れる納期を設定する」方法を実施すればいい。設計書だけあるような状況は、コーディングやテストを始めたら一発で状況が変わるので危ない状況だ。だから、どうしても納期を守らないといけない場合は、楽勝でできるような納期を設定して、早い段階で、実際にアプリケーションが動作するようにしておくのが一番安全だ。  フル機能でなくてももちろんいい。ソフトウェアに実装されている機能で実際につかわれるのは4割程度なのだから。まず機能がすくなくていいのでリリース可能で、単純な動くアプリケーションをプロジェクトの早期に作り、そこに少しづつ優先順位に従って機能を追加していく。納期が来たら、そこまで出来たものをリリースする。そうすれば、多少機能は落ちるかもしれないが、確実に「リリース」は「納期」どおりにできる。

 さらに安全な方法もある。「作って」から、「納期」をアナウンスするのはどうだろうか?例えばWindowsなどのリリースを見ても、実際にそれのリリース日が発表される随分前から、αテストや、βテストが実施されている。つまり裏を返すと、バグは多いかもしれないが、リリース予定の既に動作するアプリケーションが出来ている状態なのだ。そこから、バグを取ったり、機能変更をしたりしてリリースする。つまり、バグの残りの多い少ないはあるにせよほぼ確実に「納期」は守れることになるのだ。

 こういったリリースは、大規模なものというイメージがあるが、現在だと、「フィーチャーフラグ」というプラクティスを使って、簡単に実装できるようになっている。ソフトウェアに新機能を組み込むときに特定の機能を、特定のユーザグループに公開する「スイッチ」を付けておく。そのスイッチを特定のユーザグループにOnにすると、その機能がユーザから見えるようになる。Offにするとその機能はユーザから見えなくなる。

f:id:simplearchitect:20160707005408j:plain

 こういった機能をつかって、αテスト、βテストを実施して絶対にリリース可能な状態にもっていってから、リリース日を告知するのが安全だろう。

 これは、私のアイデアでしかないので、「無理」であることをまず受け入れて思考すると、もっといろんなアイデアがわいてくるかもしれない。

「現状」に流されず「無理」を認めることから始める

私は次のようなアイデアをシェアしてきた。しかし、これらの考えは実のところ結構昔から判明していることなのだ。

  • 納期の見積もりは星占いレベルの確度
  • 納期・コスト・品質・スコープのトレードオフは物理的な制約
  • その納期は本当に重要かを考える
  • 無理なものは無理として扱う
  • 納期を設定したい場合は絶対に守れる状態にしておこう

 これらの考えも、現在の日本の商習慣や、慣習から考えて「無理」と考えるのは簡単だろう。しかし、皆さんは、その「無理」を永遠に受け入れたいだろうか?私は少なくともまっぴらごめんだ。無理なものは無理だから。しかし、無理を受け入れてから工夫をすれば、もっと我々がもっとビジネスバリューを高めながら楽しくソフトウェア開発することが可能になると思う。少なくともあなたのチーム内だけでもこのような思考で動いたり、上の人にアピールしていくことができると思う。これを組織で取り組むともっとバリューが高いだろう。実際にユーザ企業自ら「請負」ではなく「準委任」に契約を変更して、「無理」から脱出した超大手企業も存在する。ソニックガーデンさんのように、「納期」自体を削除したケースもある。

itpro.nikkeibp.co.jp

books.rakuten.co.jp

 だから、自分ができることからまず一歩、一歩、私はアイデアをシェアするところから始めてみました。日本のソフトウェア開発が、US並みのスピードで進捗しますように。

追記 (7/7)

このブログをポストしたら私の友人の、Kiro Harada さんとRyuzee さんが、タイムリーにこのトピックに関する記事を書いたというお話を知りました。私の尊敬する両名が書いた記事なので私も読んでみようと思います。是非皆様もどうぞ!より詳しい話が読めると思います。

www.ryuzee.com

そして、Kiro Haradaさんからこの写真を貼りたい、貼りたい、、、とおっしゃっていたので、ご希望通りにしておきましたw

http://s2.quickmeme.com/img/7a/7ac6c18b1bca53b88bbd8cd25a68a327396adce14cb999a7d7130cf76b07a4c6.jpg

ちなみに日本語訳は「彼らに見積もりを頼んだら、それを納期にしてしまえ!」ですw