保険大国日本で保険のシステムを作るコツ
ITエンジニアの日々の業務は、一見業界によって特異性がないようだ。だが、実際は顧客先の業界のITデマンドや動向などが、システム開発のヒントとなることもある。本連載では、各業界で活躍するITコンサルタントが、毎回リレー形式で「システム開発をするうえで知っておいて損はない業務知識」を解説する。ITエンジニアは、ITをとおして各業界を盛り上げている一員だ。これから新たな顧客先の業界で業務を遂行するITエンジニアの皆さんに、システム開発と業界知識との関連について理解していただきたい。 はじめに 今回からITエンジニアのための業界知識をリレー連載でスタートします。毎回、各業界を担当しているアクセンチュアのコンサルタントが、業界の基礎知識、業界動向、ITとのかかわりについて、自身の経験を基に伝えていきます。しばらくの間、お付き合いのほどよろしくお願いします。 今回は、私がシステム開発で携わってきた「保
ソフトウェア開発者が読むべき IT系雑誌の一覧と，おすすめの読み方 - 主に言語とシステム開発に関して
中級クラス〜のデベロッパにとって，フォローする事が望ましいIT系雑誌のリスト。 また，それらの読み方。 つまり，書店における立ち読みのポイントと，購入の判断基準。 （１）Web+DB PRESS （２）Software Design （３）日経Linux （４）日経NETWORK （５）日経SYSTEMS （６）日経ソフトウェア 補足 なぜ雑誌なのか？ 読者層としては， 主にWebアプリの開発をチーム内でリードするエンジニアやアーキテクトを想定。 （１）Web+DB PRESS 雑誌のホームページ http://gihyo.jp/magazine/wdpress この雑誌の読み方： 「特集」は無条件で精読する。 「プログラミング言語の記事」は，下記の点に注目して把握する。 言語の癖や特色，他の言語と差異化するファクター その言語から，あるサービスを利用するためのAPIの存在 バージョンアッ
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - ＸＥＡＤ
動作環境 J2SE の1.4.* 以上が必要です(*1) WindowsXP(SP1)にて動作確認してあります 解像度1024×768ピクセルかそれ以上の画面の利用をお勧めします *1.J2SE1.4.1で起動できないケースがあります。その場合には、1.4.2以降をインストールしてください。WindowsVistaでは、1.6.0以降をインストールしてください（そうでないと文字化けします）。コマンドプロンプトで java -version と入力すれば、現在のバージョンを確認できます。そのコマンドが無効とみなされたなら、Javaがインストールされていないということです。新規にインストールするのであればRuntimeでかまいません。なお、Javaの環境設定に関して当社へ問い合わせることはご遠慮ください。 よくある質問 なぜフリーウエアとして提供しているのですか？ 当社としては、
基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る（後編）
基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る（後編） 基幹システムをクラウドで実現する。その過程でどのような技術を用い、どのような苦労があったのか。小売り流通業である西鉄ストアの基幹システムをAmazonクラウド（以下、AWS：Amazon Web Services）の上で実現したノーチラス・テクノロジーズが、その詳細について紹介したセミナーを5月15日、アマゾンジャパン本社のセミナールームで開催しました。 （本記事は「基幹システムをクラウドへあげるのは簡単ではなかった。ノーチラス・テクノロジーズがクラウドの現実を語る（前編）」の続きです） 和製クラウドでトラブルが続き、やむなくAWSへ移行 インフラについて。やはり和製クラウドベンダのインフラは値段が高い。いろいろ話をして安くならないかと相談したけれど、無理でした。理由は簡単です。デ
機能要件設計書だけで20種類
意図が伝わる設計書を作るには，前提として「それぞれの設計書がどういう役割を担うか」「それぞれの設計書が相互にどういう関係にあるか」を正しく理解しておくことが重要である。豊富なサンプルとともに，設計書の役割と関係，さらには書き方のコツを解説する。 石川貞裕 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 担当本部長 向坂太郎 日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部 「基本設計書」と聞いて，どんなものをイメージするだろうか。業務フロー図や画面レイアウト，E-R図など様々だろう。大規模，高品質のシステムを開発するなら，図1に示すような多くの設計書を作成することになる。 中心となる機能要件設計だけでも20種類。それぞれの役割や関係をきちんと理解し，過不足なく設計情報を盛り込むことが求められる。 難しいのは，設計書の読み手が開発者だけではないことだ
詳細設計書（後半）
現在使われているの画面システムは、イベントドリブン（駆動）型のアプリケーションが主流です。イベントドリブンとは、画面のロード（呼び出し）やボタンのクリックなど、画面操作イベントをきっかけに処理が実行されるしくみを言います。アプリケーションは、プラットホームにより次のように3つの世代があります。 第1世代では画面単位で処理が行われていました。これは画面上の社員コードや商品コードなど複数項目に入力した状態で、「実行ボタン」を押してはじめて社員名や商品名、単価などが取得され画面上に表示されるしくみとなります。 第2世代とともに登場したイベントドリブン機能により、項目単位で処理が行われるようになりました。例えば社員コードを入力した場合、即座に社員名が取得され画面上に表示されます。コードの誤入力などがあっても、すぐにエラー表示されるのでユーザビリティが高い技法として広く普及しました。 第3世代のWe
システム開発の仕様書テンプレートや参考サイトのまとめ｜IT情報局
システム開発の際に必要になる要求仕様書や基本設計、詳細設計に使う各種の書類のテンプレートを紹介しているサイトをまとめました。 また、参考になる資料を配布しているサイトや開発関連資料の書き方などの説明をしているサイトもあります。 システムを開発時の書式や方法は各プロジェクトによって使うフォーマットは異なりますが、初めて開発する場合や自社での開発資料を作成する際のテンプレートとして参考にしてください。 2017/2/22 追記 リンク先の資料を配布しているサイトがかなり古くなってしまったのでリンクの見直しと、新たにシステム開発の資料を提供しているサイトを探して追加しました。 仕様書のダウンロードができるサイト Pocket 9 要求仕様書から見積、基本設計、詳細設計、コーディング規約、テスト仕様書、その他スケジュールや議事録まで システム開発に必要な書類のテンプレートがそろっています。 htt
エンタプライズ系：IPA 独立行政法人 情報処理推進機構
「エンタプライズ系ソフトウェア」は、企業の業務システムや情報システム、銀 行、証券、病院、鉄道など大規模かつ社会基盤を支える情報システムなどに含まれ、それらのシステムの機能を中心となって実現するものです。これらのソフトウェアは、それによって提供されるサービスの陰に隠れて、国民の目には見えにくいものの、国民生活や社会経済活動を支える重要なインフラとなっています。エンタプライズ系ソフトウェアでは、一般に、発注者がソフトウェアの要求を提示し、受注者がその要求に提案する受発注の契約形態によって開発されます。 本サイトには、信頼性の高いソフトウェアを効率的に開発するための豊富なノウハウやヒントが、体系的に掲載されています。具体的には、ソフトウェア・ライフサイクル全般にわたり、発注者と受注者との間で開発ソフトウェアに関する認識の共有化を図ったり、ソフトウェア開発において「みえる」「はかれる」定量的な開
IPA 独立行政法人 情報処理推進機構：超上流から攻めるＩＴ化の事例集：INDEX
SEC BOOKS「経営者が参画する要求品質の確保」では、情報化の現場で起こっている問題を取り上げ、それらの解決のヒントとして超上流工程における経営層のシステム開発への参画による要求品質の確保の重要性を説明しました。 ここでは、情報化に関わるユーザ企業・ベンダ企業が、心掛けるべき原理原則や取り組む上での行動規範を示しています。 また、心構えだけでは、「実際には何を行ない、どんなものを作ればよいのか」という問いに、実際の開発現場で行なっている情報化の進め方や、実際に使用している成果物を提供することにしました。 ユーザ企業とベンダ企業の間での情報化での作業や役割分担、成果物について、具体的なイメージをつかめればと思います。 ご利用条件について 当コーナーで紹介しているファイルをダウンロードすると下記の利用条件に同意したものとみなします。 本利用条件は、IPAの「ご利用条件」に追加するものです。
IPA 独立行政法人 情報処理推進機構：超上流から攻めるIT化の事例集：システム化の方向性と計画
・方向性と計画 成果物は「経営者が参画する要求品質の確保」に記述されている 表4．2「役割分担と成果物例」にならい分類・表示している。 要件定義についてはこちら
IPA 独立行政法人 情報処理推進機構：超上流から攻めるＩＴ化の事例集：要件定義
・要件定義 成果物は「経営者が参画する要求品質の確保」に記述されている 表4．3「役割分担と成果物例」にならい分類・表示している。 方向性と計画についてはこちら
シェル操作課題 (cut, sort, uniq などで集計を行う) 設問編 - Yamashiro0217の日記
この記事は弊チームの新人の方にシェル操作に慣れてもらうために作った課題である。 皆様のチームの新人にやってもらってもいいですね。 あとで解答編を書く。 もちろん他の方も解いてもらって構わない。 というか僕の解答以上の解答がきっとあるはずなので、それを教えて欲しい。 はてブで解答でも面白解答お待ちしてます。 さて本題。 Webアプリケーションを作っていると偉いさんとか、いわゆる企画の人とかから 「ちょっと○○がどうなってるかログから数字だせない？」 とさらっとお願いされたりする。 そこで「いや、ちょっと手が空いてなくて（こっちは忙しいんだよ糞がっ）」と答えたくなるかもしれないが、 そこは「じゃあさくっとやっておきますよ！僕にかかればちょろいっすよ！」と答えらればかっこいい。 （あまりさくっとやりすぎるとそういう細々依頼がたくさんくる諸刃の剣） 例えば以下のようなログファイルがあったとする。
ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
RFP/要件定義/要求仕様---違いは明確？
「RFP（提案依頼書）」「要件定義書」「要求仕様書」──。この三つの言葉を見て、その違いを明確に説明できるだろうか。筆者は、日経SYSTEMSという雑誌を担当して日々システム開発現場における開発手法や実務情報を記事としてまとめているが、この三つの用語には、定義に曖昧な部分があったり、違いが分かりにくい面があったりすると感じている。 三つの用語が示すドキュメントはいずれも、ユーザーがどんなシステムを開発したいのかを記述したものだ。実は、筆者がこれまで普通に使っていた用語は、三つのうちRFPと要件定義書の二つ。これらについては、それなりに違いを理解しているつもりである。対して、要求仕様書という用語はあまり使っていなかった。 ざっくりいえば、RFPはシステム開発を発注するベンダーを選定するために、どんなシステムを作りたいかを提示して、最適な提案をベンダーから引き出すためのもの。一方の要件定義書は
第1回 要件定義作業を容易にするシステム化企画書の意義 | IT Leaders
「ユーザー企業が必要としているシステムはどのようなものか」を定義する要求仕様書。実際に作成する上では、まずはきちんとしたシステム化企画書をまとめることが肝要となる。システムに求める機能はUML（統一モデリング言語）で定めるユースケース図を用いると分かりやすい。 要求仕様を取り巻く議論が活発だ。書店には要求仕様を冠とする書籍が立ち並ぶ。どれを手に取ってもなるほどという内容だが、これらの本に1つだけ欠けているものがある。それは、要求仕様を書く側の技術力について言及されていないことだ。 それだから本を読めば要求仕様書が書けると勘違いしてしまう。要求仕様書を書くには深い業務知識と経験が必要である。さらにITについても造詣が求められる。ことはそう簡単ではない。 しかしながら要求を仕様化する方法や手段は「要求仕様技術」として少しずつ確立されつつある。技術であれば習得することができる。 この連載では、シ
ソフトウェア開発に携わるすべての人に捧げる、アジャイルにソフトウェアを開発する為に読むべき15冊 | Act as Professional
私は夏休みの宿題のやり方を教えてもらったことがありません。約2ヶ月という限られた時間で、どういう風に消化していくと良いのかを学習したことがなかったのです。 夏の終わりに24時間テレビが放送されますが、あれを見ながら、答えをチラ見し、綺麗なドリル(*1)を1冊消化するのは忘れられない子供の頃の思い出です。 この経験はソフトウェア開発にも似ていて、開発の手法を知らなければ、良い結果を生むのは難しいのです。不幸なことに、夏休みの宿題のように明確に何をやるべきなのか、明確では無いのです。 夏休みの苦い思い出と、ウォーターフォールっぽい大失敗プロジェクトの経験をいくつか得た上で、アジャイルソフトウェア開発を学ぶことによって、ソフトウェアのつくりかたを学びました。 これは、中小のSIerでも、イケてるWEBサービスを提供している会社でも教えてくれたことではありませんでした。そう、夏休みの宿題のやり方を
[Think IT] 第3回：ウォーターフォールにおけるドキュメント作成ポイント (1/3)
【楽々デブドックを書こう！】手法別開発ドキュメントの書き方 第3回：ウォーターフォールにおけるドキュメント作成ポイント 著者：ウルシステムズ 小堀 真義 公開日：2008/02/21（木） 基本設計書は詳細設計とテストのインプットとなる 「第2回：開発モデルに共通するドキュメントをまとめる視点」では、開発モデルに関係なく、開発ドキュメントをまとめる上で大切となる視点について解説しました。第3回、第4回では、具体的な開発モデルを取り上げ、ドキュメント作成における重要なポイントを押さえていきます。今回取り上げるのはウォーターフォールモデルです。 ウォーターフォールモデルの特徴は、各工程を順番に1回だけ行い、原則として後戻りが許されない点です。各工程は、前工程の成果物をインプットとして、次工程のインプットとなるアウトプット（成果物）を作成するために作業を行います（今回は、図1のV字モデルと工程名
テンプレートから学ぶ 受注する開発者のためのテスト仕様書
1. はじめに ソフトウェア開発プロジェクトにおいてテストは極めてストレスに満ちています。「テストとは作った成果物に誤りがあるかどうかを見つける作業だ」という本質的に不愉快な活動であることに加えて、プロジェクトの終わりにさしかかって時間も逼迫しているのに仕様変更を受けて再テストなどという、体力的にも精神的にもきつい作業であるからです。 本稿では、さまざまなストレスを受ける立場の開発者が少しでも楽に「きちんとテストしました」と言うために、テスト仕様書のテンプレートを紹介します。このテンプレートは発注者に報告するための文書だけでなく、さまざまなテスト技法の紹介も含まれていて、いつどういうテストをすればよいのかという手引きにもなっています。 さて、はじめに、ソフトウェア開発プロジェクトと品質・生産性・納期の関係を見てみましょう（図1）。 お客様（発注者）はプロジェクトを起案する際、何を作るかを「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[ThinkIT] 第3回：基本設計書 (1/3)
＠IT自分戦略研究所