九州のベンチャー企業で、システム屋をやっております。「共創」「サービス」「IT」がテーマです。

ブラックとホワイトの狭間で

»

〇我々はブラックなのか
 昨今、大手広告会社の社員過労自殺問題で働き方改革という言葉をよく聞くようになった。また、厚労省はブラック企業の公表基準を見直し、労基署から是正勧告を受けただけで公表されるようにもなった。過労自殺やブラック企業を労働時間だけで評価するわけにはいかないが、世間は長時間労働に対して厳しくなってゆくのだろう。

 そしてこのような情報に触れると、どうしても心がざわついてしまう。

 当然、過労自殺やブラック企業を肯定してい訳ではない。パワハラや行き過ぎた指導、サービス残業などは許されるわけではないが、長時間労働に関しては、どうしても発生してしまう現実があるからだ。どうしても開発を生業としていると、残業は当たり前で徹夜作業や休日出勤が常態化してしまう。いちプロジェクトの一過性の状態ならばまだ良いのだが、景気がよくなり案件が増えると開発メンバーはプロジェクト渡り歩き、長時間労働の状態が普通の状態になってしまう。もちろんのこと、長時間労働の常態化を好んでやっているわけでもなく、メンバーの定時内の働きのなかで、なんのトラブルもなく計画通りにプロジェクトが進むことを目指しているのだが、小さい会社の限られた人的リソースだと、それはとても難しいと感じてしまう。
 まあ、それはウチだけの問題ではなく、業界自体の課題でもありシステム開発の業界にブラック企業が多いと言われる所以かもしれないのだが。

 こういった状況のなか、ダークサイドには陥らない様に、残業代の支払は当たり前の事、メンバーのモチベーションには気をつけ、しんどいながらもやりがいをもってプロジェクトに臨んでもらっていたのだが、最近はそれだけは足りず労働時間の縛りが出てきた。やらなければならないことは多くあるのに、メンバーが働けない。代わりのメンバーも見つからない。じゃあ一体、どうしろ、というような状況が起こりうるのだ。

〇CS vs ES
 そのような中、ダークサイドに陥ってブラック企業にならない様にという事で出てきた言葉が働き方改革だろう。よくわからないので調べてみると「働き方・休み方改善ポータルサイト」というサイトがあり、働き方改革の取り組み事例が紹介されていた。多くがノー残業デイの設置や有休消化率の向上、リフレの設置、テレワーク、ダイバシティなどを挙げられている。
 ノー残業デイや、有休消化、リフレなどは長時間労働の抑制であろうし、テレワークやダイバシティなどは多様性への対応であろう。興味を引いたのが多くの事例がノー残業デイや有休消化など従業員満足度の向上が目的なのに対し、中には顧客満足度の向上(サービス品質の向上)の目的の中で従業員の働き方改革を位置付けている企業もあるということ。
 これは非常に難しく感じる。顧客満足度と従業員満足度のバランスをとることは経営として重要であるが、よく日本の企業は過剰サービスであるという論調も耳に入る。日本企業が提供する肌理の細かいサービスは賞賛をうける一方で、従業員の献身(犠牲?)の上に成り立っている、というのだ。実際に、提供したシステムに障害で客先から電話があった際、たまたま担当者が昼休みに昼食をとりに外出して応対できないと、「こちらが大変な思いをしているのに昼飯で不在にするとは非常識だ」とクレームを入れられたこともある。あながち、そういったクレームにどう対応するかだが、往々にして顧客満足度のために従業員が犠牲になることがある。顧客に過剰なサービスを提供すれば、利益か従業員にそのしわ寄せが来るのは確かだし、現に日本のサービス品質の高さと日本人の勤勉さ(働きすぎ)がいつも話題になるのだから。

 さらに「お客様は神様です」的な過剰サービスは実は顧客満足度を向上させない、という話もある。お客様の無理難題に応えてゆくサービスはお客様に喜ばれる一方で、サービス提供側を疲弊させ、同等のサービスを提供することが困難になるため、中長期でみると顧客満足度は下がるというのだ。
 これも一理あるように感じられる。少し意地の悪い言い方をすれば、神様扱いされたお客様が勘違いし、チヤホヤされる事にかまけてしまい、本来自分たちでやらないといけない事が出来なくなってしまうような事ことが多々見受けられるからだ。例えばシステム開発を請負ったのだが、本来ならば客先担当がやらないといけないことを過剰に手伝ってしまったため、担当からは喜ばれたができあがったシステムはグダグダだったなどもありえる。

 日本では受発注者の間に力差があり、発注者優位の商習慣があるが、アメリカなどでは受発注者の間は契約のもとに対等であるような話も聞きはするが、実際のところ経験したわけではない。ただGoogle社が空港の図面をネット上に公開した際に、メールで謝罪した。という記事を読むと、日本とは文化が違うなと感じてしまう。

