量産メモ帳

忘れっぽいのでメモを残しています。浅く適当に書きます。

日本のプログラマーの職場環境に関する考察。

スポンサーリンク

二ヶ月前の記事だけど、じっくり読んでいなかったので、読み直してみた。

元の記事を書いたと思われる Jawaad さんは、日本のIT企業またはプログラマーの生産性が悪い原因は、良いフレームワークとライブラリを知らないことにある、と主張している。
それに対して、様々な興味深いコメントが続いているので、自分の経験・意見も混ぜて適当に整理してみる。

  • 上司がフレームワークやライブラリを理解できない。…結果、それらが採用されない。できる技術者はこれでヤル気をなくすと思う。
  • 国産至上主義。…というよりも、オープンソースを採用せずに車輪の再発明をしようとする。一般的に、その方がコストは遥かに高くなると思うんだが。。
  • 実績優先。…早くリリースしたいがために、別プロジェクトで開発・保守・運用の実績があるものしか採用しない。リスク回避としては一見正しそうに見える。しかし、システムの前提条件(例:データ量)なんてプロジェクト毎に異なる方が当たり前なので、結局、大規模なカスタマイズが必要になったりして、やっぱりフレームワークのレベルから改善すべきだったと後悔する羽目になる?
  • 顧客が新しいシステムの導入に消極的。…システムの利用者が、システムの使い勝手が余程悪くない限り、利用方法の変化を嫌がる、という話はよく聞く。
  • コスト勘定と評価尺度が曖昧。…真の成果物というのは、システムそのもの、即ちソフトウェアだったりハードウェアだったりするはずで、それらのリリースに向けて最短距離で走らなければならない。けれども、自動化できそうな作業を毎回手作業でカバーしたり、開発工程の中に妙な開発プロセスを導入して無駄にドキュメントを書かされたりして、コストをかける割には効果が薄そうに見える。評価尺度に関しては、例えば、工数の見積もりが最終的にはプログラマー任せになっていて、しかもその工数がマネジメントの予想(直感)を大幅に超えると、工数を減らすように圧力をかけられる。そして、その見積工数と実際にかかった工数が食乖離してしまうと、評価が上がることはまずない。
  • 新規開発と追加開発・保守。…大抵、新規開発の方が追加開発や保守よりも予算が多いし、何よりもリリースの前と後という違いがあり、運用の悪化を招くような追加開発や保守は避けるのは当然のことと思われる。しかし、拡張性が低いシステムだと、修正するのに予想以上のコストがかかったりする。
  • ピーターの法則。解決策は階級と職制を分離すること。教育やライブラリ/フレームワークなど再生産部分にこそ優秀な者を当てなければならない。…優れたフレームワークを作り上げることができる優秀な技術者の評価や異動には十分気を付けなければならないと思う。例えば、そういった技術者を評価して昇進のつもりで管理側に回らせたら、人間をマネジメントすることに苦労しているという話を時々耳にする。また、ポジション毎の相場の上限に縛られて、技術者への報酬を上げずにいると、彼らに逃げられてしまうという事態に陥る。一方、そういった優秀な技術者が去ってしまった開発チームの技術力は当然下がるので、お互いに不幸になる。



ザッと読んでみた結果、ひとまずの結論として、日本のプログラマーが良いフレームワーク/ライブラリを知らないのではなく、日本のIT企業が優秀な技術者を適材適所に配置したり評価することができていないのが問題であるように思えてきた。


関連資料: