Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

日本のソフトウェア産業がいつまでもダメな理由

平成20年初版とちょっと古い書籍ですが、年末年始に古本屋で購入した
「日本のソフトウェア産業がいつまでもダメな理由」に関する書評です。

一定期間以上のシステム開発の経験があるものなら誰でも頷けるような内容がまとめてあります。

■概要

  • ソフトウェア会社の問題点
    • 技術者こそ資産であるはずが技術者の技術力を軽視する
    • 技術力を向上させるキャリアパスを用意する会社が少なく、管理職へのパスが一般的
    • 失敗を次に生かさない。寄せ集めの下請け業者を集め、失敗したら全員解散→ノウハウは蓄積せず
    • お客様の利益になる保守性の高いシステムよりも継続してお金の取れるシステム→技術者のモチベーションダウン
  • エンジニアの問題点
    • 日本のエンジニアの勉強不足
    • 英語アレルギー
  • システム開発業界の問題点
    • 人材斡旋業界
    • 人月計算
  • システムを発注するユーザーの問題点
    • 大手開発ベンダーを重視
    • 既存の業務フローに無理やりシステム側を合わせる
    • システム化の投資の損得勘定が不十分

■感想
明確な解決策の記述などは特にないですが、この書籍のテーマが
ダメな理由を挙げることなので論旨としては間違ってはいない。
自分の仕事に置き換えて問題点と改善案を整理するきっかけにはなりますね。

さて各要素について考えてみます。

  • ソフトウェア会社の問題点

技術力への投資は自分の時間を割いて全て自分で行う必要があると割り切ったほうがいいと思います。
それを踏まえて職場を勉強の場として利用させてもらえるように
提案・実施できるようなスキルと発言力を得ることが出来れば最高だと思います。
現場によっては保守的で予算を使って新しいことをやるのを拒むところもあるとは思いますが。
失敗のノウハウ化も、会社とは別に自分で必ず行うことを意識しています。

システムの保守性の向上を嫌がる現場=あえて保守に手間のかかるシステムを構築して
保守工数で儲けようとする会社などは実際にありますが、
そのあたりは現場が変わるまでの間割り切るしかないですかね。
以前に、ステップ見積もりをしている会社で見積のことは知らずにシステムの共通化を図り
以降の開発に必要なステップ数を1/10にしてしまったら怒られたことがありました。
※ステップ見積もりとはプログラムの行数で見積もりを行うこと。
 つまりメンテナンス性の悪い、冗長なコードほど価値が高いことになるという奇跡の見積法

  • エンジニアの問題点

勉強に関しては異常なくらいやってるので問題なし。
英語アレルギーは直さなければ。
ちょうど最近日本語の技術情報の少ない環境構成での開発を行なって痛い目を見たばかりです。

  • 業界の問題点

多重派遣の件とか人月見積もりの件とか2012年になっても変わっていないわけで。
よくある負のスパイラルが以下。
企業は下請けの開発者を固定単価(残業代、休日出勤手当なし)で雇う。
同じ現場にいる限りめったなことでは昇給は行われない。
この時、怠惰な開発者から見みると技術力を上げても無駄。
残業をすると損。ということから

▼時間内で最低限の作業を終わらせて定時退社。休日は出勤しない
▼早く終わると別の作業を振られるので終わっていないふりをして他人の作業を手伝わない
▼仮に残業や休日出勤があった場合は仮病で休んで帳尻合わせ
▼技術力を上げても無駄なので努力はしない

こういうタイプの技術者さんは将来テスターしかやらせてもらいないような人員になるわけですが。

長期的に技術力を磨くことが自分へのリターンになることが分かっている技術者は
積極的に業務をこなすことになりますが

▼怠惰な技術者がサボった負債を引き継ぐ
▼残業するほど自己投資時間が減ったり、派遣元である自社の利益(残業代分)が減る
▼技術力を上げても評価されないという不満が募る
▼怠惰な技術者への不満が募る
▼負荷がかかりすぎて体調を崩す。最悪潰れてしまう

などということになりがちで、いい技術者ほど潰れるかやめてしまうということになりがち。
ここで、怠惰な技術者を減らしてその分の予算を優秀な技術者に上乗せするような構造になってくれれば
元請けも下請けもハッピーなはずなのですが。現実は難しいですね。

  • ユーザーの問題点

品質の低いソフトにぼったくりされていることに気付ける仕組みが出来れば変わるのだろうか。
例えばソフトウェアの品質を検証する中立的な企業にアーキテクチャーやソースコードの品質を
確認する、とか。
その企業に調査を依頼する費用などを考えると小さい会社には厳しいかもしれませんが。

大手志向に関しても蓋を開ければ、実際に開発しているのは多重請負の下請け会社だったりしますし
その辺の実態を知れば選択肢も変わってくるのかな?
企業政治とかの話になるとちょっとわかりませんけど。

凡人を100人集める一流企業の開発より、天才を5人揃えた小企業のほうがいいソフトを開発すると思うのですが。

  • 総括

1技術者である自分から見た場合のスタンスとしては

    • 仕事は求められた成果を出しつつ、自分の技術力向上の場として自ら提案して業務内容自体を誘導する
    • 業務中は最大の成果を最短の工数で行う。その試み自体が自己投資だし、節約した時間は自己投資の時間になる
    • 本格的な技術力向上は自己投資で行う

このような形ですね。
他人の作業を巻きとりすぎてついつい残業漬けになるのでその辺はもっと強めに意識したい。

日本のソフトウェア産業がいつまでもダメな理由

日本のソフトウェア産業がいつまでもダメな理由