Comments
Description
Transcript
アジャイル開発の現状と未来 エンタープライズアジャイルの可能性
アジャイル開発の現状と未来 エンタープライズアジャイルの可能性 永和システムマネジメント副社長 チェンジビジョン代表 平鍋健児 https://www.flickr.com/photos/71380981@N06/14548343789/ https://www.flickr.com/photos/rapidliner/13563166414/ https://www.flickr.com/photos/78797573@N00/8867428603/ https://www.flickr.com/photos/dailuo/5527858164/ 自己紹介 • ㈱永和システムマネジメント • 株式会社チェンジビジョン • 平鍋健児 – 福井市(本社)、上野東京(支社) – Ruby と Agileを使ったシステム開発 – 福井市(開発部)、上野東京(本社) – astah* (旧:JUDE) の開発 – UML+マインドマップエディタ astah*の開発 – 要求開発アライアンス、理事 – 翻訳、XP関連書籍、『リーン開発の本質』 『IMPACT MAPPING』等多数。 – 著書『アジャイル開発とスクラム』、『要求開発』 『ソフトウェア開発に役立つマインドマップ』 p.5 アジェンダ • • • • • アジャイルの現在位置 Agile2014 を覗いてみる。 SAFe DAD 日本で考える アジャイルの現在位置 2000 Evo 2001 2010 2014 FDD, Crystal, DSDM, ASD LeanStartup Patterns XP •大規模 •組織改革 •Lean/Agile •Agile/UX Agile SCRUM Lean Software Development 野中・竹内 TPS Lean Deming Kanban Agile2014 世界最大のアジャイルカンファレンス、Agile2014 Agile20xxは、複数のトラックに分かれており、 それぞれのトラックにチェアーがいる。 Enterprise Agile はそのうち1トラック。 大企業でのアジャイルに関連した課題 1チームの実践事例ではなく、 企業全体の組織構造、アジャイルを導入する パターン、方針、実践手法 扱う課題群 エンタープライズアジャイル • • • • • • • 大企業(企業のサイズ)、 「チーム」から「組織」へ、 Agile Transformation(組織変革) ITを超えてアジャイルを採用、 管理職の役割は? 人事査定は? オフショアやアトソーシングは? 伊藤さんの参加レポート 出典: http://www.slideshare.net/ssuser968fab/agile2014-report-as-a-speaker-and-a-reporter-of-the-latest-agile-in-the-world 出典: http://www.slideshare.net/ssuser968fab/agile2014-report-as-a-speaker-and-a-reporter-of-the-latest-agile-in-the-world 伊藤さんの考察: • 実践者の関心の変化(開発チーム内の改善から組織全体の改善へ)。 • これまでのほとんどの提案は概念論。マインドセットの変革の重要性を説く。 • SAFe の影響が大きいく及んだ(5つのセッション) 出典: http://www.slideshare.net/ssuser968fab/agile2014-report-as-a-speaker-and-a-reporter-of-the-latest-agile-in-the-world Dean Leffingwell SAFe 2大 Enterprise Agile Framework SAFe=Scaled Agile Framework DAD = Disciplined Agile Delivery • Dean Leffingwell • Scott W. Ambler 出典: http://schd.ws/hosted_files/agile2014/24/1602_Agile_2014_Leadership_(no_video)_(2).pdf 参考 出典: SAFe入門 https://www.ogis-ri.co.jp/otc/hiroba/technical/IntroSAFe/IntroSAFePart2May2014.html 参考 出典: トヨタウェイ 出典: “TPS HOUSE” http://www.toyota.co.jp/jp/environmental_re http://www.emsstrategies.com/dm050104arti p/03/jyugyoin03.html cle2.html 「リーン」と「アジャイル」の関係とは?:書籍でたどる「リーン」の本質 24 www.atmarkit.co.jp/ait/articles/1311/15/news015.html 「リーン」と「アジャイル」の関係とは?:書籍でたどる「リーン」の本質 25 www.atmarkit.co.jp/ait/articles/1311/15/news015.html Scott Ambler’s DAD 出典: http://schd.ws/hosted_files/agile2014/01/1288_Ambler_Enterprise_Agile.pdf 変化する市場に 俊敏に答える企業 アジャイル・デリバリ チーム 他部門のニーズに 俊敏に答えるIT部門 大きなチーム オフショアで分散開発 コンプライアンス 問題と技術の複雑さ カルチャーの問題 組織に分散 DAD が基礎を固める Risk-value driven lifecycle Delivery focus Self-organization with appropriate governance Goal driven Enterprise aware Agile/Scrum を開始地点として 開発に注目 価値提供のライフサイクル 自己組織化されたチーム 手順的 プロジェクトチーム指向 DADの特徴 DADにはフェーズがある 大きなライフサイクル視点。 4つの典型(ただし、テーラリング重要) 1.Scrum+RUP 2.Advanced Lean 3.Lean CD 4.Lean Startup 1. Scrum+RUP 2. Advanced Lean 3. Lean CD 4. Lean Startup フェーズごとにゴール駆動 例:初期の要求の識別 (方向付けフェーズ) ちなみにモデリングの扱い SAFe と DAD 共通点 • • • • • • アジャイル宣言を大切に これまでの手法のハイブリッド 「リーン」コンセプトが浸透 リーダーシップの重要性 RUPの要素によってモデレートに アーキテクチャの視点 日本からも… 「これだけ」モデリングを使ってアジャイルに適用 (要求開発アライアンス、山岸理事長) IT戦略とプロジェクトの発生 プログラムマネジメント視点とプロジェクトマネジメント視点 XX年後 現在 時間軸 例えば3カ年計画 現在の 事業戦略 将来の 事業戦略 将来のTo-Be IT 現実的目標のIT 新規追加 現在のTo-Be IT 事業戦略 への対応 機能的改修 As-Is IT 現行システム 改善 プロジェクト プロジェクト プロジェクト 維持 サーバ統合 セキュリティ強 化 クラウド適用 保守切れ対応 OS変更 破棄 現行IT人材 育成 採用 必要IT人材 パートナ戦略 各プロジェクトが上位目的に基づいて企画されているか コスト削減 継続性確保 コンプライアン ス UMLのダイヤグラム構成 • • 13のダイヤグラムで構成(ただし、パッケージ図はクラス図の1種) 大きくは静的モデル(構造図)と動的モデル(振る舞い図)に分類される 静的モデル 動的モデル スケッチとしてのUML 設計ドキュメントとしてのUML プログラム言語としてのUML 現実的なエンタープライズアジャイル ちゃんと地図は描く たまに地図を見る RD0 RDn 保守・運用のための 整備 日本でエンタープライズアジャイル? Software Engineering Center Information-technology Promotion Agency, Japan 非ウォーターフォール型開発の 普及要因と適用領域の拡大に関する調査 ~非ウォーターフォール型開発の普及要因の調査~ 調査概要報告書 https://www.ipa.go.jp/sec/softwareengineering/reports/20120328.html より抜粋して紹介 Copyright© 2012 Information-technology Promotion Agency, Japan. All rights reserved. Software Engineering Center 【参考】アジャイル型開発の普及状況(2) Scrum Master等の推移から見るアジャイル型開発の普及状況 SEC Software Engineering for Mo・No・Zu・Ku・Ri アジャイル型開発方法論で最も有名なScrumに関する資格者が、2005年以降急増 米国の取得者が群を抜いて多く、ついで英国が多い。日本は極めて少ない。 出典: Scrum Allianceによる協力 Scrum Master等の人数の経年変化 単位(人) 2002 2003 2004 2005 2006 2007 2008 2009 2010 CSM CSPO CSP 5 344 907 2,647 1 2 14 26 6,841 83 38 12,857 503 116 22,514 1,891 264 26,886 3,514 366 34,601 5,325 534 43,028 8,629 501 150,630 19,945 1,862 TOTAL 6 346 921 2,673 6,962 13,476 24,669 30,766 40,460 52,158 172,437 各国の現在のScrum Master等人数 (2012年3月) 米国 CSM CSPO CSP TOTAL 英国 67,000 8,000 1,100 76,100 中国 11,800 1,800 0 13,600 Scrum Master等人数の経年変化 略称説明 2011 TOTAL CSM (Certified Scrum Master) チーム全体の支援者 CSPO(Certified Scrum Product Owner) 製品の責任者 CSP(Certified Scrum Professional) スクラムの実践者 単位(人) デンマーク ブラジル 日本 3,800 3,700 4,600 400 750 900 30 30 60 4,230 4,480 5,560 TOTAL 350 120 6 476 91,250 11,970 1,226 104,446 各国の現在のScrum Master等人数 (2012年3月) Copyright © 2012 IPA, All Rights Reserved. 単位(人) Software Engineering Center 48 米国民間部門における ソフトウェア投資 単位(Billions of dollars) IT技術者の所属先 100% 90% 28% 80% 50% 70% 96.3 73.4 72% 60% 75% 75% 55% 45% 80% 50% 40% 88.2 Prepackaged Custom Own account Prepackaged : パッケージソフトを購入 Custom : 外部発注作業 Own account : 自社開発ソフト 出典:「Bureau of Economic Analysis http://www.bea.gov/national/xls/soft-invest.xls」 ITサービス企業 ユーザ企業 72% 30% 50% 20% 28% 10% 0% N/A 25% 25% 45% 55% 20% N/A 出典: 「グローバル化を支えるIT人材確保・育成施策に関する調査」概 要報告書 2011年 3月 (IPA) Agileのスケール方向 米国の構造 ユーザ企業 日本の構造 ユーザ企業 システム部門 システム 部門 SIer 中堅ソフトハウス 横にスケールするAgile 縦にスケールするAgile 契約を挟み、多段の下請け構造の中で、どうしたらゴールを共有することができるだろう? 50 IT人材の 流動性 Webビジネス企業での 中途採用が圧倒的に 増えている 人材流動!!! IT人材白書2014: http://www.ipa.go.jp/jinzai/jigyou/about.html 考察: http://qiita.com/kenjihiranabe/items/05ac9fb741edc1ee5276 SEC 調査・分析結果 ~各国毎のまとめ~ Software Engineering for Mo・No・Zu・Ku・Ri 調査分析結果から分かった、各国におけるアジャイル型開発の普及状況、成長度 合、特徴の概要 国名 普及状況 成長度合 大まかな特徴 米国 ◎ ○ 既に主流となっており、さらに普及が進んでいる 英国 ◎ ○ 既に主流となっており、さらに普及が進んでいる 中国 △ ○ まだ普及しているとは言いにくいが、伸びている ブラジル ○ ◎ 急激に普及が進み出した デンマーク ○ ○ 既に普及しており、さらに普及が進んでいる 日本 △ ○ 普及が遅れており、ようやく認知されはじめた 【凡例】 (普及状況) △:普及したとはいえない ◎:主流である ○:少し普及している ×:普及していない Copyright © 2012 IPA, All Rights Reserved. 【凡例】 (成長度合) ◎ :上昇 ○:緩やかに上昇 △:横ばい ×:上昇無し Software Engineering Center 52 SEC 付録:インタビュー結果 インタビューリスト Software Engineering for Mo・No・Zu・Ku・Ri インタビューイーのリスト ※敬称略 名前 所属 Mary Poppendieck Poppendieck.LLC独立コンサルタント。 『リーンソフトウェア開発』シリーズ著者 一色 浩一郎 Professor, Computer Information Systems Department, California State Polytechnic University, Pomona Israel Gat Cutter Consortium Fellow and Director 『The Concise Executive Guide to Agile』著者 中国 Shen Hao Co-Founder, Shanghai FlagInfo Information Technology Co., LTD 英国 Portia Tung Global Agile and Lean Coach at UBS Investment Bank Agile2009, 2010, 2011にて講演 ブラジル Bruno Guicardi Ci&T社 COO。ブラジルで受託開発で成長している企業 デンマーク Bent Jensen BestBrains社Director。 政府のアジャイルプロジェクトを コンサルティング。アジャイル契約を開発、実施 前川 徹 サイバー大学教授 『ソフトウェア最前線―日本の情報サービス産業界に革新をもた らす7つの真実』著者 細谷 竜一 株式会社オージス総研グローバルビジネス推進部 米国 日本 Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 53 付録:インタビュー結果 デンマークの状況 SEC Software Engineering for Mo・No・Zu・Ku・Ri デンマークでは、アジャイルは採用が進み現在でも成長していると言える (strong and growing)。何らかのアジャイル手法を取り込んでいるプロジェクト は半数以上あるだろう。特に、ScrumはITに関与するすべての人が知ってお り、広く利用されている。アジャイルの採用率は高くなっており(予想 では50%)、大きな企業でも 取り組みが始まっている(例: Den Danske Bank -デンマークで最大の銀行 -、Maersk Line IT等) 。 政府から、アジャイル採用の推奨が出ている。マネジメントレベル でも、おおむね歓迎されている。例えば、進捗の透明性や動くソフトウェアを 確認できること、プロジェクトの途中でも計画を変えられること。さらに、アジャ イルをソフトウェア開発だけでなく、製品開発全般に適用しようと実験してい る会社もある(Danish Ultra Sound company BK-Medical 等)。普及要因とし て、マネジメントと顧客は「速い開発」、「ビジネスとITの協調」のやり方を求め ている。開発者は、正しい開発をしたい、と考えていて、よくある「掛け持ち」 や「高負荷」を避けたいと思っている。 (デンマーク:Jensen) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 54 付録:インタビュー結果 中国の状況 SEC Software Engineering for Mo・No・Zu・Ku・Ri 中国では、アジャイル型開発は徐々に認知が進んでいるが採用率は低く、20% くらいだろう。 しかし、年々採用率が上がっていることは間違いない。アジャイ ルが必要な普及要因は以下の2点。 1. マーケットのニーズ:アジャイルは動くソフトウェアを短期間でリリースでき、 ソフトウェア企業の競争力をいっそう高める。あるいは、製品開発でもコスト を抑え、よりよい顧客満足を得ることができる 2. Webを利用したサービスモデルの出現:Webのサービスではユーザからの 素早いフィードバックが欲しい 実際に、「プロジェクト」という形態から、プロダクト開発、 特にサービス開発、という風にソフトウェアの開発に変 化が起きている。顧客にとってアジャイルかどうかは意味をもたず、より 品質の高いソフトウェアが速く欲しい。品質の観点では、UIが大きな意味をもっ てきているために、動くソフトウェアを見ながらフィードバックを受け付けるアジャ イルが必要。 (中国:Hao) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 55 付録:インタビュー結果 英国の状況 SEC Software Engineering for Mo・No・Zu・Ku・Ri 英国では、アジャイルは着実にメインストリームの働き方に なってきた。よりよい手法であると認識されている。主要 な利点として、従来手法よりも、高い品質、効果(ROI)、 高い顧客満足と同時に、従業員満足があげられる。そし てなにより「仕事が楽しい」。英国でのアジャイルの採用はかなり急 速に進んでいる。アジャイルの大きな普及要因は、ビジネスとして同じ産業内の 他社に「遅れをとりたくない」ということが大きいのではないか。 また、現状をよ くしたいと積極的に考えている人がいること。さらに、オープンソースとリーンス タートアップの考え方が大きく影響を与えるだろう。 (英国:Tung) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 56 付録:インタビュー結果 米国の状況 SEC Software Engineering for Mo・No・Zu・Ku・Ri 米国では、なんらかのアジャイル手法 (Scrum, XP, Crystal Clear, Kanban, など) の採用は、チームレベルでどんどん進んでいる。 これは疑いない動きだ。しかし、大規模開発等いくつか難しい 場面もある。米国は実利主義なので、うまくいくこと、 ケーススタディしてみてうまくいったことは採用する。この 実利主義と反省の繰り返しがアジャイルの普及を進め ている。 (米国:Gat) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 57 付録:インタビュー結果 ブラジルの状況 SEC Software Engineering for Mo・No・Zu・Ku・Ri ブラジルでは、アジャイルは圧倒的(massive)。私たちの80%の顧客 がアジャイルを取り入れており、そのうち半分がアジャイルを「メイ ンの開発手法」としている。普及要因は、やってみて実際の成功 率。従来のウォーターフォールよりもビジネスが成功しやすい。そ れから、これは推測だが、ブラジル人は強い管理が苦手。ソフトな 管理手法の方がマッチしている。また、これは経済が急速に発展 していることとも関係すると思う。急速な成長には柔軟な手法が 合う。また、ブラジルは北米と時差がなく、このことは、北米からの アウトソースを受ける受託開発では大きな要因。アジャイルは顧客と 高レベルなコミュニケーションが必要。質問があったときに顧客に電話等で不明 点を明らかにできることは、非常に重要。我々の会社は中国にも支社があるが、 中国では米国から受託できない。このように、顧客と開発チームはアジャイルで は、時差が少ないことが要求される。 (ブラジル:Guicardi) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 58 付録:インタビュー結果 海外でもアジャイルの普及が進みにくい領域がある(1) SEC Software Engineering for Mo・No・Zu・Ku・Ri 米国:企業の「IT部門」(IT department: 日本では「情報システム 部」と呼ばれることが多い)で行われるプロジェクトは、あらかじ め決められたコスト、スケジュール、スコープがある。このような 組織では多くの場合に不可能な制約を、プロジェクトマネージャ という管理者が導いている形態となっている。銀行、保険、テレ コムなど15年以上前に作られた会社では、ソフトウェアに依存 したシステムを持っており、技術部分を内部のIT部門に社内ア ウトソースしている(IT部門はコストセンターなのだ)。IT部門の「 技術の人」と、ラインの「ビジネスの人」はコミュニケーションが薄 い。このITはさらに外部にアウトソースされることもある。こうな ると、ITは全体ビジネスの一部にならない。このような、ソフトウ ェア開発とラインのビジネスのギャップが大きい組織では、アジ ャイルやリーンは成功しない。また、(うまくいかなくても)ウォーターフォ ールがプロセスとして一般的には採用される。 (米国:Poppendieck) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 59 付録:インタビュー結果 海外でもアジャイルの普及が進みにくい領域がある(2) SEC Software Engineering for Mo・No・Zu・Ku・Ri 米国:チームレベルではアジャイルの採用がどんどん進んでいるが、大規模では、変更 管理が必要になり大変チャレンジングだ。その結果、アジャイルが既存ビジネスの 予算管理プロセスやポートフォリオ管理と整合せず、採用が進んでいない場合 がある。事実、Stephen Denning(“Radical Management”著者)等様々な人が 実際にマネジメントレベルに大きな変革がないと、アジャイルは持続可能では ない、と指摘している。私は個人的にアジャイルを信じているが、ソフトウェア 開発手法はその時代を反映しているので、市場やバリューチェーンが2001年 から大きく変わってしまった現在、新しい現実を反映するように、アジャイル自 身が現在のコンテキストに合わせて進化する必要がある。ヘルスケア、防衛、 政府調達などの産業では下請け契約が多く、これは日本に限ったことではな い。入札、契約、下請け契約を従来の契約でおこなっている。防衛では、情報セキュリ ティが重要なので、スクラム・マスターは機密取扱者としての人物調査が必要になる。 政府調達では、監査用のドキュメントづくりなどに追われるし、ヘルスケアでも下請けが 多く、既存手法を変えるのはむずかしい。これらの場面では、発注者がアジャイルの採 用に難色を示す。Google, Apple, foursquare, eBay そういった米国の新興企業は注目さ れるが、ごく少数の特別な例である。40年以上たったCOBOLの既存コードをもっている 企業も多く、これらの現実について光があたることはまれだ。 (米国: Gat) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 60 付録:インタビュー結果 海外でもアジャイルの普及が進みにくい領域がある(3) SEC Software Engineering for Mo・No・Zu・Ku・Ri デンマーク:新規開発が多いが、銀行などではレガシ ーシステムの拡張がほとんど。ここでは、アジャイル が難しい。 (デンマーク: Jensen) 中国:アジャイルは同一企業内の開発に向いている。 大きな会社では、(銀行や保険) やはりベンダーを彼 らのオフィスに呼んで開発を行う。契約形態は、請負 もあれば”time and material”(日本では準委任に相当 )もある。 (中国:Hao) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 61 付録:インタビュー結果 「プロダクト」から「プロダクト開発」へと形態が変化 SEC Software Engineering for Mo・No・Zu・Ku・Ri 米国:企業の「IT部門」(IT department: 日本では「情報システム部」と呼ばれ ることが多い)で行われるプロジェクトは、あらかじめ決められたコスト、スケ ジュール、スコープがある。このような組織では多くの場合に不可能な制約を 、プロジェクトマネージャという管理者が導いている形態となっている。 銀行、保険、テレコムなど15年以上前に作られた会社では、ソフトウェアに 依存したシステムを持っており、技術部分を内部のIT部門に社内アウトソー スしている(IT部門はコストセンターなのだ)。 IT部門の「技術の人」と、ラインの「ビジネスの人」はコミュニケーションが薄い 。このITはさらに外部にアウトソースされることもある。こうなると、ITは全体ビ ジネスの一部にならない。このような、ソフトウェア開発とラインのビジネスの ギャップが大きい組織では、アジャイルやリーンは成功しない。また、(うまく いかなくても)ウォーターフォールがプロセスとして一般的には採用される。 このように、「プロジェクト」という形態は企業のIT部門での開発がほとんどで あり、しかもこの部分が下火になると同時に、プロダクト開発(サービス開発、 スタートアップ)が台頭しているため、ITの開発全体を見た場合に、プロジェク ト統計は今日ではミスリーディングである。 (米国:Poppendieck) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 62 付録:インタビュー結果 顧客の参画はアジャイル型開発の必須要件である SEC Software Engineering for Mo・No・Zu・Ku・Ri デンマーク:顧客やプロジェクトのオーナーの参加は、プロジェクトの 前提条件となっている。従来型では、事前の「要求フェーズ」と最後の「文 句出しフェーズ」の2回の参加だったのが、顧客負荷がプロジェクト全体にわ たって平均的に分散され、私の経験では、参画のトータル時間は少なくなっ た。 (デンマーク:Jensen) 中国:契約をはさむ開発においても、顧客が積極的にプロジェクトに参画する ようになってきた。なぜなら、UIの洗練がどんどん現在必要になっている。初 期に使ってみたい。Webフレームワークを採用し、プロトタイプツール(例: Axure)を利用してなるべく早く顧客を巻き込む。 (中国:Hao) ブラジル:顧客の参画は必須。プロダクトオーナーとビジネスユーザが一 旦アジャイルのメカニズムを理解すれば、プロジェクトに本気で関わってくれ る。 (ブラジル:Guicardi) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 63 付録:インタビュー結果 日本に普及しにくい理由についての参考意見(1) SEC Software Engineering for Mo・No・Zu・Ku・Ri 米国は、ユーザー企業内での内製が多いというデータがある。技術者が足 りないと、プロジェクトが臨時で雇用する(外注でなく)。また、コンサルタント も非常に多い。実績主義なので、経歴で職を替わっても経験が次の就職の プラスに働く(職を替わるときは、前職の人に reference をとることも多い)。 このように、人材の流動性が高いことが、内製を支えているのでは。逆に、 政府調達はアウトソーシングとなっているためアジャイル率が低かった。日 本でのアジャイルが普及しない要因は、 1.定額請負(仕様の固定) 2.多重下請け構造 (上下関係、コミュニケーション、ユーザーと直接話しが できない) の2点が圧倒的に大きいと思う。 (日本:前川 徹) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 64 付録:インタビュー結果 日本に普及しにくい理由についての参考意見(2) SEC Software Engineering for Mo・No・Zu・Ku・Ri まず、根が深い理由は、日本の商習慣にあります。 1.請負型開発の商習慣。委任型が少ない。 2.多段式の開発習慣。少なくはなってきていますがまだまだ。 3.PMOがベンダーサイドにあり、ユーザー・サイドでない。PMOが日本のベ ンダー・サイドにあるのは、ユーザーの要求定義を日本のユーザーがしな いため、ベンダーが代わりにするからです。 4.JUASの調査によると、CIOの役職名は50%以上の会社にありますが、日 本のCIOのIT業務に投入している時間は、1割以下。 米国のCIOは、1日24時間、週に7日のフルタイムをIT業務に投入しているの に比べて、日本のCIOがITに投入する時間が非常に低い。日本のCIOが社 内で重要視されていないという現状が、浮かび上がってくる。 (米国:一色 浩一郎) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 65 付録:インタビュー結果 日本に普及しにくい理由についての参考意見(3) SEC Software Engineering for Mo・No・Zu・Ku・Ri 日本型の一括請負の契約形態の中では、まず計画の立案と仕事/責任の 分担の明確化を行うことになり、ウォーターフォールじゃないとコントロール できないのではないか。さらに階層が深く硬直した取引関係の中で、プロジ ェクト全体の構成員の中で 上下関係がはっきりしすぎており、これもアジャ イルから遠ざけている原因。雇用制度のために、特に別会社に発注する形 態を取らないとコストコントロールできないことも、上記状況を強化する方向 に作用するかと思います。 ブラジルは、歴史的にはホスト中心、ドメスティックSI中心の構造であり、そ の点では日本と似ているにもかかわらず、現在はアジャイル開発が拡大し ている。この理由は、北米からアウトソースされてくる仕事の影響が大きい のではないでしょうか。また、好景気で市場が伸びており、優秀な若者の起 業チャンスが大きく、また業界全体としても新しいことにチャレンジする余裕 があることも後押ししていると感じます。私自身が米国留学中、ときどきブラ ジル人留学生に会いました。最新のソフトウェア工学になじんだ人たちが国 に帰って業界の発展をけん引しようとするのは 自然なことかもしれません。 日本人に比べればIT業界の人たちの英語の情報源に触れる機会もはるか に多いです。 (日本:細谷 竜一) Copyright © 2012 IPA, All Rights Reserved. Software Engineering Center 66 SEC 【むすび】 野中郁次郎氏からのメッセージ Software Engineering for Mo・No・Zu・Ku・Ri “新製品開発としてのスクラムの源流は80年代の日本の製造業にあ り、それがソフトウェア開発の文脈で欧米から再発見されたものが アジャイルと理解しています。現在の欧米型企業経営が、必ずしも 国民生活の質の向上に寄与していないことを鑑みると、私たち日本 人が、過去の知恵と若者の活力の両方を活かす形で、新しい日本の 持続的イノベーションのやり方をつむぎ出す必要があります。その 力の源泉は、高い志を持った経営と、いきいきと働くことができる 現場環境にあるのではないでしょうか。日本に適したアジャイル、 スクラムの形を、描き出そうではありませんか。そのためにはまず 、経営、ミドルマネジメント、現場が話す場を作り、お互いに共感 することから始めなくてはなりません。” 平成24年4月16日 一橋大学名誉教授 Copyright © 2012 IPA, All Rights Reserved. 野中郁次郎 Software Engineering Center 67 https://www.flickr.com/photos/williamcromar/4916452966/ 参考資料など • • • • • • • 「IT人材白書を読んだ」に日本のIT人材流動のより詳しい考察 http://qiita.com/kenjihiranabe/items/05ac9fb741edc1ee5276 「IPA非ウォーターフォール型開発の普及要因の調査」の中に海外での普及 要因と、日本の特殊性に関する記述がある。 http://www.ipa.go.jp/files/000004634.pdf Agile2014 report (by Ito Hiroyuki) http://www.slideshare.net/ssuser968fab/agile2014-report-as-aspeaker-and-a-reporter-of-the-latest-agile-in-the-world 山岸さんの「これだけ」モデリング、アジャイルとモデリングの関係 http://blogs.itmedia.co.jp/hiranabe/2014/06/koredake-modeling-atredajp.html DAD 概要 (by 平鍋) http://qiita.com/kenjihiranabe/items/a59aa4f1a9f9545abcc2 SAFe(日本語ページ) http://www.scaledagileframework.com/jp/ DAD(日本語ページ) http://disciplinedagiledelivery.jp/ AgileJapanのご紹介 日本全国のAgileがつながり考える場となる メアリー・ポッペンディーク氏 黒岩恵氏 野中郁次郎先生 Alan Shalloway氏 リンダ・ライジング 氏 當仲 寛哲 氏 基調講演 The Surprising Science Behind Agile Leadership ~ アジャイルリーダーシップの背後にある驚くべき科学について ~ 「全体最適のマネジメント改革」 ~ 変えるのは現場ではない、マネジメントである ~ Jonathan Rasmusson 氏 岸良 裕司 氏 柔軟心 (にゅうなんしん) と 庭園デザインにおけるユーザーエクスペリエンス 2013ベンダー発表 「大手ベンダーが組織的に取り組むアジャイル開発の普及展開 ~お客様と共に時代を勝ち抜くための新しい「手札」を増やす~」 各社の組織的な取り組みについて、それぞれテーマを絞って紹介しました 司会 「グローバル」 (NTTデータ) 「品質」 (NEC) 「マネジメント」 (富士通) 司会 とても熱かった!!! サテライト開催情報(地方10箇所、企業内3箇所) 全国で800名以上が参加した日本最大のアジャイルイベント 2009年から始まった「アジャイルジャパン」は7年目を迎えます。2009年当時と比較して、 日本でアジャイルの関心が大きく高まっています。先進的なWeb系企業だけでなく、従来の日 本型企業でもアジャイルが本格的に検討・実践され始めています。そこで、私たちは、アジャ イルジャパンというイベントを通して、日本のビジネスとアジャイルを繋げることに本気で取 り組むことにしました。 今回の主なターゲット層は、ウォーターフォールを主体として長くソフト開発に携わっている 企業や情報システム部門の方々です。ウォーターフォールに不向きな特性の案件が増えている、 発注者からアジャイルを求められるようになってきている、そういう事態に直面している方々 です。 今回のテーマは「失敗から学ぶアジャイル、成功につなげるアジャイル」 これから、もっともっとたくさんの技術者、マネージャー、QAなどの支援部門がアジャイルを 学び、アジャイルに取り組む時代になります。しかし、新しいやり方を身につけるためには、 試行錯誤し、失敗を経験することは避けて通れません。アジャイルも同様です。幸いなこと に、アジャイルは、早めに失敗がわかり対処できる仕掛けを随所に備えています。プロジェク トの序盤で早く小さく失敗し、学び改善し、最終的な成功につなげる。それが可能です。 アジャイルジャパンでは、アジャイルの習得について、同じ悩みを持つ多くの方々が、喜びや 苦労を語り合い、お互いの「失敗」から学び、お互いの成功につなげることを応援します。そ して、アジャイルを最大限活用しているWebサービス系企業の取り組みからも学べる、そうい う場を提供していきます。1980年代に遡れば、ITが本格的に企業に入り始めた頃も、様々な企 業が集まって知恵を出し合い、試行錯誤してきました。そして、新しいやり方を築き上げ、そ の成果がこれまでの日本のIT業界を支えてきました。 今、これからの日本を背負う中堅や若手の技術者、マネージャが、同じように新しいやり方を 試す時です。 ぜひ、経営層の方々は、積極的に若手のマネージャ・技術者をアジャイルジャパンに参加させ て頂きたいと思います。 様々な業種、分野から集まる実行委員の思いはひとつです。日本のアジャイルを応援したい。 アジャイルジャパン実行委員会 委員長 和田 憲明