| ▲ このウインドウを閉じる |
| You get what you pay for. |
短納期を実現するなら、従来から継承してきた やりかた を、そのまま、適用していたら、実現できない。もし、同じ作りかたを継承して、短納期を実現するなら、作りかたのなかで、いくつかの手順を省略するしかない。しかし、手順を省略すれば、高品質を実現することはできない。
同じ手続きを継承することを前提にして、生産性向上を狙って、作業員を増すなら、手続きは、「機械的な単純作業」でなければならない--つまり、ルーチン化されていなければならない。しかしながら、データ構造を設計することも、プログラムを作ることも、ルーチン化された単純作業ではない。プログラマを増やして、ひとりが作るプログラム数を減らすとしても、（１つのシステムは、或る目的を実現するために、複数のプログラムから構成されているのだから、） 逆に、それぞれのプログラムが構成する全体像 （システム全体） に関して、共通の理解が成立していなければ、複数のプログラムは、有機的に接続できない。 言い古されてきたことだが、「少数精鋭」という編成が、「高品質・短納期」を実現するためには、いちばんに良いのかもしれない。「少数精鋭」であるためには、それぞれの技術者は、そうとうな技術力の持ち主でなければならない。したがって、かれらに支払う報酬 （fee） は、たぶん、相場に対して、1.5倍あるいは２倍として考えるのが妥当だ、と思う。だとすれば、少なくとも、「少数精鋭」部隊は、２倍の生産性を示さなければならない。もし、それが実現できるのであれば、相場に対して、２倍の報酬を支払うのは妥当である。 しかし、悲しい現実は、「値段の高い」上級の技術者を雇うことを敬遠する傾向がある、という点である。「値段×期間」が支払い代金であるのだから、もし、今の支払いを前提にすれば、「値段の高い」上級技術者を雇っても、（システム作りの期間が半減するなら、） 損にはならない。しかし、現実的に、やっかいな点は、システムに対する投資そのものが「低投資」になっている、という点である。とすれば、相場に対して２倍の値段であっても、（投資そのものが「低投資」になれば、） 上級技術者の報酬も、相対的に、低くなってしまう。 ＳＥ・プログラマの「適正な報酬」が、どのように計算されるのか、という点に関して、いままで、曖昧にされてきたのではないか。計算の前提として、たぶん、以下の３つの方式を考えることができる。
（１） 「コスト志向価格」方式
「コスト志向価格」方式というのは、「人件費＋利益」を起点にして値段を計算する やりかた である。「需要志向価格」方式というのは、需要を考慮して値段を考える やりかた であり、「競争志向価格」方式というのは、競争相手の値段を参考にする やりかた である。現実的には、これらの３つの やりかた を、いっしょに使って調整している、と思われる。 理想的には、システムがもたらす収益の割引現価を計算して、それを作る技術力の値段を導出するのが妥当であるが、そういう計算をしているユーザ企業は、まず、いないのではないか。というのは、「収益の割引現価」を計算するためには、将来の収益を見積もらなければならないが、システムの値段を見積もるための類似物がないし--market-price が成立しないし--、システムがもたらす収益そのものを見積もることができないから。 そのために、現実的には、技術者の「報酬」は、「慣習的な値段」を基礎資料にしているのではないか。そして、「慣習」が基礎資料になるのであれば、上級の技術者に対する「２倍の値段」というのは、法外な値段として、考慮の対象にはならないのかもしれない。 そして、ＳＩ社 （あるいは、ソフトウェアハウス） が大きな組織であれば、請負システム群の全体的採算を考えることができるので--たとえば、プロジェクトが 10 編成されていて、そのなかで、８つのプロジェクトが赤字でも、２つのプロジェクトの黒字を通計して、補填すれば、全体として、「採算がとれる」とか--、企業経営から観れば、「（大）規模の経済性」を優先して、経営の安定性を守るのかもしれない。しかし、逆に言えば、大多数の技術者を派遣できるような大規模なプロジェクトが多くあれば良いが、もし、プロジェクトが小さな規模になれば--したがって、投資が少なければ--、人数が投資に対して均衡しないので--需要に対して、供給が多いので--、技術者の値段は安くなる。需要-供給は、物品の値段であれば、マーケットのなかで、調整されるが、人件費であれば、なかなか、調整しにくい。というのは、（よほどのことがないかぎり、） 社員つまり技術者を layoff することはできないから。あるいは、需要が増えても、すぐに、（技術力のある） 人たちを雇うことができないから。したがって、ＳＩ社 （あるいは、ソフトウェアハウス） は、技術者を、需要-供給が揺らいでも、或る程度の人数を雇っていなければならない。 外見的には、技術者の報酬は、需要-供給のなかで成立しているように思われるが--新しい技術がマーケットに出て、その技術者が少なければ、報酬は高いし、古い技術に対する報酬は安くなるが--、（アウトソーシングする） ユーザ企業では変動費だが、ＳＩ社 （あるいは、ソフトウェアハウス） では、固定費である。しかし、損益分岐点を低くするなら、固定費を変更費化するのが定石である。そのために、ＳＩ社 （および、ソフトウェアハウス） も、人件費の固定費化を避けるために、「子-孫」請けを雇う。そういう雇用形態では、技術者の「給与」は、需要-供給のなかで成立する「値段」とは、べつの mechanism のなかで、「慣習的値段」が成立している。 技術者は技術力が問われる、というのであれば、ＲＦＰ （Request For Proposal） を提示して、入札する企業名を問わないで、入札の際に、技術力を試験する、というのが正しい やりかた ではないか。入札の際に、「値段」が最大の考慮点になっている--いちばんに安い値段を提示すれば落札できる--というのが、悲しい現実である。 小生が住んでいるマンションは、今年、大修繕を迎えた。建設会社が、数社、入札したが、修繕委員会は、（値段のほかに、） いくつもの評価点を用意して、入札企業を採点した。そして、最終的には、ほかに企業に比べて、500万円ほど高い値段を提示していたＳ社が、全体的な評価点として、いちばんに良かったので、落札した。修繕委員会は、コンサルタントを雇った。そのコンサルタントは、すべての入札企業が、かって、修繕したマンションを、多数、訪れて、工事の進めかたや工事のできあがりぐあい や居住者たちの意見などを調べていた。システム作りの入札も、こうあるべきではないか。 しかし、コンピュータ・システムに関しては、入札企業 （ＳＩ社、ソフトウェアハウス） の作ってきたシステムが、ユーザ企業の事業戦略に関与すればするほど、ユーザ企業は、システムの視察を承諾してはくれない。そして、システムとは、（ルーチン化された仕事を自動化するシステムを除けば、） そもそも、そういう性質を帯びている。そのために、入札企業の技術力を、正確に調べることが、むずかしい、というのも現実である。 さて、「高品質・短納期」を「低投資」という前提のなかで進めるなら、かっての「慣習的値段」を、いちど、外して、技術者の「報酬」計算式を再考しなければならないのではないか。
|
| ▼ このウインドウを閉じる |