Logical Cube

Gunz

Euro Gunzやってます。

Euro Gunz



Gunz the dual 2 が楽しみです。

Ryuichi Sakamoto ／ hibari

日曜日のこの時間
来週からの準備に追われる。そんな合間のホット一息。
Pianoとアメリカンコーヒーでリセット。

Gunz music

http://youtu.be/ZxRG7uoFDo4

im still lacking

show your split until the end

Play Hard Work Hard

2012年あけましておめでとうございます。
本年もよろしくお願いします。

年末正月は実家でだらだら
今今年始の仕事の準備に追われる。

本年もがんばれ俺。

Play Hard ！！　Work Hard ！


AM I STRONG?


Kaleidoscope

布施明 うりずんの風（かじ）

仕事が忙しい合間、実家で、お昼に　布施明のうりずんの風
なんだか、ささった。

話しながら歌う布施明さんの　目が輝いていた。

pokemon

DeNA

――　どういうマインドを持ったエンジニアが必要なのでしょう？
守安 サービス志向をもってプログラミングできることです。言われたものを作るのではなく、このサービスは面白い、こういうものを作りたい、というサービスのマインドですね。実際のサービス、どんなものがユーザーにウケるのか、どんなものが競合で流行っているのかに興味があって、そういうサービスを作りたいと考えて、しかも行動に落とせる。
一番重要なのは、一定水準のプログラミングスキルを備えた上で、世の中の人に使ってもらえるサービスを、自分で考えて、作りたいということです。そういう層を厚く採りたい。自分でサービスを考えてプログラミングまでできる人間は、言われたものを作る10人以上に匹敵する価値だと思っています。

Bleed It Out

［TGS2011］「10億人が利用するサービスを作り出す」---グリー田中社長が基調講演

「これからの数年間で、10億人が利用するサービスを作り出したい。これは決して不可能な目標ではない」。ソーシャルゲーム大手であるグリーの田中良和 代表取締役社長は2011年9月15日、東京ゲームショウ2011（TGS2011）の基調講演で、こう宣言した。


グリーの田中良和 代表取締役社長
[画像のクリックで拡大表示]
　講演の前半で田中社長は、ソーシャルゲームにおける今後の戦略について語った（写真1）。まず、ソーシャルゲーム市場が急拡大した背景について「通信環境、流通手段、販売手法の三つの革新が同時に起こってきたからだ」と説明。“通信環境の革新”とは、携帯電話やスマートフォンなど通信機能を備えた端末の普及によって、多くのユーザーがネットワークへ常時接続できる環境が整ったことを指す。ゲームの作り手側もネットワークの常時接続環境を前提に、新しい発想のゲームを作れるようになったという。

　また常時接続環境の普及に伴って、コンテンツの電子配信サービスの利用も促進された。ユーザーが欲しいゲームを欲しいときに入手し、いつでも自由に始められるようになってきたのだ。これが田中社長の言う“流通手段の革新”だ。さらにゲームの利用形態についても、初期費用を無料とし、ユーザーの利用度合いに応じて課金していくという“販売手法の革新”も起こった。

　こうした三つの革新がほとんど同時に進んできたことで、ソーシャルゲームの利用は一気に拡大してきた。では今後はどのような方向に進化していくのだろうか。田中社長は、ゲーム業界を広い意味でコンピュータ産業の一種と捉えた上で、「コンピュータ産業が過去に経験してきた“ダウンサイジング”の流れが、ゲーム産業にも到来する」と予測する。

　このダウンサイジングを体現する存在として田中氏が注視しているのが、世界で急速に普及しているスマートフォンである。その実体は、パソコンに迫る処理性能を備え、デジタルカメラをはじめ様々なデバイスの機能を取り込んだ万能型のコンピュータだ。田中氏は「スマートフォンは世界で最も普及するゲーム端末になるはずだ」と見る。「従来の専用機によるゲームビジネスと、スマートフォンのような汎用機のゲームビジネスは対立するものではなく、互いに伸ばし合っていく関係にある。（手軽にゲームを楽しめる）スマートフォンの普及によって、ゲーム人口が爆発的に増加し、ゲームビジネス全体をより一層拡大するチャンスが生まれる」と続ける。

　こうした見通しを踏まえ、田中社長はグリーの成長戦略を描く。同社は主に携帯電話・スマートフォンを対象に、自営のゲーム配信プラットフォームやSNSを運営しつつ、自社でもゲームを提供している。「（プラットフォームとゲームの両方を手がける）垂直統合型のビジネスモデルは、世界のソーシャル市場を見渡してもほとんど例がない。このユニークなビジネスモデルをどうやって世界へ展開していくかが目下の命題だ」と、田中社長は語る。グリーの直近の会員数は全世界で1億4000万に達しており、そのうち8割程度が海外からの利用だ。こうした状況を踏まえ、同社は日本だけでなくグローバル市場に向けたサービスを量産するための体制を強化している最中だという。


「世界を席巻した日本のゲーム産業から貪欲に学ぶ」


田中社長と、日経エンタテインメント！編集委員である品田英雄氏
[画像のクリックで拡大表示]
　講演の後半は田中社長と、日経エンタテインメント！編集委員である品田英雄氏によるQ&Aセッションが行われた（写真2）。ゲームの開発者や同業界を目指す学生から事前に集めた質問を品田氏が投げかけ、田中社長が回答する。

　例えば「せっかく有力なコンテンツを持っていても、海外進出して失敗する日本企業は少なくない。グリーは海外で成功するためにどのような手を打つのか」といった質問について、田中社長は「確かにグローバル市場で成功したと言える日本のインターネット企業はほぼ皆無だ。しかしゲーム業界に目を向ければ、海外で成功している企業はいくらでもある。そうした企業からいろいろと学んでいきたい」と語った。

　また、グリーが人材募集を積極的に進めている現状を踏まえ、同社がどのような人材を求めているかについても質問があった。田中社長は「過去の経験や知識の豊富さといったことは、実はあまり重視していない。我々だってソーシャルゲームの経験が豊富なわけではない」と冷静に回答。続けて「それよりも、経験ゼロであっても短期間で周囲に追いつこうとする人、周囲に流されるのではなく自分から状況を変えてやろうという人を求めている」と話した。

　さらに田中社長は改めて、「10億人が利用するサービスを作り出す」という“宣言”に込めた思いを語った。「もちろん達成するのは簡単ではないが、決して不可能な数字ではない。現在の大型市場である欧米や日本以外の地域にも、スマートフォンという低価格で高性能なコンピュータが行き渡り、ゲームを楽しむ時代が必ずやってくる。今までゲームに一度も触れたことない人にも楽しんでもらえるゲームを作っていく。このことを踏まえて“10億人”と言っている」。

tiesto

♪夏の終わり キャロル

The Sound Of Arrows - Nova (Tiësto remix)

application

本気で未来を考えてるのか、ゴラァ

Business Model

ビジネスモデルを見える化する ピクト図解

By 本太郎 (東京都) - レビューをすべて見る
レビュー対象商品: ビジネスモデルを見える化する ピクト図解 (単行本)
■前提事項(背景)
ピクト図解は、著者がリクルート時代に生み出した手法のようです。
とても優秀だった著者は、開発したコンテンツが国内外で高評価を得て、
多くの賞も獲得したそうです。それなのにどれも売れなかったそうです。
上司から言われたという「作品では無く商品を作れ」という言葉が印象的でした。
この失敗体験を基に、商品が優れていても儲からない原因を探るようになり、
ビジネスモデル起点で物事を考える際に生み出した手法だそうです。

■「ピクト図解」の定義
ピクトグラムのピクトから取っているようです。ピクトグラムとは、街中(建物の中)で
よく目にする緑の非常口の絵(人が逃げている絵）や、お手洗いの絵などです。
意味したいことをシンプルな絵文字で表すツールであると本書で解説されています。
ピクト図解は、このピクトグラムを使ってビジネスモデルを見える化する手法です。

■構成
本書は全6章構成ですが、前半と後半の2つのパートに分かれています。
・前半(1章～3章）：ピクト図解について解説したパート
・後半(4章～6章）：ピクト図解を活用したアイデアの発想方法を解説したパート

■内容のレビュー
ピクト図解自体は、概念も活用方法も非常にシンプルで簡単です。
著者は、3W1H(Who/Whom/What/HowMuch)を1つの図にまとめる手法と解説しています。
つまり、誰が、誰に、何を、いくらで提供するのかを図解する手法です。
概念は簡単ですが、やはりビジネスモデルを正しく捉え、競争力の源泉を明確に
するとなると、相当しっかり考えないと誤った分析をすることになりそうです。
シンプルであるが故に深く考える必要があり、一方で複雑なこと(ビジネス)を
シンプルに表現するからこそ有用であるだと感じました。

著者はピクト図解を活用することのメリットを3点挙げています。
1.　経営者の視点を手に入れられる(→ビジネスモデルを俯瞰するため）
2.　説明不要で誰とでも共有できる(簡単な図であるため）
3.　画像パターンを応用してアイデア発想ができる
　　(→情報を付加することにより思考を広げられるため）

著者はピクト図をどこまで詳しく書くかは目的次第であると仰っています。
→目的の例として経営者視点、プロジェクトリーダー視点、現場担当者視点を挙げています。

但し、上記メリットも考慮すると、常にビジネスはまず経営者視点を意識した方が有効だと
思いますし、 そうすることで、分析のレベル感(詳細度）が統一されるので、ビジネスモデル間の
比較分析や 関連性分析等もしやすくなると感じました。

本書では、ピクト図を書く際の「型」として、8つのビジネスモデルが
挙げられているので、初めて描く際にも抵抗無く書けると思います。
（例）小売モデル、消耗品モデル　等

基本的なピクト図が書けるようになると、次のステップはそれを活用して
アイデアを生み出します。その際に活用できるチェックリストも準備されています。

アイデアの創出に関しては、ダイアグラム発想法やアナロジー発想法等の発想法も
紹介されて いるので、最初の内は、まずそのまま利用してみて良いと思いました。

そして、慣れた後には、ビジネスモデルも発想法も応用して、自分なりの「型」を
構築してみるべきであり、そこで始めて自分の「武器」となると感じました。
そのためにも、手法がシンプルなだけに、継続して実践できるかどうかが勝負だと
感じました。

■余談
「おわりに」の中で、ピクト図解のネーミングに関して、感性分析の観点から
アドバイスを頂いたという記述があり興味深かったです。WEBで調べてみると、
感性リサーチという企業があることを知りました。本題では無いですが勉強になりました

tiesto

http://youtu.be/2EaE0_gQLw0

f1

女 花

女 涙 男 戦

Business

わかったつもりになっていませんか：「ビジネスモデル」とはなんだろう?




19 コメント
by Vivek Wadhwa on 2011年1月10日
テック業界にいる人なら、誰もが「ビジネスモデル」という言葉を口にする。しかしそうした人々からランダムに対象を選んで質問をしてみれば、「ビジネスモデル」という言葉を真に理解している人がほとんどいないことに気付くことだろう。たとえばカリフォルニア大学バークレー校で質問をしてみた。ほとんど全員の手が上がり、MBA学生のBlake Brundidgeの回答はなかなか面白いものではあった。しかしほとんどの学生が適切な回答をすることができなかった。唯一の例外は私のiSchoolに参加しているスタンフォードのLionel Vitalだった。

「ビジネスモデル」というのは、まるでティーンエイジャーの話す「セックス」のようでもある。みんなが四六時中話題にする。誰か知り合いがうまいことやっているという話をしつつ、誰もがセックス三昧であるように語り合うわけだ。しかし実のところは実際にそういう行為をしているのは一部に過ぎず、また行為をしていても不適切かつ不満足なやり方で「巻き込まれて」しまっているような人もいる（まあ、時代というのは変わっていくものであることは認める）。

以下では誰かに「ビジネスモデルとは何か」と尋ねられた際、適切な回答ができるようにメモを記しておこうと思う。

ただ、その前に読者の方々の疑問にお答えしておこう。おそらくは「スタンフォードの学生がなぜバークレーにいるんだ」と感じた方もいらっしゃることと思う。バークレーで開催している私のクラスがスタンフォードでの授業よりレベルが高いということだろうか。少なくともLionelにとってはそうだったようで、彼は学期始めに連絡してきて私のクラスに参加させて欲しい旨を伝えてきた。彼の名誉のために付け加えておけば、クラスの中で彼はバークレーの学生を抑えて最高の成績を示している。バークレーの学生より優秀な学生もスタンフォードにはいるようだ。そういう生徒がわざわざ来るほどなのだからバークレーの方が良い教育を提供しているということになるのだろうか。それは一概に言えないけれど、勉強をより楽しんでいるという傾向はあるように思う。真実を知るためには両方に通ってもらうしかない。

余談はともかく、ビジネスモデルの話に移ろう。本稿を読んでいるティーンエイジャーに言っておくが、この後、セックスの話はない。そちらの勉強をしたい人は他でお願いする。本稿で扱うのはアントレプレナーシップやグローバル化といった話題だ。

まずビジネスで成功するための最初のステップは、顧客がどのような製品ないしテクノロジーになら金を払うつもりでいるのかを理解することだ。これはインタラクティブなプロセスで、以前私のブログにも記事を掲載した。顧客に購入してもらえず、あるいは利用してもらえずに、多くのスタートアップがここで脱落してしまう。まず自分のアイデアを冷静に評価してみることの重要性を軽んじてはならない。

素晴らしい製品を生み出すことも難しいが、それ以上に難しいのは優れたビジネスモデルを生み出すことだ。但し幸いにというべきか、ビジネスモデルを構築するのに「魔術的方法」があるわけではない。どうすればビジネスが売上をあげて利益をもたらすのかという基本事項の組み合わせでできているものだ。長期戦略と短期的な運用手法を組み合わせることでビジネスモデルが構築される。

アントレプレナーたちは、複雑なビジネスプランによって楽観的な市場見通しを立てがちだ。たとえば10億ドルの市場があるのなら1%のマーケットシェアでも十分にやっていけるというようなプランを立てる。楽観論に基づく積極性はもちろん大切だ。しかしビジネスモデルを構築する際には現実的であることが大切だ。実際のプランニングは産業によっても異なる。ただそれらに共通する7つの基本概念をここに示してみようと思う。

1. 顧客訴求力を持つこと。Ralph Waldo Emersonが言った「Build a better mousetrap, and the world will beat a path to your door」（訳注：「桃李もの言わざれども、下自ずから蹊を成す」のような意味）という言葉は非常によく知られている。しかし実際にはいかに優れたプロダクトを生み出そうとも、ただそれだけで人が寄ってくるわけではない。ターゲット顧客層が判明している場合でも、適切なアナウンスをするのは難しいし費用もかかる。インターネットや電子メール、あるいは従来型のブロードキャストメディアや媒体広告、ダイレクトメールやテレマーケティングないし営業電話など、さまざまな方法を用いることになるだろう。しかし潜在顧客ではあったとしても話を聞きたいなどと思っていない人が多いし、また広告に対する何の反応が得られないこともある。ターゲット層をどのように開拓してリーチしていくのかは十分に考慮しておく必要がある。

2. プロダクトの差別化。最適なサービスを提供しているという自負があるかもしれない。しかしそれは誰もが思うことなのだ。相手を認知するかどうかは別として、ともかくいつの場合にも競合はあるものなのだ。優秀なマーケッターはプロダクトの価値を最大化するためのポジショニング戦略についてのノウハウを持っている。自分自身でも競合サービスを理解し、自身の提供するプロダクトの独自性をしっかりと把握しておくことが大切だ。

3. 価格設定。プロダクトないしサービスをいくらで提供することにするのか。これは真っ先に頭を悩ませるところだ。無料で提供してまず商品認知を促すという選択肢もあり得る。ただ、最終的にどのような手段で利益を生み出すのかということは考えておく必要がある。サービスの認知を広めるだけでは利益は生み出せないのだ。自身の提供するサービスが、利用者にとってどれだけ価値があるものなのかを正確に判定するようにしよう。しかる後にサービス提供にかかる費用を算定する。そして競合の動向などもチェックして、長期的戦略を立てる必要がある。生き延びるためには、価格がトータルコストを上回る必要があるのは言うまでもない。

4. 販売。消費者にプロダクトを購入してもらうためには、まず販売スキルを学ばなければならない（以前「生き残るためには、売ることがすべて」という記事も掲載しているので参考にして頂きたい）。あらゆる点で「販売」ということが大切になってくる。したがって契約を締結するための方法や、販売手続きについてきちんと理解しておく必要がある。そしてこの販売戦略は、十分に練られたものである必要がある。自分自身が購入者になったつもりで販売戦略を冷静に構築しておかなければならない。

5. 配送／頒布方式。インターネットという手段が使えるようになって、サービス頒布の容易性は増した。しかし高額なプロダクトを販売するような場合、販売部門を用意することになる。さほど高額ではないが安価というわけでもない商品を扱う場合はディストリビューターやVARを利用することになる。低額商品を扱う際には小売店やインターネットを利用する。利用する方法は産業によってもプロダクトによっても異なるわけだが、選択を誤ってはならない。また流通チャネルに応じた適切なパッケージングにも注意する必要がある。

6. カスタマーサポート。サポートの役割は購入者に利用方法を教えるだけではない。製品の欠陥や返品要求などにも応じなければならない。また消費者の疑問や、より便利に活用してもらうための提案なども行う必要がある。製品を有効に利用してもらうためのコンサルティングサービスを提供する必要があるわけだ。提供している製品があるビジネスにとって必須のものであるならば、無休でのオンサイトないしウェブサポートが必要になる場合もあるだろう。

7. 顧客満足度の向上。ビジネス成功の可否は、結局顧客に満足するサービスを提供できているのか否かに帰着する。満足度の高い顧客は、転じて優秀な販売員となってくれるものだし、続けていろいろなプロダクトを購入してくれる。満足度の低い顧客というのは、サービス展開にあたってのお荷物となっていくのだ。

構築するビジネスモデルにおいては、上に述べた要素がそれぞれジグソーパズルのピースのように噛みあっていなければならない。ただ、ビジネスモデルの考案に当たってはすべてをゼロから考える必要はない。競合や他の市場からもいろいろと学ぶことができる。もちろん成功事例だけでなく、さまざまな失敗事例を学ぶことも大切なことだ。

また、製品に各種イノベーションを持ち込むのと同様に、ビジネスモデルにイノベーションを導入することもできる。ただ、ビジネスモデルを変革していく場合は、市場変化に応じた経験を積んでからとしたい。プロダクトもバージョンアップしていくように、ビジネスモデルというのも進化していくものだ。経験を積めば積むほど良いプランニングができるようになるだろう。

編集部注：著者のVivek Wadhwaは、起業家出身の学者。UCバークレーの客員教授、ハーバード法科大学院上級研究員、デューク大学におけるEntrepreneurship and Research Commercializationのリサーチディレクターなどを務めている。Twitterでのアカウントは@vwadhwaで、研究成果はwww.wadhwa.comにて公開されている。

［原文へ］


Entrepreneur: You’re No Steve Jobs, So Look Before You Leap
JULY 10, 2010 6:59 AM 10 COMMENTS
I doubt that Steve Jobs has ever asked Apple customers what type of products they want, or that he cares about what they need. Jobs believed that if he developed a mobile phone that plays music and surfs the web, he could create both the want and need. He was right: his iPhone changed the industry and started a mini technology revolution. Most of the entrepreneurs I know fancy themselves to be like Jobs. They think they know—better than their customers—what the customers want, and what they need. Or they believe, as in the movie Field of Dreams, that if you “build it, they will come”. But it just doesn’t work this way in real life. The vast majority of technology startups fail because no one buys or uses their products.

Strategy consultant Sramana Mitra calls this failure “Infant Entrepreneur Mortality”. She says that in the hundreds of companies she has mentored, lack of customer validation is by far the biggest cause of failure. Startup guru Eric Ries says that “validated learning” about customers is even more important than revenue for a nascent startup. Revenue, by itself, doesn’t build traction for a business; it is only when you have products that are tested and proven, that customers are ready to buy, and that you can sell and deliver profitably that you have the right ingredients for a successful business.

How do you determine what customers will buy (or, if you’re building a free web technology, what it is that they will invest the time and effort to use)? Unfortunately, this isn’t a simple matter of asking. Your customers know what their problems are; they know what they like; and they know what they don’t need. They don’t know what you can uniquely develop for them that they will really want. This is what you need to figure out. Start by understanding what the customer’s problems are; use your experience and vision to conceive solutions; share this with potential customers in ways that they can understand; and learn. It is an iterative process.

The best example I’ve seen of a startup looking before it leaps is Campfire Labs. The startup has spent 14 months prototyping products. It hasn’t even started developing its products yet. It could be that Campfire never gets off the ground, but if and when it does, it has a better than average chance of becoming a Zynga or Facebook. In the meantime, it has already lived at least three lives (but, fortunately, hasn’t had to die three painful deaths). Campfire was founded by former Yahoo! search technologist Naveen Koorakula and, former Youtube head of international strategy and product, Sakina Arsiwala. Their goal is to change the way people collaborate on line—to make it more meaningful and to better manage the many contexts in which they interact (work, home, school, etc.).

Naveen and Sakina started by building a prototype of a personalized news/media site and sharing it with friends. But, while their techie friends would really get excited about algorithms, the others would scratch their heads trying to figure what the purpose of the product was. Next, they experimented with content sharing, interest graphs, and other technical concepts. They came with product ideas and asked their friends who were specialists in various disciplines to brainstorm with them. Once they thought they were on to something, they talked to random people on the street and workers in the mall next door. They went to university campuses and bought smoothies and sodas in order to get students to spend a few minutes with them. They carefully observed user reactions, read between the lines, and dug deeper to understand what the users were really saying. They incorporated what they learned into the next iteration.

Last time I met the Naveen and Sakina, they were still trying out new ideas. But they seemed to be getting closer and closer to having a product that users were eager to use.

Getting back to Steve Jobs. Does he really have some secret powers or a divine vision that lets him build one earth-shattering technology after another? I don’t think so. My guess is that in his secret lab, Jobs has teams developing and testing hundreds of ideas. He just implements the best of them. Jobs is not afraid of abandoning failures, and when something does click, he rules like a tyrant and makes it happen. Eric Ries agrees with me and prescribes a five-step process that can help people become more like Jobs:

Hold your team to high standards; don’t settle for products that don’t meet the vision; iterate, iterate, iterate.
Be disciplined about which vision to pursue; choose products that have large markets.
Discover what’s in customers’ heads, and tackle problems where design is a differentiator.
Work on as few products as possible; keep resources in reserve for experimentation.
Start over (change direction) if you find yourself with a product that’s not working.

（翻訳：Maeda, H）

未来を本気で考えてんのか、ゴラァ

「恋の片道切符」

さくら あいしてる ゆめ

あの日描いた夢はいつだって 僕たちを待ってる
さあ追いかけて追いかけて 今から迎えに行こう
その先へ

自分の限界を勝手に定めて "無駄な努力"とあきらめてた
転ばないように傷つかぬように 立ち止まっていた
そこから見えている景色は 何も変わらない毎日だ
例えば一歩踏み出したら きっと明日が変わるはず

あの日描いた夢はいつだって 僕たちを待ってる
向かい風に吹かれたって そこで待っているのに
夢から遠ざかっていたのは 僕たちのほうだろう
さあ追いかけて追いかけて 今から迎えに行こう
走り出せその先へ

目を逸らさないで 人のせいにしないで もう年だからとかじゃないだろ
自分を信じて 前だけを見て そう進んでいこう
胸の中詰め込んだ希望と そして消えない情熱を
持ち続けた人にだけ チャンスはやってくるはず

あの日描いた夢はいつだって 僕たちを待ってる
向かい風に吹かれたって そこで待っているのに
夢から遠ざかっていたのは 僕たちのほうだろう
さあ追いかけて追いかけて 今から迎えに行こう
走り出せその先へ

果てしない道のりを 見失いそうになるけど
一番大切なのは"今"を精一杯に生きることさ

思い描く未来はいつだって 今と繋がってる
無くさないで見落とさないで 小さな幸せを

あの日描いた夢はいつだって 僕たちを待ってる
向かい風に吹かれたって そこで待っているのに
夢から遠ざかっていたのは 僕たちのほうだろう
さあ追いかけて追いかけて 今から迎えに行こう
走り出せその先へ

会いたかった

会いたかった 会いたかった 会いたかった YES!!!

会いたかった 会いたかった 会いたかった YES!!! キミに～(＠⌒ο⌒＠)ｂ ｳﾌｯ

システム管理基準②

Ⅳ．運用業務（７３）
１．運用管理ルール（４）
（1）運用管理ルール及び運用手順は、運用の責任者が承認すること。
（2）運用管理ルールは、運用設計に基づいて作成すること。
（3）運用手順は、運用設計及び運用管理ルールに基づいて、規模、期間、システム特性等を考慮し
て作成すること。
（4）運用設計及び運用管理ルールに基づいて、担当責任者を定めること。
２．運用管理（１６）
（1）年間運用計画を策定し、責任者が承認すること。
（2）年間運用計画に基づいて、月次、日次等の運用計画を策定すること。
（3）運用管理ルールを遵守すること。
（4）ジョブスケジュールは、業務処理の優先度を考慮して設定すること。
（5）オペレーションは、ジョブスケジュール及び指示書に基づいて行うこと。
（6）例外処理のオペレーションは、運用管理ルールに基づいて行うこと。
（7）オペレータの交替は、運用管理ルールに基づいて行うこと。
（8）ジョブスケジュール及びオペレーション実施記録を採り、ジョブスケジュールとの差異分析を行うこ
と。
（9）オペレーション実施記録は、運用管理ルールに基づいて一定期間保管すること。
（10）事故及び障害の影響度に応じた報告体制及び対応手順を明確にすること。
（11）事故及び障害の内容を記録し、情報システムの運用の責任者に報告すること。
（12）事故及び障害の原因を究明し、再発防止の措置を講じること。
（13）情報システムのユーザに対する支援体制を確立すること。
（14）情報セキュリティに関する教育及び訓練をユーザに対して実施すること。
（15）情報システムの稼動に関するモニタリング体制を確立すること。
（16）情報システムの稼動実績を把握し、性能管理及び資源の有効利用を図ること。
３．入力管理（５）
（1）入力管理ルールを定め、遵守すること。 7
（2）データの入力は、入力管理ルールに基づいて漏れなく、重複なく、正確に行うこと。
（3）入力データの作成手順、取扱い等は誤謬防止、不正防止、機密保護等の対策を講じること。
（4）データの入力の誤謬防止、不正防止、機密保護等の対策は有効に機能すること。
（5）入力データの保管及び廃棄は、入力管理ルールに基づいて行うこと。
４．データ管理（10）
（1）データ管理ルールを定め、遵守すること。
（2）データへのアクセスコントロール及びモニタリングは、有効に機能すること。
（3）データのインテグリティを維持すること。
（4）データの利用状況を記録し、定期的に分析すること。
（5）データのバックアップの範囲、方法及びタイミングは、業務内容、処理形態及びリカバリの方法を
考慮して決定すること。
（6）データの授受は、データ管理ルールに基づいて行うこと。
（7）データの交換は、不正防止及び機密保護の対策を講じること。
（8）データの保管、複写及び廃棄は、誤謬防止、不正防止及び機密保護の対策を講じること。
（9）データに対するコンピュータウイルス対策を講じること。
（10）データの知的財産権を管理すること。
５．出力管理（７）
（1）出力管理ルールを定め、遵守すること。
（2）出力情報は、漏れなく、重複なく、正確であることを確認すること。
（3）出力情報の作成手順、取扱い等は、誤謬防止、不正防止及び機密保護の対策を講じること。
（4）出力情報の引渡しは、出力管理ルールに基づいて行うこと。
（5）出力情報の保管及び廃棄は、出力管理ルールに基づいて行うこと。
（6）出力情報のエラー状況を記録し、定期的に分析すること。
（7）出力情報の利用状況を記録し、定期的に分析すること。
６．ソフトウェア管理（９）
（1）ソフトウェア管理ルールを定め、遵守すること。
（2）ソフトウェアへのアクセスコントロール及びモニタリングは、有効に機能すること。
（3）ソフトウェアの利用状況を記録し、定期的に分析すること。
（4）ソフトウェアのバックアップの範囲、方法及びタイミングは、業務内容及び処理形態を考慮して決定
すること。
（5）ソフトウェアの授受は、ソフトウェア管理ルールに基づいて行うこと。
（6）ソフトウェアの保管、複写及び廃棄は、不正防止及び機密保護の対策を講じること。
（7）ソフトウェアに対するコンピュータウイルス対策を講じること。
（8）ソフトウェアの知的財産権を管理すること。
（9）フリーソフトウェアの利用に関し、組織体としての方針を明確にすること。
７．ハードウェア管理（６）
（1）ハードウェア管理ルールを定め、遵守すること。
（2）ハードウェアは、想定されるリスクに対応できる環境に設置すること。 8
（3）ハードウェアは、定期的に保守を行うこと。
（4）ハードウェアは、障害対策を講じること。
（5）ハードウェアの利用状況を記録し、定期的に分析すること。
（6）ハードウェアの保管、移設及び廃棄は、不正防止及び機密保護の対策を講じること。
８．ネットワーク管理（６）
（1）ネットワーク管理ルールを定め、遵守すること。
（2）ネットワークへのアクセスコントロール及びモニタリングは、有効に機能すること。
（3）ネットワーク監視ログを定期的に分析すること。
（4）ネットワークは、障害対策を講じること。
（5）ネットワークの利用状況を記録し、定期的に分析すること。
（6）ネットワークを利用したサービスについて、組織体としての方針を明確にすること。
９．構成管理（４）
（1）管理すべきソフトウェア、ハードウェア及びネットワークの対象範囲を明確にし、管理すること。
（2）ソフトウェア、ハードウェア及びネットワークの構成、調達先、サポート条件等を明確にすること。
（3）ソフトウェア、ハードウェア及びネットワークの導入並びに変更は、影響を受ける範囲を検討して決
定すること。
（4）ソフトウェア、ハードウェア及びネットワークの導入並びに変更は、計画的に実施すること。
10．建物・関連設備管理（６）
（1）建物及び関連設備は、想定されるリスクに対応できる環境に設置すること。
（2）建物及び室への入退の管理は、不正防止及び機密保護の対策を講じること。
（3）関連設備は、適切な運用を行うこと。
（4）関連設備は、定期的に保守を行うこと。
（5）関連設備は、障害対策を講じること。
（6）建物及び室への入退の管理を記録し、定期的に分析すること。
Ⅴ．保守業務（１９）
１．保守手順（３）
（1）保守ルール及び保守手順は、保守の責任者が承認すること。
（2）保守手順は、保守の規模、期間、システム特性等を考慮して決定すること。
（3）保守時のリスクを評価し、必要な対応策を講じること。
２．保守計画（３）
（1）保守計画はユーザ及び保守の責任者が承認すること。
（2）変更依頼等に対し、保守の内容及び影響範囲の調査並びに分析を行うこと。
（3）保守のテスト計画は、目的、範囲、方法、スケジュール等を明確にすること。
３．保守の実施（３）
（1）システム設計書、プログラム設計書等は、保守計画に基づいて変更し、ユーザ及び保守の責任者9
が承認すること。
（2）プログラムの変更は、保守手順に基づき、保守の責任者の承認を得て実施すること。
（3）変更したプログラム設計書に基づいてプログラミングしていることを検証すること。
４．保守の確認（５）
（1）変更したプログラムのテストの実施は、保守のテスト計画に基づいて行うこと。
（2）変更したプログラムは、影響範囲を考慮してテストを行うこと。
（3）変更したプログラムのテストは、ユーザが参画し、ユーザマニュアルに基づいて実施すること。
（4）変更したプログラムのテストの結果は、ユーザ、運用及び保守の責任者が承認すること。
（5）変更したプログラムのテストの結果を記録及び保管すること。
５．移行（３）
（1）移行手順は、移行の条件を考慮して作成すること。
（2）変更前のプログラム及びデータのバックアップを行うこと。
（3）運用及び保守の責任者は、他の情報システムへ影響を与えないことを確認すること。
６．情報システムの廃棄（２）
（1）旧情報システムは、リスクを考慮して廃棄計画を策定し、ユーザ、運用及び保守の責任者の承認
を得て廃棄すること。
（2）旧情報システムの廃棄方法及び廃棄時期は、不正防止及び機密保護の対策を考慮して決定する
こと。
Ⅵ．共通業務（７６）
１．ドキュメント管理（９）
1.1 作成（５）
（1）ドキュメントは、ユーザﾞ部門及び情報システム部門の責任者が承認すること。
（2）ドキュメント作成ルールを定め、遵守すること。
（3）ドキュメントの作成計画を策定すること。
（4）ドキュメントの種類、目的、作成方法等を明確にすること。
（5）ドキュメントは、作成計画に基づいて作成すること。
1.2 管理（４）
（1）ドキュメントの更新内容は、ユーザ部門及び情報システム部門の責任者が承認すること。
（2）ドキュメント管理ルールを定め、遵守すること。
（3）情報システムの変更に伴い、ドキュメントの内容を更新し、更新履歴を記録すること。
（4）ドキュメントの保管、複写及び廃棄は、不正防止及び機密保護の対策を講じること。
２．進捗管理（６）
2.1 実施（３）
（1）進捗計画に基づいて方法、体制等を定め、ユーザ、企画、開発、運用及び保守の責任者が承認
すること。 10
（2）ユーザ、企画、開発、運用及び保守の責任者は、進捗状況を把握すること。
（3）進捗の遅延等の対策を講じること。
2.2 評価（３）
（1）業務の工程終了時に、計画に対する実績を分析及び評価し、責任者が承認すること。
（2）評価結果は、次工程の計画に反映すること。
（3）評価結果は、進捗管理の方法、体制等の改善に反映すること。
３．品質管理（４）
3.1 計画（２）
（1）品質目標に基づいて品質管理の計画を定め、ユーザ、企画、開発、運用及び保守の責任者が承
認すること。
（2）品質管理計画は、方法、体制等を明確にすること。
3.2 実施（２）
（1）業務の工程終了時に、計画に対する実績を分析及び評価し、責任者が承認すること。
（2）評価結果は、品質管理の基準、方法、体制等の改善に反映すること。
４．人的資源管理（13）
4.1 責任・権限（３）
（1）要員の責任及び権限は、業務の特性及び業務遂行上の必要性に応じて定めること。
（2）要員の責任及び権限は、業務環境及び情報環境の変化に対応した見直しを行うこと。
（3）要員の責任及び権限を周知徹底すること。
4.2 業務遂行（４）
（1）要員は、権限を遵守すること。
（2）作業分担及び作業量は、要員の知識、能力等から検討すること。
（3）要員の交替は、誤謬防止、不正防止及び機密保護を考慮して行うこと。
（4）不測の事態に備えた代替要員の確保を検討すること。
4.3 教育・訓練（４）
（1）教育及び訓練に関する計画及びカリキュラムは、人的資源管理の方針に基づいて作成及び見直
しを行うこと。
（2）教育及び訓練に関する計画及びカリキュラムは、技術力の向上、業務知識の習得、情報システム
の情報セキュリティ確保等から検討すること。
（3）教育及び訓練は、計画及びカリキュラムに基づいて定期的かつ効果的に行うこと。
（4）要員に対するキャリアパスを確立し、業務環境及び情報環境の変化に対応した見直しを行うこと。
4.4 健康管理（２）
（1）健康管理を考慮した作業環境を整えること。
（2）健康診断及びメンタルヘルスケアを行うこと。 11
５．委託・受託（２５）
5.1 計画（３）
（1）委託又は受託の計画は全体最適化計画に基づいて策定し、責任者が承認すること。
（2）委託又は受託の目的、対象範囲、予算、体制等を明確にすること。
（3）委託又は受託は、具体的な効果、問題点等を評価して決定すること。
5.2 委託先選定（３）
（1）委託先の選定基準を明確にすること。
（2）委託候補先に必要な要求仕様を提示すること。
（3）委託候補先が提示した提案書の比較検討を行うこと。
5.3 契約（８）
（1）契約は、委託契約ルール又は受託契約ルールに基づいて締結すること。
（2）コンプライアンスに関する条項を明確にすること。
（3）再委託の可否について明確にすること。
（4）知的財産権の帰属を明確にすること。
（5）特約条項及び免責条項を明確にすること。
（6）業務内容及び責任分担を明確にすること。
（7）契約締結後の業務内容に追加及び変更が生じた場合、契約内容の再検討を行うこと。
（8）システム監査に関する方針を明確にすること。
5.4 委託業務（７）
（1）委託業務の実施内容は、契約内容と一致すること。
（2）契約に基づき、必要な要求仕様、データ、資料等を提供すること。
（3）委託業務の進捗状況を把握し、遅延対策を講じること。
（4）委託先における誤謬防止、不正防止、機密保護等の対策の実施状況を把握し、必要な措置を講
じること。
（5）成果物の検収は、委託契約に基づいて行うこと。
（6）業務終了後、委託業務で提供したデータ、資料等の回収及び廃棄の確認を行うこと。
（7）委託した業務の結果を分析及び評価すること。
5.5 受託業務（４）
（1）受託業務の実施内容は、契約内容を遵守すること。
（2）受託内容の進捗状況を把握し、リスク対策を講じること。
（3）成果物の品質管理を行うこと。
（4）契約に基づき、受託業務終了後、提供されたデータ、資料、機材等を返却又は廃棄すること。
６．変更管理（６）
6.1 管理（３）
（1）変更管理ルールを定め、ユーザ、開発及び保守の責任者が承認すること。
（2）仕様変更、問題点、ペンディング事項等の変更管理案件が生じた場合、他システムの影響を考慮
して決定すること。 12
（3）変更管理案件は、提案から完了までの状況を管理し、未完了案件は定期的に分析すること。
6.2 実施（３）
（1）変更管理案件は、変更管理ルールに従って実施すること。
（2）変更管理案件を実施した場合に、関連する情報システムの環境も同時に変更すること。
（3）変更の結果は、ユーザ、開発、運用及び保守の責任者が承認すること。
７．災害対策（１３）
7.1 リスク分析（３）
（1）地震等のリスク及び情報システムに与える影響範囲を明確にすること。
（2）情報システムの停止等により組織体が被る損失を分析すること。
（3）業務の回復許容時間及び回復優先順位を定めること。
7.2 災害時対応計画（６）
（1）リスク分析の結果に基づき、事業継続計画と整合をとった災害時対応計画を策定すること。
（2）災害時対応計画は、組織体の長が承認すること。
（3）災害時対応計画の実現可能性を確認すること。
（4）災害時対応計画は、従業員の教育訓練の方針を明確にすること。
（5）災害時対応計画は、関係各部に周知徹底すること。
（6）災害時対応計画は、必要に応じて見直すこと。
7.3 バックアップ（２）
（1）情報システム、データ及び関連設備のバックアップ方法並びに手順は、業務の回復目標に対応し
て定めること。
（2）運用の責任者は、バックアップ方法及び手順を検証すること。
7.4 代替処理・復旧（２）
（1）ユーザ及び運用の責任者は、復旧までの代替処理手続き及び体制を定め、検証すること。
（2）ユーザ及び運用の責任者は、復旧手続き及び体制を定め、検証すること。
附則
１．情報セキュリティに関連する項目については、情報セキュリティ管理基準を活用することが望ましい。
２．その他、関連する基準を活用することが望ましい。

システム管理基準①

システム管理基準
平成１６年１０月８日策定
前文
今日、組織体の情報システムは、経営戦略を実現するための組織体の重要なインフラストラクチャとなっ
ている。さらに、それぞれの情報システムがネットワーク化されることにより、社会の重要なインフラストラク
チャとなってきている。一方、情報システムはますます多様化、複雑化し、それに伴い様々なリスクが顕在
化してきている。また、情報システムに係わる利害関係者も組織体内にとどまらず、社会へと広がっている。
従って、このような情報システムにまつわるリスクを適切にコントロールすることが組織体における重要な
経営課題となっている。システム監査は、組織体の情報システムにまつわるリスクに対するコントロールが
適切に整備・運用されていることを担保するための有効な手段となる。また、システム監査の実施は、組
織体の IT ガバナンスの実現に寄与することができ、利害関係者に対する説明責任を果たすことにつなが
る。
組織体が情報システムにまつわるリスクに対するコントロールを適切に整備・運用する目的は、以下の
通りである。
・情報システムが、組織体の経営方針及び戦略目標の実現に貢献するため
・情報システムが、組織体の目的を実現するように安全、有効かつ効率的に機能するため
・情報システムが、内部又は外部に報告する情報の信頼性を保つように機能するため
・情報システムが、関連法令、契約又は内部規程等に準拠するようにするため
システム管理基準は、組織体が主体的に経営戦略に沿って効果的な情報システム戦略を立案し、その
戦略に基づき情報システムの企画・開発・運用・保守というライフサイクルの中で、効果的な情報システム
投資のための、またリスクを低減するためのコントロールを適切に整備・運用するための実践規範である。

システム管理基準は、本管理基準と姉妹編をなすシステム監査基準に従って監査を行う場合、原則とし
て、監査人が監査上の判断の尺度として用いるべき基準となる。ただし、組織体が属する業界又は事業
活動の特性等を考慮して、必要ある場合には、本管理基準の主旨及び体系に則って、該当する関係機
関などにおいて、独自の管理基準を策定し活用することが望ましい。また、時々の関連技術動向、関連
法令、及び社会規範などを考慮し、それらを反映した詳細なサブコントロール項目を策定することが望ま
しい。
なお、情報セキュリティの確保の観点から監査を実施する場合には、情報セキュリティ監査制度に基づ
く情報セキュリティ監査を行うことが要請される。一方で、システム管理基準においても情報セキュリティの
確保に関連する項目が挙げられているが、それぞれの項目について、情報セキュリティ管理基準を活用
して監査を実施することが望ましい。
1 システム管理基準（２８７項目）

Ⅰ．情報戦略(４７)
１．全体最適化（18）
1.1 全体最適化の方針・目標（６）
（1）ＩＴガバナンスの方針を明確にすること。
（2）情報化投資及び情報化構想の決定における原則を定めること。
（3）情報システム全体の最適化目標を経営戦略に基づいて設定すること。
（4）組織体全体の情報システムのあるべき姿を明確にすること。
（5）システム化によって生ずる組織及び業務の変更の方針を明確にすること。
（6）情報セキュリティ基本方針を明確にすること。
1.2 全体最適化計画の承認（３）
（1）全体最適化計画の立案体制は、組織体の長の承認を得ること。
（2）全体最適化計画は、組織体の長の承認を得ること。
（3）全体最適化計画は、利害関係者の合意を得ること。
1.3 全体最適化計画の策定（７）
（1）全体最適化計画は、方針及び目標に基づいていること。
（2）全体最適化計画は、コンプライアンスを考慮すること。
（3）全体最適化計画は、情報化投資の方針及び確保すべき経営資源を明確にすること。
（4）全体最適化計画は、投資効果及びリスク算定の方法を明確にすること。
（5）全体最適化計画は、システム構築及び運用のための標準化及び品質方針を含めたルールを明
確にすること。
（6）全体最適化計画は、個別の開発計画の優先順位及び順位付けのルールを明確にすること。
（7）全体最適化計画は、外部資源の活用を考慮すること。
1.4 全体最適化計画の運用（２）
（1）全体最適化計画は、関係者に周知徹底すること。
（2）全体最適化計画は、定期的及び経営環境等の変化に対応して見直すこと。
２．組織体制（９）
2.1 情報システム化委員会（５）
（1）全体最適化計画に基づき、委員会の使命を明確にし、適切な権限及び責任を与えること。
（2）委員会は、組織体における情報システムに関する活動全般について、モニタリングを実施し、必要
に応じて是正措置を講じること。
（3）委員会は、情報技術の動向に対応するため、技術採用指針を明確にすること。
（4）委員会は、活動内容を組織体の長に報告すること。
（5）委員会は、意思決定を支援するための情報を組織体の長に提供すること。
2.2 情報システム部門（２）
（1）情報システム部門の使命を明確にし、適切な権限及び責任を与えること。
2 3
（2）情報システム部門は、組織体規模及び特性に応じて、職務の分離、専門化、権限付与、外部委託
等を考慮した体制にすること。
2.3 人的資源管理の方針（２）
（1）情報技術に関する人的資源の現状及び必要とされる人材を明確にすること。
（2）人的資源の調達及び育成の方針を明確にすること。
３．情報化投資（６）
（1）情報化投資計画は、経営戦略との整合性を考慮して策定すること。
（2）情報化投資計画の決定に際して、影響、効果、期間、実現性等の観点から複数の選択肢を検討
すること。
（3）情報化投資に関する予算を適切に執行すること。
（4）情報化投資に関する投資効果の算出方法を明確にすること。
（5）情報システムの全体的な業績及び個別のプロジェクトの業績を財務的な観点から評価し、問題点
に対して対策を講じること。
（6）投資した費用が適正に使用されたことを確認すること。
４．情報資産管理の方針（４）
（1）情報資産の管理方針及び体制を明確にすること。
（2）情報資産のリスク分析を行い、その対応策を考慮すること。
（3）情報資産の効率的で有効な活用を考慮すること。
（4）情報資産の共有化による生産性向上を考慮すること。
５．事業継続計画（５）
（1）情報システムに関連した事業継続の方針を策定すること。
（2）事業継続計画は、利害関係者を含んだ組織的体制で立案し、組織体の長が承認すること。
（3）事業継続計画は、従業員の教育訓練の方針を明確にすること。
（4）事業継続計画は、関係各部に周知徹底すること。
（5）事業継続計画は、必要に応じて見直すこと。
６．コンプライアンス（５）
（1）法令及び規範の管理体制を確立するとともに、管理責任者を定めること。
（2）遵守すべき法令及び規範を識別し、関係者に教育及び周知徹底すること。
（3）情報倫理規程を定め、関係者に教育及び周知徹底すること。
（4）個人情報の取扱い、知的財産権の保護、外部へのデータ提供等に関する方針を定めること。
（5）法令、規範及び情報倫理規程の遵守状況を評価し、改善のために必要な方策を講じること。
Ⅱ．企画業務（２３)
１．開発計画（９）
（1）開発計画は、組織体の長が承認すること。
（2）開発計画は、全体最適化計画との整合性を考慮して策定すること。 4
（3）開発計画は、目的、対象業務、費用、スケジュール、開発体制、投資効果等を明確にすること。
（4）開発計画は、関係者の教育及び訓練計画を明確にすること。
（5）開発計画は、ユーザ部門及び情報システム部門の役割分担を明確にすること。
（6）開発計画は、開発、運用及び保守の費用の算出基礎を明確にすること。
（７）開発計画はシステムライフを設定する条件を明確にすること。
（8）開発計画の策定に当たっては、システム特性及び開発の規模を考慮して形態及び開発方法を決
定すること。
（9）開発計画の策定に当たっては、情報システムの目的を達成する実現可能な代替案を作成し、検
討すること。
２．分析（８）
（1）開発計画に基づいた要求定義は、ユーザ、開発、運用及び保守の責任者が承認すること。
（2）ユーザニーズの調査は、対象、範囲及び方法を明確にすること。
（3）実務に精通しているユーザ、開発、運用及び保守の担当者が参画して現状分析を行うこと。
（4）ユーザニーズは文書化し、ユーザ部門が確認すること。
（5）情報システムの導入に伴って発生する可能性のあるリスク分析を実施すること。
（6）情報システムの導入によって影響を受ける業務、管理体制、諸規程等は、見直し等の検討を行う
こと。
（7）情報システムの導入効果の定量的及び定性的評価を行うこと。
（8）パッケージソフトウェアの使用に当たっては、ユーザニーズとの適合性を検討すること。
３．調達（６）
（1）調達の要求事項は、開発計画及びユーザニーズに基づき作成し、ユーザ、開発、運用及び保守
の責任者が承認すること。
（2）ソフトウェア、ハードウェア及びネットワークは、調達の要求事項を基に選択すること。
（3）開発を遂行するために必要な要員、予算、設備、期間等を確保すること。
（4）要員に必要なスキルを明確にすること。
（5）ソフトウェア、ハードウェア及びネットワークの調達は、ルールに従って実施すること｡
（6）調達した資源は、ルールに従って管理すること。
Ⅲ．開発業務 （４９）
１．開発手順（４）
（1）開発手順は、開発の責任者が承認すること。
（2）開発手順は、開発方法に基づいて作成すること。
（3）開発手順は、開発の規模、システム特性等を考慮して決定すること。
（4）開発時のリスクを評価し、必要な対応策を講じること。
２．システム設計（15）
（1）システム設計書は、ユーザ、開発、運用及び保守の責任者が承認すること。
（2）運用及び保守の基本方針を定めて設計すること。
（3）入出力画面、入出力帳票等はユーザの利便性を考慮して設計すること。 5
（4）データベースは、業務の内容及びシステム特性に応じて設計すること。
（5）データのインテグリティを確保すること。
（6）ネットワークは、業務の内容及びシステム特性に応じて設計すること。
（7）情報システムの性能は、要求定義を満たすこと。
（8）情報システムの運用性及び保守性を考慮して設計すること。
（9）他の情報システムとの整合性を考慮して設計すること。
（10）情報システムの障害対策を考慮して設計すること。
（11）誤謬防止、不正防止、機密保護等を考慮して設計すること。
（12）テスト計画は、目的、範囲、方法、スケジュール等を明確にすること。
（13）情報システムの利用に係る教育の方針、スケジュール等を明確にすること。
（14）モニタリング機能を考慮して設計すること。
（15）システム設計書をレビューすること。
３．プログラム設計（５）
（1）プログラム設計書は、開発の責任者が承認すること。
（2）システム設計書に基づいて、プログラムを設計すること。
（3）テスト要求事項を定義し、文書化すること。
（4）プログラム設計書及びテスト要求事項をレビューすること。
（5）プログラム設計時に発見したシステム設計の矛盾は、システム設計の再検討を行って解決するこ
と。
４．プログラミング（４）
（1）プログラム設計書に基づいてプログラミングすること。
（2）プログラムコードはコーディング標準に適合していること。
（3）プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。
（4）重要プログラムは、プログラム作成者以外の者がテストすること。
５．システムテスト・ユーザ受入れテスト（１３）
（1）システムテスト計画は、開発及びテストの責任者が承認すること。
（2）ユーザ受入れテスト計画は、ユーザ及び開発の責任者が承認すること。
（3）システムテストに当たっては、システム要求事項を網羅してテストケースを設定して行うこと。
（4）テストデータの作成及びシステムテストは、テスト計画に基づいて行うこと。
（5）システムテストは、本番環境と隔離された環境で行うこと。
（6）システムテストは、開発当事者以外の者が参画すること。
（7) システムテストは、適切なテスト手法及び標準を使用すること。
（8）ユーザ受入れテストは、本番同様の環境を設定すること。
（9）ユーザ受入れテストは、ユーザマニュアルに従い、本番運用を想定したテストケースを設定して実
施すること。
（10）ユーザ受入れテストは、ユーザ及び運用の担当者もテストに参画して確認すること。
（11）システムテスト及びユーザ受入れテストの結果は、ユーザ、開発、運用及び保守の責任者が承認
すること。
（12）システムテスト及びユーザ受入れテストの経過及び結果を記録及び保管すること。 6
（13）パッケージソフトウェアを調達する場合、開発元が品質テストを実施したことを確認すること。
６．移行（８）
（1）移行計画を策定し、ユーザ、開発、運用及び保守の責任者が承認すること。
（2）移行作業は文書に記録し、責任者が承認すること。
（3）移行完了の検証方法を移行計画で明確にすること。
（4）移行計画に基づいて、移行に必要な要員、予算、設備等を確保すること。
（5）移行は手順書を作成し、実施すること。
（6）移行時のリスク対策を検討すること。
（7）運用及び保守に必要なドキュメント、各種ツール等は開発の責任者から引き継いでいること。
（8）移行は関係者に周知徹底すること。

Nickelback - Savin' Me

If Today Was Your Last Day
http://youtu.be/lrXIQQ8PeRs

イラストレーター KEI Live Painting

We The Kings - Heaven Can Wait

http://youtu.be/rzpCjiLMJzI