Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

帳票や記入用紙は、記入したものをもらってきたほうが安全

2005-08-31 17:29:13 | 開発ネタ

 帳票の分析を行ってER図を書くことがあります。
 その話題で、2つ
 1つめ。そのとき、帳票は、記入したものをもらってきたほうが安全だと思います。(2つめは、覚えていたら、いつか。。)

 理由を、はぶさんの記事を使って説明しますね。

 この記事の内容と、エンティティの導出方法自体は、問題ないです。
 これに、いちゃもん、文句をつけようなんてーことは、思ってもいません。
 はい。
 よい記事だと思いますですよ。

 情報処理試験なんかでやるやり方でも、このケースでは、結果は、同じものが出てきます。
(実は、上記の記事のように、イベントからそのリソースを割り出す方法と、帳票分析するだけのものでは、違うものが出てくることがあります。そのケースと理由については、2つめの話。実は、このケースかと思って、前のブログでは、勘違いした)

 で、今回の話は、この用紙を使って説明するというだけで、記事の内容うんぬんの話ではないです。はい(つまり、記事とは、ぜんぜん違う話。用紙だけ使わせてもらっているということ)




 で、その用紙についてなのですが、よーく考えると、ですよ、

 「お持ち帰りご注文用紙」

に、自分の電話番号って、書きます??

 具体的に考えて見ましょう。。

 お弁当屋さんで、お持ち帰りするとき。。。(ある会社で、つかいっぱの巻)

 (1)お昼、「お持ち帰りご注文用紙」をつかって、みんなの注文をとってくる
 (2)その用紙をお弁当屋さんに行ってわたす
 (3)お弁当屋さんは、その用紙を見て、お弁当を作る
 (4)で、ここでふつう、「何とか弁当の方」っていわれない??
    →名前も必要ないし、電話番号もいらない

 電話予約した人の場合、名前のほかに、電話番号があったほうが安全。
 ところが、これは、電話予約の用紙も兼ねているとすると、またまたちょっとへん。一番下に「指定の時間までに、おつくりしておきます」
 とあるけど、指定の日にち、時間を書く欄がない。。。
 まあ、そもそも、電話予約にこの用紙をつかってるかどうかわかんないけど。。




 で、実務上、こういうことがよくあって、上記の場合、たぶん、

・おなまえ、電話番号を書かないでもってくるケースもある
・電話予約も、この用紙を使っている場合、指定の日時は、空白に書いている

だと思います。

 上の書かないケースはまだしも、空白は、気づかないのよね。。欄がないから。
 ウィリアムのいたずらが引っかかったケースは、
 チェック欄があって、そこをチェックするようになっていて、「その他」がない。
 なんで、きっと、その項目から選ぶとおもって、コードにしてしまおうとして。。。翌週、記入された用紙を見てびっくり!そのチェック欄おかまいなしに、横に線を引いて、勝手に記入してるのよ。。。

 学校でセンセイに教わっただろう!
 欄外に書いたら、さいてんされないんだぞお!

 なんてはいえないし。。。




 てなこともあるので、用紙は、記入されたものでみたほうが安全。

 プログラムのアプリケーションの都合や、現場の都合(用紙の流用)とかで、記入しない不要な項目があったり、逆に、まったくない項目を勝手に作って書いたりしてるから。。

 でも、最近は、機密保護の関係で、
 くれないんだよねー、記入済み用紙って(>_<!)
 そいとか、線でいっぱい消されたのが、きたり(でも、線で消されてても、未記入よりまし。記入していなければ、そこは線で消されてないし。。)


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

結局、マネージャーのお仕事の範囲は、下次第ということですかね。

