中田の質問箱です
みずほ関係者の方でしょうか。連日のように繰り返されるシステム障害とその批判を目の当たりにして疲弊しているのだろうとお察しします。ただ、仰っている内容はどれも妥当性に乏しいので、公言されるとますます批判の声が強まってしまうことが危惧されます。ご自身の反論が有効かどうかを検証する有力な方法は「他の2メガバンクではこのロジックは通用するか？」という考え方です。以下、すべてこのアプローチでご説明します。 まず「銀行リテールの利益は250億円しかなく赤字のこともあるのだから莫大な設備投資をすることは株主にとって妥当ではない」というのは論理が全く逆で、莫大な設備投資をしたのですからもっと稼がなければならないのに稼げていないことが問題なのです。MUFGやSMFGをご覧頂ければ銀行リテールだけでも1,000億円単位で儲けていることがわかるでしょう。しかもシステム統合に要した費用はMUFGで3,300億円、
「現場で役立つシステム設計の原則」はプログラミング設計の普遍的な教科書 - ビープラウド社長のブログ
日本のDDD（ドメイン駆動設計）界の父ともいえる増田亨さんが著した「現場で役立つシステム設計の原則」を頂いたので、早速拝読させていただきました。 本書をおすすめしたい人 本書は、システム開発で以下のような問題を抱えている人におすすめです。 既存システムのソースコードの可読性が低く、理解に時間がかかる 機能追加・改修時の影響範囲調査に時間がかかる 機能追加・改修時の工数が予想以上にかかる テストコードが書きにくいソースコードになりがち 機能を追加・改修時の影響範囲が大きくなりがちで、テスト工数がかさんでいる デグレの確認に気を使い、多くの時間をかけている 不具合が発生したときに、調査・解決に時間がかかってしまう 新しいメンバーがプロジェクトに参画した時に、業務知識を伝えるのに多くの手間がかかる これらの問題のために、生み出す価値以上に、仕事時間が増えている このような問題を解消し、変更に強い
なぜ「システムが無事に動いている」ことの価値は理解されないのか
最近はあまり技術的な仕事をしていないんですが、実は私は元々DBエンジニアです。 OがつくDBとか、PがつくDBとか、mがつくDBとかをいじくって、クエリを書いたり、テーブルの設計をしたり、パフォーマンスのボトルネックをあれこれ調べて解消したり、INDEXヒントを総とっかえして頑迷なオプティマイザをぶん殴ったりすることが主なお仕事でした。今でもたまーにそういうことをします。 同業の方であればお分かりかと思うんですが、DBのパフォーマンスは凄く唐突に、かつ多くの場合極端に落ちます。そして、DBのパフォーマンスが落ちると物凄く広範囲に影響が及びます。 アプリケーションサーバ、重くなります。クライアント、ろくに動かなくなります。お客様、切れます。カスタマーサポートにはわんさか電話がかかってきます。 ただ「遅くなる」だけでも十分に影響は甚大なのですが、それ以上のトラブルが発生するとまあエラいこっちゃ
基本/詳細設計って呼び方やめませんか - Qiita
システムエンジニア Advent Calendar 2016 の 15 日目です。システムエンジニアなら避けては通れない設計について考えたことを書いてみようと思います。 設計ってむずかしい システム開発の様々な局面で「設計ってむずかしいなあ」と思うことがあります。細かいところはシステムの規模や自分のポジションによって変わりますが、だいたい以下に挙げたようなことで困ることが多いです。 設計 なにを、どこまで、どんなフォーマットで書くといいんだろう？ 各ドキュメントはどうやって関連付けるといいんだろう？ 基本設計書と詳細設計書はなにが違う？ 開発 なんでこういう設計になっているんだろう？ 設計されていない組み合わせのデータはどう処理すればいいんだろう？ 試験 試験データのパターンや量はどれくらい用意すればいいんだろう？ 運用 設計と実装が乖離していてなにが正しいのか分からない... 仕様変更や
ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD
これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり
「必要なこと」より「excelでやりたいこと」を優先するとシステム構築は失敗する - プロマネブログ
<追記> 追加記事を書きましたhttp://getlife.hateblo.jp/entry/2013/12/07/034949 エクセルでできることができない何百万のシステム・・ 多分現場の人かな。往々にして、システム導入を決定したトップの目的が現場に伝わらず、既存ツールとの差だけが目につくってことはよくあるし。ま、一部業務をexcelで残すみたいに調整すればいいんじゃないかな。 オッサン、こういうシステムネタ好きです。昔高度情報技術者試験を受けた時を思い出すなあ。 大体、仕事やっているとこの手の「今やっている仕事と違う～」だとか、「役員はシステム導入ばっかり言って現場をわかってない」とかそんな揉め事ばかり。 まあ、そういう揉め事を丸め込む納得できるよう調整するのがオッサンの仕事なんですけどね。 本当にやりたいことを見つける システムの要件定義のキモは 必要なこと やりたいこと やらない
システムの「価値」をどう考えるのか？〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか？という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価
アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性 - プログラマの思索
アジャイル開発はソフトウェアの品質特性のうち、機能性と信頼性の問題点をすり替えることによって、ソフトウェア開発特有の特徴をうまく取り入れているように思える。 考えたことをメモ書き。 【参考】 ソフトウェア品質特性(ISO/IEC9126)の解説 ソフトウェア品質特性について ISO 9126 - Wikipedia 品質改善.com - 品質特性とは アジャイル開発が重視する品質特性～保守性と移植性: プログラマの思索 【1】ソフトウェアの品質を話す時、普通は、機能性と信頼性が暗黙のうちに前提にされている。 仕様書に書かれた機能がシステムに反映されていてそもそも使えるのか、そして、システムの障害が少なくて安定稼働しているか、という点。 ウォーターフォール型開発では、詳細な仕様書を作り、手戻り作業がない前提でシステムを作り始める。 一括請負契約が理由でもあるが、外部設計で決定した仕様に基づい
つーか、日銀のシステム使えば国庫金としてわりとカンタンに整理つけられ..
つーか、日銀のシステム使えば国庫金としてわりとカンタンに整理つけられると思うんだが。 それやらないってことは、これ休眠口座のカネを活用っつーよりは、ポジション作りの方が重要なんだろうな。 元日銀マンの俺が言うけど、普通に日銀ネットでやれるよこの程度のこと。 休眠口座のカネを一回日銀（＝国庫金）にブチ込んで、預金者からの申し立てがあったときは 銀行が日銀に申し立てるってことでフツーにクリアできる。だって、銀行預金と日銀はツーカーなんだから。 預金口座の管理業務なんて日銀の支店にやらせりゃよろしい。確かに結構コストはかかるだろうけど、 国庫金システム専門家揃いの日銀マンが新しくシステム組めば、たぶん確実に一番安くやれる。だって、既存のを拡張するだけだし。 現業（つーか特定職）職員とパン職にやらせろよこんな仕事。 つーか、国庫金として計上するならどの道日銀に入れるしかないのに、その間に基金とか意
新信号機システムで渋滞悪化 NHKニュース
新信号機システムで渋滞悪化 11月5日 7時40分 警察庁が、全国に先駆けて滋賀県に導入した、交通渋滞緩和のための新しい信号機のシステムで、逆に渋滞が悪化していることが分かり、警察庁は今後、詳しい調査を行って検証することにしています。 この信号機のシステムは、「ムーブメント信号制御」と呼ばれるもので、センサーで読み取ったその時々の交通量に応じて自動的に信号を調整し、渋滞の緩和に役立つと期待されています。警察庁では、ことし３月、全国に先駆けたモデル事業として、国道１号線など交通量が多く渋滞しやすい滋賀県内の４つの交差点に、１億４０００万円をかけて導入しました。しかし、滋賀県警察本部が、この半年間、新しい信号システムの効果を確かめた結果、交差点を通る１０本の道路のうち９本で、これまでより渋滞が悪化していたことが分かりました。最も悪化した道路では、渋滞の時間がおよそ４倍に延びたということです。こ
システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
野人観察日誌: 業務システム開発の現実
2008年09月(4) 2008年08月(3) 2008年07月(2) 2008年06月(2) 2008年05月(4) 2008年04月(3) 2008年03月(4) 2008年02月(6) 2008年01月(6) 2007年12月(5) 2007年11月(2) 2007年10月(5) 2007年09月(9) 2007年08月(9) 2007年07月(6) 2007年06月(3) 2007年05月(9) 2007年04月(3) 2007年03月(1) 2007年02月(3) ジャパンカップ by akira@Bananas (09/09) 2008 DCA World Championships by ひろぽん (09/06) 2008 DCA World Championships by Yazin (09/05) 2008 DCA Worl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自律制御しながら動的平衡状態の系を作るWebシステムとその未来 / a Future of Dimensionless Autonomous System
悩める金融系SEの軌跡
https://www.gembook.org/benefits_of_dynamic_typing.html
地デジ保護新方式、'12年7月末に関東から開始