このエントリーをはてなブックマークに追加LINEで送る

2.2. 価格破壊+やらされ仕事=低い満足度

ハッピィ・エンジニアリング表紙

 「2.1 丸投げ文化」で書いたように、システム業界とそれを取り巻く顧客の考え方は成熟しているとは言い難い。この丸投げの連鎖が「広告、景品、大幅値下げ」とでもいうような無秩序な競争状態を生む。プログラマを抱える開発会社は、「Javaができます、C言語ができます、何年経験しています」以外の尺度がない状況の中、よりいっそうの価格破壊を行う結果となっている。この状況における大きな問題のひとつは、ソフトハウスが無秩序な競争状態を作っているのではなく、元請け・一次下請けからの強い値下げ要求があることである。2002年初頭に、業績が大きく低下していた日本の有名メーカーが、下請け企業への単価を一律に10%削減するという宣言をしたのは記憶に新しい。確かに価格競争力は必要だが、それがむやみに行われているのであれば問題である。

 

 しかし、考え方を変えれば、それまでは元請け−下請けの信頼関係、下請け同士の人間関係やコネで実際に開発する開発会社が決まっていたものが、「純粋に」金額で発注先が決まったという時期でもあった。つまり、一部の領域で「技術者市場」が成立したわけであり、需要と供給のバランスの中で「商品」としての技術者の「価格」が、それ以前よりもずっと安く決定したことになる。ただし、経済学が想定している市場経済のモデルは商品がある程度均一であることを仮定している。しかし、難易度が高い大規模プロジェクトで考えた場合、プロジェクトに参加している「商品」としての技術者のレベルがまちまちである。*1

 

 そのため、一律10%削減という宣言により開発現場がおかしくなったという側面がある。今までコネがなく、なかなか新規参入できなかった優良な開発会社が価格競争に打ち勝って仕事を取れたというメリットもあったが、それ以上に低単価で低スキルの技術者を売り込んだ「安かろう、悪かろう」タイプのソフトハウスによるデメリットのほうが開発現場に与えたインパクトは大きかった。なぜなら、アプリケーション開発は、ほかの機能がどれだけよくできていても、ある機能に致命的な問題点があり最低レベルと評価されれば、システム全体が最低レベルと評価される特質があるからである。

 

 大規模開発では、多数のプログラマが並行して作業するため、チーム体制としては、どれだけ腕の立つ者がたくさんいるか、ということよりも、足を引っ張る低スキルの者がどれだけいるか、というほうが重要なのである。*2

 

 では、「ごくごく一般的な」中小規模の開発を考えた場合、このような価格破壊の状態がどのように映ったであろうか?

 

 難易度が高くない、ごくありふれたシステムにひと山いくらというレベルのプログラマたちが参加していると考えた場合には、「ほぼ均一な『商品』としてのプログラマ」という視点で見ることができ、市場が適正価格として値下げを要求したと考えることもできる。

 

 システム開発の場合、仕入れコストのほとんどが人件費である。人件費のほかに事務所経費の按分や社内教育のコストなどが積み上げられて最終的な人月単価となる。日本企業では「年功序列」の給与体系が用いられる。発注側の人月単価が削減された結果として、質の高い中堅・ベテランのエンジニアは会社にとって採算性のない大きな負担となり、早々に解雇の対象となる。中堅・ベテランのエンジニアが職を追われた結果として、品質の低下、サービスの低下、信用の失墜、業界全体の虚弱化へ向かっていくことになる。

 

 業務システム開発において、市場の獲得、競合他社との差別化は非常に難しい課題である。なぜなら、一般的な市場と同じ行動原理が通用しない場合があるからだ。一般的な市場における戦略の基本は、客観的な市場分析である。

 

  1. 市場全体が冷え込んでいるのか?
  2. 問題の原因は価格にあるのか?

 

 この分析をふまえたうえで、以下のような一般的な市場競争原理にあてはめる。

 

  1. 今までにないサービス、顧客のかゆいところに手が届くようなサービスを実施して、顧客満足度の向上を目指し、信頼を獲得する
  2. 事業のシェア拡大を通じて、さらに顧客のウオンツ(要望)をニーズに変えていく
  3. 結果として、顧客に効果と利益をもたらすことが業績として残る

 

 こうした観点で、新製品の開発・品揃え・品質の向上というような具体的な企業戦略や目標が生まれる。

 

 ところが、システム開発においては、市場、あるいはシェアの低下要因が価格にあるのか、それ以外の問題が発生しているのかをキャッチするのは非常に難しい。なぜならば、システム開発は全般的な景気動向によって決まるものではなく、企業戦略と密接な関連を持つからである。つまり、単なる人件費削減のためのシステムの開発・導入を除けば、システム投資は企業戦略に基づく先行投資としての意味合いが強い。

 

 したがって、景気の波を先読みし意志決定が行われる。後から見ると、景気動向からやや遅れてシステム需要が発生するケースが多いが、自業種の拡大基調を予測してシステム投資がなされることもある。そのため、システム開発市場はほかの市場より複雑な分析が要求される。顧客の属する業種全体の好不調や顧客の業績、法制度の変更の有無など、さまざまな角度から市場分析を行わなければならない。

 

 システムプロダクトであれば、この一般的な市場競争原理の適用が可能である。技術トレンドに合わせた製品開発、サポート体制の強化、より使いやすくするための機能追加、性能の向上など、さまざまなサービスの拡大を行うことができる。ところが、業務システム開発を考えた場合、一般的な市場競争原理をそのまま適用するのは困難である。例えば、「かゆいところに手が届くようなサービス」をシステム開発に適用した場合、現在の日本の商慣習では、その答えが「何でもできます。お任せください」といった丸投げ文化を認めてしまうことになり、顧客と一体になって優れたシステムを提供するという開発の本質から外れることになるだろう。

 

 結局、システム開発プロジェクトは、プロダクトの提供でも、半製品の提供でもなく、オーダーメイドの製品を提供する「職人」の仕事である。職人は定められたルールに従い要求仕様を満たしたものを作るのが本来の仕事であるため、そこに付加価値が生まれにくい。また、顧客は動いているシステムそのものしか評価しないため、品質や性能・拡張性・汎用性の部分まで評価できるわけではない。

 

 さらに、品質による差別化は、価格による差別化に比べてはるかに難しい。商品の品質については、「あたりまえ品質」と「魅力品質」という概念がある。

 

