拝啓『変わらない開発現場』を嘆く皆様へ ~変わっていくエンタープライズ系業務システム開発とマイクロソフトエンタープライズサービスの取り組み~


image

 昨年、今年と 2 回に渡って de:code にてエンプラ系 SIer さんの PL, PM, SE を対象としたセッションを担当しました。エンプラ系 SI の『闇』はかなり深いものがあり、現場担当の方々はそれを改善すべく日々奮闘されていると思うのですが、その一方で、全体論としての捉え方が正しくないが故に、アプローチが誤っていたり掛け声だけで終わってしまっているケースも少なくありません。例えばエンプラ系開発現場でも最近はトップダウンで DevOps に取り組め、なんていう指示が出たりすることもあるのですが、実際にそれがうまくいっているお客様をなかなか見かけないのも事実です。

 こうした背景があり、de:code 2017 ではセッションを担当すると同時に、参加者全員に配布するマーケティングのリーフレットを使って、筆者赤間の所属するマイクロソフト エンタープライズサービス(有償サービス部門)での最近のコンサルティングの取り組みをいくつかご紹介するという試みをしてみました。マーケティング部門の費用を使っている関係で、弊社サービス部門の営業色が入った内容にはなってしまっているのですが、その一方で、この情報は(特にエンプラ系 SIer やエンド IT 部門、IT 子会社のマネジメント層の方々にとって)組織やチームをどういった方向に導いていけばよいのかの指針になる、とも考えています。実際、いくつかのお客様でこの取り組みを私からご紹介したのですが、自組織の今後の方向性を整理する上で非常に参考になった、という F/B が多かったです。

 個々の皆様の事情はそれぞれ違えど、多少でも参考になる部分があればと思い、blog 化してこちらのサイトにも掲載することにしました(基本的な骨子はリーフレットと同じですが、ページ数の関係で書ききれなかったことを加筆修正しています)。よろしければぜひご覧いただければ幸いです。


■ エンプラ系 業務システム開発を俯瞰する

 クラウドに代表される昨今の技術革新は、業務システム開発の在り方に大きな影響を与えてきました。インフラ、アプリ、運用などの領域に分けてみると、以下のような変化が起きています。

image

 これらの中でも特に重要なのが、「アプリ特性に応じた開発のやり方をする」という考え方です。様々な分類方法が提唱されているのですが、ここではシンプルでわかりやすい、SoE(System of Engagement / お客様との絆を強めるためのシステム)SoR (System of Record / 事実を記録していくためのシステム)という分類を取り上げてみます。SoE 型システムとは「コンシューマ向け、フロントエンド、オープン、B2C」といった特性を持つシステムで、代表例としてはコンシューマ向け Web サイトやゲームアプリ。一方、SoR 型システムとは「エンタープライズ系、バックエンド、基幹系、B2B/B2E」といった作成を持つシステムで、代表例としては金融系勘定システムのようなものが挙げられます。

image

 並べてみると明らかなように、これらはシステム開発としての基本的な特性が大きく異なります。例えば 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

 こうした背景を元にすると、私を含めた、エンプラ系 SI 界隈に携わる人々が取り組まなければならない課題は主に以下の 2 つであると考えています。

  • ① SoR 型システム開発における、更なる開発生産性の改善
  • ② 先進的ビジネスのための SoE 型システム開発への取り組み

 以降では、これらに関する私の考えと、マイクロソフト エンタープライズサービスによるコンサルティングの取り組みや事例をご紹介していきます。


■ ① SoR 型システム開発における開発生産性の改善 ~開発近代化コンサルティングサービス~

 開発技術の進化があれば、その恩恵により開発生産性は改善されるはずです。……にもかかわらず、実際のエンプラ系システム開発現場ではその進化の恩恵を受けられていないことが多いのではないでしょうか? これには様々な理由があると思いますが、中でも大きな理由のひとつとして、日本の SI 商慣習(多重請負構造)における『上流』の仕事のやり方が、10 年以上も変化していない(ような現場が多い)ことが挙げられると私は考えています。

