  |
はてなキーワード: リプレースとは
結構な数の反論をもらったのだけど、一番多かったのは「すげーと思ってるのはそこじゃねーよ！」というものでしたね。
「（主に）ITにおいて、ダイナミックに新しい技術を導入できているその変化の速度が羨ましいんだ」という主張が多かったように思います。
じゃあその速度がどこに起因するんだということを自分なりにいつも考えているのだけど、私に思いつくのは以下のもの。
１．独裁的で民主プロセスをすっ飛ばして規制緩和を決められる政府とそれに諦めを持っている国民
２．個人情報の収集に命を燃やし、それに役立つ民間技術があれば金銭的、法制的に積極的に後押しする政府
３．儲かる（と思った）領域に一気に人的資源を投入し、ダメだったら即首を切れるるゆるゆるの解雇規制
４．最後に人に物理的にサービスをデリバリーするための大量の低賃金労働者
５．不動産の次の投資先を探して彷徨うちょっとバブル気味の投資資金
６．15億人の同一言語の市場と毎年800万人出現する新卒労働者
７．リプレースすべき先行インフラがないことによる、新技術導入メリットの大きさ
８．怒られるまではやってもいいというゆるゆるの倫理観
９．新しいものかっこいいじゃん、かっこいいものは見せびらかしたいじゃん、という社会の空気
10．失敗して怒られてもいいじゃん、というサービス提供者側の当事者感の無さ
（ちなみに消費者側に失敗に寛容な雰囲気はないよ。ミスがあれば普通にキレまくるし、裁判起こしまくる）
はい、見るとわかる通り日本では入手不可能か、心情的に抵抗のあるものが多いですね。
最初の記事へのブクマでも何人か指摘していたけど、日本がいいところだけ取り入れようとするのは結構難しいと思うのですよ。
ということで、中国のダイナミクス羨ましい！という人は、日本でギャーギャー言ってないで、中国に移住したほうがいいです。
日本人にとって中国語は簡単だし、ちょっと勉強すれば話せるようになるよ。今の中国企業は市場として日本進出目指しているところも多くて、
日本語話者のニーズは無いことはないと思う。まあ日本語話せる中国人が死ぬほどいるので競争は厳しいけど。
自分は、個人的には新サービス好きなので、流行っているアプリやサービスは結構使ったしそれはそれで楽しんだけど、
中国の勢いをもう十分味わったからおじさんは日本に帰らしてもらうわ。あとは若人頼んだぞ！
え、あんな生活環境の悪いところには住みたくない？じゃあお先真っ暗な大嫌いな日本でブーブー文句言いながら沈没しとけよ臆病者。
リプレースでも新規でもいいけど、どちらも人数をかけなければ作れない時点で、少数精鋭の「知識集約型」ではダメなわけで、むしろ「いかに労働集約的に回すか」って話になる。
少なくとも少数精鋭ありきで成功した大規模プロジェクトなんて聞いたことないし。
まあ実際には一部の出来る人に負荷が集中しまくってる現実があったりするし、それも加味して全然上手く回ってない。
で、IT技術やプロジェクト管理のノウハウはアメリカ主導だけど、例によってどれも「知識集約型」作業が前提の話になっていて、現実の大規模開発では全く役に立ってない。
確かに、クラスライブラリやフレームワークの話は大事なんだけど、反面実際にコードを書く人間以外にとっては心底どうでもいいというか、どうでもいいってことにしたいわけじゃん。
心理的安全性とか言うけど、大事なのはどこの誰ともわからない専門家の知見じゃなく、目の前の相手に対する観察力だし、技術よりもそういう「人の問題」にフォーカスしたいわけで。
これが日本独自なのかは知らんけど、そういう文化では「バカでも人をかき集めれば何とかなる」反知性主義前提のスキームで回せるのが最強なわけよ。
それこそ大昔のフローチャート書く→コードに翻訳する→テスト一発合格→完成という流れの集合体みたいなのが最高に効率がいい。
だから今必要なのは、業務要件が複雑かつ目まぐるしく代わっていくビジネスの現状でも、変化に追従できて短納期の開発を、人集めれば出来てしまう仕組み。
かといって、メンバー全員を情報系大学出身でまとめるとか、日本人の反知性主義を変えていくとか、全く非現実的な解決案は答えになっていない。
何か上手いやり方ってないのだろうか。
こういう事情で本来業務の片手間にこしらえる小道具って、そんなものだと思うよ。
腰を据えて言語を学ぶ時間的余裕もないし、書籍などを買う費用は会社から出ない。
概念の理解ができようとできなかろうと、とりあえず動くものを作る必要には追い立てられる。
Excelのマクロ記録で生成されてきたやつを編集して、解釈違いを直して分岐や繰り返しをつけたら一丁上がりとかな。
だから当たり前のように見苦しい書き方になってたりする。
その後、会社から予算つかないまま草の根的に生まれたお手製システムの便利さに浸りきった頃に重大な問題が発生するのもお約束だ。
そうすると社内が大騒動になり経営者の頭からツノが出そうになるんだが
「ま、元が無料ですからね。必要なものにお金をかけないとこうなるんです。本来はちゃんとしたものを買うべきで」
ZOZOTOWNにメルカリと内容は違うが大手ECサイトで最近問題が起きている。
http://tech.mercari.com/entry/2017/06/22/204500
ここでメルカリのエンジニアの方が原因を説明しているが、とても単純で御粗末な内容である。
ZOZOTOWNは毛色は違うが、前から結構酷い作りのサイトらしいし、求人も出していた。（とても求める人材が来るような給料では無かったが…）
この2社に共通しているのは社内での技術者の立場の弱さではないだろうか？
もちろん全ての技術者に冷ややかな目を向けているわけでは無く、今花形のデータサイエンティストなんて感じのビックデータで統計分析する人々は社内でも一目を置かれていそうだが、そうではないネットワークやシステムの管理運営をしている日陰な役割のエンジニアに関しては、余り良い待遇を貰ってはいないのでは無いか？
経営者陣が技術者軽視だと、自然と予算も人員も割かれず、少ないマンパワーで大規模なネットワークの保守をする事となり、並行してリプレースに向けての準備やテストを行ったりしているのではないだろうか。
そして発言権も無いに等しいので、万全を期して一時的にシステムにアクセス出来なくする事も許されずに、切り替え作業を実施させられたのでは無いか？出来るか出来ないか？の2択で問われて、嘘は言えず出来なくはないと答えざる得なかったのではないか。
と言う感じの回答を土日でかき集めたバイトに社員名乗らせて答えさせている。
今回の件について対応の是非は分からない。きっと問題直後の動向を社内のデータサイエンティストが分析して、メルカリユーザーは気にせず使ってますって事で強気にGOでも出したのではないか。
でも、技術者をないがしろにしていると、いづれ第2第3のポカミスをするだろう。まぁ、その時は求人サイトに安い給料の奴隷募集を恥ずかしげもなく出すのであろう。
妄想です。
大企業や銀行で、昔から動いている基幹システムは、大抵メインフレームにCOBOLの組み合わせである。
それをここ十年くらい、リプレースでx86系サーバにJavaという構成に変更することが多い。
しかし、ハードが汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。
ぶっちゃけCOBOLはCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは？と思うのだ。
その理由はこうだ。
COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。
勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOLの文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである。
そういうモノが既にある企業や銀行の文化において、当然発注側は担当者からお偉いさんまでCOBOLer系フローチャート脳だし、新しいシステムの設計でもそれを踏襲しようとする。
というか踏襲すること前提じゃないと設計書をレビューできない。
UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。
というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法の設計書で処理を組み上げざるを得なくなる。
そうなると、実装もフローチャートの設計を基にコードを書くわけだが、こういう設計はハッカー文化で発展してきた言語(Fortran→C/C++→Javaという流れと、PerlからPython・PHPというインタプリタ系の諸言語)との相性が最悪である。
設計とは実装を楽にするために書くのに、これらの言語において、フローチャートの設計は役に立たないどころか、邪魔でしかない。
だからFortranしかなかった頃から、本物のプログラマ達はフローチャートをdisってきたわけである。
ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である。
しかし、「普通の人達の普通の思考」からはかけ離れ過ぎているという意味で、「普通の人達の普通の仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。
…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLかアセンブラを選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。
というわけで、自分はCOBOLからのリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。
目標も高いし仕事量も膨大で、部下の労働時間もながかったし精神的負荷も高かった。
特に誰か一人でも失敗するとその事業は潰れるという意識が浸透していたし（まぁ実際にそのとおりだったので）、全力で頑張ってた。士気は高かったと思う。深夜に仕事が終わってから飲みにいって仕事の話したりしてた。
10人ぐらいのチームだったけど、1年で2人がうつになり離脱した。
1人はチームの営業を全部うけてた優秀な人。もう1人は若い女性エンジニアだった。
2人とも労働時間はそこまで長くなかったので、与えられた仕事や責任が大きすぎたのだと思う。
残業時間は限定し、仕事は負荷が高くなりすぎないように注意し、困っていたら手助けをした。過保護なぐらいに。給料も大企業並みにした。
おかげで社員の休日出勤は今まで一度もないし、休暇もとりたいときに取れるし、帰りたければ定時でも帰れるし、22時を超えた残業は過去1年一度もない。役員は週末も深夜も関係ないけど。
とはいえトラブルは週末も深夜もおきるので、それに対応するために役員が全体を把握している。
すると権限移譲は行われず、責任は役員に集中し、社員は手足以上ではなくなった。
深夜対応できるということは、昼間でも対応できるわけで、ようするに社員は全てリプレースが可能な状態になった。
しばらくして進捗を聞くと、まったく進んでなかった。
なによりの問題は士気も低いし仕事が楽しくなさそうだということだと思う。
前の仕事は苦しかったが未だに週末に全員で集まってバーベキューしたり困ったら相談しあう仲間になっている。
ほとんどのメンバーが今は転職しているが、そのときに出会った仲間で仕事の融通がおこなわれたり、紹介しあったりと信頼関係がある。
いまの会社は誰かがやめたら連絡をすることもない。
うつに陥ったことに気づけなかったのは未だに後悔するし、そうしないようにしたいと思う。
ちなみに二人とも今はバリバリ働いてる。一人は起業してうちより大きい会社になってる。
最近、過保護にしすぎたせいで成長の芽をつんでしまったと思う。
とくに今後のキャリアを考えると大事な時期にそういう状態にしてしまったことは反省してる。
人をつかうのって難しいね。
当方は情報システム部に属しており、社内のインフラのサポートをしている。
無線LANのアクセスポイントは、同一フロアで全部で４台あり、全て固定チャンネル設定をして運用している。
４台のウチの２台ー３台が、この様なログを履いてチャンネルが変わってしまう現象に襲われている。
2016/07/22 16:15:13: [802.11] Radar found on channel 64
2016/07/22 16:15:13: [802.11] Changing to channel 40
2016/07/22 16:15:13: [802.11] Changing to channel 40 (5200 MHz) chanStart 64
Channel 40 に切り替わる設定はどこにも記述ないので、どこから出てきた？と。
自動でチャンネルが変わる記述は無いと思っているのだが、皆目検討つかない。
Configurationの読み込み直しのためにRestartも何回もした。
Firamwareは、バージョン：Rev.12.00.16 最新ではないが、最新までのRelease notesはチェック済みで該当してそうなものはなし。
困り果てて、バグかと思いY社サポートに問合せを入れるも１週間連絡がない。
１）受付番号を聞かれ、返答すると、そのような問合せは無いと当初言われる。
→これサポートで問合せ受領して、勝手にCloseしてんじゃねーかな。
先日は１両日には返答頂いておりましたが、最近は問合せが立て込んでいる。という事でしょうか？と質問するも
→「そんな事は無いが、返答できない。」との事。
→「返答できない。」との事。
こんな感じなので、解決時期の見込みもたてられない。
３）とても困っているので対応の優先度を上げてもらえないか？とお願いするも断られる。
まぁ、こちらとしてもY社の機器を購入すると付随する保守サービスに加入しているだけで、Additionalで費用を負担しているワケでもない。
また、Y社のサポートセンターにSLAが定義されていないので、こちらとしては明確に期限を要求できるワケでもない。
ぶっちゃけ彼らが返答に誠意を見せない。と、言われてしまっては、結局何やっても無駄なんだよね。
サポートの出来によって、その製品を使い続けるかどうかの判断になるのにね。
世の中的には、チャットサポートがデファクトになりつつあり、そのアジリティに比べると旧態依然した大企業のサポートだな。と思ったわけで
全てを悟った私はおとなしく他社製品でリプレースすることを決めた。
＃もし、原因のヒントがあれば教えて頂ければ幸いですｗ
ーーー追記ーーーー
DFS機能により使用しているチャンネルが変更される時、選択されるチャンネルの範囲を指定します。と、あり。
この定義を全て削除していて、実質切り替えできない認識でいた。
Configには表示されないが、暗黙デフォ値（airlink channel range dfs all）が使われている理解で良いのかな。
とはいえ、切り替わっても、使ってないチャンネルの中から定義して上げれば良いことに気づいたのでそれで運用しようと思います。
今日も日本の何処かで、基幹システムのリプレースが行われている。
基幹システム…そう、古くは汎用機にCOBOLという、枯れるを通り越してまさに朽ち果てんとしているアレだ。
そもそも朽ちて土に還る前に建て直すためのリプレースだ。
てか朽ちないんだったら、もう半永久的に触るべきじゃないと思うんだけど、形あるものは必ず滅びるのだ、作り直すしかない。勘弁してくれーという感じだ。
じゃあ何を用いて作り直すか？またCOBOLが一番手っ取り早そう(ソースいじらず移植という意味で)だが、それは許されないのだそうだ。ふざけんな。
今だったら大体どこでもJavaで作り直しだ。どういうわけか今のトレンド()だ。
てかそれ、オブジェクト指向とWebアプリに夢見過ぎじゃね？別にそれ銀の弾丸でもないしエクスカリバーでもなければ伝家の宝刀でもない、ただの道具なんですけど。
その証拠に、色々共通化されて保守性も拡張性も格段に上がったとか言ってる割に、その実態は、数える気にもならないほどインターフェースをimplementしまくった、複雑怪奇なクラスファイルの乱立ですよ。
もちろんドキュメントも上から下のレイヤーまで、そのクラスの分だけ揃ってる。というか山のようにある。いやそれ分量的に読めねーから。
ちなみに、今時の銀行や大企業は、基幹システム一つだけなんて事は無いケースが多い。基幹システムは複数あって相互に通信する巨大システム群の中の一つに過ぎなかったり。
そこで基幹システムだけ今風に作り直した所で、コスト増大の根本原因である複雑さの解消に、微塵も貢献しているとは思えないのだが、その質問はダメらしい。
もうさ、ぶっちゃけちゃうと、そもそも人間という柔軟な脳を持つ生き物がこなしている業務を、人間より正確かもしれないけど全く融通が効かないコンピュータに代替することが限界なんじゃね？と思うんだわ。
基幹システムを見ていると、そんな暗澹たる気分になる。
そりゃCOBOLと汎用機しか選択肢のなかった時代から比べて、今は色んなソリューションやソフトウェアがある。どれもシンプルに造るため、分かりやすく造るためにある。
しかしこの国の基幹システムは、それでもなお複雑さを解消していない。
あるいは、そういう大きなシステムを抱えている日本の組織性の問題なんですかね？
爆発しなくてもいいから、Google辺りに生息している本物のプログラマが、そういう複雑さを一気に解決するような、黒船もびっくりなソリューションで、今のITゼネコンありきのSIの世界に風穴を開けてくれることを切に願う。
中小企業勤務のど素人です。平均年齢40歳くらいの昭和からある非IT企業です。
前任者が退職して、他に出来る人がいないという理由で、自社HPのインフラを担当することになりました
個人でレンタルサーバーのVPS契約してLAMP環境構築して、ごく単純なWEBサービスを公開していますが、
ググってでてきた手順を見よう見まねでやったので、基本を理解できてないので、怖いです。
WEBサーバーもDBサーバーもファイルサーバーも一緒の１つのサーバーです。
会社のサービスは、今までは会社にサーバーを置いてやってました。
リプレースが大変なのと、AWSはWEBサービスの業界標準のようなので、迷うことなくAWSにしていきたいです。
一人でやるのは怖いので、無理ですといったのですが、押しつけられました。
中小企業勤務のど素人です。平均年齢40歳くらいの昭和からある非IT企業です。
前任者が退職して、他に出来る人がいないという理由で、自社HPのインフラを担当することになりました
個人でレンタルサーバーのVPS契約してLAMP環境構築して、ごく単純なWEBサービスを公開していますが、
ググってでてきた手順を見よう見まねでやったので、基本を理解できてないので、怖いです。
WEBサーバーもDBサーバーもファイルサーバーも一緒の１つのサーバーです。
会社のサービスは、今までは会社にサーバーを置いてやってました。
リプレースが大変なのと、AWSはWEBサービスの業界標準のようなので、迷うことなくAWSにしていきたいです。
一人でやるのは怖いので、無理ですといったのですが、押しつけられました。