あたりまえ品質…その商品が当然満たすべき品質
魅力品質…その商品がほかの商品に対して優位性を持つための品質

 

 ソフトウェアの中でも、ゲームソフトは典型的に「魅力品質」の戦いである。Webで不特定多数や会員に提供するソフトやパッケージ製品は、「あたりまえ品質」を満たすことを前提としたうえで、評価は「魅力品質」に負うところが大きい。

 

 ところが、一般のアプリケーションは大きく異なる。社内ユーザが相手であるため、よほど斬新なシステムでない限り、「魅力品質」と呼ばれる性質に乏しい。バージョンアップなどで意識的に目玉になる機能を前面に押し出し「魅力品質」に見せることは少なくないが、実質的には「あたりまえ品質」を満たしているにすぎない。

 

 つまり、アプリケーション・エンジニアにとっては、「あたりまえ品質」を満たすことが仕事の大部分である。そうすると「うまくできてあたりまえ、ダメならぼろくそ」というのが通常の評価基準となる。

 

 野球を例に取ると、ゲーム開発・Web開発・パッケージ開発などは、バッターに例えることができる。「魅力品質」を満載したホームランを打つことが期待されて、たとえ3打席凡退しても、最終打席のチャンスにホームランを打つことができればヒーローとして扱われる。

 

 しかし、アプリケーション開発の世界は内野手である。平々凡々なゴロを淡々と「あたりまえ」にさばいていくのが仕事である。90%はアウトにしても、残り10%をエラーしたら、球場で罵声を浴びまくることになるだろう。激しい投手戦を繰り広げている試合では、絶対取れそうもないヒット性のあたりでも「取れなかった」というブーイングを浴びることがあるような世界である。

 

 言い換えると、アプリケーション開発の評価は、スタートがゼロであり、マイナスが積み重なっていく減点法である。そのような呼吸がわかっている発注者は、評価がゼロやマイナス1〜2といった技術者を「守りの堅い内野手」として重用するのだ。

 

 さらに言うなら、ほかの開発者もノーエラーだとすると差別化を行うことは難しい。あからさまに言うならば、「いかにプラスを生み出せるか」ではなく「いかにマイナスを生じさせないか」が評価の基準になるのだ。

 

 このように、あたりまえ品質を要求され、その上でさらなる価格低下を求められている。さらなる価格競争の中で下請け開発会社の疲弊は続いていくだろう。

 

運命からの脱却

 

 このような状況の中で市場競争をしてほかとの差別化を行うには、新たな評価軸が必要になるだろう。新たな評価軸には、以下の2つの観点が最小限必要となる。

 

  • ユーザ企業が納得できること
  • 測定が可能であること

 

 例えば、時折、一部の技術者が「成果を人月工数で測るのはおかしい」という論調を持ち出す。しかし、残念ながら、おかしいという理由に計測可能な根拠がない。人月工数以外の代替策として「投資対効果論」を唱える者がいるが、この計測は非常に難しく、一歩間違えると技術者にとっては人月工数で評価されたほうがマシな結果になる場合も少なくないだろう。根本的な話として、代替案をユーザ企業が納得することがなければ、その条件で発注されることもない。*3

 

 このように、現時点において、新たな評価軸を作り出すのは、禅問答を繰り返すに等しく実現性が低い。そのため、この場では普遍的な評価軸をさらに強化していくことを提案するにとどめる。

 

 過去から現在において、普遍的かつ前向きな評価軸がただひとつ存在するとすれば、「とにかく、ユーザがまともに利用可能なものを仕上げられる」という底力である。特に、ソフトウェア開発職人のレベルダウンが激しいと言われる昨今では、この底力は十分な競争力となる。システム開発企業のみならず、ユーザ企業でも、あえて客観的に発注先の底力を評価するようにしていくことが、自社の損失を抑えてシステムを安定稼働させていく鍵となる。システム開発企業に必要なことは、モラルが高く腕のよい職人を育てていくことにほかならない。仕事を任せて安心できる職人にこそ、仕事を任せるべきであろう。

 

 組織的な底力を評価するには、プロジェクトの各段階における客観的な評価・分析・改善計画が必要だ。現状のほとんどのプロジェクトのように、終了したプロジェクトを無反省のまま終わらせてはいけない。統計好きの米国と異なり、失敗をつまびらかにしない日本では、成功・失敗を問わず、プロジェクトの計画時・実施時の定量的データの採取には不熱心で、結果的に感覚的・経験的な物言いが幅を利かせている。その結果、それぞれの論者がそれぞれの狭い経験にのっとった主張を繰り返し、平行線のまま議論がかみ合わないという現象が繰り返されている。

 

 さらには、開発段階のみならず、運用開始後の障害や、保守対応のコストを評価することも、開発プロジェクトの結果を測るうえで重要である。まずは、どの工程にどのようなミスがあったために障害が発生したのか、なぜ保守費用が高くついているのか、その原因の特定が必要だ。そして、先々のプロジェクトでは、過去のさまざまな問題に対して組織として改善へ取り組んでいくことこそが、本当の底力を強化するためには必須である。

 

コラム:業界のレベルダウンを検証する

 

 なぜ、システム開発業界はレベルダウンが叫ばれるようになってしまったのか? 人それぞれが、さまざまな観点から、さまざまな原因を挙げることだろう。例えば、以下のようなものがある。

 

  • システム環境の複雑化
  • プロジェクトマネジメントの空洞化
  • ゼネコン体制による役割の固定化
  • 丸投げの常態化
  • 教育体制の貧弱化
  • 開発規模の縮小による低価格化
  • 開発モラルの悪化
  • 技術継承の劣化

 

 原因として考えられることはさまざまで、それぞれの要素が複合して発生しているかもしれない。しかし、考えれば考えるほど、上述した原因とは大きく異なる推測をするに至る。

 

 米国の現状について、2005年9月9日付のjapan.internet.comで興味深い記事を見つけた。システム業界のレベルダウンを推測する前に、この記事の内容をご紹介しよう。日本の現状についての話となると、それぞれが置かれている環境で見方が変わってしまう。日米の違いをふまえたうえで、米国における傾向を見ておくことは大いに参考になると思う。

 

 この記事では、システム開発やそれにまつわる業界の動きに対して「考慮すべき事項」として3つの警告を発している。以下にその記事の要約を記述する。

 

 ひとつ目は、テクノロジー業界の合併である。簡単に言えば、企業買収による業界の再編である。企業の合併により寡占化することで競争が減りつつある。競争が減ることで、消費者にとっては、価格の高騰を招いたり、選択肢が減ったりするような影響が出てくることを懸念している。

 

 2つ目は、学生たちがコンピュータサイエンス、ソフトウェアエンジニアリング、情報システムのマネジメントなど技術系の専攻を断念していることである。この理由として、技術やビジネスプロセスのアウトソーシングが劇的に増え始めたことにより、現在におけるプログラミングの専門知識が生み出す価値が1980年代や1990年代と比較してはるかに低下したことを、学生は専門家より先に気づいていたからだと、この記事の筆者は分析している。さらなる問題として、これらの技術系を専攻志望する学生に対して、教育やトレーニング産業が市場価値に見合うスキルを生む方向に進んでいないことを警告している。

 

 3つ目は、技術革新に必要な投資が起こりにくくなっている事実である。技術系の企業は、現状に手いっぱいで、未来の収益を見込むことができなくなっているため、シード期とスタートアップ期の企業への資金提供のようなハイリスク・ハイリターンな資金投資が削減されている事実を憂えている。

 

 米国の現状として見るべきものは、2つ目の「技術系の専攻を断念している」という部分である。この記事の中でまず象徴的なのは、「学生は専門家より先に気づいていた」という一節である。

 

 専門家や業界の人間と比べて学生は、就職を念頭において、情報システム業界への特別な思い入れもなく客観的に状況を判断できる。常に学生の判断が正しいわけではないが、この場合には、結果的に学生の見通しのほうが、先見性があったといえる。

 

 「何千人もの学生が、コンピュータサイエンス、ソフトウェアエンジニアリング、情報システムのマネジメントなど技術系の専攻を断念」という一節は日米の格差が大きな箇所である。日本では、システム業界へ就職する学生の大半はこうした専攻分野の卒業生ではない。その分だけ、日本のほうが、現象があらわになるまでのタイムラグは短くなる。米国では業界の状況を見て就職するまでに4年間あるが、日本では業界選択が就職時なので、その分業界状況がストレートに反映するからである。

 

 さて、日本のシステム開発業界では公然の秘密としての「多階層の下請け構造」が歴然として存在する。開発現場の実態を知る者なら、多くの開発現場、特に大規模プロジェクトでは、元請けベンダの社員はほとんどが管理業務やごく上流の設計作業しかしておらず、実際のモノ作りを下請けに依存していることを否定できない。

 

 その中で目ざとい学生たちが就職を希望するのは、名の通った大手の元請けベンダである。多くの元請けベンダはシステム開発の子会社を持っている。本当に情報システム開発というジャンルでモノ作りがしたいのならば、そういうシステム子会社を選択するのが筋である。それにもかかわらず、学生の人気企業ランキングの中に(どことは言わないが)丸投げの代名詞のような元請け企業の名前を見ることは珍しくない。

 

 もちろん、学生にとっては長い人生の重要な選択のひとつであるから、本当にモノ作りをしたいかどうか、という点以外にも多くの判断基準があって当然だ。さらに、賃金格差の問題も考えると、元請けベンダに就職し、入社3年目以降は現場監督として顧客対応と下請け管理に徹するというコースの選択を批判するつもりはない。

 

 さて「多階層の下請け構造」は「業界内の公然の秘密」であり、開き直って一般に発表されてはいないから、就職を考えている学生が実態を必ずしも知るわけではない。そのため、業界に入って実情を知り、ほんの数年で辞めていくケースは後を絶たない。

 

 数年前の話になるが、ある超大企業のシステム子会社が、理系の院卒に限定して新卒を採った。親会社に比べると、応募者の出身大学の「銘柄」は若干落ちるものの、就職事情を反映して高い競争率になった。親会社は世間的には技術志向の会社と思われていることもあり、新入社員は多くの期待を持って入社した。しかし、彼らに求められた仕事は外注管理である。数年たった今、そのときの新入社員は誰一人残っていない。会社の実名を明かせないのが残念だが、これは紛れもない実話である。こうした現象は程度の差こそあ
