「改修案」を含む日記 RSS

はてなキーワード: 改修案とは

2024-05-03

IT土方仕事ストレスを感じるとき

曖昧な指示をされたときコミュニケーションコストストレス

量が多く期限も短いとき残業前提で仕事

納期が短いのにタスクの切り方がざっくりしすぎてるとき(終わらないよ)

修正仕事設計書が更新されてなくて、コードを見たらスパゲッティコードで読み解くのが難解だったとき(読み解くのに脳みそが焼ききれて鬱になるよ)

修正対象としたけど、その機能の使い方が誰もわからなくて、あとから今はもう使われてない機能から対象外としていいと後で言われたとき(消せやそんな機能紛らわしい)

不機嫌なオーラが漂ってる現場アサインされたとき

用語をググっても出てこない業界の基幹システム改修案件のとき

隣の人がタバコ臭とき

オフィスがうるさいとき

ウンコしたいのに個室が空いてなくてウンコ行列が出来てるとき

定時後は45分休憩時間現場だったとき作業してたから、45分の労働として残業代つけていいか聞いても駄目だと言われたとき

言われてないからやらなかったら気を利かせろと言われたとき(言われてないこと気を利かせてやったら怒るくせに)

IT土方以外の仕事につく未来が見えないとき

2023-01-12

anond:20230112222723

--

漠然としてるなあ

SIer寄りかWeb寄りかどっち?

バックエンドフロントエンドインフラネットワークテストPM経験したいってこと?

--

説明があれですまん。バックエンドで色んな現場行きたいなぐらいだったわ。SIよりがいい。

--

福岡だけなので選択肢は少ないだろうなあ

--

地域もネックか。。。

--

もうちょい詳しく書こうや

--

主にやってたのが求人システム保守改修案件だったわ。 規模は小さい。1人か2人。他の案件でも多く5人。コード管理svnメインだったな。

ドキュメントがないレガシーな他社システムリバースしての改修が殆どPHPは生のものをずっと触ってた。フレームワークは使ってない。JavaScriptはちょこちょこした修正くらいでしか触ってないな。

データベースSQLが書けます読めますデータ設計ができます程度。

(うわー技術力が低くて書くのが恥ずかしい)

2021-01-13

anond:20210113011527

結構思い切ったねー。まあそれはともかくまだ8か月でしょ?これからだよ。

実際に商用で運用して障害が発生した時にシステムがどう動けばユーザは次のアクションができるか、致命的なエラーにならないためにはどういう順序でどういう情報を残すかとか、改修案件をチョロで対応するにはどういう設計にすべきかとか、作った後でも簡単に手を入れられる部分と商用稼働してからだと手を入れずらい部分の判別だったり、リリースした後に実際に使われる中でのフィードバックから学ぶことって結構あると思うよ。

あと、ERPパッケージを触ってみるのがおススメ。ソースを見るというよりは各種マスタの設定をして触ってみる。多種多様顧客ニーズに対してプログラム改修なしにマスタテーブルの設定値変更で対応出来るよう工夫して作られているので、設計の参考になると思う。

見積顧客に突っ込まれるの面倒くさいな、後になって仕様変更対応するの面倒くさいな、障害報告面倒くさいな...etcの面倒くさいを省くためにどうすれば良いか改善点を日々考えていくことがエンジニアとしてのスキルの向上につながるんじゃないかな。

と、色々と偉そうに書いたけど同年代チャレンジ勇気づけられたよ。お互い頑張ろう!

2020-03-12

Qiitaのどうでもいい変更見てて俺が昔書いた増田思い出した

デザイナーを雇うな

https://anond.hatelabo.jp/20180928030012

この前はどうでもいいロゴ変更、からのどうでもいいUI変更。

しかしたらデザイナーじゃなくて、「事業戦略部」とかそんな名前の、BIツール眺めながら誰も求めてない改修案を押し通してくる奴らかもしれない。

とにかくQiitaはそういうフェーズに入ったってことだ。

この手のどうでもいい改修を連発するようになった企業に言いたい。

軌道に乗ったら余剰人員を切れ。

ユーザーは使い慣れた80点を見慣れない90点に改修されることなんて求めてない。

2020-02-02

anond:20200202132358

日本全体が不況新規設備投資消極的なので、既存システム改修案件が圧倒的に多いので、

レベル設計スキルを磨く機会がそもそもないのでエンジニアレベルが低い

これはエンジニア個々の問題ではないし、

プログラミング教育問題でもないし、

よく言われるような日本企業の体質の問題でもない

そもそも設備投資しても儲からない世の中なのだから

経営者保守的なのも合理的選択

この状況を変えられるのは国だけだ

2019-09-27

カスタマイズ案件の闇

一般的プログラミングと言えばいかプログラムを作るかの話だと思う

データベースがどうたらとか言語はどれがどうだだとかログインはどうだだとかデザインコーディングがとか

でも改修案件、カスタマイズ案件はそういう知識がもう役に立たなすぎてゴミ

「新たに作る」のなら自前でやればいいから楽なんだよ

でも「誰かが作った、自前フレームワークの上に乗っかったメジャーフレームワーク2つを使った、専用のからくりプログラム」とかだったら意味からないよ

どこかをいじったらバリデーションがバグり、その謎フレームワークルールに則らないとajaxうまくされなかったり、少しその自前の画面でやってないことをやろうとすると急に無理ゲーになる

意味からないフレームワークを使わないで!!!意味からないフレームワークを作らないで!!!

2019-01-03

プログラミングが必修化されると

クライアントが作った)アプリにこの機能つけて欲しいんだけど~って言われて

うーんちょっとこれはイチからうちが作った方がいいですわ(ゼロ~イチくらいは流用する)

って案件が増えそうだなと思うけど

俺はプログラミングほぼ独学だし必修教育を受けたクライアントの方がキッチリキチキチに書いて来たりするようになるんだろうか

(だから俺が組みなおしても次他所に持って行かれたら同じようにうーんこれはイチからうちがって言われるかもしれない)

増田がもし外部ソフト改修案件受けることがあったらイチから作るつもりの見積もり出しておけよ

高すぎてその仕事が取れなくても別の仕事があるやろ多分

2018-11-18

SIer若いSEがまるで老害のようだった

全然難しくないシステム改修案件。

お客さんとこで動いてる古い社内システム商品売上関連のTSVファイル毎日吐き出される→それを新しく使う事になったCRMからチェックできるS3バケットへ入れて欲しい、というだけ。

ファイルサイズも大きくないかLambda使ってバケットへ入れられるよ、1日1回だしそっちのほうが安上がりだよ、って提案したのに。

そのお客さんと長い付き合いがあるSIer若いSEさんがLambdaわからんとかでSIer系列サーバサービス会社仮装サーバセットアップしてcronでバッチ動かす事になりましたよ。

俺より若いのに老害すぎるよ。

2018-11-16

Web関係者様方への感謝

あなたは,2018年において新規立ち上げや改修案件で経済に大いに貢献されました.

予算の都合,仕様要件の食い違い,システムトラブル,度重なる修正,その他多大なる困難を解決してコンバージョンを上げました.

世の中の経済活動が円滑に進んでいるのは皆様のおかげです.

よってここにその功績をたたえ深く感謝の意を表します.

関係者一同.

2018-11-09

自分天才だなと思ったこ

連携先の設定が変わり、急遽プログラムを変更しないといけない事態になったんだけど

担当SEに話をしたら「その改修には1ヶ月かかります」と言われて難色を示された。

「どうしてですか?」

と思わず言ってしまって、さらにその後にこうやって改修すればいいと思うんですけど。

改修案が口をついて出てきた。

それが改修2時間テスト工数も激減の妙案だった。

「どうしてですか?」と聞いた時点ではそんな事考えてもいなかったんだけど、脳を介さずなんかすげー庵を出してしまった。

こういう工数削減TIPSを閃かせたら天才かもしれない。

2018-08-28

anond:20180828160234

言語によってはswitchswitchが使いづらい場合は極力ifだけみたいな感じ

 

func hoge {

 if (条件a) {

  処理a

  return

 }

 if (条件b) {

  処理b

  return

 }

 if (条件c) {

  処理c

  return

 }

 if (条件d) {

  処理d

  return

 }

 // ここに到達しないことを確認

}

 

