【図解】コレ1枚でわかるこれからの開発と運用
ビジネス環境は不確実性を増し、変化のスピードは加速している。ビジネスはこの変化に柔軟・迅速に対応できなくてはならない。そんな変化への即応力こそが、強い経営基盤となる。
そんなビジネスは、ITとの一体化がすすんでいる。もはやITは、ビジネスを支える基盤として欠かすことのできない存在となった。もしITが使えなければ、ビジネス活動が大混乱に陥ってしまう。また、「デジタル・トランスフォーメーション」や「攻めのIT」への関心が高まり、ITを武器にビジネスを差別化することへの取り組みも拡大している。そうなると、ビジネス環境の変化に柔軟・迅速に対応するためには、ITもまた同じスピードで対応できなければならない。
このような状況にあっては、次のような従来からのやり方では対応することはできない。
- 時間をかけて業務要件を定義し、仕様を固める。
- 工数と見積金額で競合させて業者を選定する。
- 仕様凍結し、その仕様書に従ってコーディングとテストを行う。
- 数ヶ月を経てユーザーにリリースし、改修箇所・追加機能を洗い出す。
- 改修作業や機能の追加、変更のために作業する。
- インフラや実行環境を、アプリケーションに合わせて構築・調整する。
- 十分なテストを行った後、ユーザーにリリースする。
ビジネス・スピードが緩やかだった時代は、このようなやり方でも対応できたが、不確実性が高まり、ビジネス環境がめまぐるしく変化するいま、業務要件も日々変わってしまう。あるいは、業務要件も決まらないのに開発を先行しなければならないこともある。当然、インフラやプラットフォームの仕様をアプリケーションに合わせて決定し、調達、構築していては、開発途中でアプリケーションの仕様が変わっても対応できない。もはや従来までのやり方では、対処できない状況にある。
「現場にジャストインタイムでITサービスを提供し、ビジネスの成果に貢献する」
そんな取り組みが求められている。そのためには、次の3つの条件を満たさなくてはならない。
- ビジネス・ニーズに迅速に対応でき、その変更にも柔軟に対応できること。
- アプリケーションでの変更を、直ちに本番環境に反映できること。
- 予期せぬ負荷の増大や減少に直ちに対応できること。
この条件を満たすために、次のような取り組みが始まっている。
■アプリケーション開発・変更に迅速に対応するアジャイル開発
アジャイル開発が生まれるきっかけは、1986年に経営学者である野中郁次郎と竹内弘高が、日本の製造業の高い効率と品質を研究した論文をハーバード・ビジネスレビュー誌に掲載したことにある。それを読んだジェフ・サザーランド(Jeff Sutherland)らが、システム開発への適用を考え、1990年代半ばにアジャイル開発の方法論としてまとめた。このようにアジャイル開発には、伝統的な日本の「ものづくり」にある、「不断の改善により、品質と生産性の向上を両立させる」という精神が、埋め込まれているといってもいい。
その精神の根本には、現場重視の考え方がある。現場とは、「業務」と「開発」の現場だ。「業務の現場」であるユーザーと「開発の現場」である開発チームが、ビジネスでどのような成果をあげたいのか、そのために何をしたいのか、その優先順位や使い勝手はどうなのかを共有し、不断の工夫と改善によって無駄を省き、迅速・柔軟に、コストを掛けずに高品質なシステムを開発しようというのだ。
「仕様書通りのシステムを手間ひまかけて開発し、工数を稼ぐ」ビジネスとは相容れない。少ない工数と短い期間で、ビジネスの成果に直ちに貢献できるシステムを開発する。普段の改善を繰り返し、現場のニーズにジャストインタイムで高品質なITサービスを提供し続ける。アジャイル開発は、そんな取り組みと言えるだろう。
■本番環境への迅速な移行、継続的なデリバリーを実現するDevOps
開発チームが、アプリケーションの開発や変更に即応できても、本番環境に反映できなければ、その成果を現場は享受できない。一方、運用チームは、システムを安定稼働させる責任を負っている。開発できたからといって、すぐに受け入れて本番で安定稼働ができないとなると大問題だ。そこで慎重に検証し、システムの調達や設定などを行い、大丈夫となれば本番移行を受け入れる。このような一連の作業には相応の時間と手間が必要であり、このやり方のままでは、加速するビジネスのスピードに対応できない。
そこで、開発チーム(Development)と運用チーム(Operations)が、お互いに協調し合い、また運用や本番移行を自動化する仕組みなどを積極的に取り入れ、開発と運用が途切れることなく連続する仕組みを実現し、ビジネスを止めずに、継続的に本番移行する取り組みである「DevOps」が注目されている。
■迅速な調達を実現するインフラ、高速開発と実行を支えるプラットフォーム
DevOpsを実現するためには、インフラ資源の調達・変更も柔軟・迅速でなくてはならない。そのためにサーバーやストレージなどの物理資源を個々のアプリケーションに合わせて導入、設定している余裕はない。そこでインフラはSDIや、そのクラウド・サービスであるIaaSといった「ソフトウエア化されたインフラ」が前提となる。
それでもまだインフラを意識して、アプリケーションを開発しなくてはならない。ビジネスの成果にとって重要なのは現場のニーズに最適化されたビジネス・ロジックだ。ならば、インフラに気をかけることなくアプリケーションを開発、実行できれば、そこにリソースが傾注できるし、変化への柔軟性と迅速性は高まる。そのためには予め用意された機能部品を組合せ、連係させてアプリケーションを開発実行させる仕組みや、業務プロセスを記述し、画面や帳票を定義すれば、プログラム・コードを生成してくれるツールなどを利用し、開発スピードだけではなく、変更への柔軟性を担保しなくてはならない。サーバーレスやFaaS(Function as a Service)、コンテナやマイクロサービスなどがそんな取り組みを支える。
ITビジネス・プレゼンテーション・ライブラリー/LiBRA
LiBRA 2019/3月度版リリース====================
- ITソリューション塾が2月より新しいシーズン(第30期)に入りました。それに伴い、下記プレゼンテーションを更新しました。
- 動画セミナーの一部を新しい内容に更新しました。
=========================================
- 【改訂】サイバー・フィジカル・システムとデジタル・トランスフォーメーション
- 【改訂】ソフトウエア化するインフラとクラウド・コンピューティング
- 【改訂】IoT
【改訂】総集編 2019年3月版・最新の資料を反映しました。
*ITソリューション塾が2月より新しいシーズンに入りました。それに伴い、下記プレゼンテーションを更新しました。
- 【改訂】サイバー・フィジカル・システムとデジタル・トランスフォーメーション
- 【改訂】ソフトウエア化するインフラとクラウド・コンピューティング
- 【改訂】IoT
- 【改訂】AI
ビジネス戦略編
- 【改訂】フィジカルとデジタル(2) p.4
- 【改訂】デジタル・トランスフォーメーションを加速するサイクル p12
- 【改訂】業務がITへITが業務へとシームレスに変換される状態 p.10
- 【新規】差し迫るSI/SES事業の限界 p.24
- 【新規】顧客価値とは何か p.195〜199
- 事例:RPA導入における業務の流れ195
- 提案と価値とは何か196
- 提案が成功する3つの要件197
- ソリューション営業は通用しない198
- 「共創」ビジネスの本質199
*ノートに解説も合わせて掲載しています。
サービス&アプリケーション・先進技術編/IoT
- *変更はありません
サービス&アプリケーション・先進技術編/AI
- 【新規】「情報」を意味する3つの英単語の違い p.4
- 【更新】一般的なプログラムと機械学習を使ったプログラム p.22
クラウド・コンピューティング編
- 【新規】クラウドによる新しいIT利用のカタチp.17
- 【新規】クラウドへの移行を成功させるための7原則 p.100
- 【新規】クラウドへの移行が難しい場合 p.102
サービス&アプリケーション・基本編
- *変更はありません
サービス&アプリケーション・開発と運用編
- *変更はありません
ITの歴史と最新のトレンド編
- 【新規】依存集中型から自律分散型へ p.22
ITインフラとプラットフォーム編
- 【新規】ソフトウェア化とはどういうことか (1) p.60
- 【新規】ソフトウェア化とはどういうことか (2) p.61
- 【改訂】「インフラのソフトウエア化」の意味・仮想化の役割 p.62
テクノロジー・トピックス編
- *変更はありません