日本のIT業界に巣くう大問題
人月での見積もりがエンジニアをダメにする（後編）
馬場史郎（グローバル ナレッジ ネットワーク）
2002/8/9
| 何げなく聞く“マンパワー”という言葉の裏に、ITベンダをむしばむ“人月問題”が横たわる。日本のIT業界に深く根を張ったこの問題が、エンジニアをダメにすると筆者はいう。人月問題とは何か、そしてそれを改善する方法とは？ |
| コンサルタント会社には人月提示がない |
前編 マンパワーという言葉人月問題の意味とは現在のシステム提案の方法人月はSEのモラルを低くするそれでもユーザーに人月提示を行う理由後編 コンサルタント会社には人月提示がない横並び単価ではSEのスキルは上がらない職位は同じでも、スキルは同じではない1つの解決策は社内資格制度人月ベースではない方法の考察人月問題の思い出 |
人月提示と同じように、ユーザーが要求するものがある。それが「体制図」だ。望むシステムができればよいはずだが、ユーザーがこの体制図をベンダに要求するのはなぜだろうか？ 実は、これも提案システムの開発可能性を判断する目安となっているためだ。これもベンダが自信を持って自分たちのやり方をユーザーに説明すれば、納得してもらえるはずだ。要はこの人月の提示も体制図の提示も、極論をいえば「ベンダの力のなさ故の逃げか、これまでの商習慣」でしかない、と筆者は思っている。
筆者のユーザー時代に、こちらが要求もしないのに工程別の工数と金額を見積書にいつも書く企業と書かない企業があった。その当時筆者は、書かない企業のSEの方が技術に対する誇りを持ち、スキルも高かったように感じていた。そんなSEをユーザーは信頼するものだ。そうでないSEに対しては、つい「裏」を取りたくなる。もしかしたら、それが人月提示という形になる一因なのかもしれない。
ところで、ユーザーはコンサルタントを頼むときには人月を要求しない。コンサルタント会社などは、「この仕事はこのレベルの人間で3カ月ぐらい必要です。よってこの金額になります」というように、ユーザーに金額の提案をするわけだが、これで通用する。稟議書にも、「○○社はこの業界の経験も豊富で、当社の目的とする××システムを……。また、費用を同業他社と比較しても……」といったように書いて社内の了解を取る。しかし、SEが同じようにユーザーの抱えている問題点の分析や、要件作りなどの作業を行えば、ユーザーは往々にして人月の提示を要求する。
この違いはどこからくるのだろうか？ この事実を、ベンダもユーザーも考えてみる価値があると思う。筆者は、ユーザー企業の情報システム部が、外注する仕事の内容を考えずに、商習慣的に職種で区別しているとしか思えないが、どうであろうか？
| 横並び単価ではSEのスキルは上がらない |
それでは、ユーザーに人月を提示しなくなれば問題が解決するのかといえば、そう単純な結果にはならないと考えている。現在、ベンダが開発費用を計算する際、企業が抱えているSEの社内単価は、同じ（横並び）企業が多い。筆者は、この点も問題だと思っている。
横並び方式では、SEが技術力や能力の向上を目指す動機付けにならないためだ。そのため、企業のSEの戦力もなかなか強くならない。現在、システム開発費用を見積もるのに当たって、個々のSEのスキルをしっかりと反映している企業は少ない。
企業の中には、「うちはSEの単価をSEの職位で決めているので、きちんとスキルが反映されている」というところもあろう。しかし、それはスキルというよりも、年功序列的な職位、例えば「彼は入社15年たったので、そろそろB職位に昇進させよう。彼女は10年たったから、そろそろ主任に昇進だ」、というようなやり方でしかないことが多い。こうした方法で職位が決まるのであれば、必ずしも職位と技術力との相関関係はないことになる。もちろん、主任SEが複数いても、それらの間で技術の能力が一様というわけでもない。
| 職位が同じでも、スキルは同じではない |
つまり、同じ職位だからといっても必ずしも同じ金額になるわけではない。このような状況では、とてもスキルが単価に反映されているとはいえないだろう。スキルが単価に反映されなければ、「あのSEの価値は月当たり100万円。自分の方がネットワークに強いのに、同じ金額とは何となく納得できない。この会社では、技術力を高めても意味がないのだろうか？」といった感想をSEに持たせたり、力のないSEに対して「もっと技術を磨かねばならない」といったプレッシャーもかからない。
これでは、SEの技術力向上の意欲は起こらない。現在の横並び主義で、日本のSEは本当に力が付くのだろうか？ 自分の価値をどうやって高めるのか、自分の価値をユーザーにできるだけ高く買ってもらう。そうしたことが、スキル向上の動機付けとなるはずだ。少なくとも、社内単価はスキルのあるSEと、スキルのないSEとでは、格差があってもよい。現在のIT業界はサービスビジネスが主流の時代である。その中心にいるのがSEやプログラマだ。彼ら／彼女らの能力次第で会社の将来が左右されるといっても過言ではない。ここで忘れてならないことは、彼ら／彼女らのスキル向上、能力向上の原点は、自己啓発であり、自分から技術を向上させる努力、いわゆる“やる気”だ。やる気、向上心なくしてSEの能力向上はあり得ない。
ITの世界では、ほかの世界よりも早く実力主義、能力主義､年俸制を採用してきた。だからこそ、能力のあるSEが正しく評価されるべき時代なのだ。逆にいえば、SEが正しく評価されないと転職などが起こる時代ともいえる。このように考えると、IT企業はスキルが高いSEをきちんと評価し、SEにやる気を起こさせる仕組みを持つことが不可欠だ。こうすることで、SEはますますスキルが向上するし、その結果、企業も業績が伸びることになるからだ。
この点についても、企業の中にはSEへの公正な評価は、人事評価で行っているから問題ないとするところがある。しかし、人事評価は仕事の総合的な結果であり、SEの直接的なスキル向上意欲の動機付けには不十分だといっておきたい。それよりも自分のスキルがそのSEの社内単価に反映された方が、個々のSEにとっては強い動機付けになるはずだ。能力別に区別化しなければ、SEの動機付けにはならない。
なお、スキルとはXXをよく知っているという知識レベルではなく､プロジェクトができる､設計ができるなど、「○○などができること」を意味する。誤解のないように理解していただきたい。
| 1つの解決策は社内資格制度 |
企業の中には、社内で技術レベルのテストを行い、それに経験値を加味してSEのAさんは○クラス、Bさんは△クラスというような社内資格制度を作り、○クラスのSEは１カ月当たり200万円、△クラスのSEは100万円と、社内単価を決めている先進的な企業もある。この場合、SEの給与と社内資格制度はリンクさせることが前提となる。こうすることで、その資格を取るためにSEは一生懸命努力するようになり、その結果会社の技術力は相当上がると聞く。
前述したように、資格を給与とリンクさせるだけでなく、スタッフとライン専門職との給与格差もなくし、技術屋として飯を食いたい人はライン職でもSEになっていく。例えば、大規模プロジェクトができる資格をもつSEは、部長職や役員などと同じぐらいの給与にし、大規模プロジェクトはライン職兼××プロジェクトマネジメント資格を持つ人が行うようにする。
ここで注意すべき点がある。この資格制度には必ず経験値を取り入れることだ。筆記試験や実機テストだけの評価ではダメだ。それらは、あくまでも知識だけであり、SEの実務で通用するとは限らないからだ。SEの実務には、ユーザー企業の管理者や担当者、仲間、パートナー、営業など、さまざまな人が絡む。また、プロジェクトを経験したと一口にいっても、数人レベルのものから数千人レベルのものまである。ネットワークでもクライアントが数台といったレベルから何万台といったレベルまである。システム復旧の設計でも、24時間稼働のシステムとそうでないシステム、3分で立ち上げる必要のあるシステムと、2、3時間かかってもよいシステムなど、さまざまである。
従って、SEの実力を見るには、どんなプロジェクトで、どんな立場で、どんな仕事をしたのか？ もしくは数百、数千のケースを勉強して擬似体験をしたのか？ こうしたことを抜きに評価の判断はできない。知識とスキルを間違えている人が多いが、企業はSEの知識に給料を払っているのではない、○○ができるというスキルに金を払っているのである。いずれにしても、日本の旧態依然の年功序列的なやり方とSEの世界とでは、矛盾が生じている。ハードの時代とは違い、サービスの時代はSEの能力が生産性を大きく左右する。能力のある人がどんどん伸びるようなやり方を取り入れなければ、企業の技術力は向上しないだろう。
| 人月ベースではない方法の考察 |
ユーザーに人月を提示するか否かにかかわらず、このシステム開発は何人月いくらという人月ベースの見積もり以外のやり方について考察する。理想としては、「今回提案しているシステムは、これだけの価値があります、この価値の何％でならば、弊社はシステムを開発します。ただし、○○機能を加えた場合の金額は***万円で、XX機能を落とせば***万円です」と、堂々とユーザーに提案できれば、社内管理上の工数は必要だが、ユーザーには人月提示という概念はなくなる。事実、ある企業は「人月ベースの見積もりはおかしい、構築したシステムにより顧客が利益を得られたのであれば、その何％かを開発費用としていただくようにしたい」といっている。
これには一理あり、素晴らしいことだと思う。だが、その論理はユーザーが抱えている問題点、例えば「在庫を減らしてコストを下げたい」とか、「顧客層を拡大して営業売り上げを伸ばしたい」など、上流のコンサルテーションから企業にかかわり、その後のシステム開発をも行える場合にいえることだ。現在の日本の多くのベンダやソフトウェア会社は、現実としてコンサルテーションから入ることはあまりない。従って日本のIT業界では、この方法は必ずしも現実的ではない。
別の意見では、ユーザーはベンダかコンサルタントに対して、「このシステムは完成すれば3年間でメリットが3億円あります。……従って、開発費は2億円まで掛けてOKです。そして、このシステムを200X年XX月に稼働させたい。そこで各ベンダは、それに沿った提案をしてほしい。それまでに何人SEを投入しようがすべてベンダの判断で構わない。ただし、社内標準としてハードはA社製、OSはB社をベースに考えてほしい」と、ユーザー主導で提案を要請すべきで、これがユーザーの義務だと主張する人もいる。
要は、現在のように、「『こんなシステムを作りたいから、ベンダさんに開発費を見積もってほしい。その中で最も安くて良いもの（システム）を買う』といった主体性のなさがおかしい。もっと主体性を持ち、予算内でベストのシステムを買うという発想に変えることが必要だ、その方が情報システム部も考えるし、ベンダも知恵を使ってくれる。そうなれば、より良いシステムができるし、採算も明確になると考えられる」というのだ。
この意見は確かに正論で、企業で役立つシステムを作るには、これぐらいの姿勢が日本の情報システム部にもあってほしい。しかし、現実はそれがなかなかできない。それでも、将来はその方向を目指してほしいと、少なくとも筆者はそう思っている。そうした企業であれば、企業の中の情報システム部の地位も変わってくると思う。そして、そうなれば人月問題もなくなるだろう。だが、ベンダ側は自分たちの能力範囲（技術力､期間、コスト）で提案して受注できていたものが、今度は自分たちのできない条件も提案時に要求されることもある。従って、力がないベンダは生き残れなくなる可能性も生まれよう。しかし、ユーザーとベンダともに、お互いの切磋琢磨が生まれ日本の情報化促進のためには、多いに役立つは筆者は思う。以上大きく2つのケースを述べたが、両者とも将来はともかく現実的には難しく当面は人月問題はなくなるまい。
| 人月問題の思い出 |
筆者はこの人月問題には、ある思い出がある。1970年ごろ、あるベンダがSEサービスを有償にした。とあるユーザー企業の課長はその通知を受け、「それは良いことだ。これでわれわれ情報システム部の技術陣が、どのくらいの仕事をしているのかを、社内に分からせることができる、これまで何回いっても理解してもらえなかったが、これで助かる」といわれたことがある。
筆者はこの言葉がいまでも鮮烈な記憶として残っているが、当時のIT業界の競争は激しく、多くのベンダはSEサービスを有償にはせず、逆にマシンを買っていただければ、アプリケーション開発などを行う「SEやプログラマを、何人か付け、常駐させます」などという提案を盛んに行い、「マシン売り＋人間売り」を行ったことがある。そして、SE体制図や人数などをユーザーにセリングポイントとして積極的に提出するようになった。つまり、「このとおり御社には何人付けます。体制はこうです」と売り込んだ。
そして、下請けのソフト会社からSEを1人月いくらかの金額で雇い、ハードウェアとともに顧客に投入した。その段階で、中身ではなく、人数・人月勝負の土壌がつくられ、そこにユーザーに人数や工数を提示する商習慣が生まれたように思える。だが、人数や工数を要求する情報システム部もまた、社内ではスキル集団とは見られず、頭数で見られるようになった。
いずれにしても、この人月問題はベンダとユーザーともに悩ましい問題であることは否定できない。これまでいろいろと述べたが、日本の産業は情報化できないと伸びないといわれて十数年たつが、メーカーやソフト会社、顧客が一致団結してSEのスキル向上を図り、マンパワーを切り売りする世界から脱却する努力をしないと日本の将来はないと思う。この原稿が、日本の情報化にとって、「SEの人月扱いはこれでよいのか？」を考える何らかのきっかけになれば幸いである。
| 筆者プロフィール |
| 馬場 史郎（ばば しろう） ●日本アイ・ビー・エムでSE、SEマネージャとして活躍。その後、金融機関営業統括本部などで統括SE部長などを歴任。1993年に萬有製薬へ入社して情報システム部で活躍後、1999年に大手IT教育ベンダのグローバル ナレッジ ネットワークへ入社した。現在は同社副社長。著書に『SEを極める50の鉄則』（日経BP社）などがある。 |
 |
2/2
|
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
