これらの日本人の特性プラス「何かあったらソフトウェアをすぐ修正」という行動によって、日本の組込みソフトウェアは今のところかろうじて高品質を維持していると思う。しかし、これらの状況は、ソフトウェアの規模が小さいことと、日本のソフトウェア技術者が劣悪な環境を我慢(高収入を求めずにオーバーワークに耐えるということ)しているからまだ破綻していないのであって、システムソフトウェアの規模が増大(例えば実行コード行数ベースで30万行を超えるような規模)し、技術者がその過酷な労働に耐えきれなくなってきたときには、組込みソフトウェアの品質と開発効率が著しく低下し始めるはずだ。
もしも、ソフトウェアに関してどうにもならなくなってしまったら、組織はこの状況を打開するためにソフトウェア開発に対して何らかの投資をするしかない。今回は組織がソフトウェア開発(実際にはソフトウェア技術者教育)に投資できるかできないかの境界について考えてみたい。ソフトウェア開発に関して悪循環が始まっているかどうかの指標は、組織がアウトプットしているソフトウェアが結果的に利益を生んでいるかどうかで簡易的に判断できる。どのプロジェクトも利益を出せていないのなら、悪循環のフェーズに入っていると考えられる。利益が出ている商品、製品、プロジェクトと利益がでていない商品、製品、プロジェクトが混在している場合は必ずしも悪循環のフェーズに入っているとは言えない。
何はともあれ、ソフトウェアエンジニアという末端の立場から離れて、自分が経営者になったつもりでこの後の記事を読んでいただきたい。
なお、ソフトウェアは毎日のソフトウェアの活動で構築される。ツールにノウハウを隠蔽することはできるが、ツールを使いこなせるようにするにはトレーニングが必要になるから、結局はソフトウェアエンジニアに対する教育やマネージメント、インフラに対して投資をしなければ、ソフトウェアの品質や開発効率は上がらない。そう考えると、よっぽどの裏技を使わない限り、ソフトウェア開発に対して何らかの投資をしない組織のソフトウェア品質と開発効率は上がらない。
そして、プロジェクトマネージャーより上の立場の者は、まずは、ソフトウェアエンジニアに対する投資を組織からどうやって引き出すかについて考え、それが無理だと分かったとき、もしくは自分自身がエンジニアに投資を進言する立場にない場合は、組織を見限るか、それとも組織に留まって、どれくらい自己投資できるかどうかという方向に考えを切り替えるべきだと思う。
【組織がソフトウェアエンジニアに投資できるかどうかの境界】
1. 儲かっている会社は投資できる
当たり前だが、潤沢に利益を出している会社はソフトウェア技術者教育やツール、インフラ整備、プロセス構築、技術コンサルの導入などに投資できる。人を動かすだけで一見投資が必要ないように見える社内コンサルのような支援部隊を組織するような場合でも、人材を外から引き抜くのにお金がかかったり、現場から人材を外すことで工数の穴埋めをしなければいけなかったりするから投資は必要だ。
儲かっている会社はいろいろな手を打つ選択肢がある。ただ、気をつけなければいけないのは、ソフトウェアに関する投資ははっきりとした効果が見えにくいから、投資が役に立たなかったとしても口先だけで継続的に組織からお金を引き出そうとする人たちもいるということだ。
でも、儲かっている会社はある程度の無駄をしても原資があれば、何かしらの手を打ち続けることはできる。現在のように不況に陥ってしまうと、儲かっていた会社も利益が減ってしまい、ソフトウェア開発に対する投資を絞ってしまう傾向はあるだろう。
2. 儲かっていない組織でも技術者への評価に差を付けることで投資はできる。
利益がそれほどない組織でも、ソフトウェア開発に投資する意志とある程度の金(例えばソフトウェアエンジニア一人に対して年間最低10万円以上)を捻出できれば、新入社員や将来有望な技術者、今後、利益を生むアーキテクチャ(再利用資産を構築できるアーキテクチャ)を設計できるアーキテクトに対して集中的に投資するという方法はある。
アメリカではプログラム言語の書き方を知っている程度のスキルのエントリーレベルのソフトウェアエンジニアの年収は200万円以下だと聞いたことがある。そこから、スキルがアップするにつれて年収が上がっていく。日本も同じようにスキルがゼロに近い新入社員への報酬を減らしたら、優秀な技術者への投資分の数十万円/人くらいは出せるだろう。
しかし、このやり方は日本人にはなじまない。日本では長い間その組織、業務を経験させ、その時間の中で成長させるというところが多い。あえてこれを教育と呼ばないのは、組織的な戦略を持たずに現場に任せきりで、日々の業務をやらせているだけで技術を引き上げようという意志を持っているプロジェクトは多くないと感じているからだ。だから、組織が意識的に取り組む「投資」とOJTという名の実際には何もしていない状態は分けて考えている。
逆に、新入社員こそ組織として投資しやすい対象であるというのが日本の特徴だ。もっと、やってくれと言われることはあっても新入社員ばかり金をかけて不公平だという中堅、ベテランエンジニアはほとんどいない。
ソフトウェアエンジニアの中に年功序列ではなく、スキルの高さによって評価に差をつけて、実際にサラリーに差をつけて、そこから投資の費用を捻出するという方法は、よっぽど組織の上位層に強い意志と決断があって、目指すべきゴールがはっきりしていないとできるものではないと感じる。
なぜなら、日本人の「あたたかい人間関係の中のやさしい一員」という性質は人と人に差を付けるというのをいやがるからだ。自分もあまり好きではない。テストの点数で評価している訳ではないから、何をもって投資対象として選択されたのかについて技術者の中に疑念が生じると「あたたかい人間関係の中のやさしい一員」という性質を活かすことができない。
だから、技術者に格差を付けて集中的に投資する方法は日本の組織ではなじまない。
3. 自分で自分に投資する
組織がソフトウェアエンジニアに投資しない、選択的でも投資できないのなら、自分で自分に投資するしかない。お金をかけようとかけまいと冒頭のような状況でエンジニアに対して投資する気がないのなら悪循環からは決して抜けられない。(誰かがスキルアップするトレーニングを自分に提供してくれる筈だと考えるのは、そうならなかったときにスキルアップできないのは人のせいだと考え自己努力しなくなってしまうから危険だ)
自分自身の投資の仕方については次回の記事に回すとして、もしも、自己投資に成功してスキルアップした時に起きる問題について触れておこう。
何らかの投資の結果、自分のスキルが向上しソフトウェアの開発効率や品質をアップできるようになるとどうなるか。そもそも、組織が投資してくれないので自己投資しているのだから、スキルアップが成功したとしても、組織貢献を明確に示すことができないのなら、組織からの評価を期待することはできない。
自分のお金や時間でスキルアップして、組織貢献を実現できたのに評価されないかもしれないのだ。評価されないどころか、スキルアップして開発効率や品質向上を実現してできた余裕につけ込まれて他人の開発効率や品質の悪いソフトウェアを何とかする仕事を回されてしまう危険性さえある。
これはやりきれない。頑張ってスキルアップした技術者の努力が報われない社会、業界が発展する訳がない。
でも、現実はこんなもんだ。だから、頑張ってスキルアップできた技術者はその組織で報われないことが分かったとき、例えば組織を出てコンサルタントになり、1 の儲かって利益を出せている会社を助ける側に回ることになる。
そうなると、成長した技術者が去ってしまった組織が潤沢な利益を出せていなかった場合は、さらにソフトウェアの開発効率が悪くなり、品質も悪化し、残った技術者が残業することでしか対応できなくなる。
この論理だと、ソフトウェアエンジニアは自己投資でスキルアップしても報われないから、自己投資しないでじっとしていた方がいいのかということになってしまう。
そんな筈はないから、こう考えるしかないと思う。
組織がエンジニアに投資をしないのなら、エンジニアは自己投資してスキルを上げ、スキルアップしたことでソフトウェアの開発効率と品質を高め、顧客満足が高まったことに対して満足を感じるようにする。顧客満足を高めたことで自分のモチベーションを保ち、顧客満足を高めることに貢献したことを組織に示し評価を得、同じことを他の技術者もできるようにするには投資が必要であると説く。
4. ソフトウェア開発やソフトウェアエンジニアに投資しないという選択
組織がソフトウェア開発に投資しない、技術者も自己投資しないとう選択肢はないのか。ないことはない。以下のようなケースが考えられる。
a) 投資せずに技術者に負担を強いる。
b) ソフトウェア部品を外から買い自組織では作らない。(サプライやにaを強いるか、逆にソフトウェア部品の価格をつり上げられるという問題あり)
c) 安い海外の労働力にシフトする。(「あたたかい人間関係の中のやさしい一員」という特性は使えない)
d) ソフトウェアでは勝負せず、真似できないハードウェア技術で勝負する。
以上、組織もエンジニアに投資を行い、エンジニアも自分自身に投資をし、投資の結果、ソフトウェアの開発効率と品質が上がり、顧客満足が高まり、それが自己満足につながって、組織にもその成果を認めエンジニアを評価し、投資の効果を確認するのが一番いい。それができないのならソフトウェアエンジニアは幸せにはなれないように思う。
次回は、お金をできるだけ使わないでソフトウェア技術者に対する投資をする方法について書こうと思う。