SlideShare a Scribd company logo
1 of 112
Download to read offline
アジャイルソフトウェア開発とは?


     VCwareが採用している
   「アジャイルソフトウェア開発」
   について、簡単な解説をします。
 要約

       アジャイルソフトウェア開発
      (agile software development)
                                     とは、
1990年代頃から考案されてきた
        軽量な開発手法群の総称
                     です
                       
(もともとこれは
      「軽量ソフトウェア開発手法」
               とよばれていました)
 要約

 これは「ウォーターフォール開発」に代表されるよ
 うな「計画重視の開発手法」の対極に位置します。
 そもそもこれは、「重量ソフトウェア開発手法」に
 対する反対運動として発展してきました。

 アジャイル          ウォーターフォール


 適応的開発手法        計画重視の開発手法
   =




                    =
軽量ソフトウェア開発手法   重量ソフトウェア開発手法
 要約

「ウォーターフォール開発」と異なり、アジャイル
ソフトウェア開発では、プロジェクトの開始時点に
おいて、あらかじめ詳細にわたる要件定義書(仕様
書)のような文書を作成せず、長期的な開発計画を
たてません。
 要約

アジャイル開発では、反復(iteration)とよばれる短
い期間に、開発対象の一部分(ビルド)のみを、「完
全に動く形で」リリースします。

この期間は、1週間から4週間程度です。

要件定義・設計・コーディング・テスト、などの、
ウォーターフォール・モデルが数ヶ月から数年の間に
行う全工程を、この反復内ですべて完結させます。
 要約

ひとつの反復が終わったら、チームは前反復を振り
返って見直し、プロジェクトの優先順位を評価しな
おします。




                    以上。
……などと概要のみを提示されても、
よくわかりませんよね。


では、「アジャイルソフトウェア開発」の対極にある、
「ウォーターフォール開発」をかんたんに解説しながら、
それのどこがまずいのか、


対するアジャイルはどのように優位であるのかについて、
述べたいと思います。
ちなみに、私(斉藤)は2001年に「基本情報技術者」を
取得しましたが、教科書で
    「ソフトウェアの開発とはこうやるのだ」
と断言されていたのが、「ウォーターフォール開発」です
(いまの教科書にはどのように書いてあるのでしょう
ね?)
 ウォーターフォール開発の概要

「ウォーターフォール・モデル」とは、
文字通り「滝」を意味しています。


 プロジェクト全体をいくつかの工程に分割し、
 計画にそって、
 ある工程が完全に終結したら、
 次の工程へと進む、


というモデルです。
 ウォーターフォール開発の概要

  要件定義               ひとつの工程が
                     終結したら
    外部設計
                     次の工程へ進む
     内部設計

     実装(コーディング)

            テスト

             運用・保守
 ウォーターフォールは戻らない

ウォーターフォール開発では、原則的にひとつの工
程が完了しない限り、次の工程に進みません。


したがって、設計中にコーディングを行うといった
「並行作業」もありえません。


このように、線形に開発が進むので、ガントチャー
トのような「線表(棒グラフ)」をもちいてプロ
ジェクト管理をします。
 ウォーターフォールは戻らない

こうしたことからわかるように、
ウォーターフォール開発では、


  前工程に間違いがないことを前提


としています。


そしてそこが問題点のひとつでもあります。
 ガントチャートの例




(引用元:ITPRO「WBSを使った作業計画と
 スケジュール作成の実践知識(2)」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

More Related Content

What's hot

シナリオテストについて考えてみる
シナリオテストについて考えてみるシナリオテストについて考えてみる
シナリオテストについて考えてみるtef-do
 
OWIN って何?
OWIN って何?OWIN って何?
OWIN って何?miso- soup3
 
他人が書いたコードのリファレンスをSphinxで作る方法
他人が書いたコードのリファレンスをSphinxで作る方法他人が書いたコードのリファレンスをSphinxで作る方法
他人が書いたコードのリファレンスをSphinxで作る方法Takeshi Sugiyama
 
テストマネージャ試験対策勉強会
テストマネージャ試験対策勉強会テストマネージャ試験対策勉強会
テストマネージャ試験対策勉強会Kosuke Fujisawa
 
テストアプローチにデータ分析を使おう
テストアプローチにデータ分析を使おうテストアプローチにデータ分析を使おう
テストアプローチにデータ分析を使おうSayaka Nakano
 
リレーショナルな正しいデータベース設計
リレーショナルな正しいデータベース設計リレーショナルな正しいデータベース設計
リレーショナルな正しいデータベース設計Mikiya Okuno
 
起業家的?!エンジニアのススメ | Developer Summit 2020
起業家的?!エンジニアのススメ | Developer Summit 2020起業家的?!エンジニアのススメ | Developer Summit 2020
起業家的?!エンジニアのススメ | Developer Summit 2020SORACOM,INC
 
オブジェクト指向アンチパターンを考えてみた
オブジェクト指向アンチパターンを考えてみたオブジェクト指向アンチパターンを考えてみた
オブジェクト指向アンチパターンを考えてみたTakuya Kawabe
 
オープンソースを用いたドローンの自律制御ソフトウェア技術
オープンソースを用いたドローンの自律制御ソフトウェア技術オープンソースを用いたドローンの自律制御ソフトウェア技術
オープンソースを用いたドローンの自律制御ソフトウェア技術Masayuki Isobe
 
[JJUG CCC 2021 Spring]Eclipse ユーザのための VSCode のススメ
[JJUG CCC 2021 Spring]Eclipse ユーザのための VSCode のススメ[JJUG CCC 2021 Spring]Eclipse ユーザのための VSCode のススメ
[JJUG CCC 2021 Spring]Eclipse ユーザのための VSCode のススメSatoshi Takami
 
オープンデータを使って地図を作ろう|QGIS 活用講座(初級編)
オープンデータを使って地図を作ろう|QGIS 活用講座(初級編)オープンデータを使って地図を作ろう|QGIS 活用講座(初級編)
オープンデータを使って地図を作ろう|QGIS 活用講座(初級編)Yu Imai
 
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacateKinji Akemine
 
ROSによる今後のロボティクスのあり方
ROSによる今後のロボティクスのあり方ROSによる今後のロボティクスのあり方
ROSによる今後のロボティクスのあり方Mori Ken
 
 〜デザイン初心者向け〜
 デザイン時に気をつけると幸せになれる事
 〜デザイン初心者向け〜
 デザイン時に気をつけると幸せになれる事 〜デザイン初心者向け〜
 デザイン時に気をつけると幸せになれる事
 〜デザイン初心者向け〜
 デザイン時に気をつけると幸せになれる事kenji goto
 
つくらない ものづくり ~明日からできるリーンスタートアップ~
つくらない ものづくり ~明日からできるリーンスタートアップ~つくらない ものづくり ~明日からできるリーンスタートアップ~
つくらない ものづくり ~明日からできるリーンスタートアップ~圭 進藤
 
CSカレッジアワード 出題者:ヘイ株式会社さま 水木絵梨
CSカレッジアワード 出題者:ヘイ株式会社さま 水木絵梨CSカレッジアワード 出題者:ヘイ株式会社さま 水木絵梨
CSカレッジアワード 出題者:ヘイ株式会社さま 水木絵梨EriMizuki1
 
コミュニケーション設計をおざなりにしない!(コンセント 笹原 舞)
コミュニケーション設計をおざなりにしない!(コンセント 笹原 舞)コミュニケーション設計をおざなりにしない!(コンセント 笹原 舞)
コミュニケーション設計をおざなりにしない!(コンセント 笹原 舞)Concent, Inc.
 
التفكير العلمي عند ابن الهيثم
التفكير العلمي عند ابن الهيثمالتفكير العلمي عند ابن الهيثم
التفكير العلمي عند ابن الهيثمibrahim ELANANI
 
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かうソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう増田 亨
 

What's hot (20)

シナリオテストについて考えてみる
シナリオテストについて考えてみるシナリオテストについて考えてみる
シナリオテストについて考えてみる
 
OWIN って何?
OWIN って何?OWIN って何?
OWIN って何?
 
他人が書いたコードのリファレンスをSphinxで作る方法
他人が書いたコードのリファレンスをSphinxで作る方法他人が書いたコードのリファレンスをSphinxで作る方法
他人が書いたコードのリファレンスをSphinxで作る方法
 
テストマネージャ試験対策勉強会
テストマネージャ試験対策勉強会テストマネージャ試験対策勉強会
テストマネージャ試験対策勉強会
 
テストアプローチにデータ分析を使おう
テストアプローチにデータ分析を使おうテストアプローチにデータ分析を使おう
テストアプローチにデータ分析を使おう
 
リレーショナルな正しいデータベース設計
リレーショナルな正しいデータベース設計リレーショナルな正しいデータベース設計
リレーショナルな正しいデータベース設計
 
起業家的?!エンジニアのススメ | Developer Summit 2020
起業家的?!エンジニアのススメ | Developer Summit 2020起業家的?!エンジニアのススメ | Developer Summit 2020
起業家的?!エンジニアのススメ | Developer Summit 2020
 
オブジェクト指向アンチパターンを考えてみた
オブジェクト指向アンチパターンを考えてみたオブジェクト指向アンチパターンを考えてみた
オブジェクト指向アンチパターンを考えてみた
 
オープンソースを用いたドローンの自律制御ソフトウェア技術
オープンソースを用いたドローンの自律制御ソフトウェア技術オープンソースを用いたドローンの自律制御ソフトウェア技術
オープンソースを用いたドローンの自律制御ソフトウェア技術
 
[JJUG CCC 2021 Spring]Eclipse ユーザのための VSCode のススメ
[JJUG CCC 2021 Spring]Eclipse ユーザのための VSCode のススメ[JJUG CCC 2021 Spring]Eclipse ユーザのための VSCode のススメ
[JJUG CCC 2021 Spring]Eclipse ユーザのための VSCode のススメ
 
Node-REDからREST APIに接続
Node-REDからREST APIに接続Node-REDからREST APIに接続
Node-REDからREST APIに接続
 
オープンデータを使って地図を作ろう|QGIS 活用講座(初級編)
オープンデータを使って地図を作ろう|QGIS 活用講座(初級編)オープンデータを使って地図を作ろう|QGIS 活用講座(初級編)
オープンデータを使って地図を作ろう|QGIS 活用講座(初級編)
 
60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate60分でわかった気になるISO29119 #wacate
60分でわかった気になるISO29119 #wacate
 
ROSによる今後のロボティクスのあり方
ROSによる今後のロボティクスのあり方ROSによる今後のロボティクスのあり方
ROSによる今後のロボティクスのあり方
 
 〜デザイン初心者向け〜
 デザイン時に気をつけると幸せになれる事
 〜デザイン初心者向け〜
 デザイン時に気をつけると幸せになれる事 〜デザイン初心者向け〜
 デザイン時に気をつけると幸せになれる事
 〜デザイン初心者向け〜
 デザイン時に気をつけると幸せになれる事
 
つくらない ものづくり ~明日からできるリーンスタートアップ~
つくらない ものづくり ~明日からできるリーンスタートアップ~つくらない ものづくり ~明日からできるリーンスタートアップ~
つくらない ものづくり ~明日からできるリーンスタートアップ~
 
CSカレッジアワード 出題者:ヘイ株式会社さま 水木絵梨
CSカレッジアワード 出題者:ヘイ株式会社さま 水木絵梨CSカレッジアワード 出題者:ヘイ株式会社さま 水木絵梨
CSカレッジアワード 出題者:ヘイ株式会社さま 水木絵梨
 
コミュニケーション設計をおざなりにしない!(コンセント 笹原 舞)
コミュニケーション設計をおざなりにしない!(コンセント 笹原 舞)コミュニケーション設計をおざなりにしない!(コンセント 笹原 舞)
コミュニケーション設計をおざなりにしない!(コンセント 笹原 舞)
 
التفكير العلمي عند ابن الهيثم
التفكير العلمي عند ابن الهيثمالتفكير العلمي عند ابن الهيثم
التفكير العلمي عند ابن الهيثم
 
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かうソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう
 

Similar to What's Agile?

アジャイルプラクティス導入事例
アジャイルプラクティス導入事例アジャイルプラクティス導入事例
アジャイルプラクティス導入事例Shun Tsunoda
 
バイオインフォマティクスのための開発基礎知識
バイオインフォマティクスのための開発基礎知識バイオインフォマティクスのための開発基礎知識
バイオインフォマティクスのための開発基礎知識丈 宮本
 
アジャイルとかDevOpsとかことばの整理
アジャイルとかDevOpsとかことばの整理アジャイルとかDevOpsとかことばの整理
アジャイルとかDevOpsとかことばの整理Osamu Watanabe
 
開発サイクルを爆速にする!~ Azure DevOpsでアプリのビルド・デプロイを自動化 ~
開発サイクルを爆速にする!~ Azure DevOpsでアプリのビルド・デプロイを自動化 ~開発サイクルを爆速にする!~ Azure DevOpsでアプリのビルド・デプロイを自動化 ~
開発サイクルを爆速にする!~ Azure DevOpsでアプリのビルド・デプロイを自動化 ~KojiKono1
 
勉強会用資料:Javaアプリ作成
勉強会用資料:Javaアプリ作成勉強会用資料:Javaアプリ作成
勉強会用資料:Javaアプリ作成ssuser331f24
 
Visualizing Software Development
Visualizing Software DevelopmentVisualizing Software Development
Visualizing Software DevelopmentKenji Hiranabe
 
独学でVueを勉強した勢いで 自社アプリをリプレイスした話_kng#4
独学でVueを勉強した勢いで自社アプリをリプレイスした話_kng#4独学でVueを勉強した勢いで自社アプリをリプレイスした話_kng#4
独学でVueを勉強した勢いで 自社アプリをリプレイスした話_kng#4Ryosuke Izumi
 
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)Developers Summit
 
