日本郵便がハード保守契約を全面見直し、ITベンダーの反発は必至
日本郵便が情報システムで使うハードウエアに関する保守契約の方針を刷新する意向を固めた。日経コンピュータの取材で分かった。 24時間保守を原則として採用せず、故障機器の修理を1週間分まとめて実施するなど過剰サービスを減らして、ハード保守費を従来の2割程度に減らす。2018年夏以降の新規入札案件から新方針を適用する。既存の保守契約は既に条件を見直す交渉に入った。 鈴木義伯専務執行役員CIO（最高情報責任者）は「現行の保守契約はITの技術変化を反映していない。サービス過剰でコストが高止まりしている」と話す。NTTデータ出身の鈴木CIOは日本取引所グループのCIOを経て2017年4月に日本郵便のCIOに就任して以来、見直しを模索してきた。 新方針ではITベンダーと契約する保守のパターンを品質が低いほうから「スポット保守」「日中週1保守」「日中保守」「24時間保守」の4つに分ける。そのうえで、ハード
NTT AT、宇宙線による誤動作「ソフトエラー」を再現するサービス
NTTアドバンステクノロジ（NTT AT）は2016年12月19日、小型加速器中性子源を用いた「ソフトエラー試験サービス」の提供を開始した。NTTや名古屋大学、住重試験検査（SHIEI）が共同で開発した試験方法を利用する。数メートル程度で比較的小型の加速器中性子源を使って、試験対象の電子機器に中性子を照射することで、宇宙線に起因する電子機器の誤動作である「ソフトエラー」を再現する。 通信装置などが一時的に故障してネットワークが不調になった場合、機器ベンダーが故障の原因を特定できないケースがある。こうした時、同サービスを利用してソフトエラーを再現させて発生確率を測定することで、ソフトエラーが原因なのかを判断できる。 ソフトエラー試験が必要になった背景には、通信機器などに使われる半導体デバイスの高集積化・微細化がある。ビットを判定するのに必要な電荷が少なくなっているため、宇宙線由来の中性子線に
質問：優秀なエンジニアが辞めてしまいます
最初に正直に書きますが、この問題については、ぼくも日々悩み続けています。優秀な人が絶対辞めない素敵な方法があるのならぜひ教えていただきたいところですが、ぼくなりの思うところを書いてみたいと思います。（というか段々回答を書くのがしんどいご質問が増えてきたような…。もっと軽めなご相談でも大歓迎です！） まず、エンジニアが転職する理由は本当に様々です。報酬が理由なこともあれば、その企業で使っている技術が不満、ということもあります。他社に一緒に働きたい人がいる場合もあれば、会社の規模、場所、昇進しやすさなどが合わないこともあるでしょう。このほか、マネジャー職に就いたものの、メンバーとしてやり直したいと思ったり、プロジェクトが一段落し、なんとなく長く勤めたので変化が欲しいと考えたりする人もいるかもしれません。非常に多くの要素が絡みますし、常に隣の芝生は青く見えますので、上司としてはエンジニアのリテン
質問：Laboや20%ルールは必要？
よくIT業界では、LaboとかR&Dといった名称で研究開発組織を設置したり、「20%ルール」などの名目で業務時間の一定割合を研究開発などに割り当てる話があったりします。弊社でも導入したほうがいいか迷っています。藤本さんのお考えをお聞かせください。 最近「内容はまっとうかもしれないけれど、面白みに欠ける」と身近な読者に怒られましたので、少しだけ「やんちゃ」に書いてみます。本当にやんちゃに書くならば「本当にそこに熱意があるなら試してみるのもいいんじゃないでしょうかっ！以上っ！」ということになるのですが。 ということで、否定的な回答タイトルにしてみました。特に研究開発組織に関しては、全てではないですが多くのケースでこの回答で間違っていないと思っています。ソフトウエアに携わる企業にとってLaboやR&D、研究所、研究開発組織などは設置しないほうがよいでしょう。響きは魅力的ですが、安易に始めるべきで
第2回 ソフト開発の3つの契約形態、成果物責任の免責が不可欠
システム開発契約には、「請負型契約」「委任型契約」「混合型契約」の大きく3種類があり、受注者であるソリューションプロバイダには、それぞれメリットとデメリットがある。現在、受注者側が成果物に責任を負う請負契約が主流だが、契約時には、請負責任に関する免責事項を明確にしておく必要がある。 システム開発におけるトラブルは、ユーザー企業のソフト開発の目的や適用業務を、開発委託先であるソリューションプロバイダがきちんと理解できていないことが原因であることが少なくない。 その点からは、業務内容やシステムに必要な要件を最もよく分かっているユーザー企業のSE自らが開発する「自社開発」が望ましい。だが実際には、多くのユーザー企業にとって、自らが十分なシステム開発の経験や技術を持つことは難しく、ソリューションプロバイダに開発を委託することになる。 システム開発を外部に委託する契約には、（1）開発請負契約型、（2
「ShellShock」は公式パッチでは不十分、JPCERT/CCが追加の注意喚起
図中の*1は、JPCERT/CCが公開されている検証コードを用いて脆弱性への影響を確認したことを、*2は発見者がパッチ適用により影響を軽減できると報告していることを示している JPCERTコーディネーションセンター（JPCERT/CC）は2014年9月30日、LinuxなどUNIXベースのOSで広く使われているシェル「GNU Bash」で2014年9月24日に見つかった非常に危険な脆弱性、いわゆる「ShellShock」に関して、現在公式に提供されているパッチでは防ぎ切れない攻撃があるとし、追加の注意喚起を行った。 ShellShock関連の脆弱性は9月30日現在、大きく5種類報告されている。これらの脆弱性に対して、GNUプロジェクトが配布しているGNU bash 4.3のソースファイルにパッチを累積的に適用し、コンパイルして検証したところ（OSはCentOS 6.4）、最新バージョンであ
OSSのDWHソフト「InfiniDB」の開発元が営業終了、国内サポートはアシストが継続
データウエアハウス（DWH）のオープンソースソフトウエア（OSS）のである「InfiniDB」の開発元、米InfiniDB（旧社名はCalpont）が2014年9月19日、営業を終了することを明らかにした。OSSとしての開発はコミュニティが継続する。日本におけるInfiniDBの販売代理店であるアシストは2014年9月22日、日経コンピュータの取材に対して「当社として既存顧客へのサポートを継続することを決定した」と述べている。 米メディアの報道によればInfiniDBは9月19日にCEO（最高経営責任者）であるBob Wilkinson氏による声明を発表し、同社の営業を停止して会社の法的整理を行うことを明らかにしたという。日本の代理店であるアシストも「海外メディアで報道されていることは事実」と述べている。 InfiniDBは「MySQL」をベースにした並列型のDWHソフトだ。InfiniD
質問：フルスタックエンジニアを目指すべき？
最近「フルスタックエンジニア」という言葉をよく聞くようになりました。そもそもフルスタックエンジニアって何なのでしょうか？ソフトウェアエンジニアが目指すべき理想像といえるのでしょうか？もしそうだとすれば、どうすればフルスタックエンジニアになれますか？ 回答 こんにちは。グリーでCTO（最高技術責任者）をしております、ふじもとです。このたび、ITproで連載記事を持つことになりました。僭越ではございますが、少しばかりの経験を生かして、ソフトウエアエンジニアの皆さんの悩みにお答えしていきたいと思います。どうぞよろしくお願いします。 さて、第1回の悩みは「フルスタックエンジニア」です…。少し前によく聞きましたねー、最近は落ち着いているようですが。 言葉をそのまま解釈すれば、すべてのTechnology Stack (技術構成要素、とでもいいますか) に精通しているエンジニア、ということになります。
「日本だけで知られた会社では終わらせない」、グリーCTOの藤本氏
インターネットの世界では「PHPの神」と言われ、社内外から多くの信頼を集めるのがグリーの藤本真樹CTOだ。約10年にわたって、同社の急成長と停滞を見てきた藤本CTOは、技術者集団を率い、“次のフェーズ”に進むことを目指す。その意気込みをCTOの藤本氏に聞いた。 藤本さんはグリーに入社する前から、PHPのエンジニアとしてIT業界では有名だったと聞いています。グリーに入る前までの話を聞かせてください。 大学生の時にソフトウエア会社でアルバイトをしていたのですが、それがエンジニアとしてお金を稼いだ最初の経験でした。当時、10歳以上年上の先輩従業員に面倒を見てもらい、色々な経験をさせてもらいました。 とにかく、会話の内容が分からない。その人たちに追いつこう、会話できるようになろうと思ったことを覚えています。今思うと、あの人たちも、今の僕より年下ですね。 それで、そこの会社経由で、システムインテグレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
