マイクロサービスアーキテクチャとは何か
マイクロサービスアーキテクチャ（以下、MSA）という言葉を聞くようになりました。きっかけはファウラーのブログ「Microservices」（2014年3月）ですが、昨年10月のJavaOne SFでも多くの講演でMicroservicesという言葉を聞かれ、多くのエンジニアがすぐに共感していたことが分かりました。今後、日本でも広く知られる言葉になることでしょう。
一方でMSAは誤解を招きやすいバズワードとも言える気がします。というわけで、僕なりのMSAについての考えをまとめてみました。
MSAは「優れたウェブサービスを観察したところ同じようなアーキテクチャだったので、それをマイクロサービスアーキテクチャと名付けた」というものです。逆に言えば「大きなウェブサービスを作ろうと思ったときの定石」といえます。「各要素を疎結合に構成し、連携する」「それぞれの要素に適した技術を使う」といったアイデアは突飛なものではありません。
大きなウェブサービスであればMSAという言葉がある前からMSA的に作っていたでしょうし、僕自身もそのようにシステムを設計していました。もちろん、先進的な企業ならではの取り組みもありますが、基本的な思想は同一です。
ですから、MSAがブームになったからといって「MSAを目的にしたアーキテクチャ設計」をしたところで失敗することになります。対象システムにとって適切な手法を選択したら自然にMSAになるはずです。それを無理にMSAにすべきではありません。アジャイルを目的としたプロジェクトが失敗したように、手段を目的としてはなりません。優れたウェブサービスがMSAであっただけで、MSAを採用したから優れたウェブサービスになるわけではありません。
SOAとMSA
エンタープライズであればSOAとの違いについて考える必要があります。資料中にもありますが、僕はSOAがトップダウンの理想論であったのに対して、MSAはボトムアップの現実論として捉えています。これは時代背景の違いと言えるでしょう。
SOAは「バラバラであったシステム群をいかに統合していくか」が課題であった時代に創られた言葉であり、一方で、MSAは「巨大なサービスをいかに複数のシステム群で構成するのか」が課題の現代における言葉です。SOAからMSAまでの10年で状況が変わったのです。
MSAと政治学
個人的な興味ですが、SOAからMSAへというアーキテクチャ設計の移り変わりは、政治学における「封建制」「君主制」「民主制」という流れと似ていると考えています。
その昔は個別のシステムは個別の部署によって管轄されて独立して存在していました。それぞれの責任は明確であったものの境目は曖昧で、個別に問題解決をしていたといえます。
これが封建制の時代。各領主には主権があり、個別の法制度が許され、比較的独立していたのです。
しかし、1990年代ごろから各システム間の連携が多くなると全体整合性の観点からシステム資産の活用度を高めるニーズが出てきます。そこで提唱されたのがSOAでした。SOAでは各システムのインターフェースに統一のルールが求められました。EAIによるデータ交換のハブ化、MDM（マスタデータマネジメント）によるデータモデルの統制、BPMによるプロセスの自動化など、企業全体を俯瞰した考えです。
これが君主制の時代。一人の王によって法制度が定められ、各地方では領主たちが統治を預けられていた時代です。ただし、君主制には偉大な王が必要であり、多くの君主制は統制の限界を迎えて打倒されていきます。
そして、2000年代を超えてくるとウェブサービスと呼ばれる巨大なシステムが作り上げられるようになりました。ウェブサービスは全体が継続的に稼働することが求められ、それを構成する各システムは切れ目なく連携続けなくてはなりません。各システムはサービス全体に組み込まれるように作られるため、インターフェースは明確なものの、それら自身の構成はライフサイクルやメンバーにしたほうが効率的でした。
これが民主制の時代。国全体としては明確な境界線を持っており中央政府も存在しますが、地方の統治は個別の自治体に任されています。地方自治体には権利はあるものの国としてのまとまりが求められるわけです。
もちろん、細かいアラはあるのですが巨大な企業システムを国に例えると、時代と共に成熟していくのは当然のように思います。
ITサービス運営におけるアーキテクチャの役割
2014年11月15日に開催されたJJUG CCC 2014 Fallにて「Javaエンジニアのためのアーキテクト講座」と題して発表を行いました。資料は以下です。
「良いアプリケーションを作る」時代から「良いITサービス運営を実現する」時代になったことで、アーキテクトの役割はどうなったか、という内容を話しました。
今回は自分なりにITサービス運営というものをモデルを書いてみました。v0.1となっていますが、まだまだ見直せることはあると思っています。
元ネタはソフトウェア品質モデルです。ソフトウェア品質モデルでも「外部」「内部」といった静的な要素に加えて、「利用時」「プロセス」といった動的な要素も含めて、お互いに依存したり影響を与えたりするということが定義されていました。ITサービス運営ということを考えて、もう一歩、複雑な構成となっています。大きく分けて「ITサービスを構成する要素」と「ITサービス運営に関わる利害関係者」となります。
ITサービスを構成する要素
| 要素名 | 特徴 | 例 |
| 利用者の体験価値 | 利用者が体験して感じるもの 利用者によって評価が異なる |
AさんとBさんで評価が異なる |
| サービスの振る舞い | 外部から見てわかる振る舞い 誰がテストしても同じ結果 仕様（機能と非機能） |
仕様とテストケース 品質特性 API |
| 動的な構成 | システム実行時の要素と相互作用 流れ、実行、プロセス |
インスタンス 処理 実行環境/インフラ |
| 静的な構造 | 成果物が配置された静的な構造 後に残り、参照可能 |
ソースコード クラス、テーブル定義 ドキュメント |
ITサービス運営の利害関係者
| 要素名 | 特徴 | 関心事 |
| 企画プロセス | ITサービスの振る舞いを管理する 振る舞いの追加や変更を要求する |
売上 要求 |
| 開発プロセス | 静的な構造を作る 構造を追加し、変更する 素早さが求められる |
リリース計画 開発ツール |
| 運用プロセス | 動的な構成を管理する 動的構成の追加や変更を受け入れる 安定が求められる |
デプロイ 監視 |
| 業務プロセス | ITサービスを利用し、利用者にサービスを提供する 利用者からフィードバックを得る 安定が求められる |
現場 効率化 |
このITサービス運営モデルで考えるべきことは以下の4つです。
- 個別の関心事を持つ利害関係者がいる
- 価値は利用者の体験によって定義される
- 複雑な構成要素によって成り立つ
- フィードバックによって持続的に成長する
これらの観点を考慮しつつ、各要素のバランスをとることがアーキテクチャの役割であり、それをデザインすることがアーキテクトの仕事ということになります。アーキテクチャ設計を進める上でも、そういった各要素を意識することが大事です。
もっと書きたいのですが、時間がないので詳細については資料を確認してください...。
オンラインでのフィードバックを見ていると「内容が難しくて分かりにくかった」というのがいくつかありました。モデルまでは理解していただいていていたようですが、後半のアーキテクトに求められる作業やスキルあたりが飛ばしすぎました。ここは反省をしております。次回、こういった機会には、もっと分かりやすく伝えられるようにします。
最後に書きましたが「アーキテクト的な発想」は職業がアーキテクトでなくてもできます。むしろ、すべてのエンジニアがITサービス運営全体を意識するというのは非常に大事なことだと思っています。
アーキテクチャのトレンドサマリ（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マネジメントを把握されているというのが伝わります。
他の会社で、変なセキュリティコンサルをいれて作業効率が落ちたり、とりあえず外注切って技術力が落ちたり、そういう残念な影響が生まれないことを祈るばかりです。
