アーキテクチャのトレンドサマリ（2014）
今年はJavaOneに参加できたので、標準Java系は詳しい人に任せて、僕はアーキテクチャ関連の技術紹介や事例系のセッションを回ってきました。このサマリをJavaOne 2014 サンフランシスコ報告会 Tokyoにて発表しています。資料はこちらから。
動画はこちらから（コミュニティアップデートの途中からがアーキテクチャトレンドになります）。
発表時間が30分なのでコンパクトになっていますので、さっくりと見ていただければと思います。
もちろん「明日から案件に使えます」という話ではありません。ただ、JavaOneということもあって、話者はエンタープライズへの適用を前提にしています。よって、単純なスケーラビリティだけではなく、システム連携や信頼性についても意識はしています。意識したうえで「まだ簡単にはいかないけど、こうやっていくべきだ」という話です。
サマリとしては、アーキテクチャ設計をする上のポイントが、
- アプリケーション構築ではなく、サービス運営に目を向けた設計が必要になる
- コンピューティングパワーを効率的に使うためのデザインパターンが「ミドルウェア」として整理されてきているため、それを最大限に活用する設計にする
であり、アーキテクトに求められることは「サービス全体におけるドメインの境界を見分ける力」ということになります。
アプリケーション構築からサービス運営
アプリケーション構築とは「スコープがあり、終わりがある行為」であり、サービス運営とは「常に変化し、終わりのない行為」です。
サービス運営に求められる要素はアジャイル・DevOps・リーンスタートアップといった用語で包含されているので、ここでは詳細は述べません。簡単に言えば「フィードバックを元にした持続的な開発」なので、「いかにフィードバックを効率的に受け取るか」「それをいかに早く反映させ続けるか」といったところでしょうか。
特にIoTと呼ばれるデバイスの多様化は「ユーザーの利用シーン（システムのコンテキスト）」の多様化を引き起こし、より変化の度合いが広がることを意味します。
こうした状況においてアーキテクチャ設計で考慮すべきなのは以下のようなことです。
デザインパターンとしてのミドルウェア
そうした中で注目されているのがミドルウェアの存在です。より変化を受け入れ、早く構築するために必要な設計がパターン化され、ミドルウェアとして提供されているようになっています。
大きく進んだのはクラウドデザインパターン（CDP）でしょう。これはクラウドプラットフォームで提供されているミドルウェアの最大活用を前提にしたアーキテクチャ設計のデザインパターンです。もちろん、この考え方はオンプレミスでも重要です。
OSSのプロダクトを見ていても、アプリケーションフレームワークは少なくなってきて、ミドルウェアが活況です。そのアプリケーションフレームワークも、いかにミドルウェア的な要素を包含するか、というのが1つのテーマでしょう。SpringBootやDropWizardは開発容易性（EoD）を実現しているだけではなく、ルーティングやマネジメントといった要素を最初から取り込んでいます。
アーキテクチャ設計上のとらえ方をすると「固有で複雑な問題を、いかに汎用で単純な問題に置き換えていくか」という活動です。これまでミドルウェアの領域が成熟していなかったため、汎用化単純化に工数をかける意味がなかったのですが、今は違います。
ミドルウェア自体も「設定ファイルなどで行う設定」だけではなく「コードで行う設定」も増えており、適用領域はすごく増えています。インフラ領域で言われているSoftware-Defined Anything（SDx）は「インフラのミドルウェア化」と捉えるとわかりやすいですね。昨今話題のDockerは、その象徴的なものでしょう。
余談ですが「アプリケーションフレームワークの標準化」という考え方は早晩なくなるでしょう。今必要なのは「基盤としてのプラットフォームの整備」であり「各ドメインに最適化されたアプリケーションフレームワークの採用」です（これだけで記事が書けそうフラグ）。
アーキテクトに求められること
この状況でアーキテクトに求められることはなんでしょうか。最も大事なのは「ドメインの境界を見分ける目」だと思っています。ドメインの境界が見えなければ、その後、どのようにシステムを分断し、統合すればよいのかを考えることはできません。
ドメイン境界の発見において特に注目すべきなのが「変化の予測」です。対象となるドメインにおいて、将来発生してくる変化の要因を理解するとドメインの境界が見えてきます。ユーザーの変化であったり、ビジネスの変化であったり、様々なことが考えられるでしょう（これだけで記事が書けそうフラグ）。
DDDは、JavaOneでも最注目されている印象です。ただし、カタログ的な知識だけではなく、対象のシステムをきちんと見て、自分で境界線を発見することは忘れてはいけません。
まとめ
こうしたトレンドの変化は既に起きていることで、着実に進んでいます。エンタープライズでは、まだまだ顧客の意識も付いてきていないですし、レガシーシステムも消えてなくなるわけではありません。でも、5-10年先を見れば、今から取り組んでいかなくはいけません。
2014/10/27追記
動画リンクを追加しました。
アジャイルが否定したものを見直そう
2014/9/6に開催されたXP祭り2014で「アジャイルを手放して得られたこと」という講演をしてきました。Togetterはこちらから。
元々は「アジャイルのダークサイド」の話がしたくて応募したのですが、その後、いろいろと考えているうちに僕自身にも気づきの多い内容となりました。
さて反応を見てると前半のアーキテクチャとマネジメントの話に興味を持っていただいたようです。なので、このブログでは「なぜアーキテクチャとマネジメントの話からアジャイルの話をしたのか」ということを書いてみます。
アジャイルがさまたげたもの
アジャイル開発手法が大きく注目されるのは1999年の「Extreme Programming Explained」の出版であり、2001年の「アジャイルソフトウェア開発宣言」です。1990年代後半から2000年代初頭というのは、IT産業が大きく成長する時代であり、同時に、当時主流であったソフトウェア開発手法（いわゆるウォーターフォール）が世の中にも開発者にも適応しなくなってきた時代でした。
アジャイルは時代の変わり目にあって、過去と決別するために生まれてきたようでした。しかし、そのこと自体が過去にあったソフトウェア開発のあり方への理解をさまたげることになったのです。
ウォーターフォールとアジャイル
ウォーターフォールというのは計画を重視するプロジェクトマネジメント手法です。
プロジェクトマネジメントの基本は「計画・計測・調整」（計画を立案したら、実行をして計画との差を計測し、それを調整しながら進める）です。バイブルたるPMOBKの初版は1987年ですから、1980年代はITに限らずプロジェクトマネジメントがブームだったのでしょう。発行元のPMIは1969年に航空宇宙、建築、防衛などの業界中心となって設立されたもので、1970年代に標準化が進むと1980年代は業界を超えた適用が進みました。
言わずもがな航空宇宙、建築、防衛といった分野は計画通りに進むことが重要です。よって、計画を多角的に検証し、段階的に精緻化していくという「計画重視」の考え方は当然のことでしょう。
しかし、1990年代以降のソフトウェア開発というのは、技術面ではオープン化/ネットワーク化に伴う要素の複雑化、一方、ビジネス面ではIT主導のビジネスモデルの興隆による適用業務の複雑化が発生しており、産業全体が混とんとした状況でした。
つまりプロジェクトマネジメントの観点からすると、ソフトウェアは計画における見積もり精度の低く、かつ、目に見えないために計測が難しいものでした。ですから、計画を重視するタイプのプロジェクトマネジメントがソフトウェア開発に適さなくなっていたのです。
そんな状況で登場したのがアジャイルソフトウェア開発手法です。アジャイルは、
- 計画：精度が出るぐらい小さな計画にしよう
- 計測：動くソフトウェアで計測しよう
- 調整：定期的に関係者全員で調整しよう
と考えました。つまり、アジャイルは「調整を重視するプロジェクトマネジメント手法」といえるでしょう。
しかし、アジャイルにも欠点があります。それは全体設計の軽視です。漸進的に進むがゆえに、個別の成果が全体として整合しているかを確認することが難しいのです。そこを補うのがアーキテクチャです。
アーキテクチャとデザインパターン
そもそも、経験あるエンジニアであればソフトウェアを本格的に作り出す前に構造や構成をデザインし、その時点で性能や拡張性を確保するというのは常識でしょう。アジャイルのように段階的な機能追加を前提とするためには骨組みとなるアーキテクチャ設計は重要な作業です。
このアーキテクチャという考え方も1990年代に流行します。ただし、この時代の「アーキテクチャ」というのはザックマンフレームワークで有名なエンタープライズアーキテクチャを指していたと思われます。
エンタープライズアーキテクチャは1980年代に企業がITを取り入れていくにあって整備された分析・設計手法の集大成で、簡単に言うと企業全体をビジネス＞情報＞情報システム＞データ＞実システムと段階的にモデル化していくものです。ITが企業戦略に組み込まれるようになると、企業全体としてソフトウェアをどのように配置し、機能させるのかというのは重要な課題となってきます。
しかし、一方でビジネスのあり方とソフトウェアの実装をリンクさせるためには広範囲な経験を必要とします。仮に、たいして実装経験もないビジネスコンサルが「アーキテクチャ」と名前でモデル図ばかりを書いていたのであれば、それを実システムに落とし込むために現場の開発者が相当苦労したであろうことは想像に難くありません。当時のアーキテクチャ設計というのは「ビジネスコンサルが作った絵空事」というイメージが強かったように思います。
一方、1995年にはデザインパターンの原点「Design Patterns: Elements of Reusable Object-Oriented Software」が出版されており、ソフトウェアの構成をデザインする際の手法としてはアーキテクチャという言葉よりもデザインパターンのほうが広まった気がします。
デザインパターンはデベロッパー同士がアドホックにコミュニケーションするためには最適のツールでした。ただし、アーキテクチャ設計論のようなプロセスではありませんし、企業システムというよりはアプリケションにフォーカスされていました。とはいえ、そんな形式化がなくとも、優秀なデベロッパーにはデザインパターンさえあれば十分だったのでしょう。
ソフトウェア開発をデベロッパーの手に
こうした時代背景からすればアジャイルがプロジェクトマネージメントやアーキテクチャのアンチテーゼとなったのは必然かもしれません。
見方を変えると、アジャイルという言葉はデベロッパーの手にソフトウェア開発を取り戻すための運動だったのではないでしょうか。その対岸にいて石を投げられたのは開発もできないビジネスコンサルやプロジェクトマネージャーやエンタープライズアーキテクトです。
僕自身も当時はデベロッパーとして仕事をしていました。ソフトウェア開発が民主化し、急速に仕事が増える中で「マネジメントだ、アーキテクチャだ、ごちゃごちゃいう前に作って動かそうぜ」という気持ちになるのは十分に理解できます。この感情をデベロッパー同士で共有するための旗印がアジャイルだったのでしょう。
しかし、非常に残念だったのはアジャイルがウォーターフォールやアーキテクチャを必要以上に否定してしまったことです。その結果、そこにあったノウハウは広く普及しませんでした。しかも、産業の発展、労働者の増加、技術の変化が同時多発に起きたため、ソフトウェア開発における手法の形式化や標準化そのものが軽視されてしまった気がします（フレームワークの標準化は別の話です。いまとなっては残念な歴史ですね）。
アジャイルが否定したものを見直す
そして時代は流れて現在。ITが社会基盤に深く組み込まれ、その重要性が増している時代になったときに、あらためてアジャイルが否定したものの価値を見直すべきではないでしょうか。
ただし、単に計画精度を上げたりや絵空事のモデル図を書けということではありません。僕らは学んだのです。アジャイルの良さを取り入れながら、あらためてプロジェクトマネジメントやアーキテクチャ設計を考えるべきです（そもそもアジャイルの良さを理解しようとしない人もいますが...）。
デベロッパーがどんなに良いソフトウェアを作っても、それが正しく組織に組み込まれ、正しく社会で使われなくては意味がありません。このためにはソフトウェア開発の過程において面倒でもやるべきことがあります。そこに目を向けていくことが、これからのIT業界で大切なことだと信じています。
ウォータフォールやアーキテチャ設計は、ソフトウェア開発を進めるにあたり、利用者を含めたステークホルダーを巻き込みながら全体整合を保ち、ソフトウェアの利用価値を定義することを重視しています。これは非常に重要な考え方です。
だからこそ、アーキテクチャやマネジメントの話からアジャイルを見直していくことで、これからのソフトウェア開発のあり方を考えられると思っています。
まだまだ途上、やるべきことはたくさんあります。もっと良いソフトウェア開発をするための手法を皆で考えていきたいですね。
毎回で恐縮ですが、そんな弊社もデベロッパーを募集しております...。そんなにハードル高くないのでご応募ください...。採用情報｜Growth xPartners Corporate Site
組織をプロダクトオーナーにする、ということ[修正あり]
2014年7月31日（木）に開催された「Developers Summit Summer 2014」（通称：夏サミ）にて、「創業122年の企業と顧客価値にコミットした開発を実現する試みと成果について」という講演をしてきました。資料と動画は以下から。
講演には弊社の顧客である（株）東京商工リサーチ（以下、TSR）の青木さん（システム本部 部長）にも参加いただきました。講演の最後に「GxPさんとは、まさに二人三脚のような関係を築けた」という言葉が非常にうれしかったです。
また、講演に向けて打ち合わせをする中で「我々は何をしてきたのか/何が出来たのか」というのをじっくり話せたのは良い経験でした。プロジェクトが完了したら顧客と一緒に講演する、みたいなことが毎回出来たらいいでしょうね。
速さよりもリズム
さて、今回の講演のキーワードでもある「組織としてプロダクトオーナーの役割を果たす」も、そういう事前打ち合わせの中で生まれた言葉です。
皆さんも承知の通り、エンタープライズ案件では顧客側の意志決定が一筋縄でいきません。プロジェクトで握っても業務部門で断られる、役員でひっくりかえされるというようなことですが、理由は簡単でシステム部門が業務や役員の関心事が理解できていないからです。エンドユーザーの興味や事業の優先事項は常に変わるので、これを常にシステム部門が把握しているのは無理でしょう。
とはいえ、「速くしたいからシステム部門が勝手に決めて、後から修正する」というわけにもいきません。たとえば商品の価格設定は「勝手に決めて後で変えればいい」ではダメで、事業計画も含めた関係各部門の確認が必須となります。
では、大企業では、どのような意志決定プロセスが「最適」なのでしょうか？我々は「速くする」ことではなく「適切なリズムを刻む」ことが重要と考えました。
3つの対象と3つのプロセス
今回のプロジェクトでは、我々が関わると決まる前からTSR青木さんが問題意識を持ってコアチーム作り/情報共有ツール整備などを推進されており、社内の意思疎通を強化していました。そこで、その流れに乗る形で意志決定プロセスの構築を進めました。
特にローンチ後は「新機能追加」「定期改善」「保守」という3つの枠で契約することを提案し、了承いただけました。
3つの枠は、それぞれ特定の開発対象と紐付いています。
・商品追加など事業戦略に関わることは都度（新機能追加）
・事業戦略までいかないが社内合意が必要な改善は3ヶ月ごと（定期改善）
・システム部だけで決められる改善は2週間ごと（保守）
・緊急事態は緊急対応（保守）
定期改善のタイミングは「組織として合意を得るような機能改善は3ヶ月定期ぐらいじゃないと無理」ということから決まりました。事前に年間計画としてリリース日と予算枠だけ役員承認をもらい、設計が進んで機能と工数を確定させた上で、再度、稟議をかけるという進め方です。やるべき機能は社内のバックログから優先順位で判断しています。特徴としては、
・定期的なリリースが実現できる（3ヶ月に1回）
・機能確定からリリースまでの時間が短い（2ヶ月程度）
・受託請負で契約できる（リソース制約が少ない）
ということになります。
なお、上記の3つの枠は全て非常駐（非委任契約）で実施しています。倉貫さんの「納品のない受託開発」でも同じですが、受託契約＋非常駐によって開発リソースの制約が少なくなることは開発側に様々なメリットをもたらします。
組織としてプロダクトオーナーの役割を果たす
3つの枠は「開発対象に応じてプロセスを変えている」だけなのですが、それは単に「ソフトウェア開発の都合」ということではなく「組織がITサービスをマネジメントする」という観点で考えられています。
アジャイル（俊敏）では速さが重要視されている気がしますが、[修正開始]「アジャイル」の訳語が「俊敏」とあるように、アジャイルはウォーターフォールと比較して「速い」ことが強調されているように思います。しかし、その本質は「速さ」ではなくて、[修正終了]僕は「ユーザーが主導すること」が最初にあって、そのために「適切なサイクルで活動を行うこと」が重要と考えています。[追記開始]ただ速さを求めるのではなく、自分にあったリズムはどのぐらいだろう？と考える事で無理のない適切な速さになるのです。[追記終了]そして、その「活動」というのがシステム部門と開発企業というプロジェクト内に閉じた話ではなく、顧客組織全体の活動になることが必要です。TSR様では都度/3ヶ月定期/2週間定期/という3つの枠を作ることで最適なサイクルに繋がりました。他の組織であれば、別のサイクルであっても問題ないでしょう。
この状況を説明するのに「組織としてプロダクトオーナーの役割を果たす」という言葉がフィットしました。誤解がないように書いておきますが、我々はスクラムを実践したかったわけではありません。でも、振り返ってみればスクラムが提唱する「プロダクトオーナー」という概念で説明ができた、というだけです。これは僕らにとっても面白い出来事でした。
まとめ
GxPは「社会的基盤を提供する事業会社と持続的な開発を実現する」ことを目指しています。その事例としてTSR様との取組みを紹介しました。もちろん、他の顧客とは、また異なるプロセスで仕事をしていますが基本的な考え方は同じです。現状では事業会社が外部のソフトウェア開発企業を受託で活用するは必要なことであり、そのためには我々が「ソフトウェア作る」だけの仕事ではなく「ITサービスを通じて顧客の成長を促す」仕事をしていかなくてはいけません。今後も機会があるたびに事例公表が出来ればと思います。
まだまだ道半ば。この案件だけではなく、様々な取組みの中でよりよい方法を模索していきたいと思います。一緒に歩いてみたい仲間はいつでも募集中ですよ！
「納品」をなくさなくてもうまくいく
倉貫さんから直接献本をしていただいきましたので感想がてらに。
本書はいわゆる“アジャイル”を清く正しく実践している実績と、その仕組みを丁寧に解説した本です。しかも、開発体制は「事業会社の内製化」ではなく「外部のソフトウェア開発企業を継続的に利用する」というスタイルであることに大きな意味があります。
（ソフトウェア開発企業という名称ですが、もはや「ソフトウェアだけを開発している」わけではないので、本来は「ITサービスを開発している」企業というような名称が最適なのですが、ここでは一般的な名称として使います）
これまでアジャイル開発方法論は「事業会社における保守運用フェーズの内製開発」に最適であるとされてきました。実際、多くのウェブ企業が社内にエンジニアを抱え、継続的な保守運用の中でイテレーティブに開発を行うスタイルを実践しています。
しかし、実際には世の中の大半の企業が“優秀なエンジニア”を雇える状況ではありません。優秀なエンジニアが少ないというより、そもそも「優秀なエンジニアを雇う」ことが簡単ではないのです。理由は「優秀なエンジニアは優秀なエンジニアによってのみ評価される」からです。日本の企業の多くは人事制度上もエンジニア向きではありません。もちろん、これから緩やかに変わっていく可能性はありますが、現段階では事業のプロフェッショナルとして能力がある企業は「いかに社外のエンジニアと協業するのか」と考えた方が効率的なのです。
一方、ソフトウェア開発企業としても、複数クライアントの案件を抱えることはITサービスの構成要素が複雑化するなかで社内にノウハウを蓄積できるという点において大きな意味があります。事業会社のIT部門では事業の安定性が最優先されるために新しい技術に取り組みにくい状況にあるのは言うまでもないでしょう。
もちろん、先進的な一部の事業会社では、新規技術も取り入れながら高いソフトウェア開発能力を維持しています。しかし、世の中は、そういう「一部の企業」だけで成り立っているわけでもありませんし、成り立つことは不可能です。
私としては「ソフトウェア開発に対して先進的でない企業」であっても、高い事業能力を保有している場合、一方で進んでいく世の中のIT化に対して、もっと“社外のITプロフェッショナル”として支援できることがあると信じています。
よって、事業のプロフェッショナルとITのプロフェッショナルが受託契約を通じて協業するモデルが求められていくべきで、本書は、そのための1つのモデルを示したものといえるでしょう。特にオフサイトでの完結を前提にしている点が特徴的だと感じました。
だが、しかし。本書に不満がないわけではありません。
「納品のない受託開発」はエンジニアを持た（て）ない事業会社にとって価値があるし、ソフトウェア開発企業にとっても事業継続性が高い点で優れたアイデアです。
しかし、開発規模が拡大できない。本書に書かれているとおりですが、小規模なスタートアップに最適なのです。もうちょっと大きな規模をこなせるようなモデルを作らないと日本の優れた事業会社の支援は難しいのではないかと考えています。
そして、開発規模を拡大しようとすると、この本に書かれていることにいくつかの事項には違和感を覚えます。
たとえば、
（要件定義とは）「事前に何を作るかをしっかり決めてく」（中略）それが顧客にとっての価値に直結しないことが一番の問題なのです。
とありますが。「決められてない未来を無理に決めることはない」と思いますが「決まられる未来については十分に決めた方が効率的」です。規模が大きくなると「決めないで進んでいく無駄」と「決めて作ってから修正していく無駄」の場合に、後者のほうが効率的になってきます。
我々の会社では「要件定義をしっかりやって8割完成させてから、残りの2割を調整していく」というスタイルを実践しています。こうすれば数百人月規模の案件でも対応することが出来ます。もちろん一括請負で契約をすることになります（ハイブリッドになることも多いですが）。
一方でエンジニアのあり方として、
私の言うプログラマーとは（中略）企画の段階から考えて、画面のデザインや仕組みの設計ができて、それを自らプログラミングし、クラウドでの運用まで、ソフトウェア・エンジニアリングに関わるすべての工程をこなせる人のことを指しています
というのは共感しつつも、規模が増えると「一人で全部」というのが難しくなってきて、チームマネジメントや顧客折衝が重要になります。エンジニアリングにおいて実際に手が動くことは間違いなく重要ですが、それだけではない能力を高めることはエンジニアの成長として認められていいはずです。
これは「プログラマは35歳を過ぎたらプロジェクトマネージャーになれ」などというレベルの低い話ではないです。上記のプログラマーの定義を前提としつつ、クライアントの事業理解、全体アーキテクチャ設計、顧客との合意形成、スケジューリングやリソース調達、チームマネジメントといった能力を身につける必要があるでしょう。
実際に出来るのか？という疑問な方は、今度の夏サミ 2014で弊社のクライアントである（株）東京商工リサーチ（以下、TSR）様と「創業122年の企業と顧客価値にコミットした開発を実現する試みと成果について」という講演をするので聞きに来てください。企業情報提供サービスと言えば（株）帝国データバンクが業界1位ですが、創業は業界2位のTSRの方が早いです。日本のレガシーな企業と数百人月の開発をする際に、いかにアジャイルを実現しようとしてきたのか、という話をします。なお講演はアトラシアンの提供です。
要するに、納品をしないとか一括請負契約をしないといったことはどうでもよくて、顧客と信頼関係を築き、優秀なエンジニアが真のパートナーになることが重要なのです。言い換えれば、事業会社とソフトウエア開発企業という両者のビジネス持続性において最も効率的で無駄のない方法を構築するのです。
こういう前提無しに「常識」と言う言葉で「一括請負はディフェンシブ」とくくり、「納品のない受託開発こそがオフェンシブ」とすることに苦言を呈したいと思います。オフェンシブにするために一括請負をやったっていいんですよ。
というわけで、本書については「目的には大賛成だけど、限界がある方法」というのが率直な感想です。もちろん、参考になった手法もありますが。
ただ、ここで立ち止まる倉貫さんでもないでしょう。おそらく、本書が出たことでクライアント数は一気に増えるし、面白い案件も転がり込んでくるはずです。そうなって開発規模を拡大しなくてはいけなくなったとき果たしてどうするのか。倉貫さんにはもっと進化したソフトウェア開発企業の経営に取り組んでもらいたいと思いました。
「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル
- 作者: 倉貫義人
- 出版社/メーカー: 日本実業出版社
- 発売日: 2014/06/12
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
- 作者: 倉貫義人
- 出版社/メーカー: 日本実業出版社
- 発売日: 2014/07/18
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
ベネッセ事件はITマネジメントの課題として語るべき（追記あり）
思ってたより衝撃的だったのでブログを書きます。
顧客ＤＢ開発に関与＝知識悪用し防止措置解除—派遣ＳＥ、逮捕状請求へ・警視庁 - WSJ
外部業者から派遣されているシステムエンジニア（ＳＥ）の男が、情報が流出したデータベース（ＤＢ）のシステム開発に関与していたことが１７日、捜査関係者への取材で分かった。
警視庁は男が専門知識を悪用し、ＤＢの流出防止プログラムを解除して顧客情報を記憶媒体に複製したことを確認。
これが本当だとすると各所が大騒ぎにならないといけません。ただ、「すわ、セキュリティコンサルに依頼だ！」では、まったく解決になりません。むしろ、振り返って「自社のITマネジメントってどうなっている」を正しく理解した上で「で、これからどうしていく？」ということを考えないといけません。
この事件はセキュリティの問題ではなく、ITマネジメントの問題なのです。
まず「流出防止プログラムがあった」ことは想定されていました。ベネッセはIT業界で参考にされるような事例を数多く持っており、僕自身も「きちんとした会社」であると認識をしていました。よって、当然の対策はしているはずなのに、と思っていました。しかし、何重にも対策がしてあったはずです。
なので、僕は以下の2つの可能性を考えていました。
1つ目は「正しい手続きに基づいてデータを持ち出した」という可能性です。データベースはアクセスできなければ活用できません。よって、正しい手続きとしてデータを閲覧し、それを他システムに連携するようなことが可能であったはずです。この「他システムへの連携」になんらかの穴があり、それを利用して外部ネットワークに大手を振って持ち出しを行っていた可能性がありました。
2つ目は「複数の防止プログラムがありながら、何らかの低レベルな抜け道があった」という可能性です。たとえばバックアップデータには容易にアクセスできた、とか。
上記の2つは「セキュリティ対策が不十分であった」という結論であり、なんらかの追加対応を行うことで解消ができます。つまり、「ベネッセはある程度はちゃんとしていたが漏れがあった」ということになります。
ですが、「内部の人間によって流出防止プログラムが解除された」となると話は別です。どういう仕組みかは分かりませんが、文章からは単なるクライアント側のコピー防止プログラムだけではなく、なんらかの解除しうる仕組みが存在していて「正しい手続きであっても持ち出しはできない」かつ「低レベルな抜け道もなかった」ということが考えられます。
つまり「十分な対策はしていたが運用に問題があった」ということになります。僕は「扉は頑丈だったが壁に穴があいていた」ということだと思っていたのですが、実際は「扉も壁も頑丈だったが、そっと内側から開けられてしまった」ということだったのです。
これは本件が単純にセキュリティ対策と呼ばれる活動を積み重ねても解消できる問題ではなかった、ことを示しています。
どんなに優れたセキュリティ製品を導入しても、どんなに厳密な運用ルールを適用しても仕組みを知った人間によるハッキングであれば、これを防ぐことは非常に困難です。
これについて「日本のIT業界が外部業者に依存する形なのが良くない」という指摘は的外れです。この構造的な問題は解決できるものではなく、事業の環境要因です。急激に内製化を進めたところでロイヤリティが低い社員が出てくれば同じ問題が起きてしまうでしょう。
ベネッセの流出事件はITセキュリティ対策がどうこうというレベルではなく、セキュリティ対策も包含されたITシステムあるいはデータを、いかにマネジメントしていくのか、というレベルで捉えるべきです。つまり、組織や契約といった会社の活動の中でITをいかに捉えていくのかという問いかけです。
不幸中の幸いとするならば、ベネッセのようなきちんとした会社で、かつ、原田さんの元であれば、おそらく事件の詳細は明らかになるであろうし、なんらかの再発防止策も提示されるであろうことでしょう。
続報を待ちつつ、ITマネジメントが企業にとってのブランドや信頼に関わるような問題であることを噛みしめておきたいと思います。
2014/7/18追記
より詳しい情報が出てきましたね。
時事ドットコム：顧客情報１０００万件不正取得＝派遣ＳＥの３９歳男、逮捕−ベネッセ漏えい・警視庁
顧客情報が記録されたサーバーにアクセスして、約１０１９万７０５０件の情報を貸与されたパソコンにダウンロードし、自分のスマートフォンに転送。複製して、不正に入手した疑い。
警視庁によると、流出防止のため記憶媒体に情報をダウンロードするとパソコンに「エラー」表示が出る仕組みだったが、松崎容疑者は、スマホを使えばデータを取れることに気付き、擦り抜けていた。
といわけで、気張ってブログ書いたけど「頑張ってはいたけど、分かりやすい穴がありました」という結論かもしれません。いずれにせよ、調査結果を待ちたいと思います。
なお、記者会見の中で対応方針についても発言がありましたが、まっとうですね。
（3/4）News ＆ Trend - ベネッセ情報漏洩事件容疑者は「ベテランで中心的な役割」、謝罪会見一問一答：ITpro
ハードウエア、ソフトウエア含め、世の中の水準よりも脆弱性があるシステムだとは思っていない。言えることは、システムへの投資よりも、（関係者に）徹底した倫理観、責任感を持たせたり、コンプライアンス教育のための費用などに、大きな投資をしたりということだ。
（4/4）News ＆ Trend - ベネッセ情報漏洩事件容疑者は「ベテランで中心的な役割」、謝罪会見一問一答：ITpro
社員であっても、派遣社員であっても、同レベルのセキュリティ管理をしたいと考えている。
いずれも原田さんの発言です。もちろん、もっと高度なセキュリティ対策が可能だとは思いますが、セキュリティ製品をたくさんいれても解決しない領域は存在するし、それよりは人材力を上げていく方が経営としてはまともだなと思います。きちんと経営としてITマネジメントを把握されているというのが伝わります。
他の会社で、変なセキュリティコンサルをいれて作業効率が落ちたり、とりあえず外注切って技術力が落ちたり、そういう残念な影響が生まれないことを祈るばかりです。
企業経営とクラウド[追記あり]
こういう抽象度の高い話もたまには。
近年、仮想化技術の発展と共にクラウドや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: アーキテクチャトレードオフ分析方法)が有名だと思います。日本語の本としては「実践ソフトウェアアーキテクチャ」ですので、読んでみるのもよいかと。
とはいえ、これは形式的にまとめられているだけなので、本当の実践には様々なアプローチが必要です。こういう具体的なところを書きたいのですが、なかなか文章になりにくく断念しました。勉強会もしにくいし、どうしたらいいんですかね。伝えたいとは思っているのですが...。
