検索
  • 平鍋健児

ビジネスに追いつけない日本式システム開発の構造欠陥

最終更新: 2019年6月4日

デジタルビジネスに活かすアジャイル開発(第3回)

前回は、「リーンスタートアップ」の登場によって、「シリコンバレー流」のイノベーションの作り方が定式化され、それが破壊的イノベーション、DX(デジタルトランスフォーメーション)の流れの中で、既存の大企業もそのやり方に注目を始めたことを、アジャイルの歴史とともに振り返った。


バックナンバー


現代の「探索型価値創造」、特にソフトウエア中心のイノベーション、DXで大切なのは以下の事柄である。

  • ニーズ(顧客)とシーズ(製品)の両方を低燃費で育てる続けること。

  • 企画と開発を組織分離せず、一体活動とすること。

  • そのために、サイロ(既存組織の枠)を取り払ったチームを作ること。

  • さらに、モチベーション重視の働き方、チャレンジと失敗を許す文化の醸成を経営が主導すること。

現在、キーワードとしてのAI、IoT、クラウドといったIT活用のインフラや要素技術に注目が集まっているが、実際には組織や人材をアジャイルを基礎にする「マインドシフト」、「組織構造シフト」が必要になる。


マインドシフト、探索型価値創造については、IPA のITSS+ のアジャイル領域から2019年4月に出されたガイドの以下が秀逸なので紹介しておく(後に解説予定)。

この問題に入る前に、今回は、日本における伝統的なシステム開発の構造、起こり始めている変化について考察していこう。


ソフト開発に関する日本の産業構造の特徴


まず、ソフトウエア開発に関する日本の産業構造の特殊性を指摘したい。日本では不思議なことに「ユーザー企業」(利用者側)と「IT企業」(提供者側)に分けてIT企業群を捉えることになっている。国内企業が参加する協会も2つに分かれており、「日本情報システム・ユーザー協会(JUAS)」(=ユーザー企業側)、「情報サービス産業協会(JISA)」(=IT企業側)、となっている。では、実際にITエンジニアがどちら側に属するのか、という調査の結果が下図である。

(出所:『IT人材白書』 IPA 2017~ITエンジニアが主体的に挑戦できる場を作れ~)

このように日本では圧倒的に提供側のIT人材が多い。これは欧米に比べると顕著な傾向である(筆者がかつて携わった同様の調査でもほぼ同じ結果だし、業界の中での「実感」としても強く認識してきた)。


この理由にはいくつかあるが、筆者は日本の特殊性として以下の要因が大きいと考えている。

  1. 日本発で製品市場に通用するプロダクトが少なく、国内ユーザー企業なしに国内IT企業が成り立たないこと。

  2. 1980年代にユーザー企業が情報システム部門を分離子会社化し、給与体系と役割を本社と分け始めたたこと。

  3. 新卒採用から1社で勤め上げることをよしとする終身雇用の習慣がいまだに存在しており、さらに解雇が規制されているため、人材の流動性が低いこと。

米国は、MicrosoftやApple、Oracleが誕生した1970年代から(さらにその前のIBM、DEC、HP時代から)、世界市場にOSや基盤ソフトウエアを提供し続けている(日本もこの時代は強かったのだが)。


さらに90年以降はGoogle、Amazon、Facebook、Twitter、SalesforceなどWebサービスとしてソフトウエアプラットフォームを提供する企業が大成長を遂げる。そして、2000年代後半に、Dropbox(2007)、Uber(2009)、Airbnb(2008)、Pinterest(2010)などのユニコーン(時価総額10億ドルベンチャー)が登場する。彼らの会社の従業員は、ほとんどがソフトウエアエンジニアやデザイナーだ。90年代のこの時代に、世界市場で成功する「ソフトウエアをコアとしたプロダクト」が日本から出てこなかったというのが、この構造を決定づけたのかもしれない。


一方で海外では、金融のような老舗の産業でさえソフトウエア人材を内部で大切にしている。たとえばゴールドマン・サックスでは社員の中のエンジニア比率が25%であるという。ITを自身の強みの中核として認識し、採用、インソースしていることの表れであり、日本の金融機関では考えにくい数字だと思う。


日本の1980年代の様々な産業における「システム子会社化」は自然な流れだったのだろうか。背景には、ITシステムは「外部から調達するもの」だという発想がある。また、ITを開発する能力は企業にとってコアコンピタンスではなく、別の組織(会社)として運営すべきだ、という考え方に基づいていたと推察する。ITはあくまでも製造物であり、仕様を提供して、入札・応札を行い、同じ仕様で最も品質がよく、安くいいものを調達する、すなわちソフトウエアを「工業製品化」する、という思想がそこにある。


ところが、DXでは「ソフトウエアは会社のコアビジネスに強く関わる」と考えなければならない。また、ビジネスを進めながらプログラムの仕様を決めたり修正していくDXやイノベーションは、ビジネスとITを分離させる構造とは非常に相性が悪い。


上記の図にははっきり表れていないが、米国の「IT企業側」にはそういったイノベーティブなソフトウエアプロダクトを開発しているエンジニアが多く含まれている。プラットフォーマーたちは、自分たちが開発するプラットフォームの提供を通じてビジネスが成り立っているのだ。対して日本の「IT企業」側は、多くの人たちが「SI」と呼ばれるユーザー企業からの受託請負開発に属していると考えられる。


日本のSI、またそれを生業とする「SIer」という事業領域では、「ユーザー企業」からのRFP(Request For Proposal:提案依頼書)を受け大きな開発を請け負うために、そのまとめ役になる開発大企業(プライムコントラクタ、1次請け)があり、その商流の下に2次請け、3次請けという徐々に受注単価が低いソフトウエアハウスがぶら下がり、ピラミッド構造を作っている。


ソフトウエア開発は「壮大な伝言ゲーム」?


ユーザー企業側の情報システム部門にITスキルを持った人材が少ないことは前述したとおりだが、ほかにも逆風として、実際のビジネス部門から見てコストセンターとなっている場合がよくある。ITを安く調達すること、失敗が許されずうまく行って当然という圧力もあり、さらに強いトップダウン管理をしがちになる。そのために、大きなSIerと協力して言葉を選ばなければいわゆる丸投げに近い形でリスクを分け合う開発体制をとらざるを得ない。


こうなると、ソフトウエア開発は「壮大な伝言ゲーム」と化す(下図)。末端のエンジニアに渡ってくる情報は期限つきの細切れ情報になり、それをこなすだけの無機質な仕事になりがちである。そんななかでも、目的を共有しながらモチベーションを維持するマネジメントと、達成のために奮闘する現場エンジニアたちに、日本のSIは支えられてきたのだ。この辺りを自身の経験もふまえて自虐的に語ることもできるが、これを変えていきたい、というのが私のモチベーションになっている。


このような開発ではSIerのPM(プロジェクトマネジャー)と呼ばれる役割が重要であるが、若くしてこの職種についた人材はプログラミングや設計をする経験が少ないので、中身がよく分かっていない(IT、プログラミングについての足腰がない)ことが少なくない。それにもかかわらず、プロジェクトのスケジュール線表管理、発注業務、顧客との交渉、成果物の受け入れと複数ベンダーの調停などに精力を傾けなければならないのだ(もちろん、これらは大規模プロジェクトの中ではきわめて重要な仕事である)。




現在、時代の波とともにこの構造が変わりはじめている。次回はそのあたりについて書いていきたい。


次の記事

アジャイルスタジオ福井では、実際にアジャイル開発を行なっている現場見学を受け入れています。ご興味があれば、こちらへからどうぞ。



410回の閲覧
ASF_logo_line.png
  • Facebook

 お電話でのお問い合わせはこちら

0776-25-8488

平日10:00~17:00まで。セールス目的のお電話はご遠慮ください。 

set-baseE_Y.png
ITS_logo_sign2.png

​株式会社永和システムマネジメント

​ITサービス事業部

 〒918-8231 福井県福井市問屋町3丁目111番地
 

© 2019 ESM, Inc.