今、日本で起こっていること(5)

(22)ソフトウェアの一般化

 

(ソフトウェア開発では、一般化を図る必要があります)

 

夢のソフトウェアが生産性が高いということは、高い一般性を持っていると考えます。そこで、ソフトウェア開発における一般化とは何かを考えます。

 

1)横の一般化

 

横とは、分野の違いを指します。

 

Aという分野用に作ったソフトウェアは、Bという分野でも使えれば、一般化ができ、開発コストが下がります。

 

一般に、Aという分野用に作ったソフトウェアが、そのままBという分野でも使えることはなく、モジュールを共通部分と分野依存部分に分解する必要があります。あるいは、オブジェクト指向であれば、継承を使うことになります。

 

ソフトウェアの開発には、これ以上深入りしませんが、横の一般化で重要なことは、横の一般化は分野の破壊を前提することです。

 

日本では、分野ごとの専門家が独立して存在するという人文的文化が主流です。例えば、生態学では、特定種の専門家がいます。歴史学では、ルネッサンスのイタリアのようにある地域のある時代の専門家がいます。

 

歴史学の現状は分りませんが、現代の生態学は、エネルギー収支を微分方程式でとき、生物多様性クラウドであつめたビッグデータで分析し、環境政策を自然資本の経済学で解析しています。つまり、生態学では、旧来の分野は破壊されています。

 

現代の生態学はDXのかたまりと解釈できます。

 

日本のように、特定種の専門家の意見を入れて、レッドデータブックを中心に種ごとの縦割り生態学を推進している国はなくなりつつあります。

 

日本では、産業界のDXの遅れが指摘されていましが、科学的文化に基づかず、人文的文化と経験科学に基づく学問分野のDXの遅れは、より深刻になっています。

 

2020年6月の科学技術基本法に「人文科学のみに係る科学技術」が追加されたことは、DXを否定になりますので、問題点を端的に示しています。

 

2)縦の一般化

 

ソフトウェアは、時間をかけて開発されます。その特徴は、次になります。

 

(1)バージョンアップ

 

機能を追加し、処理効率を上げます。セキュリィティ対策を向上します。

 

(2)システム化ツール

 

ソフトウェアを効率的に開発するソフトウェアを開発します。

 

この機能の一部は、ソフトウェア言語の進歩によってもたらされています。

 

オブジェクト指向関数プログラミングが、2本の柱になっています。

 

ソフトウェアによって作られるエディタ、デバッガも進歩を支えています。

 

これはソフトウェアに自己増殖性があることを意味します。

 

ゲームソフトの開発企業が、ゲームソフト開発のためのプラットフォームを同時に作っていれば、自己増殖性の点で、デジタル企業と言えるでしょう。

 

複数のA,B,Cのゲームで使われる共通モジュールを開発して利用する手法が横の一般化です。ゲームソフト開発のためのプラットフォームを開発するのは縦の一般化です。交換できれば、縦の一般化は、横の一般化が極度に進んだ状態であると見ることもできます。




3)高さの一般化

 

ソフトウェアは人間のグループが作ります。

1人の生産性も重要ですが、グループの生産性も重要です。

グループの生産性を上げるためには、クラウドツールの活用が欠かせません。

 

この文章は、Googleドキュメントで書いていますが、Googleドキュメントのようなクラウドに対応したツールを使えば、生産性を劇的に上げることができます。

 

紙の雑誌の印刷では、編集者がゲラ刷りに赤を入れたものを、著者に郵送して、修正点をチェックしていました。それには、数日かかりました。

 

グラウド上のエディタを使えば、こうした編集は瞬時に終わります。

 

紙の雑誌を、WEBに切り替えれば、印刷費が要らなくなるだけではなく、速報性が上がります。

 

ウィキペディアであれば、選挙の次の日には、選挙結果が書き込まれています。

 

紙の百科事典で対応するには、数年を要していました。

 

紙の雑誌が廃刊になっていますが、速報性、双方向性に利便性がなく、コストが嵩みますから、廃刊になるのは当然と思われます。

 

一方では、電子教科書には、速報性、双方向性がなく、電子化のメリットが全くない不思議な状態になっています。

 

ソフトウェア作成における高さの定義はありませんので、ここでは、第3の一般化と呼んでもかまいません。

 

4)まとめ

 

他にも、見落とした一般化の切り口があるかもしれません。

 

いずれにしても、ソフトウェアは、開発の方法、開発後の利用、システムとしての自己増殖性によって、高い生産性を実現できます。

 

(23)高度人材の給与

 

(高度人材の適性な給与の決まり方を考察します)

 

1)給与の評価

 

高度人材の給与は、生産性に比例します。

 

つまり、生産性を計測することなしに、給与はきまりません。

 

1990年頃、発展途上国ラオスに初めてテレビ局が設置されて、テレビスターが誕生します。ラオス社会主義国です。テレビスターの給与が、首相の給与より高くなって、引き下げられたそうです。当時この話をきいて、発展途上国だからやむを得ないといった人がいます。

 

しかし、現在の日本も、給与がポストで決まる同じような状態にあります。

 

一方、野球やサッカーチームで一番上のポストは監督です。しかし、監督より給与の高い選手はいくらでもいます。それは、スター選手がいれば、観客動員数が違うからです。スター選手になると年俸が非常に高くなります。そこで、スカウトマンが全国を走り回って有望な新人の発掘をしています。新人はスターになるかもしれませんが、その場合の給与には、割安感があります。

 

ポストで給与が決まることに違和感を感じない人は、人文的文化の持ち主です。



科学的文化の人は、生産性を反映しない給与には違和感があるはずです。

 

よく講演会の講師の略歴に、政府の専門員会の委員の経験者であると書かれていることがあります。

 

生産性(出来高)で考えれば、日本経済は過去30年伸びていませんので、政府の専門員会のうち生産性の向上に寄与した委員会と生産性の向上の失敗した委員会を比べれば後者の方が多いはずです。

 

野球の監督の経歴で、優勝チームの監督には、価値がありますが、どん尻チームの監督の経歴には価値がありません。

 

同様に考えれば、成果を上がられなかったの専門員会の委員の経歴は書かないで欲しいというが普通です。そうならないので、成果(エビデンス)を問わない人文的文化に洗脳されているからです。

 

2)生産性の差

 

ソフトウェアエンジニアの生産性調査では、1980年代に、IBMが行った調査レポートが広くしられています。その調査では、優秀なプログラマーと初心者のような成績の悪いプログラマーの生産性の差は26倍ありました。

 

これから、生産性に比例して考えれば、10倍程度の給与差はあって当然と思われます。

 

この調査は、全てのプログラマーが解ける課題を対象にしています。

 

数学の難問のように、誰でも解けるわけではない課題に対しては、課題を解けるプログラマーと課題を解けないプログラマーの生産性の比は無限大になってしまいます。

 

ともかく、課題を解けるプログラマーがいないと、先に進めないのです。

 

2023年1月27日のDianmondに、野口悠紀雄氏が、Levels.fyiのアップル、グーグル、メタ、マイクロソフトのソフトウェアのエンジニアの給与について記事を書いています。

 

表1は、この4社をBigtechとして、それ以外のアメリカのサンフランシスコ、英国、日本のソフトウェアエンジニアの給与を1ドル130円として万円単位で整理しています。

 

—-------------------

 

表1 2023年1月のソフトウェアエンジニアの給与

 

区分

最高

エントリー

Bigtech

15639

2197

San Francisco Bay Area

3900

2379

UK

1733

718

JPN

1043

645

—-----------------------



表1から、日本が圧倒的に安いことがわかります。

 

Bigtechの給与は、最高レベルのソフトウェアエンジニアでは、サンフランシスコエリア平均より高いですが、エントリーではさがありません。

 

アメリカのエントリーレベルの給与は、英国と日本の3倍くらいありますが、生活費が非常に高いので、可処分所得の差は、給与の差に比べれば小さいと思われます。

 

筆者は、高度人材の獲得に必要な条件は以下と考えます。

 

(1)高度人材に高い給与を提示できる利益率の高いデジタル社会型企業であること。

(2)高度人材に求めるジョブ(難しいが解ければ、競合企業に対して優位に立てる課題)を設定できること

 

この課題をクリアできる日本企業は少ないと思います。

 

給与がLevels.fyi、Glassdoor、Blindなどのサイトに掲載されていようになったのは、最近です。このデータは企業の公式データではないので、精度には問題があります。しかし、従業員はこれらのサイトに殺到し、同僚や他社で働く同様の職種の人たちと自分の報酬を比較して、条件が悪い場合には、転職を考えるか、給与の値上げ交渉をするようです。

 

10-3)アートの課題

 

ソフトウェアエンジニアの仕事は極度に演繹的です。

 

筆者は、コンピュータが出て来る前にあった職業で、ソフトウェアエンジニアにもっとも近い職種は、作曲家だと思います。

 

つまり、帰納的に考えるのではなく、演繹的に、プログラムをコーディングする作業は、音楽理論に基づいて作曲する作業に共通しています。

 

そこには、STEAM教育を行うべき理由があります。

 

作曲家の生産性を調査した研究はないと思いますが、日本作曲家の芥川也寸志は、モーツアルトの最後の3つの交響曲について、自分が楽譜を書き写す速度より、モーツアルトが作曲する速度の方が速いといっています。




引用文献

GAFA大量人員削減でも高度人材は「年収2億円超」、熾烈な獲得競争に日本は勝てるのか2023/01/27 Dianmond  野口悠紀雄

 

levels.fyi

https://www.levels.fyi/t/software-engineer/locations/japan

 

Levels.fyi、Glassdoor…給与サイトに利用者殺到。公開データで会社と交渉、報酬30%アップする技術者も 2022/07/30 LIFE INSIDER

https://www.businessinsider.jp/post-254707