「オンプレミス」を含む日記 RSS

はてなキーワード: オンプレミスとは

2021-04-15

VMwareDellより分離独立の件

機械翻訳です。

#####

ヴイエムウェアとデルテクノロジーズ、スピンオフについて合意

デルテクノロジーズ、VMwareの81%株式スピンオフし、VMwareさらなる成長につなげる

Dell Technologiesとの戦略的パートナーシップを維持しつつ、VMware戦略的および経営的な柔軟性をもたらす

VMwareは全株主に対して115億ドルから120億ドル特別配当実施し、投資適格格付けを維持する予定

カリフォルニア州パロアルト--(BUSINESS WIRE)--(ビジネスワイヤ) -- 独立取締役構成されるVMware(NYSE: VMW)特別委員会デルテクノロジーズは、VMwareデルテクノロジーから分離独立させる条件に合意しました。この条件には、企業の所有構造の大幅な簡素化と、独立した特別委員会が推奨し、VMware取締役会がスピンオフの直前にすべてのVMware株主に対して宣言した115億ドルから120億ドル特別現金配当が含まれており、すべての閉鎖条件が満たされることを条件としていますDell Technologiesの株主は、Dell Technologiesが保有するVMware株式比例配分で受け取ることになり、Michael DellとSilver Lake PartnersはVMware株式を直接保有することになります。また、両社は、共同で顧客価値提供するための戦略的パートナーシップを維持・強化する商業契約を締結しました。

ヴイエムウェアのビジョンは、あらゆるクラウドハードウェアインフラ対応したユビキタスソフトウェアおよびSaaSプラットフォームを構築し、顧客デジタルトランスフォーメーションを加速することです。デルテクノロジーからスピンオフにより、ヴイエムウェアは、両社の戦略的パートナーシップの強みを維持しつつ、戦略実行の自由度を高め、資本構造ガバナンスモデル簡素化し、戦略運用財務の柔軟性を高めることができます

"ヴイエムウェアの最高財務責任者(CFO)兼暫定最高経営責任者(CEO)であるゼイン・ロウは、「当社は、すべてのクラウドベンダーおよびオンプレミスインフラベンダーに当社のエコシステムを拡大する能力を強化し、成長機会を支援する資本構造を持つことになります。"デルテクノロジーズとの戦略的パートナーシップは引き続き当社の差別化要因であり、マルチクラウド戦略の実行に伴い、あらゆるパブリッククラウドとあらゆるインフラストラクチャ上で、お客様に当社のソリューションサービス提供していきます」と述べています

2020年7月15日に提出されたDell TechnologiesのSchedule 13D修正に関連して、VMware取締役会は、Dell Technologiesの提出書類記載されたビジネスチャンスに関するDell Technologiesから提案可能性を検討評価するために、法律顧問および財務顧問を起用した独立取締役からなる特別委員会を設置しました。特別委員会は、VMware社の取締役会による本取引および特別現金配当承認評価し、推奨しました。

"VMware特別委員会は、今回のスピンオフ契約が、簡素化された資本構造確立し、VMwareがその戦略を実行する上で有利に働くことで、すべての株主利益をもたらすもの確信しています」と、VMware独立取締役会の筆頭メンバーであり、特別委員会メンバー報酬コーポレートガバナンス委員会委員長であるPaul Sagan氏は述べています

"ヴイエムウェアの取締役会長であるマイケルデルは、「ヴイエムウェアをスピンオフさせることで、デルテクノロジーズとヴイエムウェアにさらなる成長機会をもたらし、ステークホルダーに大きな価値をもたらすことができると期待しています。"両社は今後も重要パートナーであり続け、お客様ソリューション提供する方法において、差別化された優位性を持っています」と述べています

ヴイエムウェアとデルテクノロジーズは、この商業契約を通じて、顧客戦略的価値提供するソリューション共同開発継続し、デルテクノロジーズはヴイエムウェアの製品ポートフォリオ市場規模提供します。

今回のスピンオフにより、VMwareは、成長戦略を推進するための戦略的運用的、財務的な柔軟性と俊敏性を高めることができます。これには、資本配分の決定の簡素化や、現在デュアルクラス株式構造廃止などが含まれます。また、VMware社は引き続き投資適格の格付けとプロファイルを維持します。

ヴイエムウェアが全株主提供する115億ドルから120億ドル特別現金配当推定額は、2021年3月16日時点の発行済み株式に基づいて、1株当たり27.43ドルから28.62ドルとなっています

この取引は、一定の条件のもと、2021年暦年の第4四半期中に完了する予定です。

投資家向け電話会議

VMwareは、2021年4月14日午後5時45分(米国東部時間)より、本取引の詳細について説明するインベスターコールを開催します。このイベントライブWeb放送は、VMware投資家向けウェブサイト(http://ir.vmware.com)でご覧いただけますウェブ放送にはスライドが添付されますウェブ放送スライド再生は、同ウェブサイトで2ヶ月間公開されます

VMwareについて

ヴイエムウェアのソフトウェアは、世界の複雑なデジタルインフラストラクチャを強化します。クラウドアプリケーションモダナイゼーションネットワーキングセキュリティデジタルワークスペースなどのサービス提供することで、お客様があらゆるクラウド上であらゆるアプリケーションをあらゆるデバイス提供できるよう支援していますカリフォルニア州パロアルト本社を置くヴイエムウェアは、画期的テクノロジーイノベーションから世界への影響まで、「良い方向に向かう力」となることを目指しています。詳細については、https://www.vmware.com/company.html

追加情報とその入手先

VMwareは、株主承認必要とする特定の事項の承認に関して、Schedule 14Cによる株主向けの情報提供書を作成します。情報提供書は完成後、当社の株主に郵送されます。この取引に関してVMwareSECに提出したすべての文書コピーは、SECウェブサイト(www.sec.gov)またはVMwareウェブサイト(https://ir.vmware.com/)から無料で入手することができます

将来の見通しに関する記述

プレスリリースには、提案されているスピンオフの予想時期、完了効果および利点、特別現金配当の支払い、規模および1株当たりの金額VMwareの将来の投資評価およびプロファイルスピンオフ後のVMwareデルテクノロジーズの戦略的パートナーシップ商業的取り決めおよび協力関係VMware事業戦略およびビジョン、将来の成長機会に対する期待など、将来の見通しに関する記述が含まれています。これらの将来の見通しに関する記述は、1995年米国私募証券訴訟改革法によって創設されたセーフハーバー条項対象となります

VMwareは、

(1)分離・分配契約の終了の原因となる事象、変化またはその他の状況の発生、

(2)特別現金配当のための十分な資金源の確保の失敗、

(3)VMwareのその他の失敗、

(4)その他の要因により、提案されている取引上記の条件またはその他の受け入れ可能な条件で、または全く完了できない可能性があります

(3)その他、VMwareまたはDell Technologiesがスピンオフ完了および特別現金配当の支払いのための契約条件を満たさないこと、

(4)VMware特定格付け機関基準を満たさないこと、

(5)スピンオフおよび特別現金配当の発表がVMwareおよびDell Technologiesの戦略的および商業関係に与える影響、ならびにVMwareが主要な人材を維持・雇用し、顧客との関係を維持する能力に与える影響。6)COVID-19パンデミックVMware事業財務状況、VMware顧客ビジネス環境世界経済および地域経済に与える影響、

(7)一般的経済状況または市場状況の不利な変化、

(8)消費者政府情報技術への支出の遅延または削減、

(9)価格圧力業界統合仮想化技術への新たな競合他社の参入などを含むがこれらに限定されない競争要因。10)買収した企業資産VMwareに正常に統合し、VMwareから売却した資産に関連するサービスを円滑に移行する能力

(11)仮想化ソフトウェアおよびクラウドエンドユーザー、エッジおよびモバイルコンピューティングセキュリティおよびテレコム業界における急速な技術革新、

(12)仮想化ソフトウェアおよびクラウドエンドユーザー、エッジおよびモバイルコンピューティングセキュリティおよびテレコム業界における急速な技術革新。

(12) コンテナ化、最新アプリケーション本質的セキュリティネットワーキングクラウドデジタルワークスペース仮想化通信とエッジ・コンピューティングソフトウェア定義データセンターなどの分野で、VMware顧客が新しい製品プラットフォームサービスソリューションコンピューティング戦略に移行する能力、および顧客が新しいテクノロジーを受け入れる際の不確実性、

(13) VMwareスピンオフ後に戦略的効果的なパートナーシップを締結し、協力関係を維持、拡大する能力

(14)訴訟規制措置継続的なリスク

(15)専有技術保護するVMware能力

(16)製品サービス開発スケジュールの変更、

(17)サイバー攻撃情報セキュリティデータプライバシーに関連するリスク

(18)主要な経営陣の交代による混乱。19)為替レートの変動や貿易障壁の増加など、国際的販売に伴うリスク

(20)VMware社の財務状況の変化、

(21)VMware社とDell Technologies社それぞれの財務状況や戦略的方向性の変化により、VMware社とDell Technologies社の商業関係市場開拓のための技術協力に悪影響を及ぼす可能性があること。22)VMwareDell Technologies の商業関係および市場開拓技術提携におけるスピンオフと変更が、顧客サプライヤーとの関係を維持する VMware能力、および VMware経営成績と事業全般に及ぼす影響、

(23)配当基準日における VMware の発行済株式数、および

(24)SEC に提出した当社の定期報告書および現在報告書の「リスク要因」のセクションで述べられているリスクなどです。これらの将来の見通しに関する記述は、本プレスリリースの日付の時点でなされたものであり、現在の予想に基づいており、不確実性や状態重要性、価値効果の変化、およびVMwareが随時提出するForm 10-KおよびForm 10-Qの最新のレポートやForm 8-Kのカレントレポートを含む、米国証券取引委員会に提出された文書に詳述されているその他のリスクがあり、実際の結果が期待と異なる可能性がありますVMwareは、本リリースの日付以降、そのような将来の見通しに関する記述更新する義務を負わず、現時点ではその意図もありません。

businesswire.comでソースバージョンを見る: https://www.businesswire.com/news/home/20210414005849/en/

ポール・ツィオット(Paul Ziots)

VMware Investor Relations

pziots@vmware.com

650-427-3267

マイケル・タッカー(Michael Thacker)

VMware Global PR

mthacker@vmware.com

650-427-4454

Source: VMware, Inc.

2021-01-22

anond:20210122103749

そういう意図であればインスタント(即時・即席)あたりが適当じゃないの。

オンデマンドって単語を使うなら、それまで需要に応じず一方的に与えられるとか垂れ流されるような、自由に利用できない状況があった上で、その一方向性に対する問題意識が共有されてないとそういう表現は出てこないと思うが。

もしくはオンプレミス疲労スキャンをするような技術を内製し所持する組織存在していることを前提として、その反対としてその同等技術クラウド化され万民が使えるようになった状態という意味でならオンデマンドという言葉が出てくることも想像できるが、脳の疲労度なんて漠然としたもの一方的にあるいは閉じた組織内であっても計測・数値化する技術確立済みの社会状況は存在してないんだから、突如オンデマンドという表現が湧いてくるのは違和感がある。

2020-04-11

anond:20200411184359

中国クラウドは、すべての情報政府に筒抜けです。

から自社でオンプレミス運用を好む会社も少なくありません。

また、中国クラウド国内客と海外客で提供できるサービス価格帯もすべて違います

2020-04-10

ネット会議禁止する情報監査室ぶっ転がしたい

先に言っておくが、無茶苦茶フェイクをいれているので、これを読んで具体的な会社名が浮かんできたとしてもそれは間違っている。

違っているんだ。いいね

三行で言うと

事の経緯

弊社には情報監査室というクソみたいな組織があります


ここはIT効率化をことごとく妨害するという非効率的な行為業務の中心に置いており、新しいツールを導入するとか言うときにそれがITガバナンス(笑)合致するかどうかを監査するという足の引っ張り合いを行います


従来も様々なソフトウエアサービスの導入をことごとく妨害し、今時クラウド系のサービス基本的に了承しない、自社基準に従った監査レポートが出て承認しないとダメなどと言い張るというクソみたいな組織


さて、ここが、Zoom禁止令を出した。まぁ、これは仕方がないだろう。わからんでもない。


しかし、それ意外のネット会議システム許可しないというのである



元々、弊社ではOffice 365を導入済みで、Microsoft Teamsが利用できる環境であった。が、これに待ったをかけたのがこの情報監査室。曰く、デフォルト情報共有ができる仕組みがダメだとか。


は?馬鹿かお前。


それで、単機能なら許すという事になり、単機能特化型のZoomをわざわざ購入した。

管理職の決裁を得た上で、実施時は上司が必ず監視する事を条件に(こんなルール守られるわけがなく事実上骨抜き)認めたという経緯がある。

しかし、Zoomセキュリティ問題だと言うことになってダメになった。


では、Temasの方がよいのではないか?と言う話をしたらこれもダメだという。

WebExとかMeetとか言ったら、似たようなシステムはもう信用ならんから、なんであろうと情報監査室が安全だと判断しないので許さないという。


馬鹿だろこいつら。


そもそも、奴らはネット会議をよい思っていないよう。

ただ現場から突き上げが来て容認した経緯がある。

そこで、Zoomセキュリティ問題が発覚して「ほれみたことか!」と一気に規制を厳しくしようとしている。


前は、客先から求められた場合ZoomであろうとTeamsであろうとMeetやWebExであろうと、上司の決裁と情報監査室の承認があれば許可という話だった。

それが、なんと最近になって、Zoomが串を通らなくなり、接続ができなくなった。


客先には「セキュリティ関係でうちはZoomダメです」と言って了解を得ろと。しかし、それだったら、かわりにうちはWebExなりTemasなりMeetなりを使ってるので、こっちでお願いできませんかと自社で開催するのが筋だろう?

それを許さないんだって(笑)


もうぶっ転がしたい。


情報監査室は、元々物理的にデータを紛失した事故があって、それに乗じてできた組織なのだが、やたらと「仕事してますアピールうまい連中で、日々せっせとセキュリティ問題ニュースを集めては、それを上層部にレクしている。それが弊社に関係ある案件なのか、実際に事故があったとか全く無視で日々脅しを書けている。


からといって技術があるわけでも、ポリシーが一貫している訳でもない。

セキュリティ関係機器情報監査室の管轄だと言っているが、実際に自分たちで設定する能力がないので、そこはありがたくも紙で下達される文書を読み取って担当者が設定する。

OneDrive個人用だから使用許可するが、SharePointオンプレミスじゃないと監査ができないため(は?)使用許可しないとか

かいっても、もうちょい細かい制御ができるBox許可しないとか

一時は「クラウドストレージ危険CDで焼いて郵送せよ。海外データ便を推奨」とか言っていた事もある。

また、弊社オリジナルセキュリティ監査要求するため、そんなことにいちいち対応しない大手は使えない。そのため利用しているのは中堅以下の小規模SIerが細々と運営しているデータセンターで、そもそもその会社自体ISOもとってない、という矛盾が起きている。

そこに、自社で持ち込んだ自社所有のハードウエアがずらーっと置かれている。その中にはサポートの切れたWindowsサーバなどがあるが、情報監査室の監査体制下にあるセキュアなエリアにあるから安全なんだと。○ね


だれかこいつらをぶっ転がす方法を教えてくれ

こう言う硬直した連中を説得した経験のある人、どうやったら動かせた? 何か教えていただけるとありがたいです。

2019-07-26

ダイキギョー(東証二部以上)で「好きなことをして生きていく」って

無理じゃんスか?

コンプライアンスとか、セキュリティとか、ガバナンスとか、空気読めとか。

二部上場以上のキギョーで、クラウドサービス(slackとかオンプレミスじゃないweb上のサービス)を好き勝手使えるところって、どれだけあります

普通社内規定だのコンプライアンスだので禁止されてるよね???

閉じるメリットはわかるよ?リスクもわかるよ?そこそこのメーカーで、発表前の製品情報なんて微塵も表に出したくないよね。

でもさ、それがお前らがよく口が臭くなるほど誰が口臭いねん!!あごめん、口が酸っぱくなるほど言ってる「リクス」の驚異にどれだけなるの?

誰もお前のことなんか見てないよ?「おー自意識ーwww」ってネモ(「私がモテないのはどう考えてもお前らが悪い」の根本さん)にツッコまれるよ?

多分名だたる大企業はみんなこの悩みを抱えていると思うけど、

リスクに対する攻めの姿勢世界基準よりかなーり低いと思うのよね。クールジャパンのみなさまは。

品質コアコンピタンスにしたいのは俺も賛成なんだけどさ…。

それにしても、その伊達矜持を保ったまま、もっと攻めても大丈夫だと思うよ。

そういうことを考えてくれるIT特化の政党、ないしは自民派閥でも(最悪)いいよ、出てくれたら支持するんだけどな。

2019-07-05

日立子会社SIer)を退職しました。

2019年6月を持ちまして、大学新卒入社後約7年勤務した会社退職しました。

良い機会なので記録に残したいと思います

スペック

地方国立大学工学部情報科卒。保有資格基本情報応用情報技術者

入社理由大手っぽかったため(何も考えてない)。

会社業務概要

日立製作所の子会社としてシステム開発運用保守、構築を担う会社

社員数は2~3000人。

入社してから運用、構築業務を行い、開発は未経験担当したシステムの分類は公共系のみ。

基本的には「客先常駐」で、システムが安定稼働に入った段階で別のプロジェクトに参画し、構築を行った。

身についたスキル

インフラ設計、構築

サーバ構築(オンプレミス業務としてOSMWの導入に携わることで、構築に必要知識を得られた。

ちょっと残念だったのが日立製品(JP1、uCosminexus Application Server)に携わる期間が長かったこと。

他社のAPサーバWeblogicJboss等)も触れ、インフラ屋さんとしての価値を高めたかった。

マネジメントスキル

力不足ではあったが5年目ごろから小さいチームのリーダになり、進捗管理顧客調整等を行った。

チームは3~5人でプロパー1人(私)、他は協力会社構成

協力会社メンバーは全員年上で、コミュニケーションにおいて苦労した部分もあったが、

人に恵まれ、大きな問題なくプロジェクト遂行できた。若いうちにリーダーを経験できたことはとても良かったと思う。

給与

最終年度で約560万。

◆内訳

 ・基本給 :26万

 ・扶養手当:2万(子ども二人)

 ・残業手当:8万(平均30時間/月)

 ・賞与  :約60万(年2回で業績により若干増減あり)

残業代は基本全額支給のため、それによって年収は大きく増減。

そのため、仕事がないのに残業するという所謂生活残業」をする人も少なからずいる。

また、最近働き方改革で定時退社を励行しているため、残業についてはかなり厳しくなっている。

昇給・昇格

昇給は若干ではあるが、たぶん毎年した。

昇格については、早い人で8年目から主任、15年目くらいで課長になる。

主任年収が600~800万(残業による)、課長年収が900~1000万。

主任まではある程度の実績とポイント資格等)があれば誰でもなれる(はず)。

ただ、課長以上になると「上が詰まっている」&「製作から下ってくる」ため、相当優秀でない限りはハードルが高いと思う。

劇的に仕事が増えて部&課が新しく作られれば話は別だが。

働き方

プロジェクトに合わせる形になるが、フレックスのため勤務体系が自由

上述の通り、残業についても働き方改革で定時退社を励行しており、男性の育休取得も推進している。

環境についてはシンクラ端末が一人一台支給され、インターネットがつながる場所であればどこでも仕事ができるという状態

どこでも仕事ができてしまうため、公私のバランスがとりずらいという方もいるかもしれないが、私にとっては最高でした。

これさえあれば在宅勤務も可能なので、娘が熱を出し保育園に行けないときは重宝した。

