take3000アンオフィシャルブログ「たけはらですが？」

Web Memo 20120128

2012-01-28T18:29:00.000+09:00

今日は気になるエントリーが多かったので、おためしでまとめてみましたよっと。

”RAYMOND CAMDEN'S BLOG”
PhoneGap RSS Reader

PhoneGap RSS Reader - Part 2

PhoneGap RSS Reader - Part 3

A database utility class for PhoneGap

New Adobe Inspire Magazine out (with an article by yours truly...)

PhoneGap 記事の嵐。モバイルアプリ開発なんちゃら（フレームワーク、ライブラリ、その他）はいっぱいありますね。おっかけるの大変ですね。選ぶのも大変そうですね。

”LukeW Ideation + Design”
Apple's Numbers in January 2012
Appleのプロダクトがどんだけ普及しているのかがわかるリンク。ソースが全部TC（いいのかわるいのかわからんけど）

”The Space For App Developers”
HTML5 for App Developers: Eclipse

HTML5 for App Developers: Debugger

HTML5+JavaScript コーディングをEclipseでやってー、デバッガーいれてーをビデオで説明。

”Adobe Labs”
Adobe Flash Player 11.2 Beta for Desktops

”Adobe AIR 3.2 Beta”

”Multi-threaded video decoding”がけっこーインパクトありそうな気がする。

”Crisp's Blog”
Great Retrospectives

これはイイこと書いてあるわー！

多分ね。

マーケターのひとりごと

2012-01-17T16:55:00.000+09:00

エンジニアに記事執筆を依頼したり、セミナーの講師をやってもらうことで、その人の市場価値は上がると思います。
そして組織が人で構成されている以上、そこにいる人の市場価値の向上は組織の市場価値の向上に繋がります。
エンジニアの会社に属する非エンジニアである私ができる組織への貢献の一つのやり方です。

多分ね。

道

2012-01-06T02:00:00.000+09:00

私が歩いている道はかつて誰かが歩いた道でありいつか誰かが歩く道。
そう思ったら大概の事は腹が立たない。
むしろ謙虚であるべきと思える。

そんなことに気がついた今日この頃。

この気づきによりまた大人になった！と思う反面、こういうエントリーを書くあたり厨二病って治らないことも気づく。

多分ね。

【備忘録】2012年の目標や方針

2012-01-04T12:01:00.000+09:00

一応メモっときますよ。

その１：狙って三振を取れる投手になる！
ソフトボールの話です。そのためにはコントロールをよくしないとね。ボールボールだとそもそも振ってくれんし。

その２：とりあえず風邪を治す！
ぜんぜん治らん…。歳？　歳か？　歳のせいか！？

その３：月１以上のペースで記事を書く！
インプットを増やしたければアウトプットを増やせっていうのはよく言うけど、アウトプットを増やすにはインプットの速度を上げることも大事だよね。そしてインプットとアウトプットのサイクルを確立できる人は長くやっていけるのだろうし、そのサイクルが確立できない人がいわゆる一発屋だし、そもそもアウトプットをしないことには人生が前に進んでいかんのです。

その４：痩せる！
「太った？」「貫禄でたね？」「おいどうした！何があった！？」とか言われすぎるので、そろそろ痩せる。

その５：サイクロンをどうにかする！
手前味噌だけどサイクロンはとてもよく出来たスキームだと思う。そして多くの可能性をもっていると思う。なるべく多くの人を巻き込んでいきたい。これは開発者、開発会社だけではなく多くの業種・業界の人達とやっていきたい。そのための手段は全然ないんですががががー。

その６：乱読再開
去年は洋書を読もうとか目の前の仕事等々に入れこみすぎて読書量を減らしてしまった。今年は隙間の時間や移動時間は読書につぎ込む。今日・明日の仕事のために貴重な読書時間を削ることは一切やらない。

その７：卒園アルバム
うっかり引き受けてしまった卒園アルバム制作をしっかりやりきる。しかし、私、デザイナーじゃないんだけどな…。

その８：怒らない
今年は仏のタケハラさんでいきますよ。

多分ね。

【追記】
その９：「システム開発が上手くなった」を共有する何か
　どうやるかはだいたい考えてあるので、あとは声がけと日程調整だけ…。

何故「勉強会アワード」なのか

2011-12-31T11:58:00.001+09:00

アンケート「勉強会アワード2011」

照れ隠しのため「思いつきなんですがー」って説明しているのですが、実は動機はまじめです。

ここ数年をふりかえると、勉強会やセミナーなどのイベントが数多く開催されています。東京に限って言えばほぼ毎日2,3イベントがやっていて、週末もちょっとしたカンファレンスみたいなイベントが複数開催している。私の場合、こういった勉強会好きが高じて？もはや参加と運営が仕事の一部になっていて、2011年だけでも恐らく30回ぐらいは参加をしたと思います。これは若干特殊なケースだとしても、どこかのコミュニティに属していれば年10回ぐらいは参加しているでしょうし、コミュニティがライフワークになっているような人は週１ぐらいのペースで参加・運営したのかもしれません。
個人がどうしているかは置いておいて、2011年は相当数のイベント、そしてセッションが行われたのは間違いありません。

さてさて。
それだけ数多くのセッションのうち、みなさんが参加したのはいくつあるでしょうか？
そこからブログを書くなりしてなんらかの形で参加して得たことをアウトプットしたでしょうか？
参加したセッションのうちいくつかは、何らかの知識を得たり感動したりをしたと思うのですが、それを自身の行動や組織に対して反映をさせた方ってどれぐらいいらっしゃるでしょうか。
きっと何らかの形でそうしたことをしたのではないでしょうか。
もしかしたら同僚たちに、自分が得た感動を熱っぽく語ったのかもしれません。若干ひかれつつ（笑）。でもそれはスゴイ良いことですよね。
そんな感情の動きの少しでいいから、より多くの人と共有出来れば良いなと思いました。それがイベントを運営している人達や、セッションでスピーカーをした人に伝われば、なんだか御礼を言ったような気になって双方にとって良い経験になると思うのです。

そして今回のアンケートは「一つだけ選ぶ」という縛りを設けました。
多くのイベントやセッションの中から一つを選ぶのはしんどいと思います。私もしんどかった。しかし、ひとつしか選べないからこそ、真剣になってふりかえると思うのです。どのイベントが、どのセッションが自分に最も影響を与えたのか。あるいは感動をしたのか。多くのイベントに参加したり主催したりすると一つ一つの記憶が薄くなるかもしれません。だったら、年に一度くらい、真剣にふりかえって自分自身に起きた変化の起点をみつめるのは意義があると思うのです（変化せんかったよという人もいるかもですが）。

人によっては脳天気なことしてやがるなーと思うのかもしれません。
しかし、私はいたって真面目。
ふりかえりを真剣にすることで、その真剣さを2012年に持って行きたい。そして「勉強会楽しかったね」から「勉強会で得た知識や感動で、自分や周囲を変えていきたい」といった流れが数多く生まれたら良いなー、と思っています。

しかしそんな大げさな話はおいといて、運営したり喋った人に感謝の気持ちが伝えるひとつの機会になればいいなー、というところです。

多分ね。

2012年の妄想

2011-12-25T11:43:00.000+09:00

以前から主張していますが、ソフトウェア（ないしシステム）の開発組織は旧来型の組織よりもプロスポーツチームをお手本にするべきだと思うし、2012年はおそらくそういった組織が増え始めるだろうし、結果として「スター・エンジニア（スター・デザイナー、スター・マネージャも可）」が現れ始めるのではないかと思います。今そういう人がいないかというといるんだけど、それとはちょっと違うイメージです。そういう人に注目が集まってプロ野球選手並に稼ぐ人が増える（どうやらすでにいるらしい）であろうと。
なんでそう思うかというと、技術の進化と市場の変化の高速化という要因で、組織的にどうこうというよりは、できる人にまるっとやってもらうほうがはるかに効率が良い。ビジネスの源泉に関わるような人に対して、相応の報酬を支払うのは当然だろうと。

　私達の身近なところでいうと、受託開発やっている会社はバーサタイルなエンジニアやデザイナーを数多く抱える会社が躍進していくだろうと。お客さまの抱えるプレッシャーは相当なものでしょうから、開発する側も悠長なスケジュールでやってたらお客さまの信頼を得ることはできません。そこで圧倒的なスキルを持っている「スター」が活躍するのではないだろうかと。スターとそうでない人はあらゆるところで差が着くのかもしれないけど、むしろその方が野望ゲージの高い人にとっては良いことかもしれません。

　スターな人はいずれ組織を旅立っていくのだと思います。もっと大きなビジネスをやるためだったり、あるいは違う組織の改革を期待されて。では残された組織はどうなるのか？　課題はあるのでしょうが、新しいスターを誕生させるような仕組みが作れるのが良いでしょう。それにはそういった素養をもった人を雇っていく必要があります。これをやっていくには２つのアプローチがあって、１．人事・採用が現場を理解して見どころのある人を一本釣りしてくる、のと２．組織が人に対してスターになることを奨励するような仕組みをもつことです。今は腕のよい技術者にとっては売り手市場です。であれば、自分の市場価値を高めることができる組織を選ぶのは当然ですし、「組織色に染まれ」「組織へ貢献しろ」なメッセージのゴリ押しは不毛なわけです。組織を利用して自分の「市場価値をめいっぱい上げてね！」くらいの方が双方良いのではないかと思います。

　したがって、自身の市場価値を向上できる組織でめいっぱい実績と経験を積んで自信がついたところでＦＡ宣言して更に良いステージで活躍するのが、これからのプロの働き方なんじゃないかと思います。

多分ね。

＠IT自分戦略研究所に記事を書いたよ「第1回　初心者のためのLT作成講座――まずは構成を練る」

2011-12-16T16:21:00.003+09:00

第1回　初心者のためのLT作成講座――まずは構成を練る

アットマークITさんにLTの記事を書きました。
「闇アジャイラー」ネタひっぱってすみません。本当にすみません。またかよって思いますよね。平身低頭心の底からすみません。

LTワークショップにしても今回の記事にしても、私のもっているプレゼンに関する手の内は基本的にはどんどん晒すつもりです。短期的にみたら私の話が飽きられやすくなって商売上がったりになったりする可能性を高めるわけですが、長期的に見たらこれらの情報を元にプレゼンスキルが向上する人が増えれば、いずれ私達にも良いことがあるのではないかと思うわけです。たとえそれが反面教師であったとしても！

さて、ちょっと考えてみて欲しいのです。みなさん、人にモノゴトを伝えることに自信がありますか？　共通の認識をちゃんと作れていますか？　できている顔している人でも立場や年かさに物言わせて「納得はしてませんが、理解はしてます(ｷﾘｯ」なやりとりをしていることはありませんか？

「納得感をもって過不足なく正しく伝える」は私自身もちゃんとできているわけではありません。しかし、それに拘りを持ち続け、伝える技術を向上させていくことは、ITのスキルを向上させたりマネジメントについて経験を積んだりするあらゆる専門的な技能と比べても遜色ないぐらい大事なことなのです。理解を得られなければどんなに素晴らしいアイデアであっても受け入れてもらえないのです。

どうやったら上手くできるかについては、私もこれだという結論には至っていません。いくつか気をつけていることを列挙すると、

つかみはばっちりか
ちゃんと一つのはなし
感情の振れ幅を演出しているか
どのように理解されるかを考えたか
練習したか

になります。しかしこれらのTIPSですら、人、聞いてくれるお客さんによってどのように扱うかが変わってきます。難しいですね。

私は私自身の経験から得た「伝える技術」を伝えることで、人様のお役に立てれば是幸と思っています。

多分ね。

Effective 情報発信

2011-12-16T13:04:00.001+09:00

このブログは4年やって200エントリー書いてトータルビュー数が12,000に届かないぐらい。
Slideshareは2年で25のスライドを公開してビュー数が24,000超。

これだけ見ると、Slideshareの方が圧倒的に効率が良いね。

しかし私の場合、Slideshareにアップするスライドの制作はかなり時間をかけて作っており、最近にいたっては1点数千円の画像も購入していたりするので、あらゆる意味でコストがかかっている。コンテンツもなるべく見てもらえるように工夫しているし、資料性も意識しているので、ある程度は見てもらえるようにはなっているはず。
ブログの方は脳漿だだ漏れみたいなヘロヘロ文章を思いついたときに書いているだけなので負担まったくなし。ただしアウトプットからのインパクトみたいなものもほぼなし。

Twitter のフォロワーは1,100人を超えているけど、TwitterでSlideshareのリンクをつぶやいても、実際にクリックしてスライドを見てくれる人は100人ぐらい（50－500ぐらいの振れ幅がある）。ということはTwitterは90%くらいの人は見ていないのかもしれない。

スピーカーとして人前でしゃべる場合、これはわりとちゃんと聞いてもらえる。前から見ていると80%くらいの人はちゃんと聴いている。しかし1－2割は確実に聞いていない。お客さんをつかめなかった場合は半分くらいは聞いていない。つかみ大事。これはLTであろうと長いセッションであろうと変わらない。

セッション動画はビュー数はかなり少ない。私のセッション動画で最も閲覧されたものは、同じ題材のSlideshareの10分の1もない。そして何故かdisられる率が高いｗわらかんでもないけど。

いずれの手段もやらないよりはやる方が良いだろうし、類まれなる文才があればブログのビュー数は笑いがとまらないぐらい上がると思う。

しかし、個人的には、私のマーケティングにおけるプリンシプルは「現地・現人・現物」主義であり、それを定量化するのは無理そう（ていうかやりたくない）だけど、やはり直接、人とやり取りをする方がなんだかんだで言いたいことをちゃんと伝えられる近道なんではないかと思う。だから社内外問わず、コミュニティに参加して人の話を聞いて、自分の考えを伝えるっていうの良いことですよ。

多分ね。

就活生の金太郎飴状態に原因は他にあるのではないかと思う

2011-12-14T19:17:00.001+09:00

「今年を振り返ると非常に多くの経験ができてとても良い年だった」と個人的には思うのだけど、その反面、私が関わっているモノゴトが次々とオワコン認定をいただき（受託、Flash、LT）来年はどうなっちゃうんだろうと今から不安に思ったりもします。

　そんな来年というか、今年というかちょいちょい就活生の見た目の金太郎飴ぶりが話題になって、可哀想、特徴がない、日本の教育がー、な展開をするわけですが、思うに、学生も全然アホではなく、むしろ私が学生だった時よりも今の学生のほうがシビアな世の中に接しているためかとても大人だししっかりしている（もちろんしていないヤツもいるが、そんなのはいつの世にもいる）。

　彼らは彼らなりに情報収集をし、傾向と対策をしっかり立てた結果があの金太郎飴ファッションだと思うのです。なぜそのように思うのかといえば、採用面接をやっている人達っていったい何を判断基準にして彼らを合否を判断しているのでしょうか？　本当に人の見た目に惑わされずに、その人の個性やら仕事への適正やらを判断できるているの？　そう思うと甚だ疑問で、ファッションみたいなところは安牌をチョイスして、中身で勝負できるのならラッキーだけど、あとは筆記試験やら面接時の卒のない受け答えとかそんなところで勝負していくしかないのだろうと。もちろん、金太郎飴ファッションをしていくということは、ある意味、TPOを考えた服装をチョイスできる最低限の空気を読む能力のアピールでもあるわけだから、そんなに悪いことではないと思うわけです。

　ところで人事系の人って、その企業の中長期に渡る戦略やらなにやらを握っているにもかかわらず、どうして各会社の現業から遠い「人事専門の人」がやっているのでしょうか？　専門外の彼らに任せるから、スーツの色がどうこうで判断される危険性が発生し、学生たちを金太郎飴にしているのではないのでしょうか？いまから現業の専門外である人事の専門家に現業も専門家たれ！といってもそれは無理でしょう。でもね、無理なら無理で、せめて興味ぐらいもてよ、と思うわけです。私らの業界だったら、ジョエル・スポルスキーさんの「ソフトウェア開発者採用ガイド」ぐらい読んだっていいじゃない、と思うわけです。現場や現業に対して正しく興味をもつことでアプローチに仕方は変わるだろうし、得られる結果も大いに変わるはずです。

多分ね。

DevLOVE ADVENT CALENDAR に記事を書きました

2011-12-13T11:24:00.002+09:00

DevLOVE ADVENT CALENDAR 【9日目】2012年につなげる帆

今年は皆様のおかげでいろいろな経験を積むことが出来ました。どうもありがとうございます。

「これからはモバイルでデスクトップはオワコン」みたいな主張に思うこと

2011-12-06T01:29:00.001+09:00

これなんか見て思うのだけれど、全体の割合から見たら増えているんだろうけど、全体の数で見たらどうなんだろう？モバイルからのトラフィックがものすごい伸びているけど、実はデスクトップも地味に増えている、ということはなんだろうか？世界全体で見たら、インターネットにつながるパソコンもっている人よりはもっていない人の方が圧倒的に多いでしょ。それに対してネットワークインフラってあとどれくらいのトラフィック増加に耐えられるのだろう？特にモバイル。各キャリアが従量課金へのシフトに伏線を貼らざるを得ない状況を考えるとうーん…と思ってしまう。

多分ね。

「起きたことはすべて正しい」

2011-11-24T20:38:00.003+09:00

「起きていることはすべて正しい」の本は読んでないけど、「起きたことはすべて正しい」は疑いようがないよな。事実であるという意味では。

不景気も震災も放射能漏れも特定の誰かのせいにすることは無理だと思うけど、事象としてそこには存在している。それを否定したり理由を考えたり犯人を探したり…、やるなとは言わないけどどこかの段階でそれは大事な事ではなくなって、今、目の前の状況に対してどうするか、未来をどう作っていくかが大事なんでしょう。抗いようのないことに巻き込まれたとしても、その都度、考えて動いていくことが大事じゃないのかな？

起きている事象、自身が置かれた状況が、過去の自分自身の選択の連続がそれをもたらしたのだとしたら、そんなことを愚痴ることに何の意味があるのだろう？　それは他人からの同情を期待したただの自己保身のための言い訳じゃないのか。

「起きたことはすべて正しい」
目の前の事象を直視できないんだったら、いつまでたっても変わらない。むしろ悪化する。ジリ貧になる。

ユリウス・カエサルの言葉に有名なのがあるね。

「人間ならば誰にでも、現実のすべてが見えるわけではない。多くの人は、見たいと欲する現実しか見ていない。」

厳しい現実を直視することから始まると思うよ。

多分ね。

そういえばさ

2011-11-22T20:05:00.000+09:00

オフィシャルブログってよく見かけるけど、そこで言うオフィシャルってなんぞ？

反省

2011-11-22T11:36:00.003+09:00

先月あたりからデスブログ的な能力を開花させつつあり、反省の意味を込めてブログタイトルをあらためました。
きっかけはfacebookのやりとり

・わたし

Flash はまだまだイケるよ！なレポートを書く　→　モバイル向けFP終了のおしらせ
2012年はAmazonがスゴイことになるよ　→　Kindle Fire が不評

しばらく何も言わないほうがいいのか。。。

・頂戴したコメント

take3000オフィシャルブログ『たけはらですが？』

デスブロガー？

◯原さんと呼ばせていただきます!!

逆にこれは考え方によっては有効利用する手立てもあるのでは…

ブログのタイトルに「虚構」と付ければ解決？

終わりを告げるなんとかかんとか・・・ｗ

これでL-1チャンプに次ぐ、新しい称号を得ましたね！おめでとうございますw

年内はこれで行くと思います。

多分ね。

ツールがサブスクリプションになる件について一言いっておくか（妄想）

2011-11-18T22:21:00.003+09:00

その時々にあう必要最小限の機能を実装したツールを使うことになるでしょ。
ツールベンダーはぼんぼん新しいツールをだすわけですよ。
過去作ったものは過去のニーズにあわせて作っているんであって、それを無理やり今や未来に適用しつづけるのはしんどいでしょ。
だからサクサク新しいの作る。

それを実現するには、パッケージ販売じゃだめ。むり。おっつかない。ていうかユーザーに殺される。
でもサブスクリプションで対象製品を増やしていくなら、あら不思議、新しいツール使っても追加料金かからないのねウヒョー。となる。

この施策が成功すれば、ソフトウェアのライフサイクルは大きく変わると思うし、ツールベンダーの戦略も当然変わる。

多分ね。

この戦略を上手く回すにはUXが重要になります。
「やりたいことがなるべくすぐできるツール」が重宝されます。
「クリエイターのクリエイティビティを殺さない（揮発させない）」ことが重要です。

多分ね。

きっとエンジニアにはこれまで以上に、無限の住人の卍さんみたいな器用さが求められるんですよ。

多分ね。

※もちろん、そういう早いライフサイクルが向かない製品もある

セミナーの告知が完了

2011-11-18T20:51:00.003+09:00

セミナーの告知が終わって一段落。
セッション一つと対談コーナーのコーディネートもあるから、こっからが大変なんだけど。
あと司会進行か（苦い笑い）

今回、私たちが掲げたテーマはすごい難しいものだと思う。いろんな意味で。
いろいろ心配。そして早くも胃が痛い。
（モヒカンな人がだまっちゃいないだろうとかねｗ）

でもそろそろ、自分たちの世界から飛び出て、本当の勝負をしなくちゃいけならないんじゃないかという気がしているんだな。

コミュニティで出会った仲間と一緒に新しい何かに（特に仕事で）挑戦するっていうのは、コミュニティに対する最大の奉仕じゃないかと思う。
そして正方向の大きな因果ループが回りだすきっかけにしたいと思う。
（それは継続することが一番大事なんだけど）

もし、よかったら、私たちの新しい取り組みにご賛同いただけましたら、ご来場いただくか、お友達にオススメするか、もしくはつぶやくか何かしていただけるととても嬉しいです。
http://classmethod.jp/seminar/eiwa-cm-seminer/

話は変わって「オススメの本を一冊おしえて」といった主旨の企画があって（わざとぼかしてます）
「今の私が選ぶなら」というところを軸足にしたら真っ先に「リーン開発の本質」が思い浮かびました。
Agile Japan 2009 で基調講演をされたメアリー・ポッペンディークさんが書かれた本で、たまたま前の方に座った私は図々しくもメアリーさんを初めとするスピーカーの方達からサインを貰ったのでした。その時のサインがこちら。

人生って不思議ですね。しみじみ。

レポートにまつわるエトセトラ

2011-11-01T18:22:00.003+09:00

11月1日、私の書いた Adobe MAX のレポート記事が CodeZine に掲載されました。

【Adobe MAX 2011】Flashは死んでしまうのか？

なんであのセッションを選んだのかーとか、それをするにいたった背景などもこっちに書いておこうかと。
あのレポートを読んだ方はなんてくだけた記事なんだろうと思ったかもしれませんが、脱稿前はもっとくだけた記事だったのでした。あと翔泳社さんに送るにあたり、さすがにそれはまずかろうという箇所もカットしたので、そのあたりもこっちに載せておきます。

■背景
本来、この時間帯は"Flex, Ruby on Rails, and the Cloud"というセッションを受講する予定でした。Ruby って案件数がかなり増えてきたし、技術者に人気あるし、日経新聞あたりに「ツイッターはオープンソースソフトウェアのルビーでできている」云々と紹介されたりするわけで、今後、Flex + Ruby はかなり来るでしょう！と。それにクラウドなんて言ったらもう時代の寵児じゃないですか！と。「乗るしか無いだろこのビッグウェーブに！」なわけですよ。
しかし、Adobe MAX のプログラムは非情です。同じ時間帯に"Flex and EnterPrize Java"なんていう、RIAで受託で業務システム野郎なら是非とも聞いておきたいセッションとかぶっています。ある意味、Ruby vs Java。それなんて~~エロゲ~~踏み絵？結構な時間をかけて悩んで出した結論は Ruby でした。まー、Java の方は一緒に行く他の人達が受講するよね、と。だから涙を飲んで Ruby なわけです。ビッグウェーブ乗らなきゃー！
それからしばらくして、MAX野郎のページ（http://www.adobe.com/jp/joc/max2011/team/）に私が受講する予定のセッションが載ったのですが、あれ？ Flex, Ruby on Rails, and the Cloud"はリンク切れてるよ？公式から姿を消してるよ？あれ中止？なにこれ？
運営側でどのようなドラマがあったかは存じませんが、とりあえず油を売るわけにも行かないので別のセッションを選びます。そうしたらふと目に止まった"The Death of Flash"。なんか「闇」に通じるものがあるじゃないですか。そんなわけでシンパシーを感じた私はこのセッションを選んだのでした。はあ、前置き長かった(笑)。

この相当キテいる"The Death of Flash"というネーミングですが、ここのところ続く「Flash＼(^o^)／」なニュースに対するとても冷静なメッセージがあると思いました。私も思うんですけど、巷にあふれる「Flash＼(^o^)／」ニュースのほとんどって「＼(^o^)／」って言いたいだけなんじゃないかと思います。Adobe もちゃんと Flash テクノロジーに拘り続ける技術者に対してちゃんとロイヤリティがあるようにロードマップを描いているように思えるし（たとえゆるやかに HTML5 ＋ Javascript の時代に推移していくのだとしても）。Adobe びいきコメントが多くてアレですが。各ブラウザベンダーさんは本当にデベロッパーとユーザーのことを思っているのかな。HTML5 + Javascript の世界はしんどいはずだし、デベロッパーのしんどいは確実にユーザーにも影響をもたらすからね。どうもこの辺りはモヤモヤしますな（識者による有効回答求む）。

実際、どんなセッションであったのかは「翔泳社さんの CodeZine 」をご覧いただくとして、セッションレポートであるがゆえに記事には書かなかったことを補足しますか。

・世間に流れる情報量の多さがモノゴトの正しさを決めるわけではない
Flash＼(^o^)／の情報、多いですよね。きっかけはやはりあの会社のあのガジェットに Flash なんか載せるもんか一昨日きやがれー！なあの発表が原因だったのだと思います。あの発表のインパクトって相当なもんで、IT業界で働いていても RIA とかかわりが少ない人は今でも「Flash って、iPhone じゃ動かないんでしょ（ダサッ）」な反応するわけです。「おい、ちょっと待てよ！」って言いたいですよね。動かないのは（サポートされない）Flash Player であって、Flash Builder および、Flash Professional で作られた Flash のアプリは iOS 端末上で動作するわけだし。でも、あの発表のインパクトに比べたらそんな情報は小さくて多くの人の耳にはいっていないのです。なんと残念。
しかしそれ以降、なぜか Flash を嫌う人達は語調を強めてもはやいいがかりに近い Flash 批判を展開するわけです。本当に「おい、ちょっと待てよ！」と言いたい。おまえら Flash の欠点ばっかり言うてるけど、代替技術はどれよ？それは Flash の欠点をカバーできてんのかよ？本当に代替足りえるモノだと思ってんのかよ？と。
しかし人間というのは「多い情報」に流れちゃうものです。論理的に破綻をしていても、大量にばらまかれる情報は正しく見えちゃうものです。そしてビジネスやマーケティングに関わる人達はそれを知っています。しっかり調べ込んだ論理的で適切な解説をした記事より、間違っていてもキャッチーでライトな記事を大量にばらまく方が影響力が強いのです。

・最強のマーケティング戦略「ダサいと決め付ける」
自分たちの製品やサービスの良いところをアピールするよりも、競合について「ダサい」と思わせる方が効果があります。モラル的にどうかと思いますが。。。理由はなんでも良いのです。最終的に「ダサい」と思わせるようなところに帰結するだけ。この戦略は根拠がいい加減でも有効です。前述のキャッチーでライトな記事と組み合わせて大量にばらまけばいいだけだから。単純ですが破壊力は抜群です。おかげで Flash は「iPhone に対応できない時代遅れの技術」のレッテルを貼られました。これの被害者は Flash だけではありません。他にはガラケー（フィーチャーフォン）。改めて考えると、ガラケーの何が悪いんでしょう？電池はちょーもちます。電波をキャッチするのも強いです。電話当然できます。メールできます。SMSは標準でついてます。インターネットもみられます。おサイフ機能ついてます。音楽も聴けます。たしかにGUI はダサいかもしれませんが、外観は個性があって（私はすきじゃないけど）機能的にも充分。ヘタすると電話ですらエラーで使えなくなるスマートフォンに比べてはるかに電話としての本分を全うしています。でも今後は減っていくのでしょう。なぜならダサいと決め付けられたから。キャリアもメーカーもガラケーをダサい存在にしてスマートフォンを売るほうがメリットがあるのでしょう。本当にそれでいいのかな？

・商売人の主張を真に受けるな
前述したようなやり方はビジネスやマーケティングに関わる人のやり方です。商売人の主張です（私もマーケティングやってますけど｝。しかし、いくらなんでも事実無根だったり、あまりにも極端な主張を繰り返して技術のトレンドを操作していくっていうのは、技術に対して不誠実だと思います。技術っていうのはそれを作り出す人がいるわけです。つまり技術に対して不誠実なのは、人に対して不誠実であることと変わりません。自分たちが一所懸命つくった技術が不当に「ダサい」とかいう扱いをうけて市場から締め出されたらどんな気持ちになるか。そんな目にあったらちょっとたまらんですよね。
繰り返しますが、技術に対して不誠実な人は、人に対しても不誠実です。

多分ね。

[備忘録]自分のタスク管理

2011-10-23T23:33:00.002+09:00

こまい仕事ばっかりやっていると、こまい仕事の集合に脳内リソースもってかれて生産性がえらい下がるので、それを防ぐためのタスク管理方法。ベースはかんばんだけど、ちょっとアレンジしています。

用意するもの
・ふせん
・ふせんはれるスペース

ふせんはれるスペースの準備
・次の5つに分ける
　１．ToDo
　２．Doing
　３．Done
　４．Pending
　５．Waiting

一般的なかんばんとの違いは下記
・Doingに入れる数は一つだけ！いまやっているタスクだけ入れる
・誰かの確認などを待たないと完了できないタスクは Waiting に入れる。
　Doing に入れた別のタスクが完了したら、ToDo にあるバックログを見る前に、
　Waiting を見る。Waiting タスクはなんで待ちなのかを書いておく。
・待ちではあるけれど、何か理由があってすすめることができないタスクは Pending に入れる
　（Pending はなしでもいけそうな気がするが…）
・ToDo に入れる時に日付を書く。Done に入れる時も日付を書く。

改善が必要なポイントは
・定常業務をどう扱うか
・サブタスクをどうするか
とかか。

でかいホワイトボードがほしいぜ！

HTML5、Flash、Native をそれぞれいつ使う？

2011-10-19T15:10:00.001+09:00

Ben Forta さん（Adobe の偉い人。髭クラスタ。Blog のエントリーは常に極めて短い）の Blog に「HTML5、Flash、Native をそれぞれいつ使う？」みたいなエントリーがあって、それは読まねばと思いクリックすると eWeeK へのリンクが貼ってあり、effectiveUI の人が作ったらしいスライドがありましたので紹介。

要点抜き出すと、
HTML5：ふつうのサイト作るには充分。よくあるようなビジネスアプリなら充分でしょ。
Flash：ハイエンドエンタテインメント、ビデオ再生、DRM には最適。
Adobe はこの両方をしっかりサポートしていくし、しているよ。（別エントリーでは同じくらい愛していると書かれている）
Native：速いアプリがつくれるよ
とのこと。

ちょっとひっかかる気がしなくもないけど、妥当な気もします。
例えば重要度の高い、エラーが起きると基調な資金を失う、人命に関わるようなビジネスアプリだったら、どっちの方が良いのでしょう？
やはり要求と採用する技術の特性のバランスを踏まえて選ぶ（組み合わせる）べきだと思うし、プロセスの部分も大切だと思います。そして、どこかの偉い人のビジネス都合、マーケティング都合の主張を真に受けて技術を選ぶのは良くないのだと思います。

多分ね。

節操ナッシング

2011-10-19T14:32:00.002+09:00

自分の Blog エントリーをみて思うのだけど、マネジメント、プレゼンテーション、コミュニティ、デザイン、クラウド、会社のプロモーション、契約、アジャイル、ファシリテーション、、、な感じでまとまりがないですね。
できればもうちょっと的を絞って活動したいと思う今日この頃だけど、器用貧乏を極めて黄金の小手先にもたどり着いてみたい気もする。
私にしてみれば必要に迫られて学習をしているので、仕方ないといえば仕方ないのだけど、まあ、なんというか。。

【ネタ】プレゼンの熟練度

2011-10-19T00:29:00.003+09:00

あらゆるモノゴトには熟練度や習熟度があってそれを基準にして自分（達）のレベルが如何ほどなのかを知ることが出来たりする。CMMIとか。
プレゼンテーションやスピーチにもそういうものがあっても良いと思う。というのも、プレゼンテーションに関するWebや書籍の記事を読んだり人からの話を聞いて思うことは、それはどのようなレベルの人を対象にしているのかが不明瞭なことが多いからだ。よって、その参考になればと思い書き始めたが早々につまづき完全にネタエントリーになった。正直今は反省している。

０．補助兵
補助兵は戦闘訓練を受けていないため戦場で生き残る基礎的な技術を身につけていない。よって普通に考えれば戦線に投入されることもない。
しかし古来より、戦わせてみたら思いのほか強かった例はあり、有史をたどれば、ジャンヌ・ダルク、ジュドー・アーシタなどがそれに該当する。ここで注意が必要なのだが、世間に広く知れ渡る偉業というのは、ある種の天才が時節を味方にし奇跡的なタイミングで事を為したからこそであり、誰でも知っている＝当たり前と勘違いをしてしまい自分たちでもできるのではないかと思えてくるが、当然、私たちのような凡人が真似できるわけではない。そう、現実はアニメじゃない。

１．足軽
足軽は一応、戦闘訓練を経て戦線に投入される。よって一般的なスライドウェアである Powerpoint もひと通り扱うことができる。戦法は至ってシンプルで、長槍に見立てたテキストをフォントサイズ20pt以下に研ぎ澄ませ、ひたすら箇条書きをそのまま読み上げて攻撃をする。箇条書きを8コ以上並べることはザラで、その箇条書きが3段にネストしていることすらある。これを専門用語で「箇条書き衾（かじょうがきぶすま）」と言う。
この箇条書き衾は運用が比較的に容易であり、とりあえず思いついたことや調べたことを貼って並べておけばいいので、お手軽に戦線投入できる。しかしその反面、攻撃パターンが単調で、読み上げている箇条書きを「先に客に読まれ」、話の展開を推測されやすい欠点がある。
今ではプレゼンテーション禅の影響もあって何かとDisられる足軽スタイルだが、持ち時間をしっかり使い切るだけでも立派なプレゼンターなのだ。戦場慣れしていない人はここから始めても全く問題ない。

２．弓兵
箇条書きを抜けだし、大きなフォントやインパクトのある画像を使う者を弓兵と言う。弓兵にもいろいろな種類がおり、パンチの効いた鏑矢のようなスライドを使う者もいれば、コマ送りかと言いたくなるようなスライドを使う者もいる。また「その画像、どこで探してきたの？」と言いたくなるような、とんでもない攻撃を繰り出す者もいるが、これは弩兵である。ちょっと仕組みが異なる。
良い弓兵は訓練を重視する。放つ弓の調達にも余念がない。そしてターゲットをよく観察している。己の弓の放つタイミングをよく心得ているものだ。
ここで注意が必要なのだが、腕前の良い弓兵はとても優雅にネタという矢を放っているように見えるが、訓練と経験によってそのレベルに達したのであり、決して楽はしていない。表面上だけ弓兵の真似をすると、放った弓が客に刺さらず「外す」事になる。外した弓兵の末路は悲惨で客の冷たい目線によって袈裟に切られるだけである。また、一の矢を外した場合、二の矢も当然外す確率が高くなるわけで装填した弓が重荷になることもある。

３．鉄砲兵
今のところ、鉄砲兵は少ない。稀少価値がある。その存在だけで目立つことだろう。どういった者が鉄砲兵に該当するのかというと、プレゼン中に通常は使わない動画などを見せてくる。動画は強力だ。音と映像の二本立てで客をびびらせることができる。これには弓兵では太刀打ちできない。
しかし鉄砲は運用が難しく、準備にも時間がかかる。オリジナルの動画を高品質で制作しようとすると高価なツールが必要になり、これを使いこなすのにもまた時間がかかる。そして鉄砲を扱っている間は基本的には何もできない。この間、ツッコミなど入れられようものなら黙って切られる以外術はない。また使用できる場が限定され、昼間に行うビジネスマン向けの湿っぽいイベントには向かない。火薬が湿気って効果が発揮されないのだ。一撃は強力ではあるが、運用が難しい。それが鉄砲兵の悩みである。
上手くやるコツは弓兵と共通する部分が多く、弓を放ち飽きた人はやってみると良いかもしれない。

４．騎馬隊
騎馬隊は縦横無尽である。客が椅子に座って低くなっていることをいい事に、づかづかと客席に入り込み微妙に高いところから接近戦をしかけてくる。しかし攻撃パターンは前述の3兵科のいずれかと同様になり、多くは槍を駆使するが、弓や鉄砲を使いこなす騎馬隊はかなりの手練だ。しかし戦場が足場が悪く「有線マイク」であったり、そもそも馬に相当する「リモコン」がないとどうにもならない。またリモコンは機種によって移動可能な距離が違うので要注意。さらにリモコンの電池切れとか、OSが認識しないとかもうね…。

５．大将
大将は理屈などいらない。「やあやあ我こそは…！」と名乗るだけで充分に人目を引きつける。なんせ大将なのだ。あえて言えば堂々としてれば大丈夫だろう。
ただし注意がある。大将の首が取られることは戦の負けを意味する。つまり、大将の戦闘スキル＝組織の戦闘スキルと思われることがあり、大将のプレゼンがコケれば組織ごとコケることもあり得るわけだ。
しかし一騎駆けの達人であるスティーブ・ジョブズのような大将の場合、むしろ組織の成長を大いに促進することもある。
よってプレゼンは重要だ。どこぞのJC（JKか？）に
「◯◯のスマートフォンをもっていればクラスで人気者になれる♪」
とか棒読みさせてる場合ではないのである。

多分ね。

プレゼンで使う画像の探し方について

2011-10-10T21:16:00.005+09:00

先日行われたLT祭りの後、参加された方より
「画像探しに使っているサイトを教えてくれ」
というご依頼をいただいたので、サイトと探し方をちょっとだけご紹介。

・素材図点
これは何でもいいと思うのですが、大したお金を出さなくても無難な画像をめいっぱい詰め込んだ素材集があると思います。
スライドがちょっと寂しいなというときはこういうのを使って見栄えを良くします。
（有償）

・Google検索
キーになる画像はGoogleで探すことが多いです。しかし著作権等々の制約が存在するので気をつけてください。せめて URL を貼りつけておくぐらいはしておくべきです。それと画質がまちまちなので、折角見つけたとおもっても画質が荒いのであればスパッと諦めちゃっていいと思います。
（無償？）
※追記。ものにもよりますが日本語よりも英語で検索する方が良い場合が多々あります

・Wikipedia
手堅く良い画像が入手できます。リンクをたどると画像の権利に関する情報が載ってます。基本的にはそれに従えばいいだけですし、ほとんどが”CC(クリエイティブ・コモンズ)”です。
（無償）

・プレゼンテーションzen で紹介されているサイト
プレゼンテーションzen に紹介されているサイトです。iStockPhoto は有名で良い画像がたくさんあります（有償）。フリー素材のサイトも充分に良い画像をゲットできます。画像点数がいっぱいあれば良いかというとそれは微妙で、少なめのサイトのほうがサクっと探せる時があったります。好みに合うサイトを探しましょう。

・iStockphoto

・Dreams Times

・Fotolia

・Japanese Streets

・Shutter Stock

・Shutter Map

フリー写真を提供しているサイト
・Morgue File

・Flickr Creative Commons Pool

・Image After

・Stock.xchng

・Everystockphoto search engine

※イイなと思ったら「プレzen」も買ってください。アレは良い本です。

・おまけ
「この画像、高かったんでしょ」のおねーさんは「イメージナビ」で入手できます。画像点数が多く画力がとても強い画像がいっぱいありますが「でも、お高いんでしょ。」なので、用法用量はよーくご注意ください。

成功要因が数値化できることだけで構成されているわけない

2011-09-30T19:31:00.003+09:00

アメリカンフットボールにおける花形ポジションといえばクォーターバック（以下：QB）だ。
アメフト知らない人手もQBは知ってたりするし、私らぐらいの年（30才以上）だったら「ジョー・モンタナ」が三菱のテレビのCMで「どんな、モンタナ！」って言っていたことぐらい覚えている。
QBはオフェンスチームのリーダーでありマネージャーだ。相手ディフェンスの様子を見て、どうしたらオフェンスチームが効率よく得点を出来るかを考えプレイする。手堅くランニングバック（以下：RB）にボールをもたせてじわじわ攻める、テンポ良くパスを投げて攻める、時には自分自身がボールキャリアになって単身突破を図る。オフェンスにおけるあらゆる選択肢がQBに委ねられている（といってもプレイコールはベンチからでることが多いが）。

パッと見ると、パスを投げてたまに自分で走るので、パスを投げるのが上手ければ務まりそうな気がする。足が速ければ尚良しだろうか。もちろんパス能力に秀でたところがあれば、個人成績として良い結果がでる。足が速ければQBだてらに○○ヤードも走った、と評価される。しかしアメフトの世界では、個人成績だけが優れているQBの評価はある一定のラインでとまってしまう。良いQBかどうかは勝てるQBかどうかで決まるのだ。チームが勝つには自身の能力だけではなく、チームメイトの能力も引き出さなければ勝てない。アメリカンフットボールは個人の能力だけで勝てるような仕組みにはなっていない。

チームメイトの能力を引き出すにはどのようにすればよいのだろう。ベンチからのコールを正しく伝える。味方を鼓舞する。時には叱咤する。チーム全員の共通の目的である「勝利」をつねに意識し、そのために振る舞う。リーダー兼マネジャー的な能力が求められ、ときにはコーチングの能力も必要になるだろう。アメフトの世界ではこれを「クォーターバッキング」という。ちなみにこれは私の解釈であって、異論を言う人もいる。クォーターバッキングの正体はまだ解明されていない。少なくとも数値化できるようなものではない。もし数値化できるのであれば、それはチームの勝利数ぐらいかもしれない。

仕事において、単純に○○の作業ができる、○○を知っている、○○の経験がある、だけでチームを構成しても上手くいかないことがある。とくにチームで仕事をする場合。メンバーは適正な人を揃えたつもりだが、なぜか期待する結果がでない。何故か。それはそのチームにクォーターバッキングをする人がいないからだろう。チームは個の集まりにすぎず、同期もとれず、下手をすればちぐはぐな動きをして、終わってみればみんなががっかりする結果しか得られない。

なんでこのようになるのだろう？
それは成功要因を数値化できるモノゴトだけで判断するからおこる。
本当に素晴らしい仕事というのは、そんなものだけでは構成されない。

チームに適切なリズムを生みだす。失敗をしても誰もメンバーを責めたりしないことをキッチリ宣言し安心をしてもらった上でベストを引き出し、ちょっとくらいへまをしてもオレが何とかするよという優しさをもつ。関わりのあるチーム外の、それは組織の上司や顧客、ビジネスパートナー、いろいろあるだろうが、そういった人達からの疑いや厳しい視線は自分に集め、メンバーをリラックスさせ最高のパフォーマンスをひきだす。当然、時には厳しい非難の矢面に立たされることもある。それが何だと言うのだろう？　損な役割か？　いいや、違う。メンバーはそれぞれのポジションで最高の結果をだすべく一所懸命に頑張っているのだ。もしかしたら自身の能力を超える難しいことにチャレンジをしているのかもしれない。そんなメンバーが外からのつまらない視線や声に晒されることなくそれらの役割を買ってでて、チームのために働く。そして上手くいったら、チームメンバーに最高の賞賛を贈る。みんなのおかげで成功したと伝える。これが仕事におけるクォーターバッキングだと思う。

スクラムにおけるスクラムマスターというのはこれに近いのだと思う。そう言う意味では正体不明なクォーターバッキングにある一定の形をもたせたともいえるのでスゴイ。故に私はスクラムが好きだし興味がある。

現代において、とくに間違った成果主義が横行しているような組織では、こういった働き方は損をするかもしれない。いなくても十分まわると勘違いをされることもあるだろう。しかしそんなものは間違いだ。目に見える数値だけでモノゴトを判断してるようでは、ほんとうに大事な成功要因を見失う。誤った判断は時間が経ち、すでに取り返しが付かなくなったときに顕在化する。その時になってあれこれやってももう遅い。

多分ね。

書店と出版と書籍の未来について思うこと

2011-09-29T12:25:00.001+09:00

私の父は今年の11月で60歳になる。父は私にいろいろなことを教えてくれたがその中でも特に感謝しているのは下記だ。

・本を読め
・本代をケチるな

実際、私が学生の頃は本に払う金がなければ気前よく小遣いをくれたし、そうして買った本の中には私に大きな影響を与えたものもある。また本の貸し借りもしていたので「ザ・ゴール」は父から借りて読んだ。父は言葉に出して言わないが、継続的な読書が人生をより良くしてくれるものと思っている節がある。
そういう父の影響を受けた私としては、彼の還暦祝いに Kindle か iPad を贈りたいと考えていた。書籍購入にかかる請求先は私宛にして。
しかしこの目論見は実現しそうにない。残念ながら Kindle や iBooks が日本で本格的なサービスを開始する目処は立っておらず日本語書籍もほとんどない。日本の出版社やメーカーからでているサービスはいまだ決定打と呼べるものがなく、むしろ購入しても早々に撤退しそうな雰囲気がありありであり、とても還暦祝いにプレゼントできるようなシロモノではない。
（この手のサービスはいつも「夏目漱石」や「太宰治」などのド定番を最初のラインナップに加えているが、それらが読みたくてわざわざリーダーを買うと思っているのだろうか？）
Kindle が発表されたのは2年くらい前で、私は2年もあれば日本でもサービスを開始するものだろうと思っていただけにとても残念だ。

・大手出版社に対する不信の念
彼らは「出版」というものを何だと思っているのだろう？
今の状況はどう考えてもレコード会社と同じ徹を踏んでジリ貧になることは間違いない。ビジネスとしてみるとあまりにもひどい状況だと思う。文化面でみるとどうか？　私はこの点において怒りを通り越して呆れている。

・書店
極論かつ推測で恐縮だが、将来有望な若者が多く育つ地域には良い書店があると思っている。知的な情報に気軽に、頻繁に接することができれば、興味が書籍から得られる情報に向かうのは自然な流れのはずだ。だから、そういった事業に関しては税金で優遇するとかあっても良いのではないかとすら思っていた。いちおう図書館がそういう役割を果たしているのだろうが、店主のセンスで大胆な書棚の構成ができる書店にも何らかの支援があっていいと思う。しかし現実は、Amazon.co.jp の台頭により、街角の小さな書店がどんどん姿を消している。ターミナル駅の周りには巨大な書店がどんどん立つようになったが、大量の在庫を用意しなければ来客数を確保できないこの流れは、ネット書店の魅力とかぶってしまっている。大手書店も生き残っていくのは大変だろう。

・今後どうなるのか？
地域から書店が姿を消すことによって、その地域の子供たちが書籍に接する機会が減る。間違いなく減る。自分で本を選んで買う機会も減る。すると子供は読書以外の遊びをするだろう。読書の習慣のない子どもが多く育つことになる。彼らは当然、大人になっても本を買わない。情報収集は別のやり方で行うだろう。これは結局、出版業界自体の首を締めることになるのだが、そういうことには思いが回らないのだろうか？
また、極めて偏った物言いで恐縮だが、読書の習慣のない人は情報収集が遅く仕事においてマイナスになる。ちょっとした文章を書かせても誤解を生むような書き方や、伝わらない書き方をして、周囲の人間にいらぬ負担をかけている場合がある。「こいつのメールはいつもつらつら長いが何が言いたいのかさっぱりわからない」といった経験をみなさんもお持ちではないだろうか？(※)
読書を通じて言葉の扱いに長けていくことはとても大事だ。「読み書き算盤」と良く言われるが「読む」にも上手い下手があることを認識している人は少ない。読むのが下手なら書くのも下手になるのだ。これを疎かにして、今後いったいどうしていけというのだろうか？

　※私の日本語もひどいもんだけど

・やるべきことはシンプル
一刻も早く、Amazon でも Apple でも Google でもいいから電子書籍の販売網を整備するべきだと思う。現在の出版、印刷、取次の業界の既得権を気にしている間にも日本人は学習機会を損失しつづけている。また電子書籍の普及は大量の在庫を抱える必要がなくなるので、待ちの小さな書店にとってもメリットになるはずだ。数台の端末を設置し、来客者に対して書士として対応すればいい。マンガ喫茶みたいな形態もありだと思う。多くの可能性があるはずだ。しかし紙の書籍では売場面積による棚在庫の数だけが本屋の価値になりがちである。あらゆるものがデータ化されるこの世の中でそんな馬鹿馬鹿しいことがあるのだろうか？
大手書店はスペースがあまるだろうから、出版された書籍に関するイベントをもっと頻繁にやったらいい。どのみち、本を売るだけで儲けをだしていくのは難しくなる時代だ。以下に効率よく手持ちのスペースを活用していくのかは書籍が電子化しようがしまいが関係なく考えなければならないことだ。

・あらためて「読み書き算盤」
この世の中がどんなにIT化されようと、ましてや人類補完計画や攻殻機動隊の世界が実現しようとも、言葉を扱うことの大切さはかわらない。やりとりする情報量が増えるのであればより重要になってくる。それの熟練度を上げるのは日々の読書体験だ。どうか日本の出版関係者は、私たちや私たちの子供たちが、あって当然である読書の機会を損なわないようにしていただきたい。欧米では提供されて日本にはない。こんな不公平があるか？
本から多くのことを学び、育ってきたからこそそのように願う。

多分ね。

【毒】ﾎﾞｿｯ

2011-09-28T15:14:00.002+09:00

リーダーシップやマネジメントについて、それらを身につけようとか学ぼうとか思わないのであれば、いつまでたっても人から小突き回されるのだと思うし、主体性を発揮したり自由に振舞うことだってできない。

自分自身の人生をリーディングしたりマネジメントするのはどこの誰ですか？

※それだけやれば良いとは言ってません。

会社を辞める理由ねぇ…

2011-09-26T17:19:00.006+09:00

「楽しくないから辞める」
っていうのもあるんだろうけど、個人的には「組織との対話」ができなくなると辞めていくのだと思う。
対会社、対上司、対同僚。いろいろあるだろうけど。対顧客や対ユーザーもあるだろうな。

優秀な人（あいまいだな）って、目的意識や問題意識なんかを持っていて、なんとか良い方向にもっていこうと組織に対して働きかけているはず。それとかちょっと知っていれば回避できる失敗とかも、そうならないように忠告したり、情報を発信したりとかね。
でも、組織や同僚が無関心であったり、忠告を無視して凡ミスを繰り返してたりすると「くだらねぇ付き合いきれるか」ってなるんじゃないかなー。
ああ、これが「楽しくない」という状態か。楽しくないから辞めるは確かにあってる。。

夕べテレビをみてたら中日の落合監督が言ってたことが印象に残った。
・選手というのはできないことをやろうとする
・できないことをやろうとするから失敗する
・今やれることだけやってればいい、っていうのもあるけど、それは本人がおもしろくない
・だから俺達がやることは、できないことをできるようにするための手助けだ

激しく同意してしまった。

今やれることだけやっていればいい、っていうのは人間を工場の装置か何かのように扱っているのだと思う。
あなたの成長なんか期待していないよ、みたいな。
◯◯さんが同じような仕事をずーっとしてくれるのは、管理する側からしたら楽ちん。
でも◯◯さんが「こんなことやりたいんです」とか言い出すと、その分、他の誰かをその仕事にあてたりとか、いろいろ手間がかかる。
だからずっと同じことやっていてほしい。
そりゃ楽しくないよね。

でもこれはある意味、正解かもしれなくて、そこで言う「ずっと同じこと」を何年かやって役目を果たしたなとか、そろそろキャリアアップするかと考えて違う仕事をする。それは「辞める」ではなくて「新転地をもとめて旅立つ」だからそんなに悪いことじゃないよね。

多分ね。

XP祭り2011の個人的な感想

2011-09-06T23:31:00.003+09:00

感想なんて個人的なものに決まっているのだから、いちいち前提をいう必要なんてありえないのだけど、それぐらい個人的な感想なのでいちおう（なんじゃそりゃ）。

久しぶりに友人たち（一回でも一緒に酒のんだら友達だと思ってます。一方的ですがｗ）がいて、みなさん元気そうでほっとしたり、会えて嬉しかったり。「take3000の人相が変わりすぎてて誰だかわからなかった」というTweetも散見されましたが、まあ、あれです、一貫性がなくてごめんなさい。

私は諸事情があって午後からの参加でみなさんが絶賛していらっしゃる社長セッションは聴いていない（全然悔しくないもん）のですが、私が参加したセッションの中では、「アジャイルを科学する」と「事業創造に貢献する”最速最高”プロジェクト推進活動」がとても良かったなー、と。そりゃもちろん、他にも聞きたいセッションはありましたよ。でもね、

　ジコ坊「天地の間にあるすべてのものを欲するは人の業というものだ…」

そう思って諦めればね、全然悔しくないもん。。。

ここからは本当に個人的な感想ね。

昼休みの野良LTコーナーで先陣切ってLTやったのは我ながら隠れたファインプレイだったと思う。
samuraiRedさんが「やるなら人を呼んで来ますよー」って背中を押してくれたのもありがたかった。
あの場の緩くてスニークピークっぽい雰囲気はとても良かったと思う。

その後の闇アジャイラー2.0はまあまあでしたね。
続編でこける映画が多い理由を身を持って体験しましたｗ
技術的には1年近く前の闇アジャイラー1.0（便宜的にそう言っておく）よりはるかに上がってますが、結局、1年前の自分のほうが良いパフォーマンスをしていたんだなー、と寂しく思ってみたり。

いろいろ難しいですね。
でもXP祭りは参加して良かったと思っています。
来年も（は）みんなで野良LTやるといいと思うよ。

スピーカー仕事「ここまで出来る！自動生成ツールを取り入れたこれからのRIA開発」

2011-07-13T22:29:00.002+09:00

来週、7/20(水)にキヤノンソフトウェアさんとの共催セミナーで喋ることになりました。

□イベントタイトル
「ここまで出来る！自動生成ツールを取り入れたこれからのRIA開発」

□私のセッションタイトル
「Adobe Flexによる効果的なユーザーインターフェース設計
　～ITシステム企画の要は現場目線にあり～」

裏イベントがおそろしく豪華ですが、ご来場いただけますと幸いです。

「会社ブログはじめました」のお知らせ

2011-07-13T22:26:00.002+09:00

仕事でブログを書くことになりました。

Classmethod.design()

「タケハラマサシ」が私です。
他のカテゴリーで書く予定はないです。

多分ね。

デザイン、デザイン、デザイン…

2011-07-13T22:02:00.003+09:00

半年くらい前までは気恥ずかしいというか、厨二病扱いされるのを恐れてというか、そういう感じで言わなかったのですが、私にとってはあらゆるモノゴトはデザインの対象物であり、そのモノゴトに関わる人を意識するべきである、とか思ってます。

ふわっとしてますね。
でもそういう感覚。

プレゼンで使うスライドはもちろん、私の立ち振る舞いや喋り方もデザイン対象。聴講者にどう伝わるか、ひいては主催者にどのようなメリットをもたらすことができるのか。

契約書も当然。その条件の記述の仕方で、契約の当事者とそれに関わる多くの人に影響を及ぼす。言い換えると、その契約書には利用者が存在する。だからデザインする感覚。

マーケティングだってそういうものじゃないのかなあ、と思ってます。

結局、自分の主張をするだけでは何ら上手くいくことはなく（自分の中だけなら上手くいってるように思えるんだろうけど）、関わる人様の内面の変化や自分との関係性の変化などなどを可能なかぎり想い巡らせ、その上でなるべく多くの人に効用をもたらすあり方を探る…、そういう気持ちです。

しかしそういうデザインは最初から上手くいくことはめったになく、不完全なモノゴトを根気よく観察し、時には修繕し、愛でていくような感覚があって、それでようやくスタートラインなんじゃないのか、と。
浅慮な意思決定やエゴの排除が私にとってのデザインなのかもしれません。

なんだろう。まだふわっとしてる。

デザインとは目に見えるものだけが対象ではなく、モノやサービスを通じて人の有り様がどのように変化するのか、それは内面の、心の変化という決して目に見えることがないものもデザインの対象であり、むしろその目にみえないものの方がデザインという行為の本質なのではないかと。

多分ね。

裏方ワーク（クラウドEXPO、DevLOVE HangerTalks／HangerFlight）

2011-05-24T22:16:00.007+09:00

5/11-13のクラウドコンピューティングEXPO、5/20のDevLOVE HangerTalks、5/21のDevLOVE HangerFlightと関わったイベントでめいっぱい裏方ワークをしてました。裏方に徹するの久しぶりなのでちょっと新鮮。

・クラウドコンピューティングEXPO

クリアファイルが大変好評で嬉しいです。みんな使ってくださいね！あとゲットした人は自慢してくださいね！ TwitterとかFacebookとかBlogとかなんでもいいから。

あと第二弾の制作が決まりました。完成した暁には是非、もらっていただきたく！
それと、

みなさまのおかげでクラスメソッドブースは大変盛況でしたｗ
「Twitterで話題になってるクリアファイルをもらいにきました！」
っておっしゃる人が本当にいました。うれしー♪

本当にありがとうございます！

・DevLOVE HangerTalks

@chachakiさんを紹介するLTをやりました。
時間が足りずにオチに辿りつけなかったのは初めてな気がする。反省。本当は
「UXハニカムの７つ目、価値があること。そう、今日のchachakiさんのセッションには価値があります。」

「お後がよろしいようで。」

と言い切ってドヤ顔で決める予定でした。
ま、言ったら言ったで滑ったでしょうね。

・DevLOVE HangerFlight

裏方としてスペシャルセッションの企画とコーディネート。
@kohseiさん、@yattomさんお世話になりました。また@ymkzさん、@DiscoveryCoachさん、@nohdomiさん、@to_ynrkさんにもCoファシリテーターとしてお手伝いいただきました。あの活気があって、でも優しげなダイアローグができたのは参加したみなさんを含め、かかわったみなさんのおかげかと思います。ありがとうございます。

あと@shot6さんセッションの司会と前説。
「かなり大きなテーマで無茶ブリをしましたが、バスケ仲間のおおたにさんならこんな難しいショットも上手く決めるでしょう！」
ってドヤ顔で言ったらとりかえしがつかないぐらい滑りました。
怖いですね。
前説には魔物がすんでます。

@sandayuuさんのセッションはBizRIAカンファレンスの企画の再演をお願いしました。
こっちも司会と前説やりたかったのですが、時間の都合上断念。
でも「あ〜〜（中略）〜〜じゃいる！」で盛り上がってたので良かったです＾＾

5月はこの３つのイベントでお腹いっぱい。
でもいろいろ学べました。
ラッキー。
私、また成長したな。
身体的に横方向にも成長した気がしますが。

多分ね。

縦サミの補足

2011-05-05T23:42:00.013+09:00

時間もたったし連休中だし明日仕事の人もいるし（私は休みだけど）、縦サミのほそくをします。

・スライド

[DevLOVE]これからのRIAの話をしよう(縦サミ版)

View more presentations from takehara masashi

・動画
http://www.youtube.com/view_play_list?p=2B814A7D88088C52

１．オープニング

イベントのコンセプトは「デブサミの再演」なので、2.18のセッションをそのままやることも考えましたが、少なからず、2.18で私のセッションを観た人もいらっしゃるだろうし、その人たちへのお礼はちゃんとするべきだろうと。それとデブサミよりはお祭りムードがある方が良いと思ったので、ネタ的な画像を増やしました。サンデル教授とかね。

２．ユーザーエクスペリエンスデザイン

2.18とは構成を変えました。RIA→UXという説明順序よりUX→RIAの方がしっくり来たので大幅変更。
セッション中も言いましたが、まずは「早く」「間違えない」ことを意識するので十分だと思います。UXDについて結構やりこんでいる現場は違うでしょうけど。
それと書籍をいくつか紹介していますが、必ず全部読んでいる必要はないだろうなあとも思います。デザインに関する書籍はものすごく多くて、ソフトウェアの世界に限定してもそれなりに数があります。プロジェクトに関わる全ての人が全部読むとかは無理があるし。あと書籍について、みなさまのTwitterやBlogを見て気がついたのですが、確かに入手困難なモノが多い。ごめんなさい。そこは注意して紹介するべきでした。
しかし、いい本なのに重版されない。そういう本が多いですね。今、簡単に入手ができて、ソフトウェアのUXDについて体系的かつ実務よりに学べる本は下記です（言い切っちゃえ）。

「ソフトウェアユーザーエクスペリエンス設計」

あと新しいところだとこれもオススメ。

「UXデザインプロジェクトガイド―優れたユーザエクスペリエンスデザインを実現するために」

すごく良い本だけど14章だけは好きになれない。

３．RIA＋Smartphone

いちおう、もともとの依頼内容がRIAのOverviewだったので、Flash、Silverlight、HTML5をさらっと紹介しつつ、iOS、Android、まだ見ぬWindowsPhone7も紹介。あくまでさらっと。
ただ、世の中、新しい技術、新しい手法が登場し、それが熱狂的に受け入れられると、それまであったものを急激に排除しようとしたり、過剰にdisったりっていうのがあって、そういう話って楽しいっちゃ楽しいけど、いちおうITの専門家がそれにのっかっるのはどうかと思ったので、技術選定の際は慎重にね、という話にしました。新しいモノを強烈プッシュする人たちには当然それに見合う理由があるわけで、それが私たちやユーザーにとっても益するものかは、ちょっとわからんですよね。

それとRIAの話をしているとどうしてもフロントエンドの実装技術に目が行きがちになります。それも大事だけど、もうちょっとひいた目で見るのも必要かな、と。ちょっと電波とばしてよかですか？

ソフトウェアの正常進化の過程としてRIA技術があると思っています。遅かれ早かれ、Webを利用しつつも自由度が高い技術が普及するだろう、と。それは名前がRIAかどうかは問題なく。その正常進化は人が使う道具としてより優れていく、つまり使いやすくなるし、人がかけた労力に対してより多くの成果が得られる（レバレッジが効く）ようになるわけで、そう考えるとRIAがゴールではないわけです。もっと優れた技術が登場するはず。それは入出力装置の進化もあるだろうし、サービスのコモ化もあるだろうし。それらが複合的にあわさって、より優れたソフトウェアであったりITシステムになるはずです。

今のソフトウェアの多くはGUIベースで、UIというと画面のデザインが作業の中心となり、必然的にPhotoshopやIllustratorを使い慣れた人が活躍することになります。しかしそれはあくまえGUIベースのソフトウェアの話であって、NUIみたいなジェスチャー系のものが登場すると画面デザインの枠を飛び越えます。セッションで紹介したベン図と本気で取り組む日がやってくるかもしれません。

４．プロセスとプロジェクトマネジメントと契約

プロセスについて、私は去年のデブサミの鈴木雄介さんのセッションにおける捉え方が好きなので観ていない方は是非、スライドだけでもご覧いただくと良いと思います。

http://www.slideshare.net/yusuke/ss-3221768

契約について、技術や手法に良いものが登場しているのに、契約形態だけは一向に進化しない。私は実務では契約書を作ったりレビューしたりといったことをしていますが、なかなかしんどいですよね。これでいいのかなかあと思うことはほぼ毎日です。
先日、IPAから発表されたアジャイル型に適した契約形態や、実費償還契約なんかはもっと注目されるべきです。多くの人で議論して、どういった形態がより今のソフトウェア開発に適しているのか探っていくことが必要。

契約に関わる者の責任として、もし自分達の諦めや怠惰が日本のソフトウェアエンジニアから仕事に対するやりがい、自由な発想、創造性を奪う一因となっているとしたら…、それはもう、いくら反省しても足りないですよね。自戒の念もこめて、契約についてはいろいろアピールしたいです。

「契約もデザイン対象！」

それと補足の補足ですけど、こういう新しい形態の契約をやろうと思ったら、開発そのものが上手くなっている必要があります。
いままで通りではいかんはずなので。それも踏まえて、アジャイルのプラクティスを学んだり、チケットを導入したり、テスト駆動でやってみたり。やることいっぱいありますね。

５．まとめ

実は「良いデザインを褒めてください」の話の元は私の上司の発言です。彼曰く「悪いのは記憶に残るけど、良いのは意識しないから記憶に残りづらいよね」って2年くらい前に言ってました。本人は忘れてたっぽいですが。

最後に3.11について。
よしおかさんがおっしゃっていたように不可逆の変化が起きたのだと受け止めています。
原発を沈静化する、瓦礫をどかすこと、被災者の方が住む家を作ること、そういうことはまずできませんが、情報の扱い方を教えるぐらいはできますよね。小さいことから、身近な人たちから、そんなんでも良いのだと思います。

６．渾身会

2次会でt-wadaさんのプレゼンリモコンがMacで使えるか検証。結果、使えることがわかりました。というわけでロジクールのプレゼンリモコンがほしいけど動作対象に入ってないから諦めていた方（どれだけいるか知らんが）、大丈夫ですよ。使えますよ。

多分ね。

「星の屑」がおわった

2011-04-30T20:13:00.003+09:00

この数カ月間のベシャリ仕事について、「ガンダム0083」
のストーリーラインになぞらえて列挙してみました。

・テストパイロット時代
→社内で勝手にプロジェクトマネジメントの勉強会を開いたり、
　全社KPTやったり、しゃべり場やったり、社内での活動が
　ほとんど。
　「パーティ、Beer、KPT」
　プロジェクトマネジメント勉強会（PMBOK概要）20100824
　[Slide]しゃべり場LT「エージェント、Help、Xp」

・ガトーがガンダム２号機を強奪。たまたま乗ってた1号機で
　戦闘開始。
→闇アジャイラーやったあたり。たまたま喋ったネタLTがいろんな
　ところで好評いただく。
　[Slide]闇アジャイラーvs光アジャイラーforDevLOVE(EnergizedWorkLT祭)

・終わりなき追撃戦。しかしアフリカのジオン残党軍により、
　ガンダム2号機の打ち上げ成功。
　アルビオンは宇宙域へ転戦する。
→DevLOVEの鳥一代でのLTやプレzenワークショップあたり。
　良いパフォーマンスだった思うが集客人数が少なかった。
　[Slide]DevLOVE_ EMZERO_TORI1「SCD_to_UCD」
　[リリース版]「プレゼンテーションｚｅｎ」っぽいプレゼンのやり方が誰でも１時間くらいでわかった気になるワークショップ

・宇宙用装備に未換装のガンダム1号機で出撃。シーマ様にフルボッコにされる。
→HangerFlight Winter Soltieあたり。プレゼンスタイルがLT用のままであり
　50分のロングセッションに適した装備になっていなかった。
※資料未公開

・ガンダム1号機をフルバーニアンに換装。月面上でケリー・レズナーの搭乗
　するヴァル・ヴァロを撃破。
→会社主催のセミナーに登場
　[BizRIA]UXを取り入れたこれからのRIA開発(公開用)
　※実際の資料とは違いますがだいたいこんな内容です

・ソロモン海域におけるガンダム2号機探索戦。戦術核使用の阻止失敗。
　その後、ガンダム2号機と交戦。搭乗していた1号機は2号機もろとも大破。
→デブサミ。やりきった。しかしこれが本当の終わりと思えず。
　[Developers Summit 2011]これからのRIAの話をしよう〜システムの利用者と開発者にやさしいＵＸとＵＩ設計について〜

・ガンダム3号機（デンドロビウム）に搭乗し、コロニー落下阻止作戦に参戦
→縦サミ。再演企画にもかかわらずスライドを大幅換装して喋る。

[DevLOVE]これからのRIAの話をしよう(縦サミ版)

View more presentations from takehara masashi

こうやって振り返ると、聴いてくれた人、アドバイスをしてくれた人、イベントの裏方をしてた人、そもそも私に依頼をくれた人、チャンスをくれた人、多くの人のおかげでこういったことができたのだと思います。大変、ありがたいことです。

それとデブサミの日、雅叙園の廊下でセッションスケジュールの悪口を大声で言った人！　本当にありがとう！！　おかげで私は鈴木雄介さん、和田卓人さん、よしおかひろたかさんの話を聞くことができました。だって、自分の出番があるからこの三人の話しが聞けないってそんなの理不尽だー！って思ってたし(笑)
縦サミ影のMVPはあなただと思います。本当にありがとう！ありがとう！

本当にみなさまありがとうございます。

そして縦サミのは本当に良いイベントでした。
関われて幸せ。

さて、後でデブサミと縦サミのセッション内容の補足をしますか。

多分ね。

「クラスメソッド春の集中講座」のおしらせ

2011-04-11T10:56:00.001+09:00

4/26(火)、4/27(水)、4/28(木)に「クラスメソッド春の集中講座」という正気を疑われかねないタイトルで勉強会をやります！
みなさんお誘い合わせの上、是非、お越し下さい。
ちょっと先のITシステムについて語らいましょう！

■4/26(火)1日目
「“スマート＆リモート”　ITシステムは時間と空間を超える」
http://kokucheese.com/event/index/9674/

■4/27(水)2日目
「“Adobe AIR in Everywhere!”　マルチデバイス時代のUXD」
http://kokucheese.com/event/index/9712/

■4/28(木)3日目
「”クラウドがデファクトになる日”　RIA＋AWSによる業務アプリ採用ケースと可能性」
http://kokucheese.com/event/index/9717/

BizRIAカンファレンスの感想（１）「MONEX VISIONβ」事例紹介

2011-03-20T19:23:00.004+09:00

3/9(水)にBizRIAカンファレンスというイベントをやってきました。その感想をつらつらと。

そもそもどういったイベントであるのかというと、Flexを中心としたFlashプラットフォーム、つまりRIAなんですが、これって良い技術なのに上手く使われているっていう話が表にでてこないね、業務でどうやったら上手く活用できるんだろうね、そういうのをみんなで共有したいね、という狙いで企画しました。そのためのアジャイルでありUXであり要求開発ですよね、と。

マネックス証券さんからは「MONEX VISION β」のサービスの概要と開発の進め方をご説明いただきました。私なりの気づきを簡単に書くと下記。

・開発は現物主義

・良さそう！というアイディアはすぐ作ってみる

・ユーザーレビューをかなりしっかりやっている

・とことんユーザー指向

当日のセッションを聞く限り、UXの作り込みでやったほうが良いとされるユーザー調査、ペルソナ分析法などは今回はやっていませんでした。ここが驚き。

実はこのイベントの前に打ち合わせでもいろいろお伺いしたのですが、進め方を聞くと一人の主担当者がたたき台となるモックアップを作り、そこからチームで作業をしたそうです。しかし今回はたまたまそのように進めたものの、これまではしっかりとしたデザインプロセスを踏み、ひと通りのプラクティスは試したとのこと。MONEX VSION βはこれまでの検証結果や成果物の再利用もあって生み出されたサービスということでした。

・厳格なデザインプロセスは本当に必要か？

ユーザー調査、ペルソナ分析法というのは良い手法であると思います。ユーザー調査はUXの5Sを構成する戦略部分をきっちり作るためには取り組むべきでしょう。ペルソナ分析法はチームで立ち戻る場所をつくる意味でないよりは確実にある方が良いです。しかしかねてより、これらの手法はITシステムの開発プロジェクトには適さないのではないかと思っていました。なぜなら時間がかかりすぎるからです。実際、マネックス証券さんの事例、すくなくともMONEX VISION βにはでてきません。

最適なUXはコンテキストによる、という言い方をするときもあるのですが、コンテキストを十分に理解しているのであれば、デザインプロセスをある程度省略しても十分に良いコンセプトを生み出すことが出来、その後のプロジェクト運営が適切であれば素晴らしいサービスを構築できる、MONEX VISION βの事例にはそういった気づきがありました。

・ソフトウェア開発に携わる多くの人にとっての希望ではないか

「UXをちゃんとしよう」と思い何から手をつけて良いか調べると途方も無い量の情報にぶちあたります。それらを調べていくとその先にはすぐ「デザイン」という、ソフトウェアのUX以上にもっと掴みどころのない制御困難な世界に迷い込み、結果として何をして良いのかわからないという自体を招きがちです。おそらく多くの開発者はこの時点であきらめ、これらはこの道の専門家の領域であると思うのではないでしょうか。

しかしマネックス証券さんは、まずは目に見えるものを作ってみるアプローチをとりました。これが重要です。まずは作ってみることで多くのことが見えるようになるのです。デザインプロセスの多くは見えないものを見ようとするがあまりに重厚長大で時間のかかる作業をすることになります。しかしそれらの間接成果物を直接成果物に（脳内モデルを実装モデル）に変換する際、ここで上手くいかないと事前の間接成果物はまったくの無駄になります。この場合、予算の無駄も痛いのですが時間の無駄はもっと痛い。変化がめまぐるしいこのご時世において、間接成果物作成に時間をとられてそれが実際のサービスにうまく活かせないとなると死活問題になりかねません。

しかし「まず目に見えるものをつくってみる」アプローチであれば、そのリスクは回避できます。これは別エントリーで書きますが、匠BusinessPlaceの牛尾さんのセッションでも共通のテーマが語られました（このセッションも本当に素晴らしかった！）。

しかし一つ注意ですが、これは十分に必要とされるモノゴトを理解している、コンテキストを理解し、デザインプロセスについても理解があったからできたことであって、ビジネス的な背景を理解していない技術者つれてきて、さあ作れといってもできることではありません。

・ある意味、理想的なアジャイル型の開発

初期コンセプトをもとに試行錯誤をしながらソフトウェアを少しずつ成長させる進め方をとっていました。そして要所要所で実際のお客さまにレビューをしてもらい、そこで得られた意見をフィードバックしていたそうです。意見がわかれるとは思いますが、ペルソナの意見は開発チームが推測するしかありませんが、お客さまの意見に推測は不要です。どう思い、どのようにしてほしいのかはストレートにでてきます。プロジェクトはその意見をとりいれつつ進められたそうです。

・このエントリーで言いたいこと

UXについて学ぶこと、デザインプロセスについて学ぶことは大切です。これからのソフトウェア開発において確実に理解をしておくべき事柄です。しかし”これらを学ぶこと＝良いソフトウェアが作れる”ということではありません。実際に構築するにあたっては、利用する技術の特徴を理解しておく必要は当然ですし、それを実践するだけの腕前も必要になります。また手法を学べばできるものではなく、より多くの、それも良いソフトウェアに触れた経験も必要なります。

またプロジェクトとは採用するプロセスやプラクティスはそのプロジェクトにあわせて組み合わせるのが正解です。今回のマネックス証券さんにおいては、厳格なデザインプロセスは不要でした。しかしいつもそうだとは限りません。何が必要で何が不要であるかの判断は現場で実際に作業をするチームにもよります。ここが腕前の見せどころなはずです。

マネックス証券さんの事例を聞いて、こんなに素晴らしい開発事例があるのかと感動し本当に清々しい気持ちになりました。是非、この成功事例を、ITに関わる全ての方に知っていただければ幸いと思います。

Effective UIにでてくるEngagement in Softwareの図

2011-03-04T12:00:00.002+09:00

Efflective UIにでてくるEngagement in Softwareの図をベースにUXDの勘所を説明する資料を作りましたよ。

UXD勘どころ

View more presentations from takehara masashi

デブサミ2011で知ったかぶりを晒してきた件

2011-02-19T22:35:00.006+09:00

遡ること数ヶ月前。

DevLOVEの打ち合わせ前に@papanda氏に

「心臓を叩いといてください」

と言われ、いったい何の話かと思ったら@kohseiさんより

「デブサミのRIAトラックで基調講演をお願いしたい」

「大砲をぶちかましてほしい！」

とご依頼をいただき本当に心臓が止まりそうになったのが発端。

すごいビビったわりには不思議と「やります」と即決してしまった。

なんでだろう？

多分、チャンスの神様の話を思い出したんだな。これ掴まないとこういうチャンスはないだろうな…みたいな。

RIAのOver View＋Smartphoneのネタでよろしくということだったので、現状の概要と今後の展望を軽く説明することにしました。基本的には詳しいことはこの後のRIAトラックを要チェケラで、という感じ。それとUXデザイン。これからは必須ですよ、みたいな。

でもそれだけだと営業トークで終わってしまうので、私が普段から思っていることをいい機会だから言ってしまえ！と考えました。仮に失敗しても

「二度目のオファーはない」

「いたたまれず転職」

「大衆の前で派手にスベる（これはおきた）」

とかそんなもんでしょと腹を括り、言い切る方向で推敲を開始。しかし普段から思っていることを言語化することが思いの外難しかった。これは本当にしんどかった。

しかし友人や仲間というのはありがたいもので、みんなのアドバイスなどをもらってぎりぎりのところでどうにかまとめることができました。とくに@tmtknchrさんのアドバイスは印象に残っていて、東西線のホームで言われたことで何が不足しているのかがわかり、ある程度の自信がもてました。ありがとうございます。あとお昼にごちそうになったビールが美味しかったです。

[Developers Summit 2011]これからのRIAの話をしよう〜システムの利用者と開発者にやさしいＵＸとＵＩ設計について〜

View more presentations from takehara masashi.

終わってみて、やはりというか反省点が非常に多く、もうしわけない気持ちにもなるのですが、今の自分の実力であることは確かだし、伝わったかどうかはまだわからないけど、言いたいことを言い切ることだけはできたので、やって良かったなと思っています。

今回、こういったチャンスをくれた@kohseiさん、@papandaさんにとても感謝しております。また、あきらかに能率が下がっている私を暖かく支えてくれた会社やコミュニティの仲間たちには感謝と謝罪の両方がいりまじった複雑な感情です。

あと立ち見がでるくらい集まっていただいた聴講者の皆様。本当にありがとうございます。裏番組が強力だからきっと迷いましたよね。そりゃそうです。私だって私の出番がなければそっちの３つを観たかったｗ！

なんか真っ白に燃え尽きたぜ、みたいなエントリーですが、どうやら再演企画もあるらしいとか、そもそも3日後にはAdobeさんとのセミナーがあったり、3/9にもイベントをやったりで、燃え尽きている場合じゃなかったりしますが、今後ともお付き合いいただけるとこれ幸いです。

あー、書籍リスト載せないと……。

リンクとかはすみません。ググるかBingるかしてください。

■参考書籍

「使いやすいソフトウェア」

「デザインのためのデザイン」

「ソフトウェアユーザーエクスペリエンス設計」

「インタラクションデザインの教科書 (DESIGN IT! BOOKS)」

「ウェブ戦略としての「ユーザーエクスペリエンス」―5つの段階で考えるユーザー中心デザイン (Web designing books) 」

「プロジェクトコスト見積もり入門ファンクション・ポイント、COCOMOII、WBSによるソフトウエア開発コストの導き方」

「これからの「正義」の話をしよう―いまを生き延びるための哲学」

■影響をうけた書籍

「ペルソナ作って、それからどうするの？」

「検索と発見のためのデザイン　―エクスペリエンスの未来へ」

「ソフトウェア品質知識体系ガイド―SQuBOK Guide」

「ソフトウェア開発へのSWEBOKの適用」

「IA100 —ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計」

※Webとかセミナーとかは割愛させてください。すみません。

　あとどういう人の話に影響を受けたのかは個別で対応いたします。

当日、聴講したセッションの感想はまた今度書きます。

多分ね。

2011年の野望

2011-02-07T17:17:00.002+09:00

眠いよー。眠いよー。

理不尽なぐらい眠いよー。

眠気覚ましにブログを書きますよー。

「抱負」って書くとなんだか社会貢献とか共通善とかそういう意味が含まれそうなので「野望」にします。いいんです。私は私のために生きているから！

野望１「献本もらう」

　なんかTwitterやBlogで「献本感謝！」とかみると羨ましいじゃないですか。

　しかもそういう本に限って、私も読んでみたいと思えるようなのが多いし。

　というわけで、今年は献本をもらいたい！

　もらったらちゃんとBlog書きます！

　場合によっては読書会を企画します！

　TwitterとFacebookに一週間くらいたてつづけに感想書きます。

野望２「社内外を問わず喋りまくる」

　もうすでにそのようになっているけど、今年は喋りまくる！

　「もうtakelog3000の話は飽きたよ」

　と言われてもしゃべり続ける！

　自分から情報を発信することで、学習の仕方やペースを変えたい。

　あとこれは表現しづらいけど、情報を整理して人に直接伝えることで、

　なんだか言いづらい何かが身につく気がする。去年の１月から意識して

　そういう機会を作ってきたけど、なんか私自身が変わった気がするな。

　もちろん

　「勉強会でしゃべるとみんなから話しかけられて友達が増える」

　っていうのも狙ってます。

野望３「高度情報処理技術者のどれかにうかる」

　チャンスは２回だ。

野望４「今年の後半は英語を勉強する」

　十数年前、アメリカのとあるスポーツショップで

　　客　「おい、こんどシャックがトレードされるらしいぞ。」

　　店員「へー、そうなの。すごいねー。」

　　タケ「まじで？　で、どこにいくの？」

　　客　「レイカーズらしいよ」

　　タケ「えー！　信じられん！」

　っていうHEYブラザー！、YOブラザー！な感じのトークを英語でしてたんだけど、今となってはどんな英語をしゃべっていたのかすらまったく思い出せない…。人の記憶は儚いもんです。

野望５「アメフト（バスケ）トークできる友達をつくる」

　そのための飲み会を企画しようと思う。

野望６「プログラミングをやる。今年こそ。」

　ずっとITにかかわる仕事したいからね。そのための基礎を鍛えないと。

これぐらいがんばれれば、2011年も良い年だったなって思えるよね。

多分ね。

品質管理のおじさん（1/27DevLOVE「受け入れテスト勉強会」）

2011-01-28T17:31:00.007+09:00

1/27(木)のDevLOVEで@RyuzeeさんのセッショのをTsudaっていたのですが、そのTsudaりのなかで

「品質管理のおじさんたちはプロジェクトの終わりの方に来て重箱の隅をつついてもらうのではなく、プロジェクトの初期にはいってお客さんの要求に合わせてテストを設計するべき。 #devlove」

とつぶやいたところ、今の時点でFav20、公式RT44というあまりの反響に驚きつつも、みんなそんなに品質管理のおじさんに対して言いたいことがあるのかと思い、あらためて@Ryuzeeさんの言葉の強さを実感したのでした。

そのあと@haru01さんのステキ過ぎるセッションを拝聴し（「アート・オブ・アジャイルデベロップメント」と「パターン、Wiki、XP」は本当に良い本ですよね！）、ダイアローグに突入。トーキングオブジェクトがヤンジャンで表紙がビキニの夏菜という、違った意味でステキ過ぎる時間を過ごした後、有志で軽く夕飯を食べて（飲んで）帰ったのでした。

今更私がいうことでもありませんが、テストとはその時に何を検証するのかを明らかにすることが大事なのだと実感。
私も、初めて担当したプロジェクトで、お客様のプロジェクトマネジャー様から「それぞれのテストがどういった目的で行われるのかをしっかり考えて計画を立てろ！」と口酸っぱくいわれたことを思い出しました。当時の私は何を言われているのかさっぱりわかっていませんでしたが…。

あと「テスト」ってカタカナが大事なことをピンぼけさせるのかなあ、と。「検証」って言う方がしっくりくるかなあ、と。

ソフトウェアの開発は検証することが多いですね。

講演仕事がつづきます

2011-01-26T00:50:00.004+09:00

ちょっとワケあって、講演仕事が続きます。

2011年2月8日(火)「クラスメソッドが手がけたUXの提案事例」

http://classmethod.jp/seminar/ux/

2011年2月18日(金)「これからのRIAの話をしよう～システムの利用者と開発者にやさしい、UXとUI設計について～」

http://www.seshop.com/se/timetable/2

2011年2月23日(水)「UXを取り入れたこれからのRIA開発」

※サイトは近日公開予定

2011年3月9日(水)「UXを取り入れたこれからのRIA開発（仮）」

※サイトは近日公開予定

いずれもRIAとUXをテーマにお話いたします。

「どんなしったかぶりをするのか、いっちょ聞いてやるか。」なノリで上から目線で聞いていただくぐらいがちょうど良いかと思います。

多分ね。

「プレゼンテーションzen」っぽいプレゼンのやり方が「だいたいわかった」になるエントリー

2010-11-08T10:43:00.019+09:00

「プレゼンテーションｚｅｎっぽいプレゼンのやり方が誰でも１時間くらいでわかった気になるワークショップ」というのをやってきました。

そこで話したこと、話きれなかったことを順を追って説明します。

[リリース版]「プレゼンテーションｚｅｎ」っぽいプレゼンのやり方が誰でも１時間くらいでわかった気になるワークショップ

View more presentations from takehara masashi.

P1-P4 タイトル～注意

「プレゼンテーションzen」って言えばやっぱり画像を多く使って文字数を減らすっていうイメージがあると思うんです。そこでこのワークショップでは、メッセージとマッチする、メッセージを助けてくれる画像を探す作業を体験してもらうことにフォーカスしました。だから「プレゼンテーションzenっぽい」と表現したわけです。1時間であの本なりビデオなりの内容を全部喋ってワークショップまでやるのは無理です。

P5-P9 心得

このワークショップの説明で一番伝えたいことがこれですね。

大事なのは「しゃべり」と「しゃべるあなた」です。

（聴く人も大事ですが、理由を説明し出すと時間足らないから割愛）

オープニングのLTや、他のコミュニティのワークショップでもだいたい同じようなことをいっていた気がします。

（喋りながら聞き耳たててました）

P10- つくりかたあらすじ

SUCCESsは自分なりの例題を紹介したかったのですが、準備が間に合いませんでした。この時点でこのワークショップの説明はConcreteness：具体性に欠けているわけです（苦笑）。

この章では一枚の図を中心に話を組み立てています。

感情が先行して喋り出すと気持ちが空回りして伝わらず、情報を整理して順序立てて説明するとちゃんと伝わる、ということを視覚的にわかってほしくて描いてみました。

P21はクリティカル・シンキングで必ず登場するピラミッドストラクチャーです。分解の仕方はいろいろあるでしょうが、これも視覚情報重視。

P22は情報を取捨選択して順番を決めることを伝えたくて、麻雀パイの画像を貼り付けました。これは我ながら良い例えｗ。同じ麻雀パイでも役が付く付かない、点数が高い高くないの差があるってわかったら、ちゃんと考えますよね。人に何かを伝えるということはそういう面があると思います。

よく「スライドにはとにかく情報を詰め込む。その場の雰囲気をみて、喋る内容を選ぶ。」と言う方がいますが、これはプレゼンテーションに慣れている人だからできる芸当であって、慣れていない人には難易度が高すぎます。またスライドに情報を詰め込んだ結果、時間内で完了することが出来ないこともありますが、この場合、聴講者のほとんどは集中力が切れています。集中していない人に一所懸命に語りかけたところで何も伝わりません。アンコールみたいなもので、聴講者も得したと思うはず、と考えているなら勘違いです。ロックスターなみに熱狂をもって迎えられる講演者なんてほとんど存在しません。

時間内で伝えきること、そのためには情報を取捨選択し、適切な順番に並び替え、冗長な言い回しを避け簡潔な表現に直し、言葉より視覚的に訴えた方が伝わるのなら迷わず写真を探したり図を作成してください。これらを意識することでプレゼンテーションの完成度はぐっと上がるはずです。

P25- ターゲット

「ターゲットを絞る神話」は実際に仕事でも感じたことです。

絞りすぎること、特定しすぎることで大事な何かがなくなったりします。曖昧ですが…。

P31- つくりかた演出／スライド

心得のところでも説明したのですが「パワポ作る」とか「スライドつくる」って表現はなんか気持ちが悪いのです。自分でも言っちゃうときがあるけど。

スライドは演劇における舞台装置だし、戦いにおける武器だし、登山における杖みたいなものだと思います。喋る人の助けにはなるだろうけど、喋る人以上ではありません。たまに本人とスライドの主従逆転プレゼンを見かけることがあり、そういうときはなんとも言えない気持ちになります。私も以前は間違いなくそうでした。

そうは言っても、自分を助けてくれるものだし、演劇だったら舞台装置が豪華な方が演じていて気持ちが良いじゃないですか（多分）。だから、主従が逆転しない程度に、自分をより良く演出してくれる存在として、スライド作りに注力することも必要なのかと。

（↑テキストをベタっと貼った状態）

（↑リリース版。写真や図がかなり増えている）

実際の作業については百聞は一見にしかず、画像で見てもらうとわかりやすいですね。今回のワークショップのスライドの作業着手時と完成版の一覧表示を見てください。最初はテキストをベタ貼りです。これを少しずつ要約したり、画像に差し替えられるところは差し替えたりしています。

P42- 喜怒哀楽

印象に残る物語は受け手の喜怒哀楽に振り幅を持たせています。

実は映画やドラマのストーリーの多くは凡庸で冷めた目で見るとどれも似たようなパターンにはまるのですが、それらは主人公たちを理不尽な境遇に追いやったりして視聴者の共感を誘うことで凡庸ではなくなります。怒りと哀しみに訴えかけ同情を買うのです。

逆の場合は面白おかしくすることで笑いを誘ったり、特殊な演出によって爽快感を生み出します。これらが喜怒哀楽に振り幅を持たせる、ということです。

プレゼンテーションについても近いことが言えて、どれほど良い情報を聴講者に伝えたとしても、そこに喜怒哀楽の振り幅がなければ印象に残りません。下手をすると「つまらなかった」と言われかねないのです。

そこで喜怒哀楽に振り幅をもたせる仕掛け（演出）が必要になります。

とは言っても、プレゼンテーションの場であまりにも怒りや哀しみの感情に訴えかけるのはやりすぎな気もするので、さりげなく笑いをとりに行く方が良いです。

ただし狙って笑いをとるのは難しい。それには場数を踏んで、どういったネタが喜んでもらえるのかを感覚として掴んでいく必要があります。もちろん天性の才でどっかんどっかん笑いをとる人もいるでしょうが、自分もそうだと思わない方が身のためです。笑いを扱うにも技術がいるのです。だから「ネタは扱える分まで」と考えましょう。前後関係を考え、微妙と思われるタイミングであれば削る勇気を持ってください。

P49- ペース

「Sec/Page（せっくぱーぺーじ）」は目安としては悪くないので是非使ってみてください。

プレゼンテーションの多くは制限時間内で終わりません。途中から急ぎでしゃべり始めるし、LTは時間が足らないことが度々あります（ドラ娘の出番です！）。時間内で終わらせる、ドラがなるどんぴしゃのタイミングで終わらせる、そのためにはペースを把握しましょう。

またじっくり説明するページに対して、ポンポンとめくってテンポを良くしていくページがあるのも効果的です。メリハリが効くことで、聴講者も飽きずに聴くことが出来ます。

P56- アニメーション

アニメーションやエフェクトは最小限にとどめる方が良いです。

様々な理由あります。

・まず動くものをスライドに出現させることで、聴講者の意識がそっちにいってしまう、肝心のしゃべりが伝わりづらくなる懸念。

・アニメーションは一定の時間が必要なので、ペースに影響する。その場に併せた臨機応変な対応に制約がかかる。

・スライド編集の難易度が上がる。

個人的にはアテンションで使う程度にとどめるのが上手いつきあい方だと思っていますが、世間にはグリグリに動かして楽しいプレゼンテーションをされる方もいらっしゃるので、必ずしもアニメーションをオフにしろとは言いません。

P63-P71 練習、手直し

とにもかくにも実際に声を出して確認をすることです。

多くの場合、私も含めてですが練習は嫌なものです。なんだか間抜けな感じがするし、途中で詰まったりして気分が良くありません。しかし、ここが大事です。練習ではたいてい詰まるのです。話慣れないことを喋るために体が（口が）付いてこなくて詰まること。しゃべりの内容に整合性が欠けていて自分で違和感を憶えて詰まること。これらは実際に声に出して練習することで気付くことが出来るし、本番でこういった問題に遭遇する確率をぐっと下げます。少なくとも1回、できることならスラスラと自然に喋れるようになるまで練習をしてください。やったかやってないかで結果は全然違います。

ここで注意ですが、業界を問わず、凄腕のスピーカーは「練習なんかしない」と言い切ってしまう人がいます。それはそれで構いませんが、人は人、自分は自分です。自分が最も上手くできるプロセスを模索してください。多くの人にとって、それが「練習なんかしない」になることは滅多にありません。「あのスティーブ・ジョブズでさえリハーサルをやっている」と思えば、人知れず練習をすることは恥ずかしいことでも何でもありません。貴重な時間を投資してくれている聴講者に対する礼儀です。

練習の段階でレビューを入れるか、入れないかは自由です。できれば入れた方が良いでしょう。しかしここにも落とし穴があって、よくわかっていないレビュアーが存在します。よくわかっていないレビュアーはそもそものコンセプトに否定的な意見を出し、講演者を混乱に陥れます。ですのでレビュアーは慎重に選んでください。もし適当な人が周りにいたいのであれば「ぼっち法」で乗り切ってください。

P72 伝えるためのプロセスを描いた図

ここで図は完成です。練習はしゃべりにも演出にも作用します。

練習以上のことは本番ではできません。実際は緊張と極限までの集中力が奇跡的なパフォーマンスを生み出すこともありますが、それは希です。

また図示したために段取りを追えばプレゼンテーションができそうな気がしますが、実際には卵と鶏みたいにあらゆる情報が錯綜し相互に関係し合います。手戻り作業は当たり前ですが、完成度を高めるためだと思ってがんばってください。

P73-P78 本番のコツ

なるべくリラックスし、自然な状態で語りかけるようなプレゼンテーションが理想的ですが、最初からそのようにできるとは限りません。カチカチになって喋る内容をわすれてしどろもどろすることもあります。私なんかは本当に酷くて、途中から声がでなくなったりしたこともあります。

何人か、場合によっては大勢の聴講者の前で緊張をするのは自然現象です。避けられません。ですから緊張すること自体は受け入れてください。そしてコントロールするように心掛けてください。

「照れ」や「恥ずかしい」といった感情もあります。ですが、これは打ち消してください。講演者が恥ずかしがっていると聴いている方はもっと恥ずかしいものです。そんな態度で披露したネタがスベったときにはもう！大惨事の始まりです。これを克服するのにもぼっち法は効果的です。是非、試してください。

そしてなるべく多くの本番を経験してください。ここで言う経験とは「人前で喋ること」です。

仕事、学校、地域コミュニティ、お子さんがいらっしゃれば保育園や学校の集まり、親戚の集まり…、飲み会の乾杯、いろいろあります。是非、積極的にそういった場を活用して喋ってください。たいていの場合、みんなはそういった勇気を持った人を受け入れてくれるし歓迎します。手を挙げた心意気に賞賛の拍手を送ってくれるでしょう。ただし話が長くなければです。ライトニングであることが大事ですね♪

P79- ワークショップ

このワークショップを企画したときは「KPT」について話してもらおうと考えていましたが、DiscoveryCoachさんとquindimさんからアドバイスをいただき、好きなものを説明してもらうに変更しました。これは大正解でした。お二人には本当に感謝です。

今回はあくまで「プレゼンテーションzenっぽい」プレゼンのやり方を体験してほしかったので、メッセージと画像を組み合わせる作業に特化しました。その楽しさがわかってもらうことが第一目標。実際にプレゼンテーションzenの本やDVDで説明されている内容はそれからで良いのかな、と。当日はワークショップに40分くらい使ったと思います。できれば1時間あると、お互いのプレゼンテーションに対する意見交換もできて良かったのですが、それはまたいずれどこかの会で。

P90-P95 画像を選ぶ

以前、DevLOVEのLTでやった闇アジャイラー（動画、スライド）のオチ画像で比較をしてみました。プレゼンテーションzenの本にでてくる比較画像だとあきらかに片方はありえんわ、というケースがほとんどなのですが（画像の使い方を説明しているので）、この4枚なら狙いによってはどれでもアリだと思います。個人のこだわりを前面にだしたければナウシカだし、キレイにまとめて良い話っぽくしたいなら木漏れ日です。しかしこの時はインパクトをとりました。タイミングもばっちりでしたし（マイクロソフト台湾がサイトリニューアルしたのはDevLOVE Energized Workの前々日くらい）。ちなみにあれから2ヶ月近く経った今でも「やっぱりキレイにまとめておくべきだったのではないか」と思うことがあります。

P96-P99 まとめ

まとめて言いたかったことは下記。

・プレゼンテーション作りには段階があること。大切なのはしゃべり。

・伝わることが大事。どんなに良いこと言っても伝わらないなら意味がない。

・今日スベっても明日があるさ。迷わずスベれ。スベればわかるさ！

P100- おまけ

おまけにはtipsみたいな情報を書いておきました。時間がなくて説明できなくても、あとでスライドを見てもらえればだいたいわかるかなー、みたいな。

良いプレゼンにはここ最近見た中で印象に残ったものを載せました。

どのプレゼンも型破りで聴講者に対して強いインパクトを与えます。そうすることで印象づけられ記憶に残ります。

本当は「提供クラスメソッド」も紹介したかったのですが、なんとなく割愛しました。もしE社関係の方がこのエントリーを読んでいらっしゃったら、私のパクリに許可をいただけますでしょうか？

スライドのレイヤー構造はスライドの再利用性を高めることを目的でやっています。真ん中に入る「実際の背景」がキモです。今のところ、この方法でレイアウトが壊れたことがないので、多分、イケるんじゃないかなあ。スライド作成は時間がかかります。生産性を高めるには再利用しかないだろうというのが今日この頃の考えです。

無料フォトサイトはプレゼンテーションzenに記載されているサイトに最近知ったサイトを追加して載せました。こういったサイトを知っておくのも良いのですが、使えそうな画像は普段からDLしたりURLをメモったりしておくのが吉です。ただし権利とかには注意してください。

Slideshareをやろう、っていうのはこのワークショップで最も言いたかったことなんじゃないかと思っていますｗ。人から学べることは多いです。また公開したスライドがどう受け取られているのかはview、favs、downlords、tweets、sharesあたりからなんとなーく知れます。

参考資料にはもちろん「プレゼンテーションzen」シリーズが載っています。当日、他の方もプレゼンテーションzenをかなり薦めていたようです。すごい人気。強いて言うなら、読んだだけでは何も変わりません。読んで見よう見まねでいいからそれっぽいことをやってみることが大事です。

またプレゼンテーションzenはプレゼンテーションがどうあるべきかを説明しているのに対し、「パブリック・スピーカーの告白」はその背景にはどういったことがあるのかを説明しています。ワークショップの1週間前に入手してゆっくり読んでいます。良い本です。スコット・バークンさんの失敗談で腹筋が壊されそうになります。

目指すべきところが「プレゼンテーションzen」で、その過程が「パブリック・スピーカーの告白」だと思ってください。両方ともオススメです。

あと「Webレイアウトの「解法」」が参考資料に含まれていることに驚く人がいるかもですが、レイアウトに規則性をもたせることで見た目が良くなることを学んだのはこの本なので載せました。矢野さんの本もオススメです♪

それと「XP祭りの基調LT」は動画がアップされています。是非、見てみると良いでしょう。私の説明よりはるかに良い内容です。

ボツ

実は私が人前に出て話すことをちゃんとやるようになったのは今年の1月からでまだ1年経っていません。マーケティングの仕事は7月からです。初心者なりにいろいろ試行錯誤をしてきました。その結果がこのワークショップです。だからもっと良い方法を知っているよ、という方がいらっしゃったら是非、教えてください。

このページはワークショップに参加してくれた方たちにとって、私が初心者であるなんていう情報はなんら有益ではなくただのノイズだからボツにしました。

だいたい以上です。

ああ、長かった。こんなの最後まで読む人いるかな？

それとこのエントリー「あとで新聞」とかにのらないかなｗ？

駄文に最後までおつきあいいただき誠にありがとうございます。

闇アジャイラーの影でボツになったネタ

2010-10-03T21:26:00.012+09:00

10/1(金)のエントリーでも書いたのですが、DevLOVE Energized Work!」で「闇アジャイラー」というネタLTをしてきました。

[Slide]闇アジャイラーvs光アジャイラーforDevLOVE(EnergizedWorkLT祭)

View more presentations from takehara masashi.

諸処の事情でボツにしたネタやスライド、そもそものLTの背景などをメモしておきます。

■「闇アジャイラー」について（P2-P11）

・なんで「闇アジャイラー」なのか？

冒頭で説明したとおり、XP祭の翌週、ネット上でにわかに盛り上がっていた「闇プログラマー」にインスパイア(笑)されました。アジャイル原則と架空の闇アジャイル原則を比較したらそこそこ笑ってもらえるだろうか、と。

実際のところはただ単純に闇アジャイラーって言いたかっただけなので、そんなに深いねらいはありません。LTだから出オチでいいだろう、という程度。

・カットしたスライド

当初、アジャイル原則と闇アジャイル原則の比較はもっと「エグい」話を入れていたため保険として入れておきましたが、エグい話はカットしたので不要となりました。

きっとみなさん律儀にEnergized Work!の話をするだろうなと予測しました。LTで14回もEnergized Work!の話を聞いたら参加者はみんな飽きるだろうと判断しカットしました。実際、Energized Work!については一言も喋っていません。

しかしテーマとしては外していないつもりですし、闇アジャイラーはEnergized Work!の障害の一種です。

「闇アジャイラーかわいいよ闇アジャイラー」

実は平鍋さんバージョンもあったのですが、ご本人の前でやるのは気が引けたのでカットしました。

■アジャイル原則と闇アジャイル原則の比較(P12-P19)

アジャイル原則は全部で12項目あので、闇アジャイルバージョンも12項目すべて作りましたが、しつこいのとエグすぎる（笑えない）ため4項目を残してカットしました。尚、アジャイル原則は言い方がいろいろあり、日本語訳も何種類かあるようです。

アジャイルを表面的に都合良く解釈して関わるメンバーに無理強いをさせる、前言を翻すためにアジャイルをもちだす、そういう人に対して言いたいことがあったりなかったり（※フィクションです）。

■【図解】闇アジャイラーが生まれるまで(P20-P45)

小ネタ（「絶対領域」、「すまぬ…すまぬ…」、「だが断る」）を仕込んでいますが結構まじめな話です。

「曖昧領域／調整領域／絶対領域」

twitter上で「あいまいなことが多すぎてプロジェクトの見通しが悪い」みたいなことをつぶやいたときに「あいまいなものはなくならない」ととある方がおっしゃいました。あらためて考えると確かにその通りで、プロジェクトの特性（独自性、有期性、段階的詳細化）を考えてみてもあいまいなモノゴトが存在するのは確かです。

しかし本当にマズイのは、あいまいなモノゴトを都合良く解釈したり、思い込みがあったり、またほのめかしをしたりすることで、それがステークホルダーで共有されていないことです。この「曖昧領域／調整領域／絶対領域」の図ではプロジェクトの様々な情報がどのような状態にあるのかを可視化することが大切であることを言いたかったのです。これはPMBOKのプラクティスが全てプラクティスの前後にインプットとアウトプットがあることがヒントになっています（それだけじゃないよ）。

加えると曖昧だから見積もれない、計画できないということもよくあるかと思いますが、そんなことはありません。確定していることは少なからずあり、それがあるのであればそれを制約として利用するという発想ができるはずです。何をしたいのか、何ができるのかをステークホルダーでちゃんと共有しましょう。

話はそれからです。

私が関わったとあるプロジェクトですが、そのプロジェクトでは技術はほぼ初めて採用するもの、期間は半年以上、検証をしつつ本番実装をする、ユーザー数未定、実装する機能も未定といった条件で見積もりと計画をつくったことがあります。その際、こちらの確保できる工数を伝え1ヶ月ごとのタイムボックスを切り、その都度、優先順位付けをしてスコープを検討し、見積もりを提出していく手法を提案して採用されたことがあります（この時はアジャイルじゃなくて統一プロセスを参考にしましたが）。毎月精査な見積もりを提出するのは本当にしんどかったのですが、プロジェクトの進め方としては悪くなかったと思います。

これはアジャイルや統一プロセスなどについて書籍を通じて学んでいたからできたことです。たとえ形式知のレベルであっても日々学ぶことで何かの役に立つことは多々あります。

また書籍のよいところは形式知化されているため他者に伝える際、伝え方の参考になることです。「わかっていはいるし実践もできるけど説明ができない」ことありませんか？書籍を通じて体系的な形式知を学ぶことで助けられるはずです。

ところでこの「曖昧領域／調整領域／絶対領域」の図ですが、こういった情報を意識して共有することが大切なのでこの図や言葉を使う必要はありません。

貸借対照表のような書き方をするのも面白いかもしれませんね。

■ プロセスからオチまで（P46-P58）

プロジェクトは以下の特性を持っています。

１．独自性

２．有期性

３．段階的詳細化

これをちゃんと理解しているのであれば、万能なプロセスがないことはわかるはずです。

ウォーターフォールが悪いのではなく、ウォーターフォールが適さないプロジェクトを無理矢理ウォーターフォールにあてはめることが悪いのです。これはアジャイルもそうです。

様々なプロセスについて論じること自体は嫌いではありません。むしろ積極的に飛び込んで意見を出したり聞いたりすることは好きです。でもちょっと皮肉っぽくきのこ厨vsたけのこ厨の話を引き合いに出しました。

ちなみに私はtakeだけにたけのこ派です。

・カットしたスライド

「ガンプラ」

私がプロセス偏重の危険性を説明する際、よく使う喩えなのですが時間の都合と、そもそもガンプラの組み立てはアジャイルである必要はなく、話の流れの中で違和感が生じるためカットしました。

「曇りなき眼で見定めてプロジェクトを計画すること。」

スライドは残しましたが画像はカットしました。オチにでてくる光のインパクトを最大化したかったためです。

「不確実性のコーン」と「ブルックスの法則」

不確実性のコーンはネガティブな印象を持ちそうですが、これはプロジェクトの曖昧なモノゴトを明確にしていくという学習プロセスを象徴したものだと思うとなかなか良い図だと思います。しかし初期段階における不確実性を無視することで曖昧なモノゴトの暴走を許します。

ブルックスの法則に対する無理解こそが、人を機械部品のように扱う闇アジャイルの最たるものだと思います。

いずれも時間都合でカットです。

「光のアジャイラー」

このLTのオチになるところですが、３つの候補画像からどれをどのように使うかで悩みました。

１．森の中に光が差し込むパターン

２．ああっ女神様のベルダンディーが輝く地球のようなものを抱えているパターン

３．風の谷のナウシカが「いのちは闇の中にまたたく光だ！！」と言い切るシーンのパターン

無難に１．でスライドを作っていたのですが、本番の前日にMicrosoft台湾が光をリリースしたことによりあのようになりました。これは完全にラッキーですね。

いつも使っているThank you Marioのページ、Let'sで始めたらwith meはいらないよね。今更だけど恥ずかしいミスです。。

■さいごに

再度「曖昧領域／調整領域／絶対領域」

闇アジャイラーも2つのパターンがあって、一つは1人のリーダーやマネジャーによってもたらされるとき、二つめは関わる人の多くが暗黙的な考えや振る舞いによってもたらされるときがあると思います。

今回のLTの図では、闇アジャイラーが生まれる直前、カオス状態になって全員が「死ぬまで働けば」と思い詰めてしまいます。それは時間が経つと、その状態に否という人に対して攻撃や排除をし始めたりします。過剰な残業が常態化している組織であるのかもしれません。

個人的には1人のリーダーによってもたらされる闇アジャイルよりも、チームメンバーが暗黙的にやっている闇アジャイルの方が多くの不幸を生み出す気がします。これは組織の文化であることもあるので根深い問題です。

もしそういった状況におかれている方がいたとして、その方が「Energized Work!」を知って何かが変わり始めれば良いな、と思います。

DevLOVE Energized Work! のLT祭のまとめ

2010-10-01T14:46:00.017+09:00

【追記】

当日の動画はこちらへアップされています（鋭意追加中とのこと）

http://www.youtube.com/view_play_list?p=1080389D7DD578A0

平鍋さんのスライドは@daipresentsさんのblogから閲覧できます。

http://daipresents.com/weblog/fujihalab/archives/2010/10/devlove-energized-work.php

9/30(木)に行われた「DevLOVE Energized Work!」のLT祭のまとめです。

LTは一般的には5分で行うのですが、この日は何故かLTer数が多く、各自持ち時間わずか3分で喋る「ULT（ウルトラライトニングトークス）」となったのでした。

とりあえず、ざっとしらべてわかった人のスライドだけ載せてあります。

この後アップした人はTwitterでつぶやいていただけると助かります。

1.@jun116

　「Energized Work タイプ別分析」

　http://www.slideshare.net/jun116/energized-work-for-devlove-5349702

2.@amameci

　「祭人Hacks」

　http://www.slideshare.net/amameci/hacks-5334036

3.@mtg0003

　「いつか神保町に本が詰まったビルを持ちたい DEVLOVE ENERGIZED WORK !」

　http://www.slideshare.net/mtg0003/devlove-20100930

4.@fkino

　「活き活きとした仕事」

　http://www.slideshare.net/fkino/energized-work

5.@kaji_3

　「DevLOVE energized work! 」

　http://www.slideshare.net/kaji3/kaji3-devlove-energized-work

6.@take3000

　「闇アジャイラー」

　http://www.slideshare.net/takelog3000/slidevsfor-devloveenergizedworklt

7.@kohsei

　「婚活メソッド」

　http://www.slideshare.net/iwakiri/ss-5327426

8.@oitomo

　「実証実験レポート～人を活性化するモノは何か?～」

　http://www.slideshare.net/oitomo/devlove-20100930-oitomo

9.@kawasima

　「寝プログラミングのススメ」

　http://www.slideshare.net/kawasima/ss-5356865

10.@yujiorama

　「develove_20100930_yujiorama.pdf」

　http://bit.ly/ckCNig

11.@ymkz303

　「とあるチームの開発事例」

　http://www.slideshare.net/ymkz303/20100930-devlove-enagilized-work

12.@chachaki

　-UNKNOWN

13.@kawaguti

　「Energized Workに向けて、あなたが今日からできること」

　http://www.slideshare.net/kawaguti/20100930-dev-love-energizedwork-lightning-talk

14.@quindim

　「#○○○love」

　http://www.slideshare.net/TakuYajima/udonlove

個人的には司会兼務でLTのトップバッターを務めた@jun116と、DevLOVEの「ミニ」ドラ娘の@kuni02の2人がMVPだったような気がします。

[DevLOVE]iPhoneアプリ構築＋管理勉強会「本当にあった怖い話」の開催しました。

2010-09-03T20:20:00.006+09:00

何で企画したのかって、本当は@jun116がお願いしたんですけどね(笑)

[Slide]DevLOVE iPhoneアプリ勉強会の【前説】※本編は未公開です！

View more presentations from takehara masashi.

LTで言いたかったことは、一応、結構、真面目な話です。

（SilverlightUGきてください、のとこじゃなくてｗ）

App Storeの登場によって個人でビジネスをやっていく土壌がものすごく進んでその世界でがんばっている人がいて、そうすると相対的に自分の立ち位置とか考える機会になるだろうな、と。

私は高校生の時、この世界で刀を振っていくのは無理だって思いました。

それでも縁があって、それとなんだかんだ言ってもIT好きだったから、この世界にいるわけで、やっていく以上、サラリーマンとして、つまりマネジメントとしてやっていく覚悟をもっています。

だからそれなりにこだわりあるしね。

それと一応、補足しておくとサラリーマンとフリーランスを否定してません。

組織を上手く使って己のスキルにレバレッジかけるのもありだし、素早く次々と新しいことをやるのも良いと思います。

本人の選択だと思ってます。

ま、そんな私の話はどうでもよくて、今回も良い感じにできて良かった。

@tilfinさん、@kotamzに感謝。

@jun116、@mtg0003、@kuni02に感謝。

それと参加してくれた#devloveな皆様に感謝。

Adobeさんとの共催セミナーで司会・進行・運営をやります。

2010-08-31T10:04:00.003+09:00

Adobeさんとの共催セミナーで司会・進行・運営をやります。

【ビジネス編】Flex × Java 業務システム改善セミナー

http://classmethod.jp/seminar/flex-java-day/

【デベロッパー編】Flex × Java 業務システム改善セミナー

http://classmethod.jp/seminar/flex-java-after/

どちらも明日9/1(水)です。

今回のセミナーはビジネス編、デベロッパー編と対象者を分けてダブルヘッダーにすることにしました。私が知る限りでは新しい試みのはず。

運営側としては大きな会場を借りて1回で済ます方が楽です。

しかし、私達の想いとしては、ご来場された方と少しでも多くのコミュニケーションを、それも一方通行ではない双方向の対話の場を作りたいと考えました。

私個人の経験ですが、印象に残る勉強会やセミナーって参加者は少ないけど、発表者・受講者の双方から意見や質問がガンガン飛び交うようなものが多かったと記憶しています。

明日もそのようになれば良いと思うし、そうなるような雰囲気作りに努めるつもりです。

至らぬ点は多々あるかと思いますが、皆様のご来場をお待ちしております。

ナナナナ会　30±10代しゃべり場LT　「エージェント、Help、XP」

2010-08-27T20:43:00.006+09:00

事の発端は@mongchangさんが仕事との向き合い方、距離の取り方について、いろんな人の意見を聞きたいぜ＋話したいぜー、と言ったつぶやきをしていたので、じゃあ、それナナナナ会でやろうよ、ということにし、@papandaさんをはじめとする#devloveな人達を巻き込んでLT大会＋ディスカッションをする会をやってみました。
そして自分もLTをやってみました。

[Slide]しゃべり場LT「エージェント、Help、Xp」
View more presentations from takehara masashi.

このプレゼンテーション、実はすごい難産で、映画「ザ・エージェント」を引き合いにして、私なりに仕事と生活についてどう思っているのかを面白ろ可笑しく話そう、というコンセプトはするするとできたものの、そこから納得感のある話、スライドを作るのにすんごい時間かかった。もう、途中、無理じゃないかと思うくらい。

物質、精神とかを卓越した幸せを表す言葉として「クワン」をキーワードにし、運良くディスカッションでもそんな話ができたので個人的には良かったです。

※注意
この定義は映画「ザ・エージェント」と書籍「パターン、Wiki、XP」に登場する無名の質としてのクワンを、私が強引に抽象化したものなので適切かどうかは微妙。プレゼン作るのに手こずったのは、この抽象化に納得感を持たせるのが、私としては非常に難しかったから。

ディスカッションではいろんな話をしたし、話を聞けた。

いくつかメモっておくと、

デスマの我慢の仕方は？
お金って？
技術者はサラリーマンでOK？
何が大事？
男女で違いある？
IT業界にもスーパースター的な高額所得者いてもいいのでは？
育てていく意識

などなど。

（誤解を生みそうなのは伏せておきます）

LTも含めて、本当に、録画しておくべきだったと後悔するぐらい良い話がたくさんあった。あったなぁ。

さて、次ですが…。

コミュニティ活動をがんばることによって引き起こされる「ご家庭デスマ(by @papandaさん)」について話すのも良いかも。

ナナナナ会自体は@mtg0003企画の「お絵かきナナナナ」の予定です。

最後に、この会に参加した人、参加できなかった人、端から参加する気もなかった人、だまされたと思って「クワン」について考えてみると良いですよ。

多分ね。

【業務連絡】「30±10代しゃべり場（ナナナナ会）」のおしらせ

2010-08-25T16:43:00.002+09:00

「30±10代しゃべり場（ナナナナ会）」のおしらせ

■開催概要

　日時：2010年8月27日(金)19:30～21:30

　場所：クラスメソッド株式会社セミナールーム

　主催：ナナナナ会

　参加費：割り勘

　（ビールとピザ程度を用意します）

　対象：30±10代のIT関係の人

　テーマ:仕事と生活のバランスについて語り合ってみよう

■アジェンダ

１．はじめに（5分）

２．自己紹介（10分）

参加者全員で順番で行う

３．LT&ディスカッション（5分＋15分）×4～6くらい

（順番は当日の雰囲気で決めます）

４．ご歓談

５．お開き

６．（希望者で）近所の居酒屋で反省会※別途実費

受付に張り紙をしておきますので、そちらの案内にしたがって

セミナールームまでお越し下さい。

お問い合わせは@take3000にD下さい。

take3000アンオフィシャルブログ「たけはらですが？」

Web Memo 20120128

マーケターのひとりごと

道

【備忘録】2012年の目標や方針

何故「勉強会アワード」なのか

2012年の妄想

＠IT自分戦略研究所に記事を書いたよ「第1回 初心者のためのLT作成講座――まずは構成を練る」

Effective 情報発信

就活生の金太郎飴状態に原因は他にあるのではないかと思う

DevLOVE ADVENT CALENDAR に記事を書きました

「これからはモバイルでデスクトップはオワコン」みたいな主張に思うこと

「起きたことはすべて正しい」

そういえばさ

反省

ツールがサブスクリプションになる件について一言いっておくか（妄想）

セミナーの告知が完了

レポートにまつわるエトセトラ

[備忘録]自分のタスク管理

HTML5、Flash、Native をそれぞれいつ使う？

節操ナッシング

【ネタ】プレゼンの熟練度

プレゼンで使う画像の探し方について

成功要因が数値化できることだけで構成されているわけない

書店と出版と書籍の未来について思うこと

【毒】ﾎﾞｿｯ

会社を辞める理由ねぇ…

XP祭り2011の個人的な感想

スピーカー仕事「ここまで出来る！自動生成ツールを 取り入れたこれからのRIA開発」

「会社ブログはじめました」のお知らせ

デザイン、デザイン、デザイン…

裏方ワーク（クラウドEXPO、DevLOVE HangerTalks／HangerFlight）

縦サミの補足

「星の屑」がおわった

「クラスメソッド春の集中講座」のおしらせ

BizRIAカンファレンスの感想（１）「MONEX VISIONβ」事例紹介

Effective UIにでてくるEngagement in Softwareの図

デブサミ2011で知ったかぶりを晒してきた件

2011年の野望

品質管理のおじさん（1/27DevLOVE「受け入れテスト勉強会」）

講演仕事がつづきます

「プレゼンテーションzen」っぽいプレゼンのやり方が「だいたいわかった」になるエントリー

闇アジャイラーの影でボツになったネタ

DevLOVE Energized Work! のLT祭のまとめ

[DevLOVE]iPhoneアプリ構築＋管理勉強会「本当にあった怖い話」の開催しました。

Adobeさんとの共催セミナーで司会・進行・運営をやります。

ナナナナ会 30±10代しゃべり場LT 「エージェント、Help、XP」

【業務連絡】「30±10代しゃべり場（ナナナナ会）」のおしらせ

＠IT自分戦略研究所に記事を書いたよ「第1回　初心者のためのLT作成講座――まずは構成を練る」

スピーカー仕事「ここまで出来る！自動生成ツールを取り入れたこれからのRIA開発」

ナナナナ会　30±10代しゃべり場LT　「エージェント、Help、XP」