はてな、上場準備でミロク情報サービスの財務会計システム「MJSLINK NX-I」を導入 はてなとミロクは「マニアックさ」がよく似てる!?｜特集｜株式会社ミロク情報サービス
はてなは2013年6月、上場準備の一環として、新しい財務会計システム、ミロク情報サービスの「MJSLINK NX-I」を導入しました。1月に製品を選定し、4月からの並行稼働を経て、6月から本稼働を開始。導入までの経緯と効果を、ミロク情報サービスの担当者とはてなの担当者が集まり、座談会形式で振り返りました。 （※この記事は、株式会社ミロク情報サービスの提供によるPR記事です） ▽ 中堅・中小企業向け、新ERPシステム「MJSLINK NX-I」｜株式会社ミロク情報サービス ―― ということで本日は、ミロク情報サービスさんのオフィスにお邪魔しています。座談会の参加者は以下の5人です。よろしくお願いします。 ミロク情報サービス 平井なな恵（東京第一支社CS第二グループ） 麻生隆太（東京第二支社営業第一グループ） はてな 松田光憲（総務部 部長） 堀内潤一（経理部 マネージャー） 村上翔太（営業部
自分が職を失った経緯 - id:anatooのブログ
この記事は、How I Fired Myself.という記事の試訳です。 2010年の7月、私は22歳で、カリフォルニアのあるソーシャルゲームのスタートアップで働いていた。卒業したてで、私にとって初めての本物の職だった。給料をもらってアパートに住んだ。そのころ私は初めて大人になったような気分でいた。 その会社の主力製品であるRPGのコードを書く二人のエンジニアのうちの一人が私だった。大学では哲学を専攻していた。これはどういうことかと言えば、問題に対してどうやって考えればいいかを知っていた一方で、ベストプラクティスや実用的なデザインパターンに関する知識は最低限しか持っていなかった。私は信じられないほどの熱意でもって自分が持っているごく普通のLAMPの知識を駆使した。 私の悩みの種であるゲームデザイナーはしばしばWorld of Warcraftからインスピレーションを得ていた。WoWは、Bl
序章 レビューの観点を絞り込むと効果は上がるか
要件定義書や設計書のチームレビューを実施したとき、誤字脱字のような「軽微な指摘」ばかりが挙がり、テスト工程になってから修正工数の大きい不具合がいくつも見つかったという経験はないだろうか。 一般的なシステム構築プロジェクトでは、要件定義書や設計書のレビューに費やせる時間は限られている。多くの場合、その時間は十分とはいえないだろう。レビューで軽微な指摘に時間をかけてしまっている状況は、決して好ましくない。 本来レビューで注力すべきは、「重大な指摘」を数多く挙げることである。ここでいう重大な指摘とは、一般的な意味と異なり、レビューで見逃しテスト工程になって検出した場合に修正工数・コストが膨らむものを指す。致命的な欠陥であっても、テスト工程で検出して修正すれば十分なものへの指摘は含まないことに注意してほしい。なお、重大な指摘と軽微な指摘のどちらでもない中間的なものは「グレーな指摘注1」と呼ぶことに
客が本気にならないといいシステムができない。東証arrowhead成功の鍵とは ～ Innovation Sprint 2011
客が本気にならないといいシステムができない。東証arrowhead成功の鍵とは ～ Innovation Sprint 2011 2010年から東京証券取引所で稼働を始めた新しい株式売買システムのarrowhead（アローヘッド）は、高速化が進む世界の証券取引所の中でも世界トップレベルのレスポンスを達成したと伝えられています。 そのarrowheadのプロジェクトはどのように運営されていたのか、そしてトラブルなくシステムが稼働した成功の背景に何があったのでしょうか？ 1月14日に都内で行われたイベント「Innovation Sprint 2011」で、東証側のシステム構築担当者だった宇治浩明氏が講演を行いました。 世界の高速化競争とトラブルによる危機感が背景に 東京証券取引所 株式売買システム部長 宇治浩明氏。1年前に投入した東証の新しい株式売買システム「arrowhead」は、それ以前に
特許庁の情報システムについて - myatsumoto blog
例の特許庁の情報システム刷新の頓挫について興味があるので調べている http://itpro.nikkeibp.co.jp/article/NEWS/20120120/379019/?ST=cio とりあえず、まとめブログで探したのだが http://alfalfalfa.com/archives/5124175.html mP78iXTkの言ってることが尤もらしいので参考にして 報告書と照らし合わせてみたら全然違った。 特許庁の報告書に不備が60M項目あると書いてあったろ？ オレの説明したのはその中の1個の話ｗ とりあえず2chは1,000レスしか出来ないが説明欲しいか？ 60Mステップは開発規模の話であって不備の話ではない。 報告書には 開 発 規 模 に つ い て は 、平 成 ２ ２ 年 １ ２ 月 、約 ６ ０ Ｍ ス テ ッ プ に 達 す る と の 見 積 も り が Ｔ
目指せ「社長不要の会社」：日経ビジネスオンライン
このコラムについて 中小企業の経営にコンピューターをどのように利用すればよいのでしょうか。北海道で問屋を営む現役社長が経営の悩みとコンピュータ利用の悩みを語り、読者の皆様と考えていきます。著者は30代の時オフィスコンピューター販売会社に出向しプログラマーとSE（システムエンジニア）を務めたユニークな経歴を持っています。 記事一覧 記事一覧 2012年9月11日 何事も「人」が主役、相手の理解と賛同が不可欠 10年を超えるEDI推進から学んだこと 相手が知らないことを伝える場合、未知の情報は一つに止めるべきである。知らないことを続けて説明されると、聞く意欲が削がれてしまう。未知のプロジェクトに10年取り組んで学んだのは、こういう当たり前のことだ... 2012年5月28日 “効率改善”と称する活動の曖昧なメリット 手間は増えても実入りは増えず 効率改善はどんなメリットを与えるのでしょう。分析
新ビジネスモデル研究会（第27回）2010/3/30 ビジネスプロセス革新協議会（BPIA）
杉浦 和史 氏 はじめに－現場主導の仕様作成 本日は、システム開発の進め方についてお話いたします。 現場主導の仕様作成について、宮田眼科病院院内総合電子化プロジェクトの実例を示しながらご説明いたします。私は、2000年から宮田眼科病院の業務改革とそれを踏まえてのシステム整備を指導しています。この病院は宮崎県都城市に本院あり、分院が鹿児島市にあります。地方にありますが、開業から50周年を迎える病院です。来院患者数が年間約15万人、手術件数は約8000件の病院です。規模的には眼科で全国２位くらいだと思います、眼科というのは検査項目が95種類あり、一つの診療科の検査としては最も数が多く、また、時間辺りに診る患者の数が多いのも眼科の特徴です。宮田眼科病院では、現場の人達が仕様を作成しています。しかも、基幹業務の仕様作りですから、本当に作れるのかと思うかもしれません。ところが当院では、ベンダのＳＥ
信じられますか？ 看護師や検査員がシステムを設計する病院：日経ビジネスオンライン
気になる記事をスクラップできます。保存した記事は、マイページでスマホ、タブレットからでもご確認頂けます。※会員限定 無料会員登録 詳細 ｜ ログイン 「この仕事の流れをこう変えれば、BPR（ビジネス・プロセス・リエンジニアリング）ができませんか」。 現場の日常会話でBPRという言葉が出てくる組織はそう多くはないだろう。BPRという言葉があまり使われなくなったからだ。ただ、製造業の場合、BPRを「業務改革」あるいは「カイゼン」に入れ替えれば、同様の発言が飛び交っているに違いない。 「BPRを考えて、新しい仕事の手順を整理し、新手順を処理する情報システムの操作画面とその遷移の仕方を決めました」。 この発言は、業務を改革する案に加え、必要な情報システムまで自分で設計するという意味である。現場担当者がここまでやれる組織はまれであろう。「情報システムの設計や開発は本業ではない、専門家に任せるべきだ」
みずほ銀行、障害の発端は人為ミス - 日経コンピュータReport：ITpro
「社会インフラを担う銀行として、あってはならないトラブル。ご迷惑をおかけした皆様におわび申し上げる」。みずほ銀行の西堀利頭取は、3月15日から続く大規模システム障害に関する記者会見でこう陳謝した。 15日朝に表面化した障害は、振り込みシステムから起きた。「初動対応に不手際があった」（西堀頭取）ため、これが勘定系システムに波及（図）。その結果、最大で116万件の振り込みが未処理になった。窓口業務やATMもたびたび停止した（表）。
常識破りの運用コスト削減策
情報システムの運用・保守コストを削減する努力は、これまでも続けてきた。もうこれ以上、減らせない---。リーマンショック以降、常識を打ち破るようなコスト削減策を“発明”した企業が続々と現れている。仮想化技術の導入や外部委託費用の引き下げ交渉といった定番の方法だけでは、運用・保守費の削減に限界がある。ユーザー企業20社への取材で判明した、最新のコスト削減策を紹介する。
鶴は千年、亀は万年、システムは百年
「システムって、一定期間後にすべて作り直すものなんですか」。20年ほど前の話だが、あるコンピュータメーカーのベテラン営業担当者を取材していた時、思わずこう言ってしまった。システムエンジニア（SE）が苦労して作ったシステムの寿命が案外短いことに驚いたのである。 「オンラインシステムがよれよれになる」。この表現を聞いたのも、その営業担当者からであった。企業の情報システムについて詳しくない、と正直に言ったところ、彼は次のように説明してくれた。 「新しいオンラインシステムを開発して動かしますね。最初はぴかぴかです。でも、使っているうちに、一部を直したり、新しい機能を追加したりします。するとだんだん、プログラムが傷んできます。10年も使ったら、よれよれでもう直しようがなくなる。そのころには最新のコンピュータが発売されていますから、それを買ってもらって、プログラムをまた一から作るわけです」。 「せっか
マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
還暦まで後ひと回り［2］ITエンジニアよ、パッケージを目指せ（その2）！
1000本ぐらい売れるだろうと思って2000年にリリースしたパッケージ（株式会社ヤザワの製品）は、最初の1年間でわずか2本しか売れませんでした。今回は、その原因を振り返ってみます。反省会です。 ●反省1 作ればお金がもらえるという意識があった 前回もお話しましたが、受託システム（特定の顧客の依頼に応じて作るプログラム）の開発ばかり手がけてきた私には、プログラムを作ればお金がもらえる、という意識が染み付いていました。これは、パッケージ（不特定多数の顧客に販売するソフトウエア）には当てはまりません。パッケージは、売らなければお金がもらえません。 そんなこと百も承知のはずなのですが、パッケージを開発しているときに、いつの間にか、作ればお金がもらえるという意識になってしまったのです。パッケージは、「このソフト売れるの？」「売れるかどうかわかりませんが、作ることはできます」ではなく、「このソフト作れ
システム開発実践講座
システム開発でデータベースを使う時には、売上伝票のようにデータを鑑部と明細に分けることがよくあります。 前回までに、鑑部を表形式にして、その後にテーブルの正規化を行いました。 次は明細部分の正規化が必要ですが、 その前に、今回は明細を表形式にするところから始めましょう。 これまでに行っている部分の復習です。 売上伝票を鑑部と明細部に切り分け、 関連付けるために、 明細部に「伝票No」の項目(列)を加え、 明細部の各行を、一意に識別するため、主キーとして「明細No」を加えた状態がこれです。 ・明細部 ＊一意とは、同じデータが他に無く、重複しないことです。 ＊主キー(primary key)とは、レコードを「一意」に識別するためのフィールドです。 ＊明細部での 伝票No は主キーではなく、外部キーなので、重複してもOKです。 思い出しましたか？ やっと準備が整いましたｗ リレーショナルデータベ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
みずほ銀行ちゃんシステム切替手術に成功（なお、二年後には心臓移植レベルの大手術が控えている模様） : 市況かぶ全力２階建
サイボウズ ソリューションセンター
system-initiative.com - 
バージョンアップを賢く乗り切る
CiNii Research
gauchedavinci wiki - PukiWiki