また、複数拠点サテライトオフィスがあり、社員証があれば使用できるため、打合せで移動が多い日はよく利用した。

働きやす環境作りにはかなり投資されているため、恵まれ環境仕事ができたと思う。

退職理由(順不同)

残業しないと給料低い。また、担当レベルだと成果を出した人とそうでない人で給与の差がほとんど付かない。

・新しい技術に関する感度が低い。

意識低い系がそこそこ多い。そしてその人たちは決して辞めない。優秀な若手はどんどん辞めていく。

SIerあるあるかもだが、協力会社に丸投げのプロジェクトがけっこうある。

・道半ばなのは重々承知なのだが飽きた。

SIer自体の将来性のなさ。

まとめ

転職先は事業会社IT企画部です。次が身の丈があった環境かどうか不安もありますが、新たな環境にワクワクしています

次の会社で働いてみて、前職の良し悪しもさらに見えてくると思うので、また気づきがあれば書きたいと思います

2019-05-27

「象の墓場」読んだ。ロケット飛ばしたり銀行で成り上がったりするような話に比べたら地味すぎるけど、その分リアルもっと言えば全く動けないつらみしかない。

Red Hatって十年前はエンタープライズでも下回りのインフラ屋さんしかいたことのなかった企業だったと思うが(自分カーネル弄ってたかメーリス名前知ったけど)

今や猫も杓子もOpenShiftめっちゃ盛り上がっている。先日のパートナー向け懇親会は大盛況だったと聞くし。ロゴの変更でニュースになったのがいい証左だ。

RPAは早くもシュリンクしつつあるけど、当時流行ったときはバックオフィスだし、関係ないしとスルーしてた。

でもOpenShiftは関わり深いんだよな。マネージドOpenShiftってなんだよ、オンプレミスそんなにしてまで滅ぼしたいのかよ。自鯖ますますモテないのかよ。

おっさんエンジニアにはつらい時代だ。k8s資格取らないとな。

会社から戦略費出ないとトレーニング合わせて丸々5万飛ぶけど取らないとな。

2018-11-30

ユーザーIT企業退職しました

会社概要

仕事について

技術的なところ

退職理由

会社には勉強するという文化がほぼありませんでした。これは新卒からベテランまでほぼ一貫しています

また納期遅れしないプロジェクト経験がないといってもいいほどですが、相手グループ企業なのであまり納期厳守ということもなかったです。

ユーザーのやる気も高いとは言えず、システムリリースするまで触ってもらえず、リリース後に要望が大量に来るというのがほとんどでした。

人間関係はよく待遇もよく働きやす環境ではありました。

ただ、自分の中で何に対してお金をもらっているかというところで自信が持てなかったです。

から、今度はもうすこしユーザーに近い距離で働いてみたいと思い、退職しました。聞いている話だと、地方だと技術セットがほぼ同じ会社が多いので都会にでも出てみたいかなと感じています

2018-09-11

NECで何が起きているのか

かつて日本代表するPCメーカー、そしてシステムインテグレーター大手6社に数えられるNEC。それを退職した今、機密に触れない程度に、特に研究所の裏事情説明していこう。おそらく製品部門は違う苦しみを抱えているだろうが、高額なボーナスもらってるんだから耐えてくれ。

IT音痴研究所トップ

私が入社したのは、研究発表でのいわゆる一本釣りだった。釣りあげた部門も、当時の研究比較的近かったため、給料をもらいつつ研究ができる、という不純な動機があったのは確かだ。大手特有研修体制も魅力に感じた。

雲行きが怪しくなったのは1年目の夏である。当時研究所トップであるE氏による、研究発表の総評の場で「まだそんな研究していたのか」という発言だった。NECシステムインテグレーションといえば、重要事業の柱であり、事業からの引き合いも非常に強かった。折しも、AWS日本国内での事業が躍進し、オンプレミスとは違う流動性の台頭に、研究テーマとしては佳境の段階であった。そこに貢献するミッションは他の研究テーマでは代用できないものである

それをE氏は「そんな研究」と一蹴したのだ。翌年、予算はつかず、研究チームは文字通り解散となった。そしてシステムインテグレーション研究NECから完全に姿を消すことになった。E氏は光通信の元研究者で、正直なところなぜ偉くなったのか、今でも疑問であるが、少なくとも大のつくIT音痴であることは仲間内では有名である。それこそ当時はデータベースとは何か、すら知らなかったようである

E氏が理解できる、できないはあったにせよ、そして価値提供方法まで突き詰めて考えられていたかは怪しいけれど、少なくとも、なんのためにやっているのかわからない研究ではなかった。「バイオプラスチック 漆ブラック」などいった、海のものとも山のものもつかぬものより劣っていたのだろうか。カーボンナノチューブ研究すらまだ留保しているのに。

そしてE氏はNEC常務となり、CTOとなった。社内では最高級(給)のブロガーと称され、「未来について考える」だとか、「~について意識しなければならない」といった、きわめて抽象的、かつ薬にも毒にもならないビッグワードを垂れ流し、評論し、何かをいっているようで、実際には何ひとつ具体的な行動や指示を出せない人物である。そして未来創造会議というような、何ら結論の出ないもの露出するようになった。あれを見た人は、NECが何の会社なのかわからないだろうし、それは製品として何を提供するのかすら伝わらないだろう。漫画雑誌企画会議ですらもっとマシなものだろう。

実を結ばない研究

研究所といえば、技術部門の花形、と思われる人もいるかもしれない。事実、優れた技術はほぼすべて研究所であるしかし、本当に優れた技術NECから広報には載らず、社外からの引き合いが先行する。なぜなら、広報インパクトが優先され、そして広報ノルマを充足するために実施されるからだ。そして時には大きな「事故」となる。

数年前、橋梁構造物劣化診断という技術日経新聞掲載された。これは固定カメラ画像撮影し、振動による変化で構造内部の劣化モデリングし、内部ひび割れ可視化するという画期的ものであった。事件の発端は、その研究途上であった技術に対し、研究所理事(*2)がメディアの前で口を滑らせたこである。当然注目され、実用目途についてまで発表することになった。実際には理論検証完了し、クリアしなければいけない項目の洗い出しの最中であったという。1年後を目途とされた研究テーマは、その後研究所から姿を消した。撮影には非常に繊細な取り扱いが要求され、撮影時の振動に弱いという欠点を克服できなかったと思われる。これは当時画像診断系の学会でも度々指摘されていたもので、研究者の間で共通認識であったが、残念ながら理事には理解できなかったようである

談合事件役員人事

ここ数年のNECもっとインパクトがあった事象は2件の談合による指名停止であろう。煽りをくらい、全く無関係研究所予算がまずは削減された。そして賞与が大幅に減額である。社内ですら、談合当事者やその上司名前は完全に秘匿され、明に責任をとった人物存在しないことになっている。おそらく、公表した場合、全社員から報復を受けることを恐れたのであろう。

すると、不透明な人事はいたるところにあることに気がつく。前期の大幅に未達だった中期計画責任者だった遠藤社長会長になり、その策定の中心人物だった新野副社長社長となった。そして次の新中期計画は1年目でとん挫したにも関わらず社長以下留任ときたもんだ。

グローバルビジネスの低迷。これからNEC生命線とまで言われていたグローバルBU。彼らは海外売上比率を25%を目指すと宣言していた。中期計画に対して、何ひとつ貢献できずKPIを外したそのトップ、真っ先に責任を取らなければならない人物M氏は、翌年副社長となった。その自浄作用の無さもさることながら、株主債権主の銀行は一体何を考えて、彼らの役員人事を承認しているんだろうか。株価は買値の1/10となった、もう値動きすら見たくないから早く潰れてくれ、と思っているのだろうか。

今後、NECは暗黒の時代を迎えるだろう。折しも今年は3000人のリストラを掲げ、断固と構造改革を実施する覚悟を強調する新野社長しかし、彼にあるのは覚悟だけであり、スタッフを減らす方策すら定まっていないだろう。現状、10人が事業仕事をし、8人が彼らの事務担当するような人員である。そして今回の早期退職は主に事業の主力たちが手をあげるようである

最後

思えば、個人努力が何に対しても反映されず、学習性無気力に苛まれ続けたNECライフであった。管理能力に長けた上司はおおむね本社接収され、帰ってくることはなかった。そして残ったのは、管理職不適格でありながらも、降格制度存在しないことによる吹き溜まりである会社学会仕事をしにきている主幹研究員なる人種もいれば、1時間前の記憶すらないような痴呆老人である。そんな中、近頃はカルチャー変革(*3)を謳っているようだ。NEC暗黒時代たる本質まで踏み込み、ぜひNEC再生していただければと思う。

(*1)ビジネスマナー研修思想教育といったものからディスカッションなどがあったが、参加者講師レベルが低く、こいつら大学出てるのかすら怪しげだった。彼らが同期となって、社内キャリア形成意味もつ存在だと思うと、ぞっとした。さまざまな節目に集合研修は行われたが、効果を測定する様子もなく、ただそこに予算があり、研修実施することが担当者の評価だ、というような空気であった。そしてその直感は、NECスタッフ部門全体に共通するものであると後にわかる。

(*2)理事とは事業部長、本部長、中央研究所傘下の研究所経験者で、様々な理由部門消滅したりすると発生する役職である最近では、関西研究所CCII本部長、シンガポール研究所歴任し、価値共創センターを立ち上げ、これらのすべてを失敗させたY氏が理事となっている。彼らは理事になると、「天下り」先を探すことがメインの仕事になる。そして彼らが天下れば、空席となった理事は別の元所長が補充される。

(*3)カルチャーは変革できても、働き方全般違法裁量労働たるVワークの制度は変えられないだろう。また社員モチベーションを上げるための施策は、すべて人事部門判断によって握りつぶされると思われる。総務部人事部門抵抗をどのように回避するのか、外様役員の腕の見せ所だろう。

2018-05-02

anond:20180502002250

AWSはただのインフラからどう使うかは各企業による

オンプレミスとの違いは、

AWS使用量に応じた課金から利用頻度により

繁忙期だけ能力を強化できたりする

業務のものを配置する場合もあればデータを配置する場合もある

2017-08-24

AWS使っててハードウェア障害ってありえるの?

大手ソシャゲーが緊急DBメンテハードウェア障害でした発表をしたんだけど

本日16:50頃よりデータベースサーバー障害対応のため緊急メンテナンス実施しており原因の調査対応をおこなっております。 復旧の目途が立ち次第、あらためてご報告させていただきます。ご迷惑をおかけしておりますことをお詫び申しあげます


8/23(水)16:50頃より実施しております緊急メンテナンスにつきまして、調査の結果ハードウェア障害であることがわかりました。現在、復旧に向けて対応を行っておりますお客様にはご迷惑をおかけいたしておりますことをお詫び申し上げます


AWSハードウェア障害ってありえるの?

オンプレミスも一部使用しているハイブリッド環境

インフラ屋さん教えてください

2017-05-16

wannacryって

オンプレミスを減らしてクラウド移行させるためにクラウドベンダーが仕掛けた罠でしょ?

AWSGCPがやられたという話が地球上で出てないのが不自然

2017-01-04

元増田です

コメントありがとうございます

正直私は、2013年時点でオンプレミス会計ソフトが既に自動仕分け対応していたのか、それともクラウド会計自動仕分けを強みに勢力を延ばしてきた事を受けて、

オンプレミスが後追いで自動仕分け対応してきたのか把握できていません。

もし、おっしゃる通りにオンプレミス会計ソフトが出願日以前に既に同様の自動仕分け対応していたとすると、それがクラウド版になるというだけでは特許としての進歩性が認められる事は無いと思います

結果的に、特許審査官は出願日以前に発売されていた会計ソフト自動仕分け機能対応している事を確認できなかったという事になります

特許審査では、過去特許文献だけではなく、既存パッケージサービスカタログ等でも過去に公開されているものがあれば拒絶の理由します)

プロである特許審査官が明示的に出願日以前に同様の会計ソフトがあった事を明示し拒絶できなかったのに、ニュース上の特許解説だけを見て何の根拠も明示せず

「この特許技術は何十年も前からある」とか「オンプレミス会計ソフトでも既に対応していた」というのは説得力に欠けると思うわけです。

それだけありふれた技術であれば、「この会計ソフトで○○年に同様の機能提供されていた」とか「この文献に同様の技術記載されていた」という根拠を明示すれば

競合する会社特許無効にする事もできる訳で、正式審査手続きを経て特許正式に認められた会社がそれを行使する事を「卑怯」とか「マナー違反」のように批判するのは違うのではないかと思い元記事を書きました。

もし、特許審査がザルで、何でもかんでも特許を認めてしまう事で係争コスト無効審判コストビジネス上の不利益になっていると言うのであれば、問題視するべきは企業ではなく特許審査方法特許法のものという事になると思います

anond:20170104145822

http://anond.hatelabo.jp/20170103150128

特許に関しての素人意見なんですが私見を。

この件に関して反発が多いのは、自動仕訳機能クラウドシステムには直接的な関係がなく、さらに本特許と似たような自動仕訳機能はパッケージソフトやオンプレミス会計システムでは存在していたというのが理由だと思います

パッケージソフトやオンプレミスシステムで古くからある既知の機能・(実現済みの)概念を、そのままクラウドに持って行って別の特許ですと主張されるのはかないません。

自動仕訳機能のもの新規性があったり、自動仕訳実現のアルゴリズムのもの新規性があったり、クラウドで実行するからこそ実現できる機能であったなら話は別です。

2016-12-29

はてブで「Amazon」と検索してみると

昨今話題になってるヤマト佐川関連のブックマークが上位を占めるかと思いきや、まったく違った。

2016年12月29日10:54時点、本文、新着順で検索

Amazon検索結果 (絞り込み: 3 users 以上) 約 3,423 件中 1 - 40 件目 (0.26 秒)

以下略

ECサイト連想させるトピックほとんどなくて、AmazonB2B向けサービスを充実させていることに驚いた。

Amazonって表向きは物流業界革命問題を起こしている要因に挙げられているけど、EC以外のインパクトがどれだけ大きいのか門外漢なので分からない。

↑でブクマ付けた人、何が起きるのか教えて

2016-11-20

エンジニア立ち居振舞い: 技術的な暴力を振るわない - futoase

http://futoase.hatenablog.com/entry/2016/11/19/155427

例示されている暴力はだいたい頭の悪い暴力なので反論できます

CGIには今の時代PHPを利用するのに、なぜ未だにPerlを使っているのか。処理速度も遅く、表現も難解だ。

では今あるシステム全部PHPリプレイスするとして、○人月工数必要ですがそのような予算はありません。

Go言語のもの表現力が低い。そんなものを利用するならJavaScalaで書くべきだ。ライブラリ豊富にあるだろう。Googleに縛られた環境での開発は恐ろしい。

ところでどうしてWindowsPCを開いてExcel文書作ってるのか教えてください。

Serverlessそのものサーバがなくなるわけではない。自身チューニングなど細かなリソース管理ができないPaaSを使って自身サービスの命運を預けるなんて馬鹿げている。

理屈の上ではオンプレミスIaaSの方が細かな管理できるかもしれませんが、サーバ管理にそこまでコストかけるつもりが無いのに適当なこと言わないでください。

みんな忙しいから結局何もやってないじゃないですか

iOSアプリのものプラットフォームがいつまであるかもわからないし、今後広がるかわからない。Objective Cを覚えたり、そんなもの技術をかけてどうするのか。

Nintendo Switchが大流行するかわからない。コントローラー使いづらいし。あんものはチンケなものだ。そもそもUnityインフラエンジニアが覚えて意味があるのか。

流行前は流行らないと言い、流行った後は将来性が無いと言う、じゃあ一生何も始めないつもりですか?

でも安心してください。すべてはUnity解決してくれます。そう、Unityならね。




とは言っても結局は私も暴力をふるう側の人間

例示された人たちに暴力ふるいたい。

windowsmacフロントエンドインフラ組み込みいう線引きからはみ出してはいけないと思うな。むしろ全部やれ全部だ!誰もお前がカバーしてない部分をサポートなんぞしねえからな!

ECサイト作りたい人 → ヤフオクでやれ(CMSを使うことの大切さ)

iosアプリ作りたいwindows開発者 → くだらないことにこだわってないでmaciphone買え(ios開発は何もかもmacxcode大前提

フロントエンドプログラマgo → goだけ使われても微妙。当然DBとの連携もあるんだよな?ん?(サーバサイドスクリプトDB連携のためにあるようなもの

サーバレスに興味あり組み込みエンジニア → どうでもいいからさっさと作れ。そこ悩むとこじゃねーから!(悩むなら一度サーバ立ち上げから自分でやってみてイメージをつかんだ方がいいかも)

NintendoUnityインフラエンジニア → やればいいと思うがハードルが高すぎて頓挫する可能性が高い。まずはUnityエディタ上で動くくらいを目標にすべきだ。

2016-07-29

こんなWebエンジニア部署に配属になったら終わり

社内にはいくつか Web エンジニア部署がある。

その中でこんな部署に配属になったら自分エンジニア人生が終わってしまう(テクニカルロックイン及び生涯収入的に)ので、会社を辞めるか別部署への再配属願いを出す。規模的には部署10 人以下ぐらいで。

この辺に当てはまるものがある部署はもうそれはエンジニア部署じゃなく、ただの SIer 上がりの口だけで何にもできない人間達だから近づかないほうが幸せだと思っている。

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にまとめる仕事があって、そこに給与が発生してると思うと泣きたい。

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

辞め方

2015-06-28

http://anond.hatelabo.jp/20150628084955

Webサービス事業化する場合プロセス検討(仮説)

 

(1)企画 → 何を作るか? アイデアマーケティング

(2)制作 → アイデアを具体的な形にする技術

(3)営業 → 作ったサービスを売り込む。 宣伝運営サポート等。

 

(2)の課題

・2-1 Webデザイン → IllustratorPhotoshop勉強中。CSSスキルもショボいので復習しないといけない。

・2-2 Webプログラミング → PHPよりも生産性の高い手段を得たい。サーバーサイドもJSNode.js)への一本化を要検討。

・2-3 インフラ → 貧乏なので、とりあえずVPSクラウドオンプレミス構成ノウハウを得たい。

 

PHP手続き型、OOPから関数型言語への移行を検討しているのだが、候補や学習コスト調査、導入テストができていない。

Node.js+Underscore.js等のJSライブラリFPを試してみるか?

・JavaVM上で動く関数型言語Clojure等)を試してみるか?

テスト地獄比較手続OOPRails)/関数型(JSClojure

 

ここが今の課題だな。順番に解決していくしかない。

2015-06-24

職場でこれ書いてる、書き終わったら辞表出す

何が悪かったって、ウチは三次請けなんだが、二次けが全然情報を落としてこない。

こっちが「この部分の仕様を決めてくれ」って頼むと1週間かかる。たかだが小さい句読点いりますかぐらいの話でもだ。

もともとは2年近く前からはじまったプロジェクトで、スケジュール的には余裕があったんだ。なのに具体的に着手ができたのは今年の2月。その時点でもまだ余裕はあったんだが、ほぼ待ち時間で作業ができなかった。

クラウドを使えないというのは親元のコンプラだったのでオンプレミスでウチが計画をした。

1年以上ウチからは14人月ぐらい出していた。実働は4人月ぐらいだった。

2ヶ月ほど前から雲行きが悪くなった。1ヶ月ほど前にダメだと分かった。が許されなかった。その時点で辞表を認めた。

これ以上書くと間違いなく特定されてしまうのでこれで終わりにする。長いこと帰っていない家に戻ったらあの会社家具も捨てる。

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