〇少しホンネ
 炎上覚悟で、長時間労働について少しホンネを書くと、正直、必要悪と考えているフシがある(あくまでも長時間労働であり、ブラック企業ではない)。理由は大きく二つ。ひとつは受注(プロジェクトの数と規模)と社内技術者のアンバランス。経営上、プロジェクトが増えることが売上が増えるのでうれしい。しかし、受注は年によって波があり、社内技術者の数は最低時の受注量で決まってしまう。受注の見込みがないのに技術者を増やすことを経営者は躊躇してしまうからだ。また外注化もコストの問題があるので、なるべく少ない社内技術者で多くのプロジェクトをこなそうとする。そうするとどうしても、社内技術者に負担が行ってしまう。
 もう一つは、技術者の育成。この業界、技術者は一生の技術力向上と向き合ってゆかないといけない。そのため、プロジェクトはメンバーの自己啓発と人材育成を考慮しないといけない。また、未熟な技術者と熟練の技術者の生産性は下手をすると何十倍も差が出る。本当に生産性のある仕事をしている時間を定時でやるとなると、技術取得と向上の時間がどうしても時間外で考えるしかない。そんな時間分の費用は認めないという考え方もあるかもしれないが、それでは意識の高い技術者はいつかないだろう。そして、人材育成の時間は未熟な技術者程多くなるし、基本的にはそれで良いと思われる。技術は量と質を熟さないとダメなのだから。ただプロジェクトにいる限り、納期の縛りがあるのでどうしても徹夜や休日出勤をやってでも自分のタスクは終わらせなければならない。

〇我々の働き方改革って何?
 そんな状況の中、あらためて働き方改革って何だろうと考えてみた。
 残業をするな、有休をとれ、リフレをくれてやる、というのは簡単だ。22時に会社の電気を強制的に消すのも良いだろう。本当にそれだけで働き方改革になるのだろうか?正直、開発現場には今以上の負担が来るだけの様に思えてならない。だから、現場の時間を減らすのであれば、業務量も減らすことをセットで考えないといけない。社内技術者の数を増やして業務を割り振る。未熟な技術者を参画させず熟練技術者でプロジェクトを回す。赤字容認で、外注化する。いっその事、顧客満足度は下がってもよいので、客先との打合せ減らせ、いらぬフォローはするな、受注金額を増やせ、など。

 どれも、経営者にとっては難しい判断と感じるられる...。
 
 そう。これまで通りのシステム開発というビジネスモデルの中では、働き方だけを改革するのはとても難しいのだ。
 となると、ビジネスモデルを変えるしかない。優秀なノンプログラミングツールやAIを駆使して、開発工数を劇的に短縮する。開発は全てアウトソーシングし販売と企画・設計のファブレス化。請負開発をやめてクラウドでのサービス提供業へ。かつて、機械化のながれのなかで、しんどい仕事が人から機械に置き換わっていったように。
 ん?これは本末転倒ではないか。働き方改革は、その人が働いている事が前提で、仕事がなくなってしまうと、それそれで別問題だ。

 ...やはり難しい。働き方改革は経営者はもちろんのこと、労働者にとっても難問なのだ。

Comment(12)

コメント

非現実性AR

プログラムってのは本質的に「耐久消費財」なんです。

