Contenu connexe
Similaire à アジャイルとクラウドの『危険なカンケイ』 (20)
Plus de Mamoru Ohashi (13)
アジャイルとクラウドの『危険なカンケイ』
- 1. Copyright © 2016 KDDI Corporation. All Rights Reserved
アジャイルとクラウドの
『危険なカンケイ』 2016年10月25日
KDDIの技術の裏側見せます!
〜アジャイル、クラウド、大規模ネットワーク編〜
- 2. Copyright © 2016 KDDI Corporation. All Rights Reserved
「KDDIの技術の裏側見せます!」
というタイトルに反して、、、、
私のセッションでは
技術の話は一切しません!
ごめんなさい。。。。。
1
- 3. 自己紹介
Copyright © 2016 KDDI Corporation. All Rights Reserved
2
大橋 衛(オオハシマモル)
1974/10/01(42歳)
アプリエンジニア12年
インフラエンジニア4年
クラウドエンジニア3年(=AWS歴)
AWSコンサル/セキュリティ監査
クラウドアーキテクト
家族:妻、娘2人、両親、祖母
趣味:スノーボード、読書、DIY
絶賛本名プレイ中
@mamohacy
http://blog.mamohacy.com/
- 4. AWS Summit Tokyo 2016に登壇しました
Copyright © 2016 KDDI Corporation. All Rights Reserved
3
http://cloudblog.kddi.com/iaaspaas/4279/
- 6. グローバルのトレンド
Copyright © 2016 KDDI Corporation. All Rights Reserved
5
【導入の効果Top4】
①優先順位による柔軟な変更管理、②生産性向上、③プロ
ジェクトの可視化、④チームのモチベーション向上
出典:VERSIONONE 9th ANNUAL State of Agile Survey 2015
海外ではアジャイル開発などの新たな開発方法が主流
- 7. 国内のトレンド
Copyright © 2016 KDDI Corporation. All Rights Reserved
6
リクルート、楽天をはじめとする先進的Web系企業のみではなく、金融、自動車、鉄鋼業でのエ
ンタープライズ系システム開発に本格的な導入が始まっている。
導入事例
• トヨタ自動車
• アクサ生命
• 東京海上日動
• 神戸製鋼
• JFE
ここ数年で、大手企業が積極的に採用
約50%がアジャイル開発案件となっている(NTT-DATA調査)
- 8. 一方で・・・・
Copyright © 2016 KDDI Corporation. All Rights Reserved
7
実際に導入したが、継続してAgile開発を行っている
企業は全体の30%強程度というデータもある
出典:一般社団法人PMI日本支部 アジャイル プロジェクト マネジメント 意識調査報告 2015
36%
31%
- 10. グローバルでの市場動向
Copyright © 2016 KDDI Corporation. All Rights Reserved
9
2016年度の世界のパブリッククラウド市場予測では、2040億ド
ルもの規模に到達。
2015年からの1年間で16.5%もの成長が見込まれている。
出典:ガートナー社 パブリッククラウドのセグメント別市場規模 2016年1月25日
16.5%
- 11. 一方、国内では
Copyright © 2016 KDDI Corporation. All Rights Reserved
10
この5年間で6ポイント近く上昇し、全体平均で16.1%の採用率
ただし2015年比では0.3%の微増に留まる
出典:ガートナー社 クラウド・コンピューティングに関する調査 2016年4月
16.1%
- 12. KDDIの選択
Copyright © 2016 KDDI Corporation. All Rights Reserved
11
1. Agileの利用を継続的に行っている国内の
IT企業はまだ半数にも遠く及ばない
1. Cloudの採用率に至っては国内全体の1/6程度
しかも伸び悩んでいるようにも見える
しかし
KDDIは Agile も Cloud も
正式に採用することを決めた
- 15. KDDIがAgileを選んだ理由
Copyright © 2016 KDDI Corporation. All Rights Reserved
14
一、最初から誤差のない計画など立てられない
二、市場を取り巻く環境は常に変化し続けている
三、作られた機能の六割以上は使われない
WaterFall型開発が無視し続けている課題を
避けられない現実として受け入れるため
- 16. ①最初から誤差のない計画など立てられない
Copyright © 2016 KDDI Corporation. All Rights Reserved
15
出典:プロジェクトの本質とは何か 日経ITPro 2013年10月
不確実性は初期段階では大きく、時間が経っていくことで
減っていく。ならば「進みながら計画を立ていくやり方」を
受け入れるしか他に方法がない
不確実性のコーン
- 18. ③作られた機能の殆どが使われない
Copyright © 2016 KDDI Corporation. All Rights Reserved
17
最初に決めて作られたソフトウェアの機能のうち64%は「まった
く使わない」か「めったに使わない」。ならば最も確定的で優先
度の高いものから作り、まず市場に出してみればいい
前進
漸進
- 21. ①工期の足を引っ張る「インフラ開発」
Copyright © 2016 KDDI Corporation. All Rights Reserved
20
開発全体の工期のうち、インフラの設計・調達・設置・SIにかか
る割合はおよそ3割。容量設計も調達リードタイムも不要な
Publicクラウドならインフラ開発工数を絶対的に削減できる
要
件
定
義
設
計
イ
ン
フ
ラ
開
発
ア
プ
リ
開
発
試
験
導
入
/
移
行
開発全体の工期(100%)
限りなく0へ!
- 22. ②規模変化に迅速に追従できない
Copyright © 2016 KDDI Corporation. All Rights Reserved
21
システムへの想定外のアクセス急増があった時にその場でいきな
り増強/増設が可能。さらに予測が外れたとしても全システムを
クローズし費用をゼロにできるのはPublicクラウドだけ。
Public Cloud
Only
- 23. ③Infrastructure As Codeの採用
Copyright © 2016 KDDI Corporation. All Rights Reserved
22
システムを取り巻く状況の把握とそれに伴う構成変更をプログラ
ムコードで実現させる。「ボタンひとつで云々」はPublicクラウ
ドの魅力のほんの一握りでしかない。
出典:AWS January 2016 Webinar Series - Managing your Infrastructure as Code 2016年1月
- 25. ある社内案件の例
Copyright © 2016 KDDI Corporation. All Rights Reserved
24
API
Consumer-A Consumer-B Consumer-C
Provider-1
Provider-2
Provider-3
Provider-4
Provider-5
Provider-6 Provider-7
MySQL
memcached
Proxy
- 26. ある社内案件の例
Copyright © 2016 KDDI Corporation. All Rights Reserved
25
API
Consumer-A Consumer-B Consumer-C
Provider-1
Provider-2
Provider-3
Provider-4
Provider-5
Provider-6 Provider-7
MySQL
memcached
Proxy
- 27. Copyright © 2016 KDDI Corporation. All Rights Reserved
26
インフラプロビ
インフラコンフィグ
インフラテスト
アプリケーション
ユニットテスト
結合テスト
上記のフロー制御
全てをコードで書けるから
アジャイルで回せる!
- 28. ”怒り”から生まれたアジャイルとクラウド
Copyright © 2016 KDDI Corporation. All Rights Reserved
27
アジャイルとクラウドはどちらも現場で苦しむプログラマの苦悩
から生み出された"究極の現実解"。コーディング能力やアーキテ
クティングと組み合わせてこそその効果が最大化される。
どちらもプログラマの"怒り"から生みだされた
- 29. Agile
Copyright © 2016 KDDI Corporation. All Rights Reserved
一度繋げて使ってしまったら
もう2度と離れられない…
もはや"麻薬"のよう
と Cloud
- 31. エンプラ業界でのシステムエンジニアの立ち位置
Copyright © 2016 KDDI Corporation. All Rights Reserved
30
お
客
様
ユ
ー
ザ
オ
ー
ナ
ー
シ
ス
テ
ム
エ
ン
ジ
ニ
ア
デ
ベ
ロ
ッ
パ
フィードバック
サービス提供
要求事項
・製品
・ドキュメント
・ドキュメント
・マネジメント
・製品
・ドキュメント
ビジネス
判断
成果物
評価
・設計
・製造
・試験
非常に長いターンアラウンドタイム
オーナーの意図が作り手に伝わり難い
- 32. エンプラ業界でのシステムエンジニアの立ち位置
Copyright © 2016 KDDI Corporation. All Rights Reserved
31
お
客
様
ユ
ー
ザ
シ
ス
テ
ム
エ
ン
ジ
ニ
ア
フィードバック
サービス提供
要求事項
製品
・設計
・製造
・試験
オ
ー
ナ
ー
ビジネス
判断
「フルスタック・エンジニ
ア」
エンジニアも
ビジネスサイド
志向へ!
- 33. 組み合せ型アーキテクチャ
Copyright © 2016 KDDI Corporation. All Rights Reserved
32
あらゆるレイヤーの仮想化が進めば、究極的にはインフラや実行環境は
作り手の意識から消えてなくなる。今後もSaaSは増え続けるから、最後は
「スクラッチ」と「SaaS」の組み合わせのバランス取りがキモになる
調べる
使う
作る
組み
合せる
生み出す
OSS/プロプラ + フルスクラッチ
SaaS + コンフィグ
- 36. Today’s Wrap-up
35
Copyright © 2016 KDDI Corporation. All Rights Reserved
日本国内市場におけるAgile採用率は約35%、
クラウド採用率は約16%
Agileの本質は、製品の市場へのリーチを早め
ユーザーニーズにずっと追随し続けること
Cloudの本質は、インフラをコードで書ける意味を理解
しソフトウェア開発のノウハウを活かすこと
エンプラ業界のエンジニアは高い技術力と強い好奇心、
そしてそれを支えるコミュ力が生き残りのカギ
- 38. Copyright © 2016 KDDI Corporation. All Rights Reserved
僕たちは共に戦い、共に笑い、共に成長していく仲間を求めています!
We are
Hiring!
- 40. アジャイル開発センターの設立
Copyright © 2016 KDDI Corporation. All Rights Reserved
39
http://news.kddi.com/kddi/corporate/newsrelease/2016/09/07/2011.html
「アジャイル開発センター」
- 42. Publicクラウド( )の積極利用
Copyright © 2016 KDDI Corporation. All Rights Reserved
41
Privateクラウド(KCPS)も
Publicクラウド(AWS)も
まったく同じセキュリティ規準・規定で使えます!
社内セキュリティ規準に準拠
弊社セキュリティ規準をAWSに
当てはめて正式に準拠!
安全にAWSを使う方法と運用の
両方を整備
社内クラウド利用規定に準拠
「社内認定Publicクラウド」
としてAWSが利用可能に!
クラウド管理統制業務の運用
体制を整備
Notes de l'éditeur
- それは、なぜか?
私は、本業務ではAWSの社内コンサルとアーキテクティングをやっているのですが、
今日はアジャイル開発センターの代表としてきましたので
Publicクラウドの話はちょっとおいといて、アジャイルについての話に言及したいと思います。
- 最初に述べておきますが、私は過去に色々あってですね。。。
ウォーターフォール型開発が大っつつつつ嫌いです。
これはアジャイル開発センターの人間だから言っているのではありません。
KDDIの中ででも、アジャイルでやるべきかウォーターフォールでやるべきかは
きちんとアセスメントをとってから判断しているので、当然のことながら
両方の開発プロセスが混在している、というより殆どがWFなのですが
私はWFが大嫌いなので、結構辛辣な言葉で表現しちゃうかもしれませんが
個人的な意見、ということでご容赦ください。
さて、KDDIがアジャイルを選択した理由はいくつかありますが、その中でも
大きなものつぎになります。
- それは、、、、
のちほど順次説明していきますが、
これらは、WF型開発を経験されている方の殆どが痛感していることだと思います。
もちろん、それは我々も例外ではありません。
実はWF型開発は米国から日本に取り入りれた際にそのメソッドが大ーーきく
ねじ曲げられたのですが、ここに言及するとあと3時間くらいかかって
しまいそうなのでやめておきますが、
要は、最初っからできないことをやれると言い張って、できないことを守ろうと
するのがWFだと私は思っています。
- まず、1点目。。。。。。です。
みなさん、振り返ってみてください。
WF型開発で、過去に計画通りに進められたプロジェクトが過去にいくつあたでしょうか?
私の経験では、80 %の達成率というしきいちまで下げたとしても、そんなプロジェクトは
1つもありません。
この図をみてください。これは「不確実性のコーン」という有名なグラフですが、
プロジェクトの進行につれて見積もりのばらつきがどのように推移していくかを
表しています。ヨコ軸かマイルストーン、縦軸がその時期に見積もった工数やスケジュールです
初期段階では不確実性が非常に高いですが、これが意思決定をしながら
進んでくことでブレが減っていきます。
つまり、開発初期の段階では、確実なスケジュールや見積もりを立てることなど
事実上不可能だということです。
であれば、最初に建てた計画や見積もりを基準としてひたすらそれを守ろうとする
やり方が、いかに非現実的で非効率であるかがわかると思います。
我々は、進みながら計画を立てて進んでいくやり方を受け入れなければならないんです。
WFでも、なんども手戻りが発生しているでしょう?手戻り禁止のプロセスのはなずなのに。
アジャイルではここを受け入れたプロセスになっています。
- 2点目。XXXXです。
たとえば、ある時点でオーナーから要件を集めたとして、それがその製品や
サービスの目指す「完璧なゴール」であると言えるでしょうか?
所詮それはその時点での「スナップショット」でしかないですよね?
時間の経過とともに、市場や開発環境をとりまく状況はずーーっと
変化を続けているんです。もちろん、開発を行っている最中も、です。
競合相手がかわる、お客様からネガティブな反応があった、オーナーが心変わりした、社内情勢的にそんなことやれなくなった、
まったく別の革新的な技術が登場してしまった、などなど。
ターゲットはずっと動きているのです。アーチェリーや射的のように、
最初から的をを絞って狙い撃つ!などということは現実的ではありません。
- 3つ目です。
ある市場調査によると、最初から作ると決めて開発されたソフトウェアのうち
約64%の機能が、まったく使わないか滅多に使わないのいずれかであるそうです。
要するに、オーナーを含めた開発プロジェジェクト全体の意見が、顧客やユーザーと
呼ばれる人たちとこれだけ意見の相違があるということです。
使われない機能があるかもしれないのに、「使うかもしれないから」「今後の拡張を考えて」
などといって、金と人と時間をかけて行った開発の6割以上が無駄になるんですよ?
こんなバカなことがありますか?
あなたが締め切りに追われて泣きながら徹夜して作った機能は、ほとんどの場合で
使われないから、役立たず呼ばわりされるんです。まったく嫌になりますよね。
だったら、市場へのリーチを早くして、最も確定的で優先度の高いもの、市場影響力の
大きいいものだけを先に作り、その反応を見て次を作っていけばいい。
使われなかったらそこを掘り下げなければいいし、反応が良ければそこに加えていけばいい。
決められた道をただただ進む「前進」ではなく、方向性はあっているが完璧であるかどうかは
- すでにクラウドを利用されている方であればご存知の内容だとは
思いますが、クラウドを採用する価値は、コストやスピードはもちろんそうですが、
インフラという考え方の次元がこれまでとはまったく違うという点にあります。
- たとえば、オンプレミスの開発において、インフラの設計から調達には非常に時間がかかります。
それはインフラが固定化されたものであり、後から変更することができないから、
ブレが少なくなるよう十分に検討する必要があったからです。
しかしPublicクラウドは違います。
使いたいと思ったその日、その瞬間から使い出すことができます。
しかも後からいくらでも変えられるし増やせるから、そもそも容量設計という考え方自体が不要です。
開発工程全体の3割とも言われているインフラ部分の工期が、殆どゼロに近い数字にまで
落とし込めるという魅力は、オンプレミス上で開発を余儀なくされてきたエンプラ技術者には
筆舌に変えがたいほどの魅力があります。
- アジャイルだけを追い求めても、長い開発タームのうちの
「ソフトウェア開発」の部分だけしかファーストリリースを
縮められなかった。
しかしCloudと組み合わせることで、インフラの調達リードタイムや
容量設計などもカットできるようになった。
しかも、そのCloudはコードで実装され、プログラミングのノウハウを
活かしてソフトウェアにおけるAgileと同じ要領で改修、回帰テスト、
リリースが可能になった。
AgileはCloudと出会ったことで「本物のアジリティ」を手に入れた
- インフラプロビ
インフラコンフィグ
ユニットテスト
インフラテスト
アプリケーション
ユニットテスト
結合テスト
上記の制御
これらすべてをプログラムコードで!
- 快適すぎて、もう止めることはできない。
この関係を崩すことができない。。。。
そう、これが
- btocであれb2b2cであれ、我々エンジニアの先にはお客様と直接相対している「オーナー」がいる。
我々のようなエンタープライズ業界におけるエンジニアにとって、このオーナーにこそがお客様に当たる。
このスタイルには使うユーザーやオーナーにとって非常に不都合であることが多いんです。
なぜなら人が人に何かを渡すことでそこにギャップが生まれ、その数が多くなればなるほど、
要求内容や求める品質はどんどんズレていくからです。人と人との意思疎通をドキュメントで
埋めようとしても、パスが長くなればなるほど、もともとあった意思は伝言ゲームのごとく
薄れていくのは、理解いただける話だと思います。
しかし、いまは短納期を求められる時代。このやりかたをいくら洗練させても
限界があります。
では、どうするべきか。
- 我々はこう考えています。
オーナーと付かず離れずの関係をきずく。
要求事項をそのまま製品に落とし込み、一緒にビジネス判断も行う。
よくフルスタックエンジニアということばを耳にしますが、
究極的にはオーナーと一体となって開発を行う姿こそが、
真の意味でのフルスタック・エンジニアだと私は考えます。
今後、自社でWFをやるにせよやらないにせよ、短納期を実現していくためには
このマインドは必要不可欠であると言え得るでしょう。
- 一方で、クラウドという言葉でまとめてしまいますが、
インフラレイヤーの仮想化はあらゆる領域に侵食していきます。
すでにチューニングレスのRDBMSや仮想サーバがありますし、
サーバレスというPaaSとはまた別の概念も登場しています。
また、マネージドサービス、昔のことばでいうとSaaSと表現される
ものは、今後も続々と登場し続けるでしょう。
そんな中で、今まで通りにIaaSの上にミドルを乗せ、アプリを作るという
方法だけでものづくりをするとうことは、果たして正しいと言えるでしょうか?
私は違うと思います。
今後は、何かを作ろうと思ったときはまず調べて、ありものでどうにかならないか
使ってみて、それでもどうにもならない部分だけをスクラッチで作り、それらを
組み合わせてモノを生み出す時代になると確信しています。
我々システムエンジニアに必要なのは、このバランスをうまくとれる能力になっていくはずです。
- インフラ・アプリ関係なく「コーディング力」は必携の能力
常に最新の業界動向を追い続け、実際に手を動かしてみるという「好奇心」
自ら情報を発信し人との繋がりを太く大きくできる「人脈力」
オーナーの課題を技術で救い、それを通訳して伝えられる「会話力」
- 私のパートは以上となります。
ここで再び、平岡にバトンを戻したいと思います。
感じたことは
- 我々ももちろんAWSについての予備知識がまったくなかったので、
2013年の8月、3年前のAWSサミット明けから検証をスタートしました。
具体的な数字をお伝えできないのですが、このグラフは、
2013年に本格的にPoCをスタートして迎えた最初の四半期で発生した
利用費の平均を1とした場合の、月毎の利用費との比率推移を折れ線
グラフで表したものです。
2016年4月末時点で、当時との比較で実に 1 5 0 倍 以 上 の利用量増加となっています。
もちろんauでんきもこの中に含まれております。
実は、ここまでくるまでの3年間の間には、ほんとーーーーーに色んなことががありました。
技術的な課題はもちろんなのですが、エンタープライズ企業ならではの課題がいくつも、
いくつもいくつも登場し、そのたびに1つずつ着実にクリアしていきました。
話そうと思えば、このネタだけで1晩くらい飲めそうな勢いですが、、、
お時間の都合から残念ながら今回は割愛させて頂きたいと思います。