れ珍しくない。

 

 中には、上場クラスの大企業(大手元請けベンダ)の職を捨て、賃金のダウンをものともせずに中堅以下の開発会社に転職し設計者やプログラマとして、管理業務よりも開発実務を選択する者もいる。しかし、絶対数は多くない。うがった見方かもしれないが、下請けプログラマの置かれている立場を目の当たりにするせいか、他業種に転じるほうが多いように思える。

 

 すなわち、

 

「レベルダウンの最大の原因は、良質の人材がこの業界に入ってこなくなったからである」

 

より正確を期すると、

 

  • 元請けの場合、入ってきても下請け管理などに充てられ、実際の設計や製造に携わることは少ない
  • 入ってきても辞めていくケースが少なくない

 

点も原因に付け加えておくほうがいいかもしれない。

 

 システム開発業界は、いわゆるインターネットを利用したコンテンツビジネスと企業買収で成立する「IT産業」とは異なる。一般社会で話題となるシステム業界の話といえば、決まって金融系オンラインシステムの悲惨なトラブル事例と、むやみやたらに繰り返される残業地獄の話題ばかりである。「時代の先端をいくハイテク産業」だったのは遠い昔の幻想である。

 

 IT業界で大金をつかんだ人のほとんどは技術者ではなく、あたりまえの技術を使いながらも、営業力と幸運に恵まれたケースである。人月いくらで買われていく「商品」であるアプリケーション・エンジニアが巨額の報酬を得ることは決してあり得ないのである。

 

 もはや、いまどきの若者にとってSEという仕事は、ほかに何の取りえもない人間がやるようなものに成り下がっている。名誉にも金にも縁のない世界。野心的な者や才能豊かな者が目指す職業ではないのである。

 


*1プログラマ個人を分析した研究によると、もっとも優秀なプログラマは最悪なプログラマに比べ、28倍優れている。(『ソフトウェア開発55の真実と10のウソ』ロバート・L・グラス著、山浦恒央訳、日経BP、ISBN4-8222-8190-6)

*2もちろん、品質管理体制をきちんと行い、低スキルの仕事のチェックをすることでリカバリ可能なはずではあるが、現実の開発現場ではなかなかそうもいかなかった。
*3はるか遠い昔、COBOL全盛時代には、ステップ単価(1行いくら)という契約形態があった。比較的個人差が出にくいCOBOLだからこそ成立した方法ではあったが、それでもコンパクトなプログラムを組んだプログラマよりも、冗長なプログラムを組んだプログラマのほうが売り上げを得るという問題点が生じたり、以前に組んだプログラムソースの再利用についての評価が難しくなったりしたため、すたれていった。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

2.2. 価格破壊+やらされ仕事=低い満足度 ハッピィ・エンジニアリング関連ページ

2.1. 丸投げ文化
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.3. 中間搾取でボロもうけ
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.4. 人手余って人材足らず
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.5. 根性、根性、ド根性
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング