情報サービス産業の今を俯瞰する(その5)

情報サービス産業の今を俯瞰する(その5)

しばらくはこのテーマでシリーズものをエントリをします。
また少しシリーズものをエントリします。

内容としては、情報サービス産業の現状を理解し、また中小派遣型受託開発ソフトハウスの課題や解決策を探るべく、ちょろちょろと以前に書いていたメルマガがベースになっています。

特定の企業だけでなく多くの中小派遣型受託開発ソフトハウスに当てはまる内容かと思っています。
ぜひご批評を頂ければと。
それではどうぞ。

現状の情報サービス産業についての情報展開のVol.5です。

自分たちの置かれている産業の実態、変わりつつある時流を感じてもらえればと思います。

●問題を我々の課題へ(その2)

1.前回までの振り返り

前回までは、多重下請構造と、業界慣行によって起きる問題を1つ1つ掘り下げ、対策の方向性を考えてきました。
 
今回も残りの問題について同じように考えていきましょう。

2.問題のリスト

これまでに我々が認識した問題のリストです。
 

NO 問題の内容 原因 分類
下流工程担当による価格競争の激化 下請 財務面
リスクが高く成長の天井のあるビジネスモデル 業界慣行
生産性向上が売上増加に直結しない 業界慣行
人材育成・スキル向上の取組みの遅れ 下請、業界慣行 人材面
優秀な人材を誘因する魅力ある職場ではない 下請、業界慣行
組織としての自律性・独立性の不足 下請、業界慣行 組織面

 今回は、(2)と(3)の問題について見ていきましょう。
 
 
 
 
 

3.問題の掘り下げと、経営課題の抽出

 

(2)リスクが高く成長の天井のあるビジネスモデル

(3)生産性向上が売上増加に直結しない

 
●問題の原因を探る

(2)と(3)は、ほとんど同じ原因によって引き起こされている問題です。「人月単価での発注」「技術者を常駐させる」という2つの業界慣行によって、「1人=1プロジェクト」の縛りが発生します。その結果、スキル向上などの生産性向上が売上高の増加に直結しない仕組みになっていました。
 
「1人=1プロジェクト」の縛りがあるために、売上高を増加させるには、技術者の新規雇用(確保)が必要になります。売上高を増加させるために、人件費も増加させなければならず、その結果として、低い利益率(ローリターン)を受入れざるを得ませんでした。
  
それでも、仕事があるうちはどんどん雇用しても問題ないのですが、一旦仕事がなくなり、縮小局面に突入すると、固定費型組織のハイリスクの側面が顔を出します。損益分岐点を下回ると、大幅な損失が発生し、一気に財務面が悪化します。
 
この結果、ハイリスク・ローリターンのビジネスモデルになってしまっていました。
 
 

以上までの振り返りでも自明だと思いますが、すべては、
 
  「生産性向上が売上の増加につながらない」 

ということが根本的な原因です。
 

 
●生産性向上が売上増加につながる仕組み

業界慣行は「生産性向上が売上の増加につながらない」という状況を誘発するための1つの契機でしかないことがわかります。業界慣行以外の要因によって生産性向上が売上の増加につながらない事象が発生しても、これらの問題が発生するからです。
 
 
こうして考えてみると、業界構造が悪いだの業界慣行がおかしいだの言ってみたところで、実際は「生産性向上が売上の増加につながらない」という、比較的組織の内部要因と思える事象が、物事の根本原因になっていることに気付けるかと思います。
 
業界構造や業界慣行などといった「わかりやすい敵」をスケープゴートにして責任を擦り付けていても何も解決しません。
 
そこで思考停止にならずに、物事の根本原因を考えてみれば、何かしら打つ手は見えてくるように思います。
 
 
 
 
我々の本職は技術屋です。技術力の向上や、資格取得など、たゆまぬ努力が求められますが、その努力が売上の増加に直結するという仕組みこそ、本来の組織のあるべき姿だと思いませんか?
 
 
ただし、そのような仕組みにするためには、組織の構造やビジネスのやり方を、少し工夫する必要がありそうです。
 
 
 
例えば、「1人=1プロジェクト」の縛りが原因なのですから、「1人で複数プロジェクトを掛け持ちする」というのが、単純な解決案になります。
 
ただし、1人で2つのプロジェクトを丸々抱えるのはしんどいので、2つ目以降のプロジェクトは、他のメンバと共同で分担するといった工夫もできそうです。
 
そのためには、分業できる体制作りも必要ですし、複数人でプロジェクト情報を共有する仕組みも必要です。効率的なプロジェクト運営が求められて来ますから、プロジェクト管理の方法や、設計ノウハウなどを共有するためのナレッジマネジメントも必要になるでしょう。
 
 
 
いろいろやることが増えて大変かもしれませんが、ただしこうした取組みを行うことが、本来の組織の姿なのではないでしょうか?
 
 
他の産業を見れば、製造業などたゆまぬ生産性の向上・効率化を追求し、我々の仕事よりも高度なマネジメントを導入しています。それは、生産性向上をしないと生き残れないからです。世界中に競合が存在するので、それだけの努力をしないといけないのです。
 
 
 
我々受託ソフトウェア業は、ほとんど国内市場に特化し、かつ多重下請構造に安寧することで、努力することを忘れてしまったのかもしれません。
 
技術力の向上や生産性の向上が、ダイレクトに売上増加につながる仕組みができれば、誰も「資格を取得しろ」などと口をすっぱくして言わなくても、自然と技術力の向上が重要であることに気付き、自ら勉強をするようになると思います。
 
なぜならば、技術力向上 ⇒ 生産性向上 ⇒ 売上増加 ⇒ 給料増加 の図式がスマートに描けるからです。努力がそのままダイレクトに報酬として跳ね返ってくるならば、誰しもが率先して努力するはずです。
 
 
ここまで綺麗な図式が描けないかもしれませんが、少なからず本職である技術の向上を、一時たりとも忘れない組織になると思います。そして技術者間での協力・競争が自然に促されます。その組織文化こそが、他社がマネできない競争優位(強み)になるのではないかと思います。
 
 
 
 
●労働集約から知識集約への転換 

生産性向上が売上増加につながるためには、具体的にはどのようなことを検討すればよいでしょうか。
 
 
これは一言で表現すると、「労働集約から知識集約への転換」がキーワードです。
 
 
 
労働集約とは、人そのものが担う仕事の分量が多いことを示します。手作業など、人が介入する割合が多く、人の頭数が必要とされる仕事です。頭数がいないと仕事が進まないので、頭数を確保し、大量に投入します。
 
仕事の対価(売上高)に占める人件費の割合が多いという特徴があります。今の我々は「1人=1プロジェクト」の縛りによって、とっても労働集約的な仕事をしています。
 
 

これに対して知識集約とは、人が仕事をするのではなく、人の知恵やノウハウ、技術などを活用することで仕事を効率的に行うことです。例えば、装置のログ解析を手作業で行っていたのを、ノウハウを集約して解析ツールを作成し、ツールが仕事を行うようになれば、生産性は向上します。こうした、ノウハウや知識を共有し活用することで生産性を向上させることを知識集約と呼びます。
 
設計スキルの高い人がノウハウをドキュメント化し、それを他人が活用することで、品質の高い成果を生み出せたとしたら、それも知識集約です。人が直接に絡んでおらず、ノウハウや知識を他に転用することで生産性を向上させたからです。
 
 
つまり、1人1人の持っている知識やノウハウを標準化するなりして集約し、そのノウハウを活用することで生産性を向上するような仕事の仕方を目指すことが解決策の1つです。
 
 
 
もっと具体的に言えば、ソフトウェアプロダクトは、それ1つで知識集約を実現できています。本来は人が行わなければならなかった仕事を、そのソフトウェアが代わりに実行することで生産性を飛躍的に向上させることができています。ソフトウェアは知識やノウハウの集まりなので、ソフトウェア自体が知識集約の産物です。なので、現在行っている業務に役立つソフトウェアプロダクトを開発することも、知識集約を実現することに含まれます。
 
知識集約の特徴は、一度生み出された成果物は、いつまでも成果を生み出すことに貢献するという点です。
 
マニュアルや設計標準、ソフトウェアはすべてその特徴を備えています。
 
 
知識やノウハウを属人化してしまうと、必ず「労働集約」的な組織になってしまうのです。一人ひとりの持っている知識やノウハウを吐き出して「知識集約」を行うことが、生産性向上のためには必須なのです。
 
 
 
 
●知識集約を活かすための取組み
 
「知識集約」をするだけで、生産性向上が売上増加につながるかといえば、実はそれだけでは片手落ちです。
 
 
より明確に対価を頂戴するためには、顧客との契約のスタイルや、仕事の対価の支払い形態をきちんと交渉しなければなりません。
 
 
つまるところ、「人月単価」のような、人の労働時間に対して定額の対価を割当てた契約をしてしまったら、生産性向上が売上増加につながらない「労働集約」的な仕事になってしまいます。
 
つまり、自分の時間を切り売りするのは労働集約型であり、何らかの成果物やパフォーマンスに応じた対価を頂戴するのが、知識集約型ということになります。
 
 
 
具体的に考えてみましょう。
 
仕事の対価の支払い形態は、おおよそ以下があります。
 
 

・定額契約

システムの成果物に応じた対価を一括で契約する。

・単価契約

特定の期間や時間に応じた単価を設定し、単価×時間によって報酬を決定する契約。

・実費償還契約

仕事にかかった実費に、利益率を上乗せした額を請求する契約。

・インセンティブ・フィー契約

上記3つの契約にオプションで設定できる。ある一定のパフォーマンスを達成できたら、追加報酬を得られる契約。品質や納期において、一定のパフォーマンスに達した場合などの条件を設定することが多い。

 
 
 
どれが「労働集約型」の契約形態だと思いますか?
 
 
単価契約、実費償還契約が労働集約型の典型的な契約形態です。自分の時間を切り売りして対価を得るという方法なので、時間を拘束されます。

この点が労働集約的であり、生産性を高めるには、提供できる時間を増やす、つまり頭数を増やすことが必要になります。これでは労働集約型の仕事になってしまいすね。
 
 
定額契約は、成果物の量や難易度、顧客へのインパクトに応じた金額をその都度見積ります。成果物とは、ソフトウェアプロダクトも含まれます。なので、一度作成したソフトウェアは費用ゼロで販売できますので利益が増加しますし、開発案件であっても、自社内で蓄積したノウハウを活用することで、対価よりも少ない費用で開発できれば、それだけ利益が増加します。
 
つまり創意工夫が売上高(利益)に直結する契約形態なのです。これを目指すのが1つです。
 
 
もう1つがインセンティブ・フィー契約です。これは成果物ベースの契約ではなく、パフォーマンスベースの契約です。特定のパフォーマンスを達成できたら、その分追加で報酬を得る契約です。なので、人月単価で受注しても、なんらかのパフォーマンスベースの契約を付加できるならば、それは「知識集約」の仕事の仕方になります。
 
 
 
このように、対顧客との交渉も必要になるところがポイントであり、また難しいところでもあります。
 
支払い形態は、請負・委任・派遣の業務契約とは独立に存在しますから、請負契約だからといっても、支払い形態が「人月単価」だったら、それは労働集約的な仕事のままであり、何も改善しませんので注意が必要です。
 
ただし委任契約なのに一括の定額契約はやりにくいと思いますから、請負契約を目指せればそれが一番です。
 
ちなみにお気づきかとは思いますが、一括の定額契約やパフォーマンス・ベースの契約は、受託側のスキルが高くないと採用できません。成果物に責任を持ったり、進捗やコスト面でのパフォーマンスを達成するには、受託側に高度なスキルやマネジメントが要求されます。
 
結局は、受託側がいかに自律した組織運営ができ、技術力を組織として蓄積できているかどうか、という点が、採用できる契約形態の幅に直結します。何のスキルや能力もないのに、パフォーマンス・ベースの契約や、一括定額の契約をしてくれる顧客はいないです。
 
 
 
 
●導き出した経営課題
 
以上までの議論の結果、(2)(3)の問題を、自社の経営課題としてとらえると、
 

・労働集約から知識集約への転換

  ⇒時間の切り売りをするのではなく、成果物やパフォーマンスベース
   での対価をもらえるようにする。また、生産性向上が売上増加につ
   ながる仕組みを構築する。

 

といったことになります。これが対策の方向性です。
 
 
 
これまでに見てきたように、知識集約型への転換のためには、組織内部と外部の2つの視点から考える必要がありました。
 
 
組織内部の視点としては、各メンバが保有するスキルやノウハウを集約して再利用可能なものを生み出すことと、仕事を高度に分業するための仕組みを構築することなどが必要になります。つまりは、生産性向上が売上増加に直結する仕組みを構築するということです。
 
組織外部の視点としては、顧客との報酬の支払い形態を見直すために、交渉を行うということです。ただし、何の根拠もないのに契約を見直すことも難しいので、やはり見直しをすることの根拠となる、組織の強みなどを、しっかり構築することがまずは先決なのかと思います。
 
 
 
 
 

●次回予告

次回も、残りの問題について1つ1つ掘り下げていき、原因と対策の方向性を考えていきたいと思います。

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

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です