EM ZERO Vol.9

April 28, 2017 | Author: manaslink | Category: N/A
Share Embed Donate


Short Description

2016年5月31日に開催されたアジャイル&...

Description





















た。

EM ZERO、 再 開 し ま し た。

EM ZERO vol.09 2016



  EM ZERO vol.09 01

emzero_vol09.indd 1

2016/05/24 12:34

EM ZERO vol.9 Contents

アジャイル開発入門 西河 誠……………04

「 「

アジャイル」 「DevOps」 「クラウド」 言う前にすべきだったこと  渋川よしき……………06

アジャイルコーチの7つ道具 ツールで理解するアジャイルコーチの役割 天野 勝……………08

アジャイル開発とレジリエンス 永田 敦……………10

スタートアップの「死の谷」を 乗り越えるためのプロダクトマネジメント 橋本将功……………12

アジャイルとミリタリー 今、あらためて読む『失敗の本質』 斎藤良太……………14

思考停止の技法 大槻 繁……………16

ベトナムで技術情報誌を創刊してみた あまのりょー……………18

ある40代男のレガシーボディ改善物語  懸田 剛……………20 02 EM ZERO vol.09

emzero_vol09.indd 2

2016/05/24 12:34



で アジャイルのススメ の っ

プレイ ー アジャイルを

◎株式会社マナスリンクについて  株式会社マナスリンクはEM ZEROの運営

だら

はサンスクリット語でマインドを意味します。 良いマインドを持った人々をEM ZEROを通じ

……………22

て結び付け、良い人の流れ良い情報の流れ を作り出し、ソフトウェア業界を盛り上げて

「イン プシ ンデッ 」と 「 開発」を た ダン アジャイル開発 川

を目的として設立された会社です。マナスと

いくお手伝いをいたします。

◎EM ZERO配布のお願い  EM ZEROはイベントでの配布&EM ZERO に共感してくださる方の草の根配布を拠り所 としています。よろしければ本誌を何冊かお 持ちいただき、周囲の方に紹介していただけ るとうれしく思います。

……………24

◎広告出稿のお願い

マイクロ ト り の である ー



剛……………26

 EM ZEROでは広告を掲載してくださるクラ イアント様を募集しています。企業、団体、 個人は問いません。EM ZEROの存続にご協 力していただける方、広告効果の可能性を感 じていただける方がいらっしゃいましたら、 ぜひご相談させてください。

■EM ZERO広告のお申し込み  [email protected]

 久しぶりにEM ZEROを刊行することができました。急な依頼にも関わらず、快く 執筆を引き受けてくださった同志のみなさま、 (まさかの)広告出稿をしてくださった アトラシアンさん、いつもすてきなデザインを提供してくださるデザイナさん、ギリ ギリまで無理難題を引き受けてくださる印刷会社さん、そして縁あって今本誌を手 にとってくださっている読者のみなさま、どうもありがとうございます。  今号は通算で11号となっていました。なぜVol.9なのにそうなるのかと思い返すと、 1号の前に0号があり、3号が大きくなりすぎて3.1と3.2に分割していたのでした。次 は10号記念かと思っていたら、通算10号はとっくに過ぎていたのです……  EM ZEROはこれからもちょっとずつ続いていきますので、今後とも熱いご支援を よろしくお願い申し上げます!

◎お取り寄せ  EM ZEROの最新号をお取り寄せいただく ことができます。また、イベントや社内での 配布用には、送料をご負担いただければ承 ります。部数に限りがございますので、お早 めにお申し込みください。

■EM ZEROお取り寄せ [email protected] ◎EM ZEROの最新情報はTwitter/Face  bookをご覧ください。

EM ZERO Vol.9

■EM ZEROのナカノヒト:@em_staff

2016年5月31日発行

デ ザ イ ン:ミヤムラナオミ 編 集:EM ZERO編集部

発 行 元:株式会社マナスリンク 〒162-0011 東京都中野区中央3-27-11-101 http://www.manaslink.com/ お問い合わせ先:[email protected]

POStudy

 com/emfamily

み の を して り す! POStudy代表

プロダクト ーナーシップ

した ークシ ップ で 開 ! した D !

■EM Family:http://www.facebook.

Copyright ManasLink Printed in Japan

、 ル開発 アジャイ マネージャ ル アジャイ !!!

「プロダクト」を「マネジメント」する

 

印 刷 所:昭栄印刷株式会社 http://www.shoei-p.net/

関 満徳

詳しくは 下記まで

! p

p s   EM ZERO vol.09 03

emzero_vol09.indd 3

2016/05/24 12:34

アジャイ イル開発入門 ル開発入門 アジャイルジャパン実行委員

西河 誠

NISHIKAWA Makoto

日本でのアジャイル開発の拡がり

プロジェクトマネージャを経て、数十

アジャイル開発は、 「アジャイルソフ

名規模の部門を担当する立場となり、

トウェア開発宣言」 ( 2)で述べられて

アジャイル開発についていろいろな視

いる「価値」と「原則」に則った開発

点で考えるようになりました。

手法の総称です。どの開発手法も、ア

2009年のことです。2016年でアジャイ

 私が多数進めてきたスマホアプリ開

プローチや具体的な進め方は違います

ルジャパンは8回目を迎えます。

発では、もはやアジャイルでないと開

が、 「顧客満足」を再優先の目的にして

 アジャイルジャパン実行委員として、

発が難しいと思いますし、日々変化す

います。アジャイル開発では、顧客の

イベント立ち上げ当初から推進に関わ

る市場、サービス分野においては必須

開発投資に対して最大限のパフォーマ ンスを出すための取り組みを考えます。

 アジャイルジャパンを始めたのは

らせていただいていますが、この間、

の考え方だと思います。最近ではお客

日本のソフトウェア開発者はもちろん

様から「アジャイル開発でお願いしま

日本の企業においてもアジャイル開発

す」というリクエストを頂くほどです。

アジャイルの価値と原則

が普及してきました。

 日本においても、ソフトウェアを発

 アジャイル開発では、顧客のビジネ

 アジャイルジャパン2014の参加者ア

注する側、開発する組織についても、

ス価値を最大化するため、次の行動指

ンケートは、メイン会場の参加者265名

本質的な理解をしている方が着実に増

針( 「価値」と「原則」 )に従ってプロ

のうち、10.2%の方が多くのプロジェク

えてきているように感じます。アジャ

セスを決めています。

トで使っている、60.4%の方が一部の

イル開発手法のひとつであるスクラム

プロジェクトで使っていると回答され

を中心に、具体的なアジャイル開発の

ており、70%以上の方がアジャイルに

進め方を解説した日本語の良書も増え

  「 (アジャイル開発の)価値=開発で

取り組んでいることがわかります(

てきています。

重視すること」です。たとえば、アジャ

1) 。  アジャイルジャパンの中で発表・議 論される内容も、最初はアジャイルと

イルソフトウェア開発宣言の中で、

あらためて、アジャイル開発入門

“   ” プロセスやツールよりも 個人との対話を

はなにかという解説や体験講座が多 かったように記憶しています。最近で

 このようにアジャイルな開発手法、

は実践して取り組んだ内容の説明はも

事例などの情報は増えてきましたが、

ちろん、失敗事例に至るまで、具体的

アジャイル開発の本質は変わっていま

セスやツールを軽視しているわけでは

な発表が増えてきました。

せん。これからアジャイル開発に取り

ありません。

 2014年より公 募セッションで 発 表

組んでみようという方、アジャイル開

テーマの受付が始まりましたが、最近

発に取り組むことでより良い製品・サー

顧客満足を最大化するためには、

では応募論文がどれも興味深いもの

ビスを作りたいという方は、アジャイ

ソフトウェア開発において、プロセス

ばかりで、実行委員会の中でも当日の

ル開発の基本を見直してみましょう。

やツールも大切だけど、 個人と対話することがもっと大事です

タイムテーブルに入れるセッションを 選ぶのが実に悩ましいです(本当に接

という記載があります。これは、プロ

アジャイル開発の目的

よね

戦の末選ばれていますので、選出され

「アジャイル開発ってなんですか?」

なかった場合もまた応募をお願いしま

と聞かれたとき、私は「ソフトウェア・

と述べています。

す!!!) 。

製品・システムのビジネス価値を最大

 ほかの項目についても、左側に記載

 私自身もこの8年間で開発者の立場

化するための考え方です」と答えてい

している内容はソフトウェア開発にお

から小規模なプロジェクトのリーダー、

ます。

いて欠かせないが、右に記載したほう

04 EM ZERO vol.09

emzero_vol09.indd 4

2016/05/24 12:34

に重点を置くほうが顧客満足を得られ

ゴールである「顧客価値」であると考

 アジャイル開発は考えるためのフ

るという考え方になります。

えています。アジャイル開発で取り組

レームワークであり、やり方はビジネ

  「 (アジャイル開発の)原則=アジャ イル開発を進める上での行動原則」で

むプロジェクトで、最初にお勧めして

スフィールドや現場、取り組む人によっ

いる方法があります。拙書である『わ

て変わってきます。日本のものづくり、

かりやすいアジャイル開発の教科書』

日本人に合った「日本のアジャイル」



)でも紹介したのですが、 「お客様

ができるのではないかと考えています。

す。顧客のビジネス価値を最大化する

は誰?」という簡単なディスカッショ

 どんな取り組みも現場から始まりま

ために、動くソフトウェアをできるだ

ンです。

す。まずはなんでも結構です。できる ことから取り組んでみましょう!

け短い時間感覚でリリースするなど、

 ホワイトボードに「お客様は誰です

ソフトウェア開発をどのように進める

か?」 「お客様のハッピーはなんです

かの枠組みを述べています。

か?」というテーマを書き出し、プロ

1 「アジャイル開発の現状と課題につ

 スクラムやエクストリームプログラ

ジェクトメンバーとディスカッションし

