クラウドに基幹を移行して5年超経過 - 急がば回れ、選ぶなら近道
もう5年か、まだ5年というべきかちょっと判断に迷う。大抵の業務系のシステムがクラウドを始めるのは現実的には今年来年以降になるので、今の自分達の状況は多分、今後の業務系システムをクラウド移行したユーザの近未来になると思う。ので、予想的にまとめておく。本格的にクラウドを利用した業務アプリケーションの5年がどうなるかの一つの指針になるかと。 以降は別に統計データでもなんでもなく5年間を眺めてみて自分の印象。 ・障害：大規模は５年で2-3回程度。一度は業務に影響が出て客先にお詫びに行った。AWSだったけど、サポートからは「もう回復してるのでチケットクローズね」みたいな話だったと記憶している。その後は大体四半期に一回程度のN/W障害。障害は普通に起きているし、オンプレと比べてどうか、という比較では細かい障害件数は減った気はしていない。ただし、「ドカンと来るでかい障害」は確実に減った。 ・データ増加対
SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
「ソフトウェアの時代」について - 急がば回れ、選ぶなら近道
まぁなんか適当に思うことを。 ■ハードの限界の露呈 ムーアの法則の限界はITのあり方を根本から変えると思う。この四半世紀、ITの現場レベルでは「困ったらハード増強」が一つの基本政策であったことは間違いない。ハードウェアの進歩は結果として、IT全体のパフォーマンスを上げ、結果として社会における有用性を増した。その一方でハードウェアの高進はソフトウェアの進化を止めていた側面は確かにある。 ソフトウェアのレイヤー、とくにミドルレイヤー〜アプリケーションのレイヤーでは、通信にしろ、分散処理にしろ、DBにしろ、OSにしろ、「業界全体としてトコトンできるレベルまでやったのか？」という意味では、実際はやっていないと思う。もちろん、各セグメントではそれなりに追求はしたけど、ドカドカ、金突っ込んで全部ひっくり返すというまでには至っていない。これはIT全体に言えることだけど、ソフトウェアにコストをかけるよりも
みずほ銀行こうすれば救えるんじゃないかなあ - novtan別館
とにかく、3.11以来金融庁がうるさいので、ちょっと計画変えますって話もなにか問題があるのかどうなってるんだ報告しろで貴重な時間と金を吹っ飛ばすことになりかねないので計画を変えることに対して及び腰になってしまうという問題があるんじゃないかと思うんですよね。つまり、金融庁が余計な口を出さなければ計画が適正になるんじゃないの？ という話はさておき、やっぱりこっちの業界の人とあっちの業界の人では思うことにだいぶ差異があるんだなあと思いました。 で、結局何百億という予算は多重下請け構造の中で中抜きに中抜を繰り返され、最終的に実際に作業する人には時給数百円しか行き渡らないため、中国や台湾、ベトナムといったところから人が駆りだされてきて、現場の中国人が台湾人と殴り合いの喧嘩を演じるとかもう収集つかないところまで来ているという話です。原発事故の石棺処理みたいな煉獄が、こんな近所に存在しているかと思うと胸
ITは必要悪か？その2 - 急がば回れ、選ぶなら近道
大規模会社、特に社会インフラ系の会社で売上も兆に届くところでのITのあり方は、中小規模の会社とは全く違います。システム構築、とくにSI的な観点からは、実際のプロジェクト単位で見たときに大規模システムと中小規模システムを便宜的に一緒にして考察することが多いのですが、俯瞰したときのあり方は、まったくの別ものです。 大規模な会社では情報システムは、大きな組織のバックエンドの一部であると同時に、企業を動かす歯車として欠くことできない存在になっています。「ITがない」という選択肢は企業活動としてありえません。システムのあり方が大企業と中小企業では異なるため、中小企業でITの必要性という点と、大企業でのITの必要性では意味が大きく違います。明確に区別する必要があります。 ■あり方 大規模企業の内部において、情報システムはその企業が存続するための重要な機能を担っており、それなしでは企業は成立しません。大
SIはやめておけ
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない
RelaxTools Addin for Excel 2013/2016/2019/Office365(Desktop) | Excelを便利にする250以上の機能を体系化したアドインはこちらです。
TimeLeapの動作を変更しました(Version 4.27.2) TimeLeap の不具合を修正した際に、TimeLeapの動作を見直しました。 内容としては 「最新のブックに上書き」 の際に履歴を作成しないよう…
企業情報システムのモダナイゼーション - 勘と経験と読経
企業情報システムにはモダナイゼーションが必要だ、というInfoQの記事を見て考えたこと。単なる新規アーキテクチャへの移行の事ではなく、ソフトウェアライフサイクル全般のアップグレードについて。 モダナイゼーションは避けがたい道 企業情報システムのモダナイゼーションとは何なのか 元記事を読むと非常に包括的な事が書いてある。自分なりに整理するとこういう感じなのだろうか。 ビジネスとITが共通言語を持つ アジリティーを考慮したビジネスアーキテクチャを構築する 情報システムをポートフォリオ管理し、移行のロードマップを描く システム部門とビジネス部門の統合 情報システムに関するナレッジマネジメント コーディネーションとガバナンス、リスクマネジメントの確立 結局は、IT部門とビジネス部門の役割分担が変わるという事になるのだと理解している。IT部門が企業の情報システムを集約管理することは、ガバナンスの観点
2014年のSI業界の展望 - プロマネブログ
2014年もいよいよ始まりました。 新年、今年の仕事初めに向けて、SI業界の今後について考えていきたいと思います。 ※オッサンの独断と偏見が混じっているので注意 なお、IT業界ではなくSI業界に限定しているので、WEB業界等その他のIT関連業は除外してます 大手SIerではデスマの災禍に見舞われる 昨年に引き続き、今年も企業のシステム投資欲は高まると想定されてます。 これまでのかなりの期間企業投資が低下していたこともあり、昨年は特に大手のSIer各社の数社は今までジリ貧で減少してきた顧客を取り戻すべく、売上の拡大を行おうと積極的な受注を行ってきてました。 結果、案件数過剰による無理な受注とそれによる開発力低下、費用増大がタタリ、大手SIerでは利益率低下を招く結果になったと考えております。 ※大手SIerで、プロジェクトマネジメントがあまり得意でない会社は特に。 今年のシステム投資欲の需要
請負より派遣がよい、切り捨てられるITベンダー
最近、ユーザー企業のIT投資が間接業務から直接業務の領域に移りつつある。ERP（統合基幹業務システム）の導入といった、会計などの業務の効率化のためのIT投資ではなくて、新たなビジネスを創ったり、既存のビジネスモデルを変革したりするためのIT投資にシフトしつつあるのだ。これからのビジネスはIT抜きでは不可能。だから、売り上げを押し上げるためにITを積極活用しようというわけだ。 実は、こうしたIT投資のシフトの過程で、ユーザー企業とITベンダーとの関係に本質的な変化が生じつつある。端的に言えば、ITベンダーにシステム開発を請け負ってもらう必要はなく、技術者を派遣してもらえば十分だ、ということになる。「派遣で十分」と書くと、技術者を軽く扱っているようだが、そうではない。優れた技術者ならむしろ直接雇用したい。ユーザー企業が切り捨てるのは、技術者個人ではなく、変化に対応できないITベンダーのほうであ
IT系上場企業の平均給与を業種別にみてみた 2013年版 ～ パッケージベンダ、SIer、ホスティング企業編
IT系上場企業の平均給与を業種別にみてみた 2013年版 ～ パッケージベンダ、SIer、ホスティング企業編 IT系企業で給与が高いのはSIerなのか、それともネットベンチャーなのか、ソーシャルメディア系なのでしょうか。Publickeyの恒例企画として、今年も上場企業を主な業種ごと分類し、調査しました。 前編のネットベンチャー、ソーシャル、モバイル編に続いて、後編ではパッケージベンダ、SIer／システム開発、組み込み開発、ISP／ホスティングベンダなどの企業について見ていきます。 この記事は、Yahoo！ファイナンスの「業種別銘柄一覧：情報・通信」および金融庁の「EDINET」で公開されている企業の有価証券報告書から、従業員数、平均年齢、平均年収などの情報を収集、Publickeyが独自の判断で主な企業をピックアップして業種を分類。平均給与が高い順に並べてみたものです。年収の単位は千円で
システムの「価値」をどう考えるのか？〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか？という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価
基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る（前編）
基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る（前編） 基幹システムをクラウドで実現する。その過程でどのような技術を用い、どのような苦労があったのか。小売り流通業である西鉄ストアの基幹システムをAmazonクラウド（以下、AWS：Amazon Web Services）の上で実現したノーチラス・テクノロジーズが、その詳細について紹介したセミナーを5月15日、アマゾンジャパン本社のセミナールームで開催しました。 大規模システム開発の現状、Hadoopの可能性、クラウドのメリットとデメリットなど、参考にすべき多くの内容が語られたセミナーでした。この記事ではその概要を紹介します。 止まってはいけない基幹システムをクラウドへ ノーチラス・テクノロジーズ 代表取締役社長 神林飛志氏（写真中央）。 西鉄ストア様の本部基幹システムをクラウドへ移行する
なんでもかんでもクラウドにあげるのか？ - 急がば回れ、選ぶなら近道
某エントリーの話で、「なんでもかんでもクラウド化なのか？」というお話もご意見も多数頂戴いたしまして。一応念押しですが、そういうつもりはまったくないですよ。以下、個人的な補足メモです。会社の意見ではありません。一応、会社の公式声明は「できるものは、とっとクラウド化したほうがいいですよ。」です。 クラウド化の是非については、いろいろあるでしょう。ユーザーの所属する産業毎にシステムのあり方・考え方は違うでしょうし、当然クラウド化すべきだという意見や、いやそもそも無理があるという意見もあると思います。ただ、今までのように先例がないから無理、という理屈は通用しなくなっているのが現状でしょう。その意味では無茶な理屈ではなく、普通に選択肢としてクラウド化が候補になっている、と思います。その上で、クラウド化しない、するという議論が普通にできる状態になりつつあると思います。 そんな中でいろいろ思うところをち
「オンプレミス・システムの終わり」の始まり〜AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道
個人的には割と大変だったので、その辺をまとめておきます。 ニュースリリースはこちら。 http://www.nautilus-technologies.com/topics/20130409.html 要するに本部系バックエンド基幹システムの「一式」のクラウド移行です。完全なミッションクリティカルシステムで、止まった段階で業務に確実に影響が出ます。 システムの機能概要 1.売上の確定処理と債権管理 POSデータの直結です。売上確定処理を行います。同時に債権管理も行い、F/Bからの入金データをそのままつなぎ込み、入金処理・債権の消し込み処理を実行します。マッチングは自動処理できるものは処理を行い、ヒューリスティックなものはユーザー判断に従います。 2.仕入・費用の計上と確定処理、および支払いデータの作成 費用・在庫の計上確定処理です。当時に支払データの確定処理を行います。EDI（BMS）との
第2回 なぜ、「技術力のないシステムエンジニア」が通用するのか？
（前回はこちら） 情報システムの構築には、多くの人手がかかります。「最大瞬間要員数100人」のプロジェクトがあったとして、100人のうち何人が顧客やエンドユーザーの顔を見ながら仕事をすることができるのでしょうか。 100名のうち半数近く、あるいは半数以上が、プロジェクトの「山場」に召集される、いわゆる「下流工程」を担当する要員です。彼ら彼女らは詳細設計書などのドキュメントが正確、かつ変更されないという前提で、その設計を実現するソフトウエア・プログラムの開発を担います。 設計書が間違っていたり、設計内容が変更されることは当然あり得ます。設計ミスを発見できる実力や、変更に迅速かつ柔軟に対応できる実力があれば、「人月単価」のアップにつながります。 ところが、設計を実現するという役割自体は固定化されています。顧客企業やエンドユーザーの顔が見える「上流工程」に関われる機会はなかなかないのが現実です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
地図を片手にアジャイル開発
コピーした画像を「Excel」へ自動でスクラップできる「imageClipPaste」NOT SUPPORTED
特許庁システム開発中断:東芝子会社など２社５６億円返還 - 毎日新聞
サービス終了のお知らせ