Embed Size (px)
Citation preview
アジャイルソフトウェア開発とは？アジャイルソフトウェア開発とは？
VCwareが採用している「アジャイルソフトウェア開発」について、簡単な解説をします。
要約要約
アジャイルソフトウェア開発(agile software development)
とは、1990年代頃から考案されてきた
軽量な開発手法群の総称です
（もともとこれは
「軽量ソフトウェア開発手法」とよばれていました）
要約要約
これは「ウォーターフォール開発」に代表されるような「計画重視の開発手法」の対極に位置します。そもそもこれは、「重量ソフトウェア開発手法」に対する反対運動として発展してきました。
アジャイルアジャイル ウォーターフォールウォーターフォール
適応的開発手法適応的開発手法 計画重視の開発手法計画重視の開発手法＝
重量ソフトウェア開発手法重量ソフトウェア開発手法軽量ソフトウェア開発手法軽量ソフトウェア開発手法
＝
要約要約
「ウォーターフォール開発」と異なり、アジャイルソフトウェア開発では、プロジェクトの開始時点において、あらかじめ詳細にわたる要件定義書（仕様書）のような文書を作成せず、長期的な開発計画をたてません。
要約要約
アジャイル開発では、反復(iteration)とよばれる短い期間に、開発対象の一部分（ビルド）のみを、「完全に動く形で」リリースします。
この期間は、1週間から4週間程度です。
要件定義・設計・コーディング・テスト、などの、ウォーターフォール・モデルが数ヶ月から数年の間に行う全工程を、この反復内ですべて完結させます。
要約要約
ひとつの反復が終わったら、チームは前反復を振り返って見直し、プロジェクトの優先順位を評価しなおします。
以上。
……などと概要のみを提示されても、よくわかりませんよね。
では、「アジャイルソフトウェア開発」の対極にある、「ウォーターフォール開発」をかんたんに解説しながら、それのどこがまずいのか、
対するアジャイルはどのように優位であるのかについて、述べたいと思います。
ちなみに、私（斉藤）は2001年に「基本情報技術者」を取得しましたが、教科書で
「ソフトウェアの開発とはこうやるのだ」と断言されていたのが、「ウォーターフォール開発」です（いまの教科書にはどのように書いてあるのでしょうね？）
ウォーターフォール開発の概要ウォーターフォール開発の概要
「ウォーターフォール・モデル」とは、文字通り「滝」を意味しています。
プロジェクト全体をいくつかの工程に分割し、 計画にそって、 ある工程が完全に終結したら、 次の工程へと進む、
というモデルです。
ウォーターフォール開発の概要ウォーターフォール開発の概要
要件定義要件定義
外部設計外部設計
内部設計内部設計
実装（コーディング）実装（コーディング）
テストテスト
運用・保守運用・保守
ひとつの工程が終結したら
次の工程へ進む
ウォーターフォールは戻らないウォーターフォールは戻らない
ウォーターフォール開発では、原則的にひとつの工程が完了しない限り、次の工程に進みません。
したがって、設計中にコーディングを行うといった「並行作業」もありえません。
このように、線形に開発が進むので、ガントチャートのような「線表（棒グラフ）」をもちいてプロジェクト管理をします。
ウォーターフォールは戻らないウォーターフォールは戻らない
こうしたことからわかるように、ウォーターフォール開発では、
前工程に間違いがないことを前提前工程に間違いがないことを前提
としています。
そしてそこが問題点のひとつでもあります。
ガントチャートの例ガントチャートの例
（引用元：ITPRO「WBSを使った作業計画と スケジュール作成の実践知識（２）」2005,12,09 http://itpro.nikkeibp.co.jp/article/COLUMN/20051202/225619/）
ガントチャート、科学的管理法。ガントチャート、科学的管理法。 あるいはテイラー・システム あるいはテイラー・システム
「ガントチャート」は、アメリカの機械工学者で経営コンサルタントのヘンリー・L・ガント(1861-1919)によって考案されました（名付けたのはガントの部下のウォーレス・クラークですが）。
なかなかガントじゃん
ガントチャート、科学的管理法。ガントチャート、科学的管理法。 あるいはテイラー・システム あるいはテイラー・システム
ガントは、「科学的管理法の父」とよばれるフレデリック・W・テイラー(1856-1915)の弟子で、科学的管理法を共に研究したメンバーです。
（「科学的管理法」は別名「テイラー・システム」ともいわれます）
私がお父さんです
ガントチャート、科学的管理法。ガントチャート、科学的管理法。 あるいはテイラー・システム あるいはテイラー・システム
ガントは第一次世界大戦に参戦することになった米国の造船計画にコンサルタントとして参加し、大統領表彰を受けています。
また彼の死後、ガントチャートはフーバーダムの建設、インターステートハイウェイといった大型公共事業で使われ、いまでも古典的管理手法としての地位を保っています。
ガントチャート、科学的管理法。ガントチャート、科学的管理法。 あるいはテイラー・システム あるいはテイラー・システム
科学的管理法（テイラー・システム）について解説を始めたらきりがありません。
ブルーカラーとホワイトカラーの対立構造を生み出したという批判、効率性の追求による人間性の軽視という批判、さらに科学的管理法を批判したミンツバーグの研究は科学的管理法の反復にすぎないとして批判した「ネオ・テイラー主義」。
ガントチャート、科学的管理法。ガントチャート、科学的管理法。 あるいはテイラー・システム あるいはテイラー・システム
これらの批判を取り入れ、そしてさらに、心理学や社会学の観点をも取り入れることによって、経営学・組織論は発展してきました。
（私は院生時代、ハーバート・A・サイモンらの経営・組織論も研究対象のひとつとしていたということもあり、ついこのあたりの事情について語りたくなってしまいます）
フォーディズムからトヨディズムへフォーディズムからトヨディズムへ
ところで、この科学的管理法、どこかで聞いたことがありませんか？
多くの方が、いわゆる「フォーディズム」、そしてその影響下にある「トヨディズム（トヨタ自動車の生産方式）」を想起されたかと思います。
その通りです。
フォーディズムからトヨディズムへフォーディズムからトヨディズムへ
フォード・モーターは科学的管理法を応用した生産システムを採用して成功した企業です。
「フォーディズム」という言葉はイタリアの思想家アントニオ・グラムシ(1891-1937)によって命名されたものです。
ムッソリーニに投獄されたよ
フォーディズムからトヨディズムへフォーディズムからトヨディズムへ
社会学や、経済学のレギュラシオン理論において言及されます（私の院生時代はグラムシの再評価が盛んだった時代です）。
まさに、戦後の高度経済成長の基軸となったのが、科学的管理法だったというわけです。
獄中ノートが後世大きな影響を与えることに
なったんだけどね
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
高度経済成長の帰結は、バブル経済（高度消費社会）のみではありません。
いわゆる「一億総中流意識」が国民に共有され、1970年以降の日本では、国民の90％が「自分は中流である」と認識していました。
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
同様に中流意識の高い国には、アメリカなど、戦後高度経済成長を遂げた多くの国がありますが、人口が一億人ではないため「一億総中流」という言葉は日本だけのものです。
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
「科学的管理法」がブルーカラーとホワイトカラーの対立構造を生み出したというけれど、「一億総中流」なら、対立していないではないか、
とお思いでしょうか。
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
まさしく、そうした「経済成長によって労使間対立は解消され、マルクス主義は敗北した」という理論が、学問の世界でも盛んになりました。
（正確には、学問の世界というより、学問の意匠を借りたジャーナリズムの世界ですが）
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
1970年代に初めてパッケージングされた「水」が店頭で売られるようになったことが、「資本主義社会」から「高度消費社会」への転換だった、と語られるようになります。次いで、「情報化社会」への転換が起きたと（いわゆる「IT革命」）。
（ちなみに「六甲のおいしい水」は1983年発売ですし、さらに言えば江戸時代から「飲料水の販売」はありました。水道環境の悪い明治期・戦時期日本やヨーロッパでは水を買うのは当たり前のことでした。しかし確かに、'72年に、日本では第二次産業従事者を第三次産業従事者が超えたのです）
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
21世紀に入って、これらがすべてたんなる資本主義の掌の上での出来事だったことが白日のもとにさらされます。
近年「格差社会」と言う言葉が盛んに用いられます。しかし、「格差社会」は近年生じた稀な事象ではありません。
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
じつは1970年の「日本国民の9割が『自分は中流』だと思っていた」その時点で、世帯収入という現実の面では、「一億総中流」などではなかったという事実が明らかになっています（統計技術上のミスがあったということが、後年判明しました。）。
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
そして2011年、アメリカ版「流行語大賞」ともいえるWord of the Year(WOTY)として、「99％」がノミネートされました。
（大賞受賞は「occupy」でした。「99％」の貧困層が「1％」の富裕層に怒り、ウォール・ストリートを「occupy」したのは記憶にあたらしいところですね）
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
歪みは世界中のいたるところで噴出しています。
2006年に「自殺対策基本法」が施行されたのを受け、警察庁は翌07年から自殺者の原因分析を始めましたが、08年9月のリーマン・ショックを受け、若者の、とくに学生の、就職活動を原因とした自殺が2.5倍に増えました。
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
学生の就職難にせよ、女性のM字型就労にせよ、日本における雇用問題の最大のポイントは「マッチング」にあるといえます。
企業には欲しい人材が明確にある。労働者にも、自分の特性があり、職業で自己実現したいという意欲がある。しかし、彼らが「出会う」ことはない。
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
ウォーターフォール、そしてガントチャートに代表される科学的管理法から、「フォーディズム」を想起しませんでしたか、と言いました。
そして「フォーディズム」は日本型の「トヨディズム」に受け継がれた、とも言いました。
これは、日本の高度経済成長を支える軸となりました。
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
「マッチング」を阻害している要因として、日本の企業が、高度経済成長を支えた文化的風土の惰性から抜け出るのに、充分な世代交代を果たしていないことがあげられると思います。
つまり、高度経済成長はとっくの昔に終わっているのに、企業の組織的風土、企業文化は、依然として高度経済成長期に掲げた夢に引きずられているのです。
「日本的風土」に合ったウォーターフォール「日本的風土」に合ったウォーターフォール
容易に想像できることですが、日本の企業にとって、ウォーターフォールは極めて受け入れやすいものです。
アジャイル開発の「弱点」としてあげられる事項のひとつに、「『指示と管理』を社風とする企業における適用可能性」があります。このような組織文化において、アジャイル開発を採用するのは難しい、というわけです。
適応的開発手法としてのアジャイル開発適応的開発手法としてのアジャイル開発
もしあなたがソフトウェア開発・システム開発に関わったことがあれば、こういう風景を目にしたことがあるのではないでしょうか。
部下「このユーザーインターフェースの挙動は矛盾しています。バグではないでしょうか？」
上司「仕様だ」
適応的開発手法としてのアジャイル開発適応的開発手法としてのアジャイル開発
ウォーターフォールの上流工程（要件定義から仕様書の策定、計画立案までを指します）で、開発側は、クライアントからシステムの要件をすべて聞き出し、持ち帰り、機能として仕様に盛り込みます。
適応的開発手法としてのアジャイル開発適応的開発手法としてのアジャイル開発
そして、ウォーターフォールが「前に戻らない」モデルである以上、一度仕様が決められれば、それがくつがえされることはありません。
たとえユーザーにとって使い勝手が悪くとも。
たとえクライアントが内心「嫌だなあ」と思ったとしても。
適応的開発手法としてのアジャイル開発適応的開発手法としてのアジャイル開発
とても矛盾した、非効率的な方法論だとは思いませんか？
適応的開発手法としてのアジャイル開発適応的開発手法としてのアジャイル開発
仮に、クライアントが極めて強引で、「状況が変わったから当初の仕様を変更して欲しい。変更しなければ納品を受け入れない。契約を破棄する」と言ってきたらどうでしょう。
このクライアントの要求に対して、ウォーターフォールは柔軟な対応をとるのが、極めて難しいですよね。
適応的開発手法としてのアジャイル開発適応的開発手法としてのアジャイル開発
つまり、ウォーターフォールは、状況の変化に適応するのが困難なモデルだと言えます。
そして、数ヶ月から数年という単位で計画が策定されている開発に対して、状況は必ず変化します。
適応的開発手法としてのアジャイル開発適応的開発手法としてのアジャイル開発
ウォーターフォールに代表される「計画重視開発手法」に対して、その対極にあるのが「適応的開発手法」で、その代表が「アジャイル開発」だというわけです。
なにしろ、アジャイル開発での計画は週単位であり、つねに計画を再評価し、「状況適応的に」開発を進めていくのですから。
適応的開発手法としてのアジャイル開発適応的開発手法としてのアジャイル開発
そしてさらに、アジャイル開発のチームは、たいていのばあい一箇所で顔を突き合わせて作業をし、頻繁に意思疎通を行い、メンバーとしてプログラマとクライアントを含んでいます。
適応的開発手法としてのアジャイル開発適応的開発手法としてのアジャイル開発
ユーザインタフェース設計者によるデザインは、チームリーダー（ウォーターフォールでは仕様策定者であることが多い）にお伺いをたてるまでもなく、クライアントがいい顔をするか否かという極めて直接的で時間短縮的な方法で決められます。
それでもデザイナが自分が設計したUIの優位性を主張したいならば、チームリーダーまかせにせずとも、自分がクライアントを直接説得すれば良いのです。
アジャイル開発の弱点をいかに克服していくかアジャイル開発の弱点をいかに克服していくか
ここまで、「計画重視開発手法」の代表であるウォーターフォール開発との対比で、アジャイル開発の良い点を見てきました。
しかし、「企業風土・組織的文化」がアジャイルを受け入れられない、ということからわかるように、現在でもアジャイル開発を採用している企業は極めて少ないのが現状です。
アジャイル開発の弱点をいかに克服していくかアジャイル開発の弱点をいかに克服していくか
他にも、アジャイル開発には「弱点」と言われている部分があり、議論されています。
その点をVCwareではいかにして克服していくつもりなのかを、述べてみたいと思います。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
アジャイル開発を採用するには、組織文化を大きく変えなければならない、と言われます。
したがって、自然と、アジャイル開発に親和的な組織は、ベンチャー企業のような「若い」企業ということになります。
われわれVCwareもそのひとつです。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
若い企業独自の困難として、何十年も開発に関わってきたベテラン開発者を取り込めない点があげられます。
そして、アジャイル開発が「非・計画重視」である以上、ベテラン開発者が参加する必要があるではないか、という批判があります。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
私は個人的には、必ずしもそうではない、と思いますが、
（ザッカーバーグがFacebookのベースとなるコードを書いたのは学生時代で、まったくベテラン開発者などではなかったではないですか）
ひとつアイディアがあります。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
VCwareは現時点ではまだ、法人化していません。
今後も、法人化するかどうかわかりません。
不謹慎なことを言えば、「法人化したほうが税制上有利になる」という分岐点に来た時に、タックス・ヘイブンに所在地を移すかもしれません。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
ともあれ、法人化し、正社員を雇用する、という方法論が、そもそもアジャイル開発的ではないのではないか、と感じます。
派遣社員を雇うのではありません。
個々人との、プロジェクト単位での協力契約です。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
個々人は、法人化していても構わないし、フリーランスでもかまいません。
VCwareは、彼らに、正社員としてではなく（雇用関係にあるのではなく）、協力関係者として契約料を支払います（雇用関係にはなくとも、契約関係にあります）。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
プロジェクトが終われば、VCwareと縁を切ってもかまいませんし、また次のプロジェクトで再契約してくださってもかまいません。
従来の企業には、「協力会社」という制度があり、被雇用者は、協力会社から「出向」というかたちで、本社に出勤します。この制度では、あくまでも「本社」が「上」であり、被雇用者は協力会社から賃金を支払われます。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
われわれのアイディアは、個と個の契約に基づくため「上下関係」が存在せず、「賃金の支払い」は、自分が自分に対して行うというものです（個人事業主・フリーランスの場合はVCwareからの契約料支払いがそのまま収入になり、法人化している場合は社長＝自分から社員＝自分が賃金を受け取ります）。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
「それって、ほら、いま流行り、っていうか死語？の『ノマド・ワーカー』ってやつじゃないの？」
という冷やかしがきこえてきそうですね。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
たしかにわれわれはノマド・ワーカーかもしれませんし、そうじゃないかもしれません。
でも、どちらでもいいではないですか。
「働く人」のメリットが大きければ、呼び方や、形態はどうでもいいのです。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
「個別契約では収入が安定しない」というなら、安定した法人と正規雇用契約を結べば良いのです。
そのうえで、「安定した法人」とVCware間の契約を結ぶのもよいでしょう（ただしその場合、先述した「協力会社」と変わらなくなってしまいますが。その「安定した法人」は、アジャイル開発に親和的ですか？）
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
VCwareが「次のプロジェクトでも一緒に」と申し出たとしても、「長期の旅行を計画しているので、また次の機会に」と断れるのは、大きなメリットです。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
さて、こうしたことを前提に、「ベテラン開発者」との契約を考えてみます。
企業に所属していない、かつ、有能なベテランが、ゴロゴロ転がっているとは思っていません。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
かといって、少ないとも思っていません。
ある程度有能な開発者であれば、今現在、日本の上場企業に籍を置いて満足しているとは思えません。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
大企業に在籍するメリットを享受することが、魅力的であることはたしかでしょうが、それ以上に、「自分は能力が高い」と認識している開発者（彼は自分を「プログラマ」か「ハッカー」だと思っているでしょう）が、中間管理職のような立場に満足するとも思えません。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
多くの自称「たんなるプログラマ」の大半が独立しているのではないでしょうか。
クライアントが名前を聞いただけで飛びついてくるような、名前の通った著名人である必要はありません。
熟練した開発者が組織内にいない場合どうするか熟練した開発者が組織内にいない場合どうするか
VCwareとしては、フットワークの軽い、そして有能なベテランと、積極的に接触していきたいと思っています。
ベテランとの仕事は、われわれに大きな財産を残してくれるでしょうから。
開発者が遠隔地に散らばっている場合はどうするか開発者が遠隔地に散らばっている場合はどうするか
アジャイル開発の基本的パターンとして、「場所を同じくし、顔を突き合わせること」があげられます。
そうすると、プログラマがアメリカに、クライアントがスイスに、VCwareが福島に、というような場合、困難が生じます。
開発者が遠隔地に散らばっている場合はどうするか開発者が遠隔地に散らばっている場合はどうするか
これは解決が比較的容易で、Skypeとco-meeting（http://www.co-meeting.com） が解決すると思います。
「時差があるではないか」と思われるかもしれませんが、重要なミーティングは、われわれの場合、1日に1回でよい、と考えています。
開発者が遠隔地に散らばっている場合はどうするか開発者が遠隔地に散らばっている場合はどうするか
むしろ、プログラマの「フロー状態」を壊したくありません。
メールや電話、Skypeの呼び出しは、作業中は一切禁止します。
開発者が遠隔地に散らばっている場合はどうするか開発者が遠隔地に散らばっている場合はどうするか
もちろん、外部からの連絡（仕事の依頼など）はひっきりなしにあることが望ましいでしょう。
そういったものは、私が個人的に引き受けます。
プログラマは、私によってサマライズされたメール一通を、作業の合間に読むだけです。
開発者が遠隔地に散らばっている場合はどうするか開発者が遠隔地に散らばっている場合はどうするか
「定時ミーティング」も可能な限りなくします。
いつ、「フロー状態」にプログラマが突入するかはわかりませんし、いったん「フロー状態」に入ったならば、その妨害を可能な限り排除するのが私の役目です。
開発者が遠隔地に散らばっている場合はどうするか開発者が遠隔地に散らばっている場合はどうするか
そうやって切り詰めてゆくと、1日に1回の重要なミーティングの濃度が増します。アジャイル開発においてはなおさらです（ミーティングですべての計画が明らかになるのですから）。
開発者が遠隔地に散らばっている場合はどうするか開発者が遠隔地に散らばっている場合はどうするか
とはいえ、クライアントと私は、常に顔をつきあわせているべきだと思います。
クライアントと私（共にチームの一員です）は、1日8時間ミーティングをし、そこに飛び込んでくるUIデザインの見本を、40秒以内に判断します。判断に不服があれば、デザイナもそこに加わって、3分間プレゼンをします（オンラインで、かもしれません）。
密接なコミュニケーション、 密接なコミュニケーション、 日本人に、発達障がい者に可能か 日本人に、発達障がい者に可能か
アジャイル開発では、つねに顔を突き合わせたチームが、ひっきりなしに意思疎通をはかります。
計画の文書化が少ないためです（適応的に、計画は更新されなければならないので、文書化にかけるリソースも、メリットもないのです）。
密接なコミュニケーション、 密接なコミュニケーション、 日本人に、発達障がい者に可能か 日本人に、発達障がい者に可能か
さて、このような組織文化は、日本人に受け入れ可能でしょうか？
密接なコミュニケーション、 密接なコミュニケーション、 日本人に、発達障がい者に可能か 日本人に、発達障がい者に可能か
さらにいえば、VCwareは、VirtuousCycle Inc.の子会社です。VirutuousCycle Inc.では、RyoJunKanという、自立支援施設を運営しています。
そこでは、不登校・引きこもり・ニートといった「症状」をかかえた、高機能自閉症（アスペルガー症候群）や発達障がいといった「特性」を持つ人々の自立を支援しています。
密接なコミュニケーション、 密接なコミュニケーション、 日本人に、発達障がい者に可能か 日本人に、発達障がい者に可能か
VCwareは、RyoJunKanでジョブ・トレーニングをし、「卒業」した人々の雇用先としても機能します。
さて、特に「コミュニケーション」に対する苦手意識を持つ発達障がい者たちにとって、このような組織は苦痛でしかないのでしょうか？
密接なコミュニケーション、 密接なコミュニケーション、 日本人に、発達障がい者に可能か 日本人に、発達障がい者に可能か
ここで、われわれが必要とする「コミュニケーション・スキル」に関する誤解をとかねばなりません。
アジャイル開発に必要なコミュニケーション・スキルは、
密接なコミュニケーション、 密接なコミュニケーション、 日本人に、発達障がい者に可能か 日本人に、発達障がい者に可能か
1) 自分にも相手にも了解可能な日本語あるいは英語による発話と聞き取り
2) アサーティブであること（自分と相手を大切にすること）
このふたつだけです。
密接なコミュニケーション、 密接なコミュニケーション、 日本人に、発達障がい者に可能か 日本人に、発達障がい者に可能か
RyoJunKanでは全員に「アサーション・トレーニング」プログラムを課しており、その卒業生は、一般的日本人よりもはるかに「アサーティブなコミュニケーション」に長けています。
密接なコミュニケーション、 密接なコミュニケーション、 日本人に、発達障がい者に可能か 日本人に、発達障がい者に可能か
挨拶なんかしなくたっていいのです（してもいいですが）。
相手の目なんか見られなくともよいのです（アサーション・トレーニングを受けると、それでも「見られるようになってしまう」のですが）。
「上司の前や就職の面接では足を組んではいけない」などという日本独自の文化なぞ、くたばってしまえばよいのです。
密接なコミュニケーション、 密接なコミュニケーション、 日本人に、発達障がい者に可能か 日本人に、発達障がい者に可能か
この「アサーティブなコミュニケーション」というのが、RyoJunKanを卒業したわけではないパートナーにとっては、よくわからないところかもしれません。
そこはぜひ、RyoJunKan卒業生を観察し、学んでみてください。
密接なコミュニケーション、 密接なコミュニケーション、 日本人に、発達障がい者に可能か 日本人に、発達障がい者に可能か
VCwareで特別研修会をひらいて、アサーション・トレーニングを行なってみるのもよいかもしれません。
「コーチング」みたいに自己啓発セミナーのようなものとは違って、怪しいものではないので、ご心配なさらずに（「コーチング」一般を否定はしません。私も個人的に「やる気」をむりやり引き出すためにコーチングを必要とすることもあります）。
クリティカルなシステムへの対応クリティカルなシステムへの対応
最後に、アジャイル開発への批判として議論される、この点について、われわれの考えを述べたいと思います。
クリティカルなシステムへの対応クリティカルなシステムへの対応
アジャイル開発は一般的に、クリティカルなシステム、つまり、クライアント（ユーザー）の業務に重大な支障をきたす可能性がある、もしくは人命に関わるシステムの開発には向いていない、と言われています。
クリティカルなシステムへの対応クリティカルなシステムへの対応
しかし、それは真実なのでしょうか？
ウォーターフォールのもつ「重量」が、「クリティカル」なシステムの持つシリアスさに「見た感じ釣り合っている」というほどの批判にしか思えません。
クリティカルなシステムへの対応クリティカルなシステムへの対応
もちろん、たった1週間でリリースされるビルドで、人命を救うことができるとは思いません。
たしかに、コーディングは雑であり、「ミッション」に「計画性」をもって挑むというよりは、混沌とした状況に挑むといったほうがふさわしいかもしれません。
クリティカルなシステムへの対応クリティカルなシステムへの対応
しかし、「クリティカルなシステム」のうち、それほど「重大」なものは、そのシステムの中の何分の一なのでしょうか？
クリティカルなシステムへの対応クリティカルなシステムへの対応
ウォーターフォールでは、jQueryによるそのコーディングがIE6に対応しているか否か、ということと、誰かの手作業による不注意でデータベースの中身がすべてバックアップも含めて消えてなくなる、ということを、まったく同じ深刻さで扱います。
そのようにしか動けないのがウォーターフォールです。
クリティカルなシステムへの対応クリティカルなシステムへの対応
アジャイル開発の何よりも強調されてしかるべき点は、常時、全メンバーが、計画と優先度を評価し続ける、という点です。
クリティカルなシステムへの対応クリティカルなシステムへの対応
このとき、何が重大で、何が後回しにされるべきなのか、何を「コア」とするべきであり、何を「付随的な機能」とするべきなのか、といったことがらを、「人間的かつ常識的に」判断できる状況にあるはずです。
クリティカルなシステムへの対応クリティカルなシステムへの対応
私が日頃苦々しく感じていることのひとつに、外国為替証拠金取引口座（日本ではFX、海外ではFOREX）のUXがあります。
クリティカルなシステムへの対応クリティカルなシステムへの対応
FXはクリティカルなシステムです。
大量の顧客のIDと現金を扱い、さらにレバレッジを計算し、インターバンク取引と同期し、オンラインバンクとのクイック入金システムをセキュアに完結させなければなりません。
クリティカルなシステムへの対応クリティカルなシステムへの対応
明らかに、「コア」はその部分です。
「コア」は何度も何度もテストされなければならず、サーバは何重にも同期して安定したシステムを提供できなければならず、データベースは世界各地にデータセンターを分散して強力なRAIDを組まなければなりません。
クリティカルなシステムへの対応クリティカルなシステムへの対応
さらにネットワーク・セキュリティの専門家がチームにいなければならず、法務の専門家の協力も必要です。
クリティカルなシステムへの対応クリティカルなシステムへの対応
ここで強調したいのは、こうしたことが「クリティカル」なのだ、ということを「知る」ことができるのは、アジャイル的環境においてのみだということです。
クリティカルなシステムへの対応クリティカルなシステムへの対応
ウォーターフォールの中では、ここに手作業の要素が入り込むとユーザーが死に至る、という問題と、IEだとJavaScriptでstr[0]のような書き方をしても文字列の1文字目を取り出せないことがよくある、という問題のどちらが「重大」なのか、区別ができません。
クリティカルなシステムへの対応クリティカルなシステムへの対応
逆にいえば、ウォーターフォールがそうした区別をせずに済んでいるのは、最初の要件定義の時点で、仕様書策定者が（アジャイル的に）人間的な判断をしているからにすぎません。
クリティカルなシステムへの対応クリティカルなシステムへの対応
私の言いたいことを言いましょう。
なぜ、こんなにFX業者が乱立しているのに、どこも「100％！完璧！君に決めた！」と言える基本インターフェースを提供できないでいるのでしょうか？
クリティカルなシステムへの対応クリティカルなシステムへの対応
私の推測ですが、日本のFXシステムは、コアの部分がウォーターフォールで作成され、UXにかかわる付随的な部分がアジャイル的に作成されているのではないでしょうか。
クリティカルなシステムへの対応クリティカルなシステムへの対応
ひょっとしたら、別の開発会社が担当しているのかもしれません。
だから、ユーザーを混乱に陥れるしかない、あまりにも多種多様で、ベースとなる技術もてんでバラバラなシステムがグロテスクにも出来上がってしまうのではないでしょうか？
クリティカルなシステムへの対応クリティカルなシステムへの対応
（なにしろ、ログイン画面でFlash版かAjax版かを選択させておきながら、Ajax版で開いたUIで「プレミアチャート」をプルダウンして選択すると、JAVA Web Startの実行ファイルがその都度ダウンロードされ、アプレットUIが展開してしまうのですから！そりゃタスクマネージャのメモリ使用率も90％を超えるというものです）
クリティカルなシステムへの対応クリティカルなシステムへの対応
アジャイル開発であれば、まず「コア」の仕様から考え、たとえば、使用する技術をRuby on Railsに統一することを決定します。
クリティカルなシステムへの対応クリティカルなシステムへの対応
そしてデータベース処理のコアシステムを4週間でリリースするでしょう。
次の4週間で、ネットワーク・セキュリティのコア・システムをリリースするでしょう。
クリティカルなシステムへの対応クリティカルなシステムへの対応
アジャイルの重要な点は、この4週間のうちに、その前の工程でリリースされたDB処理システムのバージョン2もビルドされるということです。並行作業が可能だからです。
クリティカルなシステムへの対応クリティカルなシステムへの対応
ベースとなる技術が決定されており（根本から見直すことも可能です。クライアントを含むチームのコンセンサスがあるからです）、DBチームとネットワークチームのように分割されてもいないので、コアの部分から派生して、きわめて一貫したシステム構築がなされます。
クリティカルなシステムへの対応クリティカルなシステムへの対応
FXはいわば流行りものです。開発開始から1年後に、クライアントがUXに対する不満をもらすかもしれません。新しいUIをおまけのようにリリースすることなどせずに、UXの根本から見直し作業が始まります。コアの部分がチーム全体に対して隠蔽されていないので、根本的な作業が可能です。もしかしたら次の週にはログインシーケンス自体が完全に変更されているかもしれません。
結語結語
最後の方は、なんだか私の個人的うらみつらみになってしまいました。
結語結語
なにしろ、ブラウザの通常ログインでは外為ジャパンのUIが最高。でもシンプル過ぎて、テクニカル指標がない（それが欲しければjnlpファイルをダウンロードして実行しなければならない）。
結語結語
デスクトップアプリとしてはDMM.comが最高。でも成行注文しかできない。
外為どっとコム（外為ネクスト）はブラウザのUIが最悪。でもiPadアプリはこれ以上なく最高！
FXブロードネットはログインシーケンスとその後のUIがありえない！最悪！でもスプレッドはすごく狭くて業界最安値。
結語結語
AndroidアプリはDMM.comもみんなのFX（トレイダーズ証券）も外為ネクストもがんばってる。なかなかいい！……あれ？DMMとトレイダーズのUI、まったく同じなんですけど……こういうのって著作権とかあるんじゃ……あ！おなじところが開発してるのか！
結語結語
経済指標はどこもろくなアラート方式を採用してない。自分でGoogleアラートを設定したほうが全然マシ！
……という状況なのですから。
結語結語
「自分だったらこうするのにな」という思いは、あらゆるシステム開発の基本にあるはずです。
今の世の中、「誰の得にもなっていない」モノで溢れかえっていませんか？
結語結語
それもこれも、重厚で官僚的な、「計画重視」な風土が生み出しているのではないでしょうか。
結語結語
われわれは、ITで世界を変えられる、とはまでは思っていません。
でも、「アジャイルで世界を変えるんだ！」という意気込みは持っているのです。
結語結語
これを読んだあなたも、一緒に「世直し」しませんか？
VCware
