「ベンダ」を含む日記 RSS

はてなキーワード: ベンダとは

2018-07-13

anond:20180713003737

まぁ、綺麗事効率化より食い扶持どう稼ぐかの方が問題だよな。

ホントに人売りはクソだと実感するわ。

複数ベンダが入り乱れてる職場だとそれぞれのチーム同士で縄張り争いやってんだよな。

居ないヤツの文句で談笑してよ。辟易する。

食い扶持稼ぐためにPC使って真心こめた手作業やってんの見てると心底馬鹿らしいと思うわ。

2018-03-31

人でなし、ロクデナシ

IT派遣奴隷売買に例えるよね。

死んだ魚の目をしたITソルジャー達を派遣企業に押し込むアレ。

私は押し込む側ではなくて、発注元。派遣さんや業務委託さんの事を、戦力やリソースといえば

まだ聞こえが良いが、実態としては使い捨て要員のように思ってしまうことがある。

派遣会社やベンダに「いついつから○人必要から準備して」と言う。

カネ出せば補充がきく存在だ、と。

年度末に契約期限切れをむかえた人達が私のもとに挨拶にきてくれたんだけど、なんだか

申し訳ない気持ちに陥ってしまった。

私は、いったい何様なのか。

2018-03-07

anond:20180307150124

朝は皮被って無いか要チェックな。

毛が挟まって飛び散ったり、

朝立ちで便座の前部からションベンダ漏れなんてことがアル

冬は特に

2018-02-21

炎上中の桂 春蝶公式サイトの(マイニング)マルウェア埋め込み疑惑の不

桂春蝶公式サイト

ttp://shunchou.jp/

アクセスすると、Avast遮断する。

警告は JS:Includer-BJQ [Trj] で、JavaScriptによるトロイリンク埋め込みの判定だ。

ウイルスバスターなど、トレンドマイクロ社の製品でも遮断されるという報告がある。

警告はJS/CoinMiner.AEで、トロイのうち、仮想通貨マイニングスクリプトの判定だ。

イケダハヤトも埋め込んで炎上したやつである

しかし、念のためにオンラインURLスキャナーに掛けてみると、

https://virusdesk.kaspersky.com

https://rescan.pro

https://quttera.com

共にSafe/clearの判定なのである

rescan.proではHTTPエラー403以外SAFEとの事だが、そもそも403食らって何故スキャン出来るのか?

ともかく、これが誤判定なのかどうかは不明のままだ。

炎上しているので嫌がらせ登録された可能性もあるが、ユーザーのpostだけでブラックリスト入れるほどユルイセキュリティベンダもない筈だ。

2018-02-09

anond:20180209135006

イッヒフンバルト デル ウンコ ハイル! フンデルベン! ミーデルベン! ヘーヒルト ベンデル! フンバルト ヘーデル! ベンダタイナー!フンデルモレル ケッツカラデルド! フンベン モルゲン! モーデルワ イッヒ アーデル ゲーベン! ワーデル!

2018-01-31

冗長構成に夢を見すぎな人が多すぎる

ニュース解説 - 日本郵便ハード保守契約を全面見直しITベンダーの反発は必至:ITpro

冗長構成ってのは、方系が故障したときにもう一方が動作しているか問題ないという仕組み。つまり、もう一方が稼動している最中に元の方を直せなかったら業務が止まる。この業務停止時間の影響を抑えるために冗長構成は組まれる。欧米業務が止まっても顧客は許すし職員は諦めて酒飲み始めるのが許容される文化日本サービス10秒切れたらクレームがくる世界なんだぞ?その世界で堂々と「壊れたのだから仕方ない」といえるような会社仕事けが冗長構成いらんといえる。

クラウド使えばいいとか、仮想化すれば大丈夫とか、果てにはVMWareを使うからとか言う人まで出てくる始末。不思議コメント抽出

id:z1h4784 日本郵政 の社内インフラはvSphereのHA構成になってたりするの?であれば確かに可能かもしれない。ただそんな話は全然聞かないんだよなあ…。

vSphereのHAが何だか知ってる?VMWareがHA構成かどうかとその下のハードウェア構成がどう組まれいるかはぜんぜん別の話だぞ?

id:s025236 "ハード故障した際に1週間放置してみた。「それでも業務に全く支障が出なかった」"←これ不要ハードな気がしてならないのだけどハード見直しが先では

ハードが何を意味しているか想像できてる?RAID組んでるうちの1本が壊れたのを放置してたけど偶然もう別のディスクは壊れなくて問題なかったとかいレベルなんだけど理解できるだろうか?

