とある元SEの思考を探る

ひょんなことからとあるICT企業ではたらくことになったなんちゃって元SEがしたためるブログ。主に、政治・経済・社会問題・日常の出来事について発信していきます。お読みいただけたら、感動にむせび泣くほど嬉しいです。よろしくお願いします。


エンジニアの給与に関して思っていること

またこんな月に一度も更新がないブログにコメントをいただきました。
ありがとうございます。

smartenergy.hateblo.jp

返信したいなと思いつつ、番組の終わるタイミングだったので、アイドル論を語る記事を先に公開してしまいました。鉄は熱いうちに打てと言われるので、自分の中で盛り上がっているときに書かせていただきました。

 

さて、本題に入ります。

 

SIerからWeb系をみると、裁量労働制も含め、自由な働き方やおしゃれなオフィス、最新の技術を扱っているという輝かしい面を強く感じるかと思います。

その反面、闇というのもあり、その一つが給料、もっと広く言うとキャリアパスというところだと思います。


Web系をはじめ、できて数年の会社はみなし労働制をとっているところが多いでしょう。2社目も3社目もつき45時間のみなし残業時間がついて固定給でした。これに関しては、私はどうしても仕方がないと思っています。
私は新卒で入社した会社の頃から残業代に対しては疑問に思っていました。なぜなら、ゆっくり仕事して残業をして、残業代を稼ぐ社員が多くいたからです。生活残業とも言われていました。

また、配属される部署によって忙しさは異なり、忙しさによって給与が変わるというのも不思議でした。私が配属されて半年ぐらいはそれほど忙しくなく、定時に帰っていましたから、同期で遅くまで働いて残業代で自分より稼ぎがいい人の話を聞くと、本当に忙しいのか、それとも仕事が遅いだけなのか疑問に思っていましたし、本当に仕事量が多いのであれば、当時の私のように余裕のある部署はありますから、緊急的にも配置換えをするなどという対応をすればいいと考えていました。
もちろん大企業で部署の異動ですら容易なものではないこともわかっています。しかし、今の変化の早い時代、それでは追いついていけないのでないか、という思いも同時にありました。
炎上している案件に要員を追加しても教育コスト等で逆に遅くなるということもあるので一概には言えませんが、システム屋なのだから、会社全体の発注状況、アサインされているメンバー、進捗度合い等から、事前に人員が不足しないかをある程度予測できるのではないか、と考えたりもしていました。

なので、裁量労働制で残業代がつかないということに不満があるのではなく、その人の能力に対して賃金が支払われていないということに不満があるのだと思います。

賃金の算定根拠となる指標はいくつかあります。職能給(能力に対する給与)、職務給(仕事の内容に対する給与)、役割等級(役職や職務に求められる役割に対する給与)などです。

職能給といえば、従来の日本企業では、年功序列賃金として考えられていました。長く働いているほど職務を遂行する能力が高いだろうということです。しかし私は、年功序列だけが職能給であるとは思いません。むしろ、在籍年数などは考慮せず、個々人の能力だけを見て定めるべきなのが職能給だと思います。これはエンジニアの世界だと割と明確で、例えば、Railsができる、React.jsができる、などがそれに当たります。もちろん、Railsができるといっても、どこまでできるのかというのがあるので、単純ではないのですが、会社としてそこをきちんと評価できているかというのが大きなポイントになってくると思います。

私の2社目のとき、その会社は東洋経済でも賃金が低い会社としてランクインされる会社で働いていました。みなし労働時間いっぱいまで働いていた時期があり、それでも年収が300万円台前半で、とてもストレスを感じていました。

その人の能力というのはしばらく働いてみないとわからない部分があるので、最初は安いのは仕方がありません。会社としても本当にきちんと働いてくれるかわからない人に最初から高い給与を支払うことはできませんし、雇われる側としてもいきなり高い給与を提示されたらプレッシャーに感じるでしょう。

こうした事情を鑑み、私がここで会社に対して提案したいのは、入社後3ヶ月〜半年程度で通常の給与改定とは異なるタイミングで新入社員の給与を見直すことです。想定より働いてくれるのであれば給与を上げたり、過去に払った賃金が少ないなと思えば、賞与という形で支払うというのが良いと思います。

ところが、多くの会社は最初入社したタイミングで賃金が安ければそんなにドラスティックに昇級しないことがほとんどだと思います。2社目でも3000円しか上がらなくて退職を決意したという話をつい最近も聞きました。

残業代というのは言ってみれば職務給に当たると思います。残業して仕事量を増やすわけですから、能力とは別な軸なわけです。仕事量ではなくて、能力も十分に加味して給与を支払ってもらえる、そんな会社に勤めることが大事なのだと思います。

