You are on page 1of 28

た。

EM ZERO 再 開 し ま し た。

EM ZERO

vol.09 2016

R O 、 再 開 し ま し た。 EM ZERO vol.09 2016 夏 EM ZERO
R O 、 再 開 し ま し た。 EM ZERO vol.09 2016 夏 EM ZERO
R O 、 再 開 し ま し た。 EM ZERO vol.09 2016 夏 EM ZERO
EM ZERO vol.09
EM ZERO vol.09

   EM ZERO vol.09

  

 01

01

R O 、 再 開 し ま し た。 EM ZERO vol.09 2016 夏 EM ZERO

EM ZERO vol.9 Contents

アジャイル開発入門  西 04

アジャイル」「DevOps」「クラウド」

言う前にすべきだったこと 

渋川よしき……………06

アジャイルコーチの7つ道具

永田 敦……………10
永田 敦……………10

ツールで理解するアジャイルコーチの役割

天野 勝……………08

アジャイル開発とレジリエンス

スタートアップの「死の谷」を

乗り越えるためのプロダクトマネジメント

橋本将功……………12

アジャイルとミリタリー

今、あらためて読む『失敗の本質』

斎藤良太……………14

思考停止の技法

大槻 繁……………16

ベトナムで技術情報誌を創刊してみた

あまのりょー……………18

ある40代男のレガシーボディ改善物語 

02  EM ZERO vol.09

02

EM ZERO vol.09
EM ZERO vol.09

懸田 剛……………20

 

 

 

なんでもアジャイルのススメ

もし草野球のおっさんプレイヤーがアジャイルを学んだら

◎株式会社マナスリンクについて

 株式会社マナスリンクはEM ZEROの運営 を目的として設立された会社です。マナスと はサンスクリット語でマインドを意味します。 良いマインドを持った人々をEM ZEROを通じ て結び付け、良い人の流れ良い情報の流れ を作り出し、ソフトウェア業界を盛り上げて いくお手伝いをいたします。

小林 信……………22

「インセプションデッキ」と

「MVP開発」を用いた

モダンなアジャイル開発

◎EM ZERO配布のお願い

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

中川伸一……………24 ◎広告出稿のお願い マイクロソフトは やはり悪の帝国である
中川伸一……………24
◎広告出稿のお願い
マイクロソフトは
やはり悪の帝国である
アリスター・ファウラー・Mc剛……………26
●編集後記
◎お取り寄せ
 久しぶりにEM ZEROを刊行することができました。急な依頼にも関わらず、快く
執筆を引き受けてくださった同志のみなさま、(まさかの)広告出稿をしてくださった
アトラシアンさん、いつもすてきなデザインを提供してくださるデザイナさん、ギリ
ギリまで無理難題を引き受けてくださる印刷会社さん、そして縁あって今本誌を手
にとってくださっている読者のみなさま、どうもありがとうございます。
 今号は通算で11号となっていました。なぜVol.9なのにそうなるのかと思い返すと、
1号の前に0号があり、3号が大きくなりすぎて3.1と3.2に分割していたのでした。次
■EM ZEROお取り寄せ
は10号記念かと思っていたら、通算10号はとっくに過ぎていたのです……
 EM ZEROはこれからもちょっとずつ続いていきますので、今後とも熱いご支援を
よろしくお願い申し上げます!
 bookをご覧ください。
EM ZERO Vol.9
2016年5月31日発行
デザイン:ミヤムラナオミ
発行元:株式会社マナスリンク
印刷所:昭栄印刷株式会社
編 集:EM ZERO編集部
〒162-0011
http://www.shoei-p.net/
 com/emfamily
東京都中野区中央3-27-11-101
http://www.manaslink.com/
お問い合わせ先:contact@manaslink.com
Copyright ManasLink
Printed in Japan

contact@manaslink.com

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

■EM ZERO広告のお申し込み

 contact@manaslink.com

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

◎EM ZEROの最新情報はTwitter/Face

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

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

「プロダクト」を「マネジメント」する 熱いみなさまのご参加を POStudy
「プロダクト」を「マネジメント」する
熱いみなさまのご参加を
POStudy
お待ちしております!
POStudy代表
詳しくは
~プロダクトオーナーシップ勉強会
関 満徳
下記まで
アジャイル開発者、
アジャイルマネージャ
必見!!!
・ ・
徹底したワークショップ中心主義!
徹底したワークショップ中心主義!
・ ・
全国各地で勉強会開催!
全国各地で勉強会開催!
・ ・
充実した資料がDL可能!→http://www.postudy.com/
充実した資料がDL可能!→http://www.postudy.com/
EM ZERO vol.09
EM ZERO vol.09

   EM ZERO vol.09

  

03

 03

アジ ャ イル開発入門 アジャイルジャパン実行委員 西河 誠 NISHIKAWA Makoto

アジイル開発入門

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

西河 誠

NISHIKAWA Makoto

西河 誠 NISHIKAWA Makoto 日本でのアジャイル開発の拡がり

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

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

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

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

 アジャイルジャパン実行委員として、 イベント立ち上げ当初から推進に関わ らせていただいていますが、この間、 日本のソフトウェア開発者はもちろん 日本の企業においてもアジャイル開発 が普及してきました。

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

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

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

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

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

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

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

1)。

 アジャイルジャパンの中で発表・議 論される内容も、最初はアジャイルと はなにかという解説や体験講座が多 かったように記憶しています。最近で は実践して取り組んだ内容の説明はも ちろん、失敗事例に至るまで、具体的 な発表が増えてきました。

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

テーマの受付が始まりましたが、最近 では応募論文がどれも興味深いもの ばかりで、実行委員会の中でも当日の タイムテーブルに入れるセッションを 選ぶのが実に悩ましいです(本当に接 戦の末選ばれていますので、選出され なかった場合もまた応募をお願いしま す!!!)。

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

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

04  EM ZERO vol.09

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

てきています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

開発投資に対して最大限のパフォーマ

ンスを出すための取り組みを考えます。

アジャイルの価値と原則

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

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

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

セスを決めています。

・価値

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

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

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

プロセスやツールよりも

   

個人との対話を

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

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

ありません。

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

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

やツールも大切だけど、

個人と対話することがもっと大事です

アジャイル開発の目的

よね

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

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

と述べています。

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

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

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

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

ます。

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

に重点を置くほうが顧客満足を得られ るという考え方になります。 ・原則
に重点を置くほうが顧客満足を得られ るという考え方になります。 ・原則

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

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

・原則  「(アジャイル開発の)原則=アジャ イル開発を進める上での行動原則」で す。顧客のビジネス価値を最大化する ために、動くソフトウェアをできるだ け短い時間感覚でリリースするなど、 ソフトウェア開発をどのように進める かの枠組みを述べています。  スクラムやエクストリームプログラ ミング(XP)などのアジャイル開発手 法は、これらの価値、原則に従って “プ ラクティス” と呼ばれる実践手法で構 成されています。  プラクティスの具体的な例として、 ペアプログラミングやテスト駆動開発 などが有名ですが、これらの取り組み もアジャイルの価値・原則に沿って行 われるプロセスのひとつです。これら のプラクティスはそれぞれの開発手法 の中で実践されるものであり、開発す る製品・サービスや、ビジネス形態に よって部分的に取り入れていくのもア ジャイルに取り組むための一歩になり ます。

アジャイル開発の第一歩

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

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

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

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

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

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

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

ゴールである「顧客価値」であると考 えています。アジャイル開発で取り組 むプロジェクトで、最初にお勧めして いる方法があります。拙書である『わ かりやすいアジャイル開発の教科書』

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

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

ンです。

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

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

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

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

てみましょう。

てみましょう。 ■写真 お客様は誰?

■写真 お客様は誰?

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

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

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

ります。

これからアジャイル開発に

取り組むみなさんへ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

す。まずはなんでも結構です。できる

ことから取り組んでみましょう!

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

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

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

inar/seminar_tokyo_20141217-02.pdf)

注2)「アジャイルソフトウェア開発宣言」

(http://www.agilemanifesto.org/iso/ja/)

注3)『わかりやすいアジャイル開発の教

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

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

html)

注4)「アジャイル開発とは:『アジャイ

ル開発』をエグゼクティブサマリにまと

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

jp/2011/08/post-41.html)

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

   EM ZERO vol.09  05

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

¦¦¦ \(‾▽‾;) / ¦¦¦ワーイ?

渋川よしき

SHIBUKAWA Yoshiki

日本企業はフットワークが鈍い?

 eXtreme Programmingが 生 ま れ て

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

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

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

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

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

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

す。

「日本企業はSIer頼みになっていてフッ

トワークが鈍い。海外(主にアメリカ)

はユーザー企業のIT部門が強く内製で

どんどんやっていける。」

 たしかに、USの技術系カンファレ ンスではユーザー企業のIT部門のメン バーが事例発表などをしています。ウォ ルマートのIT部門が大規模にnode.jsを 導入して、その中でメモリリークが発 見されてnode.jsの修正が行われたよ、 という発表が行われましたが、今か

ら2年半前の段階で、大規模採用事例

がほとんどなかったnode.jsを、小売最

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

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

ません。

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

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

あります。

IT部門はコストセンター

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

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

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

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

06  EM ZERO vol.09

コアのビジネスが別にあって、その業 務を円滑化し業務改善することで費用 を回収するのがほとんどでしょう。  ある程度の業務システムを作りこん で完成させるのに何人ぐらい必要で しょうか? 20人? 100人? 1,000人?年

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

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

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

の悪化が見込まれます。  日本の労働基準法では首にするのが 難しいので、一度雇ったら雇い続ける 覚悟が経営側には必要です。で、何人 システム部門に人が必要でしょうか? みずほ銀行の次期勘定系システムは

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

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

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

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

ん。

差別化とビジネス競争力強化を

 区別する

 受託開発の知人に聞くと、たいて い出てくるのが「競争力に直結しない 会社固有機能の開発」です。たとえ ば、昔ながらのターミナルのUIに慣れ ているので、それとまったく同じ入力 方式を新しいUIフレームワークで新規 開発するのです。Enterキーで入力欄の フォーカス移動とかそういうものです。  そのような機能の積み重ねで開発項 目数が爆発している例をよく聞きます。 既存メンバーの教育コストは削減でき ますが、新規メンバーはその特殊なUI

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

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

