メソッド屋のブログ

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

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

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

 

マネジメントスタイルの違いがもたらす「圧倒的スピード感」の違いと「楽しさ」

最近は、ソフトウェアの新しい技術や、考え方の日本に対する導入の遅れをどうやったら無くすことができるか?ということを考えている。今回はインターナショナルチームに参加して感じたマネジメントスタイルの違いについて書いてみたい。

f:id:simplearchitect:20160704001910j:plain

海外企業のリーダーシップスタイルの変化

ソフトウェアの世界では、2001年にアジャイル開発が登場以来、それ以降のパラダイムでは、「サーバントリーダーシップ」と呼ばれるタイプのマネジメントスタイルが主流になっている。  従来型のスタイルは「コマンドアンドコントロール」というスタイルで、リーダーが部下に指示をし、リーダーは部下の状況を把握、確認し、管理していく。一方、サーバントリーダーシップの場合、リーダーは、ビジョンとKPIを示すが、実際にどのようにするかは、チームが自ら考えて意思決定していく。

 この考え方は、既に1969年に発表されているらしいというのを下記の本で知った。

books.rakuten.co.jp

マイクロソフトに入社して感じた事

私はアジャイル/DevOpsのコーチをしていたので、サーバントリーダーシップに関してはおなじみの概念だったのだが、マイクロソフトに入って気づいたことがある。マイクロソフトはソフトウェアのチームだけではなく、会社全体が「サーバントリーダーシップ」スタイルだ。ビジョンや、戦略、KPIは明確だが、誰も指示をすることは無い。現場のメンバーが日本企業とくらべると、かなりの権限を与えられて、どう実行するかを考えている。これはインターナショナルチーム、日本チームどちらもそうだ。

日本はマネジメントの世界でも遅れている

 私もマイクロソフトのことしか知らないので、詳細は分からないが、他の外資系に努めている友人に聞いても、こういうスタイルという事らしい。「コマンドアンドコントロール」型の管理は今ではオールドファッションと呼ばれているようだ。個人的意見だが、日本もそろそろサーバントリーダーシップ型に移行してもよい気がしている。ロッシェル・カップさんの下記の本は非常に興味深いのだが、そこでも、日本のマネジメント技術が低いこと、マイクロマネジメントが横行していること、権限付与のレベルが低いことが指摘されている。

books.rakuten.co.jp

また、書籍で、「社員」と「ステークホルダ」という表が乗っていて、とても興味深い。コマンドアンドコントロールは、メンバを「社員」として扱い、サーバントリーダーシップのチームメンバは、「ステークホルダ」として扱われる。

f:id:simplearchitect:20160704002642j:plain f:id:simplearchitect:20160704002649j:plain

自己組織チーム / フィーチャーチーム

スクラムやDevOps の世界では、チームに強い権限を与えて、ソフトウェアに関する決定は、そのチームが行う。「コマンドアンドコントロール」スタイルだと、上司の承認とか説得とかあったかもしれないが、チームを「信頼」して「任せる」スタイルになっている。このようなスタイルのメリットとしては次のような要素がある

  • 生産性が高い
  • チームのエンゲージメントが高い
  • よりよいソリューションが選択されやすい

生産性の高さ

最初の生産性が高いということは、「コマンドアンドコントロール」時代だと、リーダーの承認や、説得、日本だと合議・根回しもあるかもしれないが、とかく何かを決定するのに時間がかかる。これは、現在のソフトウェアのデリバリのスピードを考えると致命的だ。 だから、チームを信頼して、チームでビジネスの仮説や、仕様、そして、そのアーキテクチャ、使用する技術を決定していく。タスクの割り振りもチームが自らやっていく。基本的にチームメンバーがやりたい仕事を「自分がやるよ」と選択していく。

エンゲージメントの高さ

 インターナショナルチームの基本は、メンバーが「楽しんでいる」か?はすごく重要視されているので、メンバーは楽しめる仕事をプロとして実施して、主体的に考えて仕事をする。だから「やらされる」仕事より圧倒的に「楽しい」し、「自分がやっている感」がある。正直な話やらされている仕事なんて何にも面白くない。

だから、こういった「自己組織チーム」は、エンゲージメントが高い傾向にある。ロッシェルカップさんの先の書籍を読んでもやはり、日本のマネジメントはまだコマンドコントロールが主体だが、海外だと、サーバントリーダーシップ型になっていて、そういう点もチームメンバのエンゲージメント(満足度)に大きく影響していると思われる。単純な話、自分が面白いと思うことのほうが生産性は何倍も高くなるだろう。

良質なソリューション

最後に、よりよいソリューションが選択されやすい点だが、これは単純で、現在の技術は日進月歩で、それを一番把握しているのは、そのツールや言語で毎日コーディングをしたり運用しているメンバである。つまりチームメンバが一番知っている。何年も前にプログラマを引退した人では鼻が利かない。だから、現場で様々の選択をしてもらうのが一番質がいいことになる。稀にリーダーが一人で判断したほうがいいと感じることもあるかもしれないが、それだと、チームが指示待ちになって、何も考えなくなってしまう。いつまでたってもリーダーの指示が必要だ。

ただし、リーダーでも、例外的に技術に対して超人的に鼻が利く人もいる。グルーブノーツの最首さんはその例だ。しかし、彼も社長をやっているが、自分で様々な技術をハックしたうえで、チームに技術を推薦している。それも特に押し付けではない。

エンゲージメントの重要性

日本では、我慢が大人、西洋では、自分で自分の考えで人生に責任を持つのが大人であり、雇用制度も異なっている。日本に閉じている場合は、ロッシェルさんの本でも示されているが、日本のエンゲージメントの低さはそんなにダメージがないと考えるかもしれない。

f:id:simplearchitect:20160626063947j:plain    しかし、海外に進出したときはどうだろう?近年海外にオフショアしている企業も多いが、現地のエンジニアは、日本ほどエンゲージメントが低くない環境にいるので、自分が面白くないと、当然他のもっと楽しい企業に流れてしまうだろう。プログラマの生産性は10 - 25倍の差があるといわれている。「低いスキルの人」に全体を合わせる時代は終わって、より全体の生産性を高めていく、そのためにも、メンバーがエンジョイできる環境を作り出すということが重要になってくる。実際私も上司からは指示は一切なく「エンジョイしてるか?」ということは頻繁にきかれる。人をコントロールしようとする時代は終わったのだと思う。

simplearchitect.hatenablog.com

おかげで私は自分の考えで、自分で判断して仕事ができている。とても楽しい。はっきり言ってDream Jobだ。

Damienとのレビューでの出来事

先日年次レビューがあって、小さなことかもしれないけど、自分的には感動的な体験をした。Damienは、日本での私の成果をとても喜んでくれいる様だった。彼がとてもほめてくれるので、私は彼に「私の力じゃないよ。Damienが凄く助けてくれたからだよ。」という話をしたらDamienはこう言った

誰が、Hackathonをやったんだ?de:codeで他のイベントで凄いインパクトを出したのは?みんな君がやったことじゃないか。僕じゃない

私はADHDで普通の人が出来ることができない。だから、Damienは凄く私のカバーをしてくれているのを知っている。そんなことを一言も言わす、「みんな君がやったことだ」と彼は言い切った。当時Skypeミーティングだったが、不覚にもいろんなことを思い出して泣いてしまった。彼は初対面の私を信じて一切を任せてくれた。過去も素晴らしい人に囲まれていたがこれほどのことは初めてだ。あれはダメ、これはダメと子ども扱いされる職場と比べると凄い差じゃないだろうか。

こんな気持ちになれる会社と「言われたことをただ単にやればいい」という会社では、採用できるメンバーに大きく差が出てくるのは当然ではないだろうか?今は国内だけだから、成り立つかもしれないが、こういった事情に気づいた人が、どんどん海外の「楽しい」職場環境を求めて日本を去る人が増えてくるのではないだろうか?

ソフトウェアチームレベルに留まるスクラム

t.co

 先日英語の記事だが、「スクラムがアジアでは機能しない」というポストを見かけて大変興味深く読んだ。私が特に印象に残ったパートは、「欧米では、組織にスクラムを導入しているが、アジアでは、ソフトウェアチームでの導入に留まっている」という箇所だ。  これは、一見「スクラム原理主義」みたいに聞こえるが、そうではない気がしてきた。私も昔は、スクラムを会社全体に入れるという話を聞いたときは、「スクラムは、ソフトウェアの方法なのだから、何にでも適用するのは違う」と思っていた。今はもしかすると、そういうニュアンスではないのではないかと思い始めた。

組織でスクラムをしていない意味

「自己組織チーム」を作るためには、ソフトウェアチームだけを変えても機能しないことに気づく。例えば、折角チームが自己組織チームであっても、その上のマネジメントが「コマンドアンドコントロール型」の管理を続けていれば、そのチームを「コマンドアンドコントロール」しようとしてしまうだろう。上位マネジメントはそうでもなくても、中間のマネジメントの方が、コマンドアンドコントロールしてしまうかもしれない。人事制度も、「自己組織チーム」で仕事をすること前提のものに変えていかないと、不公平感が出てしまうかもしれない。

 また、アジャイル以降のパラダイムでは、「計画」や「納期」に関する考え方も大きく異なる。この辺りは次回のポストで解説したい。

 つまり、「自己組織チーム」は単にソフトウェアチームをそのような形態にしたらいいだけではなくて、効果を出すためには、その周囲も変えていかないといけない。これが、「ソフトウェアだけにスクラムの導入がとどまっている」ということの意味だろう。

日本で自己組織チームを実践する方法

 では、日本で自己組織チームを導入し、実践していくにはどういうTipsがあるだろうか?私の個人的な経験に基づく意見だが、記述しておきたい。

トップ層

まず、日本の場合は、上下関係があるので、出来るだけ上の方のOKを取り付けるのが良い。そして、アジャイル / DevOps などを推進するコミットを得て、それをしっかり資料化するのをお勧めする。どういった理由で、それを導入するのか、何を目指しているのか?また、定期的にステータスを報告することを約束しておくとより安心していただけるだろう。他には、可能であれば、バリューストリームマッピングなどの手法を使うと、例えばリードタイムの短縮など目に見える効果を提示することも可能だ。

docs.com

ミドル層

サーバントリーダーシップ型への転換で一番抵抗が激しいのがこの層だ。しかし、それにはれっきとした理由がある。トップ層は、自分のKPI的には新技術を導入するとか、様々な変革をするミッションがあるのでサポーティブになりやすい。しかし現場のマネジメントからすると、プロジェクトやサービスごとに数字を持っているので、当然自分の慣れていない方法で新しいことを始めるのは相当勇気がいるはずだ。だから、トップ層でも書いたが「トップ層」が明確に「自己組織チーム」で「サーバントリーダーシップ型を推進する」とコミットしていたら、ミドル層も、そちらに進みやすい。

また、ミドル層の方が反対する理由は、大抵は「石頭」とかではなく「不安」があるからだ。そらそうだろう。今まで慣れ親しんだ方法じゃない方法で、リーダーシップを発揮しなければならない。だから、「それはアジャイルだから」とか「それはスクラムで決まっているから」とかではなく、彼らの不安に耳を傾けて、それに答えていく必要がある。そして、しっかりとトレーニングをすると、過去のマネジメント経験も生きて、新しいサーバントリーダーが誕生しやすくなる。そうやって、いったんサーバントリーダー型になると、細かいことを計画・管理しなくてよくなるので、ビジョンや戦略や改善などより本質的な部分に注力することができるようになる。  

できれば、KPIもサーバントリーダーや、自己組織チーム前提にするのが望ましい。

また、進捗報告など、アジャイルやDevOpsサービスではどうすればいいかを具体的にお話ししておくと、安心してもらえやすい。大体私がやりがちなパターンは、「スピードチャート、開発進捗サマリ、課題」程度の報告にとどめている。しかし、それらがあれば、終了の見込み、全体像、課題がわかるので、シンプルながら十分だ。下記の資料のP42, P43あたりのイメージだ。

docs.com

チーム

最後にチームだが、「自己組織チーム」になっても、大抵の場合は、今まで「指示」を受けて動いていた人が多いので、自ら考えて、行動する習慣を持った人が少ないことが多い。だから、最初は自己組織チームになっても、みんな「どうしたらいいんだろう」という雰囲気になることが多い。そういう場合は、誰かが「ファシリテーター」役になって、行動を促進する質問をするといい。最初は「どう考えたらいいかわからない」と言わることもある。彼らに「アドバイス」をするのはよいがそれはあくまで「彼らが求めたとき」にする。 その前に「質問しやすくする空気」を作っておくのは効果的だ。私はよく「Ask For Help」の話をする。次のブログ参照してほしい。すると、メンバーが「あ!気軽に質問していいんだ!」と思えるようになってくるので、どんどん質問がやってくるようになる。

simplearchitect.hatenablog.com

指示待ち系の人も多いが、そのような場合も「じゃあ、○○さん、どのタスクやっときます?」とか、こちらが指示するのではなく、あくまで彼らを「促進」するようにだけする。決定はあくまで本人だ。アーキテクチャの議論をしていても、年上の人に遠慮して、本当に思っていることを言えなさそうにしている人がいることを発見するかもしれない。そしたら例えば「○○さん、このアーキテクチャの議論で、気になっていることはありますか?もし、ほんの小さなことでも結構なのですが、ちょっとでも気になっていることがあったら共有してくれませんか?」ぐらいのニュアンスで「促進」すると、少しづつ話をしてくれるようになったりする。

また、本当は「自己組織チーム」で自分たちに決定権限があるのに、「会社のルールで決まっているから無理」と自主規制してしまうケースもある。その場合は、上の人を連れてきて、その人から、「変えちゃっていいよ!」ということを言ってもらうようにする。そうすれば、徐々に「あ、会社のルールも変えようと思ったら変えられるんだ、自分で考えて自分で仕事をやったらいいんだ」ということに全員が徐々に気づいてくる。これにはプロセスは変えていいんだと気づくことができる副作用のあるバリューストリームマッピングのセッションも有効だ。

  こんなことをしていくと、明日からスグという感じではないが、1週間もたつと「自己組織チーム」にチーム自体が慣れてくる。

他にも、自己組織チームのはずなのに、何となく上下関係を感じる場合がある。そうすると、チーム内部で指示待ちが発生してしまうことがある。ポイントは、チーム内ではスキルや経験に関係なく、全員が同じ責任を持っているフラットな「仲間」としてふるまうことだ。最初の「社員 vs ステークホルダ」を思い出そう。 もちろんスキル差があるのは事実だが、聞いてはいけないということではない。「指示」をうけるのではなく「主体的に聞く」ことが必要なのだ。そして、目上の人も「教えたくなるのを我慢」することだ。「考える」のはそれぞれの仕事で、「考えてあげる」のは相手を子供としてみなしていることになる。新人であっても「(西洋の)大人」として扱おう。

チームにパワーを持たせる価値

海外の同僚の活動を見ていると気づくことに、日本以外の国は「開発者」「運用者」つまり現場の人が技術や方法論選定のパワーを持っている。日本は「マネージャ」が決めるので、「開発者」「運用者」の決定権がない。しかし、新技術導入のペースを勧めるために必要なのは、そこに対して鼻の利かない人の承認ではなく、彼らを「信頼」して「任す」ことによって「現場」がパワーをもって、チームが自ら考え意思決定していく組織にある。 チームが自ら判断していけば、新しい技術の導入も、新しいチャレンジも活発化されてくる。

f:id:simplearchitect:20160704004618j:plain

「自分で指示するほうがチームメンバーを考えるとよいと思う」とか「チームメンバーは指示待ちだから厳しいと思う」とか「自分勝手な行動をチームが取り始めたらどうするのだ」という意見もあると思う。

それでも私は「自己組織チーム」をお勧めしたい。1人が、他人に対してすべての要素で優れているということはほぼ無いだろう。だから、みんなのCPUを結集して問題解決に当たるほうが効果が出やすい。

「指示待ち」ということに関してはその通りの場合もあるかもしれないが、「人間は成長する」ため、「できない人を何とか管理」という方向性ではなく、「できる人」にする方向性のほうが、人による生産性の違いが10-25倍と言われるソフトウェア開発の場合は、効率的な気がする。「できない人」に焦点を合わせるといつまでたっても生産性は上がらない。

最後に何より、チームメンバーが「仕事を楽しめる」ことだ。これが最も自分的に大きい。私だったら指示されて仕事するなんて面白くもなんともないのでまっぴらごめんだ。自分の意志で自分で選択した仕事をプロフェッショナルにこなしていきたい。あくまで個人的な意見ではあるのだが、私はそう考えている。

日本に合わせるのではなくルールを変える

こういった「サーバントリーダーシップ」の考え方なども、現在の日本の組織や、ルールになじまないように感じる。ここで「できない」というのは簡単だが、そうやっている間に、海外とどんどん差をあけられていくのも確かだ。しかし、会社のルールなんて所詮どっかのおっさんが過去に決めたものだ。過去にはそのルールは有効だったが、現時点でそのルールが有効かは分からない。ルールは目的があったはずで、それに人間が縛られるのはナンセンスだ。東洋の端っこの小さな「日本のやりかた」にこだわるよりも、私は自分がより良い仕事をして楽に成果を出せるようにしたい。世界の基準でよい仕事ができるようになって、もっと世界に貢献したいなと思う。

次回は、自己組織チームに関係する、計画や、納期の考えの違いに関して整理しておきたい。