  |
はてなキーワード: SubVersionとは
2022.7.24 一般公開シンポジウム 「フェミ科研と学問の自由」
https://www.youtube.com/watch?v=FP8rL7KfisI
長いため講演部Part1~Part5+質疑応答の6部に分割する。
分割の境界はスライドにある番号に従うが、副題は増田の判断である。
スライドはすべて図表のない文字ベースのものであったため、引用記法を用いて本文に組み込んだ。
講演部については、「女性スペースを守る会」が公開している文字起こしをベースに、
増田が誤字の修正や、句読点の変更、改行の追加などの編集を行った。
まず、江口聡先生による、8/9のブログ記事は必読だと考える。
加えて、講演に対する批判として書かれたものではないが、一般論として「キャンセル・カルチャー批判」的な立場で書かれたベンジャミン・クリッツァー先生の記事、
なども参考になる。これら2記事は、江口先生も講演に欠いている「ミルのタイプの言論の自由の擁護」として紹介されている。
また、あまり整理がされていないが、この講演に対するTwitter上の批判的な反応を一覧できるものとして、
他、法学の専門家による分析という点で他になく注目に値するものとして、
(あと、この書き起こしを編集している私自身も手前味噌ながら批判記事を書いている。「清水晶子先生の講演を読んで見る (1) 「学問の自由」の定義ってなんだろう」anond:20220809001101 )
anond:20220805225632 Part1 〜学問の自由とその濫用〜
anond:20220805225835 Part2 〜ポリティカル・コレクトネスという言説戦略〜
anond:20220805230017 Part3 〜Academic Bill of RightsとProfessor Watch List〜
anond:20220805230307 Part4 〜キャンセル・カルチャー批判〜
anond:20220805230534 Part5 〜Ahmedが見立てたキャンセル・カルチャー批判のメカニズム〜
anond:20220805230705 Part6 〜質疑応答〜
https://www.youtube.com/watch?v=FP8rL7KfisI&t=2457s
40:57~48:23
清水さんは東京大学大学院総合文化研究科で教鞭を執られています。
研究関心としては非規範的な身体と性の政治、とりわけ身体の他者性、自己表象と生存の戦略、可視性を巡る問題などがあります。
最近は英語圏のフェミニズムおよびクィア理論史を改めて辿ることにも興味があるとのことです。
主な著作に、
Lying Bodies: Survival and Subversion in the Field of Vision、英語の本です、2008年、
「埋没した棘――現れないかもしれない複数性のクィア・ポリティクスのために」、2019年、
『フェミニズムってなんですか？』、2020年、などがあります。
清水晶子：
はい、ご紹介ありがとうございます、清水晶子です。もうそのまま入っていきますが、
本日は「学問の自由とキャンセル・カルチャー」というタイトルで報告をしたいと思います。
少し方向性が違うかもしれないんですが、よろしくお願いします。
学問の自由とは
「学問の自由という原則は、学術コミュニティの構成員、すなわち、研究者、教員や学生が、倫理的規則と国際的水準に関して学術コミュニティが定めた枠組みの中で、そして外部からの圧力を受けることなく、学術的活動を追求する自由と定義できる」
学問の自由というところからいきたいんですが、学問の自由とは何を指すのか。
政府なり場合によっては非常に強力な宗教だったり経済的な権力だったりというところからの圧力を受けることなく、
さらに言えば個々の研究者が、大学当局だったりとか大学の経営陣あるいは多数派の社会的通念・経済的な要請などからの
不当な干渉や抑圧を受けることなく、学問的良心と手続きとに従って真理を探究する自由、というふうに考えることができる。
例えば、1998年の国際大学協会声明「学問の自由、大学の自治と社会的責任」という文書があるんですが、これによると
「学問の自由という原則は、学術コミュニティの構成員、すなわち、研究者・教員・学生が、
倫理的規則と国際的水準に関して学術的コミュニティが定めた枠組みの中で、
そして外部からの圧力を受けることなく、学術的活動を追求する自由と定義できる」というふうにされています。
学問の自由というものの基本がここにあるというふうに考えると、フェミ科研裁判の文脈における学問の自由の主張というのは、
ある意味まさにここに相当するもの、王道の部分というふうに言うことができるというふうに思います。
「過激な性教育・ジェンダーフリー教育調査プロジェクトチーム」
残念ながら、日本でフェミニズムとかマイノリティの政治に関わる研究者にとって、
今言ったような意味での学問の自由というのは、必ずしも安定して保障されてきたものではない。
だからこそ、その必要性というのはしばしば痛感もされてきましたし、主張もされてきました。
2000年代前半のフェミニズム女性運動へのいわゆる「バックラッシュ」いうのがありまして、
ここでは与党自民党のプロジェクトチームにおいて、ジェンダーという語それ自体の使用に疑義が提示されたりしている。
2014年には、いわゆる「従軍慰安婦」問題を取り上げた広島大学の研究者の授業というのが、
先ほども産経新聞出てきましたけど、ここでも産経新聞ですが、産経新聞によって吊し上げにあって、
批判や抗議が大学に殺到し、日本科学者会議広島支部幹事会が学問の自由の侵害であるというふうにして、
産経新聞に抗議をする、声明を出すという事態になったりもする。
もちろんさらに記憶に新しいのは、2020年日本学術会議の会員任命拒否ですね。つまり当時の菅内閣総理大臣が、
日本学術会議が会員候補者として推薦した内の6名の任命を拒否した、というかしなかった件ですよね。
この任命拒否については、憲法23条の保障する学問の自由を脅かすものであるというふうにして、
2011年11月に、日弁連が「日本学術会議会員任命拒否の違法状態の是正を求める意見書」というものを総理大臣に提出をしていると。
この意味での学問の自由の重要性というのは、本日のシンポジウムのいわば前提になっているものだというふうに考えます。
差別的・抑圧的な言説に対して政治的・経済的に力のない側、社会的少数派の側からなされる批判や異議申し立てを「学問の自由の侵害」とする言説
その前提をご確認いただいた上で、私の報告は少し角度を変えて、学問の自由という主張や枠組みがどう利用されているのか、
もう少し強く言うと、どう濫用されているのかでもいいかもしれないんですが、それを考えたいと思います。
今申し上げたように、従来はそして一般的には、学問の自由というのは、
国家とか、強力な宗教団体、経済団体、多数派の社会通念や経済的要請、などなどの圧力を受けることなく、
研究者の社会的通念と研究の手続きに則って真理を探究する自由を指す、というふうに理解されています。
力のある人たちとか多数派にとって都合が悪い、あるいはそこにとって利益にならないというだけの理由で、
研究教育を抑圧したり不当に妨げたりすることを困難にするはずのものです。
ところがこの学問の自由の主張が、全く逆のベクトルで利用されることがある。
すなわち差別的・抑圧的な考察や言説に対して、政治的・経済的に力のない側、社会的少数派の側からなされる批判や異議申し立てを、
これは「学問の自由の侵害」であるというふうにする言説、というのが見られるようになっている。
これは日本国憲法で保障される学問の自由からはかなりかけ離れたもので、何を言ってるんだというふうに思われるかもしれません。
けれども法的な解釈とは別のところで、こういう言説上の戦略というのが一定の効果を持ってきているのも事実です。
二面での闘い
結果として、フェミニストとして学問の自由を考えるにあたって、
私たちは一方では、フェミ科研裁判のように国家による学問の自由の明白な侵害というものと闘わなくてはいけない。
けれども同時にもう一方で、学問の自由というのが、差別的あるいは抑圧的な現状を追認し、
抑圧されてきた側からの異議申し立てを封じる目的で動員されるということに対して警戒をしなくてはならない。
学問の自由を巡っては、フェミニストには現在そういういわば両面での闘いというものが要請されている。
この現状は忘れるべきではないと思います。
実は今日、私からお伝えすべき論点はそこに尽いているので、ここで報告終わってもあんまり問題ないっていう感じなんですが、
ちょっとさすがにそれでは簡便過ぎるので、この後の時間を使って、
こういうタイプの、マイノリティの権利主張を抑圧する目的で動員される「学問の自由の侵害」という枠組み、
この言説というのが具体的にどう現れてきたのか、
これが非常に大きな論点になってきた英語圏の動きというのを中心に、簡単にまとめてご説明したいと思います。
anond:20220805225835 Part2 〜ポリティカル・コレクトネスという言説戦略〜
そもそも大企業の上層部はDXっていうのを買ってくればDXできると思ってる。
DXっていう研修とかDXっていうコンサルを買ってくればDXできると思ってる。
これが中小企業ぐらいだったら鶴の一声でDXできるかもしれない。
ところが大企業っていうのは意思決定者が細分化されていることが多くて
社長が「DXするぞ！」って言っても実際に社長はDXの状況を年に１回ぐらいしか確認しないし
「結局はこれだけやってりゃいいんでしょ？」
例えば、社内の会計システムがエクセルよりダメダメな終わってるような会社（某大手通信会社）でも
それを変えようとすると
「これで慣れてるから変えるな」
これ、実際にはそういうこと言う人はほとんど居ないんだが
会計システムを管轄している部署が実際に使う人達の部署の上位組織にあたることはほとんど無いし
下手したらコストセンターの部長は営業系の部長より立場が低い場合がある。
だから売り上げが下がるような可能性を忖度して新しい社内システムなんて簡単には入らないし
入れるとしても無茶苦茶時間かけて旧来のシステムとの整合性とか気にしまくってから導入する。
ってなってほとんど使われないのが現状。
他にも何かしらDXしようとしても結局は上司の意見を忖度する。
パワポの資料やめてnotionにしましょうとかソースコードのSubversionやめてGitにしましょうとか
そういうことを「言うことが構造的に難しい」っていうのが根本的に問題。
社長や部長が「そういう声を拾うぞ！」とか言ってご意見箱的なのを用意したりもするんだが
結局そこに投稿されてる提案が良いのか悪いのか判断できないから無駄。
必要なのはリーダーシップというある意味独裁的なやり方であって民主主義的なことをやってたら成功しない。
なのでDXを本気でやりたかったら上層部の人間がイケてるベンチャーで下っ端として１ヶ月ぐらい働いたらどうですかね。
日銭を稼ぐようなベンチャーでイケてるところは効率化の塊ですよ。
上司は基本はいい人なのだが仕事は「分かんないから自分がうまくいけば他は知らん」な人である。
他のSI企業と同様にSubversionをうちの会社も使っている。
リリースミスが多発してルールを厳格化したのだが、ある日、厳格化を進めた本人によってリリースの忙しさによってうやむやとなった。
最近、「綺麗にする」と理由で本番環境のファイルを全部devにバックポートするということがあった。
すべてのパスは上書きされ、チームのドキュメントの置き場もなくなった。
それなりにルール守るのに結構言われるし、努力してきたのだが、意味は無くなったらしい。
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万以上でした。
最後の最後のダイバーシティについては、ダイバーシティを勘違いしているように思う
この程度でも600万は稼げるという夢を持つか、こんなのでもちょっと何かが違うだけで600万稼げるか否かが分かれてしまう業界に闇を感じるか、600万程度で何ドヤってるの？と思うかはご自由にどうぞ（外資系ってもっと稼げるの？）。
歳は30台前半。学部卒。BtoB向けのパッケージ製品の開発プロジェクトで、設計、コーディング、テストあたりを担当している。仕様について発注元との折衝もやっている。
業務で使う技術のうち、自分自身がそれなりに習得しているものだけを書く。プライベートでしか習得・使用していない技術は別。
以上。
PythonもgitもDockerもkubernetesもAnsibleもCIツールもAWSもGCPもRuby on Railsも知らなくてもなんとかなってしまっている。業務でこれらのスキルを要求されることは（今のところは）ないから。
楽でいいと思う一方、このままだと将来ヤバいとも思っている。いざ転職となったときに詰みそう。
でもいざとなったらググっていくらでも独学できるだろうとたかをくくっているので焦ってはいない。
というか「その他」のところに書いた能力が高ければ世の中大体はなんとかなるんじゃないの。知らんけど。
ちなみに自分は構築できないというだけで、プロジェクトではJenkinsとかgradleとかbabelだかwebpackだかでビルド環境は整えられている。
あとプライベートで、単純な仕様の独自言語のコンパイラフロントエンドをC++とLLVMで作っている（これで金が稼げるとは微塵も思っておらず、完全にただの趣味）。
main をpainにかえただけで 動かなくなったプログラム
プロなら １０分？って聞かれたけど
全部のコードを洗って
最悪 ファイルが１個消えている というのも すべて 確認していくから
これだけのファイル数があると 数ヶ月
ようするに これをうたがう って mala
rm main.cc って やって まぁ これなら １０分って 今度はアシスタントさんになおしてって 聞いてみた いちおうサブバージョンははいっている
え？Gitがいいしょうがないなぁ sudo yum install git
git init
git commit -m""
つぎなにしよっか？
え？subversionとコリジョンしている？とりあえず消してみる？
yum remove subversion
いわれたとおりに やってるよ
Wikipediaを見たら
Care/harm
Fairness/cheating
Loyalty/betrayal
Sanctity/degradation
わかりやすく言うなら
1. 危害を加えないこと
2. 公正であること
3. 集団内で結束すること
4. 権力に従うこと
5. 欲望を抑えること
といったところか。
で、上二つだけを支持し、下三つを軽視するのがリベラル、
すべてを支持している（相対的に下三つを重視している）のが保守だと。
主にアメリカ人の研究であって、日本だと多少違いそうだけどな。
もちろん「だからリベラルは配慮が足りていない」ということではない。
どちらも善良さに違いはなく、ただ「チャンネル」の数が違うだけだ。
チャンネルの数が違うことによって、それぞれに欠点が生まれている。
この本もリベラルに向けて書かれていて、
日本版の「リベラルはなぜ勝てないのか」という煽りがミスリードな感じがするな。
そう言われてもアメリカ大統領選だって交互に勝ってるけど…って思っちゃう。
30代前半で政令指定都市に在住。社員数百人の古き悪しきSIerに勤めている。
年収は500万～600万未満と言う感じで大したことはないが大企業の子会社ということで仕事は安定していて、退職金や企業年金制度もある。古臭い企業文化と将来性の無さに目を瞑れば働きやすい。
最初に転職を考えたのは5年ほど前、ギリギリ第2新卒だった頃。要因は時代遅れの仕事環境。スキルが身に付かず人の管理とエクセル操作ばかりの仕事に嫌気がさした。
勢いで「とにかく東京だ」と考えて無計画に活動を始めた結果、深夜バスで東京に行き1日3社面接して心身共に疲労困憊の中、3社とも面接通過してしまい「もう疲れた...」となってしまった。
実はその時も選考を進めるべきか考え直すべきか悩んで増田に投稿した。すると思いの外反応があり「とにかくチャレンジしてみるべき」「安定して収入そこそこの仕事を捨てるなんて信じられない」「本当に技術的なことに興味があるなら日頃からもっと勉強してるはず」など様々で余計に悩んだ。
結局その時は「まだ今の会社で頑張れることがある」と自分に言い訳をして転職を中断した。
それから5年。結局仕事環境は何も変わらなかった。相変わらず開発環境はインターネットに繋がらないしエクセルで課題管理・進捗管・スクショを取って、subversionでバージョン管理している。
その間、仕事では数人チームのプロジェクトのPMをやったり、個人ではクラウドなりDockerなり勉強してアプリを作ってリリースしてみる、などしていた。
だけれど会社の変わらなっぷりを見て危機感は日に日に増している。別に多くを求めているわけではない。世界を変える仕事や高い収入を求めているわけでもない。エクセル地獄と酷い社内システムを止めて、IE以外のブラウザ、githubやチャットツールが使えてCI/CDできるようなインターネットにつながった環境で働きたいだけだ。でもこの会社にその環境が入る頃には世間から2週遅れぐらいになっているだろう。
最初の転職活動の原動力は希望であったが、今は危機感に変わった。このままここにいては、この会社以外で生きていけなくなる。
そんなこんなでまた転職活動に思い立ったわけだかだ、タイトルのとおりツケが回ってきたと感じる。
それは年齢が上がったこと、そして今年第一子が生まれたことだ。
前回の反省を活かして今回は東京ではなく住んでいる地域で仕事を探し、詰め込みすぎないように進めている。というか詰め込むほどの求人は無い。一応転職先の軸みたいなものはあるが、声がかかるのはベンチャー企業だったり英語能力が求められるところ（当方TOEIC610のクソザコ）が多い。さらには大部分が東京本社の地方拠点扱いでリモートのコミュニケーションがベースになるような環境だ。
ここまでぬるま湯に浸かってきたもう30を過ぎたおっさんがいきなり環境が全く異なるベンチャーなんかでやっていけるんだろうか。自分の適応能力に不安を持ち、古い保守的な考えが染み付いてしまった。
自分だけならまだいい。でも今は子どもがいる。妻も育休を終えて職場復帰する予定なので共働きではあるが、妻は転職に難色を示している。
収入はどうなる。仕事が大変でうつになったりしないか。子どもが保育園に行くようになれば休まないといけない日も増える。いずれは住宅も購入したい。
一人だった頃より考えること、決断を鈍らせる要因が増した。
確かに子どもが生まれた直後に転職なんてリスキーだと思う。だけれど現職に留まるのはそのリスクを先延ばしにしているだけとも考えられる。もし10年後、今の会社が無くなったり人員整理を始めたら自分の行き先は無い。子どもが大きくなるのを待ってから転職しても拾ってくれる会社があるとは思えない。既に遅い自覚はあるが、動くなら本当に今がギリギリだろう。
自分は将来のリスクを見て、妻は今のリスクを見ている。そんな感じだ。
みんな知ってのとおりエンジニアは深刻な人材不足で超売り手市場。2社だけ受けてどちらも内定をいただいた。
仕事内容や技術周りの環境は現職からすれば申し分ない。だけれど前述のとおり、待遇や制度さらには自身の適応能力への不安で決断に迷っている。全ては過去に転職を放棄したツケが回ってきたものだと感じている。身軽なうちに環境変えるべきだった。
それを他の人が触った時に念のため前のデータをおいて置かなければいけない（バックアップを作らなければならない）決まりがあるわけ。
※そんなもんgitなりSubversionなりのバージョン管理ソフト入れれば良いのでは？っていう話は今はNG。その提案は「業務効率が悪くなる」という理論で通らなかった。
があるとした時に、どれが最新版のデータになるかというとどうやらうちの会社では「設計書_20180226.docs」が最新版となるようだ。
業務の流れとしてはこの後、設計書に変更があったとき、設計書_20180226.docsをコピーし、本日の日付をつけたファイルを作成しそこに変更を加えていくわけだ。
今現在の状況だけど、平気で「設計書_20180226.docs」を最新版として業務が一日跨いだので2018年02月27日に書き足しを行っているわけだ。
つまり、このまま行くと「最終更新日が2018年02月27日の設計書_20180226.docs（最新版）」が出来上がることになる。そして、そういうファイルがざらにある。
個人的にだけど
という並びがあった時、設計書.docsというデータがあれば日付がついていないものが最新版にならないといけないのではないかと思う。
設計書.docsがあくまでもマスターで、それをいつコピーしたのかが日付つきファイルという認識だ。
設計書_20180226.docsというのは2018年02月26日の状態の設計書.docsをコピーしたものという意味ではないかと思う。
というか、取引先もこちらに設計書を渡す時、「2018年02月26日のマスターをコピーしたものですよ」という認識で「設計書_20180226.docs」を渡してきていると思っている。
私が「最終更新日が2018年02月27日の設計書_20180226.docs（最新版）」はおかしいのではないか？と社長に話したところ「他の会社ではそれ普通。おまえは経験が浅いから間違ってる。すなわち俺が正しい。他の会社の人に聞いてもらってもかまわない。」という話なのでこうやって増田に話をしに来たわけ。
※そんなもんgitなりSubversionなりのバージョン管理ソフト入れれば良いのでは？っていう話は今はNG。その提案は「業務効率が悪くなる」という理論で通らなかった。
SubversionやGitだったら迷わずそうしてる