image

 当たり前のことですが、モノづくりのやり方が変われば、設計手法やプロマネ手法もそれに合わせた見直しが必要になります。この点は、私が昨年・今年と 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

 上図に示したのはシステム開発の業務遂行に必要な「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

 内容としては、開発プロセス、チーム編成、外部設計、内部設計、ソフトウェアテストなどについて、日本の現状や欧米でのベストプラクティス、また日本の様々な現場に見られる課題の解決のヒントなどをひたすら紹介していく、というものになっています。実装方法を解説するものではないので、コードはほとんど出てこず、それ故に特にマイクロソフト技術に縛られる内容にもなっていません。実際の開発現場において「なぜそれをしなければならないのか」というところに踏み込むことで、プロマネ・業務 SE として外してはならない要点、SI において『幹』となる考え方やタスクをきちんと理解・習得していただくことを目的としています。

 また、こちらは単発トレーニングとして実施することも多いのですが、より踏み込んだお客様では、この内容を元に実際のお客様プロジェクトにおける設計・テストドキュメントの改善レビューを行い、より一層深い理解・改善をしていただいていることもあります。

[B. アーキテクト育成プログラム]

 もう 1 つは、そもそもの問題の根幹であるアーキテクト不足を解消するために、社内アーキテクトを育成していくプログラムです。アーキテクト育成のための設計・実装技術のスキルトランスファーといった昔ながらのサービスも手掛けていますが、アーキテクトとしての重要スキルの一つであるコンサルテーションスキルについても OJT での育成サービスを行っています。

 もう少し具体的に書くと、SIer や IT 子会社におけるアーキテクトは非常に貴重な人材であるため、共通部門(CoE, Center of Excellence)に集約され、下図のような様々なミッションを担っていることがよくあります。こうした人材はアーキテクトとしての活動を通して、究極的には現場向けの社内コンサルタントになっていくことが望ましいのですが、一朝一夕にコンサルタントとしての立ち振る舞いができるようになるわけでもありません。そこで弊社コンサルタントが『お手本』となって、ガイドラインの作成支援や実際の現場プロジェクト支援などに参画し、メンバーを育てていくといったこともしています。

image


■ ② 先進的ビジネスのための SoE 型開発への取り組み ~PoC ラボによるアイディアの早期具現化~

 さてここまで述べてきたように、SoR 型システム開発の改善は、従来のやり方の延長線で考えていくことが可能です。しかし SoE 型システム開発への取り組みに関しては、全く異なる発想とアプローチが必要になります。これについて、ビジネス的な背景も含めて少し掘り下げます。

 ご存じのように、昨今の IT(デジタル)は人々の生活(アナログ)をあらゆる面で支え、よりよいものにしています。このような変化は「デジタル変革」(デジタルトランスフォーメーション)と呼ばれていますが、このデジタル変革は極めて急激に進むという特徴を持っています。具体的に言うと、ひと昔前であれば Facebook や Google、そして最近であれば Uber や Airbnb などといった、いわゆるスタートアップと呼ばれる企業は、恐るべき速度でサービスを拡大してきました。そして既存企業がその速度についていけず、あっという間に既存ビジネスが破壊されるということが現実のものとなっています。

 この既存ビジネスの破壊において重要なポイントの一つは、そこで使われている技術は必ずしも新しいものではない、という点です。よく語られることですが、例えば 2007 年に発売された iPhone は、当時の既存技術を組み合わせて作られており、iPhone のために何か全く新しい技術が発明されたというわけではありません。この例からわかるように、現代は、すでに多数の「発明」(AI や VR などの革新的技術)が存在しており、それが「ユースケース」(使い方・ニーズ)の発見を待っている、そしてそれを最初に見つけてビジネス化できた人がイノベーションを起こす、という形になっているわけです。