2005-08-31 13:34:46 | 開発ネタ

 昨日の、マネージャーは、下の人間がやっていることを理解できる必要があるか否かに、いろいろ、コメント、トラックバックいただき、ありがとうございます。
 マネージャーは、管理だけでいいというのが、大方の意見のようにも見受けられますが、実際は、kudryavkaさんのように、それだけでは、すまないって言うのが、実情といえそうですね。

 たしかに、下請けに出す場合などは、まったく管理者がわからなくても、丸投げできるわけだし、逆に、会社の都合(作戦、計略??)で、下の人が、なーんにもわかんない場合には、マネージャーが、たぶん指導するだけでは、ぜんぜんすまないだろうし。。。

 ということで、やっぱり、マネージャーのお仕事の範囲は、下次第ということになるのでしょうね。




 でも、そうすると、状況は悪くなる一方なのかもしれません。
 というのは、現在出回っている仕様書の書き方から規定される仕事の手順内容などと、世間の本等で書かれている、いわれている手順などとは、違いがあり、その差を説明する人もいなければ、勉強する機会もない。
 ので、下の人は、自分の作業が、コンピューターサイエンスやソフトウエア工学のどこと結びついているかわからない。興味が沸かないというより、わけわなんないでこなすという状態だと思います。

 さらに、ずーっと下の人を下のままにさせておくというのは、人道上できない(初任給のまま、10年も20年も勤めさせるというのは、相手がフリーSEならさておき、社員だとできない。会社全体の士気が下がるし)ので、上に上げないといけない。そうすると、経験がある下の人が少なくなる。

 さらにさらに、下の人が上に上がった場合、フレームワークが最近頻繁に変わるので、管理ポイントが変化しているんだけど、それについていけない。
 たとえば、COBOLの場合とStrutsを使った場合では、モジュール割りから、管理方法まで、かなり変わってくる(まあ、今度覚えてたら、どこがどう違うなんてことはかきます)

 なんてかんじで、下の人に期待はできないし、自分の経験も当てにできない。。。マネージャーの仕事は難しくなるばかりかも。。。




はじめに書いていた、どうでもいいおまけについて:
(訂正:はじめに書いていた、例、まちがい。クリックすると、下のほうに、顧客エンティティのデータがあった。みえんかった。ふつうないんだけどね (^^;))

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

31日の「コピーされるほど儲かるシステム!開発日記」第22号

2005-08-31 11:02:11 | コピーされるほど儲かるシステム!

 8月31日、「コピーされるほど儲かるシステム!開発日記」第22号を出しました。
 内容は、

コピーされるほど儲かるシステムと同じ考え方の、インディーズのプロモーションサイト


YAHOOミュージックのサウンドステーションは、無料で曲がきけるらしい
の書き直しです。

 次号について、Windowsのデジタル著作権管理 (DRM)のSDKについてにしようかな、とおもったら、う、大部分が英語だ。。チュートリアルビデオも、英語だ。こまった。。。

 なので、次号の予定は、わかりません。

 ちなみに、まえの英語の話
わけあって、英語について思い出させられ(この理由は、数日後、このブログ内に書くと思います)
の理由は、上記のDRMの説明が英語だということにつながります。

ということで、あとは決り文句。




 22号のメルマガについての、感想などはここの「コメント」にどうぞ!

 メールと、ウィリアムのいたずら自身のブログについては、このブログの
「コピーされるほど儲かるシステム!開発日記」へのメールについて
http://blog.goo.ne.jp/xmldtp/e/a58b79b40b1148c2f744556e27b76a79
を参称してください



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

問題があるプロジェクトほど、(簡単なところが)進んでいる報告を受けるよね

2005-08-30 19:14:50 | 開発ネタ

 さっきのブログで、下手すると、ウィリアムのいたずらがとっても悪い子に思われたかもしれないので、ちょっとフォロー。

 順調に計画が言っている場合、可能であれば、普通、悪めに報告します。
 (モノには限度がありますが)

 というのは、順調に言っているものを、そのまま報告すると、順調に言っている時間で計算されてしまうからです。
 そうすると、あとで、問題が起こったとき、困るからです。
 問題が起こったからといって、たいてい、時間はくれません(>_<!)

 なので、悪めに報告しておいて、問題が起きても大丈夫なようにしておきます。

 だから、悪めに報告された場合は、訂正しないのね。
 マネージャーも、わからなかったら、悪めに報告するわけです。




 逆に、問題がありそうな場合は、よさげに報告されることが、多い気がします。

 これは、問題があって遅れてるんだけど、ちょっとでも、よさげにみせるためなのかな。。。私は、こういう報告をしないですんでいるけど、ほかの部署や人の報告で、きいたことがあります。

 この手の報告、特徴があります。

 GUIなど、あとで、手戻りが起こる部分を、どんどん開発していってます。
 (手戻りが起こりやすい部分というのは、実は開発しやすい。
  手作業でやる場合の入出力部分とか、帳票作成とか)

 で、同じところが、ずーっと残ってます。

 ある意味、簡単なところが、どんどん進んでいるプロジェクトは、注意したほうがいいのかも。。
 

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

マネージャーは、下の人間がやっていることを理解できる必要があるか否か

2005-08-30 13:13:15 | 開発ネタ

 プログラム開発などの場合、マネージャーが下の人のやっていることを理解して、指導できる場合と、まったく理解も指導もできず、管理するだけのケースと、実際、2種類ありますよね。

 で、本来、後者のケースがよいか悪いか。
 もし、悪いとすると、マネージャーは下の人間のやっていることが理解できて、指導できなければならず、マネージャーというのは、ある程度のプロジェクトになると、超人的な人しかできなくなってしまう(まったく知らない言語のプログラムがあって、その部分も管理しなければならないことは、ある程度の規模になるとあるから)

 後者のケースの場合、最大の問題は、事実と乖離した判断をしてしまうことがある場合。

 たとえば、自分はやったこともないし、状況も判断できない(というか、報告されている内容すら、わからないというケース)ので、必要以上に悪い状況と判断してしまう場合とか。

 こういう場合、このわからない部分が下請け会社だと、お金にかかわらなければ(というか、状況を悪く判断させ、難しいと思わせたほうがお金が稼げる)、自分が無能と判断されても、難しいと判断した、マネージャーの解釈を、わざわざ変えようとはしない。

 ということで、必要以上に難しく判断され、下請けは、サボりだす。。

 そんな、悪い下請けって、いるの!と思ったそこのあなた。

 今、ここにいる(^_^)v




 でも、これは、ましなケース。

 逆に、わからないから、進んでいると判断してしまうけど、実態は進んでいないというケースももちろんありえる。

 この場合は悲劇。

 急に、進捗はとまってしまい、それどころか、今までやったことも、不備があるということで、手戻りになったりする。

 うーん、やっぱ、マネージャーは指導できたほうがいい?

 とはいっても、プログラムの書き方とかは、その言語をやっていれば、指導することができたとしても、やってない言語を指導するのは、きつかったりするんじゃない(>_<!)

 いま、Javaのシステムでも、Javaだけやってればいいわけじゃないからねえ。。。

 それに、同じJavaでも、フレームワークによって、管理方法も違うしねえ。。。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

めも:かばやき(なまずを使いやすくしたオープンソースらしい)

2005-08-29 20:30:12 | コピーされるほど儲かるシステム!
http://kabayaki.jp/portal/syousai/index.html
自分のためのメモなんで、これでいいんですけど、
これだと???と思う人がいると思うので、ひとこと。

全文検索のなまずを使いやすくしたものらしい。
オープンソースらしい
お金を出すと、ExcelやWordのプロパティを検索できるらしい。

いじょう

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

PDCAのチェック(C)の道具としての管理台帳を、インセンティブとして使う方法

