いさぼうネット
賛助会員一覧
こんにちはゲストさん

登録情報変更(パスワード再発行)

  • rss配信いさぼうネット更新情報はこちら
 シリーズコラム 「よろずIT・ネットワーク情報」 
【第9回】 ソフトウェア開発従事者と残業について
 

(1)電通ショックに関しての報道に対する個人的感想

 一昨年前の年末に電通社員が過労死したいわゆる「電通ショック」以来、日本中で過労死や超過残業、サービス残業の問題がクローズアップされ、それに伴い、大手企業の就労条件見直しや過去に遡っての未払い賃金の支払い等、また厚生労働行政からの残業時間規制等、日本全体の就労環境の変化が現在進行形で現在も報道され続けています。


 私の場合は既に30年以上ソフトウェア開発とネットワークエンジニアの仕事に従事していますが、かけだしの頃はまだバブル崩壊前の日本経済の絶頂期で、とにかく次から次と営業が取ってくる仕事を納期までに納めることが最優先で、残業、徹夜は当たり前、30代前半の最も残業が多かった月は休日残業も含めると160時間/月となり、ちょうど月の給料が倍になった記憶があります。
但し、さすがにその月は給料日直前に社長に呼び出され、「XX君、なんやこの残業時間は?」と問い詰められ、理由の説明に困った記憶もあります。
 また、その当時のソフト開発会社の多くは社内に仮眠室があり、徹夜の仕事に対応できる体制でした。
私自信もその時の習慣が抜けず、今でも社内に登山用の寝袋と床に敷くマットをロッカーに常備しています。
 まあ、この頃の常識では仕事のできる技術者は残業100時間/月なんてのはごく当たり前でした。
また、ろくに仕事もしていないのに、毎日1時間〜2時間程度残業をしていくいわゆる「生活残業」というのも少なからず見かけました。

(2)苦い思い出
 30代後半で既に管理職になっていた時の徹夜残業での苦い思い出があります。
 入社2年目の新入社員と小さなプロジェクトをやっていた時、納期直前に二人で徹夜をして、なんとか納品物を大方仕上げたのですが、既に朝の5時を過ぎていました。
 私もその日に別の客先にも行く予定があったので、長く伸びてしまった髭を剃るとか身支度を整える必要があったので、一旦20Km程離れた自宅まで帰宅しようとしましたが、一緒に徹夜した新人には「君は帰宅すると居眠り運転で交通事故を起こす可能性があるから、帰宅せずそのまま会社で仮眠をとりなさい。」と言って一旦帰宅して会社へ戻ってきました。
 ところが会社へ戻ってみると待機させたはずの新人がいません。 数時間して会社へ連絡がありました。 なんとその新人は一旦帰宅したあと、再度会社へ出社する道中で路線バスと正面衝突する事故を起こしてしまったのです。 幸い身体の怪我はなかったのですが、バス会社からかなり大きい金額の営業補償請求が彼にきたことを覚えています。

(3)バブル崩壊
 だいたいソフトウェア開発というものは、技術革新のスピードが速いので、ボケっとしていると直ぐに自分の技術が通用しなくなる世界です。 その極端な事例がバブル崩壊後に起こった「ダウンサイジング化」の波でした。 自分はもともと文学部の出身だったので、独学で覚えたBASIC(ベーシック)という言語とC言語しか知らず、扱うコンピュータもパソコンがほとんどでした。 その頃は大きな業務システムは、ほとんどが汎用コンピュータかオフコンと呼ばれていたオフィスコンピュータが主流で使用する言語はCOBOL(コボル)という言語が主流でした。 そんな理由で、BASICとパソコンで小規模なシステムしかやったことのない自分は汎用機やオフコンの技術者達に対してかなりコンプレックスを持っていました。
 ところが1990年代の前半から始まったバブル崩壊がこのような状況を一変させました。 今まで飛ぶように売れていた汎用機やオフコンが全く売れなくなり、代わりにコストの安い複数のパソコンをLANに繋ぎ、今まで汎用機やオフコンで行っていた業務をパソコンで行う「ダウンサイジング化」の波が押し寄せてきたのです。 社内でも社長や重役がパソコンシステムしか作ったことのない私に「XX君、今まで汎用機やオフコンしかやったことのない人間にどうやってパソコンのソフト開発をさせたらいいんや?」と相談しに来るようになりました。 文字通り開発現場における立場が脇役から主役に1年足らずで180度転換した瞬間でした。

(4)確立された開発体制と全てが独自開発の違い
 それまでの汎用機やオフコンのソフトウェア開発体制は、メインのシステムエンジニアが基本設計を行い詳細設計をプログラマに渡し、プログラマは機械的にその詳細設計通りにプログラミングするという完全なルーチンワークの基での開発体制でした。
 ところが「ダウンサイジング化」に伴うパソコンネットワーク上での開発体制はそれまでとは全く異なり、個々のプログラマも基本技術、言語習得以外にシステムの概要とサーバクライアントシステムの基本やネットワークの基礎知識をある程度理解しておかないとシステム開発ができず、個人の能力の違いもありますが、それまでのCOBOLプログラマにとっては新たに乗り越えなければならない壁が相当あったと思います。 汎用機やオフコンの開発システムは電算機メーカーの作成した開発ツールやフレームワークが既に確立しており、アプリケーションはそのフレームワークに乗っかり開発するだけでよかったのが、開発言語以外、フレームワークもレポート機能のない環境でごりごりコーディングしなければならない環境など、彼らは体験したこともなかったからです。