id:sakidatsumono いっそクラウド化すれば

クラウドを使えば障害対応から逃れられるとか夢見ちゃってませんか?インフラってそんな単純な世界じゃないですよ?

id:htbman 冗長化した上で台数分の保守契約ベンダにとってうまい話だっただろうなぁ

冗長構成を組むことで余計にかかるコストがあり、対障害性を上げるために難易度が上がるのだけどお分かりになるだろうか?

2017-12-13

IT企業つらいこと一覧


転職かぁ

2017-12-06

anond:20171206215049

開発は不確定要素が多い

スムーズに行けばこれだけの工数で済むが最悪ここまでかかる、という幅が、既製品の導入よりずっと広くなる

開発者見積もりは、未知の落とし穴にハマる最悪パターン考慮した見積もりだけど、それを「シビア確認」とかいって最善パターンに合わせるのを強制すれば、間に合わない可能性が当然高くなる

それを「開発の責任だ」といって押し付けてたら、誰もそんなところでは働かない

リスク管理勉強しろ

「熊とワルツを」を読め

リスクをとる気がないなら今までどおりにベンダサポート範囲既製品の導入に専念するしかない

2017-10-20

いきなり元号4文字かになったらおもしろ

あらゆる書類レイアウト崩れのテストしなきゃならなくなって、ベンダも「無料ではできない!」ってなって、むしろシステムから廃止の方向になるだろう

2017-10-14

http://gendai.ismedia.jp/articles/-/52889

スルガ銀行システム開発にかける覚悟が表れたのが、日本IBMとの訴訟です。同行は基幹システムの開発を日本IBMに依頼しますが、契約通りに開発できなかったとして'08年に損害賠償を求めて提訴しました。

これまで日本企業の多くはシステム会社に対して要求された額を唯々諾々と支払ってきましたが、スルガ銀行はその悪習にも風穴を開けたんです。

判決は、日本IBMスルガ銀行に約42億円を支払えというものでした。これで他のシステム会社も、スルガ銀行には開発費をふっかけられないと思い知ったことでしょう。その結果、システム開発費は他行より安くなっているはずです」(前出・加谷氏)

スルガ銀行には開発費をふっかけられないと思い知ったことでしょう。その結果、システム開発費は他行より安くなっているはずです」(前出・加谷氏)

いや、むしろ高くなってるだろ。この案件パッケージ使って安価に作りましょうってスタートしたが、そのパッケージではスルガの要望に全部は沿えないってのが判ってきて、仕切り直しが泥沼化して契約解除なのだから、次のベンダーは(見えていない)リスク分を多めに積むようになるでしょ。ふっかけたのがばれたんで、金返せとかじゃ全くないし。(泥沼の中で色々やらかして不信感持たれたとかもあるようだけど)

今回の京都市の例もそうだけど、システム開発には地雷多すぎで当初見積もり金額で一括受託は無理ありすぎるよなぁと。その辺りのリスクユーザベンダが納得する形でうまく扱える契約形態一般的にならないものかと妄想中。米国はいろんな契約形態があるっぽいが良くは見てない。ベンダースキルが~とかユーザーシステムに関する知識が~とかもあるがその辺は置いておく。小さなプロジェクトだとSESアジャイル系ってのが一番良いのだろうけど。なんか良いのないですかね~、正直大手SIer新規ではぶっこきまくってるから欲しいはずなんだけどなぁ。まぁ、下請けに被せてるから良いっすと思ってるかもだが。

2017-10-12

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代コンピュータだよ。IBMとかがベンダーごとに作っていてOSベンダー謹製だよ。性能はいいけどメチャ高いよ。

システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。

オープンソースソフトウェアとは全然関係ないよ。


Q3.使いまわしってどうやってやるの?

A3.80年代かに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語コンバートしてリコンパイルするよ。

DBデータ階層データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。

あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。

コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。

COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。

今回もめたのもバッチらしいね


Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん

A4.お金無限にあればできるよ。今の時代お金があった時代システムフルスクラッチ再開発するととんでもない予算になって市役所内の決裁が通らないよ。

しか汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから費用さらにかさむよ。


Q5.そんなんでよく運用できてたな

A5.当時はSE汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2017-09-29

ベンダーって何?

ベンダアアアアアアアアアアアアアアアイヤァアアアアアアアアアアアアアアアアウィルオオオオオルウェイズラアアブユウウウウウウウウアアアアアアアアアアアアア