2005-08-29 15:17:36 | 開発ネタ

 おとといのブログ、見てる人多かった。

 意外と、個人の計画と、PDCAによる管理の問題&実務でどうしてるネタなど、請けるのかもしれないと思い、今日は図に乗ってその第二段。

 つい最近まで、大手の会社をみて、おばかだと思っていたものに、意味があることを知ったというお話。




 個人の計画は、たとえば、「この仕様書を何時(何時何分)までにおわらせ、その後、この仕様書を。。。」というふうに立てる人もいれば、「今日終わらせるのは、この仕様書とこの仕様書とこの仕様書」というふうに立てる人もいる。
 まちまちである。効率上、これは、どっちでやれと決め付けられない。

 小学生なら、前者である。後者のやり方は、たいてい、「漢字で、町という字を100回練習しなさい」といわれたときに、田を100回書いて、そのあと丁を右に100回書くみたいなやりかたである。
 子供なら、これは禁じ手だが、大人なら、これはありだからだ。




 っていうことで、人によってやり方が違い、報告のタイミングも違う。なんで、いちいち完了報告を受けていたのでは、マネージャーがたまらない。

 そこで、管理台帳をつくり、終わったら記入してもらうようにする。

 PDCAのCのチェックに相当する会議のときは(スクラムでいうデイリースクラム、現場的には、朝会(「あさかい」とよんでね。ちょうかいってよむと、歌、歌わないといけないけど、ソフトハウスの会合は、あんまり、歌、歌わないと思う)などの報告(進捗)会議では、この台帳の内容をもとに報告する。

 一方、現場への問題把握は、進捗会議レベルの回数では遅い。そこで、管理台帳の更新具合をみて、更新が遅れている(=進捗が滞っている)場合、問題がないかどうか、個別に声かけする。

 こんなふうに使うんで、台帳は有効。って思っていた。

 まあ、現場の作業する側にとっても、作業が整理されるメリットはあるんだけどね。




 で、大手さんに行くと、この台帳を、模造紙に書いて、できたところをシールで貼っていくっていう光景を見たりする。

 はじめ、「小学校ではあるまいし、みっともない」と正直思っていたが、これにも効果があるということに気づいた。

 インセンティブやペナルティを与えるには、その直後でないと意味がないというのは、コーチングでも、心理学でも聞く話。

 でも、作業が完了したときに、インセンティブなどをあげるとすると、いちいち報告を受けないといけない。これはむり。
 でも、この模造紙にシールを貼るという形にすると、みんなに終わったことが示せるし、なんとなく、仕事が消えていく楽しみ(プレッシャーがすごし和らぐという意味でのインセンティブ??)つーものもある。
 進捗が悪いと、無言のプレッシャー(自分のシールが少ない)が生まれる(=ペナルティ)




 っていうことで、みんながすぐ見えるようなところに、模造紙で、やることを書いて、できたらシールを貼るのは、管理台帳のチェックの補助という意味以外にも、効果があるということは、納得した。

 でも、その効能は認めたうえで、それでもなお、

 みっともないと思うよ(^^;)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AjaxのIMEと、松本研と、公文の英語の話

2005-08-28 15:44:41 | Weblog

 わけあって、英語について思い出させられ(この理由は、数日後、このブログ内に書くと思います)、「英語。。なんかブログに書こうと思ってたネタあったな!。。。思い出した!」となったので、きょうは、そのネタを書きます。




 この前(っていってもだいぶ前)、スラッシュドットをみていたら
 AjaxをつかったFull IMEがあるそうな。。。

 という記事を見ました。おお、使ってみようとおもって、みてみました
 ここです

 さ、ためしてみましょう。

 あむろなみえ

 おお、普通のかな漢だと、ぼろぼろなのに、3番目にでてくるではないか!すごい

 じゃあ、

 こうだくみ

 って、出るわけないか(^^;)つーより、これは、辞書のもんだいっすね。
 では気を取り直して、ちゃんとした文

 うみたまごのらっこは、たってさーふぃんをします
  (ほんとほんと。詳しくは、ここ

 海卵のラッコは、立ってサーフィンをします

 おお、できてますね




 で、そのブログをみていたら、「英語係り受け」の話がでていた
ここ

 そうそう、英語の係りうけによる解析っていうのは、学会的には、松本先生とかが、さきがけになるのでしょうが、受験業界では、駿台の高橋先生とかが、かかり受けを中心とした構文解析を利用して、受験生の人気を博しておりましたなあ。。。

 って、あれとは違うのかな?論文も見てないで、いいかげんなこといっております。




 英語の構文に着目し(たいていの場合は、文中の動詞に着目すると、その動詞の修飾関係で文がきれる、その文の切れる範囲に切れ目をいれたり、括弧でくくる)、読んでいくって言うのは、駿台の高橋先生のほかに、公文のGRやSRS、東京SIM外語研究所のスーパーエルマーなど、たくさんあるんだけど、その手法ははっきりしていない(区切りが、経験と勘になっている)よーな気がします。

 なんで、ちゃんとだれかが、英語かかり受けを研究して、それにそって、読む読み方を学校でおしえたら、日本の英語の能力は上がると思う。

 つーか、NHKの英語講座あたりで、この手のことを取り上げて欲しいんだけど。。。。

 っていうのは、公文の英語、たしかにいいんだけど、SRS,毎月13000円だと、ウィリアムのいたずらは、出費おおきいっす。むりっす(1回13000円だけならOKだけど、毎月続くのはたいへんっす!)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

個人が計画する時間と、開発上マネージャーが管理する時間単位のちがい

2005-08-27 19:42:26 | 開発ネタ

 ウィリアムのいたずらの場合、現在は、最底辺の人間だし、以前も、管理する側にいたことはあるものの、上の人たちとは、立場がちがうわけです。

 そういう人間が、この業界の上の人たちのブログをみると、下の世界のわたくしとは、まったく違う考え方をしているので、面白く感じることがあります。

(なーんてかくと、けんか売ってるように読めるかもしんないけど、そんな意図は、まったくないっす。本当に面白く感じた。。)




 最近、スケジュールを分刻みにするかどうかという話がでてますね。

 これ、下の人間は、開発規模うんぬんでなく、納期前かどうか(=開発段階)できまります。
 開発段階で、流れる時間(単位、ペースメーカー)を意識的に変えます。

 ただし、「大きいシステムは、納期前、分単位で管理せざる終えない」という理由を説明するのはやさしいですね。

 具体的にいうと、大きいシステムでは、CVSでは管理できず、make(antでもいいけど)でビルトして管理します。

 この理由は、だれだったかの日記に、「セキュリティに問題なければ、バージョン管理サーバーは、見えるところに置くべし」みたいなことが書いてあったけど、そのとおりで、CVSみたいなサーバーは、みんなが見えるところにないと、更新に矛盾がでるので、意味ない。でも、セキュリティ上、そんなことは、大手でゆるされるわけもなく。。。っていうのが1つ

 あと、勝手に更新されると、リグレッションテスト(回帰テスト)をやるタイミングは、どーするの?という問題が1つ。

 あと、これはちょっと説明すると長くなるので、今回は省略するけど、もう1つ理由があります(IT2の場合、PTとIT1を行わないといけないところからくる制約)。

 もちろんCVSに詳しい人からすると、反論はあるんだろうけど、現実的には、構成管理の係の人がいて、makeでビルトし、変更したいモジュールがある場合は、構成管理の係に、申請書を出すという形になっているのが現実な気がします。




 このような場合、納期前に、バグ修正を行うと、プロジェクトマネージャーは、分単位で管理せざる終えません。その理由を、具体的なお仕事内容をしめして、説明します。

 まず、ビルトは、ふつう1日2回以上走ります(朝皆がくる前に走らせ、その後、テストする。1日の定時の終わりにもう一度走らせる。もし、そのとき、おかしかったら、一晩かけて直すみたいなノリ)。
 多いときは、1日4回から、最高6回くらい(これ以上になると、事実上、不定期になる)。
 6回だと、(24時間開発しているので)1回のビルト感覚は4時間になります(これが限界だと感じている)。

 さて、次の構成管理に、バグ修正したいものを載せたい場合の手順は、一般に以下のとおりです。

■■ プログラマ
・プログラムソースを修正し
・コンパイルをして
・単体テストOKとなっているとして
(1)最後のビルトで出来たもので確認する
(2)マネージャーにわたす
(3)(マネージャーがやらない場合)申請書を書く

■■ マネージャー
(1)プログラマの(2)の物を受け取る
(2)IT1を行うため、関連するプログラムのマネージャーに配布
(3)(2)の結果を関連するマネージャーから受ける
(4)更新すると決定したら、申請用紙を記入
   →プログラマがやる場合や、あらかじめ書いておく場合あり
(5)構成管理に申請

プログラマの(1)、マネージャーの(2)、(3)、(4)、(5)の順に流れます。ステップが5つで4時間(=240分)なので、1工程48分ということになります。
 でも、これを1工程48分でできるか?と監視すると、そうはいかないわけで、(2)から(3)の工程に、かなりの時間がかかり、(4)、(5)の工程は、分単位で管理する形になりますね。

 実際には、(3)のうける報告が、何時何分までに報告がこなかったら、次のビルトに載せるのは見送ると、分単位で、自分の心の中では決めています(株でいう損切りラインに相当します)。
 つまり、(4)、(5)をあわせて10分として、3時にビルトなら、2時50分に報告を受けるのがデット、なので、2時40分までに回答が無ければ、こちらから確認、2時45分には回答の有無にかかわらず、終わらなかったらつぎまわし。

 こんなかんじで、納期前は、分きざみで管理です。
 ただ、こんな状況は、3ヶ月も続かない。。。よねえ(^^;)




 逆に、大きいプロジェクトはもちろん、小さいプロジェクトでも、開発初期は、相手の(とくに偉い人の)打ち合わせが取れる時間に、開発が左右されます。

 なので、下の人間は、細かい時間管理は難しいですね。

 もちろん、この場合でも、個人としては、別に細かい時間で計画していっていただいてもいいわけなんですけどね。




 なんで、偉い人の場合は、時間の計画レベルを、開発規模なんかで、分にしたり、時間にしたりするかもしれないんですが(個人に流れる時間を開発管理時間とし、まわりに、「それにあわせろ」といえるから)、下の人間の場合は、開発に流れる時間(基準となる時間、ペースメーカーとなる時間)の単位を、開発の場面、人によって変えます。

 場面によってかえるのは、上記のとおりなのですが、人によっても、おおきく変えますね。

 細かい時間単位に指示しないと、指示まちになるやつとか、
 1日単位に指示しないとやる気を損ねるやつとか、
 そもそも、分単位に、契約上、縛れない場合もあるわけで(お持ち帰りの請負仕事。法律上は当然しばってはいけないし(情報処理試験のお勉強で出てくるとおり)のこと、実質、縛れない)。




 ただ、基本的には、どこの会社も、PDSまたはPDCAのしくみによる、スパイラルの管理をするわけで、この場合、暴走させないためには、個人計画をチェックする仕組みが必要になってきます。そのため、そのチェック機能であるSないしCの部分を決定すると、それに対して、P(計画),D(行動=開発作業)のタイミングがきまってくるわけで、その範囲で、計画を立ててくれれば、いいようにします。

 スクラムの場合、デイリースクラムによって、Cを確認(=成果チェック)することになりますから(くわしくはここ)開発管理時間は、1日単位で、それにあわせて計画(P)をつくり、作業(D)してもらうことになります。

 その間の個人的な作業時間に関しては、自分の中に流れる時間に、基本的にはまかせます。

 (新人の場合や、自分のなかに流れる時間が極端に違うやつ、うつ病っぽい人の場合は、管理方法がちがう。スクラムは、うつ病患者対策を教えてくれてはいない。うつ病の人にスクラムの価値基準である「専念」を強要すると、悪化するよね!)




 で、現場では、構成管理と、朝会、夕会、昼会などの状況確認が、開発管理時間になります。
 (そうしないと、報告するネタがなくなるので、そうせざる終えない。。)

 そのため、1日よりも、短い時間(たいてい4時間くらい)で、P(自分の計画)を作ってもらわないと、マネージャーは、毎日朝会でPDCAが回ってないとおこられないといけなくなるので、

「強制です。自分の人間性うんぬんにかんけいなく、4時間単位で、計画をたてて、それにもとづき粛々と作業をすすめてくださいね!」

 なんてことは、まちがっても、メンバーにいえないので、ここも、うまい管理法があって(今度紹介するかも、面白い話があるんで)それをつかって管理します。

 そして、スクラムより、短い時間で管理することとなるので、スクラムでいう、スクラムマスター(現場的には、チームリーダーがこれにあたる)の役割が重要になります。

 。。。なんで?って、疑問に持っちゃうよねえ。。

 説明すると長いんだな、これが。。なんで、今日は、もう帰りたいから省略ぴょ!

 ではでは


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

仕事のBGMに、YAHOOのサウンドステーション、いいかも!

2005-08-27 02:40:10 | Weblog


昨日のブログで、反射的な作業を効率的にやるのには、スピード感を出すという話をしましたけど、このスピード感を出す簡単な方法として、BGMをかけるというのがあります。

 ITベンチャーっぽい会社だと、J-WAVEがかかること多し(関東の場合。関西だとFM802が似ているらしい)。
 そうすると、J-WAVEのこの番組までに、この仕事を終わらせようとかのめどが立てられるし、適当な刺激になるから。。

 ただ、この方法の欠点として、ウィリアムのいたずらが、実際にやって感じたことは、重いテーマの内容だと、作業がとまってしまうこと。どろどろの恋愛のお話(リスナーからのお手紙コーナーで)なんか、流れてくると、気分重たくなっちゃいました。




 で、それをさけるために、有線ってなると、お金かかるわけです。
 なんで、CDって言ってもやっぱりお金かかる。。。
 ということで、ウィリアムのいたずらは、(仕事以外でも)いつもはBGMをかけないんですけど、昨日から、無料のYAHOO!ミュージック サウンドステーションをきいています。
 結構、いいかも!ただ、以下の点に注意

(1)ログインしないと、3曲くらいしか聴けません
(2)番組が終わってしまうと、そこで一覧がでて、また聞く場合は、クリックしないといけません(エンドレスではない。もしかすると、設定があるのかもしれないけど)
(3)パソコンで聞くことになるので、音質は、そんなもんっす。
(4)途中、PRが入ります

 番組が終わるので、逆に言えば、1番組の間に、仕事を片付けようとか、計画を立てて聞けるかも。。。 




 ただし、一生懸命考えてるとき、BGMは、逆効果になることもあります。
 (はっきり言って、気が散る)



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

すべての仕事に対してモチベーションをあげることは可能か?そもそも必要があるのか?

2005-08-26 14:35:16 | 開発ネタ

 よく、最近、モチベーションということばを、いろんなブログで目にします。

 ちょっと気になるので、昨日と、おなじく、禁句のことを言ってしまいましょう。

 そもそも、すべての仕事に対して、モチベーションをあげる必要があるのでしょうか?

 たとえば、

 「1たす1は、」

 と聞かれたら、「2」って、すぐに答えますよね。

 このとき、モチベーションが高いから答えたんじゃないですよね。
 聞かれたから、答えたんですよね。反射です。
 前から車が来たとき、よけるのと同じです。
 モチベーションが高いからではないです。反射です。




 ウィリアムのいたずらの開発の場合、ほとんど多くの仕事は、この反射に近い状態です。

 プログラムを組んだりするのに、あまり、考え込みません。いわれたら、すぐにプログラムが出てきますから。。

 たぶん、「ワーカーさん」といわれる多くの人が、この状態だと思います。

 この状態でないと、安心して発注側は、仕事を出せないと思います。


 だって、考えてみないとわかんないとかいわれたら、
  考えてもだめだった。。。ってことがありえるわけで。。。
  でも、それって、しゃれになんないっしょ!
  発注してるんだから(^^;)




 かなり多くの仕事(この場合作業)、とくにソフト関係の仕事は、このレベルだと思います。
 頭の中にプログラムはでてきていて、それを追いかけてキーボードを打っているというかんじ。。

 で、そういう状態のときは、モチベーションをあげるというのは無理だし、あんまり意味ないです。

 車をよけるのに、モチベーションを上げると早くよけられる??

 モチベーションより大事なのは、スピード感です。

 スピードを上げると、この課題は、困難になるので、達成するためにモチベーションがあがることがあります。

 車が速く来ると、よけるのが大変になり、
 でも、よけるのが面白くなりゲームになってきます。
 うまくよけることにやりがいを感じたりします。

 でも、まちがっても、本当にそうかな?と思って実験しないでください。

 それで、いかなる犠牲者がでても、ウィリアムのいたずらは、しりませんからね。





 つまりですね、コンピューター作業で、仕事でやっている場合、多くの作業はモチベーションをあげる以前の反射の世界の話。この作業で効率化を図るには、スピード感を出す(さらにスピードをあげてゲーム化する)ことで、その課題を達成しようとするモチベーションがあがる。といえると思います。

 この際、競い合うのも1つの手なのですが、そんなことしなくっても、モチベーションはあがります。自分で、毎日記録をとっていると、「今日はここまでやろう!」と達成課題を普通作るからです。




 つまりですね、単調な作業には、スピード感を感じさせることが、効率化の第一歩なのであります。で、ゲーム化できて、目標ができれば、しめたもんです。

 はい、ながい、前置き終わり

 (実は、この文章、あとで書こうとする文の、前置きだったりする。
  ただ、その文章、あとで書くことを忘れてしまうかもしれん。そのときは、ごめん!)


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ペアプログラミングの問題点:まわりの人からみるとうるさい!っていうのは禁句?

2005-08-25 19:28:54 | 開発ネタ

 たぶん、あのグループは、ペアプログラミングで開発しているのであろう。

 おお、最近は、ペアプログラミングが、こんなところまで浸透しているのであるね。。。

 でも、きっと、この一言は、禁句になっているあるね。

 ペアプログラミング、やってる当人はいいけど、

 まわりにいると、うるさい!!


 会社は、静かにお仕事するもんだぞお!
 (わかる人へ:「ぱにぽに」のレベッカ宮本先生(=ベッキー)風に)

 でもそんなこといえない。

 なぜか。

 自分もケータイの開発で、ヘッドフォンしてないから、うるさいので。

 でも、大手にペアプログラミングが導入されたら、うるさいに違いない。

 まちがいない。

 なんて書いてたら、急に静かになった。。

 ひょっとして、今書いてるの見られてたりして(^^;)


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

環境変数って変えたいときありません?WSHを使うのがいいのかなあ

2005-08-25 15:20:04 | Weblog

 環境変数って、変えたいときありませんか?

 たとえば、BREWの2.1と3を切り替えたいとき、環境変数BREWDIRをかえればいい。
 で、マニュアルには、別アカウントで入ればいいってかいてある。
 それはたしかにそうで、いまそうしてるんだけど、めんどっちい。。。

 あと、テストなんかで環境合わせたいときとか。。

 で、そういうとき、バッチで、どうやるんだっけ?SETだっけSETENVだっけとおもって、検索しらべてたら、WSHが出てきた。

 うーん、やっぱ時代はWSHかなあ。。。

 と思い、時間があったら見ようと思って、とりあえず、参考になりそうなサイトのめもめも




http://www.roy.hi-ho.ne.jp/mutaguchi/wsh/wshtop.htm
 ここが人気のようだ

http://www.atmarkit.co.jp/fwin2k/operation/wsh01/wsh01_02.html
http://www.atmarkit.co.jp/fwin2k/win2ktips/460envset/envset.html
 WshEnvironment.Item("キー")="値" で環境変数は変わりそう

http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/script56/html/wsoriWindowsScriptHost.asp
本家


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

細かく時間を分けて管理すると、人間性が疎外されるように感じる。その際の管理法

2005-08-25 13:55:13 | 開発ネタ

 きのうのアクセス数が意外とあったので(たぶんホットドッグのほうだと思うけど)、もしかすると、原価計算のはなしに興味あり!かもしんないので、今日は、昨日書いた「ホーソン実験の応用としてのスクラムの利用」について。

 あ、その前に、今までの話は、作業量とお金と時間が比例している(少なくても関係がある)場合のお話です。たとえばアジャイルの開発で、月ぎめや時間給でお金をもらっている場合は、この話とは違った管理方法をします(理由:ユーザーの仕様変更によって、いままで作ったものがすべて無駄になる可能性がある。それでも現金を回収するため月ぎめや時間給(=拘束時間による支払い)にするのですが、その場合、生産量による支払いではないので、原価計算管理には、なじまないです)。

 これらの話が成立するのは、比較的難易度が低いプログラミングや設計、入出力(画面・DBアクセス)などの作成の場合です。




 これらの管理をする場合、たとえば、帳票1つにつき1日とかいうように管理します。ただ、この管理が行き過ぎると、あるドキュメントをつくるのに3時間とか、非常に細かい単位になってしまいます。

 ここまで細かい単位になると、問題が起こります。

・作業の途中に邪魔が入ると、その時間が予定外となり、計画がずれる。
 そのため、邪魔が入らないように。。。というのは、結構難しい
 →どっかの会社のように、がんばるタイムの導入とか(^^)

・ユーザーの要望などのように、仕様変更というのが頻繁に起こると
 現場が混乱するし、標準時間以内には、できないことが多い。
 (安定して、ある程度の量をこなすと、経験曲線に示されるように、
  時間は少なくてすむ=安定しないと、経験が積まれず、時間がかかる)

・作業する側は、疎外感を感じる。
 アジャイルなどの導入は、この疎外感から逃れるために、自分の居場所探しで導入されることがあります

 ただし、上の人間からみると、細かい単位で管理したほうが、管理しやすいわけです(差異の部分が細かくわかり、どこがどういう状況になっているかの把握がしやすい)




 で、どうするか。

 スクラムを採用しているか否かにかかわらず、定期報告というのをしているはずです。この定期報告の単位で、作業を管理するのが、やりやすいです。

 たとえば、仕様書1つ30分として、8時間労働だったら、

 管理用の標準作業時間は、それ(1つ30分)でいいんだけど、

 仕事の管理内容としては、
 定期報告が毎日あるんなら、

 16本分の仕様書を今日作って、できたかどうか、明日の定期報告で報告。
 それ以外、今日は「自由に使っていい」

 と、自由な部分を認めないと、無理が出てきます。機械じゃないんですし、学校でもないんですから。。




 そもそも、標準時間の概念は、テーラーが導き出したものですが、テーラーは、あのとき、標準作業時間より、よくできたものに対しては、多くの賃金を払うという出来高性をたしか、導入していたと思います。

 でも、今の現状では、標準時間でちゃんとやったから、ほめられるとか、それ以上やったら、インセンティブがもらえるという仕組みはないです。だから、標準時間を単純に導入して、作業をきめてしまうと、そこに人間性の存在を認められなくなり。。うう、哲学的になりそうなんで、ここでやめとくけど、そんなかんじ。




 そこで、ホーソン実験がでてくるわけです。「特別な人」と意識させることによって、パフォーマンスがあがるという、作業における人間関係について言及したホーソン実験なわけっす。

 定期報告させるときに、その報告内容をただ単純にきき、あたりまえとおもうんじゃなくって、標準時間で終わらせられた、さらには、それ以上にできたリアクションが必要になってくるんじゃあないでしょーか(まあ、簡単に言ってしまえば、ほめるということになるが、それくらいでほめだすと、あぶない宗教団体のようになってしまう。まあ、そういう宗教団体のようなかんじで、仕事を進めてもいいんだけどね)




 うーん、話題が広く、ちょっち、はなしさんまん。
 なので、とりあえず、ここまで。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ひえー、アルバイトの書いたブログで企業が謝んないといけない時代なのか!

2005-08-24 19:25:24 | Weblog

 スラッシュドットのここの記事によると、ホットドッグチェーンの「ネイサンズ」というところのフランチャイズ店の社員が、客をからかうブログを書き、その「ネイサンズ」が謝っているらしい。(っていうか、ここに、謝罪文が!)

 おお、アルバイトの1人のブログのせいで、本社の人が謝んなくっちゃなんない時代なんですな。。でも、アルバイト全員のブログのチェックなんて、できないしねえ。。

 ウィリアムのいたずらの場合、実名はだしてないし(出せないっす。内容的に)あと、ウィリアムのいたずらが従事している、してきた仕事なんかも、名前を明らかにしてないので、あんまりわかんない人が多いと思う(とはいえ、かなり、絞り込まれるんだけどね)ので、まあいいけどね。。

 その記事に載っている、「いかに安全にブログを運営するか(仕事やその他色々に関して)」は読んでおかないと??

(ちなみに、そのアルバイトの人のブログの記事は削除されていて、スナップショットはこれらしい。。??)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする