Image may be NSFW.
Clik here to view.
昨年、今年と 2 回に渡って de:code にてエンプラ系 SIer さんの PL, PM, SE を対象としたセッションを担当しました。エンプラ系 SIer の『闇』はかなり深いものがあり、現場担当の方々はそれを改善すべく日々奮闘されていると思うのですが、その一方で、全体論としての捉え方が正しくないが故に、アプローチが誤っていたり掛け声だけで終わってしまっているケースも少なくありません。例えばエンプラ系開発現場でも最近はトップダウンで DevOps に取り組め、なんていう指示が出たりすることもあるのですが、実際にそれがうまくいっているお客様をほとんど見かけないのも事実です。
こうした背景があり、de:code 2017 ではセッションを担当すると同時に、参加者全員に配布するマーケティングのリーフレットを使って、筆者赤間の所属するマイクロソフト エンタープライズサービス（有償サービス部門）での最近のコンサルティングの取り組みをいくつかご紹介するという試みをしてみました。マーケティング部門の費用を使っている関係で、弊社サービス部門の営業色が入った内容にはなってしまっているのですが、その一方で、この情報は（特にエンプラ系 SIer のマネジメント層の方々にとって）組織やチームをどういった方向に導いていけばよいのかの指針になる、とも考えています。実際、いくつかのお客様でこの取り組みを私からご紹介したのですが、自組織の今後の方向性を整理する上で非常に参考になった、という F/B が多かったです。
個々の皆様の事情はそれぞれ違えど、多少でも参考になる部分があればと思い、blog 化してこちらのサイトにも掲載することにしました（基本的な骨子はリーフレットと同じですが、ページ数の関係で書ききれなかったことを加筆修正しています）。よろしければぜひご覧いただければ幸いです。
■ エンプラ系 業務システム開発を俯瞰する
クラウドに代表される昨今の技術革新は、業務システム開発の在り方に大きな影響を与えてきました。インフラ、アプリ、運用などの領域に分けてみると、以下のような変化が起きています。
Image may be NSFW.
Clik here to view.
これらの中でも特に重要なのが、「アプリ特性に応じた開発のやり方をする」という考え方です。様々な分類方法が提唱されているのですが、ここではシンプルでわかりやすい、SoE（System of Engagement / お客様との絆を強めるためのシステム）、SoR （System of Record / 事実を記録していくためのシステム）という分類を取り上げてみます。SoE 型システムとは「コンシューマ向け、フロントエンド、オープン、B2C」といった特性を持つシステムで、代表例としてはコンシューマ向け Web サイトやゲームアプリ。一方、SoR 型システムとは「エンタープライズ系、バックエンド、基幹系、B2B/B2E」といった作成を持つシステムで、代表例としては金融系勘定システムのようなものが挙げられます。
Image may be NSFW.
Clik here to view.
並べてみると明らかなように、これらはシステム開発としての基本的な特性が大きく異なります。例えば SoE 型システムはページ数や業務数は少なめですが、かわりに極めて先進的な技術が投入されます。一方、SoR 型システムは、一つ一つのロジックはさほど難しくないものの膨大な数の業務が存在し、品質の安定性重視のために枯れた技術が好まれる傾向にあります。
また、開発特性が異なれば、求められる開発文化も当然異なります。例えば SoE 型システムでは「素早くリリースして素早く軌道修正していく」という Try & Error の文化が重視されますし、SoR 型システムでは「大規模システムを早く・安く・上手く作るためにいかにプロジェクトやメンバーを制御するのか」といった点が重視されます。
もちろん実際の個々のシステムはここまで両極端ではないでしょうが、この分類に従って考えてみると、いろいろ考えやすくなるのも事実です。例えば日本のシステム開発市場に関して考えてみると、
- いわゆるエンプラ系 SIer での業務システム開発は SoR 型システムが圧倒的多数。（この傾向は今後もおそらく変わらない）
- アジャイルやDevOps プラクティスは SoE 型システム開発界隈から生まれてきた手法であり、エンプラ系 SIer の SoR 型システム開発には単純適用できないことが多い。
- 最近ではお客様が新規性の高いビジネスを模索していることも多く、エンプラ系 SIer といえど SoE 型システムの開発に取り組まねばならないことが多くなってきている。
といった実情があるのですが、こうした状況が整理されないまま、DevOps やアジャイルは日本に定着するのか？ 的な議論が数多くなされています。こうしたことが、日本の開発現場の改善に向けた建設的な議論が進みにくいことの一因ではないかと私は考えています。
また加えて言うのであれば、私は日本と欧米とでは随分と状況が異なると考えています。
- 例えば、「欧米では Scrum が基本で DevOps が当たり前」と言われるが、そもそも欧米で 2000 年代にオフショア化が非常に進んだことを考えると、欧米の国内に残った「高付加価値 SI」は、必然的に内製でも成立するような（内製でないと成立しないような） SoE 型のような先進性を求めたものになる。よって、そこでアジャイルや DevOps などのプラクティスが進化・発展するのはある意味当たり前。
- その一方、日本は世界中でも言語障壁が特に高い国であり、欧米のように大規模 SoR 型システム開発をうまくオフショアできていないのが実態。結果として、国内には Web サービス系企業やゲーム業界のように積極的に DevOps プラクティスを活用する企業と、確実性をなにより重視し、膨大なドキュメントに基づく大規模な SoR 型システム開発を実施するエンプラ系 SIer 企業とがごった煮で共存している形となっている。
よく、「システム開発に関して日本はガラパゴスだ」と言われるのですが、むしろこれは逆で、実際には欧米（特にアメリカ）のシステム開発の方がある意味よっぽどガラパゴスなのではないかと思うのです。というのも、アメリカにおけるオフショア先であるインドや中国などにおいて大規模開発が行われる場合は当然受託開発であり、そこではやはりウォーターフォール的な開発文化が強いらしく（私の見聞きしている範囲なのでバイアスはあるかもしれませんが）、その部分に関しては、日本の SIer とあまり状況は変わらないように見えるのです。……と考えると、おそらく日本のシステム開発の市場というのは、簡単に言えば「世界の縮図」ではないかと思うのです。
しかしここで勘違いして欲しくないのは、仮に欧米のシステム開発がガラパゴス化していたとしても、そこからエンプラ系 SIer の SoR 型システム開発が学ぶべきこと・学べることはたくさんある、という点です。「ガラパゴス化」というのはあまりいい意味で使われない言葉ですが、最先端を突っ走ることによって多数の様々なプラクティス（実践的手法）が生み出されていることも事実であり、こうした内容は開発文化の違いを意識ししつつ（＝きちんと取捨選択しながら）積極的に取り入れていく必要があります。
Image may be NSFW.
Clik here to view.
こうした背景を元にすると、私を含めた、エンプラ系 SI 界隈に携わる人々が取り組まなければならない課題は主に以下の 2 つであると考えています。
- ① SoR 型システム開発における、更なる開発生産性の改善
- ② 先進的ビジネスのための SoE 型システム開発への取り組み
以降では、これらに関する私の考えと、マイクロソフト エンタープライズサービスによるコンサルティングの取り組みや事例をご紹介していきます。
■ ① SoR 型システム開発における開発生産性の改善 ～開発近代化コンサルティングサービス～
開発技術の進化があれば、その恩恵により開発生産性は改善されるはずです。……にもかかわらず、実際のエンプラ系システム開発現場ではその進化の恩恵を受けられていないことが多いのではないでしょうか？ これには様々な理由があると思いますが、中でも大きな理由のひとつとして、日本の SI 商慣習（多重請負構造）における『上流』の仕事のやり方が、10 年以上も変化していない（ような現場が多い）ことが挙げられると私は考えています。
Image may be NSFW.
Clik here to view.
当たり前のことですが、モノづくりのやり方が変われば、設計手法やプロマネ手法もそれに合わせた見直しが必要になります。この点は、私が昨年・今年と de:code で一貫して取り上げてきたテーマで、実践論として具体的なレベルまで踏み込んで解説しています（仔細は以下の ppt やビデオをご覧ください）。
- de:code 2016 CLT-016 拝啓『変わらない開発現場』を嘆く皆様へ ～エンプラ系 SI 開発現場の「今」を変えていくために～
https://channel9.msdn.com/Events/de-code/2016/CLT-016
https://docs.com/decode2016/9106 - de:code 2017 DO-08 『変わらない開発現場』を変えていくために ～エンプラ系レガシー SIer のための DevOps 再入門～
（ppt, ビデオは後日公開予定）
しかし上記のセッションで説明されているような「ベストプラクティス」がすでに存在するにもかかわらず、 Excel 設計書に代表されるように、日本の開発現場は昔ながらのやり方を淡々と続けていることが少なくありません。実際の開発現場を数多く訪問している私の肌感覚ですが、その最大の理由は、IT 部門や SI 関連会社、あるいは SIer のプロパーが、最新の開発技術やモノづくりのやり方を単に「知らない」、そしてその結果、それに併せた最適な SI のやり方を考えられなかったり、改善の打ち手を考えられなかったりすることが多いためだと考えています。
これは、SIer のプロパーが怠けている、ということではありません。いやむしろ、SIer のプロパーさんほど身を粉にして働いている方々はいないでしょう。にもかかわらずなぜこのような状況が発生するのか？ その原因の一つに、私は IT 部門や SIer における過度な外注やアウトソーシングがあると考えています。
Image may be NSFW.
Clik here to view.
上図に示したのはシステム開発の業務遂行に必要な「5 つの専門性」です（仔細はこちらのエントリを参照）。こうした役割を、SIer のプロパーさんと、協力会社の方々によって分担していくわけですが、このアウトソースの仕方に問題がある場合が少なくありません。通常、SIer のコアコンピタンス は「プロマネ」「業務」「技術」の 3 つですが、 行き過ぎたアウトソースや協力会社への依存により、 社内にアーキテクトがいなくなっているケースが非常に多いです。その結果、現場あるあるとして以下のようなことが起こります。……というよりホントにこんな現場ばっかです；（涙）。
- プロマネや業務 SE に対して 技術的視点から下支えする人材がおらず、技術的に正しい開発方針を取れていない。
- ベンダーや協力会社に対して不適切な指示を出してしまう。
- 技術がわからないので協力会社の成果物を全くレビューできない。
- 意味のない・効果の薄いドキュメントや報告書を大量に作らせてしまったりしている。
このアーキテクト不在問題は SoR 型システム開発の改善を考えていく上で極めて根深い問題です。これについては、de:code 2017 DO-08 セッションにて詳細に取り扱っているのでご確認いただければと思うのですが、こうした状況を改善していくための基本的な手立ては以下の 2 つです。
- 現在のプロマネや業務 SE の使っている、10 年前から進化していない SI 方法論を、近代的なものにリニューアルしていく。
- 社内に技術がわかるアーキテクトを育てて保有していく。
これらに関するマイクロソフト エンタープライズサービスの取り組みを私は「開発近代化サービス」と銘打っているのですが、具体的には以下のようなコンサルティングをお客様向けに実施しています。
- A. 中堅層のプロマネ・業務 SE の再教育プログラム
- B. アーキテクト育成プログラム
以下に順に解説します。
［A. 中堅層のプロマネ・業務 SE の再教育プログラム］
前述したように、モノづくりのやり方が変われば、設計手法やプロマネ手法もそれに合わせた見直しが必要になります。だからこそ、手持ちの仕事で忙殺されている業務 SE やプロマネの方々を、アーキテクトが技術面から下支えし、近代的な SI を実践していくことが必要なのですが、現状を踏まえると、以下の 2 つの問題があります。
- そもそもアーキテクトが SIer の中にいない（or 不足している）
- そもそも SoR 型システム開発における、「近代的な SI 手法」が（世の中的に）十分に整備されていない
これらのうち、後者は非常に大きな問題です。先に述べたように、欧米は内製ベースの SoE 型システム開発を前提として、アジャイルや DevOps といった手法・プラクティス群を開発・整備し続けてきました。しかしその一方で、受発注ベースの SoR 型システム開発に関する「近代的な SI 手法」の改善に関しては手つかずで放置されており、全体としてはほとんど進化していません。私見ですが、おそらくこの問題は日本固有の問題ではなくグローバル共通の課題であり、これに対するソリューションは誰かが先陣を切って新しく作っていかなければならない状況である、と思います。そしてその先陣を切れるのは、SoE/SoR 型システム開発が共存する国である日本をおいて他にないだろう、とも考えています。
なぜかというと、先に述べたように、SoR 型システム開発手法を進化させていく際には、SoE 型システム開発向けとして開発された各種の DevOps 系プラクティス群が参考になります。右から左に導入することはできませんが、本質論を踏まえて取捨選択しながら取り込んだり融合させていくことは十分にできるわけで（具体的な手法は de:code イベントセッションを参照）、こうした「SoR 型システム開発向けの近代的な SI 手法」を、自社の状況に併せて作り上げていくことが、SIer や IT 子会社の多くに求められている、と考えています。そしてこうした「他国／他社のいいところを参考にして、自分たちのやり方を上手に進化させていく」ことは、もともと日本のお家芸、だったのではないでしょうか？
幸い、私はマイクロソフトというグローバル企業に所属しており本社の R&D 部門の手法の話やDevOps 系プラクティスについて聞く機会が多いこと、また日本のいわゆるエンプラ系システム開発現場に向けたコンサルティングサービスを 15 年以上手掛けていること、そしてこの領域をなんとかしたいという思いがあり、日本独自のソリューションとして開発近代化サービスを開発し、展開しています。具体的には、主に現場経験 10 年程度のプロマネ・業務 SE を対象として、V 字型モデル開発の基本を、現在の開発技術やトレンドに沿った実践的手法と共に学び直す、という再教育プログラムを開発・デリバリしています（実は de:code の昨年・今年の私のセッションは、この再教育プログラムからごく一部を切り出したものです）。
Image may be NSFW.
Clik here to view.
内容としては、開発プロセス、チーム編成、外部設計、内部設計、ソフトウェアテストなどについて、日本の現状や欧米でのベストプラクティス、また日本の様々な現場に見られる課題の解決のヒントなどをひたすら紹介していく、というものになっています。実装方法を解説するものではないので、コードはほとんど出てこず、それ故に特にマイクロソフト技術に縛られる内容にもなっていません。実際の開発現場において「なぜそれをしなければならないのか」というところに踏み込むことで、プロマネ・業務 SE として外してはならない要点、SI において『幹』となる考え方やタスクをきちんと理解・習得していただくことを目的としています。
また、こちらは単発トレーニングとして実施することも多いのですが、より踏み込んだお客様では、この内容を元に実際のお客様プロジェクトにおける設計・テストドキュメントの改善レビューを行い、より一層深い理解・改善をしていただいていることもあります。
［B. アーキテクト育成プログラム］
もう 1 つは、そもそもの問題の根幹であるアーキテクト不足を解消するために、社内アーキテクトを育成していくプログラムです。アーキテクト育成のための設計・実装技術のスキルトランスファーといった昔ながらのサービスも手掛けていますが、アーキテクトとしての重要スキルの一つであるコンサルテーションスキルについても OJT での育成サービスを行っています。
もう少し具体的に書くと、SIer や IT 子会社におけるアーキテクトは非常に貴重な人材であるため、共通部門（CoE, Center of Excellence）に集約され、下図のような様々なミッションを担っていることがよくあります。こうした人材はアーキテクトとしての活動を通して、究極的には現場向けの社内コンサルタントになっていくことが望ましいのですが、一朝一夕にコンサルタントとしての立ち振る舞いができるようになるわけでもありません。そこで弊社コンサルタントが『お手本』となって、ガイドラインの作成支援や実際の現場プロジェクト支援などに参画し、メンバーを育てていくといったこともしています。
Image may be NSFW.
Clik here to view.
■ ② 先進的ビジネスのための SoE 型開発への取り組み ～PoC ラボによるアイディアの早期具現化～
さてここまで述べてきたように、SoR 型システム開発の改善は、従来のやり方の延長線で考えていくことが可能です。しかし SoE 型システム開発への取り組みに関しては、全く異なる発想とアプローチが必要になります。これについて、ビジネス的な背景も含めて少し掘り下げます。
ご存じのように、昨今の IT（デジタル）は人々の生活（アナログ）をあらゆる面で支え、よりよいものにしています。このような変化は「デジタル変革」（デジタルトランスフォーメーション）と呼ばれていますが、このデジタル変革は極めて急激に進むという特徴を持っています。具体的に言うと、ひと昔前であれば Facebook や Google、そして最近であれば Uber や Airbnb などといった、いわゆるスタートアップと呼ばれる企業は、恐るべき速度でサービスを拡大してきました。そして既存企業がその速度についていけず、あっという間に既存ビジネスが破壊されるということが現実のものとなっています。
この既存ビジネスの破壊において重要なポイントの一つは、そこで使われている技術は必ずしも新しいものではない、という点です。よく語られることですが、例えば 2007 年に発売された iPhone は、当時の既存技術を組み合わせて作られており、iPhone のために何か全く新しい技術が発明されたというわけではありません。この例からわかるように、現代は、すでに多数の「発明」（AI や VR などの革新的技術）が存在しており、それが「ユースケース」（使い方・ニーズ）の発見を待っている、そしてそれを最初に見つけてビジネス化できた人がイノベーションを起こす、という形になっているわけです。
Image may be NSFW.
Clik here to view.
こうした「ニーズ」の発見には Try & Error による試行錯誤が欠かせませんが、昨今はクラウドの登場、デバイスのコモディティ化などによって IT 技術の利用コストが大幅に低減しており、挑戦のためのハードルが昔に比べて圧倒的に下がっています。その結果、数多のスタートアップ企業がリスクをどんどん取って、イノベーションへの挑戦（簡単に言えば「一発当てる」ための挑戦）を繰り返している、という状況が生まれています。米国におけるスタートアップブームの背景にはこうした IT 環境の変化があるわけです（このあたりは馬田さんの良著「逆説のスタートアップ思考」にて詳細に解説されていますので、興味がある方はご一読いただくとよいと思います）。
上記のような状況を元に考えると、先進的テクノロジを使った新しいビジネスの取り組みに必要なポイントは以下の 3 つであり、マイクロソフト エンタープライズサービスではこれらに対応するサービスをそれぞれ展開しています。
Image may be NSFW.
Clik here to view.
以下に順に解説します。
［A. 最新テクノロジの理解（インベンションの理解）］
革新的なサービスを考える際、シーズ（種）となる最新技術を知ることは極めて重要です。特に事業部門のお客様に近ければ近いほど、ビジネスに深い造詣がある一方、最新技術を知らないことが多くなるため、こうした最前線の方々の業務知識と、最新技術とを突き合わせてみることがより重要になってきます。
とはいえ数多の技術をすべて把握することは非現実的でもあります。こうしたことから、弊社では定着期に入りつつある技術を効率的に把握するための最新技術セミナーを用意しています。このセミナーによって、ビジネスアイディアとマッチングできる最新技術を探っていくわけです。
Image may be NSFW.
Clik here to view.
［B. ビジネスニーズの深掘り（ユースケースの模索）］
2000 年以降に成人になった若者の方々をミレニアル世代と呼びますが、消費世代に差し掛かってきたミレニアル世代の人々の考え方は、旧世代の人たちとは大きく異なることが知られています。よく言われることとして、デジタルネイティブである、所有欲がない（シェア・利用）、出世よりワークライフバランス、自分が納得したものを消費する、ソーシャルで緩く繋がる、といったことが挙げられますが、こうした価値観の変化にうまく追随できていない既存企業が増えつつあります。
実はこの問題はミレニアル世代に限った話ではなく、リーマンショック以降の生活様式の変化や人々の価値観の変化といったものに追随できないことで、新しい企業にお客様を奪われていくことがしばしば発生します。その大きな理由の一つとして、「従来型のビジネスを熟知していること」、すなわち過去の成功体験が発想・思考の妨げになることが挙げられます。こうした課題を解決していくためには、なによりお客様を深く理解すること、そしてそこから隠れたビジネスニーズを深掘り・発見していくことが必要になりますが、そのための手法として最近着目されているのが、デザイン思考（Design Thinking）と呼ばれる手法です。
本論から逸れるため、ここではデザイン思考の詳細に立ち入ることは避けますが、もともとデザイン思考は優秀なデザイナさんによる物事の「思考方法」「考え方」を真似るところからスタートしており、下図に示すような発展の経緯を辿ってビジネスの世界へと入ってきています。このことからもわかるように、デザイン思考そのものは必ずしも IT に限定されるものではないのですが、近年では、こうした「優秀なデザイナさんによる物事の思考方法」を、各業界に特化した形で進化・発展させ、より使いやすい手法（プロセス）としたものが各社から提唱・提供されているようになってきました。
Image may be NSFW.
Clik here to view.
マイクロソフトでもこうした流れを受け、デジタルエンビジョニングワークショップ（DEWS）という手法を開発し、サービスを提供しています。これはお客様への深い洞察を元に、新たなイノベーションを IT 技術との組み合わせにより生み出していくビジネスデザイン手法を体系化したもので、デジタルトランスフォーメーションへの足掛かりとして、現在マイクロソフト エンタープライズサービスよりサービスを提供しています。
Image may be NSFW.
Clik here to view.
［C. プロトタイプによる PoC 検証（Try & Error による模索）］
さて、最新技術とユーザニーズの掛け合わせから生まれたアイディアは、PoC （Proof of Concept、プロトタイピングによる概念検証）により素早く具現化・検証していくことが必要です。前述したように、今日では IT 実現コストの低減により「まずは試してみる」ことが昔に比べて圧倒的に容易化しています。アイディアを素早く形にして試しいみることで、お客様からの F/B を早期に得ることができ、より優れたアイディアやビジネスに昇華させていくことができるわけです。
こうしたアイディアの素早い具現化のためには、以下の 2 つが必要不可欠です。
- 社内 PoC ラボセンターの設置
アイディアの具現化は素早く社内で行うことが必要であり、いちいち請負型でベンダーに発注することは非現実的です。このため、PoC アプリ開発チームは社内に持つ必要があります。（社内アーキテクトは SoR 型システム開発におけるアーキテクトロールだけでなく、こうした取り組みでも活躍してもらう（＝アーキテクトの人たちが先端技術を使って直接プロトタイプを実装していってもらう）ことになります。） - 高速開発基盤の整備
Azure などのクラウドをフル活用した開発基盤を整備し、PoC アプリ開発チームが作成したプロトタイプをすぐさま配置してテストできる環境を整えておく必要があります。
なおこれらの取り組みは、SoE 型システム開発における PoC 検証はもとより、従来の SoR 型システム開発においても有効性が高いです。なぜなら PoC によるプロトタイピングで十分に UI などの要件を煮詰めたうえでベンダーに発注することにより、見積もりブレや手戻りなどのプロジェクトリスクを極小化することができるためです。
Image may be NSFW.
Clik here to view.
弊社マイクロソフト エンタープライズサービスでは、上に示したような取り組みをしやすくするため、以下のようなサービスを展開しています。
- PoC ラボセンターの提供
弊社コンサルタントチームが（場合によってはお客様先に常駐して）実際に PoC を回し、高速にお客様アイディアを具現化していく。 - Azure PaaS 開発基盤の整備
Azure を利用する場合のリファレンスアーキテクチャガイドの整備などを実施する。
■ マネジメント層に求められる役割
さて、ここまでマイクロソフト エンタープライズサービスが手掛けてきているエンプラ系 SIer 向けの取り組みをご紹介してきましたが、こうした取り組みを実際に進める際には、マネジメント層にも重要な役割を担っていただく必要が出てきます。それは、SoR 型システム開発と SoE 型システム開発とを分離し、そこに適切な経営レベルの判断を入れる、という点なのですが、このポイントは非常に重要なため、最後に解説して締めくくっていきたいと思います。
前述した SoR 型システム開発への取り組みは漸進的アプローチ、すなわち従来の取り組みを改善していくアプローチである、ということができます。一方で、SoE 型システム開発への取り組みは革新的アプローチであり、リスクを取って進めていくべき性格が強いものです。このため、適用対象となるプロジェクトも違えば、個々の社員の向き不向きも異なってきます。もちろんノウハウを交換しあうことは重要ですが、全社一律のルールで管理しようとすると、様々なところに無理が生じます。故に、会社の中で、SoR 型システム開発への取り組みと、SoE 型システム開発への取り組みとをきちんと分けてそれぞれ考えることがまず重要になるわけです。
また、特に SoE 型システム開発でイノベーションへ取り組む場合には、マネジメント層の『投資判断』が必要になることもしばしば発生します。イノベーションに必要なユースケースの発見には、相当な Try & Error が求められるのですが、実際のスタートアップ企業の打率はかなり低く（例えば 100 社に投資しても 1 社成功するかどうか、しかしその成功する 1 社は 1 万倍のリターンがある、といった具合）、ハイリスク・ハイリターンの博打的な側面があります。こうしたところに企業としての合理的な判断（例えば ROI や短期的なリターンなど）を求めると、イノベーションへの取り組みは必然的に失敗します（これをイノベーションのジレンマと呼びます）。
こうした問題から最近着目されているのが「バーベル戦略」という考え方です。これは大半のリソースは従来通り安全牌にかけておき、一定のリソースをハイリスク・ハイリターンに賭けてイノベーションを目指す、というものです。先に述べたように、スタートアップ的な領域への投資では一発の大当たりが他のすべての失敗を帳消しにするものの、実際には「全部失敗することもありうる」わけで、余剰体力が残っているうちに、余剰体力で新しいビジネスの芽を見つけるために頑張るわけです。
Image may be NSFW.
Clik here to view.
マネジメントは何かと現場に ROI を求める傾向がありますが、ROI が算出できるのであれば、マネジメントの判断など不要です。原理的に白黒が付けられない投資（リソース投入など）に対して、自らの裁量、そして KKD （勘と経験と度胸）で判断をすることこそがマネジメントの仕事である、私はそう考えています。（← KKD はそういうところで使うべきものだと私は思います）
本 blog で解説したような取り組みでは、必ず投資モードで行う作業が発生すると思います……が、そうした取り組みをいつ、どの程度、どのような形でやるのか。それを判断しサポートするのはマネジメント層の役割であり、経営判断がどうしても必要な領域になります。マネジメント層の方々には、ぜひ現場メンバーの積極的な姿勢や取り組みをサポートし、会社やチームの活性化につなげていただければと思います。
■ まとめ
本 blog では、私が所属するエンタープライズサービス統括本部のコンサルティングの取り組みのご紹介を通して、『変わらない開発現場』に苦しむ IT 子会社さんや SIer さんの改善の取り組みのヒントになる情報を執筆してみました。要点をまとめると、以下の通りとなります。
- システム開発の改善を考える場合には、SoE 型システム開発と SoR 型システム開発とに分けて考える。
- SoE 型システム = 「コンシューマ向け、フロントエンド、オープン、B2C」といった特性を持つシステム、コンシューマ向け Web サイトやゲームアプリなど
- SoR 型システム = 「エンタープライズ系、バックエンド、基幹系、B2B/B2E」といった特性を持つシステム、金融系勘定システムなど
- これら 2 つは開発特性が全く異なるため、分けて考える必要がある
- 欧米の手法を右から左に導入するのではなく、システム開発特性を意識した上で導入する。
- アジャイルや DevOps などの手法は、SoE 型システム開発の文化の中で進化・発展してきたもの。
- 日本国内には SoE 型システム開発と SoR 型システム開発の両方が共存している。このため、SoR 型システム開発へ欧米の手法を導入する際には、各種プラクティスを取捨選択しながら段階的に導入し、現場改善につなげていく必要がある。
- SoR 型システム開発の改善は、以下の 2 軸で考えていくとよい。
- 現在のプロマネや業務 SE の使っている、10 年前から変わらない SI 方法論を、近代的な SI 方法論にリニューアルしていく。
- 社内に技術がわかるアーキテクトを育てて保有していく。
- SoE 型システム開発の改善は、以下の 3 軸で考えていくとよい。
- 最新テクノロジの理解（インベンションの理解）
- ビジネスニーズの深掘り（ユースケースの模索）
- プロトタイプによる PoC 検証（Try & Error による模索）
システム開発現場の悩みは、SIer ごと、開発現場ごとにそれぞれ異なると思います。本エントリの解説を参考にしていただいて、現場改善のための具体的な戦略立案、そして実行へとつなげていただければ幸いです。