1ブロックだけ見れば基本修正できる状態を保つ(独立した状態

else if一切使わないわけではないし、重複した条件が続く場合は工夫するけど

else ifが10個繋がるシーンとかは避ける

改修案件でちょいちょい見かけて訳わからなくなって死ぬ、影響範囲広すぎ

 

__

 

すまん上記変だな

returnが余計だが、return抜いても独立してるように見えない

2018-04-28

ステップ

数年前に開発会社から全く別業界システム部門に入り、受注者から発注者立場が変わったので良い発注者になろうと頑張ってきたつもりなんだけど

日中途で入ってきた同僚が、長く付き合いのある開発会社に「改修案件の見積もり根拠が分からないので改修対象ステップ数とソース数を出せ」とか言い出して、それを止めようとした自分喧嘩になった、しかも「改修見積もりをしたのならステップ数は当然すぐに出せるはずだ」と言いながら

そいつは以前にも「単体テストの結果も全て説明付きの画面キャプチャエビデンスとしてつけろ。これは当然の事で、テストをしたのなら作っているはず。だから追加工数も払わない」と言い出してこれも喧嘩になった


残念ながらうちのシステム部門は専門の人材がいない為、こいつの言うことのおかしさを理解してもらえない

「規模を知るためにソース数を貰うのは当然の事です」とか言い出して、それをまわりが真に受けてしま

いくら自分反論しても1対1の話なので「やり方は色々あるからね」と窘められてしま

さらに本人には少し反論すると絶対に認めずかなり攻撃的に返されるという厄介さ

感じた事の無いレベルストレスを感じています。助けて…

良かったら対処案とか下さい…連休けが憂鬱だ…

2016-11-18

http://anond.hatelabo.jp/20161118215013

第一に、やはりマークアップ記述するコストが非常に大きいように思える。

元々HTMLが書けない素人向けの仕組みだぞ。Wikipediaでもゲーム攻略Wikiでも素人が覚えて編集してるのに技術者が何言ってんだ。

第二に、保守以降、一つのシステム複数改修案件や故障対応が並行するようなことはままあることだが、ソースSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である

案件ごとに設計書分けたり、後でマージしたりは、どっちにしろ面倒だと思うけど。

デメリットで思いつくのは、Wikiソフトウェアは廃れる可能性がある、かな。

メンバー設計書をwikiで書きましょうって提案された

私はソフトウェア製造業で十年近く働いているが設計書と言えばExcelまたはWordだった。

UMLなどの作図にツール使用することはあっても、最終納品物としてはExcel画像として張り付けて提出していた。

もちろんExcel方眼紙については批判もあるのは理解しているが、開発者運用者、顧客など関係者すべてが手間なく簡単に読めることを条件とすると、やはりExcelに落ち着いてしまう。

 

そんな私に表題のようなことを提案されたわけだが、最初何を言っているのかわからなかった。

設計書と言えばExcelという私には設計書をwikiで書くという発想がみじんもなかったからだ。

開発者運用者、顧客のだれでも手間なく容易に読めるという条件はwikiでもかなえられることに気付いたが、私にはwiki知識ほとんどない。

 

彼に詳しく聞いてみると、前に参画していたプロジェクトでは社内サーバに建てたwiki用語集として活用していたそうだ。

wikiには顧客業務専門用語などを記載して、製造工程以降に参画してくるメンバーとの情報共有のツールとして使用していたらしい。

そういった運用をしているうちに彼はwiki自体設計書とできないか考え、調査したところ実際にwiki設計書として使用している会社もあるようだということで、今回提案に踏み切ったらしい。

 

私も今調べてみたところwiki設計書を書くという運用をしている会社もあるようだが、メリットデメリットwiki知識があまりない私には判断しかねている。

ぱっと思いつくデメリットとしては、第一に、やはりマークアップ記述するコストが非常に大きいように思える。

記述する手間だけでなく、記述するスキルを手に入れるためのコストも考えると無視できないコスト必要となるように思える。

第二に、保守以降、一つのシステム複数改修案件や故障対応が並行するようなことはままあることだが、ソースSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である

 

メリットとしては、リンク機能で各設計書間を容易に行き来できることが第一に挙げられる。

第二に、改訂履歴差分が標準で用意されていることもメリットであろう。

第三に、検索が容易であることがあげられる。この点はExcel比較して十分大きなメリットだと思っている。

 

私がぱっと思いつく限りではこんなもんである

はてな諸兄の中にwiki設計書を書いたことがある方がいれば、メリットデメリット、その他運用において気をつけるべきことなどあればご助言願いたい。

 

なお、今回の案件は数万LOCの小規模な、VBからWEBアプリへの置き換え案件であり、顧客から設計書の決まった書式などは指定されていない。

そのため自社の標準の設計テンプレート使用する予定だった。もちろんExcelである

 

また、設計作成使用するツールExcelWord以外の素晴らしいツールがあれば教えていただきたい。

どうかよろしくお頼み申し上げ候。

2016-01-23

SIはやめておけ

20代の数年間SIで働いた。1年以上前退職して今は別業界にいる。

今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくり暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。

一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。

以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。

工数至上主義

受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積おかしくても顧客と対等な関係が築けていないから追加請求もできない。時間(工数)をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。

まり、どう頑張っても売上は同じなのだから、良いもの価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。

これが諸問題の根源で、いかに述べるような組織プロジェクトが出来上がっていく。

作業効率化しない

マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。

私は定型作業効率化しようとjsやrubyスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。

あるとき上司に肩越しに自分作業を覗かれて「何やってるの?」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの?工数に乗ってないよね?」「スクリプトテストもちゃんとしないと結果が正しいって保証できなくない?」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分作業工数内で完結する。むしろ工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず(読めないので)1時間無駄にした。

技術力いらない

前述したようなビジネスモデルから営業力と、予定工数で無難プロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者人材派遣系の企業や下請けにいっぱいいるから。

社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術=技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。

そういう人が集まっているor残っている組織なので開発者ほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム部長お気に入り課長になり、部門長のお気に入り部長になる。その繰り返し。

開発案件でのBP(ビジネスパートナー委託先、派遣下請け比率自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い=マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。

私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。

意識の低い開発者メンバー

上述の通り、案件で接する開発者基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。

まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度(この場合顧客は私が所属する企業)、請負場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズド世界で生きている。

そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルール説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステム課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループ疲弊の一因だ。

static BP

ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパー技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。

だが、拍子抜けした。あまりにも仕事が雑なのだコミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分ブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。

また、彼はJavaの有名なフレームワークであるStruts拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークバージョンを上げると壊れるというのが残念な点で負債になりかけていた。

私は異動したが、彼は今でもそこにいると聞いた。

技術の話

テストコード書けない

(最低限のものしか作らないから)安くて早い!という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何?」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの?』って問われるから絶対言うなよ」と拒否された。

保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。

リファクタできない

先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコード顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。

レビューない

私がいたどの案件にもコードレビューがなかった。リーダー開発者数人という構成場合、まず開発者は全員下請けリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステム挙動実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解齟齬が頻発していた。特に入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。

そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。

新規技術試せない

無難プロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業マネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術(言語フレームワーク)がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらラッキーぐらいの考えでいる。

常に横に倣えのアーキテクチャは私にとって面白くはなかった。

横に倣え

また横に倣えが加速してさらに悪い事に、同じアーキテクチャネットワーク再利用するために既存のサーバに新システム相乗りすればよいという発想も珍しくない。「資産再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックオンプレミスサーバ上で複数アプリケーションサーバ運用した結果、予想通り耐障害性が下がった。

また、Oracleライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システム共倒れになったこともあったがOracleのバグとして報告していた。

static Perlおじさん

新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。

まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか?」と聞いたら「Perlクラスなんて必要ない。構造プログラミング研修でならってないのか」と返ってきた。「俺が前に書いたPerlバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。

また、そのプロジェクトのメイン言語Javaで、Eclipseを使っていたのでPerlプラグインを入れてコーディングデバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグイン品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタしろと言っただろ!」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。

待遇・制度

給与

SI業界の中では高いのかもしれないが決してよくはない。4年目(たぶん25歳)ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。

個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。

マシン

会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者基本的デスクトップ使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。

組織問題

とにかくクローズド組織

つの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから

情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメール添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダ権限を持った人間しか見られない。何で他の部や課が行った過去の見積提案資料自由に見られないんだよ。

ソースコードリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。

会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。

意思決定の遅さ

どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクト利害関係者ならまだわかるものの、まったく関わっていない上長(課長部長、時には部門長)を通さないと進まないという異常さ。

コスト削減

利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自ノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員デスクトップを使っている。ITとは。

本当に無駄しか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員派遣で雇うべきという提案が何度もされたが、課の予算オーバーするから無理だという回答しか返ってこない。

残業削減

表向きは社員健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システム監視し、削減できていない組織や人間評価を下げるようになった。

その結果、サービス残業が復活した。30時間を超えると部長説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員残業時間を管理するとかい無駄な仕事を増やしたし、管理される社員ストレスサービス残業に繋がったので下策だと思う。

他人残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。

そもそも無駄作業や工数至上主義作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。

辞め方

 
ログイン ユーザー登録
ようこそ ゲスト さん