  |
はてなキーワード: パッケージソフトとは
元々そこそこ高給だけど激務のソフトハウスでパッケージソフトの開発してたんだけど
その後、精神状態も落ち着いてきたので地元の物流会社に再就職したのね。
面接のときに前職の話とかもちゃんとして、その上で肉体労働で給料が安くてもいい
って話でまとまって、もう５年くらい働いてたんだけど、
いろいろ人が入れ替わって中途で入ってきた常務がこれからの時代はIT化だ！とか言い出して
いや時代100周は遅れとるやろって感じなんだけど、
俺の前職からお前社内SEやれって言い出して、最初は断ったんだけど
どうしても断れなさそうな感じだったからだったらせめて給料を上げろって要求したら
５年サボってた俺のスキルが今のソフトウェア開発業界においてどのレベルかはともかく、
それでも俺と同等クラスの会社に勤めてた奴を中途で取ったら月給は今の俺の1.7倍はあると思うの。
それは俺が代替可能なパーツとしての肉体労働職(バイトの管理とかもしてるけど)でしかないからで、
前の職場と同じ仕事をやらせるってんだったら、見合った待遇よこせよっていうのってそんなおかしいかな？
| タイトル | 記者 | 日付 | 乳首数 | 個人的抜粋引用 |
|---|---|---|---|---|
| 『スーパーマリオ オデッセイ』はシリーズ史上初の「CERO B（12才以上対象）」タイトルとして発売へ | Ayuo Kawase | 17-09-19 | 1 | 国内外で話題となった「マリオの乳首」を理由としてあげているが |
| 性的表現を“売り”にするゲームがまたもSteamで規制、『Strangers in a Strange Land』が無修正化パッチを外部サイトで配布開始 | Taijiro Yamanaka | 17-09-05 | 1 | のように女性の乳首が露出しているものもある。ただ両者の違いは明確で、 |
| 『Missileman』にハマっております。『ファイナルファンタジーXIII-2』始めました。『Conan』再開しました。それぞれの今週のゲーミング | AUTOMATON JP | 17-02-05 | 3 | 『Age of Conan』といえば乳首問題でしょうか。乳首の描写がなくなるかもしれないという話がフォーラムで加熱し、最終的に乳首描写が継続されるようになったのはユーザーの団結が開発元を動かしたのでしょう。 |
| 『閃乱カグラ』5周年。「パッケージソフトを続けたい、そのためには変えなければならない」プロデューサー高木謙一郎氏インタビュー | Shinji Sawa | 16-10-14 | 1 | 乳首が絆創膏で隠れているとか、まさに僕が子供のころに読んでドキドキしたやつだなと。（笑） |
| ゲームキャラのファッションは実際イケているのか、女性誌で活躍する業界人が本音トークでぶっちゃけ採点 | Ritsuko Kawai | 16-02-09 | 1 | 5サイズも小さいビキニ着てたら乳首ポロりしないことを祈りながらじっとしてる以外にほとんどできることなんてないのよ(増田注：引用文) |
| 『メタルスラッグディフェンス』 メタスラが到達した「パクリ」の一つ先 | Nobuki Yasuda | 14-05-16 | 1 | 「フィオ・ジェルミ」のとあるやられモーションで乳首が見えているか否かで、某BBSのスレッドが軽く炎上してい たことを見かけたこともあります。 |
以前在籍していた会社で企業向けパッケージソフトの開発をしていた。
お客様にそのソフトだけを売ることもあるが、サーバーへの導入など非IT企業には難しいので、維持管理も含めて契約していた。
私はアプリ側の担当者だった。パッケージソフト本体を作っていた。
導入、サービス管理、お客様のアプリが入っているサーバー（Linux）の保全などは維持チームが担当している。
お客様の要求に合わせたスペックにあわせた構成にするのも維持チームが担当するということになっている。
しかし、この維持チームはコマンドをコピペでしかできないわけだ。
なにか障害等が発生したときは当然アプリ側もバグの調査などでログを確認したりするが、サーバー側の不具合かどうかも我々が確認していた。
ミドルウェアの脆弱性が発覚したときもその対応方法の調査、手順の作成もした。
アプリ導入方法もミドルウェアの導入方法も我々がかいたものだ。
そのアプリがDBがもともと有償のあるDBしか対応していなかったんだが、PostgreSQLにも対応できるように機能改善した。
その時は差分バックアップの方法、リストアのやり方、ディスクが故障しても大丈夫なアーカイブログの保存法などの説明して、バックアップ設計までした。
なにせ、リカバリをする場合はリストアコマンド一つでできるもんではなく、ロールフォワードでどの時点まで戻すかという判断が必要になってくる。
ある時点で重要なデータを消したというのであればその時点より前までに戻さなければならないので、リストアのやり方の選択肢も状況により変わる。
あとPostgresは他のDBに比べてファイルをコピーしたりテキストを書いたりすることが多い。
Linuxのディストリが新しいバージョンが出たとき、アプリの動作検証も行ったあと、そのLinuxの導入手順書もつくったな
Apacheの導入手順も書いたな。
ミドルウェアやLinuxの使い方教えるのアプリ実装担当の範囲外じゃね？
でも維持チームにやれる人がいなかったのよ。
維持チームはつまり手順書というコマンドで動くシェルのようなもんだ。
Linuxの上にBashというシェルがあるが、その上に維持チームというシェルがあって、我々プログラマがその維持チームにコマンドを送っていた。
維持チームシェルの良いところはお客様の窓口になってくれたのでメールや電話はやってくれた。
電源機器などの製造販売を業とするユーザー企業が、商品の販売・生産管理を一元管理するシステムの構築をITベンダーに依頼した。開発はITベンダーが提案したパッケージソフトを利用する形で行われ、システムは納品されたものの、稼働後、多数の不具合が発生した。また、このパッケージではユーザー企業がこれまで行ってきた「新規品」「前同品」「修理品」のうち、「前同品」の管理しかできず、開発中からベンダーにカスタマイズ要望を行っていたにもかかわらず、ベンダーがこれに対応しなかった。そうしたこともあり、このシステムは業務に使えないとユーザー企業は判断し、稼働を停止した。
ユーザー企業は、前述の管理部分をITベンダーが開発しなかったことは債務の不履行にあたると訴訟を提起したが、ITベンダーは、この開発の方針はユーザー企業の業務をパッケージソフトウェアの機能に合わせて改善する「フィッティング方式」で行うことで同意されていたはずであり、「新規品」や「修理品」の管理は別の手法で行うはずだったと反論した。
本件における新規品は、まだ市場に投入されていない新製品、前同品は既に売り出して市場に出回っている製品、そして修理品は文字通り修理対象の製品を指す。確かにITベンダーが提案したパッケージソフトウェアでは製品をこのように区別しておらず、結果として「前同品だけ」しか管理できなかった。
ベンダーは当初、パッケージソフトウェアを業務に合わせるカスタマイズ方式を提案したが、ユーザー企業から「パッケージソフトウェアのカスタマイズは行わない」「機能が足りない場合は、業務の方をパッケージソフトウェアに合わせて改善する」という方針を示され、基本的にフィッティング方式で行うことになった。ITベンダーはそれを前提にパッケージソフトウェアを選択し、提案した。だがユーザー企業は途中からカスタマイズ要望を多発し、プロジェクトは実質カスタマイズ方式に変わってしまった。
フィッティング方式とカスタマイズ方式のどちらを採用するかは、その後の要件定義や開発に大きな影響を与える。
カスタマイズ方式の場合、ベンダーは、ユーザー企業の業務をよく把握して要件を定義し、さらに必要と考えられる機能については、仮にユーザー企業から指示されなくても要件と捉えて、開発しなければ債務不履行に問われる可能性が出てくる（必ずとは限らないが）。
フィッティング方式を採るなら、主として汗をかくのはパッケージの機能に合わせて業務を変えるユーザー企業ということになる。パッケージの機能は変えず、設定をどうすればよいのかを決めていけばいいので、ITベンダーの手間は少ない。
当初しなくてもよいと思っていた機能の追加や変更が、ユーザー企業の翻意によって変わってしまう、つまり開発中にフィッティング方式からカスタマイズ方式に変わると、当然、プロジェクトは混乱する。ITベンダーの作業は増えるし、業務知識も補足しなければならない。しかもこうした変更要望はランダムに言われるため、スケジュールもコストも計画から逸脱することになる。
本件の場合、特に大きかったのは「新規品」と「修理品」への対応だ。これらの機能はユーザー企業の既存システムには具備されていた。しかし、パッケージソフトウェアにはこれらに対応する機能がない。
カスタマイズ方式で開発を行うなら、恐らく必ず実装しなければならない機能だっただろう。しかし本件では、ユーザー企業自身が「業務をパッケージソフトに合わせる」と言ってしまっている。であれば、ITベンダーがこれを作らなかったのも致し方のないところだ。
他方で、作ったシステムは結果として業務には使えない。いくらフィッティング方式だからといって、業務が成り立たないほど乖離（かいり）したシステムを納品するのはITの専門家として許されないのではないか――ユーザー企業はそんな思いで裁判に訴えたと想像できる。
ユーザー企業の提示した（中略）提案依頼書には、本件新システム構築の「基本方針」として「1 システム構築には標準パッケージで構築する、2 カスタマイズは行わない、3 標準パッケージで合わないところは業務をパッケージに合わせる 標準パッケージで対応の取れない部分はパッケージに業務を合わせる」などと記載されて（中略）いる（基本方針はフィッティング方式である）。
（中略）
ユーザー企業は、（中略）新規品、修理品の関連業務について（中略）フィットアンドギャップ分析（中略）概要設計（中略）詳細設計および開発を行う義務を負っていたのに、（これらを）行わなかったのは（中略）債務不履行であると主張する。しかし（両者が合意した開発方式がフィッティング方式である以上）、ユーザー企業側の上記主張は採用することができない。
いわゆるOA分野とか、コンピューターを主に使用する作業の、自動化が流行っている。
製品で言えば、RPAとか、ノーコード、あるいはSaaSやパッケージソフトとか。
OfficeについてるVBAを使うとか、Pythonでスクレイピングとか、そういうのも併せて。
いわゆるマクロ的な何かで、タスクを自動化する、という考え方だ。これは昔からあったとも言えるし、製品や方法論がここ数年、急激に増えて、環境が激変したとも言える。
さて、個人が、その責任の範囲で、自己のタスクを自動化するのは、組織が禁止しているやり方でなければ、それについてとやかく言うつもりはない。
問題は、組織内部での自動化の推進や、それを補助するコンサル、あるいはソフトウェアのメーカーやベンダーだ。
すべてが駄目というわけではない。
「自動化で単純な作業から解放されて、クリエイティブな作業をすれば良い」
言い換えよう。今挙げたようなことを言う（書く）メーカーやベンダー、あるいはコンサルから個人まで。それらは皆、地雷だ。関わってはいけない人だ。
====
何故か。それは彼らが現実を見ていないからだ。そして、その現実を見ていないことが、軋轢を生むからだ。もしかしたら現実を見た上で、しらばっくれてる人も居るかもしれないが、タチの悪さは変わらない。
困ったことに、彼らの言う「単純作業から解放されてクリエイティブな仕事を」は、一見、理想的な環境に見えるのだ。
いや、実際、理想的ではあるのだ。現実的でないという問題さえ目をつむれば。
「世の中には2種類の人間がいる」という、使い古されたレトリックを、労働分野に応用してみよう。
すなわち、言われたことを淡々とやり続けることを好む人と、抽象的な指示や課題に対して、具体的な対応を行うことを好む人だ。
もう少し具体的に書けば、「言われた作業を淡々とやる人」と「創意工夫して結果を出そうとする人」になる。
さて、前者の、言われた作業を淡々とする人にとって。自動化は、己の存在意義と競合する。つまり、自動化されてしまったら、仕事がなくなる。
意識の高い社員や、コンサル、ソフトウェアのメーカーやベンダーの言うような「クリエイティブな仕事」なんて興味がない。
そういう人を「意識が低い」「生産性が低い」と卑下するのは簡単だ。だが、それは何も事態の解決にはつながらない。
単純作業の自動化がなされた時、その人たちに襲いかかるのは、「クリエイティブな仕事」という、安定した手順も方法論もなく、それでいて成否は存在する、という苦痛のような仕事への移行なのだ。
そして少なからぬケースで、単純作業を淡々と行うことこそ仕事、と捉え、そう働いてきた人は、クリエイティブな仕事とやらでは成果が出せない。ただ苦しむだけになる。
おそらく組織としての生産性は上がるだろう。それをもって成果とするなら、それはそれで矛盾はない。
ただし「働き方改革」のような題目を掲げて、自動化を進めていたのであれば。それは善人面をして、人を地獄に蹴り落とす所業だ。本稿のタイトルで「信じるな」と書いたのは、まさにここにある。
この話には、日本の雇用に関する、法律、行政の態度や、判例なども影響してくる。
前述したような、単純作業を奪われ、苦痛に満ちた苦手な仕事にたたき落とされた人は、どうなるか。
第一に、会社を去るという選択肢はある。だが、このご時世だ。今と同等の条件すら見つかるかどうかは怪しい。
それを自業自得と嘲笑するのは簡単だ。改善を肯定し、生産性の向上を是とし、発展を求める価値観からすれば、矛盾はないのだ。それが倫理的に正しいことなのかは、私にはわからないが。
第二に、苦しみながら会社にしがみつくという選択肢もある。正規雇用の場合、これが簡単に成立してしまう。「クリエイティブな仕事」をさせた成果がボロクソに悪くても、本人の意図的な手抜きなどがない限り、会社は簡単には社員を解雇できない。
はて、本人も苦しんでいることが多い、機能不全の社員を雇用し続けることが、生産性の向上や、働き方改革、ワークライフバランスなどにつながるのか、私は甚だ疑問だ。
つまり、業務の自動化、省力化を目的にするのは、それ自体が破綻を招きやすいのだ。それで浮いた人的コストを、どのようにするか。適材適所で別の仕事をあてがえるのか、あるいは解雇して雇用コストを削減するのか。
どうあれ、簡単なことではない。配置転換の教育コストを見積もるのは簡単ではないし、非正規だからと大量に解雇すれば、それだけで負の風評が生まれたりもするのだから。
人は、自分と異質な人に対して、理解が及ばないことがある。これ自体は仕方が無いことと言える。誰しもがわかり合う、なんてのは現実的ではないからこそ、フィクションで度々取り上げられる題材なのだ。
しかしながら、業務の自動化を改善と捉え、自身が単純作業を嫌う人の中には、少なからぬ割合で、単純作業を延々と行い、その労働時間を以て成果となす考え方の人を、理解していない、あるいは想定していないケースが多い。
その不理解や想定不足は何を生むのか。自動化の導入失敗や、同僚からの強い反発だ。決してプラスの結果ではない。その現実から目を背けてはいけない。
だからね。
「単純作業から人を解放したい」とか「空いた時間でクリエイティブな仕事ができるようになる」なんて、手放しで言っていたら。
その人たちを、信じちゃあいけないよ。
蛇足。
筆者は、別に、「単純作業を淡々とやることで鬻ぎたい人」を肯定するつもりはない。
少なくともデスクワーク、パソコンでの仕事等であれば、そういった人は滅びるべくして滅びるだろうと考えている。
だが、彼らに引導を渡すのは、個人や、少人数程度による「カイゼン」的な何かではない。個人や少人数による「カイゼン」が引き起こすのは、せいぜいが内部分裂や、一部の人に苦痛を与えるだけなのは、前述した通りで。
引導を渡す、という次元の話で言うと、おそらくは、そういった非効率的な人員を抱え込んだ組織の崩壊（企業で言えば倒産など）のような、圧倒的かつ、個人で抗うことに意味がない流れになると考えている。
もちろんその場合、多くの社員が路頭に迷うだろう。クリエイティブな仕事がどうとか言っていられる状況ではなくなるのは明白だ。
そういう未来が見えているからこそ、ミクロな視点でしかモノを見ずに、「自動化で業務を改善して～」「クリエイティブな仕事を～」というおためごかしを唱える人には、関わってはいけないと考えているのだ。
当初はWeb制作でJavaのパッケージソフトを動かせるようにということだったが、その後、そのパッケージで扱えない内容をPHPで開発することになった。
しかし、そのパッケージはPHPとの共存を前提にしておらず、ライブラリの競合でなかなか動かせなかった。
それほど有名ではないパッケージソフトで資料も少なく、社内に聞いてもあまり回答してもらえなかった。
頑張って動かしたと思ったが、デプロイ時にうまく動かず、障害が発生してしまった。
プログラマ経験初期の頃で自分の経験が不足していたことも大きいが、早めにできないと言って声を上げるべきだった。
全体的にプロジェクトマネジメントが機能しておらず、ただスケジュールを急かされる中で間に合わせようとして失敗した。
上司に相談したかったが、打ち合わせ等でいないことが多かった。その後、すぐに上司は転職してしまった。転職活動もあって、いないことが多かったのかもしれない。
親にパソコンを買ってくれってねだって買ってくれたPC-98は、
今思うとドン引きしてしまうんだけど、トータル80万円ぐらいだったかな？
で、高校入ってパソコンは使うんだけど家では、ほぼゲームのみ。
その時は流行っていた、ぷよぷよとかファルコムとかアートディンクのゲームに夢中になった。
家でそうやって課題に使ったことも覚えてないぐらい、たぶん使ってない。
要は高校で必要なパソコンの用事は学校で学校のもので事足りたってことで、
わざわざ高価なPC-98なんて買わなくても良かったのでは？と今になって思う。
あと学校と家のパソコンでは互換性が無かったFM-TOWNS。
今でこそ分かるけど
今思うと本当にMSXでも良かったと思う。
もちろんインターネットはそんときなかったし、パソコン通信とかもするわけがなく、
今になって思うと、それ自分の実になって役にたったのかな？と思う、
あと覚えてるのはそのPC-98で
それ以外のまともなUXはなかったから、せいぜいそれらのUIに慣れて触れたぐらい。
あと本当に今思うとなんでそのソフト買ったんだろう？って思うんだけど、
NECの音声合成出力ソフトを2万5000円ぐらいで買ったのは今でも謎。
インストールしてサンプルをしゃべらせて飽きたような気がする。
とにかく今思ったら、
キーボードやマウスとかパソコンを物理的に使いこなせるようになったってスキルしか得られてない。
親もよく買ってくれたなと思うし、
あの時PC-98を買わなくてもMSXで良かったのではと今でも思う。
でもその時MSXを買っていたら今どんな道を歩んでいるのかは知る由もないけど。
とにかく今思うとあのPC-98は自分にとってもったいなかったなーと同時にそれで何をしたかったんだろうって思う。
ただそれだけ。
3年前、世間一般にはメーカー系SIerとして知られている会社を退職した。ただ俺のポジションはパッケージソフト開発であり純粋なSIerとは異なる。
客ともSEとも会話せず、ひたすらドキュメントとプログラムを書く部署だ。といっても別にペーペーではなく主任クラスであり、
会社の業績がとてもよかったこともあり年収は1000万弱はあった。35歳。
これだけ見るととてもいい待遇に見えるだろう。でも耐えられないことがいっぱいあった。
Linuxで動くアプリなのにVMを動かすのも苦労する8GBしかメモリのないWindows PC、紙にコードを印刷して説明しないと納得しない品質保証部、
手作業で実施しExcelにチェックを付けていくテスト、jquery一つ使うのに3ヶ月かかる承認フロー、開発中にバグを一つ出すごとに
ひたすら反省文を求める品質保証部と一緒になって詰めてくるマネージャー、常にコンパイルできないtrunk、
Java 5の時代から進化しないコード、使いにくい社内ミドルウェアの利用を強制される設計、開発期間の半分以上を占める最上流設計、
一旦書いたコードは消してはならずコメントアウトしないといけないコーディング規約など、数を上げればきりがない。
色々改善活動を頑張ったものの、結局Subversionの導入も品質保証部がついていけないから、ということでClearCaseといわれる
今ではほぼ誰も使ってないであろうバージョン管理ツールが使われ続けることになった。使いにくい社内ミドルウェアは
研究所がその道のプロと聞いたので一緒に改善を図った。そしたらRubyしか書いたことがない文系新卒の子が出てきた。
一応研究所の人だし…と思って新バージョンのプロトの開発を依頼したら、1分以上稼働できない状態になって出てきた。
研究開発は準委任相当なのでそれ以上修正を依頼できずに期間が終わった。
また前の会社独特の文化として、大きなバグを出した開発者の反省会（社内ではとある固有名詞で呼ばれている）があった。
この反省会のターゲットになった開発チームはその資料準備で開発が1〜3ヶ月ほど止まるほど大掛かりなイベントだ。
このとき、担当の品質保証部は「連帯責任だから」という理由で資料レビューに大変な精を出す。余計なお世話だ。
このため10〜20ページほどの資料を毎週レビューにかけて最高のものにしていく。でも結局本番では幹部からの怒号が飛んで終わりである。
連帯責任とかいっていた品質保証部は幹部と一緒になって詰めてくる。連帯責任ではなかったのか。
幹部によると、この反省会があるから今の会社があるんだそう。これを経験して一人前らしい。
こんな感じで開発の体制はひどかったが、世間一般ではホワイト企業と見られている通り有休は取りやすかった。
そのため、転職活動を始めた。そしたらなんと「メモリ32GBのマシン」「mavenが気兼ねなく使える回線」「自動テスト」
「GitHub」「CI/CD」 という発言がポンポン出てくる。メルカリだのGoogleだのといったイケイケWeb系ではなく、
いわゆるSIerでもだ。最初は何だこの格差はと思ったが、まぁ営業トークなんだろうな、と思い直した。というわけで
イケイケWeb系も内定は出たものの、つい安定をとってしまい某大企業のDX系の部署に転職した。
そしたら何だこれは。最高スペックのMacBook ProからGitHubにpushするだけで自動デプロイで即サービスイン、
問題が発生したら社用携帯に通知が飛んできて、クラウド監視サービスでログをチェック、即修正即デプロイ。
社内の連絡はSlackで、スタンプを押せばIssueがたち即関連部署が対応に走る。OfficeツールはGoogle Docsで、
計算表はちゃんと表として使っている。開発者はちゃんと開発をしており、反省会の準備や品質保証部の接待なんて業務はなく
純粋にエンドユーザーだけを見ている。ここはなんて最高の環境なんだと歓喜した。また個人的にはおまけ程度であるが、
年収は30万ほど増えて大台に乗った。
さて、それから3年がたった。人間というのはいい環境になれると対して喜びを感じなくなる、というのはそうだと思う。
今では別にdeployブランチにマージされたらCIが走って自動でテストが走りデプロイされるのも、だから何？
って感じだしまぁ普通の仕事として淡々とやっている感じはする。待遇面で悪化した点もちらほらあるし
（例えば年間休日が5日ぐらい減った、残業が月5時間ぐらい増えたなど）などもある。
ただ一つ言えることは前の会社には戻れないな…ということである。人間一度生活レベルを上げてしまうと下げるのは
ただ、一つだけ今の会社に転職してよかったと感じ続けられることが一つある。それは人だ。
前の会社では家でプログラムを書いているなんていった日にはおちょくられたり、人生楽しいの的な目で見られたりした。
芸能人とゴルフの話ができないとコミュ障扱いされた。そのため仕事の話はしても、飲み会にはできるだけ行きたくなかった。
でも今の会社では雑談としてFastlyが落ちても大丈夫なCDN構想とか、AtCoderの話をして盛り上がることができる。
ダイバーシティなんていうが、人間は所詮同質な人間同士で集まったほうが快適なんだな・・・という複雑な思いを抱いている。
皆さん読んでくれてありがとうございます。いくつか質問が出ているので答えられる範囲で答えます。
真面目な疑問なんだけど、Java5のコード書いてる人を1000万で雇う会社があるの？どういうモチベーション？？
製品自体が90年代から脈々とバージョンアップしている企業向けのソフトウェアなので、コードベースが古いというのがあります。
またユーザーからすると中身がJava17だろうがJava5だろうが関係ないわけで、要は業務が滞りなく進めばよいわけです。
そのため昔から受け継がれたスパゲッティコードを地道に解き明かし、新しく出てきた要件を今までのコードベースを壊さずにバグなしで追加していく、
もとからあったバグについては、その他の数百万行のユニットテストもないコードに影響なしで修正を施す、といった技能が必要になります。
こう考えると意外と希少なスキルなんだな・・・と思えるかもしれません。
clearcaseよりもsubversionの方が100億倍導入も運用も簡単だと思うんだけど品管どうなってんの？
ClearCaseご存知な方がいるんですね！一から作る製品だとSubversionのほうが簡単かもしれません。ただ、ClearCase専用の
社内ツールがいくつかあり、そのツールで出力した情報を社内資産として持っているという理由があったりします。
例えばお客さんから「この機能がバグってるっぽい」というクレームを受けた際、その機能周辺の情報をそのツールから検索し、
コードレベルで再発防止策を関係部署総出で練った上でお客さんに回答する、という運用フローになっています。
そのため、Subversionに変えるためには開発陣の一存では無理で、品質保証部やマネージャー層など全ての知識のアップデートが
必要になり、そこまでコストをかけて説得して回る必要はあるのか・・・という話になってしまうわけです。
ただ、社内の生産性を向上させるのが目的の部署としてはSubversionやGitを社内に浸透させたがっているのも事実で、
新規プロダクトなんかはGitを使っていました。ただしGitHubはプロキシでアク禁されているだけでなく、サービス名名指しで使用禁止
になっているので、相当の理由がない限り使えないかと思います。
主任クラスでも1000万円近くもらえるのか。すごい。
1000万という数字に興味のある方が多かったので参考までに書いておくと、等級ランクというものが存在して管理職を除く最上位のランクに
なると2人の子持ち、賃貸住まい、標準評価で大体900万になるという感じです。年功序列だが部署ごとに違うというイメージで、
研究所だと20代で到達する一方、利益を上げていない事業部や間接部署だと定年間際まで到達しない人も多い、ぐらいの感じです。
平均では30代中盤ぐらいでしょうか。
ちなみに私の場合は基本給は33万程度ですが、そこに裁量労働手当と住宅手当、家族手当がついて月給で50万を超えるぐらいでした。
ボーナスは個人評価よりも部門業績に大きく左右されるのですが、部署が最高評価の場合は夏冬とも150万以上でした。
最後の最後のダイバーシティについては、ダイバーシティを勘違いしているように思う
