2008年5月27日火曜日

ズルはいかん

そんな感じの記事ですね

「倒産を招きかねない11の愚かなビジネス判断」
http://builder.japan.zdnet.com/news/story/0,3800079086,20373952,00.htm?ref=rss

[memo]おもてなしとコーヒーポット

ドバイでは「コーヒーポット」には「おもてなし」
の意味が込められている、

という話を世界ふしぎ発見!でやってました。

> > Q3もてなしの精神の象徴にし、大切にされているものとは?
> >
> > A:ポット(コーヒーポット)

http://television.ti-da.net/e2033584.html

JavaでRIAでユーザーエクスペリエンスなことやっていると人には「へぇ~」が高いトリビアだと思いませんか?

[Microsoft Office Project]MSPがやらかした

日経SYSTEMS6月号で「開発支援ツールの利用実態」という特集やってます。
去年もやってましたね。

そこで我らが(?)Microsoft Office Projectが利用数でぶっちぎりの一位を獲得したものの、総合満足度「58点」というなんともしょっぱい結果をたたき出しました。

そうね。
たしかにね。
作法はうるさく融通聞かず。
かゆいところにまったく手が届かず。

でもツールのせいだけじゃないはず。
利用者はプロジェクトというものがそもそもどういったものなのか、どういった特徴をもつのか等を理解しているのだろうか?
プロジェクトがわかっていないのに、MSP使いこなすのは無理なはず。
Javaわかんない人にEclipse使わせてもJavaのプログラミングできないし。

じゃあ、タケがそもそもプロジェクトを理解しているか?

NO!
まったくわかりません!!
でもMSP普通に使えます!





あれ?

2008年5月25日日曜日

[memo]ショートカット

プログラミングをしようがしまいが、生産性向上の手っ取り早い策だったりもする。

http://alfalfa.livedoor.biz/archives/51299744.html

ソフトウェア開発会社の文化

「3年で辞めた若者はどこへ行ったのか (城繁幸 著)」
インタビュー集? 他業界の人と接する機会が少ないので勉強になった。


「ソフトウェア開発者 採用ガイド (Joel Spolsky)」
いま読み途中。
ワロス。電車の中でニヤニヤしてたり。
採用する側だけでなく、採用される側のエンジニアが読んでみても良い気がする?
時間があれば。


たまたま人材系の本が連発しました。

そして思うのがソフトウェアの開発をやっている企業がどういった「文化」を持つのが良いのか?みたいな。

組織としての効率性を上げていくのならある程度の規則や「型にはめる」ことは必要。
しかしいきすぎれば自由な発想や意見交換の場を失う(→いわれたことだけやる)。
そもそも仕事詰めすぎれば自由な発想や意見交換の時間をもなくなる。
その場合、遅かれ早かれ起業時にもっていたとがった部分がなくなる。
それの行き着く先は…?

n○dさん(伏せ字になってない)が「この業界は人が大事だ」って話してたなー。
そりゃそうなんですよ。
設備に投資できるお金はたかがしれているし。
「究極の指示待ち野郎(from「ウチのシステムはなぜ使えない」)」のコンピュータさんは人がいなけりゃなんもできないし。
ノウハウの共有や文書化だって限界がある。
結局、人の頭の中に蓄積される。

人! 人! 人!

人がいなけりゃなんにもできないどころか、「その人」がいないとなんにもできない。
ソフトウェア開発はそういう特徴を強くもっているのでは?
ものすごい難易度の高いプログラムを、新人プログラマ100人集めて書けるのか? 無理でしょ。

Joel曰く、
「(省略)必要な技術書は何でも自由にAmazon.comで注文させるべきだ。」
とのこと。
良いこと言った!
スゲー良いこと言ったよ、Joel!!

…話がそれた(本音が出た)。
ていうかまとまらん。

ま、タケにはいかなる決裁権も発言権もないですが。

2008年5月7日水曜日

[RIA][memo]RIAのメリットというかを殴り書き

青いこと書いてたなー。。。。。。


以下、本文



ビジネス視点のRIA活用

①RIAによるビジネスメリット
②RIAに取り組むには?
 ~コンサルタント選びのポイント~
③RIAプロジェクトの進め方
 ~現物主義~
④RIAの保守・運用
 ~攻めの保守・運用~


全体を通じて
・ユーザー視点のアプローチ
・テクノロジー中心のアプローチ
の両方が必要であることをテーマとする

①RIAによるビジネスメリット

ユーザー視点と管理者の視点で考えること
ユーザーは使いやすい、楽しい、仕事がはかどる
管理者は管理が楽になる
これらはシステムを使うための目に見えづらい負担からの解放
システムを使うための苦労が減る分、ユーザーは一件でも多くの仕事をこなすし、あるいは高品質なサービスにつながる。
管理者は次の改善策、運用策を考えることができる。
繰り返すがRIAはかかわる人間に対し、システム利用時にまつわる「使うための負担」を下げ、より本来の業務に注力
できるようにする技術である。またそれを強く意識して活用されるものである。

②RIAに取り組むには?
 ~コンサルタント選びのポイント~

RIAのプラットフォームベンダ(AdobeやMicrosoftなど)に相談をすると「開発経験のあるベンダーのサポートをえてください」となることがおおい。
その言葉に従いキックオフ。でも何故かプロジェクトの進捗が芳しくない。
もしかしたらそのベンダーの経験領域の外の仕事をしている可能性がいあります。
たとえば一口にFlashといっても、エンジニアのタイプには下記があります。

Flashデザイナー/アニメーター
→Web上のコンテンツなどを制作する人。使用ツールはFlash CS3
Flashデベロッパー
→ActionScriptを記述してプログラムを構築する人。エンジニアの数は非常に少ない。
Flexプログラマ
→FlexBuilderを使ってプログラムを構築する人。じつはFlexプログラマの中にも
・Mxmlに強い人
・ActionScriptに強い人
・サーバー側との通信部分に強い人
などの種類がある。
UIデザイナー
→アプリケーションのユーザーインターフェースデザインについて設計、構築する人。Flexプロジェクトだとmxmlを書くことも多々あり。
 またUIデザインから要件を詰められる人はいなくもないが希少人種
サーバーサイドのエンジニア
Java、PHP、.NET、等々のLogicを作る技術があってさらにデータベースとの連携。。。。。。

FlashやAIRが実行環境となっている場合、構築技術としては広い範囲をカバーする必要があるため、Flashができれば即OKとはなりません。
他にもOOP理解していますか? OOPの理解が拡張性、変更容易性の高い設計に結びついていますか?
生産性と品質を確保するためのフレームワークを熟知してますか?
フレームワークの相性を理解していますか?
中~大規模プロジェクトの経験はありますか? などなど。プロジェクトマネジメントのスキルと実装スキルは別物です。
まとめるとRIAはこれらの様々なスキルを統合して進めるスキルが必要です。それがないとシステムの「全体最適」は図れません。
そしてFlex/Flash/AIRの独特なところ、深いところをどうにかできるスキル。
ユーザーからみた要望とテクノロジーからの検証を両面で進められるスキル。
これだけ必要です。
どれか欠けるなら代替え策が必要です。

③RIAプロジェクトの進め方
 ~現物主義~

アジャイル型開発に対する誤解。
変化の激しい市場に適用させるためにあるプロセスであること。
RIA開発におけるIIDのメリットは→現物主義であること。
設計と実装で見積もりを二回とること。これ重要。
「やっぱりできないんですけど」のリスクは避けたい
ベンダーがきついと品質にも悪影響。
win-winであることが重要

④RIAの保守・運用
 ~攻めの保守・運用~

Flex/AIRであればユーザーごとにカスタマイズも可能(一部ですが)
アカウント管理によって権限を設定して使える機能と使えない機能をもたせる。
動的CSSで見た目を変える。
これらは開発が上手くできていれば変更拡張は簡単
よって
管理者は業務に集中できる
ユーザーは改善要望をだしやすくなる。
より強力にシステムを使い倒すことができる
そして開発ベンダーをキープしましょう。またキープできるベンダーを探しましょう。
保守体制を切り分けましょう

ユーザー → 一時対応(あなた)→対策(ベンダー)

「もちはもちやに」
結構、大切なんですよ♪

逆説的に言うと
ユーザーが使いづらいのに改善されないシステムとの決別

2008年5月2日金曜日

[Project]プログラミングファースト開発とコードアンドフィックスモデル

プログラミングファースト開発
http://d.hatena.ne.jp/higayasuo/20080501/1209636051

なんかコメント欄をみて思ったんだけど「昔からある~」はコードアンドフィックスモデルだよね。
プログラミングファースト開発の中身はわかってないですけど、そのプロセスにはちゃんと秩序があってそれにそって進めていくんだよね。
コードアンドフィックスモデルは計画がなく、工程管理もできずといったものなので根本的に違うはず。

コメントの意図するところがわかんないので推測ですが。。。

駄目なアジャイルが無計画でアジャイル(笑)になってしまうことの弊害とか先入観からきてるのかと。

タケはアジャイルであったりインクリメンタルな開発プロセスのほうがソフトウェアの開発には適しているとは思いますが、〆切りをおそれたり計画を立てることを面倒くさがってアジャイルを適用するのは違うよね、と。


・考える
・実行する
・確認する

「考える」の放棄はろくなことないです

2008年5月1日木曜日

考える、実行する、確認する

くどい用だけど正しい行動の最短プロセス

考える、実行する、確認する