(5)確立された開発体制環境下と試行錯誤の開発環境では、工数計算予測手法が全く異なる。
 バブル崩壊前のCOBOL主体の開発体制では、プログラミングの工数予想はプログラムのステップ数が用いられていました。 プログラマの能力は時間当たりのプログラムコーディングのステップ数で評価されていたのです。 ところが「ダウンサイジング化」によりこの工数計算が成り立たなくなってきました。 BASICやC言語によるプログラミングは、COBOLによる開発とは大きく異なり、個々のプログラマの能力により開発工数が3倍以上の差が出てきたからです。 また、成果品の品質そのものにもプログラマの能力により大きな格差がありました。
 このようなソフトウェア開発重要の外部環境が大きく変わり、開発体制そのものが試行錯誤を繰り返す環境下では、開発に要する工数の予測は難しくなっていました。

(6)業務内容別の平均時間で予想工数を割り出す手法
 最近テレビで見たのですが、どこかの企業が「残業ゼロ」を目指して業務別の全社の社員の時間当たりの平均時間を割り出し、それを基に予想工数を計算する手法が紹介されていました。 この手法をソフトウェア開発に適用しようとすれば、ある程度確立された開発体制環境下に限っては適用できるかもしれませんが、新規参入分野のプロジェクトとか、試行錯誤を繰り返す難度の高いプロジェクトには適用はむずかしいと考えられます。

(7)日本電産「残業ゼロ」を宣言
 昨年10月末のDAIAMOND ONLINE の記事ですが
 http://diamond.jp/articles/-/105939

 'モーレツ日本電産も挑む「残業ゼロ」は実現可能か?'という興味深い記事がありました。
 この記事によると、モーターの世界的メーカーの日本電産の永守重信社長は創業以来、朝8時から夜12時まで一日16時間、年365日自らに課していたそうで、業界ではハードワークで知られていたそうです。
 そのハードワークで知られていた社長が「2020年までに残業ゼロを目指す」といい、
日本電産の代名詞といわれた「モーレツ」の言葉を挙げて「モーレツはもうウチにはない」と会社の決算発表会場の場で言い切り、世間を驚かせたそうです。
 この記事の中で興味深いのは、
 '社員が自ら望んで行う残業は「あり」か「なし」か?'
 という部分で、以下に引用させていただきます。

(以下、DAIAMOND ONLINEより引用)
--------------------------------------------------------------------------------
 さて、仕事の構造や会議の構造をいくら変えても減らない残業がある。それは社員が自ら望んで行う残業だ。
「生活が苦しいから残業代が必要だ」という社員は、会社全体で「帰れ!」と言えば意外と減っていくものだ。 しかし、本人が「仕事が好きで働きたい」という場合はどうだろう?日本電産の永守社長自身がそうだったように。

 人間があるスキルに習熟するには1万時間が必要だという説があり、これはかなりの部分で正しいらしい。それがスポーツであれ、趣味であれ、仕事であれ、1万時間こなしたあたりで深いところまで理解が進む。 つまり、その道のプロになれるのだ。

 そこで若手社員が「早くこの仕事のプロになりたい」と考えたとしよう。 経理でも営業でも企画でもいい。年間1950時間労働で残業ゼロの会社で働くと、1万時間に到達するのは6年目だ。 ところが永守社長のように働けば、2年で1万時間に達することができる。

 私自身、コンサルティングファームに入社した最初の5年は、勤務時間が毎年5000時間を超えていた。 午前2時にタクシーで帰宅して、翌朝は9時半に出社する毎日。 当然土日はない。 仕事はきついが、チャレンジングであり、タフな毎日をある意味で楽しんでいた。

 そして、そういう働き方をする人材でなければ生き残れない職場でもあった。 コンサルティングファームが残業ゼロを目指すことはまあ考えにくいが、普通の会社の職場にも、「少しでも多く働いて、スキルを身に付け、実績を上げて、職場でのし上がりたい」と考えている若手は存在する。 ないしは「この会社の仕事は3年で覚えて、次のよりよいキャリアを求めて転職したい」と、内心考えている部下もいる。

 彼らに「残業ゼロ」を納得させるのはかなり難しい。 逆にそういった人材が隠れて長時間労働をし、結果的にいい仕事をする場合は、他の社員との評価において不公平が起きる。

「仕事をし過ぎる社員は、うちの会社には必要ない」

 どこまで経営者がそう自信を持って言い切れるか、最後はそこが問われるのである。
--------------------------------------------------------------------------------
(以上、DAIAMOND ONLINEより引用)

(8)イノベーションを生み出す開発現場
 ソフトウェア開発従事者にはイノベーションへの取り組みは、避けて通れないルーチンワークです。 今使用している技術は数年後には役に立たなくなるかもしれません。 新たな技術を習得する場合や、初めて取り組む分野の仕事を受注した場合も未知の領域の知識や技術習得が必要な場合は数多くあります。 そのような現場で残業ゼロで仕事がこなせるのか私個人としては、よくわかりません。
 

Copyright(C) 2002- ISABOU.NET All rights reserved.