同じ機能を何度も再実装しなければな りません。  また世の中でよく使われるUIから離 れれば離れるほど、実装の手間は増え ます。Windows Formsデザイナーの素 組みでできるUIなら開発コストも少な く、メンテナンスのドキュメントも少 なくて済み、情報も豊富に得られます。 コード量も少なければバグも少ないで しょう。再実装のコストが大きければ、 システムリプレースのリードタイムも 伸びます。 「このUIじゃないとユーザーが嫌が る」というのはよく聞かれる言葉です が、それによる目に見えない負担の増 加は重荷となっていきます。  UIの例がわかりやすいので最初に出 しましたが、パッケージソフトの利用 という文脈でも同じです。日本はパッ ケージソフトを導入するにあたっても、 なるべく多くのカスタマイズを入れよ うとします。  UIの例と同じようにそれは差別化に なりますが、パッケージソフトベンダー にとっては効率があまり良くない開発 になります。費用対効果が悪化します し、一時的な開発なので少ない人数で 開発することになり開発期間も伸びま す。フットワークが遅くなりますよね。  差別化のために競争力が下がるとい う本末転倒な結果になりがちです。「新 システム導入の教育手当」という名目 でユーザーにボーナスを出して「シス テム側に合わせることを了承してもら う」ほうがよいように思います。 「会社固有開発」をなるべくやめる。 そうすれば新規システム導入をする場 合のピーク人数は減らせます。パッケー

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

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

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

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

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

う。

IT部門の開発競争力を増やす

 自分で開発する割合が多くなれば なるほど、世の中のシステムの進化の 恩恵を得ることが難しくなります。た とえば、UI画面をなんの工夫もない Webアプリケーションとして実装し たとします。今時のUIフレームワーク (BootstrapとかMaterial Design Lite)を 使って画面を作るとします。そうする と、スマホでもタブレットでもちょっと した調整で扱えるようになります。  ソフトウェアの世界はそういう一石 二鳥、三鳥、四鳥がたくさん転がって います。バグもどんどん直っていきま

す。1人の開発者であっても、バックに

世界中の仲間がいるのと同じです。レ バレッジが利くようになります。イン フラ周りも、多くの人が使っているツー ルを使っていけば自然とクラウド対応 が簡単になったりします。

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

す。これに対して、世界がシステムに 求める水準はどんどん上がっていきま す。自分ですべてを開発すると、相対 的に開発力はどんどん落ちていくので す。  ゲーム開発が顕著な例です。最初の ドラゴンクエストは数人のメンバーで 数ヵ月で作られたとよく書かれていま すが、その後スーパーファミコン、プ レイステーション、プレイステーショ

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

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

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

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

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

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

ほとんど増えていません。同じ金額に 対する要求がどんどん上がっています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

日本のソフトウェア開発の

 競争力を増やす

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

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

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

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

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

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

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

ます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ことができます。

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

る速度アップ。そしてそこからの競争

力アップ。今後、そういうおもしろい

事例が増えてきたらいいな、と思いま

す。

 このように競争力を上げる土壌がで

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

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

ないでしょうか?

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

   EM ZERO vol.09  07

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

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

天野 勝

AMANO Masaru

はじめに

・すでにアジャイル開発に取り組んで

(3)コーチング計画

 現場ヒアリングの結果をもとに、対

象となるプロジェクト/チームのどの

ような課題をどのように解決していく

かを計画する。ここで役立つ道具は、「利

害関係者マップ」と「ゴール分析ツリー」

「リスク分析ツリー」である。

(4)作戦会議

 コーチング計画をもとに、依頼主や

推進者と進め方を定期的に確認してい

く。ここで役立つ道具は、「ゴール分析

ツリー」「障害物リスト」「KPT」である。

 

いるが、想定している成果が出ないの

(5)現場コーチング

 「アジャイルコーチ」という名前を

でなんとかしてほしい。

 対象となるプロジェクト/チームに

耳にはするが、その役割は理解できて

対して、コーチングを行なう。ここで

いないという方が多いのではないだろ

 近年は、後者の依頼が増えている。

役立つ道具は、「リスク分析ツリー」「障

うか。本稿は、アジャイルコーチが使

また、コーチングの成果も上がりやす

害物リスト」「KPT」「チェックリスト」

用している道具(ツール)を紹介し、

い。

である。

これらの道具からアジャイルコーチの

 ここで役立つ道具は、「利害関係者

役割を知っていただくために執筆した。

マップ」と「ゴール分析ツリー」「リス

(6)状況報告

 筆者がはじめてソフトウェア開発

ク分析ツリー」である。案件の質があ

 対象となるプロジェクト/チームの

チームのコーチをしたのは、2003年の

まりにも低い場合は、要望を分析した

現在の状況と今後の課題を報告する。

ことである。それからいくつもの案件

時点でお断りすることもある。そうで

口頭の報告で済ますこともあれば、定

にコーチとして関わってきた。いまだ

なければ、依頼主の要望、実施体制、

型のドキュメントを用意することもあ

に手探り状態ではあるが、その中でも

スケジュール、費用を提案書の形にま

る。予算に余裕のある依頼主の場合、

効果を感じている道具を7つ紹介する。

とめて提出する。

ドキュメントを求められることが多い。

 提案を受け入れてもらえれば、契約

ここで役立つ道具は、「障害物リスト」

アジャイルコーチ案件のプロセス

手続きとなる。機密性の高いプロジェ

と「KPT」「チェックリスト」である。

 道具を紹介する前に、アジャイルコー

クトの場合は、要望を具体的に聞く前

に秘密保持契約(NDA)を結ぶことも

アジャイルコーチの7つ道具

チとして案件に関わる際の流れを整理

ある。

する。

 筆者が活用している道具の概要を紹

 

(2)現場ヒアリング

介する。表1にアジャイルコーチの7つ

(1)要望の確認/提案

 対象となるプロジェクト/チームの

道具を整理した。

 まずは、依頼主のもとに赴き、要望 を確認する。その後、要望を分析し、

メンバーと利害関係者にヒアリングを する。ここで役立つ道具は、「利害関係

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

提案する。アジャイルコーチとして関

者マップ」と「ヒアリング項目」である。

 対象となるプロジェクト/チームを

わる案件は、主に次の2つの要望に分

利害関係者マップをもとに、誰にヒア

中心に、取り巻く利害関係者を1枚の図

類される。

リングするか計画し、1人ずつヒアリン

で表したもの(図1)。インセプション

グを行なう。1人のヒアリング時間は45

デッキの「ご近所さんマップ」やSSM

・これからアジャイル開発を始めるに

分としているが、話がなかなか終わら

の「リッチピクチャ」に相当するもの

あたり、不安があるので一緒に進め方

ない場合も多く、余裕をもって90分の

と考えていただきたい。

を考えて、成果が出るまでフォローし

インターバルでスケジュールを組んで

てほしい。

いる。

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

■表1 アジャイルコーチの7つ道具

 

要望の確認/提案

現場ヒアリング

コーチング計画

作戦会議

現場コーチング

状況報告

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

○ ○

 

     

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

 

○ ○

 

   

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

 

○ ○

   

 

道具その 4:障害物リスト

     

道具その 5:ヒアリング項目

 

       

道具その 6:KPT

     

道具その 7:チェックリスト

       

08  EM ZERO vol.09

 アジャイル開発によってなにを達成 したいのか、達成するにはなにがで きるようになるかをツリー状に細分化 し た も の。OKR(Objectives and Key

Results)の考えが参考になる。

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

 リスクごとに、そのリスクを発生さ

せる要因をツリー状に細分化したもの

図2)。このツリーを使って、どのよう

A社 B社 兼務 C社 ○○さん ○○さん ○○さん PM 事業部長 リーダー ○○さん
A社
B社
兼務
C社
○○さん
○○さん
○○さん
PM
事業部長
リーダー
○○さん
○○さん
○○さん
○○さん
課長
開発者/バッチ 開発者/バッチ 開発者/バッチ
○○さん
PO
○○さん
D社
担当
兼務
○○さん
○○さん
○○さん
○○さん
○○さん
開発者/インフラ
開発者/DB
開発者/アプリ
開発者/アプリ
リーダー
開発者/アプリ
兼務
○○さん
○○さん
○○さん
○○さん
開発者/アプリ
開発者/テスト
開発者/テスト
アーキテクト

■図1 利害関係者マップ

ユーザー内で 作業を 要件が 要件の合意が やり直す 変更になる とれていない 作業が
ユーザー内で
作業を
要件が
要件の合意が
やり直す
変更になる
とれていない
作業が
作業が
合意の会議に
二人で
遅れる
難しく
参加する
作業する
納期に
時間がかかる
間に合わない
少し着手して
作業の着手が
かかる工数が
工数を見積る
遅れる
わからない
納期を延ばす
バッファ込みで
有識者に
交渉をする
計画する
見積ってもらう
作業の途中で
割込みを
割込みが入る
断る

■図2 リスク分析ツリー

な対策を打つかを検討する。

 要望を確認する際には、案件として

のゴールを達成するのに、どのような

阻害要因が潜んでいるかを分析する。

コーチング計画を立案する際には、ア

ジャイルコーチとして現場のゴールを

達成するのに、どのような阻害要因が

潜んでいるかを分析する。この段階で

は、コーチだけで行なうのではなく現

場メンバーを中心にリスクを洗い出し、

その対応策も、現場メンバーと一緒に

考えていく。

(4)道具その4:障害物リスト

 ゴール達成の障害となるモノ・コトと

その解決策・解決状況を一覧にしたも

の。コーチの第三者としての立場から、

客観的に障害物を特定し、障害物ごと

に解決策を決め、適宜、解決状況を更

新していく。

(5)道具その5:ヒアリング項目

 現場メンバーにヒアリングをする際

の質問リスト。依頼主の要望をもとに、

どのような現場なのかを推測し、障害

物を見つけやすいように質問内容をそ

の都度アレンジする。

(6)道具その6:KPT

 Keep、Problem、Tryの観点で物事を 整理する思考フレームワーク。プロジェ クト/チーム状況の推測や、現場メン バーとのコミュニケーションに活用す る。また、現場メンバー自身がチーム を改善する際のアクションを考え出す のに活用するなど、適用範囲はとても 広い。  KPTについては、拙著『これだけ!

KPT』(参考文献1)を参考にしてほしい。

(7)道具その7:チェックリスト

 コーチがプロジェクト/チームの行

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

 主に以下の3種類を使っている。

・朝会チェックリスト(表2)

・ふりかえり会チェックリスト(KPT用)

・チーム状況チェックリスト

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

文献2)をもとにしている。

【ルールの共有】

1 朝会のグラウンドルールを

明文化している。

2 朝会の進行(アジェンダ)を

明文化している。

3 実施時間が決まっている。

4 参加者が決まっている。

5 司会者をローテーションしている。

【場の設定】

6 メンバーが輪になって集まれる場で行なっ

ている。

7 チーム状況を可視化している。

【全員の振る舞い】

8 開始時間に全員集まっている。

9 立って行なっている。

10 開始と終了に挨拶している。

11 チーム全員に聞こえるように話している。

12 今日やることの工数を見積もれている。

13 些細な問題点も話している。

14 他の人の発言を聞いている(聞き流し ていない)。

15 短時間(最大15分)で行なっている。

16 問題を深掘りしすぎない。

17 二次会の要/不要をチームと合意してい

る。

【司会者の振る舞い】

18 発言しやすい雰囲気づくりをしている。

19「問題ありません」を見逃さない。

20 ルール違反を伝えている。

【リーダーの振る舞い】

21 朝会を行なう目的をチームに伝えている。

■表2 朝会チェックリスト

おわりに

 筆者がアジャイルコーチとして関わ る際に使用する道具の中で、有効性を

感じている7つを紹介した。道具そのも

のに、コーチとしての仕事内容が反映

されていると考えていただきたい。

 これら道具の特徴から、アジャイル

コーチがどのような役割を果たすのか

アジャイルコーチ像をイメージし、今

後、アジャイルコーチを採用する際や

アジャイルコーチを目指す方の役に立

てれば幸いである。

■参考文献

(1)『これだけ!KPT』(天野 勝、すばる

舎、2013年)

(2)「プロジェクトファシリテーション実

践編 朝会ガイド」

(平鍋健児、天野 勝、オブラブ、

http://objectclub.jp/download/files/

pf/MorningMeetingGuide.pdf)

Profile ロフィール

株式会社永和システムマネジメント コンサルティングセンター センター長 天野 勝 AMANO
株式会社永和システムマネジメント
コンサルティングセンター センター長
天野 勝
AMANO Masaru
オブジェクト指向、アジャイル開発、
開発現場の活性化をテーマに、ファ
シリテーションを活用したコンサル
ティング、セミナーに従事。

   EM ZERO vol.09  09

アジャイル開発とレジリエンス

レジリエンス

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

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

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

話しします。

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

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

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

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

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

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

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

とあります。

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

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

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

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

この変化を受け入れるには、どのように行

動したらよいでしょうか。

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

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

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

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

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

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

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

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

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

永田 敦

NAGATA Atsushi

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

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

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

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

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

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

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

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

サポートできるのか?

お話しの前提

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

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

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

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

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

す。

最初のバージョン

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

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

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

魂2015』(参考文献1)でお話ししたスク

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

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

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

てくると推測されます。

ソフトウェアは変化で劣化する

 ソフトウェアはハードウェアとは異な り、劣化しないと言われます。ハードウェ

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

なバスタブ曲線を描きます。時間の経過 に伴い、あるときから劣化するのです。

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

す。初期に起こるバグを直していけば、そ の後は単発的なバグはあったとしても劣 化はしないというのが、理想的な曲線です。  しかし実際は、ソフトウェアも劣化しま す。リリース後に、変更が行われるためで す。変更すると新たな不具合が混入する

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

合による故障率の増大」のように上昇し、 ソフトウェアを劣化させます。定常状態の 故障率になる前に次の変更が必要になり、 それが曲線を上昇させます。そして、徐々 に故障率の最小値のレベルが上がってい きます。つまりソフトウェアは変更により

悪化するのです(参考文献2)。

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

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

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

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

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

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

初期故障 劣化 故障率
初期故障
劣化
故障率

010  EM ZERO vol.09

時間

■図2 ソフトウェアの故障率曲線 新たな不具合による 故障率の増大 故障率 変更
■図2 ソフトウェアの故障率曲線
新たな不具合による
故障率の増大
故障率
変更
実際の曲線
理想的な曲線

時間

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

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

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

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

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

要求が出てきます。

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

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

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

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

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

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

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

かかります。

効率化のリスク

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

タスク配分できれば効率的です。ですが

変更は、ある特定の機能、特定のモジュー

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

ルを担当する開発チームメンバー(ある意

味でドメインエキスパートと呼んでもよい

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

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

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

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

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

す。

①変更前の仕様の理解不足によるリスク

…仕様レベルの欠陥、仕様の漏れ

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

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

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

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

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

でしまいます。

②プログラム構造の理解不足によるリス

ク…デグレの発生、プログラム構造が壊

れる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

てしまいます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「他人のコード(プログラム構造)を理解

する」

 これは、ふりかえりのとき、一人の若手 メンバーがTryで出したものです。そのと きは、これがチームのレジリエンスを高め るとは思っていませんでした(そもそもレ ジリエンスを意識していませんでした)。 「他人のコードを理解すること」は、『組

織パターン』(参考文献3)でも「トラック

ナンバーはほどほどに」で述べられていま す。トラックナンバーとは、組織内で、ド メインに関する重要な知識を唯一持つ人 の数です。万が一、そのような人がトラッ クに轢かれたら、彼の持つ重要な知識は 使えなくなります。トラックナンバーが大 きいということは、そのような唯一のエキ スパートが多くいる組織ということです。 彼らは、ずっと長い間、特定の機能やモ ジュールを担当し、知見をものすごく貯め ています。その機能のことは任せておけば、 とにかく早く的確に片付けてくれます。こ のようなエキスパートが何人もいれば、開 発は早くなります。

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

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

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

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

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

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

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

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

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

したからです。

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

くなる可能性があります。まだ余裕のある

今のうちにやるべきでしょう。さて、どう

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

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

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

まとめ

 アジャイル開発のレジリエンスを高める には、トラックナンバーを減らす活動が必 要です。QAオジサンがなぜこんなことを 考えているのか、それは、仕様の理解不足、 プログラム構造の理解不足がバグを生ん でおり、その情報をQAが捉えられないと QAのテストでも漏れてしまうからです。  この活動にチャレンジしなければ、最初 は品質の高いきれいなプログラム、バー

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

したレガシーコードになってしまいます。

だからこそ、このパターンの知見を生かし

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

■参考文献

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

ルジャパン2015小冊子、2015年)

(2)『実践ソフトウェアエンジニアリン

グ—ソフトウェアプロフェッショナ

ルのための基本知識』(ロジャー・

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

2005年)

(3)『組織パターン』(ジェームズ・O・

コプリエン、翔泳社、2013年)

Profile ロフィール

ソニー株式会社 IP&S 品質保証部門 システムクオリティ部
ソニー株式会社
IP&S 品質保証部門 システムクオリティ部
品質エンジニアリングマネージャ
永田 敦
NAGATA Atsushi
業務用システムおよび製品の品質保
証、特にソフトウェア品質の改善に従
事。得意技は、ステルスモードでアジャ
イルチームに潜り込むこと。通称「ア
ジャイル好きな QA おやじ」。

   EM ZERO vol.09  011

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

スタートアップの「死の谷」を

乗り越えるためのプロダクトマネジメント

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

橋本将功

HASHIMOTO Masayoshi

 スタートアップとは「アイデアの製品化」 によって急速な事業成長を目指す試みの ことですが、実現するには少ないリソー スで適切な製品開発を行う必要があり ます。多くのスタートアップがシード期の 「死の谷」でアイデアを実現する前に倒れ てしまう中、どうやってMVP(Minimum Valuable Product)を製作し、ビジネス 開発のフェーズに移行させればよいので

しょうか。弊社の4年間の経験から得た

知見を紹介します。

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

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

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

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

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

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

響します。

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

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

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

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

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

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

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

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

という考え方です。

②「プロダクトのブラッシュアップ」

フェーズ

戦を展開する国内大企業が参入する可 能性もあるでしょう。  事業アイデアの選択は自分たちの競 争環境と収益構造にも反映され、大き な時価総額を見込める企業になれるか という将来性にも影響します。  このように事業アイデアの軸をオリ ジナルとするか、他者の模倣をベース とするかは極めて重要なポイントです。 そして、その判断に伴う「アイデアの 革新性と必要なリソース」のジレンマ を乗り越えるには、適切な製品開発の マネジメントが求められます。  弊社の経験では、事業アイデアをビ

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

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

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

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

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

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

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

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

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

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

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

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

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

が多いでしょう。

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

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

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

非エンジニアを含む複数人のチームで

は「クリティカルパスマネジメント」

が適切だと考えています。チームで常

にプロジェクトの状況を共有し柔軟性

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

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

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

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

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

フェーズです。

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

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

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

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

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

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

られる品質基準」と「ビ

られる品質基準」と「ビ

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

012  EM ZERO vol.09

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

■図2 弊社プロダクトのブラッシュアップ

フェーズ。初期α版からβ版までのタスク

を可視化している

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

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

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

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

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

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

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

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

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

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

③「プロダクトの製品化」フェーズ

事」を片付けていくことが可能となる ため、スクラムを実施できるようにな

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

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

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

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

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

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

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

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

です。

経営課題としての「技術的負債」を

 MVPを製作したら、プロダクトの品 質を「世の中に出せるレベル」に持っ ていき、課金システムなどのビジネス 上の要求を組み込んでリリースするこ とが目的となります。  このフェーズに入れば、アイデアは 多くの人に理解してもらえる状態にな るため、資金調達も以前のフェーズよ りはスムースに進めることができます。 日本のベンチャーキャピタルや政策金 融公庫の担当者は、製品開発のプロで あることが少ないため、事業アイデア や製品の理解を得るには、この段階ま で持っていくことが必要なことが多い のです。 「新しいモノをつくる」ことは、それ 自体がエンジニアやデザイナーなど多 くの専門家にとってモチベーションに つながる営みですが、製品化のフェー ズでは細かいバグ取りやUI / UXのブ ラッシュアップが必要です。資金調達 を行い、稼働を確保することで、これ らの「つまらないけど大事な大量の仕

どう解消するか

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

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

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

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

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

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

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

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

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

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

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

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

タートアップ経営者が不要な開発コス

トとして認識し忌避してしまいます。

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

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

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

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

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

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

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

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

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

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

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

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

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

う。

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

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

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

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

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

ば幸いです。

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

   EM ZERO vol.09  013

アジャイルとミリタリー

今、あらためて読む『失敗の本質』

スクラムのルーツ

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

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

ごしでしょうか?

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

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

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

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

ています。

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

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

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

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

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

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

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

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

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

1984年における賢者達の預言

 ということで、ここでは、スクラムの生 みの親、野中郁次郎らがグループで著し た『失敗の本質』をあらためて引っぱり出

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

かなるものであったか、読み返してみま しょう。  執筆者一同を名乗る彼らが何を書きた かったのかは、序章「本書のねらい」にあ ります。  要約すれば、“軍隊とは、近代的組織、 すなわち合理的・階層的官僚制組織の最 も代表的なものである。しかし日本の軍隊 という組織は、戦争というその使命を果 たすべき状況下で、しばしば合理性と効 率性とに相反する行動を示した。それは 組織的欠陥であり、日本を代表すべき組 織が欠陥を発現させたのであれば、同様 の特性が他の日本の組織一般にも共有さ れているのではないかと疑われる。大東 亜戦争における日本軍の作戦失敗例から、 その組織的欠陥をあらわにし、現在への 教訓とする。” とのことです。  そうです、今あなたが、読者の皆さまが 所属しているのは、日本の組織じゃないで すか?その組織は、日本軍と同様の欠陥を 持っていたりしませんか?

014  EM ZERO vol.09

014

EM ZERO vol.09
EM ZERO vol.09

斎藤良太

SAITO Ryota

6つの事例

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

上げています。ノモンハン、ミッドウェー、 ガタルカナル、インパール、レイテ、沖縄 と、果てしなく憂鬱になる名前が並んでい ます。それぞれの事例について詳しくは、

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

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

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

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

まま失敗しました。 す。 失敗の分析 行を許します。
まま失敗しました。
す。
失敗の分析
行を許します。

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

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

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

略を見ていきましょう。  まず、ノモンハン。そこでの失敗は、あ いまいな目的、コミュニケーション不全、 独善的な情報解釈、過度の精神主義、を 原因として取り上げています。

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

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

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

遠く離れたモンゴルと満州の間の国境で、 大日本帝国陸軍とソ連赤軍が断続的に戦 闘を繰り広げた軍事衝突です。ソ連崩壊 後、最近の研究では「日本負けてなかっ た論」の声が大きくなっているようですが、

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

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

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

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

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

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

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

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

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

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

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

死じゃないですよ、自決ですよ。  続いて、ミッドウェー。こちらは二重の 作戦目標、複雑な部隊編成、そして不測 の事態が発生した時の対応に大きな問題 があったとしています。

こうしたあいまいな、目的の明確でない作

戦がしばしば実施されました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

新型空母が続々と就役すると、もうマトモ な戦いにはなりません。日本艦隊が一方的 に負けるだけです。

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

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

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

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

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

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

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

を失う大損害を被り、太平洋における主導 権をも失いました。

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

力の逐次投入、日本の陸軍と海軍はバラ バラの状態で戦い、さらに米軍の新機軸、 水陸両用作戦に対処できませんでした。

 4つ目はインパール。しなくてもよかっ

た作戦。合理性を欠き、人間関係を過度

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

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

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

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

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

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

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

て国境を越えて攻撃するのは、事件が大

きくなるから絶対にやっちゃダメ、という

もの。

 ところが、この「ノモンハン国境事件処

理要綱」は腹案で、正式に関東軍に命令

はされませんでした。命令にはしないけど、 こういうのを作ったんだから「察して」ほ
はされませんでした。命令にはしないけど、
こういうのを作ったんだから「察して」ほ
しいという、国軍の運営にはありえないよ
うな意思疎通がまかりとおります。関東軍
は独断で、盛大に越境航空攻撃をかけて
戦果をあげます。一撃加えた後も攻撃を
続けます。
 関東軍参謀が電話で大本営に戦果報告
すると、大本営サイドは「ちゃんと命令し
なかったのは、関東軍の地位を尊重して、
自発的に中止させようとしたのに、関東軍
は大本営の意中を無視して強行し、大本
営の信頼を裏切った」と非難し、関東軍サ
イドは、「決死の大戦果に対し、第一線の
心理を無視しなにが大本営だ」と反発しま
した。
 こんなことをしていたら、ソ連の大兵力
による砲撃で負けてしまいました。
 ミッドウェーでの作戦目的もあいまいで
す。ミッドウェー島を攻略するのか、敵艦
隊を撃滅するのかはっきりしない。
 レイテでの作戦目的も不統一。大本営
の目的は、レイテ湾に艦隊を突入させて、
そこにいる輸送船団をたたきのめす。実際
に艦隊を指揮する現場の目的は、敵艦隊
を撃滅して死に花を咲かせる。中央と現場
の意思疎通は不十分としか言いようがあり
ません。
 沖縄戦でも同じ。大本営は航空決戦を。
現地第三十二軍は地上戦闘による長期持
久戦を。
 日本軍の思考方法は、現実から出発し、
はなかったから。「自己革新組織」とは、
状況ごとに、ときには場当たり的に、対応
環境に対して自らの目標と構造を主体的に
し、それらの結果を積み上げていく方法で
変えうる組織です。
す。これは、客観的事実の尊重とその行
 あなたの組織は、自己革新能力を持っ
為の結果のフィードバック、一般化が頻繁
ていますか?
に行われる限りにおいて、とりわけ不確実
な状況下できわめて有効なはずです。
 最後に一言。
 ううむ、何かの方法論に似ているぞ。「ふ
りかえり」は重要ですね。
「ガルパンはいいぞ」
 ところがぎっちょん、日本軍にあったの
は客観的事実の把握ではなくて、主観の、
自分の思い込みによる戦略策定でした。日
■参考資料
本軍の戦略策定が、状況変化に適応でき
なかったのは、組織の中に論理的な議論
『失敗の本質』
ができる制度と風土がなかったことに原因
(戸部良一、寺本義也、鎌田伸一、杉之
が求められます。山本七平は、日本軍の最
尾孝生、村井友秀、野中郁次郎 著、中
大の特徴は「言葉を奪ったことである」と
公文庫)
指摘しています。
『アメリカ海兵隊』
(野中郁次郎 著、中公新書)
 戦略策定を誤った場合、作戦がうまく
『彗星夜襲隊』
いかない場合でも、それを修正する行動
(渡辺洋二 著、光人社NF文庫)
である「中止」や「撤退」は、決定的局
『スクラム』(Jeff Sutherland著、早川書房)
面を迎えるまで、できませんでした。
『スクラム』(松瀬学 著、光文社新書)
 さらに、日本軍という組織は、「日本的
『新・スクラム』(松瀬学 著、東邦出版)
集団主義」に立脚していると論じています。
『カンバン仕事術』
それは、組織目標と目標達成手段の合理
(Marcus Hammarberg, Joakim Sundén著、
的、体系的な形成選択よりも、組織メンバー
オライリージャパン)
間の「間柄」に対する配慮を重視する主
義です。それは、組織の意思決定を手酷
く遅らせることにより重大な失敗をもたら
します。
 
 結局、日本軍はインパールも含む6つの
あなたの組織の意思決定は
事例すべてについて、作戦目的に対する
十分に早いですか?
Profi
le
プロフィール
全軍的一致を得ることに失敗しています。
 
 さらに、人事において、日本軍は結果よ
あなたの組織は目的が明確ですか?
りも、「やる気」を重視しました。攻撃、侵攻、
突撃を主張する人たちは、作戦が失敗し
 だいたい、米軍と戦争を始めて、どう
ても責任はあいまいに、いったん左遷され
やって終わらせるつもりだったんでしょう
ても再び中央に戻されました。
かね?
 が、撤退や中止や持久を進言する人た
 日本軍の戦略決定には、一定の原理や
ちの多くは、罷免、予備役編入などの処
斎藤良太
論理に基づくというより、多分に情緒や空
分を受けました。どうしてこうなったので
SAITO Ryota
気が支配する傾向があると断じています。
しょうね。
科学的とは言い難い、「やればできる」と
信じる力、主観で作戦を立てているわけ
では、どうしてこうなったか
です。あなたの組織は、アイドルマスター
のオープニングみたいなこと、言っていま
 詳しくは本書第3章を読んでもらうとし
1961 年生まれ。2000 年より 2014 年
にかけて開催された仮想戦記コンベ
ンション IFCON の事務局を運営。そ
の傍らプログラマとして、駅やら空港
やら工場やらのシステム開発に従事す
る。趣味はフットボール観戦と計算尺。
埼玉県在住。
せんか?
て、結論から言えば、「自己革新組織」で
  
   EM ZERO vol.09
EM ZERO vol.09
 015
015
株式会社一(いち)代表取締役社長 大槻 繁 OTSUKI Shigeru 学際的アプローチ

株式会社一(いち)代表取締役社長

大槻 繁

OTSUKI Shigeru

大槻 繁 OTSUKI Shigeru 学際的アプローチ
大槻 繁 OTSUKI Shigeru 学際的アプローチ
大槻 繁 OTSUKI Shigeru 学際的アプローチ

学際的アプローチ

 最近、「学際(interdisciplinary)」と

いう言葉が気になっている。異なる学

問領域にまたがることを意味している

らしい。新しい製品・サービスを生み

出すということは、それを支える理論・

技術は、既存のものでは済まなく、新

しい世界、境界領域に広がっていかざ

るをえない。

 ソフトウェアエンジニアリングは、

学問領域として発祥して半世紀程経っ

た。ソフトウェアに関する原理・方法論・

技法・ツールは、それなりに進歩・成

熟し、ソフトウェアによって我々の社

会を豊かにし、富をもたらしてきたと

いえる。

 仕様が明確になったとき、それをコ

ンピュータプログラムで実現すること

によって解くにはどうしたらよいかと

いうことが、ソフトウェアエンジニアリ

ングの中心的な問題設定だった。しか

し、ソフトウェアが社会に溶け込んで

(dissolving)いくにしたがって、ソフト

ウェアの使い方、さらには、新しい要

求を策定し、新たなソフトウェア社会

を構築していくにはどうしたらよいか

というところが探求の中心になってき

ている。

ている。 アーキテクトの思考

アーキテクトの思考

 「アーキテクト」と呼ばれる人々が 行う「思考」は、このような学際的も

のに違いない。そこで、図1に示すよう

に、ソフトウェアエンジニアリングを 取り巻く学問領域に目を向け、「ソフト ウェア」+「デザイン」+「システム」

の3つの領域を統合する試みを行って

いる。とりあえず「〇△思考」と題して、

デザイン論 心理学 記号論 人間工学 哲学 デザイン思考 共感・創造 エスノグラフィー
デザイン論
心理学
記号論
人間工学
哲学
デザイン思考
共感・創造
エスノグラフィー
芸術・美
言語学
記号
文化
パターン
意味
社会理論
情報学
全体
検証
概念・計算
社会
コミュニケーション
言語・記述
複雑系
オートマタ
大規模・複雑性
変化・進化
ソフトウェア思考
自然・生命
組織
ソフトウェア科学
進化論
システム思考
ソフトウェア工学
システム工学
システム科学
経営学

016  EM ZERO vol.09

■図1 学際的アプローチによる統一思考

それぞれの領域の思考方法の特徴を把

握するところからアプローチしている。

 デザイン思考は、工業製品やクラフ

ト(工芸品)に見られるように、芸術

的要素や美しさの追求、システム思考

はハードウェア・ソフトウェアなどを

含む大規模で複雑な世界を扱う。で

は、ソフトウェア思考はなにかというと、

最終的にはコンピュータ上で実行され

るものを扱うので、計算や、それに伴

う概念が中心課題となる。

う概念が中心課題となる。 コミュニケーションの定義

コミュニケーションの定義

 このような探求では、必然的に今 まであまりお付き合いしたことがない 研究者・実務家などとやりとりしな くて は ならな い。 △×BoK(Body of Knowledge)と呼ばれている標準知識 体系も、山のように提唱されていて、 勉強するだけで一生終わってしまいそ うな感覚である。  そこで、はたと気づく。異種文化の 交流、学際的アプローチとは、コミュ ニケーションはとるけれども、すべて を理解できないし、理解する必要もな い。アジャイルプロセス協議会の知働 化研究会(ソフトウェアの知の働きを 探求する研究会)では、「知のフリマ」 という知を持ち寄って交換する蚤の市 を時々開催している。原理は簡単、

2に示すように、コミュニケーションの

定義を、なにかを伝えるということで

はなく、「お互いに学習・成長するプロ

コミュニケーション お互いに学習するプロセス フィードバック 成長 フィードバック 成長

コミュニケーション

コミュニケーション お互いに学習するプロセス フィードバック 成長 フィードバック 成長

お互いに学習するプロセス

お互いに学習するプロセス フィードバック 成長 フィードバック 成長

フィードバック

成長

フィードバック

成長

セスである」と変えるだけでよい。

 男女の仲を考えてみるとわかりやす

い。しょせんお互いにすべてを理解で

きるということはないが、切磋琢磨し、

刺激し合うことによって、成長してい

く。これが全体として、(人生を)豊か

にしていくことに繋がる。

 古くからあるソフトウェア開発にお

けるユーザ・ベンダ関係の間にもコミュ

ニケーションが成立していなくてはな

らない。ユーザはベンダの開発専門家

としての世界すべてを知ることはでき

ないし、逆に、ベンダはユーザのこと

をすべて掌握することはできない。往々

にして、「お互いに学習するプロセス」

であることを忘れ、成長もなく、「ハラ

スメント」に陥ってしまうことが散見さ

れる。

れる。 蛸壺化の処方箋

蛸壺化の処方箋

 最近読んだ書籍『サイロ・エフェクト』 (リジアン・テッド著)では、社会・大 企業が凋落するのは専門や事業領域ご とに蛸壺化してしまうからだという主 張が印象的だった。  同様の指摘は、『プラグマティズムの 作法』(藤原 聡著)にもある。プラグマ ティズムの格率(格言)によると、「対 象の概念を明晰にとらえようとするな ら、その対象の効果を考察せよ。すると、 この効果についての概念は、その対象 の概念と一致する」。  専門領域分化の処方箋として述べる ならば、「自分のやっている研究・製品・ サービスなどが、専門外の人々にとっ て、どのような利用・活用法があるか を常に考えよ」ということだ。簡単な ことだが、なかなか難しい。専門化す ることがいけないのではない!専門領 域が、その外部でどのように利用され るかを常に考えなくてはならないのだ。

■図2 コミュニケーションとは?

思考停止の原理■図2 コミュニケーションとは?  人間、すべてを理解・思考すること

 人間、すべてを理解・思考すること

はできない。どこかで「思考停止」し

なくてはならない。我々は、教科書に

書いてあることは、自ら確かめること

なく正しいと信じる。数学の定理、物

理や化学の法則など、すべてを自分で

証明し、実験することは不可能である。

 思考停止の原理は、「権威」によって

いる。背景に、専門家による検討とレ

ビューという社会的なしくみに支えら

れているから、ある程度正しいと信じ

られることになる。学会の査読制度は、

論文の読者にとって、追試や反証の余

地があるかもしれないが、少なくとも

次のステップに研究を進めていくため

の命題については、思考停止して受け

入れてよいことを保証している(だと

よいが)。

 BoKは、専門分野の研究やそれらを

支える諸概念がまとめられ、編纂され、

レビュープロセスを経て公開される。

これも知に関する社会的なしくみのひ

とつである。ただし、科学論文よりは

ゆるいプロセスなので、盲目的に信じ

ることができないものも多い。すなわ

ち、権威が薄れていることもあり、全

てを信じることができるほど、思考停

止可能ではない。

正しい思考停止の技法止可能ではない。  ここで述べておきたいのは、「正しい

 ここで述べておきたいのは、「正しい

思考停止」の方法である。高度専門化

社会では、それぞれの専門領域を深掘

りしつつ、その知見の他領域での利用・

活用方法を常に意識しなくてはならな

い。そして、その利用・活用法の探求は、

お互いに学習するプロセスとしての「コ

ミュニケーション」が成立するように

しなくてはならない。この状況が保た

れるときにのみ、思考停止を行っても

かまわない。  曖昧模糊としたキーワードを羅列し てコミュニケーションがとれたと誤解 する人が多い。「システムをIoT活用で 得られたビッグデータとディープラー ニング推論によってリアルタイムマネ ジメントを可能にする」といったポス トモダン表現は、おそらく、なにも伝 えていないし、これを発した人も聴い た人も、なにも学習することもできな

い。〇△思考で掲げた3つの領域間で

とくに注意すべきなのは、「システム」

「モデル」「設計(design)」といった用

語が、多義的であったり、矛盾した用

法になっていたりすることが多いこと

である。

 優れたアーキテクトと呼ばれている

人々は、大規模・複雑なものを扱う場

合でも、専門領域の構成、タイムスケー

ル上の変貌などを予見し、どこで思考

停止すべきかを、自らの意思で決定で

きる能力を持っているというのが、筆

者の現時点の仮説である。

 さて、あなたの周りに、思考停止の

達人は、見当たりますかな?

Profile ロフィール

株式会社一(いち)代表取締役社長 大槻 繁 OTSUKI Shigeru アジャイルプロセス協議会
株式会社一(いち)代表取締役社長
大槻 繁
OTSUKI Shigeru
アジャイルプロセス協議会 フェロー
知働化研究会 運営リーダ
実践的ソフトウェア教育コンソーシア
ム 理事
ソフトウェアアーキテクト協会 発起人

   EM ZERO vol.09  017

あまのりょー AMANO Ryo
あまのりょー
AMANO Ryo
あまのりょー AMANO Ryo  こんにちは、あまのりょーです。久しぶりのEM ZEROとい

 こんにちは、あまのりょーです。久しぶりのEM ZEROとい うことで原稿を書く機会を頂いちゃいました。ありがたいこ とです。  私は以前、EM ZEROでは「私のテキトー読書術」という 連載を持っていたのですが、今回は本を読むほうではなく出 すほうについて書いてみようと思います。まぁ、お付き合い ください。

つつ、こちらからは「さまざまなプロジェクトをこなしてき

た経験」を提供することでプロジェクトを成功させたい、と

私は表現しました。

自分たちで勉強する風土が定着しない

ベトナムの会社と一緒に仕事

 さて、私は昔DevLove やデブサミで「MY JOB WENT TO VIETNAM?」というタイトルでベトナムの会社と一緒に仕事 をした(いわゆるオフショア開発)の話をしたことがあります。 ひょっとしたら聞いてくださった方もいるかもしれません。  私がその担当をしたのは 2010年9月から1年ほどで、以後 は別業務にアサインとなり、ベトナムとは離れてしまいまし た。しかし、私の所属会社としてはその後も継続的にそのベ トナムの会社(表記が冗長なので、以後 F社と書きます)と 一緒にプロジェクトを執り行ってきています。

 5年も協業が続くと、私が立ち上げた当初の、規模がそこ

までではなかったころには見えにくかった課題が目立つよう

になってきたのです。そこで、弊社では単一のプロジェクト

ごとに担当者が付くのに加えて、半常駐に近い形でベトナム

に住んで取り組むPMO役の人間もアサインし、F社と共同で

総合的に戦略を練る方策に出ました。それがアサインされ

たのは、F社との協業開始当初から関わっていて(もちろん

私が事例発表したプロジェクトも一緒に手伝ってもらいまし

た)、現地のメンバーからの信頼も厚いNさんです。

 ビジネス上パートナーとなる、ということは(単にヘッド

カウントや単価だけではなく)なにがしか補完関係があって

こそ長続きするのだと私は確信します。それを事例発表の場

では、彼らからは「溢れるようなモチベーション」をもらい

 さて、Nさんはいわゆる PMO的な活動をしながら、課題の 本質の考察を行いました。ここで着目したのは、自分たちで いろいろと勉強したりする風土がなかなか定着しないところ です。  NさんはHofstedeの文化次元インデクスなどに基づく独自 の見解として「自分たちのやり方」を見つけない限り長続き

しないと考えていますので(ちょっと話題は外れますが、2

月末に行ったインハウスイベントでの、これに関するNさん

の発表も素晴らしいものでした)、「日本や米国のソフトウェ

アエンジニアは仲間内で勉強会や読書会をやったりするの

で、ここでもやってみましょう」と文化を押し付けたところ

で意味がないことを知っています。

「母国語でライトに読める技術情報誌」が欲しい

 そういう押し付けの代わりに、Nさんはひとつの仮説を立 てたのです。すなわち、日本では古くは『C Magazine』や『I/ O』あるいは『マイコンBASICマガジン』、最近ですと『WEB +DB PRESS』のように「母国語でライトに読める技術情報 誌」があるのに、ベトナムにはそれが皆無であることが、ひ とつ影響しているのではないか、という仮説です(ここで言 う「ライトに読める」というのは内容が軽いという意味では なく、アカデミック寄りではなくてより実践的な、くらいの 意味、つまり学術情報誌とは違うニッチの雑誌という意味で す)。

018  EM ZERO vol.09

 そう、Nさんは社内誌ではありますが、ベトナム語で読め る技術情報誌を創刊することにしたのです。創刊にあたって は私にも主に記事提供という形で協力依頼がきましたので喜 んでお受けしました。始めてみてわかったのですが、フリー テーマのコラム的連載を毎月書き上げるのはなかなかに大変 なことです。でも、Nさんの熱意と、なにより私自身がベト ナムのみんなとまた関わりあえるというので 2015年6月号の 創刊号以来、毎月の連載記事を持たせてもらっています。

ベトナム語で見る自分の記事

 日本語で書いた原稿がベトナム語に訳されるわけですが、

翻訳後の記事を読んでも自分にもなにが書いてあるかわから

ない、というのは結構おもしろい経験です:)。なにより、意

図どおりの記事になっているかどうかも検証できない、とい

うスリリングさがあります。けれど、私の尊敬する方の一人

があるとき言っていた「近似値でもいいから伝えようとする

努力」が必要な場面だと考えてやっています。

 小規模とはいえ、そういったものを出すとなると、私やN

さん以外の現地メンバーで記事を書いてくれる人の手配、特

集のネタ決め、翻訳スタッフの確保、編集部メンバーとして

学生インターンの採用、印刷の手配、組版ソフトの習熟、な

どやることは盛りだくさんなのですが(主にNさんの情熱の

賜物として)なんとか続いています。

 文化をインストールする、というのは時間がかかるもの

だと思います。まだその効果がどうなったか、目に見えるも

のはないのも事実ですが、先日ベトナムに数年ぶりに出張

に行ったときに「読んでるよ!○○の記事が特に印象に残っ

ている」と言われたときには単純にうれしかったですね。そ

んな素朴な喜びの積み重ねでなにかが変わっていくといい

なぁ、と思います。

『Geek & Tech Magazine』の紹介

 創刊号以来、私が書いた記事の元タイトルと、その雑誌

『Geek & Tech Magazine』の表紙を紹介して本稿を閉じます。

Magazine』の表紙を紹介して本稿を閉じます。 私が書いた記事の元タイトル

私が書いた記事の元タイトル

・2015年6月号(創刊号): アジャイルマインド、最初の一歩

・2015年7月号 : プロジェクトの強力な助っ人「自動化」

・2015年8月号 : ドキュメントについて考えてみる

・2015年9月号 : 勉強会を開催してみよう

・2015年10月号 : チーム開発を促進する Project Facilitation(1)

・2015年11月号 : チーム開発を促進する Project Facilitation(2)

・2015年12月号 : チーム開発を促進する Project Facilitation(3)

・2016年1月号 : Extreme Experience

・2016年2月号 : The ultimate XP project I met

・2016年3月号 : Unicode in a nutshell

■創刊号の表紙(この号の特集は「アジャイルマインドセット」)

 そんなわけで、皆様の寄稿もお待ちしております!

Profile プロフィール あまのりょー AMANO Ryo      
Profile プロフィール
あまのりょー
AMANO Ryo
     
 都内のメーカー系ソフトウェア会社
で働く自称「チアリーダー」。
 ちなみに『Geek & Tech Magazine』
での連載のタイトルは
。日本語だと「パクチー
王子の部屋」とのことです。なんか
誰かに勝手に紹介された内容みたいだ(http://www.manaslink.
com/articles/8952)。

   EM ZERO vol.09  019

ある40代男の

レガシーボディ

改善物語

ゼンソー代表/ Agile459代表

懸田 剛

KAKEDA Takeshi

 久しぶりのEM ZEROへの執筆というこ とでワクワクしています。今回は、ここ 数年取り組んでいるヘルスハック(健康 増進の工夫)について触れてみたいと思 います。

「自分が成長する歓び・楽しさ」に導かれ

ていきました。

ていきました。 『走るために生まれてきた』

『走るために生まれてきた』

『走るために生まれてきた』  走り始めたころ、カフェで見かけた『走

 走り始めたころ、カフェで見かけた『走 るために生まれた』(Born to Run、図1) という本を手にとりました。結局自分で購 入して最初から読み始めたのですが、読 み進めるうちに、どんどんのめり込んでい きました。  この本では、人間はほかの動物と比べ て「長距離を走る」ということに最適化さ

て「長距離を走る」ということに最適化さ 失敗の数々

失敗の数々

 これまで、人生の中で多くの失敗をして きました。その中でも特筆すべきなのは「ダ イエット」の失敗です。  子供のころからふくよかだった私は、高

校のころには最大86kgの体重を記録し、

それ以降も78kg付近をいったりきたり。

たまに一念発起して、75kgくらいに減らし

ては戻り、戻っては増え、そしてまた減ら しては戻る、そんなジェットコースターの

ような体重変化を20年くらい繰り返してき

ました。

 なぜ、うまくいかなかったのでしょう か?当時の私には「なぜ体重を減らした
 なぜ、うまくいかなかったのでしょう
か?当時の私には「なぜ体重を減らした
いのか」「減らした先にどうなりたいのか」
という具体的ななりたい姿がなかったから
だと感じます。
ランへの目覚め
 そんな私ですが、2012年(当時40歳)
から突然走り始めました。シューズもウェ
アも買わず、ありあわせのスニーカーとT
シャツで。それまで「走るという習慣」な
んてものは、人生の中で一度もなかったに
も関わらず、です。
 初日は3kmを20分くらいで走りました。
翌日は足が筋肉痛で、階段の昇降にとて
も苦労しました。それでも、3km走れたこ
とがうれしくて、足が痛ければ歩き、痛み
がなくなればまた走りだしました。走るた
びに距離や時間を伸ばしていきました。
 これまでまったく習慣のなかった自分で
も、少しずつ遠くまで走れるようになる、
020  EM ZERO vol.09
020
EM ZERO vol.09

■図1 『走るために生まれた』

(クリストファー・マクドゥーガル著)

れた構造に設計されているということ、靴

を履くことで本来の身体の動きと異なる

動きになってしまい、その結果として問題

(怪我、身体の使い方の欠如)が発生して

いること、裸足で走ることが本来の人体の

構造に適していること、世界には走ること

を当たり前としている人々が住んでいると

いうこと、フルマラソンを越えた超長距離

の山を走るレースがあるということ、など

など、どれもが今まで聞いたこともない新

鮮な驚きばかりでした。

鮮な驚きばかりでした。 夢と楽しみ
鮮な驚きばかりでした。 夢と楽しみ

夢と楽しみ

「自分でも、人類の本来の動きを取り戻せ

ば、裸足で走れるようになるはず」という

仮説を検証したい欲求がふつふつと湧い

てきました。

 その結果、「走ること自体・走ることで

自分が成長できる歓び・楽しみ」に加えて

「人の身体の可能性を生かして走れる(=

裸足で走る)ことを検証する」という新た

な目的が生まれ、走ることにどんどんのめ

り込んでいきました。

り込んでいきました。 ランから食生活への目覚め

ランから食生活への目覚め

 走るという行為で身体に興味を持った

結果、食生活にも目を向けるようになりま

した。人は食べたものを身体に取り入れ、

日々の過ごし方の積み重ねによって、身体

がどのように構成・成長・維持されるかが

決まります。

「食べて、運動して、成長する」、当たり

前のようにも思えますが、大事である自分

の身体・健康について、仕事と同じような

意識で取り組んでいる人は驚くほど少な

いのではないでしょうか。

いのではないでしょうか。 脳を鍛えるには運動しかない?

脳を鍛えるには運動しかない?

 また運動することが、脳科学の分野で も注目されていることも知りました。  有名なのは、ジョン・レイティの『脳を 鍛えるには運動しかない!』(Spark:The Revolutionary New Science of Exercise and the Brain、図2)です。この書籍では、「運 動すると、なぜ脳に良いのか」という点を、 さまざまから科学的な結果をもとに説明し ています。

 思えば、2006年ごろに一部で話題になっ

たライフハックである「腰リールメモ」は、

歩きながらふと思いつくアイデアを記録す

今を楽しむ・工夫する  もうひとつのポイントは、未来に進む
今を楽しむ・工夫する
 もうひとつのポイントは、未来に進む
だけでなく、「今ここを楽しむ」ことです。
いくら向かいたい未来が魅力的でも、その
過程の一日一日、一瞬一瞬が、退屈であっ
たら継続することができません。
「今をどう楽しみ充実させるか、よりよ
く・楽しくする」ための工夫を継続的に行

■図2 『脳を鍛えるには運動しかない!』

(ジョン・レイティ著)

るためのガジェットでした。以前職場が新

宿御苑の近くだったとき、散歩ミーティン

グを頻繁に行っていたのも、すべて繋がり

ました。

ました。 体質・習慣改善は システムの改善である

体質・習慣改善は

システムの改善である

 あらためて思うのは、自分の身体を変え

る、生活習慣を変えるということは、「シ

ステム改善である」ということです。

 ありたい姿を描き、そこに向かうため

に、ひとつひとつ課題をクリアしていく。

うまくいかないところは、うまくいくよう

に変えて、小さな成功体験を積み重ねて

いく。古い習慣を徐々に、新しい習慣に変

えていく。

 皇居に走りに行き始めたら、徐々に仲間

ができてランニングクラブに参加する。ク

ラブの皆と週末に合同練習をすることにな

る、というようになるかもしれません。

「漸進的に、自分・自分を取り巻く環境

がゆっくりと変わっていく」のです。

がゆっくりと変わっていく」のです。 「今を変えたい」だけでなく

「今を変えたい」だけでなく

「こうなりたい」を作る

 ここでポイントなのは「~変えなければ ならない」という強迫観念だけでは続かな い、ということです。  私の場合、「いつか裸足でマラソン走り たいなぁ」というぼんやりとした未来像と 共に、近い将来の目標としての「ハーフマ

ラソンを完走したい」「フルマラソンで4時

間切りたい」という、明確な「なりたい姿」 に向かうことになりました。

 そして、いつしか「100kmマラソンを完

走したい」「100マイル(160km)の山岳レー

スを完走したい」という、最初は思いもよ

らなかった「なりたい姿」が見えてきまし

た。

います。

 たとえば、「畑に走っていって水やりし

てみよう(水やりラン)」とか「走りなが

らミーティングしてみよう(ランミーティ

ング)」といった試行、スマフォやGPSウォッ

チで自分の走った記録をつけて分析する

といったガジェット利用、自分で草鞋(わ

らじ)を編んで走ってみよう(ワラジラン)

といった工夫をしながら日々を楽しんでい

ます。

ます。 試してみる、ふりかえる、改善する

試してみる、ふりかえる、改善する

 変化の過程では、アジャイル開発と同

様に「フィードバックループを回す」こと

が不可欠です。

 なにか新しいことを試したら、評価して

みて継続するかを判断します。まずは試し

てみて、自分の体験をもとに評価する、そ

ういった試行錯誤を意図的に行います。

 巷に溢れるさまざまな情報に振り回さ

れるのではなく、「自分でひとつずつ試し、

ふりかえり、次のステップを自分自身で見

出していく」フィードバックループが重要

です。

です。 健康はすべてにつながる

健康はすべてにつながる

 プログラマは、テストが整備され、可読

性が高く、品質が高いコードを「健康的な

コード」というメタファを使う場合があり

ます。健康的なコードは、持続的に価値を

提供することができるためです。

 次にメタファではなく、プログラマが関

わっている開発対象のシステム・プロダク

トは、「関わっている人も含めてひとつの

システム」と考えてみてください。

 プログラマが自身の健康をないがしろに

して、日々仕事に没頭しているのであれば、

たとえコードの健康状態は維持していて

も、プログラマの健康的負債をシステムに

対して日々借金していることに等しいと考

えることができます。

 世界保険機関(WHO)は、健康を次の

ように定義しています。

ように定義しています。 “Health is a state of complete physical, mental and social

“Health is a state of complete physical, mental and social well-being and not merely the absence of disease or infirmity.” (健康とは、病気でないとか、弱っていな いということではなく、肉体的にも、精神 的にも、そして社会的にも、すべてが満た された状態にあることを言います。)

 仕事で成果を出すこと、社会的に認め られたり、人と繋がること、精神的に満た されること、それらと同じように、肉体的 に充実させ、その状態を維持することが、 すべてが満たされた状態にあるということ になります。コードも身体も実はつながっ ているのです。

 もしも、あなたが、30歳を過ぎて身体

のことをまったく考えていないのであれ

ば、少しずつ、できることを始めてみてく

ださい。自分で楽しいと感じることだけを

行い、なりたい姿を描いて、工夫してみて

ください。

 肉体的のみならず全方位的に健康な状

態を作り、維持し、充実した仕事、充実し

た人生を送るために。

Profile ロフィール

ゼンソー代表/ Agile459代表 懸田 剛 KAKEDA Takeshi  2010年より東京から松山に移住し、
ゼンソー代表/ Agile459代表
懸田 剛
KAKEDA Takeshi
 2010年より東京から松山に移住し、
アジャイル・スクラム、プロジェクトファ
シリテーション、パタン・ランゲージ
などのスキルを活かし、顧客の現場
で価値提供のための人づくり、しくみ
づくり・文化づくりを支援している。
 ITエンジニア向けの健康情報の共
有+アクティビティ体験型イベント「ヘ
ルスハックカンファレンス」(http://
healthhackconf.github.io/)を、2016
年3月に愛媛県松山市で開催した。
 2016年度中に100kmマラソン完走、
70kmトレイルレース完走、フルマラソ
ンサブ3.75、裸足でのフルマラソン完
走を目指す。
サイト:http://zensow.jp/
個人ブログ:http://giantech.jp/
全走歴:https://www.strava.com/
athletes/3772130/

   EM ZERO vol.09  021

な ん で も ア ジ ャ イ ル の ス ス メ

もし草野球のおっさんプレイヤーが

アジャイルを学んだら

小林 信

KOBAYASHI Makoto

なんでもアジャイルのススメ

 一生の2割、職に就いているときは1

年の3割が仕事に費やす時間らしい。3

割が睡眠時間にあたるので、起きてい る時間の半分近くは仕事だ。残り半分 がプライベート。せっかく仕事で得た スキルや考え方なのだから、有用なら ば(規則やモラルに反しない限り)プ ライベートにも適用したいと常々思っ ている。その考えが根底にあるため、 趣味の野球にアジャイルの考え方を導 入したことは自然の流れだった。  僕はアジャイル開発手法の中でもス クラムを中心に学び実践したが、ソフ トウェア開発手法という枠組みに収め ておくにはもったいないやり方である。 自分やチームの成長を促し、結果を出 し続けるためのしくみそのものだ。  アジャイルをプロジェクトに適用す ることができなくて悶々としている人 は、趣味に適用することを推奨したい。 あなたの生活にプラスの効果を与えて くれるものだと信じている。

 2014年夏。僕は歓喜した。「これだ!」

と思うやり方に出会ったのだ。

 昔から計画を立てるのは好きだった。

このとおりにやれば完璧なものができ

あがるはず。ただ、それがうまくいくこ

とはほぼなかった。なぜならば、僕は

行動が苦手なのだ。PDCAサイクルが

重要だ、というのは承知している。だが、

実行に移せない、習慣になってくれな

い。

 僕がこの夏に出会ったアジャイルは

行動を支えてくれるやり方、そんな予

感がした。そこで、趣味である草野球

のトレーニングにアジャイルを導入す

ることにした。これはその足跡である。

僕のアジャイルチャレンジ

【原則】

 僕ははじめから悩んだ。アジャイル

を行う場合、アジャイルマニフェスト

は押さえていなければならない。しか

し、草野球に適用する場合はどうすれ

ばいいのだろう。そこで自分なりの解

釈をすることにした。

・個人との対話→1人なので自身の思

いをアウトプットして記録

・動くソフトウェア→草野球選手とし

ての自分そのもの

・顧客との協調→草野球・自チームが

なにを求めているかを真摯に受け止

める

・変化への対応→そのまま

【方向づけ:インセプションデッキ】

 次に方向づけ、インセプションデッ

キの導入である。まずはエレベーター

ピッチだ。テンプレートに従い、どの

ようになりたいのかを表現。当初は守

破離の守に則って作成した。

「得点力不足を解消」したい「我が

チーム」の「小林信」という選手は、

「相手投手の嫌がる巧打者」である。

「甘い球を見逃さず、際どい球を見

極める」ことができ、「昨年までの

小林信」とは違って、「高い打率と

出塁率」が備わっている。

 ふりかえるとエレベーターピッチの

効用はすごい。なによりの道標になり、

見直したときのお題目にもなる。

 アジャイルは変化を受け入れる。だ

からこそ、変化が価値のあるものかを

見極めることが重要だ。その判断基準

がインセプションデッキによって表現

される。インセプションデッキの作成

こそ、アジャイルを成功させる第一歩

である。

 やる・やらないことリストで範囲も

明確にした。今回は「打つこと」に対

して徹底的に行い、守備に関しては(ど

うすればいいかわからない)対象外と

した。

【計画:ユーザーストーリーの作成】

 なりたい選手を表現することはでき

た。次に、その選手になるためになに

が必要かをユーザーストーリーによっ

て記述した。ここでは「こうしたらい

いな」と思うことを書き連ねた。テン

プレートにある「なぜなら」の部分が

エレベーターピッチの枠内に収まって

いるかが重要である。

【実行:スプリント】

 シーズンも終盤を迎えた9月。僕は

求める姿を体現すべく、アジャイル野

球に取りかかった。スプリント期間を1

週間のタイムボックスとして設定する。

 デモは顧客に披露する機会、つまり

■図1 スプリント模式図 登録 要求一覧 スプリント計画 ・要求 1 ・タスク 1
■図1 スプリント模式図
登録
要求一覧
スプリント計画
・要求 1
・タスク 1
結果・ニーズ
短期計画
・要求 2
・タスク 2
 …
 …
満足
実践
日々のトレーニング
ふりかえり
試合
ビルドアップ

022  EM ZERO vol.09

試合とした。試合に臨む自分そのもの を成果物とし、ビデオに記録。ユーザー ストーリーで描かれるイメージと実際 の動きの差異から、フィードバックを 受け取ることとした。  スプリントは自分の中でもっとも価 値のあるストーリーから手を着ける。 そのストーリーとは「【巧打者】として 【自分が得意なボールを初球から打ちに いき】たい。なぜなら【不利な状況に なる前に打ちに行くことにより、自分 のスイングで勝負できるから】だ」。  選んだストーリーに対して、実行す

るための(1人)計画ミーティングを行

う。このミーティングで、ストーリーを

実現するにはなにをすればいいかを決

めていく。

 分割方法に言及している書籍は少な

く、もっともチームによる差がでる箇

所だ。今回は、「単純な行動」として分

割することにした。上記ストーリーの

場合は、「得意なボールを調査する」「得

意なコースを振り抜ける素振りを行う」

「バッティングセンターで得意なコース

のみ打ちにいく」などに切り分けていっ

た。

【検査・改善:スプリントレビュー】

 スプリントレビューは試合の打席結

果によって行う。野球の打撃において

動くソフトウェアとは、打者そのもの

である。ストーリーを満たした結果を

出しているか、想定した動きができて

いるかを検査していく。当初は自分の

感覚と結果で判断をしていたが、途中

からビデオを導入し客観的に判断でき

るように改善を重ねた。ビバふりかえり。

アジャイル再チャレンジ

 4 ヵ月が経ち、アジャイルトレーニ

ング2014シーズンが終了した。アジャ

イルを学びながら試行錯誤で進めたた

め、必ずしも満足な結果ではない。常

に順調にストーリーを消化できるわけ

ではなかった。

 しかし、繰り返し実施することによ

り一つ一つ課題を克服し、新たに出た

フィードバックをストーリーに反映さ

せていく。そこには、成長という実感

と確かな足跡が残った。そして僕はエ

レベーターピッチで描いた選手像に確

実に近づいていた。

いつか… 【なりたい姿】 満塁で敬遠される打者
いつか…
【なりたい姿】
満塁で敬遠される打者

目標を立てながらなりたい姿に

近づいていく!

エレベーターピッチ 2015 エレベーターピッチ 2014 昔の姿
エレベーターピッチ 2015
エレベーターピッチ 2014
昔の姿

エレベーターピッチ 2016

■図2 最終目的に向けたステップ

 迎えた2015シーズンでは新たなエレ

ベーターピッチを策定し、一からつく りあげることを決めた。アジャイルは 行動できない人に対して有用なしくみ。 タイムボックスに従い改善を重ねてい くこと、その結果が早期に検査できる こと。このしくみそのものが、継続し た行動へのモチベーションとなる。  投手の横を抜け、センター前にボー ルが転がる。僕はボールの行方を見送 り右手を高々と突き上げた。草野球人

生20年で初めての三冠王に輝いた瞬間

だった。2015年冬。アジャイル打撃ト

レーニングに取り組んで1年半。僕はエ

レベーターピッチに描いた選手像その ままに成長した。

 僕は今、2016年のシーズンに向け

てインセプションデッキを行っている。

まずは目的を決めることが重要だ。ど

こを目指すかが決まれば、もう心配は

いらない。僕にはアジャイルがついて

いるのだから。カイゼンの余地がある

限り、翌年が僕のキャリアハイだ。

最後に

 今回の趣味事例では、自分自身のマ

ネージメントとしてアジャイル手法を

取り入れた。難しいカテゴリであるチー

ムビルディングや情報共有を気にする

必要がないため、適用事例としてはもっ

とも簡単な部類だ。だからこそ、その

ようなところから始めるのも手だ。仕

事でしか使ってはいけないなんて決ま

りはないのだ。

 プロジェクトに適用するには、さま

ざまな外部要因が邪魔をする。僕も開

発現場でアジャイルを導入しているが、

試行錯誤の日々だ。しかし、僕はアジャ

イルによって求める姿を実現できるこ

とを知った。最高にハッピーになれる

ことを知った。そして、周りの人にも

ハッピーを味わってもらいたい。この

気持ちを原動力に、今日も少しずつ周

りをアジャイル色に染めていこうと決

意する。

■参考文献

(1)「アジャイルマニフェスト(アジャイ

ルソフトウェア開発宣言)」 (http://www.agilemanifesto.org/iso/ja/)

(2)『アジャイルサムライ—達人開発者

への道』(Jonathan Rasmusson、オーム社、

2011年)

(https://estore.ohmsha.co.jp/titles/97842

7406856P)

Profile プロフィール 小林 信 KOBAYASHI Makoto エスビーエス株式会社入社13年目。プロ
Profile プロフィール
小林 信
KOBAYASHI Makoto
エスビーエス株式会社入社13年目。プロ
ジェクト主任に従事するかたわら、エスビー
エス野球部主将・エスビーエス運動会実
行委員長(非公認)を兼務。
アジャイルとは2014年8月に出会い、以来
とりこ。好きなプラクティスはスプリント
レビュー、ふりかえり、ペアプログラミン
グ。アジャイル開発に取り組むうえでは、
マザーテレサの「Be careful」を肝に銘じ
ています。まずは手の届くところから普及
活動!

   EM ZERO vol.09  023

「インセプションデッキ」と 「インセプションデッキ」と

「MVP開発」を用いた 「MVP開発」を用いた

モダンなアジャイル開発 モダンなアジャイル開発

中川伸一

NAKAGAWA Shinichi

 筆者は、野球のデータ分析を行う アプリケーションを開発してオープン ソース化したり、事例や知見を発表す る活動を行っています。この章では、 プログラミング言語Pythonのカンファ レンス「PyConJP 2015」(https://pycon.

jp/2015/ja/)登壇にあたり行ったアジャ

イル開発の実践例を紹介します。

どのような価値を提供できるか

 プロダクト(Pythonアプリケーショ

ン)の開発も徐々に進んでいたのです

が、ここで壁にぶつかりました。一言

で言うと、限られたリソースの中で、

カンファレンス参加者と発表者(筆者)

に対してどのような価値を提供できる

かが課題であると気がつきました。

 そこで、「インセプションデッキ」と

「MVP開発」を用いたアジャイルな開

発を行うことにしました。

「インセプションデッキ」

インセプションデッキによる言語化

「インセプションデッキ」は『アジャ

イルサムライ—達人開発者への道』(Jo nathan Rasmusson著、オーム社、2011 年)で紹介されている、「プロジェクト の目的・意義を言語化する」フレーム

ワークです。10個の手強い質問に答え

ることで、プロジェクトの目的・価値 を言語化します。  インセプションデッキには「我々は なぜここにいるのか」という質問があ ります。この質問に対する筆者の答え は「Pythonと野球で仕事をすること」 です。言語化することで、発表する意 義やモチベーション、参加者が持ち帰 る価値を明確に定義し、プロダクトを 開発するうえでの基礎としました(

1)。

インセプションデッキによる  スコープ定義  インセプションデッキの「やらない ことリスト」の質問を通じて、スコー プを明確にしました。

 特に気をつけたポイントは次の2つ

です。

・言語化した「価値」を最低限実現す

るために必要な機能はなにか?

・「価値」の提供に結びつかない機

能・タスクはなにか?

 これらを整理した結果、

・打撃(本塁打・打点な ど)、投球(勝利 数・敗北 数など)の分析と可視化 ・分析サーバーとデータベースをDocker / Ansibleで自動化 ・デモ環境(自分のPC)で動作可能

というプロダクトが構築できれば、価

値が伝わると考えました(図2)。

「MVP開発」

「インセプションデッキ」で発表の 概要を決めた後、実験用のプロダクト (MVP:Minimum Viable Product) を 開発しました。インセプションデッキ で定義した「価値」を最小限で実現す るためのプロダクトです。  具体的には、

・ブラウザ上でPythonのコードを記

・ブラウザ上でPythonのコードを記

■図1 インセプションデッキの質問「我々はなぜここにいるのか?」

024  EM ZERO vol.09

0 2 4   EM ZERO vol.09 ■図2 やらないことリスト

■図2 やらないことリスト

述・実行可能な「IPython notebook」 を用いてアプリケーションを開発
述・実行可能な「IPython notebook」 を用いてアプリケーションを開発
述・実行可能な「IPython notebook」 を用いてアプリケーションを開発
述・実行可能な「IPython notebook」
を用いてアプリケーションを開発
・pyenv・virtualenvを活用し、実行環
境を仮想化
・SQLAlchemy(O/Rマッピング)、pan
 das(データセット)、matplotlib(グ
ラフ描画)などのOSSライブラリを
活用
net/shinyorke/hackpython-pyconjp
・発表のようす(YouTube):https://
これから挑戦したいこと
youtu.be/MBAh5qE57Hs
 今回はインセプションデッキとMVP
 発表後もPython関連のノウハウに
開発を用いて最初のプロダクトを構築
ついてフィードバックをいただいたり、
し、価値を出すところから始めました。
野球のデータ分析に関する問い合わせ
今後は、アジャイル・スクラムの知見・
があったりと、多くの交流ができ、大
経験を自社サービスや開発チームに還
変充実した時間を過ごしました。
元したり、継続的なアジャイル推進に
といった技術・ライブラリを活用し、
より、自分の夢・プロダクトを世の中
最小限かつ変更が容易なMVPを構築し
に出すことに挑戦します。
アジャイル開発を実践してみて
ました。
 これからもアジャイルの実践者、エ
 今回の実践を通じて得た学びは次の
ンジニアの一員として、「アジャイル」
2つです。
「動くソフトウェア」を通じて、価値あ
勉強会での検証
るサービス・プロダクトを追求したい
 本番の11日前に開催された「Kawasa
●プロジェクトの目的と価値の
と思います!
ki.rb」(https://kawasakirb.doorkeeper.
 言語化の大切さ
jp/)という勉強会で、発表練習の機会
 プロジェクトの目的や価値の言語化
をいただきました。簡単な発表を行い、
は、Webサービスや業務アプリケーショ
その場の質疑応答や懇親会での会話を
ン開発の文脈でよく語られていますが、
通じて、技術面での指摘・改善点、発
学術研究やR&Dなどの「限られた条件
表内容(データ分析)に関する疑問や
で最高の結果・価値をつくる」活動でも、
Profile プロフィール
考え方、発表全体の感想といったフィー
アジャイルなアプローチ、価値の言語
ドバックをいただき、本番に向けての
化は非常に大切だと学びました。
プロダクトと発表のブラッシュアップ
に役立てました。
本番発表に臨む

 MVP開発と勉強会での検証で磨いた 成果をもとに本番での発表を行いまし

た。約60人の会議室に100人近い人々

が集まり、大盛況のうちに終わりまし

た。

 本番発表の成果やようすは次にまと

まっています。

・野球Hack!~Pythonを用いたデータ

分析と可視化:http://www.slideshare.

MVP検証をイベント・勉強会で  行う有効性  Webサ ー ビ ス や 業 務 ア プ リケ ー ション開発における「ユーザーインタ ビュー」「ユーザーテスト」に代わる モノとして、勉強会での発表を通じて フィードバックをもらう手法をとりまし た。  これも有効性が高く、実践しやすい 方法だったと思います。ある程度まと まった人数からのフィードバックをも らえる、発表の準備のみで即検証可能 と、非常にライトウェイトで実行の障 壁も少ないいい方法でした。

中川伸一 NAKAGAWA Shinichi Pythonista /スクラムマスター。
中川伸一
NAKAGAWA Shinichi
Pythonista /スクラムマスター。
独立系ITコンサル企業、株式会社リクルー
ト住まいカンパニーを経て、2016年2月か
ら株式会社ビザスクのエンジニア/スクラ
ムマスターとしてジョイン。
プライベートでは野球のデータ分析と可視
化、アジャイル開発と野球の融合をテー
マに執筆・イベント登壇といった活動を行
う。趣味は野球観戦、UKロック、飲み歩き。

   EM ZERO vol.09  025

 私はアジャイル原理主義者である。 現在はアジャイルをルーツとした、 DevOps
 私はアジャイル原理主義者である。 現在はアジャイルをルーツとした、 DevOps

 私はアジャイル原理主義者である。 現在はアジャイルをルーツとした、 DevOps の原理主義者である。  はっきり言ってバズワードなのでア ジャイルと中身はそんなに変わらない。 私はそのような “バズワード” の衣を 纏い、日々 DevOpsテロを行い新たな 信者を獲得・洗脳するための活動をし ている。  私はSolarisで育ち、Linuxそして、素 晴らしいオープンソースの世界を楽し んできた。もちろん現在のメインマシ ンはいうまでもなくMacである。その ような私からすると決して許せない存 在がある。それはマイクロソフトだ。  皆さんも異論はないだろう。このよ うな素晴らしいオープンソースの活動 が生まれたころに、「ホビィストへの公 開状」という書簡を発表したのがビル・ ゲイツだ(http://jibun.atmarkit.co.jp/

ljibun01/rensai/genesis/165/01.

html)。  彼はホビィストがやっている行為が 「盗み」だと糾弾したのだ。我々が今 GitHubを通じて行っている活動は盗み なのか?それを言うなら多くの企業が 自社のソフトウェアをGitHubで公開し て、Pull Requestを受け付ける行為こ そが労働力の「盗み」ではないか。  私の脳裏にふとしたことが浮かんだ。

2002年にアリスター・コーバーンを大

阪城に案内した。そのときに、金の茶

室を見た。

 彼は一言こう言った。「ビル・ゲイツ

のようだ…」そう。金だ。世の中金だ。

私のようなアジャイルの殉教者にとっ

ては到底許せるはずもない。私のやる

ことは一つ。「テロ」だ。そう思い私は

念密な計画を立てた。

026  EM ZERO vol.09

アジャイル原理主義者

アリスター・ファウラー・Mc剛

Alistair Fowler McTsuyoshi

 そこで下した結論は「マイクロソフ トに内部から潜入し腐敗させる」とい う戦略だ。よしこれがいい。  私は自分がパッションを持てる DevOpsのポジションに応募してみた。 このポジションに応募する前に、日本 側でも面接があった。出てくる面接官 は一風変わっているが魅力的な人物ば かりだった。わかっている。騙されて はいけない。  人間的魅力で篭絡するのは歴史を見 ても常套手段じゃないか。私は計算高 く自分の憶測にある「真の目的」を秘 めながら順調に面接を突破していった。  最初の日本のポジションはクローズ したが、インターナショナルのポジショ ンに再度応募して、とうとう「マイク ロソフト」に内部から潜入することが できたのだ。くっくっく。愚かな奴らよ。 わしの本質が見抜けないとは。これが、 マイクロソフトの腐敗の始まりとも知 らず。  マイクロソフトでは「シニアテクニ カルエバンジェリスト DevOps」という ポジションについた。ハッカソンを開 催したり、DevOps を本気で導入する 企業を支援して、世界的な事例を作る のが私のミッションだ。  会社はオープンスペースでリモート ワークの環境が整備されており、勤怠 は相当自由だ。幸いなことにDockerや HashiCorpやGoと戯れていてもサティ アとかいう新しい社長が “Microsoft loves OSS” とか言ったものだから、怒 られないらしい。  もっとも前の社長のバルマーは、社 員のiPhoneを見て叩き落したらしいが な。くっくっく。  おっと、向こうからにこやかな顔を

したボーダーシャツを着た男が歩いて

きた。彼は「てらだよしお」と名乗っ

ていた。にこやかにしているが俺には

わかる。こいつは俺以上のクズだと。

ゲロ以下のにおいがプンプンしやがる

ぜ。

 奴にはマイクロソフトへの忠誠心な

どない。現に奴のメインマシンはMac

じゃないか。しかもNetBeansでJavaば

かりコーディングしてやがる。

 なぜNetBeansなんだ。私の想像を超

えるマゾ野郎だぜ。向こうにいてる「久

森」とか「パクえ」というやつも俺た

ちと同じにおいがする。奴らも私と同

じくマイクロソフトを内部から腐敗さ

せようとしているに違いない。

 しかし、こうしてみると、私が手を

下すまでもないのかもしれない。くっ

くっく。現にこの会社にはおかしな奴

らばかりが集っているじゃないか。

 向こうから歩いてくる男はなぜか毎

日着物を着ている。それに、「クラウディ

ア」さんの中の人は、本当に金髪でそ

のままじゃないか。まるで磔にされた

「キリスト」のような見た目のおっさん

までいる。

 さらに、マイクロソフトが最も力を

入れているAzureというクラウドプラッ

トフォームの部長が書いているブログ

は、ガンダム用語が難解すぎて、素人

にはわからないじゃないか。

 向こうにいるなんかよくわからない

おっさんの名刺を見ると「ジニアス平

井」と書いてある。くっ。自分でジニ

アスなどなんという思い上がりだろう

か。私が手を下すまでもないようだが、

獅子はネズミをとらえるにも全力を尽

くすという。

 私もそれに従っていい「仕事」をす