今日のむいむい @mui_king 先日システム会社勤務の友だちと飲んでて 「今までクライアントの偉い人に却下されがちだったやつが 『これをケチるとみずほみたいになりますよ！』 って言うとなんでも通るようになった」 ってくだりで千切れるほど笑った。みずほ、役に立ってるぞ
今日のむいむい @mui_king 先日システム会社勤務の友だちと飲んでて 「今までクライアントの偉い人に却下されがちだったやつが 『これをケチるとみずほみたいになりますよ！』 って言うとなんでも通るようになった」 ってくだりで千切れるほど笑った。みずほ、役に立ってるぞ
システム開発が大幅に遅延し、サービス計画が頓挫したとして、野村ホールディングス（HD）と野村証券が日本IBMを相手取って計約36億円の損害賠償を求めた裁判。2019年3月の一審東京地裁判決では一部の請求を認め、日本IBMに約16億円の支払いを命じた。 だが、2021年4月21日の控訴審判決で東京高裁（野山宏裁判長）は一審判決を変更し、野村側の請求を棄却した。なぜ一審判決が覆され、野村2社が逆転敗訴となったのか。約90ページに及ぶ判決文から控訴審判決の経緯を読み解く。 プロジェクト遅延の原因は野村側と認定 訴訟の対象となったシステム開発プロジェクトの始まりは2010年。野村2社は、個人が資産運用を証券会社に一任する金融サービス「ラップ口座」向けフロントシステムの開発を日本IBMに委託。スイスの金融系ソフト大手テメノス（Temenos）が開発したパッケージソフト「Wealth Manager」
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 先日、Microservices Meetup vol.2という勉強会に参加してまいりまして、マイクロサービス・アーキテクチャ（以下、MSA）の教科書的なメリット／デメリットをまとめておくと有益ではないかと思うようになりました。 Microservices Meetup vol.2のTogetter（資料のリンクあり） というわけで、本エントリーで、マイクロサービス・アーキテクチャ（以下、MSA）を従来のモノリシック・アーキテクチャと比較した際の、メリット／デメリットを書きたいと思います。 Sam Newmanのマイクロサービス本1の内
みずほ銀行は2016年12月に予定していた新たな勘定系システムの完成時期を遅らせる検討に入った。システムの一部で実施中の動作確認テストを延長する必要があると判断した。遅らせれば2度目の延期となり、新システムの運用開始は18年夏以降になるとみられる。みずほは過去に2回の大規模なシステム障害を起こしており、今回も万全を期すことにした。勘定系システムは、口座の入出金や資金決済、口座管理などを担うシス
業務システムのあり方を構想する際には、論理設計と物理設計とをフェーズ分けしたほうがいい。システム要件を仕様化しやすくなるだけでなく、スキル育成や効率改善の基礎となるからだ。それはソフトウエアの特性にもとづくプレゼントのようなもので、ありがたく活用したい。 そもそも「論理設計」とは何か。「受注情報だけを管理する」という単純なシステム要件があったとしよう。その際、たとえば以下のような「論理定義」がまとめられることになる。 １．業務構成 受注登録業務、受注保守業務、受注照会業務 ２．データ構成 受注見出しテーブル、受注明細テーブル ３．機能構成 受注一覧機能、受注登録機能、受注保守機能、受注照会機能 ここでは定義要素の字面だけが示されているが、それぞれ独特な形式の詳細情報を伴う。たとえば「業務構成」は「いつ誰がどのようにこのシステムを利用するか」についての定義のまとまりなのだが、それぞれ「いつ(
システムやワークフローを分かりやすく説明する際にフローチャートを使うことがあります。特に業務システムなど、多数のシステムが複雑に組み合わさって処理が実行される場合、きちんと可視化されているかどうかで結果が大きく変わる可能性があります。 Excelで仕様書を書いているとExcel上で完結しそうです。しかしこれでは検索性やメンテナンス性がよくありません。そこで仕様書をMarkdownやHTMLで書いているならばflowchart.jsを使ってみましょう。 flowchart.jsの使い方 flowchart.jsのデモです。専用の記述方法に沿って書くことで、右側のようなフローチャートが生成されます。URLがあるところはクリッカブルになっています。 さらにカラーリングの指定もできたり、縦ではなく横に広がっていく形にもできます。 flowchart.jsはSVGで生成しているのがポイントで、元文書
第1回と第2回で解説したように、戦略を確実に実行に結び付けるには「伝達率の問題」「変換の問題」「言語の問題」という三つのハードルを乗り越えなければなりません。 そのためには、プロジェクトマネジャーが第4回で説明した「要求を引き出し、議論を深める力」「価値を設計する力」「不確実性に対処しながら、やり切る力」という三つの力をもって、戦略を現場の言葉に翻訳するための継続的なプロセスが必要となります。それが「マネジメントサイクル」です。 マネジメントサイクルで最も有名なのは「PDCAサイクル」でしょう。「Plan（計画）－ Do（実行）－ Check（評価）－ Action（改善）」のサイクルです。品質管理の父といわれるウィリアム・エドワーズ・デミング博士が提唱したことから「デミングサイクル」とも呼ばれます。 マネジメントサイクルには他にも「PDC：Plan － Do － Check」や「PDS：
※本エントリは､自分の気持ちを整理するという事と､同じ様なやりきれない気持ちを抱えている人達に対して､何かのきっかけになればいいなと思い書きました｡自分の不満の憂さ晴らしでもなければ､SIerで働く人達を否定するものでもありません(そんな低俗な事をするつもりは毛頭無いです…)｡自分が現状の業界構造に疑問を覚えたのは事実ですが､それでもその中で正しい道を進もうと頑張る人達を心から尊敬しています｡ 2013年8月31日を持って､新卒で就職したSIerを退職しました｡ 2012年4月に入社してから約1年半､社会人としてのマナーやプログラマとしての基礎を教えて頂きました｡ 関係者の皆様､大変お世話になりました｡ 退職を決めた理由ですが､これといった契機があったわけではありません｡ 強いて言えば､下記の様な問題を考え続けた結果､転職という選択肢が自分にとって最善であると感じたという事です｡ 業界の方
「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか？という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価
ソースコードレビューは意味がないなんて言われることもあるが、適切に運用すればとても役立つシステムだ。他人のソースコードを見て勉強したり、人が見ることを意識するので奇麗なコードを書くようにもなる。 Redmineでソースコードレビューを Redmineにはリポジトリブラウザがついているが、ソースコードレビュー機能がないのが残念に思っていた。が、プラグインを使えば実現できるのだ。 今回紹介するオープンソース・ソフトウェアはRedmine Code Review プラグイン、Redmineにソースコードレビュー機能をつけるプラグインだ。 Redmine Code Review プラグインはRailsのプラグインのようにvendor/plugins以下に配置する。そしてモジュール画面で有効にすれば利用が出来る。使い方は簡単で、リポジトリを表示した際にあるDiffリンクをクリックすれば良いだけだ。
特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には（１）コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、（２）霞ヶ関から流れて来るお金にたかる IT ゼネコン、（３）そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた９９億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ
BarkeepはGitリポジトリに対応したユーザビリティ高いコードレビューシステムです。 会社でプログラミングを行っているとそのコードの品質はばらつきが出てきます。そうするとバグが多くなったり、予期しない問題に直面したりします。それを防ぐのに有効なのがコードレビューです。Barkeepはユーザフレンドリーなコードレビューシステムになっています。 メイン画面です。コミットログが並んでいます。 詳細です。差分が表示されています。 サイドバイサイド。アニメーションしながら表示されて格好いいです。 コードをダブルクリックするとコメントできます。 コメントしました。 一つにまとまっている場合もコメントできます。 レビュー依頼もできます。 ステータスです。レビューされている、されていないといった情報が一目で分かります。 検索結果です。 こちらはプロフィール。 Barkeepは検索における入力補完やフィ
米ワシントンD.C.（Washington D.C.）にあるコンテンツ会社オートメーテッド・インサイツ（Automated Insights）で、自動生成プログラム作成した記事コンテンツを表示させたコンピューター画面（2012年7月9日撮影）。(c)AFP/Jim Watson 【7月13日 AFP】米ジャーナリズム界にさっそうと現れたその「新人記者」は、コーヒーブレークも取らず、猛烈なスピードでひたすら記事を量産するが、福利厚生は適用されない。 その正体は、コンピューター・アルゴリズム。企業の業績報告書やスポーツの試合結果といった膨大な量の生データから、必要な情報だけを抽出し、文章として読める形に整えるのだ。米国の新聞紙面やニュースウェブサイトで今、こうしたアルゴリズムが生み出す記事がじわじわと数を増している。 「基本的で定型の記事ならば、何にでも使える」と、メディア関連リサーチ会社アウ
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
1 名前:以下、はてなにかわりまして元増田がお送りします。 投稿日:2012/02/23 11:49:47うちの団体で、インターネットで講習会を申し込めるようなシステムを作ることになって、ネットで調べた何社かに見積りを頼んだら、出てきた金額が業者によって２５万～４００万で出てきた。 見積りの項目も各社バラバラだしそれぞれの意味も、なにがなんだか素人の俺にはさっぱりわからない。 年間に１万人ぐらいが100会場でやる研修の申込みを受付けられるようにするってだけの機能なのになんで各社こんなにもバラバラなのかが理解不能。 若いってだけでITに詳しいと思われて、担当にあてがわれて、２５万～４００万の間で業者決める手掛かりが全くない状態でどうすればいいんだ？（それでもし業者選びに失敗したらやっぱり俺のせいなのかな。。） 続きを読む
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