こう書くとどこぞのコラムニストが発狂しそうですが、現実がそうなんだから認めるしかないわけですよ。

つまりどこかに飽和点があるし、コモディティ化も必然起こる。

新発明なんかそう頻発するはずもないし、無理矢理新提案したってニーズがないものが売れる訳ゃない。

そういうどん詰まり、パイの大きさが決まっていると認めた上での経営戦略をするしかないのと違いますか。

成長青天井前提で経営するから歪むし破綻するんです。

まずは身の丈計るところからでしょう。

山無駄

どうも 非現実性ARさん コメントありがとうございます。

プログラム(ソフトウェア?、システム?)を「耐久消費財」といって良いのかは分かりませんが、この業界コモディティ化が激しいのは確かですね。ハードウェアのPCやネットワーク機器、周辺装置はまさに最たるもので、20年前にPCは50万円以上もする高価なものでしたが、いまや10万円程度になるり、ほぼ消耗品に近い感覚です。価格的には1/5程度になっていますがスペック敵には10倍以上になっているわけですから、かなりの価格破壊です。
サーバ機器も用途が特殊であるためPCほどコモディティ化は進まないと思われましたが、PCの高スペック化がサーバとPCの境界を曖昧にし、PCがサーバになる時代になってしまいました。加えて、コモディティ化ではなくイノベーションだと思うのですがクラウドの出現で価格はさらに下がっています。
ソフトウェアも、プログラマーは昔は特殊技術者で高額な単価で稼いでいましたが、VBなど簡易な言語の出現により誰でもできる技術になってなってしまったとたん、単価は下がってしまいます。DBやセキュリティ、ネットワークなど特殊性のある分野ではまだ高額単価かもしれませんが、プログラマーほど需要のある職種ではありません。加えて、Googleなどの出現で高機能なソフトウェアが無償で使えるようになると、開発技術者のできることは限られてきて、さらにコモディティ化が進むでしょう。

ただ、この業界が特殊なのが、コモディティ化がイノベーションにつながっているという事ではないでしょうか。他の日常品の様にスペックが変わらず徐々に価格が下がっていく、というよりかはIT業界はスペックも価格も信じられないほどの短期間で変化しました。この変化は、システム化ドメインの急激な拡張をもたらしています。これまでシステム化ができなかった領域が、システム化されてきているのです(デジタル化といった方が正確?)。会社に数台だったコンピュータはPCとなって社員全員にいきわたり、タブレットやスマホになれば、ほぼ国民全員が持っています。いままで一部の業務だけに使っていたシステムは、いまやそれがないと業務は回りません。

おそらく、今、自分たちが主流と考えている事業ドメインは急速に縮まってゆき、別のところに新しいニーズが広がって行っているのでしょう。だから、おっしゃられる様に成長青天井の経営は破たんするし、短期変化の事業領域で、中長期の戦略をたてないといけないから、経営は難しいように感じられます。

和(わ)

>受注の見込みがないのに技術者を増やすことを経営者は躊躇してしまうからだ
その通りだと思います。
 受注がないから手が余る人が出てくる -> サボっている!問題!
となるのは目に見えています。
しかし、例えそれで手が余っても、
 手が余ったら学習する -> 次のプロジェクトが早く終わる -> 更に学習して次に備える
ということができると思います。
日本の会社は技術習得を軽視し、とにかく作業をさせたがります。
長く作業をすればするほど良い、それが勤勉で美徳だ、という愚かしい風潮で、負のスパイラルだと思います。
山無駄さんの「技術者の育成」を読んだ時に、学習の時間は時間外でやるという風に見受けられましたが、私は学習の時間は勤務時間でやってもいいと思いました。

山無駄

どうも 和(わ)さん コメントありがとうございます

>山無駄さんの「技術者の育成」を読んだ時に、学習の時間は時間外でやるという風に見受けられま>したが、私は学習の時間は勤務時間でやってもいいと思いました。

すみません。分かり難かったかもしれませんね。言いたかったことは、プロジェクトにアサインされて忙しい時に勉強時間をどうとるか、という事です。プロジェクトにアサインされていると作業を見積らいないといけません。その見積もりの中に学習時間を含めてしまうと、当然、そのプロジェクトはコストオーバーになってしまいます。だから定時で作業を見積り、定時外で学習するしかないのかな、と。当然、学習時間も時間外勤務として認められないといけないのですが、勤務時間に制約が出てくると業務優先で学習時間は優先度が下がってゆくのだろうなと。
しかし、実態は業務の中でスキルを向上させるOJTなどが主流となるので、定時は業務、時間外で学習というのは難しいと思います。
Google社の様に勤務の20%は好きな研究にあててよい、というのも理想ですが、請負開発を主体でやっている限り、それも難しいかと…。

非現実性AR

1980年代くらいは科学万能と言われてました。
21世紀に入ってとんと聞かなくなりましたが。
それはつまるところ、科学では解決できない領域があると周知されてきたからではないでしょうか。
それ同様ITで解決できない領域というものも存在し、現在その境界線に達しつつあります。自動運転とか馬鹿言ってんじゃないよって話ですな。
無限に仕事が湧いてくる訳ゃないんです。
もう大きくならないパイの取り合いの結末は、大多数が季節労働者化ではないかと睨んでいます。
IT土方と言うのも前世紀からある呼び名ですが、今にしてみると言い得て妙でしたな。

非現実性AR

確かトヨタあたりが言っていましたが、自動運転が実現しない理由は「法律」です。
突き詰めれば社会のあり方であり、生活のしかたであり、倫理の問題です。
ITは責任問題を複雑化させているだけで、解決には決して寄与しません。
死人が出なければ不幸じゃない? そんな訳ないでしょう。
IoTなんかもその手の臭いがぷんぷんします。
そしてそのくらいしかトピックがないIT業界は、やはりどん詰まりが近づいているのではありませんか?
10年先とか高をくくっていると足元すくわれかねませんよ。

ある

コラムの結論が、技術者がいらなくなるようなビジネスモデルまで飛躍してしまってましたが、
働き方改革は、絶対にビジネスモデルの転換がセットで必要と思います。
前提になる環境が変わらないのに、働き方だけ劇的に変わるなんてことはないな、と。

例えば、請負だけでなく自社ソフトの開発・販売を2つ目の武器として持つ。
そうすることで経営が安定するので、無理な請負案件の受注が減らせる。
そうやって割に合わないデスマ案件を減らしていかないと現場の負担は減らない気がします。
自動化はすべての企業に等しくやってきますので、自動化できない高付加価値の部分を
強みにするような単価の高い仕事へのシフト。
自社の技術者を活かすようなビジネスモデルの転換、という視点で是非。


> Google社の様に勤務の20%は好きな研究にあててよい、というのも理想ですが、請負開発を主体でやっている限り、それも難しいかと…。

20%も割り当てられるかどうかはともかくとして、
ゆくゆくは苦しい請負開発主体のビジネスモデルから脱却したいと思っておられるのであれば、
苦しくてもこういうことをするべきなんだと思います。
一見、鶏と卵的な話のようにも思いますが、起点はトップの意思表示、経営戦略そのものだと思います。
数人のベンチャー企業で、資金もろくにない状態で新しい事業を立ち上げる人たちも
たくさんいる(もちろん死屍累々の先ですけども)わけですから、やってやれないことはないな、と。

非現実性AR

2011年頃の研究に「AT車の事故率はMT車の2倍近い」というのがあるそうで。
ここのところの誤発進事故もMTではまず起こらないものばかりです。
「技術『で』社会を変えてやる」なんてのは、もはや弊害の方が大きくなってますよ。
大体「よく吟味」されたことが歴史上一回でもありましたか?
みんな見切り発車で大事故起こして現在に至るまでグダってばかり。
IoTも安全性担保される前にやろうやろうばかりじゃありませんか。
ITだけで完結してる分にはまだ被害も少ないですが、あれは本当に危ないです。
いい加減懲りて学習すべきだと思いますね人類。
そして他分野に進出しようって話しか出てこないあたりが、ITの余地のなさを端的に表していると思います。

コメントを投稿する