そういう会社を探すのは大変ですし、自分から会社に対して発信するのも多大なエネルギーが必要です。労働組合があればそこに相談すればいいかもしれませんが、労働組合は一律賃上げなどは頑張るものの、個別の事象に対してどのくらいまで対応してくれるかはわかりません。やはり自分で頑張るしかないということだと思います。

その方法の一つがやはり転職だと思います。昨今、アベノミクスで求人は大幅に改善されてきています。私がかねてから主張してきたリフレ政策が効いてきている結果だと思います。(まだまだ不十分ですが)

私が最初に転職した時とは大幅に状況が変わり、エンジニアはどこも引く手数多です。年収500万以上の給与水準の求人はたくさんあります。私の2社目でも最近大量に人が辞めていっていますが、昨今の状況を考えると当然と言えるでしょう。

会社を見るときに、経営者が従業員の給与に対してどういうスタンスでいるのかというのは大事なポイントになってきますが、経営者がどういう経歴なのかというのは大事な要素です。

例えば、経営者が外資系出身であれば、会社員時代の給与が高いので社員の給与も全体的に高くなる傾向がある気がします。あるいは、昔から能力に対してお金を支払われるべきだという意見の人であれば、能力に見合った給与を提示してくれるでしょう。傾向として高学歴な経営者に多い気がします。なぜなら、そういう人たちは昔から、自分は他の人よりもできるのになぜ報酬の差が少ないんだと思う機会が多いからです。

もちろんむやみやたらに高給を提示してくるのは危ないので、もし自分が想定しているよりも高い給与を提示されたら、下げてもらうよう断る勇気も必要です。あるいは働いてから査定してほしいという交渉をしても良いでしょう。

転職で多くの会社を見るのは大変かもしれませんが、昨今の状況を見るとちゃんとしたエンジニアであれば大抵は入社できるものと思って活動すれば良いかと思います。

私が就職活動をしていたときは、不景気だったので、どうせ採用してくれないんでしょと思ってなかなか企業研究に力が入らなかったのですが、今はエンジニアが会社を選ぶ時代ですので、「求人を出している=人手不足=自己研鑽をしっかりしていれば入社できる」という図式が当てはまることが多いかと思います。

 

次に、Web系の買い叩き問題ですが、コメントくれた方がどういった業態なのかわからず、私が自社サービスおよびOEM提供(受託に近い)の経験しかないので、的外れになってしまうかもしれませんが、自社サービスに関しては、基本儲かっていないケースが多いです。あるいは、まだまだ投資の段階で黒字化できていないケース。よっぽどビジネスモデルが秀逸でないかぎり、自社サービスですぐに黒字化するのは難しいことが多いように、周りをみていて感じます。

もし仮に儲かっていたとしても、ストック型のサービスの場合は、サービスを運営していれば自動的に収益がついてくる構成となっているので、最低限運用してくれるエンジニアがいればよく、そうしたコアメンバーにはそれなりの報酬を払うものの、細かな改善施策などをするエンジニアには給与を高くしないという会社はあると思います。まさしく2社目がそうでした。現に最近退職するメンバーのほとんどは平社員でした。
ですので、自社サービス系は給与が頭打ちになりやすい気がします。

そして、自社サービスにいて割と問題になるのはエンジニアのスキルの問題です。ずっと同じ会社にいると見慣れたコードしか見ないですし、見慣れた技術しか使わなくなってしまいます。私はRailsはじめて4ヶ月目で副業をして他のプロダクションのコードも見たのですが、当時自社サービスで使っていなかったテンプレートエンジンであるslimを知ることができましたし、wordpressとの連携なども学びました。違う環境に行くと違う技術や設計と触れ合うことができるので知見が増えます。

ずっと同じ組織にいるとそれができにくくなるのが難点であると思います。

もう一つは、クライアント対応です。自社サービスでクライアント対応が少ないサービスであれば、必然とこもって内輪で作業することが多くなってしまいます。しかし、今後のキャリアを考えたときにクライアント対応ができないエンジニアというのは、市場価値が下がってしまいます。自社サービス系の給与が頭打ちになるというのもここが一つ大きな要素ではないかと思います。ただ自分で開発しているだけではスケールしないのです。

 

別の観点で、受託型だとやはり労働集約的になってしまう点が問題です。コメントをくれた方が、「何千万かけて開発して保守費15万/月」というところからそんな感じがしています。ここも会社を選ぶときに、どこがその会社の強みかを見極める必要があると思います。

