賞味期限を見極める
「いつまで使うのか」、そして「いつ捨てるのか」-。ムダなコストを使わないよう今あるシステムを最後まで使い切るには、“余命”の把握が欠かせない。この努力を怠るとハード/ソフトの保守サポート期間切れに直前で気付き、あわてる羽目になるかもしれない。ほとんどビジネスに貢献しないシステムを保守し続け、予算を無駄に垂れ流す可能性だってある。 システムの寿命をコントロールする第一歩は、余命の把握から始まる。 保有するハード/ソフト資産の種類や数、購入日、購入価格、簿価などはどこの企業も台帳で管理している。だがハード/ソフトの保守サポート期間がいつ切れるかや、保守運用費に見合った効果をシステムが上げているかまで、きちんと管理できている企業はほとんどない。 システムの余命年表を作る 「当たり前のことだが、自社のシステムは自分で守らなければならない」。JUKIの松本部長は、ユーザー自らがハード/ソフトの余命を
システム延命で逆風を乗り切れ：自己防衛でコントロール：ITpro
システムの寿命は自社の事業戦略に合わせて決めるもの。だが、税制上の減価償却期間やハード/ソフトの保守期間といった外部要因で決まっているのが実情だ。 ハード/ソフトを提供するベンダーが保守サービスを長期間提供し続けるようになればユーザー企業は苦心せずにすむ。 だがベンダーが変わる兆しはない。「保守サポート期間の延長は製品価格を2～3倍に上げないと採算がとれない」と異口同音に主張する。 結局、ベンダーの論理に振り回されないためには、ユーザー企業が自己防衛するしかない。 10年前のPCを保管 東京都多摩市にあるJTBグループの情報システム会社、JTB情報システム。同社の会議室には年季の入ったパソコン約50台がところ狭しと積み上げられている（図6）。リサイクル業者が来るまで一時的に保管しているわけではない。いつでも現場に配備できるよう待機させているのだ。 これらのパソコンは1998年製造の日本IB
世界最大のプロジェクトをこう見積もった
大規模，複雑，厳しい納期――。昨年秋に完全統合したJAL/JASの情報システム。成功を収めたプロジェクトの裏に，見積もり精度の高さがあった。プロジェクト・マネージャ（PM）を務めた岡村正司氏に，どのように見積もったのかを聞いた。（聞き手は本誌 池上俊也） JAL/JAS統合とはどんなプロジェクトだったんでしょうか。 岡村：昨年10月に完全統合しましたが，日本航空（JAL）と日本エアシステム（JAS）の約160のシステムを，JAL側のシステムに片寄せするものでした。工数は全体で1万2000人月，規模は8000万ステップと，とんでもなくデカいものです。IBMが手掛けてきた案件の中でも世界最大級でした。 時間の制約も厳しい。2002年初頭に始まったプロジェクトは，2年間で中核部分をすべて統合しなければならない。失敗は許されませんでした。 岡村さんがPMとして招かれたときの様子を聞かせてください。
3000億円企業のシステム統合 わずか8カ月間でR/3を片寄せ
田辺三菱製薬は2007年10月1日の合併を機に、旧田辺製薬と旧三菱ウェルファーマの基幹システムを統合した。合併の基本合意から、8カ月後の本番稼働という“超”短納期の統合だった。成功の要因は、スケジュール順守の目標を掲げ、基幹系、営業系など4つの主要システムのすべてを、旧会社のいずれかのシステムに片寄せしたこと。そのシステム評価と、事業部門に対する説得に注力した。 「新システムになると、そんなこともできなくなるのか。この前も我慢してくれと言われたが、まだ我慢しなければいけないのか？」。事業部からは容赦ない言葉を浴びせられる。「すみません。すべてを今まで通りにしようとすれば、10月1日にシステムが稼働できなくなるんです」。田辺製薬（当時、現在は田辺三菱製薬）の木之下敦彦情報システム部長はプロジェクトが始まってからというもの、事業部に頭を下げてばかりだった。「システム統合が間に合わなければ顧客に
このままだとSIerの給与水準は下がっていく - ひがやすを技術ブログ
今後のビジネスの方向性として、たいていのSIerは、上流を強化するだとか、上流にシフトするだとか、上流に専念するなんて答える。 下流には、付加価値がつけられないから、自分たちの付加価値をつけるためには、上流を強化するしかないと思っているSIerの人も多い。 でも、みんなが同じ方向を向いたら、最後は価格競争になる。 日本の市場が厳しくなっているので、ブランド力よりも価格が重要視される割合が増えてきているのです。 ブランド力が通用しない市場は、自然と価格競争になるわけですが、今のSIerは、どこも同じような重量級の開発プロセスだから、開発プロセスでは差がつかない。後は、下請けの単価を下げるか、自分たちの給料を下げるかになってしまいます。 つまり、SIerの給与水準は、今後少しずつ下がっていく。負けているわけじゃないけど、ジリ貧みたいな。 ひがやすを氏の会社がプログラミング・ファースト開発を標榜
非機能要求は，検証できなければ意味がない
JUAS(日本情報システム・ユーザー協会）が，「非機能要求仕様定義ガイドライン」を発行した。このガイドラインは，JUASが2007年9月から2008年3月にかけて実施した「UVC(User Vender Collaboration）研究プロジェクトII」の成果で，ユーザー企業がベンダーに提示する要求仕様書(別の言い方ではRFP＝提案依頼書）における非機能要求の定義方法をまとめたものである。 JUASは，2007年に「UVC研究プロジェクト」の成果として「要求仕様定義ガイドライン」を発行しているが，非機能要求については不十分だった。これを補うために，非機能要求に正面から取り組んだのがUVC研究プロジェクトIIであり，「非機能要求仕様定義ガイドライン」だ。 言うまでもなく，ユーザー企業がシステムの非機能要求を明確にベンダーに伝えることは非常に大切である。しかしこれまでは，どんな非機能要求を伝え
「うっかり」ミスは無くせる
あっ、と気づいたときは手遅れだ。 運用操作を間違えた、パラメータの変更を忘れた、障害対応を誤った――。 作業者の「うっかりミス」によるシステム障害が止まらない。 本誌が過去3年に発生したトラブルの原因を調べたところ、全体の半分に達した。 作業者を責めたり責任者を処罰したりしても、ミスは減らない。 ミスを誘発する根本的な原因を突き止めて対策を講じることが不可欠だ。 うっかりミスを無くす方策を探る。 （大和田 尚孝） 本記事は日経コンピュータ7月15日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集1」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。 なお本号のご購入はバックナンバーをご利用ください。 「ミサイル発射情報、当地域にミサイルが着弾する恐れがあります」。6月30日午後4時37分、福井県美浜町全
現場に蔓延する“ひどいRFP”
ITproの読者で「RFP（提案依頼書）」という言葉を知らない人は少ないだろう。それだけ，RFPが市民権を得た結果と言える。しかし，RFPの活用が広がる一方で，悲鳴を上げているベンダー担当者も増えているように感じてならない。悲鳴を上げているのは，コンペによって競争にさらされているからではない。“ひどいRFP”によって不当な提案を強いられたり，迷走プロジェクトに巻き込まれたりしているケースが目立つからである。 現場ではいったい何が起きているのか。記者は5月某日，RFPの読み手であるベンダー担当者3人を招いて，覆面座談会を開いた。テーマは「現場に蔓延する“ひどいRFP”」。すると，実際に出くわした“ひどいRFP”が，次から次へと挙がった。以下では，その典型パターンをいくつか紹介しよう。 ケース（1） 担当者の思いだけで記述 一つめは，担当者の“思い”だけがRFPに書かれていたケースである。大手
業務システムのユーザビリティ: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 世間では、ユーザビリティといえば、プロダクトのUIやWebサイトに関連した話題ばかりが取り上げられます。しかし、ユーザビリティを改善することで最も効果が得られやすく、かつ、実はユーザビリティの改善のための作業を行いやすいのが、業務システムの分野だろうと僕は感じています。 ユーザビリティの改善によって、 システムの利用効率を上げる利用のわかりにくさや利用の仕方の誤認を要因とする誤操作や誤入力を減らすエンドユーザーが利用時に不満を感じるところを削減してシステム利用に対する精神的負担を軽減する などが実現できれば、業務全体の効率や、システムを用いて行う情報の入力率を高めて、開発するシステムに期待する効果をあげやすくなると思います。ほかの場面ではその拡大使用を懐疑的な目で見ていいの
長い付き合いだからと甘えるな，熟知しているからこその提案を
長い付き合いだからと甘えるな，熟知しているからこその提案を 田中 弘幸氏 明治乳業 情報システム部部長 取引関係が長くなると、どうも“斬新な提案”が出てこなくなるようだ。当社はある大手メーカー系のITベンダー1社に、主に工場向けシステムの開発や運用・保守を任せている。このITベンダーの営業部門の事業部長とは、新人時代から約30年の付き合いがある。昔は困ったことがあると、一目散に当社に駆けつけてくれたものだ。 事業部長と私は、気心が知れた関係。今では互いに都合の良いことも悪い話も腹を割って話せる。このことが問題解決のスピードを高めていることは多い。例えばITベンダーの営業担当者が、当社の突き付けた“宿題”に手間取っている時などがそうだ。 私はすぐに担当者の上司である事業部長に直接連絡して、課題をすぐに解決してもらっている。システム構築プロジェクトを立ち上げる際も、優秀なエンジニアを集めて開発
システムを作りっぱなしにしていませんか？
少し前のことだが，2006年4月，東レの情報システム部門を中心とした，EIP（Enterprise Information Portal）システムのプロジェクト・チームは，経営層から成果を認められ，社長賞を贈られた。 画期的なEIPシステムを開発したから，というわけではない。社長賞を得た最大の要因は，EIPシステムを開発した後の取り組みにあった。その取り組みとは，導入したEIPシステムの利用状況をチェックし，素早く改善につなげ，社内の各現場での利用をいち早く定着させたことだった。 利用状況をチェックし矢継ぎ早に改善 具体的にはこんな具合だ。まず，利用の浸透度合いを表す評価指標としてログイン・ユーザー数（ユニーク・ユーザー数）を設定。週次で部署ごとに集計し，利用が進んでいる部署を見つけ出した。その上で，利用が進んでいる部署におけるEIPシステムの活用の仕方を調べ，ベストプラクティスとして他部
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論 Developers [Test] Summit 2008（デブサミTest） 「建前ではなく実際にテストを普及させるにはどうすればいいのか」。2008年4月23日，東京・九段で開催されたテストに特化したソフトウエア開発者向けカンファレンス「Developers [Test] Summit 2008（デブサミTest）」で「【徹底討論】テストなんていらない？！-テストを，どこまでやるべきか？」というパネル・ディスカッションが開催された。 司会を務めたのはタワーズ・クエスト プログラマ兼取締役社長であり，テスト駆動開発（TDD）の日本での第一人者である和田卓人氏。同氏に，オープンソース・プロジェクト「Seasar」のチーフコミッタであるひがやすを氏，テストの
システム開発って工事だったんだ……
確かに、SIerは建設業界をある時代までお手本にしてきた歴史がある。多層請負構造や人月による見積もりなどはその名残といえるだろう。そう考えると“工事”といえるのかもしれないが、複雑化し、より競争環境が苛酷なIT業界では、三菱総合研究所（MRI）の主任研究員の飯尾淳氏がいうように「もう無理がある」。建設業界、SIerともすでに別々の道を歩んでいるように私には思える。 そのような状況のシステム開発に工事進行基準を当てはめれば現場は大混乱に陥るだろう。かといって工事進行基準が悪いとはいえないと思う。工事進行基準が求める厳密な要件定義やプロジェクトマネジメントは多くのSIerが理想とするところだ。うまく適合すれば失敗プロジェクトを減らすことができるだろう。 近年、SIerには逆風が吹き続けている。景気回復によって人手が不足するほどに仕事は多いが、単価の低下は続いている。海外へのオフショア開発がいよ
第20回 “安定稼働”のシステムこそ危険人間同様，定期検診を欠かすな
「ここ数年，風邪をひいたことさえないよ」と言った翌日に風邪をひく。「生まれてこのかた，病院通いなんてしたことないね」と自慢した翌週に，心臓発作で病院に担ぎ込まれる。 不思議なもので，健康ぶりを吹聴した途端に病気に見舞われるというのは，よくある話だ。しかも，病気らしい病気にかかったことがない人ほど，いざ病気になると生死にかかわる大病だったりする。逆に，年中痛いの辛いのとボヤいて病院通いしている人ほど，病気そのものは大したことなく，結果的に長生きしたりする。 なぜ，こんなことになるのだろうか。ちょっと考えれば理由は明らかだろう。健康に対する日々の自覚の違いである。 身体が弱いと自覚している人は，普段から自分の健康状態に気を配り，ちょっとした異変でもすぐに察知して病院に駆け込むものだ。そのため，大きな病気を予防したり早期発見したりすることが可能になる。かかりつけの病院で長年診てもらっている医師が
「情シス部門の地位向上」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
情シス部門の地位向上（4）： 仕様はどうして決まらないのか？ ドキュメントがどうとか、開発プロセスがどうとか、インフラやアーキテクチャがどうとかという点は、われわれサイドには大変重要な課題ですが、＜正しい＞ユーザーからすれば本質的な要求ではありません。（本文より）（2008/3/27） 情シス部門の地位向上（3）： 失礼ながら、それはガバナンスではありません 私はITガバナンスという言葉が、中央集権的に「ITガバナンス＝企業におけるIT部門の統治」「ITガバナンスの強化＝IT部門の権力強化」みたいに使われている例が多いと感じています。しかし、『それはガバナンスじゃないんです』と声を大にして訴えていきたいと思います。（本文より）（2008/3/13） 情シス部門の地位向上（2）： IT戦略は情シスが立案するものです 前回「企業組織と情報システム部門――『話通じてる？』」では、企業組織における
「見える化」だけで経営は変わらない---目次
最近の「見える化」の議論は，BI（ビジネス・インテリジェンス）などシステムの話に終始しがちだ。だが残念ながら，不ぞろいで鮮度が低いデータばかり集めても実際の経営判断には使えないし，次のアクションにつながらない情報には一片の価値もない。本当に役立つ情報を提供し，効果的な経営管理を実現するには，従来の「見える化」の先にあるものを目指す必要がある。企業グループの経営管理には特に重要だ。 第1回 見当違いな「見える化」 第2回 見える化の進化形，5つの条件（前編） 第3回 見える化の進化形，5つの条件（後編） 第4回 “使える”経営情報の作り方 第5回 失敗しない「見える化」，実例に学ぶ
システム部内の情報共有を強化
人材サービス大手、フジスタッフホールディングスのシステム部は、システム業務に関する情報の共有を強化している。今年から、業務システムを導入・刷新するたびに、担当した社員が講師となり、約20人のほかのシステム部員を対象に勉強会などを開くことにしている。既に2つのシステム構築について勉強会を実施。1つは登録スタッフにキャリアアップを促すための「ランクアップ制度」を基幹システムに反映させるための作業で、もう1つは社内向けeラーニングシステムの構築だ。 ランクアップ制度とは、グループ会社で工場向けの人材派遣を手がけるアイライン（東京・千代田区）が、登録スタッフに対して勤続年数に応じて奨励金を支給するといった制度。システムの全体像を理解するにはまず、スタッフとじかに接しているアイラインの支店と、そこから様々な情報を吸い上げてデータベースで管理するアイライン本部の双方で、どのように業務が流れているのかを
技術力とプロマネ力の強化に重点を，互いに意見し合える関係が理想
技術力とプロマネ力の強化に重点を，互いに意見し合える関係が理想 大杉 隆氏 エーザイ システム企画部担当部長 当社のシステム部門はその名の通り、システム化の企画に専念する。システム開発や運用、保守といった実務の大部分はITベンダーに任せている。 ITベンダーに期待するのは、我々が考えたアイデアを素早くシステムとして具現化してもらうことだ。そのためには、どんなITを利用するのが得策かなのかを提案してほしい。 ところが、導入すべき技術や製品はそっちのけで、「できるだけ多くのエンジニアを投入しよう」という考えが透けて見える提案を出すITベンダーが少なくないのだ。ITサービス業界が人月ベースで仕事をすることが多いせいかもしれない。 我々はエンジニアの頭数をそろえて、巨大なプロジェクトを進めようなどとは思っていない。きつい言い方になるが、スキルレベルの低いエンジニアを大勢、送り込まれても困る。できる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
上流工程-設計---目次
上流工程-見積もり---目次：ITpro