多重下請けとか
100名という境
企業規模100名を境に平均給与が大幅に上がるというのはなかなか興味深い。
他業界同様、ある程度の規模拡大を目指すのがSIの正道か。
中小零細企業
SI業界は中小零細企業が多い。
土地、店舗、工場などの大きな初期投資を必要としない、また、士業と異なり免許を必要としないし、規制産業でもないので、参入障壁が極めて低い為である。
ベンチャー
単なる中小零細企業が自らをベンチャーと呼ぶケースは割と多いように思われる。
ベンチャーとスタートアップは本質的には意味が異なるのだが、日本では似たような意味で捉えられることも多い。
個人的には設立５年を経過した企業がベンチャーを標榜するのは些か自己欺瞞ではないかと感じる。
５年を過ぎてなお自らの事業を「冒険的な企業」と定義するのは些か乱暴だと思う。
というか、みっともない。
中小零細企業での新事業立ち上げ
資金的余裕のない中小零細企業で経営基盤を維持しつつ新規事業を立ち上げるのは分が悪い。
規模拡大への道
幾つかのSI企業のHPを見て気付いたのだが、沿革にM&Aがある企業は少なくない。
10年を超えて思うような事業展開、規模拡大を行えていないならば、まるっと会社を売ってしまい、大きなところに吸収してもらった方が良いのでは？とか思う。
（資金的余裕があるなら逆に他を取り込むのも手かもしれない）
企業規模と給与に相関性が認められるならば、社員にとっても大きな会社に吸収される方が幸せだろう。
ただ、役員にとってメリットが大きいか否かは場合による。大企業の部長・係長クラスの方がより大きな金額・人材を動かせたりもするのだが、（節税など）経営陣が会社の仕組みを積極的に活用している場合、この限りではない。
（会社の保養所や寮が実は上層部社員の個人資産だった、というのもよくある話）
M&A
「業界再編時代」のM&A戦略 ~№1コンサルタントが導く「勝者の選択」~
- 作者: 渡部恒郎
- 出版社/メーカー: 幻冬舎
- 発売日: 2015/09/19
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
売れているらしい。
ただし読んでない、気にはなっているのだけど。
なぜ多重下請けが起こるのか
個人的には中小零細企業の乱立が大きな原因の一つと考える。
そもそも発注者側は多重下請けを望んでいない。むしろ労務管理が煩雑になるというデメリットの方が大きい。
下請け企業側が潤沢な人材供給力を有していれば、そこから更に下請けへ、ということはなくなるのだが、実際にはその力が不足している為、更に別企業へ人材を問い合わせるということになる。
派遣会社の活用もある程度は成功しているが、スキル評価という点ではそこまでの信頼性を得てはいない。SIはフリーの人材ブローカーが跋扈している業界なのだが、人を評価する力という点では彼らの方が信頼性を得ていると思われる。
下請け側が「うちは多重下請けではやりません」と宣言するのも手だが、多くの中小零細はそこまでの営業力を持ち得ない。
発注者側が「直接契約」にこだわるのも手だと思う（近年は増えている）。
「長年の関係」を重視し、目を瞑るケースが多いのだが、多重下請けは本質的にデメリットの多い仕組みである。業界は別だが、建築業界の不正事例（検査に対する結果改竄など）も多重下請けが原因の端をなすケースも多い。
SI業界で多重下請けが確認される現状の状態で、品質毀損や情報漏洩事故が今のレベルで収まっているのはある意味奇跡ではないか、とは思う。
社畜と下請け、独立心
「このまま社畜で終わるのか？」と煽られ、独立起業したとしても、仕事の受注先が元々いた起業であれば、単に下請け構造が増えるだけである。
結局、元いた企業以外に販路を広げられないケースは割と多いように思われる。
「独立したい」というのは、報酬に関わらず野心ある社員なら一度は考えることのようだ。
外部から見ると親会社に100%依存し、経営基盤も超安定している子会社でも親会社からの「独立」を夢見たりするのだから、奇妙な話だと思う。
昔の記事
似たようなことは相当前に書いていた。
ところでこの記事
アニメーター業界は「肩書きはフリーランスなのだけど、会社に席を確保して仕事する」のが割と一般的なようだが、一歩間違えればそれになる事例。
正社員として固定費化せず、必要に応じてそれなりのスキルの人材を確保できるのはある意味企業としては理想である。
インセンティブの最大公約数はカネとチカラとか
モチベーション
そもそもは、目標シートへの疑問提示の記事から始まった記事なのだが、
エンジニアにとっては金銭面よりも（もちろんある程度は必要）
どれだけ楽しい仕事ができるかのほうが重要だったりする。
この結論は一部のエンジニアを一般化しすぎるという点で極めて危険である。
「モチベーションの源泉はバラバラであり、それがマネージメントを難しくする」という南場智子の指摘の方がすっと胸に入る。
日本に「モチベーション3.0」が根づかない理由 ： プレジデント（プレジデント社）
最近話題に上ることの多い、ダニエル・ピンクの「モチベーション3.0論」は、ある意味では、ハーツバーグらのこうした議論をさらに発展させたものである。彼は、「モチベーション 1.0」は「生存や安心に基づく動機づけ」、「モチベーション 2.0」は「アメとムチに駆り立てられる動機づけ」だと定義し、内面から湧き出るやる気に基づく
「モチベーション3.0」こそが、創造性を要する高度な知的業務に携わる現代の労働者には、重要な「やる気」の源泉だと主張する。
モチベーション3.0は必要充分な報酬が与えられていることが前提とは思う。
ただ、日本の多くの企業はそれが充分ではない為、その前提が成立しない。
インセンティブの最大公約数はカネとチカラ
多くのエンジニアや労働者に有効なインセンティブの最大公約数はカネ（報酬）とチカラ（人事権、決裁権などの裁量）だと思う。
そこを無視して、経営陣がポエム化（精神主義）を目指すと、立派なブラック企業が出来上がる（「システムの問題を各人の精神主義で解決しようとする」）。
目標管理シートへの批判
目標管理シートが有効に機能していない、という批判だが、「マネージメントの難しさ」に立脚すれば、いささか仕方のないことのように思われる。
批判を受け入れ、粛々と仕組みの改善を続けるしかない。
ただ、目標管理シートは人事評価ツールであり、本来は貢献度測定ツールである。
貢献度を正しく測れず、従業員のモチベーションに対しマイナス効果を与えるならば、やめてしまうのも手だろう。
評価がない会社の現状
なお、目標管理シートどころか、評価や査定がない会社を知っている。
この場合、会社が与える形での、従業員のスキルアップを促すインセンティブが存在しない。
観測結果、彼らが自発的にスキルアップを行うか？と問われると、業務効率化の為、ある程度は取り組むが、低い達成度で満足する者が多い、というのが実情である。
CMSの選定とか
Qiitaは割と頻繁に眺めるサイトですが、少し気になる投稿があったので。
極めて個人的な感想なのでブログで。
RailsでCMS
友人のBlogサイトを構築するのに、選定の結果、Refinery CMS(Ruby on Rails CMS that supports Rails 4.2)を採用したという記事。
選定の理由
「Paasで安くて手軽に運用したい」「Railsでも遅くならないはず」を除けば、これらは全て初期開発者側の都合でしかない。
wordpressはPHPの特性のためか、HTMLと処理が同じソース内に存在します。 昨今MVCと口うるさく言われている開発者としては非常に気持ちが悪いです。またwordpress独自の実装方法を覚えないといけないのが最悪です。
wordpressの良い点は非開発者でもサイトが簡単に作れるところ。しかし現実はデザイナーさんだけでは解決できない要望が多いのも事実です。メンテナンスがしにくいwordpressよりもRailsで楽に要望に応えられる方がメリットが多いと判断しました。
Railsを理解している人間より、WordPress(或いはPHP)を理解している人間の方が圧倒的に多いのが現実だとは思うが？
デファクトスタンダードで考えるべき
仮に自分が友人側のエンジニアに立っているなら、WordPress（CMSのデファクトスタンダード）で構築を依頼することを強く勧める。
先々、自分以外の人間がメンテナンスできる可能性を残すなら、当然、エンジニアを確保しやすい、デファクトスタンダードで実装することを考えるべき。
デファクトスタンダードを捨てるケース
なお、デファクトスタンダードを捨てるケースも幾つかあると思われる。
- 顧客が既に何らかの技術ベースを持っており、そこに準じる場合。
- 顧客要件に対しデファクトスタンダードでの実現が困難な場合。
- 技術的に開発物が自社（或いは開発者）の所有物であり、継続して運用し、開発効率を重視する場合。
- 戦術として、開発者が顧客（案件）を囲いこむ場合。
- （金銭など）開発作業から得れる報酬メリットがゼロに近い為、開発者の「やりたいこと」で埋め合わせをする場合。
「友人のBlog」の場合、5に該当している可能性がある。
なぜこんなエントリーを書いたのか
前述した、自分以外の人間が運用改修を行う可能性を軽視するエンジニアについて、これ以外でも、あまりに多く散見されると思った為。
もしすると僕自身、クライアントワーク思考に陥っているかもしれないが。
（自分達のプロダクツであれば、他者が運用する可能性は低い）
CMSの革新（蛇足）
サーバーサイド、・・・少なくともCMSについては、WordPress以降、ここ４、５年は革新的な発見は何１つない。
そこは十二分に成熟している。探検に投資する意味はあるのか？
運用に対する個人的な考え
なお運用に対する個人的な考えは以下になる。
プログラムの英語とか
指針
命名に関しては幾つかの指針が考えられるが、開発プロジェクト内でそれを共有しておくことが重要。
- 正しい英語で記述する
- 分かりやすい英語で記述する
個人的には「迷ったら短い記述にする」という指針をとっている。
タイプ数が少なければ、開発時間も短くて済むという単純な理由。
並び順
[動詞]+[名詞]か、[名詞]+[動詞]か、についてはファイル一覧等で綺麗に並ぶか否かで決まることが多い気がする。
分類としては[名詞]を採用することが多いので、[名詞]+[動詞]になりがち。
ローマ字
顧客によっては、「ローマ字日本語でコーディングをお願いします」という企業もあり、当然そのルールに従う。
ローマ字日本語なのは、「英語に詳しくなくても分かるから」と極々自然な理由。
プログラミングの為の英語教育に投資する必要なし、との判断がされている。
regist問題
9. registという単語は存在しない
日本人には(？)なぜかregistという単語が存在すると思っている人が多いですが、そんな単語は存在していません。意外と間違いだと気づいていない人が多いのでリストアップしておきました。
registについては定期的にネタになっている。
今まで出会ったプログラマ(日本人)については、ほぼregistを使っていた。
多分これが日本標準だと思うし、気付いてもそこに突っ込むことはしない。
なお、自分は短い方が好きなので、「reg」と省略することが多い。
複数形のs
Railsの場合、単数形複数形の変換メソッドがあるので話が変わってくると思うが。
例えば、"person"の複数形は"people"なのだが、単純に"persons"と"s"を付与するだけにする。
"s"は単なる印である、と割り切る方針であれば、このような形式になる。英語知識も必要としない。
もし
もし、上司に「正しい英語を使ってプログラム書かなきゃダメじゃない？」とドヤられたら、「それで可読性本当に上がります？修正しやすくなります？開発時間が短縮して、僕が早く帰れるようになります？」と言ってしまうかもしれない。
客先常駐とか
話題
メリット、デメリット
ブコメに書いたが、簡潔に。
- メリット - 営業マンとして顧客の近い場所に位置付けられる。
- デメリット - 技術や業務ノウハウなどが社内に蓄積されにくい。
客先常駐社員の精神的負担
場合による。
自社の方がむしろ制約が多いケースもあり（社内飲食禁止、服装、休憩の扱い、朝礼など）、こういった場合「客先の方がむしろ楽」と思われることもあるようだ。
客先常駐の数
そういった業界とは若干ずれた場所で働いているので「主語が大きい」事案ではあるが、客先常駐の絶対数自体は減っているように感じる。
リモートワーク環境の整備
減っているように感じる理由の１つがインターネットやPCの発達によるリモートワーク環境の整備だ。
ネットがなかったり開発環境の入手が難しかった時代、そもそも客先でなければ開発ができない状態だったように感じる。
90年代末期頃からそういった状態が変わっていき、近年ではオフショア開発までたどり着く。
開発プロジェクトの短期化
「減った」もう１つの理由として、小規模案件が徐々に発生するようになり、プロジェクトが短期化したことがあるように思われる。
かつては年単位のプロジェクトが圧倒的多数だったが、現状、一ヶ月単位のプロジェクトも相当増えたと思われる。
1人月案件を年12本回す場合、それが定期的に発生するということはほぼなく、幾つかの案件は時期が重複する。時期が重複した場合、「どの案件に集中するか？」といったスケジュールを日単位で詰める。客先常駐でこれを行うのは非常に困難だ。
客先常駐案件での重複について
客先常駐案件の期間中に別顧客の案件を行うということは相当難しい。
実際に経験があるのだがあまりいいものではない。
- 常駐先で周囲の目を気にしながら、ものすごくコソコソ他案件を手がける、授業中の早弁状態
- 常駐先での業務終了後、自社にて別業務を行うという極めて心身負荷が高い状態
ちなみに、昔、常駐先で「持ち帰りの方が複数案件回せて（売上的に）良いですよ」みたいな話をしたら、「そうことはお客さんにあまり言わないほうがいいよ」と優しく諭された。
まぁ１人月は１人月。。。
常駐によるリスク回避
自社内での開発で問題ない、と持ち帰りで任せたものの、「期日になってもできてない」という発注先が幾つかあり、結局、常駐をお願いし缶詰対応していただいた、という経験があります。
なので、リスク高めだったり、新規発注先の場合、常駐で対応をお願いできないか、まず考える。
発注先の開発能力が把握できており、アウトプットが信頼できるなら持ち帰りでも問題ない。
個人的には
個人的には今の職場環境のゆるゆるさが気に入っているので、客先常駐案件はできれば避けたい。
運用など別案件を同時に回したり、社内業務が少なくない、というのもある。
ただ、売上が下がれば、そういう案件でも取らざるを得ない状況になるのだろうな、とは思う。
由々しき問題
なお客先常駐という労働スタイルが、多重請負という重大な労働問題を発生させる温床となっているのは否めない。
昔書いた記事
新しいIT技術を習得するとか
無駄な育成投資
営業が「仕事になるから」と言って、大勢の社員に講習を受けさせたが、あてにしていた顧客担当者が異動になって、無駄な投資になったとか。
「これからxxxというソリューションを売っていくんだ」と言って、一年近くそのソリューションに専念させているけど、実際に受託できる見込みがまるで立ってないとか。
遊ばせる社内リソースもロクにないのに、と、ストレスがたまることが多いので。
営業、技術の信頼関係
営業は営業で「新しいソリューションをあまり提示してくれない」という不満があるだろう。「でも提示したところで今までちゃんと売り切ったことないでしょ？」と技術者側は不満があって、そもそも信頼関係が。
技術者の市場価値
技術者として市場価値が高いのは「イノベーター」か「ラガード」と考える。
「イノベーター」は普及段階では先駆者として扱われるため、大きな先行者利益を得られる。ただし、その技術が普及しないリスクがある。
「ラガード」は単に新しい技術に疎いという意味ではなく、ここでは既に枯れた技術(COBOLとか)をスキルとして有すると仮定する。市場規模は縮小するが、対応できるエンジニア数の減少はそれ以上に激しい為、人材市場からの獲得コストが非常に高くなる。
市場価値の現実
しかし、多くのIT技術者はこういった純粋な「技術者」として実は生きることはできない。
IT技術の市場は開放的である為、プレイヤーが多い。
また、IT技術への知見は業務遂行能力の一部でしかない為、純粋たる必要がない。
習得の効率
「その技術をいつ覚えるか？」という点ではアーリーマジョリティーの段階が一番効率がよいと思われる。
その段階になると、ある程度の知見やTIPS、書籍が出揃っている為、学習コストが下がっている。
また、IT技術者以外への普及はもう一段階遅い為、受託であれば、十分に顧客の要請を満たすことができる。
たとえ、デファクトであっても、代替選択肢が既に存在しているのであれば、それをあらかじめ覚える必要があるか否かは疑問だ。業務で必要になった時点で１ヶ月程度で覚える。「覚えた技術が無駄になる」というリスクを回避する。
技術の習得価値
あらかじめ技術を覚えるとしたら「今後金になりそうか否か」「ラクになるか否か」だ。
自分の経験上、新規開発受託においては、言語やフレームワークの指定が要件として入ることはあまりない。発注者側が開発体制を維持していなければ、こういう要件は発生しない。多くの発注者は開発チームを所有していない。
問題は運用を引き継いだ場合だ。この場合は流石に言語、フレームワークが決まっている。この時は「めんどくさいな」と悪態をつきながら、新しい技術を習得する。
イノベーター理論とは1962年に米・スタンフォード大学の社会学者、エベレット・Ｍ・ロジャース教授（Everett M. Rogers）が提唱したイノベーション普及に関する理論で、商品購入の態度を新商品購入の早い順に五つに分類したものです。
- イノベーター（Innovators：革新者）：
冒険心にあふれ、新しいものを進んで採用する人。市場全体の2.5％。- アーリーアダプター（Early Adopters：初期採用者）：
流行に敏感で、情報収集を自ら行い、判断する人。他の消費層への影響力が大きく、オピニオンリーダーとも呼ばれる。市場全体の13.5％。- アーリーマジョリティ（Early Majority：前期追随者）：
比較的慎重派な人。平均より早くに新しいものを取り入れる。ブリッジピープルとも呼ばれる。市場全体の34.0％。- レイトマジョリティ（Late Majority：後期追随者）：
比較的懐疑的な人。周囲の大多数が試している場面を見てから同じ選択をする。フォロワーズとも呼ばれる。市場全体の34.0％。- ラガード（Laggards：遅滞者）：
最も保守的な人。流行や世の中の動きに関心が薄い。イノベーションが伝統になるまで採用しない。伝統主義者とも訳される。市場全体の16.0％。
