  |
はてなキーワード: 人月単価とは
JTC SIerの研究職と長年お付き合いしてきたけど、彼らはそもそも研究なんて高度なことをしてる人はごく少数で、ほとんどの人は要件定義フェーズの派遣業をしてる感じだね。
研究所も自分でお金を稼ぐというプレッシャーのせいか、事業部門が募集する「研究（依頼研）」という名の開発をする作業員をやっている。
その中で適当に新規性を見つけて（無理やりひねり出して）特許書いて研究所としてのノルマ達成。
ちなみに研究職の人月単価は通常SEの数倍に上るため基本は上流工程しかさせられない。また研究職のためかドキュメントはあまりかけないし、
プロダクトコードレベルの品質を作ることはもちろん、プロジェクトマネジメント等もできない。
となると一体何をやっているかというと、PJ初期段階の技術調査という名のAWSのドキュメントを読んでまとめる作業をしてたりする。
エンジニア組織に所属してまして上流工程を担当するmgrです。
本日企画承認会議でビジネス部門から商品企画が起案されたので、レビューと承認依頼がありました。
通常なら事前に根回しやすり合わせをして承認会議に臨むので、ハレーションは発生しにくいのですが、本日の企画は
事前レビューなし、完全初見、要求事項不明瞭、リターンも不明、何を開発すればよいかも不明、と散々。
そこで以下を聞いた。
・これのリターンは？ → やってみないとわかりません
・リーガルリスク（主に景表法まわり）対策は？ → あっ。。。
・売上計上方法は？ → なんですかそれ。。。
初見の企画を見せられて、何も回答しないので詰める形になった。
同席してたビジネス部門の責任者から「お前がそんな詰め方をするから萎縮した」となぜか説教された。
「お前ひとりが騒いでる」とも。
なるほど、そういう理解なのか。
KPIも不明、開発工数はおそらく15人月はかかりそう、リソース逼迫してると説明しててもこれか。
15人月なら工期は半年以上は必要だが、3ヶ月ちょっとしか猶予がない。
ユーザーに真っ当なサービスを提供したい、するんだ。そのために有限のリソースを最適配布するんだ、と
意気込んできたけど、全部私の一人相撲だなこれは。
うちの人月単価＠200なのでコスト3000万前後。部下は残業してまでも開発をしてる。
これに対して、クソ案件を安易に承認してしまうビジネス組織に絶望した。
もしくは、何も言わないで工数と工期を示すのみ、か？
https://anond.hatelabo.jp/20210610184501
文面からおそらく弊社の、しかも関わりのある事業部なのだろうと想像した。そういう意味ではまずは今までご苦労様。
まず自己紹介からしよう。私は主に公共向けのSEをしている部長相当職（社内ではある固有名詞で呼ばれている）だ。社内の製品は一通り把握している自負はあるので、よっぽどマイナーなものでなければおそらく君のところの製品も触ったのではないだろうか。
開発に必要があるなら申請を出せば普通に入手できるし、Gitも普通に使っている。正直なことを言おう。そんな小さいことで辞めたのか？と思ってしまった。35歳で主任（これもある固有名詞で呼ばれてたんじゃないか？）ということはそもそも開発者なんてフェーズはとっくに過ぎてマネージメントを任される頃のはず。これはたとえ製品開発の事業部だったとしてもそんなに変わらない。それなのにその視座の低さがとても気になったよ。概して若いコーダーは顧客のメリットが0であるような単なる自己満足としてGithubの利用やDockerを使いたがるが、悪いけどそのまま大人になってしまった感じを受けた。開発環境の優劣というのはそんな低レベルな話ではなく、上流工程での品質の作り込みがしっかり行われているかとか、品質管理のKPIがしっかりされており、そのKPIに対するPDCAが回っているかとか、人月単価を適正に管理し競争力のある製品を作る予算管理ができているかといったことのほうがよっぽど重要。
弊社はあくまでも「ものづくり」「エンジニアリング」の会社であって、「コーダー」の会社ではない。そのためDockerだのGithubだのMavenだのといった要素技術に対してそんなに価値を認めてないんだよね。もちろんそういった技術で儲けようとしているWeb系の企業がたくさんあるけれど、年収を比べてみれば結局どっちの市場評価が高いのか、よくわかるんじゃないかな。「ものづくり」で大事なのはあくまでも顧客の要求を満たすことで、それはDockerだのGithubだのMavenだのを使うことととは次元の違う話だし、市場価値が高いところにコミットしてそうでないところを適正に管理しているからこそその年収が出せるものだと思ったほうがいい。今の年収と同じ水準でモダン 笑な環境に転職したじゃないかと反論されそうだが、転職市場は前職の年収ベースになるので結局君の実力ではなく弊社の実力が評価されただけなんだよね。そこは謙虚になったほうがいいと思う。
まずシステム開発は「ものづくり」ということが見えていない。「ものづくり」というのは単にコードを書くというだけでない（君はそこにフォーカスしすぎて、その環境の悪さだけが目についたように見えた）。市場の要求に対して適切に答えてるのが命題であり、技術は単なる手段ということを忘れてはいけない。プログラミングというのは手段である技術のたった一要素に過ぎない。そういう徹底的な顧客志向を日本のメーカーは長いことやってきており、高い生産性を実現してきたし、社員にもその精神を学んでほしいという一心でビジネスを動かしている。だが、最近のIT系企業は「ものづくり」ではなく技術を目的にしているところが多いよね。MacやGithubとか言ってる層は特にその気が強いと思うのだが、君は結局そこに行ってしまったようだ。
以上を踏まえておじさんから一つだけアドバイス。今のWeb系がやっていることは所詮大昔の技術を再発明しているだけであり、本質的に価値が薄いということ自覚した上で本当に顧客が欲しい物を作るということを忘れないでほしい。例えばDockerなんて大昔からLinuxが持っている機能の寄せ集めだし、Gihubなんて本質的にはファイル名に日付を管理するのと変わらない。弊社に関して言うと、AWSなんていってるけど所詮VMだし、弊社はハードウェアレベルでより高い技術を持っている。AI企業は専用AIを個別案件ごとに作っているが、弊社は汎用AIを世界で初めて開発した。でもそれらを積極的に宣伝はしていない。なぜか？それらは単なる手段だから。むしろお客様へのソリューションという形で宣伝していて、結局顧客のビジネスにフォーカスしているんだよね。だからこそ利益が出せ、年収も高いというわけ。なので、再度いうが、本当に顧客が欲しい物を作るということを忘れないでほしい。
プログラミング塾でいわれてるように、東京でまともにフリーランスのウェブエンジニアやってて今の時代に年商1000万以上稼ぐのは簡単だと思った。ちな20代で。（いまは30超えてるけど）
自分はだいたい一月160万円程度の人月単価で何社かと契約して4年ほど仕事した。
他にも単発でいくつか開発したりもして、1年の売上は2500万を超える年もあった
(※こういうとき「所詮年商でしょ笑」とかいわれるけど、webエンジニアなんて物仕入れて売ってるんじゃないから年収とほぼ同じ、色々経費に回せること考えたらむしろ可処分所得は上)
別に自分はスーパースターエンジニアとかではない、普通に仕事こなしてただけ。仕事内容は新規プロダクト開発のメンバーとしてシリーズA以降のベンチャーへの参加が多くてプロジェクトマネージャーみたいなことはしていない
ただ別にプログラミング塾出身とかではない、残念ながら経歴は恵まれているかもしれない
・その後フリーランス、仕事は大学時代の同期やメガベンチャー時代の元同僚から紹介してもらう
恵まれてるかもしれないけど、自分のまわりにはこれくらいの経歴の人何も珍しくなかったから同じような人はだれでも稼げると思う
プログラミング塾出身とかの人がどうなるかはわかんないけど、自分の知り合いは私立文系(高偏差値大学ではない)卒30歳超えてからプログラミングはじめて1年半くらいで今は年収500万くらいもらってるみたいだから順調にいけば同じようにいけるんじゃないかな
仕事もあと5年は途切れる気がしない（その先はわからんけど、まあもう稼いだから多少仕事なくなってもいいかな）のでのらりくらりやっていく
【可視範囲内で見かけたもっともな指摘を受けていくらか補足・訂正】【100ブクマ突破してたのでちょいちょい追記。】
基本的に、イラストレーターさんにとってラノベのイラスト仕事は割に合わない。締切は外道だし、イラストの量も膨大だ。
仮に、ラノベ1冊のイラストを発注するとする。カラーイラストはカバー1枚・口絵3枚（口絵4ページに対して単ページ2枚と見開き1枚）の計4枚、本文中のモノクロ10枚が1セットだろう。カラーイラストに5営業日、モノクロイラスト1枚に1営業日という計算で、最低でも1冊あたり30営業日＝1.5ヶ月分の工数を割いてもらうことになる（厳密にはキャラクターデザインの工数も別途計算しなきゃなのだが、意図的に割愛してます）。
【本職の某氏から指摘を受けて気づいたので補足訂正。ここでの「1営業日」は稿料計算の為に出した仮の日数であり、実際のスケジュール調整の参考にしてはならない。たとえば、カバーイラストの「5営業日」などは「発注から完成まで5日で十分」という意味ではない。現実問題として、一つの仕事に丸々5日間かかりっきりになってもらうのは不可能なので、合間合間に別の仕事をしてもらったり、休み休みで仕事をしてもらうことを前提にすると、最初の発注から納品までどれだけ急ぎでも２週間、最低でも１ヶ月は日数を確保すべきである。個人的には、同人で仕事を依頼するなら、発注→ラフ→線画→仕上げの各プロセスで1ヶ月以上は作業期間を設けて、最初の発注からイラスト納品まで3ヶ月くらいは見ておいた方がいいと思う。それくらい開けないと、プロのイラストレーターさんは同人イラストの仕事を受けてくれない、というか受けられないのではないか。】。
そうなると、本来なら計算上は人月単価1.5ヶ月分の稿料が発生するのが当たり前である。しかし、様々な事情によって、そんな予算はないわけだ。重版かかりまくった作品とかなら稿料もそれなりになるかとは思うが、中々そうはいかない。
それに加えて大量のリテイク地獄（たまにある）、小説原稿の遅延（よくある）、編集の怠慢による発注書の遅れ（もっとある）などが重なり、外道のスケジュールに追い込まれることが多い。結果イラストレーターが地獄を見がち。悲しいけどこれ現実なのよね。商業だと利害関係者が膨大なので、どうしても各種調整により色んな問題が発生しがちである。
一方で、同人誌の原稿になると、別に本を落としても数十万単位での損害は発生しない。多少の融通は聞くはずである。いまから書くのは、増田がイラストレーターさんに仕事をお願いするときに抑えておくべきと考えている、発注時のポイントである。キャラクター発注のコツはぶっちゃけ今でもわからないし増田のやり方が正しかったのか自信もないので割愛し、それより前の基礎的なことだけ書いたつもりだ（増田は以下の内容に加えて「売れるためのデザインや表紙」をディレクションするのが書籍編集の仕事だと考えている）。同人でイラストを発注したいと考えている方々は参考にしていただけるとありがたい。
350dpiの文庫本表紙サイズの4Cイラストを1000円で依頼するのは正気の沙汰ではない……というのは直感的に理解してもらえると思う。時給1000円として1時間で描けるイラストってどんなもんやねん。ただ、その一方で、カラーイラストに対する金額がわからないのも実情ではないか。
この辺りは、「そのイラストを何営業日かけて描いてもらうか」を念頭に考えるのがいいと思う。たとえば、商業イラストレーターさんにイラストを依頼するのであれば、一番安くても人月20万円の仕事（本当に一番安いことを前提です）として、1営業日1万円、前述の通りカラーイラストは1枚につき最低でも5営業日はかかると考えて、5営業日で5万円になる【税金を加味していないという指摘はもっともです。お恥ずかしい。+10％は提示すべきですね…】。
直感的に「高い」と思った方の感覚を否定はしない。金銭感覚は人それぞれだ。だが、それでもイラストレーターさんの仕事としては、月20万円分にしかならないのである。あなたがイラストレーターに敬意を払うならそれくらいの前提は持ってもらいたい。
もし、様々な事情でそれ以下の予算しか用意できないなら、なにかしらの融通をきかせる必要はあるだろう。たとえば、依頼するイラストの構図を一から考えてもらうのか、こちらで事前に指定するのか。キャラクターデザインを「小説の本文を読んでもらって一から考えてもらう」のか「事前に発注書をガッチガチにかためてそのとおりに作ってもらう」のか。
重要なのは、イラストレーターさんの負担を減らすことである。そして、人間は「考える」ことに労力を要するのだ。予算が潤沢ならイラストレーターさんのクリエイティビティを存分に発揮してもらえばいいが、そうでないならできる限りイラストレーターさんの負担を減らしてあげるべきである。
そして、負担を減らすとは、発注における「曖昧さ」をなくすということだ。可能な限り、曖昧な発注はしないようにしよう。
※ただし、そういった「ガッチガチの指定」に近づけば近づくほど、イラストレーターさんは「言われたことをやるだけの存在」に近づかざるをえない。発注者と受注者という関係は本質的にそうなってしまうかもしれないが、それはそれとしてそのことを嫌がる方もいると思う。発注相手がはじめて連絡する相手なのか、関係性のそれなりにある友人なのかで許容可能な曖昧さは変動する。この辺りは臨機応変に考えていただきたい。
ごめん大事なこと書き忘れたけど「文庫本表紙カラーイラスト5万」は【商業で】依頼する金額としてめっっっっっちゃ安いからな！！！！！！！！！！！！！
「5万で頼むのは相手を額面月収20万扱いすることと同義」くらいの意味で書いたんだけど俺が悪かった！！！！すまん！！！！！！！！
あと「平均的な金額を書け」と言う批判も見たが、本当に申し訳ないことに「元」なので自分のいたところ以外の金額相場を知らんのだ……。
「商業であれば許されない金額で同人のイラスト発注できるのには理由がある。相手の趣味とかスケジュールとか工数の簡略化とか」という話です。特に商業イラストだとせっかく描いてくだすったイラストを、様々な理由によって（時には相手の感性を否定するかたちで）リテイクせざるをえないことが多くて、そういったことを込みで考えると稿料はもっと高くてしかるべきなのだ。
これは絶対だ。
たとえば、「イラストを1枚お願いしたい」とだけお願いしてあとからイラストの点数を増やすのは一番最悪なパターンだ。最低でも、
は全部伝えること。
どちらにとっても不幸なことは「聞いてない！」の発生だ。
といった、いくつかの発注レイヤーを設けておくのが望ましい。柔軟性のレイヤーを設けておかないと、前述のとおりイラストレーターさんを「言われたとおりに描いてもらう存在」として扱うことに繋がりかねない。また、「絶対に変わらない発注要件」を明示しておかないと、イラストレーターさんが仕事に関する予測可能性を確保できない。たとえば、リテイクに関する同意はとりつけておいた方がいい。「リテイクは１回まで」「リテイクを出すときは２４時間以内に出す」など。そういった取り決めを設けた上で、取り決めをこちらが破った場合は追加予算を払うといったルールを設ける。
前述の予算の問題にも絡むが、あんまり予算が出せないときは「リテイクは絶対に出さない（〇回まで）」といったルールを設け、イラストレーターさんの不安を最小限に抑えるといった心遣いは重要だと思う【ちなみに、実際にラノベイラストを発注したときに「リテイクを出さない」という約束を設けたことは一度もない。あとリテイク費用を出せたこともない。リテイク云々は「最悪利益が出なくてもいい非商業発注」だからこそ簡単に取り決められる話だと認識している】。
大変失礼ながら、同人小説の原稿は多かれ少なかれ「読みづらい」。本文をイラストレーターさんに読ませることを強要してはならない。その前提でいるべきである。本文をそのまま送りつけて「この話のこのキャラクターを」とお願いするのはもっての他である。イラストなしの長編小説からキャラクターの外見描写を抜き出す作業を想像してみてほしい。むっちゃくちゃめんどくさい。
くらいは事前にこちらから提示したい。なお、これは「原稿を送ってはならない」という意味ではない。作品の雰囲気がわからないのにイラストを描いてもらうの大変なので。小説原稿を送った上でちゃんとイラストの指定をまとめておくこと。
この辺りはキャラクター発注書の作り方に踏み込むからそろそろやめておくが（飽きてきたとも言う）、文章で全て書く必要はない。「こういうイメージで」とGoogleで拾った画像を投げるだけでも随分違う。
【追記】
肝心なことを書き忘れていたが、そもそもの前提として
こういった諸々をいきなり提示したからといって、それだけで先方が楽になるとは限らない。相手にも相手の事情があるからだ。
相手が商業デビューしたイラストレーターさんなら、相手のスケジュールを必ず確認しよう。別に「相手が締め切りを破るの前提に考えるべき」と言っているのではない。商業仕事の締め切りと、同人仕事の締め切りが重なった場合、当たり前だがイラストレーターさんは商業仕事を優先するに決まっているのだ。イラストレーターさんが商業作家だったり、あるいは商業での仕事が降ってきかけている方だったりする場合は、そのスケジュールを可能な限り把握して、その上で「商業を優先した場合の同人スケジュール」を逆算すべきなのである。
【追記】
「普段その人が描きなれてないものを依頼するなら工数を多く見積もるべき」みたいな話もあるがこれも割愛している。これ以上細かい話になるとボロが出るので。
これをしない人がものすごく多いが、上記のようなスケジュールを計算をガチガチにやっても、スケジュールは、絶対に、遅延する。
同人イラストでリテイクや修正を出す事例はどれほどあるかわからないが、たとえばスケジュールの中に修正対応の期間を計算に入れているだろうか。同人誌だったら多少は余裕を持たせられるはずだ。冬コミのイラストを仮にお願いするとしたら、仮に11月中旬が最終締め切りだとして、あちらこちらにマージンを設定して提示する締日は10月中旬くらいにすべきである。
諸々書き殴らせてもらった。思いついたり批判を受けたりしたら適宜追記・修正する。
なお、これらは失敗から学んだことであり、書き手の増田がそのように振る舞っていたことを意味しない。つまり本投稿は過去に仕事をしたイラストレーターさんへの贖罪の意味合いが強い。皆さんは増田のような失敗をしないでいただけるとさいわいだ。
anond:20170413064206 を4月に書いた。匿名ダイアリーで書いた日記としては、反響をいっぱい頂いた。耳に痛い意見もあったし、励ましや慰め、感謝の言葉も頂いた。
今年の仕事も終わったので、あの記事が結局どうなったのかはまとめておこうと思う。
1. SIerへの思い
元の日記へのコメントでは発注者側の無知が二次、三次請を地獄に落とすことについて指摘があったので、それも併せて。
・人月など意味がないことについて自分の中で割り切ったので、社内への説明では適当な人月をでっちあげることにした
社内で通りそうな人月単価はもうわかった。だから、うちの希望納期が通るかどうかだけ聞いておいて、通りそうな単価で割り算するだけにした。
そんなに人数必要か？ と突っ込まれた時には「必要でしょうね。だって、あなただったらプログラムからテストまで、一人でできますか？」と言い返すことにした。
これを続けた結果、人月について突っ込まれることはなくなった。
・納期についてはメーカの意見を最大限採用している（これは前からだが）
納期遅れだけはまずいな、と思っていたから可能な納期については昔からメーカからの提示を採用してきた。最近は3か月くらいはプラスしておくことにしている。
「短くならないの？」という問いについては「無理ですね。そもそもこの機能が必要なら、もっと早く相談するべきだったでしょう？」と返している。
これを続けた結果、逆にこっちでスケジュールを作れるようになった。
また、納期をプラス3か月することで人月計算に余裕があるから、通りそうな単価に近づけられるようにもなった。もっと早くにやっておけばよかった。
交渉するけど、基本的には保守費を下げてもらえる条件などほとんどない。さてどうするかはこれから考えようと思う。実の支払金額を下げろと言われたけど、下がらなかったら仕方ないよね、と割り切っている。そもそも保守費をけずるのは私の本意ではない。
2. 偉い人への思い
・どうでもええわ、の精神
4月13日のあの日記の後、上期・下期の人事評価がなされた。評価は大してあがりもしなかった。どちらも6段階評価の3。
昇格の条件で考えれば、2年間・4回の人事評価でコンスタントに4を取り続け、上期評価後に部門長に審査されなければならない。
つまり、この先2年は昇格しないことがわかっている。この4年ずっとそうだったから、もう昇進・昇格は期待していない。
どれだけ頑張っても評価など上りもしないのだから、社内の意向を気にすることもやめた。
何もかもどうでもええわ、それよりは自分のやりやすい方法をとろう、と決めた。
・システム開発における工数単価の比較はバカへの説明に楽なので、使い続けている。
上でも書いたけど、工数単価をコントロールしているから理解のできない上司や偉い人への説明に苦労することは少なくなった。機能面を理解させるのも一苦労だが、バカにもわかるように擬人化させて説明することが増えた。
例:このデータをなげないと、システム側は「データが来ていなくて処理できませーん」って言うんですよー。
・システムの機能追加や保守ができるのは、そのメーカだけだよ→でも、似たような機能は自分らで作るよ。
システムについて理解できない偉い人らに連れられて、メーカの人を何度も呼んで打合せするかわりに、こっちが作った仕様の説明と実装するのにいくらかかるのか？ を問うだけの打合せを一度だけすることにした。あとは全部私とやりとりしてもらっている。
また、金額に折り合いがつかないから、別のメーカに代替機能をつくってもらうことにしたものもある。
ソースコートは開示できない。だから、代わりに私が必要となる機能の仕様を実装手前まで作って、コーディングをお願いする手口をとることにした。
上でも書いたが、どうでもええわと割り切っているので、多少問題があってもいい。実装手前までの仕様策定を私がやったのだから、それに従ったメーカは私が守るだけのこと。
場合によっては自分でも作ることにした。その代わり残業時間が増えたけど（後述）。
・「実際そういうやり口で、うちの仕事を受けてくれなくなった業者があったと聞くぞ。又それを繰り返すのか？」
繰り返している。前はそうならないように配慮していた。しかし、下っ端の私らが配慮しても、開発・工事の現場を担当したことがない者(大概は課長以上)の行動で業者を困らせつづけた。
もうリカバリーできない。業者からは不平不満がでており、この案件が終ったら、二度とうちの案件はうけないと言う会社もあるようだ。
バカに役職を与えたのは会社なのだから、そのツケは会社が払うしかない。
金銭面というよりも、ある種の機材を技術面/運用面/コスト面から否定した結果、その機材を使うことで微々たるイメージアップができると思っていた偉い人にとって不満だったようだ。2ヶ月遅れたが、引き戻しをさせられた稟議案件は完工した。
その機材は別の工事担当者の案件で導入することになった。すでに私が指摘していた問題点が露呈している。
偉い人にとっては何のダメージもないだろうけど、導入させられた部署の不満は高まっている。バカの下で働くのは大変だな、と思っている。
3.個人的な話。
・評価もされない
上でも書いたとおり、評価されないのはもう諦めたのでいい。理解できないものを評価できるわけもないし、そもそも理解しようという気もないのだろう。
・ユーザからは「使いにくい」と文句を言われて、上からは「よく考えたのか」と怒られる。誰がそんな仕事に喜びを感じる？
未だに喜びは感じていない。しかし、辛いと思わなくてもいいように働く方法がわかってきた。
使いにくい、と文句をいわれても「どうせシステムなど、お金を生まないと思われていて、予算がでないからしかたないよね」と答えている。
その上で改善の検討はするが、お金がでないのだからできることには限りがある。
自作のソフトでなんとかできそうなところはそれでカバーすることにした。
・内作を許容することにした。
ここまでで、予算が通らない分で小規模なものは自作することにした、と書いてきた。
以前ならば、自分が退職するまえに死んだりしたら内作したソフトのメンテができるひとが居なくなるので、極力メーカに作ってもらおうとしてきた。
そもそも、内作のメンテが大変なこと、開発者が死んだり会社に来られなくなったときの対応を考えておかないとならないことはずっと説明してきたし、退職者が好き勝手につくったソフトのメンテで苦しんでいる部署が社内にある。だからメーカに任せましょうという説明をしてきた。
内作を提案したとき、メンテ担当者をふやすことも依頼したが特に増やされる様子もない。
それは会社の考えかたなので、どうでもいいと割り切った。私が死んだ後のことなど知ったことではない。
一番大きく変ったのはここだと思う。残念ながらかかわっている案件全体が炎上しつつあり、残業時間がそのまま勉強時間にはなっていないが、内作をしつつ興味のある言語の勉強をすることにした。
それについて「家で勉強するべきではないか？」などとのツッコミはない。どうせ理解できていないのだろう。
もし文句をつけられたとしても、こっちには「内作で数百～数千万を浮かすんだから、内作に必要な学習時間は業務として認めろ」といいきる度胸がついた。
それで上司の評価が厳しくなっても「どうでもええわ」、もとより評価されていなかったのだから。
ちなみに残業時間がどんどこ増えた。体はだるいし、ストレスチェックの結果2年連続で産業医やカウンセラーとの面談を推奨する手紙をもらった。36協定上の制限時間などもブッチすることがあるが、それについて文句をいわれても「どうせ人がいないのだから仕方ないだろう？ 文句あるなら仕様の策定もできるような人材を確保するか、メーカに頼んで数千万はらえ」と言い切った。
開き直ると楽だとわかった。
・今の部署を離れるか、システム以外の仕事をするために勉強することにした。
実は法律に興味がでてきた。そこで行政書士の試験をうけた。新しい分野を勉強するのはたのしい、合格していればうれしい。
また、本社のシステム担当者に「本社でシステムをやらせてほしい」とお願いした。今の部署から離れられるなら嬉しい。バカな上司の下はもううんざりである。
一杯ブコメをいただいた。皆様ありがとう。特に気になったコメントは次のとおり。
「id:luccafort これに少しだけ似た経験を若い頃にさせてもらった。その時言われたことが「なんでそんなに彼らの肩を持つの？」だったので根本の考え方や感じ方に断絶を感じて絶望した。増田はすごいよ。」
→私も言われました。「なんで業者の味方するんだよ」と。あー、そういう風におもってるんだ、と理解した瞬間にもうええわ、と切り変わりました。そこから上記のとおりです。
「id:celaeno_w インフラのありがたさは、一回サーバー落ちて、保守費用なんかと桁が違う損害出すと分かるんだけれどな。こういうのは、「格安バスツアー」とか、「格安海外旅行」と一緒よ。後悔した時には遅い。 」
→そうですね。ですから、保守稟議にはそういう話を書いてきました。停止からの復旧時間、その間に指図できなかったロットの機会損失などなど。1日とまれば保守費など比較にならん損失がでるよ、と。
でもそれでもけちりたいようなので、もういいのです。一回地獄をみればいいんですよ。
「id:otihateten3510 “評価もされない、新しい技術も身につかない。ユーザからは「使いにくい」と文句を言われて、上からは「よく考えたのか」と怒られる。誰がそんな仕事に喜びを感じる？” 至言。問題はなぜ全員辞めないのかという点 」
「id:su_zu_ki_1010 転職おすすめされても、その方の年齢とかスキル（新しい技術も身につかないとぼやいておられる）もあるので難しい場合もありそう。部署異動で無縁のところに行くのを希望するという手もあるのではないか。 」
→無職が怖い、この一言です。部署移動はこの6年間、評価毎に話ししていますが希望は通りませんでした。今は他部署から是非貰いしてもらえるようにアピールしています。
趣味でプログラミングはやってたけど、なぜか３０越える今になるまでそれを仕事にしようとしたことはなかった。
ネット上でいろいろなIT業界関連の恐ろしい情報が飛び交っていたし、ビビッていたのもあったと思う。
でもこのままだと人生詰んじゃうなーと思って、とにかく実際の業務を知るべきだろうと思って飛び込んでみた。
本当はWeb系の会社で働いてみたかったけど、汚しまくった経歴と、その当時の金欠ゆえに、その選択はかなわなかった。
ネットでよくみる、「経歴が山のように盛られて、研修終わったら気付いたら実務経験○年のエンジニアになっていた」（これ普通に詐欺だと思う）とか、「FizzBuzzすら解けない人がプログラマーやってる」とか
どうせ業界の人たちが冗談で大分脚色して書いてるんでしょ？って思ってたことが、現実にあるということを知った。本当に信じられないが。
もちろん、全員が全員酷いというわけじゃなくて、ちゃんとしてる人もいるけどね。
1個目は中小SIerという人月単価で人を送り込んで金を得るという、実質は人材派遣会社みたいな仕組みなんだけど、何でこんなに横行してるんだろう？
プログラミングの作ったプログラムはほぼノーコストで複製可能であるっていう点と、そのプログラムが何をしているかというと、自分がやらなければいけない仕事の自動化で
人がやるべきことをコンピューターがやること（もしくはコンピューターのその圧倒的な処理の早さによって実現できる人間にはちょっと無理なこと）によって、利益を生むんだと思ってたけど、
その利益の源泉となりうる「プログラムが書ける人」を自社で利益を作るためのサービスに使わないで人に貸して金取るっていうのは、戦略的に間違ってるんじゃないかなと思うんだよね。
その点Webサービスやってる会社とかは、最初の立ち上げの時にはリスクがあるとは思うものの、よく自分達の持ってる武器の性質を理解しているように見える。
2個目はSEという仕事とPGという仕事が何故分かれているのかがわからない。
俺が素人なりに独学でやってきた感覚では、コーディングと設計って切っても切り離せないものであって、設計をする人がSE、コード書く人がPGってのは感覚的に物凄い違和感がある。
なんでこのSEって言葉ができたかっていうと「単価」を高くするために誰かが作り出した言葉にしか思えないんだよね。
もしくは、このウォーターフォール開発っていう方式の中で、分業するときの名前ってことで作り出されたのかもしれない。
けどこのウォーターフォール開発ってのも、あんまりピンとこないんだけどね。無茶言うなっていうやりかたな気がしてる。
趣味でプログラミングやってるっていうことが結構役に立つということを知ったこと。
所詮自分のやってたことは独学遊んでる程度で、クソの役にも立たないものだと勝手に思い込んでたけど、全然そんなことなかった。
今もまだ知りたいことは山ほどあるし、趣味を継続してやっていく価値は非常に高いんだということを知れたのはよかった。
あと、実際に働いてみて「これはもっと改良できるよな」とか「これは自動化できるよな」とか「これはもっといい意思疎通の方法があるよな」っていう反面教師みたいなのもたくさん知れた。
下っ端なりに、提案はしてみて、却下されたら素直に引っ込んでるけど。一緒に作業してるのお客さんだしね。
上にあがったらマネジメントやって、どうこうみたいな話しか聞かないんだよな。
そっちのほうが「単価」が高いからなんだろうけどね。
■背景と問題点
SI業界におけるシステム開発のプロジェクトでは、ソフトウェアの品質が問題になることが多い。
問題点は、知識不足や経験不足な人間が大量に放り込まれたプロジェクトでは低品質なクソコード（※1）を大量生産してしまう事にある。
※1：クソコードとは、可読性の低さ、保守性の低さ、コーディング規約違反、テストが不十分、静的解析の指摘結果が多い、命名の悪さなどが該当するコードである。
■解決方法
真っ先に思いつく品質向上手段としては、レビュー、指導（教育）が考えられると思う。ただ、コストがかかり浸透するまでに時間がかかるのが欠点だ。
そこで、人間の感性に訴える「羞恥心」をうまく利用する方法はどうだろうか？
クソコードの基準を作り、基準に満たないソースコードをコミットした人物を徹底的に「晒す」ことで、
危機意識が高まり、クソコードをコミットする前に見直しする結果、品質が上がると考える。
「晒す」とは、クソコードをコミットした人物の所属会社名と所属プロジェクトと氏名を館内放送するなどプロジェクトメンバーが一目瞭然で分かる公知の事実にすることである。
月末にクソコードコミットワーストランキングを作成し、食堂、トイレ、休憩スペースなどの目に付くあらゆる場所に掲示することで危機意識が生まれるだろう。
人月単価交渉の際にも基準値に満たない数値が出ていることを示すことで、具体的な根拠を持った単価の切り下げ交渉も可能だろう。
朝会・夕会があるのであれば、クソコード作成者を読み上げて周知の事実とするべきだろう。
請け負った会社単位でのクソコードコミットワーストランキングも作成し、会社ぐるみでの取り組みも強化させることで品質が向上するだろう。
■まとめ
プロジェクトメンバの意識が「クソコードをコミットすると恥をかく」を徹底させ、
きちんとしたものを作らなければならないという意識を芽生えさせる事が一番重要である。
ソフトウェアは目に見えないものなので、品質が分かりにくいが、
物作りの現場だとクソな部品を渡されれば次の工程の人間が困るのは目に見えている。
物作りの現場では、誰が不良品を作ったか？を特定されて、詰められるのは当たり前だろう。
だが、ソフトウェアの現場では未だそれを見ない。そろそろやっても良いのではないか？
読者の皆様はいかが考えるだろうか？