image

 こうした「ニーズ」の発見には Try & Error による試行錯誤が欠かせませんが、昨今はクラウドの登場、デバイスのコモディティ化などによって IT 技術の利用コストが大幅に低減しており、挑戦のためのハードルが昔に比べて圧倒的に下がっています。その結果、数多のスタートアップ企業がリスクをどんどん取って、イノベーションへの挑戦(簡単に言えば「一発当てる」ための挑戦)を繰り返している、という状況が生まれています。米国におけるスタートアップブームの背景にはこうした IT 環境の変化があるわけです(このあたりは馬田さんの良著「逆説のスタートアップ思考」にて詳細に解説されていますので、興味がある方はご一読いただくとよいと思います)。

 上記のような状況を元に考えると、先進的テクノロジを使った新しいビジネスの取り組みに必要なポイントは以下の 3 つであり、マイクロソフト エンタープライズサービスではこれらに対応するサービスをそれぞれ展開しています。

image

 以下に順に解説します。

[A. 最新テクノロジの理解(インベンションの理解)]

 革新的なサービスを考える際、シーズ(種)となる最新技術を知ることは極めて重要です。特に事業部門のお客様に近ければ近いほど、ビジネスに深い造詣がある一方、最新技術を知らないことが多くなるため、こうした最前線の方々の業務知識と、最新技術とを突き合わせてみることがより重要になってきます。

 とはいえ数多の技術をすべて把握することは非現実的でもあります。こうしたことから、弊社では定着期に入りつつある技術を効率的に把握するための最新技術セミナーを用意しています。このセミナーによって、ビジネスアイディアとマッチングできる最新技術を探っていくわけです。

image

[B. ビジネスニーズの深掘り(ユースケースの模索)]

 2000 年以降に成人になった若者の方々をミレニアル世代と呼びますが、消費世代に差し掛かってきたミレニアル世代の人々の考え方は、旧世代の人たちとは大きく異なることが知られています。よく言われることとして、デジタルネイティブである、所有欲がない(シェア・利用)、出世よりワークライフバランス、自分が納得したものを消費する、ソーシャルで緩く繋がる、といったことが挙げられますが、こうした価値観の変化にうまく追随できていない既存企業が増えつつあります。

 実はこの問題はミレニアル世代に限った話ではなく、リーマンショック以降の生活様式の変化や人々の価値観の変化といったものに追随できないことで、新しい企業にお客様を奪われていくことがしばしば発生します。その大きな理由の一つとして、「従来型のビジネスを熟知していること」、すなわち過去の成功体験が発想・思考の妨げになることが挙げられます。こうした課題を解決していくためには、なによりお客様を深く理解すること、そしてそこから隠れたビジネスニーズを深掘り・発見していくことが必要になりますが、そのための手法として最近着目されているのが、デザイン思考(Design Thinking)と呼ばれる手法です。

 本論から逸れるため、ここではデザイン思考の詳細に立ち入ることは避けますが、もともとデザイン思考は優秀なデザイナさんによる物事の「思考方法」「考え方」を真似るところからスタートしており、下図に示すような発展の経緯を辿ってビジネスの世界へと入ってきています。このことからもわかるように、デザイン思考そのものは必ずしも IT に限定されるものではないのですが、近年では、こうした「優秀なデザイナさんによる物事の思考方法」を、各業界に特化した形で進化・発展させ、より使いやすい手法(プロセス)としたものが各社から提唱・提供されているようになってきました。

image

 マイクロソフトでもこうした流れを受け、デジタルエンビジョニングワークショップ(DEWS)という手法を開発し、サービスを提供しています。これはお客様への深い洞察を元に、新たなイノベーションを IT 技術との組み合わせにより生み出していくビジネスデザイン手法を体系化したもので、デジタルトランスフォーメーションへの足掛かりとして、現在マイクロソフト エンタープライズサービスよりサービスを提供しています。

image

[C. プロトタイプによる PoC 検証(Try & Error による模索)]

 さて、最新技術とユーザニーズの掛け合わせから生まれたアイディアは、PoC (Proof of Concept、プロトタイピングによる概念検証)により素早く具現化・検証していくことが必要です。前述したように、今日では IT 実現コストの低減により「まずは試してみる」ことが昔に比べて圧倒的に容易化しています。アイディアを素早く形にして試しいみることで、お客様からの F/B を早期に得ることができ、より優れたアイディアやビジネスに昇華させていくことができるわけです。

 こうしたアイディアの素早い具現化のためには、以下の 2 つが必要不可欠です。

  • 社内 PoC ラボセンターの設置
    アイディアの具現化は素早く社内で行うことが必要であり、いちいち請負型でベンダーに発注することは非現実的です。このため、PoC アプリ開発チームは社内に持つ必要があります。(社内アーキテクトは SoR 型システム開発におけるアーキテクトロールだけでなく、こうした取り組みでも活躍してもらう(=アーキテクトの人たちが先端技術を使って直接プロトタイプを実装していってもらう)ことになります。)
  • 高速開発基盤の整備
    Azure などのクラウドをフル活用した開発基盤を整備し、PoC アプリ開発チームが作成したプロトタイプをすぐさま配置してテストできる環境を整えておく必要があります。

 なおこれらの取り組みは、SoE 型システム開発における PoC 検証はもとより、従来の SoR 型システム開発においても有効性が高いです。なぜなら PoC によるプロトタイピングで十分に UI などの要件を煮詰めたうえでベンダーに発注することにより、見積もりブレや手戻りなどのプロジェクトリスクを極小化することができるためです。

image

 弊社マイクロソフト エンタープライズサービスでは、上に示したような取り組みをしやすくするため、以下のようなサービスを展開しています。

  • PoC ラボセンターの提供
    弊社コンサルタントチームが(場合によってはお客様先に常駐して)実際に PoC を回し、高速にお客様アイディアを具現化していく。
  • Azure PaaS 開発基盤の整備
    Azure を利用する場合のリファレンスアーキテクチャガイドの整備などを実施する。

■ マネジメント層に求められる役割

 さて、ここまでマイクロソフト エンタープライズサービスが手掛けてきているエンプラ系 SIer 向けの取り組みをご紹介してきましたが、こうした取り組みを実際に進める際には、マネジメント層にも重要な役割を担っていただく必要が出てきます。それは、SoR 型システム開発と SoE 型システム開発とを分離し、そこに適切な経営レベルの判断を入れる、という点なのですが、このポイントは非常に重要なため、最後に解説して締めくくっていきたいと思います。

 前述した SoR 型システム開発への取り組みは漸進的アプローチ、すなわち従来の取り組みを改善していくアプローチである、ということができます。一方で、SoE 型システム開発への取り組みは革新的アプローチであり、リスクを取って進めていくべき性格が強いものです。このため、適用対象となるプロジェクトも違えば、個々の社員の向き不向きも異なってきます。もちろんノウハウを交換しあうことは重要ですが、全社一律のルールで管理しようとすると、様々なところに無理が生じます。故に、会社の中で、SoR 型システム開発への取り組みと、SoE 型システム開発への取り組みとをきちんと分けてそれぞれ考えることがまず重要になるわけです。

 また、特に SoE 型システム開発でイノベーションへ取り組む場合には、マネジメント層の『投資判断』が必要になることもしばしば発生します。イノベーションに必要なユースケースの発見には、相当な Try & Error が求められるのですが、実際のスタートアップ企業の打率はかなり低く(例えば 100 社に投資しても 1 社成功するかどうか、しかしその成功する 1 社は 1 万倍のリターンがある、といった具合)、ハイリスク・ハイリターンの博打的な側面があります。こうしたところに企業としての合理的な判断(例えば ROI や短期的なリターンなど)を求めると、イノベーションへの取り組みは必然的に失敗します(これをイノベーションのジレンマと呼びます)。

 こうした問題から最近着目されているのが「バーベル戦略」という考え方です。これは大半のリソースは従来通り安全牌にかけておき、一定のリソースをハイリスク・ハイリターンに賭けてイノベーションを目指す、というものです。先に述べたように、スタートアップ的な領域への投資では一発の大当たりが他のすべての失敗を帳消しにするものの、実際には「全部失敗することもありうる」わけで、余剰体力が残っているうちに、余剰体力で新しいビジネスの芽を見つけるために頑張るわけです。

