Murayama blog.

プログラミング教育なブログ

Cubeで遊んでみた。


久しぶりにActionScriptを触ってみたので記念にアップ。



プログラムはしょぼしょぼやけど、3Dで動くのを作るのはやっぱり面白い。

package
{
	import flash.display.Bitmap;
	import flash.display.BitmapData;
	import flash.events.Event;
	
	import org.papervision3d.materials.BitmapMaterial;
	import org.papervision3d.materials.ColorMaterial;
	import org.papervision3d.materials.utils.MaterialsList;
	import org.papervision3d.objects.primitives.Cube;
	import org.papervision3d.view.BasicView;
	
	public class CubeSample extends BasicView
	{
		[Embed(source="/assets/IMG_0150.JPG")]
		private var ok:Class;
		[Embed(source="/assets/IMG_0053.JPG")]
		private var boy:Class;
		[Embed(source="/assets/IMG_0055.JPG")]
		private var bird:Class;
		[Embed(source="/assets/IMG_0077.JPG")]
		private var cafe:Class;
		private var cube:Cube;
		
		public function CubeSample()
		{
			var materialsList:MaterialsList = new MaterialsList();
			var array:Array = [bird, boy, ok, cafe];
			var array2:Array = ["front", "back", "top", "bottom"];
			for(var i:Number = 0; i < array.length; i++){
				var bitmap:Bitmap = new array[i]() as Bitmap;
				var bitmapData:BitmapData = new BitmapData(210, 280);
				bitmapData.draw(bitmap);
				var material:BitmapMaterial = new BitmapMaterial(bitmapData, true);
				materialsList.addMaterial(material, array2[i]);	
			}
			
			materialsList.addMaterial(new ColorMaterial(0xffffff), "right");
			materialsList.addMaterial(new ColorMaterial(0xffffff), "left");
 			cube = new Cube(materialsList, 210, 280, 280, 4, 4, 4);
			scene.addChild(cube);
			startRendering();
		}
		
		override protected function onRenderTick(event:Event=null):void
		{
			cube.rotationX += 1.5;
			super.onRenderTick(event);
		}
	}
}

チェンジマネジメント


何かの本で読んだんですけど、Change Managementという言葉があります。
てきとうに訳すと「変更管理」とかなわけですが、カタカナで表現するのが個人的には気に入ってます。チェンジマネジメント。


で、このチェンジマネジメント広義には、

社員が大規模な業務改革といった新しい変化に対応しやすくするためのマネジメント手法。多くの人は急速に環境が変化することを好まないため、何らかの改革を推進しようとすると必ず抵抗が生じる。業務改革を成功させるには、経営陣などが率先して、改革の狙いや目標などを社員に浸透させることが、不可欠になっている。

とITProには書いています。
#ここで話したいことと少し違うかもしれませんが。。


このチェンジマネジメントという言葉ですが、
IT業界、特に要件定義で使われる場合は、以下のような意味合いになります。
新しいシステムを開発、導入することで、業務の形態が変化してしまったため、人員の配置転換が発生したとします。
こういうときの備えをしっかりしておくのがチェンジマネジメントです。


例えば、営業社員が100名いる会社があるとして、
その会社が、営業支援システムを導入した結果、営業社員30名で仕事がまわせるようになったとします。


このとき、仕事のなくなってしまう70名をどうするか?
そういうところまで考慮しておくのがチェンジマネジメントになります。


チェンジマネジメントのしっかりできている会社(システム開発)は、
この70名の感情(営業職への誇り)を汲んだ形の人員配置まで想定して、システムを開発しているんでしょう。
#この70名は、皆、納得して商品企画部、経理部へ異動してもらう、とか。
そうでない会社は、
システムを導入することで、社員70名を解雇してしまうかもしれません。


個人的には、システムを導入するとことで、顧客全体に幸せになってもらいたいと思います。
というか、そこまで考慮して仕事したいと思います。簡単ではないでしょうけど。
もし、システムを導入することで、一部の人にとって不幸を招くのでは、なんだか寂しいものがあります。


無駄をなくすのは大事だけど、心もなくすのは、なくしすぎです。*1


話は変わりますが、高速道路の値下げ1000円の件です。
車好きな人には、けっこう反応は良いみたいですね。
#僕は車乗らない、というか車があまり好きではないので、正直、実感はないのですが。。


一方で、高速道路の値下げの影響で、
フェリー業界(車を船で運ぶの)はけっこうな痛手を受けているようです。
#倒産しそうな会社もあるんだとか。


高速道路1000円を考案した人、承認した人ってのは、フェリー業界がこうなることとか考えてなかったのかな。



要求:車を売りたい。
仕様:高速道路を1000円にすればイイんじゃね?


そんなかんじやったんかな。

*1:上手いこと言った

エンタープライズアプリケーション。


僕は普段、業務アプリケーションを開発しているわけですが。


なんか「業務アプリケーション」って呼ぶとイケてない気がする。
「ビジネスアプリケーション」とか「エンタープライズアプリケーション」とか呼ぶ方が格好イイかんじがする。




オーロラエクスキューション。

要求と仕様について


要求仕様書について、いろいろ勉強してみるといろいろわかってきたので、
少しふざけたかんじでまとめてみます。
#そもそも、僕は要求と仕様についてちゃんと理解していなかったので。


「要求」と「仕様」について。


「要求(Requirement)」とは、言い換えると「欲しいもの」になります。
「要求」は依頼者の欲しいものを表していますが、それ自体は非常に曖昧なものです。
曖昧な「要求」は、どのようにすれば達成したことになるのかという明確な基準がありません。
そこで、「要求」から「仕様」を導き出すことによって、その曖昧性を排除します。


「仕様」とは「要求」の利害関係者が、その意味を取り違えることなく一意に識別できるものです。*1
つまり、「仕様」は曖昧なものであってはいけません。
「要求」から導き出した「仕様」をすべて満たしているかどうかによって、
その「要求」が達成できたかどうかを判断することができます。


そのため、「仕様」は開発者にとって達成すべき目標になります。
「仕様」は、最終的にはソースコードなどなんらかの形に変換することになります。



と、この話をシステムとはぜんぜん関係のないところで例えてみます。
こっからいいかげんです。



例えば、僕が「かっこよくなりたい」と思ったとします。



「かっこよくなりたい」というのは「要求」です。
「要求」なので曖昧です。
「かっこよくなりたい」っていうのは簡単ですが、いかんせん曖昧なもんで、
何をもって「かっこいい」と判断するか、っていうのが大事なわけです。


そこで「かっこよくなりたい」という「要求」から「仕様」を導き出します。
例えば、
・髪を切ってオシャレなヘアスタイルにする。
・ダイエットをして体重を60キロにする。
・オシャレな服を買いにいく。
みたいなものが「仕様」の候補に挙がります。


細かいことを言うと、「仕様」は曖昧であってはいけないので、


・髪を切ってオシャレなヘアスタイルにする。


のままでは、「オシャレな」の部分がイマイチ明確ではありません。
そこで、


・髪を切って3センチ程度のショートモヒカンにする。


の方が明確でよいと思います。



同じ理由で、
・オシャレな服を買いにいく。

・ビームスのTシャツを買いにいく。
とした方が明確になります。#厳密には、まだ若干グレーですけど。。


「仕様」が明確かどうかの基準は、「要求」の利害関係者(この場合、自分。と周りの友人くらいとします。。)が、
同じ理由で納得できるかどうかです。


結果として、
・髪を切って3センチ程度のショートモヒカンにする。
・ダイエットをして体重を60キロにする。
・ビームスのTシャツを買いにいく。


が「かっこよくなりたい」という「要求」から導き出した「仕様」ということになります。


次に、これらの「仕様」を達成するため行動を起こします。


美容院に行き、ベッカムみたいなショートモヒカンで、と時代錯誤なお願いをして、
ビームスにいってTシャツを買います。ディスプレイされてるのを買っておけば、まーたぶん大丈夫でしょう。
最後にダイエットです。これは大変ですが、一番てっとり早く痩せる方法は食べないことです。
昼ごはんをバランスアップとかソイジョイにするだけでけっこう痩せます。ソースは俺。


以上で僕は、
・髪を切って3センチ程度のショートモヒカンにする。
・ダイエットをして体重を60キロにする。
・ビームスのTシャツを買いにいく。


という「仕様」をみたし、かっこよくなったのでした。


おしまい。



一応言っとくと、この話はフィクションです。

*1:「仕様」は検証可能です。

要件定義の用語について


今、要件定義(要求定義?)について勉強しています。


「要求」とか「要件」とか。
微妙に人によって解釈に差があるような気がします。


とりあえず僕なりの使い分けを書いてみます。
あまり自信がないので、参考にはならないかもしれません。
#ツッコミ歓迎です。優しいのがいいです。

  • 「要求」とは、問題を解決するために顧客が望むもの。
  • 「要件」とは、問題を解決するためにシステムが提供するもの。


何が言いたいかというと、要件定義のヒアリングをする時点で、
まず、顧客からあがってくる依頼事項が「要求」と考えています。


「要求」は、それ自身に実現性がなかったり、要求間での矛盾、曖昧性を含んでいたりします。
システムエンジニア(コンサルでもよい)は、顧客からあがってくる「要求」に対して、
実現性、矛盾、曖昧性など問題がないか検討し、「要求」に対する費用対効果や開発コストを検討します。


システムエンジニアは、顧客に対して、
「要求」の実現性や、費用対効果、開発コストを提示します。
顧客は、提示された情報をもとに「要求」を取捨選択します。


取捨選択の結果、最終的に必要ということになった「要求」を「要件」と呼びます。*1
「要件」は顧客との間で取り決めたシステム開発を進める上で「守らなければならないもの」であると思っています。


以上、こんなかんじでどうでしょう。


帰ったら続きを書きます。

*1:ソースは俺。。