［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro
特許庁が5年前から進めてきた基幹系システムの刷新プロジェクトを中止する方針を固めたことが、日経コンピュータの取材で分かった。当初は2011年1月の稼働を予定していたが、業務分析の遅れなどから要件定義と設計が難航。稼働を3年遅らせたが、立て直すことができなかった。 政府が策定したレガシーシステムの刷新指針に基づき、特許庁は2004年10月に「業務・システム最適化計画」を策定した。この刷新指針は、特定のITベンダーとシステム保守などを長期契約することによるITコストの高止まりを解消する目的で策定されたものだった。同庁はさらに、入札に分割調達の仕組みを採用して競争原理を働かせることを目指した。 要となるシステム設計とシステム基盤の構築については、東芝ソリューションが入札予定価格の6割以下の99億2500万円で落札した。ところがプロジェクトが始まると、現行の業務やシステムを理解した職員と技術者が足
開発者が知っておくべき、6つのUIアーキテクチャ・パターン - ＠IT
.NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― 「matarillo.com」より ―― 猪股 健太郎 2011/12/15 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET／.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の『GUI Architectures』を訳して公開しようと思ったのだが、FAQページに「PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい」と書いてある。なので翻訳の公開はやめて、「
情マネ流マーフィーの法則 インデックス － ＠IT情報マネジメント
情マネ流マーフィーの妖誤集～その3 情マネ流マーフィーの法則（42） 本連載の最終回となる今回は「超上流」「ユビキタス」「シンクライアント」など、誤解されやすい用語や概念を独自の視点で定義する
なぜ糞システムができあがるか
納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサル、PM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ
システム開発プロセスを管理する·::mound:: MOONGIFT
::mound::はTwitterライクな機能がついたプロジェクト管理システム。 [/s2If] ::mound::はPHP製のオープンソース・ソフトウェア。システム開発はとても面白いものだ。デジタルの世界においても、一からモノを作り形作っていくのは楽しい。それを生業としたときでも同じく、楽しさを維持しなければならない。 ステータス だが数あるプロジェクト管理システムはプロジェクトの遂行にのみ観点がおかれ、開発する楽しさが感じられる代物ではない。その意味で若干毛色が違うのではないかと思うプロジェクト管理ソフトウェアが::mound::だ。 ::mound::はプロジェクトごとのタスク管理、バグ管理をメインとしている。リリース計画を作り、その中にタスクを登録して漏れてしまったものについてはバックログとして管理されていく。そしてタイムトラッキング機能やワークフロー管理がある。 メッセージ そし
システム開発を成功させたいSEに送る、「文書執筆のおきて」まとめ
システム開発を成功させたいSEに送る、「文書執筆のおきて」まとめ：誰にでも分かるSEのための文章術（15）（1/2 ページ） 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 文書を記述するに当たって、常に意識しておかなければならない点が4つあります。 システム開発における文書の重要性を認識する 読み手のことを考える 文書の構成を作ってから、文書作成に取り掛かる 必ず読み返す これらは、分かりやすい文書を作成するための基本ポリシー、“おきて”とでもいうべきものです。連載の最終回となる今回は、文書作成時に常に意識しておきたい「文書執筆のおきて4カ条」について解説します。 その1：システム開発における文書の重要性を認識する
アジャイル開発の現在・過去・未来
9月4日土曜日に、有志によるアジャイル開発のイベント「XP祭り2010」が早稲田大学西早稲田キャンパスで開催されました。イベントは200名以上の参加者が集まる盛況となり、アジャイル開発への注目の高さをうかがわせました。 基調講演では、「アジャイル開発の現在・過去・未来」というタイトルで、アジャイルの第一人者であるチェンジビジョン代表取締役社長の平鍋健児氏が登場。タイトル通り、アジャイル開発の全体と最新動向を俯瞰する、アジャイル開発のイベントでしか聞けない充実した内容となっています。 この記事では、その基調講演の内容を紹介しましょう。 なぜアジャイルが注目されるようになったのか なぜいまアジャイルが注目されるようになったのか？ 何かのビジネスを行う際には、企業が市場を分析して、企画を立て、IT関連のシステムを発注する、といったことが行われる。すると、ITが「仕様通りにできました」と納品してく
ウノウラボ Unoh Labs: アジャイルな開発をチームでやってみた(2010年版) - その2
テストコード書いてますか？ HIROKIです。 murahashiに続いて、テストファーストを導入してみての振り返りをします。 まず、どうやってチームにテストファーストのスタイルを持ち込んだのか。 1．テストが重要だという共通認識を持つ。 前のプロジェクトではテストコードは、ほとんどありませんでした。 その中で、開発になれていない人や新たに人が投入され、 極少数ですが、デグレーションが起きました。 その経験を元にテストが重要だという共通認識を持つことができました。 2．プロジェクト開始時からテストファーストに踏み切る気持ちが必要 テストコードを書かなければコミットさせない。ぐらいの気持ちが必要です。 実際に何度も、本格的な実装が始まる前から口にしていました。 「うちのチームはテストを書かなければコミットを許さない。」と。 3．でも、テストコード書いたことないよ？ テストコードを書いたことの
知るだけで天地の差が出る、テスト仕様書の必須項目＆表現方法
テスト仕様書で絶対に必要な項目リスト テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号（通し番号など） テストを実施した年月日 テストを実行した担当者 障害報告票番号（発生した障害の詳細を開発グループに報告する帳票の識別番号） まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。 なぜなら、
第11回 新しいシステム開発技法への挑戦 ～オブジェクト指向の失敗経験より～ | gihyo.jp
情報技術の発展 最近、世の中の情報機器が急速に進化していると実感しています。自動車業界のETC・カーナビといった技術、携帯電話業界のスマートフォンの普及、書籍業界では、電子書籍の普及も見込まれています。IT業界のPCやデジタルカメラの高性能化は言うまでもないでしょう。 それでは、IT業界の中でも業務システムを構築するシステムエンジニアの仕事はどうでしょうか？ 開発環境が整備されたことにより、過去に比べて格段と簡単に開発ができるようにはなりました。それでも、開発生産性はこの10年間で、大幅には改善されていないのが筆者の実感です。 今回は、新しいシステム開発技法への取り組みについて考えてみたいと思います。 お客様が理解できるもの システムエンジニアの主な仕事は、お客様とシステム要件の刷り合せを行っていくことです。 お客様は画面や帳票といった具体的なものから、どんな機能になるのかを確認します。そ
SEがお金とやりがいを手に入れるために必要なこと
SEや情報マネージャにお勧めの書籍を幅広い視点からセレクトし、毎週1冊ずつ紹介してきた＠IT情報マネジメント ブックガイドコーナー。今回からリニューアルして情報量を拡充させました。今後も役立つ本、興味深い本をより詳しく紹介していきますのでお楽しみに。 SaaSをはじめとするクラウドサービスの進展により、企業はビジネスに必要な機能を、必要なときに、迅速に入手できる環境が整いつつある。だが「迅速に入手」できるだけでは意味がない。それを収益向上につなげられるか否かは、経営戦略に基づいて設計・構築したIT基盤と、そこに適切にサービスを組み込むノウハウを持っていることが前提条件となる。当然と言えば当然のことだが、多くの企業がより手軽にサービスを入手できる環境が整うだけに、今後はそうしたIT活用の“基礎体力”が、従来以上に企業の競争力を左右するポイントになると言えるだろう。 そんな背景もある中で、本書
どうしてプログラマがPMになりたくないのか - GoTheDistance
SIerでプログラマ(PG)からプロマネ(PM)までやった僕が通ります。 ＰＭになりたくない症候群 - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japan 一度でも失点をしたらそこからリカバリーすることが困難な立場に放り込まれるし、放り込まれたら現場の裁量で何とかするしかないというデフェンシブなやり方に起因する構造的なPM疲弊体質。確かにコレは、嫌悪される理由の１つにあると思います。ただ、それだけではないな、と。技能という側面で考えても嫌悪される理由があるのかな、と思いました。 要はPG→SE→PMというキャリアパス、についてですね。 色々な議論がありますが、何が問題かと言えばプログラマとして未来を奪い去ってしまう所が過多あるってことに尽きるように思います。技術は移り変わるわけですから、プログラマでありたいなら保有スキルが陳腐化しないようにしなくてはな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
＠IT - スキル創造研究室 - 全記事一覧