弧と花ブログ
さあ、才能(じぶん)に目覚めよう。あなたの5つの資質。
- 2010-05-06 (木)
- 通常日記
本を1冊紹介します。
「さあ、才能(じぶん)にめざめよう」という本です。
この本は、200万人のインタビュー調査から、人が持っている強みという
資質を34パターン定義して、「あなたは、この34パターンのうち、
この5つのパターンを強めに持っています。」というのを教えてくれるというものです。
パッと見割と怪しいのですが、私がこの本を知った数年前に会社の部署内でちょっと流行って紹介してもらいました。遊びも兼ねてやってみるか〜と。
2001年頃に初版が出た後、2008年時点で21刷だったので今はもっと刷られてる気がします。
この記事書く時に発売時期と刷数見てちょっとびっくりしました。
こんなにあやしそうなのに結構売れてますね(笑
さて、私の強みとなる資質はというと以下の5つだそうです。(傾向が強い順)
-
1. 着想
2. 最上志向
3. 内省
4. 学習欲
5. 戦略性
のようです。
それぞれの資質を詳しく見て行くと、こういう紹介のされ方をします。
要点を太字にしておきます。
■1. 着想
あなたは、複雑に見える表面の下に、なぜ物事はそうなっているかを説明する、的確で簡潔な考え方を発見すると嬉しくなります。着想とは結びつきです。あなたのような考え方を持つ人は、いつも結びつきを探しています。見た目には共通点のない現象が、何となく繋がりがありそうだと、あなたは好奇心をかき立てられるのです。着想とは、皆がなかなか解決できずにいる日常的な問題に対して、新しい見方をすることです。あなたは誰でも知っている世の中の事柄を取り上げ、それをひっくり返すことに非常に喜びを感じます。それによって人々は、その事柄を、変わっているけれど意外な角度から眺めることができます。他の人たちはあなたのことを、創造的とか独創的とか、あるいはコンセプチュアルとみなすかもしれません。
■2. 最上志向
あなたは平均以下の何かを平均より少し上に引き上げることに全く意味を見出しません。平均以上の何かを最高のものに高める方がはるかに胸躍ります。自分自身のものか他の人のものかに関わらず、強みはあなたを魅了します。あなたはあなたの強みを高く評価してくれる人たちと一緒に過ごすことを選びます。同じように、自分の強みを発見しそれを伸ばしてきたと思われる人たちに惹かれます。あなたを型にはめて、弱点を克服させようとする人々を避ける傾向があります。あなたは自分の弱みを嘆きながら人生を送りたくありません。それよりも、持って生まれた天賦の才能を最大限に利用したいと考えます。その方が楽しく、実りも多いのです。そして意外なことに、その方がもっと大変なのです。
■3. 内省
あなたは考えることが好きです。あなたは頭脳活動を好みます。あなたは脳を刺激し、縦横無尽に頭を働かせることが好きです。内省という資質は、あなたが何を考えているかというところまで影響するわけではありません。単に、あなたは考えることが好きだということを意味しているだけです。あなたは独りの時間を楽しむ類の人です。なぜなら、独りでいる時間は、黙想し内省するための時間だからです。
■4. 学習欲
あなたは学ぶことが大好きです。あなたが最も関心を持つテーマは、あなたの他の資質や経験によって決まりますが、それが何であれ、あなたはいつも学ぶ「プロセス」に心を惹かれます。内容や結果よりもプロセスこそが、あなたにとっては刺激的なのです。あなたは何も知らない状態から能力を備えた状態に、着実で計画的なプロセスを経て移行することで活気づけられます。最初にいくつかの事実に接することでぞくぞくし、早い段階で学んだことを復誦し練習する努力をし、スキルを習得するにつれ自信が強まる――これがあなたの心を惹きつける学習プロセスです。
■5. 戦略性
戦略性という資質によって、あなたはいろいろなものが乱雑にある中から、最終の目的に合った最善の道筋を発見することができます。これは学習できるスキルではありません。これは特異な考え方であり、物事に対する特殊な見方です。他の人には単に複雑さとしか見えない時でも、あなたにはこの資質によってパターンが見えます。起こる可能性のある障害の危険性を正確に予測し、行き止まりの道をあなたは切り捨てます。まともに抵抗を受ける道を排除します。そして、選ばれた道(すなわちあなたの戦略)にたどり着くまで、あなたは選択と切り捨てを繰り返します。
この本は「長所」を教えてくれるわけではないです。
行動に強く傾向が出ているパターンを長所となりうる資質として教えてくれているだけです。
まわりで10人くらいやってて、周りのみんなの結果を見てもなかなかフィットしていて理解できる結果だったので、結果をExcelで表にして共有したりして楽しみましたね。周りから「着想が1つめに来てるのは予想通り(笑」みたいなことを言われるのはちょっとうれしかったり。「自分でこうありたいと思っている事」と「自覚していること」がある人は、割とダイレクトに反映される結果になるんじゃないかなと思います。
さて、実際に5つの資質をどうやって教えてもらうかというと、
この本は「ストレングスファインダー」という、50問くらいの質問に対して
「あてはまる/あてはまらない」みたいなのを答えて行く、よくある性格診断みたいなウェブサイトが同時に用意されていてそれを利用して答えを出します。
「サイトのURL」と「パスワード」が本の中に書かれていて、パスワードで登録して自分用の答案を作るようになっているので、中古で買ってもだめです。必ず新品を買わないといけないというなかなかのビジネスモデルになっているのでご注意ください(笑
まあ、自分について見直してみるきっかけが1600円で得られると思ったら安いもんだと思いますよ〜。
(一応上でアマゾンのリンクで紹介してますけど、アソシエイトID外してもらっても構いませんので(笑))
■関連記事:
イチローに学ぶ芸術性
- 2010-05-05 (水)
- デザイン
少し前に、イチローが隔週スポーツ雑誌「Number」の751号(4/15)での特集インタビューに出てたのですが
こんなことを言っていました。
イチロー:(少し省略してます)
「僕は相手の選手によく『なぜ簡単にヒットが打てるんだ』と不思議がられるんですけど、おそらく僕の動きって、いろんなことが簡単に見えているんですよ。相手も、攻めていたはずなのにいつの間にかやられている。それは、やっかいですもんね。相手を僕の方に導く。相手の事を読んで結果を出しても、そこに芸術性は無いんです。相手を知らず知らずのうちに誘導するというのは、読むという次元を超えた芸術なんです」
この記事を見た時、
最近考えていたデザインの話とつながりそうだと思ったので考えたことを書いてみる。
デザインとアートの境界線
デザインを、イチローが言う言葉にあてはめて考えるなら、
相手の事を読んで、状況を読んで、文脈を考えて結果を出すことはデザインと呼ぶだろう。
でも、それだとそこには芸術性は無い、となる。
じゃあ、相手を知らず知らずのうちに誘導するというのはどうあてはめられる?
ここで、最近僕が考えていたデザインについて話すと、
僕は最近、「何かをやる」ことに対する最高のデザインの形は、
「何かをやる」作業を簡略化することでも省略化することでも、はたまた別の何かで代替してそもそも無くしてしまうことでもなく、その「何か」を「したくなる」カタチなんじゃないかなと思っている。
例えば掃除機のデザインについて考えるとする。
掃除をいかに簡単に楽にするか、便利にするかということを考えて、そういうモノが実際作られている。いいデザインだと言えるものもあるだろうと思う。
けど、掃除する事って基本めんどくさいよね?掃除機がいかに便利になろうと掃除する本人がやる気にならないと当然部屋はきれいにならない。
掃除機の究極の目的を考えた時にそれは「部屋がきれいになること」だろうと考えた。「掃除を簡単便利にすること」は手段であって究極的な目的じゃないはず。
そして、その目的達成のために最も大きな問題って人のやる気のところじゃないのかなと。
そうしたら、「掃除の作業プロセスの一部を便利で機能アップさせた掃除機」を使ってよりも、少々便利じゃなくて簡単じゃなくても「なんか知らんけど『うわぁ〜掃除してぇ〜〜!!』ってなる掃除機」の方が「良い掃除機」なんじゃないの?って考えた訳だ(笑)。(それは使ってて楽しい、何だか気持ちいい、かもしれないし、掃除したあかつきには何かが起こるものかもしれないし)
それで、イチローの記事読んだ時にこれが「相手を知らず知らずのうちに誘導することにある芸術」ってのになるんじゃないの?って思った。
知らず知らずの内に誘導するというアート
状況文脈にフィットさせようとするデザインのプロセスと、
人や結果の方を自分に引き寄せるアートのプロセス。
もしかしたら、結果同じになることもあるかもしれないけど、
物事の優先度が全く違うので、切り捨てることの順番が全く変わるはず。
だから、このプロセスはきっと同じではない。
もしこの「相手を知らず知らずのうちに誘導する」ことを芸術・アートと呼ぶなら、
上で考えた「最高のデザイン」というのはアートの力が必要ということになる。
ただ、ものごとを簡単化、省略化しようというデザインプロセスの方でも、「掃除という作業を人の作業から消しきる」ところまでいくなら、それは「刀を抜く前から勝っている」っていう方向の意味で究極芸術って言えるかもしれないけど(笑
どこをアートとして捉えるかってのは人によるのはもちろんですが、
自分にとっての「アート」の部分がどこなのかってのを意識しておくことにヒントをもらえた。
何か作る時に、この「アート」っていうもやもやした部分が残るからこそ、ものと人、自分と他人との関係性を
考えることが楽しくなるってものだと思う。
それにしても・・・イチローさすがだなあ。
「知らず知らずに誘導する」の部分、具体的にどう考えながらプレイしてるのか気になるなあ〜。
■関連記事:
Flashサイト開発日記#3 -オブジェクト指向-
- 2010-03-01 (月)
- ActionScript | Flash | Flashサイト開発日記
さて、Flashサイト開発日記第3回です。
(いつものように弧と花開発の場合です)
今回はオブジェクト指向の利点について。
Flashサイト開発する時にActionScrip3.0でオブジェクト指向を用いて
開発しているので、オブジェクト指向についてある程度知識を持ってもらった方が
設計の話をする時に楽になるので、そこから入りたいと思います。
さて、やっと、ちゃんとまともに設計の話が絡んできます、、、と思ったんですが、
書いてるうちにオブジェクト指向だけで
かなりの量になったので、サイト見ながら設計について
話すのはまた次回にします。。。
はい、とにかく、
ソースコードを一切使わずに、オブジェクト指向について
説明しようと思う!
最初本当にオブジェクト指向という概念を理解するための
話になりますからね!実装出てきませんからね!気をつけてね!
オブジェクト指向用の用語とかもほぼ使いませんからね!
●オブジェクト指向とは
ざくっと言ってしまうと、
ソースコードを書く時に、何も考えずに処理を書いて行くんじゃなくて、
実際に物体をイメージして、そいつに名前を付けて、
そいつの性質とか機能とかの役割を、
ちゃんとひとまとめにしてプログラムを書く感じで
作って行こうよっていう、開発する時の考え方のこと。
(これは色々意見あると思いますが)
というのも、現実の世界で僕らが名前をつけて呼んでいるものには
大体名前がついてますよね。
「テレビ」とか「車」とか「犬」とか。

ぼくらは「テレビ」と言ったら何ができるものかってのを知っている。
電源をつけると映像が映る、チャンネルを指定すると
そのチャンネルごとの番組が映ることを知っている。
僕らは、名前がついた「もの」の単位で、ものごとを理解して覚えている。
そういう、機能とか性質を持った「テレビ」みたいな名前がついたものの
単位でプログラムも作って理解していった方がわかりやすいよ、管理しやすいよ、
っていうメリットのある開発時の考え方です。
そこから、
「みんなで分担しやすい」「後から拡張しやすい」
「後から見ても内容を思い出しやすい」みたいなメリットも
出てくるんですが、そういうのも軽めに説明していきます。
●じゃあ、オブジェクト指向のうれしさを分かってもらうために
具体的なものにあてはめて見てみよう!
まず、目の前になつかしの任天堂ファミコンと、
それにつながってるテレビモニタがあって、
それとソフト(カセットと言うべきかなw?)が何本か
あるところを想像してほしい。
そして、そこにあなた(ユーザー)がいるとしましょう。
(ファミコン分からない人はDSに置き換えて想像して下さい。)

この、実際に存在する物体(オブジェクト)の1つ1つを「class、クラス」と呼ぶとします。
ここではクラスになるのは、
「あなた(ユーザー)」「ファミコン」「カセット(ソフト)」「モニタ」あたりになるね。
それで、「あなた」が「ファミコン」に「カセット」をざくっとさしこんで、
ファミコンの”電源スイッチ”を入れれば「モニタ」に映像が映る。
「あなた」が「ファミコン」の”Aボタン”や”Bボタン”を押せば、
今ささっている「カセット」に応じた反応がモニタ上に反映される。
各クラスは、それぞれが自分の役割を持っています。
そして、クラス同士は一定のルールに基づいて連携しています。
例えば、ファミコンとカセット(ソフト)というクラスの間の
やりとりのルールについて見てみると、
あなたが違うカセットで遊びたい場合、
ファミコンに刺さっているカセットを刺し替えればいいんだけど、
全てのカセット(ソフト)は、差し込み口の形は全部同じになってるよね。

カセットって1つ1つに「ドラゴンクエスト」とか「ファイナルファンタジー」とか
固有の名前もついていて、中身は全然違うものなんだけど、
それらは全部まとめて一言で「カセット」とみなす事ができますよね。
そういう、同じ名前で呼べるもの(生物でも無生物でも)は、
共通の特徴を持っていて、見た目が似ていて、
同じ機能を必ず持っています。
今回の例で「カセット(ソフト)」の特徴と言えば、
・あなたがファミコンのAボタンやBボタンを押した時の反応の仕方が決められている
・どれもファミコンの差し込み口に刺さる口を持っている
というようなことですね。
この共通の特徴・ルールがとても重要。
ファミコンの差し込み口に合わせて作らないと
そのカセットはファミコンでは遊べないことになります。
こういう、オブジェクト同士のやりとりのための
つなぎ部分のことを「インタフェース」と言ったりします。
オブジェクト間でインタフェースをそろえておく事が大事。
プログラミングでもそのまんま使える言葉です。
(publicメソッドをどうデザインするか?ってことにもなる)
●作業分担がちゃんとできるよ!
こういうインタフェースのルールを作ったら何がうれしいか?
それは例えば、1つ挙げると、
「カセット」を作る時に
・決まった受け口を持っている事、と
・AボタンやBボタンを押す事で反応を返してくれる事、
みたいなルールさえ守ってくれればあなたが作ったゲームをファミコンで遊んでもらえますよ!」
みたいなことにしておくことでいろんな人がファミコン用カセットを作ることができるようになったこと!
「私はこれを作るから、あなたはこれを作ってね。」がとってもやりやすい!

→これって全体で見ると見事に作業分担できてますよね。
沢山のソフト会社が、「ユーザ」とコントローラを使ってやりとりしたり、
「テレビモニタ」と映像のやりとりをするハード(ファミコン)を作るのは任天堂に
任せておいて、自分達はその上で遊ぶためのカセットだけ作るっていう風になりました。
この絵は、大きい視点で見た会社ごとの作業分担ですが、
もちろん自分のチームで作る時の作業分担や、自分のソースコードの中だけでも
きっちり役割分担させるための考え方としても役立ちますよ。
●ユーザを迷わせない!:【制約】という考え方
上で見たインタフェースには「制約」という非常に重要な考え方があります。
制約って言葉はデザインを勉強してても出てきますが、大体同じ意味です。
「どこをユーザから見える/触れるように解放(publicに)して、
どこをユーザから隠すか(privateに)」です。
(実際、ここの線引きがすっごい大事です)
あなたは自分の好きな「カセット」を「ファミコン」に指せば
AボタンやらBボタンやら押して、そのゲームに合った操作ができる。

これは、別の見方をすれば、
・「ユーザーは、『カセット』というオブジェクトを差し替える」という
ことを通してしか、操作内容をきり変えることができないようにしてある。
・ユーザがファミコンに対して与えられる操作はAボタンとかBボタンを押すという
方法しかない。
という風にに制限してある。
=ユーザが簡単に遊べるようにデザインしてある。
もしこの制限がなくて、ファミコンが内部でやってくれてるような映像変換計算や音声出力なんかも
あなたがやらないといけないとしたら、ものすごく大変(というか普通の人間には無理)ですよね。
ざくっとソフトを差し込んで電源いれたらあとはAとかBとか押すだけで楽しめるから良いんでしょ、ってこと。
”あえて制限してある”ってのが大事。
余計なところを触れないようにしておくことで、あなたが不必要に困る事のないようにする。
あなたにとっては、AボタンやBボタンを押した後の処理はファミコンの役目。
ファミコンにとっては、AボタンやBボタンが押された後にゲーム映像にどういう処理をするか、
ってのは「カセット」の役目であって、ファミコンはそんなこと知らないわけだ。
こういう風に、各オブジェクト間でやりとりする方法を限定してあげて、
自分の中身に不用意に触ることができない作りをすることは、オブジェクト指向のすごく大事なところです!
オブジェクトは中身が勝手に触れないからこそオブジェクト。
テレビも車も犬も人間も”中身”は勝手に触れませんよね。
これをやることで、やっとソースコードをひとかたまりにしてオブジェクトが表現できます。
(一方で、なんでも触り放題な状態だとただの”部品の羅列”になっちゃいますね。
自由度は高いけど危険度も高い。こういうのはチームで開発する場合は結構大変です。C言語とかね。)
●オブジェクト指向できれいにソースコードを書けばドキュメントは不要?
じゃあ、ここまで見てきたようなオブジェクト指向で書かれたソースコードは後から見たら
すぐ内容が把握できるのか、というと、そうではないです。
たまに「きれいに書きさえすれば、ソースコードがドキュメント」みたいに言う人がいますが、それは大嘘です。
ソースコードを見て分かることと、ドキュメントを別に用意して説明すべきことは全く別になるからです。
クラス図みたいな絵を書いておいたり、各クラスの説明のためのドキュメントが
ちゃんと残ってないと、初めて見た人が短時間で理解するのは結構きついです。
自分が書いたものであっても、半年前の自分が書いたコードは
もはや別人が書いたのと大差ないくらい忘れてます。
ちゃんと周りのドキュメントも書かないとだめですね。
結構時間をかけさせてもらえないプロジェクトが実は相当多いですが、
継続的にメンテする可能性がちょっとでもあるなら、
ドキュメント作成に時間をかけることは絶対に理解を得て作成しておくべきですね。
(あー、ドキュメントに書くべき情報とはどんなものなのか、でも1つ記事できそうなくらいですね。。。)
では、今回はここまで。
次回こそはサイトの設計の話に・・・(笑
多分そこで、今回話したようなクラスを実際に書くとしたらどうなるのか、
みたいなことが書けるはずです。多分。多分!
■関連記事:
- Flashサイト開発日記#1:「弧と花」の設計とProgression利用方法
- Flashサイト開発日記#2-開発環境&開発スタイル-
- ActionScript3.0の表示は「深度」っていう概念ではないです。
- みっくみく
Flashサイト開発日記#2-開発環境&開発スタイル-
- 2010-02-07 (日)
- ActionScript | Flash | Flashサイト開発日記
Flashサイト開発日記第2回です。
主にフルフラッシュサイト「弧と花」の開発の場合です。
前回のエントリで「次はオブジェクト指向について」とか言いましたが、
その前に、今回はFlash&ActionScript3.0での現在の私の開発環境と開発スタイルのご紹介。
もっとこうすると便利だよ!ってことがあればコメントぜひお願いします!
(ああ実に手探り運転w。最終的には、開発中考えてること全部しゃべるよ!)
さて、FlashとFlex Builderの私にとっての現状の役割分担。
■Flash:パーツの倉庫的役割(SWC作成)と、コンパイル(パブリッシュ)。
■FlexBuilder:ActionScriptエディタ。全ての実装はここで行う。
大体こんな分担。Flash上で一切スクリプトは書きません。
以下、Flash用Progressionはインストール済という前提で!
●実際作り始めるまでの流れ(Flashで作ってFlexBuilderで読み込み)
まず、Flash上でProgressionの窓を使ってプロジェクトを作る。
例えば今回のサイト用のプロジェクトを(適当な)Index.flaとして
作るとしましょう。そしたら、こんな画面。

作るところからコンパイルまでずっとこんな画面。
ずっとほぼ空っぽのまんまです。
その後、できたプロジェクトをFlexBuilderにまるごと読み込みます。
FlexBuilderをFlashのActionScriptエディタとしてFBを使う準備が整う。
流れは、FlexBuilderでActionScriptプロジェクトを作ったら、
あとは、Flash(progression)で作ったプロジェクトを、何も考えずにフォルダごと
まるごとナビゲータにドラッグしてつっこむだけ!それで準備完了!
余分なものも一緒に入るかもしれませんが気にしない!
あっても別に困らないからね。
そしたらこんな画面です。

●Flashの役割(その1)
次に、ここから開発作業ですが
Flashに画像やら音楽やら素材を読み込んだり、複数の
パーツを一塊にしたものを作りたいなら適当にFlashで作る。
それぞれにリンケージのクラス名をつけておく。
例えば(適当な)main.flaをSWC作成用のflaファイルだとしましょう。
それで以下のように、とにかく作ったものに名前つけただけの状態にしておきます。

Flashは単にパーツをグラフィカルにわかりやすく整理するのに向いていると思うので、パーツの倉庫としての役割をさせる。
素材を分かりやすく管理する倉庫としてのFlashは実に優秀。
それで、Flash(main.fla)でSWCとして書き出しすると、
作った全ての素材が1パックになったファイルが1つできる。
開発者的に言えば、クラス定義が沢山書いてあるライブラリができましたってことになる。
そして、全てのスクリプトは後述するFlexBuilderでやる。ちょっとの量の場合でも。
Flashは単に素材をグラフィカルに配置してパーツを作ってただ管理するだけの役割に撤すること。
Flash上でちょっとでもスクリプト書くと管理が全く効かなくなってわけがわからなくなるので絶対書かない。
アニメーションをつけるにしても、スクリプトは書かないこと。(せいぜいstop()とかくらい)
●FlexBuilderの役割
さて、メインでActionScriptを書くのはFlexBuilderです。
(FlexBuilderのかわりにFlashDevelopとか使ってもOK。使った事無いのでFBとの差分とかあんまりわかりませんが。)
画面はこんな感じです。

ここで重要なところを2つ。
●1つめ、LIbsフォルダにライブラリパスを通しておくこと。([プロジェクト]-[プロパティ]-[ActionScriptビルドパス]かな)
●2つめ、Progressionのサイトから落としてきたProgression.swcをLIbsファイルに入れておくこと。(図参照)
あとはASファイルを好き勝手にがんがん作って行けばいいのですが、
そこで使う画像素材などのパーツは、上で書いたパーツ作成用のFlaファイル、
main.fla(仮)で書き出ししたSWCにすべて入っていますので、
それを、Libsフォルダの中に入れておけば、FlexBuilderでAS書く時に、
普通にSWCの中の素材についているリンケージ名(クラス名)でnewする形で使えます。
ここまで見てもらうと、
グラフィカルな作業はFlashでやり、
動きをつけたり実際の構造を作るのはFlexBuilder(ActionScript)で作成するという
分担を可能な限りやろうとしているのはわかってもらえるかと思います。
こうしておくと、後から混乱しにくいんです。
●Flashの役割(その2)
で、FlexBuilderでコードを書き書きしたら、ここでFlash再登場。
最終的なコンパイル(パブリッシュ)をする役割です。
本当はコードを書いたらそのまんまFBでコンパイルをやれればいいのだけれど、
現状、progressionでプロジェクトを作り、FBで色々コード書いた後、
わざわざFlashに戻ってコンパイル(パブリッシュ)するという方法をとっています。
なぜかというと、
MXMLで画面の初期化とか読み込みとかそのへんを作る方法を
ちゃんと調べてやるのがしんどそうで、手をつけていないから。。。
つい、progressionがそこらへんを自動で設定してくれてるFlashでコンパイルしちゃってます。
どういう封に設定してくれてるのか確認してないほど、その辺触りたくないところです。。。
実際、このフローも結構めんどうなんですが、MacBookのExposeで
FlexBuilder – Flash間を素早く移動することができるのでギリギリ挫折せずに済んでます。
●流れをまとめると・・・
FlashでProgressionでプロジェクト作る
→FlexBuilderでプロジェクトソースコード丸ごと読み込み
→Flashで素材SWC作る
→FlexBuilderでSWC読み込み&ソース書き書き実装
→Flashでコンパイル(パブリッシュ)
の流れです。
●でも、本当はFlexBuilderでソース書いてそのままコンパイルしたい!
どなたか、今のFlashでprogression利用でパブリッシュした時に生成されるものと
ほぼ同じものが生成されるような、FlexBuilderでのMXMLの書き方とかプロジェクトの設定とか
教えてください。。。切実に。。。
そしたら開発のほとんどをFBでやって、Flashはパーツ倉庫の役割だけという理想の状態になれる…!依存するのはprogressionのSWCだけという状態になれます。
みなさま、ホントにお願いします。
次回は多分本当に「オブジェクト指向について」書く。
あ、今は完全に実装のところばっかり書いてますが、
きりのいいところまで行ったらコンセプトメイキングとか、
実装の前、もしくは実装しながら考える必要があることについても書きたいな。
ではまた次回。
■関連記事:
- Flashサイト開発日記#3 -オブジェクト指向-
- Flashサイト開発日記#1:「弧と花」の設計とProgression利用方法
- ActionScript3.0とC#とJavaについてオブジェクト指向の思想の違いを見る
- ActionScript3.0の表示は「深度」っていう概念ではないです。
- みっくみく
Flashサイト開発日記#1:「弧と花」の設計とProgression利用方法
- 2010-02-04 (木)
- ActionScript | Flash | Flashサイト開発日記
第一回!設計について!
といっても多分今日はまともな設計の話じゃなくて、
クラス図の紹介とフルフラッシュサイト「弧と花」でのProgressionの使い方について。めっちゃActionScript3.0とかオブジェクト指向な話になります。
一緒に実装力を鍛えたい方、これから勉強してみようか、という方もよろしくどうぞ!
出来る方にとっては、必ずしも良い設計になってないところも多々あるかと
思いますがその時は指摘もらえるとうれしいです。
まずは下の図を見てもらえるといいかと。
「弧と花」のサイト、今はこのようになってます。

なんだよこの図は!よくわからねえよ!って人もいるかもしれませんが、
一応これが「クラス図」というものになります。
分かる人は、この絵を見ただけで私のおおよその意図はわかってもらえると
思います。
クラス図って開発者にとっては、そのくらいの威力をもった道具です。
私は結構柔軟に使いますので実際は「クラス図っぽいの」くらいになってますけどね。
(ああああ、クラス名が微妙なところが多くて直したいところですが、恥を忍んで公開する…!)
図の見方をざっくり簡単に説明すると、
・四角いオブジェクトは「クラス」
・フォルダの形のオブジェクトは「パッケージ」
・通常矢印は指した先のクラスを「使う」
・白三角矢印は指した先のクラスを「継承する」
・ひし形から出た矢印は指した先のクラスを「持つ」
とだいたいそんな感じの理解でOKです。
それだけ押さえてもらえればこの図の意味は大体ふわっと理解できます(笑
細かいちゃんとした意味について興味がある方は「UML クラス図」とかで
調べてみてくださいね。
で、ざっくりと各クラスのブロックが担っていることとその意図について
書いて行こうと思うんですが、今日はほんとに導入のところだけ。
どうやって絵を出すところまで行ってるかについて。

この図の、左側の赤い線で囲んだ部分について説明します。
実はここは、「Progression」を使っているだけです(笑
Progressionは一定のFlashサイトを作成することをものすごく楽にするフレームワークです。
まあ、イメージとしてはすでに便利に作って頂いているパーツを張り合わせるだけでFlashサイトができちゃうぜ!という感じ。
使い方のスタイルは3種類ほどあるみたいですが、私は色々自由にやりたいので一番プログラミング寄りな「ActionScriptのクラススタイル」で使っています。
で、私は「それでProgression使ってるって言えるのか!?」って怒られてしまいそうな使い方をしてるんですが、設計上、赤い線で囲んだ部分しか使ってません。
ファイル構成は基本的には
・preloader.swf
・メインのswf
の2つだけです。
順番に離すと、まずHTMLにPreloader.swfを読み込んで、Preloaderがメインのswfをロードしてくれて、IndexSceneを作る、というところまでほとんど自動でやってくれます。
図で言えば、Preloaderがまず呼ばれて、メインのswfが読み込まれたら、その中にあるIndexSceneというクラスのオブジェクトが作られます。そして、IndexSceneが最初にやる処理に、SceneOjectとしてEntranceScene(玄関シーン)というオブジェクトを作る処理を書いておけば、まず玄関シーンが表示されます。
はい、Progression、設計上はここまでしか使ってません!(笑
その後は、EntranceSceneの上に自分で勝手に作ったものを好きなようにばしばし乗っけて表示していくだけです。
EntranceSceneのかわりに、図の中でEntranceSceneと同じようにぶら下がっているKyakumaScene(客間)やNiwaScene(庭)などを表示させてもOKです。
実際はこれらはまだ実装できてないんですけどね。
Progressionの今の使い方は、イメージ的にはこんな感じ。
(preloaderでメインページを作って、シーン表示用のクラスを作ったら、その上に自分の好きなものをトッピングしていくイメージ。)

図で見て分かるとおり、サイトのベースの部分にだけ使わせてもらっています。
あんまり使ってないように見えますが、実は私がProgressionをベースに使う理由は全体の設計ではなく、それ以外の部分がめっちゃ楽になるからなんです。
例えば、Flashでコンパイルするだけで、
swfをHTML上に埋め込んで表示するためのjavascriptやらindex.htmlの用意を
勝手にやっておいてくれるところだとか、stageの初期設定なんかも簡単にやっといてくれるところとか!
地味にめんどくさい作業を全部やらなくてすみます。
まさに「作りたいところだけ作る」。ありがとうございます。
Progression3で不満だったのはpreloaderが1つのファイルしか読み込めないところ。
最初に初期設定を書いたXMLとか、外部に置いた画像やらフォントやらを読み込みたいことはあると思うのですが、それができません。
ただ、次のProgression4で複数ファイルをロードできるようになるらしいので、そこにとても期待です。
今、Progressionのオブジェクトにほとんど依存していないので、バージョンアップがかかったとしてもすんなり移行できるだろうなと思って(期待して)います。
さて、「弧と花」のベースの部分はProgressionを使っているよというのを
説明したところで、今日はおしまい。
次回はオブジェクト指向のいいところについて書こうかな。
「弧と花」は趣味で、「持続的に拡張して行きたい」のですが、そこで
重要になってくるのがオブジェクト指向です。
では、次回の設計開発日記にて!ノシ
■関連記事:
ころもやのサイト「弧と花」オープンしました。
- 2010-01-28 (木)
- 通常日記
とても久しぶりにサイトをリニューアルしました。
やっと、やりたいことをやるためのベースとなるサイトになりました。
「弧と花」http://www.kogetsujin.info/
Flashで作っていて、ほぼ全てをActionScript3.0で作成しています。
今は、3種類の天気のシーンを用意していて、トップページにアクセスした時に、晴れ、雨、雪の3種類のうち1つがランダムに表示されます。
今後は実際アクセスした時の季節や天気、時間に応じて変化していくようにしたいなあと思ってます。
実はまだ作りがまずい部分も結構あるんですが、今後の課題とします。。。
大きな目的は、日本の、ものを見る時の感覚や認識について探って行くことです。それを、建築やしつらいを含めた、わたしが「いいなぁ」と感じることを表現することを通してやっていこうと思います。
それをやろうと思った理由は、建築やら生活文化みたいなものを勉強して、ものの見方とか、ベースとなっている考え方をちゃんと分かりたいということが1つ。
それとわたしも日本人ですから、自分が何かを見た時に思ったこととか、想像したことの中にもそういうベースがあるはずだと思ってそれをはっきり見える形にしたいというのが1つ。
「方法を探す」ことと「表現に落とす」ことを同時にやっていきたいなーと思っています。
というのがかっこいい方の言い方で(笑)、
同時に、「わたしには景色がこう見えている」をたっぷり描くためのサイトです。
今まで、絵を描くことを表面的にしかやってこなくてかっこわるいなあと思っていたので、自分が表現する意味をしっかりと練るための場所が欲しいなあと思っていて、もうそれを公開しながらできるようにしようと考えて、こういう形になりました。
絵を描いて、ギャラリーやworksとして展示する形では自分のやりたいことはできないなと考えた結果、こういう形でサイト自体で表現していくのがいいんじゃないかということになりました。
今後は、このブログではサイトの更新や意図、設計(ついでにオブジェクト指向とかデザインパターンについてもやろうかな)とかについてここで詳しく解説していくようにしたり、サイト作る時に気づいたFlash&ActionScript3.0で作って行った中でのTIPSみたいなものを書いたりしようかなーと思っています。
よろしくどうぞ!
■関連記事:
コップ使わなくても口がすすげる歯ブラシ
あー、これ、面白いね。
確かに、あるある。
歯磨きの時、あんまりコップ使いたくないから蛇口から出る水に
直接口を持っていって水含んだりとか、
手ですくって含んだりとかするね。
歯磨きに必要な一連の動作を1つの道具で完結できるのはとても大きいです。
実にデザイン思考。見てて気持ちいいです。まだプロトタイプだけど。
小学校の時に運動の後良く飲んでたウォータークーラーを思い出したよ。
via GIGAZINE
■関連記事:
- Googleの携帯用オープンプラットフォーム「Android」
- Adobe MAX Japan 2009 – 川上俊さん
- セカンドネイチャー展に行った。
- wordpress ME2.2.3→2.5.1→2.6.3→2.6.1にアップグレード&ダウングレード
- お買い物
VOCALOID絵アップ「ミク・レン・リン・ルカ」
- 2009-12-19 (土)
- 落書き
クリプトン系VOCALOIDの4人を描いてみました。
音源てことを意識してデザイン。
ちょっとずつ絵が変わってきたけど、
次から意識的に、劇的に絵を変化させていこうと思う。
意図的に方向修正をして進んでいきたいと思うよ。
pixivに上げたやつはさすがにでかすぎた・・・。
ここにあるやつは多分見やすいかと。。

それでもでかいの見たいって方はpixivへどうぞ。
(その時はついでに評価ぽちってもらえるとうれしいですとても)
■関連記事:
VOCALOID [miki]の動画で絵描かせてもらいました
- 2009-12-06 (日)
- 通常日記
AetherのEruさんが12/4日に発売されたmikiを使って、そっこーで動画を作るとのことで絵を描かせてもらいました。
ニコニコ動画で先程(12/6午前)アップされましたので、よろしくどうぞー!
「fragile snow」P∴Rhythmatiq
使用した絵をpixivにも上げました-。
mikiのオリジナルの絵はコザキユースケさん。
大学の時に、サイトにあるGIFアニメをめちゃめちゃ見てました。
■関連記事:
アップルの中心デザイナー、ジョナサン・アイブの考え
- 2009-11-15 (日)
- デザイン
アップルのデザイナー、ジョナサン・アイブはiMacとかもろもろ中心で手がけている人です。
その彼が、Gary Hustwit監督の最新作映画『Objectified』で語るそうで、そのインタビューの動画が公開されていました。
(情報元記事:Gizmodoさん)
それがこの動画なのですが、よく考えているデザイナの言葉はやっぱりかっこいい。
とても心に突き刺さってくる言葉。
しかも、特にデザイナじゃなくても同じように重要なことなのでこの動画は見ておいて損はないかと。
4:46:
「物のデザインではなく考察の積み重ね。何が重要で何が重要でないか、そのヒエラルキーを見極める作業が大事」
(Gizmodoさんから引用)
これを真に考え、さらにそれをモノに落とすまで妥協せずに、ブレさせずに実現することがどれだけ難しい事か…!(特に企業の中で)
出来ている人の言葉だからこそ意味がありますね。心に刻んでおくことにします。
——-
さて、今日言いたかったことは以上でほぼ終わり。
映画はアメリカで春に公開されていて、
日本では公開未定だそうです。
以下は予告編ムービー。
最後から2番目のジョナサン・アイブの笑顔の超いいこと!
もの作るの好きなんだなっていうのが超伝わってきます(笑
最後の深沢直人さんの「ほらね?」っていう感じのいつものニヤリ顔もいいですけど!w
——–
それと、今作「Objectified」ではものづくりとプロダクトデザイナーに焦点をあてる作品ですが、
前作「Helvetica」は世界で最も有名な書体と言っていいHelveticaをテーマにして、
グラフィックデザイナーに焦点を当てる作品で、そっちの評価も高かったみたい。
本屋さんで見たことはあったけど、買うまでに至ってなかった。
でも上の動画みたら、ついアマゾンでポチッと押してしまった(笑
もちろん「Objectified」のDVDも押しちゃったのはいわずもがな、
もう日本語字幕とか待ちきれずに英語字幕でがんばって見るよ…!
(リージョン1のDVDなのでちょっと手間かかるかもだけど。)
届いたら、Helveticaの方も、英語の勉強を兼ねて英語字幕で見ようと思う。
興味のあることをテーマにして勉強するのが一番だと思うので。