たとえば単純なWeb制作会社だとなかなか他社のWeb制作会社との差をつけにくいです。ところが、もう少し業務の一部まで効率化できるようなサービスで、SIerなどが競合になる分野であれば、SIerの価格に比べて優位に立てます。普段SIerとつきあっている人たちから見れば安く感じるわけです。それでいて開発側からして見れば、それなりに利益が出せる価格。SIerは従来型の開発をしていますから、結構ムダが多い。要件定義をする人と開発者が別になっていて、業務要件を知らない人が開発したりするわけです。昨今のクラウドサービス(AWSなど)やRailsなどの開発効率性の高いフレームワークを用いれば、そこをワントップでできる。現に私もクライアントと仕様を調整しつつ、自分でコードも書いています。

そういった他社と比べた強みがある会社というのが生き残って行く、すなわち収益性の高いビジネスをしている会社と言えるのだと思います。

 

ちょっと長くなってしまったので、明日続きを書きたいと思います。 

ラストアイドル第2期を終えて

3月31日の放送でラストアイドルの第2期が終わった。

最終的に表題曲を取ったのは、シュークリームロケッツ
ラストアイドル第2期は5人のプロデューサーが5組のユニットをプロデュースし、毎週2組のユニットがパフォーマンスを行い、1人の審査員が勝敗を決めると言う形式であった。

個人戦ではなく、ユニット対決という点が1期と異なる点であった。

最近休日もなかなか時間が取れないが、タイムシフトでも必ずみるようにしている番組がいくつかあり、ラストアイドルはそのうちの一つであった。第2期をすべて見てきて感じたことは、秋元康の絶対的なプロデュース力に他ならなかった。

実は私がシュークリームロケッツの「君のAchoo!」を最初に聞いたとき、楽曲単体としてはすんなりと受け入れられるものではなかった。

冒頭の歌詞は低音で入り、サビの前にはくしゃみをし、後半にはハンカチを取り出してカメラに向かってふきふきする。

奇をてらっている感。あるいは、秋元康の挑戦と言ってもいいのかもしれない。

受け入れることができなかったのである。

しかし、この曲が秀逸だったのは、1回聞いて気に入ってもらって終わりということではなく、およそ三ヶ月間に渡って戦っていくための楽曲であるという点である。

1月28日の放送では、シュークリームロケッツLove Cocchiに破れる。前述のように曲の難しい入りや、前代未聞の曲中のくしゃみなど、メンバーはこの曲に対してどう向き合っていけばいいのか、その答えが出ていないままでのパフォーマンスであるように感じた。
一方つんくプロデュースのLove Cocchiは、青春シンフォニーで挑む。まさにつんくワールド前回のパフォーマンス。1回のパフォーマンスで聴衆を虜にする楽曲であった。シンセサイザーの明るいイントロから、高音での歌い出し。「努力全部私になる」という歌詞もわかりやすい。後半の一人一人が右手を振り上げて、1人ずつ自分をアピールする場もあり、メンバーの良さを存分にアピールするパフォーマンスであった。
最終的にLove Cocchiは決勝トーナメントにも駒を進めることになるが、納得の結果であろう。

話を「君のAchoo!」に戻す。
前述のように「君のAchoo!」の良さは、1回ではわかりにくい。むしろ、三ヶ月を通してシュークリムロケッツの取り組みの様子も加味した上で良さがわかるような構成だったと言える。

各放送のパフォーマンスの前には、前回のパフォーマンスから各ユニットがどう取り組んだかが紹介される。
曲冒頭の低音の難しさにフォーカスを当てた回があった。ここでは曲としての難易度の高さをアピールした。
くしゃみの仕方に注目した回もあった。くしゃみという前代未聞のパフォーマンス。何を参考にしたらいいかわからない中メンバーがもがく姿を見せ、見ている人に感情移入させた。

また、他のユニットに比べ、細部にこだわっているというのをまざまざと感じた。

例えば、パフォーマンスの冒頭は、メンバー3人のスカートがくっついた状態からスタートする。軽めのマジックテープになっているのかどうかわからないが、くっついた状態から、回転してくっついていたのが取れる。こうしたメンバー同士の連携は、見る人の心を揺さぶる。同様のパフォーマンスが曲の途中でも見せる。3人が腕を絡ませて歌っている箇所があるのだ。確実に歌いにくい体制だと思うのだが、そうしたある意味での歪は秋元康が視聴者、特に男性の気持ちがわかっているということだと思う。これが2月18日の審査員の判定が男女で別れた大きな要因の一つだったと思う。

そして、もう一点気になるのが、Someday Somewhereのプロデューサーの指原莉乃のこだわりと言っていた「さしこ丈」である。スカートの長さを34cmに統一したというさしこ丈であるが、もっとこだわっていると感じたのがシュークリムロケッツだったと思う。シュークリームロケッツのスカートは一見長いが、これは二段構えになっており、衣装の後部は長い丈、前部は短い丈となっている。
長い丈にしている理由は長いほど遠心力を利用できるからであると思う。遠心力はmrω2で表せれるので、同じ角速度であれば、半径が大きい方が大きな力となるのである。
シュークリムロケッツのパフォーマンスの中には随所で回転する箇所がある。この時に、長い丈の方が美しく見えるのである。いやらしさもない。そして、回転のタイミングではカメラは必ずと言っていいほど引きで撮る。この理由は、実際に映像を見てもらった方がわかるであろう。回転のパフォーマンスは全体を映すのが一番映えるのである。

正直、1回見ただけではここまで気付くことはないだろうし、まだ他にも私が気づいていないこだわりもあるのだと思う。こうした1回だけで消費される楽曲ではなく、長く話題を提供する楽曲という点で「君のAchoo!」は優れているのである。

これは、プロデュース力と言う以外になんと言えばいいのだろう。

終わってみれば秋元康の独壇場だったと言えるのではないだろうか。


しかし、総じてみれば、どのユニットにとっても、幸せな終わり方だったのではないだろうか。
総当たり戦で全敗したSomeday Somewhereは視聴者投票で1位を獲得。総当たり戦でもトータルの審査員票が9とLove Cocchiに次ぐ数であり、自信になる。
Goot Tearsは、1位突破ながらも、トータルの審査員投票数では最下位。視聴者投票でも3位であり、1位突破は自信になるものの課題を残す結果となった。
Love Cocchiは、つんくのプロデュースがとてもよかった。路上で歌わせて度胸をつかせるなど各メンバーに課題を課すというのはなかなかできることではない。2位という結果も順当であろう。
ラストアイドルは、最初の2回は2勝したものの後半2敗することになってしまった。2勝したタイミングでの視聴者投票ということもあってか、視聴者投票でも最下位であった。とはいえ第1期で表題曲を取った経験もあるので、今回の経験を生かしてさらなる飛躍が期待できる。

どこまでがシナリオに沿った展開なのか分からないが、エンターテインメントとしては秀逸であったと思う。負けて表題曲は歌えないにしても結局はCDとして発売されるんでしょという前提もあるものの、負けた後に涙を流している姿を見ると本気で取りに行っているのが感じられる。もしそれもシナリオ通りというのであれば、賞賛に値する。

秋元康の手法の一つとしてアイドルの成長を見せる+競わせるということが挙げられると思うが、それが前面に出た番組展開であった。そして、どのグループにせよ、プロデューサーにせよ、秋元康の手のひらで転がされている感が半端ない上、それをわかった上でも視聴者を惹きつけてしまうのは、脱帽するしかない。

職業エンジニアの価値の指標

職場で、すごく知識はあるのになぜバグが多いのだろうというエンジニアがいて、エンジニアとしての価値の指標はなんだろと考えてみた。

 

そして、私の頭の中で、大まかに以下の6つにまとめてみた。 

  1. 業務の理解
  2. 技術に対する知識
  3. 保守運用性の高い(可読性の高い)コードの実装力
  4. バグが少ない
  5. コーディング速度
  6. アルゴリズム

それぞれ、活動しているフィールドによってどの軸に強いとか弱いとかあると思う。たとえば、言語を開発しているエンジニアにとってみれば、その言語が正しく動くためのアルゴリズムを実装できるかというのが大事な要素になってくるし、会計システムに関わっているエンジニアであれば、会計の知識(業務知識)は必須のものであると言える。

各軸について、簡単に説明したいと思う。

 

1. 業務の理解

業務の理解は、上位レイヤー(要件定義・外部設計など)に関わるエンジニアであれば、これができないと実装まで落とし込めないし、メソッドを作るにしても、メソッド名すら名付けるのが難儀になってくる。古くからのSIerでは、業務を理解していなくても与えられた仕様書に沿って実装してしまうかもしれない。しかしそれでは、その仕様書が本当に業務に沿ったものかがわからないし、それがバグの温床ともなる。SIerが炎上しがちなのは、実装がわからないSEと業務がわからないプログラマがシステムを構築することも一因であると思う。

 

2. 技術に対する知識

エンジニアであれば自分が使っている技術に関しての知識があるのは大前提であるが、全てを知っているというのは到底無理なので、今までの経験や自分の興味等により濃淡が生じる。例えば、Rubyエンジニアであれば、基本的なオブジェクト指向の考え方、Rubyが用意してくれている便利なメソッドたちを知っておくことは必要であるが、Cの実装までは理解しなくても仕事にはなる。とはいえ、内部実装を知っておくことは何らかの形で役にたつかもしれないから知っているにこしたことはないが、そこまでの知識は必須とはいえない。

 

3. 保守運用性の高い(可読性の高い)コードの実装力

究極的にいえば、逐次処理,条件分岐,繰り返しを理解していれば、望む挙動となるプログラムを書くことができるであろう。しかし、一つのメソッドがだらだらと長く、複数のことを行なっていたり、全然関係ないメソッドがあったりすると、後から読むと何をするコードなのか理解が難しくなる。

そうならないようにオブジェクト指向などの概念を理解し、プロジェクト毎のルールに沿って実装し、できる限り後から読んだ人が理解できるよに書くかが大事である。

また、あまり使われないトリッキーなコードを書かないということも重要である。少し挙動把握が難しくかつあまり頻繁に使われないメソッドをつかったりすると、その挙動の理解だけでエネルギーが消費され、それが要件にあった挙動なのかということと合致させる難易度が高くなる。できる限り、シンプルに記述するように努めるべきである。とはいえ、配列をforで回して代入して新しい配列をつくろうというのであれば、最近の言語にはmap関数があるのでそれを使わない手はないし、何が難しく何がシンプルなのかの線引きは難しい。言語の習熟度や時勢(流行り廃り)にも影響されるので、コードレビューなどを通じてチームとしての認識の一致をはかっていくべきであろう。

 

4. バグが少ない

バグというのは、必ず生み出されてしまう。これをゼロにするのは不可能に近い。しかし、バグをできる限り減らそうとする努力は怠るべきではない。

前述した、「シンプルに書く」 というのもバグを減らす良い方法の一つである。なぜなら、多くの場合、現実に求められる要件の方が複雑で移り気だからである。一見理不尽な要件が正しかったりする。一方でプログラムの方は完全に論理の世界であり理解すれば難しいことではない。現実の要件をコードからも読み取れるよう、できる限りシンプルに書くべきなのである。

バグを減らすというのは、言ってみれば、いかに全ケースを網羅できるかということにかかっている。数学でいえば、場合分けだ。二次関数の最小値を求める時に範囲がどこかによって最小値が変わる問題を解いたとことがあると思うが、それと同じである。一つでも抜け漏れがあれば、不正解となってしまう。このパターンが多くなればなるほどバグが生じやすくなる。このパターンをいかに網羅できるかがバグを減らす鍵となってくる。

 

5. コーディング速度

すなわち生産性だ。保守運用生が高く、バグが少ないコードを素早く実装できるエンジニアは強い。

 

6. アルゴリズム

実は、業務システムを作るにあたって、アルゴリズム力というのはそこまで必要とされない。

昔の人は並べ替えをいかに速く行うかについて研究してきた。マージソートクイックソートなどが考案された。

しかし、業務システムを作るにあたってはあまり重要とはならない。最悪、ループで回して一つずつ処理をおこなっていけばいいのである。それらの効率の良いアルゴリズムは、言語の中で実装され、私たちが知らないところで活躍してくれている。

また、特に近年は、ハードウェアの技術が向上して愚直に実装してもそれなりの速度で返ってくることが多い。札束で殴れば解決することも多い時代なのだ。

しかし、処理速度をあげたい!新しいロジックで機能を追加しなければいけないエンジニアはアルゴリズムをつくる力が必要になる。例えば、以前私はぷよぷよにインスパイアされたゲームを作ったことがあるのだが、4色揃えば消えるようにするのはアルゴリズムを書かなければいけない。ぷよぷよアルゴリズムであればググれば出てくるので、コピペエンジニアである私は、コピペして使ったが(もちろん、理解をし、自分の環境に合うように修正は行った)、新しいゲームのルールであればエンジニアが自分で考える必要があるであろう。

 

 

私自身はというと、どちらかというと業務寄りのコードを、しかも短納期で仕上げることが求められることが多いので、業務の理解やコーデイング速度はそれなりに高い方だと思う。しかし、技術に対する知識はまだまだで、先輩エンジニアに教えてもらうことも多い。保守運用生に関しては、自分では評価しにくいが、同僚に聞いてみたいところ。バグもまだまだ多く、減らす努力もしているが、なるべく検知して大怪我にならないようなところで止めるようにしている。アルゴリズム力に関しては皆無といってよく、競技プログラミングは敬遠している。