企業経営とクラウド[追記あり]
こういう抽象度の高い話もたまには。
近年、仮想化技術の発展と共にクラウドやXaaS（X as a Service）と呼ばれる概念が登場しました。"as a Service"というのは必要に応じてサービスされること、つまり、技術面ではスケーラビリティできることを意味し、ビジネス面では従量課金のように投資リソースの最適化ができるようになります。
このXaaSですが、大きく分けると以下のように類型化されます。
| 名称 | 提供レベル | 利用イメージ |
|---|---|---|
| IaaS(Infrastructure as a Service) | インフラ | 自分で作ったソフトウェアを置く |
| PaaS(Platform as a Service) | 特定ニーズに合わせたアプリケーション基盤 | 自分で作ったソフトウェアから利用する |
| SaaS(Software as a Service) | 具体的なアプリケーション | 自分では設定やプラグイン開発だけ |
XaaSの登場は"マルチテナント型ASP"としてのSaaSですが、その後、AWSのような存在が出てくることでレイヤー化していきました。上記の区分けは大雑把なので具体的なサービス名を挙げていけば中間的な存在もあります。
たとえばSalesforce.comにおけるSalesforce1 Platform（Force.comなど）は、ど真ん中のPaaSというよりは「カスタマイズ性の高いSaaS」の位置づけに感じています（だからHerokuを買収したのでしょうが）。一方、AWSでもEC2やS2はIaaS的ですし、SQSやAppStreamなどはPaaS的、RedShiftなどは一種のSaaS的な要素も包含しています。
成熟と共に専門化が発生してくるのは産業の常ですから、こうしたレイヤーどんどん細かくなっていきますし、対象となる専門分野もどんどん増していくことでしょう。
その専門化の次に来るのは統合化です。たとえばソーシャルゲーム業界やデジタルマーケティング業界向けにフロント部分からデータ分析に至るまでの全体を統合してサービス化することが可能でしょう。特定業界向けにソリューションとして各サービスをパッケージングするような動きは既に出てきていますし、もっと増えるはずです。
その先は標準化です。OpenStackはIaaSのレイヤーを中心とした標準化ですがPaaS版となるものも登場して来てもいいと思います。
パブリッククラウドばかりの話をしてしまいましたが、プライベートクラウドがなくなるということありません。
仮想化は規模の経済性が重要なので、単純にはパブリッククラウドが有利です。しかし、既存資産や運用/保守にかかる人件費やリスクコスト（特にセキュリティや内部統制）を考えると、一定の条件を満たす企業であれば社内構築（＝自社資産）のほうが"企業経営的に考えて最適"という判断になることはありえます。
ハイブリッドクラウドはパブリッククラウドとプライベートクラウドのどちらも有効に活用するという概念です。理想形としてはIaaS/PaaSレベルのAPI互換性を高めてBCPの観点から活用しようと言ったコンセプトでしょうが、もっと現実的にはデータ交換を効率化するためのミドルウェア分野で、EAIやELTやSOAのようなものになります。
企業システムは全システムが相互連携をすることで成り立ちます。データ交換には少なくないコストがかかるのはご存じの通りですから、クラウドの活用にあたってはシステム単体の設計をするだけではなく、システムの相互連携も慎重に設計する必要があります。
さて、こうした成熟化が始まったクラウドサービスを企業はどのように活用を検討していくべきでしょうか。以前のようにオンプレミスかクラウドかといったような単純な図式では理解ができないはずです。
これまでの話を整理すると
- ビジネスの継続性と可変性：ITリソースの柔軟性がどの程度必要か
- ビジネスの差別化：どの程度、何を独自に"作る"必要があるか
- ビジネスの相互作用：他のシステムと、どの程度の結合度をもっているべきか
といった観点から判断をしていく必要があります。
分かりやすく言えば、下記のようなマッピングとなります。が、これは一般論としての最適化であり、企業の状況によって「この限りではない」というのもお分かりいただけるところかと思います。
この分析が簡単ではありません。特にビジネスの継続性と可変性については企業経営の論理をよく理解しないといけません。
良く言われるのは「あらゆるビジネスは環境要因によって変化する。そして、現代における環境変化は激しい」ということですが、現実的には「あらゆるビジネスは可変性が高い」という定義はできません。
なぜなら、効率化は継続的な安定を前提とするからです。「業務プロセスの改善には、まず計測」というのは科学的管理以来の事実です。ビジネスがある程度の期間以上継続することを前提とするならば、ビジネスの可変性を抑制することは効率化に寄与します。
社会基盤に近い企業はベンチャーのようなマインドを持てないし、持つべきではありません。それは役割が違うのです。もちろん、企業継続にイノベーションの継続的な創発が重要であることは明らかなわけですが、それは新規事業や社内ベンチャーという枠組みを使うべきであって、企業全体のビジネスの可変性を上げることとは異なります。
要はアジャイルやリーンばかりが正解ではないということです。はい。
まとめ
大きく考えれば、ITは"情報"という現在の企業経営において最も重要な要素を司る技術です。企業経営のあり方が多様化し、かつ、切磋琢磨している状況であれば、当然ながらITも1つの方向に進むなんてことはなくて、常に変化をしていくことでしょう。
そういった背景を考えれば、クラウドという概念あるいは技術群も、企業のIT戦略に対して適材適所であればよいと思います。全てがクラウド、というのは楽観的な議論です。
追記2014/5/25
「クラウドにSAPなどのパッケージをおく、というのは非常に多い」という意見を頂きました。はい、その通りだと思います。スケーラビリティを求めないIaaS＝マネージドなホスティングとして使っているわけです。ただ、たとえばORACLEは全てのERP製品をSaaS提供しようとしているわけで、今後はパッケージをIaaSに置くぐらいならSaaSを採用するのが有利な気がします。
そもそも「図が正しい」というつもりはないです。『企業の状況によって「この限りではない」』というのが大前提です。
アーキテクチャ設計に品質特性を使おう
アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。
このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。
- 利害関係者にインタビューをして重視しているポイントを聞き出す
- そのポイントからシステムに求められる品質特性を整理する
- 整理された品質特性を元に、実際のアーキテクチャの設計を行う
- 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う
品質特性というのは色々なところで定義がありますが、経産省が公開している「情報システム/ソフトウェアの品質メトリクスセット」というのがよくまとまっているので紹介します。この資料は様々なソフトウェア品質についての資料を統合し、いまの状況に合うように整理したものです。
情報システム／ソフトウェアの品質メトリクスセット（PDF）
情報システム/ソフトウェアの品質メトリクスセット 利用ガイド（PDF）
この資料で定義されている品質特性は以下の通りです。8つの品質特性と、それぞれに副特性が定義されています（細かい説明などは資料を参照ください）。
- 機能適合性
- 完全性
- 正確性
- 適切性
- 性能効率性
- 時間効率性
- 資源利用性
- キャパシティ
- 互換性
- 共存性
- 相互運用性
- 使用性
- 適切度認識性
- 習得性
- 運用性
- ユーザエラー防止性
- ユーザインタフェースの快美性
- アクセシビリティ
- 信頼性
- 成熟性
- 可用性
- 障害許容性
- 回復性
- セキュリティ
- 機密保持性
- インテグリティ
- 否認防止性
- 責任追跡性
- 真正性
- 保守性
- モジュール性
- 再利用性
- 解析性
- 変更性
- 試験性
- 移植性
- 順応性
- 設置性
- 置換性
これを参照しながら評価する軸を決めていくと抜け漏れなくできると思います。使用性とか保守性とかは抜けがちですよね。
重要なことは上記全てについて検討をすることです。利用ガイドには「全てのメトリクスを利用する必要はありません。情報システム／ソフトウェアの特性に合ったメトリクスを選び、」とはありますが、全ての視点で考えてみるというのも非常に大事です。思いつかないから抜くのではなく、ひねり出すぐらいの心づもりで考えた方が抜け漏れがなくなる気がします。
品質特性を使ったアーキテクチャ評価としてはATAM (Architecture Tradeoff Analysis Method: アーキテクチャトレードオフ分析方法)が有名だと思います。日本語の本としては「実践ソフトウェアアーキテクチャ」ですので、読んでみるのもよいかと。
とはいえ、これは形式的にまとめられているだけなので、本当の実践には様々なアプローチが必要です。こういう具体的なところを書きたいのですが、なかなか文章になりにくく断念しました。勉強会もしにくいし、どうしたらいいんですかね。伝えたいとは思っているのですが...。
エンタープライズから見たImmutable Infrastructure
Immutable InfrastructureとかDisposable ComponentsとかBlue-Green Deploymentが話題になってるみたいで。
Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（前編） － Publickey
Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏（後編） － Publickey
詳しくは記事を。「不変のインフラ」つまり、一度動くようになったサーバーには手を触れず、なにか変更が発生したら新たなサーバーを別途構築し、丸ごと入れ替えることでシンプルな管理が可能になるというもの。「インフラ設定を自動化する」という流れとして見ると非常に面白い。
言いかえれば「アプリからインフラまでを一貫して構成管理する」ということになると思います。ソフトウェアの動的な状態を「サービス」という言葉で表現するなら、「サービスの構成管理」といっても良いでしょう。
とはいえ、エンタープライズの人間としてはモジュラリティの管理ができないと、Immutable Infrastructureにも限界があるなと思うわけです。
ある一つのサービスが構成管理されることは良いのですが、そのサービスを利用するサービスとの関係はどうするのですか？と。
単体のサービスを単体としてバージョンアップすることは、言ってしまえばそんなに難しくない。ただ、ソーシャル系はエンタープライズに比べてリリース頻度が多いので、毎回の作業が大変だから自動化するのはよくわかります。
（ちなみにエンタープライズのリリース頻度が少ないのは関係各部署との調整が多いからであって、いわゆる文化の問題ではありません。エンタープライズは安定していることが価値であり、それが社会基盤としての役目です。文化は現象であって原因ではないのです）
でもサービス同士の関係性が強い場合、単体のサービスの変更は周辺のサービスに影響を与えます。そうすると、そこだけ自動化されていてメリットは少ないのです。
じゃ、サービス間に関係性があるもの全部、たとえば企業システム全体を巨大な一つのサービスとすればいいじゃんと言っても、じゃ、取引先はいいんですかとか、言い始めればきりがありません。そもそも、他人様のものですし。
つまり、エンタープライズの場合は、単体をきちんと管理するというだけではなくて、単体同士の関係性や全体としての整合性という別の次元をきちんと管理する必要性がある。
そうなるとエンタープライズからみたときにImmutable Infrastructureに投資するメリットって何だろうなと思います。
いつも通りの話です。Immutable Infrastructureは有益な概念ですが銀の弾丸じゃない。
エンタープライズでは「システム全体におけるサービス間の変化の差異をどのように管理するか」というテーマを考えないといけません。モジュラリティ管理ですね。
Immutable Infrastructureのような概念の登場は本当にワクワクしますが、それをさらに応用して、よりスピード感のあるエンタープライズシステムを構築するにはどうしたらいいか、まだまだ考えるべきことは多いのです。
アーキテクトと要求もしくは技術について[追記あり]
2014年2月27日の要求開発アライアンス２月定例会で「アーキテクチャの発掘に見る要求変化の発見」、そして翌2014年2月28日にはEnterprise ☓ HTML5 Web Application Conference 2014で「JavaエンタープライズアーキテクチャにおけるHTML5」という講演をさせていただきました。
前半は（ここ数年間は同じですが）、ITサービスの提供において「利用価値、提供機能、構成／構造、プロセス」の４つの要素のバランスが重要であり、そのバランスを取る事がアーキテクチャ設計だという話です（そのバランスを保ちながらモノを作るのがマネジメントですね）。そして、後半はそれぞれのイベントの趣旨に従って変えています。
要求定義がきちんとできても、どんなにHTML5に詳しくても、あるいは、どんなにアジャイルがうまく回っても、それ"だけ"で良いITサービスを提供する事は出来ません。4つの要素が調和してこそ、はじめて良いサービスにつながるのです。特定の要素に縛られすぎずに視野を広げて、各要素を整合させることこそが重要でしょう。
ここ最近は、どちらかというとDevOpsやアトラシアンの話をすることが多かったので、改めてアーキテクト／アーキテクチャの話がきちんとできたので非常に楽しかったです。お誘いただいた皆様、ありがとうございました。
それぞれのイベントでの気づきをメモ程度に。
要求開発アライアンスでは質問をきっかけに懇親会で「いかに変化し続ける要求に対応すべきか」という話になりました。おそらく４つの要素だけでは難しくて、もっと高レベルな意味での「利害関係者間での目的の共有や信頼関係」というようなことが必要になるかと思います。
どんなに優れた人間でも予言者ではありません。未来は常に不確定です。よってプロジェクトを進めるなかでは様々な不測の事態が発生するわけですが、それには「対処し続ける」という事でしかゴールに近づけません。これは、決して1人では出来ないのです。顧客、仲間、その他大勢の人の協力なしに乗り切る事はできません。こうした、泥臭いというか、非常に人間臭いことがITサービスの提供には欠かせないものでしょう。
ただ、まぁ、これだけを取り出して「みんなの信頼が大事だ」と声高に叫んでも事態が改善されるわけではありません。地道な積み重ねをしながら、利害関係者が真摯に話し合っていくしかないのです。それぞれの現場で、それぞれの姿で少しでも良くしていこうとする努力が続けられたらなと思います。
一方でEnterprise ☓ HTML5 Web Application Conferenceでは散々UI/UXをdisりました。現状のUI/UX論というのは所詮インタラクティブなホームページをデザインする域を出ておらず、非常に感性にまかされており、エンジニアリングと呼べるような状況ではないと考えています。そもそも、IAにしても、あるいはRESTfulにしても「静的な情報」の取り扱いをメインにしており、エンタープライズで必要な業務アプリケーションをデザインするには不足感が強い。だからこそ、ユーザーテストを中心に据えるという原始的な手法に頼るしかないのです（これがダメということではありません）。
とはいえ、こういう限界点さえ分かっていれば過去の積み重ねを学ぶことは大事です。ウェブに接続される動的なアプリケーションというのは発展途上であり、まだまだ多くの可能性を持っています。今年はウェアラブルデバイスの数も増えますし、IoT（Internet of Things/もののインターネット）というバズワードも広がってきていますし、試すべき事がなくなることはしばらくはありません。こちらも現場での努力を続け、その結果を共有しながら前に進んでいければと思います。
というわけで、これからも引き続き宜しくお願いいたします。資料は以下で。
※2014/3/4追記 Youtubeで講演記録が見れます。
※2014/4/3追記 CodeIQ MAGAZINEさんで「エンタープライズの課題解決を考える「Enterprise x HTML5 Conference 2014」レポート（おやつ問題解説付き） #html5biz」として、講演録を書いていただきました。ほぼ書き起こし状態なのでご覧下さい。
ymsr君のこと
＃ymsr との最後の会話はJJUG CCCの後の打ち上げで「席の周りの女子がかわいい」という話だった。
出会いは10年ぐらいまえ、優秀で身体のでかいエンジニアだった。職場は机と机の間隔が狭くて、彼ともう一人のでかい男が背中合わせに座っていると隙間がなくなってしまい「通路がnullだ」とか意味不明なことで爆笑してた。
それから彼が本格的に一緒のチームになり、java-jaという悪ふざけの立ち上げに付き合い、赤毛やダンサーも入ってきて、とても不思議な空間だった。
残念ながら彼らの実力を活かしきる仕事が用意できず、どっかのカフェの喫煙室で赤毛と2人して転職するって言われたときは、ちょっと安心した。
その後は、あまりにツブヤキが多くてtwitterのフォローは止めたけど、彼はずっと横目に見ている存在だった。
訃報を聞いたとき、あいつらならやりかねんと関係者のSNSを見たけど、みんながザワザワしているを見て悪ふざけじゃないと確信した。あまりのあっけなさに声が出なかった。同世代の死は何度目かだけど、どいつもこいつもあっけない。ただ、いなくなる。なんなんだまったく。
山城君は、みんなと出会う事で自由になっていったように思う。元々、彼は正直で純粋で思いを持っていて、それをどんどん自由に出すようになった。java-ja自体、そこに参加する人たちが相互にノリあっていって自由になる場だった。何をしても何を言っても死ぬわけじゃないから楽しもうって。
でも、そんなやつが死ぬんだから世の中ってわからないですよね。
弔いの形はいろいろだけど、彼については「語り」が良さそうなので書いておきます。これで許して。さようなら。
SIにおけるアジャイルとかウォーターフォールとか
取材を受けないとブログを書けないのは問題ですが、@ITの「特集：DevOpsで変わる情シスの未来」というのの第5回で「DevOpsというバズワードに流されないために」という話をさせていただいたので紹介を。
特集：DevOpsで変わる情シスの未来（5）：DevOpsというバズワードに流されないために (1/4) - ＠IT
弊社も当然、最初は顧客企業の業務のことをよく知りませんから、会話を軸に業務を理解し、顧客企業との共通理解という土台を構築する作業から入ることになります。従って、そこではアジャイル開発は行いませんし、行うべきではないと考えています。ウォーターフォールで始めて、まずは満点ではなく合格ラインのシステムを作ることで共通理解の土台を固めます。その上でアジャイルに移行してスピーディに改修を進めるといったケースが多いです。
というあたりがポイントかと思います。
「顧客の求めることには永遠にたどり着けない」という現実と「手法としてのプロジェクトマネジメントには明確なゴールが必要」という現実があって、その落としどころとして「小さく繰り返しゴールを定める」というアジャイル開発方法論が生まれました。
これ自体は素晴らしいアイデアですが、一方で「アジャイルでは繰り返し可能な土台があるかというのが成否を分ける」という現実も生まれました。保守フェーズにおいてアジャイルが有効なのは、この土台がしっかりしているためだというのは言うまでもありません。
SIにおいては保守フェーズだけではなくて新規開発もありますから、どうしても土台がない状況がありえます。そういった場合には「共通の土台を作るまでは迷うことなく進める」というのが必要となります。その場合には60点とか80点を取れるようなところまでゴールを定めることが重要であり、そのうえではウォーターフォール的な進め方が効率的です。
繰り返し言っていますが、ウォーターフォールでもアジャイルでも、別に名前なんかどっちでも良くて、
アジャイルやDevOpsを「開発プロセスの話」とか「運用のツールの自動化の話」といったように解釈せず、企画、開発、運用、フィードバックという一連のサイクル加速へのビジネスニーズがある、という背景に目を向け、そのためにDevOpsやアジャイルという手法が大事だと考えることが大切です。手法ばかりを見て矮小化して捉えてしまうことなく、トレンドの裏側にある本質的なことは何かを見据えることで、これらの言葉をあらためて理解できるのではないでしょうか。
ということで、ひとつよろしく。
アジャイルがビジネス価値を作るわけじゃない - 改めて開発手法としてのアジャイル
"アジャイル"は単なる開発手法というだけでなく、その出自からして「ビジネス価値にコミットする」というような意味を含んでいるように思います。なので「アジャイルだけがビジネス価値を作ることができる」、その逆として「ウォーターフォールではビジネス価値を作れない」というような言い方が出てしまう場合があります。
もちろん「ビジネス価値を作ること」と「ソフトウェアを作ること」は無関係ではありませんが、それがすべてではありません。ビジネス価値にとって重要なのは「どういうソフトウェアを作るか」ということであって「どうソフトウェアを作るか」ではないからです。
というわけで、改めてアジャイルやウォーターフォールを純粋な開発手法として整理したいと思います。
from Choices by Caleb Roenigk
基本は計画、実行、調整
ソフトウェア開発に限らず、プロジェクトマネジメントの基本は「計画し、実行し、調整する」です。プロジェクトマネジメントには必ず計画があり、それを実行します。そして実行しながら計画とのズレを把握し、調整を行います。完璧に計画通りなら調整というプロセスは不要ですが、世の中そうはうまくいきません。だから、計画だけではなく、調整が重要なのです。
そして開発手法とは「計画、実行、調整をどのような考え方で行うのか」であり、特に重要なのは「いかに計画と実行のズレを発見し、どのように調整するか」ということです。この点に注目してウォーターフォールとアジャイルを比較してみます。
ウォーターフォールは「計画を正として調整」
ウォーターフォールは全体計画を重視し、それを正しいものとしてスケジュールやリソース配置が組み立てられます。よって、実行が開始されると、ズレは計画を基準にして把握され（進捗管理）、タイミングを計って調整（変更管理）していきます。
前提は「計画が正しい」ですが、計画変更をしてはいけないわけではありません。ただ、調整が少ないほど効率は良いのは確かです。調整が多発するような状況になると、基準がブレてしまうためズレの把握が困難になっていきます。いわゆる「進捗が信用できない」という状況です。
このようにウォーターフォールでは計画精度が低いと実行段階での調整が間に合わずプロジェクトが崩壊します。よく聞くのはビジネス要件の決定が曖昧、技術的な検証が曖昧というような場合でしょうか。
逆に、十分に計画精度が高いと効率的で最適化されたプロジェクトが実現できます。そのドメインに十分な知識がある、あるいは、パッケージ導入や法律に定められたような機能のように繰り返し実行してノウハウが蓄積されているなどが考えられます。
アジャイルは「再計画によって調整」
一方アジャイルでは「調整が不要なぐらい計画を小さくし、その次の再計画によって調整を行う」という考え方をします。
まず、計画が小さくなれば計画精度は高まります。1年後ではなく数週間先のことだけを検討するのです。次に、実行しはじめたら調整をせずに「期間の完了後に棚卸を行うことでズレを把握」し、「次の計画に反映することで調整」させます。
ポイントはタイムボックスと呼ばれる「計画の期限が来たら必ず棚卸をする」という点です。これによって強制的に調整を働かせることができます。
ウォーターフォールが適宜調整していくのに比べると、アジャイルの強制調整は乱暴な考え方にも思えますが、実際にプロジェクトで調整が多い場合には効果を発揮します。つまり、調整を定期的なプロセスとして織り込んだわけです。かつ、再計画というのは調整幅が非常に大きく、どんな状況にも柔軟に対応することができます。これはウォーターフォールが計画を変えない前提に立つのとは大きく異なります。
ただし、逆にいえばアジャイルでは全体計画と個別計画の整合性を検証することが困難です。そのため個別計画はうまく行っていても、全体として問題が生じてしまい、崩壊することがあります。
アジャイルで全体と個別のバランスを取るのは職人的です。エンジニアと顧客が十分にコミュニケーションを行い、つねに全体感を共有する必要があります。双方が十分に対象ドメインに詳しければ、もっとも効率的な問題解決方法でしょう。
なので、改善や保守あるいはサービス運営などの「既に全体的な基盤が安定しているが、問題が突発的に発生してしまう」ような状況においては比較的簡単に導入できますし、逆に新規の大型案件のように「安定した基盤もなくコミュニケーションパスが大きくなりすぎる」ような状況では不利になります。
局面に合わせた選択を
こうして考えてみると、多くのプロジェクトが完全にどちらかの状況にあるわけではありません。よく言われるように近年はビジネス環境の変化が激しいため、一見するとアジャイルが適するような状況が多いでしょうが、一方でアジャイルは全体整合性が取りにくいのも事実です。
ビジネス環境の変化は大きいからといって事前の綿密な計画が不要なわけではありません。計画できることは十分に計画して効率的に進め、不明瞭な部分は先行的にトライ＆エラーをしてフィードバックを得ればよいのです。残念ながら絶対的な銀の弾丸は存在せず、敵に応じて弾の詰め替えをするしかないのです（写真はレゴを前に悩む女の子）。
ビジネス価値を作るのは「姿勢」
ビジネス価値を作るのに大事なのは、それを実現しようとするプロジェクトチームの姿勢です。それが開発手法によって決定するわけではありません（もちろん、助けにはなります）。これは請負受託だろうが自社開発だろうが、まったく同じことです。
プロジェクトはアジャイルだから成功するわけでも、ウォーターフォールだから失敗するわけでもありません。「ビジネス価値があるシステムを作りたいからアジャイル」という短絡的な考えに陥り、色々な制約を無視してプロジェクトを進めても成功することはありません。
チームはビジネス価値に貢献するという姿勢を忘れず、そのうえで、局面や状況にあわせた開発手法を選択してください。
