そのうちWeb2.0みたいにバズワードになっちゃうんじゃないかと思ってる。
WEB2.0の恐怖
RIAの定義ってなんなのさ、と。
個人的にはこういったいくつかの条件から定義される概念みたいな言葉は、他の言葉と相対的な立ち位置によって存在していると思います。
例えば「オープン系」を説明しよう等すると「プロプライエタリ」という単語を比較対象としてださなきゃ、うまく説明できないです。だからRIAも絶対的な定義なんかなくて、それまでのものと比べた相対的な言葉じゃないかと。
で何が言いたいのかというと、システムの企画やら営業やらで「これからはRIA」ということにどんだけの意味があんのかと問いたい。
RIAでなんでも解決すんのか?
RIAはリッチクライアント、シンクライアント、クラサバ、メインフレームに比べて優れてんのか?
というわけでRIAに対して食傷気味。
「RIA=優秀」
ではないはず。当たり前ですが向き不向き、そもそもシステムで何がやりたいのかが最も重要なわけで。。。
別にFlexやSilverlightが嫌いというわけじゃないですよ。
多分ね~。
2008年12月19日金曜日
2008年11月6日木曜日
選択肢の一つ
「1対1もオフェンスの選択肢の
一つにすぎねぇ
それが わからねぇうちは
おめーには負ける気がしねえ」
仙道彰(陵南バスケ部)
http://www.great-saying.com/w-slumdunk51.html
この間、久しぶりに読み直してこの言葉の重さ、凄さがわかった気がする。
プロジェクトにおいては「実装で解決」も選択肢の一つですよ。
多分ね~。
一つにすぎねぇ
それが わからねぇうちは
おめーには負ける気がしねえ」
仙道彰(陵南バスケ部)
http://www.great-saying.com/w-slumdunk51.html
この間、久しぶりに読み直してこの言葉の重さ、凄さがわかった気がする。
プロジェクトにおいては「実装で解決」も選択肢の一つですよ。
多分ね~。
2008年11月5日水曜日
プログラマーを採用する際に重視すべき10の資質
プログラマーを採用する際に重視すべき10の資質
誤解を恐れずに言わせてもらえば、プログラマーと他の職業の違いは「パソコン」に対してより深いコミュニケーションが求められているかいないかだけで、他の職業が有するようなコミュニケーションをまったくとらないで済むわけではないです。
そういう意味では(あまり適切でないことは重々承知の上で)人間的なベーシックなスキルは必須である、ということです。
もちろんプログラマーである以上、他の職業の人より「パソコン」とコミュニケーションを円滑にとれるスキルが重要視されることは言うまでもございません。
多分ね~。
誤解を恐れずに言わせてもらえば、プログラマーと他の職業の違いは「パソコン」に対してより深いコミュニケーションが求められているかいないかだけで、他の職業が有するようなコミュニケーションをまったくとらないで済むわけではないです。
そういう意味では(あまり適切でないことは重々承知の上で)人間的なベーシックなスキルは必須である、ということです。
もちろんプログラマーである以上、他の職業の人より「パソコン」とコミュニケーションを円滑にとれるスキルが重要視されることは言うまでもございません。
多分ね~。
2008年10月27日月曜日
IT一番戦略の実践と理論
SIer,ITソフト会社のビジネスモデル再構築のための『IT一番戦略の実践と理論』
読んだ感想としてはさらっと読めてしまう。結構、簡潔。
「IT業界向けにカスタマイズした船井流ライフサイクル理論」の図がすばらしい。
最後の章の冒頭が可笑しかったので引用。
想像してみて下さい。
人通りの少ない場所に一軒のお店が建っています。看板はなく宣伝しているわけでもありません。店内には職人風の人が立っています。
恐る恐る店をのぞいてみる聞いてみると、どうも飲食店のようです。何が得意なのかと聞くと、何でもできると答えられました。
注文すると、レシピを調べはじめ、材料を買いに出かけました。一心不乱に料理を作っています。でき上がりました。可もなく不可もなくといった感じでしょうか。味は普通です。
店員のサービスにも特に目立つところはありません。こちらの要望で値段は下がりました。あなたは、このお店の常連客になろうと考えるでしょうか。
この文章の後に「これがIT業界の真実です。」と続きます。ワロスwwwwwwwwww。
「ウチのシステムはなぜ使えない SEとユーザの失敗学」
をおもいだしました。
しかしかなーり良いことが書いてあるんだ。
従来の「SIerやベンダーの工数を積み上げてお客さんがいくらでも払ってくれた時代」はそろそろ終了ですよ。予算の制約にあわせて売る必要がありますよ~。みたいな。
営業やっていたときにつくづくそう思った。うちみたいなベンチャーに声をかけるお客さんからしたら、自分でいろいろ調べて探してたどり着いた小さいけど若くてとんがっている会社からSIerみたいな見積だされたら引くよね。
タケはこの本、読んでみる価値あり、だと思います。
自社の営業戦略と照らし合わせて考えてみるといいんじゃないでしょうか。
多分ね。
読んだ感想としてはさらっと読めてしまう。結構、簡潔。
「IT業界向けにカスタマイズした船井流ライフサイクル理論」の図がすばらしい。
最後の章の冒頭が可笑しかったので引用。
想像してみて下さい。
人通りの少ない場所に一軒のお店が建っています。看板はなく宣伝しているわけでもありません。店内には職人風の人が立っています。
恐る恐る店をのぞいてみる聞いてみると、どうも飲食店のようです。何が得意なのかと聞くと、何でもできると答えられました。
注文すると、レシピを調べはじめ、材料を買いに出かけました。一心不乱に料理を作っています。でき上がりました。可もなく不可もなくといった感じでしょうか。味は普通です。
店員のサービスにも特に目立つところはありません。こちらの要望で値段は下がりました。あなたは、このお店の常連客になろうと考えるでしょうか。
この文章の後に「これがIT業界の真実です。」と続きます。ワロスwwwwwwwwww。
「ウチのシステムはなぜ使えない SEとユーザの失敗学」
をおもいだしました。
しかしかなーり良いことが書いてあるんだ。
従来の「SIerやベンダーの工数を積み上げてお客さんがいくらでも払ってくれた時代」はそろそろ終了ですよ。予算の制約にあわせて売る必要がありますよ~。みたいな。
営業やっていたときにつくづくそう思った。うちみたいなベンチャーに声をかけるお客さんからしたら、自分でいろいろ調べて探してたどり着いた小さいけど若くてとんがっている会社からSIerみたいな見積だされたら引くよね。
タケはこの本、読んでみる価値あり、だと思います。
自社の営業戦略と照らし合わせて考えてみるといいんじゃないでしょうか。
多分ね。
2008年10月24日金曜日
2008年10月22日水曜日
良いテスト品質と黒集団の話
良いテストの品質とは何か?
読んだら「ピープルウェア」の「黒集団チームの伝説」を思い出した。
簡単に黒集団の伝説を抜粋:
(購読をオススメします)
黒集団は、最初は、他の同僚よりもテストが少しうまい人手構成された。(中略)
最も驚くべきことは、当初は普通のチームだったが、翌年に賭けて素晴らしいチームに成長したことだった。(中略)
テストについて開発者と敵対する哲学がチームメンバーの間に次第に育ち、個性となった。その哲学とは、バグを見つけなければならない、見つけたい、というものである。黒集団は決して開発設計者の側には立たず、敵対する立場をとった。(中略)プログラムに絶え間ない試練を与えることに喜びを見いだしていた。
(中略)
初めのうちは、テストチームが流す意地の悪い情け容赦のないテストプログラムもほんの冗談で、他人のプログラムをコケさせては喜んでいる程度だった。だが、そのうち冗談ではなくなってきた。チームメンバーは破壊者のイメージを持ちはじめた。コーディングだけでなく、みんなの一日の予定を破壊した。ミスを引き出すために、途方もなく無茶なことをした。バッファに過負荷をかけ、空ファイル同士を比較し、とんでもない順序で入力した。黒集団が作ったテストプログラムの下で、自分のプログラムが誤作動するのを見て、大の大人が思わず泣き出したぐらいである。悪く思われれば思われるほど、それを楽しんだ。
陰湿なイメージをふくらませるために、チームのメンバーは黒い服を着用始めた(ここから黒集団の名がついた)。プログラムがテストにひっかかると恐ろしい声でケタケタ笑った。メンバーの中には長い口ひげを生やし、『アンクル・トムの小屋』に出てくる残忍な奴隷商人のようにそれをひねくりまわした。このチームは一団となって仕事をし、次々に恐ろしいテスト計画を実施した。プログラマーは黒集団の病的な態度に不満をもらしはじめた。
言うまでもなく会社は喜んだ。チームが見つけたバグは、いずれも顧客には見つけられないものだった。チームは大成功だった。テスト班としてチームは成功したが、もっと重要なことは、社会組織としてチームが成功したことだ。(省略)
赤備えでもつくろうかな。一人で。
読んだら「ピープルウェア」の「黒集団チームの伝説」を思い出した。
簡単に黒集団の伝説を抜粋:
(購読をオススメします)
黒集団は、最初は、他の同僚よりもテストが少しうまい人手構成された。(中略)
最も驚くべきことは、当初は普通のチームだったが、翌年に賭けて素晴らしいチームに成長したことだった。(中略)
テストについて開発者と敵対する哲学がチームメンバーの間に次第に育ち、個性となった。その哲学とは、バグを見つけなければならない、見つけたい、というものである。黒集団は決して開発設計者の側には立たず、敵対する立場をとった。(中略)プログラムに絶え間ない試練を与えることに喜びを見いだしていた。
(中略)
初めのうちは、テストチームが流す意地の悪い情け容赦のないテストプログラムもほんの冗談で、他人のプログラムをコケさせては喜んでいる程度だった。だが、そのうち冗談ではなくなってきた。チームメンバーは破壊者のイメージを持ちはじめた。コーディングだけでなく、みんなの一日の予定を破壊した。ミスを引き出すために、途方もなく無茶なことをした。バッファに過負荷をかけ、空ファイル同士を比較し、とんでもない順序で入力した。黒集団が作ったテストプログラムの下で、自分のプログラムが誤作動するのを見て、大の大人が思わず泣き出したぐらいである。悪く思われれば思われるほど、それを楽しんだ。
陰湿なイメージをふくらませるために、チームのメンバーは黒い服を着用始めた(ここから黒集団の名がついた)。プログラムがテストにひっかかると恐ろしい声でケタケタ笑った。メンバーの中には長い口ひげを生やし、『アンクル・トムの小屋』に出てくる残忍な奴隷商人のようにそれをひねくりまわした。このチームは一団となって仕事をし、次々に恐ろしいテスト計画を実施した。プログラマーは黒集団の病的な態度に不満をもらしはじめた。
言うまでもなく会社は喜んだ。チームが見つけたバグは、いずれも顧客には見つけられないものだった。チームは大成功だった。テスト班としてチームは成功したが、もっと重要なことは、社会組織としてチームが成功したことだ。(省略)
赤備えでもつくろうかな。一人で。
2008年10月21日火曜日
2008年10月20日月曜日
2008年10月17日金曜日
2008年10月11日土曜日
netstat
netstatコマンドを使いこなす
http://www.atmarkit.co.jp/fwin2k/win2ktips/234netstat/netstat.html
netstat
~ホストのネットワーク統計や状態を確認する
http://www.atmarkit.co.jp/fnetwork/netcom/netstat/netstat.html
あとで読む。
http://www.atmarkit.co.jp/fwin2k/win2ktips/234netstat/netstat.html
netstat
~ホストのネットワーク統計や状態を確認する
http://www.atmarkit.co.jp/fnetwork/netcom/netstat/netstat.html
あとで読む。
2008年9月24日水曜日
「PMPを取得せよ」と上司にいわれたら、最初にとる5つの対策
「PMPを取得せよ」と上司にいわれたら、最初にとる5つの対策
タケが会社から
「PMP取得汁!」
とかいわれることはまずないのですが、このサイトはとても参考になりました。
やっぱね、PMBOKは買った方がいいよ。
多分ね。
タケが会社から
「PMP取得汁!」
とかいわれることはまずないのですが、このサイトはとても参考になりました。
やっぱね、PMBOKは買った方がいいよ。
多分ね。
「Excelでプロジェクト管理」が圧倒的多数、しかし満足度は低め
「Excelでプロジェクト管理」が圧倒的多数、しかし満足度は低め
そりゃそうかと思う。
Excelはとても自由度の高い優秀なアプリケーションですが、プロジェクト管理をするためのアプリにあらず。
もしMicrosoft Office Projectと同じようなことしようとしてもムリ。絶対ムリ。
でもMicrosoft Office Projectを使っていても、Excelでつくるスケジュールとかわんなくね? っていうのはよくある話。
使い慣れていないこともあると思うけど、プロジェクトというものがどういった情報をもっているのかを理解していないかと思われ。
多分ね。
そりゃそうかと思う。
Excelはとても自由度の高い優秀なアプリケーションですが、プロジェクト管理をするためのアプリにあらず。
もしMicrosoft Office Projectと同じようなことしようとしてもムリ。絶対ムリ。
でもMicrosoft Office Projectを使っていても、Excelでつくるスケジュールとかわんなくね? っていうのはよくある話。
使い慣れていないこともあると思うけど、プロジェクトというものがどういった情報をもっているのかを理解していないかと思われ。
多分ね。
2008年8月20日水曜日
「プロジェクトX リーダーたちの言葉」を読みました
プロジェクトX リーダーたちの言葉
【くるーる】開発日記【kuru-ru】の中の人が
「嫁!」
と言ってきたので読みました。
その際、
「じっくり時間をかけて勉強汁!」
「間違っても1日、2日で読み飛ばさないように!」
と言われたのですが、読書のペースは人それぞれなので(笑)、半日で読み切ってみました。
この本に登場するリーダー達の共通点を私なりに考えてみました。
「メンバーに対する明確な動機付け」
プロジェクトに社会的な意義を見いだしたり、個人や組織を超えたところでやるべき「理由」を説明しています。
「自ら規範となる」
まさにリーディング。自信が率先してキツイ作業を行ったりです。あと登場人物全員が現場主義の人のように思えました。
「人の話を聞く/観察をする」
強烈なリーダーシップでメンバーを牽引しつつも、メンバーの話を聞いたり、多くを語らないにしてもメンバーの状態をしっかり観察していたりします。
これらはリーダーやマネジャー向けの書籍だよく登場するキーワードだと思いますが、この本は、実際に存在するリーダー達が現実のプロジェクトに対してどのようにふるまったか、どのような心構えでプロジェクトをリーディングしていたかが書かれています。
抽象的な文章が多いのですが、事例ベースのため説得力があります。そして熱い!です。
そしてこれらを元に下記を実践していると思います。
「いい感じでメンバーに無理をさせる(笑)」
創造性を問われる仕事を振る、メンバーの実力より高い結果を求める等々。
つまり一緒に仕事をするメンバーの最大限以上を引き出すことで、困難なプロジェクトを成功させているのではないでしょうか。
私なりにもうちょっと考えること。
「リーダーは自分自身をプロデュース/プロモーションすること」
メンバー視線、お客さまやステークホルダー視点で頼れるリーダーであることをアピールする必要があるかと思います。自分はしっかりやっているから大丈夫では足りません。大多数の人はそんなに他人を観察したり興味をもったりはしないものです。
以上、もろもろ書きましたが私自身はまだまだプレイヤーの領域ですね。
「生涯一捕手」ではありませんが、プレイヤーでいられる限りはプレイヤーであり続けたいです。
【くるーる】開発日記【kuru-ru】の中の人が
「嫁!」
と言ってきたので読みました。
その際、
「じっくり時間をかけて勉強汁!」
「間違っても1日、2日で読み飛ばさないように!」
と言われたのですが、読書のペースは人それぞれなので(笑)、半日で読み切ってみました。
この本に登場するリーダー達の共通点を私なりに考えてみました。
「メンバーに対する明確な動機付け」
プロジェクトに社会的な意義を見いだしたり、個人や組織を超えたところでやるべき「理由」を説明しています。
「自ら規範となる」
まさにリーディング。自信が率先してキツイ作業を行ったりです。あと登場人物全員が現場主義の人のように思えました。
「人の話を聞く/観察をする」
強烈なリーダーシップでメンバーを牽引しつつも、メンバーの話を聞いたり、多くを語らないにしてもメンバーの状態をしっかり観察していたりします。
これらはリーダーやマネジャー向けの書籍だよく登場するキーワードだと思いますが、この本は、実際に存在するリーダー達が現実のプロジェクトに対してどのようにふるまったか、どのような心構えでプロジェクトをリーディングしていたかが書かれています。
抽象的な文章が多いのですが、事例ベースのため説得力があります。そして熱い!です。
そしてこれらを元に下記を実践していると思います。
「いい感じでメンバーに無理をさせる(笑)」
創造性を問われる仕事を振る、メンバーの実力より高い結果を求める等々。
つまり一緒に仕事をするメンバーの最大限以上を引き出すことで、困難なプロジェクトを成功させているのではないでしょうか。
私なりにもうちょっと考えること。
「リーダーは自分自身をプロデュース/プロモーションすること」
メンバー視線、お客さまやステークホルダー視点で頼れるリーダーであることをアピールする必要があるかと思います。自分はしっかりやっているから大丈夫では足りません。大多数の人はそんなに他人を観察したり興味をもったりはしないものです。
以上、もろもろ書きましたが私自身はまだまだプレイヤーの領域ですね。
「生涯一捕手」ではありませんが、プレイヤーでいられる限りはプレイヤーであり続けたいです。
2008年8月8日金曜日
2008年7月29日火曜日
2008年7月20日日曜日
ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト
「ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト」
(棚橋 弘季・ソフトバンククリエイティブ)
いま読んでる途中。
ん~。
「ソフトウェア見積り―人月の暗黙知を解き明かす」
「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法」
この二冊は私が仕事をしていく上でものすごく影響を受けた本。
まだ完全にモノにできた感はないものの、困ったら読み返している。
「ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト」は三冊目の予感。
それぐらい読んでいて楽しい。
そして濃密な内容が苦しい。
買って良かった♪
(棚橋 弘季・ソフトバンククリエイティブ)
いま読んでる途中。
ん~。
「ソフトウェア見積り―人月の暗黙知を解き明かす」
「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法」
この二冊は私が仕事をしていく上でものすごく影響を受けた本。
まだ完全にモノにできた感はないものの、困ったら読み返している。
「ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト」は三冊目の予感。
それぐらい読んでいて楽しい。
そして濃密な内容が苦しい。
買って良かった♪
システム開発とアメリカンフットボール
OL=PG
TE=SE
WR=アーキテクトやらテクニカルリーダーやらUIデザイナやら。わりと特殊で高度なスキルの人。
FB=サポートSE
TB=営業
QB=PM
わりとこんなイメージ。
TE=SE
WR=アーキテクトやらテクニカルリーダーやらUIデザイナやら。わりと特殊で高度なスキルの人。
FB=サポートSE
TB=営業
QB=PM
わりとこんなイメージ。
システム開発の営業という仕事
半年ほど前、ある人が「結局この仕事は人間にいくらの付加価値をつけて売ってくるかが大事」と言っていて、私はその言葉に若干違和感を感じつつもそんなもんかもと思っていた。
また別のある人が最近「受託開発といっても今やっていることは人売りと変わらない」と言っていた。心の中で激しく同意してしまった。
そう。
今の仕事ってエンジニアの時間を売っているだけなんだよね。
そう考えたらなんかいろんな意味で悲しくなってきた。
ま、それをおいといて。
システム開発の現状が、場所は違えど常駐だろうが持ち帰りだろうがエンジニアの時間を売っているだけでしかない以上、そこにかかるコストはきっちり請求しなくてはならない。そしてシステム営業はなんでそのような時間とコストがかかるのかをきっちり説明しなくてはならない。システム営業と呼ばれる職種の人達はこの説明が苦手な人が多いんだと思う。なんでかというと必ずテクニカルなこととプロジェクトに関する事がでてくるから。営業のスキルってそこは専門じゃないんだよね。そういう説明を営業に求めるのはちょっと無理があるし、逆にそこをついて案件を発注側の良いようにコントロールしようとする担当者もいたりする。これはとても悲しいことだね。個人的にはエンジニアがもっと自分の仕事の価値の評価基準の一項目として「お金」というものにもっと執着しても良いんじゃないかと思う。
さてさて、話が発散しますが、時間売りの仕事ってちょっとね。
なんでそんなんなっているか? という理由の一つに契約書面に記述される権利の項目があるように思う。作ったモノは全部、甲(発注側)のモノってやつ。嘘かと思うけど本当にある。普通にある。ていうかほとんどそんなんばっかり。
これ書かれたら時間売りになるしかないよね。
また別のある人が最近「受託開発といっても今やっていることは人売りと変わらない」と言っていた。心の中で激しく同意してしまった。
そう。
今の仕事ってエンジニアの時間を売っているだけなんだよね。
そう考えたらなんかいろんな意味で悲しくなってきた。
ま、それをおいといて。
システム開発の現状が、場所は違えど常駐だろうが持ち帰りだろうがエンジニアの時間を売っているだけでしかない以上、そこにかかるコストはきっちり請求しなくてはならない。そしてシステム営業はなんでそのような時間とコストがかかるのかをきっちり説明しなくてはならない。システム営業と呼ばれる職種の人達はこの説明が苦手な人が多いんだと思う。なんでかというと必ずテクニカルなこととプロジェクトに関する事がでてくるから。営業のスキルってそこは専門じゃないんだよね。そういう説明を営業に求めるのはちょっと無理があるし、逆にそこをついて案件を発注側の良いようにコントロールしようとする担当者もいたりする。これはとても悲しいことだね。個人的にはエンジニアがもっと自分の仕事の価値の評価基準の一項目として「お金」というものにもっと執着しても良いんじゃないかと思う。
さてさて、話が発散しますが、時間売りの仕事ってちょっとね。
なんでそんなんなっているか? という理由の一つに契約書面に記述される権利の項目があるように思う。作ったモノは全部、甲(発注側)のモノってやつ。嘘かと思うけど本当にある。普通にある。ていうかほとんどそんなんばっかり。
これ書かれたら時間売りになるしかないよね。
2008年7月19日土曜日
会社辞めたい!
「日本のソフトウェア産業がいつまでもダメな理由」
(久手堅 憲之・技術評論社)
書店で見かけてタイトルにドキッとしたので購読しました。
ドキッとしたのはずいぶん前ですが。
読後の感想としては「会社辞めたい!」と思いました。
正確に書くと会社辞めても1人で食っていけるようになりたい!そういう意味で。
個人的な想いとして、忙しいのはイヤじゃない。
ただしべらぼうに忙しいのにその忙しいのを経験しても自身に何にも残らない、成長が見込めないというのがイヤ。
それは時間を売っているのと同じじゃん。
忙しさを緩和してもらって自身で何か知識や技術を身に着ける時間がないとキツイね。
あと気になったポイントとしては下記。
実際のデータも見てみよう。社団法人情報サービス協会(JISA)が、経済産業省の「平静17年特定サービス産業実態調査報告書・情報サービス業編」をもとにまとめたデータによると、「情報サービス産業」(ソフトウェア開発以外の業種を4割強含む)就業者1人あたりの年間売上げ高は、2006年で約3000万円となっている。上場企業の公開データを見ると、だいたいこのレベルにあるのは、日立情報システムズ、東洋ビジネスエンジニアリング、TIS、CSKあたりになる(いずれも連結ベース、以下同じ)。これらの企業は、業界でもかなり業績が良好なグループと思われ、平均と見なすのにはやや違和感がある。
「保守運用・ライセンス更新」をしっかりやることが大事だとか。
そうなんだ。ちょっとしたショック。ネガティブな意味でなくて。
(久手堅 憲之・技術評論社)
書店で見かけてタイトルにドキッとしたので購読しました。
ドキッとしたのはずいぶん前ですが。
読後の感想としては「会社辞めたい!」と思いました。
正確に書くと会社辞めても1人で食っていけるようになりたい!そういう意味で。
個人的な想いとして、忙しいのはイヤじゃない。
ただしべらぼうに忙しいのにその忙しいのを経験しても自身に何にも残らない、成長が見込めないというのがイヤ。
それは時間を売っているのと同じじゃん。
忙しさを緩和してもらって自身で何か知識や技術を身に着ける時間がないとキツイね。
あと気になったポイントとしては下記。
実際のデータも見てみよう。社団法人情報サービス協会(JISA)が、経済産業省の「平静17年特定サービス産業実態調査報告書・情報サービス業編」をもとにまとめたデータによると、「情報サービス産業」(ソフトウェア開発以外の業種を4割強含む)就業者1人あたりの年間売上げ高は、2006年で約3000万円となっている。上場企業の公開データを見ると、だいたいこのレベルにあるのは、日立情報システムズ、東洋ビジネスエンジニアリング、TIS、CSKあたりになる(いずれも連結ベース、以下同じ)。これらの企業は、業界でもかなり業績が良好なグループと思われ、平均と見なすのにはやや違和感がある。
「保守運用・ライセンス更新」をしっかりやることが大事だとか。
そうなんだ。ちょっとしたショック。ネガティブな意味でなくて。
2008年7月17日木曜日
ユーザーインターフェースデザインの考え方 その②
ユーザインターフェースデザインの考え方
このエントリーを書いた後に
「ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト」
という本をパラパラとめくっていたらこんなのがでてきたじゃないですか!
ユーザー・エクスペリエンスのダイアグラム
これ!
こういうことが言いたかった!
このエントリーを書いた後に
「ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト」
という本をパラパラとめくっていたらこんなのがでてきたじゃないですか!
ユーザー・エクスペリエンスのダイアグラム
これ!
こういうことが言いたかった!
2008年7月15日火曜日
RadioheadがGoogleと組んで音楽ビデオを提供
RadioheadがGoogleと組んで音楽ビデオを提供
なんかよくわかんないけどスゴイね。
Radioheadがオープンソースミュージシャンを自称しているのは知らなかった。
音楽をオープンソースにするっていうのは何をもたらすんだろうか?
と思ったけど、すげー昔にさかのぼればもともとオープンソースだったんじゃないだろうか?
レコードを販売することがビジネスとして成立したからオープンソースじゃなくなったのかな?
そう思うと人から人へのつながりで伝えられる。
良いものは残る。
演奏者が替わっても、媒介する機器が替わっても、聞く人がいる限りずっと残る。
オープンソースが知恵の共有を意味するのなら、そこらで垂れ流されているしょーもない音楽は消える。
良いものがタダで聞けるならそっち聴くから。
きっとずっと聴くだろうから。
多分ね。
なんかよくわかんないけどスゴイね。
Radioheadがオープンソースミュージシャンを自称しているのは知らなかった。
音楽をオープンソースにするっていうのは何をもたらすんだろうか?
と思ったけど、すげー昔にさかのぼればもともとオープンソースだったんじゃないだろうか?
レコードを販売することがビジネスとして成立したからオープンソースじゃなくなったのかな?
そう思うと人から人へのつながりで伝えられる。
良いものは残る。
演奏者が替わっても、媒介する機器が替わっても、聞く人がいる限りずっと残る。
オープンソースが知恵の共有を意味するのなら、そこらで垂れ流されているしょーもない音楽は消える。
良いものがタダで聞けるならそっち聴くから。
きっとずっと聴くだろうから。
多分ね。
一流の開発者を惹きつける--魅力的な人材募集広告を作成するための10の秘訣
一流の開発者を惹きつける--魅力的な人材募集広告を作成するための10の秘訣
100%同意するわけではありませんが「成長の機会」や「成長への欲求」って大事だよね。
「今もらえるお金のためだけに働く」を否定する気はないけどね。
忙しいとか仕事が大変とか給料が安い(生活に困窮するレベルはおいといて)っていうのは、本当にやりがいのある仕事に携わっていられればそんなに気にならなかったりするんじゃなかろか。
忙しくて、給料が安くて、成長の見込みのないつまんない仕事だとしたら条件次第ですぐどっかに行ってしまうと思う。
実際、タケが転職を決めたのはそういう部分が強かったし。
「やりがい」って言葉は今となっては安っぽくなってしまったかもしれないけど、やっぱり大事だと思います。
多分ね。
100%同意するわけではありませんが「成長の機会」や「成長への欲求」って大事だよね。
「今もらえるお金のためだけに働く」を否定する気はないけどね。
忙しいとか仕事が大変とか給料が安い(生活に困窮するレベルはおいといて)っていうのは、本当にやりがいのある仕事に携わっていられればそんなに気にならなかったりするんじゃなかろか。
忙しくて、給料が安くて、成長の見込みのないつまんない仕事だとしたら条件次第ですぐどっかに行ってしまうと思う。
実際、タケが転職を決めたのはそういう部分が強かったし。
「やりがい」って言葉は今となっては安っぽくなってしまったかもしれないけど、やっぱり大事だと思います。
多分ね。
2008年7月14日月曜日
SaaSに対応できないベンダは新規顧客を見つけにくくなる
クラウドコンピューティングの現実
今まで以上に手段よりも目的に注力するようになるわけですよ。
でも手段を熟知していないと意外と目的に達することができないわけです。
アプリケーションベンダやソフトウェアベンダ、あとSIerも必ずしも商売が成り立たなくなる?
単純にそういう訳じゃないよね、と。
SaaSだって数ある手段の一つですよ。
そして技術の振り子は「SaaS」に対して振り切れたとき、その反動で今度はどこにいくのかな? と。
それがPaaSかもしれないし、意外とSIerを中心としたシステムインテグレーションかもしれないし。
多分ね。
今まで以上に手段よりも目的に注力するようになるわけですよ。
でも手段を熟知していないと意外と目的に達することができないわけです。
アプリケーションベンダやソフトウェアベンダ、あとSIerも必ずしも商売が成り立たなくなる?
単純にそういう訳じゃないよね、と。
SaaSだって数ある手段の一つですよ。
そして技術の振り子は「SaaS」に対して振り切れたとき、その反動で今度はどこにいくのかな? と。
それがPaaSかもしれないし、意外とSIerを中心としたシステムインテグレーションかもしれないし。
多分ね。
ユーザインターフェースデザインの考え方
要求開発にでてくる「キャビネット」みたいなものをイメージするとわかりやすいんじゃないかな、と。
もしくはPMBOKの5つのプロセス、9つの知識体系でもいい。
ヴィジュアルデザインとレイアウトデザインは「表面的」だけど、各パーツは階層的に意味をもちユーザの操作に対してリアクションを返す。インタラクティブ性とかインタラクションとかいわれる考えかた。
つまり意味とインタラクションをしっかり決めれば表面的なレイアウトやヴィジュアルデザインになると思うし、その逆から考察することもできるんだと思う。
どうもユーザインターフェースデザインの「デザイン」の部分がヴィジュアルなものを想起させすぎるんじゃないのかな、と。
だからお客さんを含めたステークホルダーと話すときは、UIは表面だけやってりゃいいんじゃないですよ、って説明する必要があると思うんですよ。パーツの一つ一つの動作や意味、それぞれのパーツの相関性なんかをね。
しっかり時間かけて作ればいいものになるし、推敲が足らなければ惜しいUIになっちゃうし。
上記、あくまで雑用係の知ったかぶりにつき異論は認めます。
2008年7月9日水曜日
Javaのビヘイビア駆動開発をやさしく実現する"easyb"を試す
Javaのビヘイビア駆動開発をやさしく実現する"easyb"を試す
テスト駆動開発はメンテナンスに手こずる(仕様変更が入るとテストケースなりテストコードなりを書き直すのが面倒?)という話を聞いたけど(そんなのアウトプットを残したらなんだってそうだろ)、ビヘイビア駆動開発ってどうなんだろ。
テスト駆動開発はメンテナンスに手こずる(仕様変更が入るとテストケースなりテストコードなりを書き直すのが面倒?)という話を聞いたけど(そんなのアウトプットを残したらなんだってそうだろ)、ビヘイビア駆動開発ってどうなんだろ。
「似非」SOAを見破る10の方法
「似非」SOAを見破る10の方法
SOAについて、わかっているようでいてよくわかっていないのでメモ。
#7:IT部門がすべてを仕切っているのであれば・・・それはSOAではない。
IT部門の人間には悪いが、真のSOAでは業務部門が深く関与する必要があるのだ。
ふーん。これだけを見ると「つかえる」「まともな」システムやサービスが必要であれば、SOAかどうかは問題じゃない。
多分ね。
SOAについて、わかっているようでいてよくわかっていないのでメモ。
#7:IT部門がすべてを仕切っているのであれば・・・それはSOAではない。
IT部門の人間には悪いが、真のSOAでは業務部門が深く関与する必要があるのだ。
ふーん。これだけを見ると「つかえる」「まともな」システムやサービスが必要であれば、SOAかどうかは問題じゃない。
多分ね。
2008年7月7日月曜日
見積もりなめんな!
コンペ案件を受注できるかできないかは単純に金の話だけできまるわけないです。
発注者はそんなにアホちゃう。
見積もり=金
この認識しかないなら3の倍数と3の付く数字にテキトーに100万かけとけばいいじゃん。
「さーんぜーんまんっ!」
そんなアホに発注なんかしないでしょ。
発注者はそんなにアホちゃう。
見積もり=金
この認識しかないなら3の倍数と3の付く数字にテキトーに100万かけとけばいいじゃん。
「さーんぜーんまんっ!」
そんなアホに発注なんかしないでしょ。
事業ってさ……
「乾坤一擲の新サービス展開!」
博打とまでは言いませんが、一点買いみたいでちょっと怖いよね。
博打うちだったら一点買いって楽しいかも。単勝一点買い! 有り金全部つっこんじゃえー!
でも投資家だったらそうじゃないよね。リスク分散するよね。それが「ポートフォリオ」ってもんじゃないのかな。
博打とまでは言いませんが、一点買いみたいでちょっと怖いよね。
博打うちだったら一点買いって楽しいかも。単勝一点買い! 有り金全部つっこんじゃえー!
でも投資家だったらそうじゃないよね。リスク分散するよね。それが「ポートフォリオ」ってもんじゃないのかな。
SaaSとPaaS
システムの歴史は集中と分散の繰り返し。
それを踏まえるとSaaSは集中。
PaaSは分散。
SaaSは集中型なのでメインフレームのときと似たような課題を抱えるはず。
PaaSは分散型なのでクラサバのときと似たような課題を抱えるはずです。
エンドユーザコンピューティングの良いところも悪いところもまた再現するかもしれません。
ただしメインフレーム→クラサバへの移行の時ほど大きな振り幅はないと思います。
技術も進んだので再現しない課題もあるはずだし、乗り切るのもそんなに時間かかんないと思います。
言語よりもサービスを統合する技術に注目が集まるんじゃないかな~。今まで以上に~。
多分ね。
それを踏まえるとSaaSは集中。
PaaSは分散。
SaaSは集中型なのでメインフレームのときと似たような課題を抱えるはず。
PaaSは分散型なのでクラサバのときと似たような課題を抱えるはずです。
エンドユーザコンピューティングの良いところも悪いところもまた再現するかもしれません。
ただしメインフレーム→クラサバへの移行の時ほど大きな振り幅はないと思います。
技術も進んだので再現しない課題もあるはずだし、乗り切るのもそんなに時間かかんないと思います。
言語よりもサービスを統合する技術に注目が集まるんじゃないかな~。今まで以上に~。
多分ね。
ぼんやりとした不安
自殺予告じゃないよ。
友人の証券マンがサブプライムの影響をもろに食らって夏のボーナスが55%カットされたそうな。。。
本人は成績優秀なんだけどね、外部要因とはいえ本人の努力や結果とはほとんど関係のないところでおきたことがそこまでの影響をおよぼすって怖いよね。
いまのところ私のつとめる会社にそこまでの影響はないんですけど、ちょっと先はわかんないね。
半年先が怖い。
そんな不安です。
友人の証券マンがサブプライムの影響をもろに食らって夏のボーナスが55%カットされたそうな。。。
本人は成績優秀なんだけどね、外部要因とはいえ本人の努力や結果とはほとんど関係のないところでおきたことがそこまでの影響をおよぼすって怖いよね。
いまのところ私のつとめる会社にそこまでの影響はないんですけど、ちょっと先はわかんないね。
半年先が怖い。
そんな不安です。
子育てへの理解がほしいです
NTTデータ、父親が子育てしやすい会社ランキング3位に
次世代認定マークも取得
TISでは社内ブログとオフ会で育児の悩み相談
こういう取り組みがある会社はうらやましいね。。。
「現行制度に照らし合わせると遅刻が多いおまえの勤怠評価はマイナス」
って言われたからね。。。
だいたい遅刻理由も
・雨天による交通機関の遅れ
・娘を保育園に送る
の複合条件だし。どないせーっちゅーねん。
(ベビーシッターを雇えるくらい給料をくれるんなら話は別だけどさ)
きっと子育て世代も増えるだろうから制度見直すのかな。
その人達は評価マイナスされないんだろうな。
オレはマイナスされ損だ(笑)
フレックスタイム制を導入して発生する問題と、導入しないで発生している我が家の問題は後者の方がキツイね。
次世代認定マークも取得
TISでは社内ブログとオフ会で育児の悩み相談
こういう取り組みがある会社はうらやましいね。。。
「現行制度に照らし合わせると遅刻が多いおまえの勤怠評価はマイナス」
って言われたからね。。。
だいたい遅刻理由も
・雨天による交通機関の遅れ
・娘を保育園に送る
の複合条件だし。どないせーっちゅーねん。
(ベビーシッターを雇えるくらい給料をくれるんなら話は別だけどさ)
きっと子育て世代も増えるだろうから制度見直すのかな。
その人達は評価マイナスされないんだろうな。
オレはマイナスされ損だ(笑)
フレックスタイム制を導入して発生する問題と、導入しないで発生している我が家の問題は後者の方がキツイね。
アップル、スライド型「iPhone」を検討か?--The Register報道
アップル、スライド型「iPhone」を検討か?--The Register報道
プラットフォームとしてのiPhoneは魅力的なんだけど、デバイスとしてはなんか興味がわかないのは、個人的にはソフトウェアキーボードはなんか不安というか押したか押してないのかわかんないのはなんかイヤ。
プラットフォームとしてのiPhoneは魅力的なんだけど、デバイスとしてはなんか興味がわかないのは、個人的にはソフトウェアキーボードはなんか不安というか押したか押してないのかわかんないのはなんかイヤ。
2008年7月6日日曜日
PaaSに興味がわきました
PaaS
SIerにとって“怖い”のはSaaSよりもPaaS
salesforce.com上で会計ソフトの提供を始めたCODA聞いた
PaaSを利用することで開発期間を2年間短縮できた~英CODA
SaaSからPaaSへ ~プラットフォーム・サービスの新潮流
システム屋にとってみると「利用」よりも「構築」が気になるし、作りやすいのであれば興味がわきますね。
汎用的な使いやすさが保証されているのであれば、ユーザーにとっても導入のめりっとあるし。
それがシステムとしてよりあるべき姿に近づくのであれば、とても良いことだよなー、と漠然と思いました。
SIerにとって“怖い”のはSaaSよりもPaaS
salesforce.com上で会計ソフトの提供を始めたCODA聞いた
PaaSを利用することで開発期間を2年間短縮できた~英CODA
SaaSからPaaSへ ~プラットフォーム・サービスの新潮流
システム屋にとってみると「利用」よりも「構築」が気になるし、作りやすいのであれば興味がわきますね。
汎用的な使いやすさが保証されているのであれば、ユーザーにとっても導入のめりっとあるし。
それがシステムとしてよりあるべき姿に近づくのであれば、とても良いことだよなー、と漠然と思いました。
2008年7月3日木曜日
「フィットクライアント」時代到来か-RIAでリードを狙うAdobeのAIR
「フィットクライアント」時代到来か-RIAでリードを狙うAdobeのAIR
・ちょー流行る。そして定着する。ソフトウェアエンジニアリングの基礎本にも普通に紹介される。
・流行して一時もてはやされるが、よく分かっていない人たちのおもちゃにされ、その後まじめな顔で口にすると「痛い人」扱いされる
・全然はやらない。秋が来る頃にはみんな忘れる。
でもこの記事、よく読んだら3月の記事だった。
(RSSリーダーが古い記事を拾ってきた模様)
なので答えは「全然はやらない。秋どころか夏を迎える前にみんな忘れる」だ
・ちょー流行る。そして定着する。ソフトウェアエンジニアリングの基礎本にも普通に紹介される。
・流行して一時もてはやされるが、よく分かっていない人たちのおもちゃにされ、その後まじめな顔で口にすると「痛い人」扱いされる
・全然はやらない。秋が来る頃にはみんな忘れる。
でもこの記事、よく読んだら3月の記事だった。
(RSSリーダーが古い記事を拾ってきた模様)
なので答えは「全然はやらない。秋どころか夏を迎える前にみんな忘れる」だ
2008年7月1日火曜日
営業とエンジニアの協業
営業を体験しよう
RIA界隈(?)でよくプログラマとデザイナの協業(競業?)が話題になりますが、エンジニアと営業の競業(協業w)も課題になっているんじゃなかろか。
上手く協業できれば良い仕事ができるだろうし、下手すりゃ競業相手になってお客さんへのサービス品質が下がるし。
だいたい問題はお互いの仕事に対する無理解だと思うし、そうでないなら上手くいくと思う。
漠然としてるけど。
そして最近思うこと。
プロジェクトって営業→エンジニアの間でなにやら断絶される感があるけど、本来は不可分なものじゃないのだろうか?
企業単位でみたら営業の活動もエンジニアのものづくりも企業活動の一環であるし、きれいに分断なんてできないはず。
つまり両方を統括したり把握できる人が必要になるんでないかな?
求められる知識やスキルはすごい広範囲になるけどね。
RIA界隈(?)でよくプログラマとデザイナの協業(競業?)が話題になりますが、エンジニアと営業の競業(協業w)も課題になっているんじゃなかろか。
上手く協業できれば良い仕事ができるだろうし、下手すりゃ競業相手になってお客さんへのサービス品質が下がるし。
だいたい問題はお互いの仕事に対する無理解だと思うし、そうでないなら上手くいくと思う。
漠然としてるけど。
そして最近思うこと。
プロジェクトって営業→エンジニアの間でなにやら断絶される感があるけど、本来は不可分なものじゃないのだろうか?
企業単位でみたら営業の活動もエンジニアのものづくりも企業活動の一環であるし、きれいに分断なんてできないはず。
つまり両方を統括したり把握できる人が必要になるんでないかな?
求められる知識やスキルはすごい広範囲になるけどね。
「Flashのコンテンツは検索エンジンにひっかからなくて」とかボヤいてFlashを採用しないでAjaxを採用する人に朗報
Searchable SWF
GoogleとYahoo!が一緒になってSWFの中の情報を検索にひっかかるようにするんだとか。
(前からやるっていってた?)
朗報だと思います。
間違いなく。
補足しておくと得手、不得手はどんなものにもあるんだからやりたいことと実現容易性などもろもろ踏まえて考えればいいんだと思います。
SEO対策ができない、という理由は選別の要因にはならなくなる日がきっとくる、ということですか?
※ 追記
Google learns to crawl Flash
Googleからも関連する情報が。
ところでいつ実現するん?
※ 追記2(2008年7月17日)
Flashコンテンツが検索可能に
deep linkingというらしい。
GoogleとYahoo!が一緒になってSWFの中の情報を検索にひっかかるようにするんだとか。
(前からやるっていってた?)
朗報だと思います。
間違いなく。
補足しておくと得手、不得手はどんなものにもあるんだからやりたいことと実現容易性などもろもろ踏まえて考えればいいんだと思います。
SEO対策ができない、という理由は選別の要因にはならなくなる日がきっとくる、ということですか?
※ 追記
Google learns to crawl Flash
Googleからも関連する情報が。
ところでいつ実現するん?
※ 追記2(2008年7月17日)
Flashコンテンツが検索可能に
deep linkingというらしい。
snaker(RSS Reader)
Snackr:ちょっといいRSSリーダー
AIRに釣られたオレがインストールしてみましたよ、と。
なんか面白いんだけど、ハードウェアのリソースを結構食ってしまう気がする。
良いPCでデュアルディスプレイならアリだと思う。
ノートPCのタケにはツライです。
けど、飽きるまでは使ってみます。
AIRに釣られたオレがインストールしてみましたよ、と。
なんか面白いんだけど、ハードウェアのリソースを結構食ってしまう気がする。
良いPCでデュアルディスプレイならアリだと思う。
ノートPCのタケにはツライです。
けど、飽きるまでは使ってみます。
2008年6月30日月曜日
2008年6月29日日曜日
2008年6月26日木曜日
2008年6月25日水曜日
性格って大事なんだね
グーグルも実践中!「くそったれ社員」排除で収益向上
周囲に厳しく接するのと、根本的にイヤな奴というのは別ですよー、と。
確かによく目にするのが「仮想敵」を作り上げてメンバーの団結を高める手法。
あんまり好きじゃないね。
多分、私も大分イヤな奴ではなかろうかと思うけど。
周囲に厳しく接するのと、根本的にイヤな奴というのは別ですよー、と。
確かによく目にするのが「仮想敵」を作り上げてメンバーの団結を高める手法。
あんまり好きじゃないね。
多分、私も大分イヤな奴ではなかろうかと思うけど。
2008年6月24日火曜日
ビルGがかっこよすぎる件について
MS退任間近のB・ゲイツ氏--周囲の反応と自身の思い
「Microsoftの強みの多くは、Billが危機の文化を作ってくれたおかげだ。仮にGoogleが存在していなかったら、同社に代わる別のライバル企業を作り出す必要があった。Microsoftは今、これまでにない強さを誇っている。仮にBillが去り、Microsoftが新たな段階に移行しなければならないとしたら、今こそ最適な時期はないだろう」
つまりAppleもGoogleもMozillaも(Adobeも)ビルの手のひらの上ということですね。わかります。
「飢餓や死に関する問題に比べれば、誰がどのOSを使うかなど取るに足らないことだ」
かっこよすぎだろ(笑)!
「Microsoftの強みの多くは、Billが危機の文化を作ってくれたおかげだ。仮にGoogleが存在していなかったら、同社に代わる別のライバル企業を作り出す必要があった。Microsoftは今、これまでにない強さを誇っている。仮にBillが去り、Microsoftが新たな段階に移行しなければならないとしたら、今こそ最適な時期はないだろう」
つまりAppleもGoogleもMozillaも(Adobeも)ビルの手のひらの上ということですね。わかります。
「飢餓や死に関する問題に比べれば、誰がどのOSを使うかなど取るに足らないことだ」
かっこよすぎだろ(笑)!
チームのモチベーションを高めるためにリーダーができること10(+α)選
チームのモチベーションを高めるためにリーダーができること10(+α)選
マネジメントとリーディングは別のものですが、切っても切れない関係にある。
これは間違いない。
どちらにも共通するところは人と関わるということ。だからコミュニケーションがとても重要になるし、もうちょっと言い切ると自分自身が人としてちゃんとしているか、みたいなところになってくる。
だから不誠実な行動はとるべきではないし、関わるメンバーに対して誠意を持つことだ大事なんではなかろか。
これはリーダーだろうがマネジャーだろうが一メンバーだろうが変わらない。
この記事で書かれていることはとても当たり前のことだけど、不慣れな人ならそれなりに苦労するはず。
そして時間もかかかるはず。
もしマネジャーやリーダーとしてメンバーにたいするこういった「人間的な」フォローや指導ができないのであれば、できるようにしなくてはいけないし、自分の作業で手一杯でやってるヒマがないならその時間を作り出すよう努力するべきだ。
マネジメントとリーディングは別のものですが、切っても切れない関係にある。
これは間違いない。
どちらにも共通するところは人と関わるということ。だからコミュニケーションがとても重要になるし、もうちょっと言い切ると自分自身が人としてちゃんとしているか、みたいなところになってくる。
だから不誠実な行動はとるべきではないし、関わるメンバーに対して誠意を持つことだ大事なんではなかろか。
これはリーダーだろうがマネジャーだろうが一メンバーだろうが変わらない。
この記事で書かれていることはとても当たり前のことだけど、不慣れな人ならそれなりに苦労するはず。
そして時間もかかかるはず。
もしマネジャーやリーダーとしてメンバーにたいするこういった「人間的な」フォローや指導ができないのであれば、できるようにしなくてはいけないし、自分の作業で手一杯でやってるヒマがないならその時間を作り出すよう努力するべきだ。
Googleがデザイナーおよび開発者分野に進出
Googleがデザイナーおよび開発者分野に進出
「批判されてもカッとしないこと。バックエンド/フロントエンドのコードにかんする熱弁に喜んで耳を傾けること。Photoshopカンフーの使い手であること。コードを怖がらないこと」
そうそう。使ってない人から見るとカンフーに見えるwww。
あとIllustratorカンフーはいらないのかな?
いや、この記事のおもしろいところはそこじゃなくて、プログラマ/デザイナのお互いがお互いの仕事に対して無関心であってはNGで、ちゃんと関心を持って刺激し合うみたいな、「オレ、お前リスペクト」みたいな感じがいいのかな、と。
これは身近な例でみてもそのようにやっているから上手くいっているように思えるしね。
「批判されてもカッとしないこと。バックエンド/フロントエンドのコードにかんする熱弁に喜んで耳を傾けること。Photoshopカンフーの使い手であること。コードを怖がらないこと」
そうそう。使ってない人から見るとカンフーに見えるwww。
あとIllustratorカンフーはいらないのかな?
いや、この記事のおもしろいところはそこじゃなくて、プログラマ/デザイナのお互いがお互いの仕事に対して無関心であってはNGで、ちゃんと関心を持って刺激し合うみたいな、「オレ、お前リスペクト」みたいな感じがいいのかな、と。
これは身近な例でみてもそのようにやっているから上手くいっているように思えるしね。
2008年6月23日月曜日
FLASH OOP for ActionScript 3.0 Flash OOP Japan/株式会社クスール 編著
FLASH OOP for ActionScript 3.0 Flash OOP Japan/株式会社クスール 編著
この本おもしろそうだなーと思ったらwebにあるよということなので捜してみた
続Flash OOP本
あった。
でも読めない(?)ところがある。
買う方がいいのかな?
この本おもしろそうだなーと思ったらwebにあるよということなので捜してみた
続Flash OOP本
あった。
でも読めない(?)ところがある。
買う方がいいのかな?
「心理的すれ違い職場」をカイゼンせよ!――メールだけじゃダメ
「心理的すれ違い職場」をカイゼンせよ!――メールだけじゃダメ
いずれにせよ、コミュニケーションツールはとにかく多彩に持ち、TPOを勘案してパイプを太く、濃密に持つことが肝心です。人と人との関係なので、同じツールばかりでは飽きられてしまうこともあるからです。
正直、この発想はなかった。
確かに新しいツールってそれだけで気分が楽しく(あるいは煩わしく)なるね。
こうして結果が出たら、チームの皆にお礼をすると同時に、評価の面談でよかった点、至らなかった点などを率直にフィードバックします。
これを曖昧にやられると本当にムカツクね。
事実誤認とかさ。
信賞必罰を舐めてる男の人ってどうかと思う。
いずれにせよ、コミュニケーションツールはとにかく多彩に持ち、TPOを勘案してパイプを太く、濃密に持つことが肝心です。人と人との関係なので、同じツールばかりでは飽きられてしまうこともあるからです。
正直、この発想はなかった。
確かに新しいツールってそれだけで気分が楽しく(あるいは煩わしく)なるね。
こうして結果が出たら、チームの皆にお礼をすると同時に、評価の面談でよかった点、至らなかった点などを率直にフィードバックします。
これを曖昧にやられると本当にムカツクね。
事実誤認とかさ。
信賞必罰を舐めてる男の人ってどうかと思う。
ソフトウェアテスト・ミーティング2008
https://itmedia.smartseminar.jp/public/seminar/view/20
これ面白そう。
いきたいなぁー。
言語に詳しい、フレームワークに詳しい、良い設計ができる以上にテストをどうするのかをちゃんとわかっていることが、プロジェクト管理において大事な気がする今日この頃。
理由の一つとしてはテスト工程は「クリティカル・パス」になることが多く、短縮するのが難しかったりします。
ユーザー検収を開発者の都合で「1ヶ月のところを1週間でやってください」って言えないでしょ。
これ面白そう。
いきたいなぁー。
言語に詳しい、フレームワークに詳しい、良い設計ができる以上にテストをどうするのかをちゃんとわかっていることが、プロジェクト管理において大事な気がする今日この頃。
理由の一つとしてはテスト工程は「クリティカル・パス」になることが多く、短縮するのが難しかったりします。
ユーザー検収を開発者の都合で「1ヶ月のところを1週間でやってください」って言えないでしょ。
ゼロからはじめるAdobe AIR - TodoMemoを作ってみよう
ゼロからはじめるAdobe AIR - TodoMemoを作ってみよう
有償のFlexやFlashを使わないでAIRアプリを構築する方法を紹介。
"Aptana"というIDEを使うそうです。
HTML/CSS/JavaScript。
ActionScriptとJavaScriptならJavaScriptの方が書ける人多いからね。(オレはどっちもかけねー)
ActionScriptをやったことがない人のAIRのとっかかりとしては良いのかな?
それともJavaScriptでAIRアプリを作るのは今後増えるんだろうか?
それにしてもこの記事、内容充実だな~。
AIRの概要から入って、Aptana説明してHelloWorldやってアプリつくって本の宣伝してって、おい!
宣伝が目的だったんかいw!
うちの会社で誰か買わないかな~♪
有償のFlexやFlashを使わないでAIRアプリを構築する方法を紹介。
"Aptana"というIDEを使うそうです。
HTML/CSS/JavaScript。
ActionScriptとJavaScriptならJavaScriptの方が書ける人多いからね。(オレはどっちもかけねー)
ActionScriptをやったことがない人のAIRのとっかかりとしては良いのかな?
それともJavaScriptでAIRアプリを作るのは今後増えるんだろうか?
それにしてもこの記事、内容充実だな~。
AIRの概要から入って、Aptana説明してHelloWorldやってアプリつくって本の宣伝してって、おい!
宣伝が目的だったんかいw!
うちの会社で誰か買わないかな~♪
2008年6月22日日曜日
2008年6月21日土曜日
日本人はiPhoneがキライ?
日本人はiPhoneがキライ?
1.ワンセグチューナーがない
2.ケータイお財布のFelica機能がない
3.カメラが貧弱
4.パネルカラーが一色だけ
5.絵文字の表示が困難
6.日本ではケータイの契約期間が長く(普通2年でプリペイドはまずない)、契約を解除するのも困難
6.すでにiPod Touchを所有しているひとが多い(2007年10月発売)[注:番号ダブり]
7.ツメを長くのばした日本女性がたくさんいるので(ホントだよ)買わない
8.高校生はもっぱらケータイでメールを打つ。親指入力で数字キーやジョグダイアルを使うが、漢字入力にはそれがピッタリだ
9.ケータイそのもの、アクセサリ、サービスプランなどを合わせると、ソフトバンクは高額な料金設定にするのではないか
10.日本はケータイマーケットとしては世界でも最も難しい国だ(洗練された技術、要求の多い顧客、高度な技術革新など)
1コ1コだとそんなに購入/非購入の直接要因にはならなさそうだけど、これだけ集まっちゃうとね。
でもきっと売れるよ! うんざりするくらい売れるはずだ!
うんざりするくらい売れたあとにどのような市場が形成されるか?
だね。
個人的には、、、
プロダクトとしては面白そうだけど、現時点ではiPhoneが私の生活になんらかの「潤い」をもたらせてくれるとは考えづらいね。
しばらく傍観します。
1.ワンセグチューナーがない
2.ケータイお財布のFelica機能がない
3.カメラが貧弱
4.パネルカラーが一色だけ
5.絵文字の表示が困難
6.日本ではケータイの契約期間が長く(普通2年でプリペイドはまずない)、契約を解除するのも困難
6.すでにiPod Touchを所有しているひとが多い(2007年10月発売)[注:番号ダブり]
7.ツメを長くのばした日本女性がたくさんいるので(ホントだよ)買わない
8.高校生はもっぱらケータイでメールを打つ。親指入力で数字キーやジョグダイアルを使うが、漢字入力にはそれがピッタリだ
9.ケータイそのもの、アクセサリ、サービスプランなどを合わせると、ソフトバンクは高額な料金設定にするのではないか
10.日本はケータイマーケットとしては世界でも最も難しい国だ(洗練された技術、要求の多い顧客、高度な技術革新など)
1コ1コだとそんなに購入/非購入の直接要因にはならなさそうだけど、これだけ集まっちゃうとね。
でもきっと売れるよ! うんざりするくらい売れるはずだ!
うんざりするくらい売れたあとにどのような市場が形成されるか?
だね。
個人的には、、、
プロダクトとしては面白そうだけど、現時点ではiPhoneが私の生活になんらかの「潤い」をもたらせてくれるとは考えづらいね。
しばらく傍観します。
バージョンは3.1
Windows3.1なつかしす。。。
FDDで十数枚とかもうアフォかと。。。いや昔話カンケイない。Windowsの話じゃない。
Flexの話。夏ごろ3.1とのこと。
Flex 3.1 が今年の夏の後半にでるらしい...by Matt Chotin
メモメモ~。
FDDで十数枚とかもうアフォかと。。。いや昔話カンケイない。Windowsの話じゃない。
Flexの話。夏ごろ3.1とのこと。
Flex 3.1 が今年の夏の後半にでるらしい...by Matt Chotin
メモメモ~。
2008年6月20日金曜日
2008年6月19日木曜日
たとえて言うならプロジェクトデザイナー?
プロジェクトをデザインする
この考え方はとても良いと思います。
マネジメント(管理)する前に計画ちゃんとしないとね。
いきあたりばったりなプロジェクトを「マネジメントしてます!」と言われてもそれって本末転倒だよね。
この考え方はとても良いと思います。
マネジメント(管理)する前に計画ちゃんとしないとね。
いきあたりばったりなプロジェクトを「マネジメントしてます!」と言われてもそれって本末転倒だよね。
Firefox3ですな
リリースされて5時間で深刻な脆弱性発覚ですか。そうですか。
「Firefox 3」、正式リリース後5時間で初の脆弱性が見つかる
でもタケはFirefox3使ってます。
とくに理由はありません。
使い慣れたブラウザがFirefoxなだけです。
「Firefox 3」、正式リリース後5時間で初の脆弱性が見つかる
でもタケはFirefox3使ってます。
とくに理由はありません。
使い慣れたブラウザがFirefoxなだけです。
OpenProjとやら
OpenProj:優れたソフトウェアだがドキュメントの欠如が問題
某友人がどうなのよ?ってエントリーをしていたのでためしにインストール。
いちおう、MSPとのファイル互換はできるものの、、、重い! Undoが1回!?
・取引先が遠慮なくMSPファイルを送りつけてくるが自分はもっていない
・Linux環境
という状況なら使い道ありますな~。
某友人がどうなのよ?ってエントリーをしていたのでためしにインストール。
いちおう、MSPとのファイル互換はできるものの、、、重い! Undoが1回!?
・取引先が遠慮なくMSPファイルを送りつけてくるが自分はもっていない
・Linux環境
という状況なら使い道ありますな~。
ATOK定額制サービス
ジャストシステム、月額300円の「ATOK定額制サービス」を開始
年間3,200円で常に最新のATOKが使えてあのアホを使わなくてすむなら検討の余地あり、というか多分申し込む。
ちなみに会社PCはVAIOなもんでATOK搭載済み。
Excelとの相性の悪さ、Thunderbirdのショートカットに勝ってしまったりと問題がまったくないわけではないが、それでもあのアホと比べたら!
300円徴収する方が大変そうだけど法人でドカンと契約とかが見込めるのかな?
年間3,200円で常に最新のATOKが使えてあのアホを使わなくてすむなら検討の余地あり、というか多分申し込む。
ちなみに会社PCはVAIOなもんでATOK搭載済み。
Excelとの相性の悪さ、Thunderbirdのショートカットに勝ってしまったりと問題がまったくないわけではないが、それでもあのアホと比べたら!
300円徴収する方が大変そうだけど法人でドカンと契約とかが見込めるのかな?
2008年6月18日水曜日
2008年6月10日火曜日
2008年6月9日月曜日
哀・見積
タイトルはどうでもいいんですが。。。
工数(コスト)と価格を何故分離するのか!?
「①お客さまの予算-営業」と「②お客さまのスコープ-開発メンバー」でのやりとりはまったく別物だから。
②はプロジェクト開始前でさんざん変わるけど、微調整レベルまで①に影響を及ぼしていたら仕事なんないし。いちいちやってると遅いし。
②におきた変更を受けて、①も変えるべきかどうかは分離がきちんとできていないとムズイっす。
工数(コスト)と価格を何故分離するのか!?
「①お客さまの予算-営業」と「②お客さまのスコープ-開発メンバー」でのやりとりはまったく別物だから。
②はプロジェクト開始前でさんざん変わるけど、微調整レベルまで①に影響を及ぼしていたら仕事なんないし。いちいちやってると遅いし。
②におきた変更を受けて、①も変えるべきかどうかは分離がきちんとできていないとムズイっす。
2008年6月6日金曜日
[Project]もやもや見積もりと命名する!
もやもや~と機能を書き出して、
もやもや~と〆切りに合わせて要員あてこんで
もやもや~とスケジュールをひいて、、、
コストが不明で。。。
誠に勝手ですが「もやもや見積もり」と命名する!
工数(コスト)と価格は分離! 絶対分離! 分離しないと実行予算管理でおかしなことおこるし。
あと見積もった人じゃないとプロジェクト管理できないとかね。
「なんかタスク増えたけど、、、ま、いっか。利益がちょっと減るだけだし」
あああーーーーー!!!!!!
すげーもやもや!!!
なにそれ!? 気持ち悪いわっ!
もやもや~と〆切りに合わせて要員あてこんで
もやもや~とスケジュールをひいて、、、
コストが不明で。。。
誠に勝手ですが「もやもや見積もり」と命名する!
工数(コスト)と価格は分離! 絶対分離! 分離しないと実行予算管理でおかしなことおこるし。
あと見積もった人じゃないとプロジェクト管理できないとかね。
「なんかタスク増えたけど、、、ま、いっか。利益がちょっと減るだけだし」
あああーーーーー!!!!!!
すげーもやもや!!!
なにそれ!? 気持ち悪いわっ!
2008年6月4日水曜日
IT業界は成功するチャンスの多い夢のある業界
IT業界は成功するチャンスの多い夢のある業界
タケもそのように思うなー。
他の業界での仕事はもっと閉鎖的。
うんざりするくらい同じ毎日が続く。
少なくともタケが働いたことのある業界では。
会社の大きさも関係あると思うけどね。
IT業界は今やっている技術が来年には陳腐化しているかもしれない。
その速度が半端ないね。
どっちが良いかは本人しだいでしょ。
タケもそのように思うなー。
他の業界での仕事はもっと閉鎖的。
うんざりするくらい同じ毎日が続く。
少なくともタケが働いたことのある業界では。
会社の大きさも関係あると思うけどね。
IT業界は今やっている技術が来年には陳腐化しているかもしれない。
その速度が半端ないね。
どっちが良いかは本人しだいでしょ。
2008年5月27日火曜日
ズルはいかん
そんな感じの記事ですね
「倒産を招きかねない11の愚かなビジネス判断」
http://builder.japan.zdnet.com/news/story/0,3800079086,20373952,00.htm?ref=rss
「倒産を招きかねない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でユーザーエクスペリエンスなことやっていると人には「へぇ~」が高いトリビアだと思いませんか?
の意味が込められている、
という話を世界ふしぎ発見!でやってました。
> > 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普通に使えます!
あれ?
去年もやってましたね。
そこで我らが(?)Microsoft Office Projectが利用数でぶっちぎりの一位を獲得したものの、総合満足度「58点」というなんともしょっぱい結果をたたき出しました。
そうね。
たしかにね。
作法はうるさく融通聞かず。
かゆいところにまったく手が届かず。
でもツールのせいだけじゃないはず。
利用者はプロジェクトというものがそもそもどういったものなのか、どういった特徴をもつのか等を理解しているのだろうか?
プロジェクトがわかっていないのに、MSP使いこなすのは無理なはず。
Javaわかんない人にEclipse使わせてもJavaのプログラミングできないし。
じゃあ、タケがそもそもプロジェクトを理解しているか?
NO!
まったくわかりません!!
でもMSP普通に使えます!
あれ?
2008年5月25日日曜日
ソフトウェア開発会社の文化
「3年で辞めた若者はどこへ行ったのか (城繁幸 著)」
インタビュー集? 他業界の人と接する機会が少ないので勉強になった。
「ソフトウェア開発者 採用ガイド (Joel Spolsky)」
いま読み途中。
ワロス。電車の中でニヤニヤしてたり。
採用する側だけでなく、採用される側のエンジニアが読んでみても良い気がする?
時間があれば。
たまたま人材系の本が連発しました。
そして思うのがソフトウェアの開発をやっている企業がどういった「文化」を持つのが良いのか?みたいな。
組織としての効率性を上げていくのならある程度の規則や「型にはめる」ことは必要。
しかしいきすぎれば自由な発想や意見交換の場を失う(→いわれたことだけやる)。
そもそも仕事詰めすぎれば自由な発想や意見交換の時間をもなくなる。
その場合、遅かれ早かれ起業時にもっていたとがった部分がなくなる。
それの行き着く先は…?
n○dさん(伏せ字になってない)が「この業界は人が大事だ」って話してたなー。
そりゃそうなんですよ。
設備に投資できるお金はたかがしれているし。
「究極の指示待ち野郎(from「ウチのシステムはなぜ使えない」)」のコンピュータさんは人がいなけりゃなんもできないし。
ノウハウの共有や文書化だって限界がある。
結局、人の頭の中に蓄積される。
人! 人! 人!
人がいなけりゃなんにもできないどころか、「その人」がいないとなんにもできない。
ソフトウェア開発はそういう特徴を強くもっているのでは?
ものすごい難易度の高いプログラムを、新人プログラマ100人集めて書けるのか? 無理でしょ。
Joel曰く、
「(省略)必要な技術書は何でも自由にAmazon.comで注文させるべきだ。」
とのこと。
良いこと言った!
スゲー良いこと言ったよ、Joel!!
…話がそれた(本音が出た)。
ていうかまとまらん。
ま、タケにはいかなる決裁権も発言権もないですが。
インタビュー集? 他業界の人と接する機会が少ないので勉強になった。
「ソフトウェア開発者 採用ガイド (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で見た目を変える。
これらは開発が上手くできていれば変更拡張は簡単
よって
管理者は業務に集中できる
ユーザーは改善要望をだしやすくなる。
より強力にシステムを使い倒すことができる
そして開発ベンダーをキープしましょう。またキープできるベンダーを探しましょう。
保守体制を切り分けましょう
ユーザー → 一時対応(あなた)→対策(ベンダー)
「もちはもちやに」
結構、大切なんですよ♪
逆説的に言うと
ユーザーが使いづらいのに改善されないシステムとの決別
以下、本文
ビジネス視点の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
なんかコメント欄をみて思ったんだけど「昔からある~」はコードアンドフィックスモデルだよね。
プログラミングファースト開発の中身はわかってないですけど、そのプロセスにはちゃんと秩序があってそれにそって進めていくんだよね。
コードアンドフィックスモデルは計画がなく、工程管理もできずといったものなので根本的に違うはず。
コメントの意図するところがわかんないので推測ですが。。。
駄目なアジャイルが無計画でアジャイル(笑)になってしまうことの弊害とか先入観からきてるのかと。
タケはアジャイルであったりインクリメンタルな開発プロセスのほうがソフトウェアの開発には適しているとは思いますが、〆切りをおそれたり計画を立てることを面倒くさがってアジャイルを適用するのは違うよね、と。
・考える
・実行する
・確認する
「考える」の放棄はろくなことないです
http://d.hatena.ne.jp/higayasuo/20080501/1209636051
なんかコメント欄をみて思ったんだけど「昔からある~」はコードアンドフィックスモデルだよね。
プログラミングファースト開発の中身はわかってないですけど、そのプロセスにはちゃんと秩序があってそれにそって進めていくんだよね。
コードアンドフィックスモデルは計画がなく、工程管理もできずといったものなので根本的に違うはず。
コメントの意図するところがわかんないので推測ですが。。。
駄目なアジャイルが無計画でアジャイル(笑)になってしまうことの弊害とか先入観からきてるのかと。
タケはアジャイルであったりインクリメンタルな開発プロセスのほうがソフトウェアの開発には適しているとは思いますが、〆切りをおそれたり計画を立てることを面倒くさがってアジャイルを適用するのは違うよね、と。
・考える
・実行する
・確認する
「考える」の放棄はろくなことないです
2008年5月1日木曜日
2008年4月23日水曜日
[memo]勝てる見積もり
仕事柄、何度となく見積もりを書いていますが、やっぱり仕事とれないとどんなに「美しい」見積もり書いても意味ねーと思うんですよ。
というわけで「勝てる見積もり」についてアイディアをメモ。これからブラッシュアップ。
・組織として一定のフローを持つこと
・モデルシステム
業種ごとにいくつかのモデルシステムを作る(あくまで見積もりとプロジェクト計画の話)
依頼された見積もりはモデルシステムをベースに差分を数えることで規模間を算出する。
これは営業段階でやっていいプロジェクトかどうかを判断できる
・モデルプロジェクト
モデルシステムに対してどこまでが決定事項なのか判断する。
・モデルシステムとモデルプロジェクトのメンテナンス
日常業務と密接に結びついて、常に最新の状態を保つこと。
・お客さまはコストだけを見ているわけではないこと
・品質
広義の意味で。ユーザビリティといった数値化しづらい付加価値についてもしっかりアピールすること
・コスト
安いに超したことはないが、お客さまがシステムに対して求める条件を満たすために必要十分なコストを
請求すること。
・納期
ほとんどの場合、システムは1日も早くビジネスの現場に投入される必要がある。
・スコープ
スコープ網羅率。QCDと関わる要素だが、お客さまの求めるものを作りきること。場合によっては機能スコープに優先度をつけ、お客さまに対し「過剰な機能」であることを伝えること
・マイルストーン
いつの段階でどういったものがだせるか? 見せられるか? エンジニアの都合だけで進めず、プロジェクトの可視化も含めて宣言をすること
というわけで「勝てる見積もり」についてアイディアをメモ。これからブラッシュアップ。
・組織として一定のフローを持つこと
・モデルシステム
業種ごとにいくつかのモデルシステムを作る(あくまで見積もりとプロジェクト計画の話)
依頼された見積もりはモデルシステムをベースに差分を数えることで規模間を算出する。
これは営業段階でやっていいプロジェクトかどうかを判断できる
・モデルプロジェクト
モデルシステムに対してどこまでが決定事項なのか判断する。
・モデルシステムとモデルプロジェクトのメンテナンス
日常業務と密接に結びついて、常に最新の状態を保つこと。
・お客さまはコストだけを見ているわけではないこと
・品質
広義の意味で。ユーザビリティといった数値化しづらい付加価値についてもしっかりアピールすること
・コスト
安いに超したことはないが、お客さまがシステムに対して求める条件を満たすために必要十分なコストを
請求すること。
・納期
ほとんどの場合、システムは1日も早くビジネスの現場に投入される必要がある。
・スコープ
スコープ網羅率。QCDと関わる要素だが、お客さまの求めるものを作りきること。場合によっては機能スコープに優先度をつけ、お客さまに対し「過剰な機能」であることを伝えること
・マイルストーン
いつの段階でどういったものがだせるか? 見せられるか? エンジニアの都合だけで進めず、プロジェクトの可視化も含めて宣言をすること
2008年4月16日水曜日
[Project]アジャイル(笑)
アジャイル型の開発プロセスを採用すれば全てが解決、さよならデスマーチ、こんにちは働きやすい環境とすばらしい品質のソフトウエア…、そんなわけないですよね。
アジャイル型の開発プロセスにも「作法」のようなものがあるし、それらがプラクティスと呼ばれたりしていて、先人の知恵を上手く取り入れないといけないわけです。
前述のような幻想は誤った認識で広まった非可逆のウォータフォール型の開発プロセスのせいかと思います。多くの人にとって〆切りに追われるのは気持ちが良いものではないですし。
アジャイル型も非可逆のウォーターフォールもそれぞれに長所はあるわけです。
結局、短期の計画、中期の計画、長期の計画をつくり、その計画をメンテナンスしながらプロジェクトを進めることが大事なわけで、無計画にやればいいってもんじゃないはず。
出たとこ勝負、行き当たりばったり = アジャイル(笑)
ちょっと人伝で聞いた話でちょっと「むむむ?」思ったので書きました。
アジャイル型の開発プロセスにも「作法」のようなものがあるし、それらがプラクティスと呼ばれたりしていて、先人の知恵を上手く取り入れないといけないわけです。
前述のような幻想は誤った認識で広まった非可逆のウォータフォール型の開発プロセスのせいかと思います。多くの人にとって〆切りに追われるのは気持ちが良いものではないですし。
アジャイル型も非可逆のウォーターフォールもそれぞれに長所はあるわけです。
結局、短期の計画、中期の計画、長期の計画をつくり、その計画をメンテナンスしながらプロジェクトを進めることが大事なわけで、無計画にやればいいってもんじゃないはず。
出たとこ勝負、行き当たりばったり = アジャイル(笑)
ちょっと人伝で聞いた話でちょっと「むむむ?」思ったので書きました。
2008年4月13日日曜日
[Project][memo]受託開発の極意
「受託開発の極意(岡島幸男[著] 技術評論社)」を読みました。
思ったことをメモ。
でもメモ意味ないかも。
手元に置いてふとしたときに手にとって読む。
自分やチームの仕事の仕方を振り返ってみる。
自分と役割が近い人、仕事で関わることが多い人と読み合わせて語り合ってみる。
それぐらいしたい本でした。
ここであえてふれていないColumnも役立つ情報多かったし!
なので
「購 読 す る こ と を オ ス ス メ し ま す」
0章 受託開発を楽しむには
0.2
「顧客満足の公式」
顧客満足はQCDからなる成果物に対する「結果」と、仕事を進めていく過程にたいする「感情」の両面からなるということ。
私も恩師から「お客さんは感動に対してお金を払う」といわれたことがあるので、この説明はとても納得。
(こまかく話すとちょっと違うんだけどね)
第1部 受託開発の手ほどき
第1章 お客様に関心をもつ
1.1
「7段階にもネストしたif文や~」
ごめん。それオレ(笑)。
正確に言うとExcelの関数でIF文の限界にチャレンジしてた。無知って恐ろしい。
1.2
「要はお客さまと接する機会が少ないため関心が持てないのです。会ってもいない人に関心を持つことはできません」
激しく同意! ちなみに私はお客さまとお会いしないと仕事できないタイプ。
たまにお客さまの顔見ないで仕事する必要が発生しますが、なんかあってもちゃんと判断できないですよ。
情報が一方的に的になっちゃうから。
1.6
「お客さまの立場でプロジェクトを眺める」
仕事してるとついついこっち都合を優先しちゃったりするのですが、、、いかんですよね。
猛省です。
第2章
「サービスは見積りから始まっている」
スティーブ・マコネルの『ソフトウェア見積り』が引き合いに出されています。
タケも読みました!
マコネル最高w この本に書かれている見積もりに関する話は非常に奥が深い!
2.2
「お客さまは金額だけで発注先を決めるのではありません。見積もり期間におけるサービスの質も重視しましょう。」
うっすらわかっているようでいてちゃんとわかっていなかったこと。
言い換えると安易な価格勝負すんな! と。
もし価格勝負をするために意図的にテスト期間を短くして品質を下げるようなことがあるなら、いかんですよね。
システムに関わるもののモラルの問題も含めて、見積もりはしっかりやらないと。
また「プラスα」はいままでまったくできてなかった。スキル不足と時間不足のせいにして。これもなんとかしたいなぁ。
2.4
「見積もり手法を身につける」
「オブジェクト倶楽部」のワークシートが紹介されていました(http://www.objectclub.jp/download/)。
今度、試してみよう♪
タケはそんなに見積もり手法を勉強した訳じゃないですけど、いろいろな手法を知ったり勉強したりすると見積もりに対する考え方に厚みがでる気がします。
日々勉強ですな。
第3章
3.1
「実質、要件は変わったのではなく、間違って定義されてしまっていることが多いのです。」
そうっすよね!
あとプロジェクトがキックオフするときに営業から開発へ情報伝達が上手く言ってない場合!
これもある意味、間違った要件定義。
話変わりますけど、RIA開発に関わっていると「デザイナとデベロッパの協業」についてよく議題にあがりますが、それ以上に営業と技術者の協業の方が問題な気がします。
炎上する原因てだいたいそれだよね。
3.2
手段ばかりに着目するのではなく何を何故作るのか!? を考えなさいと。なんかもう御礼言いたいです。
3.4
「表3-1 システム要件で定義する内容」
これもきっちり認識する必要あり。
3.7
「丸投げドキュメントの読み方」
これは丸投げドキュメントに限らない気がするのですが、それってタケがいつも丸投げされている証拠?
第4章 保守性にこだわった設計・実装・テスト
4.4
単体テストが重要だというのは重々承知していたつもりですが、サンプルとして数値でだされるとその重要さをより認識することができます。
4.5
テスト計画の重要性、各フェーズで何を気をつけるべきかが書いてあります。品質をどこまで保証する、つまりどれくらいテストをしっかりやるか、どういった分担で行うのか、どういったアプローチをとるのかはプロジェクトを始める前にしっかり決めておかないといけないはずです。
またテストは私の知る限りでは必ずと言っていいほどクリティカルパスになります。
テストちょー重要!
第5章 運用が最上流
5.2
「お客さまとの信頼関係も保守する」
なんて良いことを言うんだろう。。。
5.3
「テスト資産を活かす」
なんだかんだ言って、同じテストを何度も何度もやることになることがあります。
そう考えたらテスト計画やテスト仕様書、結果はしっかり書かなきゃいけないし、ツールを使って自動化できるんだったらやっておいた方がいいかもしれません。
第6章 計画とスケジュールの管理
「計画がないプロジェクトはありえませんし、計画が頻繁に変わるからといって、まったく無秩序ではいけません。計画は管理・メンテナンスするものです。」
私の作るMSPがプロジェクト開始2週間でぐっちゃぐちゃになるのはMSPがダメなツールだからではなくて、プロジェクトの計画と実行と管理というのはそんなもんだからです。全然変わらない場合は「わーい♪」と喜んでないで潜在リスクがないか考えないと。
6.1
「3つのスケジュールを使い分ける」
これは目から鱗。。。
プロジェクトを進めていく内にだんだんブレイクダウンしていくことはありますが、明確に3つに分ける(違うものだと認識する)のは考えてなかった。。。
きっと当たり前なんだろうな。自分の無知がおそろすぃ。
6.3
「見積もりが外れる原因と対策」
私は個人的には下記のように考えています。ちなみにKKD法(笑)ね。
・経験
→タスク洗い出し、アプリーチやプロセスの選択、プロジェクト基盤作成に必要なことや技術知識などなど。
・勘
→潜在するリスクをあげること。ここは○○日じゃないだろう…とか、ここで詰まるだろう…とか。
・度胸
→工数を「削る」のは度胸! ここは○○日もいらないだろう…とか。超安全見積もりで仕事がとれるほど世の中そんなに甘くない!
6.5
「プレッシャーを感じたままスケジュールや計画を立てると、手段の目的化が起きます。」
私はプロジェクトの計画を立てるのと見積もりを書くのは限りなく近い作業であると認識しているので、それを前提に話すと、見積もりを書くときに入ってくる情報が「参考値」なのか「制約条件」なのかはちゃんと切り分ける必要があります。
特に予算はね。書こうと思えば書けるんですよ。予算内で。やべーな、と思ってても。。。
ましてや見積もりを書く人間より、その情報をもってくる人が年長者だったり経験が豊富だったり組織内で権力もってたりすると、余計にやっかいです。そういうもんだって思っちゃうからね。
第7章 チームで成功を目指す
7.3
「表7-1 リーダーのカラー別の特徴」
これわ。。。「ボケボケ」型ってないんですか? タケはボケボケ型だと思います。
7.4
「お客さまに対する陰口を止めてみる」
コラッ!
7.5
「交渉力」
勝ち過ぎない、っていうのはわりと意識してやってますね。
でもそれでつけ込まれて不利になることが多い気もします。。。さじ加減が難しい。
第2部 人と組織を変えること
8.5
「問題なのは相対評価を気にするあまり自信をなくし、自分が何を目指したいのかわからなくなってしまうことです。」
うーむ。確かにわからなくなっている気がしますなー
Column
「アムロとブライトさんのセリフ」
岡島さんとは美味い酒がのめそう(笑)。
タケはもう子供がいて30歳にもなったので「若さ故の過ちか…」と言えない感じです。
思ったことをメモ。
でもメモ意味ないかも。
手元に置いてふとしたときに手にとって読む。
自分やチームの仕事の仕方を振り返ってみる。
自分と役割が近い人、仕事で関わることが多い人と読み合わせて語り合ってみる。
それぐらいしたい本でした。
ここであえてふれていないColumnも役立つ情報多かったし!
なので
「購 読 す る こ と を オ ス ス メ し ま す」
0章 受託開発を楽しむには
0.2
「顧客満足の公式」
顧客満足はQCDからなる成果物に対する「結果」と、仕事を進めていく過程にたいする「感情」の両面からなるということ。
私も恩師から「お客さんは感動に対してお金を払う」といわれたことがあるので、この説明はとても納得。
(こまかく話すとちょっと違うんだけどね)
第1部 受託開発の手ほどき
第1章 お客様に関心をもつ
1.1
「7段階にもネストしたif文や~」
ごめん。それオレ(笑)。
正確に言うとExcelの関数でIF文の限界にチャレンジしてた。無知って恐ろしい。
1.2
「要はお客さまと接する機会が少ないため関心が持てないのです。会ってもいない人に関心を持つことはできません」
激しく同意! ちなみに私はお客さまとお会いしないと仕事できないタイプ。
たまにお客さまの顔見ないで仕事する必要が発生しますが、なんかあってもちゃんと判断できないですよ。
情報が一方的に的になっちゃうから。
1.6
「お客さまの立場でプロジェクトを眺める」
仕事してるとついついこっち都合を優先しちゃったりするのですが、、、いかんですよね。
猛省です。
第2章
「サービスは見積りから始まっている」
スティーブ・マコネルの『ソフトウェア見積り』が引き合いに出されています。
タケも読みました!
マコネル最高w この本に書かれている見積もりに関する話は非常に奥が深い!
2.2
「お客さまは金額だけで発注先を決めるのではありません。見積もり期間におけるサービスの質も重視しましょう。」
うっすらわかっているようでいてちゃんとわかっていなかったこと。
言い換えると安易な価格勝負すんな! と。
もし価格勝負をするために意図的にテスト期間を短くして品質を下げるようなことがあるなら、いかんですよね。
システムに関わるもののモラルの問題も含めて、見積もりはしっかりやらないと。
また「プラスα」はいままでまったくできてなかった。スキル不足と時間不足のせいにして。これもなんとかしたいなぁ。
2.4
「見積もり手法を身につける」
「オブジェクト倶楽部」のワークシートが紹介されていました(http://www.objectclub.jp/download/)。
今度、試してみよう♪
タケはそんなに見積もり手法を勉強した訳じゃないですけど、いろいろな手法を知ったり勉強したりすると見積もりに対する考え方に厚みがでる気がします。
日々勉強ですな。
第3章
3.1
「実質、要件は変わったのではなく、間違って定義されてしまっていることが多いのです。」
そうっすよね!
あとプロジェクトがキックオフするときに営業から開発へ情報伝達が上手く言ってない場合!
これもある意味、間違った要件定義。
話変わりますけど、RIA開発に関わっていると「デザイナとデベロッパの協業」についてよく議題にあがりますが、それ以上に営業と技術者の協業の方が問題な気がします。
炎上する原因てだいたいそれだよね。
3.2
手段ばかりに着目するのではなく何を何故作るのか!? を考えなさいと。なんかもう御礼言いたいです。
3.4
「表3-1 システム要件で定義する内容」
これもきっちり認識する必要あり。
3.7
「丸投げドキュメントの読み方」
これは丸投げドキュメントに限らない気がするのですが、それってタケがいつも丸投げされている証拠?
第4章 保守性にこだわった設計・実装・テスト
4.4
単体テストが重要だというのは重々承知していたつもりですが、サンプルとして数値でだされるとその重要さをより認識することができます。
4.5
テスト計画の重要性、各フェーズで何を気をつけるべきかが書いてあります。品質をどこまで保証する、つまりどれくらいテストをしっかりやるか、どういった分担で行うのか、どういったアプローチをとるのかはプロジェクトを始める前にしっかり決めておかないといけないはずです。
またテストは私の知る限りでは必ずと言っていいほどクリティカルパスになります。
テストちょー重要!
第5章 運用が最上流
5.2
「お客さまとの信頼関係も保守する」
なんて良いことを言うんだろう。。。
5.3
「テスト資産を活かす」
なんだかんだ言って、同じテストを何度も何度もやることになることがあります。
そう考えたらテスト計画やテスト仕様書、結果はしっかり書かなきゃいけないし、ツールを使って自動化できるんだったらやっておいた方がいいかもしれません。
第6章 計画とスケジュールの管理
「計画がないプロジェクトはありえませんし、計画が頻繁に変わるからといって、まったく無秩序ではいけません。計画は管理・メンテナンスするものです。」
私の作るMSPがプロジェクト開始2週間でぐっちゃぐちゃになるのはMSPがダメなツールだからではなくて、プロジェクトの計画と実行と管理というのはそんなもんだからです。全然変わらない場合は「わーい♪」と喜んでないで潜在リスクがないか考えないと。
6.1
「3つのスケジュールを使い分ける」
これは目から鱗。。。
プロジェクトを進めていく内にだんだんブレイクダウンしていくことはありますが、明確に3つに分ける(違うものだと認識する)のは考えてなかった。。。
きっと当たり前なんだろうな。自分の無知がおそろすぃ。
6.3
「見積もりが外れる原因と対策」
私は個人的には下記のように考えています。ちなみにKKD法(笑)ね。
・経験
→タスク洗い出し、アプリーチやプロセスの選択、プロジェクト基盤作成に必要なことや技術知識などなど。
・勘
→潜在するリスクをあげること。ここは○○日じゃないだろう…とか、ここで詰まるだろう…とか。
・度胸
→工数を「削る」のは度胸! ここは○○日もいらないだろう…とか。超安全見積もりで仕事がとれるほど世の中そんなに甘くない!
6.5
「プレッシャーを感じたままスケジュールや計画を立てると、手段の目的化が起きます。」
私はプロジェクトの計画を立てるのと見積もりを書くのは限りなく近い作業であると認識しているので、それを前提に話すと、見積もりを書くときに入ってくる情報が「参考値」なのか「制約条件」なのかはちゃんと切り分ける必要があります。
特に予算はね。書こうと思えば書けるんですよ。予算内で。やべーな、と思ってても。。。
ましてや見積もりを書く人間より、その情報をもってくる人が年長者だったり経験が豊富だったり組織内で権力もってたりすると、余計にやっかいです。そういうもんだって思っちゃうからね。
第7章 チームで成功を目指す
7.3
「表7-1 リーダーのカラー別の特徴」
これわ。。。「ボケボケ」型ってないんですか? タケはボケボケ型だと思います。
7.4
「お客さまに対する陰口を止めてみる」
コラッ!
7.5
「交渉力」
勝ち過ぎない、っていうのはわりと意識してやってますね。
でもそれでつけ込まれて不利になることが多い気もします。。。さじ加減が難しい。
第2部 人と組織を変えること
8.5
「問題なのは相対評価を気にするあまり自信をなくし、自分が何を目指したいのかわからなくなってしまうことです。」
うーむ。確かにわからなくなっている気がしますなー
Column
「アムロとブライトさんのセリフ」
岡島さんとは美味い酒がのめそう(笑)。
タケはもう子供がいて30歳にもなったので「若さ故の過ちか…」と言えない感じです。
2008年4月10日木曜日
[Project]PMOってなーに?
社内のメンバーに私なりのPMOが何かを伝えたくて書きました。
以下、本文。
はじめに
PMBOKのPMOの定義を確認
******PMBOK3版より******
1.6.4 プロジェクトマネジメント・オフィス
プロジェクトマネジメント・オフィス(PMO)は、その管轄下にある複数のプロジェクトのマネジメントを一元化し、調整を行う組織の一部門である。PMOは、「プロジェクトマネジメント・オフィス」、「プロジェクト・オフィス」、または「プログラム・オフィス」と呼ばれることもある。PMOは、プロジェクト、プログラム、またはその両方を監視する。PMOによって支援または管理されるプロジェクト群は、一緒にマネジメントされるということ意外に相互の関係はない場合もある。もちろん、関係のある複数のプロジェクトの調整およびマネジメントをPMOが行う場合もある。多くの組織において、PMOがプロジェクトを調整し、マネジメントする方法に従って、複数のプロジェクトは実際にグループ化されるか、または、関係付けられる。PMOの主たる関心事は、親組織またはクライアントの全体的なビジネス目標に関連するプロジェクトおよびサブプロジェクトに対する計画調整、優先順位設定、および実行ということである。
PMOは、トレーニング、ソフトウェア、標準化された方針および手続きという形態でのプロジェクトマネジメント支援機能の提供を始めとし、実際の直接マネジメントやプロジェクト目標の達成責任に至るまでの連続的な範囲全体の中で、種々の機能を果たすことができる。ある種のPMOは、権限の委譲を受けて、中心的なステークホルダーとして行動し、また、各プロジェクトの初期段階時の重要な意志決定を行うことがある。このPMOは、提案の権限を持ち、ビジネス目標の一貫性を保つためにプロジェクトを中止することもできる。さらに、このPMOは、必要に応じて、複数プロジェクトを兼任する要員や、プロジェクト専従要員(可能な場合)の選択、マネジメント、再配置に関与することができる。
******ここまで******
分解
■前半部分
読む人によって解釈が大きく異なることはないと思うので放置
■後半部分
ここからが濃い
> PMOは、トレーニング、ソフトウェア、標準化された方針およ
> び手続きという形態でのプロジェクトマネジメント支援機能の
> 提供を始めとし、実際の直接マネジメントやプロジェクト目標
> の達成責任に至るまでの連続的な範囲全体の中で、種々の機能
> を果たすことができる。
これはPMO管轄下ある全てのプロジェクトの成功に対して責任をもち、あらゆる手段で実施や支援をしろ、ということです。
「連続的な範囲全体の中」という表現がミソ。プロジェクトは様々な要因が集合しているので、何か一つの課題を解決したら即、プロジェクト成功というのは難しい。
「制約条件の理論(ボトルネックがなんちゃらいうやつ)」を参考にすると、一つのボトルネックを解決すると別の場所がボトルネックになると説明しています。言い換えれば改善活動に終わりはない、ということです。極端な話、短所と思われる箇所を全て改善したら、いままで長所と思っていた箇所が短所に変わることもありえます。
> ある種の
> PMOは、権限の委譲を受けて、中心的なステークホルダーとし
> て行動し、また、各プロジェクトの初期段階時の重要な意志
> 決定を行うことがある。このPMOは、提案の権限を持ち、ビジネ
> ス目標の一貫性を保つためにプロジェクトを中止することもで
> きる。さらに、このPMOは、必要に応じて、複数プロジェクト
> を兼任する要員や、プロジェクト専従要員(可能な場合)の選択、
> マネジメント、再配置に関与することができる。
私の個人的な解釈は「組織とそれに関わる全ての人を守れ」という意味合いととらえています。
だいぶ端折った見方ですが、こう言うと重いですよね。。。
これを行うには、IT業界においてはテクニカルスキルも重要ですし、プロジェクトをまとめるマネジメントスキルも必要です。また正しいものがいつでも成功するとは限りません。
一方的な見解による無理難題は政治的なスキルで解決することも必要です。
ここで「タケの働く会社」のこれまでを振り返ってみます。
先月PMOの活動が止まった理由は何だったでしょうか?
みんなで時間をつくって集まった課外活動が半ば空中分解し、参加メンバーにそのアウトプットを提示できなかったのは何ででしょう?
かつては行われていたという月1飲み会をやっていないのは?
勉強会は業務という形で○○さんが実施するようになりましたが、かつてのように有志が講師の役をかって行うことは減りました。
極論、みんな目の前の仕事が忙しくて時間がとれないせいです。
(メンバーが増えたこともそうですが、あえて置いておく)
新しい取り組み、新しい技術の習得、それらに対するメンテナンス活動、何をやるにしても時間が必要です。モチベーションを上げるための施策、コミュニケーションを深めるための行事だって時間が必要です。
当たり前だけど、これらの時間をとるための試みが二の次になっていました。
だいたいが厳しいプロジェクトをやっていたがために、そういった状態になっていたのだと思います。
じゃ厳しいプロジェクトって何であるの? と。
これは内的要因、外的要因が複雑に絡むので答えを単純に言うことは無理です。
とは言うものの、私、個人的な意見としてクラスメソッドの場合は無計画なプロジェクトのキックオフが原因のほとんどであると思います。
また営業サイド、情シスサイドの連携ミスや齟齬もあるでしょう。
よく言うように炎上する案件は炎上するべくして炎上する。
デスマーチプロジェクトはプロジェクト始まる前から決まっているんです。
難しい課題ですが情シスメンバーの稼働率を下げ、新しい施策のための時間を作り出し、効果的な取り組みを行って、会社とそれに関わる人達の成長と幸せを促す。
それを目指すのがPMOの存在意義だと思っています。
でも難しい。
ちょー難しい。
解決する課題は一つじゃありません。前述したように「連続的な
範囲全体」なのでやることいっぱいあります。
営業と上手く連携することも必要です。
メンバーのスキルをどういった方向にのばしていくのか、これはテクニカルな課題もありつつマーケティング的な分野にも関わってきます。
「タケの働く会社」の生産性を考慮して他社に勝てる見積もりをだして、その上でみんなまともな時間で帰ってもプロジェクト成功、というのは本当にいろんなことを改善しないとたどり着けないと思います。
まじでマーケティングも必要ですね。
PMOじゃなくてPMMOにしたいくらい。
とは言うものの「タケの働く会社」にとってPMOは心臓であり脳でもあると思います。
JavaにたとえたらきっとJVMでしょう。よくわからんけど。
それだけスゴイぞ、と伝えたかったのです。
以下、本文。
はじめに
PMBOKのPMOの定義を確認
******PMBOK3版より******
1.6.4 プロジェクトマネジメント・オフィス
プロジェクトマネジメント・オフィス(PMO)は、その管轄下にある複数のプロジェクトのマネジメントを一元化し、調整を行う組織の一部門である。PMOは、「プロジェクトマネジメント・オフィス」、「プロジェクト・オフィス」、または「プログラム・オフィス」と呼ばれることもある。PMOは、プロジェクト、プログラム、またはその両方を監視する。PMOによって支援または管理されるプロジェクト群は、一緒にマネジメントされるということ意外に相互の関係はない場合もある。もちろん、関係のある複数のプロジェクトの調整およびマネジメントをPMOが行う場合もある。多くの組織において、PMOがプロジェクトを調整し、マネジメントする方法に従って、複数のプロジェクトは実際にグループ化されるか、または、関係付けられる。PMOの主たる関心事は、親組織またはクライアントの全体的なビジネス目標に関連するプロジェクトおよびサブプロジェクトに対する計画調整、優先順位設定、および実行ということである。
PMOは、トレーニング、ソフトウェア、標準化された方針および手続きという形態でのプロジェクトマネジメント支援機能の提供を始めとし、実際の直接マネジメントやプロジェクト目標の達成責任に至るまでの連続的な範囲全体の中で、種々の機能を果たすことができる。ある種のPMOは、権限の委譲を受けて、中心的なステークホルダーとして行動し、また、各プロジェクトの初期段階時の重要な意志決定を行うことがある。このPMOは、提案の権限を持ち、ビジネス目標の一貫性を保つためにプロジェクトを中止することもできる。さらに、このPMOは、必要に応じて、複数プロジェクトを兼任する要員や、プロジェクト専従要員(可能な場合)の選択、マネジメント、再配置に関与することができる。
******ここまで******
分解
■前半部分
読む人によって解釈が大きく異なることはないと思うので放置
■後半部分
ここからが濃い
> PMOは、トレーニング、ソフトウェア、標準化された方針およ
> び手続きという形態でのプロジェクトマネジメント支援機能の
> 提供を始めとし、実際の直接マネジメントやプロジェクト目標
> の達成責任に至るまでの連続的な範囲全体の中で、種々の機能
> を果たすことができる。
これはPMO管轄下ある全てのプロジェクトの成功に対して責任をもち、あらゆる手段で実施や支援をしろ、ということです。
「連続的な範囲全体の中」という表現がミソ。プロジェクトは様々な要因が集合しているので、何か一つの課題を解決したら即、プロジェクト成功というのは難しい。
「制約条件の理論(ボトルネックがなんちゃらいうやつ)」を参考にすると、一つのボトルネックを解決すると別の場所がボトルネックになると説明しています。言い換えれば改善活動に終わりはない、ということです。極端な話、短所と思われる箇所を全て改善したら、いままで長所と思っていた箇所が短所に変わることもありえます。
> ある種の
> PMOは、権限の委譲を受けて、中心的なステークホルダーとし
> て行動し、また、各プロジェクトの初期段階時の重要な意志
> 決定を行うことがある。このPMOは、提案の権限を持ち、ビジネ
> ス目標の一貫性を保つためにプロジェクトを中止することもで
> きる。さらに、このPMOは、必要に応じて、複数プロジェクト
> を兼任する要員や、プロジェクト専従要員(可能な場合)の選択、
> マネジメント、再配置に関与することができる。
私の個人的な解釈は「組織とそれに関わる全ての人を守れ」という意味合いととらえています。
だいぶ端折った見方ですが、こう言うと重いですよね。。。
これを行うには、IT業界においてはテクニカルスキルも重要ですし、プロジェクトをまとめるマネジメントスキルも必要です。また正しいものがいつでも成功するとは限りません。
一方的な見解による無理難題は政治的なスキルで解決することも必要です。
ここで「タケの働く会社」のこれまでを振り返ってみます。
先月PMOの活動が止まった理由は何だったでしょうか?
みんなで時間をつくって集まった課外活動が半ば空中分解し、参加メンバーにそのアウトプットを提示できなかったのは何ででしょう?
かつては行われていたという月1飲み会をやっていないのは?
勉強会は業務という形で○○さんが実施するようになりましたが、かつてのように有志が講師の役をかって行うことは減りました。
極論、みんな目の前の仕事が忙しくて時間がとれないせいです。
(メンバーが増えたこともそうですが、あえて置いておく)
新しい取り組み、新しい技術の習得、それらに対するメンテナンス活動、何をやるにしても時間が必要です。モチベーションを上げるための施策、コミュニケーションを深めるための行事だって時間が必要です。
当たり前だけど、これらの時間をとるための試みが二の次になっていました。
だいたいが厳しいプロジェクトをやっていたがために、そういった状態になっていたのだと思います。
じゃ厳しいプロジェクトって何であるの? と。
これは内的要因、外的要因が複雑に絡むので答えを単純に言うことは無理です。
とは言うものの、私、個人的な意見としてクラスメソッドの場合は無計画なプロジェクトのキックオフが原因のほとんどであると思います。
また営業サイド、情シスサイドの連携ミスや齟齬もあるでしょう。
よく言うように炎上する案件は炎上するべくして炎上する。
デスマーチプロジェクトはプロジェクト始まる前から決まっているんです。
難しい課題ですが情シスメンバーの稼働率を下げ、新しい施策のための時間を作り出し、効果的な取り組みを行って、会社とそれに関わる人達の成長と幸せを促す。
それを目指すのがPMOの存在意義だと思っています。
でも難しい。
ちょー難しい。
解決する課題は一つじゃありません。前述したように「連続的な
範囲全体」なのでやることいっぱいあります。
営業と上手く連携することも必要です。
メンバーのスキルをどういった方向にのばしていくのか、これはテクニカルな課題もありつつマーケティング的な分野にも関わってきます。
「タケの働く会社」の生産性を考慮して他社に勝てる見積もりをだして、その上でみんなまともな時間で帰ってもプロジェクト成功、というのは本当にいろんなことを改善しないとたどり着けないと思います。
まじでマーケティングも必要ですね。
PMOじゃなくてPMMOにしたいくらい。
とは言うものの「タケの働く会社」にとってPMOは心臓であり脳でもあると思います。
JavaにたとえたらきっとJVMでしょう。よくわからんけど。
それだけスゴイぞ、と伝えたかったのです。
2008年3月27日木曜日
[Project]見積もりのときのインプット
「予算は○○円らしい。」
それ参考値? 制約条件?
それによって全然違いますよね。
インプットは重要です。その情報の重みは? 精度は? 誰の発言?
怖いのはいい加減なインプット情報で、コストが独り歩きしてしまうことです。
それ参考値? 制約条件?
それによって全然違いますよね。
インプットは重要です。その情報の重みは? 精度は? 誰の発言?
怖いのはいい加減なインプット情報で、コストが独り歩きしてしまうことです。
2008年3月26日水曜日
[memo]アーキテクチャ
スターロジックのはぶさん(面識はありませんが)のブログより
「アーキテクチャ」
http://d.hatena.ne.jp/habuakihiro/20080317#1205758083
同意。激しく同意。
最近はプロジェクトの計画や契約書にだってあるんではないかと思っています。
プロジェクトの計画も、たとえば作業内容がシンプルになっている方が作業効率は良いと思います。あれもこれも同時に、、、は危険。意外とパフォーマンス悪くなるし。
複雑怪奇でどう解釈していいのか分からない契約書より、記述がシンプルで数値も具体的なものの方がわかりやすいですよね。いやなのはわかるんですが、ステークホルダーで認識を一致するのであればシンプルなものの方がリスクは少ないよなー、と思います。
「アーキテクチャ」
http://d.hatena.ne.jp/habuakihiro/20080317#1205758083
同意。激しく同意。
最近はプロジェクトの計画や契約書にだってあるんではないかと思っています。
プロジェクトの計画も、たとえば作業内容がシンプルになっている方が作業効率は良いと思います。あれもこれも同時に、、、は危険。意外とパフォーマンス悪くなるし。
複雑怪奇でどう解釈していいのか分からない契約書より、記述がシンプルで数値も具体的なものの方がわかりやすいですよね。いやなのはわかるんですが、ステークホルダーで認識を一致するのであればシンプルなものの方がリスクは少ないよなー、と思います。
2008年3月25日火曜日
[Project]計画通りに進まなくて当然
タイトルが秀逸
「プロジェクトは、計画通りに進まなくて当然」
http://www.atmarkit.co.jp/im/cpm/serial/9target/03/01.html
契約形態に関しても言及されていますね。
準委任契約と請負契約はその状況によって発注者、受注者双方に不利益を生じないように締結されるべきです。
文中で書かれているように要件定義フェーズなどでは準委任契約が望ましいですし、製造工程に入っているのなら社内での作業割り振りが自由な請負契約の方が動きやすくなります。
また契約形態を含めて仕事の定義はシンプルな方が良いです。
下手な考えで一方的にリスクをヘッジしようとするとかえってリスクまみれの契約になることもありえます。
例)準委任なのに成果物しばり、期日縛り
さてこの参照した記事のタイトルですが、私が尊敬している他社のPMの方にまんま同じことを言われました(笑)。スケジュール表がぐっちゃぐちゃになることを相談した時のことです。
記事にも書いてありますがプロジェクト管理は非常にシンプルな作業ですが、手間暇は結構かかります。社内外でこの苦労を認めてもらうことが最も難しい気もします。
「プロジェクトは、計画通りに進まなくて当然」
http://www.atmarkit.co.jp/im/cpm/serial/9target/03/01.html
契約形態に関しても言及されていますね。
準委任契約と請負契約はその状況によって発注者、受注者双方に不利益を生じないように締結されるべきです。
文中で書かれているように要件定義フェーズなどでは準委任契約が望ましいですし、製造工程に入っているのなら社内での作業割り振りが自由な請負契約の方が動きやすくなります。
また契約形態を含めて仕事の定義はシンプルな方が良いです。
下手な考えで一方的にリスクをヘッジしようとするとかえってリスクまみれの契約になることもありえます。
例)準委任なのに成果物しばり、期日縛り
さてこの参照した記事のタイトルですが、私が尊敬している他社のPMの方にまんま同じことを言われました(笑)。スケジュール表がぐっちゃぐちゃになることを相談した時のことです。
記事にも書いてありますがプロジェクト管理は非常にシンプルな作業ですが、手間暇は結構かかります。社内外でこの苦労を認めてもらうことが最も難しい気もします。
2008年3月24日月曜日
[Project]見積もりは誰のもの?
・見積ってなによ?
まず見積もりって人や役割によって意味が違います。
私は営業みたいな役割になることが多いから見積もりの「コスト」についてフォーカスするし、エンジニアだったら実現手段やかかる工数、プロジェクトマネジャーとかならスケジュールにフォーカスすると思います。
なので「見積もり」じゃなくて「プロジェクト計画」ですね。コスト、スケジュール、リソース、品質、などなどを統合して計画になるはずです。まずこれ前置き。
・プロジェクトに計画が必要なわけ
PMBOKにはプロジェクトの特性として下記の三つが記述されています。
1.有期性
2.独自性
3.段階的詳細化
大ナタ振って言い換えると「二つとして同じものはない」です。定常業務じゃありません。
定常業務でない以上、プロジェクトをどのように始めて、どのように進めて、何をもって終了とするのか? 期間はいつか? 実現手段はどうするか? などなどをステークホルダーで合意をとる必要があります。とれなくても宣言くらいする必要があります。
にも関わらず予算だけ決めて「あとよろしく」は愚の骨頂です。
人月見積もりについて話題になることがありますが、人月のコスト見積もりが間違っているんじゃなくて計画性のなさが問題なはずです。
補足しますが計画が全てといっているわけではありません。計画は思った以上に簡単に壊れます。しかしそれをメンテナンスしながら、調整しながらプロジェクト完遂に向けてやりくりしていくことが大事なはずです。
・見積もりって…
何気なやりとりをしてる見積もりですが、ソフトウェア開発会社にとって開発プロジェクトは主業務であることはもちろんですし、その企業のありとあらゆる能力が如実に表現されます。それはプロジェクトの計画をしっかり作成した上で出てくるものであるべきだし、その重要性を認識するべきです。
「とりあえず見積もり書いて」とか
「すぐに見積もり書いてもってきます」とかは責任感が希薄だと思います。そんなノリだから人月ベースのいい加減な見積もりが横行するのではないでしょうか。
・見積もりは誰のもの?
開発会社として、そのプロジェクトをどのような計画をもって進めていくのか、という問題は営業担当者が決められるものではありませんし、エンジニアが一人で決めていいものではありません。会社のナレッジから得られるものは重要ですし、利益率をおろそかにしてはそもそも会社の経営自体が危うくなります。これは組織内に技術、経営、マーケティングを把握し、これまでのプロジェクト計画と実績をしっかり管理している担当部署を作る必要があるということではないでしょうか。
一般的にはPMOといった担当部署を設けてプロジェクト計画の統合を行うことになるはずです。
見積もりはとても重要なものですし、各担当者が個人でどうにかして良いものではありません。
だからといって、各担当者がまったくかかわらなくていいものではなく、むしろ積極的にかかわっていくべきだと思いますし、集合知のようなものがプロジェクトの計画の妥当性と見積もりの正しさを向上させていくのかと思います。
まず見積もりって人や役割によって意味が違います。
私は営業みたいな役割になることが多いから見積もりの「コスト」についてフォーカスするし、エンジニアだったら実現手段やかかる工数、プロジェクトマネジャーとかならスケジュールにフォーカスすると思います。
なので「見積もり」じゃなくて「プロジェクト計画」ですね。コスト、スケジュール、リソース、品質、などなどを統合して計画になるはずです。まずこれ前置き。
・プロジェクトに計画が必要なわけ
PMBOKにはプロジェクトの特性として下記の三つが記述されています。
1.有期性
2.独自性
3.段階的詳細化
大ナタ振って言い換えると「二つとして同じものはない」です。定常業務じゃありません。
定常業務でない以上、プロジェクトをどのように始めて、どのように進めて、何をもって終了とするのか? 期間はいつか? 実現手段はどうするか? などなどをステークホルダーで合意をとる必要があります。とれなくても宣言くらいする必要があります。
にも関わらず予算だけ決めて「あとよろしく」は愚の骨頂です。
人月見積もりについて話題になることがありますが、人月のコスト見積もりが間違っているんじゃなくて計画性のなさが問題なはずです。
補足しますが計画が全てといっているわけではありません。計画は思った以上に簡単に壊れます。しかしそれをメンテナンスしながら、調整しながらプロジェクト完遂に向けてやりくりしていくことが大事なはずです。
・見積もりって…
何気なやりとりをしてる見積もりですが、ソフトウェア開発会社にとって開発プロジェクトは主業務であることはもちろんですし、その企業のありとあらゆる能力が如実に表現されます。それはプロジェクトの計画をしっかり作成した上で出てくるものであるべきだし、その重要性を認識するべきです。
「とりあえず見積もり書いて」とか
「すぐに見積もり書いてもってきます」とかは責任感が希薄だと思います。そんなノリだから人月ベースのいい加減な見積もりが横行するのではないでしょうか。
・見積もりは誰のもの?
開発会社として、そのプロジェクトをどのような計画をもって進めていくのか、という問題は営業担当者が決められるものではありませんし、エンジニアが一人で決めていいものではありません。会社のナレッジから得られるものは重要ですし、利益率をおろそかにしてはそもそも会社の経営自体が危うくなります。これは組織内に技術、経営、マーケティングを把握し、これまでのプロジェクト計画と実績をしっかり管理している担当部署を作る必要があるということではないでしょうか。
一般的にはPMOといった担当部署を設けてプロジェクト計画の統合を行うことになるはずです。
見積もりはとても重要なものですし、各担当者が個人でどうにかして良いものではありません。
だからといって、各担当者がまったくかかわらなくていいものではなく、むしろ積極的にかかわっていくべきだと思いますし、集合知のようなものがプロジェクトの計画の妥当性と見積もりの正しさを向上させていくのかと思います。
2008年3月21日金曜日
[Microsoft Office Project]マクロのUndo
MSPですごい簡単なマクロを作って気づいたこと。
MSP→Undoできる
Excle→Undoできない。2008でも。
でっ? て聞こえそうですね。
MSP→Undoできる
Excle→Undoできない。2008でも。
でっ? て聞こえそうですね。
[memo]納期優先の無理なプロジェクトが失敗を招く
納期優先の無理なプロジェクトが失敗を招く
http://jibun.atmarkit.co.jp/lskill01/rensai/pwhyf05/pwhyf01.html
案件を取ってくる段階でしっかりハンドリングしましょう、
というメッセージかと思います。
過去記事のタイトルとかみると耳が痛いですね。。。
2008年3月19日水曜日
[プロジェクト管理]管理工数をどう見積もるか
小~中規模のシステム開発の場合、管理工数をどのように算出し、合意を得るのかがヒジョーに難しかったりします。
お客さん:人数少ないとプロマネなんていらないよね。
社内のメンバー:実作業とマネジメントなんて同時にできるわけないだろ、常識的に考えて。
両者の見解は異なります。
私自身は実作業と管理は分ける方が望ましいと考えます。
しかし望ましいといっても、その工数ってどのくらいみとけばいいの? となるわけです。
そこで「ソフトウェア見積り 人月の暗黙知を解き明かす」のコミュニケーションパスを参考に仮説をたてました。
以下、1年前に書いた文書。
意外と妥当そうな数字が出てきたような……。
この時の仮説ではパス1本あたり15分の工数としました。
これはプロジェクトのフェーズや、システムの重要度によっても変化すると思います。
あと顧客内のステークホルダーの数も重要です。仕様の決裁者が複数いて、顧客内の合意に時間かかるとかはざらですよね。
それとメンバー間でどれくらいコミュニケーションがとれているのか、とか。
どこかで聞いた受け売りですが、ビルは高くなればなるほど、エレベーターの占める面積が増えて、フロアあたりの有効な面積が減るそうです。
組織やプロジェクトチームも同様で、人が増えれば管理したりコミュニケーションとったりする工数が増えます。
この仮説で一番伝えたいポイントはそこです。人が増えると大変だぁぁぁぁ、と。
しかしこの仮説の正当性についてはまったく自信がございません。
ご意見いただけると幸いです。
お客さん:人数少ないとプロマネなんていらないよね。
社内のメンバー:実作業とマネジメントなんて同時にできるわけないだろ、常識的に考えて。
両者の見解は異なります。
私自身は実作業と管理は分ける方が望ましいと考えます。
しかし望ましいといっても、その工数ってどのくらいみとけばいいの? となるわけです。
そこで「ソフトウェア見積り 人月の暗黙知を解き明かす」のコミュニケーションパスを参考に仮説をたてました。
以下、1年前に書いた文書。
プロジェクトは同時稼動人数が多ければ多いほど、コミュニケーションパスが
増えその分、管理コストがかさみます。
50人月の仕事を10ヶ月で行うのと、5ヶ月で行うのでは全体コストに変化が
生じます。
※ コミュニケーションパスの数を算出する式
n×(n-1)÷2 = パスの数
n | パスの数 |
3 | 3 |
4 | 6 |
5 | 10 |
6 | 15 |
7 | 21 |
8 | 28 |
9 | 36 |
10 | 45 |
3名以下、管理者は兼務で対応可能
4名、管理者は0.5人月相当の作業量が発生する。
5~8名、管理者は1人月相当の作業が発生する。実作業はほとんど行えない。
9名以上、管理者にサポートが必要
※ 1日あたり32のパスを処理できると仮定する。
基本的にはこれらの組み合わせ(ピラミッドを積み上げれば)で管理費を計上できる。
意外と妥当そうな数字が出てきたような……。
この時の仮説ではパス1本あたり15分の工数としました。
これはプロジェクトのフェーズや、システムの重要度によっても変化すると思います。
あと顧客内のステークホルダーの数も重要です。仕様の決裁者が複数いて、顧客内の合意に時間かかるとかはざらですよね。
それとメンバー間でどれくらいコミュニケーションがとれているのか、とか。
どこかで聞いた受け売りですが、ビルは高くなればなるほど、エレベーターの占める面積が増えて、フロアあたりの有効な面積が減るそうです。
組織やプロジェクトチームも同様で、人が増えれば管理したりコミュニケーションとったりする工数が増えます。
この仮説で一番伝えたいポイントはそこです。人が増えると大変だぁぁぁぁ、と。
しかしこの仮説の正当性についてはまったく自信がございません。
ご意見いただけると幸いです。
2008年3月6日木曜日
[RIA]RIAについて考えてみた
営業時に技術の話を一切しないでRIAとは何かを説明しようと思ってとりあえず書き出してみた。
推敲はこれから。
「どっかで聞いたような話。。。」もあるので、そこも自分の言葉におきかえる。
でも暇があったらの話。
「RIAの利用について」
1. 導入
1.1 RIAのイメージは?
RIAのイメージについてどのようなイメージをお持ちでしょうか?
Flash等の要素技術を思い出す方、見た目のカッコ良さを想像される方、操作性の優位性を考える方、ユーザビリティやユーザーエクスペリエンスといった言葉を思い出す方もいらっしゃるでしょう。それらは間違いではありません。いずれの言葉もRIAをあらわす特徴の一つと言えます。
そこでRIAは何をしてくれるものなかのか? 従来のWebアプリケーションとはいったい何が違うのか? この記事ではそれらを技術的な単語をなるべく使わずに解説したいと思います。
1.2 「おもてなし」について
私が妄想する高級レストランでは、訪れたお客さんは下記のようなサービスを受けられることと思います。
・身なりがきちんとした「ギャルソン」と呼ばれるスタッフがあなたを席まで案内するでしょう。
・もちろんさわやかな笑顔つきです。
・あなたがメニューの中からどういった料理を選ぶのか助けてくれるでしょう。
・その際、あなたがフランス語が読めなかったり発音ができなかったりしても小馬鹿にした態度はとりません。
・(フランス語を読めない)あなたがメニュー選びに迷っているようなら、シェフのおすすめなどを提案して、あなたのメニュー選びを助けてくれるはずです。
・場合によっては嫌いなものや、アレルギー反応を起こしてしまう食材を避けるようアドバイスしてくれるかもしれません。
・その際、発生する気難しい職人肌のシェフとの面倒くさい交渉も引き受けてくれるはずです。
・メニューを注文し終えるとギャルソンとは別に「ソムリエ」と呼ばれるスタッフがあなたにワインや飲み物を進めてくれるはずです。
・もちろんソムリエはあなたが主要なワイン銘柄をちっともしらなくても、あなたの懐具合を察してその場に適当と思われるワインを提供してくれます。
・そしてより食事を美味しく、楽しくするためにメニューにまつわるトリビアも教えてくれます。
これら高級レストランのイメージを記述しました。さて、ここでWebアプリを思い出してください。あなたが良く使うもので構いません。まず見た目。あなたが目的を達するためのメニューはわかりやすく表示・配置されているでしょうか? 作業の順序。使い方を悩んだりしていませんか? 慣れてしまっているかもしれませんが、よく見ると押したことのない謎のボタンも並んでいませんか? たまにキーを間違えて意図しない動作をしたりしませんか?
これは極端な話、あなたの使っているアプリはあなたを「おもてなし」していないかもしれません。食事で例えると、ただ積まれただけのおにぎりなのかも…?(決しておにぎりを馬鹿にしているわけではありません)
1.3 インタラクションの効用
ユーザーが目的を達するためにただしく導くことを「インタラクション」と言います。こう書いちゃうと簡単そうですね。ところがこれが、そうは簡単に片付かないのです。たとえば仕事場において春先によく見かける光景です。業務システムの使い方について会話をしています。
新人さん「○○さん。これ、この先、どう進めていいのかわかりません?」
○○さん「これはメニューからこれを選んで」
新人さん「…」
○○さん「ここでこれとこれを選んで画面を切り替えて」
新人さん「…」
○○さん「切り替えた先のサブシステムのメニューを選んで、さっき何が表示されていたのかを忘れないでね」
新人さん「…」
○○さん「ここでショートカットでCtrl+*で、、、」
新人さん「…」
○○さん「それでデスクトップ上に保管してあるExcelファイルの中身をコピペすれば完成。わかった?」
新人さん「もういっかい、最初からお願いします」
※ 業務においてExcelの使用率は限りなく100%に近いだろう。だけど忘れてはいけないことがある。私たちはこの自由度がべらぼうに高いOfficeソフトを自分たちの業務に合わせるためにとてつもないカスタマイズを施すこともあり、さらにファイル管理も煩雑になりがちで、必要な業務を行う前の準備の時間に費やしている。
仕方ないとは言えますが時間の無駄ですね。時間=コストです。こんなやりとりが新人さんが来たとき、新しいアプリが導入されたとき、機能に修正が加わったときに行われているのならうんざりです。
2. 考えて、実行して、確認すること
2.1 多くの事で共通する行動
さて話はまた脱線します。が、ちょっと原則的な話です。
モノゴトを行うときの共通点は
1.考える
2.実行する
3.確認する
です。
いろんなことをこれであてはめて考えることが可能です。多くの場合、このプロセスを経ているはずです。たとえ無意識であっても。例えばゴルフ。(どこに打つのか)考えて、(ショットを)実行し、(ボールの行方を)確認します。お仕事でもそうです。計画して、実行して、成果を確認します。この3つからなるプロセスは目的を「正しく」果たすための最短パスです。どれかが欠けると問題がおこります。
1、行き当たりばったり
2、口ばっかり
3、やりっぱなし
いずれかです。
ではアプリの場合。それもダメなアプリの場合はどうなるでしょうか?
1.考える
2.使い方に悩む
3.実行する
4.不安になったので
5.確認をする
目的を達成することに意識が欠けてしまうかもしれません。人間の集中力は有限です。使い方で悩んで仕事の本質から外れてしまうのはもったいないですよね。より効果的に、効率よく目的を達成するために集中力は使われるべきです。確認の作業も仕事の成果を確認し、次につなげることに使うべきです。操作が正しいか正しくないかに多くの集中力を割かれるのはもったいない。
2.2 おもてなし
「おもてなし」にもどります。
高級レストランではあなたが食事を楽しむための手助けをしてくれます。
高級なホテルではあなたが心地よく滞在できるよう手助けをしてくれます。
この手助け=おもてなしがアプリケーションに必要なのです。
RIAとはまさにそれを実現するための技術なのです。
もしあなたが「そんなことは使って慣れればどうということはない」と思うかもしれません。しかしそれは、はっきりと「間違い」であるといえます。
自動車のパワーウィンドウを思い出してください。今ではほとんどの車に搭載されています。高級車であろうとリーズナブルな軽自動車であろうとです。私たちはパワーウィンドウを当たり前のものとして認識しています。慣れてしまっています。もし昔懐かしいハンドル型の窓を使ったら、若かったころの自分を思い出して気分が良くなるのは最初の1回か2回だけで、あとは多少のストレスか違和感を感じるはずです。昔当たり前でも今では当たり前ではないからです。
RIAも当たり前になりつつあります。ユーザーはいたるところでその恩恵を享受しているでしょう。自宅のPCで、店舗の端末で、会社で、もしかしたらケータイで。
あなたの会社のアプリだけ古く、ユーザーの慣れを強いるようなものならどうでしょうか? ユーザーは何らかの違和感をもつでしょう。それは仕事の品質に影響するはずです。そして本来やるべきことに集中できなくなるはずです。
その違和感の対象はアプリだけにとどまらないかもしれません。経営にかかわる大事なデータを紙か静的なHTMLで分析していませんか? もしくはお使いのPCのローカルフォルダにxlsデータを大量に保管していませんか? それは情報の共有と管理ができていない状態です。
想像をしてください。様々なデータを1つの画面でチャートを用いて視覚的に分析する業務を。そして他所でおきた変化をリアルタイムで受け取ることができる画面を。あなたはアプリやデータの取り扱いに煩わされることなく、お仕事で必要な決断をタイミングよく行えるようになるのです。
あなたがユーザとして自宅のPCから「何か」を買うとしたら? それが安い買い物でないとしたら? 家族と一緒に画面を見て商品の色や細かい仕様を変更できたら? もしくは遠距離恋愛中の恋人と同じ商品を違うPCから見ることができたら?
もしくはトレーニングなどを受けたり、教える側になったら?
数年前、遠隔地での教育は専用のテレビ電話を使っていました。
RIAならPCの画面でテレビ電話と同様なやりとりに加え、専用のアプリケーションと連携してさらにいろんなことができます。
ピアノの先生と連弾ができるかもしれませんね。音の波形を画面に出力して先生と生徒の演奏を「見た目」で比較するのも面白いですね。
2.2.1 まとめ
ここまで説明をして今更なんですが、これらの話は「RIA」だからあり得ることではありません。
ユーザビリティやインタラクションなどをいかに作りこむか、ユーザに提供をするか、というのは大切なことです。RIAと呼ばれる技術は既存技術に対しそれらを実現しやすい、またはそのような文化をもっているにすぎません。比較的新しく従来の技術よりも表現力に優れているから、そのようなポジションになっているだけです。Adobe Flexで作れば即ちRIAではないのです。仮にそうであったとしてもユーザを置き去りにしたりストレスを与えているアプリであれば価値は低いと考えます。
極端な話、Excel VBAでも使いやすいアプリはつくれるかもしれません。それがRIAの定義から外れるものであったとしてもユーザの要件を満たし使い勝手に優れているのであれば問題はありません。
ユーザの声を真摯に受け止めること。
技術力の高さ、デザインセンスを誇ることが全てではないのです。
RIAとは何か。
真剣に考えれば考えるほど、いきつく結果は当然のものになるのではないのでしょうか。
推敲はこれから。
「どっかで聞いたような話。。。」もあるので、そこも自分の言葉におきかえる。
でも暇があったらの話。
「RIAの利用について」
1. 導入
1.1 RIAのイメージは?
RIAのイメージについてどのようなイメージをお持ちでしょうか?
Flash等の要素技術を思い出す方、見た目のカッコ良さを想像される方、操作性の優位性を考える方、ユーザビリティやユーザーエクスペリエンスといった言葉を思い出す方もいらっしゃるでしょう。それらは間違いではありません。いずれの言葉もRIAをあらわす特徴の一つと言えます。
そこでRIAは何をしてくれるものなかのか? 従来のWebアプリケーションとはいったい何が違うのか? この記事ではそれらを技術的な単語をなるべく使わずに解説したいと思います。
1.2 「おもてなし」について
私が妄想する高級レストランでは、訪れたお客さんは下記のようなサービスを受けられることと思います。
・身なりがきちんとした「ギャルソン」と呼ばれるスタッフがあなたを席まで案内するでしょう。
・もちろんさわやかな笑顔つきです。
・あなたがメニューの中からどういった料理を選ぶのか助けてくれるでしょう。
・その際、あなたがフランス語が読めなかったり発音ができなかったりしても小馬鹿にした態度はとりません。
・(フランス語を読めない)あなたがメニュー選びに迷っているようなら、シェフのおすすめなどを提案して、あなたのメニュー選びを助けてくれるはずです。
・場合によっては嫌いなものや、アレルギー反応を起こしてしまう食材を避けるようアドバイスしてくれるかもしれません。
・その際、発生する気難しい職人肌のシェフとの面倒くさい交渉も引き受けてくれるはずです。
・メニューを注文し終えるとギャルソンとは別に「ソムリエ」と呼ばれるスタッフがあなたにワインや飲み物を進めてくれるはずです。
・もちろんソムリエはあなたが主要なワイン銘柄をちっともしらなくても、あなたの懐具合を察してその場に適当と思われるワインを提供してくれます。
・そしてより食事を美味しく、楽しくするためにメニューにまつわるトリビアも教えてくれます。
これら高級レストランのイメージを記述しました。さて、ここでWebアプリを思い出してください。あなたが良く使うもので構いません。まず見た目。あなたが目的を達するためのメニューはわかりやすく表示・配置されているでしょうか? 作業の順序。使い方を悩んだりしていませんか? 慣れてしまっているかもしれませんが、よく見ると押したことのない謎のボタンも並んでいませんか? たまにキーを間違えて意図しない動作をしたりしませんか?
これは極端な話、あなたの使っているアプリはあなたを「おもてなし」していないかもしれません。食事で例えると、ただ積まれただけのおにぎりなのかも…?(決しておにぎりを馬鹿にしているわけではありません)
1.3 インタラクションの効用
ユーザーが目的を達するためにただしく導くことを「インタラクション」と言います。こう書いちゃうと簡単そうですね。ところがこれが、そうは簡単に片付かないのです。たとえば仕事場において春先によく見かける光景です。業務システムの使い方について会話をしています。
新人さん「○○さん。これ、この先、どう進めていいのかわかりません?」
○○さん「これはメニューからこれを選んで」
新人さん「…」
○○さん「ここでこれとこれを選んで画面を切り替えて」
新人さん「…」
○○さん「切り替えた先のサブシステムのメニューを選んで、さっき何が表示されていたのかを忘れないでね」
新人さん「…」
○○さん「ここでショートカットでCtrl+*で、、、」
新人さん「…」
○○さん「それでデスクトップ上に保管してあるExcelファイルの中身をコピペすれば完成。わかった?」
新人さん「もういっかい、最初からお願いします」
※ 業務においてExcelの使用率は限りなく100%に近いだろう。だけど忘れてはいけないことがある。私たちはこの自由度がべらぼうに高いOfficeソフトを自分たちの業務に合わせるためにとてつもないカスタマイズを施すこともあり、さらにファイル管理も煩雑になりがちで、必要な業務を行う前の準備の時間に費やしている。
仕方ないとは言えますが時間の無駄ですね。時間=コストです。こんなやりとりが新人さんが来たとき、新しいアプリが導入されたとき、機能に修正が加わったときに行われているのならうんざりです。
2. 考えて、実行して、確認すること
2.1 多くの事で共通する行動
さて話はまた脱線します。が、ちょっと原則的な話です。
モノゴトを行うときの共通点は
1.考える
2.実行する
3.確認する
です。
いろんなことをこれであてはめて考えることが可能です。多くの場合、このプロセスを経ているはずです。たとえ無意識であっても。例えばゴルフ。(どこに打つのか)考えて、(ショットを)実行し、(ボールの行方を)確認します。お仕事でもそうです。計画して、実行して、成果を確認します。この3つからなるプロセスは目的を「正しく」果たすための最短パスです。どれかが欠けると問題がおこります。
1、行き当たりばったり
2、口ばっかり
3、やりっぱなし
いずれかです。
ではアプリの場合。それもダメなアプリの場合はどうなるでしょうか?
1.考える
2.使い方に悩む
3.実行する
4.不安になったので
5.確認をする
目的を達成することに意識が欠けてしまうかもしれません。人間の集中力は有限です。使い方で悩んで仕事の本質から外れてしまうのはもったいないですよね。より効果的に、効率よく目的を達成するために集中力は使われるべきです。確認の作業も仕事の成果を確認し、次につなげることに使うべきです。操作が正しいか正しくないかに多くの集中力を割かれるのはもったいない。
2.2 おもてなし
「おもてなし」にもどります。
高級レストランではあなたが食事を楽しむための手助けをしてくれます。
高級なホテルではあなたが心地よく滞在できるよう手助けをしてくれます。
この手助け=おもてなしがアプリケーションに必要なのです。
RIAとはまさにそれを実現するための技術なのです。
もしあなたが「そんなことは使って慣れればどうということはない」と思うかもしれません。しかしそれは、はっきりと「間違い」であるといえます。
自動車のパワーウィンドウを思い出してください。今ではほとんどの車に搭載されています。高級車であろうとリーズナブルな軽自動車であろうとです。私たちはパワーウィンドウを当たり前のものとして認識しています。慣れてしまっています。もし昔懐かしいハンドル型の窓を使ったら、若かったころの自分を思い出して気分が良くなるのは最初の1回か2回だけで、あとは多少のストレスか違和感を感じるはずです。昔当たり前でも今では当たり前ではないからです。
RIAも当たり前になりつつあります。ユーザーはいたるところでその恩恵を享受しているでしょう。自宅のPCで、店舗の端末で、会社で、もしかしたらケータイで。
あなたの会社のアプリだけ古く、ユーザーの慣れを強いるようなものならどうでしょうか? ユーザーは何らかの違和感をもつでしょう。それは仕事の品質に影響するはずです。そして本来やるべきことに集中できなくなるはずです。
その違和感の対象はアプリだけにとどまらないかもしれません。経営にかかわる大事なデータを紙か静的なHTMLで分析していませんか? もしくはお使いのPCのローカルフォルダにxlsデータを大量に保管していませんか? それは情報の共有と管理ができていない状態です。
想像をしてください。様々なデータを1つの画面でチャートを用いて視覚的に分析する業務を。そして他所でおきた変化をリアルタイムで受け取ることができる画面を。あなたはアプリやデータの取り扱いに煩わされることなく、お仕事で必要な決断をタイミングよく行えるようになるのです。
あなたがユーザとして自宅のPCから「何か」を買うとしたら? それが安い買い物でないとしたら? 家族と一緒に画面を見て商品の色や細かい仕様を変更できたら? もしくは遠距離恋愛中の恋人と同じ商品を違うPCから見ることができたら?
もしくはトレーニングなどを受けたり、教える側になったら?
数年前、遠隔地での教育は専用のテレビ電話を使っていました。
RIAならPCの画面でテレビ電話と同様なやりとりに加え、専用のアプリケーションと連携してさらにいろんなことができます。
ピアノの先生と連弾ができるかもしれませんね。音の波形を画面に出力して先生と生徒の演奏を「見た目」で比較するのも面白いですね。
2.2.1 まとめ
ここまで説明をして今更なんですが、これらの話は「RIA」だからあり得ることではありません。
ユーザビリティやインタラクションなどをいかに作りこむか、ユーザに提供をするか、というのは大切なことです。RIAと呼ばれる技術は既存技術に対しそれらを実現しやすい、またはそのような文化をもっているにすぎません。比較的新しく従来の技術よりも表現力に優れているから、そのようなポジションになっているだけです。Adobe Flexで作れば即ちRIAではないのです。仮にそうであったとしてもユーザを置き去りにしたりストレスを与えているアプリであれば価値は低いと考えます。
極端な話、Excel VBAでも使いやすいアプリはつくれるかもしれません。それがRIAの定義から外れるものであったとしてもユーザの要件を満たし使い勝手に優れているのであれば問題はありません。
ユーザの声を真摯に受け止めること。
技術力の高さ、デザインセンスを誇ることが全てではないのです。
RIAとは何か。
真剣に考えれば考えるほど、いきつく結果は当然のものになるのではないのでしょうか。
2008年3月3日月曜日
2月猛省
・データモデリングの本(タイトル忘れた)
・DBの入門本(読み終わってない)
・Adboeの25周年本(パラパラめくっただけで貸してしまった)
・RFPの作り方(調べ物があったのでちょっと舐めた)
以上、仕事に関係がありそうな本
以下、その他の本
・よつばと! ①~⑦ 読み終わった
・BECK! 新しいやつ2冊
・ローマ人の物語 のでてるやつの後半
よつばとローマ人しか記憶に残ってねーっす。ははははは。
でもローマ人の物語はいろいろな思考をする上で役に立ちますね。
「人は見たいと欲する現実しか見ない」
といったのはカエサル。
「みたい現実だけみせて、本質の部分は水面下でこっそり。。。」
なアウグストゥス。
一方の視点から見ると都合の悪い本質を隠ぺいして、全体として都合のいい方に話をもっていく。。。
しかも嘘はつかない。
とても神経すり減って大変なんだというのはよくわかるけど、このセンスは重要。
偉そうなこと言える立場でないですけどね。
とても大事でやらなくてはならないことがあるのであれば、それくらいの演出とかはあってもいいと思うわけです。現実を直視させるのはそれからでも遅くないはず。嘘ついてなければ。
仕事にも必要そうでいて、あんまり必要であっちゃおかしいんだけど、このセンスがあるのとないのじゃ結構違う。
それとこのセンスには「見たくない現実を直視できる」ことが必須。
で、タケはよつばと!ばっかり読んで勉強してない現実を見るべきなんです。
2月は猛省なんです。
・DBの入門本(読み終わってない)
・Adboeの25周年本(パラパラめくっただけで貸してしまった)
・RFPの作り方(調べ物があったのでちょっと舐めた)
以上、仕事に関係がありそうな本
以下、その他の本
・よつばと! ①~⑦ 読み終わった
・BECK! 新しいやつ2冊
・ローマ人の物語 のでてるやつの後半
よつばとローマ人しか記憶に残ってねーっす。ははははは。
でもローマ人の物語はいろいろな思考をする上で役に立ちますね。
「人は見たいと欲する現実しか見ない」
といったのはカエサル。
「みたい現実だけみせて、本質の部分は水面下でこっそり。。。」
なアウグストゥス。
一方の視点から見ると都合の悪い本質を隠ぺいして、全体として都合のいい方に話をもっていく。。。
しかも嘘はつかない。
とても神経すり減って大変なんだというのはよくわかるけど、このセンスは重要。
偉そうなこと言える立場でないですけどね。
とても大事でやらなくてはならないことがあるのであれば、それくらいの演出とかはあってもいいと思うわけです。現実を直視させるのはそれからでも遅くないはず。嘘ついてなければ。
仕事にも必要そうでいて、あんまり必要であっちゃおかしいんだけど、このセンスがあるのとないのじゃ結構違う。
それとこのセンスには「見たくない現実を直視できる」ことが必須。
で、タケはよつばと!ばっかり読んで勉強してない現実を見るべきなんです。
2月は猛省なんです。
2008年2月25日月曜日
2008年2月5日火曜日
事実は小説より奇なり。
昨日は日付が変わったくらいに帰宅開始。
家につくとNFLスーパーボウルの録画放送中。
今シーズン観戦する最初にして最後の試合…。
ペイトリオッツのQB、トム・ブレイディはタケと同い年。そのくくりの中でおそらく世界中で最も成功している人だと思う。
QBとしてはクレバーで常に冷静。フリーのレシーバーを探す能力はもちろん、自身に迫ってくる相手ディフェンス選手の存在も常に把握。一発狙いのバクチみたいなプレイはほとんどせず、パッツの複雑なオフェンススキームを自在に駆使している。身体も頑丈らしくけがもくて相手ディフェンス選手との接触も恐れない。
しかも大舞台に強い。過去にスーパーボウルを3回経験し3回とも勝っている。
まさに理想のQB。
そんなブレイディ率いるパッツだけど、昨日のスーパーボウルは負けた。
シーズン中無敗、自身もTDパス記録(年間50TDは何かがどうかしているとしか思えない記録)を更新し、パーフェクトシーズンの言葉以上の完璧ぶりだった。
でも昨日は負けた。
試合終了30秒前までパッツは勝っていたのに。
言い換えると今シーズン終了まであと30秒というところまでパッツは「パーフェクトシーズン」だった。
でも逆転された。
NFLの歴史に残るアップセットマッチだと思う。
ジャイアンツのディフェンスはカンペキすぎる位に機能していたし、オフェンスも時間を使ってロースコアゲームに持ち込むという戦略(事前のマスコミ予測)に沿って進行していた。
けっしてまぐれとかじゃなかったと思う。テレビの解説はメンタル面を強調していたけど、ジャイアンツは事前準備を怠らず、計画に沿ってゲームを進行していたように思う。
確かにイーライ・マニングがたまにやる不用意なパスが致命的な結果につながったりはしなかったけどね。
さてブレイディの話。
タケはブレイディという選手が好きです。
スターQBなのに気取ってなくて、接触プレイを嫌わず、チームの勝利を最優先に考えられる選手。身長は高いけど、足なんかたいして速くないし、パスだってそんなにスゴイわけでもない。
でも「クォーターバッキング」という曖昧とした言葉をもっとも体現しているQB。
そして同い年。
すんごい難しいと思うけど、今シーズン達成できなかった「パーフェクトシーズン」を来シーズンで実現してほしい。タケと同じ年のQBがそんなスゴイ記録を達成したらなんか気分いいじゃん。おれたちの学年にスゴイやついるぞ! みたいで。
いや、すでにスゴイやつなんですが。
事実は小説より奇なり。
第42回のスーパーボウルを観てそんな感想をもちました。
ところでモンタナの話。
ブレイディはモンタナとよく比較される。というかモンタナっぽいといわれることが多い。
確かに近しいものを感じる。ドラフトの順位が低かったこととか、長身痩身なところとか。
ブレイディが4回目のスーパーボウルで負けたことによって、モンタナの4回出て4回とも勝利がより際立つことになった気がする。ブレイディですら負けたことあるのにモンタナは負けてない、みたいな。
家につくとNFLスーパーボウルの録画放送中。
今シーズン観戦する最初にして最後の試合…。
ペイトリオッツのQB、トム・ブレイディはタケと同い年。そのくくりの中でおそらく世界中で最も成功している人だと思う。
QBとしてはクレバーで常に冷静。フリーのレシーバーを探す能力はもちろん、自身に迫ってくる相手ディフェンス選手の存在も常に把握。一発狙いのバクチみたいなプレイはほとんどせず、パッツの複雑なオフェンススキームを自在に駆使している。身体も頑丈らしくけがもくて相手ディフェンス選手との接触も恐れない。
しかも大舞台に強い。過去にスーパーボウルを3回経験し3回とも勝っている。
まさに理想のQB。
そんなブレイディ率いるパッツだけど、昨日のスーパーボウルは負けた。
シーズン中無敗、自身もTDパス記録(年間50TDは何かがどうかしているとしか思えない記録)を更新し、パーフェクトシーズンの言葉以上の完璧ぶりだった。
でも昨日は負けた。
試合終了30秒前までパッツは勝っていたのに。
言い換えると今シーズン終了まであと30秒というところまでパッツは「パーフェクトシーズン」だった。
でも逆転された。
NFLの歴史に残るアップセットマッチだと思う。
ジャイアンツのディフェンスはカンペキすぎる位に機能していたし、オフェンスも時間を使ってロースコアゲームに持ち込むという戦略(事前のマスコミ予測)に沿って進行していた。
けっしてまぐれとかじゃなかったと思う。テレビの解説はメンタル面を強調していたけど、ジャイアンツは事前準備を怠らず、計画に沿ってゲームを進行していたように思う。
確かにイーライ・マニングがたまにやる不用意なパスが致命的な結果につながったりはしなかったけどね。
さてブレイディの話。
タケはブレイディという選手が好きです。
スターQBなのに気取ってなくて、接触プレイを嫌わず、チームの勝利を最優先に考えられる選手。身長は高いけど、足なんかたいして速くないし、パスだってそんなにスゴイわけでもない。
でも「クォーターバッキング」という曖昧とした言葉をもっとも体現しているQB。
そして同い年。
すんごい難しいと思うけど、今シーズン達成できなかった「パーフェクトシーズン」を来シーズンで実現してほしい。タケと同じ年のQBがそんなスゴイ記録を達成したらなんか気分いいじゃん。おれたちの学年にスゴイやついるぞ! みたいで。
いや、すでにスゴイやつなんですが。
事実は小説より奇なり。
第42回のスーパーボウルを観てそんな感想をもちました。
ところでモンタナの話。
ブレイディはモンタナとよく比較される。というかモンタナっぽいといわれることが多い。
確かに近しいものを感じる。ドラフトの順位が低かったこととか、長身痩身なところとか。
ブレイディが4回目のスーパーボウルで負けたことによって、モンタナの4回出て4回とも勝利がより際立つことになった気がする。ブレイディですら負けたことあるのにモンタナは負けてない、みたいな。
2008年2月2日土曜日
[memo]作業の履歴をとることにした
もとはといえば「書きなさい!」というお達しだったのですが、やってみると結構、楽しい?
少なくとも自分の役にはたっている気がする。
ここからはまじめな話。
タケは仕事を一言で表現すると「IT雑用係」です。
社内外のいろんな人との連携やら調整やらが発生します。
コミュニケーションをとって目的と手段の認識を一致させたり共有したり。
わかりやすい成果のでる作業以外に使っている時間が結構多いわけです。
も~何やってんのか自分でもわかんない。
もやもや~ん!!!
そんな毎日なわけです。
なので細かく作業の履歴をとることにしました。ちょっと面倒くさいけど。
簡単な表をExcelで作って、開始時刻を入力(ショートカット Ctrl+「*」)。
作業内容を簡単に書いて着手。終わったら終了時刻を入力。
割り込みはいったら割り込みもちゃんと書く。
こうやって計測をつづけるとタケの仕事の生産効率に影響するものがハッキリしてくると思います。
(たぶん割り込みと不要な情報のインプットだ。間違いない。)
ちなみにソフトウェア開発の計測は総コストの7~9%必要、とのこと(※ 「初めて学ぶ ソフトウェアメトリクス」より)。
タケの仕事にかぎらずそんくらいの時間と金かけて計測した方がいいと思うんですわ。
現状を数値で認識できなければ、改善の目標なんて立てられないし、そもそも適正かどうかもあいまいな判断になってしまうし。
「改善する前に計測すべし」
なんか良いこと言った気がする。
孫子の兵法に通ずるものがある気がする。
あと着手した作業はできるだけその時にかたづけることを強く意識する、とか。
細かい作業でもつもってくと効率悪くなってきます。マルチタスクについては「クリティカルチェーン」にリードタイムの増加の弊害としてさくっと書かれていました(たしか)。
作業効率を改善して、自分のための時間を増やそう♪キャンペーンです。
とても初歩的な話ですが。
少なくとも自分の役にはたっている気がする。
ここからはまじめな話。
タケは仕事を一言で表現すると「IT雑用係」です。
社内外のいろんな人との連携やら調整やらが発生します。
コミュニケーションをとって目的と手段の認識を一致させたり共有したり。
わかりやすい成果のでる作業以外に使っている時間が結構多いわけです。
も~何やってんのか自分でもわかんない。
もやもや~ん!!!
そんな毎日なわけです。
なので細かく作業の履歴をとることにしました。ちょっと面倒くさいけど。
簡単な表をExcelで作って、開始時刻を入力(ショートカット Ctrl+「*」)。
作業内容を簡単に書いて着手。終わったら終了時刻を入力。
割り込みはいったら割り込みもちゃんと書く。
こうやって計測をつづけるとタケの仕事の生産効率に影響するものがハッキリしてくると思います。
(たぶん割り込みと不要な情報のインプットだ。間違いない。)
ちなみにソフトウェア開発の計測は総コストの7~9%必要、とのこと(※ 「初めて学ぶ ソフトウェアメトリクス」より)。
タケの仕事にかぎらずそんくらいの時間と金かけて計測した方がいいと思うんですわ。
現状を数値で認識できなければ、改善の目標なんて立てられないし、そもそも適正かどうかもあいまいな判断になってしまうし。
「改善する前に計測すべし」
なんか良いこと言った気がする。
孫子の兵法に通ずるものがある気がする。
あと着手した作業はできるだけその時にかたづけることを強く意識する、とか。
細かい作業でもつもってくと効率悪くなってきます。マルチタスクについては「クリティカルチェーン」にリードタイムの増加の弊害としてさくっと書かれていました(たしか)。
作業効率を改善して、自分のための時間を増やそう♪キャンペーンです。
とても初歩的な話ですが。
2008年1月22日火曜日
2008年1月18日金曜日
[RIA]Flexおさらい
tedさんblogをメモ
http://www.onflex.org/ted/2008/01/what-is-flex.php
, or on mobile devices.
え?
うわ。英語わからない。翻訳して読んでみる。。。
とりあえずそれができるように一所懸命だということがわかりました。
http://www.onflex.org/ted/2008/01/what-is-flex.php
, or on mobile devices.
え?
うわ。英語わからない。翻訳して読んでみる。。。
とりあえずそれができるように一所懸命だということがわかりました。
2008年1月15日火曜日
[memo]古今東西のSEとプログラマという記事について
古今東西のSEとプログラマ
http://blue.hkisl.net/mutteraway/archives/2004/05/post_2.html
備忘録?のために貼り付け。
思うにプログラマを評価するしないではなく単純に「金に近いところにいる人に金が入る」世の中な気がします。
良いか悪いかはおいといて。
つまり
「実際に業務に携わる人(※)」>「業務を設計する人」>「システムを設計する人」>「システムを構築する人」
という序列というか金に対する距離があって、左から順に取り分を取ったら右の人の取り分は少なくなるでしょう、、、と。
※ 正確には「実際に業務に携わる人を雇用している人」
とはいっても「システムを構築する人」がいなくてはシステム作れないですし、業務だってどーともならないかもしれません。卵が先か鶏が先か、みたいな話です。
他の人も言っているかも知れませんが、「腕の良いプログラマ」と「普通のプログラマ」の作るものがどうちがうのか? どんな付加価値があるのか? そういったことを数値で証明する必要があるのではないでしょうか。お金に近い人は数字が大好きです。
そこでまた難しいのですが、それには正確で的を得た「計測」の作業が必要なはずです。
しかし悲しいかな、私の働く会社も同じく計測に使うコストや工数が捻出できません。必要性も感じていません。
悲しいです。
私は一所懸命働くエンジニアにやりがいのある仕事を良い条件で楽しくやってもらうことが今の仕事の目標の一つだと思っています。
でも本当に難しいです。
悩みがつきません。
http://blue.hkisl.net/mutteraway/archives/2004/05/post_2.html
備忘録?のために貼り付け。
思うにプログラマを評価するしないではなく単純に「金に近いところにいる人に金が入る」世の中な気がします。
良いか悪いかはおいといて。
つまり
「実際に業務に携わる人(※)」>「業務を設計する人」>「システムを設計する人」>「システムを構築する人」
という序列というか金に対する距離があって、左から順に取り分を取ったら右の人の取り分は少なくなるでしょう、、、と。
※ 正確には「実際に業務に携わる人を雇用している人」
とはいっても「システムを構築する人」がいなくてはシステム作れないですし、業務だってどーともならないかもしれません。卵が先か鶏が先か、みたいな話です。
他の人も言っているかも知れませんが、「腕の良いプログラマ」と「普通のプログラマ」の作るものがどうちがうのか? どんな付加価値があるのか? そういったことを数値で証明する必要があるのではないでしょうか。お金に近い人は数字が大好きです。
そこでまた難しいのですが、それには正確で的を得た「計測」の作業が必要なはずです。
しかし悲しいかな、私の働く会社も同じく計測に使うコストや工数が捻出できません。必要性も感じていません。
悲しいです。
私は一所懸命働くエンジニアにやりがいのある仕事を良い条件で楽しくやってもらうことが今の仕事の目標の一つだと思っています。
でも本当に難しいです。
悩みがつきません。
2008年1月10日木曜日
[memo]James Gosling氏がAdobe Flash・Flex・AIRを語る
James Gosling氏がAdobe Flash・Flex・AIRを語る
http://www.infoq.com/jp/news/2008/01/gosling-on-flash
おもしろい記事だったのでメモ。
そして彼はFlexが2008年の初旬にリリースされる予定である一方、JavaFXは出荷される予定がないことを自身の考えとして述べた。
何かもっといい向上が成されるのであればどうぞ出荷してください。
それをいっちゃ。。。
http://www.infoq.com/jp/news/2008/01/gosling-on-flash
おもしろい記事だったのでメモ。
そして彼はFlexが2008年の初旬にリリースされる予定である一方、JavaFXは出荷される予定がないことを自身の考えとして述べた。
何かもっといい向上が成されるのであればどうぞ出荷してください。
それをいっちゃ。。。
登録:
投稿 (Atom)