image

 マネジメントは何かと現場に 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 ごと、開発現場ごとにそれぞれ異なると思います。本エントリの解説を参考にしていただいて、現場改善のための具体的な戦略立案、そして実行へとつなげていただければ幸いです。


Comments (3)

  1. nakama より:

    ネット上での反応は、可能な限り拾っていきたいと思います。あくまで私の個人的な考えですが、皆様が何かを考えるきっきけになれば。

    Kouichi Nishizawa(19‏ さん
    https://twitter.com/koty/status/868984155169726464
    > “欧米の国内に残った「高付加価値 SI」は、(中略)(内製でないと成立しないような) SoE 型のような先進性を求めたものになる。” まだ時間がかかるけど日本もこうなるのでは。

    少なくともこれまでは言語の壁でオフショアがうまく進まなかった実態があると思います。一方未来については……ぶっちゃけわかりませんが;、以下の2つの視点があるかな、と思います。

    ① 自動翻訳技術の発展で、日本でもオフショア活用が進む可能性はあります。が、残念ながら日本語の自動翻訳はまだ精度が低いことや、リアルタイムコミュニケーションに関してはまだ不十分なことなどもあり、そこの技術進化次第ではないかと感じています。(ここはどうなるか正直予測がつかないです;)

    ② そもそも内外の賃金価格差を活用したオフショア利用(身も蓋もなく言えば「大変なところを押し付ける」モデル)は、グローバル化による賃金格差の是正が進むと成立しなくなります。実際、インドや中国は賃金上昇によってオフショアの旨味が減りつつあり、最近は東欧へのオフショアも検討され始めているとか。

    ②については本質的な問題で、資本主義的に見れば単価の安い仕事は単価の安い場所や国に流れて当然と言われそうですが、果たしてそれは是か非か、という議論があると思います。米国でもオフショアが進んだときに国内の中小ベンダーが大打撃を受けていたという話もありますし、我々がその道を取ってもよいのだろうか? というと、ちょっと違う気もします。SoR 型システム開発の開発生産性改善(これはまだまだ可能だと思います)をしていかない限り、本質的な意味での成長はないのではないか? という気がしています。

    池田 秀一さん
    https://www.facebook.com/hidekazu.ikeda.3/posts/1500004060038551
    > 「SoR」の部分は、ERP や国産の業務パッケージや、クラウドサービスで済ませるのが良いと思うのだけど、個別開発する意味あるのかな?
    > 「SoE」の部分が、他社との優位性になる部分で、そこは個別開発やカスタマイズが多くなると捉えてる。で、Drupal は SoE の部分に使われて、SoR との接続にも使われてる(海外)

    基本的には私も同感なのですが、直近で見ると、以下の2つの課題があります。

    ① 非競争領域については他社と共有、というのは理想論としてはその通りなのですが、現実的にはなかなかこれが進まない(特に大規模であればあるほど)のが実態です。例えば金融勘定系で言えば、大手3行で勘定系システムはそれぞれ別。地銀などになってくるとパッケージも増えてきますが、過去の歴史や既存システム、横並びの競争意識、完全には切り離せないSoR/SoEのシステム特性など、乗り越えるべき壁は多いです。ただこの点に関しては、やはり各社がコスト的に回らないという理由により、少しずつ状況は改善しつつあるようにも感じています。

    ② SaaSなどのパッケージ製品が適用できる業務範囲は必ずしも広くない、という問題もあります。例えばメールやコラボレーションなどの領域はほとんど業界・業種を問わないので、マイクロソフトを初めとする各ベンダーが頑張って汎用ソフトウェアを開発しますが、これが業界・業種に絞り込まれていくと、当然市場規模が小さくなっていくので、汎用パッケージ製品も少なくなっていきます。
    この点についてはやはり国内だと言語障壁も問題で、英語圏の場合には国内市場が狭くてもグローバル市場を取りにいくことでパッケージ製品を成立させていますが、国内企業はこの辺が結構苦手なのではないかと思います。(これはIT業界に限らず再三指摘されていることではありますが)

    日本の場合は、パッケージ製品と言いながらも、ユーザ企業もベンダー側も、めちゃめちゃ個社カスタマイズを要求する/入れていく、というモデルが当たり前になっています(もはやそれはパッケージ製品ではなくただのカスタムSI)。ただ、この辺もいろいろ手痛い目を見て少しずつユーザ企業さんも含めて変わりつつあるので、これからは池田さんの書かれているような方向性に、少しずつ変わっていくのではないかと感じています。

  2. nakama より:

    さらに少し拾ってみますー。

    @sinya_alpha さん
    https://twitter.com/sinya_alpha/status/869144416329412608
    > 「社内にアーキテクトがいなくなっているケースが非常に多いです」アーキテクトがいなくなり我々協力会社しか中身を知らない状況はやっぱまずいね。

    ひどいケースになると、技術だけでなく業務も知らなかったりしますからね;(大汗)。
    ただこれに関しては、IT 部門や SIer が自分たちのビジネス(コアコンピテンス)をどう定義するのかが問題です。IT 部門の場合には、技術を追いきれないので業務だけに特化する、という考え方も成立しますし、SIer が「自分たちは保険業である」と定義するのであれば、技術丸投げという考え方も成立するのかもしれません。でももしそうなら、SIer さんのピンハネは極限まで削られてしかるべきですよね、ということかと。

    もっとも、中身がほとんど何もわからない状態で、どうして管理(プロマネ)ができるのかと小一時間ほど問いたいです。いやマジで;。

    @kkamegawa さん
    https://twitter.com/kkamegawa/status/868683234057404416
    > 技術がわかるアーキテクトって私が見聞きする範囲では求められてないんだよなぁ…。ひたすらプロマネ、ついでに技術をちょっとだけ知ってればいいという感じ(泥縄でやればいい)

    最近はエンプラ系でも、特にスマホアプリや HTML5 ベースのリッチな Web サイト開発などの領域では SIer 中抜きがしばしば見られるようになってきています(技術わかってない・作れない・提案力ない、という状況だと、従来の SIer さんと付き合う意味がない = 技術力のある中小ベンダーに直接発注してしまう)。

    日本の場合、系列会社へ優先発注することが多いため、まだ「雇用を守られている」会社さん(特にシステム子会社さん)は多いのですが、私が接していても、危機意識は会社や人によってホントにまちまちです。意識の高い中堅層は非常に多いと思うので、少しずつでも現場改善を進めていって欲しいところです。

    @ktana_ さん
    https://twitter.com/ktana_/status/869394064675753984
    > 正直今の会社が変わっていくように頑張るよりも転職した方が早そうだよなぁ…

    積極的に転職を勧めるつもりもないのですが;、『実力行使』でしかわかってもらえないこともある、とは思います。でもそれは本当に最後の最後であって欲しいと願うばかりです。

    @nagise さん
    https://twitter.com/nagise/status/869370379025788931
    > 今のプロジェクトはSoEとSoRの両方の特性が混ざっている感触があるなあ。B2C的な業務システムだとどうしてもね

    はい、SoE/SoR の両方の特性が混ざるシステムは非常に多いです。特に最近だと、基幹系システムでもフロントエンド UI は高機能化・高ユーザビリティが求められるケースが増えており、フロントエンドとバックエンドを切り離して考えるケースが多いです。

    バックエンド → SoR 型、Web API などを使ってラッピング(手堅く作る)
    フロントエンド → SoE 型、アジャイルに素早く UI 改善を繰り返していく

    最近はやりの “API 化” だとか “レガシーシステムの Modernization” と呼ばれるのは、概ねこういうシステム構成で考えられていることが多いです。もっとも実務レベルだと「そんなに話は単純じゃないよ」とツッコミたくなることはしばしばあるのですが;。

  3. nakama より:

    さらに拾い続けてみます^^。

    @ruicc さん
    https://twitter.com/ruicc/status/869423917827366913
    > 昔なんとなく切ったアウトソースの構造を変えられずに縮小していくのは、間違ったライブラリ選定の影響が後々まで影響してしまうようなものかな。そこのメンテナンスは経営陣がしないとだがそこに技術視点が入るか

    SI 子会社さんの場合、技術に明るくない社長さんが親会社から来るケースや、それが数年単位で発生するので方針がころころ変わる、といった課題もあるように感じています。ISV(独立系ソフトウェアベンダー)さんの方が(会社全体として)技術を大切にする傾向は強いです。

    基本的に日本の IT 業界は「欧米に倣え」の文化が非常に根強くあり、そのために 2000 年代にオフショアやアウトソースが持て囃されたと思うのですが、言語障壁に起因する環境の違いが想定以上に大きかった、というのが大きいと思います。ここの舵取り修正は今からでも必要だろうと思います。

    @kawasima さん
    https://twitter.com/kawasima/status/869550503528611840
    > SoRとSoEという分類の世間的なイメージはいささか短絡的で、SIerの課題でいうと失敗前提のプロセスを作れるかどうかと思う → http://qiita.com/kawasima/items/aefbe8ffefb14a685624

    Qiita の方も拝読させていただきました。私が書いている “SoR, SoE” という用語はご指摘の通り、当初の定義から離れて、現在、「世間的なイメージ」として使われている用語に近いです。このため、SoR, SoE の背後には、暗黙的にそれぞれ「受託開発(請負開発)」「内製」というニュアンスが含まれており、ここにこの問題の大半の原因が煮詰まっていると思います。

    @kawasima さんは「失敗前提のプロセスを作れるかどうか」を「SIer の課題」としているのですが、この点については議論を 2 つに分けた方がよいと思います。

    ・マクロスコピックに見た場合
    特に受託開発(請負型開発)の場合、これは受注する SIer の課題というよりも、発注するエンド側(IT 部門や IT 子会社側)の課題である側面が圧倒的に強いです。発注側が「完成」を条件として発注する以上、受注側が「失敗を前提とすることはできない」のは当然で、Try & Error でやってみたけどできませんでした、は請負型開発では契約上、許されません。

    本来的には、ウォーターフォール型であったとしても、フェーズ単位にプロジェクト停止条件をきちんと定めておくべきなのですが(というより本来のウォータフォールはそういうものですが;)、実際には機能していないことがほとんどで、「図体のでかいプロジェクトはなかなか止まれない」(=雪だるま式にコストが膨らんでいく)になるのが普通です。これは不健全そのものですが、その根幹原因は、発注側がプロジェクト停止(失敗)なんてものを想定していない・許していないから、ということが多いです。ここは発注側に意識改革が求められるところ(or SIer がもっと強気に出てもよいところ)です。

    ・ミクロスコピックに見た場合
    プロジェクト全体として失敗できなくても、ミクロスコピックな日々のタスクでは少しずつ失敗しながら(Try & Error しながら)進んでいくべき、というのは正しい考え方で、この点に関しては SoR/SoE どちらであっても変わらない、というのは @kawasima さんと同意見です。

    これらについては下記の blog にてより詳細に触れていますので、よかったらご覧ください。
    https://blogs.msdn.microsoft.com/nakama/2016/06/24/waterfall/

    @kyohei_ak さん
    https://twitter.com/kyohei_ak/status/869578729676132352
    > これかなり同意できるなぁ。特にアーキテクト不在問題。少なくともプロジェクトの舵をとるためには、「技術的な筋の良さ」がわからないと管理できないと思ってる。そこ下請けに丸投げしちゃうとデカいシステムは全体がイビツになるんだよなぁ…

    ですねー;。ちなみにマイクロソフトのコンサルティングが受託開発をする場合、ある一定以上の規模の案件の場合、財務的な観点と技術的な観点の両方からプロジェクトレビューが必ず入るようになっています。(TQA, Technical Quality Assurance と呼ばれており、私は TQA Reviewer の社内資格を持っています)

    あと、SIer で外注するケースであっても 15 年ぐらい前はおそらく普通に技術的レビューはできたんだと思います。(当時はまだ内製文化が少なからずあったので) しかし進化する技術に関して知識のリフレッシュを全くしてきていないので、当時のカビついた技術知識では今どきの技術レビューができない、という状況なんですよね;。なので今、悲惨な状況になっているのではないかと。

    @masatsugumatsus さん
    https://twitter.com/masatsugumatsus/status/869416502172065792
    > 社内コンサルだと責任とれないから、突っ込めなくて、改善につながらない。現場でアーキテクト担って改善しようとすると責任押し付けられる。
    > 現場のプロセスまで踏み込もうとするんなら、会社の上級管理職の支援か、アーキテクト個人が人間系も含めた高度な判断力やストレス耐性もってないときつい。だからなり手がいなくなる。
    > アーキテクトを育てようとするんなら、PJ全体として、プロセスや技術的チャレンジに対するリスクを理解し、問題が起こった時に支援しあう関係つくらなきゃだめだ。そして、それができるんなら、アーキテクトって役割が多分あまり目立たなくなって最後にはいなくなる。
    > だから、アーキテクトを探しても探しても常に足りない。アーキテクト要らずのPJを目指すのが近道と思う。

    2 つ目あたりまでは同感ですが、3 つ目の後半以降は私的には少し違和感がありました。「PJ 全体としてのチーム内のプロフェッショナリズム」として PjM や SE、アーキテクトのロールが認められるようになるのであれば、アーキテクトという役割が目立たなくなることはない、と思います。(PjM も SE もアーキテクトも一人の人間で兼務できるような内容じゃないからです。それぞれに専門性があります。実際、プロジェクト内で技術がよくわかっている人は間違いなく重宝されます。問題なのは「重宝」されるだけで報いられているわけではない、という点です;。)

    また、結論としての「アーキテクト要らずのPJ」はほとんどの場合、実態として成立しないかと思います。

    ・「アーキテクト要らずのPJ」が成立するなら、今のエンプラ系 SI はここまで悲惨なことになっていない。
    ・「アーキテクト要らずのPJ」は、言い換えれば「モノ作りをしないPJ」。つまり SaaS やパッケージソフトの導入で済む領域であれば可能だが、残念ながらそれがうまくいく業務領域は限られる。

    前者に関して補足すると、アーキテクト不要の PJ は IT 部門や SIer(の中の技術がわかっていない管理職の人)がめちゃめちゃ模索しているわけですが、実態として成功していないわけで(そりゃ成功するわけないだろう常考とか思うわけですが;)、「歴史と現状がそれを証明している」のではないかと。

    ただ、@masatsugumatsus さんの書かれている嘆きは非常に共感するところがあって、今は会社の上級管理職の支援もなく、アーキテクト個人が孤軍奮闘して頑張って、それがいいように会社や組織に食われてしまっている、という実情があると思います。そりゃアーキテクトが転職して SIer から人材流出するのも当然だよね、と;。このあたりの悲喜こもごもは先日の de:code スライドでいやというほど話したのですが(こちらのスライドですね > https://twitter.com/aqu_cc/status/866890802391203840 )、そろそろこの問題、SIer のマネジメント層な方々はまじめに考えないとホントに潰れますよ、とは言いたいところです。

Skip to main content