Dev rel first step ベンチャー&内資のレアケース
Dev rel first step ベンチャー&内資のレアケースDev rel first step ベンチャー&内資のレアケース
Dev rel first step ベンチャー&内資のレアケースRyoKawamata
 
Sustainable Software Development
Sustainable Software DevelopmentSustainable Software Development
Sustainable Software DevelopmentKenji Hiranabe
 
SharePoint 2013 ワークフロー開発入門
SharePoint 2013 ワークフロー開発入門SharePoint 2013 ワークフロー開発入門
SharePoint 2013 ワークフロー開発入門Hiroaki Oikawa
 
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発Makoto SAKAI
 
第1回Web屋にとってのWindows Azureとは?
第1回Web屋にとってのWindows Azureとは?第1回Web屋にとってのWindows Azureとは?
第1回Web屋にとってのWindows Azureとは?WebSig24/7
 
アジャイルマニフェストから見るインセプションデッキ
アジャイルマニフェストから見るインセプションデッキアジャイルマニフェストから見るインセプションデッキ
アジャイルマニフェストから見るインセプションデッキYou&I
 
営業さんに知ってほしいアジャイルの勘所 R2
営業さんに知ってほしいアジャイルの勘所 R2営業さんに知ってほしいアジャイルの勘所 R2
営業さんに知ってほしいアジャイルの勘所 R2Shinsuke Matsuki
 
XP祭り2016 - SWチームとHWチームがスクラムを組んだら
XP祭り2016 - SWチームとHWチームがスクラムを組んだらXP祭り2016 - SWチームとHWチームがスクラムを組んだら
XP祭り2016 - SWチームとHWチームがスクラムを組んだらLife Robotics
 
DevOpsが引き金となるインフラエンジニアの進撃
DevOpsが引き金となるインフラエンジニアの進撃DevOpsが引き金となるインフラエンジニアの進撃
DevOpsが引き金となるインフラエンジニアの進撃Teruo Adachi
 

Similar to What's Agile? (20)

azyair
azyairazyair
azyair
 
アジャイルプラクティス導入事例
アジャイルプラクティス導入事例アジャイルプラクティス導入事例
アジャイルプラクティス導入事例
 
バイオインフォマティクスのための開発基礎知識
バイオインフォマティクスのための開発基礎知識バイオインフォマティクスのための開発基礎知識
バイオインフォマティクスのための開発基礎知識
 
アジャイルとかDevOpsとかことばの整理
アジャイルとかDevOpsとかことばの整理アジャイルとかDevOpsとかことばの整理
アジャイルとかDevOpsとかことばの整理
 
開発サイクルを爆速にする!~ Azure DevOpsでアプリのビルド・デプロイを自動化 ~
開発サイクルを爆速にする!~ Azure DevOpsでアプリのビルド・デプロイを自動化 ~開発サイクルを爆速にする!~ Azure DevOpsでアプリのビルド・デプロイを自動化 ~
開発サイクルを爆速にする!~ Azure DevOpsでアプリのビルド・デプロイを自動化 ~
 
C#
C#C#
C#
 
勉強会用資料:Javaアプリ作成
勉強会用資料:Javaアプリ作成勉強会用資料:Javaアプリ作成
勉強会用資料:Javaアプリ作成
 
Visualizing Software Development
Visualizing Software DevelopmentVisualizing Software Development
Visualizing Software Development
 
独学でVueを勉強した勢いで 自社アプリをリプレイスした話_kng#4
独学でVueを勉強した勢いで自社アプリをリプレイスした話_kng#4独学でVueを勉強した勢いで自社アプリをリプレイスした話_kng#4
独学でVueを勉強した勢いで 自社アプリをリプレイスした話_kng#4
 
Pivotal Tracker概略
Pivotal Tracker概略Pivotal Tracker概略
Pivotal Tracker概略
 
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
 
Dev rel first step ベンチャー&内資のレアケース
Dev rel first step ベンチャー&内資のレアケースDev rel first step ベンチャー&内資のレアケース
Dev rel first step ベンチャー&内資のレアケース
 
Sustainable Software Development
Sustainable Software DevelopmentSustainable Software Development
Sustainable Software Development
 
SharePoint 2013 ワークフロー開発入門
SharePoint 2013 ワークフロー開発入門SharePoint 2013 ワークフロー開発入門
SharePoint 2013 ワークフロー開発入門
 
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発
UAS5 アジャイル開発に学んだアダプタブルウォーターフォール開発
 
第1回Web屋にとってのWindows Azureとは?
第1回Web屋にとってのWindows Azureとは?第1回Web屋にとってのWindows Azureとは?
第1回Web屋にとってのWindows Azureとは?
 
アジャイルマニフェストから見るインセプションデッキ
アジャイルマニフェストから見るインセプションデッキアジャイルマニフェストから見るインセプションデッキ
アジャイルマニフェストから見るインセプションデッキ
 
営業さんに知ってほしいアジャイルの勘所 R2
営業さんに知ってほしいアジャイルの勘所 R2営業さんに知ってほしいアジャイルの勘所 R2
営業さんに知ってほしいアジャイルの勘所 R2
 
XP祭り2016 - SWチームとHWチームがスクラムを組んだら
XP祭り2016 - SWチームとHWチームがスクラムを組んだらXP祭り2016 - SWチームとHWチームがスクラムを組んだら
XP祭り2016 - SWチームとHWチームがスクラムを組んだら
 
DevOpsが引き金となるインフラエンジニアの進撃
DevOpsが引き金となるインフラエンジニアの進撃DevOpsが引き金となるインフラエンジニアの進撃
DevOpsが引き金となるインフラエンジニアの進撃
 

Recently uploaded

TokyoTechGraduateExaminationPresentation
TokyoTechGraduateExaminationPresentationTokyoTechGraduateExaminationPresentation
TokyoTechGraduateExaminationPresentationYukiTerazawa
 
TEAMIN Service overview for customer_20240422.pdf
TEAMIN Service overview for customer_20240422.pdfTEAMIN Service overview for customer_20240422.pdf
TEAMIN Service overview for customer_20240422.pdfyukisuga3
 
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学ssusere0a682
 
UniProject Workshop Make a Discord Bot with JavaScript
UniProject Workshop Make a Discord Bot with JavaScriptUniProject Workshop Make a Discord Bot with JavaScript
UniProject Workshop Make a Discord Bot with JavaScriptyuitoakatsukijp
 
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2Tokyo Institute of Technology
 
The_Five_Books_Overview_Presentation_2024
The_Five_Books_Overview_Presentation_2024The_Five_Books_Overview_Presentation_2024
The_Five_Books_Overview_Presentation_2024koheioishi1
 

Recently uploaded (6)

TokyoTechGraduateExaminationPresentation
TokyoTechGraduateExaminationPresentationTokyoTechGraduateExaminationPresentation
TokyoTechGraduateExaminationPresentation
 
TEAMIN Service overview for customer_20240422.pdf
TEAMIN Service overview for customer_20240422.pdfTEAMIN Service overview for customer_20240422.pdf
TEAMIN Service overview for customer_20240422.pdf
 
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学
ゲーム理論 BASIC 演習105 -n人囚人のジレンマモデル- #ゲーム理論 #gametheory #数学
 
UniProject Workshop Make a Discord Bot with JavaScript
UniProject Workshop Make a Discord Bot with JavaScriptUniProject Workshop Make a Discord Bot with JavaScript
UniProject Workshop Make a Discord Bot with JavaScript
 
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2
東京工業大学 環境・社会理工学院 建築学系 大学院入学入試・進学説明会2024_v2
 
The_Five_Books_Overview_Presentation_2024
The_Five_Books_Overview_Presentation_2024The_Five_Books_Overview_Presentation_2024
The_Five_Books_Overview_Presentation_2024
 

What's Agile?