いて」 (独立行政法人情報処理推進機構

ミング(XP)などのアジャイル開発手

てみましょう。

法は、これらの価値、原則に従って “プ

(http://www.agilemanifesto.org/iso/ja/) 『わかりやすいアジャイル開発の教

成されています。

科書』 (ソフトバンククリエイティブ、

 プラクティスの具体的な例として、

http://www.sbcr.jp/products/4797371284.

ペアプログラミングやテスト駆動開発

html)

などが有名ですが、これらの取り組み

4 「アジャイル開発とは: 『アジャイ ル開発』をエグゼクティブサマリにまと

もアジャイルの価値・原則に沿って行

めてみた」 (http://kuranuki.sonicgarden.

われるプロセスのひとつです。これら の中で実践されるものであり、開発す

inar/seminar_tokyo_20141217-02.pdf) 2 「アジャイルソフトウェア開発宣言」

ラクティス” と呼ばれる実践手法で構

のプラクティスはそれぞれの開発手法

山下博之、http://sec.ipa.go.jp/users/sem

jp/2011/08/post-41.html) ■写真 お客様は誰?

る製品・サービスや、ビジネス形態に

 簡単に取り組めますし、アジャイル

よって部分的に取り入れていくのもア

の目的である顧客満足の最大化につい

ジャイルに取り組むための一歩になり

て考え、チームで共有する第一歩にな

ます。

ります。

Profile プロフィール

アジャイル開発の第一歩

これからアジャイル開発に 取り組むみなさんへ

 ここまで説明したとおり、アジャイ

 アジャイル開発の考え方は、製品・

アジャイルジャパン実行委員

ル開発は顧客のビジネス価値を最大化

システムを作っている私たちにとって

するために取り組むものです。これを

とても基本的な考え方になると思いま

NISHIKAWA Makoto

実現するために、開発で重視する「価

す。アジャイルの目的、価値、原則に

値」に従い、 開発を進めるうえでの「原

定期的に立ち返り、考え続けることで

則」に則って開発を進めていきます。

みなさんの取り組んでいる開発はより

 やはり、いちばん重要なのは開発の

良いものになると考えています。

西河 誠

組込みソフトウェアエンジニアとして、 各種マイコン制御ソフトウェア、オペ レーティングシステムの設計・開発を 担当する。 ブログ:http://d.hatena.ne.jp/mnishi kawa/

  EM ZERO vol.09 05

emzero_vol09.indd 5

2016/05/24 12:34

「アジャイル」「DevOps」「クラウド」 言う前にすべきだったこと ¦¦¦ \(‾▽‾;) / ¦¦¦ワーイ?

渋川よしき

SHIBUKAWA Yoshiki



ット ーク

コアのビジネスが別にあって、その業

同じ機能を何度も再実装しなければな

務を円滑化し業務改善することで費用

りません。

 eXtreme Programmingが 生 ま れ て

を回収するのがほとんどでしょう。

 また世の中でよく使われるUIから離

今年で20年、日本に上陸してからもも

 ある程度の業務システムを作りこん

れれば離れるほど、実装の手間は増え

う16年ほどです。その後もいろいろな

で完成させるのに何人ぐらい必要で

ます。Windows Formsデザイナーの素

言葉が生まれては大騒ぎしています。

しょうか? 20人? 100人? 1,000人?年

組みでできるUIなら開発コストも少な

ディープラーニングやら、FinTechやら、

収の2〜3倍が会社の負担する人件費の

く、メンテナンスのドキュメントも少

IoTやら。いろいろな用語が飛び交うた

総額と言われるので、20人欲しいとす

なくて済み、情報も豊富に得られます。

びに必ず出てくるセンテンスがありま

ると、2億から3億のキャッシュフロー

コード量も少なければバグも少ないで

す。

の悪化が見込まれます。

しょう。再実装のコストが大きければ、

 日本の労働基準法では首にするのが

システムリプレースのリードタイムも

難しいので、一度雇ったら雇い続ける

伸びます。

本 ー ー





覚悟が経営側には必要です。で、何人

「このUIじゃないとユーザーが嫌が

システム部門に人が必要でしょうか?

る」というのはよく聞かれる言葉です

みずほ銀行の次期勘定系システムは

が、それによる目に見えない負担の増

ピーク時8,000人規模とのことですが、

加は重荷となっていきます。

 たしかに、USの技術系カンファレ

このピークの人数に合わせてメンバー

 UIの例がわかりやすいので最初に出

ンスではユーザー企業のIT部門のメン

を揃えなければならないのでしょう

しましたが、パッケージソフトの利用

バーが事例発表などをしています。 ウォ

か?もちろん、そんなことはありませ

という文脈でも同じです。日本はパッ

ルマートのIT部門が大規模にnode.jsを

ん。

ケージソフトを導入するにあたっても、 なるべく多くのカスタマイズを入れよ

導入して、その中でメモリリークが発 見されてnode.jsの修正が行われたよ、 という発表が行われましたが、今か

 

と ジネス する



うとします。  UIの例と同じようにそれは差別化に なりますが、パッケージソフトベンダー

ら2年半前の段階で、大規模採用事例 がほとんどなかったnode.jsを、小売最

 受託開発の知人に聞くと、たいて

にとっては効率があまり良くない開発

大手が導入するというフットワークの

い出てくるのが「競争力に直結しない

になります。費用対効果が悪化します

軽さはなかなか日本で見ることができ

会社固有機能の開発」です。たとえ

し、一時的な開発なので少ない人数で

ません。

ば、昔ながらのターミナルのUIに慣れ

開発することになり開発期間も伸びま

 とはいえ、今のままIT部門の人を増

ているので、それとまったく同じ入力

す。フットワークが遅くなりますよね。

やしてもダメだろうな、という実感が

方式を新しいUIフレームワークで新規

 差別化のために競争力が下がるとい

あります。

開発するのです。Enterキーで入力欄の

う本末転倒な結果になりがちです。 「新

フォーカス移動とかそういうものです。

システム導入の教育手当」という名目

 そのような機能の積み重ねで開発項

でユーザーにボーナスを出して「シス

門 コスト ンター

目数が爆発している例をよく聞きます。

テム側に合わせることを了承してもら

 IT部門はシステムを開発して、ビジ

既存メンバーの教育コストは削減でき

う」ほうがよいように思います。

ネスの流れを円滑にするのが仕事で

ますが、新規メンバーはその特殊なUI

す。とはいっても、ITで作ったものそ

に慣れる学習が必要です。また、5年

そうすれば新規システム導入をする場

のものでお金を生み出すことは少なく、

おき、10年おきのリプレースのたびに

合のピーク人数は減らせます。パッケー

「会社固有開発」をなるべくやめる。

06 EM ZERO vol.09

emzero_vol09.indd 6

2016/05/24 12:34

ジに業務を合わせて一部だけ開発にな

ほとんど増えていません。同じ金額に

な人数を減らしてフットワークを軽く

れば極少ない人数で開発できます。そ

対する要求がどんどん上がっています。

して稟議書に取られる手間も減らす。

うなれば「IT部門を手厚くして内部で

スマートフォンのFree2Playゲームはさ

年単位の予算確保と執行のタイムボッ

開発したほうがフットワークが軽くな

らに極端です。開発費に何億円がか

クス開発から、週単位のタイムボック

る」という話もできるようになるでしょ

かっているのか知りませんが、アイド

スへ。そして社内から社外へ。そうい

う。

ルマスターシンデレラガールズスター

う社内IT部門は楽しそうですよね。

ライトステージというゲームも無料で

 もうひとつ、最近になっておもしろ

す。スマートフォンのゲームは、無料

いニュースがありました。メルコHDが

でも大きな開発費がかかったゲームと

麺製造のシマダヤの株式を買収したと

 自分で開発する割合が多くなれば

勝負しなければならないのです。

いうニュースです。社内IT部門の競争

なるほど、世の中のシステムの進化の

 ゲームの例は極端かもしれません

力強化とは真逆ですが、ソリューショ

門の開発





恩恵を得ることが難しくなります。た

が、Microsoft社も最近はオープンソー

ン提供会社によるユーザーの内部化と

とえば、UI画 面をなん の工 夫もない

スを活用する方向になってきています。

いう方向にも見えます。IoTを活用した

Webアプリケーションとして実 装し

自社開発以外のコンパイラスイートで

トレーサビリティの向上などを関連会

たとします。今時のUIフレームワーク

はLLVMを活用するなどになってきてい

社間でやり切る。将来メルコがそのソ

(BootstrapとかMaterial Design Lite)を

ます。また、マルチプラットフォーム

リューションを販売しようとするとき

使って画面を作るとします。そうする

のGUIではElectronを使っています。世

にも、自社内で完成されたものを売る

と、スマホでもタブレットでもちょっと

の中の求める水準のものをすべて自社

ことができます。

した調整で扱えるようになります。

で抱え込むのは効率に見合わない時代

 IT企業とユーザー企業の一体化によ

 ソフトウェアの世界はそういう一石

になってきているのは明白です。

る速度アップ。そしてそこからの競争 力アップ。今後、そういうおもしろい

二鳥、三鳥、四鳥がたくさん転がって います。バグもどんどん直っていきま す。1人の開発者であっても、バックに

本の トウ ア開発の   を す

事例が増えてきたらいいな、と思いま す。  このように競争力を上げる土壌がで

世界中の仲間がいるのと同じです。レ

きてきたら、たぶんそのときにはもう

バレッジが利くようになります。イン

 競争力というのは数値で比較できる

フラ周りも、多くの人が使っているツー

ものではありませんが、アウトプット

勝手にアジャイルになっているのでは

ルを使っていけば自然とクラウド対応

の量と競争力は正の相関があるという

ないでしょうか?

が簡単になったりします。

主張に異論がある人はあまりいないで

 1人で開発できる量には限界がありま

しょう。海外のIT部門があって、研究

す。これに対して、世界がシステムに

所(Lab)がある企業は、 たくさんのオー

求める水準はどんどん上がっていきま

プンソースのソフトウェアを出してい

す。自分ですべてを開発すると、相対

ます。

的に開発力はどんどん落ちていくので

 今やインフラの話をすると常に話題

す。

の中心にあるAWSも、元は社内IT部門

 ゲーム開発が顕著な例です。最初の

でした。 「多くの企業は自社でインフラ

ドラゴンクエストは数人のメンバーで

整備するのはコストに見合わない」 「計

数ヵ月で作られたとよく書かれていま

算資源も無駄が多い」というところに

すが、その後スーパーファミコン、プ

目をつけて、世界最大規模のECを支え

レイステーション、プレイステーショ

るインフラの知識をサービス化して新

ン2と時代が進むにつれて、開発費はど

しいビジネスにしようというところか

んどん上がっています。今では2桁億

ら出発しています。そういう新しいサー

円と言われています。世界のトップク

ビスがたくさん出てくれば、 「日本のIT

ラスでは3桁億円。2年前に発売された

は元気だね」となるはずです。

Destinyが5億ドルとのことです。

 競争力に繋がらない差別化で工数と

 ところが、ユーザーの払うコストは

時間が取られる状況から脱却し、必要

Profile プロフィール

渋川よしき

SHIBUKAWA Yoshiki DeNA で仕事をしています。サンフラ ンシスコから帰ってきました。sphinxusers.jp のファウンダー。主に使う言 語は C/C++、Python、JavaScript。 Twitter:shibu_jp Facebook:yoshiki.shibukawa メール:[email protected] ブログ:http://blog.shibu.jp/

  EM ZERO vol.09 07

emzero_vol09.indd 7

2016/05/24 12:34

(3)コーチング計画  現場ヒアリングの結果をもとに、対 象となるプロジェクト/チームのどの ような課題をどのように解決していく かを計画する。 ここで役立つ道具は、 「利 害関係者マップ」 と 「ゴール分析ツリー」 「リスク分析ツリー」である。 (4)作戦会議  コーチング計画をもとに、依頼主や 推進者と進め方を定期的に確認してい く。ここで役立つ道具は、 「ゴール分析 ツリー」 「障害物リスト」 「KPT」である。

株式会社永和システムマネジメント コンサルティングセンター センター長

天野 勝

AMANO Masaru

はじめに

り し

 「アジャイルコーチ」という名前を 耳にはするが、その役割は理解できて いないという方が多いのではないだろ うか。本稿は、アジャイルコーチが使 用している道具(ツール)を紹介し、 これらの道具からアジャイルコーチの 役割を知っていただくために執筆した。  筆者がはじめてソフトウェア開発 チームのコーチをしたのは、2003年の ことである。それからいくつもの案件 にコーチとして関わってきた。いまだ に手探り状態ではあるが、その中でも 効果を感じている道具を7つ紹介する。

アジャイルコーチ案件のプロセス  道具を紹介する前に、 アジャイルコー チとして案件に関わる際の流れを整理 する。 (1)要望の確認/提案  まずは、依頼主のもとに赴き、要望 を確認する。その後、要望を分析し、 提案する。アジャイルコーチとして関 わる案件は、主に次の2つの要望に分 類される。

あ り

あ の ま

ーし





の し

 近年は、後者の依頼が増えている。 また、コーチングの成果も上がりやす い。  ここで役立つ道具は、 「利害関係者 マップ」と「ゴール分析ツリー」 「リス ク分析ツリー」である。案件の質があ まりにも低い場合は、要望を分析した 時点でお断りすることもある。そうで なければ、依頼主の要望、実施体制、 スケジュール、費用を提案書の形にま とめて提出する。  提案を受け入れてもらえれば、契約 手続きとなる。機密性の高いプロジェ クトの場合は、要望を具体的に聞く前 に秘密保持契約(NDA)を結ぶことも ある。 (2)現場ヒアリング  対象となるプロジェクト/チームの メンバーと利害関係者にヒアリングを する。ここで役立つ道具は、 「利害関係 者マップ」と「ヒアリング項目」である。 利害関係者マップをもとに、誰にヒア リングするか計画し、1人ずつヒアリン グを行なう。1人のヒアリング時間は45 分としているが、話がなかなか終わら ない場合も多く、余裕をもって90分の インターバルでスケジュールを組んで いる。

■表1 アジャイルコーチの7つ道具 要望の確認/提案

現場ヒアリング

コーチング計画

道具その 1:利害関係者マップ







道具その 2:ゴール分析ツリー





道具その 3:リスク分析ツリー





道具その 4:障害物リスト 道具その 5:ヒアリング項目 道具その 6:KPT 道具その 7:チェックリスト

作戦会議

現場コーチング

状況報告

○ ○ ○

















(5)現場コーチング  対象となるプロジェクト/チームに 対して、コーチングを行なう。ここで 役立つ道具は、 「リスク分析ツリー」 「障 害物リスト」 「KPT」 「チェックリスト」 である。 (6)状況報告  対象となるプロジェクト/チームの 現在の状況と今後の課題を報告する。 口頭の報告で済ますこともあれば、定 型のドキュメントを用意することもあ る。予算に余裕のある依頼主の場合、 ドキュメントを求められることが多い。 ここで役立つ道具は、 「障害物リスト」 と「KPT」 「チェックリスト」である。

アジャイルコーチの7つ道具  筆者が活用している道具の概要を紹 介する。 1にアジャイルコーチの7つ 道具を整理した。 (1)道具その1:利害関係者マップ  対象となるプロジェクト/チームを 中心に、取り巻く利害関係者を1枚の図 で表したもの( 1) 。インセプション デッキの「ご近所さんマップ」やSSM の「リッチピクチャ」に相当するもの と考えていただきたい。 (2)道具その2:ゴール分析ツリー  アジャイル開発によってなにを達成 したいのか、達成するにはなにがで きるようになるかをツリー状に細分化 し た も の。OKR(Objectives and Key Results)の考えが参考になる。 (3)道具その3:リスク分析ツリー  リスクごとに、そのリスクを発生さ せる要因をツリー状に細分化したもの ( 2) 。このツリーを使って、どのよう

08 EM ZERO vol.09

emzero_vol09.indd 8

2016/05/24 12:34





者 バッ

者 者

ー 者







要件が 変更になる

ユーザー内で 要件の合意が とれていない

作業が 難しく 時間がかかる

二人で 作業する

合意の会議に 参加する



者 バッ



作業を やり直す

者 バッ

作業が 遅れる

納期を延ばす バッファ込みで 交渉をする 計画する







納期に 間に合わない

作業の着手が 遅れる

かかる工数が わからない

作業の途中で 割込みが入る

割込みを 断る

少し着手して 工数を見積る 有識者に 見積ってもらう



■図2 リスク分析ツリー

■図1 利害関係者マップ

な対策を打つかを検討する。  要望を確認する際には、案件として のゴールを達成するのに、どのような 阻害要因が潜んでいるかを分析する。 コーチング計画を立案する際には、ア ジャイルコーチとして現場のゴールを 達成するのに、どのような阻害要因が 潜んでいるかを分析する。この段階で は、コーチだけで行なうのではなく現 場メンバーを中心にリスクを洗い出し、 その対応策も、現場メンバーと一緒に 考えていく。 (4)道具その4:障害物リスト  ゴール達成の障害となるモノ・コトと その解決策・解決状況を一覧にしたも の。コーチの第三者としての立場から、 客観的に障害物を特定し、障害物ごと に解決策を決め、適宜、解決状況を更 新していく。 (5)道具その5:ヒアリング項目  現場メンバーにヒアリングをする際 の質問リスト。依頼主の要望をもとに、 どのような現場なのかを推測し、障害 物を見つけやすいように質問内容をそ の都度アレンジする。 (6)道具その6:KPT  Keep、Problem、Tryの観点で物事を 整理する思考フレームワーク。プロジェ クト/チーム状況の推測や、現場メン バーとのコミュニケーションに活用す る。また、現場メンバー自身がチーム を改善する際のアクションを考え出す のに活用するなど、適用範囲はとても 広い。  KPTについては、拙著『これだけ! KPT』 ( 1)を参考にしてほしい。 (7)道具その7:チェックリスト  コーチがプロジェクト/チームの行

動を第三者として評価する場合や、現 場メンバーが自分たちの行動を客観的 にセルフチェックする際に用いるリス ト。  主に以下の3種類を使っている。 2 り ー



 朝会チェックリストは、オブラブで 公開している「プロジェクトファシリ テーション実践編 朝会ガイド」 ( 2)をもとにしている。

おわりに  筆者がアジャイルコーチとして関わ る際に使用する道具の中で、有効性を 感じている7つを紹介した。道具そのも のに、コーチとしての仕事内容が反映 されていると考えていただきたい。  これら道具の特徴から、アジャイル コーチがどのような役割を果たすのか アジャイルコーチ像をイメージし、今 後、アジャイルコーチを採用する際や アジャイルコーチを目指す方の役に立 てれば幸いである。

■参考文献 【ルールの共有】 1 朝会のグラウンドルールを 明文化している。 2 朝会の進行(アジェンダ)を 明文化している。 3 実施時間が決まっている。 4 参加者が決まっている。 5 司会者をローテーションしている。 【場の設定】 6 メンバーが輪になって集まれる場で行なっ ている。 7 チーム状況を可視化している。 【全員の振る舞い】 8 開始時間に全員集まっている。 9 立って行なっている。 10 開始と終了に挨拶している。 11 チーム全員に聞こえるように話している。 12 今日やることの工数を見積もれている。 13 些細な問題点も話している。 14 他の人の発言を聞いている(聞き流し ていない) 。 15 短時間(最大15分)で行なっている。 16 問題を深掘りしすぎない。 17 二次会の要/不要をチームと合意してい る。 【司会者の振る舞い】 18 発言しやすい雰囲気づくりをしている。 19「問題ありません」を見逃さない。 20 ルール違反を伝えている。 【リーダーの振る舞い】 21 朝会を行なう目的をチームに伝えている。 ■表2 朝会チェックリスト

(1)『これだけ! KPT』 (天野 勝、すばる 舎、2013年) (2) 「プロジェクトファシリテーション実 践編 朝会ガイド」 (平鍋健児、天野 勝、オブラブ、 http://objectclub.jp/download/files/ pf/MorningMeetingGuide.pdf)

Profile プロフィール

株式会社永和システムマネジメント コンサルティングセンター センター長

天野 勝

AMANO Masaru オブジェクト指向、アジャイル開発、 開発現場の活性化をテーマに、ファ シリテーションを活用したコンサル ティング、セミナーに従事。

  EM ZERO vol.09 09

emzero_vol09.indd 9

2016/05/24 12:34

アジャイル開発とレジリエンス ソニー株式会社 IP&S 品質保証部門 システムクオリティ部 品質エンジニアリングマネージャ

永田 敦

NAGATA Atsushi

●レジリエンス

ロセスとしてうまくできています。

 レジリエンスというのは、立ち直る力と

 今回は、そのときチームに起こることと

●ソフトウェアは変化で劣化する  ソフトウェアはハードウェアとは異な

か弾力性という意味ですが、ここでは(ゴ

チームの「レジリエンス」 、つまり変化へ

り、劣化しないと言われます。ハードウェ

ムのような)弾力性というニュアンスでお

の弾力性の必要性を考えていきます。

アの故障率は部品劣化により、 1のよう

話しします。

 QAオジサンがこんなことを気にするの

なバスタブ曲線を描きます。時間の経過

 アジャイルソフトウェア開発宣言の中

は、この変化が成果物の品質を劣化させ

に伴い、あるときから劣化するのです。

に「計画に従うことよりも変化への対応に

る原因になるからです。それを克服できる

  2は、ソフトウェアの故障率の曲線で

より多くの価値をおく」とあります。さら

チームとは?そしてQAとしてどのように

す。初期に起こるバグを直していけば、そ

に、 アジャイル宣言の背後にある原則には、

サポートできるのか?

の後は単発的なバグはあったとしても劣

「要求の変更は、たとえ開発の後期であっ

化はしないというのが、 理想的な曲線です。

ても歓迎します。変化を味方につけること

●お話しの前提

 しかし実際は、ソフトウェアも劣化しま

によって、 お客様の競争力を引き上げます」

 このお話しでは、ある大きなシステムの

す。リリース後に、変更が行われるためで

とあります。

サブシステム開発を担当しているスクラム

す。変更すると新たな不具合が混入する

 ソフトウェア開発を生業とする限りエン

チームを取り上げます。開発対象のシス

ことがあり、故障率は図2の「新たな不具

タープライズから組込みに至るまで、この

テムは新規開発で、チームが担当するサ

合による故障率の増大」のように上昇し、

変化にはどうしても対応していかなければ

ブシステムもスクラッチから起こしていま

ソフトウェアを劣化させます。定常状態の

なりません。ではアジャイル開発の場合、

す。

故障率になる前に次の変更が必要になり、

●最初のバージョン

に故障率の最小値のレベルが上がってい

この変化を受け入れるには、どのように行 動したらよいでしょうか。

それが曲線を上昇させます。そして、徐々

 スクラムには、その手順がよく示されて

 新規開発ですから、要求の変更はそれ

きます。つまりソフトウェアは変更により

います。変更要求をユーザーストーリーに

ほど多くなく、無事にバージョン1.0をリ

悪化するのです(

2) 。

表現し、バックログに落とし、見積もりを

リースします(このとき、 『アジャイルの

 また、定期的なバージョンアップ(実は

して優先順位をつけ直します。スプリント

魂2015』 (

バグの修正もしているのだが)も、品質劣

プランをやり直した結果、ほかのバックロ

ラムチームにQAを取り込む活動をしまし

グをリリースから外すことになれば、プロ

た) 。ほかのサブシステムも立ち上がり、

1)でお話ししたスク

化の原因になることがあります。

ダクトオーナーがステークホルダーと合意

今後運用が始まってから徐々に要求が出

●バージョン1.0、リリース後

するトレードオフの話をしていきます。プ

てくると推測されます。

 最初のバージョン1.0のリリース以降は、

■図1 ハードウェアの故障率曲線

■図2 ソフトウェアの故障率曲線







障 故障率

故障率



010 EM ZERO vol.09

emzero_vol09.indd 10

2016/05/24 12:34

市場や関係するベンダーからの要求が多

シャーが、担当者の作業効率と質を落とし

くなります。ビジネス上、早期に対処しな

てしまいます。

くなる可能性があります。まだ余裕のある 今のうちにやるべきでしょう。さて、どう

ければならないことも出てきます。社内で

したらチームにトラックナンバーを少なく

は、さらに価値を上げるために新たな機

●リスクを減らすための施策

する活動を取り入れることができるでしょ

能を追加したり、既存の仕様を改善する

 今後もプロジェクトには、変更要求のプ

うか?これが今のチャレンジです。

要求が出てきます。

レッシャーが何度もかかることでしょう。

 加えて、障害が起こることも考えなけれ

 このプレッシャーに耐えることができる

●まとめ

ばなりません。障害対応は優先順位が高

力、これが「レジリエンス」です。レジリ

 アジャイル開発のレジリエンスを高める

い変更要求なので、優先的にソフトウェア

エンスを取り上げた書籍には、よく個人が

には、トラックナンバーを減らす活動が必

の修正が行われます。アジャイルでは開

逆境から回復する方法や逆境に対処する

要です。QAオジサンがなぜこんなことを

発後期であっても要求を受けることに、よ

考え方が述べられていますが、ここでは

考えているのか、それは、仕様の理解不足、

り価値をおきます。開発後期に要求を受

チームとしてのレジリエンスです。

プログラム構造の理解不足がバグを生ん

け入れると、当然、時間のプレッシャーが

 それでは、チームとして、プレッシャー

でおり、その情報をQAが捉えられないと

かかります。

をゴムのように早く柔軟に受け止め、一時

QAのテストでも漏れてしまうからです。

へこんでも、うまくいなして復元し予定ど

 この活動にチャレンジしなければ、最初

●効率化のリスク

おりソフトウェアを仕上げてこなしていく

は品質の高いきれいなプログラム、バー

 チームメンバーの実力に応じて、均等に

にはどうしたらよいでしょうか。

ジョン1.0がリリースできても、やがて劣化

タスク配分できれば効率的です。ですが 変更は、ある特定の機能、特定のモジュー

したレガシーコードになってしまいます。 だからこそ、このパターンの知見を生かし

の ー

ルに偏りがちです。つまり、対象モジュー

ていかなければなりません。

ルを担当する開発チームメンバー(ある意 味でドメインエキスパートと呼んでもよい

 これは、ふりかえりのとき、一人の若手

と思います)に仕事が集中してしまうので

メンバーがTryで出したものです。そのと

す。担当者にも限界があるので、ほかのメ

きは、これがチームのレジリエンスを高め

ンバーを投入することになります。もし、

るとは思っていませんでした(そもそもレ

投入するメンバーに対象モジュールの知

ジリエンスを意識していませんでした) 。

見がなければ、次のようなリスクがありま す。

「他人のコードを理解すること」は、 『組 織パターン』 (

)でも「トラック

ナンバーはほどほどに」で述べられていま の …









メインに関する重要な知識を唯一持つ人 クに轢かれたら、彼の持つ重要な知識は

いる場合があります。特に、仕様の背景は

使えなくなります。トラックナンバーが大

暗黙知になりがちです。そのような状況で

きいということは、そのような唯一のエキ

は、誤解や思い込みからバグを埋め込ん

スパートが多くいる組織ということです。



彼らは、ずっと長い間、特定の機能やモ



グ—ソフトウェアプロフェッショナ ルのための基本知識』(ロジャー・

も、どう変更するかを考えるには不足して



ルジャパン2015小冊子、2015年) (2)『実践ソフトウェアエンジニアリン

S・プレスマン、日科技連出版社、

の数です。万が一、そのような人がトラッ



(1)『アジャイルの魂2015』(アジャイ

す。トラックナンバーとは、組織内で、ド

 変更前の仕様をザクッと理解していて

でしまいます。

■参考文献

2005年) (3)『組織パターン』(ジェームズ・O・ コプリエン、翔泳社、2013年)

Profile プロフィール

ジュールを担当し、知見をものすごく貯め ています。 その機能のことは任せておけば、 とにかく早く的確に片付けてくれます。こ

 プログラム構造の理解不足は、より大

のようなエキスパートが何人もいれば、開

きなリスクになります。意図を読みきれず、

発は早くなります。

保守性、可読性、結合度の増加、クラス

 バージョン1.0の開発チームは、担当を

の依存性増加、凝集度の低下といった品

固定していました。できるだけ早く立ち上

質特性やメトリクスが悪化し、バグの温床

げるために効率を優先したからです。

となります。つまりこのコードに変更が加

 私はチームに、トラックナンバーを減ら

ソニー株式会社 IP&S 品質保証部門 システムクオリティ部 品質エンジニアリングマネージャ

わっていくと、バグを生み出すのです。

していく提案をしました。しかし、当初は

NAGATA Atsushi

永田 敦

 これらのリスクを回避するため、わから

今それをやるのはきつい、という反応が

ないところは、ドメインエキスパートであ

返ってきました。ドメインエキスパート以

業務用システムおよび製品の品質保

る担当者に聞いたり、レビューしてもらえ

外のメンバーが、そのモジュールを引き受

証、特にソフトウェア品質の改善に従

ばよいのですが、ただでさえ、たくさんの

ける場合のオーバーヘッドやリスクを懸念

仕事を抱えている担当者のタスクが、ま

したからです。

すます増えることになります。このプレッ

 しかし、今後はもっとプレッシャーが強

事。得意技は、ステルスモードでアジャ イルチームに潜り込むこと。通称「ア ジャイル好きな QA おやじ」。

  EM ZERO vol.09 011

emzero_vol09.indd 11

2016/05/24 12:34

スタートアップの「死の谷」を 乗り越えるためのプロダクトマネジメント パラダイスウェア株式会社 創業者/ CEO

橋本将功

HASHIMOTO Masayoshi

ー よ



戦を展開する国内大企業が参入する可

た技術とではアンマッチの印象を受け



能性もあるでしょう。

ますが、プロトタイピングの段階で枯



 事業アイデアの選択は自分たちの競

れた技術を採用するのは、新技術を採

あり

争環境と収益構造にも反映され、大き

用すると実装中に想定外の限界が見つ



な時価総額を見込める企業になれるか

かることが多いからです。









の しま し の



しょ

よ の の4



しま

という将来性にも影響します。

 プロジェクトマネジメントのスタイ

 このように事業アイデアの軸をオリ

ルはアジャイルも有効ですが、この

ジナルとするか、他者の模倣をベース

フェーズでは十分な資金的・時間的リ

とするかは極めて重要なポイントです。

ソースが確保できないスタートアップ

そして、その判断に伴う「アイデアの

がほとんどのため、一定の稼働量を前

革新性と必要なリソース」のジレンマ

提としたスクラムの実施は困難なこと

を乗り越えるには、適切な製品開発の

が多いでしょう。

事業アイデアはオリジナルか模倣か

マネジメントが求められます。

 エンジニアのみでプロトタイピング

 スタートアップの核となるアイデア

 弊社の経験では、事業アイデアをビ

を行う場合は、エクストリームプログ

は、独創的であればあるほど実現には

ジネスへと形成するには、大きく3つの

ラミング(XP)の採用も可能ですが、

多くの試行錯誤が伴います。これはプ

フェーズがあると考えています。

なリソース(時間や労力)にも直接影

非エンジニアを含む複数人のチームで は「クリティカルパスマネジメント」

ロジェクトの複雑さに反映され、必要

①「アイデアの具体化」フェーズ

が適切だと考えています。チームで常 にプロジェクトの状況を共有し柔軟性

響します。  すでに米国などで確立したサービス

 独創的なアイデアが、既存の技術

を確保したうえで、実装タスクを積み

や他分野のアイデアを転用すれば、 「お

で製品化できるかを確認するのがこの

上げて検証可能な状況まで持っていく

手本」があるため製品化までの試行錯

フェーズです。

という考え方です。

誤は減らせますが、参入障壁が低いこ

この段階ではまだビジネス化が見えて

とから競争が激化しレッドオーシャン

いないため、少人数のチームでコスト

となる可能性もあります。また、圧倒

を抑え、できるだけ「枯れた技術」を採

的な資金とサービス力を持つ本国から

用することが重要なポイントでしょう。

の「黒船来襲」や、大規模ローラー作

 新規性で戦うスタートアップと枯れ

②「プロダクトのブラッシュアップ」 フェーズ  プロトタイプを製作してアイデアの 製品化が可能そうだと 判断できるところまで 来たら、今度はそれを MVP(Minimum Valuab le Product)として他者 が評価できるところま で持っていくのが目的 となります。  スタートアップを語 るうえで見過ごされが ちな点ですが、スター トアップが置かれてい る環境は数年前と比較 して、 「サービスに求め

■図1 弊社プロダクトのプロトタイプフェーズ。各タスクのクリティカルパスを共有して進捗を共有した

られる品質基準」と「ビ

012 EM ZERO vol.09

emzero_vol09.indd 12

2016/05/24 12:34

■図2 弊社プロダクトのブラッシュアップ フェーズ。初期α版からβ版までのタスク を可視化している

ジネス構造の複雑性」が大幅に上昇し

事」を片付けていくことが可能となる

かが非常に重要な経営課題となります。

ています。いったん、事業アイデアが

ため、スクラムを実施できるようにな

 長い「死の谷」の間に「つくり直し」

検証可能な状態になっても、他者が評

るのです。1~2週間程度の短期間のイ

を入れることは、非常に勇気のいる判

価できるMVPまで持っていくハードル

テレーション(反復)をベースに、大

断ですが、やはりビジネス要件が増え

が飛躍的に上昇しているのが現在のス

量の細かいタスクを片付けていくこと

る前に「製品のバージョンアップ」と

タートアップ環境なのです。

を目的にプロジェクトを進めます。

して早期に導入することが重要でしょ

 一定額の資金調達ができない場合

 これをやり切って製品化にたどり着

う。

は、引き続きクリティカルパスマネジ

けば、 「死の谷」も好転の兆しが見え、

 志を高く持って過酷な環境で生き残

メントを行い、 「実績を積み上げること」

セールスやマーケティングといったビ

りプロダクトを形づくっていくには、確

を目的とすることが有効でしょう。

ジネス開発に取り組めるようになるの

かなマネジメント技術が必要です。本

です。

稿が独創的なアイデアをビジネスにす

③「プロダクトの製品化」フェーズ  MVPを製作したら、プロダクトの品

るという高い志を持つ方の参考になれ

経営課題としての「技術的負債」を どう解消するか

ば幸いです。

質を「世の中に出せるレベル」に持っ ていき、課金システムなどのビジネス

 プロダクトの製品化によってビジネ

上の要求を組み込んでリリースするこ

ス開発を行うことができるようになる

とが目的となります。

と、プロダクトには新規性や一定の品

 このフェーズに入れば、アイデアは

質に加え、システム上の安定性や拡張

多くの人に理解してもらえる状態にな

性が求められるようになります。この

るため、資金調達も以前のフェーズよ

ときに課題となるのが「技術的負債」

りはスムースに進めることができます。

をどう解消していくかです。

日本のベンチャーキャピタルや政策金

 技術的負債の解消にもっとも有効な

融公庫の担当者は、製品開発のプロで

のは、リファクタリングで内部構造を

あることが少ないため、事業アイデア

つくり直すことです。ですがリファクタ

や製品の理解を得るには、この段階ま

リングそのものはプロダクトの表面的

で持っていくことが必要なことが多い

な機能には寄与しないため、多くのス

のです。 「新しいモノをつくる」ことは、それ

タートアップ経営者が不要な開発コス トとして認識し忌避してしまいます。

自体がエンジニアやデザイナーなど多

 しかし技術的負債は、不要な開発コ

くの専門家にとってモチベーションに

ストを垂れ流すことにつながり、さら

つながる営みですが、製品化のフェー

に開発者のモチベーション低下を引き

ズでは細かいバグ取りやUI / UXのブ

起こし、中長期的に経営面に大きなコ

ラッシュアップが必要です。資金調達

ストとリスクをもたらします。従って、

を行い、稼働を確保することで、これ

「実装優先」となる製品化までのプロセ

らの「つまらないけど大事な大量の仕

スで、いつこの技術的負債を解消する

Profile プロフィール

パラダイスウェア株式会社 創業者/ CEO

橋本将功

HASHIMOTO Masayoshi http://www.paradiseware.net/ 業務経験は 15 年を超え、メディアサ イトから数千万人規模の会員システム まで、10 社で 80 件以 上のプロジェ クトのマネジメントを実 施。2011 年 にスタートアップを立ち上げ、多くの 人 がプロジェクトをより成 功できる ためのツール「マンモスプロジェクト (Mammoth Project)」を開発。世界 中の現場で戦うチームを応援すること を人生の使命とする。

  EM ZERO vol.09 013

emzero_vol09.indd 13

2016/05/24 12:34

アジャイルとミリタリー あ

の本

斎藤良太 SAITO Ryota

スクラムのルーツ

6つの事例

に重視する情緒主義や強烈な個人の突出 を許容するシステムの失敗。

 破綻したり、死んだり、あいかわらす忙

『失敗の本質』では、6つの事例を取り

 5つ目はレイテ。精緻をこらした独創的

しいアジャイルですが、皆さまいかがお過

上げています。ノモンハン、ミッドウェー、

な作戦計画も、現場がその任務を十分把

ごしでしょうか?

ガタルカナル、インパール、レイテ、沖縄

握しないまま実施し、統一する指揮のない

 さて、アジャイルとミリタリーと言えば、

と、果てしなく憂鬱になる名前が並んでい

まま失敗しました。

スクラム社、そしてスクラムの提唱者ジェ

ます。それぞれの事例について詳しくは、

 最後は沖縄。相変わらずあいまいな作

フ・サザーランドですね。彼はもともと米

本書の第1章をお読みいただくとして、概

戦目的、特に大本営と沖縄現地軍の間に、

空軍のパイロットでベトナム戦争に従軍し

略を見ていきましょう。

認識のずれや意思の不統一が見られたこ

ています。

 まず、ノモンハン。そこでの失敗は、あ

とが、失敗というには重大な敗北を招きま す。

 一般社会のみならず、軍隊においても、

いまいな目的、コミュニケーション不全、

複雑で面倒くさい取り組みをしなけりゃい

独善的な情報解釈、過度の精神主義、を

けないときには、アジャイルな方法が適

原因として取り上げています。

用できるんじゃなかろうかという認識は、

 1939年5月から9月にかけて、日本から

彼や彼の会社の、そして米国国防省やら

遠く離れたモンゴルと満州の間の国境で、

 そして、本書第2章では失敗の分析をし

NATOやらのレポートを覗きみるに、ある

大日本帝国陸軍とソ連赤軍が断続的に戦

ています。いかなる軍事上の作戦におい

程度の広がりを見せているように思えま

闘を繰り広げた軍事衝突です。ソ連崩壊

ても、そこに明確な戦略ないし作戦目的が

す。かように花開いたアジャイル、そして

後、最近の研究では「日本負けてなかっ

存在しなければなりません。目的のあいま

た論」の声が大きくなっているようですが、

いな作戦は、必ず失敗する。なぜならば、

スクラムですが、そのルーツはいかに。

1984年における賢者達の預言  ということで、ここでは、スクラムの生

失敗の分析

日本陸軍の連隊長が4人戦場で自決し、敗

それは軍隊という大規模な組織を、明確

戦の責任を取らされて自決を強要させら

な方向性を欠いたまま指揮し、行動させる

れた連隊長が3人もいるのは事実です。戦

ことになるからです。ところが日本軍では、

死じゃないですよ、自決ですよ。

こうしたあいまいな、目的の明確でない作 戦がしばしば実施されました。

みの親、野中郁次郎らがグループで著し

 続いて、ミッドウェー。こちらは二重の

た『失敗の本質』をあらためて引っぱり出

作戦目標、複雑な部隊編成、そして不測

 ノモンハン事件の作戦目的は明確では

して、1984年における賢者達の預言がい

の事態が発生した時の対応に大きな問題

なかった。ソ連との国境線をめぐる争いに

かなるものであったか、読み返してみま

があったとしています。

対して、軍中央たる大本営は明確な判断

しょう。

 この年、1942年には、日本とアメリカの

を示さないで、結果的に関東軍の独断専

 執筆者一同を名乗る彼らが何を書きた

空母同士による戦いが4回ありました。珊

行を許します。

かったのかは、序章「本書のねらい」にあ

瑚海海戦、ミッドウェー海戦、第二次ソロ

 関東軍は、どうやって国境紛争に対処

ります。

モン海戦、南太平洋海戦の4つです。日米

するかを決めた「満ソ国境紛争処理要綱」

 要約すれば、

の空母が、マトモに戦ったのはこの年のこ

を発令して、同時に大本営に報告します。

の の あ

し し 本の の



し し し あり

本 の



き あ

の 本の の

大 本 の









の4回だけです。1944年以後、アメリカの

が、大本営はなんも言ってこない。 「満ソ

新型空母が続々と就役すると、もうマトモ

国境紛争処理要項」は、ソ連が国境越え

な戦いにはなりません。日本艦隊が一方的

て来たら、即座に一撃加えて出鼻をくじい

に負けるだけです。

てやるぜというもの。関東軍としては、大

 その2回戦目が、ミッドウェー海戦です。

本営がなんも言ってこないんだから、これ

1942年6月ミッドウェー島をめぐるこの戦

は認められたものだと判断します。

いで、大日本帝国海軍は、真珠湾攻撃以来、

 で、 一紛争あった後、 今度は大本営が「ノ

無敵を誇ってきた空母機動艦隊の主力4隻

モンハン国境事件処理要綱」を作成しま

を失う大損害を被り、太平洋における主導

す。これの主旨は、関東軍を信頼して任せ

権をも失いました。

るけど、一撃加えた後は速やかに兵を撤

 3つ目はガタルカナル。情報の欠落と戦

退させるようにしなさい。航空部隊を使っ

力の逐次投入、日本の陸軍と海軍はバラ

て国境を越えて攻撃するのは、事件が大

 そうです、今あなたが、読者の皆さまが

バラの状態で戦い、さらに米軍の新機軸、

きくなるから絶対にやっちゃダメ、という もの。

とのことです。 所属しているのは、日本の組織じゃないで

水陸両用作戦に対処できませんでした。

すか?その組織は、日本軍と同様の欠陥を

 4つ目はインパール。しなくてもよかっ

 ところが、この「ノモンハン国境事件処

持っていたりしませんか?

た作戦。合理性を欠き、人間関係を過度

理要綱」は腹案で、正式に関東軍に命令

014 EM ZERO vol.09

emzero_vol09.indd 14

2016/05/24 12:34

はされませんでした。命令にはしないけど、

 日本軍の思考方法は、現実から出発し、

はなかったから。 「自己革新組織」とは、

こういうのを作ったんだから「察して」ほ

状況ごとに、ときには場当たり的に、対応

環境に対して自らの目標と構造を主体的に

しいという、国軍の運営にはありえないよ

し、それらの結果を積み上げていく方法で

変えうる組織です。

うな意思疎通がまかりとおります。関東軍

す。これは、客観的事実の尊重とその行

 あなたの組織は、自己革新能力を持っ

は独断で、盛大に越境航空攻撃をかけて

為の結果のフィードバック、一般化が頻繁

ていますか?

戦果をあげます。一撃加えた後も攻撃を

に行われる限りにおいて、とりわけ不確実

続けます。

な状況下できわめて有効なはずです。

 関東軍参謀が電話で大本営に戦果報告

 ううむ、 何かの方法論に似ているぞ。 「ふ

すると、大本営サイドは「ちゃんと命令し

りかえり」は重要ですね。

なかったのは、関東軍の地位を尊重して、

 ところがぎっちょん、日本軍にあったの

自発的に中止させようとしたのに、関東軍

は客観的事実の把握ではなくて、主観の、

は大本営の意中を無視して強行し、大本

自分の思い込みによる戦略策定でした。日

 最後に一言。 「ガルパンはいいぞ」

営の信頼を裏切った」と非難し、関東軍サ

本軍の戦略策定が、状況変化に適応でき

イドは、 「決死の大戦果に対し、第一線の

なかったのは、組織の中に論理的な議論

心理を無視しなにが大本営だ」と反発しま

ができる制度と風土がなかったことに原因

した。

が求められます。山本七平は、日本軍の最

 こんなことをしていたら、ソ連の大兵力

大の特徴は「言葉を奪ったことである」と

による砲撃で負けてしまいました。

指摘しています。

『アメリカ海兵隊』 (野中郁次郎 著、中公新書)

 ミッドウェーでの作戦目的もあいまいで

 戦略策定を誤った場合、作戦がうまく

す。ミッドウェー島を攻略するのか、敵艦

いかない場合でも、それを修正する行動

隊を撃滅するのかはっきりしない。

である「中止」や「撤退」は、決定的局

 レイテでの作戦目的も不統一。大本営

面を迎えるまで、できませんでした。

の目的は、レイテ湾に艦隊を突入させて、

 さらに、日本軍という組織は、 「日本的

そこにいる輸送船団をたたきのめす。実際

集団主義」に立脚していると論じています。

に艦隊を指揮する現場の目的は、敵艦隊

それは、組織目標と目標達成手段の合理

を撃滅して死に花を咲かせる。中央と現場

的、 体系的な形成選択よりも、 組織メンバー

の意思疎通は不十分としか言いようがあり

間の「間柄」に対する配慮を重視する主

ません。

義です。それは、組織の意思決定を手酷

 沖縄戦でも同じ。大本営は航空決戦を。

く遅らせることにより重大な失敗をもたら

現地第三十二軍は地上戦闘による長期持

します。

久戦を。

 

 結局、日本軍はインパールも含む6つの

あなたの組織の意思決定は 十分に早いですか?

事例すべてについて、作戦目的に対する 全軍的一致を得ることに失敗しています。  

 さらに、人事において、日本軍は結果よ

あなたの組織は目的が明確ですか?

りも、 「やる気」 を重視しました。攻撃、 侵攻、

 だいたい、米軍と戦争を始めて、どう

ても責任はあいまいに、いったん左遷され ても再び中央に戻されました。

かね?

 が、撤退や中止や持久を進言する人た

 日本軍の戦略決定には、一定の原理や

ちの多くは、罷免、予備役編入などの処

論理に基づくというより、多分に情緒や空

分を受けました。どうしてこうなったので

気が支配する傾向があると断じています。

しょうね。

科学的とは言い難い、 「やればできる」と です。あなたの組織は、アイドルマスター

尾孝生、村井友秀、野中郁次郎 著、中 公文庫)

『彗星夜襲隊』 (渡辺洋二 著、光人社NF文庫) 『スクラム』 (Jeff Sutherland著、 早川書房) 『スクラム』 (松瀬学 著、光文社新書) 『新・スクラム』 (松瀬学 著、東邦出版) 『カンバン仕事術』 (Marcus Hammarberg, Joakim Sundén著、 オライリージャパン)

Profile プロフィール

突撃を主張する人たちは、作戦が失敗し

やって終わらせるつもりだったんでしょう

信じる力、主観で作戦を立てているわけ

『失敗の本質』 (戸部良一、寺本義也、鎌田伸一、杉之

では、どうしてこうなったか

のオープニングみたいなこと、言っていま

 詳しくは本書第3章を読んでもらうとし

せんか?

て、結論から言えば、 「自己革新組織」で

斎藤良太 SAITO Ryota

1961 年生まれ。2000 年より 2014 年 にかけて開催された仮想戦記コンベ ンション IFCON の事務局を運営。そ の傍らプログラマとして、駅やら空港 やら工場やらのシステム開発に従事す る。趣味はフットボール観戦と計算尺。 埼玉県在住。

  EM ZERO vol.09 015

emzero_vol09.indd 15

2016/05/24 12:34

株式会社一(いち)代表取締役社長

大槻 繁

OTSUKI Shigeru

アプローチ  最近、 「学際(interdisciplinary) 」と

いうことが、ソフトウェアエンジニアリ

それぞれの領域の思考方法の特徴を把

ングの中心的な問題設定だった。しか

握するところからアプローチしている。

いう言葉が気になっている。異なる学

し、ソフトウェアが社会に溶け込んで

 デザイン思考は、工業製品やクラフ

問領域にまたがることを意味している

(dissolving)いくにしたがって、ソフト

ト(工芸品)に見られるように、芸術

らしい。新しい製品・サービスを生み

ウェアの使い方、さらには、新しい要

的要素や美しさの追求、システム思考

出すということは、それを支える理論・

求を策定し、新たなソフトウェア社会

はハードウェア・ソフトウェアなどを

技術は、既存のものでは済まなく、新

を構築していくにはどうしたらよいか

含む大規模で複雑な世界を扱う。で

しい世界、境界領域に広がっていかざ

というところが探求の中心になってき

は、 ソフトウェア思考はなにかというと、

るをえない。

ている。

最終的にはコンピュータ上で実行され

 ソフトウェアエンジニアリングは、

アー

学問領域として発祥して半世紀程経っ

るものを扱うので、計算や、それに伴

クトの思考

う概念が中心課題となる。

た。ソフトウェアに関する原理・方法論・

  「アーキテクト」と呼ばれる人々が

技法・ツールは、それなりに進歩・成

行う「思考」は、このような学際的も

コミ

ーシ ンの

熟し、ソフトウェアによって我々の社

のに違いない。そこで、 1に示すよう

 このような探求では、必然的に今

会を豊かにし、富をもたらしてきたと

に、ソフトウェアエンジニアリングを

まであまりお付き合いしたことがない

いえる。

取り巻く学問領域に目を向け、 「ソフト

研 究 者・実 務 家などとやりとりしな

 仕様が明確になったとき、それをコ

ウェア」+「デザイン」+「システム」

くて は な ら な い。 △×BoK(Body of

ンピュータプログラムで実現すること

の3つの領域を統合する試みを行って

Knowledge)と呼ばれている標準知識

によって解くにはどうしたらよいかと

いる。とりあえず「〇△思考」と題して、

体系も、山のように提唱されていて、 勉強するだけで一生終わってしまいそ うな感覚である。

デザイン論

心理学 人間工学 芸術・美 文化

社会理論

社会 複雑系

進化論

共感・創造

自然・生命

を理解できないし、理解する必要もな

記号 パターン 全体 検証

変化・進化

システム思考

システム工学

ニケーションはとるけれども、すべて

言語学 意味

コミュニケーション

大規模・複雑性

交流、学際的アプローチとは、コミュ

哲学

デザイン思考

エスノグラフィー

 そこで、はたと気づく。異種文化の

記号論

組織

情報学

概念・計算

化研究会(ソフトウェアの知の働きを

言語・記述

オートマタ

ソフトウェア思考

ソフトウェア科学 ソフトウェア工学

システム科学

経営学

■図1 学際的アプローチによる統一思考

い。アジャイルプロセス協議会の知働 探求する研究会)では、 「知のフリマ」 という知を持ち寄って交換する蚤の市 を時々開催している。原理は簡単、図 2に示すように、コミュニケーションの 定義を、なにかを伝えるということで はなく、 「お互いに学習・成長するプロ

016 EM ZERO vol.09

emzero_vol09.indd 16

2016/05/24 12:34

フィー

コミュニケーション



フィー



イラスト

アラ

■図2 コミュニケーションとは?

セスである」と変えるだけでよい。

思考停止の 理

かまわない。  曖昧模糊としたキーワードを羅列し

 男女の仲を考えてみるとわかりやす

 人間、すべてを理解・思考すること

てコミュニケーションがとれたと誤解

い。しょせんお互いにすべてを理解で

はできない。どこかで「思考停止」し

する人が多い。 「システムをIoT活用で

きるということはないが、切磋琢磨し、

なくてはならない。我々は、教科書に

得られたビッグデータとディープラー

刺激し合うことによって、成長してい

書いてあることは、自ら確かめること

ニング推論によってリアルタイムマネ

く。これが全体として、 (人生を)豊か

なく正しいと信じる。数学の定理、物

ジメントを可能にする」といったポス

にしていくことに繋がる。

理や化学の法則など、すべてを自分で

トモダン表現は、おそらく、なにも伝

 古くからあるソフトウェア開発にお

証明し、実験することは不可能である。

えていないし、これを発した人も聴い

けるユーザ・ベンダ関係の間にもコミュ

 思考停止の原理は、 「権威」によって

た人も、なにも学習することもできな

ニケーションが成立していなくてはな

いる。背景に、専門家による検討とレ

い。〇△思考で掲げた3つの領域間で

らない。ユーザはベンダの開発専門家

ビューという社会的なしくみに支えら

とくに注意すべきなのは、 「システム」

としての世界すべてを知ることはでき

れているから、ある程度正しいと信じ

「モデル」 「設計(design) 」といった用

ないし、逆に、ベンダはユーザのこと

られることになる。学会の査読制度は、

語が、多義的であったり、矛盾した用

をすべて掌握することはできない。往々

論文の読者にとって、追試や反証の余

法になっていたりすることが多いこと

にして、 「お互いに学習するプロセス」

地があるかもしれないが、少なくとも

である。

であることを忘れ、成長もなく、 「ハラ

次のステップに研究を進めていくため

 優れたアーキテクトと呼ばれている

スメント」に陥ってしまうことが散見さ

の命題については、思考停止して受け

人々は、大規模・複雑なものを扱う場

れる。

入れてよいことを保証している(だと

合でも、専門領域の構成、タイムスケー

よいが) 。

ル上の変貌などを予見し、どこで思考

 BoKは、専門分野の研究やそれらを

停止すべきかを、自らの意思で決定で

支える諸概念がまとめられ、編纂され、

きる能力を持っているというのが、筆

(リジアン・テッド著)では、社会・大

レビュープロセスを経て公開される。

者の現時点の仮説である。

企業が凋落するのは専門や事業領域ご

これも知に関する社会的なしくみのひ

 さて、あなたの周りに、思考停止の

とに蛸壺化してしまうからだという主

とつである。ただし、科学論文よりは

達人は、見当たりますかな?

張が印象的だった。

ゆるいプロセスなので、盲目的に信じ

の  最近読んだ書籍『サイロ・エフェクト』

 同様の指摘は、 『プラグマティズムの

ることができないものも多い。すなわ

作法』 (藤原 聡著)にもある。プラグマ

ち、権威が薄れていることもあり、全

ティズムの格率(格言)によると、「対

てを信じることができるほど、思考停

象の概念を明晰にとらえようとするな

止可能ではない。

ら、 その対象の効果を考察せよ。すると、 この効果についての概念は、その対象

Profile プロフィール

し 思考停止の技法

の概念と一致する」。

 ここで述べておきたいのは、 「正しい

 専門領域分化の処方箋として述べる

思考停止」の方法である。高度専門化

ならば、 「自分のやっている研究・製品・

社会では、それぞれの専門領域を深掘

サービスなどが、専門外の人々にとっ

りしつつ、その知見の他領域での利用・

て、どのような利用・活用法があるか

活用方法を常に意識しなくてはならな

を常に考えよ」ということだ。簡単な

い。そして、その利用・活用法の探求は、

ことだが、なかなか難しい。専門化す

お互いに学習するプロセスとしての「コ

ることがいけないのではない!専門領

ミュニケーション」が成立するように

域が、その外部でどのように利用され

しなくてはならない。この状況が保た

るかを常に考えなくてはならないのだ。

れるときにのみ、思考停止を行っても

株式会社一(いち)代表取締役社長

大槻 繁

OTSUKI Shigeru アジャイルプロセス協議会 フェロー 知働化研究会 運営リーダ 実践的ソフトウェア教育コンソーシア ム 理事 ソフトウェアアーキテクト協会 発起人

  EM ZERO vol.09 017

emzero_vol09.indd 17

2016/05/24 12:34

あまのりょー AMANO Ryo

あまのりょー

つつ、こちらからは「さまざまなプロジェクトをこなしてき

し りの まし

た経験」を提供することでプロジェクトを成功させたい、と

あり

私は表現しました。 の の

ー 本







自分たちで勉強する風土が定着しない



 さて、Nさんはいわゆる PMO的な活動をしながら、課題の

ベトナムの会社と一緒に仕事

本質の考察を行いました。ここで着目したのは、自分たちで いろいろと勉強したりする風土がなかなか定着しないところ です。

 さて、私は昔DevLove やデブサミで「MY JOB WENT TO

 NさんはHofstedeの文化次元インデクスなどに基づく独自

VIETNAM?」というタイトルでベトナムの会社と一緒に仕事

の見解として「自分たちのやり方」を見つけない限り長続き

をした(いわゆるオフショア開発)の話をしたことがあります。

しないと考えていますので(ちょっと話題は外れますが、2

ひょっとしたら聞いてくださった方もいるかもしれません。

月末に行ったインハウスイベントでの、これに関するNさん

 私がその担当をしたのは 2010年9月から1年ほどで、以後

の発表も素晴らしいものでした) 、 「日本や米国のソフトウェ

は別業務にアサインとなり、ベトナムとは離れてしまいまし

アエンジニアは仲間内で勉強会や読書会をやったりするの

た。しかし、私の所属会社としてはその後も継続的にそのベ

で、ここでもやってみましょう」と文化を押し付けたところ

トナムの会社(表記が冗長なので、以後 F社と書きます)と

で意味がないことを知っています。

一緒にプロジェクトを執り行ってきています。  5年も協業が続くと、私が立ち上げた当初の、規模がそこ までではなかったころには見えにくかった課題が目立つよう

「母国語でライトに読める技術情報誌」が欲しい

になってきたのです。そこで、弊社では単一のプロジェクト ごとに担当者が付くのに加えて、半常駐に近い形でベトナム

 そういう押し付けの代わりに、Nさんはひとつの仮説を立

に住んで取り組むPMO役の人間もアサインし、F社と共同で

てたのです。すなわち、 日本では古くは『C Magazine』や『I/

総合的に戦略を練る方策に出ました。それがアサインされ

O』あるいは『マイコンBASICマガジン』 、最近ですと『WEB

たのは、F社との協業開始当初から関わっていて(もちろん

+DB PRESS』のように「母国語でライトに読める技術情報

私が事例発表したプロジェクトも一緒に手伝ってもらいまし

誌」があるのに、ベトナムにはそれが皆無であることが、ひ

た) 、現地のメンバーからの信頼も厚いNさんです。

とつ影響しているのではないか、という仮説です(ここで言

 ビジネス上パートナーとなる、ということは(単にヘッド

う「ライトに読める」というのは内容が軽いという意味では

カウントや単価だけではなく)なにがしか補完関係があって

なく、アカデミック寄りではなくてより実践的な、くらいの

こそ長続きするのだと私は確信します。それを事例発表の場

意味、つまり学術情報誌とは違うニッチの雑誌という意味で

では、彼らからは「溢れるようなモチベーション」をもらい

す) 。

018 EM ZERO vol.09

emzero_vol09.indd 18

2016/05/24 12:34

 そう、Nさんは社内誌ではありますが、ベトナム語で読め



る技術情報誌を創刊することにしたのです。創刊にあたって は私にも主に記事提供という形で協力依頼がきましたので喜 んでお受けしました。始めてみてわかったのですが、フリー テーマのコラム的連載を毎月書き上げるのはなかなかに大変 なことです。でも、Nさんの熱意と、なにより私自身がベト

201

6



201



201

8

201





ナムのみんなとまた関わりあえるというので 2015年6月号の

201

10



1

創刊号以来、毎月の連載記事を持たせてもらっています。

201

11



2

201

12



2016 1

ベトナム語で見る自分の記事

2016 2 2016

 日本語で書いた原稿がベトナム語に訳されるわけですが、 翻訳後の記事を読んでも自分にもなにが書いてあるかわから ない、というのは結構おもしろい経験です:)。なにより、意 図どおりの記事になっているかどうかも検証できない、とい

■創刊号の表紙(この号の特集は「アジャイルマインドセット」 )

うスリリングさがあります。けれど、私の尊敬する方の一人 があるとき言っていた「近似値でもいいから伝えようとする 努力」が必要な場面だと考えてやっています。  小規模とはいえ、そういったものを出すとなると、私やN

EK GE

さん以外の現地メンバーで記事を書いてくれる人の手配、特 集のネタ決め、翻訳スタッフの確保、編集部メンバーとして 学生インターンの採用、印刷の手配、組版ソフトの習熟、な どやることは盛りだくさんなのですが(主にNさんの情熱の 賜物として)なんとか続いています。  文化をインストールする、というのは時間がかかるもの だと思います。まだその効果がどうなったか、目に見えるも

an

のはないのも事実ですが、先日ベトナムに数年ぶりに出張 に行ったときに「読んでるよ!○○の記事が特に印象に残っ ている」と言われたときには単純にうれしかったですね。そ んな素朴な喜びの積み重ねでなにかが変わっていくといい

T

d

なぁ、と思います。

 そんなわけで、皆様の寄稿もお待ちしております!

H MAG EC

『Geek & Tech Magazine』の紹介

 創刊号以来、私が書いた記事の元タイトルと、その雑誌

Profile プロフィール

『Geek & Tech Magazine』の表紙を紹介して本稿を閉じます。

E IN AZ emzero_vol09.indd 19

あまのりょー AMANO Ryo

 都内のメーカー系ソフトウェア会社 で働く自称「チアリーダー」。   ち な み に『Geek & Tech Magazine』 での連載のタイトルは       。日本語だと「パクチー 王子の部屋」とのことです。なんか 誰かに勝手に紹介された内容みたいだ(http://www.manaslink. com/articles/8952)。

  EM ZERO vol.09 019

2016/05/24 12:34

ある40代男の レガシーボディ 改善物語

ゼンソー代表/ Agile459代表

懸田 剛

KAKEDA Takeshi

し りの

の し



「自分が成長する歓び・楽しさ」に導かれ

夢と楽しみ

ていきました。



「自分でも、人類の本来の動きを取り戻せ



ば、裸足で走れるようになるはず」という

『走るために生まれてきた』



仮説を検証したい欲求がふつふつと湧い

 走り始めたころ、カフェで見かけた『走

失敗の数々

るために生まれた』 (

1)

てきました。  その結果、 「走ること自体・走ることで

という本を手にとりました。結局自分で購

自分が成長できる歓び・楽しみ」に加えて 「人の身体の可能性を生かして走れる(=

 これまで、人生の中で多くの失敗をして

入して最初から読み始めたのですが、読

きました。 その中でも特筆すべきなのは 「ダ

み進めるうちに、どんどんのめり込んでい

裸足で走る)ことを検証する」という新た

イエット」の失敗です。

きました。

な目的が生まれ、走ることにどんどんのめ

 子供のころからふくよかだった私は、高

 この本では、人間はほかの動物と比べ

り込んでいきました。

校のころには最大86kgの体重を記録し、

て「長距離を走る」ということに最適化さ

それ以降も78kg付近をいったりきたり。

ランから食生活への目覚め

たまに一念発起して、75kgくらいに減らし ては戻り、戻っては増え、そしてまた減ら

 走るという行為で身体に興味を持った

しては戻る、そんなジェットコースターの

結果、食生活にも目を向けるようになりま

ような体重変化を20年くらい繰り返してき

した。人は食べたものを身体に取り入れ、

ました。

日々の過ごし方の積み重ねによって、身体

 なぜ、うまくいかなかったのでしょう

がどのように構成・成長・維持されるかが

か?当時の私には「なぜ体重を減らした

決まります。

いのか」 「減らした先にどうなりたいのか」

「食べて、運動して、成長する」 、当たり

という具体的ななりたい姿がなかったから

前のようにも思えますが、大事である自分

だと感じます。

の身体・健康について、仕事と同じような 意識で取り組んでいる人は驚くほど少な いのではないでしょうか。

ランへの目覚め  そんな私ですが、2012年(当時40歳)

■図1  『走るために生まれた』 (クリストファー・マクドゥーガル著)

から突然走り始めました。シューズもウェ アも買わず、ありあわせのスニーカーとT

脳を鍛えるには運動しかない?  また運動することが、脳科学の分野で

シャツで。それまで「走るという習慣」な

れた構造に設計されているということ、靴

んてものは、人生の中で一度もなかったに

を履くことで本来の身体の動きと異なる

 有名なのは、ジョン・レイティの『脳を

も関わらず、です。

動きになってしまい、その結果として問題

鍛えるには運動しかない!』 (

 初日は3kmを20分くらいで走りました。

(怪我、身体の使い方の欠如)が発生して

翌日は足が筋肉痛で、階段の昇降にとて

いること、裸足で走ることが本来の人体の

も注目されていることも知りました。

2) です。 この書籍では、 「運

も苦労しました。それでも、3km走れたこ

構造に適していること、世界には走ること

動すると、なぜ脳に良いのか」という点を、

とがうれしくて、足が痛ければ歩き、痛み

を当たり前としている人々が住んでいると

さまざまから科学的な結果をもとに説明し

がなくなればまた走りだしました。走るた

いうこと、フルマラソンを越えた超長距離

ています。

びに距離や時間を伸ばしていきました。

の山を走るレースがあるということ、など

 思えば、2006年ごろに一部で話題になっ

 これまでまったく習慣のなかった自分で

など、どれもが今まで聞いたこともない新

たライフハックである「腰リールメモ」は、

も、少しずつ遠くまで走れるようになる、

鮮な驚きばかりでした。

歩きながらふと思いつくアイデアを記録す

020 EM ZERO vol.09

emzero_vol09.indd 20

2016/05/24 12:34

“Health is a state of complete physical,

今を楽しむ・工夫する

mental and social well-being and not merely the absence of disease or infirmity.”

 もうひとつのポイントは、未来に進む

(健康とは、病気でないとか、弱っていな

だけでなく、 「今ここを楽しむ」ことです。

いということではなく、肉体的にも、精神

いくら向かいたい未来が魅力的でも、その

的にも、そして社会的にも、すべてが満た

過程の一日一日、一瞬一瞬が、退屈であっ

された状態にあることを言います。 )

たら継続することができません。

■図2  『脳を鍛えるには運動しかない!』 (ジョン・レイティ著)

「今をどう楽しみ充実させるか、よりよ

 仕事で成果を出すこと、社会的に認め

く・楽しくする」ための工夫を継続的に行

られたり、人と繋がること、精神的に満た

います。

されること、それらと同じように、肉体的

 たとえば、 「畑に走っていって水やりし

に充実させ、その状態を維持することが、

てみよう(水やりラン) 」とか「走りなが

すべてが満たされた状態にあるということ

らミーティングしてみよう(ランミーティ

になります。コードも身体も実はつながっ

るためのガジェットでした。以前職場が新

ング) 」 といった試行、 スマフォやGPSウォッ

ているのです。

宿御苑の近くだったとき、散歩ミーティン

チで自分の走った記録をつけて分析する

 もしも、あなたが、30歳を過ぎて身体

グを頻繁に行っていたのも、すべて繋がり

といったガジェット利用、自分で草鞋(わ

のことをまったく考えていないのであれ

ました。

らじ)を編んで走ってみよう(ワラジラン)

ば、少しずつ、できることを始めてみてく

といった工夫をしながら日々を楽しんでい

ださい。自分で楽しいと感じることだけを

体質・習慣改善は システムの改善である  あらためて思うのは、自分の身体を変え

行い、なりたい姿を描いて、工夫してみて

ます。

ください。

試してみる、ふりかえる、改善する

る、生活習慣を変えるということは、 「シ

 変化の過程では、アジャイル開発と同

ステム改善である」ということです。

様に「フィードバックループを回す」こと

 ありたい姿を描き、そこに向かうため

が不可欠です。

に、ひとつひとつ課題をクリアしていく。

 なにか新しいことを試したら、評価して

うまくいかないところは、うまくいくよう

みて継続するかを判断します。まずは試し

に変えて、小さな成功体験を積み重ねて

てみて、自分の体験をもとに評価する、そ

いく。古い習慣を徐々に、新しい習慣に変

ういった試行錯誤を意図的に行います。

えていく。

 巷に溢れるさまざまな情報に振り回さ

 皇居に走りに行き始めたら、徐々に仲間

れるのではなく、 「自分でひとつずつ試し、

ができてランニングクラブに参加する。ク

ふりかえり、次のステップを自分自身で見

ラブの皆と週末に合同練習をすることにな

出していく」フィードバックループが重要

る、というようになるかもしれません。

です。

「今を変えたい」だけでなく 「こうなりたい」を作る

態を作り、維持し、充実した仕事、充実し た人生を送るために。

Profile プロフィール

ゼンソー代表/ Agile459代表

懸田 剛

KAKEDA Takeshi

「漸進的に、自分・自分を取り巻く環境 がゆっくりと変わっていく」のです。

 肉体的のみならず全方位的に健康な状

健康はすべてにつながる  プログラマは、テストが整備され、可読 性が高く、品質が高いコードを「健康的な

 2010年より東京から松山に移住し、 アジャイル・スクラム、プロジェクトファ シリテーション、パタン・ランゲージ などのスキルを活かし、顧客の現場

コード」というメタファを使う場合があり

で価値提供のための人づくり、しくみ

 ここでポイントなのは「~変えなければ

ます。健康的なコードは、持続的に価値を

づくり・文化づくりを支援している。

ならない」という強迫観念だけでは続かな

提供することができるためです。

い、ということです。

 次にメタファではなく、プログラマが関

 私の場合、 「いつか裸足でマラソン走り

わっている開発対象のシステム・プロダク

たいなぁ」というぼんやりとした未来像と

トは、 「関わっている人も含めてひとつの

共に、近い将来の目標としての「ハーフマ

システム」と考えてみてください。

ラソンを完走したい」 「フルマラソンで4時

 プログラマが自身の健康をないがしろに

間切りたい」という、明確な「なりたい姿」

して、日々仕事に没頭しているのであれば、

ンサブ3.75、裸足でのフルマラソン完

に向かうことになりました。

たとえコードの健康状態は維持していて

走を目指す。

 そして、いつしか「100kmマラソンを完

も、プログラマの健康的負債をシステムに

走したい」 「100マイル(160km)の山岳レー

対して日々借金していることに等しいと考

スを完走したい」という、最初は思いもよ

えることができます。

らなかった「なりたい姿」が見えてきまし

 世界保険機関(WHO)は、健康を次の

た。

ように定義しています。

 ITエンジニア向けの健 康情報の共 有+アクティビティ体験型イベント「ヘ ルスハックカンファレンス」 (http:// healthhackconf.github.io/)を、2016 年3月に愛媛県松山市で開催した。  2016年度中に100kmマラソン完走、 70kmトレイルレース完走、フルマラソ

サ イ ト:http://zensow.jp/ 個人ブログ:http://giantech.jp/ 全 走 歴 :https://www.strava.com/ athletes/3772130/

  EM ZERO vol.09 021

emzero_vol09.indd 21

2016/05/24 12:34

なんでもアジャイルのススメ もし草野球のおっさんプレイヤーが アジャイルを学んだら なんでもアジャイルのススメ  一生の2割、職に就いているときは1

小林 信

KOBAYASHI Makoto

見直したときのお題目にもなる。

し、草野球に適用する場合はどうすれ ばいいのだろう。そこで自分なりの解

 アジャイルは変化を受け入れる。だ

釈をすることにした。

からこそ、変化が価値のあるものかを 見極めることが重要だ。その判断基準

年の3割が仕事に費やす時間らしい。3 割が睡眠時間にあたるので、起きてい る時間の半分近くは仕事だ。残り半分 がプライベート。せっかく仕事で得た スキルや考え方なのだから、有用なら

がインセプションデッキによって表現

・個人との対話→1人なので自身の思

される。インセプションデッキの作成

いをアウトプットして記録

こそ、アジャイルを成功させる第一歩

・動くソフトウェア→草野球選手とし

である。

ての自分そのもの

ば(規則やモラルに反しない限り)プ

・顧客との協調→草野球・自チームが

 やる・やらないことリストで範囲も

ライベートにも適用したいと常々思っ

なにを求めているかを真摯に受け止

明確にした。今回は「打つこと」に対

める

して徹底的に行い、守備に関しては(ど

ている。その考えが根底にあるため、 趣味の野球にアジャイルの考え方を導

うすればいいかわからない)対象外と

・変化への対応→そのまま

した。

入したことは自然の流れだった。  僕はアジャイル開発手法の中でもス

【方向づけ:インセプションデッキ】

クラムを中心に学び実践したが、ソフ

 次に方向づけ、インセプションデッ

トウェア開発手法という枠組みに収め

キの導入である。まずはエレベーター

 なりたい選手を表現することはでき

ておくにはもったいないやり方である。

ピッチだ。テンプレートに従い、どの

た。次に、その選手になるためになに

自分やチームの成長を促し、結果を出

ようになりたいのかを表現。当初は守

が必要かをユーザーストーリーによっ

し続けるためのしくみそのものだ。

破離の守に則って作成した。

て記述した。ここでは「こうしたらい

「得点力不足を解消」したい「我が

プレートにある「なぜなら」の部分が

【計画:ユーザーストーリーの作成】

いな」と思うことを書き連ねた。テン

 アジャイルをプロジェクトに適用す ることができなくて悶々としている人 は、趣味に適用することを推奨したい。 あなたの生活にプラスの効果を与えて くれるものだと信じている。  2014年夏。僕は歓喜した。 「これだ!」 と思うやり方に出会ったのだ。  昔から計画を立てるのは好きだった。 このとおりにやれば完璧なものができ

エレベーターピッチの枠内に収まって

チーム」の「小林信」という選手は、

いるかが重要である。

「相手投手の嫌がる巧打者」である。 「甘い球を見逃さず、際どい球を見

【実行:スプリント】

極める」ことができ、 「昨年までの

 シーズンも終盤を迎えた9月。僕は

小林信」とは違って、 「高い打率と

求める姿を体現すべく、アジャイル野

出塁率」が備わっている。

球に取りかかった。スプリント期間を1

あがるはず。ただ、それがうまくいくこ

 ふりかえるとエレベーターピッチの

週間のタイムボックスとして設定する。

とはほぼなかった。なぜならば、僕は

効用はすごい。なによりの道標になり、

 デモは顧客に披露する機会、つまり

行動が苦手なのだ。PDCAサイクルが 重要だ、 というのは承知している。だが、 実行に移せない、習慣になってくれな

■図1 スプリント模式図

い。

Redmine

 僕がこの夏に出会ったアジャイルは

登録

行動を支えてくれるやり方、そんな予 感がした。そこで、趣味である草野球 のトレーニングにアジャイルを導入す

結果・ニーズ

ることにした。これはその足跡である。

要求一覧

スプリント計画

・要求 1

・タスク 1

・要求 2

短期計画

・タスク 2

 …

僕のアジャイルチャレンジ 【原則】

 僕ははじめから悩んだ。アジャイル を行う場合、アジャイルマニフェスト

 … 満足

実践 試合

ふりかえり

日々のトレーニング

ビルドアップ

は押さえていなければならない。しか 022 EM ZERO vol.09

emzero_vol09.indd 22

2016/05/24 12:34

試合とした。試合に臨む自分そのもの

か…



を成果物とし、 ビデオに記録。ユーザー



ストーリーで描かれるイメージと実際



の動きの差異から、フィードバックを 受け取ることとした。  スプリントは自分の中でもっとも価 値のあるストーリーから手を着ける。 レ

そのストーリーとは「 【巧打者】として 【自分が得意なボールを初球から打ちに いき】たい。なぜなら【不利な状況に なる前に打ちに行くことにより、自分

ーター



ーター



2 1



ーター



2 1



2 1

の ■図2 最終目的に向けたステップ

のスイングで勝負できるから】だ」 。  選んだストーリーに対して、実行す るための(1人)計画ミーティングを行

 迎えた2015シーズンでは新たなエレ

とを知った。最高にハッピーになれる

う。このミーティングで、ストーリーを

ベーターピッチを策定し、一からつく

ことを知った。そして、周りの人にも

実現するにはなにをすればいいかを決

りあげることを決めた。アジャイルは

ハッピーを味わってもらいたい。この

めていく。

行動できない人に対して有用なしくみ。

気持ちを原動力に、今日も少しずつ周

 分割方法に言及している書籍は少な

タイムボックスに従い改善を重ねてい

りをアジャイル色に染めていこうと決

く、もっともチームによる差がでる箇

くこと、その結果が早期に検査できる

意する。

所だ。今回は、 「単純な行動」として分

こと。このしくみそのものが、継続し

割することにした。上記ストーリーの

た行動へのモチベーションとなる。

場合は、 「得意なボールを調査する」 「得

 投手の横を抜け、センター前にボー

意なコースを振り抜ける素振りを行う」

ルが転がる。僕はボールの行方を見送

「バッティングセンターで得意なコース

り右手を高々と突き上げた。草野球人

のみ打ちにいく」などに切り分けていっ

生20年で初めての三冠王に輝いた瞬間

た。

だった。2015年冬。アジャイル打撃ト

(http://www.agilemanifesto.org/iso/ja/)

レーニングに取り組んで1年半。僕はエ

(2) 『アジャイルサムライ—達人開発者

【検査・改善:スプリントレビュー】

レベーターピッチに描いた選手像その

 スプリントレビューは試合の打席結

ままに成長した。

果によって行う。野球の打撃において

 僕は今、2016年のシーズンに向け

動くソフトウェアとは、打者そのもの

てインセプションデッキを行っている。

である。ストーリーを満たした結果を

まずは目的を決めることが重要だ。ど

出しているか、想定した動きができて

こを目指すかが決まれば、もう心配は

いるかを検査していく。当初は自分の

いらない。僕にはアジャイルがついて

感覚と結果で判断をしていたが、途中

いるのだから。カイゼンの余地がある

からビデオを導入し客観的に判断でき

限り、翌年が僕のキャリアハイだ。

(1) 「アジャイルマニフェスト(アジャイ ルソフトウェア開発宣言) 」

への道』 (Jonathan Rasmusson、 オーム社、 2011年) (https://estore.ohmsha.co.jp/titles/97842 7406856P)

Profile プロフィール

るように改善を重ねた。 ビバふりかえり。

最後に

アジャイル再チャレンジ

 今回の趣味事例では、自分自身のマ

 4 ヵ月が経ち、アジャイルトレーニ

ネージメントとしてアジャイル手法を

ング2014シーズンが終了した。アジャ

取り入れた。難しいカテゴリであるチー

イルを学びながら試行錯誤で進めたた

ムビルディングや情報共有を気にする

め、必ずしも満足な結果ではない。常

必要がないため、適用事例としてはもっ

エスビーエス株式会社入社13年目。プロ

に順調にストーリーを消化できるわけ

とも簡単な部類だ。だからこそ、その

ジェクト主任に従事するかたわら、エスビー

ではなかった。

ようなところから始めるのも手だ。仕

 しかし、繰り返し実施することによ

事でしか使ってはいけないなんて決ま

り一つ一つ課題を克服し、新たに出た

りはないのだ。

フィードバックをストーリーに反映さ

 プロジェクトに適用するには、さま

せていく。そこには、成長という実感

ざまな外部要因が邪魔をする。僕も開

と確かな足跡が残った。そして僕はエ

発現場でアジャイルを導入しているが、

レベーターピッチで描いた選手像に確

試行錯誤の日々だ。しかし、僕はアジャ

実に近づいていた。

イルによって求める姿を実現できるこ

小林 信

KOBAYASHI Makoto

エス野球部主将・エスビーエス運動会実 行委員長(非公認)を兼務。 アジャイルとは2014年8月に出会い、以来 とりこ。好きなプラクティスはスプリント レビュー、ふりかえり、ペアプログラミン グ。アジャイル開発に取り組むうえでは、 マザーテレサの「Be careful」を肝に銘じ ています。まずは手の届くところから普及 活動!

  EM ZERO vol.09 023

emzero_vol09.indd 23

2016/05/24 12:34

「インセプションデッキ」と 「MVP開発」を用いた モダンなアジャイル開発

中川伸一

NAKAGAWA Shinichi





イルサムライ—達人開発者への道』 (Jo



ー ー







の の

能・タスクはなにか?

の目的・意義を言語化する」フレーム ワークです。10個の手強い質問に答え

 これらを整理した結果、

ることで、プロジェクトの目的・価値

201 あ の

・「価値」の提供に結びつかない機

年)で紹介されている、 「プロジェクト

し り

201

nathan Rasmusson著、オーム社、2011

るために必要な機能はなにか?

り しま

を言語化します。

・打撃 (本塁打・打点な ど) 、投球 (勝利

 インセプションデッキには「我々は

数・敗北 数など)の分析と可視化

なぜここにいるのか」という質問があ

・分析サーバーとデータベースをDocker

どのような価値を提供できるか

ります。この質問に対する筆者の答え

 プロダクト(Pythonアプリケーショ

です。言語化することで、発表する意

は「Pythonと野球で仕事をすること」

/ Ansibleで自動化 ・デモ環境(自分のPC) で動作可能

ン)の開発も徐々に進んでいたのです

義やモチベーション、参加者が持ち帰

というプロダクトが構築できれば、価

が、ここで壁にぶつかりました。一言

る価値を明確に定義し、プロダクトを

値が伝わると考えました( 2) 。

で言うと、限られたリソースの中で、

開発するうえでの基礎としました(

カンファレンス参加者と発表者(筆者)

1) 。

「MVP開発」

に対してどのような価値を提供できる かが課題であると気がつきました。



 そこで、 「インセプションデッキ」と 「MVP開発」を用いたアジャイルな開 発を行うことにしました。

「インセプションデッキ」

「インセプションデッキ」で発表の 概要を決めた後、実験用のプロダクト

ー  インセプションデッキの「やらない

(MVP:Minimum Viable Product) を

ことリスト」の質問を通じて、スコー

開発しました。インセプションデッキ

プを明確にしました。

で定義した「価値」を最小限で実現す

 特に気をつけたポイントは次の2つ

るためのプロダクトです。

です。

 具体的には、

・言語化した「価値」を最低限実現す

・ブラウザ上でPythonのコードを記

よ 「インセプションデッキ」は『アジャ

■図1 インセプションデッキの質問「我々はなぜここにいるのか?」

■図2 やらないことリスト

024 EM ZERO vol.09

emzero_vol09.indd 24

2016/05/24 12:34

述・実行可能な「IPython notebook」 を用いてアプリケーションを開発 ・pyenv・virtualenvを活用し、実行環

net/shinyorke/hackpython-pyconjp ・発表のようす (YouTube):https:// youtu.be/MBAh5qE57Hs

これから挑戦したいこと  今回はインセプションデッキとMVP

境を仮想化 ・SQLAlchemy(O/Rマッピング)、pan

  発表後もPython関連のノウハウに

開発を用いて最初のプロダクトを構築

 das(データセット)、matplotlib(グ

ついてフィードバックをいただいたり、

し、価値を出すところから始めました。

ラフ描画)などのOSSライブラリを

野球のデータ分析に関する問い合わせ

今後は、アジャイル・スクラムの知見・

活用

があったりと、多くの交流ができ、大

経験を自社サービスや開発チームに還

変充実した時間を過ごしました。 といった技術・ライブラリを活用し、 最小限かつ変更が容易なMVPを構築し ました。

アジャイル開発を実践してみて  今回の実践を通じて得た学びは次の

勉強会での検証

元したり、継続的なアジャイル推進に より、自分の夢・プロダクトを世の中 に出すことに挑戦します。  これからもアジャイルの実践者、エ ンジニアの一員として、 「アジャイル」 「動くソフトウェア」を通じて、価値あ

2つです。

るサービス・プロダクトを追求したい

 本番の11日前に開催された「Kawasa



ki.rb」 (https://kawasakirb.doorkeeper.



と思います!

の大

jp/)という勉強会で、発表練習の機会

 プロジェクトの目的や価値の言語化

をいただきました。簡単な発表を行い、

は、Webサービスや業務アプリケーショ

その場の質疑応答や懇親会での会話を

ン開発の文脈でよく語られていますが、

通じて、技術面での指摘・改善点、発

学術研究やR&Dなどの「限られた条件

表内容(データ分析)に関する疑問や

で最高の結果・価値をつくる」活動でも、

考え方、発表全体の感想といったフィー

アジャイルなアプローチ、価値の言語

ドバックをいただき、本番に向けての

化は非常に大切だと学びました。

Profile プロフィール

プロダクトと発表のブラッシュアップ に役立てました。

本番発表に臨む  MVP開発と勉強会での検証で磨いた

 Webサ ー ビ ス や 業 務 ア プ リ ケ ー ション開発における「ユーザーインタ ビュー」 「ユーザーテスト」に代わる

中川伸一

NAKAGAWA Shinichi

成果をもとに本番での発表を行いまし

モノとして、勉強会での発表を通じて

た。約60人の会議室に100人近い人々

フィードバックをもらう手法をとりまし

が集まり、大盛況のうちに終わりまし

た。

た。

 これも有効性が高く、実践しやすい

 本番発表の成果やようすは次にまと

方法だったと思います。ある程度まと

ムマスターとしてジョイン。

まっています。

まった人数からのフィードバックをも

プライベートでは野球のデータ分析と可視

らえる、発表の準備のみで即検証可能 ・野球Hack!~Pythonを用いたデータ 分析と可視化:http://www.slideshare.

と、非常にライトウェイトで実行の障 壁も少ないいい方法でした。

Pythonista /スクラムマスター。 独立系ITコンサル企業、株式会社リクルー ト住まいカンパニーを経て、2016年2月か ら株式会社ビザスクのエンジニア/スクラ

化、アジャイル開発と野球の融合をテー マに執筆・イベント登壇といった活動を行 う。趣味は野球観戦、UKロック、飲み歩き。

  EM ZERO vol.09 025

emzero_vol09.indd 25

2016/05/24 12:34

アジャイル原理主義者

アリスター・ファウラー・Mc剛 Alistair Fowler McTsuyoshi

 私はアジャイル原理主義者である。

 そこで下した結論は「マイクロソフ

したボーダーシャツを着た男が歩いて

現 在 はアジャイル を ル ーツとした、

トに内部から潜入し腐敗させる」とい

きた。彼は「てらだよしお」と名乗っ

DevOps の原理主義者である。

う戦略だ。よしこれがいい。

ていた。にこやかにしているが俺には

 はっきり言ってバズワードなのでア

  私 は 自 分 が パ ッ シ ョン を 持 て る

わかる。こいつは俺以上のクズだと。

ジャイルと中身はそんなに変わらない。

DevOpsのポジションに応募してみた。

ゲロ以下のにおいがプンプンしやがる

私はそのような “バズワード” の衣を

このポジションに応募する前に、日本

ぜ。

纏い、日々 DevOpsテロを行い新たな

側でも面接があった。出てくる面接官

 奴にはマイクロソフトへの忠誠心な

信者を獲得・洗脳するための活動をし

は一風変わっているが魅力的な人物ば

どない。現に奴のメインマシンはMac

ている。

かりだった。わかっている。騙されて

じゃないか。しかもNetBeansでJavaば

 私はSolarisで育ち、Linuxそして、素

はいけない。

かりコーディングしてやがる。

晴らしいオープンソースの世界を楽し

 人間的魅力で篭絡するのは歴史を見

 なぜNetBeansなんだ。私の想像を超

んできた。もちろん現在のメインマシ

ても常套手段じゃないか。私は計算高

えるマゾ野郎だぜ。向こうにいてる「久

ンはいうまでもなくMacである。その

く自分の憶測にある「真の目的」を秘

森」とか「パクえ」というやつも俺た

ような私からすると決して許せない存

めながら順調に面接を突破していった。

ちと同じにおいがする。奴らも私と同

在がある。それはマイクロソフトだ。

 最初の日本のポジションはクローズ

じくマイクロソフトを内部から腐敗さ

 皆さんも異論はないだろう。このよ

したが、インターナショナルのポジショ

せようとしているに違いない。

うな素晴らしいオープンソースの活動

ンに再度応募して、とうとう「マイク

 しかし、こうしてみると、私が手を

が生まれたころに、 「ホビィストへの公

ロソフト」に内部から潜入することが

下すまでもないのかもしれない。くっ

開状」という書簡を発表したのがビル・

できたのだ。くっくっく。愚かな奴らよ。

くっく。現にこの会社にはおかしな奴

ゲイツだ(http://jibun.atmarkit.co.jp/

わしの本質が見抜けないとは。これが、

らばかりが集っているじゃないか。

l jibun01/rensai/genesis/165/01.

マイクロソフトの腐敗の始まりとも知

 向こうから歩いてくる男はなぜか毎

html) 。

らず。

日着物を着ている。それに、 「クラウディ

 彼はホビィストがやっている行為が

 マイクロソフトでは「シニアテクニ

ア」さんの中の人は、本当に金髪でそ

「盗み」だと糾弾したのだ。我々が今

カルエバンジェリスト DevOps」という

のままじゃないか。まるで磔にされた 「キリスト」のような見た目のおっさん

GitHubを通じて行っている活動は盗み

ポジションについた。ハッカソンを開

なのか?それを言うなら多くの企業が

催したり、DevOps を本気で導入する

までいる。

自社のソフトウェアをGitHubで公開し

企業を支援して、世界的な事例を作る

 さらに、マイクロソフトが最も力を

て、Pull Requestを受け付ける行為こ

のが私のミッションだ。

入れているAzureというクラウドプラッ

そが労働力の「盗み」ではないか。

 会社はオープンスペースでリモート

トフォームの部長が書いているブログ

 私の脳裏にふとしたことが浮かんだ。

ワークの環境が整備されており、勤怠

は、ガンダム用語が難解すぎて、素人

2002年にアリスター・コーバーンを大

は相当自由だ。幸いなことにDockerや

にはわからないじゃないか。

阪城に案内した。そのときに、金の茶

HashiCorpやGoと戯れていてもサティ

 向こうにいるなんかよくわからない

室を見た。

アとか いう新し い 社 長 が “Microsoft

おっさんの名刺を見ると「ジニアス平

 彼は一言こう言った。 「ビル・ゲイツ

loves OSS” とか言ったものだから、怒

井」と書いてある。くっ。自分でジニ

のようだ…」そう。金だ。世の中金だ。

られないらしい。

アスなどなんという思い上がりだろう

私のようなアジャイルの殉教者にとっ

 もっとも前の社長のバルマーは、社

か。私が手を下すまでもないようだが、

ては到底許せるはずもない。私のやる

員のiPhoneを見て叩き落したらしいが

獅子はネズミをとらえるにも全力を尽

ことは一つ。 「テロ」だ。そう思い私は

な。くっくっく。

くすという。

念密な計画を立てた。

 おっと、向こうからにこやかな顔を

 私もそれに従っていい「仕事」をす

026 EM ZERO vol.09

emzero_vol09.indd 26

2016/05/24 12:34

ることにしよう。

フォームとの統合性はなかなかのも

いけない。これは幻覚作用だというのは

 私はさらにさまざまな手を尽くし、

の。負荷テストや、Azureのインフラ

わ かって いる。現 に 俺 のWindowsで

「de:code」という奴ら最大の開発者向

構成をデプロイできるAzure Resource

UbuntuとBashが 動 いている。これ が

けイベントに、私以上に下衆な寺田と

Managerもグラフィカルに簡単に作れ

幻覚でなくてなんだろう。向こうでは

共に、 「Mesosphere」 「Chef」 「HashiCorp」

るのか……。さっき作ったアプリも一

Service Fabricというマイクロサービス

「Jenkins」などのオープンソースの巨

瞬でテンプレートができてAzureにデプ

基盤が動いていて、カオスモンキー食

人を召喚した。このような大物を前に

ロイできたじゃないか。簡単すぎてア

わらせてもノードを殺してもメモリを

したら奴らはひとたまりもないだろう。

ホになりそうだ。

共有しているから処理が継続する……

私がわざわざなんの興味もない、マイ

 よくよく考えたらC#を今勉強したら、

これも幻覚だ。マイクロソフトの技術

クロソフトの技術など試すまでもない。

Webから、API、UWPというモバイル

がおもしろいなんて幻覚だ!

高みの見物で、奴らが崩壊する姿を楽

から、XBox、IoTデ バイスから、Holo

 こんなのだったら金払ったら生産性

しむとするか。

Lendsまでなんでも動くプラットフォー

上がりそうじゃないか……なに?人件

 さっきの「ジニアス平井」とかいう

ムがあるし、コグニティブサービスと

費とツールの費用はどっちが安いか

おっさんが出てきたぞ。プレゼンほと

いう人工知能のサービス群まであるの

だって……

んどないじゃないか……ってなんじゃ

で、何でも作れちゃうんじゃないだろ

 俺はオープンソースエンジニアだっ

こりゃー。

うか?

て!今はマイクロソフトのソースもGitH

  凄 い デ モ や! Kinectか ら、IoTHub

 ついでにXamarinがあるので、iOSや、

ubで公開されているだと……

そっから、PowerBIにつないでリアルに

Androidまで……

 オープンソースっていったいなんだ、

分析やと、最後にはなんか知らんけど、

 いやいやいや。騙されてはいけない。

わからなくなってきやがった。じゃあ

一緒におっさんとゲームをやることに

これが奴らの手口というのはわかって

ちょっとだけ……ちょっとだけならい

なった……60分が一瞬だ、ガチでこの

いるじゃないか。

いだろう……

人「天才」やん……

 私はDevOps担当だから、Visual Stud

 次はあのキリストみたいなおっさん

io Team Serviceとやらのクラウドサー

や。な、なんてトークがうまいんや、

ビスを触らんといかんのか。ふん。め

……まさに「神」やん……むっちゃわ

んどくさい。

かりやすい。

 これは、Kanbanとか、ビルドとか、 リリー

 まさにキリストが民衆に説教をして

スマネジメントとか、テストとかできるプ

いるかのような説得力……こんな「神」

ラットフォームだな。

を感じたのはマイケル・シェンカー以

 ん、Javaや、AndroidやiOSのアプリ

来や……

とかでもビルドできるらしいな。C#と

 この「エバンジェリスト」連中の実

Windowsだけちゃうんか。あれ、ビル

力ガチで世界一ちゃうん……

ド定義がテンプレートで一瞬で作れた。

 いやいや、騙されてはいけない。所

マジ?カバレッジも設定しただけで……

Profile プロフィール

詮マイクロソフトのツールの宣伝だろ

しかも、Azure デプロイや、Docker……

う。俺は騙されんぞ。

むっちゃ簡単やん……インフラすら自動で

 おっと私もしゃべらないといけない

構築できる……

んだった。 「社員」という扱いになって

 えー、しかも、WebAppsというAzureの

いるので、エバンジェリストとしてマ

PaaSにデプロイしただけで、Blue Green

イクロソフトの技術に触れないと怪し

Deployment とか、カナリアリリースや、ス

まれてしまうので、めんどくさいがさっ

ケールアウトパフォーマンステスト、別リ

さと片づけるか。めんどくさい。ただ

ージョンからの死活監視とかも付いとる

でさえ、Windowsを久々に触っておじ

んかいな。これなにもせんとできるんか

いちゃんのように操作がわからないと

……そして監視もマシンラーニングで予

いうのに。

測して事前通知したり、監視データも

  ふ ん。こ れ が Visual Studioか。 金

PowerBIで簡単に可視化して、おっちゃ

をざっくざくにぶち込めば多少まし

んも大満足やと……未来のようじゃない

しかわかっていない。その正体は誰に

なものが作れるだろう。しかし、この

か……

もわからないという。

インテリセンスやさまざまなプラット

 だめだ、いけない。奴らに騙されては

アジャイル原理主義者

アリスター・ファウラー・ Mc剛 Alistair Fowler McTsuyoshi

アジャイル原理主義者歴15年。最近 は、DevOpsというバズワードに身を 隠し、日々信者の獲得と普及に努め る。日本のソフトウェア業界で暗躍し 起こしたテロは数知れず。 現 在はマイクロソフトでインターナ ショナルチームに所属し、DevOps の シニアテクニカルエバンジェリストと いう職業についているという情報のみ

※編集部注:バレバレですが……

  EM ZERO vol.09 027

emzero_vol09.indd 27

2016/05/24 12:34

素晴らしいチームワークはここから生まれる アトラシアンはチー の ラ レーシ ンと



ーシ ンを

トウ ア開発で ったプラク ィスを あら るチームの リ ーシ ンに

する ールを

して



企画から計画、開発、ビルド、デプロイ、 そしてサービスの運 用といったソフト ウェア開発で培ったプラクティスを、あ らゆるチームで活用いただけます。

(ソフトウェア開発) 画 計画

ビルド





クル

ート

ンプル





(サービスデスク) か の



ーの





ービス





スク



(ビジネス) ング



ーク













ス ー

す アトラシアン . l

.co

. l

.co

を って る o

lo

アトラシアン 品は、10ユーザーまでなら 10( )でご利用いただけるスターターライセンスを 提供しています。 しくはこちらから  ja.atlassian.com/software/starter/overview  ンプレ









アトラシアン製品の詳しい情報は アトラシアン株式会社 2 1

2  合 ー 合 028 EM ZERO vol.09

emzero_vol09.indd 28

2   i n m 1

n

n

ja.atlassian.com

1 1

2016/05/24 12:34

View more...

Comments

Copyright ©2017 KUPDF Inc.
SUPPORT KUPDF