2017-09-14

ジーニアスAppleと戯言

アップルジーニアスって、あまりジーニアスだと感じた事がない。

スペシャリストという肩書きの人も、会話中の早い段階で諦めを感じてしまう。

こちらがわからない事はわからない、というのでは、時間無駄で、

本国に問い合わせします」とドヤ顔で言われても、

それならあなたフィルター邪魔になるので直接こちから問い合わせした方がいい、と内心思う。


結局、海外フォーラム書き込みして訊いてみるのが一番早いのは、

他のソフトウェアベンダサポートセンタも同じで、

そんなものなのだとわかっているけれど、

アップル場合は、なんていうか雰囲気ドヤ顔ごまかしているようにしか見えないんだよね。


わざわざ予約して時間作って行っても、ドヤ顔の客と店員の高い意識雰囲気は私には暑苦しい。

でも、そんなアップルストア好きな人も多いのも理解はしている。


ちなみに、マイクロソフトは、チャットでそのまま話を聞いてくれて解決も早かった。

技術的に優秀な人が対応してくれる。


PowerMac漢字トークを使って、ResEditでリソースフォークをいじりつつ、

RealBasicプログラムを書き、HyperCardスタックを作って遊ぶ。

暇つぶしにMKLinuxインストールしたりしてた、過去のパワーユーザにとっては、

好きだったアップルはもうどこにも存在しない。


歴代で一番好きな好きなノートパソコンは、PowerbookG3。

ジョブズが戻ってきて、人気の出たスケルトンで5色のiMacは好きでなかった。

OSXにはPantherまで懐疑的だった。

Palmを持って、iPod三世代にLinuxインストールしてお茶を濁したりしてた頃、

VAIOクリエを持っていた回りの人間現在は皆、iPhoneとMacBookAirを持っていて、

表面に変なシールを貼っている。


あのシールなんなのかな。あれはダサいよね。

2017-06-26

体の疲れがメンタルに響く

昨日一昨日と遊んですごく歩いたり食べたりした。

それ自体は楽しかったのだが、

疲れがネガティブ思考へとつながる自分は、

今日は一日すぐ傷つくメンタリティになってる。

先輩の受け答えがちょっと雑なだけで、

嫌われちゃったかなー呆れられたかなーとかよぎる。自動的ネガティブな考えが出てくる。

元気だとそんなことないから、これは疲れが出てるだけってのはわかってるんだけど、凹む

それに今朝またシステムエラーはいてるし、ベンダの回答遅いしで、そわそわそわそわしてしまってる。

仕事が遅れてなければソッコー帰りたい

2017-05-12

エラーメッセージスグケスマ

最近若いIT技術者の人と仕事をするんだけど、みんなエラーメッセージが出たら即消してしまう。

普通の人ならまだ判らないでもないが、IT技術者

「今のエラーメッセージベンダに伝えて下さい」

と言ったら

「見てません、見る前に消してしまいました」

とさ。

一人や二人じゃない。というか若い人のデフォルト動作っぽい。

割とのんびりゆっくり動作して普段からイライラさせられるような人でも、エラーメッセージボックスを削除するスピードものすごく早い。

2017-04-09

Rubyはもうやめた

もうRubyシステム書くの止めた

日々更新されてコロコロ変わる言語仕様に付き合ってられない

最近互換性を気にしてるようだけど新しい書き方ですとか毎回言われるストレス半端ない

プログラミング言語みたいな土台となる技術がそんな変わって何も違和感覚えないやつらがどうかしてる

(その意味SwiftRuby以上に頭おかしい)

rbenvやらBundlerで完璧ベンダリングできますってそんな誇れることなの?

バージョン依存が激しいのでそうしないとバグますって言ってるようなもんじゃねーかw

まだpython2,perl5で書いた方がまだ良いわ(Perl文法が糞だから書かないけど)

多少言語に粗があっても互換性を維持してくれた方がよっぽど重要なんだけど(少なくとも俺は)

ついでにRailsも止めた

フルスタックフレームワークでなんでもできるぞ!とか言ってるけど理解できない

自分が使わない機能がたくさんコードに入ってて使わない機能脆弱性がありましたアップデートあります

って毎回言われてどう思うの?

モックアップみたいなのをササッと作るには良いかもしんないけど、こんな異常なアップデート地獄に付き合わされて

まだRails生産性が高いとか言えるの?

結局Railsマジックで作ったような気になってるだけで後に来る保守問題先延ばしにしてるだけじゃねーの?

Rubyが変わりRailsが変わりそれに追従して今回のアップデートはあーだーこーだーって茶番すぎんだろw

世の中のレガシーRailsシステムを見て現実を見たらw?

2016-04-29

2段ベット増田憧れるレガコア堕す魔にとっベンダに(回文

今日昭和の日だけど、

昭和の日と言えば、

なんか2段ベット的な感じで、

小さい頃憧れたなぁ、なんて思い出すわ。

いまは、2段ベットなんてなくても平気だけど、

ドラえもん方式の押入れ2段ベット

いいなと思ったわ。

寝台列車もあれ昔は3段ベットだったんでしょ?

さらに上行くわね。

3段ベットとか、

たぶん今2段ベットとかあっても

ハシゴ上るのがめんどくさいわってなっちゃうわね。

まあ、ちょっと何言ってるか分からないけど、

志は高く持ちたいわ!!!

最近増田プロ界隈の話題どうなってるのかしらね

でも、今日もせっせと増田を書くわ!


今日朝ご飯

賞味期限半年以上切れてるヨーグルト

チャレンジしてみたわ。

案外平気ね、

即効性があるわけではないからからジワジワくるかも!

デトックスウォーター

今日果物を買いに行こうかしらね

何もないので作り置き麦ウォーターです。


すいすいすいようび!

今日も頑張ろう!

2016-04-24

富士通退職して思うこと

筆者は、新卒入社した富士通を三年で退職した。

退職から一年が経過し、新しい職場(WEBベンチャー企業)での仕事に慣れたこと、

また、富士通の同期入社の友人から頻繁に転職の相談を受けるようになったこともあり、本エントリ執筆する。

はじめに、筆者の退職理由を簡単に述べると、富士通という会社未来を感じなかったことと、やりたい仕事はできないだろうと判断したためである

参考までに、筆者は公共機関向けのシステム開発部門所属していた。

担当していた業務は様々で、小規模なシステム開発や、子会社・下請企業管理であった。


1.成果主義を謳いながら実態は年功序列主義

富士通には、人材キャリアフレームワークという社員評価制度があり、現場には、入社何年目はこのレベル仕事、といった暗黙の了解がある。

本人の能力や意欲とは全く無関係に、入社後の経過年数で、仕事裁量の幅が大きく制限される。

このことはいわば、学習指導要領ならぬ、業務指導要領があるようなものだ。

このような枠組みや暗黙の了解存在すること自体問題なのではなく、その枠組から逸脱した人材を想定しない・評価しないことが問題なのである

筆者がお世話になった優秀な先輩方は、この業務指導要領の要件を満たして手に余った人、

いわば天井にぶつかった人から先に、より大きな仕事がしたいという理由で辞めていった。

筆者もその一人である

既存産業の大きな成長が望めなく、社員個々の多様性重要視される昨今の経済情勢において、

高度成長期における横並び思想をもとの作られたやり方が未だに社内を謳歌しているのは時代錯誤というほかない。

富士通への提言として、これから時代は、年齢も在籍年数も関係ない人材評価制度を作っていくべきである

そして重要なのは会社既存事業でいかに利益を上げたかについての評価ウェイトを下げ、

いかに新しい発想で新しい事業を提案したか・実現したかという評価項目を設立するべきである

なお、富士通には社内ベンチャー制度があるが、これはうまくいかない可能性が高い。

なぜなら、社内ベンチャー承認するのは旧式の人材の典型である高齢経営であるからだ。

いままで数十の社内ベンチャー審査結果を見てきたが、彼ら経営層に事業の将来性を判断する能力はないと痛感した。

また、他の理由としては、富士通既存事業と衝突すると社内ベンチャーが潰されるということがある。

将来性のない既存事業を残して、将来を託すべき社内ベンチャーを潰すという企業風土なのだ


2.社内既得権益集団が絶対に損をしないルール

富士通という会社には多数の既得権益集団がいる。そして、社内のルールは彼らが決して不利にならないように作られている。

なぜなら、ルールを作る権限は、先頭を走る集団、1980年代大成功を収めた既得権益層がガッチリ握っているからだ。

いわば、前を走る人を抜かしてはいけないレースのようなものだ。

このような出来レースで若手社員モチベーションが続くはずはないことは明らかだ。

筆者は、決して年功序列主義を批判したいのではない。

既得権益層が年功序列悪用して、部下の手柄を自分の手柄にし、部下の失敗を部下に押し付けている実態に対する批判である

ノブレスブリージュ、権利を有するものには義務がある、という思想がある。

富士通既得権益集団には会社技術力や社員を率先することで、企業としての地位を向上させていく義務がある。

実態は、社内の後進に抜かされることを恐れるあまり、後進の他社に抜かされている。

これでは既得権益集団が義務果たしていないことは明らかだ。

ちなみに、この既得権益集団に有利なルールが生み出した現状については、

同じく富士通OBである城繁幸氏の著書「若者はなぜ3年で辞めるのか?」(光文社新書)が詳しい。


3.企業ビジョンを失った社員たち

経営学において「ヴィジョナリーカンパニー」という名著がある。

この本によると、会社が永続的に成長・発展していくためには企業理念ビジョン)を社員ひとりひとりが持つことが必要不可欠であると指摘している。

富士通企業理念は、変革に挑戦し続ける姿勢や、よりよいICT社会づくりに貢献することを掲げている。

しかし、富士通という会社の現状として、このヴィジョンを失っている社員、とくに管理職がとても多い。

30代を過ぎて会社に定住することを決めた社員に変革に挑戦しようという熱意ある人物はひとりもいなかった、

そういう人々にとってICTで社会づくりなどどうでもいいのだ。

ただ顧客要求を聞いて、それを子会社下請けに作らせて予算や利益を達成することにしか興味がない管理職が大半であった。

これでは富士通企業理念など誇大広告もいいところである

元GEのCEOであるジャック・ウェルチ氏は、たとえ成果を出していようと企業ビジョンを共有しないものはクビにしろと自著で語っている。

このポリシーを導入したら、富士通管理職の80%はクビになるであろう。そのくらいに富士通管理職は夢や熱意のない人物ばかりであった。

そのような人材が将来的に会社破壊する、というウェルチ氏の指摘の正当性を、富士通という会社惨状が示しているのは皮肉という他ない。

富士通への提言として、ウェルチ氏のやり方を実行すればよいのだ。

成果によって管理職のクビを決めるのではなく、ヴィジョンを共有できているかでクビを決めるのだ。

このやり方を実行すると既得権益を握って離さな経営層や管理職が一掃される。

既得権益にしがみつくだけの人物こそ、ヴィジョンを持たない人物である割合がとても多かったことを付け加えておく。


4.発展途上国レベル業務標準化の原因

経営コンサルタント大前研一氏は、日本生産性アメリカの半分しかなく、もはや発展途上国にすら負けていると指摘している。

その原因について、日本では業務標準化が全く進んでいないためであると述べている。

このことについてITベンダに勤めていた経験から詳解したい。

まず、マイナンバー関連のシステムを例に挙げる。

自分の住む自治体と異なる自治体マイナンバーのITシステム比較してみてほしい。

ここで、自治体が異なればITシステムも異なることに気づくはずである

はたして自治体ごとに個別マイナンバーシステムを作る必要があるのだろうか?

答えはもちろんノーである。全国どこでも一律の業務であるべきであり、同じITシステムを導入するべきである

なぜ、各自治体ごとにITシステムがバラバラなのか。

その理由業務標準化がなされていないためである

自治体ごとに業務フローが異なるために、別のITシステム使用した時に業務がこなせないという事態が発生する。

そのため各自治体が個別にITシステムをITベンダー発注することになる。

そこでITベンダー各自治体ごとに個別のITシステムを作ることになる。

ITベンダーからすると一度作ったことがあるものカスタマイズして、業務の順番を入れ替えたり、扱うデータを多少変更するだけで済む。

それなのに膨大な金額を請求するわけだ、ITベンダーとしてはボロ儲けである

(なお、主要ITベンダー決算書を見ていただくとわかるが、ITベンダー利益率が高いわけではない)

特に自治体のITシステムは国民の税金で作られているわけである

各自治体は、このような現状を放置していて、国民に申し訳ないと思わないのであろうか?

このことは、決してITベンダーにの責任があるわけではない。

総務省が陣頭指揮をとって各自治体の業務標準化統一化を進めなくてはいけないのに、それが全くなされていないのは監督官庁としての責任放棄である

このように業務標準化が全く進んでいない現状は自治体に限らず、民間企業においても同様である

会計パッケージにおいて、世界デファクトスタンダードになりつつあるSAP導入に失敗する事例を数多く見てきた。

失敗する理由は、個々の企業業務に合わせてSAPをカスタマイズしており、そのカスタマイズでは対応できない業務フロー存在するからである

問題なのは、そのような業務フローは、決して必然的業務ではなく、過去の慣習から存在しているだけであることがとても多い。

ここにおいて、ITシステム業務に合わせるのではなく、ITシステムに合わせて業務の方を変えていかなくてはいけないのだ。

日本サービス流通業生産性特に低い。

このことは、サービス流通業顧客からSAPのカスタマイズ無理難題があがってくることが特に多いことと無関係ではないであろう。

富士通は、既存顧客業務標準化およびデファクト・スタンダードとなるITシステムの開発の陣頭指揮をとる役割を果たすべきだが、その望みは期待できない。

なぜなら関係が深い企業において、業務効率化すると大量の社内失業者を出すことになるからだ。

そのような"顧客との良い関係"を崩すようなことはやらない会社である

日本という国のあるべき姿を長期的に考えた際に必然的なことであるにもかかわらずである

富士通企業理念である、よりよい社会づくりに貢献するとは、まさにこの業務標準化を推し進めることなのではないのか。


5.時代に取り残されたガラパゴス化した閉鎖社会

富士通には外国籍社員が相当数在籍している。しかし、彼らに求められる日本人への"帰化圧力"がとても強い。

同期入社中国籍の友人は、対外発表会のために完璧日本語発音の練習をさせられていた。

完璧日本語発音日本人に任せるべきで、中国精通しているというメリットを活かせる部署配置転換するべきである

この現状に直面した外国籍社員は数年で辞めていく。

なお、残った外国籍社員をみると、小学生から日本にいるなど、生まれたのが海外というだけのほぼ日本人だったりする。

外国籍社員離職率が高いことに対して、本部長が提示した対策が、

長く働きたい会社とはどのような会社か、というテーマ外国籍社員を集めランチタイムディスカッションさせるというものだった。

この話を聞いたとき、筆者は絶句してしまった。

この席で「無能な人が本部長にならない会社で長く働きたい」という大喜利でもすればいいのだろうか。

富士通グローバル企業を表明しているが、このような組織海外進出などできるはずもない。

なぜならば富士通利益構造では、海外において利益を上げられないからだ。

このカラクリ解説大前研一氏が詳解されているので、参考にしていただきたい。※1


6.富士通の良いところ

ここまで富士通に対する批判と改善提言を述べてきたが、富士通の良いところについても触れておきたい。

まず、個々の社員仕事力や組織力といった点では、他の大企業比較して遜色ない。ただし、富士通の主要グループ企業に限るが。

数十を超える大企業および中小企業仕事をしたが、やはり大企業は個々の社員レベルが高く、組織力も高い傾向にある。

顧客として他社と仕事を進めていくうえで、大企業の方が優秀な担当者に遭遇することが多く、仕事がとても進みやすかった。

この理由について、大企業社員育成能力が高いことはもちろん、社内チェック体制が整っているからではないかと思う。

社内で質の悪いものは弾いており、社外に出さないようにしているのだろう。

また、富士通顧客主義がきちんと徹底されている会社であると感じた。

筆者と富士通顧客主義が異なっていた点はあるものの、顧客起点に立つという考え方は大事なことである

これは、筆者が富士通入社して良かったと感じることである

人間関係について、他社と比較して良好な会社であると感じた。

柔らかい人が多く、職場雰囲気はとても良かった。お世話になった直属の上司や先輩方は、優しく丁寧なご指導をいただいたことに感謝している。


7.おわりに

最後に、立花隆氏の著書「東大生はバカになったか」(文春文庫から名文を引用したい。※2

「いま、この辞めたい気持ちを逃したら、この会社に骨を埋めて、あそこにいる連中と同じになってしまうと思った。」

結局、筆者の退職理由は、偉そうな顔をしているがロクなビジョンも打ち出せない富士通上層部のような人間になりたくなかったからである

富士通という会社必要なのは、優秀な若手の育成などではなく、無用老害排除である

筆者には、富士通という会社は、沈みゆく泥船にしか思えなかった。


※1「産業突然死」の時代人生論、第44回 談合をなくす二つの妙案-"便利なゼネコン"はいじめの温床

http://www.nikkeibp.co.jp/sj/2/column/a/46/

(この記事ゼネコンITゼネコン(ITベンダー)に置き換えていただきたい。)

※2 引用にあたり、語尾を改めた。


補足1.城繁幸氏の著書「内側から見た富士通」(光文社)についてのコメント

この本は富士通が先んじて導入した成果主義が、名ばかりで社員のやる気を奪う結果に終わったという実態を告発した本である

この本について、いくつか述べたい。

まず、本題である成果主義経営層のご都合で導入されて、社員モチベーションを奪うという最悪の結果に終わったという指摘はまさにその通りである

また、この本が出版されてから10年以上経つが、実態は改善されていないし、する気もないのだろう。

(そもそも経営者のご都合成果主義の導入を失敗だと気づく能力が欠如しているのかも知れない)

富士通では、そもそも「成果」などを評価されていない。

管理職仕事は、部下の成果を評価することではなく、予算内におさまるように部下の評価を調整することであった。

なお、成果主義の導入を評価している現場社員は誰もいなかった。

成果主義を批判する幹部社員はいなかった。おそらく批判すると何らかのペナルティがあるのではないかと邪推している。)


補足2.転職について

筆者の転職について、考慮したことをいくつか述べる。

まず、次の会社仕事の選び方および交渉の進め方については、山崎元氏の著書「会社は二年で辞めていい」(幻冬舎新書)を大いに参考にした。

転職は考えていなくとも、今の時代を働く考え方、人材価値セルフマネジメントなどは一読の価値がある。

富士通という大手を辞めたはいいが、次の会社で苦労している人が多いという意見についてコメントしたい。

筆者に言わせれば、それは転職のツメが甘いのだ。

現職のどこに不満を持っていて、そのうち、どこが改善余地があり、妥協するべきであり、次の職で改善を期待するのか、についての思慮が浅い。

社会ルールをわかっていないで転職したとしか思えないケースもある。

そもそも富士通という会社に勤めているにもかかわらずITゼネコン生態系を理解していない社員がとても多い。

下請け企業にいけばもっとやりがいのある仕事ができる、などという浅い考えで転職する人はいる。

ITゼネコン下請け生業とする会社社長は、中間管理職と何一つ違いはない。

上の指示(元請け発注)を受けて下に伝達するだけであって、自身で新しい事業を生み出す能力のない企業である

筆者はITゼネコン生態系から離れた企業を選んだ。

新しい会社は、自社で新しい事業を生み出す能力があり、きちんと利益を上げている。

転職において改善したかったこと、専門的な業務ができること、自分アイディア事業に活かすことができること、それらがすべて達成できた。

なお、富士通からWEBベンチャーに転職する人が多いと思われがちであるが、一番多いのは地方公務員である

2016-03-01

http://anond.hatelabo.jp/20160301213541

システム構築は共同作業

客側は業務ベンダ側はIT専門家としてそれぞれ果たすべき責任がある

ってなことを本で読んだ

http://www.amazon.co.jp/dp/4534051158

って反応したけど、弁護士の話ね。

弁護士なら当然提案すべきこと、ってあると思うけど。

2016-02-20

零細IT企業から大手IT企業転職した結果

汚いコードを書くプログラマが嫌いだった

糞みたいな設計と短すぎる納期発注してくるSier

尻拭いをするのも嫌いだった

無能なのに勉強しないプログラマも嫌いだった

都内勉強会に行ってみると、優秀な人に多く会えたような気がしたので

田舎の零細ITレベルが低いのかと思い、

周りに嫌気が差したのもあって転職をしてみた

……なんだ、この糞みたいな環境

社内政治責任のなすりつけあい

無能ベンダに数億単位で金を支払い成果物バグまみれ

内製化(笑)といいつつ零細IT企業未満のプロジェクト管理

なんで転職してしまったんだろう

そして何よりこれだけの企業

この程度のレベルしかないことに、

日本ITレベルの低さに絶望した

欧米はもちろんアジアでも最低の技術力なんじゃないか……?

2015-08-06

金額見積もりと時間見積もり

システム開発見積もりは工数まり時間じゃないですか。

からすれば安いほうがイイわけだけど、安くすれば時間も短くなり、できることも少なくなる。

なれた客だと、見積もり時には要件ミニマムで、安く見積もらせておいて、後出しであれこれ要件タスクを増やしていくといった手法をとる。もちろん、見積もり金額が決定した後では、追加工数は認められないの一点張り


逆に、いい客は文句言いつつもカネを出してくれる。スケジュールも長くとってくれる。多くは無いがそういう客も存在する。

そういう客にはディスカウントしたいと思うんだよね。タスクボリュームに対して長いスケジュールを組んでくれれば、作業は余裕が出るし、品質も向上するし、何か問題が起きてもリカバリやすい。

営業や会社はイヤだろうけど、開発の現場からすればカネより時間重要じゃん?。

タスクボリュームに対してスケジュールが長いと判断できればディスカウントする。そういう仕組みがあれば、客も長めにスケジュールを組むモチベーションになるので、客と現場は ウィィィーーーーン/ウィィィーーーーンじゃないですか。

カネ的には一見ベンダ不利だけど、現場疲弊しにくい状況になれば、人材補充/教育コストも減るので、中長期的にはそんなに不利でも無いとか言う可能性もあるし。トラブルによる炎上なんかも、時間さえあればボヤで済むケースも多いしね。


どっかにそういう取り組みの実例ないかね。

2015-07-07

イッヒ フンバルト デル ウンコ

ハイル! フンデルベン! ミーデルベン! ヘーヒルト ベンデル!

フンバルト ヘーデル! ベンダタイナー!

フンデルモレル ケッツカラデルド! フンベン モルゲン!

モーデルワ イッヒ アーデル ゲーベン! ワーデル!

2015-03-31

JVN#81094176 の裏側

http://jvn.jp/jp/JVN81094176/index.html Android OSオープンリゾルバとして機能してしま問題

ってやつね。

報告者の森下さんが「とあるから私個人宛で報告をいただき」と言っているので、その「とある」人として少し背景を書いてみようと思う。

https://twitter.com/OrangeMorishita/status/581314325853306882

どのタイミング発見したのか?

発見タイミングは、Android 4.2 のソースコードが出て少しして、ぐらい。この時点では、Android全てが修正されていなかった。当時、 CVE-2012-3411 (dnsmasq が libvirt特定config で使うときにオープリゾルバとなる) が発表されていて、これと同じ問題があるのでは、と調べた結果だった。Androidテザリングは、framework の指示を netd という daemon が受け取りネットワークの設定を変更して実現されている。で、テザリングクライアントDHCPプライベートアドレスを配りDNSのリゾルバを提供するために、必要に応じて netd から dnsmasq が起動される。

そのころ、Android端末の製品開発で、スケジュールに珍しく余裕があり、わりと好き勝手できる状況だったので、AOSPのソースコードを精査していた。

いくつか、セキュリティ問題をみつけて、ものによって単に修正修正と並行して Google会社から報告、あるいは単に Google会社から報告、ぐらいの対応をした。

この問題は、Google に報告だけ、の対応をとった。なぜかといえば、 次のような事情があった。

で、この報告の結果なのか、他の報告もあったのか分からないが、Android 4.3 のリリース修正が含まれていた。もっとも、国内ほとんどのスマートフォン端末は Android 4.3 はスキップした。森下さんへの個人的な連絡の最初は、Android 4.3 発表より前。

どうして森下さんに?

正直、この問題リスクは、端末ベンダ、および端末ユーザにとっては相当に低いものに見えた。3GLTE国内キャリアで、外から端末へ DNS query を許すところはほとんどないだろう、というのは直感的には思っていた(これが間違っている場合は、影響がケタ違いに大きくなるところだった。上流も下流も Wifi という構成テザリングAndroidは持っていないので、上流を Wifi と仮定すると、残るのは USBBluetooth だけになる) 。NAT される場合ならなおさら

ただ、ネットワークインフラにとってのDDoSというのは、個々にとってはリスクが低くても、それが何百万台、何千万台とあれば影響が出てくるんじゃないか、という気もした。ちょうどそのころ、森下さんが DNS リフレクション攻撃に関してベンダ等への啓発を始めていたのが目に留まったので、森下さんに連絡してみた。脆弱性対応としてハンドリングするのがIPAJPCERT/CC になるとしても、ネットワークインフラへの影響ということであれば、表に出ない話も扱える方が報告したほうが適切だと思った。私は原理的には分かってもネットワーク運用に関しては業界の外にいるからね。

なぜいま発表?

事情は知らないけど。

ひとつの可能性としては、「対応未定」の端末、おそらくは対応しないことになるのだろうけど、それらの現役感がなくなってきたからじゃないかな。Android 4.2系が端末のラインナップとして長生きしすぎたせいで、けっこうOSバージョンアップではなくセキュリティ修正としての対応をする製品が多くなったのかなぁ、という気もするけど。

もうひとつの可能性としては、当初よりもインフラへのリスクが上がっているのかもしれない。Android 4.2系の端末で修正リリースが去年の秋とか、これから近未来とかのが多い、という状況からするとね…。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん