タグ

システムに関するkoichi99のブックマーク (9)

  • 簡単だと誤解されがちな、システムの「新元号」対応(BCN) - Yahoo!ニュース

    【日高彰の業界を斬る・13】 新元号の発表は、2019年5月1日の改元の半年前と言われていた時期もあったが、新聞報道によると、政府会合では改元1カ月前に発表する方針で固まったようだ。 改元に関して合わせて話題に上るのが、情報システムの改修だ。民間企業の日常業務では西暦を使うことが多いが、官公庁、金融機関、公的機関に提出する文書等では、まだまだ和暦が使われており、日々の業務で使われているシステムが新元号に正しく対応できるかは、業種を問わずあらゆる組織における関心事になっている。 「そんなこと今から簡単に準備できるじゃないか。とりあえず“??”とでも表示されるようにしておいて、新元号が発表されたらそこだけ書き換えればいいのでは」 このように思う人は多いだろう。筆者もまさにそう考えていた。しかし、長年にわたって使い続けられているプログラムに手を入れるとなると、そう簡単な話ではないらしい。 マイク

    簡単だと誤解されがちな、システムの「新元号」対応(BCN) - Yahoo!ニュース
  • タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話

    何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に

    タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
  • 6000人が作ったシステムは必ず動く:ITpro

    最盛期の開発要員6000人,開発工数11万人月,投資額2500億円,取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ,勘定系システム一プロジェクトの成果物である。6000人のシステムズエンジニア(SE)が作り上げた巨大システムは,2008年5月の連休明けに必ず動くはずだ。 23年間にわたって情報システム開発プロジェクトの取材を続けているが,6000人のSEを集めた事例は過去に一度も見聞きしたことがない。世界を見渡してもおそらく例がないはずだ。これから何年間,記者を続けるのか分からないが,今回の三菱東京UFJ銀行を除けば,6000人を動員するプロジェクトを取材する機会は二度とないだろう。 6000人のSEが同時期に集まったのであって,「6000人月」ではない。開発工数は先に書いた通り,11万人月である。この数字も凄い。一体何を作ったのかと思ってしまう。正確にはこのSEパワーは開

    6000人が作ったシステムは必ず動く:ITpro
  • 日本でアジャイルが流行らない理由 - @ledsun blog

    ポジション的なもの 個人的に、アジャイルは「(あんまり未来や遠くのことを考えるのをやめて)目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは? と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ

    日本でアジャイルが流行らない理由 - @ledsun blog
    koichi99
    koichi99 2016/06/21
    返答が楽しみ。
  • 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

    私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ15年ぐらい実施し、導入の支援をしている。私はかつては、日の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか?ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して

    私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
    koichi99
    koichi99 2016/06/20
    メリットはシンプルな事じゃないの?!いや、推奨はいないけど。
  • ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン

    同期処理が失敗した原因は、4台をつなぐスイッチの不具合。具体的には、スイッチが故障状態であるにもかからず、故障を知らせる「故障シグナル」を発信しなかった。国内線システムは故障シグナルを検知するとスイッチを予備機に切り替えるが、今回はその機能そのものを作動できなかった。 スイッチは完全に停止したわけではなく、「不安定ながらも動作していたようだ」(同)。そのため、DBサーバー間の同期は順次失敗し、停止していったと見られる。 ANA広報によると、スイッチは米シスコシステムズ製「Catalyst 4948E」という。「2010年6月の発売開始以降、世界で4万3000台、うち日で8700台を販売しているが、今回の不具合は初めての事象と聞いている」(ANA広報)。なぜ「故障シグナル」が発信できなかったかは分かっていない。 1台での縮退運転を決断 4台の完全停止から37分後、ANAは1台のDBサーバー

    ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン
  • 乙武不倫の謝罪ホームページに見るサーバー構築:

    今回、不倫で有名になった乙武さんの謝罪文はAWSのS3で構築してる。技術的にもプロの犯行だ。S3とは、ざっくり言うとAmazonさんが運営してるほぼ絶対落ちない静的サーバのことです。http://ototake.com をDNSで全部S3に降ってる。要するに謝罪文しか表示しないけど絶対落ちないサーバをAmazonさんから短期的に借りる。今後、芸能人の謝罪文はAWSのS3というソリューションが増える。 GMOさんは芸能人に強いのに営業しないのかな。CAと組んで謝罪文サーバとか売ればいいのに。これは、芸能人のサイトを運用している人には重要な事例だ。教科書にのるかもしれない。むしろ、今後の謝罪ページのセオリーになるかもしれない。昔に比べて、DNSの浸透は爆速になったので、こういうのが可能なんだろな。 今まで、ototake.comを無視して、短期的にS3にDNSを降ることで、以下のメリットが有る

    乙武不倫の謝罪ホームページに見るサーバー構築:
  • 自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編)

    自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編) ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか? 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡

    自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編)
  • asahi.com(朝日新聞社):新幹線運休、同じフロアにシステム開発者 連携できず - 社会

    JR東日の新幹線が一時運休した問題で、「システムの不具合が発生した」と誤解した運行担当の指令部門が所属する新幹線運行部には、システムの開発者もいたことが関係者への取材でわかった。しかし連携できず「不具合ではない」と見抜けなかったため、1時間15分の全面運休を招いた。  JR東の発表によると、17日朝、東北新幹線の沿線で雪が降り、福島県内でポイントが切り替わらなくなる事故が相次いだ。新幹線運行部(東京都)では同8時ごろから、指令部門の7人が、24の列車ダイヤの変更を入力し始めた。  運行管理システム「COSMOS(コスモス)」では1分ごとにデータ修正が必要な箇所をチェックしており、上限の600件を超えると各列車の駅到着予定時刻を示す線がモニター上から消える仕組みになっていた。だが、これを知らされていなかった指令部門はシステムの不具合が起きたと考え、同8時23分に全線で停車を指示した。

    koichi99
    koichi99 2011/01/20
    開発者側からすれば、とんだとばっちりだな。
  • 1